Re: gnunet-guile reboot & guix

[Amirouche Boubekki]

On 2018-01-13 01:49, ng0 wrote:

Amirouche Boubekki transcribed 1.5K bytes:

Héllo all,

I restarted from scratch the gnunet-guile bindings. It was made
much easier thanks to the work of ng0 on gnunet documentation and
guile-bytestructures to handle C structs and unions.


...


I think I need to know what's the plan/design for gnunet/guix
integration to continue.


If you want a (relative) unprocessed summary of its history, it's
collected in here
(org-mode recommended):
https://gnunet.org/git/infotropique-artwork.git/tree/doc/guix-past-notes.txt


Here is an extract relevant to the current discussion:

* Design of guix/gnunet integration


So I can see two milestones now, as we discussed before:



1. Create a variant of ‘guix publish’ that publishes over GNUnet’s
file sharing (FS) service, using the neat bindings that you wrote.



For that you can literally copy guix/scripts/publish.scm as a
starting point, and simply remove the HTTP-related code (which is a
small fraction.)  The rest will be mostly identical: narinfo
meta-data generation, signing.  I guess it will be easy to test it
using gnunet-search and similar tools.



As a 2nd step, we’ll see how we can refactor things to allow code
sharing between the existing ‘guix publish’ and its GNUnet variant.



2. Create a variant of ‘guix substitute’ for searches through GNUnet.
Again, a large part of the code is about narinfo and signature
checking, and it can be reused.



I’m not completely clear on how search for substitutes will work,
though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
substitute’ simply fetches http://hydra.gnu.org/xyz.narinfo.  How will
that work with GNUnet?  Are we going to look up their /gnu/store file
name?




I’m not completely clear on how search for substitutes will work,
though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
substitute’ simply fetches http://hydra.gnu.org/xyz.narinfo.  How will
that work with GNUnet?  Are we going to look up their /gnu/store file
name?



I’ve considered a solution for that: GNUnet allows one to create
specific namespace and publish files under this namespace. Unlike
publishing under the “global namespace” where keywords are used to
identify a file, when publishing under a specific namespace files are
identified with a choosen identifier. Moreover, as a namespace is
basically a cryptographic key pair, and publishing a file under your
namespace means signing, one’s assured nobody else will publish under
her or his namespace. By the way, the private key associated with a
namespace is named “ego” or “pseudonym”.



It’s easy to test this feature:



# create a `test` ego/namespace
$ gnunet-identity -C test



# list the known egos in the form: `name - public key`
$ gnunet-identity -d
test - M2OC987U9LFJHQ8LC9SLCV4Q0ONHJV7FMTFQ2VRPE0M9R9MK5860
…



# index the file `foo.txt` under the `test` namespace
$ gnunet-publish -P test -t foobarbaz foo.txt



# find the file `foo.txt`
$ gnunet-search gnunet://fs/sks/M2OC987U9LFJHQ8LC9SLCV4…/foobarbaz
#0:
gnunet-download -o "foo.txt" gnunet://fs/chk/PL217ODD8EDSMOIQ3UT0…



Now if Alice wants to publish her binaries, she creates an
ego/namespace and publishes everything under it; Bob adds her
namespace’s public key to his authorized substitutes list, and when
installing `/gnu/store/xyz` the substitute will search for
`gnunet://fs/sks//xyz`.



Instead of publishing an archive we might also directly publish/index
the build, but I don’t know if it’s viable.



Does it seem right to you?


* Another discusion about guix integration


Instead of using ‘file-system-tree’, this variant should probably use
‘live-paths’ from (guix store), which returns the list of live store
items.



Well, `file-system-tree` is only used to recursively index a random
directory’s content (in our case, a single store item). It looked 
viable

for publishing a single store item, but won’t be good for indexing at
once the entire set of live paths; I should ask the GNUnet team how to
properly index such a huge amount of directories.



On my machine, running `live-paths` takes ~2 seconds, but the
publication of the entire store will probably take much longer anyway.



BTW, I noticed there’s quite a bunch of global variables that are
‘set!’.  It would be better to avoid that, but I suppose the
continuation-passing style that the GNUnet libraries impose makes it
difficult.



Hopefully, using the “closure” parameters of the GNUnet API in the
bindings should reduce the need for global variables, and improve
elegance of end-user programs.




Nitpick: it’s a bit annoying that we have to specify a GNUnet
configuration file.


Yes, GNUnet programs usually look for `~/.config/gnunet.conf`, and
`publish-gnunet` does the same. Now, maybe `publish-gnunet` could
somehow obtain the config file used by `gnunet-arm`?



No, it would need the config file to figure out how to talk to
gnunet-service-arm (or any other service). And we do support running
many ins

Re: gnunet-guile reboot & guix

[ng0]

