* tests/guix-package.sh: The 'rm -rf' for clean-up inside the trap may not
succeed on an NFS share, but this should not fail the test.
---
tests/guix-package.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/guix-package.sh b/tests/guix-package.sh
index 3e5fa71d20..b1c6e
Guillaume Le Vaillant skribis:
> Marius Bakke skribis:
>
>> Hello Guix,
>>
>> gst-plugins-bad fails its test suite on anything other than x86_64-linux.
>>
>> Upstream issues:
>>
>> i686:
>> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1463
>> aarch64:
>> https://gitla
Hi!
The “dtmp/” issue is not new. It appeared already in these bugs:
https://issues.guix.gnu.org/27032
https://issues.guix.gnu.org/27034
https://issues.guix.gnu.org/29676
In all cases it happens in tests/store.scm:
test-name: verify-store + check-contents
This bug happened on x86_64 and aarch
raingloom writes:
> On Mon, 23 Nov 2020 03:32:08 +0100
> Taylan Kammer wrote:
>
>> On 23.11.2020 00:20, Christopher Lemmer Webber wrote:
>> > Okay, I just realized I left a friend vulnerable by guiding them
>> > through a Guix graphical install and telling them it would give
>> > them a decent se
Carlo Zancanaro writes:
> Hey Chris!
>
> On Mon, Nov 23 2020, Christopher Lemmer Webber wrote:
>> ... Plus, few distributions do what we're doing anymore, precisely
>> because of wanting to be secure by default.
>
> Is this true? Debian defaults to passwords being allowed. I think it
> even allows
On a recent pull, MPD will not start any more.
Herd status reports:
--8<---cut here---start->8---
Status of mpd:
It is stopped.
It is disabled.
Provides (mpd).
Requires (user-processes).
Conflicts with ().
Will be respawned.
Last respawned on Mon N
Seems strange... the message I get:
guix deploy: error: failed to deploy tulsi: ~A: ~S
Errors upon errors! Formatting this time, apparently. :)
Looking at the relevant code:
(define (deploy-machine* store machine)
"Deploy MACHINE, taking care of error handling."
(info (G_ "deploying to ~
By the way, I did pinpoint out what caused the failure in *deploying*,
but not what caused the error message to not format correctly.
The mistake was:
(modify-services %desktop-services
(guix-service-type config =>
(guix-configuration
Fun With More Debian packaging test suite failures...
Updating the build dependency to libgit2-dev >= 1.0.1 (which pulls in a
similar version to what guix is using) fixes test suite failures ... but
only on the amd64 architecture. The same tests pass Using an older
version of libgit2-dev (0.28). F
Guillaume Le Vaillant skriver:
> After trying to find where the problem could come from, GStreamer
> started working fine again, but I'm not sure why. I suspect there was
> some bad local state in my user environment that I reset while hacking
> around, or something like that...
Oh, that's good
10 matches
Mail list logo
