bug#36551: [META] Run Guix System on Purism Librem 5

[Jonathan Brielmaier]

Eric already worked on Anbox:
https://notabug.org/bavier/guix-bavier/src/master/bavier/packages/android.scm
It still needs some work to get upstream.

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> I'd like to test what happens if one builds json-c on an aarch64 host
> for i686.
>
> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
the whole binfmt_misc shebang.

HTH,
Ludo’.

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

[Danny Milosavljevic]

Hi Ludo,

On Tue, 29 Sep 2020 12:25:54 +0200
Ludovic Courtès  wrote:

> > I'd like to test what happens if one builds json-c on an aarch64 host
> > for i686.
> >
> > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?  
> 
> I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
> the whole binfmt_misc shebang.

Sure, but I want to know what happens to json-c.  That sounds like a lot of
manual invocations (like about 2--for invocations of "configure", "gcc",
including all the dependencies etcetc).

Andreas Enge already tried to configure dover.guix.info to uses qemu-binfmt
to emulate i686-linux, but apparently it doesn't work (on dover.guix.info):

building /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv...
\builder for 
`/gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv' failed 
with exit code 1
build of /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv 
failed
View build log at 
'/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2'.

bash-5.0$ bzless 
/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2
--> 
/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2
 <--
while setting up the build environment: executing 
`/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory


pgpd4odgjrmPX.pgp
Description: OpenPGP digital signature

bug#43685: xonotic player ID and stats reporting are broken

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hullo bdju,

bdju via Bug reports for GNU Guix 写道：
This isn't working. I asked in the #xonotic IRC and it sounds 
like this
sometimes happens from a certain file being left out of distro 
packages.

"it tends to happen when using linux distro packages that omit
key_0.d0pk" is the exact quote.


We don't omit the file.  It's in the root of the upstream 
xonotic-0.8.2.zip & is copied to /share/xonotic 
which is then symlinked to /share/xonotic:


 λ ls $(guix build xonotic)/share/xonotic
 data/  key_0.d0pk  server/

Perhaps the engine has trouble finding it, or perhaps it's not the 
reason for your missing stats after all.


I'm downloading the (gig of) sources to take a closer look on the 
bus.


This stats reporting does not seem like a privacy concern, and 
it's

optional, so I doubt it was broken on purpose.


Certainly not!

Thanks,

T G-R


signature.asc
Description: PGP signature

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

[Danny Milosavljevic]

On Tue, 29 Sep 2020 12:43:08 +0200
Danny Milosavljevic  wrote:

> /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash

Also, this file exists, and is for i686, and if I invoke it using

  /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash -c "echo foo"

then it works (which means the qemu transparent emulation picks it us).


pgpgTrjzbXhbu.pgp
Description: OpenPGP digital signature

bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> Jan Nieuwenhuizen  skribis:
>
>>> Ludovic Courtès  skribis:
>>>
>> Displaying notes found in: .note.ABI-tag
>>   OwnerData size Description
>>   GNU  0x0010NT_GNU_ABI_TAG (ABI version tag)
>> OS: Hurd, ABI: 0.0.0
>
> Oh, well done, I browsed ‘file’ but didn’t find it.

:-)

>>> So I think we can’t count on an ‘execve’ error and thus have to treat
>>> this case (same architecture but different OS kernel) specially, as
>>> shown below.
>>>
>>> Thoughts?
>>
>> If that really doesn't work...then yeah (yuck ;-)
>
> Yeah, I think we’ll have to do this hack (we’re not going to parse ELF
> files and all to determine whether to call ‘execve’.)

Ah, we're C++; I was thinking Guile and "we surely have" an ELF library.
That's allright then.  Let's have this workaround.

> (Besides, it would be interesting to understand how the libc/Hurd
> startup code ends up segfaulting on GNU/Linux.)

Hmm...are you saying something like "it could run until it wants to RCP
Mach or Hurd?"  Might it "just load" shared libraries...

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#38414: Bug not relevant anymore.

[Brendan Tildesley]

I'm trying to run guix pull after 4  months. This is guix on Arch.


Is this bug report  still relevant? It looks like you have binarysubstitutes disabled, is 

that on purpose?

They were never intentionally disabled. not sure what happened since i 
hadn't touched it in ages.


Closing since I haven't experienced this since. it wont be pursued.

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[Maxim Cournoyer]

Hello!

Giovanni Biscuolo  writes:

> Hello Maxim,
>
> thank you for your help
>
> Maxim Cournoyer  writes:
>
> [...]
>
>> I tried to reproduce this using the following environment:
>>
>> --8<---cut here---start->8---
>> guix environment --pure --ad-hoc emacs emacs-elfeed
>> --8<---cut here---end--->8---
>>
>> Then launching emacs with 'emacs -q', and running elfeed with M-x
>> elfeed, and couldn't reproduce the problem.
>
> The problem is with emacs-elfeed-org, not emacs-elfeed :-)

Ah!  I need glasses :-)

Retrying with emacs-elfeed-org, I also can't reproduce:

