Re: [PATCH] guix package: Export generation procedures.

On Sat, Oct 04, 2014 at 09:59:06PM +0400, Alex Kost wrote: > - (Not related to this patch, but still …) Currently with “roll-back”, > we can only switch to the previous generation. What about adding a > possibility to switch to any generation? So that we could use > something like this: >

Re: [PATCH] gnu: clucene: Enable the contrib-libs.

On Mon, Oct 06, 2014 at 06:02:02PM +0200, Ludovic Courtès wrote: > LGTM. (Andreas is our Clucene expert now ;-), so you could leave him a > one-day delay before committing just in case.) I would not claim so. Maybe you could add a quick explanation at the top of the patches on where they are from

Re: [PATCH] gnu: clucene: Enable the contrib-libs.

On Mon, Oct 06, 2014 at 07:21:56PM +0200, John Darrington wrote: > I thought I did that. Sorry, my mistake! Andreas

Update sqlite

Hello, needing sqlite, I wondered if I could not quickly update it to the latest version. It appears that sqlite-large-page-size-fix.patch does not apply any more. Mark, as you added it, could you maybe check if it is still needed? Below is the new version and hash. Thanks! Andreas diff --git

Re: [PATCH] gnu: Add Cython

On Mon, Oct 20, 2014 at 08:43:38PM +0200, Federico Beffa wrote: > I'm a little bit unsure about the name of the package. I've not > prefixed it with "python[2]-" as the program extends the Python > language and can work with both (2 and 3) Python version series. > However, the package installs file

Re: [PATCH] gnu: Add ttf-symbola.

On Wed, Oct 22, 2014 at 08:51:04PM +0400, Alex Kost wrote: > «In lieu of a licence: Fonts in this site are offered free for any use; > they may be opened, edited, modified, regenerated, posted, packaged and > redistributed.» > Is it OK to use "fsf-free" for this package? To me, this sounds like "p

Re: [PATCH 5/5] gnu: Some cleanup based on lint checkers.

On Fri, Oct 24, 2014 at 12:19:03AM -0500, Eric Bavier wrote: > 2. Many descriptions begin with the package name in lowercase form, > which triggers a warning about the description beginning with a > lowercase letter. In this patch I capitalised the package name if I > could find a reference to the

Re: [PATCH] gnu: Add Cython

Concerning the following problem with python-wrapper: On Fri, Oct 24, 2014 at 05:51:12PM +0200, Federico Beffa wrote: > +;; we need the full python package and not just the python-wrapper > +;; because we need libpython3.3m.so Maybe we should propagate its input python? Then python-wrappe

Re: Suggestion: disable offloading for texlive builds on hydra?

On Sun, Oct 26, 2014 at 03:12:40PM +0100, Ludovic Courtès wrote: > - (outputs '("out" "data")) > + (outputs '("out" "data" "doc")) I just tried this, and it does not work: builder for `/gnu/store/r39sf9gzfdlxb6q2c4zaz18z63mmc8fz-texlive-2014.drv' failed to produce output path `/gnu/store/s75

Re: Suggestion: disable offloading for texlive builds on hydra?

On Wed, Oct 29, 2014 at 01:29:01PM +0100, Andreas Enge wrote: > A problem is that I need a working texlive, and compiling an additional > one may take too much space. Actually, now that deduplication works, havings several texlive installations with the same data is not a problem an

Texlive and native-inputs