Amirouche Boubekki transcribed 6.3K bytes:
> On 2018-01-13 01:49, ng0 wrote:
> > Amirouche Boubekki transcribed 1.5K bytes:
> > > Héllo all,
> > > 
> > > I restarted from scratch the gnunet-guile bindings. It was made
> > > much easier thanks to the work of ng0 on gnunet documentation and
> > > guile-bytestructures to handle C structs and unions.
> 
> ...
> 
> > > I think I need to know what's the plan/design for gnunet/guix
> > > integration to continue.
> > 
> > If you want a (relative) unprocessed summary of its history, it's
> > collected in here
> > (org-mode recommended):
> > https://gnunet.org/git/infotropique-artwork.git/tree/doc/guix-past-notes.txt
> 
> Here is an extract relevant to the current discussion:
> 
> * Design of guix/gnunet integration
> 
> > > So I can see two milestones now, as we discussed before:
> 
> > > 1. Create a variant of ‘guix publish’ that publishes over GNUnet’s
> > > file sharing (FS) service, using the neat bindings that you wrote.
> 
> > > For that you can literally copy guix/scripts/publish.scm as a
> > > starting point, and simply remove the HTTP-related code (which is a
> > > small fraction.)  The rest will be mostly identical: narinfo
> > > meta-data generation, signing.  I guess it will be easy to test it
> > > using gnunet-search and similar tools.
> 
> > > As a 2nd step, we’ll see how we can refactor things to allow code
> > > sharing between the existing ‘guix publish’ and its GNUnet variant.
> 
> > > 2. Create a variant of ‘guix substitute’ for searches through GNUnet.
> > > Again, a large part of the code is about narinfo and signature
> > > checking, and it can be reused.
> 
> > > I’m not completely clear on how search for substitutes will work,
> > > though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
> > > substitute’ simply fetches http://hydra.gnu.org/xyz.narinfo.  How will
> > > that work with GNUnet?  Are we going to look up their /gnu/store file
> > > name?
> 
> 
> > > I’m not completely clear on how search for substitutes will work,
> > > though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
> > > substitute’ simply fetches http://hydra.gnu.org/xyz.narinfo.  How will
> > > that work with GNUnet?  Are we going to look up their /gnu/store file
> > > name?
> 
> > I’ve considered a solution for that: GNUnet allows one to create
> > specific namespace and publish files under this namespace. Unlike
> > publishing under the “global namespace” where keywords are used to
> > identify a file, when publishing under a specific namespace files are
> > identified with a choosen identifier. Moreover, as a namespace is
> > basically a cryptographic key pair, and publishing a file under your
> > namespace means signing, one’s assured nobody else will publish under
> > her or his namespace. By the way, the private key associated with a
> > namespace is named “ego” or “pseudonym”.
> 
> > It’s easy to test this feature:
> 
> > # create a `test` ego/namespace
> > $ gnunet-identity -C test
> 
> > # list the known egos in the form: `name - public key`
> > $ gnunet-identity -d
> > test - M2OC987U9LFJHQ8LC9SLCV4Q0ONHJV7FMTFQ2VRPE0M9R9MK5860
> > …
> 
> > # index the file `foo.txt` under the `test` namespace
> > $ gnunet-publish -P test -t foobarbaz foo.txt
> 
> > # find the file `foo.txt`
> > $ gnunet-search gnunet://fs/sks/M2OC987U9LFJHQ8LC9SLCV4…/foobarbaz
> > #0:
> > gnunet-download -o "foo.txt" gnunet://fs/chk/PL217ODD8EDSMOIQ3UT0…
> 
> > Now if Alice wants to publish her binaries, she creates an
> > ego/namespace and publishes everything under it; Bob adds her
> > namespace’s public key to his authorized substitutes list, and when
> > installing `/gnu/store/xyz` the substitute will search for
> > `gnunet://fs/sks//xyz`.
> 
> > Instead of publishing an archive we might also directly publish/index
> > the build, but I don’t know if it’s viable.
> 
> > Does it seem right to you?
> 
> * Another discusion about guix integration
> 
> > > Instead of using ‘file-system-tree’, this variant should probably use
> > > ‘live-paths’ from (guix store), which returns the list of live store
> > > items.
> 
> > Well, `file-system-tree` is only used to recursively index a random
> > directory’s content (in our case, a single store item). It looked viable
> > for publishing a single store item, but won’t be good for indexing at
> > once the entire set of live paths; I should ask the GNUnet team how to
> > properly index such a huge amount of directories.
> 
> > On my machine, running `live-paths` takes ~2 seconds, but the
> > publication of the entire store will probably take much longer anyway.
> 
> > > BTW, I noticed there’s quite a bunch of global variables that are
> > > ‘set!’.  It would be better to avoid that, but I suppose the
> > > continuation-passing style that the GNUnet libraries impose makes it
> > > difficult.
> 
> > Hopefully, using the “closure” parameters of the GNUnet API in the
> > bindings should reduce the need for global variables, a

Re: FOSDEM 2018 and announcing a GNU Guix/Guile day!

[Ludovic Courtès]

Heya,

Pjotr Prins  skribis:

> On Tue, Jan 09, 2018 at 09:45:33PM -0800, Chris Marusich wrote:
>> It's a little last minute, but I'm thinking of going.  It'd be really
>> great to meet people in person and also to be able to go to FOSDEM!
>> Would there still be enough room for me on the Guix/Guile day if I came?
>
> Absolutely. Just add your name to the list. 

Looking forward to meeting you in person!

> We are happy to announce that Eelco Dolstra will be a speaker too to
> talk about the future of Nix and to take part in GNU Guix dicussions.

Awesome, thank you Eelco!

Ludo’.

Re: offloading issues again

[Ludovic Courtès]

Hi ng0,

ng0  skribis:

