bug#30228: desktop files embedding full path

[Efraim Flashner]

Fixed in commit 2b371f4dd5ddafa0786240b40408ef5c30d7a526

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#19749: Progress

[Leo Famulari]

On Tue, Feb 19, 2019 at 11:53:41PM +0100, Andreas Enge wrote:
> Hello,
> 
> this bug dates from a time where it was still almost realistic to reach
> zero non-building packages... Should we close it, since mips has been
> removed from the release architectures?

Yes, I've closed it.


signature.asc
Description: PGP signature

bug#34565: ungoogled-chromium contains Widevine DRM

[Leo Famulari]

On Tue, Feb 19, 2019 at 03:44:17PM +0100, Julien Lepiller wrote:
> So I've downloaded the source tarball with `guix build -S chromium`
> and here's what I found in it:

[...]

Thanks for taking a look, Julien!

We need to find out if Widevine DRM is actually included in the Guix
ungoogled-chromium package or not.

Obviously the intent was to not include it, and it does not work in
practice. Widevine videos do not play and there is no prompt to install
or enable DRM, unlike in some other browsers that use DRM.

I think the next steps for this subject are to first, in general, figure
out where Widevine comes from, and then, more specifically, decide what
to do about the files you mentioned. 

As I mentioned already, other distros seem to get Widevine by extracting
its binary from Chrome, even when using it for Chromium. It seems
reasonable to assume that if Widevine were included in Chromium they
would not be downloading a whole 'nother browser for that one component.

As for the specific files listed by Julien, they may be harmless, or
not, we should figure out what they do and if they need to be removed.


signature.asc
Description: PGP signature

bug#34565: ungoogled-chromium contains Widevine DRM

[Jason Self]

Leo Famulari wrote:
> To clarify this general point about Guix for anyone who is reading
> along, as a matter of policy the end user does not receive non-free
> source code from Guix.

Right; the source is downloaded from commondatastorage.googleapis.com
but that is a technicality. What I'm saying is that the recipe should
be updated to cause it to download an already-cleaned up version
directly from Guix (it could be hosted somewhere on gnu.org for example
but exactly where can be up for negotiation) and that this excuse of
"they're getting it elsewhere" shouldn't be usable as an excuse to
sidestep the FSDG. It's still causing the user to download the software
due to the recipes provided by Guix.

> The tools provided by Guix to access source code only return source
> code that is freely licensed. If the sources have to be modified to
> ensure this, the unodified source code is not provided to the user. 

It's still being downloaded into their computer and then being cleaned
up after the fact. If there weren't freedom problems with it there
wouldn't be a need for a clean-up program (ungoogled-chromium in this
case) to be running -- as a process on the user's computer -- to do
this.

And in https://www.gnu.org/distros/free-system-distribution-guidelines.
html we have:

"For instance, a free system distribution must not contain browsers that 
implement EME, the browser functionality designed to load DRM modules."

So that should make it quite clear.

bug#34565: ungoogled-chromium contains Widevine DRM

[Leo Famulari]

On Tue, Feb 19, 2019 at 05:12:17PM -0800, Jason Self wrote:
> Taking this and considering Guix's build process: The method of
> building seems to involve downloading Chromium, then runnning
> ungoogled-chromium over it, and then building. I'm not sure if any
> other packages have their freedom problems fixed in this way but this,
> just like build flags, should not be sufficient. Freedom problems
> should not be hidden/removed after the fact by asking the user to run a
> clean-up program after downloading the source, even if that has been
> automated by the package manager. What is sent to the end user to
> compile should itself be 100% free software and FSDG compliant from the
> beginning. If not it still amounts to distributing non-free software to
> the user when they want to, for example, do guix build -S chromium.

To clarify this general point about Guix for anyone who is reading
along, as a matter of policy the end user does not receive non-free
source code from Guix.

The tools provided by Guix to access source code only return source code
that is freely licensed. If the sources have to be modified to ensure
this, the unodified source code is not provided to the user. Guix is
specifically designed to do it this way.


signature.asc
Description: PGP signature

bug#34565: ungoogled-chromium contains Widevine DRM

[Jason Self]

> should not be hidden/removed after the fact by asking the user to run
> a clean-up program after downloading the source, even if that has
> been automated by the package manager. What is sent to the end user
> to compile should itself be 100% free software and FSDG compliant
> from the beginning. If not it still amounts to distributing non-free
> software to the user when they want to, for example, do guix build -S
> chromium.

I should probably add on that this position comes from my interaction
with the FSF in 2010: When LibreWRT was founded in 2010 (before it
later merged into libreCMC) we submitted a similar question to the FSF,
as to if it was sufficient for the LibreWRT build scripts (which would
be run by the person building the firmware image from source and would
have completely automated, just like how someone might instruct Guix to
build from source) to download Linux and then run the Linux-libre
deblobbing scripts on it vs having the build scripts instead download
tarballs that were already cleaned up. I can't seem to find the email
from back then but the response was that we needed to use already
cleaned-up tarballs, not ask the user to clean up the software after
ward even if automated. So that was what we did. Guix should do
something similar.

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

bug#34565: ungoogled-chromium contains Widevine DRM

[Jason Self]

A different but related matter is the build process itself. I
understand this is not exactly related to the DRM matter but it does
seem similiar. I can open another bug over this if needed. I have
recently submitted upstream's Chromium 73.0.3683.45 into my FOSSology
instance for analysis. Actually, less than a third of the total files
were classified as "BSD-like". In total it found 162 unique licenses.
Of course, automated licenses analysis is never perfect and I have not
fully vetted any particular results but it does help to at least
indicate that which is very clearly free software and that which needs
further investigation.

Even in the short time I was reviewing it I found a number of freedom
problems. I don't mean that to be an exhaustive list of everything,
merely an indicator of a symptom:

* unrar (license denies freedom 0)
* third_party/blink has some images under CC-BY-NC-SA-2.0
* Google Toolbar is in there, with a non-free EULA

Taking this and considering Guix's build process: The method of
building seems to involve downloading Chromium, then runnning
ungoogled-chromium over it, and then building. I'm not sure if any
other packages have their freedom problems fixed in this way but this,
just like build flags, should not be sufficient. Freedom problems
should not be hidden/removed after the fact by asking the user to run a
clean-up program after downloading the source, even if that has been
automated by the package manager. What is sent to the end user to
compile should itself be 100% free software and FSDG compliant from the
beginning. If not it still amounts to distributing non-free software to
the user when they want to, for example, do guix build -S chromium.

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

bug#34565: ungoogled-chromium contains Widevine DRM

[Jason Self]

