Re: [PATCH] gnu: Add systemd.

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

Re: fftw runtime cpu detection

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

Re: Treating tests as special case

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

Autotools formely: a blog post

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

Re: a blog post

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

Re: Treating tests as special case

On Thu, Apr 05, 2018 at 04:26:50PM -0400, Mark H Weaver wrote: > Tests on different hardware/kernel/kernel-config/file-system > combinations are quite useful for those who care about reliability of > their systems. I, for one, would like to keep running test suites on my > own systems. Sure. And

Re: Why is the default user group "users"? and: rights and access to /var/mail

Nils Gillmann writes: > can someone tell me why in gnu/system/shadow module you thought > it would be a good idea to default to "users" as a shared group > for all accounts created as normal user profiles? > > Reason why I'm asking has a second question attached: > Why does our

Re: Patching the default PATH of `su`

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

Re: Python applications that are also libraries

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.

Re: Treating tests as special case

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

Re: fftw runtime cpu detection

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

Re: Python applications that are also libraries

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

Re: Treating tests as special case

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

a blog post

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,

Re: fftw runtime cpu detection

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

Re: Patching the default PATH of `su`

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

Re: fftw runtime cpu detection

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

Re: fftw runtime cpu detection

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

Re: fftw runtime cpu detection

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

Re: Treating tests as special case

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

Re: Python applications that are also libraries

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

Re: Looking for Thunderbird/Icedove

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