--8<---cut here---start->8---
$ guix environment --pure --ad-hoc emacs emacs-elfeed-org -- emacs --batch 
--eval='(elfeed)'
Loading 
/gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/dash-autoloads...
Loading 
/gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/elfeed-autoloads...
Loading 
/gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/elfeed-org-autoloads...
Loading 
/gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/org-autoloads...
Loading 
/gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/s-autoloads...
--8<---cut here---end--->8---

Can you try to reproduce it again?  Perhaps there's some other Emacs
package in your profile which somehow conflicts with it?

Thanks,

Maxim

bug#43564: cuirass: Contention while registering new builds.

[Mathieu Othacehe]

Hello,

> In the best case of one pending evaluation, the registration duration is
> reduced from 1800 seconds to 320 seconds. I think that the gain is way
> larger when there are multiple pending evaluations.
>
> Pushed a fix as 461e07e14e1c8013343c0a2cb26c0e022e10d5e4.

While this improves the situation, another evaluation contention episode
occurred this afternoon (evaluations 16920 to 16938).

Even though reading queries are cheaper, I guess that when 10 fibers try
to execute 50k read queries, there's some contention in the
communication with the 4 database workers.

I'm trying locally to spawn database workers dedicated to registration,
that execute the evaluation queries in a single batch. Let's see if it
helps.

Thanks,

Mathieu

bug#43518: Guix substitute crash in procedure raise-exception: wrong type agument in position 1: #f

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

[...]

