Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-23 06:09, swedebu...@riseup.net wrote:
> On 2018-12-22 09:44, Danny Milosavljevic wrote:
>> Please add to your /etc/config.scm to the "services" section:
>>
>> (service qemu-binfmt-service-type
>>  (qemu-binfmt-configuration
>>(platforms (lookup-qemu-platforms "arm"))
>>(guix-support? #t)))
> 
> Thanks.
> 
> Added, reconfigured and now it is building away happily. Will report
> back how it goes...

It took a long long time to compile python2.7 and failed a 1 test in the
end.

356 tests OK.
1 test failed:
test_mmap
39 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
test_dl test_gdb test_gl test_imgfile test_ioctl test_kqueue
test_linuxaudiodev test_macos test_macostools test_msilib test_nis
test_ossaudiodev test_scriptpackages test_smtpnet
test_socketserver test_startfile test_sunaudiodev test_timeout
test_tk test_ttk_guionly test_urllib2net test_urllibnet
test_winreg test_winsound test_zipfile64
4 skips unexpected on linux2:
test_bsddb test_bsddb3 test_gdb test_ioctl

Total duration: 55 min 1 sec
Tests result: FAILURE
make: *** [Makefile:878: test] Error 2

Test suite failed, dumping logs.
Backtrace:
   4 (primitive-load "/gnu/store/dbh5r09sm7hw8jjmxvgmjks9h2q…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
   863:16  2 (every1 # …)
In
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:
   799:28  1 (_ _)
369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)

/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/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed
with exit code 1
build of /gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
failed
View build log at
'/var/log/guix/drvs/c9/d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv.bz2'.
guix system: error: build failed: build of
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed

-
fail details:

0:27:38 load avg: 1.19 [216/396] test_mmap
test test_mmap failed -- Traceback (most recent call last):
  File
"/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15/Lib/test/test_mmap.py",
line 696, in test_large_offset
self.assertEqual(m[0xFFF], b" ")
AssertionError: '\x00' != ' '

0:27:40 load avg: 1.18 [217/396/1] test_module -- test_mmap failed

I'm on i386.
Will try again when I succeded in disabling the test.
-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:44, Danny Milosavljevic wrote:
> Please add to your /etc/config.scm to the "services" section:
> 
> (service qemu-binfmt-service-type
>  (qemu-binfmt-configuration
>(platforms (lookup-qemu-platforms "arm"))
>(guix-support? #t)))

Thanks.

Added, reconfigured and now it is building away happily. Will report
back how it goes...

-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Did you reconfigure?

# guix system reconfigure /etc/config.scm

If so, that's weird.

>I'm on x86_64 hardware running a i686 guix

Yeah, "--system" is using qemu to emulate the target architecture and the build
job then runs in there.


pgpFwnBuOYzyx.pgp
Description: OpenPGP digital signature

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:33, swedebu...@riseup.net wrote:
> On 2018-12-22 00:09, Danny Milosavljevic wrote:
>> Now I get:
>>
>> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
>> $ ./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)' >QQQ3 2>&1
>> [...]
>> The following derivation will be built:
>>/gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
>> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
>> environment variable `PATH' set to
>> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
>> creating raw image of 1265.54 MiB...
>> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
>> fmt=raw size=1327019190
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
>> (GCC)) #1 SMP 1
>> [0.00] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), 
>> cr=10c5387d
>> [0.00] CPU: div instructions available: patching division code
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction 
>> cache
>> [0.00] OF: fdt: Machine model: linux,dummy-virt
>> [0.00] Memory policy: Data cache writealloc
>> [0.00] efi: Getting EFI parameters from FDT:
>> [0.00] efi: UEFI not found.
>> [0.00] cma: Reserved 16 MiB at 0x4f00
>> [0.00] psci: probing for conduit method from DT.
>> [0.00] psci: PSCIv0.2 detected in firmware.
>> [0.00] psci: Using standard PSCI v0.2 function IDs
>> [0.00] psci: Trusted OS migration not required
>> [0.00] random: get_random_bytes called from
>> start_kernel+0xa0/0x50c with crng_init=0
>> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
>> d22708 u69632
>> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 64960
>> [0.00] Kernel command line: panic=1
>> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
>> console=ttyAMA0
>> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 
>> bytes)
>> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> [0.00] Memory: 214952K/262144K available (9216K kernel code,
>> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
>> 16384K cma-reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> [0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
>> [0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>> [0.00]   .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
>> [0.00]   .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
>> [0.00]   .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
>> [0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
>> [0.00] ftrace: allocating 33359 entries in 98 pages
>> [0.00] rcu: Hierarchical RCU implementation.
>> [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
>> [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> [0.00] GICv2m: range[mem 0x0802-0x08020fff], SPI[80:143]
>> [0.00] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
>> [0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
>> [0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
>> every 4398046511096ns
>> [0.006045] Switching to timer-based delay loop, resolution 16ns
>> [0.308537] Console: colour dummy device 80x30
>> [0.36] Calibrating delay loop (skipped), value calculated
>> using timer frequency.. 125.00 BogoMIPS (lpj=25)
>> [0.373670] pid_max: default: 32768 minimum: 301
>> [0.426475] Security Framework initialized
>> [0.431096] Yama: becoming mindful.
>> [0.506448] AppArmor: AppArmor initialized
>> [0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
>> bytes)
>> [0.965208] CPU: Testing write buffer coherency: ok
>> [0.998104] CPU0: Spectre v2: firmware did not set auxiliary
>> control register IBE bit, system vulnerable
>> [1.411470] /cpus/cpu@0 missing clock-frequency property
>> [1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
>> [1.698318] S

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Please add to your /etc/config.scm to the "services" section:

(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm"))
   (guix-support? #t)))


pgpNYpbaqnEr8.pgp
Description: OpenPGP digital signature

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 00:09, Danny Milosavljevic wrote:
> Now I get:
> 
> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
> $ ./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)' >QQQ3 2>&1
> [...]
> The following derivation will be built:
>/gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
> environment variable `PATH' set to
> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
> creating raw image of 1265.54 MiB...
> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
> fmt=raw size=1327019190
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
> (GCC)) #1 SMP 1
> [0.00] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> [0.00] OF: fdt: Machine model: linux,dummy-virt
> [0.00] Memory policy: Data cache writealloc
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
> [0.00] cma: Reserved 16 MiB at 0x4f00
> [0.00] psci: probing for conduit method from DT.
> [0.00] psci: PSCIv0.2 detected in firmware.
> [0.00] psci: Using standard PSCI v0.2 function IDs
> [0.00] psci: Trusted OS migration not required
> [0.00] random: get_random_bytes called from
> start_kernel+0xa0/0x50c with crng_init=0
> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
> d22708 u69632
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 64960
> [0.00] Kernel command line: panic=1
> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
> console=ttyAMA0
> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [0.00] Memory: 214952K/262144K available (9216K kernel code,
> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
> 16384K cma-reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
> [0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
> [0.00]   .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
> [0.00]   .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
> [0.00]   .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
> [0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
> [0.00] ftrace: allocating 33359 entries in 98 pages
> [0.00] rcu: Hierarchical RCU implementation.
> [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
> [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [0.00] GICv2m: range[mem 0x0802-0x08020fff], SPI[80:143]
> [0.00] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> [0.00] clocksource: arch_sys_counter: mask: 0xff
> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> [0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
> every 4398046511096ns
> [0.006045] Switching to timer-based delay loop, resolution 16ns
> [0.308537] Console: colour dummy device 80x30
> [0.36] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 125.00 BogoMIPS (lpj=25)
> [0.373670] pid_max: default: 32768 minimum: 301
> [0.426475] Security Framework initialized
> [0.431096] Yama: becoming mindful.
> [0.506448] AppArmor: AppArmor initialized
> [0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
> bytes)
> [0.965208] CPU: Testing write buffer coherency: ok
> [0.998104] CPU0: Spectre v2: firmware did not set auxiliary
> control register IBE bit, system vulnerable
> [1.411470] /cpus/cpu@0 missing clock-frequency property
> [1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [1.698318] Setting up static identity map for 0x4010 - 0x401000a0
> [1.748454] rcu: Hierarchical SRCU implementation.
> [1.926086] EFI services wil

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Now I get:

$ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
$ ./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)' >QQQ3 
2>&1
[...]
The following derivation will be built:
   /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
environment variable `PATH' set to 
`/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
creating raw image of 1265.54 MiB...
Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image', fmt=raw 
size=1327019190
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0 (GCC)) #1 
SMP 1
[0.00] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt: Machine model: linux,dummy-virt
[0.00] Memory policy: Data cache writealloc
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 16 MiB at 0x4f00
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv0.2 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: Trusted OS migration not required
[0.00] random: get_random_bytes called from start_kernel+0xa0/0x50c 
with crng_init=0
[0.00] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192 d22708 
u69632
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 64960
[0.00] Kernel command line: panic=1 
--load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader 
console=ttyAMA0
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 214952K/262144K available (9216K kernel code, 1133K 
rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved, 16384K 
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
[0.00] ftrace: allocating 33359 entries in 98 pages
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] GICv2m: range[mem 0x0802-0x08020fff], SPI[80:143]
[0.00] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
[0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 
4398046511096ns
[0.006045] Switching to timer-based delay loop, resolution 16ns
[0.308537] Console: colour dummy device 80x30
[0.36] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 125.00 BogoMIPS (lpj=25)
[0.373670] pid_max: default: 32768 minimum: 301
[0.426475] Security Framework initialized
[0.431096] Yama: becoming mindful.
[0.506448] AppArmor: AppArmor initialized
[0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.965208] CPU: Testing write buffer coherency: ok
[0.998104] CPU0: Spectre v2: firmware did not set auxiliary control 
register IBE bit, system vulnerable
[1.411470] /cpus/cpu@0 missing clock-frequency property
[1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[1.698318] Setting up static identity map for 0x4010 - 0x401000a0
[1.748454] rcu: Hierarchical SRCU implementation.
[1.926086] EFI services will not be available.
[1.993192] smp: Bringing up secondary CPUs ...
[1.994874] smp: Brought up 1 node, 1 CPU
[1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
[1.998883] CP

Re: GuixSD on eoma68-a20?

[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?

[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: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Sat, Dec 15, 2018 at 02:04:58PM -0500, Mark H Weaver wrote:
> >> See also 
> >> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
> > It was, and I disabled it. Hopefully this does not break anything...
> Why did you disable it?

Because we get exactly these spurious ENOSPC mentioned in the blog post
on bayfront when the disk is only one third full.

Now I am happy to try out any other combination of flags that solves the
problem.

So should I add dir_index again (is this possible live?), and then
add large_dir?

Andreas

Re: GuixSD on eoma68-a20?

[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: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Andreas,

On Sat, 15 Dec 2018 11:29:06 +0100
Andreas Enge  wrote:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> > can you check whether dirindex (hashtables for directory) is enabled?
> > # tune2fs -l /dev/... | grep -o dir_index
> > See also 
> > https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html  
> 
> It was, and I disabled it. Hopefully this does not break anything...
> But does this not mean a big performance hit on /gnu/store/.links?

It does mean that because it uses a linear search to find the file names now.

What ext filesystem is it?

https://en.wikipedia.org/wiki/Ext4 says that ext4 supports B trees - which
should have no problems with hash collisions (it uses operator< to construct
a tree -- and not hashes to construct a list).


pgppoffvtH3X2.pgp
Description: OpenPGP digital signature

Re: bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Andreas,

Andreas Enge  writes:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
>> can you check whether dirindex (hashtables for directory) is enabled?
>> # tune2fs -l /dev/... | grep -o dir_index
>> See also 
>> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
>
> It was, and I disabled it. Hopefully this does not break anything...

Why did you disable it?

> But does this not mean a big performance hit on /gnu/store/.links?

I would expect disabling dir_index to be a big performance hit on Guix
systems, and especially those with a large store, such a build farm
master nodes.

  Mark

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> can you check whether dirindex (hashtables for directory) is enabled?
> # tune2fs -l /dev/... | grep -o dir_index
> See also 
> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

It was, and I disabled it. Hopefully this does not break anything...
But does this not mean a big performance hit on /gnu/store/.links?

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Andreas,

can you check whether dirindex (hashtables for directory) is enabled?

# tune2fs -l /dev/... | grep -o dir_index

See also 
https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html


pgp6PbcZAEg70.pgp
Description: OpenPGP digital signature

Re: GuixSD on eoma68-a20?

[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?

[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?

[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: bug#33676: GuixSD on eoma68-a20?

[Efraim Flashner]

On Sun, Dec 09, 2018 at 04:32:00PM -0500, Mark H Weaver wrote:
> 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

time for a crontab hack job?

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Mon, Dec 10, 2018 at 11:30:14AM +0100, Danny Milosavljevic wrote:
> I've tried it now and I get:
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image 
> --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device

this is the mysterious error message we have seen before: There is still
plenty of space on all the machines! I think it was related to an ext4
limitation on the number of files, or the number of files inside a single
directory. I ran some garbage collection on bayfront, and it can now offload
and retrieve builds again. Please give it another try!

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Andreas,

I've tried it now and I get:

dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image 
--system=armhf-linux gnu/system/install.scm
...
importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
ootstrap-0'...
found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
tstrap-0'
guix offload: error: link: No space left on device
cannot build derivation `/gnu/store/mdc6h56cg0a8i09rh0zbw5kgipwlnvln-binutils-cr
oss-boot0-2.31.1.drv': 1 dependencies couldn't be built


pgpJu1twe2HtF.pgp
Description: OpenPGP digital signature

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Sat, Dec 08, 2018 at 06:12:14PM +0100, Danny Milosavljevic wrote:
> 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

although the problem seems to lie somewhere else, I would just like to
point out that you can use your account on bayfront to build things for
arm as well - it offloads to the redhill machine. Notice, however, that
this is a single machine building everything from source without using
the hydra or berlin build farms for substitutes.

I can also give you a direct login on redhill if you need it.

Andreas

Re: GuixSD on eoma68-a20?

[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?

[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?

[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: bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> On Sat, 08 Dec 2018 18:34:04 +0100
> Ricardo Wurmus  wrote:
>
>> > 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?).  
>> 
>> Is this now better with ci.guix.info (berlin.guixsd.org)?
>
> No idea.  How to I get the flash-image using ci.guix.info ?
>
> I tried "guix system disk-image --system=armhf-linux gnu/system/install.scm" 
> but
> that builds a lot of stuff from source.  Let's see whether it will be done 
> before
> the sun exploded :)

I’d suggest trying again, and possibly retrying a bit later so that
substitutes have had a chance to be “baked”.

hydra.gnu.org and now ci.guix.info both provide armhf-linux substitutes.
They have much less armv7 CPU power than x86 but still, it shouldn’t be
that bad.

Ludo’.

Re: GuixSD on eoma68-a20?

[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: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Ricardo,

On Sat, 08 Dec 2018 18:34:04 +0100
Ricardo Wurmus  wrote:

> > 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?).  
> 
> Is this now better with ci.guix.info (berlin.guixsd.org)?

No idea.  How to I get the flash-image using ci.guix.info ?

I tried "guix system disk-image --system=armhf-linux gnu/system/install.scm" but
that builds a lot of stuff from source.  Let's see whether it will be done 
before
the sun exploded :)

> > I have the device here in my hand (I tested it using u-boot only - works 
> > fine).  
> 
> Oh, so it works out of the box with GuixSD already?

As I said, I've tested it with u-boot only so far.


pgpNorLwX6iCV.pgp
Description: OpenPGP digital signature

Re: bug#33676: GuixSD on eoma68-a20?

[Ricardo Wurmus]

Hi Danny,

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

Is this now better with ci.guix.info (berlin.guixsd.org)?

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

Oh, so it works out of the box with GuixSD already?

-- 
Ricardo

Re: GuixSD on eoma68-a20?

[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

GuixSD on eoma68-a20?

[swedebugia]

Hi

I would like to know if there is any interest in this?

It seems to be well on the way to deliver as promised (though the time 
schedule has been updated a couple of times ;-) )


https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like

Cost 65$
Est. shipping jan 2019.

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

--
Cheers
Swedebugia