Currently, texlive has a certain number of native inputs: (native-inputs `(("perl" ,perl) ("pkg-config" ,pkg-config) ("python" ,python-2) ; incompatible with Python 3 (print syntax) ("tcsh" ,tcsh))) But I think these are not needed during build time, but to patch-shebang sc

Re: Texlive and native-inputs

On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote: > If they were "normal" inputs and you were cross compiling, then the packages > which > are made available, would be those for the target system, not the native one. > Hence > they could not run, and the build would break. Well,

Re: Texlive and native-inputs

On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote: > You are probably right - to be sure they should be manually checked. An > alternative would be to attempt cross building all the affected packages. In the case that native inputs should instead be normal, if I understand correct

Re: Texlive and native-inputs

On Wed, Oct 29, 2014 at 06:39:48PM +0100, Andreas Enge wrote: > Would it work? One would need to patch-shebang with the normal input and > use the native-input for scripts that are used during the build process. > Is this distinguished somehow? (Well, there is of course the problem of

Re: Suggestion: disable offloading for texlive builds on hydra?

On Sun, Oct 26, 2014 at 12:07:13PM -0400, Mark H Weaver wrote: > Hmm. It is indeed a hack, but maybe worth considering. When I think > about Guix users downloading over 3 GiB from our humble hydra quite > often just to have TeX, it makes me worry about our bandwidth > requirements. What do you m

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

On Tue, Oct 28, 2014 at 09:10:30AM +0100, Ludovic Courtès wrote: > Alex Kost skribis: > > Not related to this patch: what about renaming ‘freefont-ttf’ package > > into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"? > I think so. What do others think? Andreas? So far, we have no

Re: [PATCH 1/2] gnu: Add numpy

On Mon, Oct 27, 2014 at 09:26:41PM +0100, Federico Beffa wrote: > I get error messages that matplotlib is missing. I started looking at > matplotlib as well, but I've found that, for the TkAgg back-end, it > needs TKinter which is part of the standard python libraries and it is > built if, during

Re: Problems with downloading from https

On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote: > Alex Kost skribis: > > But currently it's not possible to install 2 (or more) packages with the > > same name. So a user can't have guile 2.0 and guile 1.8 in the same > > profile. The same thing with python: there is no ‘python2

Re: [PATCH 1/2] gnu: Add numpy

On Tue, Oct 28, 2014 at 10:34:48AM +0100, Ludovic Courtès wrote: > Ah right. And what if you again remove Python from ‘inputs’, and add > #:python ,python > to the arguments? > That means it will use the actual Python 3.x package, not the wrapper, > so everything will be visible. The downside i

Re: [PATCH 1/2] gnu: Add numpy

On Wed, Oct 29, 2014 at 08:55:52PM +0100, Federico Beffa wrote: > Updated patch. > - (python (string-append (assoc-ref %build-inputs "python") > "/bin/"))) > + (python (string-append (assoc-ref %build-inputs "python") > "/bin/")) > + (lib (string-a

Re: Texlive and native-inputs

On Wed, Oct 29, 2014 at 08:55:55PM +0100, John Darrington wrote: > What do these scripts do anyway? Are they fundamental to TeXlive or are they > for some bells and whistles? I never use them as far as I know, so they do not seem to be fundamental. Andreas

Icecat not substituted

Hello, when issueing guix package -u icecat -n I see: The following package would be upgraded: icecat 31.2.0 → 31.2.0 /gnu/store/rsf4pww335qqv7iyss54i8fmwr7kfm83-icecat-31.2.0 The following derivations would be built: /gnu/store/wxfxjbbc268gxmbinb0bnckhxq6h

Propagate python in python-wrapper

As discussed, I would like to push such a patch. But: $ guix refresh -l python-wrapper Building the following 185 packages would ensure 364 dependent packages are rebuilt In light of these numbers, should we do this in core-updates? There is also the lingering update of pkg-config that I would

Re: Problems with downloading from https

On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote: > I think such an "evil" case is just not handled currently. If you have > python-3… installed and you install python-2… in the same profile, then > python-3… would be replaced, but if you install both packages in the > same command, then

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote: > Why should? What about “ttf-dejavu”? Should it be called > “dejavu-fonts-ttf” then? Yes, that was a mistake, maybe inspired from the debian package name. We should rename it. > Then it shouldn't be prefixed with "ttf". I suggest to u

Re: Texlive and native-inputs

On Thu, Oct 30, 2014 at 08:53:24AM +0100, John Darrington wrote: > In that case, it would seem to me, that perl should not be in input at all. It should. Perl is needed for "make check". But even if it were not, we always patch-shebang script files in our packages. Otherwise they would not be usab

Re: Font package naming convention

On Thu, Oct 30, 2014 at 06:20:46PM +0100, Ludovic Courtès wrote: > There’s no documented convention (yet), so it’s not a mistake strictly > speaking. :-) We have a convention for package names, including fonts; so strictly speaking it is a mistake. > I think we must settle on a convention, and I

Re: [PATCH 1/2] gnu: Add numpy

On Thu, Oct 30, 2014 at 05:56:53PM +0100, Federico Beffa wrote: > On Wed, Oct 29, 2014 at 11:20 PM, Andreas Enge wrote: > > So we should add tk as an input to the python package? > > That would be great! In this way the python package should build the > Tkinter library

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

On Thu, Oct 30, 2014 at 03:52:50PM +0300, Alex Kost wrote: > I don't understand why you call it a mistake. It's just a package name > used by some distributions (and I think it's a good name). Is there a > convention to use “…-fonts-ttf” in Guix? It may be a good name, but the Guix convention is

Re: Problems with downloading from https

On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote: > I think the latter is a bug. IMHO it shouldn't be possible to install > several packages with the same name in one profile. Well, having python 2 and 3 is reasonable, and from what I saw in their naming scheme, it is entirely possible (

Patch-shebangs phase and created binaries

Hello, should the final patch-shebangs phase not include the generated output path (well, the bin subdirectory) in its $PATH? In texlive I see lines such as patch-shebang: ./texmf-dist/tex/luatex/lualibs/lualibs-compat.lua: warning: no binary for interpreter `texlua' found in $PATH The file sta

Re: Font package naming convention

On Fri, Oct 31, 2014 at 06:58:40PM +0100, Andreas Enge wrote: > On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote: > > Andreas prefers this ↑ > I did not say this. Sorry, I actually did prefer this ;-) But I am open to discussion. Andreas