Based on http://issues.guix.info/issue/28004#2 it is disabled at build
time; but not removed. The person said they thought this was FSDG
compliant but a reading of "the distro must contain no DRM" from the
FSDG could be taken to mean the distro still "contains" it, since it's
still within the source code of the program. "Disabled by default"
shouldn't be good enough IMHO; build flags should not be used to hide
freedom problems. The source code represents what the software *is*,
not the build flags.

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

bug#34570: Failure to build swig/graphviz

[Andreas Enge]

On Tue, Feb 19, 2019 at 10:34:01AM +0100, Andreas Enge wrote:
> if there is not an obvious error somewhere,
> it might be easier to close the bug report as not reproducible or non-deter-
> ministic.

Doing so.

Andreas

bug#32253: Fixed

[Andreas Enge]

The bug has apparently been fixed in the meantime, I cannot reproduce
it any more.

Andreas

bug#19749: Progress

[Andreas Enge]

Hello,

this bug dates from a time where it was still almost realistic to reach
zero non-building packages... Should we close it, since mips has been
removed from the release architectures?

Andreas

bug#18221: Close

[Andreas Enge]

The bug stricto sensu has been fixed by a "supported systems" clause.
Since in more than 4 years nobody seems to have missed the package on
other architectures, I am closing the bug for now.

Andreas

bug#17117: Close

[Andreas Enge]

There have been so many changes since this bug was opened that it is not
meaningful any more, and it was in any case more of "wishlist type".
Closing it.

Andreas

bug#32238: Close

[Andreas Enge]

The problem was corrected at some point in time without reference
to the bug. The calibre package now builds and works.

Andreas

bug#22835: Close

[Andreas Enge]

This can probably be closed, as nobody really remembers any more
what it is about.

Andreas

bug#27462: OCaml CVE-2015-8869

[Andreas Enge]

On Thu, Jan 31, 2019 at 06:30:27PM +0100, Julien Lepiller wrote:
> I still care about ocaml-4.02, but I could probably update it to ocaml-4.04 
> without breaking dependents.

Commits 2e125ece093ef842ca017ffb146cbc5fa33f2f75 and
4982c0c98deecea0d4f69f14ea28cab53b5f2123 remove ocaml@4.01, pplacer and
all other dependent packages.

Is ocaml@4.02 really needed? It would be nice to get rid of a package
with CVE.

Andreas

bug#34580: Service ssh-daemon could not be started

[Andreas Enge]

Hello,

twice in a row at work (on harbourfront) and now twice in a row at home
(on dover) I am in a situation where sshd does not start on Guix machines.
Networking is available (the machines can be pinged), and I have to log
in via a console and execute "herd start ssh-daemon" by hand.

Here is the relevant portion of /var/log/messages for dover:
Feb 19 22:02:23 localhost vmunix: [  108.990196] ipmi_si e001.kcs: There 
appears to be no BMC at this location
Feb 19 22:02:23 localhost vmunix: [  109.021176] shepherd[1]: Service udev has 
been started.
Feb 19 22:02:23 localhost vmunix: [  109.026910] Adding 467648k swap on 
/dev/sda4.  Priority:-2 extents:1 across:467648k FS
Feb 19 22:02:23 localhost vmunix: [  109.037138] shepherd[1]: Service 
swap-/dev/sda4 has been started.
Feb 19 22:02:23 localhost vmunix: [  109.045502] shepherd[1]: Service 
user-file-systems has been started.
Feb 19 22:02:23 localhost vmunix: [  109.229105] shepherd[1]: Service 
file-system-/boot/efi has been started.
Feb 19 22:02:23 localhost vmunix: [  109.238721] shepherd[1]: Service 
file-system-/dev/pts has been started.
Feb 19 22:02:23 localhost vmunix: [  109.248214] shepherd[1]: Service 
file-system-/dev/shm has been started.
Feb 19 22:02:24 localhost vmunix: [  109.257629] shepherd[1]: Service 
file-system-/gnu/store has been started.
Feb 19 22:02:06 localhost ntpd[354]: Command line: 
/gnu/store/rgj9dvakw960p0p44cq6kfwk9a4pzcmw-ntp-4.2.8p12/bin/ntpd -n -c 
/gnu/store/1l1yf5dss8r9pqxklaax32s6bkah09c6-ntpd.conf -u ntpd
Feb 19 22:02:24 localhost vmunix: [  109.266692] shepherd[1]: Service 
file-systems has been started.
Feb 19 22:02:24 localhost vmunix: [  109.284615] shepherd[1]: Service 
urandom-seed has been started.
Feb 19 22:02:24 localhost vmunix: [  109.292825] shepherd[1]: Service 
user-processes has been started.
Feb 19 22:02:24 localhost vmunix: [  109.301269] shepherd[1]: Service host-name 
has been started.
Feb 19 22:02:24 localhost vmunix: [  109.318409] shepherd[1]: Service 
user-homes could not be started.
Feb 19 22:02:24 localhost vmunix: [  110.331371] shepherd[1]: Service nscd has 
been started.
Feb 19 22:02:24 localhost vmunix: [  110.343051] shepherd[1]: Service 
guix-daemon has been started.
Feb 19 22:02:24 localhost vmunix: [  116.296395] sky2 :02:00.0 enp2s0: 
enabling interface
Feb 19 22:02:24 localhost vmunix: [  116.301800] IPv6: ADDRCONF(NETDEV_UP): 
enp2s0: link is not ready
Feb 19 22:02:24 localhost vmunix: [  118.611449] sky2 :02:00.0 enp2s0: Link 
is up at 1000 Mbps, full duplex, flow control rx
Feb 19 22:02:25 localhost vmunix: [  118.619821] IPv6: ADDRCONF(NETDEV_CHANGE): 
enp2s0: link becomes ready
Feb 19 22:02:25 localhost shepherd[1]: Service mcron has been started. 
Feb 19 22:02:08 localhost dhclient: DHCPACK of 192.168.1.113 from 192.168.1.1
Feb 19 22:02:10 localhost sshd[359]: Server listening on 0.0.0.0 port 22.
Feb 19 22:02:12 localhost nscd: 314 monitored file `/etc/resolv.conf` was moved 
into place, adding watch
Feb 19 22:02:12 localhost dhclient: bound to 192.168.1.113 -- renewal in 19054 
seconds.
Feb 19 22:02:25 localhost shepherd[1]: Service ssh-daemon could not be started. 
Feb 19 22:02:17 localhost ntpd[354]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Feb 19 22:02:20 localhost ntpd[354]: Listen normally on 3 enp2s0 
192.168.1.113:123
Feb 19 22:02:20 localhost ntpd[354]: Listen normally on 4 lo [::1]:123
Feb 19 22:02:21 localhost ntpd[354]: Listen normally on 5 enp2s0 
[fda3:5c49:ae85:0:e2ff:f7ff:fe00:20b3]:123
Feb 19 22:02:23 localhost ntpd[354]: Listen normally on 6 enp2s0 
[2001:910:103f:0:e2ff:f7ff:fe00:20b3]:123
Feb 19 22:02:24 localhost ntpd[354]: Listen normally on 7 enp2s0 
[fe80::e2ff:f7ff:fe00:20b3%2]:123
Feb 19 22:02:25 localhost ntpd[354]: Listening on routing socket on fd #24 for 
interface updates
Feb 19 22:02:25 localhost ntpd[354]: kernel reports TIME_ERROR: 0x41: Clock 
Unsynchronized
Feb 19 22:02:25 localhost ntpd[354]: kernel reports TIME_ERROR: 0x41: Clock 
Unsynchronized
Feb 19 22:03:26 localhost shepherd[1]: Respawning term-ttyAMA0. 
Feb 19 22:03:26 localhost shepherd[1]: Service term-ttyAMA0 has been started. 
Feb 19 22:03:48 localhost sshd[380]: Server listening on 0.0.0.0 port 22.
Feb 19 22:03:48 localhost sshd[380]: Server listening on :: port 22.
Feb 19 22:03:48 localhost shepherd[1]: Service ssh-daemon has been started. 

