Re: Optionally using more advanced CPU features

2017-08-25 Thread Pjotr Prins
On Sat, Aug 26, 2017 at 11:39:41AM +0800, Ben Woodcroft wrote: > I was wondering how we should go about optionally building software for > more advanced CPU features. Currently, we build software for the lowest > common feature set among x86_64 CPUs. That’s good for portability, but > not so good

Re: Optionally using more advanced CPU features

2017-08-25 Thread Ben Woodcroft
Hi, On 21/08/17 22:23, Ricardo Wurmus wrote: Hi Guix, I was wondering how we should go about optionally building software for more advanced CPU features. Currently, we build software for the lowest common feature set among x86_64 CPUs. That’s good for portability, but not so good for perform

Re: 'core-updates' status

2017-08-25 Thread Leo Famulari
On Fri, Aug 25, 2017 at 10:57:12PM +0300, Manolis Ragkousis wrote: > On 08/25/17 21:34, Marius Bakke wrote: > > Hello! > > > > 'core-updates' has finished building on x86_64 on i686, and the grafting > > failures should now be fixed. Are we ready to merge this branch? :-) > > > > Does cross-com

Re: 'core-updates' status

2017-08-25 Thread Manolis Ragkousis
On 08/25/17 21:34, Marius Bakke wrote: > Hello! > > 'core-updates' has finished building on x86_64 on i686, and the grafting > failures should now be fixed. Are we ready to merge this branch? :-) > Does cross-compilation work? Because I cannot cross-compile anything for any target I tried (i686

Re: 'core-updates' status

2017-08-25 Thread Leo Famulari
On Fri, Aug 25, 2017 at 08:34:21PM +0200, Marius Bakke wrote: > 'core-updates' has finished building on x86_64 on i686, and the grafting > failures should now be fixed. Are we ready to merge this branch? :-) I think it's ready. There are a handful of failing packages left, but I assume they will

Re: 'core-updates' status

2017-08-25 Thread Marius Bakke
Marius Bakke writes: > Marius Bakke writes: > >> What do you think, are we ready to merge this branch? There are ~2k >> armhf packages left in the queue, but many of them have already changed >> in 'master' and thus will need to be rebuilt anyway. > > I started a (hopefully final) evaluation wh

Re: Guix - installation script

2017-08-25 Thread Christopher Baines
On Mon, 31 Jul 2017 23:49:50 +0100 Sharlatan Hellseher wrote: > I've found your project very interesting. I've played with > installation instruction but it has a lot of different steps, for > convenience purpose I've wrote installation script which goes through > all points of your guide. > > A

Re: QT install and search paths

2017-08-25 Thread 宋文武
Here is a patch to adjust the directory layout of qtbase: >From b264ccfdec5c7334ef7e428c8b483bc673edc393 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= Date: Fri, 25 Aug 2017 22:52:41 +0800 Subject: [PATCH] gnu: qtbase: Use a more standard directory layout. * gnu/packages

Re: System configuration on non-GuixSD systems (Debian)

2017-08-25 Thread Pjotr Prins
On Fri, Aug 25, 2017 at 09:56:50AM +0200, Ricardo Wurmus wrote: > > One maybe bizare suggestion that comes to mind is to use a container > > created through the `guix system container` command. > > > > This would allow you to create a set of processes, that you could give > > access to specific par

Re: QT install and search paths

2017-08-25 Thread 宋文武
Hartmut Goebel writes: > Am 24.08.2017 um 13:59 schrieb 宋文武: >> Currently, it doesn't follow a normal package layout, We should change >> it to (like it in Debian and ArchLinux): > > I'd support this. > > What do you think about using "…/qt5" instead of just "…/qt", like > Fedora does. IMHO this

Re: Difference between search-paths and native-search-path

2017-08-25 Thread Ricardo Wurmus
Hi Hartmut, > what is the difference between search-paths and native-search-path? The > manual describes search-paths at [1], but native-search-paths are only > named at [2] without any description. “native-search-paths” are used when cross-building. The arm eabi cross-compiler, for example, d

Re: System configuration on non-GuixSD systems (Debian)

2017-08-25 Thread Ricardo Wurmus
Christopher Baines writes: > On Tue, 22 Aug 2017 11:23:25 +0200 > Pjotr Prins wrote: > >> I need to reinstall a Debian server (again) and I am looking at how I >> can use 'guix system' to configure stuff. I remember there was someone >> who wrote a about configuring on non-GuixSD, but can't fin

Re: QT install and search paths

2017-08-25 Thread Hartmut Goebel
Am 24.08.2017 um 13:37 schrieb Thomas Danckaert: > Either way, I think qtbase's QT_PLUGIN_PATH setting only has an effect > if a user installs qtbase directly in their profile […] so > applications using these plugins will still need to set the correct > environment variable themselves somehow? Do

Difference between search-paths and native-search-path

2017-08-25 Thread Hartmut Goebel
Hi, what is the difference between search-paths and native-search-path? The manual describes search-paths at [1], but native-search-paths are only named at [2] without any description. [1] https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#index-search-paths-1 [2] http

Re: On packaging old versions of libraries

2017-08-25 Thread Pjotr Prins
On Thu, Aug 24, 2017 at 10:06:43PM -0500, Eric Bavier wrote: > > I'm going to look into what is required to backport, but if I decided to > > go the first route, I would probably use Guix. Would such a > > contribution be accepted considering it packages older libraries, which > > would add some c

Re: QT install and search paths

2017-08-25 Thread Hartmut Goebel
Am 24.08.2017 um 13:59 schrieb 宋文武: > Currently, it doesn't follow a normal package layout, We should change > it to (like it in Debian and ArchLinux): I'd support this. What do you think about using "…/qt5" instead of just "…/qt", like Fedora does. IMHO this is not a bad idea. > Which need adju