Re: Trying to contribute packages: ./pre-inst-env doesn't work

[Amirouche]

On 2019-05-15 18:33, Amirouche wrote:

Welcome Dordon,


On 2019-05-15 11:46, Doron Behar wrote:



[...]




I'd like to be convinced I'm wrong at least in this subject because as
I dive more and more into Guix I feel there have been made a lot of 
poor

design choices in it..


That the usual feeling one get when one start a project. That's good, it
means you have ideas!!

Re: Trying to contribute packages: ./pre-inst-env doesn't work

[Amirouche]

Welcome Dordon,


On 2019-05-15 11:46, Doron Behar wrote:


On Wed, May 15, 2019 at 10:46:29AM +0200, Gábor Boskovits wrote:

>
It might be easier to first set up a channel with your packages only. 
You

can find
several examples out there.
Here is one of my channels:
https://gitlab.com/g_bor/nominatim-channel


Here is mine: https://git.sr.ht/~amz3/guix-amz3-channel




>
> - I ran ./configure inside /var/code/doron/guix
>

Did you specify your localstatedir to configure?


Yes, I've given it the same flags I gave it when I've build it at 
first.



Did you also run make?


No! I was hoping I could avoid that as that's extremely CPU intensive..
Is there a way to run make with only the relevant targets? That could 
be

very helpful...


That is up to you. Look up:

compression.scm
1454: (replace 'build
1455-   (lambda* (#:key (make-flags '()) #:allow-other-keys)
1456- (apply invoke "make" "generic_gcc" make-flags)))

If you mean running a specific target in guix tree, I don't know about
such thing.

Plus, do I have to run make after every change to a package 
definition!?

Will it compile everything from the ground up after every such change?


There is several way around that but I do not do it often (or at all):

1) You can run guix build -K -e "(@ (doron module) software-package)"

Several things here:

The -K flag will keep the build if it fails, lookup the
documentation about it. From there you can recreate the environment and
retry manually the build (almost?) as done by the builder.

The -e will install the package that is returned by the eval'ed string
that follow the flag. That thing:

  (@ (doron module) software-package)

Read as "import 'software-package' from (doron module)". Usually you
also rely on --load-path=DIR aka. -L so the complete command might look
like the following:

  guix build -L $(pwd) -K -e "(@ (doron module) software-package)"

There is also the option -f not as nice as -e once you get it.

2) The above technic is nice and good to know but it will not help
to tweak and trick a lot of stuff. Another way to go, if you want to
keep around the build and experiment with various settings. You can
setup a profile that will gather all and only the dependencies for
the build your are working on. Once you are confident with the steps
required to execute the build your can *translate* that into a guix
package. I never do that so I can not help much more.


I wish these technical details would have been documented...


Maybe slow but sure thing :)


I'm running make while I'm writing this email and I must say that not
only it takes a lot of time and uses a lot of CPU power,


I think, It use all the CPU available (maybe minus one) except if you
disable parallel build in the package definition #:parallel-build? #f


it handles way too much irrelevant things such as translations.


I don't understand why they show up in git status all the time.
Last time I published a patch with those.


I also noticed it runs GUILEC - is it really necessary? I'm no Guile
expert and I wish I could avoid diving to the whole ecosystem of it 
just

because I want to use Guix and contribute some packages!


You can avoid that package definition compilation step, but it is not
worthwhile. the way guix works is that, I think, it needs to lookup all
definitions to be able to figure the one you want to install. So, 
anyway,

guile/guix will go through all the packages that are defined.

The compilation itself is linked to the fact that GNU Guile use a 
bytecode

VM.



I talked about this subject in a different thread: The design choice of
putting all package definitions in the same repository as the package
manager it self is very uncommon in the Linux.


monorepo(s) for the win!


I understand that almost
all of Guix is written in Guile so it must be linked somehow to the
package definitions but I think it makes it very hard to actually
contribute something to the packages definitions! It seems that we,
package maintainers, or to put it simply - the community, need to be 
too

much involved in the source code of everything in order to help the
distributions.


Not really, with channels you are free to do whatever you want. Most 
likely
you will helpers defined in guix/ or refer to existing package 
definitions
with guix edit sqlite3 or else... so in the end I think a monorepo is 
good

for the time being, given there is channels.


I'd like to be convinced I'm wrong at least in this subject because as
I dive more and more into Guix I feel there have been made a lot of 
poor

design choices in it..

Re: guile scheme tutorial

[amirouche]

On 2019-05-04 08:08, rendaw wrote:

On 5/3/19 9:45 PM, amirou...@hyper.dev wrote:

Hello!



(Whoops, replied with the wrong account.)

Oh, this is great!  I've actually been putting together a small Guix
guide here:
https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_those_who_dont.md

It has a small Guile primer, but it doesn't go into depth or have any
hands on examples like yours.  My goal was to cover just enough so that
people could understand Guix configs (or at least 90% of them), so no
recursion, etc.  I'm glad you got into records, I just kind of 
handwaved

that away ("they're functions", not 100% sure this is correct either).