> @ build-started 
> /gnu/store/kigimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv - 
> x86_64-linux 
> /var/log/guix/drvs/ki//gimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv.bz2
> Backtrace:
>9 (primitive-load "/gnu/store/v3rv8n4m73h3isgg1pbq4xzh9q6?")
> In guix/ui.scm:
>   1480:12  8 (run-guix-command _ . _)
> In guix/scripts/offload.scm:
>696:22  7 (guix-offload . _)
> In ice-9/boot-9.scm:
> 837:9  6 (catch srfi-34 # ?)
> 837:9  5 (catch system-error # ?)
> In guix/scripts/offload.scm:
>530:19  4 (process-request _ _ # ?)
> 342:4  3 (transfer-and-offload # ?)
> In guix/ssh.scm:
>249:18  2 (send-files # _ _ # _ # _)
> In ssh/dist/node.scm:
> 393:4  1 (node-eval # ?)
> 158:6  0 (rrepl-skip-to-prompt #)
>
> ssh/dist/node.scm:158:6: In procedure rrepl-skip-to-prompt:
> ssh/dist/node.scm:158:6: Throw to key `node-error' with args `("Could not 
> locate REPL prompt" #)'.

This has been fixed in d06d54e338064d84a59c5811587b930799aab208 and in
the subsequent ‘guix’ package update.  Let me know if there are still
problems for you!

Thanks,
Ludo’.

Re: offloading issues again

[ng0]

Ludovic Courtès transcribed 1.4K bytes:
> Hi ng0,
> 
> ng0  skribis:
> 
> > @ build-started 
> > /gnu/store/kigimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv - 
> > x86_64-linux 
> > /var/log/guix/drvs/ki//gimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv.bz2
> > Backtrace:
> >9 (primitive-load "/gnu/store/v3rv8n4m73h3isgg1pbq4xzh9q6?")
> > In guix/ui.scm:
> >   1480:12  8 (run-guix-command _ . _)
> > In guix/scripts/offload.scm:
> >696:22  7 (guix-offload . _)
> > In ice-9/boot-9.scm:
> > 837:9  6 (catch srfi-34 # ?)
> > 837:9  5 (catch system-error # ?)
> > In guix/scripts/offload.scm:
> >530:19  4 (process-request _ _ # ?)
> > 342:4  3 (transfer-and-offload # ?)
> > In guix/ssh.scm:
> >249:18  2 (send-files # _ _ # _ # _)
> > In ssh/dist/node.scm:
> > 393:4  1 (node-eval # ?)
> > 158:6  0 (rrepl-skip-to-prompt #)
> >
> > ssh/dist/node.scm:158:6: In procedure rrepl-skip-to-prompt:
> > ssh/dist/node.scm:158:6: Throw to key `node-error' with args `("Could not 
> > locate REPL prompt" #)'.
> 
> This has been fixed in d06d54e338064d84a59c5811587b930799aab208 and in
> the subsequent ‘guix’ package update.  Let me know if there are still
> problems for you!
> 
> Thanks,
> Ludo’.

No issues, all fixed here. Thanks!
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

Re: offloading issues again

[ng0]

ng0 transcribed 2.7K bytes:
> Ludovic Courtès transcribed 1.4K bytes:
> > Hi ng0,
> > 
> > ng0  skribis:
> > 
> > > @ build-started 
> > > /gnu/store/kigimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv - 
> > > x86_64-linux 
> > > /var/log/guix/drvs/ki//gimal0dd5885mkli6h7n5mcbvp7g66-libvorbis-1.3.5.tar.xz.drv.bz2
> > > Backtrace:
> > >9 (primitive-load "/gnu/store/v3rv8n4m73h3isgg1pbq4xzh9q6?")
> > > In guix/ui.scm:
> > >   1480:12  8 (run-guix-command _ . _)
> > > In guix/scripts/offload.scm:
> > >696:22  7 (guix-offload . _)
> > > In ice-9/boot-9.scm:
> > > 837:9  6 (catch srfi-34 # ?)
> > > 837:9  5 (catch system-error # ?)
> > > In guix/scripts/offload.scm:
> > >530:19  4 (process-request _ _ # ?)
> > > 342:4  3 (transfer-and-offload # ?)
> > > In guix/ssh.scm:
> > >249:18  2 (send-files # _ _ # _ # _)
> > > In ssh/dist/node.scm:
> > > 393:4  1 (node-eval # ?)
> > > 158:6  0 (rrepl-skip-to-prompt #)
> > >
> > > ssh/dist/node.scm:158:6: In procedure rrepl-skip-to-prompt:
> > > ssh/dist/node.scm:158:6: Throw to key `node-error' with args `("Could not 
> > > locate REPL prompt" #)'.
> > 
> > This has been fixed in d06d54e338064d84a59c5811587b930799aab208 and in
> > the subsequent ‘guix’ package update.  Let me know if there are still
> > problems for you!
> > 
> > Thanks,
> > Ludo’.
> 
> No issues, all fixed here. Thanks!

I noticed a `herd restart guix-daemon` after reconfigure wasn't
enough, I had to reboot to make use of the new guix. Could this
be improved?

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

LanguageKit (targets llvm)

[Catonano]

This project

http://etoileos.com/etoile/features/languagekit/

targets llvm

As far as I understand it doesn't target llvm too. It targets llvm _only_

If I understand correctly, it aims to make dinamic languages wrap the
GNUStep kernel

Sort of like Guile does

I know what Stallmand wrote about llvm

But what does this mean for Guix ?

Is LanguageKit acceptable in Guix ?

Is it worth to ask the Etoile devs about this choice of theirs ?
Could it be that they can help in making LanguageKit work with the GCC ?

Thanks

Re: LanguageKit (targets llvm)

[Adonay Felipe Nogueira]

For those just getting the discussion, I have here a stripped log from
from #guix IRC channel at chat.freenode.net:

--8<---cut here---start->8---
2018-01-13T11:31:33-0200  the Languagekit project targets llvm. Is
 it good for Guix ? And how does that relate to the GNU project ?
 http://etoileos.com/etoile/features/languagekit/
[...]
2018-01-13T11:38:19-0200  correctly: This is bad for user's freedom
 for sure (non-copyleft thing), but we have in Guix packages with those
 licenses.
[...]
2018-01-13T11:45:55-0200  catonano wigust: Agree, LLVM is one of the
 worst indeed.
2018-01-13T11:46:44-0200  The question is: what should we do? (a)
 Provide recipes to build with GCC; (b) Use LLVM.
2018-01-13T11:47:35-0200  I vote for (a), but it would be somehow more
 work in the begining. After the recipes are ready, however, we will have the
 option to send them upstream. This is an option of course, not a requirement.
2018-01-13T11:48:54-0200  ... but I wish that LanguageKit would soon
 figure out the right reasons for using GCC build recipes/instructions
 instead.
2018-01-13T11:49:08-0200  ... before something worse happens.
2018-01-13T11:49:50-0200  adfeno: something worse ?
[...]
2018-01-13T12:02:05-0200  catonano wigust: Re: LangugageKit and GCC
 vs. LLVM: Something worse in terms of "software freedom not being available
 for the end-user".
2018-01-13T12:02:23-0200   aaand I can't type today... ;)
2018-01-13T12:02:41-0200  catonano: See about llvm from RMS
 https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
[...]
2018-01-13T12:05:47-0200  catonano wigust: I may not be an experienced
 programmer, but I can already see an issue here if LanguageKit and other
 projects keep up with this madness to support LLVM.
[...]
2018-01-13T12:07:33-0200  adfeno: we should probably move this
 discussion on the mailing list. I'd love having a deeper discussion about
 this
[...]
2018-01-13T12:09:58-0200  wigust: Stallman's assessment settles the
 point of the relationship between the GNU project and LanguageKit
2018-01-13T12:10:43-0200  it´s a pity because otherwise GNUStep is
 an interesting project
2018-01-13T12:10:45-0200  catonano wigust: Agreed to move to mailing
 list. ;)
2018-01-13T12:10:50-0200  ok
2018-01-13T12:11:00-0200  ... who will do the move?
2018-01-13T12:11:10-0200  adfeno: I will ;-)
2018-01-13T12:11:23-0200  Oh OK thanks catonano ;)
[...]
2018-01-13T12:49:46-0200  adfeno: I wrote on the dev ml
[...]
2018-01-13T12:56:24-0200  catonano: OK ;)
2018-01-13T12:56:31-0200  Thanks! :D
--8<---cut here---end--->8---

2018-01-13T15:47:21+0100 Catonano wrote:
> This project
>
> http://etoileos.com/etoile/features/languagekit/
>
> targets llvm
>
> As far as I understand it doesn't target llvm too. It targets llvm _only_
>
> If I understand correctly, it aims to make dinamic languages wrap the GNUStep
> kernel
>
> Sort of like Guile does
>
> I know what Stallmand wrote about llvm
>
> But what does this mean for Guix ? 
>
> Is LanguageKit acceptable in Guix ?
>
> Is it worth to ask the Etoile devs about this choice of theirs ?
> Could it be that they can help in making LanguageKit work with the GCC ?
>
> Thanks

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: LanguageKit (targets llvm)

[Leo Famulari]

On Sat, Jan 13, 2018 at 03:47:21PM +0100, Catonano wrote:
> This project
> 
> http://etoileos.com/etoile/features/languagekit/
> 
> targets llvm
> 
> As far as I understand it doesn't target llvm too. It targets llvm _only_
> 
> If I understand correctly, it aims to make dinamic languages wrap the
> GNUStep kernel
> 
> Sort of like Guile does
> 
> I know what Stallmand wrote about llvm
> 
> But what does this mean for Guix ?
> 
> Is LanguageKit acceptable in Guix ?

Yes, if LanguageKit is free software, it's acceptable. We have an LLVM
package and build several packages with it.


signature.asc
Description: PGP signature

weird errors

[Catonano]

Ok, I'm trying to build this tryton service

In running a VM like this

/gnu/store/9qcwl2vl8lnfbiid31irj92ffcagrc45-run-vm.sh --serial stdio -m 2G

I run into this error:

...
In execvp of TRYTONPASSFILE =
/gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin:
No such file or directory
ERROR: In procedure scm-error:
ERROR: program "TRYTONPASSFILE =
/gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin"
exited with non-zero code 32512

I read on a random page in the internet that the code 32512 is given when
sh doesn't find an executable

So, inspecting
/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin

this is what I find:

~$ cat
/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin
#!/gnu/store/f8k940vy9gck66m9r4id5m098w3hxgka-bash-minimal-4.4.12/bin/bash
export
PYTHONPATH="/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/lib/python3.5/site-packages:/gnu/store/284w0ylkn07d2wi452wdlzi6r7jc7lgh-python-mock-1.0.1/lib/python3.5/site-packages:/gnu/store/pd791yb95476z517rvh178hhk58n8c7f-python-dateutil-2.6.0/lib/python3.5/site-packages:/gnu/store/b4m2rv4nr88i69wjp8hshc0wc36hzv8b-python-genshi-0.7/lib/python3.5/site-packages:/gnu/store/ggxg8igwls4zvwy2mn85m1cd7f8iw6ls-python-polib-1.0.8/lib/python3.5/site-packages:/gnu/store/b8k8jzjd7yi3fwk0bpq6iwfg8i0ph68b-python-magic-0.4.15/lib/python3.5/site-packages:/gnu/store/5h2bscbxf1iy56rad731ynqb6gi2a45f-python-psycopg2-2.7.3.1/lib/python3.5/site-packages:/gnu/store/zx6x4f0rap8ks7yfglvqq349agrkjbpd-python-relatorio-0.8.0/lib/python3.5/site-packages:/gnu/store/a2awr40fbbhi7ala2wip8j4nw6nhz85x-python-lxml-3.8.0/lib/python3.5/site-packages:/gnu/store/q3330wrmdj1vhfzrvz0w1hws7wbhn40q-python-sql-0.9/lib/python3.5/site-packages:/gnu/store/nch06kxa2y9czp7wwz4fbyp1s8c1g4in-python-werkzeug-0.11.15/lib/python3.5/site-packages:/gnu/store/4walcharyljdhyj1bfg5002i84cmzmxp-python-wrapt-1.10.8/lib/python3.5/site-packages:/gnu/store/jb3n0bsdpkhvyb8y70jyr8fcx8fqssr9-python-3.5.3/lib/python3.5/site-packages:/gnu/store/8f72v1ngblndikg9pf8ig0p3r5gc0gi7-python-six-1.10.0/lib/python3.5/site-packages${PYTHONPATH:+:}$PYTHONPATH"
exec -a "$0"
"/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/.trytond-admin-real"
"$@"

Logging into the VM I see this

root@antelope ~# ls
/gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/
trytond  trytond-admin  trytond-cron
root@antelope ~#

So, the file being called is ".trytond-admin-real" but that doesn't exist

Insted trytond-admin exist



Also, when I quit the Guile repl (like this: ",q") I see several of these
messages

Backtrace:
   3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
In ice-9/eval.scm:
   182:19  2 (proc #(# #("tryt?" ?) ?))
   142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
In unknown file:
   0 (%resolve-variable (7 . invoke) #)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: invoke
13 Jan 17:41:54 ntpd[387]: Listen normally on 5 eth0
[fe80::f4dc:1d61:f230:f197%2]:123
13 Jan 17:41:54 ntpd[387]: new interface(s) found: waking up resolver
Respawning trytond.
Service trytond has been started.
Backtrace:
   3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
In ice-9/eval.scm:
   182:19  2 (proc #(# #("tryt?" ?) ?))
   142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
In unknown file:
   0 (%resolve-variable (7 . invoke) #)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: invoke
Respawning trytond.
Service trytond has been started.
Backtrace:
   3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
In ice-9/eval.scm:
   182:19  2 (proc #(# #("tryt?" ?) ?))
   142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
In unknown file:
   0 (%resolve-variable (7 . invoke) #)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: invoke
Respawning trytond.
Service trytond has been started.
Backtrace:
   3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
In ice-9/eval.scm:
   182:19  2 (proc #(# #("tryt?" ?) ?))
   142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
In unknown file:
   0 (%resolve-variable (7 . invoke) #)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: invoke
Service trytond has been disabled.
  (Respawning too fast.)


This is the GNU system.  Welcome.
antelope login: root
New session c1 of user root.
This is the GNU operating system, welcome!

invoke can't be found ?

How so ?
(guix build utils) is correctly imported as far as I can see

here's the relevant file
https://gitlab.com/humanitiesNerd/guix-hacks/blob/trytonservice/gnu/services/trytond.scm


Stangely, this command succeeds
make check-system TESTS="trytond"

It runs the only test thhaht I managed to write: it checks if 

diffoscope

[Gábor Boskovits]

Hello guix,

I think we should consider moving some diffoscope inputs to propagated
inputs.
It would be nice to test it with a plain profile, to check what should be
propagated.

I don't know if package-management is a logical place for this package.
Do we have any better to place this?

Re: diffoscope

[Leo Famulari]

On Sat, Jan 13, 2018 at 06:44:02PM +0100, Gábor Boskovits wrote:
> Hello guix,
> 
> I think we should consider moving some diffoscope inputs to propagated
> inputs.
> It would be nice to test it with a plain profile, to check what should be
> propagated.

Help wanted :)

> I don't know if package-management is a logical place for this package.
> Do we have any better to place this?

"Package management" doesn't cover all the potential uses of diffoscope,
but we put it there because it came out of the reproducible builds
project and most people seem to use it to compare the results of
building software.


signature.asc
Description: PGP signature

Re: Ideas for Summer of Code 2018 anyone?

[Gábor Boskovits]

I've checked last the list from last year.

It seems to me that the RISCV port might be more important than ever in the
face of Spectre.

The shepherd systemd semantics would be also nice to have.
I consider the syntax less important.
It would be also nice to create a service or set of services to make
administration experience
similar to a systemd sytem. For example the functionality of journalctl
would be nice to have.
Even a howto on configuring guixds to have the equivalent services of
systemd would
benefit adoptation, and it could point to functionality missing in our
system compared to
systemd.


2018-01-11 21:42 GMT+01:00 Ludovic Courtès :

> Hello Guix!
>
> It’s time to prepare for GSoC again!
>
> We need to collect ideas, presumably based on
> , in a new
> “GSoC-2018” page on that wiki.
>
> Let’s add new ideas to
> !
>
> Does someone want to take care of coordinating with Giuseppe Scrivano
> and others at summer-of-c...@gnu.org?  (Essentially sending them the URL
> of the idea list and monitoring the list.)
>
> Ludo’.
>
>
>
> -- Továbított levél --
> From: Giuseppe Scrivano 
> To: GNU Summer Of Code 
> Cc:
> Bcc:
> Date: Tue, 09 Jan 2018 11:06:53 +0100
> Subject: [IMPORTANT] Ideas for Summer of Code 2018
> Hi!
>
> Google is accepting applications for the next Summer of Code and as
> usual we are going to apply for it. José, Darshit and myself are going
> to manage the presence of GNU.
>
> We should start thinking about a list of ideas for the next Summer of
> Code and potential mentors.
>
> This is the list of ideas we had last year:
>
>   http://www.gnu.org/software/soc-projects/ideas-2017.html
>
> Is there anything left undone that can be reused this year?
>
> Please start sending ideas to add to the page and link them to the
> potential mentors that can help with it.
>
> Please send the html snippet for the ideas page, something like:
>
> 
> -
> http://www.gnu.org/software/foo";;>GNU FOO
>
> GNU FOO maintains their list of ideas for GSOC in an external
>   webpage:  href="http://foo.org/wanted.html";;>http://foo.org/wanted.html.
> 
> 
> -
>
> so that it can be embedded in the page as it is.
>
> Regards,
> Giuseppe
>
>
>

Re: Ideas for Summer of Code 2018 anyone?

[ng0]

Gábor Boskovits transcribed 6.9K bytes:
> I've checked last the list from last year.
> 
> It seems to me that the RISCV port might be more important than ever in the
> face of Spectre.

It doesn't really fix that and suffer from it aswell, but a port to it
would be great for the other obvious reasons.

> The shepherd systemd semantics would be also nice to have.
> I consider the syntax less important.
> It would be also nice to create a service or set of services to make
> administration experience
> similar to a systemd sytem. For example the functionality of journalctl
> would be nice to have.

That is one goal that can be defined 'log view' and discussed.
The rest above is not very clear, lots of guessing.

> Even a howto on configuring guixds to have the equivalent services of
> systemd would
> benefit adoptation, and it could point to functionality missing in our
> system compared to
> systemd.

I don't think we need everything systemd has, or do we?
What are you personally or work related missing, besides the obvious amount of 
services?

I myself was missing an easy, less scheme focused way to create operating
systems, so I'm working on that. To get to why I mention this: I thought it
was too obvious, but most of the time the things that are too obvious
are not being worked on because they are too obvious.

I would very much like to have an build log reader+browser as mentioned here
in the past. Today I've pointed someone to /var/log/guix/drvs/ and just gave
the note to use `find -name '*thingtosearchfor*'` and copy it to $home,
extract and view it.

> 
> 2018-01-11 21:42 GMT+01:00 Ludovic Courtès :
> 
> > Hello Guix!
> >
> > It’s time to prepare for GSoC again!
> >
> > We need to collect ideas, presumably based on
> > , in a new
> > “GSoC-2018” page on that wiki.
> >
> > Let’s add new ideas to
> > !
> >
> > Does someone want to take care of coordinating with Giuseppe Scrivano
> > and others at summer-of-c...@gnu.org?  (Essentially sending them the URL
> > of the idea list and monitoring the list.)
> >
> > Ludo’.
> >
> >
> >
> > -- Továbított levél --
> > From: Giuseppe Scrivano 
> > To: GNU Summer Of Code 
> > Cc:
> > Bcc:
> > Date: Tue, 09 Jan 2018 11:06:53 +0100
> > Subject: [IMPORTANT] Ideas for Summer of Code 2018
> > Hi!
> >
> > Google is accepting applications for the next Summer of Code and as
> > usual we are going to apply for it. José, Darshit and myself are going
> > to manage the presence of GNU.
> >
> > We should start thinking about a list of ideas for the next Summer of
> > Code and potential mentors.
> >
> > This is the list of ideas we had last year:
> >
> >   http://www.gnu.org/software/soc-projects/ideas-2017.html
> >
> > Is there anything left undone that can be reused this year?
> >
> > Please start sending ideas to add to the page and link them to the
> > potential mentors that can help with it.
> >
> > Please send the html snippet for the ideas page, something like:
> >
> > 
> > -
> > http://www.gnu.org/software/foo";;>GNU FOO
> >
> > GNU FOO maintains their list of ideas for GSOC in an external
> >   webpage:  > href="http://foo.org/wanted.html";;>http://foo.org/wanted.html.
> > 
> > 
> > -
> >
> > so that it can be embedded in the page as it is.
> >
> > Regards,
> > Giuseppe
> >
> >
> >

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

Re: Ideas for Summer of Code 2018 anyone?

[Gábor Boskovits]

2018-01-13 20:32 GMT+01:00 ng0 :

> Gábor Boskovits transcribed 6.9K bytes:
> > I've checked last the list from last year.
> >
> > It seems to me that the RISCV port might be more important than ever in
> the
> > face of Spectre.
>
> It doesn't really fix that and suffer from it aswell, but a port to it
> would be great for the other obvious reasons.
>
>
Current implementations seem not to be affected.
Also mitigating problems like this, provided that we have rtl level
open source designs have a much better chance. We have this
for example for Freedom: https://github.com/sifive/freedom.
And yes, porting would be great for other reasons too.

What I currently miss from the field of open hardware the most
is an open source FPGA. This could really close the gap we
are now having, and we could make really fully open hardware.
An open sourced FPGA design would be important not for
manifaturing, but to allow checking it. It is not unheard of
buggy FPGA-s. However,I don't think that this will happen any
time soon.

> The shepherd systemd semantics would be also nice to have.
> > I consider the syntax less important.
> > It would be also nice to create a service or set of services to make
> > administration experience
> > similar to a systemd sytem. For example the functionality of journalctl
> > would be nice to have.
>
> That is one goal that can be defined 'log view' and discussed.
> The rest above is not very clear, lots of guessing.
>
> > Even a howto on configuring guixds to have the equivalent services of
> > systemd would
> > benefit adoptation, and it could point to functionality missing in our
> > system compared to
> > systemd.
>
>
What I actually is journalctl, and a status display like systemctl status.
It is great that work is in progress in this area, I was not aware of 'log
view'.

I think it would also be great if we could give pointers how to replicate:

localectl
networkctl
resolved
systemctl
timedatectl

functions. People coming from a systemd background could have a
document to find the appropriate sections in our manuals.


> I don't think we need everything systemd has, or do we?
> What are you personally or work related missing, besides the obvious
> amount of services?
>
> I myself was missing an easy, less scheme focused way to create operating
> systems, so I'm working on that. To get to why I mention this: I thought it
> was too obvious, but most of the time the things that are too obvious
> are not being worked on because they are too obvious.
>
> I would very much like to have an build log reader+browser as mentioned
> here
> in the past. Today I've pointed someone to /var/log/guix/drvs/ and just
> gave
> the note to use `find -name '*thingtosearchfor*'` and copy it to $home,
> extract and view it.
>
> >
> > 2018-01-11 21:42 GMT+01:00 Ludovic Courtès :
> >
> > > Hello Guix!
> > >
> > > It’s time to prepare for GSoC again!
> > >
> > > We need to collect ideas, presumably based on
> > > , in a new
> > > “GSoC-2018” page on that wiki.
> > >
> > > Let’s add new ideas to
> > > !
> > >
> > > Does someone want to take care of coordinating with Giuseppe Scrivano
> > > and others at summer-of-c...@gnu.org?  (Essentially sending them the
> URL
> > > of the idea list and monitoring the list.)
> > >
> > > Ludo’.
> > >
> > >
> > >
> > > -- Továbított levél --
> > > From: Giuseppe Scrivano 
> > > To: GNU Summer Of Code 
> > > Cc:
> > > Bcc:
> > > Date: Tue, 09 Jan 2018 11:06:53 +0100
> > > Subject: [IMPORTANT] Ideas for Summer of Code 2018
> > > Hi!
> > >
> > > Google is accepting applications for the next Summer of Code and as
> > > usual we are going to apply for it. José, Darshit and myself are going
> > > to manage the presence of GNU.
> > >
> > > We should start thinking about a list of ideas for the next Summer of
> > > Code and potential mentors.
> > >
> > > This is the list of ideas we had last year:
> > >
> > >   http://www.gnu.org/software/soc-projects/ideas-2017.html
> > >
> > > Is there anything left undone that can be reused this year?
> > >
> > > Please start sending ideas to add to the page and link them to the
> > > potential mentors that can help with it.
> > >
> > > Please send the html snippet for the ideas page, something like:
> > >
> > > 
> > > -
> > > http://www.gnu.org/software/foo";;>GNU
> FOO
> > >
> > > GNU FOO maintains their list of ideas for GSOC in an external
> > >   webpage:  > > href="http://foo.org/wanted.html";;>http://foo.org/wanted.html.
> > > 
> > > 
> > > -
> > >
> > > so that it can be embedded in the page as it is.
> > >
> > > Regards,
> > > Giuseppe
> > >
> > >
> > >
>
> --
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
>

Re: Ideas for Summer of Code 2018 anyone?

[ng0]

Gábor Boskovits transcribed 13K bytes:
> 2018-01-13 20:32 GMT+01:00 ng0 :
> 
> > Gábor Boskovits transcribed 6.9K bytes:
> > > I've checked last the list from last year.
> > >
> > > It seems to me that the RISCV port might be more important than ever in
> > the
> > > face of Spectre.
> >
> > It doesn't really fix that and suffer from it aswell, but a port to it
> > would be great for the other obvious reasons.
> >
> >
> Current implementations seem not to be affected.
> Also mitigating problems like this, provided that we have rtl level
> open source designs have a much better chance. We have this
> for example for Freedom: https://github.com/sifive/freedom.
> And yes, porting would be great for other reasons too.
> 
> What I currently miss from the field of open hardware the most
> is an open source FPGA. This could really close the gap we
> are now having, and we could make really fully open hardware.
> An open sourced FPGA design would be important not for
> manifaturing, but to allow checking it. It is not unheard of
> buggy FPGA-s. However,I don't think that this will happen any
> time soon.
> 
> > The shepherd systemd semantics would be also nice to have.
> > > I consider the syntax less important.
> > > It would be also nice to create a service or set of services to make
> > > administration experience
> > > similar to a systemd sytem. For example the functionality of journalctl
> > > would be nice to have.
> >
> > That is one goal that can be defined 'log view' and discussed.
> > The rest above is not very clear, lots of guessing.
> >
> > > Even a howto on configuring guixds to have the equivalent services of
> > > systemd would
> > > benefit adoptation, and it could point to functionality missing in our
> > > system compared to
> > > systemd.
> >
> >
> What I actually is journalctl, and a status display like systemctl status.
> It is great that work is in progress in this area, I was not aware of 'log
> view'.

There is no work on a log viewer. I just suggested it again, for the GSoC.

> I think it would also be great if we could give pointers how to replicate:
> 
> localectl
> networkctl
> resolved
> systemctl
> timedatectl
> 
> functions. People coming from a systemd background could have a
> document to find the appropriate sections in our manuals.
> 
> 
> > I don't think we need everything systemd has, or do we?
> > What are you personally or work related missing, besides the obvious
> > amount of services?
> >
> > I myself was missing an easy, less scheme focused way to create operating
> > systems, so I'm working on that. To get to why I mention this: I thought it
> > was too obvious, but most of the time the things that are too obvious
> > are not being worked on because they are too obvious.
> >
> > I would very much like to have an build log reader+browser as mentioned
> > here
> > in the past. Today I've pointed someone to /var/log/guix/drvs/ and just
> > gave
> > the note to use `find -name '*thingtosearchfor*'` and copy it to $home,
> > extract and view it.
> >
> > >
> > > 2018-01-11 21:42 GMT+01:00 Ludovic Courtès :
> > >
> > > > Hello Guix!
> > > >
> > > > It’s time to prepare for GSoC again!
> > > >
> > > > We need to collect ideas, presumably based on
> > > > , in a new
> > > > “GSoC-2018” page on that wiki.
> > > >
> > > > Let’s add new ideas to
> > > > !
> > > >
> > > > Does someone want to take care of coordinating with Giuseppe Scrivano
> > > > and others at summer-of-c...@gnu.org?  (Essentially sending them the
> > URL
> > > > of the idea list and monitoring the list.)
> > > >
> > > > Ludo’.
> > > >
> > > >
> > > >
> > > > -- Továbított levél --
> > > > From: Giuseppe Scrivano 
> > > > To: GNU Summer Of Code 
> > > > Cc:
> > > > Bcc:
> > > > Date: Tue, 09 Jan 2018 11:06:53 +0100
> > > > Subject: [IMPORTANT] Ideas for Summer of Code 2018
> > > > Hi!
> > > >
> > > > Google is accepting applications for the next Summer of Code and as
> > > > usual we are going to apply for it. José, Darshit and myself are going
> > > > to manage the presence of GNU.
> > > >
> > > > We should start thinking about a list of ideas for the next Summer of
> > > > Code and potential mentors.
> > > >
> > > > This is the list of ideas we had last year:
> > > >
> > > >   http://www.gnu.org/software/soc-projects/ideas-2017.html
> > > >
> > > > Is there anything left undone that can be reused this year?
> > > >
> > > > Please start sending ideas to add to the page and link them to the
> > > > potential mentors that can help with it.
> > > >
> > > > Please send the html snippet for the ideas page, something like:
> > > >
> > > > 
> > > > -
> > > > http://www.gnu.org/software/foo";;>GNU
> > FOO
> > > >
> > > > GNU FOO maintains their list of ideas for GSOC in an external
> > > >   webpage:  > > > href="http://foo.o

Re: LanguageKit (targets llvm)

[Catonano]

2018-01-13 17:29 GMT+01:00 Leo Famulari :


> Yes, if LanguageKit is free software, it's acceptable. We have an LLVM
> package and build several packages with it.
>


Ok

Thanks for clarifying

‘guix system reconfigure’ does not always load new services

[Ludovic Courtès]

Hello,

ng0  skribis:

> I noticed a `herd restart guix-daemon` after reconfigure wasn't
> enough, I had to reboot to make use of the new guix. Could this
> be improved?

Yes, that’s a problem (Andreas also reported it to me a couple of days
ago.)

The problem is that ‘guix system reconfigure’ reloads and restarts
services that were not currently running.  For other services, such as
guix-daemon, it does nothing—it does not even load the new version.

This is because the Shepherd currently doesn’t offer a way to “hot-swap”
services without stopping them.  Instead it first unloads the service,
loads the new one, and (optionally) starts it.  See (gnu services herd).

So what we would need is to somehow overwrite the current service.  The
problem is that it may be incorrect, for instance because we’d like to
use the ‘stop’ action of the previous service when we eventually stop
it, rather than the new ‘stop’ action.  So perhaps we should register
the new service so that it replaces the old one only when the old one is
stopped.

Thoughts?

Ludo’.

Re: weird errors

[Ludovic Courtès]

Heya,

Catonano  skribis:

> In execvp of TRYTONPASSFILE =
> /gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
> /gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin:
> No such file or directory
> ERROR: In procedure scm-error:
> ERROR: program "TRYTONPASSFILE =
> /gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
> /gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-admin"
> exited with non-zero code 32512

It’s trying to execute a program named “TRYTONPASSFILE = …/…”.  This
initial “TRYTONPASSFILE =” string is bogus, it’s not the name of the
program.

> Respawning trytond.
> Service trytond has been started.
> Backtrace:
>3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
> In ice-9/eval.scm:
>182:19  2 (proc #(# #("tryt?" ?) ?))
>142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
> In unknown file:
>0 (%resolve-variable (7 . invoke) #)
>
> ERROR: In procedure %resolve-variable:
> ERROR: Unbound variable: invoke

‘invoke’ is in (guix build utils), so you need (use-modules (guix build
utils)) somewhere.

Specifically, in the ‘tryton-shepherd-service’ procedure you posted, you
need to define ‘start-script’ like this:

  (program-file "start-trytond"
(with-imported-modules '((guix build utils))
  #~(begin
  (use-modules (guix build utils))

  (let ((user …))
;; …
(invoke …)

> warning: failed to load '(gnu tests install)':
> In procedure allocate-struct: Wrong type argument in position 2: 13

This suggests an ABI mismatch; run ‘make clean-go && make’.

HTH, looks like you’re almost there!  :-)

Ludo’.

Re: Ideas for Summer of Code 2018 anyone?

[Ludovic Courtès]

Heya Gábor,

Gábor Boskovits  skribis:

> I've checked last the list from last year.
>
> It seems to me that the RISCV port might be more important than ever in the
> face of Spectre.
>
> The shepherd systemd semantics would be also nice to have.
> I consider the syntax less important.
> It would be also nice to create a service or set of services to make
> administration experience
> similar to a systemd sytem. For example the functionality of journalctl
> would be nice to have.
> Even a howto on configuring guixds to have the equivalent services of
> systemd would
> benefit adoptation, and it could point to functionality missing in our
> system compared to
> systemd.

I have mixed feelings about journalctl (but then again I have almost no
experience with it), but otherwise these all look like good ideas to me!
Would you like to adjust the wiki page accordingly?

Thanks,
Ludo’.

Re: Ideas for Summer of Code 2018 anyone?

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> It’s time to prepare for GSoC again!
>
> We need to collect ideas, presumably based on
> , in a new
> “GSoC-2018” page on that wiki.
>
> Let’s add new ideas to
> !
>
> Does someone want to take care of coordinating with Giuseppe Scrivano
> and others at summer-of-c...@gnu.org?  (Essentially sending them the URL
> of the idea list and monitoring the list.)

I’ve created the  but
rest assured: the position of Guix GSoC coordinator is still available.
:-)

Ludo’.

Re: gnunet-guile reboot & guix

[Ludovic Courtès]

Hello,

Amirouche Boubekki  skribis:

> I restarted from scratch the gnunet-guile bindings. It was made
> much easier thanks to the work of ng0 on gnunet documentation and
> guile-bytestructures to handle C structs and unions.
>
> You need guix from today with latest guile-bytestructures 1.0.1.
>
> You can get the code using the following command:
>
>git clone git://gnunet.org/gnunet-guile2.git

Thanks a lot for giving it some love!

Perhaps we should retire the repo at
?
(The ‘wip-monad’ branch might be of interest though.)

Ludo’.

Re: [GNUnet-developers] gnunet-guile reboot & guix

[ng0]

Ludovic Courtès transcribed 1.0K bytes:
> Hello,
> 
> Amirouche Boubekki  skribis:
> 
> > I restarted from scratch the gnunet-guile bindings. It was made
> > much easier thanks to the work of ng0 on gnunet documentation and
> > guile-bytestructures to handle C structs and unions.
> >
> > You need guix from today with latest guile-bytestructures 1.0.1.
> >
> > You can get the code using the following command:
> >
> >git clone git://gnunet.org/gnunet-guile2.git
> 
> Thanks a lot for giving it some love!
> 
> Perhaps we should retire the repo at
> ?
> (The ‘wip-monad’ branch might be of interest though.)
> 
> Ludo’.
> 
> ___
> GNUnet-developers mailing list
> gnunet-develop...@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

I think both Amirouche as well as myself (and gnunet.org) have a
copy of the old code base. If I understand savannah hosting
correctly 'retiring' just means making it read-only, so that
would be alright.
Development happens on gnunet.org and future releases will be
placed on the GNU Ftp folder of gnunet.

Our mailinglist at gnunet-developers is open for patches
(no sign-up required) and whoever wants to help developing
it can get push access (of course Amirouche has to decide on
this project, etc).

Eventually we should remove the old repository 
https://gnunet.org/git/gnunet-guile,
or rename the current one (gnunet-guile2).

That is my position. I'm not working on this right now,
Amirouche does.
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

Re: weird errors

[Catonano]

2018-01-13 22:13 GMT+01:00 Ludovic Courtès :

> Heya,
>
> Catonano  skribis:
>
> > In execvp of TRYTONPASSFILE =
> > /gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
> > /gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-
> admin:
> > No such file or directory
> > ERROR: In procedure scm-error:
> > ERROR: program "TRYTONPASSFILE =
> > /gnu/store/3qpvdgkagkqyzpaw65c0plzd9zqp44v6-passfile
> > /gnu/store/144hjm67pzq9x0v47hwfiabwqq219aya-trytond-4.6.2/bin/trytond-
> admin"
> > exited with non-zero code 32512
>
> It’s trying to execute a program named “TRYTONPASSFILE = …/…”.  This
> initial “TRYTONPASSFILE =” string is bogus, it’s not the name of the
> program.
>

TRYTONPASSFILE is supposed to be an environment variable forr trytond-admin
to consume

If TRYTONPASSFILE isn't set, tytond-admin will prompt the user and require
some interaction

the line is supposed to be like

TRYTOPASSILE = /path/to/some/passfile trytond-admin -c
trytond-conf-file.conf

that is

TRYTOPASSILE = /gnu/store/some-hash-passfile
/gnu/store/some-hash-trytond-admin -c
/gnu/stor/some-hash-trytond-conf-file.conf

The problem seesm to be that a call to some .trytond-admin-real can't be
satisfied

> Respawning trytond.
> > Service trytond has been started.
> > Backtrace:
> >3 (primitive-load "/gnu/store/dh2mm0hk37q4cr4g390psp5y7jl?")
> > In ice-9/eval.scm:
> >182:19  2 (proc #(# #("tryt?" ?) ?))
> >142:16  1 (compile-top-call _ (7 . invoke) ((11 0 . 1) (10 # # ?)))
> > In unknown file:
> >0 (%resolve-variable (7 . invoke) #)
> >
> > ERROR: In procedure %resolve-variable:
> > ERROR: Unbound variable: invoke
>
> ‘invoke’ is in (guix build utils), so you need (use-modules (guix build
> utils)) somewhere.
>
> Specifically, in the ‘tryton-shepherd-service’ procedure you posted, you
> need to define ‘start-script’ like this:
>
>   (program-file "start-trytond"
> (with-imported-modules '((guix build utils))
>   #~(begin
>   (use-modules (guix build utils))
>
>   (let ((user …))
> ;; …
> (invoke …)
>

Ah, ok, I missed this



>
> > warning: failed to load '(gnu tests install)':
> > In procedure allocate-struct: Wrong type argument in position 2: 13
>
> This suggests an ABI mismatch; run ‘make clean-go && make’.
>
>
Ok


> HTH, looks like you’re almost there!  :-)
>

Thankks you Ludo !

Admittedly I'm a bit tired ;-)

I'll do this last turn of tries

If it doesn't work afer this, I'll abandon it and move on

I'll keep you posted !