Am 04.04.2018 um 22:13 schrieb Ricardo Wurmus:
>> If this is a "pure" application, I'd install it with*out* propagated
>> inputs. This might not be easy to determine, though.
> It is both. It is often used just as an application, but the procedures
> that make up the application are just as often
On Thu, Apr 05, 2018 at 08:05:39AM +0200, Gábor Boskovits wrote:
>Actually running tests test the behaviour of a software. Unfortunately
>reproducible build does not guarantee reproducible behaviour.
>Furthermore there are still cases, where the environment is
>not the same around t
On Thu, Apr 05, 2018 at 08:21:15AM +0200, Björn Höfling wrote:
> great ideas!
>
> Last night I did a
>
> guix pull && guix package -i git
>
> We have substitutes, right? Yeah, but someone updated git, on my new
> machine I didn't configure berlin.guixsd.org yet and hydra didn't have
> any subst
Am 05.04.2018 um 10:39 schrieb Pjotr Prins:
> We should not forbid people to run tests. But I don't think it should
> be the default once tests have been run in a configuation.
+1
> My point is that we should not overestimate/overdo the idea of
> leakage. Save the planet. We have responsibility.
+
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-trivial set of
bioinfo pipelines I got to 97.7% reproducibility (or 95.2% if you
include ve
Hi Pjotr,
> And this hooks in with my main peeve about building from source. The
> building takes long enough. Testing takes incredibly long with many
> packages (especially language related) and are usually single core
> (unlike the build).
I share the sentiment. Waiting for tests to complete
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-trivial set
> of bi
myg...@gmail.com skribis:
> Even as separate items, the video + slides would be a great addition to
> the Guix web site.
Done!
https://www.gnu.org/software/guix/blog/2018/guix--reproducible-builds-at-libreplanet-2018/
Ludo'.
Hello!
I sympathize with what you write about the inconvenience of running
tests, when substitutes aren’t available. However, I do think running
tests has real value.
Of course sometimes we just spend time fiddling with the tests so they
would run in the isolated build environment, and they do r
On Thu, Apr 05, 2018 at 04:14:19PM +0200, Ludovic Courtès wrote:
> I sympathize with what you write about the inconvenience of running
> tests, when substitutes aren’t available. However, I do think running
> tests has real value.
>
> Of course sometimes we just spend time fiddling with the tests
Pjotr Prins writes:
> If all the inputs are the same the test will *always* pass. There is
> no point to it! The only way such a test won't pass it by divine
> intervention or real hardware problems. Both we don't want to test
> for.
>
> If tests are so important to rerun: tell me why we are not
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 focussed integration tests - ref Hickey). What I am
> writing is that we don't have to rerun tests for everyone *once
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_PATH and ENV_SUPATH definitions in
/etc/login.de
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 focussed integration tests - ref Hickey).
On Thu, Apr 05, 2018 at 06:41:58PM +0200, Pjotr Prins wrote:
> Providing test-substitutes is much lighter and can be retained
> forever.
See it as a light-weight substitute. It can also mean we can retire
large binary substitutes quicker. Saving disk space. I think it is a
brilliant idea ;)
A res
Hi Pjotr,
Pjotr Prins writes:
> and he gave me a new insight which rang immediately true. He said:
> what is the point of running tests everywhere? If two people test the
> same thing, what is the added value of that? (I paraphrase)
>
> With Guix a reproducibly building package generates the sam
Hello Guix,
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 runtime, make those
kernels available
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
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 opensmtpd-service
19 matches
Mail list logo
