Hi Guixs, this is actually a feature wish.
I tried to use guix to manage many of my softwares on my system, but
some dependencies are missing which is blocking a full transition to
Guix based system and development environment. Most notably is GPU
computing support.
My daily routine is doing mach
Joshua Branson writes:
> Fis Trivial writes:
>
>> Hi Guixs, this is actually a feature wish.
>>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based syst
Ludovic Courtès writes:
> Hello,
>
> Joshua Branson skribis:
>
>> Fis Trivial writes:
>>
>>> Hi Guixs, this is actually a feature wish.
>>>
>>> I tried to use guix to manage many of my softwares on my system, but
>>> some dependencies
Ricardo Wurmus writes:
> Hi,
>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based system and development environment. Most notably is GPU
>> computing support.
>>
>> My daily routine is doin
Tobias Platen writes:
> On 25.04.2018 19:17, Ricardo Wurmus wrote:
>>
>> Hi,
>>
>>> I tried to use guix to manage many of my softwares on my system, but
>>> some dependencies are missing which is blocking a full transition to
>>> Guix based system and development environment. Most notably is GPU
>
> Oh sorry, I had overlooked that.
>
No problem, I really appreciate all the hardwork you have done, thanks. :)
> You wrote:
>
>> However, I wanted to manage all of these with guix so that we can have a
>> unified dependency tree. Currently there are a few options for OpenCL
>> runtime. Namel
Chris Marusich writes:
> Hi Guix,
>
> I've noticed that a fair number of packages in gnu/packages/python.scm
> using the python-build-system declare native-inputs. I suspect that in
> every case, these should actually just be inputs. I also suspect that
> this is benign, except perhaps for the
Ludovic Courtès writes:
> Hi,
>
> Fis Trivial skribis:
>
>>>> However, I wanted to manage all of these with guix so that we can have a
>>>> unified dependency tree. Currently there are a few options for OpenCL
>>>> runtime. Namely, beigne
Fis Trivial writes:
> Ludovic Courtès writes:
>
>> Hi,
>>
>> Fis Trivial skribis:
>>
>>>>> However, I wanted to manage all of these with guix so that we can have a
>>>>> unified dependency tree. Currently there are a few options for
Hi, Guixs.
Recently I encountered some libraries that's written in c++ and have
multiple language bindings, each of them has their corresponding build
system, namely, R, Python, Java. And all the bindings are in
tree. During the build process, One would first build the c++ part by
cmake, then chd
Ricardo Wurmus writes:
> Fis Trivial writes:
>
>> An ideal scenario would be the one that we can specify multiple outputs
>> for one packages, each output corresponds to one language binding, and
>> we can specify different dependencies and build system for each
>&g
Ricardo Wurmus writes:
> Fis Trivial writes:
>
>>> We can also
>>> reuse parts of build systems without having to reimplement them
>>> manually. We would simply reference them with something like this:
>>>
>>> --8<---cut here-
Catonano writes:
> 2018-05-09 17:21 GMT+02:00 Fis Trivial :
>
>>
>> Hi, Guixs.
>>
>> Recently I encountered some libraries that's written in c++ and have
>> multiple language bindings, each of them has their corresponding build
>> system, namel
Christopher Lemmer Webber writes:
> I think Catonano and Mark discussed things nicely earlier in the thread,
> so I'm not going to weigh in on that (though I do agree that we would
> can and should do better, but that also it's important to realize that
> community members only have so many pers
>
> Fis claimed that the error messages that Guile provides them with don't
> include indications about in which file the error occurred
>
> So he's using Chez scheme instead of Guile, if I remember correctly
>
> I take from this that the Chez scheme error mesages are better.
>
Actually, I tried
Please help sending this package to guix-patches list. I got blocked due
to various reasons (It's not something bad, it's just I can't send it
myself with contained keywords). The patches is contained within
package.tar.xz attached in this mail.
Thanks in advance.
package.tar.xz
Description: pa
Fis Trivial writes:
> Please help sending this package to guix-patches list. I got blocked due
> to various reasons (It's not something bad, it's just I can't send it
> myself with contained keywords).
Contained keyword probably is just the name of that package.
&g
Jonathan Brielmaier writes:
> Maybe you should use a different mail provider. Hotmail is known to have
> sometimes issues like this.
>
> On 6/12/18 1:07 PM, Fis Trivial wrote:
>>
>> Fis Trivial writes:
>>
>>> Please help sending this package to guix
Gábor Boskovits writes:
> 2018-06-12 13:43 GMT+02:00 Fis Trivial :
>
>>
>> Jonathan Brielmaier writes:
>>
>> > Maybe you should use a different mail provider. Hotmail is known to have
>> > sometimes issues like this.
>> >
>> > On 6/12/1
宋文武 writes:
> Fis Trivial writes:
>
>> Please help sending this package to guix-patches list. I got blocked due
>> to various reasons (It's not something bad, it's just I can't send it
>> myself with contained keywords). The patches is contained within
Tim Gesthuizen writes:
> Hi,
>
> I am trying to package irony-mode for emacs and quickly
>
> noticed that I need more input on how packages like this should
>
> be seperated or handled.
>
> Maybe somebody wants to take my approach and integrate the
>
> package definition(s) into guix or provide
Ludovic Courtès writes:
> Hello Guix!
>
> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> do or might want to do for 1.0, with the understanding that 1.0 should
> happen in 2018 (or early 2019 at the latest!). :-)
>
> https://git.savannah.gnu.org/cgit/guix/maintenance
Björn Höfling writes:
> On Sat, 08 Sep 2018 13:25:15 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> Hello!
>>
>> One week left to submit a proposal. Manolis, Pjotr: please let us
>> know if you need more input!
>
> I added another talk that I could give: Hacking free software with GNU
> Guix
Hi Brett,
Clang-tidy comes from clang-extra-tools, which is not bundled in guix package.
I have my own clang packaging based on clang-7. But I don't have time to test
upgrading LLVM on core-update. Here is my clang package which includes clang
extra tools, anyone interested in packaging LLVM-7 f
Please ignore the patches field though.
Trivial Fis writes:
> Hi Brett,
>
> Clang-tidy comes from clang-extra-tools, which is not bundled in guix package.
> I have my own clang packaging based on clang-7. But I don't have time to test
> upgrading LLVM on core-update. Here is my clang package
On 12/28/2017 01:16 AM, Pjotr Prins wrote:
> I just went through
>
> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
>
> And it works well enough.
>
> Two minor niggles:
>
> 1. Can we inline section 4 on creating users and build group? I think
> people easily miss
Due to bug#29864
http://lists.gnu.org/archive/html/guix-patches/2018-01/msg00177.html
I need to package *rct* library to solve to bundling issue of *rtags*.
Reading from the short README file and a glimpse of source code from rct, it's
like a
oversimplified version of Qt, or maybe Boost.
I have
The network connections to hydra is bad at day time from where I am, the
download speed is about 10kB/s, I can only work with guix at night.
And sometimes I use guix --fallback option(like texlive), guix will redirect to
the upstream download link. Chances are the upstream has even worse network
ba
Sorry about the mess in the original question.
>
> ‘Installing’ is too ambiguous to answer.
>
> - When *substituting* (installing a binary), native-inputs are not
> required and should never be downloaded.
This answers my question in mind, thanks. :)
>
> If any of the substitute servers *can* pr
I am currently running guix on top of Fedora 26. This is a mix of several
problems, and possibly contains bugs in guix, I am not sure if I have done
anything wrong. So I will try to describe them in order. If you believe I
should make separate threads or fill a bug report, just tell me to.
I trie
On 01/21/2018 04:45 AM, Pjotr Prins wrote:
> On Sat, Jan 20, 2018 at 08:16:04PM +0000, Fis Trivial wrote:
>> I am currently running guix on top of Fedora 26. This is a mix of several
>> problems, and possibly contains bugs in guix, I am not sure if I have done
>> anything wr
Sorry for the really late reply.
>
> Installing a missing package by guessing from non-existing command is a
> Fedora's “feauture” of Bash. I believe this is a reason of following
> failures. You probably could avoid this by starting a Bash process with
>
> bash --noprofile
>
> [...]
>
It wo
On 01/20/2018 06:40 PM, Danny Milosavljevic wrote:
> Hi Leo,
>
>> Although native-inputs are typically things that are only required while
>> building [0], there's nothing that prevents a built package from keeping
>> references to native-inputs.
>
> We should change that in core-updates-next,
>
> What do you mean by disable? You could invoke it at any time with a
> clean Bash session. Also I would recommend to search for a Fedora's
> Bash feature for installing programms if a command is missing and
> disable/remove it. Fedora's folks probably could help this it.
>
> Oleg.
Thanks fo
* Problem
The exported environment variables can cause various problems in foreign
distribution(1)(2). And besides, The long list of environment variables(4)
injected into user's login shell makes the user's environment impure.
So, I believe that if I want to run guix safely on a foreign distribut
>
>> I will post the profile files in another thread latter if its helpful.
>
> It maybe be helpful. Thank you!
>
I don't think it's needed. Please check
https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00507.html
Hi:
Ludovic Courtès writes:
> Hello,
>
> Fis Trivial skribis:
>
>> * Problem
>> The exported environment variables can cause various problems in foreign
>> distribution(1)(2). And besides, The long list of environment variables(4)
>> injected into
Pjotr Prins writes:
> On Thu, Feb 01, 2018 at 12:40:39AM +0100, Ludovic Courtès wrote:
>> Hello,
>>
>> Fis Trivial skribis:
>>
>> > * Problem
>> > The exported environment variables can cause various problems in foreign
>> > distrib
Ludovic Courtès writes:
> Hello Guix!
>
> This post is a followup to our previous discussions on how to handle
> architecture-specific optimizations:
>
>
> https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/
>
> Comments welcome!
>
> Ludo’.
Instructions support
Ludovic Courtès writes:
> Hello,
>
> Fis Trivial skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hello Guix!
>>>
>>> This post is a followup to our previous discussions on how to handle
>>> architecture-specific optimizations:
>&g
Fis Trivial writes:
> Ludovic Courtès writes:
>
>> Hello,
>>
>> Fis Trivial skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Hello Guix!
>>>>
>>>> This post is a followup to our previous discussions on ho
>
> It depends. The frontier between data and code is not as clear as it may
> seem. An example: the weights of a trained neural network can be seen as
> data (a bunch of numbers), but also as code for a special-purpose
> processor defined by the neural network.
>
> Starting from that example, con
> On Wed, Feb 14, 2018 at 04:43:50AM +0000, Fis Trivial wrote:
>> Sorry for bothering with a completely unrelated topic.
>> I'm curious do you train neural network with packages in Guix? Or did
>> you packaged related libraries yourself?
>>
>> I would love t
43 matches
Mail list logo