Besides the notice that "Service ssh-daemon could not be started" I do not see
much information. The second time corresponds to the starting by hand.
Maybe it is a problem that " sshd[359]: Server listening on 0.0.0.0 port 22."
at 22:02:10 before the IP address arrives via dhcp 2 seconds later?

Andreas

bug#34567: Bogus 'upower-service' deprecation message

[Christopher Baines]

Mark H Weaver  writes:

> My OS config includes a reference to 'upower-service', which is now
> deprecated, but the deprecation message is bogus:
>
>   mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1
>   /etc/config.scm:149:19: warning: 'slim-service' is deprecated, use 
> 'slim-service-type' instead
>   /etc/config.scm:156:19: warning: 'upower-service' is deprecated, use 
> 'Return a service that runs @uref{http://upower.freedesktop.org/,
>   @command{upowerd}}, a system-wide monitor for power consumption and battery
>   levels, with the given configuration settings.  It implements the
>   @code{org.freedesktop.UPower} D-Bus interface, and is notably used by 
> GNOME.' instead
>   building 
> /gnu/store/nwdjz1mkvcc4ic65mgw5i94ig3qzp8kf-libjpeg-turbo-2.0.2.tar.gz.drv...
>   [...]

Haha, that is quite bogus. I didn't realise define-deprecated took two
arguments. I've sent a patch to fix this here [1].

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


signature.asc
Description: PGP signature

bug#33608: bug#33882: Blender is not loading menu scripts

[Leo Famulari]

On Sun, Jan 06, 2019 at 12:03:03PM +0100, Thorsten Wilms wrote:
> Sounds reasonable. However, Blender is a case where it might be worthwhile
> to keep a 2.79 around even after the final release of 2.8, because the
> graphics card requirements have been increased to  OpenGL core 3.3 *

I think this problem has finally been reported and fixed upstream:

Reports:

https://lists.blender.org/pipermail/bf-committers/2019-February/049823.html
https://blenderartists.org/t/new-blender-install-gui-is-empty-no-icons-controls-etc/1145751

Fix commmit:

https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/1db47a2ccd1e68994bf8140eba6cc2a26a2bc91f

I didn't test the fix but it's reported to work in that mailing list
discussion.

Blender 2.8 is working fine for my very limited use case, so I'm not
going to resurrect Blender 2.79 in Guix.

However, if somebody sends a patch that brings it back in a working
state, we can have both versions in Guix during the 2.79 -> 2.8 upstream
transition.


signature.asc
Description: PGP signature

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Tomáš Čech]

On Thu, Jan 10, 2019 at 07:51:07AM -0500, Maxim Cournoyer wrote:

Debugging a bit further, it seems that my change to the
network-manager-service-type had the following effect:

A file populated at /etc/dbus-1/system-local.conf now has an include
directive for network-manager-openvpn:

--8<---cut here---start->8---
/gnu/store/gw3ckmw2pihc44d23lc8pipfw7wr16g7-network-manager-openvpn-1.8.0/etc/dbus-1/system.d
--8<---cut here---end--->8---

There is no /etc/dbus-1/system.conf file, which usually should source
the above system-local.conf, although the package holds a copy of it
such as
/gnu/store/5bda3bgy871dyb9cna4k7gnz002j88rq-dbus-1.12.6/share/dbus-1/system.conf,
and this file has:

--8<---cut here---start->8---

 /etc/dbus-1/system-local.conf
--8<---cut here---end--->8---

I'm not sure if it works though, because using the Emacs dbus support to
view the available definitions, I cannot see the ones from the
system-local.conf file:

