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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo