Hello,
I am trying to build an armhf disk image on an aarch64 machine.
The build fails in this order:
genimage requires fdisk
fdisk requires guile-1.8.8 (!)
guile-1.8.8 fails two of its 16 tests:
ERROR: Value out of range -9223372036854775808 to 9223372036854775807:
-9223372036854775808
FAIL: te
The same two tests also fail on an armhf machine.
Andreas
emacs-next recently broke. It now has this error on start up.
"require: Cannot open load file: No such file or directory, seq"
I think this must have happened relatively recently (with the last 3
weeks) since it was working fine earlier.
signature.asc
Description: OpenPGP digital signature
Hi,
I had a similar error yesterday, with emacs27. Turned out I had to reload
my environment because some variables still pointed to emacs 26.3
directories which didn't exist anymore.
Malte
On Tue, 8 Sep 2020, 14:25 Martin Becze, wrote:
> emacs-next recently broke. It now has this error on sta
Here is what happens when I drop fdisk from native-inputs of genimage:
starting phase `check'
make --no-print-directory check-TESTS
PASS: test/basic-images.test 1 - cpio
SKIP: test/basic-images.test 2 # SKIP cramfs (missing mkcramfs)
...
PASS: test/basic-images.test 20 - fit
==
I just tried out emacs27 and what replicated Malte's experience. But
even after reloading my environment emacs28 doesn't work.
On 9/8/20 7:40 AM, Malte Gerdes wrote:
> Hi,
>
> I had a similar error yesterday, with emacs27. Turned out I had to
> reload my environment because some variables still p
Hi Martin,
Martin Becze writes:
> emacs-next recently broke. It now has this error on start up.
>
> "require: Cannot open load file: No such file or directory, seq"
Maybe it's possible to find where this is coming from?
(starting emacs with "--debug-init" might help or starting with a
minimal .e
--debug-init doesn't help and we don't seem to be loading the init file.
On 9/8/20 9:01 AM, Michael Rohleder wrote:
> Hi Martin,
>
> Martin Becze writes:
>> emacs-next recently broke. It now has this error on start up.
>>
>> "require: Cannot open load file: No such file or directory, seq"
>
> M
On Tue, Sep 08, 2020 at 03:12:03PM +0200, Andreas Enge wrote:
> So there does not even seem to be a test that relies on fdisk.
Looking at the tests, they do call "fdisk" and "sfdisk", but these come
from the util-linux package. The fdisk package only provides "gnufdisk",
which does not seem to be
On Tue, Sep 08, 2020 at 05:47:53PM +0200, Andreas Enge wrote:
> The next step would be to check newer releases (12 and 13) of genimage.
> Has it actually ever been built on the arm architecture?
I tried 12 and 13, but already on x86_64 the test
FAIL: test/basic-images.test 7 - mke2fs
fails.
If so
Hi,
Andreas Enge [2020-09-08 18:24:21+0200]:
>> The next step would be to check newer releases (12 and 13) of genimage.
>> Has it actually ever been built on the arm architecture?
genimage tests fail on arm64 due to differently signed char. The fix¹
is in upstream master but has not been release
It looks like it's failing when trying to build a dependency,
python-gssapi-1.6.5. Here's the log:
#+BEGIN_EXAMPLE
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to
`/gnu/store/wc4xh9wj49r
Seems to be the same as in #42370:
https://issues.guix.gnu.org/42370
signature.asc
Description: PGP signature
On 9/7/2020 2:52 PM, divoplade wrote:
Le lundi 07 septembre 2020 à 23:19 +0200, divoplade a écrit :
Sorry, I don't know how to make a patch.
By trying to make one, I noticed that you have already sent a patch. I
don't know why I did not recieve it. I am still clueless about a lot of
things her
Hello,
On Mon, Sep 07, 2020 at 06:15:15PM +1000, Brendan Tildesley wrote:
> Your patch also works I think but it will wrap the programs twice, so
> you will get calibre, .calibre-real, and ..calibre-real-real, etc for
> every program, which seems ugly. My patch reproduces the same PYTHONPATH
> tha
Hello Timotej,
On Tue, Sep 08, 2020 at 07:50:58PM +0200, Timotej Lazar wrote:
> genimage tests fail on arm64 due to differently signed char. The fix¹
> is in upstream master but has not been released yet. Maybe we can add
> it to the current Guix package until then?
> ¹ https://github.com/pengutro
In an eariler bug comment [1] I corroborated that nscd was leaking
/etc/passwd information from the host OS into the Guix container, and I
wondered aloud why the container would use the host OS's nscd if there was
a risk of this happening.
I've looked into how Guix configures its own nscd, and it
17 matches
Mail list logo