--8<---cut here---start->8---
(require 'dbus)
(dbus-list-activatable-names ':system)

;; Results:
("org.freedesktop.DBus";
"org.freedesktop.UPower"   ;from /etc/dbus-1/system-services
"org.freedesktop.GeoClue2" ;from /etc/dbus-1/system-services
"org.freedesktop.login1"   ;from /etc/dbus-1/system-services
"org.freedesktop.UDisks2"  ;from /etc/dbus-1/system-services
"org.freedesktop.ColorHelper"  ;from /etc/dbus-1/system-services
"org.freedesktop.PolicyKit1"   ;from /etc/dbus-1/system-services
"org.freedesktop.Accounts" ;from /etc/dbus-1/system-services
"org.freedesktop.ColorManager" ;from /etc/dbus-1/system-services
"org.freedesktop.nm_dispatcher")  ;from /etc/dbus-1/system-services
--8<---cut here---end--->8---

So it could be that the system-local.conf file is not read in.

I've tried stracing the dbus-daemon (by attaching to it) as suggested by
Ludovic on #guix, but that doesn't mention anything about reading the
files.

So, to debug this further, I've added the documentation to dbus [1] and
in `man dbus-daemon`, we can read:



--8<---cut here---start->8---
DEBUGGING
  If you're trying to figure out where your messages are going or why you 
aren't getting messages, there are
  several things you can try.

  Remember that the system bus is heavily locked down and if you haven't 
installed a security policy file to
  allow your message through, it won't work. For the session bus, this is 
not a concern.

  The simplest way to figure out what's happening on the bus is to run the 
dbus-monitor program, which comes
  with the D-Bus package. You can also send test messages with dbus-send. 
These programs have their own man
  pages.

  If you want to know what the daemon itself is doing, you might consider 
running a separate copy of the daemon
  to test against. This will allow you to put the daemon under a debugger, 
or run it with verbose output,
  without messing up your real session and system daemons.

  To run a separate test copy of the daemon, for example you might open a 
terminal and type:

DBUS_VERBOSE=1 dbus-daemon --session --print-address

  The test daemon address will be printed when the daemon starts. You will 
need to copy-and-paste this address
  and use it as the value of the DBUS_SESSION_BUS_ADDRESS environment 
variable when you launch the applications
  you want to test. This will cause those applications to connect to your 
test bus instead of the
  DBUS_SESSION_BUS_ADDRESS of your real session bus.

  DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was compiled 
with verbose mode enabled. This is
  not recommended in production builds due to performance impact. You may 
need to rebuild D-Bus if your copy
  was not built with debugging in mind. (DBUS_VERBOSE also affects the 
D-Bus library and thus applications
  using D-Bus; it may be useful to see verbose output on both the client 
side and from the daemon.)

  If you want to get fancy, you can create a custom bus configuration for 
your test bus (see the session.conf
  and system.conf files that define the two default configurations for 
example). This would allow you to
  specify a different directory for .service files, for example.
--8<---cut here---end--->8---

This should help in further debbugging the issue, along with this local
definition that enables the verbose mode of dbus:

--8<---cut here---start->8---
gnu/packages/glib.scm | 11 +++

modified   gnu/packages/glib.scm
@@ -68,6 +68,7 @@
  ;; Export variables up-front to allow circular dependency with the 'xorg'
  ;; module.
  

bug#34407: [PATCH] shepherd: Delete the socket file upon exit.

[Danny Milosavljevic]

On Sun, 17 Feb 2019 11:38:16 +0800
iyzs...@member.fsf.org (宋文武) wrote:

> Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
> script too...
> 
> According to 'man 2 bind', the socket pathname should be deleted when no
> longer required, so a patch to fix this bug:

Hmm, I guess you can do that.

But /run is supposed to be a tmpfs and elogind is supposed to rm -rf 
/run/user/1000
after all sessions of that user terminated in any case, so how is it left over
in the first place?

If the deletion in the case above doesn't work, please report a bug.

If that patch is only in order to enable users to restart user's shepherd
without exiting all their sessions, then I guess that's ok--although unusual.

Does your patch do the right thing if the user's shepherd is already
running? (i.e. keep the socket file)


pgpP93wFjHWpO.pgp
Description: OpenPGP digital signature

bug#34526: Updating node.js

[Daniel Gerber]

I mean, it builds after also updating libuv: 

--- gnu/packages/libevent.scm.orig	2019-02-13 10:04:31.913458810 +0100
+++ gnu/packages/libevent.scm	2019-02-19 13:30:49.496780516 +0100
@@ -124,14 +124,14 @@
 (define-public libuv
   (package
 (name "libuv")
-(version "1.24.0")
+(version "1.26.0")
 (source (origin
   (method url-fetch)
   (uri (string-append "https://dist.libuv.org/dist/v"; version
   "/libuv-v" version ".tar.gz"))
   (sha256
(base32
-"01pg0zsfr8mxlpipkbpw0dpsl26x5s966f5br7dx9ac29abk419q"
+"1rqlh0ag02fni8ildz3anc26z9vz69vwf5qmzsid2gvzzfkigy6a"
 (build-system gnu-build-system)
 (arguments
  '(;; XXX: Some tests want /dev/tty, attempt to make connections, etc.

Then, tests from test/cctest/test_inspector_socket.cc fail.

bug#34573: Backtrace of guix pull failed

[Leo Famulari]

On Tue, Feb 19, 2019 at 05:48:01PM +0100, Vincent Rouvreau wrote:
> Maybe this is not a guix bug but a server issue.
> Sorry for the noise, I will see with the admin.

This is likely related to .

If so, the solution is to either use nscd, as Ricardo suggested, or to
edit '/etc/nsswitch.conf'.


signature.asc
Description: PGP signature

bug#34573: Backtrace of guix pull failed

[Vincent Rouvreau]

Hello,

I rolled back all my generations (I hope this is good - with command guix 
package --roll-back)

$ guix package -i python python-numpy python-conda
Les paquets suivants seront installés :
   python   3.7.0   /gnu/store/9z98cvjm7p7z21xdid1ryydxy5vyz6wr-python-3.7.0
   python-numpy 1.15.4  
/gnu/store/hsdzxq5jvb96yffnxqp8h4lq5z59r29k-python-numpy-1.15.4
   python-conda 4.3.16  
/gnu/store/gabw5n3216xzbbsjsc5j5vhjpninanyh-python-conda-4.3.16

$ eval `guix package --search-paths=prefix`

It seems there is no issue.

nscd seems to be launched. I am not admin on the server.
$ ps aux | grep nscd
vrou001   25642  0.0  0.0 112688   976 pts/37   S+   17:46   0:00 grep 
--color=auto nscd
nscd 135028  0.0  0.0 768500  4020 ?Ssl  févr.11   2:17 
/usr/sbin/nscd

Maybe this is not a guix bug but a server issue.
Sorry for the noise, I will see with the admin.

Regards,

Vincent Rouvreau

- Mail original -
> De: "Andreas Enge" 
> À: "vincent rouvreau" 
> Cc: 34...@debbugs.gnu.org
> Envoyé: Mardi 19 Février 2019 16:42:02
> Objet: Re: bug#34573: Backtrace of guix pull failed

> Bonjour Vincent,
> 
> On Tue, Feb 19, 2019 at 10:55:58AM +0100, Vincent Rouvreau wrote:
>> And guix pull failed :
>> 
>> guix package -i python python-numpy python-conda
>> eval `guix package --search-paths=prefix`
> 
> so the first two commands succeeded?
> 
>> guix pull
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   2887:24 19 (_)
>>222:29 18 (map1 (((guix i18n)) ((guix gexp)) ((guix sets)) ((?)) ?))
>>222:29 17 (map1 (((guix gexp)) ((guix sets)) ((guix utils)) (#) ?))
>>222:29 16 (map1 (((guix sets)) ((guix utils)) ((guix store)) (#) ?))
>>222:29 15 (map1 (((guix utils)) ((guix store)) ((guix config)) # ?))
>>222:29 14 (map1 (((guix store)) ((guix config)) ((guix #)) ((?)) ?))
>>222:29 13 (map1 (((guix config)) ((guix packages)) ((guix #)) # ?))
>>222:29 12 (map1 (((guix packages)) ((guix profiles)) ((guix #)) ?))
>>222:17 11 (map1 (((guix profiles)) ((guix derivations)) ((# #)) ?))
>>   2800:17 10 (resolve-interface (guix profiles) #:select _ #:hide _ # ?)
>> In ice-9/threads.scm:
>> 390:8  9 (_ _)
>> In ice-9/boot-9.scm:
>>   2726:13  8 (_)
> 
> Could you post the lines preceding this error message? I just experienced
> a similar case, and the real error happened before (a package needed to be
> compiled first and failed).
> 
> Could you please send the output of
>   guix --version
> and
>   guix describe
> ?
> 
> Thanks,
> 
> Andreas

bug#34526: Updating node.js

[Daniel Gerber]

2019-02-18, Jelle Licht: 

It seems that llhttp includes a build step for generating 
C-files using TypeScript, making it a non-starter for proper 
packaging in Guix. 

See https://github.com/nodejs/llhttp/issues/14 for more details, 
but sadly no solution. 


What about statically linking llhttp's C "sources" included in 
node?   Building v11.10.0 succeeds with this:


diff --git a/node.gypi b/node.gypi
index c07b5ea704..c08493efbe 100644
--- a/node.gypi
+++ b/node.gypi
@@ -174,6 +174,12 @@
   ],
 } ],
 
+[ 'node_shared_http_parser=="true"', {
+  'dependencies': [
+'deps/llhttp/llhttp.gyp:llhttp'
+  ],
+} ],
+
 [ 'node_shared_cares=="false"', {
   'dependencies': [ 'deps/cares/cares.gyp:cares' ],
 }],

bug#34574: Confusing manual entry for gexp->file

[pelzflorian (Florian Pelz)]

Hello,

The Guix manual contains the following description of gexp->file:

 -- Monadic Procedure: gexp->file NAME EXP [#:set-load-path? #t]
  [#:module-path %load-path]  [#:splice? #f]  [#:guile
 (default-guile)] Return a derivation that builds a file NAME
 containing EXP. When SPLICE? is true, EXP is considered to be a
 list of expressions that will be spliced in the resulting file.

 When SET-LOAD-PATH? is true, emit code in the resulting file to set
 ‘%load-path’ and ‘%load-compiled-path’ to honor EXP’s imported
 modules. Look up EXP’s modules in MODULE-PATH.

 The resulting file holds references to all the dependencies of EXP
 or a subset thereof.

I do not understand this last sentence.  How can it be a subset?  A
subset of what?  Can this be explained more clearly or removed?

Regards,
Florian

bug#34573: Backtrace of guix pull failed

[Ricardo Wurmus]

Hi Vincent,

> I wanted to install python, numpy and conda on plafrim as explained here : 
> https://www.plafrim.fr/en/guix/
> And guix pull failed :
[…]
> In ./guix/profiles.scm:
>   1773:23  2 (_)
> In ./guix/utils.scm:
>661:47  1 (xdg-directory _ "/.config" #:ensure? _)
> In unknown file:
>0 (getpw 10837)
>
> ERROR: In procedure getpw:
> In procedure getpw: entry not found

This looks like nscd is not running.

The manual says this:

2.6.2 Name Service Switch
-

When using Guix on a foreign distro, we _strongly recommend_ that the
system run the GNU C library’s “name service cache daemon”, ‘nscd’,
which should be listening on the ‘/var/run/nscd/socket’ socket.  Failing
to do that, applications installed with Guix may fail to look up host
names or user accounts, or may even crash.

Could you check that NSCD is in fact available and running?

-- 
Ricardo

bug#34573: Backtrace of guix pull failed

[Andreas Enge]

Bonjour Vincent,

On Tue, Feb 19, 2019 at 10:55:58AM +0100, Vincent Rouvreau wrote:
> And guix pull failed :
> 
> guix package -i python python-numpy python-conda
> eval `guix package --search-paths=prefix`

so the first two commands succeeded?

> guix pull
> Backtrace:
> In ice-9/boot-9.scm:
>   2887:24 19 (_)
>222:29 18 (map1 (((guix i18n)) ((guix gexp)) ((guix sets)) ((?)) ?))
>222:29 17 (map1 (((guix gexp)) ((guix sets)) ((guix utils)) (#) ?))
>222:29 16 (map1 (((guix sets)) ((guix utils)) ((guix store)) (#) ?))
>222:29 15 (map1 (((guix utils)) ((guix store)) ((guix config)) # ?))
>222:29 14 (map1 (((guix store)) ((guix config)) ((guix #)) ((?)) ?))
>222:29 13 (map1 (((guix config)) ((guix packages)) ((guix #)) # ?))
>222:29 12 (map1 (((guix packages)) ((guix profiles)) ((guix #)) ?))
>222:17 11 (map1 (((guix profiles)) ((guix derivations)) ((# #)) ?))
>   2800:17 10 (resolve-interface (guix profiles) #:select _ #:hide _ # ?)
> In ice-9/threads.scm:
> 390:8  9 (_ _)
> In ice-9/boot-9.scm:
>   2726:13  8 (_)

Could you post the lines preceding this error message? I just experienced
a similar case, and the real error happened before (a package needed to be
compiled first and failed).

Could you please send the output of
   guix --version
and
   guix describe
?

Thanks,

Andreas

bug#34531: Guix profile fails on Overdrive 1000

[Danny Milosavljevic]

Hi Andreas,

On Tue, 19 Feb 2019 16:35:53 +0100
Andreas Enge  wrote:

> I tried to simply drop python-wrapper from inputs. Actually it is not
> referenced by the final output, so it should be in native-inputs. And
> here is what happens:
> 
> -- Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
> CMake Error at tests/CMakeLists.txt:4 (MESSAGE):
>   Could not find a python interpeter, which is needed to build the tests.
>   Make sure python is available, or pass -DBUILD_CLAR=OFF to skip building
>   the tests

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index b8e967bf6..7452f17b8 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -545,7 +545,8 @@ everything from small to very large projects with speed and 
efficiency.")
 (build-system cmake-build-system)
 (outputs '("out" "debug"))
 (arguments
- `(#:configure-flags '("-DUSE_SHA1DC=ON") ; SHA-1 collision detection
+ `(#:configure-flags '("-DUSE_SHA1DC=ON" ; SHA-1 collision detection
+   "-DBUILD_CLAR=OFF")
#:phases
(modify-phases %standard-phases
  (add-after 'unpack 'fix-hardcoded-paths
@@ -558,11 +559,13 @@ everything from small to very large projects with speed 
and efficiency.")
  #t))
  ;; Run checks more verbosely.
  (replace 'check
-   (lambda _ (invoke "./libgit2_clar" "-v" "-Q"))
+   (const #t)
+   
 (inputs
  `(("libssh2" ,libssh2)
("http-parser" ,http-parser)
-   ("python" ,python-wrapper)))
+;   ("python" ,python-wrapper)
+))
 (native-inputs
  `(("pkg-config" ,pkg-config)))
 (propagated-inputs

> So we could create a separate package for internal guix use without running
> the tests, which would save us from compiling and especially testing python.

Please, let's just replace the test generator in this case.  It's ridiculous
to complicate Guix that much for a 250 line test generator, most of which is
templates.

If necessary, I can do it, although a person who knows Perl or Guile better
can probably do it much faster.

> Although this is not our usual style - but on the other hand, "guix pull"
> is more or less the first command that we recommend to our users, and
> it would be nice if it ran fast without requiring (many) additional packages.
> 
> Ironically, libgit2 advertises itself as needing "Zero Dependencies" on its
> web site...
> 
> What do you think?

Just replace the one script and do run the tests, without depending on Python.


pgpxuAW0IKAhM.pgp
Description: OpenPGP digital signature

bug#34531: Guix profile fails on Overdrive 1000

[Andreas Enge]

On Tue, Feb 19, 2019 at 02:23:23PM +0100, Ricardo Wurmus wrote:
> Guix pull needs “guile-git”, and “guile-git” needs “libgit2”, which
> needs “python-wrapper”.  To remove the need for Python in “guix pull” we
> would need to build libgit2 without Python.  I don’t know if anyone has
> investigated whether this can be done.

I tried to simply drop python-wrapper from inputs. Actually it is not
referenced by the final output, so it should be in native-inputs. And
here is what happens:

-- Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
CMake Error at tests/CMakeLists.txt:4 (MESSAGE):
  Could not find a python interpeter, which is needed to build the tests.
  Make sure python is available, or pass -DBUILD_CLAR=OFF to skip building
  the tests

So we could create a separate package for internal guix use without running
the tests, which would save us from compiling and especially testing python.

Although this is not our usual style - but on the other hand, "guix pull"
is more or less the first command that we recommend to our users, and
it would be nice if it ran fast without requiring (many) additional packages.

Ironically, libgit2 advertises itself as needing "Zero Dependencies" on its
web site...

What do you think?

Andreas

bug#34573: Backtrace of guix pull failed

[Vincent Rouvreau]

Hello,

I wanted to install python, numpy and conda on plafrim as explained here : 
https://www.plafrim.fr/en/guix/
And guix pull failed :

guix package -i python python-numpy python-conda

eval `guix package --search-paths=prefix`

guix pull

Backtrace:
In ice-9/boot-9.scm:
  2887:24 19 (_)
   222:29 18 (map1 (((guix i18n)) ((guix gexp)) ((guix sets)) ((?)) ?))
   222:29 17 (map1 (((guix gexp)) ((guix sets)) ((guix utils)) (#) ?))
   222:29 16 (map1 (((guix sets)) ((guix utils)) ((guix store)) (#) ?))
   222:29 15 (map1 (((guix utils)) ((guix store)) ((guix config)) # ?))
   222:29 14 (map1 (((guix store)) ((guix config)) ((guix #)) ((?)) ?))
   222:29 13 (map1 (((guix config)) ((guix packages)) ((guix #)) # ?))
   222:29 12 (map1 (((guix packages)) ((guix profiles)) ((guix #)) ?))
   222:17 11 (map1 (((guix profiles)) ((guix derivations)) ((# #)) ?))
  2800:17 10 (resolve-interface (guix profiles) #:select _ #:hide _ # ?)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  2726:13  8 (_)
In ice-9/threads.scm:
390:8  7 (_ _)
In ice-9/boot-9.scm:
  2994:20  6 (_)
   2312:4  5 (save-module-excursion #)
  3014:26  4 (_)
In unknown file:
   3 (primitive-load-path "guix/profiles" #)
In ./guix/profiles.scm:
  1773:23  2 (_)
In ./guix/utils.scm:
   661:47  1 (xdg-directory _ "/.config" #:ensure? _)
In unknown file:
   0 (getpw 10837)

ERROR: In procedure getpw:
In procedure getpw: entry not found
guix pull: error: You found a bug: the program 
'/gnu/store/i49yy9zlv7h1bsds96ld7fhgni9ycvr6-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"be92b4b000dbe84a525de7857296fede318048d9"; system: "x86_64-linux";
host version: "a9ba0a3154f3f20097000407a96a390ad3dee100"; pull-version: 1).
Please report it by email to .



I want to precise it is my first time with guix and I may misunderstood some 
points...

Regards,

Vincent Rouvreau - Service Expérimentation et Développement
INRIA Saclay
Tel: (+33).1.74.85.42.32

bug#34531: Guix profile fails on Overdrive 1000

[Danny Milosavljevic]

Hi Ricardo,
Hi Andreas,

On Tue, 19 Feb 2019 14:23:23 +0100
Ricardo Wurmus  wrote:

> Andreas Enge  writes:
> 
> > Before closing the bug, I would still like to ask whether there is a way
> > of getting around the need for python.  
> 
> Guix pull needs “guile-git”, and “guile-git” needs “libgit2”, which
> needs “python-wrapper”.  To remove the need for Python in “guix pull” we
> would need to build libgit2 without Python.  I don’t know if anyone has
> investigated whether this can be done.

I have read it now--in the interest of simplicity and bootstrappability.

Python is only required to generate some libgit2 tests.  It would be easy
to port the one Python program "generate.py" to some other language.

"generate.py" is from clar, which appears to be https://github.com/vmg/clar .

If someone were to replace it, that would be the correct place to contribute
it.

Python is listed as a regular input in libgit2.
I think it should be a native-input instead.

The dependency graph of libgit2 is very small after removing Python.
The languages it still depends on (possibly indirectly) are:

* Perl 5.28.0
* Guile 2.0.14
* bash 4.4.23

So writing the generate.py in one of those languages would not make the
dependency graph bigger than necessary.

generate.py uses regular expressions, simple file I/O, string templating
and that's pretty much it.

In any case, the first simplification would be just to move Python from
regular input to native-input.


pgpmjKwy4CUMR.pgp
Description: OpenPGP digital signature

bug#34565: ungoogled-chromium contains Widevine DRM

[Julien Lepiller]

Le 2019-02-19 14:42, Julien Lepiller a écrit :

Le 2019-02-19 14:28, Jason Self a écrit :

On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
Why do you think this is the case?

We know Chromium comes with it. Have you looked through ungoogled-
chromium to see where it's being deleted?


Our package definition has two widevine-related headers listed as
preserved third-party stuff... I'm not sure how widevine normally
gets into chromium, but if we don't have it, I guess we should
not need these headers? There might actually be an issue, but
I'm not sure how to check. Where is widevine in upstream (non
ungoogled) chromium? Is it downloaded at runtime?

IIUC, the rest of this widevine directory is removed before
building anything, so maybe there's nothing to worry about
after all?


So I've downloaded the source tarball with `guix build -S chromium`
and here's what I found in it:

$ find -name cdm
./media/cdm
./third_party/widevine/cdm
./chrome/android/java/src/org/chromium/chrome/browser/media/cdm
./chrome/browser/media/android/cdm
./content/renderer/media/cdm
./chromecast/media/cdm
./components/cdm

$ find -name widevine
./third_party/widevine

$ find -name '*widevine*'
./third_party/widevine
./third_party/widevine/cdm/android/widevine_cdm_version.h
./third_party/widevine/cdm/widevinecdmadapter.ver
./third_party/widevine/cdm/stub/widevine_cdm_version.h
./third_party/widevine/cdm/widevine.gni
./third_party/widevine/cdm/widevine_cdm_version.h
./third_party/widevine/cdm/widevine_cdm_common.h
./chrome/common/widevine_cdm_constants.h
./chrome/common/widevine_cdm_constants.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.h
./components/cdm/common/widevine_drm_delegate_android.cc
./components/cdm/common/widevine_drm_delegate_android.h
./components/cdm/renderer/widevine_key_system_properties.cc
./components/cdm/renderer/widevine_key_system_properties.h


This 
./chrome/browser/component_updater/widevine_cdm_component_installer.cc

looks particularly suspicious to me...

Now, it seems that widevine stuff only gets built when the 
ENABLE_WIDEVINE
option is set, and it doesn't seem to be the case in guix' package. 
Since

I don't understand how the browser gets built, so I'm not sure about the
default. In any case, it would be good to get rid of these files even
if they aren't built.

HTH!

bug#34565: ungoogled-chromium contains Widevine DRM

[Leo Famulari]

On Tue, Feb 19, 2019 at 05:28:26AM -0800, Jason Self wrote:
> We know Chromium comes with it. Have you looked through ungoogled-
> chromium to see where it's being deleted?

Please show us the paths in our package's source code. We need to remove
it if it is there.

I looked and cannot find it.

I looked at how some other distros do it.

They get the Widevine binaries by extracting them from a download of the
Google Chrome browser, which is not the browser that has been packaged
for Guix.


signature.asc
Description: PGP signature

bug#34565: ungoogled-chromium contains Widevine DRM

[Julien Lepiller]

Le 2019-02-19 14:28, Jason Self a écrit :

On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
Why do you think this is the case?

We know Chromium comes with it. Have you looked through ungoogled-
chromium to see where it's being deleted?


Our package definition has two widevine-related headers listed as
preserved third-party stuff... I'm not sure how widevine normally
gets into chromium, but if we don't have it, I guess we should
not need these headers? There might actually be an issue, but
I'm not sure how to check. Where is widevine in upstream (non
ungoogled) chromium? Is it downloaded at runtime?

IIUC, the rest of this widevine directory is removed before
building anything, so maybe there's nothing to worry about
after all?

bug#34565: ungoogled-chromium contains Widevine DRM

[Jason Self]

On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
Why do you think this is the case?

We know Chromium comes with it. Have you looked through ungoogled-
chromium to see where it's being deleted?

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

bug#34531: Guix profile fails on Overdrive 1000

[Ricardo Wurmus]

Andreas Enge  writes:

> Before closing the bug, I would still like to ask whether there is a way
> of getting around the need for python.

Guix pull needs “guile-git”, and “guile-git” needs “libgit2”, which
needs “python-wrapper”.  To remove the need for Python in “guix pull” we
would need to build libgit2 without Python.  I don’t know if anyone has
investigated whether this can be done.

> And why "guix pull -n" builds
> such a large number of packages, while one would expect it to just print
> a number of packages to be built.

This is likely due to grafts.  When you do “guix pull --no-grafts -n”
the behaviour is as expected.

--
Ricardo

bug#34570: Failure to build swig/graphviz

[Andreas Enge]

On Tue, Feb 19, 2019 at 10:16:32AM +0100, Danny Milosavljevic wrote:
> I think that the test suite contains multiple sets of tests and and earlier 
> set
> failed (the 514 perl5 tests apparently didn't fail; the warning shouldn't
> make tests fail anyway).  What's before what you posted in the log?

Lots of lines similar to these:
> > \@ build-log 23167 506
> > In file included from 
> > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/libc-header-start.h:33:0,
> >  from 
> > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/string.h:26,
> >  from multi_import_b_wrap.cxx:341:
> > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/features.h:381:4:
> >  warning: #warning _FORTIFY_SOURCE requires compiling with optimization 
> > (-O) [-Wcpp]
> >  #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)

In the meantime I got around the problem by copying the build from berlin,
so I also cannot reproduce the failed build. Apparently some machine did
correctly compute the derivation; if there is not an obvious error somewhere,
it might be easier to close the bug report as not reproducible or non-deter-
ministic.

Andreas

bug#34570: Failure to build swig/graphviz

[Danny Milosavljevic]

Hi Andreas,

I think that the test suite contains multiple sets of tests and and earlier set
failed (the 514 perl5 tests apparently didn't fail; the warning shouldn't
make tests fail anyway).  What's before what you posted in the log?

> I suppose the first one complaining that "make check" fails is the real one,
> and the error around computing a derivation just follows from this?

Yes.

> ...
> \@ build-log 23167 506
> In file included from 
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/libc-header-start.h:33:0,
>  from 
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/string.h:26,
>  from multi_import_b_wrap.cxx:341:
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/features.h:381:4:
>  warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
> [-Wcpp]
>  #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> ^
> |@ build-log 23167 23
> 514 perl5 tests passed
> @ build-log 23167 34
> 
> Test suite failed, dumping logs.
> @ build-log 23167 11
> Backtrace:
> @ build-log 23167 74
>4 (primitive-load "/gnu/store/bjd20p2a8a6hcqp5gip98xgwd8j?")
> @ build-log 23167 19
> In ice-9/eval.scm:
> @ build-log 23167 19
>191:35  3 (_ _)
> @ build-log 23167 20
> In srfi/srfi-1.scm:
> @ build-log 23167 77
>863:16  2 (every1 # ?)
> @ build-log 23167 94
> In 
> /gnu/store/p6nx31x59dzzqbqd572986f1jilg2n2f-module-import/guix/build/gnu-build-system.scm:
> @ build-log 23167 19
>799:28  1 (_ _)
> @ build-log 23167 70
> 369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)
> @ build-log 23167 1
> 
> @ build-log 23167 117
> /gnu/store/p6nx31x59dzzqbqd572986f1jilg2n2f-module-import/guix/build/gnu-build-system.scm:369:6:
>  In procedure check:
> @ build-log 23167 167
> Throw to key `srfi-34' with args `(# arguments: ("check" "-j" "3") exit-status: 2 term-signal: #f stop-signal: #f] 
> 49ffc0>)'.
> -builder for `/gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv - 
> 1 builder for `/gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv' 
> failed with exit code 1
> cannot build derivation 
> `/gnu/store/hmg3xwghi64jqqv4ya90bh8pny3d03zn-graphviz-2.40.1.drv': 1 
> dependencies couldn't be built
> Backtrace:
>   19 (primitive-load "/gnu/store/a84xx8gbasmxp3s0n1hi7w8dglk?")
> In ice-9/eval.scm:
> 155:9 18 (_ _)
> 159:9 17 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ./guix/store.scm:
>   1737:24 16 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
>1610:8 15 (_ _)
> In ./guix/gexp.scm:
> 703:2 14 (_ _)
> In ./guix/monads.scm:
> 482:9 13 (_ _)
> In ./guix/gexp.scm:
>573:13 12 (_ _)
> In ./guix/store.scm:
>1610:8 11 (_ _)
> In ./guix/gexp.scm:
> 703:2 10 (_ _)
> In ./guix/monads.scm:
> 482:9  9 (_ _)
> In ./guix/gexp.scm:
>573:13  8 (_ _)
> In ./guix/store.scm:
>1610:8  7 (_ _)
>1610:8  6 (_ _)
>   1633:38  5 (_ #)
> In ./guix/packages.scm:
>904:16  4 (cache! # # ?)
> In ./guix/grafts.scm:
> 314:4  3 (graft-derivation # # ?)
> 192:4  2 (references-oracle # #)
>201:20  1 (_ _ _)
> In ./guix/store.scm:
>   1151:15  0 (_ # _ _)
> 
> ./guix/store.scm:1151:15: Throw to key `srfi-34' with args `(# &store-protocol-error [message: "build of 
> `/gnu/store/hmg3xwghi64jqqv4ya90bh8pny3d03zn-graphviz-2.40.1.drv' failed" 
> status: 100] 41c5f030>)'.
> guix pull: error: You found a bug: the program 
> '/gnu/store/a84xx8gbasmxp3s0n1hi7w8dglky5pvy-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "33756922bbe1d54c34ecaa77509e34746b779ac9"; system: "aarch64-linux";
> host version: "0.16.0"; pull-version: 1).
> Please report it by email to .


pgpPb5Gu7iulr.pgp
Description: OpenPGP digital signature

bug#34570: Failure to build swig/graphviz

[Andreas Enge]

Hello,

the following happens when using "guix pull -n" on my Overdrive with
Guix 0.16.0. So maybe it has been solved in the meantime.

When building swig-3.0.12 (for whatever reason...), the build fails with
the following error during the check phase. Actually there are two errors;
I suppose the first one complaining that "make check" fails is the real one,
and the error around computing a derivation just follows from this?

...
\@ build-log 23167 506
In file included from 
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/libc-header-start.h:33:0,
 from 
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/string.h:26,
 from multi_import_b_wrap.cxx:341:
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/features.h:381:4:
 warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
[-Wcpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
|@ build-log 23167 23
514 perl5 tests passed
@ build-log 23167 34

Test suite failed, dumping logs.
@ build-log 23167 11
Backtrace:
@ build-log 23167 74
   4 (primitive-load "/gnu/store/bjd20p2a8a6hcqp5gip98xgwd8j?")
@ build-log 23167 19
In ice-9/eval.scm:
@ build-log 23167 19
   191:35  3 (_ _)
@ build-log 23167 20
In srfi/srfi-1.scm:
@ build-log 23167 77
   863:16  2 (every1 # ?)
@ build-log 23167 94
In 
/gnu/store/p6nx31x59dzzqbqd572986f1jilg2n2f-module-import/guix/build/gnu-build-system.scm:
@ build-log 23167 19
   799:28  1 (_ _)
@ build-log 23167 70
369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)
@ build-log 23167 1

@ build-log 23167 117
/gnu/store/p6nx31x59dzzqbqd572986f1jilg2n2f-module-import/guix/build/gnu-build-system.scm:369:6:
 In procedure check:
@ build-log 23167 167
Throw to key `srfi-34' with args `(#)'.
-builder for `/gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv' 
failed with exit code 1
@ build-failed /gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv - 1 
builder for `/gnu/store/kpg54qz7nlw5ygx5lmyd4d05cx423ysq-swig-3.0.12.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/hmg3xwghi64jqqv4ya90bh8pny3d03zn-graphviz-2.40.1.drv': 1 
dependencies couldn't be built
Backtrace:
  19 (primitive-load "/gnu/store/a84xx8gbasmxp3s0n1hi7w8dglk?")
In ice-9/eval.scm:
155:9 18 (_ _)
159:9 17 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ./guix/store.scm:
  1737:24 16 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
   1610:8 15 (_ _)
In ./guix/gexp.scm:
703:2 14 (_ _)
In ./guix/monads.scm:
482:9 13 (_ _)
In ./guix/gexp.scm:
   573:13 12 (_ _)
In ./guix/store.scm:
   1610:8 11 (_ _)
In ./guix/gexp.scm:
703:2 10 (_ _)
In ./guix/monads.scm:
482:9  9 (_ _)
In ./guix/gexp.scm:
   573:13  8 (_ _)
In ./guix/store.scm:
   1610:8  7 (_ _)
   1610:8  6 (_ _)
  1633:38  5 (_ #)
In ./guix/packages.scm:
   904:16  4 (cache! # # ?)
In ./guix/grafts.scm:
314:4  3 (graft-derivation # # ?)
192:4  2 (references-oracle # #)
   201:20  1 (_ _ _)
In ./guix/store.scm:
  1151:15  0 (_ # _ _)

./guix/store.scm:1151:15: Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/a84xx8gbasmxp3s0n1hi7w8dglky5pvy-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"33756922bbe1d54c34ecaa77509e34746b779ac9"; system: "aarch64-linux";
host version: "0.16.0"; pull-version: 1).
Please report it by email to .


Andreas

bug#34531: Guix profile fails on Overdrive 1000

[Andreas Enge]

Hello Marius,

thanks a lot for your quick and helpful reply!

On Mon, Feb 18, 2019 at 09:49:10PM +0100, Marius Bakke wrote:
> The Python contained within this Guix snapshot has a known bug that
> makes it leak memory on newer kernels.  The Guix commit that works
> around it is 589aca1c183ef1dfdef54d40fdd6a258bbcd39d0.

okay, so the main problem is fixed then.

> One thing you could try is bootstrap a Guix checkout through the usual
> mechanisms (./bootstrap; ./configure; etc), using packages from the host
> system if necessary.

The host system is Guix, so this is complicated... But I realise that
there is also a guix-0.16.0 lying around, and with this I get beyond the
python point.

Before closing the bug, I would still like to ask whether there is a way
of getting around the need for python. And why "guix pull -n" builds
such a large number of packages, while one would expect it to just print
a number of packages to be built. But maybe this is also solved in a
later version already.

Andreas

bug#34526: Updating node.js

[Björn Höfling]

On Mon, 18 Feb 2019 21:50:41 +0100
Jelle Licht  wrote:

> See https://github.com/nodejs/llhttp/issues/14 for more details, but
> sadly no solution.

Thanks for looking into these things, really sounds sad. It would be
nice if the JavaScript/node.js people would care more about
bootstrapping from source.

Björn


pgpcC5sLcQm3p.pgp
Description: OpenPGP digital signature