Re: GuixSD on eoma68-a20?

2018-12-16 Thread Danny Milosavljevic
Hi Ludo,

> > The following package will be installed:
> >guile-bootstrap  2.0 
> > /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0  
> 
> The solution I proposed only works if you’re using /gnu/store as your
> store prefix.  Otherwise you cannot get substitutes from the build
> farm.  :-/

I do use /gnu/store , but I think the above was from a "guix" package unit test.

> > gnu/packages/scheme.scm:170:30: In procedure inputs:
> > Throw to key `match-error' with args `("match" "no matching pattern" 
> > "armhf-linux")'.  
> 
> This looks like the issue fixed in
> 966629a114fd90153784dfdbe5e332e0ac94f1bc.

Indeed.

Now po4a fails one of the tests.  It's not easy to get the image :)

I'll try some more...


pgpYCPhXEZaJ9.pgp
Description: OpenPGP digital signature


Re: GuixSD on eoma68-a20?

2018-12-16 Thread Ludovic Courtès
Hi Danny,

Danny Milosavljevic  skribis:

> On Fri, 14 Dec 2018 11:48:52 +0100
> Ludovic Courtès  wrote:
>
>> I believe you can download it by running:
>> 
>>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv
>
> I don't have it.
>
>> If you don’t have this .drv, you should be able to build it from commit
>> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.
>
> I tried
>
> ./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin 
> (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu 
> system install)) (operating-system (inherit installation-os) (bootloader 
> (bootloader-configuration (bootloader u-boot-bootloader) (target #f)'
>
> and I get:
>
> [...]
> The following package will be installed:
>guile-bootstrap  2.0 
> /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The solution I proposed only works if you’re using /gnu/store as your
store prefix.  Otherwise you cannot get substitutes from the build
farm.  :-/

> gnu/packages/scheme.scm:170:30: In procedure inputs:
> Throw to key `match-error' with args `("match" "no matching pattern" 
> "armhf-linux")'.

This looks like the issue fixed in
966629a114fd90153784dfdbe5e332e0ac94f1bc.

HTH!

Ludo’.



Re: GuixSD on eoma68-a20?

2018-12-15 Thread Danny Milosavljevic
Hi Ludo,

On Fri, 14 Dec 2018 11:48:52 +0100
Ludovic Courtès  wrote:

> I believe you can download it by running:
> 
>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

I don't have it.

> If you don’t have this .drv, you should be able to build it from commit
> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

I tried

./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin 
(use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system 
install)) (operating-system (inherit installation-os) (bootloader 
(bootloader-configuration (bootloader u-boot-bootloader) (target #f)'

and I get:

[...]
The following package will be installed:
   guile-bootstrap  2.0 
/tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The following derivation will be built:
   /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv
building /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv...
1 package in profile
The following environment variable definitions may be needed:
   export PATH="t-profile-15269/bin${PATH:+:}$PATH"
++ guix package -A guile-bootstrap
++ cut -f 1-2
Backtrace:
In guix/ui.scm:
  1603:12 19 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9 18 (catch _ _ # …)
829:9 17 (catch _ _ # …)
In guix/scripts/package.scm:
914:8 16 (_)
   729:25 15 (process-query _)
In guix/discovery.scm:
155:3 14 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
45:26 13 (fold2 # …)
45:26 12 (fold2 # …)
In guix/discovery.scm:
   158:33 11 (_ # …)
In guix/scripts/package.scm:
   732:39 10 (_ # …)
In guix/packages.scm:
   777:17  9 (supported-package? # …)
In guix/memoization.scm:
101:0  8 (_ # # …)
In srfi/srfi-1.scm:
   466:18  7 (fold # …)
In guix/packages.scm:
   768:33  6 (_ _ ("x86_64-linux" "i686-linux" "armhf-linux" "aar…" …))
In guix/memoization.scm:
101:0  5 (_ # # …)
In guix/packages.scm:
   980:46  1 (thunk)
In gnu/packages/scheme.scm:
   170:30  0 (inputs)

gnu/packages/scheme.scm:170:30: In procedure inputs:
Throw to key `match-error' with args `("match" "no matching pattern" 
"armhf-linux")'.
++ guix package -p t-profile-15269 -I
++ cut -f 1-2
+ test '' = 'guile-bootstrap2.0'
+ rm -f t-profile-15269 t-profile-15269-1-link t-guix-package-file-15269
+ rm -rf t-guix-package-15269 t-home-15269
./test-env: line 1: 15250 Terminated  
"/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/pre-inst-env" 
"/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/guix-daemon" 
--disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
FAIL tests/guix-package.sh (exit status: 1)
[...]
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6:
 In procedure check:
Throw to key `srfi-34' with args `(#)'.
builder for 
`/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed 
with exit code 1
build of /gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv 
failed
View build log at 
'/var/log/guix/drvs/db/f84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv.bz2'.
guix system: error: build failed: build of 
`/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed

And no image...


pgppR3qNVXNCA.pgp
Description: OpenPGP digital signature


Re: GuixSD on eoma68-a20?

2018-12-14 Thread Ludovic Courtès
Hello!

Danny Milosavljevic  skribis:

> Ye!
>
> flash-image just successfully built on Hydra.
>
> Can I have the resulting file please?
>
> See https://hydra.gnu.org/build/3255541/log/raw

I believe you can download it by running:

  guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

If you don’t have this .drv, you should be able to build it from commit
cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

See all the details at .

Ludo’.



Re: GuixSD on eoma68-a20?

2018-12-12 Thread Danny Milosavljevic
Ye!

flash-image just successfully built on Hydra.

Can I have the resulting file please?

See https://hydra.gnu.org/build/3255541/log/raw


pgpDhY5HPmJHh.pgp
Description: OpenPGP digital signature


Re: GuixSD on eoma68-a20?

2018-12-11 Thread Ludovic Courtès
Hi Mark,

Mark H Weaver  skribis:

> Danny Milosavljevic  writes:
>
>> After the change, I get the following on Hydra 
>> :
>>
>> ---
>> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 
>> x86_64-linux 
>> /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
>> environment variable `PATH' set to 
>> `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
>> creating raw image of 1024.00 MiB...
>> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw 
>> size=1073741824
>> Could not access KVM kernel module: Permission denied
>> qemu-system-x86_64: failed to initialize KVM: Permission denied
>
> This indicates that /dev/kvm on hydra.gnunet.org has permissions that
> prevent the guix build user from accessing it.
>
> I raised this issue long ago (2015) on the guix-sysadmin mailing list.
> In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
> 0600 and is owned by root, which caused our disk image derivations to
> fail.
>
> At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
> to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
> but that for some reason that didn't seem to work, possibly because it
> was being overridden by another rule or startup script.  As far as I
> know, we never implemented a proper fix.
>
> Ludovic, for now, can you chmod it again?

I did that again this morning.

Apparently there was a typo in the udev rules I had written: “=” instead
of “==”…  Should be better now on the next reboot.

Ludo’.



Re: GuixSD on eoma68-a20?

2018-12-09 Thread Mark H Weaver
Hi Danny and Ludovic,

Danny Milosavljevic  writes:

> After the change, I get the following on Hydra 
> :
>
> ---
> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 
> x86_64-linux 
> /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
> environment variable `PATH' set to 
> `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
> creating raw image of 1024.00 MiB...
> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw 
> size=1073741824
> Could not access KVM kernel module: Permission denied
> qemu-system-x86_64: failed to initialize KVM: Permission denied

This indicates that /dev/kvm on hydra.gnunet.org has permissions that
prevent the guix build user from accessing it.

I raised this issue long ago (2015) on the guix-sysadmin mailing list.
In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
0600 and is owned by root, which caused our disk image derivations to
fail.

At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
but that for some reason that didn't seem to work, possibly because it
was being overridden by another rule or startup script.  As far as I
know, we never implemented a proper fix.

Ludovic, for now, can you chmod it again?

 Thanks,
   Mark



Re: GuixSD on eoma68-a20?

2018-12-09 Thread Danny Milosavljevic
After the change, I get the following on Hydra 
:

---
@ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 
x86_64-linux 
/var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
environment variable `PATH' set to 
`/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
creating raw image of 1024.00 MiB...
Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw 
size=1073741824
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
Backtrace:
   2 (primitive-load "/gnu/store/c2phacd8p7x3g8ysnzrx09jmnxp?")
In ./gnu/build/vm.scm:
152:2  1 (load-in-linux-vm _ #:output _ #:qemu _ #:memory-size _ ?)
In ./guix/build/utils.scm:
616:6  0 (invoke _ . _)

./guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed 
with exit code 1
@ build-failed /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 1 
builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed 
with exit code 1
---

What does it mean?


pgpDzIgJ5Ck3h.pgp
Description: OpenPGP digital signature


Re: GuixSD on eoma68-a20?

2018-12-08 Thread Danny Milosavljevic
Hi Mark,

On Sat, 08 Dec 2018 15:59:58 -0500
Mark H Weaver  wrote:

> This sounds like two distinct bugs:
> 
> * Regarding the lack of disk space: if I'm not mistaken, as things are
>   currently implemented, we must specify the size of the disk image
>   manually.  I guess we need to increase the size.

Ah, you are right!  https://hydra.gnu.org/build/3194622/log/raw (the usb-image
for i686) also fails - but nobody noticed because we only distribute the iso
image (which determines its size dynamically).

I didn't make the connection that this is a fixed-size guest filesystem before.

> * This error that occurs within QEMU is apparently not being propagated
>   to the outer build script.  That should be fixed.

Yes.

> > I'm now setting up my own build server and trying to get the flash image
> > that way - which is ridiculous.  
> 
> You seem to be assuming that the problem building the disk image is a
> Hydra-specific problem.  Do you have reason to believe so?  I would
> guess that these bugs are in the disk image builder.

Probably!

According to the progress bar it's missing an additional 40% ?  That's... large.

I've increased the size for the time being, but according to the logs
it was at 800 MiB in 2015.


pgpgEFx__y_kh.pgp
Description: OpenPGP digital signature


Re: GuixSD on eoma68-a20?

2018-12-08 Thread Mark H Weaver
Hi Danny,

Danny Milosavljevic  writes:

> On Sat, 8 Dec 2018 17:39:01 +0100
> swedebugia  wrote:
>
>> Could we pre-order some of these owned by the foundation to
>> be used to to hack on this?
>> 
>> See https://www.crowdsupply.com/eoma68/micro-desktop
>
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done (for
> example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> Note: The latter thing counts as "successful" build.  WTF?).

This sounds like two distinct bugs:

* Regarding the lack of disk space: if I'm not mistaken, as things are
  currently implemented, we must specify the size of the disk image
  manually.  I guess we need to increase the size.

* This error that occurs within QEMU is apparently not being propagated
  to the outer build script.  That should be fixed.

> I'm now setting up my own build server and trying to get the flash image
> that way - which is ridiculous.

You seem to be assuming that the problem building the disk image is a
Hydra-specific problem.  Do you have reason to believe so?  I would
guess that these bugs are in the disk image builder.

What do you think?

Regards,
  Mark



Re: GuixSD on eoma68-a20?

2018-12-08 Thread Danny Milosavljevic
Hi swedebugia,

On Sat, 8 Dec 2018 17:39:01 +0100
swedebugia  wrote:

> Could we pre-order some of these owned by the foundation to
> be used to to hack on this?
> 
> See https://www.crowdsupply.com/eoma68/micro-desktop

Guix received one but we have so far be unable to get the GuixSD flash
image because something always breaks on Hydra before it's done (for
example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
Note: The latter thing counts as "successful" build.  WTF?).

I have the device here in my hand (I tested it using u-boot only - works fine).

I'm now setting up my own build server and trying to get the flash image
that way - which is ridiculous.

Also, be aware that the Allwinner A20 is really really slow.  There are
ARM computers worth using as a normal PC, but this one isn't.  I tried.

(For example the Allwinner R40 is quite okay to use as a PC - see
Sinovoip Banana Pi M2 Ultra)

I like the concept of easily upgradeable computers, though!


pgpG0Sm5ciLWY.pgp
Description: OpenPGP digital signature