That is good. The beginning looks like guix is not worthwhile and then
you continue in the second page with an introduction to guile and guix.
I find it nice actually.

I spotted a minor error:

  (system* (string-append #$openssl "/bin/openssl")
   "genrsa" "-out" private-key "2048"))

  
https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_those_who_dont.md#running-executables


Indeed you can run programs like that but in guix it is preferred to run
with invoke, see the source :)

Thanks for sharing!

Re: GNU Guix 1.0.0 released

[Amirouche Boubekki]

Le jeu. 2 mai 2019 à 14:12, Ludovic Courtès  a écrit :

> We are thrilled to announce the release of GNU Guix 1.0.0!
>
> This 1.0 release is a major milestone for Guix.  It represents 7 years
> of hard work with more than 40,000 commits by 260 people, 19 releases,
> and an equally amazing amount of work on documentation, translation,
> artwork, web design, mentoring, outreach, and many other activities that
> together have made it a thriving project.
>

I would like to add that the maitainers in many places had the vision. The
first
being getting started with guix. The dedication is inspiration. Sadly I did
help
as much as I could. I had bad experience with packaging stuff. I know it is
easier with guix but still. I also know that not everything in guile is
about
packaging. I am happy my graph hack was reworked to be part of guile proper.


Anyway Happy 1.0.0

Re: guile scheme tutorial

[amirouche]

On 2019-05-03 14:45, amirou...@hyper.dev wrote:

Hello!


If you are getting started guix and want a glimpse of guile,
I made a small tutorial that might get you started:

   https://github.com/a-guile-mind/book/#a-guile-mind-book


I was just made aware that the calculations results are not good
in the tutorial. I can not fix it right now. I will do it tomorrow.

You need to install guile-readline to have "normal" REPL:

  guix install guile-readline

Also, rekado made a package called guile-studio:

  This is Emacs with a few settings that make working
  with Guile easier for people new to Emacs.  Features
  include: CUA mode, Geiser, tool bar icons to evaluate
  Guile buffers, support for Guile's very own picture
  language, code completion, a simple mode line, etc.

And as noted above guile-picture-language.

In my usual workflow I don't rely only on emacs. I use somewhat
magit but for instance I don't use emacs-guix. ymmv. Anyway,
the goal of the tutorial is to get you started with scheme syntax.

The big omissions of the tutorial:

- macros, you can use macros without knowing how to write one.
  define-record-type is a macro. The package definition is a macro.
  Just remember that the evaluation of expressions in a macro is macro
  specific. Refer to an example or the documentation to learn how
  to use it.

- quasiquote, quote, unquote, unquote-splicing which is used a lot
  in guix package definitions. Their understanding and use are
  straight forward. They allow to describe a construction using
  the literal syntax e.g.:

(list (cons 'a 42) ('b 101))

  Can be written:

