* [PATCH] gnu: kde: Add kdelibs.
@ 2014-11-04 21:37 Andreas Enge
2014-11-05 13:18 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2014-11-04 21:37 UTC (permalink / raw)
To: guix-devel
Hello,
thanks to Ludovic's help with debugging Qt and dbus, I finally have a working
recipe for kdelibs that allows me to compile the KDE "Hello, world"
tutorial at
https://techbase.kde.org/Development/Tutorials/First_program
It looks like all KDE programs require at least kdelibs, qt, phonon and
automoc4 to compile; but as these are not needed for running the program,
it seems inappropriate to make them propagated inputs.
The configure flags
"-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
"-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
look like bugs in kdelibs to me; but I wonder if reporting them makes sense.
I sense the answer that we should simply keep Qt in a standard location...
Quite a few of the tests fail, and already the first one (which is a simple
compression and archiver test) hangs at 100% CPU before being killed after
1500s. I can try to run all the tests and see whether there is some useful
output. Otherwise hunting down the test failures looks hopeless.
Comments are welcome.
Andreas
* gnu/packages/kde.scm (kdelibs): New variable.
---
gnu/packages/kde.scm | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 98 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 8c2673e..602f5fb 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -17,14 +17,22 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu packages kde)
- #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
+ #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system cmake)
+ #:use-module (gnu packages bison)
#:use-module (gnu packages compression)
+ #:use-module (gnu packages docbook)
#:use-module (gnu packages doxygen)
+ #:use-module (gnu packages flex)
#:use-module (gnu packages geeqie)
#:use-module (gnu packages glib)
+ #:use-module (gnu packages gnome)
+ #:use-module (gnu packages image)
+ #:use-module (gnu packages linux)
+ #:use-module (gnu packages openssl)
+ #:use-module (gnu packages pcre)
#:use-module (gnu packages perl)
#:use-module (gnu packages pkg-config)
#:use-module (gnu packages pulseaudio)
@@ -225,3 +233,92 @@ calculation of sha1 for every file crawled
(synopsis "oxygen icon theme for the KDE desktop")
(description "KDE desktop environment")
(license lgpl3+)))
+
+(define-public kdelibs
+ (package
+ (name "kdelibs")
+ (version "4.14.2")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "http://download.kde.org/stable/" version
+ "/src/" name "-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+ "0nw9zl54wdzw26l9l1a520ykjqgrzc1dx9aa6y015k0ry1vmlx1r"))))
+ (build-system cmake-build-system)
+ (native-inputs
+ `(("pkg-config" ,pkg-config)))
+ (inputs
+ `(("attica" ,attica)
+ ("automoc4" ,automoc4)
+ ("bison" ,bison)
+ ("docbook-xml" ,docbook-xml)
+ ("docbook-xsl" ,docbook-xsl)
+ ("flex" ,flex)
+ ("giflib" ,giflib)
+ ("libdbusmenu-qt" ,libdbusmenu-qt)
+ ("libice" ,libice)
+ ("libjpeg" ,libjpeg-8)
+ ("libpng" ,libpng)
+ ("libsm" ,libsm)
+ ("libx11" ,libx11)
+ ("libxau" ,libxau)
+ ("libxcomposite" ,libxcomposite)
+ ("libxcursor" ,libxcursor)
+ ("libxdamage" ,libxdamage)
+ ("libxdmcp" ,libxdmcp)
+ ("libxext" ,libxext)
+ ("libxfixes" ,libxfixes)
+ ("libxft" ,libxft)
+ ("libxi" ,libxi)
+ ("libxinerama" ,libxinerama)
+ ("libxkbfile" ,libxkbfile)
+ ("libxml2" ,libxml2)
+ ("libxpm" ,libxpm)
+ ("libxrandr" ,libxrandr)
+ ("libxrender" ,libxrender)
+ ("libxscrnsaver" ,libxscrnsaver)
+ ("libxslt" ,libxslt)
+ ("libxt" ,libxt)
+ ("libxtst" ,libxtst)
+ ("libxv" ,libxv)
+ ("libxxf86vm" ,libxxf86vm)
+ ("openssl" ,openssl)
+ ("pcre" ,pcre)
+ ("perl" ,perl)
+ ("phonon" ,phonon)
+ ("python" ,python-wrapper)
+ ("qt" ,qt-4)
+ ("shared-mime-info" ,shared-mime-info)
+ ("soprano" ,soprano)
+ ("strigi" ,strigi)
+ ("eudev" ,eudev)
+ ("zlib" ,zlib)))
+ (arguments
+ `(#:tests? #f ; currently failing
+ #:configure-flags
+ (list "-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
+ "-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
+ (string-append "-DDOCBOOKXML_CURRENTDTD_DIR="
+ (assoc-ref %build-inputs "docbook-xml")
+ "/xml/dtd/docbook/")
+ (let* ((docbook-xsl (assoc-ref %build-inputs "docbook-xsl"))
+ (docbook-xsl-version ,(package-version docbook-xsl)))
+ (string-append "-DDOCBOOKXSL_DIR="
+ docbook-xsl
+ "/xml/xsl/docbook-xsl-"
+ docbook-xsl-version
+ "/")))
+ #:phases
+ (alist-cons-before
+ 'configure 'patch-bin-sh
+ (lambda _
+ (substitute* "cmake/modules/kde4_exec_via_sh.cmake"
+ (("/bin/sh") (which "sh"))))
+ %standard-phases)))
+ (home-page "http://www.kde.org/")
+ (synopsis "Main libraries for the KDE desktop")
+ (description "KDE desktop environment")
+ (license lgpl2.0))) ; the libraries; examples are under GPL
--
2.1.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-04 21:37 [PATCH] gnu: kde: Add kdelibs Andreas Enge
@ 2014-11-05 13:18 ` Ludovic Courtès
2014-11-05 13:49 ` 宋文武
2014-11-05 19:22 ` Andreas Enge
0 siblings, 2 replies; 22+ messages in thread
From: Ludovic Courtès @ 2014-11-05 13:18 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
Andreas Enge <andreas@enge.fr> skribis:
> thanks to Ludovic's help with debugging Qt and dbus, I finally have a working
> recipe for kdelibs that allows me to compile the KDE "Hello, world"
> tutorial at
> https://techbase.kde.org/Development/Tutorials/First_program
This is good news. :-)
> It looks like all KDE programs require at least kdelibs, qt, phonon and
> automoc4 to compile; but as these are not needed for running the program,
> it seems inappropriate to make them propagated inputs.
Right, this is not a reason to propagate them.
Perhaps eventually you’ll find it convenient to have a specific build
system with those listed as implicit inputs, though.
> The configure flags
> "-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
> "-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
> look like bugs in kdelibs to me; but I wonder if reporting them makes sense.
What does it fix? Would be nice to leave a comment above it.
> Quite a few of the tests fail, and already the first one (which is a simple
> compression and archiver test) hangs at 100% CPU before being killed after
> 1500s. I can try to run all the tests and see whether there is some useful
> output. Otherwise hunting down the test failures looks hopeless.
It would be nice to investigate a bit, but IMO it can be done
incrementally (commit with #:tests? #f and a FIXME, and then see what
can be done.)
> - #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
> + #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
At this point, it’s probably better to just use #:prefix. :-)
> + (inputs
> + `(("attica" ,attica)
> + ("automoc4" ,automoc4)
> + ("bison" ,bison)
> + ("docbook-xml" ,docbook-xml)
> + ("docbook-xsl" ,docbook-xsl)
> + ("flex" ,flex)
I suspect automoc4, bison, flex, and docbook-* should be in
‘native-inputs’.
> + (synopsis "Main libraries for the KDE desktop")
> + (description "KDE desktop environment")
Make sure to improve it before committing.
> + (license lgpl2.0))) ; the libraries; examples are under GPL
It’s version 2.0 only?
Thanks!
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 13:18 ` Ludovic Courtès
@ 2014-11-05 13:49 ` 宋文武
2014-11-05 19:22 ` Andreas Enge
1 sibling, 0 replies; 22+ messages in thread
From: 宋文武 @ 2014-11-05 13:49 UTC (permalink / raw)
To: Ludovic Courtès, Andreas Enge; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> Andreas Enge <andreas@enge.fr> skribis:
>
>> thanks to Ludovic's help with debugging Qt and dbus, I finally have a working
>> recipe for kdelibs that allows me to compile the KDE "Hello, world"
>> tutorial at
>> https://techbase.kde.org/Development/Tutorials/First_program
>
> This is good news. :-)
>
>> It looks like all KDE programs require at least kdelibs, qt, phonon and
>> automoc4 to compile; but as these are not needed for running the program,
>> it seems inappropriate to make them propagated inputs.
>
> Right, this is not a reason to propagate them.
>
> Perhaps eventually you’ll find it convenient to have a specific build
> system with those listed as implicit inputs, though.
>
>> The configure flags
>> "-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
>> "-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
>> look like bugs in kdelibs to me; but I wonder if reporting them makes sense.
>
> What does it fix? Would be nice to leave a comment above it.
Hi, when packaging libqtxdg(using cmake and qt5), I find out that I have
to set CMAKE_SHARED_LINKER_FLAGS too to get qt5 into output's rpath.
Then I do a similar build for libqtxdg in nix for comparision, which do not
need to set this variable.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 13:18 ` Ludovic Courtès
2014-11-05 13:49 ` 宋文武
@ 2014-11-05 19:22 ` Andreas Enge
1 sibling, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2014-11-05 19:22 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Thanks for your comments!
On Wed, Nov 05, 2014 at 02:18:24PM +0100, Ludovic Courtès wrote:
> Perhaps eventually you’ll find it convenient to have a specific build
> system with those listed as implicit inputs, though.
This sounds like a good idea. I considered a "define" with a list of the
basic packages that every KDE package needs as input, but inheriting a
new build system from the cmake build system sounds like a plan.
> > The configure flags
> > "-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
> > "-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
> > look like bugs in kdelibs to me; but I wonder if reporting them makes sense.
> What does it fix? Would be nice to leave a comment above it.
As usual, the libraries and binaries are not explicitly linked with the
libraries they depend on. So in a context where the input libraries are not
in /usr/lib, executing binaries fails.
In my private branch I also tried to compile a few KDE packages. The same
problem everywhere: Unless I set an LD_LIBRARY_PATH, they do not find the
necessary KDE and Qt libraries. I think we need a more general solution,
as also witnessed by this:
On Wed, Nov 05, 2014 at 09:49:39PM +0800, 宋文武 wrote:
> Hi, when packaging libqtxdg(using cmake and qt5), I find out that I have
> to set CMAKE_SHARED_LINKER_FLAGS too to get qt5 into output's rpath.
> Then I do a similar build for libqtxdg in nix for comparision, which do not
> need to set this variable.
Maybe someone here can come up with a good solution? In any case, I will
try to discuss with Ludovic and my personal cmake guru.
> > Quite a few of the tests fail, and already the first one (which is a simple
> > compression and archiver test) hangs at 100% CPU before being killed after
> > 1500s. I can try to run all the tests and see whether there is some useful
> > output. Otherwise hunting down the test failures looks hopeless.
> It would be nice to investigate a bit, but IMO it can be done
> incrementally (commit with #:tests? #f and a FIXME, and then see what
> can be done.)
Agreed; the package is not finished yet, as one of the last steps I should
at least look at the test results (unless many of the about 150 time out
after 1500s...).
> > - #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
> > + #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
> At this point, it’s probably better to just use #:prefix. :-)
Okay!
> I suspect automoc4, bison, flex, and docbook-* should be in
> ‘native-inputs’.
Probably so.
> > + (synopsis "Main libraries for the KDE desktop")
> > + (description "KDE desktop environment")
> Make sure to improve it before committing.
Okay.
> > + (license lgpl2.0))) ; the libraries; examples are under GPL
> It’s version 2.0 only?
A bunch of files, yes. I just realise that the truth is really messy:
http://metadata.ftp-master.debian.org/changelogs/main/k/kdelibs/oldstable_copyright
There is also LGPL2+, "deal in the software without restriction", etc.
and so on.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
@ 2014-11-05 19:50 Federico Beffa
2014-11-05 20:15 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Federico Beffa @ 2014-11-05 19:50 UTC (permalink / raw)
To: andreas, Guix-devel, Ludovic Courtès
Andreas Enge <andreas@enge.fr> writes:
> As usual, the libraries and binaries are not explicitly linked with the
> libraries they depend on. So in a context where the input libraries are not
> in /usr/lib, executing binaries fails.
>
> In my private branch I also tried to compile a few KDE packages. The same
> problem everywhere: Unless I set an LD_LIBRARY_PATH, they do not find the
> necessary KDE and Qt libraries. I think we need a more general solution,
> as also witnessed by this:
I'm working on dconf and I had the same problem: the produced binaries
like dconf-edit, but even shared libraries produced by the build would
not find their own companions. Initially I did set LD_LIBRARY_PATH to
resolve the problem. However, after setting
#:configure-flags
;; Set the correct RUNPATH in binaries.
(list (string-append "LDFLAGS=-Wl,-rpath="
(assoc-ref %outputs "out") "/lib"))
at build time, everything was working fine without having to set
LD_LIBRARY_PATH. That is not in dconf and not in packages build against
dconf's libraries.
Regards,
Fede
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 19:50 Federico Beffa
@ 2014-11-05 20:15 ` Ludovic Courtès
2014-11-05 20:28 ` Eric Bavier
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2014-11-05 20:15 UTC (permalink / raw)
To: Federico Beffa; +Cc: Guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> I'm working on dconf and I had the same problem: the produced binaries
> like dconf-edit, but even shared libraries produced by the build would
> not find their own companions.
What build system does dconf use?
Usually there’s no problem for packages that use Libtool (it sets the
RUNPATH automatically), but there’s almost systematically a problem when
CMake is used (we may not be passing the right options or something, as
Andreas notes.)
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 20:15 ` Ludovic Courtès
@ 2014-11-05 20:28 ` Eric Bavier
2014-11-05 21:00 ` Federico Beffa
0 siblings, 1 reply; 22+ messages in thread
From: Eric Bavier @ 2014-11-05 20:28 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
Ludovic Courtès writes:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> I'm working on dconf and I had the same problem: the produced binaries
>> like dconf-edit, but even shared libraries produced by the build would
>> not find their own companions.
>
> What build system does dconf use?
>
> Usually there’s no problem for packages that use Libtool (it sets the
> RUNPATH automatically), but there’s almost systematically a problem when
> CMake is used (we may not be passing the right options or something, as
> Andreas notes.)
Our cmake-build-system sets CMAKE_INSTALL_RPATH_USE_LINK_PATH=True,
which will add the directory of a library given during link time to the
executable or library's rpath. As was noted before, this is not helpful
if the package does not put those libraries in the link line.
It also sets CMAKE_INSTALL_RPATH to the "lib" directory of the package
output. I'd imagine this would help with libraries finding libraries
from the same package, but perhaps not.
--
Eric Bavier
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 20:28 ` Eric Bavier
@ 2014-11-05 21:00 ` Federico Beffa
2014-11-05 21:18 ` Andreas Enge
0 siblings, 1 reply; 22+ messages in thread
From: Federico Beffa @ 2014-11-05 21:00 UTC (permalink / raw)
To: Eric Bavier; +Cc: Guix-devel
On Wed, Nov 5, 2014 at 9:28 PM, Eric Bavier <ericbavier@gmail.com> wrote:
>
> Ludovic Courtès writes:
>
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>> What build system does dconf use?
I'm using glib-or-gtk-build-system (which I'm refining). So, it is
mostly the gnu-build-system. But, in the end of the day, the option is
just a parameter for the linker and I thought it may help... but maybe
not.
Regards,
Fede
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 21:00 ` Federico Beffa
@ 2014-11-05 21:18 ` Andreas Enge
2014-11-05 23:20 ` Andreas Enge
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2014-11-05 21:18 UTC (permalink / raw)
To: Federico Beffa; +Cc: Guix-devel
On Wed, Nov 05, 2014 at 10:00:12PM +0100, Federico Beffa wrote:
> I'm using glib-or-gtk-build-system (which I'm refining). So, it is
> mostly the gnu-build-system. But, in the end of the day, the option is
> just a parameter for the linker and I thought it may help... but maybe
> not.
It definitely sounds like a good idea. We could add the rpath linker flags
for Qt and for KDE via -DCMAKE_SHARED_LINKER_FLAGS and
-DCMAKE_EXE_LINKER_FLAGS to the kde build system. I would like to give
it a try.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 21:18 ` Andreas Enge
@ 2014-11-05 23:20 ` Andreas Enge
2014-11-06 11:46 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2014-11-05 23:20 UTC (permalink / raw)
To: Federico Beffa; +Cc: Guix-devel
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
On Wed, Nov 05, 2014 at 10:18:18PM +0100, Andreas Enge wrote:
> It definitely sounds like a good idea. We could add the rpath linker flags
> for Qt and for KDE via -DCMAKE_SHARED_LINKER_FLAGS and
> -DCMAKE_EXE_LINKER_FLAGS to the kde build system. I would like to give
> it a try.
It works! I am attaching the updated kdelibs patch (still not finished,
just for your information; but I took Ludovic's suggestions into account).
So for the kde build system, we could add such lines to code the Qt and KDE
libraries into the rpath. Different submodules (at least kdegames)
also come with their own additional libraries. Anyway, I had the intention
of creating separate guile modules for them to keep a manageable number of
packages per module. So one could imagine a KDE build system, and a local
extended variant in each module inheriting from it.
So is this a solution we should implement, or does anyone have a better idea
or an argument why this would be bad?
Andreas
[-- Attachment #2: 0001-gnu-kde-Add-kdelibs.patch --]
[-- Type: text/plain, Size: 7256 bytes --]
From 4c82ecb734da93dbe8d41a0466b1cd20ab52981f Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Tue, 4 Nov 2014 21:44:16 +0100
Subject: [PATCH] gnu: kde: Add kdelibs.
* gnu/packages/kde.scm (kdelibs): New variable.
---
gnu/packages/kde.scm | 122 +++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 114 insertions(+), 8 deletions(-)
diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index e97ac27..27838f2 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -17,14 +17,23 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu packages kde)
- #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
+ #:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system cmake)
+ #:use-module (gnu packages avahi)
+ #:use-module (gnu packages bison)
#:use-module (gnu packages compression)
+ #:use-module (gnu packages docbook)
#:use-module (gnu packages doxygen)
+ #:use-module (gnu packages flex)
#:use-module (gnu packages geeqie)
#:use-module (gnu packages glib)
+ #:use-module (gnu packages gnome)
+ #:use-module (gnu packages image)
+ #:use-module (gnu packages linux)
+ #:use-module (gnu packages openssl)
+ #:use-module (gnu packages pcre)
#:use-module (gnu packages perl)
#:use-module (gnu packages pkg-config)
#:use-module (gnu packages pulseaudio)
@@ -55,7 +64,7 @@
(home-page "http://techbase.kde.org/Development/Tools/Automoc4")
(synopsis "Build tool for KDE")
(description "AutoMoc4 automatically generates moc-files for KDE.")
- (license bsd-2)))
+ (license license:bsd-2)))
(define-public phonon
(package
@@ -85,7 +94,7 @@
(home-page "http://phonon.kde.org/")
(synopsis "Qt 4 multimedia API")
(description "KDE desktop environment")
- (license lgpl2.1+)))
+ (license license:lgpl2.1+)))
(define-public qjson
(package
@@ -108,7 +117,7 @@
(description "QJson is a Qt-based library that maps JSON data to QVariant
objects and vice versa. JSON arrays are mapped to QVariantList instances,
while JSON objects are mapped to QVariantMap.")
- (license lgpl2.1+)))
+ (license license:lgpl2.1+)))
(define-public libdbusmenu-qt
(package
@@ -136,7 +145,7 @@ while JSON objects are mapped to QVariantMap.")
(description "The library provides a Qt implementation of the DBusMenu
protocol. The DBusMenu protocol makes it possible for applications to export
and import their menus over DBus.")
- (license lgpl2.0+)))
+ (license license:lgpl2.0+)))
(define-public attica
(package
@@ -160,7 +169,7 @@ Collaboration Services API version 1.6. It grants easy access to the
services such as querying information about persons and contents. The
library is used in KNewStuff3 as content provider. In order to integrate
with KDE's Plasma Desktop, a platform plugin exists in kdebase.")
- (license lgpl2.1+)))
+ (license license:lgpl2.1+)))
(define-public strigi
(package
@@ -204,7 +213,7 @@ currently a simple socket;
simple interface for implementing plugins for extracting information;
calculation of sha1 for every file crawled
(allows fast finding of duplicates).")
- (license lgpl2.0+)))
+ (license license:lgpl2.0+)))
(define-public oxygen-icons
(package
@@ -224,4 +233,101 @@ calculation of sha1 for every file crawled
(home-page "http://www.kde.org/")
(synopsis "oxygen icon theme for the KDE desktop")
(description "KDE desktop environment")
- (license lgpl3+)))
+ (license license:lgpl3+)))
+
+(define-public kdelibs
+ (package
+ (name "kdelibs")
+ (version "4.14.2")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "http://download.kde.org/stable/" version
+ "/src/" name "-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+ "0nw9zl54wdzw26l9l1a520ykjqgrzc1dx9aa6y015k0ry1vmlx1r"))))
+ (build-system cmake-build-system)
+ (native-inputs
+ `(("automoc4" ,automoc4)
+ ("bison" ,bison)
+ ("docbook-xml" ,docbook-xml)
+ ("docbook-xsl" ,docbook-xsl)
+ ("flex" ,flex)
+ ("pkg-config" ,pkg-config)))
+ (inputs
+ `(("attica" ,attica)
+ ("avahi" ,avahi)
+ ("giflib" ,giflib)
+ ("libdbusmenu-qt" ,libdbusmenu-qt)
+ ("libice" ,libice)
+ ("libjpeg" ,libjpeg-8)
+ ("libpng" ,libpng)
+ ("libsm" ,libsm)
+ ("libx11" ,libx11)
+ ("libxau" ,libxau)
+ ("libxcomposite" ,libxcomposite)
+ ("libxcursor" ,libxcursor)
+ ("libxdamage" ,libxdamage)
+ ("libxdmcp" ,libxdmcp)
+ ("libxext" ,libxext)
+ ("libxfixes" ,libxfixes)
+ ("libxft" ,libxft)
+ ("libxi" ,libxi)
+ ("libxinerama" ,libxinerama)
+ ("libxkbfile" ,libxkbfile)
+ ("libxml2" ,libxml2)
+ ("libxpm" ,libxpm)
+ ("libxrandr" ,libxrandr)
+ ("libxrender" ,libxrender)
+ ("libxscrnsaver" ,libxscrnsaver)
+ ("libxslt" ,libxslt)
+ ("libxt" ,libxt)
+ ("libxtst" ,libxtst)
+ ("libxv" ,libxv)
+ ("libxxf86vm" ,libxxf86vm)
+ ("openssl" ,openssl)
+ ("pcre" ,pcre)
+ ("perl" ,perl)
+ ("phonon" ,phonon)
+ ("python" ,python-wrapper)
+ ("qt" ,qt-4)
+ ("shared-mime-info" ,shared-mime-info)
+ ("soprano" ,soprano)
+ ("strigi" ,strigi)
+ ("eudev" ,eudev)
+ ("zlib" ,zlib)))
+ (arguments
+ `(#:tests? #f ; FIXME: some tests currently time out or fail
+ #:configure-flags
+ (let*
+ ((docbook-xsl (assoc-ref %build-inputs "docbook-xsl"))
+ (docbook-xsl-version ,(package-version docbook-xsl))
+ (qt (assoc-ref %build-inputs "qt"))
+ (qt-lib (string-append qt "/lib")))
+ (list
+ (string-append "-DCMAKE_SHARED_LINKER_FLAGS=-Wl,-rpath=" qt-lib)
+ (string-append "-DCMAKE_EXE_LINKER_FLAGS=-Wl,-rpath=" qt-lib)
+ (string-append "-DDOCBOOKXML_CURRENTDTD_DIR="
+ (assoc-ref %build-inputs "docbook-xml")
+ "/xml/dtd/docbook/")
+ (string-append "-DDOCBOOKXSL_DIR=" docbook-xsl
+ "/xml/xsl/docbook-xsl-" docbook-xsl-version
+ "/")))
+ #:phases
+ (alist-cons-before
+ 'configure 'patch-bin-sh
+ (lambda _
+ (substitute* "cmake/modules/kde4_exec_via_sh.cmake"
+ (("/bin/sh") (which "sh"))))
+ %standard-phases)))
+ (home-page "http://www.kde.org/")
+ (synopsis "KDE libraries")
+ (description "This package includes libraries that are central to the
+development and execution of a KDE program, as well as internationalization
+files for these libraries, HTML documentation, theme modules, and
+regression tests.")
+ ;; The different files are under various licenses; libraries under
+ ;; lgpl2.0 or lgpl2.0+, other programs under gpl.
+ ;; For details, see the file README in the source.
+ (license license:lgpl2.0)))
--
2.1.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-05 23:20 ` Andreas Enge
@ 2014-11-06 11:46 ` Ludovic Courtès
2014-11-06 22:37 ` Andreas Enge
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2014-11-06 11:46 UTC (permalink / raw)
To: Andreas Enge; +Cc: Guix-devel, Federico Beffa
Andreas Enge <andreas@enge.fr> skribis:
> On Wed, Nov 05, 2014 at 10:18:18PM +0100, Andreas Enge wrote:
>> It definitely sounds like a good idea. We could add the rpath linker flags
>> for Qt and for KDE via -DCMAKE_SHARED_LINKER_FLAGS and
>> -DCMAKE_EXE_LINKER_FLAGS to the kde build system. I would like to give
>> it a try.
>
> It works! I am attaching the updated kdelibs patch (still not finished,
> just for your information; but I took Ludovic's suggestions into account).
Cool! LGTM.
> So for the kde build system, we could add such lines to code the Qt and KDE
> libraries into the rpath. Different submodules (at least kdegames)
> also come with their own additional libraries. Anyway, I had the intention
> of creating separate guile modules for them to keep a manageable number of
> packages per module. So one could imagine a KDE build system, and a local
> extended variant in each module inheriting from it.
>
> So is this a solution we should implement, or does anyone have a better idea
> or an argument why this would be bad?
Apologies if this was already mentioned, but why don’t
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE and
-DCMAKE_INSTALL_RPATH=$out/lib (in cmake-build-system.scm) lead to
binaries with a RUNPATH? As Eric said, this should produce binaries
with an appropriate RUNPATH, no? Or does it only take care of setting
the RUNPATH to $out/lib?
To me, passing -Wl,-rpath would be a workaround for a package-specific
defect. The ideal solution would be to have cmake-build-system DTRT.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 11:46 ` Ludovic Courtès
@ 2014-11-06 22:37 ` Andreas Enge
2014-11-06 22:54 ` Andreas Enge
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Andreas Enge @ 2014-11-06 22:37 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
On Thu, Nov 06, 2014 at 12:46:21PM +0100, Ludovic Courtès wrote:
> Apologies if this was already mentioned, but why don’t
> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE and
> -DCMAKE_INSTALL_RPATH=$out/lib (in cmake-build-system.scm) lead to
> binaries with a RUNPATH? As Eric said, this should produce binaries
> with an appropriate RUNPATH, no? Or does it only take care of setting
> the RUNPATH to $out/lib?
From what I understood, the first variable should have solved the problem.
I set -DCMAKE_VERBOSE_MAKEFILE=ON and compiled ktouch. When running it, it
stops with
ktouch: error while loading shared libraries: libkdeclarative.so.5: cannot open shared object file: No such file or directory
And indeed:
$ ldd ~/.guix-profile/bin/ktouch
linux-vdso.so.1 (0x00007fff961ff000)
libkdeclarative.so.5 => not found
...
(lots of other "not found").
$ objdump -x ~/.guix-profile/bin/ktouch
...
Dynamic Section:
NEEDED libkdeclarative.so.5
NEEDED libplasma.so.3
NEEDED libkio.so.5
NEEDED libkcmutils.so.4
NEEDED libQtCore.so.4
NEEDED libpthread.so.0
NEEDED libQtOpenGL.so.4
NEEDED libQtScript.so.4
NEEDED libQtDeclarative.so.4
NEEDED libQtXmlPatterns.so.4
NEEDED libQtSql.so.4
NEEDED libQtNetwork.so.4
NEEDED libQtXml.so.4
NEEDED libkdeui.so.5
NEEDED libQtSvg.so.4
NEEDED libkdecore.so.5
NEEDED libQtDBus.so.4
NEEDED libQtGui.so.4
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
RUNPATH /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
(Thanks to Ludovic for the suggestion to use objdump!)
The linker line looks like this:
Linking CXX executable ktouch
cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1
/gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG -DQT_NO_DEBUG -Wl,--enable-new-dtags CMakeFiles/ktouch.dir/ktouch_automoc.o CMakeFiles/ktouch.dir/main.o CMakeFiles/ktouch.dir/application.o CMakeFiles/ktouch.dir/mainwindow.o CMakeFiles/ktouch.dir/bindings/utils.o CMakeFiles/ktouch.dir/bindings/stringformatter.o CMakeFiles/ktouch.dir/declarativeitems/applicationbackground.o CMakeFiles/ktouch.dir/declarativeitems/cursorshapearea.o CMakeFiles/ktouch.dir/declarativeitems/griditem.o CMakeFiles/ktouch.dir/declarativeitems/lessonpainter.o CMakeFiles/ktouch.dir/declarativeitems/preferencesproxy.o CMakeFiles/ktouch.dir/declarativeitems/scalebackgrounditem.o CMakeFiles/ktouch.dir/declarativeitems/
traininglinecore.o CMakeFiles/ktouch.dir/core/resource.o CMakeFiles/ktouch.dir/core/keyboardlayoutbase.o CMakeFiles/ktouch.dir/core/keyboardlayout.o CMakeFiles/ktouch.dir/core/abstractkey.o CMakeFiles/ktouch.dir/core/key.o CMakeFiles/ktouch.dir/core/keychar.o CMakeFiles/ktouch.dir/core/specialkey.o CMakeFiles/ktouch.dir/core/coursebase.o CMakeFiles/ktouch.dir/core/course.o CMakeFiles/ktouch.dir/core/lesson.o CMakeFiles/ktouch.dir/core/trainingstats.o CMakeFiles/ktouch.dir/core/profile.o CMakeFiles/ktouch.dir/core/dataindex.o CMakeFiles/ktouch.dir/core/dataaccess.o CMakeFiles/ktouch.dir/core/dbaccess.o CMakeFiles/ktouch.dir/core/profiledataaccess.o CMakeFiles/ktouch.dir/core/resourcedataaccess.o CMakeFiles/ktouch.dir/core/userdataaccess.o CMakeFiles/ktouch.dir/undocommands/coursecommands.o CMakeFiles/ktouch.dir/undocommands/keyboardlayoutcommands.o CMakeFiles/ktouch.dir/models/resourcemodel.o CMakeFiles/ktouch.dir/models/lessonmodel.o CMakeFiles/ktouch.dir/models/charactersmodel.o CMakeFiles/ktouch.dir/models/
categorizedresourcesortfilterproxymodel.o CMakeFiles/ktouch.dir/models/errorsmodel.o CMakeFiles/ktouch.dir/models/learningprogressmodel.o CMakeFiles/ktouch.dir/editor/resourceeditor.o CMakeFiles/ktouch.dir/editor/resourceeditorwidget.o CMakeFiles/ktouch.dir/editor/newresourceassistant.o CMakeFiles/ktouch.dir/editor/resourcetypeswidget.o CMakeFiles/ktouch.dir/editor/newcoursewidget.o CMakeFiles/ktouch.dir/editor/newkeyboardlayoutwidget.o CMakeFiles/ktouch.dir/editor/resourcetemplatewidget.o CMakeFiles/ktouch.dir/editor/abstracteditor.o CMakeFiles/ktouch.dir/editor/courseeditor.o CMakeFiles/ktouch.dir/editor/keyboardlayoutcombobox.o CMakeFiles/ktouch.dir/editor/lessontexteditor.o CMakeFiles/ktouch.dir/editor/lessontexthighlighter.o CMakeFiles/ktouch.dir/editor/keyboardlayouteditor.o CMakeFiles/ktouch.dir/editor/keyboardlayouteditorview.o CMakeFiles/ktouch.dir/editor/keyboardlayoutpropertieswidget.o CMakeFiles/ktouch.dir/editor/charactersviewdelegate.o CMakeFiles/ktouch.dir/trainingconfigwidget.o CMakeFiles/
ktouch.dir/colorsconfigwidget.o CMakeFiles/ktouch.dir/customlessoneditorwidget.o CMakeFiles/ktouch.dir/keyboardlayoutmenu.o CMakeFiles/ktouch.dir/preferences.o -o ktouch -rdynamic /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkio.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkcmutils.so.4.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtCore.so -lpthread /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtOpenGL.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtScript.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtDeclarative.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtXmlPatterns.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtSql.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/
lib/libkcmutils.so.4.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkio.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtNetwork.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtXml.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeui.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtSvg.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdecore.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtCore.so -lpthread /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtDBus.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtGui.so -Wl,-rpath,:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
You see lots of "...so" and no "-l...", which is apparently the cmake way of
doing things. But no "-Wl,-rpath" despite
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
Does this mean that this option only honours paths coming from "-l", while
at the same time using "-l" is unusual with cmake?
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 22:37 ` Andreas Enge
@ 2014-11-06 22:54 ` Andreas Enge
2014-11-06 23:12 ` Andreas Enge
2014-11-06 23:09 ` Eric Bavier
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2014-11-06 22:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
On Thu, Nov 06, 2014 at 11:37:44PM +0100, Andreas Enge wrote:
> Does this mean that this option only honours paths coming from "-l", while
> at the same time using "-l" is unusual with cmake?
Actually I do not know about the second part of the sentence, but the first
one seems to be true. When I add
-DCMAKE_EXE_LINKER_FLAGS=-lkdeclarative ,
the binary ktouch is indeed linked with an additional "-lkdeclarative".
In the link line, we still have "-Wl,-rpath,:::...:::".
Maybe something happens before or during installation. In any case, objdump
now shows:
RUNPATH /gnu/store/w931dmcqpkb3sdcxnjpqxdn7qykh3qbr-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
Notice the additional
/gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib ,
which contains libkdeclarative.so.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 22:37 ` Andreas Enge
2014-11-06 22:54 ` Andreas Enge
@ 2014-11-06 23:09 ` Eric Bavier
2014-11-06 23:24 ` Andreas Enge
2014-11-07 9:20 ` Ludovic Courtès
2014-11-07 14:59 ` 宋文武
3 siblings, 1 reply; 22+ messages in thread
From: Eric Bavier @ 2014-11-06 23:09 UTC (permalink / raw)
To: Andreas Enge; +Cc: Guix-devel, Federico Beffa
Andreas Enge writes:
> -Wl,-rpath,:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
As I understand things, cmake might relink executables during
installation with the appropriate rpath for the installation directory.
It may also patch the executables rpath in place, replacing the
"::::..." string above with the actual rpath, presumably containing the
directories of the .so's. Can you tell if any of that is taking place?
--
Eric Bavier
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 22:54 ` Andreas Enge
@ 2014-11-06 23:12 ` Andreas Enge
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2014-11-06 23:12 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
In nixpkgs, the file for ktouch looks like this:
{ kde, kdelibs, libxkbfile }:
kde {
buildInputs = [ kdelibs libxkbfile ];
meta = {
description = "Touch Typing Tutor";
};
}
Where do I find the "definition" of what could probably be called the
kde build system?
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 23:09 ` Eric Bavier
@ 2014-11-06 23:24 ` Andreas Enge
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2014-11-06 23:24 UTC (permalink / raw)
To: Eric Bavier; +Cc: Guix-devel, Federico Beffa
On Thu, Nov 06, 2014 at 05:09:35PM -0600, Eric Bavier wrote:
> As I understand things, cmake might relink executables during
> installation with the appropriate rpath for the installation directory.
> It may also patch the executables rpath in place, replacing the
> "::::..." string above with the actual rpath, presumably containing the
> directories of the .so's. Can you tell if any of that is taking place?
I do not think it could possibly patch in place, as the ":...:" string is
too short.
Before installing, there is another linking phase. But it also has the
":...:" rpath.
Then there is
-- Set runtime path of "/gnu/store/w931dmcqpkb3sdcxnjpqxdn7qykh3qbr-ktouch-4.14.2/bin/ktouch" to "/gnu/store/w931dmcqpkb3sdcxnjpqxdn7qykh3qbr-ktouch-4.14.2/lib"
which corresponds to
(string-append "-DCMAKE_INSTALL_RPATH=" out "/lib")
This is for the build where I explicitly gave "-lkdeclarative", and where the
final rpath does contain the path to the kde libraries (but not the path to
the qt libraries, as these were not given with -l, but directly as .so on
the linking line). So the log does not show at which point and how the rpath
is set.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 22:37 ` Andreas Enge
2014-11-06 22:54 ` Andreas Enge
2014-11-06 23:09 ` Eric Bavier
@ 2014-11-07 9:20 ` Ludovic Courtès
2014-11-07 14:51 ` Andreas Enge
2014-11-07 14:59 ` 宋文武
3 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2014-11-07 9:20 UTC (permalink / raw)
To: Andreas Enge; +Cc: Guix-devel, Federico Beffa
Andreas Enge <andreas@enge.fr> skribis:
> RUNPATH /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
>
> (Thanks to Ludovic for the suggestion to use objdump!)
>
> The linker line looks like this:
> Linking CXX executable ktouch
> cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1
> /gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++
[...]
> -o ktouch -rdynamic /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0
[...]
> You see lots of "...so" and no "-l...", which is apparently the cmake way of
> doing things.
Our ld-wrapper is ineffective when the .so file names are passed
directly like this. That is, ld-wrapper adds -rpath for any -l switch,
but it does not add -rpath for libraries whose absolute file name is
specified.
That could be easily fixed, but in core-updates.
> But no "-Wl,-rpath" despite
> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
> Does this mean that this option only honours paths coming from "-l", while
> at the same time using "-l" is unusual with cmake?
Uh. While we can improve ld-wrapper, the best would of course be to get
CMake to do the right thing...
Thanks for investigating,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-07 9:20 ` Ludovic Courtès
@ 2014-11-07 14:51 ` Andreas Enge
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2014-11-07 14:51 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
On Fri, Nov 07, 2014 at 10:20:15AM +0100, Ludovic Courtès wrote:
> Our ld-wrapper is ineffective when the .so file names are passed
> directly like this. That is, ld-wrapper adds -rpath for any -l switch,
> but it does not add -rpath for libraries whose absolute file name is
> specified.
>
> That could be easily fixed, but in core-updates.
>
> > But no "-Wl,-rpath" despite
> > -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
> > Does this mean that this option only honours paths coming from "-l", while
> > at the same time using "-l" is unusual with cmake?
>
> Uh. While we can improve ld-wrapper, the best would of course be to get
> CMake to do the right thing...
Following our discussion, I think that indeed the flag
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
does nothing at all, and that our ld-wrapper is doing all the work indeed.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2014-11-06 22:37 ` Andreas Enge
` (2 preceding siblings ...)
2014-11-07 9:20 ` Ludovic Courtès
@ 2014-11-07 14:59 ` 宋文武
3 siblings, 0 replies; 22+ messages in thread
From: 宋文武 @ 2014-11-07 14:59 UTC (permalink / raw)
To: Andreas Enge, Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
Andreas Enge <andreas@enge.fr> writes:
> On Thu, Nov 06, 2014 at 12:46:21PM +0100, Ludovic Courtès wrote:
>> Apologies if this was already mentioned, but why don’t
>> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE and
>> -DCMAKE_INSTALL_RPATH=$out/lib (in cmake-build-system.scm) lead to
>> binaries with a RUNPATH? As Eric said, this should produce binaries
>> with an appropriate RUNPATH, no? Or does it only take care of setting
>> the RUNPATH to $out/lib?
>
> From what I understood, the first variable should have solved the problem.
> I set -DCMAKE_VERBOSE_MAKEFILE=ON and compiled ktouch. When running it, it
> stops with
> ktouch: error while loading shared libraries: libkdeclarative.so.5:
> cannot open shared object file: No such file or directory
I vote for making CMAKE_VERBOSE_MAKEFILE=ON default in our cmake-build-system
>
> And indeed:
> $ ldd ~/.guix-profile/bin/ktouch
> linux-vdso.so.1 (0x00007fff961ff000)
> libkdeclarative.so.5 => not found
> ...
> (lots of other "not found").
>
> $ objdump -x ~/.guix-profile/bin/ktouch
> ...
> Dynamic Section:
> NEEDED libkdeclarative.so.5
> NEEDED libplasma.so.3
> NEEDED libkio.so.5
> NEEDED libkcmutils.so.4
> NEEDED libQtCore.so.4
> NEEDED libpthread.so.0
> NEEDED libQtOpenGL.so.4
> NEEDED libQtScript.so.4
> NEEDED libQtDeclarative.so.4
> NEEDED libQtXmlPatterns.so.4
> NEEDED libQtSql.so.4
> NEEDED libQtNetwork.so.4
> NEEDED libQtXml.so.4
> NEEDED libkdeui.so.5
> NEEDED libQtSvg.so.4
> NEEDED libkdecore.so.5
> NEEDED libQtDBus.so.4
> NEEDED libQtGui.so.4
> NEEDED libstdc++.so.6
> NEEDED libm.so.6
> NEEDED libgcc_s.so.1
> NEEDED libc.so.6
> RUNPATH /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
>
> (Thanks to Ludovic for the suggestion to use objdump!)
>
> The linker line looks like this:
> Linking CXX executable ktouch
> cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1
> /gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG -DQT_NO_DEBUG -Wl,--enable-new-dtags CMakeFiles/ktouch.dir/ktouch_automoc.o CMakeFiles/ktouch.dir/main.o CMakeFiles/ktouch.dir/application.o CMakeFiles/ktouch.dir/mainwindow.o CMakeFiles/ktouch.dir/bindings/utils.o CMakeFiles/ktouch.dir/bindings/stringformatter.o CMakeFiles/ktouch.dir/declarativeitems/applicationbackground.o CMakeFiles/ktouch.dir/declarativeitems/cursorshapearea.o CMakeFiles/ktouch.dir/declarativeitems/griditem.o CMakeFiles/ktouch.dir/declarativeitems/lessonpainter.o CMakeFiles/ktouch.dir/declarativeitems/preferencesproxy.o CMakeFiles/ktouch.dir/declarativeitems/scalebackgrounditem.o CMakeFiles/ktouch.dir/declarativeitems/
> traininglinecore.o CMakeFiles/ktouch.dir/core/resource.o CMakeFiles/ktouch.dir/core/keyboardlayoutbase.o CMakeFiles/ktouch.dir/core/keyboardlayout.o CMakeFiles/ktouch.dir/core/abstractkey.o CMakeFiles/ktouch.dir/core/key.o CMakeFiles/ktouch.dir/core/keychar.o CMakeFiles/ktouch.dir/core/specialkey.o CMakeFiles/ktouch.dir/core/coursebase.o CMakeFiles/ktouch.dir/core/course.o CMakeFiles/ktouch.dir/core/lesson.o CMakeFiles/ktouch.dir/core/trainingstats.o CMakeFiles/ktouch.dir/core/profile.o CMakeFiles/ktouch.dir/core/dataindex.o CMakeFiles/ktouch.dir/core/dataaccess.o CMakeFiles/ktouch.dir/core/dbaccess.o CMakeFiles/ktouch.dir/core/profiledataaccess.o CMakeFiles/ktouch.dir/core/resourcedataaccess.o CMakeFiles/ktouch.dir/core/userdataaccess.o CMakeFiles/ktouch.dir/undocommands/coursecommands.o CMakeFiles/ktouch.dir/undocommands/keyboardlayoutcommands.o CMakeFiles/ktouch.dir/models/resourcemodel.o CMakeFiles/ktouch.dir/models/lessonmodel.o CMakeFiles/ktouch.dir/models/charactersmodel.o CMakeFiles/ktouch.dir/models/
> categorizedresourcesortfilterproxymodel.o CMakeFiles/ktouch.dir/models/errorsmodel.o CMakeFiles/ktouch.dir/models/learningprogressmodel.o CMakeFiles/ktouch.dir/editor/resourceeditor.o CMakeFiles/ktouch.dir/editor/resourceeditorwidget.o CMakeFiles/ktouch.dir/editor/newresourceassistant.o CMakeFiles/ktouch.dir/editor/resourcetypeswidget.o CMakeFiles/ktouch.dir/editor/newcoursewidget.o CMakeFiles/ktouch.dir/editor/newkeyboardlayoutwidget.o CMakeFiles/ktouch.dir/editor/resourcetemplatewidget.o CMakeFiles/ktouch.dir/editor/abstracteditor.o CMakeFiles/ktouch.dir/editor/courseeditor.o CMakeFiles/ktouch.dir/editor/keyboardlayoutcombobox.o CMakeFiles/ktouch.dir/editor/lessontexteditor.o CMakeFiles/ktouch.dir/editor/lessontexthighlighter.o CMakeFiles/ktouch.dir/editor/keyboardlayouteditor.o CMakeFiles/ktouch.dir/editor/keyboardlayouteditorview.o CMakeFiles/ktouch.dir/editor/keyboardlayoutpropertieswidget.o CMakeFiles/ktouch.dir/editor/charactersviewdelegate.o CMakeFiles/ktouch.dir/trainingconfigwidget.o CMakeFiles/
> ktouch.dir/colorsconfigwidget.o CMakeFiles/ktouch.dir/customlessoneditorwidget.o CMakeFiles/ktouch.dir/keyboardlayoutmenu.o CMakeFiles/ktouch.dir/preferences.o -o ktouch -rdynamic /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkio.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkcmutils.so.4.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtCore.so -lpthread /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtOpenGL.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtScript.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtDeclarative.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtXmlPatterns.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtSql.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/
> lib/libkcmutils.so.4.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkio.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtNetwork.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtXml.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeui.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtSvg.so /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdecore.so.5.14.2 /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtCore.so -lpthread /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtDBus.so /gnu/store/ay41dmszxgl57mxsfrp0misnz159csw1-qt-4.8.6/lib/libQtGui.so -Wl,-rpath,:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
> You see lots of "...so" and no "-l...", which is apparently the cmake way of
> doing things. But no "-Wl,-rpath" despite
> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
> Does this mean that this option only honours paths coming from "-l", while
> at the same time using "-l" is unusual with cmake?
after read this, I think it's desired behaviors of cmake's imported targets:
http://www.cmake.org/pipermail/cmake/2010-September/039639.html
> Andreas
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
[not found] <641d5f5d.31e3.14aaea456bc.Coremail.iyzsong@163.com>
@ 2015-01-03 7:20 ` 宋文武
2015-01-03 11:06 ` Andreas Enge
2015-01-04 21:29 ` Ludovic Courtès
0 siblings, 2 replies; 22+ messages in thread
From: 宋文武 @ 2015-01-03 7:20 UTC (permalink / raw)
To: Guix-devel
> Andreas Enge <andreas@enge.fr> skribis:
>
>> RUNPATH /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
>>
>> (Thanks to Ludovic for the suggestion to use objdump!)
>>
>> The linker line looks like this:
>> Linking CXX executable ktouch
>> cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1
>> /gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++
>
> [...]
>
>> -o ktouch -rdynamic /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0
>
> [...]
>
>> You see lots of "...so" and no "-l...", which is apparently the cmake way of
>> doing things.
>
> Our ld-wrapper is ineffective when the .so file names are passed
> directly like this. That is, ld-wrapper adds -rpath for any -l switch,
> but it does not add -rpath for libraries whose absolute file name is
> specified.
>
> That could be easily fixed, but in core-updates.
>
>> But no "-Wl,-rpath" despite
>> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
>> Does this mean that this option only honours paths coming from "-l", while
>> at the same time using "-l" is unusual with cmake?
>
> Uh. While we can improve ld-wrapper, the best would of course be to get
> CMake to do the right thing...
We have not change ld-wrapper for this right?
And I have add a note to cmake's tracker:
http://www.cmake.org/Bug/view.php?id=14974
>
> Thanks for investigating,
> Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2015-01-03 7:20 ` 宋文武
@ 2015-01-03 11:06 ` Andreas Enge
2015-01-04 21:29 ` Ludovic Courtès
1 sibling, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2015-01-03 11:06 UTC (permalink / raw)
To: 宋文武; +Cc: Guix-devel
On Sat, Jan 03, 2015 at 03:20:45PM +0800, 宋文武 wrote:
> We have not change ld-wrapper for this right?
Not yet, but I think we should do it soon.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gnu: kde: Add kdelibs.
2015-01-03 7:20 ` 宋文武
2015-01-03 11:06 ` Andreas Enge
@ 2015-01-04 21:29 ` Ludovic Courtès
1 sibling, 0 replies; 22+ messages in thread
From: Ludovic Courtès @ 2015-01-04 21:29 UTC (permalink / raw)
To: 宋文武; +Cc: Guix-devel
宋文武 <iyzsong@gmail.com> skribis:
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>> RUNPATH /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../..
>>>
>>> (Thanks to Ludovic for the suggestion to use objdump!)
>>>
>>> The linker line looks like this:
>>> Linking CXX executable ktouch
>>> cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1
>>> /gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++
>>
>> [...]
>>
>>> -o ktouch -rdynamic /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0
>>
>> [...]
>>
>>> You see lots of "...so" and no "-l...", which is apparently the cmake way of
>>> doing things.
>>
>> Our ld-wrapper is ineffective when the .so file names are passed
>> directly like this. That is, ld-wrapper adds -rpath for any -l switch,
>> but it does not add -rpath for libraries whose absolute file name is
>> specified.
>>
>> That could be easily fixed, but in core-updates.
>>
>>> But no "-Wl,-rpath" despite
>>> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
>>> Does this mean that this option only honours paths coming from "-l", while
>>> at the same time using "-l" is unusual with cmake?
>>
>> Uh. While we can improve ld-wrapper, the best would of course be to get
>> CMake to do the right thing...
> We have not change ld-wrapper for this right?
I’ve made the change in d8491ba (core-updates), which Hydra is now
building. Please report any issues.
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-01-04 21:30 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-04 21:37 [PATCH] gnu: kde: Add kdelibs Andreas Enge
2014-11-05 13:18 ` Ludovic Courtès
2014-11-05 13:49 ` 宋文武
2014-11-05 19:22 ` Andreas Enge
-- strict thread matches above, loose matches on Subject: below --
2014-11-05 19:50 Federico Beffa
2014-11-05 20:15 ` Ludovic Courtès
2014-11-05 20:28 ` Eric Bavier
2014-11-05 21:00 ` Federico Beffa
2014-11-05 21:18 ` Andreas Enge
2014-11-05 23:20 ` Andreas Enge
2014-11-06 11:46 ` Ludovic Courtès
2014-11-06 22:37 ` Andreas Enge
2014-11-06 22:54 ` Andreas Enge
2014-11-06 23:12 ` Andreas Enge
2014-11-06 23:09 ` Eric Bavier
2014-11-06 23:24 ` Andreas Enge
2014-11-07 9:20 ` Ludovic Courtès
2014-11-07 14:51 ` Andreas Enge
2014-11-07 14:59 ` 宋文武
[not found] <641d5f5d.31e3.14aaea456bc.Coremail.iyzsong@163.com>
2015-01-03 7:20 ` 宋文武
2015-01-03 11:06 ` Andreas Enge
2015-01-04 21:29 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.