Hello Catonano,
Thanks for the blog post, I added your feed to my feed reader. I
understand your frustration with autotools, it can be difficult to
figure out how to get autotools to do what you want. The benefit of
autotools is that it creates the same interface to build, test, and
install GNU s
Hi Catano,
Thanks for the blog.
Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.
I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an
Ludovic Courtès writes:
> That said, if the package can be of any use, I don’t have any objections
> to its inclusion, especially after all the hard work that Marius and the
> reviewers put in it. ;-)
FWIW I think my work already paid off plenty ;-)
> I suspect the only use case that might wor
Ludovic Courtès writes:
> Eric Bavier skribis:
>
>> On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote:
>>
>>> If that’s the case, I’d be in favor of pushing this patch to core-updates.
>>
>> Great. I'll do some more testing. Should I send a finalized patch to
>> guix-patches when
Hello,
> > An idea that came up on #guix several months ago was to separate the
> > building of packages from testing. Testing would be a continuation of
> > the build, like grafts could be envisioned as a continuation of the
> > build.
> What problems would that solve?
If one can run tests s
On Fri, Apr 06, 2018 at 12:54:19AM -0700, Chris Marusich wrote:
> Eric Bavier writes:
>
> > I recently discovered that the FFTW library can do runtime cpu
> > detection.
>
> Cool! I'm not familiar with this library, but the patch seems pretty
> reasonable to me.
Thanks for looking at it.
> >
Eric Bavier skribis:
> On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote:
>> Hello Eric,
>>
>> Eric Bavier skribis:
>>
>> > I recently discovered that the FFTW library can do runtime cpu
>> > detection. In order to do this, the package needs to be configured to
>> > build SIMD "
On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote:
> Hello Eric,
>
> Eric Bavier skribis:
>
> > I recently discovered that the FFTW library can do runtime cpu
> > detection. In order to do this, the package needs to be configured to
> > build SIMD "codelets", like how our 'fftw-av
FYI, here's my current WIP patch to add Icedove. It's currently stuck
on the same issue that Nils reported being stuck on, but it's based on
our existing IceCat package and already includes most (maybe all?) of
the Icedove rebranding and FSDG fixes from Parabola.
This is currently based on core-u
Chris Marusich writes:
> Ricardo Wurmus writes:
>
>> we have a bunch of packages that are used both as applications and as
>> Python libraries. An example is “deeptools”.
>
> I took a brief peek at deeptools. It looks like there are programs in
> bin, and libraries in lib. Why can't we just
Hi Björn,
> On Thu, 05 Apr 2018 12:14:53 +0200
> Ricardo Wurmus wrote:
>
>> Björn Höfling writes:
>>
>> > And you mentioned different environment conditions like machine and
>> > kernel. We still have "only" 70-90% reproducibility.
>>
>> Where does that number come from? In my tests for a non-
On Fri, Apr 06, 2018 at 10:01:57AM +0200, Ludovic Courtès wrote:
> Probably, yes. It would be good to check how this affects
> mingetty/login, sshd, etc.
Okay. I can test the change.
> Note that libc also has its own default PATH value in :
>
> /* Default search path. */
> #define _PATH
Am 06.04.2018 um 11:12 schrieb Chris Marusich:
> Why can't we just split them into two
> outputs? For example, put the libraries into the default "out" output
> and the programs into the "bin" output.
For consistence, we should then do this for all other python packages
including a script, e.g. s
Ricardo Wurmus writes:
> we have a bunch of packages that are used both as applications and as
> Python libraries. An example is “deeptools”.
I took a brief peek at deeptools. It looks like there are programs in
bin, and libraries in lib. Why can't we just split them into two
outputs? For ex
Hello fellow guixers,
I posted a brand new post in my little personal somewhat indie blog
It's about Guix, Guile and Free Software in general. From my very own point
of view
You can find it here
http://catonano.v22018025836661967.nicesrv.de/guile-and-free-software.html
There's also a feed, reac
Pjotr Prins writes:
> I think we should have a switch for turning off tests. Let the builder
> decide what is good or bad. Too much nannying serves no one.
I think it would be OK to give users the choice of not running tests
when building from source, if they really don't want to. This is
simil
Pjotr Prins writes:
> Ludo is correct that provisioning binary substitutes is one solution.
> But not cheap. Can we guarantee keeping all substitutes? At least the
> ones with long running tests ;).
For berlin.guixsd.org we have an external storage array of a couple of
TB, which currently isn’
Hello Eric,
Eric Bavier skribis:
> I recently discovered that the FFTW library can do runtime cpu
> detection. In order to do this, the package needs to be configured to
> build SIMD "codelets", like how our 'fftw-avx' currently does. Then,
> based on the instruction support detected at runtim
Hello,
Leo Famulari skribis:
> In the man page of su(1), it says this:
>
> --
> The current environment is passed to the new shell. The value of $PATH is
> reset to
> /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
> superuser.
> This may be changed with the ENV_PA
Hello,
Pjotr Prins skribis:
> On Thu, Apr 05, 2018 at 05:24:12PM +0200, Ludovic Courtès wrote:
>> Pjotr Prins skribis:
>>
>> > I am *not* suggesting we stop testing and stop writing tests. They are
>> > extremely important for integration (thought we could do with a lot
>> > less and more focu
Eric Bavier writes:
> I recently discovered that the FFTW library can do runtime cpu
> detection.
Cool! I'm not familiar with this library, but the patch seems pretty
reasonable to me.
> In order to do this, the package needs to be configured to build SIMD
> "codelets", like how our 'fftw-avx'
21 matches
Mail list logo