'((a . 42) (b 101))

  Which happens to be what the REPL give in the output plus the quote.

  Then if you have a variable around you can insert it inside a
  quasiquote with unquote e.g.:

 (define magic 42)
 `((a . ,magic) (b 101))

  quasiquote and unquote is used in most association lists. Like in 
package
  definition inputs, propagated inputs and the last one I don't 
remember.



One last advice, when you import a module in the REPL, it must be easier
to prefix the import (that will import everything public in that module)
so that you can TAB-complete the prefix to learn the content fo the 
module:



  (use-modules ((guix packages) #:prefix foo:))

Then when you type foo: in the REPL (or geiser) you get only what is in 
the

module prefixed with foo:

This is usually done in guile project, inside modules to avoid variable 
clash

but it is also helpful in the REPL to discover the content of a module.

The best way to learn code is to read good code like guix.


Feel free to share your own resources to learn Guile Scheme.

Happy hacking!

guile scheme tutorial

[amirouche]

Hello!


If you are getting started guix and want a glimpse of guile,
I made a small tutorial that might get you started:

   https://github.com/a-guile-mind/book/#a-guile-mind-book

Feel free to share your own resources to learn Guile Scheme.

Happy hacking!



Amirouche ~ amz3

Re: Ubuntu 18.04 LTS Bionic - Installing Guix in an LXC

[Amirouche Boubekki]

There is still an issue with the locale that is C.UTF-8.

To fix it, you can add:

lxc.environment = LC_ALL=en_US.UTF-8

To the file /var/lib/lxc/schemer/config

Le mar. 16 oct. 2018 à 12:57, Amirouche Boubekki <
amirouche.boube...@gmail.com> a écrit :

> To install guix (the package manager) inside an ubuntu LXC on Ubuntu you
> can do the following:
>
> $ sudo apt install lxc
> $ sudo lxc-create -t download -n schemer -- --dist ubuntu --release bionic
> --arch amd64
>
> That will create a lightweight virtulal machine with ubuntu bionic as a
> distribution.
>
> To connect to it, use the following command:
>
> $ sudo lxc-start -n schemer
> $ sudo lxc-attach -n schemer
>
> This will open a bash prompt inside the LXC container.
>
> It's recommended to install emacs-no-x (!) and openssh-server:
>
> # apt install emacs-no-x
> # apt install openssh-server
>
> Then change the configuration of sshd to allow to connect as root:
>
> # emacs /etc/ssh/sshd_config
>
> You must have a line in that file that says:
>
> PermitRootLogin yes
>
> Restart ssh daemon:
>
> # /etc/init.d/sshd restart
>
> Use the following command to know the IP of the container:
>
> # ip a
>
> Set a password for the root login:
>
> # passwd
>
> Now type 'exit' to exit the container and return to the host. You can a
> now connect using ssh:
>
> $ ssh root@$IP_OF_SCHEMER
>
> Now, you are connected to the LXC using ssh, you can follow the usual
> steps
> to install guix from the manual:
>
>   http://www.gnu.org/software/guix/download/
>
> Now you might try to do:
>
> # guix package -i hello
>
> And it will fail with the following error:
>
> > build failed: while setting up the build environment: unable to make ?/?
> private mount: Permission denied
>
> If you look at 'dmesg' output you will see something like:
>
> > audit: type=1400 audit(1539605833.825:115): apparmor="DENIED"
> operation="mount" info="failed flags match" error=-13
> profile="lxc-container-default-cgns" name="/" pid=13543 comm="guix-daemon"
> flags="rw, rprivate"
>
> That's where it gets ugly. I only know how to disable apparmor for that
> lxc container.
>
> Go to /var/lib/lxc/schemer/config and add somewhere in that file the
> following command:
>
> lxc.apparmor.profile = unconfined
>
> You might need to restart the lxc container:
>
> $ lxc-stop -n schemer
> $ lxc-start -n schemer
> $ ssh root@$IP_OF_SCHEMER
> # guix package -i hello && hello
>
>
> Happy hacking!
>

Ubuntu 18.04 LTS Bionic - Installing Guix in an LXC

[Amirouche Boubekki]

To install guix (the package manager) inside an ubuntu LXC on Ubuntu you
can do the following:

$ sudo apt install lxc
$ sudo lxc-create -t download -n schemer -- --dist ubuntu --release bionic
--arch amd64

That will create a lightweight virtulal machine with ubuntu bionic as a
distribution.

To connect to it, use the following command:

$ sudo lxc-start -n schemer
$ sudo lxc-attach -n schemer

This will open a bash prompt inside the LXC container.

It's recommended to install emacs-no-x (!) and openssh-server:

# apt install emacs-no-x
# apt install openssh-server

Then change the configuration of sshd to allow to connect as root:

# emacs /etc/ssh/sshd_config

You must have a line in that file that says:

PermitRootLogin yes

Restart ssh daemon:

# /etc/init.d/sshd restart

Use the following command to know the IP of the container:

# ip a

Set a password for the root login:

# passwd

Now type 'exit' to exit the container and return to the host. You can a now
connect using ssh:

$ ssh root@$IP_OF_SCHEMER

Now, you are connected to the LXC using ssh, you can follow the usual steps
to install guix from the manual:

  http://www.gnu.org/software/guix/download/

Now you might try to do:

# guix package -i hello

And it will fail with the following error:

> build failed: while setting up the build environment: unable to make ?/?
private mount: Permission denied

If you look at 'dmesg' output you will see something like:

> audit: type=1400 audit(1539605833.825:115): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=13543 comm="guix-daemon"
flags="rw, rprivate"

That's where it gets ugly. I only know how to disable apparmor for that lxc
container.

Go to /var/lib/lxc/schemer/config and add somewhere in that file the
following command:

lxc.apparmor.profile = unconfined

You might need to restart the lxc container:

$ lxc-stop -n schemer
$ lxc-start -n schemer
$ ssh root@$IP_OF_SCHEMER
# guix package -i hello && hello


Happy hacking!

Ubuntu + Guix + Git + python pre-commit hook = server certificate verification failed. CAfile: none CRLfile: none

[Amirouche Boubekki]

Hello,


I am trying to use pre-commit [https://pre-commit.com/]
in a project of mine. git fails with an error about missing
certificate.

You can find an example run at https://framagit.org/snippets/2183

And you will find attached to this mail the pre-commit.log

Help greatly appreciated!

--
Amirouche ~ amz3 ~ http://www.hyperdev.frAn unexpected error has occurred: CalledProcessError: Command: 
('/home/amirouche/.guix-profile/libexec/git-core/git', 'clone', 
'--no-checkout', 'https://github.com/ambv/black.git', 
'/home/amirouche/.cache/pre-commit/repo8iqyopmi')
Return code: 128
Expected return code: 0
Output: (none)
Errors: 
Cloning into '/home/amirouche/.cache/pre-commit/repo8iqyopmi'...
fatal: unable to access 'https://github.com/ambv/black.git/': server 
certificate verification failed. CAfile: none CRLfile: none


Traceback (most recent call last):
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/error_handler.py",
 line 47, in error_handler
yield
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/main.py",
 line 261, in main
return run(runner, store, args)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/commands/run.py",
 line 256, in run
for _, hook in repo.hooks:
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/cached_property.py",
 line 35, in __get__
value = obj.__dict__[self.func.__name__] = self.func(obj)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/repository.py",
 line 162, in hooks
if hook['id'] not in self.manifest_hooks:
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/cached_property.py",
 line 35, in __get__
value = obj.__dict__[self.func.__name__] = self.func(obj)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/repository.py",
 line 155, in manifest_hooks
repo_path = self.store.clone(repo, rev)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/store.py",
 line 150, in clone
    return self._new_repo(repo, ref, deps, clone_strategy)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/store.py",
 line 126, in _new_repo
make_strategy(directory)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/store.py",
 line 142, in clone_strategy
cmd_output(*cmd, env=env)
  File 
"/home/amirouche/.local/share/virtualenvs/socialite-J8sGaPJp/lib/python3.6/site-packages/pre_commit/util.py",
 line 177, in cmd_output
returncode, cmd, retcode, output=(stdout, stderr),
pre_commit.util.CalledProcessError: Command: 
('/home/amirouche/.guix-profile/libexec/git-core/git', 'clone', 
'--no-checkout', 'https://github.com/ambv/black.git', 
'/home/amirouche/.cache/pre-commit/repo8iqyopmi')
Return code: 128
Expected return code: 0
Output: (none)
Errors: 
Cloning into '/home/amirouche/.cache/pre-commit/repo8iqyopmi'...
fatal: unable to access 'https://github.com/ambv/black.git/': server 
certificate verification failed. CAfile: none CRLfile: none

Re: Setting up Guile for use with Guix

[Amirouche Boubekki]

On 2018-08-17 14:34, HiPhish wrote:

Hello everyone,



Hello HiPhish,


I am a regular Ubuntu, guix user and I develop stuff using guile.



I have Guix up and running on my Kubuntu 18.04 machine. I installed it
manually
from the binary: I first installed Guile 2.2.3 via apt, then I 
installed Guix.


Wow! ubuntu has a quiet recent guile! that's good news!

What matters when installing guix package manager on top another 
distribution is
only the shell and PID 1. If you use zsh or something fancy as shell, 
you might need to
adapt some of the instructions from the manual. If you don't rely on 
systemd
or upstart again, you will need to adapt the direction given in the 
manual which can
boil down to run guix-daemon as root in the background in a screen. Poor 
man's service,

I know, but it works.

Another thing that might matter is some kernel options, but that is only 
relevant
if you use guix containers. I did not try guix containers for a long 
time,

so it might work out of the box with recent kernels.

Since I am a using both bash and systemd I just follow the instructions 
from

the manual I have nothing specific to do.

The only thing I struggle with is the shell environment variables. That 
is

what outputs the following command as a regular user:

  guix package --search-paths

I just reinstalled ubuntu and guix from binary and I have setup my guile 
dev
environment to run and develop my guile project. Here is the output of 
the above

command:

->8-- START 
->8--->8--->8--->8--->8--->8--


export 
PATH="/home/amirouche/.guix-profile/bin:/home/amirouche/.guix-profile/sbin"
export 
GUILE_LOAD_PATH="/home/amirouche/.guix-profile/share/guile/site/2.2"
export 
GUILE_LOAD_COMPILED_PATH="/home/amirouche/.guix-profile/lib/guile/2.2/site-ccache:/home/amirouche/.guix-profile/share/guile/site/2.2"

export XDG_DATA_DIRS="/home/amirouche/.guix-profile/share"
export GIO_EXTRA_MODULES="/home/amirouche/.guix-profile/lib/gio/modules"
export 
GIT_SSL_CAINFO="/home/amirouche/.guix-profile/etc/ssl/certs/ca-certificates.crt"

export GIT_EXEC_PATH="/home/amirouche/.guix-profile/libexec/git-core"
export 
PKG_CONFIG_PATH="/home/amirouche/.guix-profile/lib/pkgconfig:/home/amirouche/.guix-profile/share/pkgconfig"

export SSL_CERT_DIR="/home/amirouche/.guix-profile/etc/ssl/certs"

->8-- END 
->8--->8--->8--->8--->8--->8--


That is actually the content of ~/.bash_profile file

I added an export EDITOR=emacs because emacs is my editor of choice. For 
some reason,
I always need to source ~/.bash_profile when I want to use guix in a new 
shell.


I wanted to do some more serious Guile work involving libraries, and 
since
Guile does not have a package manager of its own, using Guix is the way 
to go.


If you try guile-hall, don't forget to send us feedback, please :)

Here is my question: how do I properly set up Guile on Guix? I already 
have
Guile set up system-wide (via apt), but packages like Haunt list Guile 
as

their
own dependency. Will this install a second Guile for me (one 
system-wide from

apt and one for the Guix profile from Guix)?


It depends on how haunt package definition is written. Because of how 
guix
works, you can use a program that uses guile without having 'guile' 
command
available. Similarly, it makes it possible to run two programs at the 
same
time that depends on different versions of the same library.. that's 
something
that is very difficult to do outside guix and nix. It's one of the 
consequences
of packaging is done. This leads to the point that in theory, you SHOULD 
never
install _libraries_ in your user profile ie. the regular / default 
profile because
no executable will use it. Default guix profile, SHOULD, I THINK, only 
contain data

and executables.

I say SHOULD everywhere because that's not the way *I* work. Indeed, I 
install
libraries in the user profile instead of relying on guix environment see 
[0].
Because I find guix environment not good enough for my use case. But I 
did not
come around understanding/explaining what the problem is. (The issue, I 
have, is
that I only know how to use environment with a guix.scm package 
definition or manifest.
I don't like that way. I prefer to have a directory with my profile next 
to my
project and then do a bunch of 'guix package -i guile-wiredtiger'. It's 
prolly possible

but I never did it)

[0] 
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-environment.html


Don't skip environment because of me. I actually use environments when I 
need to hack
on guix itself (because the guix.scm file, aka. the file that setups the 
environment

profile, is already written...)


Should I uninstall the Guile from apt?


You can and you SHOULD. To avoid any misunderstandings.

Any server recommendations to run Guix System?

[amirouche]

Hello all,

I would like to buy a rack server (from Algeria (North Africa)) to host in a 
data center and use Guix System.
Looking up the Internet for rack server offering in Algeria doesn't lead to 
good results so far.
So it seems like I will need to import it myself.

I don't need top of the market CPU but I will need something that is x86 ie. 
not arm. I will need a lot of hard disks
but not necessarily SSD since it's more costly. I don't need a GPU. I was said 
IPMI is very useful.

What are you recommendations?

TIA


Amirouche aka. amz3

 

Re: Help understand some guix concepts

[Amirouche Boubekki]

On Mon, Jan 1, 2018 at 8:31 PM Amirouche Boubekki <
amirouche.boube...@gmail.com> wrote:

> Héllo,
>
> It's a long time I did not read the manual. So I read he manual this
> afternoon.
>
> I have to say that I don't really understand some guix concepts and how
> they map to the rest of the world.
>
> Can someone try to explain to me how the following concepts are related to
> each other:
>
> Environments, profiles, gc roots, root filesystem, chroot, containers,
> docker and lxc
>
> TIA
>

Sorry, it deserves a bit more explanation.

I know what *chroot* command is. It change the root directory. For
instance, I can do the following:

$ mkdir tmp && cd tmp
$ tar xvf $(guix pack --symlink=/bin=bin guile)
$ sudo chroot . /bin/guile

And then guile will be running inside the tmp directory without access to
the rest of the filesystem except if I mount --bind something inside the
tmp directory.

As wikipedia explains it <https://en.wikipedia.org/wiki/Chroot#Uses>, it
used for:

- Testing and development
- Dependency control
- Compatibility
- Recovery
- Privilege separation

In the past I used, chroot to run a gentoo build system on top of any other
distribution. The result is that the developer is free to use whatever
distribution they want as long as they can chroot inside the development
*rootfs* which is possibly another distro or another version of the same
distribution.

*Q:* Does chroot guix/sd use chroot?
*Q:* Do guix developers use chroot somehow?

In particular, using chroot, processus are not separated somehow from the
host system; You don't get another IP and you have the same ports namespace.

What I call *root filesystem* is what is found that / in the filesystem
where in debian there is /usr, /proc, /dev etc...

That's the result of the following command:

$ guix system init ~/src/guile/guix/git/gnu/system/install.scm .

Then I can chroot inside that directory if I want and I will be *somewhat*
like in a guixsd.

*Q:* Do guix developers use 'guix system init' in combination with chroot?

Now, I will mention containers. I know little about cgroups, but I know
it's a feature of the Linux kernel.

*Q: *Does guix/sd use cgroups <https://en.wikipedia.org/wiki/Cgroups>?

The most popular tools using cgroups are Docker
<https://en.wikipedia.org/wiki/Docker_(software)> and LXC
<https://en.wikipedia.org/wiki/LXC>. They have very different approach to
containers. AFAIU, Docker re-invent the wheel (?) of how networking,
filesystem and prolly how other stuff happens in the GNU/Linux world.
Whereas LXC re-use concepts with which people that used to play with VMs
are familiar with. For instance, LXC networking setup re-use commands like
ip <https://linux.die.net/man/8/ip> or brctl
<https://linux.die.net/man/8/brctl>. Docker use a concept of images that
made Docker famous and a single command to download & execute whatever
program you want... But the most intriguing thing in Docker, is that they
are against using systemd (or similar tool) inside containers to run
multiple procesus inside the container. Basically, PID 1 in the container
must be the PID of the application. That's why Docker call it: application
containers. Whereas LXC containers are system containers.

One thing that took me long time to understand regarding the distinction
between containers and simple chroot, is that in the case of chroot there
is no processus managing the chroot. Whereas a container appears as
processus in the host system.


*Q: *Does guix/sd containers enforce an image format?
*Q: *Can guix/sd use images? What are the advantages?
*Q: *How does networking happens in guix/sd?
*Q: *Is it possible to bind multiple interfaces via a bridge on the host
system to the container?
*Q: *Is it possible or recommended to run shepherd inside a guix container?

*Q:* isn't AppImage <https://en.wikipedia.org/wiki/AppImage> a
"combination" of 'guix pack' and 'guix container'.

*Q: *Is it possible to have Xorg running inside a container and then use
ssh -X to access it? Is there a way to avoid the ssh -X?

TIA

Re: Introducing GNUPaste (and guile-wiredtiger future)

[Amirouche]

Le 17/12/2017 à 18:35, Kristofer Buffington a écrit :

Amirouche Boubekki <amirou...@hypermove.net> writes:


Héllo,

On 2017-12-14 19:37, Kristofer Buffington wrote:

Hello!

I am excited to share GNUPaste! This is a really simple web app
similar to paste.lisp.org built with Guile. I have a linode running it
from git on GuixSD.

https://paste.freshbakedyams.com (Please use it!)
Source: https://github.com/kristoferbuffington/gnupaste.git

Currently the frontend uses twitter bootstrap + jquery and highlightjs
from a CDN. It really doesn't need all that boilerplate. It will
definitely change in the future. GNUPaste depends on guile-wiredtiger
and guile-fibers to compile.

Thanks for considering guile-wiredtiger.

Basically, guile-wiredtiger is not compatible yet with fiber
in the general case, because fiber will spawn several threads
and several fibers in each thread (and I think that fibers
can be stolen by other threads but I am not sure).

The way wiredtiger works is that there is one
*connexion* (called *environment* in guile wiredtiger)
per database and one *session* per "thread" of execution
(called *context* in guile wiredtiger).

I changed the naming because they are different from the
original things. Both environment and context are backed
by fluids.

In a pre-fork thread model, one must use with-context [1]
after the fork to populate the current fuild with a specific
context.

[1]
https://framagit.org/a-guile-mind/guile-wiredtiger/blob/master/wiredtiger/extra.scm#L328

The thing is that when using fibers, the thread of execution
is a fiber, hence simply said the wiredtiger extra abstraction
called context fails. Because context/session must not be
shared between different fibers even if they are executed in
the same thread.

I have noticed that I get "Resource busy" issues if multiple requests
are handled by the server simultaneously. I tried running (with-env ...)
in the request-handler instead, but it is the same problem. Multiple
environments can't open the database simultaneously either.


I will try to make the 0.8 before the end of the year with a fix.




Otherwise said, guile-wiredtiger extra abstraction context
and environment are handy in single thread context because
it avoids passing the context around. It's also handy in
simple multithread settings where you don't need to pass
environment around (to create a new session per thread).
But it fails in the advanced use case of guile fibers.

This won't trigger a crash under low traffic, but will fail
under load and advanced use of guile wiredtiger, like multiple
statments transactions. This can be mitigated by turning off
preemption in guile-fibers but again it's not perfect solution.

I failed to create an API that makes simple things simple and
complex things possible. There might be an escape if fibers
implemented fluids for fibers something like PEP 550 [2].
But anyway, it won't be perfect, so I will rework the current
databases in guile wiredtiger to completly avoid the use of
fluids and instead pass around database cnx and session.

[2] https://www.python.org/dev/peps/pep-0550/

I started doing this in culturia [3] but it's far from being
complete. Since I need to convert all databases grf3, feature-space
and ix to that style.

Also, it's a backward incompatible change.

[3]
https://github.com/a-guile-mind/culturia.one/commit/15328e53fcb51d43f14de2f9f21d0b309237969a

At the end of the day, I don't think I want to maintain grf3,
feature-space and ix inside guile-wiredtiger because they are
much more than wiredtiger bindings. So I am pondering the fact
that I will drop those databases abstraction from guile wiredtiger
and focus on improving the core bindings (like actionable exceptions)
and maybe improve bindings coverage.

IMHO I think feature-space, ix and grf3  don't really belong in
guile-wiredtiger.


agree


For the next release 0.8 of guile-wiredtiger, the abstractions grf3,
feature-space and ix will be deprecated. And after for 0.9 release
they will be moved to the example folder (or better, forked by
other people to be maintained separatly).

I really like the advanced abstractions. I'm not sure I'm knowledgeable
enough to fork and improve them yet.


This is not happening before I have a replacement for them.
When I think replacement, I think about a database (server?)
that is hopefully both easy to use (in the spirit of mongodb)
but that is also ACID across documents (aka. that cares about
your data).




Ultimately I want to be able to deploy with something like:

$ guix system disk-image gnupaste-system.scm

Then boot it up in a VPS.

That will be neat!


Thanks!
Kris

I really don't want to rely on a database server. It would be easy
enough to store pastes on the filesystem, maybe even with (guix store)
or use git like tekuti and get the benefit of revision history with
paste modifications.


I don't like either the idea of the database server. That said
without one, you have to code a

Re: Introducing GNUPaste (and guile-wiredtiger future)

[Amirouche Boubekki]

Héllo,

On 2017-12-14 19:37, Kristofer Buffington wrote:

Hello!

I am excited to share GNUPaste! This is a really simple web app
similar to paste.lisp.org built with Guile. I have a linode running it
from git on GuixSD.

https://paste.freshbakedyams.com (Please use it!)
Source: https://github.com/kristoferbuffington/gnupaste.git

Currently the frontend uses twitter bootstrap + jquery and highlightjs
from a CDN. It really doesn't need all that boilerplate. It will
definitely change in the future. GNUPaste depends on guile-wiredtiger
and guile-fibers to compile.


Thanks for considering guile-wiredtiger.

Basically, guile-wiredtiger is not compatible yet with fiber
in the general case, because fiber will spawn several threads
and several fibers in each thread (and I think that fibers
can be stolen by other threads but I am not sure).

The way wiredtiger works is that there is one
*connexion* (called *environment* in guile wiredtiger)
per database and one *session* per "thread" of execution
(called *context* in guile wiredtiger).

I changed the naming because they are different from the
original things. Both environment and context are backed
by fluids.

In a pre-fork thread model, one must use with-context [1]
after the fork to populate the current fuild with a specific
context.

[1] 
https://framagit.org/a-guile-mind/guile-wiredtiger/blob/master/wiredtiger/extra.scm#L328


The thing is that when using fibers, the thread of execution
is a fiber, hence simply said the wiredtiger extra abstraction
called context fails. Because context/session must not be
shared between different fibers even if they are executed in
the same thread.

Otherwise said, guile-wiredtiger extra abstraction context
and environment are handy in single thread context because
it avoids passing the context around. It's also handy in
simple multithread settings where you don't need to pass
environment around (to create a new session per thread).
But it fails in the advanced use case of guile fibers.

This won't trigger a crash under low traffic, but will fail
under load and advanced use of guile wiredtiger, like multiple
statments transactions. This can be mitigated by turning off
preemption in guile-fibers but again it's not perfect solution.

I failed to create an API that makes simple things simple and
complex things possible. There might be an escape if fibers
implemented fluids for fibers something like PEP 550 [2].
But anyway, it won't be perfect, so I will rework the current
databases in guile wiredtiger to completly avoid the use of
fluids and instead pass around database cnx and session.

[2] https://www.python.org/dev/peps/pep-0550/

I started doing this in culturia [3] but it's far from being
complete. Since I need to convert all databases grf3, feature-space
and ix to that style.

Also, it's a backward incompatible change.

[3] 
https://github.com/a-guile-mind/culturia.one/commit/15328e53fcb51d43f14de2f9f21d0b309237969a


At the end of the day, I don't think I want to maintain grf3,
feature-space and ix inside guile-wiredtiger because they are
much more than wiredtiger bindings. So I am pondering the fact
that I will drop those databases abstraction from guile wiredtiger
and focus on improving the core bindings (like actionable exceptions)
and maybe improve bindings coverage.

For the next release 0.8 of guile-wiredtiger, the abstractions grf3,
feature-space and ix will be deprecated. And after for 0.9 release
they will be moved to the example folder (or better, forked by
other people to be maintained separatly).


Ultimately I want to be able to deploy with something like:

$ guix system disk-image gnupaste-system.scm

Then boot it up in a VPS.


That will be neat!



Thanks!
Kris


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: Help neeeded to package guile-wiredtiger and microkanren

[Amirouche]

Hi!


Le 01/06/2017 à 13:40, Adonay Felipe Nogueira a écrit :

Hi Amirouche! :)

What is the status of this?

I found someone for the task. Thanks for showing up nonetheless.

- Was there any previous attempt?

Yes but I deleted the files.

   - What are the findings so far?
- Does it need a system service to be running?


No! It's a library, it works like sqlite except it's multithread.



- Since your last message, is there someone working on this now?



Yes.

Have a good day!

Help neeeded to package guile-wiredtiger and microkanren

[Amirouche]

Héllo

I am willing to pay 100€ or offer equivalent work for someone that will
package guile-wiredtiger and microkanren.

guile-wiredtiger [1] is a binding of wiredtiger for guile using ffi.
It doesn't have autotools, I'd rather keep it that way. The guix package
must run the test suite as per guix standard. wiredtiger is already 
packaged.


[1] https://framagit.org/a-guile-mind/guile-wiredtiger

microkanren is a micro version of minikanren. That is a single file project
that should be straightforward to package. Same I'd rather not have to deal
with autotools. microkanren doesn't have any dependency outside guile 2.2.

[2] https://framagit.org/a-guile-mind/microkanren

Payment will happen upon the patches are accepted in guix.

Please do not work on packaging this stuff before contacting me to agree on
a payment method.

I am amz3 on IRC.


Thanks in adavance,


Amirouche ~ amz3 ~ http://hyperdev.fr

Re: is it me ?

[Amirouche]

Le 03/05/2017 à 21:08, myglc2 a écrit :

On 05/03/2017 at 18:05 Catonano writes:


2017-05-02 20:58 GMT+02:00 myglc2 :

  As it stands, your video is a great sanity check for someone wondering
  if their emacs-guix environment is working properly. It is also a great
  demonstration of how easy it is for a guix user to see and, with a git
  checkout, modify a package.

  If you expanded it a bit to illustrate a few
  more guix-edit/geiser features, it could be a great addition to the
  guix-video-verse, and, IMO, a good thing to add to www.gnu.or

Which eatures, exactly, you would like to be showed ?

How about a scenario like this, all done from within emacs-guix running
against a git checkout ...

- find a package

- install it

- observe how it is working

- consider changing a config flag

- 'M-x Guix edit '

- download the source: 'C-u . s'

- copy the package source out of the store (there is probably a better
   thing to do here)

- in  source: './configure --help' to see config options

- 'M-x Guix edit ' & modify #:configure-flags

- build the package: 'C-u . b'

- install the new version

- verify the package behavior has changed

- commit the change

- produce a potential guix patch

Note: I am not a 'M-x guix-edit' "daily driver". I hope others who are
will comment/improve the outline.

ISTM this scenario is useful because ...

1) it shows the control that guix gives to users

2) a knowledgeable  user can follow it to help improve how
 runs in guix.

HTH - George


+1

Failed to install guile-bytestructures

[Amirouche]

Héllo!

When I try to install guile-bytestructures, guix reports a success
but the content of guile-bytestructures directory is empty.
Also there is bizarre warning+error when I run guix:

amirouche@ubudec:~/src/guile/guix$ guix build --check guile-bytestructures
;;; WARNING: loading compiled file 
/home/amirouche/.guix-profile/lib/guile/2.2/site-ccache/gnutls.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object 
file: "\x7fELF\x02\x01\x01�\x00\x00\x00\x00\x00\x00\x00\x00"
@ build-started 
/gnu/store/p3w0wnfbc5kqsnwc2h72lmnh7k4mq14d-guile-bytestructures-20170402.91d042e.drv 
- x86_64-linux 
/var/log/guix/drvs/p3//w0wnfbc5kqsnwc2h72lmnh7k4mq14d-guile-bytestructures-20170402.91d042e.drv.bz2
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/base.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/base.syntactic.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/bitfields.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/explicit-endianness.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/numeric.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/string.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/struct.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/union.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/utils.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/body/vector.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/base.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/bitfields.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/bytevectors.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/cstring-pointer.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/explicit-endianness.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/ffi.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/numeric-all.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/numeric-data-model.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/numeric-metadata.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/numeric.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/pointer.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/string.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/struct.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/union.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/utils.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/guile/vector.go'
wrote 
`/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e/share/guile/site/2.2/bytestructures/r6/bytevectors.go'