> 0.0 
> http://127.0.0.1:8080/nar/gzip/954b3kw59mdvanp33yx93q5pzzll4wg9-qemu-5.0.0 - 
> 29605888
>  qemu-5.0.0   
> 1.6MiB/s 00:26 | 41.8MiB transferredBacktrace:
> In ice-9/boot-9.scm:
>   1731:15 19 (with-exception-handler # ice-9/boot-9.scm:1815:7 (exn)> _ # _ # …)
> In guix/scripts/package.scm:
>966:10 18 (_)
> In guix/status.scm:
> 776:4 17 (call-with-status-report _ _)
> In guix/store.scm:
>1300:8 16 (call-with-build-handler _ _)
>1300:8 15 (call-with-build-handler # guix/ui.scm:1166:2 (continue store …> …)
> In guix/scripts/package.scm:
> 889:2 14 (_)
> In guix/build/syscalls.scm:
>1167:4 13 (call-with-file-lock/no-wait _ _ _)
> In guix/scripts/package.scm:
>143:19 12 (build-and-use-profile # 
> "/var/guix/profiles/per-u…" …)
> In guix/store.scm:
>   2042:24 11 (run-with-store # _ 
> #:guile-for-build _ #:system _ # …)
> In guix/profiles.scm:
>1586:2 10 (_ _)
> 348:2  9 (_ _)
> In guix/store.scm:
>   1924:12  8 (_ #)
>1357:5  7 (map/accumulate-builds # _ 
> _)
>   1368:15  6 (_ # _ _)
>740:13  5 (process-stderr _ _)
> In unknown file:
>4 (display "@ substituter-succeeded 
> /gnu/store/277yzwcx6fshsxlqnwvyv94q66miv3ii-diffoscope…" …)
> In guix/status.scm:
>699:16  3 (write! _ _ _)
> 613:6  2 (_ (download-progress 
> "/gnu/store/954b3kw59mdvanp33yx93q5pzzll4wg9-qemu-5.0.0" "http:…" …) …)
> In guix/progress.scm:
>213:14  1 (display-download-progress "qem@" _ #:start-time _ #:transferred 
> _ #:log-port _)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure =: Wrong type argument in position 1: #f

Here's a second instance of that problem, that I could get just now,
from Guix commit d48b17adb91d68acf6fb3f321c05102fcc8c39eb:

--8<---cut here---start->8---
guix environment --system=armhf-linux --ad-hoc gcc-toolchain
substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
0.4 MB will be downloaded
downloading from 
https://ci.guix.gnu.org/nar/lzip/jf2x64p5z1ykg4px2plh0v5a7r20pc50-glibc-utf8-locales-2.31
 ...
 glibc-utf8-locales-2.31  376KiB683KiB/s 00:01 
[##] 100.0%

substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/2iswjr97v4kfpb8q0jwzjwwjm9rvcq1q-profile.drv
   /gnu/store/anx317lak54y5lg3hw8i8fn5hy485ayx-gcc-toolchain-10.2.0.drv
   /gnu/store/6vqbb2jks246cjbqclxaq6x1j4zcvvg1-gcc-10.2.0.drv
   /gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv

10 items will be downloaded
building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
process 18399 acquired build slot '/var/guix/offload/127.0.0.1:/1'
load on machine '127.0.0.1' is 0.78 (normalized: 0.39)
building 
/gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv...
The following builds are still in progress:
  /gnu/store/dzchr45vhqwa538skm6h5mjqb73ly01i-manual-database.drv
  /gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv
  /gnu/store/s12hk0x8khglmqky7035a904ryjf4hbd-info-dir.drv
  /gnu/store/zafx1kh4jnycqxhy2kfm6jajq3dgp3cm-fonts-dir.drv

The following builds are still in progress:
  /gnu/store/dzchr45vhqwa538skm6h5mjqb73ly01i-manual-database.drv
  /gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv
  /gnu/store/s12hk0x8khglmqky7035a904ryjf4hbd-info-dir.drv

The following builds are still in progress:
  /gnu/store/dzchr45vhqwa538skm6h5mjqb73ly01i-manual-database.drv
  /gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv

The following build is still in progress:
  /gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv

|offloading build of 
/gnu/store/ih15jlds75wh246dnb6s9sixqz93mqrp-module-import-compiled.drv to 
'127.0.0.1'
downloading from 
https://ci.guix.gnu.org/nar/lzip/1nr37qqaqmcn3dbrjg5z7r0mfkaaf2aq-glibc-bootstrap-0
 ...
downloading from 
https://ci.guix.gnu.org/nar/lzip/idr9bk61lar8i6fqpmkvpg8ph5wdbapr-isl-0.22.1 ...
downloading from 
https://ci.guix.gnu.org/nar/lzip/dnikscj9hksx4g4fs4qd2ynj1rzv6fz9-libelf-0.8.13 
...
downloading from 
https://ci.guix.gnu.org/nar/6m9zimmw8p6gbc1yfbg454c1r587b7h4-gcc-10.2.0.tar.xz 
...
|

substitution of /gnu/store/dnikscj9hksx4g4fs4qd2ynj1rzv6fz9-libelf-0.8.13 
complete
 80% 
[###
]

substitution of /g

bug#43529: Guix Interactive Installer Broken

[zimoun]

Dear,

Thank you for the feedback.

On Sun, 20 Sep 2020 at 16:51, Yasuaki Kudo  wrote:

> Is there a bug tracker ID already assigned for this?

Do you hit the bug using the last image [1]?

[1] 



All the best,
simon

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[Giovanni Biscuolo]

Hello Maxim,

Maxim Cournoyer  writes:

[...]

>> The problem is with emacs-elfeed-org, not emacs-elfeed :-)
>
> Ah!  I need glasses :-)

:D

> Retrying with emacs-elfeed-org, I also can't reproduce:
>
> --8<---cut here---start->8---
> $ guix environment --pure --ad-hoc emacs emacs-elfeed-org -- emacs --batch 
> --eval='(elfeed)

[...]

> Can you try to reproduce it again?

OK I did this:

--8<---cut here---start->8---

$ guix environment --pure --ad-hoc emacs emacs-elfeed-org curl
$ emacs

--8<---cut here---end--->8---

In this environment then I "manually" set up elfeed-org in my *scratch*
buffer copying relevant parts from init.el: it worked, I was able to
start elfeed and update my feeds from my elfeed.org file

> Perhaps there's some other Emacs package in your profile which somehow
> conflicts with it?

After the test above I updated my emacs profile and started emacs
daemon, now I'm on emacs 27.1 and, again, if I try to start elfeed I
get:

--8<---cut here---start->8---

File mode specification error: (void-function 
org--check-org-structure-template-alist) [2 times]
Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
mapc: Symbol’s function definition is void: 
org--check-org-structure-template-alist

--8<---cut here---end--->8---

Tomorrow I'll try to catch what's the conflicting package, now I'm using
this manifest:



emacs-guix.scm
Description: Binary data

Thank you for your help!

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#43710: missing debug symbols for dino dependencies

[bdju]

It seems just the debug symbols for dino weren't quite enough to get
good info. I also need debug symbols for the other dependencies. For
sure glib or libglib, whichever it is. If there are other dependencies
that could have debug output enabled, that would probably be helpful as
well.

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[zimoun]

Hi,

On Tue, 29 Sep 2020 at 20:12, Giovanni Biscuolo  wrote:

> File mode specification error: (void-function 
> org--check-org-structure-template-alist) [2 times]
> Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
> mapc: Symbol’s function definition is void:
> org--check-org-structure-template-alist

Hum?  What is your ’~/.emacs.d/init.el’&co.?  The issue seems the
loading order.  It could happen with lazy eval &co.  Well, this ’alist’
is from ’org.el’, so it appears to me a bit weird.


> Tomorrow I'll try to catch what's the conflicting package, now I'm using
> this manifest:

I have noticed that you use ’ghc-pandoc’.  Except if you require
“pandoc” as an Haskell library for linking, what you want is probably
the package ’pandoc’ (introduced by e380ef14cf).


All the best,
simon

bug#43685: xonotic player ID and stats reporting are broken

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
I'm downloading the (gig of) sources to take a closer look on 
the bus.


Unfortunately no progress was made there, as Xonotic consistently 
failed to start at all.  I got the Cool Earth background, but no 
main menu.  Had to kill it -9.  Once I got off and connected to 
wi-fi, Xonotic started fine.


I'll report it as a separate issue if it happens again, but 
turning off wi-fi and removing ~/.xonotic did not allow me to 
reproduce it.


Weird.

T G-R


signature.asc
Description: PGP signature