Re: Acl
Andreas Enge skribis: > From 34f1cd18d14a0a75d73e7f4b57f76495edae56d8 Mon Sep 17 00:00:00 2001 > From: Andreas Enge > Date: Thu, 6 Nov 2014 22:56:32 +0100 > Subject: [PATCH] gnu: acl: Also install header files. > > * gnu/packages/acl.scm (acl): Install header files. Drop unneeded phase > PATCH-MAKEFILE-SHELL. OK. Could you create the ‘core-updates’ branch and commit it? Thanks! Ludo’.
Re: [PATCH] gnu: kde: Add kdelibs.
Andreas Enge 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’.
Re: [PATCH] gnu: kde: Add kdelibs.
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
Re: [PATCH] gnu: kde: Add kdelibs.
Andreas Enge 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 (0x7fff961ff000) > 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/resou
Xorg, mesa, libdrm
I just came across these lines in the new package xf86-video-modesetting:
(inputs `(;; FIXME: This is a libdrm version incompatible with that of
;; MESA, which xorg-server uses. Therefore, using this driver
;; leads to "unresolved symbol drmModeSetCursor2".
("libdrm" ,libdrm)
Could we not simply use libdrm-2.4.33 as in mesa? The same should hold for
xf86-video-intel. Or probably better yet, as in the other xf86-video-*,
use mesa as an input.
Andreas
More corner cases for ‘guix lint’
I’ve just pushed a series of changes that make ‘guix lint’ better handle various corner cases found in the wild for synopses and descriptions: 15a6d43 * lint: Allow synopses that start with an abbreviation. 105c260 * lint: Skip starting-article test for the synopses of GNU packages. 431e5f5 * lint: Tolerate sentences that start with a parenthesis or a quote. 17854ef * lint: Improve check for synopses starting with package name. b1e6668 * lint: Simplify no-warnings tests. Comments welcome. Ludo’.
Re: Xorg, mesa, libdrm
Andreas Enge skribis:
> I just came across these lines in the new package xf86-video-modesetting:
> (inputs `(;; FIXME: This is a libdrm version incompatible with that of
> ;; MESA, which xorg-server uses. Therefore, using this driver
> ;; leads to "unresolved symbol drmModeSetCursor2".
> ("libdrm" ,libdrm)
> Could we not simply use libdrm-2.4.33 as in mesa?
No, this driver requires the latest libdrm.
The long-term solution will be to use the same one in MESA, but I’d
rather not do it too close to the release. :-)
Thanks,
Ludo’.
Re: Xorg, mesa, libdrm
On Fri, Nov 07, 2014 at 05:56:51PM +0100, Ludovic Courtès wrote: > No, this driver requires the latest libdrm. And the intel driver? I think that may have been my mistake in the first place to not use mesa. > The long-term solution will be to use the same one in MESA, but I’d > rather not do it too close to the release. :-) Yes, update to a newer mesa - but they have this unpleasant infinite configure loop. Andreas
[ART] Background image for login manager and desktop
Hi, I'm starting to work on this. The background images should work for any login manager and desktop environment, but I'm testing in GNOME 3 because I can't access SLiM's website to find information about theme structure. [1] It seems that the SLiM project was abandoned. [2] I'll post a background image proposal soon. Best, [1] http://slim.berlios.de/ [2] https://wiki.archlinux.org/index.php/SLiM -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
Re: Xorg, mesa, libdrm
On Fri, Nov 07, 2014 at 07:02:04PM +0100, Andreas Enge wrote: > And the intel driver? I think that may have been my mistake in the first > place to not use mesa. I pushed after swapping libdrm with mesa. It still compiles, at least. Andreas
Re: Acl
On Fri, Nov 07, 2014 at 10:15:12AM +0100, Ludovic Courtès wrote:
> OK. Could you create the ‘core-updates’ branch and commit it?
Done. I have also worked a bit on tests and got them to execute at least.
Now a few of the first ones fail like this:
[16] $ ls -dl d | awk '{print $1}' | sed 's/.$//g' -- failed
drwxr-xr- != drwxr-xr-t
[18] $ ls -dl d/u | awk '{print $1}' | sed 's/.$//g' -- failed
-rwSr--r- != -rwSr--r--
[20] $ ls -dl d/g | awk '{print $1}' | sed 's/.$//g' -- failed
-rw-r-Sr- != -rw-r-Sr--
It looks as if "ls -dl" were expected to output one character more than
it does. The tests also fail outside of guix. When I drop the "sed ...",
these tests pass, but then others fail.
Andreas
Re: Acl
l...@gnu.org (Ludovic Courtès) writes: > ndreas Enge skribis: > >> Adding optional inputs to kdelibs, I notice that acl is not recognised. >> The reason is that the header files are not installed. Would that be easy >> to modify? Maybe by changing the line >> (zero? (system* "make" "install" "install-lib"))) > > Commit 16755848 added ‘install-lib’ (before that libacl.so was not > installed), but yeah, installing headers would have been cool too. ;-) Indeed. I would apologize for overlooking this, but doc/INSTALL specifically recommends "make install install-lib", and "install-dev" appears to be completely undocumented :-/ Mark