/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-bytestructures-20170402.91d042e

Then:

amirouche@ubudec:~/src/guile/guix$ tree 
/gnu/store/h4m863d310mfmshypshy9jr3xlhsjscd-guile-byte

Re: What about dependency resolution à la apt?

[Amirouche]

Le 16/03/2017 à 21:28, Tobias Geerinckx-Rice a écrit :

Amirouche,

On 16/03/17 19:52, Amirouche wrote:

Héllo,

Hi!

I'm not the most technically qualified person to answer this, nor the
most articulate, but I'm mainly curious and slightly puzzled as to why
this question keeps popping up.


Sorry!


I hope others will join in, since I fear
this hints at some fundamental misunderstandings about Guix that might
hurt world d^W^W adoption.


Maybe patch the FAQ?




AFAIU guix does hardcode the dependencies so that to know the
dependencies one has onlytocrawl the dependency DAG using a BFS or
something. I don't know what is the exact part in guix that does
that. It's only my understanding.

This doesn't happen.[1]

It takes some getting used to when you're used to old-school package
managers where the resolver is A Big Deal, or even The Biggest Deal:
Gentoo, anyone?


Yes.. But autoconf does the same, it specify some dependency
that can match patch or minor version number.


But one of the many great things about functional package management à
la Nix/Guix is that you don't need — or want — a dependency resolver. At
all. That eliminates a lot of nasty problems, and makes others much
easier to solve.

Huge Deal.


What about having apt-like dependency resolution, also like npm
where version are specified in terms of "superior to", "equal to"
taking advantage of semantic versionning?[2]

Guix already does ‘equal to’ better than anyone. Bit-identical, even.


That's is off topic?

What about dependency resolution à la apt?

[Amirouche]

Héllo,

AFAIU guix does hardcode the dependencies so that to know the dependencies
one has onlytocrawl the dependency DAG using a BFS or something. I don't
know what is the exact part in guix that does that. It's only my 
understanding.


What about having apt-like dependency resolution, also like npm where 
version
are specified in terms of "superior to", "equal to" taking advantage of 
semantic

versionning?

tx!

Re: Debian Install Instructions

[amirouche]

On 14/03/2017 00:50, iekath@mail2tor wrote:

Hello. I'm a Guix noob running Debian and I'm finding it difficult to
install.

Can you please change the install instructions to show exactly how to do
each step on Debian to run it?



I am using Debian on my server and had no issue with the installation
instruction.

Can you explain what you did and failed?

Regards,


Amirouche