Re: Font package naming convention

On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote: > I suggest this ↑ IIUC it is a common practice in other distributions. This is absolutely no argument for us! We have quite a few different practices from other distributions (and some of them are more logical, I think, like trying to st

Re: Font package naming convention

Alex, On Sat, Nov 01, 2014 at 12:36:30PM +0300, Alex Kost wrote: > I think the majority should decide. So if the most of guix people think > that it should be named "bar", then let it be so. for this we would need an "infrastructure": a social contract, a voting system and what else not, which s

Re: Font package naming convention

On Fri, Oct 31, 2014 at 10:30:24PM +0100, Ludovic Courtès wrote: > Furthermore, unlike software packages, what matters here is the actual > name of the font or font collection, not the “system name” or “tarball > name.” > Here’s a possible answer to the above questions, informally: > • Use ‘font-

Re: Different versions of a package in the same profile?

On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote: > Technically it would be easy to allow the installation of different > versions of a package in the same profile, but I wonder about the > implications. > > For instance, ‘-u foo’ would upgrade all the installed versions of > ‘foo’,

Re: Update sqlite

On Sat, Oct 25, 2014 at 07:20:10PM -0400, Mark H Weaver wrote: > I got the patch from upstream, but they didn't want to apply it to their > stable branch. I'm not sure whether the latest release is part of that > same branch or not. For that matter, I never checked to see if they > applied it to

Re: [PATCH] gnu: Add freeimage.

Hello! On Sat, Nov 01, 2014 at 11:48:46AM -0400, David Thompson wrote: > +(uri (string-append > "mirror://sourceforge/freeimage/Source%20Distribution/" > +version "/FreeImage" > +(string-join (string-split version #\.) ""

Re: [PATCH] gnu: Add docbook-xml-4.2

On Sun, Nov 02, 2014 at 06:26:59PM +0100, Federico Beffa wrote: > Add version 4.2. It is needed by dconf. This looks very safe (although we will end up with four versions of it!). Andreas

Re: Different versions of a package in the same profile?

On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote: > I don’t think so. In this thread, I rather wanted to discuss the > implications of allowing same-named packages to be installed in the same > profile, should we decide to go that route. > > > Another idea: How about letting "guix

Re: Changing python-wrapper to handle lib/ etc.

On Thu, Oct 30, 2014 at 02:12:58PM +0100, Ludovic Courtès wrote: > We’ll also need the patch from > in > this branch. Maybe not, we will see. Once the python library is propagated, should it not appear automatically in the LIBRAR

Re: [PATCH] gnu: Add freeimage.

On Sat, Nov 01, 2014 at 01:21:55PM -0400, David Thompson wrote: > +'(#:phases (alist-replace > +'unpack > +(lambda* (#:key source #:allow-other-keys) > + (and (zero? (system* "unzip" source)) > + (chdir "FreeImage"))) > +

Re: Patch-shebangs phase and created binaries

On Sun, Nov 02, 2014 at 05:54:09PM +0100, Ludovic Courtès wrote: > Andreas Enge skribis: > > should the final patch-shebangs phase not include the generated output > > path (well, the bin subdirectory) in its $PATH? > It already does. Hm. > > The file starts with &

Re: Font package naming convention

On Sun, Nov 02, 2014 at 06:18:19PM +0100, Ludovic Courtès wrote: > Some of the fonts created by foundries are often referred to it using > the foundry’s name, such as “Bitstream Vera”; there are also > counter-examples, like Gentium, Charis, etc. (by SIL.) > > So, again very informally, I would su

Re: [PATCH] gnu: Add freeimage.

Unfortunately, it fails to build on mips: http://hydra.gnu.org/build/136438 Could you have a look? To me it looks as if there is bad assembly code in the source: /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s: Assembler messages: /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s:360: Error: opc

Re: Changing python-wrapper to handle lib/ etc.

The first problem occurs. Swig does not compile any more: http://hydra.gnu.org/build/134889/log/raw There are lots of error messages of the form: checking testcase namespace_nested under python namespace_enum_wrap.cxx:154:21: fatal error: Python.h: No such file or directory # include If one

Re: [PATCH] gnu: Add freeimage.

On Mon, Nov 03, 2014 at 10:00:38AM +0100, Ludovic Courtès wrote: > Same problem as with Valgrind, so I would suggest disabling builds on > MIPS, as done in commit 67a86d3. Speaking of valgrind, how is transitivity of disabled builds handled, on hydra and by the users? I noticed that some packages

Re: Font package naming convention

On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote: > If there’s rough consensus on this, the next step would be to write this > informal rule in the manual, and to update package names. > > Any volunteer? Alex? :-) I volunteer, as I feel responsible for the package guidelines. An

[andr...@enge.fr: ATLAS fails to build on mips]

As I am not sure if Fede is subscribed to the bug mailing list, I am forwarding my report here. It is http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18933 Andreas - Forwarded message from Andreas Enge - ATLAS fails to build on mipsel64: http://hydra.gnu.org/build/133025 with mkdir

Re: Changing python-wrapper to handle lib/ etc.

On Mon, Nov 03, 2014 at 11:11:22AM +0100, Federico Beffa wrote: > - Compilation fixes on some systems for the generated Lua, PHP, Python > and R wrappers. > Maybe, it was an upstream bug? Thanks, I will try to update and keep you updated. Andreas

Re: [PATCH] gnu: Add Cython

On Mon, Nov 03, 2014 at 05:57:58PM +0100, Ludovic Courtès wrote: > Federico Beffa skribis: > > Subject: [PATCH] gnu: Add Cython > > * gnu/packages/python.scm(cython,cython2): New variables. > Pushed, with missing spaces in the commit log added. I think that should have gone on the wip-python bran

Re: [PATCH] gnu: Add Cython

On Mon, Nov 03, 2014 at 08:42:25PM +0100, Ludovic Courtès wrote: > But are you sure you aren’t confusing it with NumPy, which requires the > new python-wrapper? Probably I am confusing things, even less problems then! Andreas

Re: Changing python-wrapper to handle lib/ etc.

On Mon, Nov 03, 2014 at 11:13:45AM +0100, Andreas Enge wrote: > Thanks, I will try to update and keep you updated. This was it not. There is also a newer swig-3.0.2, but it also does not solve the problem. My suspicion is that swig has never worked with python for us. So my current solution wo

Re: Changing python-wrapper to handle lib/ etc.

On Mon, Nov 03, 2014 at 09:19:28PM +0100, Andreas Enge wrote: > This was it not. There is also a newer swig-3.0.2, but it also does not > solve the problem. My suspicion is that swig has never worked with python > for us. So my current solution would be to disable it and push this change

Re: Changing python-wrapper to handle lib/ etc.

On Mon, Nov 03, 2014 at 09:49:21PM +0100, Andreas Enge wrote: > In 2.0.12 without python, now the guile tests fail... 3.0.2 without python > compiles well, so I am trying to build the swig dependencies now. Everything worked well, so I pushed this solution to wip-python. Andreas

Re: Changing python-wrapper to handle lib/ etc.

Next step: When adding tk as an input to python, I get the followiing error. tcl in place of tk poses no problem; is there another variable named tk somewhere? Backtrace: In srfi/srfi-1.scm: 578: 19 [map # (# # # ...)] In guix/packages.scm: 655: 18 [expand-input # # # ...] 613: 17 [cache # # #

Re: Changing python-wrapper to handle lib/ etc.

On Tue, Nov 04, 2014 at 05:48:56PM +0100, Ludovic Courtès wrote: > Doesn’t that create a circular dependency between the ‘python’ package > and the ‘tk’ package, somehow? I checked only the direct inputs, the key is in "somehow"! tk depends on libx11, depends on libxcb, depends on python. How do

Re: Changing python-wrapper to handle lib/ etc.

On Tue, Nov 04, 2014 at 06:08:30PM +0100, Andreas Enge wrote: > How do we break this dependency? By creating one version of python with > input tk (used inside the xorg module), and one with input tk (served to > the outside world)? The first "with" should have been "without", of course. Andreas

Package version at build side

Hello, for kdelibs, I need to pass the version of the input docbook-xsl as a configure flag. So I added something like #:configure-flags (list "-DCMAKE_VERBOSE_MAKEFILE=ON" ; for debugging (let ((docbook-xsl (assoc-ref %build-inputs "docbook-xsl"))) (s

Re: Package version at build side

On Tue, Nov 04, 2014 at 02:55:58PM -0600, Eric Bavier wrote: > You should be able to do this by quasi-quoting the list and unquoting > package-version. See e.g. the definition of maxima in maths.scm:891. That did it, thank you! Andreas

[PATCH] gnu: kde: Add kdelibs.

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 a

Re: How to package software for guix?

On Tue, Nov 04, 2014 at 02:06:56PM -0800, Omar Radwan wrote: > I wanna get into guix development. Since I don't know any programming, I would > be most useful in packaging software for guix. I want to package lxqt. I know > qt5 is in the guix repo. So it wouldn't be very hard to package it, I think

Re: [ART] Background image for GRUB

On Tue, Nov 04, 2014 at 04:15:47PM -0600, Eric Bavier wrote: > I think the the red in the lower corners is a bit distracting though. > Could it perhaps be a more subtle color? Or could it be more Guix specific? For instance, one of the coloured petals of the guix logo in each corner, and the text

Re: Changing python-wrapper to handle lib/ etc.

On Tue, Nov 04, 2014 at 10:40:14PM +0100, Ludovic Courtès wrote: > guix gc --references $(guix build libxcb) | grep python > shows nothing. So what about creating a bare-bones Python for that > (perhaps with other optional dependencies removed, while we’re at it), > and use that as a dependency

Re: [ART] Background image for GRUB

One more comment: It would be good to have a high contrast in the grub screen, but I do not know if this is related to the background image or needs to be done in grub. For instance, white text on dark background would work better than the current light gray text on dark background. Ideal from my p

Re: [ART] Background image for GRUB

On Tue, Nov 04, 2014 at 08:22:54PM -0200, Bruno Félix Rezende Ribeiro wrote: > I think that if we want to make the GNU Guix distribution the one and > true GNU operating system, as a sort of marketing strategy, we need to > make every reference to the sense of operating system or software > distrib

Re: [ART] Background image for GRUB

On Wed, Nov 05, 2014 at 12:31:48PM -0200, Bruno Félix Rezende Ribeiro wrote: > GNU Guix is a package manager, GNU is an operating system. Please, > don't conflate the two. Part of the fun in Guix is that it conflates and blurs boundaries, the package descriptions, the dmd init system and the pack

Re: [PATCH] gnu: kde: Add kdelibs.

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

Acl

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"))) to (zero? (system* "make" "install"))) or not replacing the n

Re: [PATCH] gnu: kde: Add kdelibs.

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 definitel

Re: [ART] Background image for GRUB

On Wed, Nov 05, 2014 at 04:28:25PM -0500, Felipe López wrote: > Since I completely agree with Bruno, here is the GRUB image proposal > using the GNU logo: > http://sirgazil.bitbucket.org/static/temp/img/gnu/2014-11-05-grub-dark.png The GNU is nice. How about having a gnu without the text and then

Re: [ART] Background image for GRUB

On Wed, Nov 05, 2014 at 10:39:17PM +0100, Andreas Enge wrote: > This is not bad at all! The gnu like a watermark is very elegant, I think. > But the Guix logo and the gnu head are stomping on each other's feet. How > about putting the Guix logo in the lower right corner of the

Re: [PATCH] gnu: kde: Add kdelibs.

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

Re: [ART] Background image for GRUB

On Wed, Nov 05, 2014 at 06:38:12PM -0500, Felipe López wrote: > As for the frame, GRUB 2 is supposed to be more flexible about the > appearance of the elements in the screen. The frame can be removed and > the boot options can be graphically enhanced. However, I'm using GRUB > legacy appearance bec

Re: [ART] Background image for GRUB

On Thu, Nov 06, 2014 at 11:09:09AM -0500, Felipe López wrote: > Since the background with the GNU head seems to work, here is modified > version. I made the head a bit more visible and moved the Guix logo to a > corner. > MOD: > http://sirgazil.bitbucket.org/static/temp/img/guix/2014-11-06-grub-dar

Re: Acl

On Wed, Nov 05, 2014 at 09:38:32PM +0100, Ludovic Courtès wrote: > Commit 16755848 added ‘install-lib’ (before that libacl.so was not > installed) Ah, nothing stops the progress! Just to make sure that I understand things correctly: Can we drop the 'patch-makefile-SHELL phase? There is no occurre

Re: Acl

The attached patch should do the job. Andreas >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 unnee

Re: [PATCH] gnu: kde: Add kdelibs.

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

Re: [PATCH] gnu: kde: Add kdelibs.

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 on

Re: [PATCH] gnu: kde: Add kdelibs.

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

Re: [PATCH] gnu: kde: Add kdelibs.

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

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

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".

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 t

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

Libtool

Hello, I need a newer libtool, and thought it would have to go into core-updates. But: $ guix refresh -l libtool Building the following 93 packages would ensure 162 dependent packages are rebuilt So should I update in master instead? Andreas

1000

Hello, if my count is correct, I just pushed package number 1000: $ guix package -A|wc -l 1000 The package itself is not so exciting, but the number is something to celebrate! Andreas

Re: Libtool

On Sun, Nov 09, 2014 at 06:47:19PM +0100, Ludovic Courtès wrote: > (Now, you’ve probably found a good case for Eric to study. ;-)) I have another one: $ guix refresh -l acl Building the following 95 packages would ensure 195 dependent packages are rebuilt Andreas

Re: Libtool

The test suite has been rewritten, the patches do not apply any more, and some of the tests they disabled do not seem to exist any more. The current test results are: ERROR: 137 tests were run, 66 failed (59 expected failures). 32 tests were skipped. So there are 7 failed tests now. I am attaching

Propagated inputs

Hello, polkit builds two libraries, polkit-agent and polkit-gobject. According to pkg-config, the second one Requires: gio-2.0 >= 2.18 glib-2.0 >= 2.18, while the first one requires nothing. So I decided to not propagate the glib input (which also contains gio), as potentially one could use th

Re: [ART] Background image for login manager and desktop

On Tue, Nov 11, 2014 at 10:19:03PM +0100, Ludovic Courtès wrote: > > Here is a background image for login managers and desktops: > > http://sirgazil.bitbucket.org/static/temp/img/guix/layers-16-10.png > I like it! Me too! > I was wondering whether it’d be relevant to add a logo somewhere, but > m

Re: Atheros firmware support

On Wed, Nov 12, 2014 at 10:59:47AM +0100, Ludovic Courtès wrote: > Commit 1306b0b fixes a miscompilation of the ath9k-htc-firmware package > (I had overlooked the fact that the upstream source patches Binutils and > GCC to get things done.) This is a bit frightening: $ git diff 1306b0b003a557105d3

Re: Releasing on Tue, 18th?

On Wed, Nov 12, 2014 at 11:05:56AM +0100, Ludovic Courtès wrote: > I think most of the important things are in place for the release, and I > would like to target Tuesday 18th as the release date. So we would need > to be done with testing and everything on Monday. Thoughts? I would like to merg

Re: [ART] Background image for login manager and desktop

On Wed, Nov 12, 2014 at 03:00:39PM -0500, Felipe López wrote: > Here is a variant of the SLiM theme with the GNU: > > http://sirgazil.bitbucket.org/static/temp/img/guix/panel-gnu.png > > This one has the GNU head as well but all elements are centered on the > screen (needs modification of slim.th

Re: Releasing on Tue, 18th?

On Wed, Nov 12, 2014 at 02:03:09PM +0100, Ludovic Courtès wrote: > What package(s) do these ACL fixes unblock? None except for ACL - it is the addition of include files, and some modifications to the test environment (with tests still not executed). Rebuilding the archive was incidental and not a

Re: [ART] Background image for login manager and desktop

On Wed, Nov 12, 2014 at 07:23:07PM -0500, Felipe López wrote: > The only decent position I could find for the head as a watermark was this: > http://sirgazil.bitbucket.org/static/temp/img/guix/panel-gnu-watermark.png > The GNU head overlaps with the waves, but the same happens in the other > varian

Re: Handling ‘file’ CVE

On Thu, Nov 13, 2014 at 11:41:17AM +0100, Ludovic Courtès wrote: > Commit 3940c5c makes a replacement for ‘file’, so that the new version > of file (5.20), which fixes a security vulnerability, is now grafted > onto packages that are installed. >From what it looks like on hydra, this triggered a c

Re: wip-libreoffice

On Thu, Nov 13, 2014 at 07:01:41PM +0100, John Darrington wrote: > I've pushed a branch wip-libreoffice which has the start of a package for > libreoffice and dependencies. Amazing! I thought you needed java for this? Actually, you could already propose patches for the dependencies that we could

Re: [PATCH 3/4] gnu: Add minetest-data.

Hello! On Sun, Nov 16, 2014 at 10:59:37AM -0500, David Thompson wrote: > +(define-public minetest-data As I suppose that this is only meaningful as a propagated input of minetest, maybe it would be better to not expose it to the public, by using only "define"? Andreas

  1   2   3   4   5   6   7   8   9   10   >