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: It's time to build "guix deploy"

[Amirouche Boubekki]

On 2019-02-11 15:47, Christopher Lemmer Webber wrote:

Pjotr Prins writes:


I am also interested in 'guix deploy', especially if it can run on top
of Debian and handle HOME directories. Currently using a mixture of
sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
to switch, test and hack. But not enough time to run with it.

Pj.


I am trying to think, "what can I do to help advance things further",
and maybe my best next step is to write minimalist user stories with
mockups of configurations and deployments based off of davexunit's old
branch?  That way I can think through what's there and what I need yet.

 - Chris



Great idea!

Re: ‘staging’ merged!

[Amirouche Boubekki]

Great!

So it is time for guix pull && guix package -u?

Le sam. 9 févr. 2019 à 15:58, Ludovic Courtès  a écrit :

> Hello Guix!
>
> I’ve just merged the ‘staging’ branch as ‘guix weather’ reported a
> rather sunny day.
>
> If you stumble upon build issues or bugs, please do report them and
> let’s address them together.
>
> Thanks to everyone who took care of this branch!
>
> Ludo’.
>

Re: New videos: topic daily use.

[Amirouche Boubekki]

On 2019-02-08 18:43, Ricardo Wurmus wrote:

Björn Höfling  writes:


> I was thinking of daily use of guix package, mentioning profile,
> generations (both the concepts and commands to deal with them)

Sounds good.  “--install”, “--roll-back”, and maybe even “--manifest”
for stateless installations would be good topics to cover.


Is "--manifest" really "daily use" for a Guix newbie? I would disagree
and first stick to the "--install" --"remove "--rollback"
"--list-generations" mode.


You’re probably right.  I keep recommending the use of manifests here 
at

work, but I suppose this could be explained in another video (with a
focus on reproducibility maybe).


I am also looking for a video about manifests.

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

Re: Guix Days starting in two days!

[Amirouche Boubekki]

Le mar. 29 janv. 2019 12:09, Andreas Enge  a écrit :

> On Tue, Jan 29, 2019 at 10:58:24AM +0100, Ludovic Courtès wrote:
> > We’ll update  as
> > needed to share practical info.  Please email Pjotr, Manolis, Ricardo,
> > or myself if you have any questions.
>
> And since we need to book food now, please tell us if you are mentioned
> on the wiki page, but finally will not attend; or vice versa.
>

Sorry,  I won'the be there.


>

Re: e3 package don't work!!

[Amirouche Boubekki]

Seems like it's a known bug. Try using another kernel as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913014 or apply the patch!

Le dim. 6 janv. 2019 à 21:08, Amirouche Boubekki <
amirouche.boube...@gmail.com> a écrit :

>
>
> Le dim. 6 janv. 2019 à 21:03, Guy fleury  a écrit :
>
>> guy@guixSd ~$ strace e3
>> execve("/home/guy/.guix-profile/bin/e3", ["e3"], 0x7ffc330ee950 /* 63
>> vars */) = -1 EEXIST (File exists)
>> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
>> +++ killed by SIGSEGV +++
>> Segmentation fault
>>
>
> Internet says it requires to reproduce to debug. I will try to reproduce
> then :)
>
>
>> attach dmesg output
>>
>
> Those lines are suspicious:
>
> [  815.422533] 1423 (e3): Uhuuh, elf segment at 0804b000 requested
> but the memory is mapped already
> [  846.447644] 1487 (e3): Uhuuh, elf segment at 0804b000 requested
> but the memory is mapped already
> [  855.708685] 1498 (e3): Uhuuh, elf segment at 0804b000 requested
> but the memory is mapped already
>
>
>
>>
>>
>> Le dim. 6 janv. 2019 à 19:05, Amirouche Boubekki <
>> amirouche.boube...@gmail.com> a écrit :
>>
>>> can you attach the dmesg output and strace?
>>>
>>> Le dim. 6 janv. 2019 à 16:23, Guy fleury  a écrit :
>>>
>>>> hi all,
>>>>
>>>> this package does't work for me:
>>>> guy@guixSd ~$ e3
>>>> Segmentation fault
>>>>
>>>> guy@guixSd ~$ uname -a
>>>> Linux guixSd 4.19.8-gnu #1 SMP 1 x86_64 GNU/Linux
>>>>
>>>> thanks,
>>>> guy
>>>>
>>>>
>>>>

Re: e3 package don't work!!

[Amirouche Boubekki]

Le dim. 6 janv. 2019 à 21:03, Guy fleury  a écrit :

> guy@guixSd ~$ strace e3
> execve("/home/guy/.guix-profile/bin/e3", ["e3"], 0x7ffc330ee950 /* 63 vars
> */) = -1 EEXIST (File exists)
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
> +++ killed by SIGSEGV +++
> Segmentation fault
>

Internet says it requires to reproduce to debug. I will try to reproduce
then :)


> attach dmesg output
>

Those lines are suspicious:

[  815.422533] 1423 (e3): Uhuuh, elf segment at 0804b000 requested
but the memory is mapped already
[  846.447644] 1487 (e3): Uhuuh, elf segment at 0804b000 requested
but the memory is mapped already
[  855.708685] 1498 (e3): Uhuuh, elf segment at 0804b000 requested
but the memory is mapped already



>
>
> Le dim. 6 janv. 2019 à 19:05, Amirouche Boubekki <
> amirouche.boube...@gmail.com> a écrit :
>
>> can you attach the dmesg output and strace?
>>
>> Le dim. 6 janv. 2019 à 16:23, Guy fleury  a écrit :
>>
>>> hi all,
>>>
>>> this package does't work for me:
>>> guy@guixSd ~$ e3
>>> Segmentation fault
>>>
>>> guy@guixSd ~$ uname -a
>>> Linux guixSd 4.19.8-gnu #1 SMP 1 x86_64 GNU/Linux
>>>
>>> thanks,
>>> guy
>>>
>>>
>>>

Re: Brain storming cool Guix features

[Amirouche Boubekki]

Le dim. 6 janv. 2019 à 17:33, swedebugia  a écrit :

> Amirouche Boubekki  skrev: (6 januari 2019
> 14:44:30 CET)
> >Le ven. 4 janv. 2019 à 18:14,  a écrit :
> >
> >
> >> - Guile and Scheme for Beginners book.
> >>
> >
> >Regarding this topic, I just made a mini game to teach scheme, there
> >very
> >few exercices, let me know what you think
> >
> >http://scheme-lang.com/cons/
>
> I like it!
>

Thanks a lot! I forgot to point out that the code is available at your own
risk at https://github.com/amirouche/scheme-lang/

A tentative explanation of how it works is over the moutain at
https://groups.google.com/forum/#!topic/chibi-scheme/UW11XvoAF1c


> Maybe we could make a guix variant. Maybe enable selection of topics in
> the beginning like: config, packaging, derivations...
>

With that tool at hand, we can imagine many things. My primary thoughts was
about learning scheme hence guile (even if it's a variant of scheme, a lot
of concepts are shared between the two). But we could use it to provide
questions with multiple answers to learn guix specifically.

Re: e3 package don't work!!

[Amirouche Boubekki]

can you attach the dmesg output and strace?

Le dim. 6 janv. 2019 à 16:23, Guy fleury  a écrit :

> hi all,
>
> this package does't work for me:
> guy@guixSd ~$ e3
> Segmentation fault
>
> guy@guixSd ~$ uname -a
> Linux guixSd 4.19.8-gnu #1 SMP 1 x86_64 GNU/Linux
>
> thanks,
> guy
>
>
>

Re: Brain storming cool Guix features

[Amirouche Boubekki]

Le ven. 4 janv. 2019 à 18:14,  a écrit :


> - Guile and Scheme for Beginners book.
>

Regarding this topic, I just made a mini game to teach scheme, there very
few exercices, let me know what you think

http://scheme-lang.com/cons/

Re: improve installation instructions

[Amirouche Boubekki]

Le sam. 5 janv. 2019 17:59, Ricardo Wurmus  a écrit :

> Hey,
>
> I just installed Guix as a package manager on an aarch64 box.  The
> manual makes it a little difficult to perform all these steps, because
> the commands cannot be easily copied.  We do have the shell script, but
> the manual mentions it only in passing – as a user I skipped over the
> introduction and went straight to step 1, right past the script.
>
> What do you think about mentioning the script in the Installation
> section and only asking users to look in the subsections for details?
>
> Here’s a draft patch:
>
> --8<---cut here---start->8---
> diff --git a/doc/guix.texi b/doc/guix.texi
> index fcb5b8c08..f9afe2bc3 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -25,7 +25,7 @@ Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
>  Copyright @copyright{} 2014 Pierre-Antoine Rault@*
>  Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
>  Copyright @copyright{} 2015, 2016, 2017 Leo Famulari@*
> -Copyright @copyright{} 2015, 2016, 2017, 2018 Ricardo Wurmus@*
> +Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus@*
>  Copyright @copyright{} 2016 Ben Woodcroft@*
>  Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
>  Copyright @copyright{} 2016, 2017, 2018 Efraim Flashner@*
> @@ -394,29 +394,32 @@ garbage collection of packages (@pxref{Features}).
>  @chapter Installation
>
>  @cindex installing Guix
> -@cindex official website
> -GNU Guix is available for download from its website at
> -@url{http://www.gnu.org/software/guix/}.  This section describes the
> -software requirements of Guix, as well as how to install it and get
> -ready to use it.
>
> -Note that this section is concerned with the installation of the package
> -manager, which can be done on top of a running GNU/Linux system.  If,
> -instead, you want to install the complete GNU operating system,
> -@pxref{System Installation}.
> +We recommend the use of this
> +@uref{
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
> +shell installer script} to install Guix on top of a running GNU/Linux
> system,
> +thereafter called a @dfn{foreign distro}.@footnote{This section is
> concerned
> +with the installation of the package manager, which can be done on top of
> a
> +running GNU/Linux system.  If, instead, you want to install the complete
> GNU
> +operating system, @pxref{System Installation}.} The script automates the
> +download, installation, and initial configuration of Guix.  It should be
> run
> +as the root user.
>
>  @cindex foreign distro
>  @cindex directories related to foreign distro
> -
> -When installed on a running GNU/Linux system---thereafter called a
> -@dfn{foreign distro}---GNU@tie{}Guix complements the available tools
> -without interference.  Its data lives exclusively in two directories,
> -usually @file{/gnu/store} and @file{/var/guix}; other files on your
> -system, such as @file{/etc}, are left untouched.
> +When installed on a foreign distro, GNU@tie{}Guix complements the
> available
> +tools without interference.  Its data lives exclusively in two
> directories,
> +usually @file{/gnu/store} and @file{/var/guix}; other files on your
> system,
> +such as @file{/etc}, are left untouched.
>
>  Once installed, Guix can be updated by running @command{guix pull}
>  (@pxref{Invoking guix pull}).
>
> +If you prefer to perform the installation steps manually or want to tweak
> +them, you may find the following subsections useful.  They describe the
> +software requirements of Guix, as well as how to install it manually and
> get
> +ready to use it.
> +
>  @menu
>  * Binary Installation:: Getting Guix running in no time!
>  * Requirements::Software needed to build and run Guix.
> @@ -437,11 +440,6 @@ dependencies.  This is often quicker than installing
> from source, which
>  is described in the next sections.  The only requirement is to have
>  GNU@tie{}tar and Xz.
>
> -We provide a
> -@uref{
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
> -shell installer script}, which automates the download, installation, and
> -initial configuration of Guix.  It should be run as the root user.
> -
>  Installing goes along these lines:
>
>  @enumerate
> @@ -638,6 +636,10 @@ build procedure for Guix is the same as for other GNU
> software, and is
>  not covered here.  Please see the files @file{README} and @file{INSTALL}
>  in the Guix source tree for additional details.
>
> +@cindex official website
> +GNU Guix is available for download from its website at
> +@url{https://www.gnu.org/software/guix/}.
> +
>  GNU Guix depends on the following packages:
>
>  @itemize
> --8<---cut here---end--->8---
>

LGTM

>

Re: [Cuirass] Missing database indexes?

[Amirouche Boubekki]

Did you consider using wiredtiger?

Le lun. 19 nov. 2018 à 11:47, Danny Milosavljevic 
a écrit :

> Hi Ludo,
>
> >It doesn’t seem to help much, perhaps because the query is too complex?
>
> Yeah, probably.
>
> According to the docs a log message is supposed to appear when it is doing
> it.
>
> We should just special-case the common queries so the optimizer has a
> easier life.
>

Re: [Cuirass] Missing database indexes?

[Amirouche Boubekki]

Hello all,

Le lun. 12 nov. 2018 à 19:51, Björn Höfling <
bjoern.hoefl...@bjoernhoefling.de> a écrit :

> Hi Ludo,
>
> On Sun, 11 Nov 2018 18:06:00 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
> > Indeed, that solves the problem for this simple example, thanks!
> >
> > Now, if I go back to the big query that /api/latestbuilds makes¹, the
> > result is still pretty bad:
> >
> > --8<---cut here---start->8---
> > sqlite> EXPLAIN QUERY PLAN SELECT * FROM (
> >...> SELECT Builds.derivation, Builds.rowid, Builds.timestamp,
> > Builds.starttime, ...> Builds.stoptime, Builds.log, Builds.status,
> > Builds.job_name, Builds.system, ...> Builds.nix_name,
> > Specifications.name ...> FROM Builds
> >...> INNER JOIN Evaluations ON Builds.evaluation = Evaluations.id
> >...> INNER JOIN Specifications ON Evaluations.specification =
> > Specifications.name ...> WHERE (:id IS NULL OR (:id = Builds.rowid))
> >...> AND (:derivation IS NULL OR (:derivation = Builds.derivation))
> >...> AND (:jobset IS NULL OR (:jobset = Specifications.name))
> >...> AND (:job IS NULL OR (:job = Builds.job_name))
> >...> AND (:system IS NULL OR (:system = Builds.system))
> >...> AND (:evaluation IS NULL OR (:evaluation = Builds.evaluation))
> >...> AND (:status IS NULL OR (:status = 'done' AND Builds.status
> > >= 0) ...>  OR (:status = 'pending' AND
> > >Builds.status < 0)
> >...>  OR (:status = 'succeeded' AND
> > Builds.status = 0) ...>  OR (:status = 'failed'
> > AND Builds.status > 0)) ...> AND (:borderlowtime IS NULL
> > OR :borderlowid IS NULL ...>  OR ((:borderlowtime, :borderlowid) <
> > (Builds.stoptime, Builds.rowid))) ...> AND (:borderhightime IS NULL
> > OR :borderhighid IS NULL ...>  OR ((:borderhightime, :borderhighid) >
> > (Builds.stoptime, Builds.rowid))) ...> ORDER BY
> >...> CASE WHEN :borderlowtime IS NULL
> >...>OR :borderlowid IS NULL THEN Builds.stoptime
> >...>ELSE -Builds.stoptime
> >...> END DESC,
> >...> CASE WHEN :borderlowtime IS NULL
> >...>OR :borderlowid IS NULL THEN Builds.rowid
> >...>ELSE -Builds.rowid
> >...> END DESC
> >...> LIMIT :nr)
> >...> ORDER BY stoptime, rowid ASC;
> > 1|0|0|SCAN TABLE Builds
> > 1|1|1|SEARCH TABLE Evaluations USING INTEGER PRIMARY KEY (rowid=?)
> > 1|2|2|SEARCH TABLE Specifications USING COVERING INDEX
> > sqlite_autoindex_Specifications_1 (name=?) 1|0|0|USE TEMP B-TREE FOR
> > ORDER BY 0|0|0|SCAN SUBQUERY 1
> > 0|0|0|USE TEMP B-TREE FOR ORDER BY
> > --8<---cut here---end--->8---
> >
> > I don’t really know what additional index to create (and I’d rather
> > let SQLite do it for me, if it were possible).
>
> I don't know if there is any automated process to assist you. I have
> the feeling that query optimization is more an art than science.
>
>
Hm. This code smells ... It looks too complicated.
>

Agreed.


>
> I don't know if this brings you further concerning performance, here
> are some thoughts:
>
> One problematic part is this construct:
>
> :variable IS NULL OR :variable=my_column)
>
> Here is a very simple example:
>
> sqlite> CREATE TABLE tst (
>...> id INTEGER PRIMARY KEY AUTOINCREMENT,
>...> name TEXT NOT NULL,
>...> age INTEGER NOT NULL);
> sqlite> CREATE INDEX tst_name_age_idx ON tst(name, age);
>
> sqlite> EXPLAIN QUERY PLAN
>...> SELECT * FROM tst WHERE (23=23 OR id=:id);
> 0|0|0|SCAN TABLE tst
>
> sqlite> EXPLAIN QUERY PLAN
>...> SELECT * FROM tst WHERE id=:id;
> 0|0|0|SEARCH TABLE tst USING INTEGER PRIMARY KEY (rowid=?)
>
> sqlite> EXPLAIN QUERY PLAN
>...> SELECT * FROM tst WHERE name=:name AND age < 42;
> 0|0|0|SEARCH TABLE tst USING COVERING INDEX tst_name_age_idx (name=? AND
> age
> So, even when we have a constant part(23=23) in the OR clause, this
> leads to a full table scan. I think the optimizer cannot detect the
> fact that it is a constant boolean value. In the other examples, it is
> using the index.
>
> Even this OR-clause with two variables looks better:
>
> SELECT * FROM tst WHERE (id=:id1 OR id=:id2);
> 0|0|0|SEARCH TABLE tst USING INTEGER PRIMARY KEY (rowid=?)
> 0|0|0|EXECUTE LIST SUBQUERY 1
>
> I double-checked with Postgresql and it is also performing a full table
> scan in the "boolean-constant OR :id=id" case. I could not find any
> references on the net about it.
>
> When this would be Java/JPA I would suggest to dynamically create the
> query. Can we do something in Scheme-DB too? I.e. pseudo-code
>
> (string-append sql-prefix
>   (unless (empty? derivation) "AND :derivation=Builds.derivation")
>   (unless (empty? jobset) "AND :jobset=Builds.jobset)
>   ...)
> ;;; Should be more some kind of folding, because of the "AND"
>
> ;;; Parameter-filling needs to be considered too
>
>
> Two more things I noticed that are not directly 

Re: Membership disabled due to excessive bounces

[Amirouche Boubekki]

On 2018-11-11 11:58, Pierre Neidhardt wrote:

Hi Guix,



Hi!



I've re-enabled my membership both times.

My email is hosted by https://gandi.net (I use their email hosting
service).  I send emails with Emacs' mu4e if that matters.

Does anyone know why this happens?  I've never had this issue before
with any other mailing list (most of them also hosted by Mailman).


I have the same issue with gandi, I use the webmail.



--
Pierre Neidhardt
https://ambrevar.xyz/


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

Re: CLI reorganization revisited

[Amirouche Boubekki]

>
> I do not understand how args work. Is this documented somewhere?
>
> Also I do not understand this form:
>
> (define (guix-describe . args)
>^
> What is the role of the dot?
>


The dot serve as a separator between 'required' argument and 'rest'
arguments which is always a list that might be empty.
In the above case everything passed to the procedure guix-describe is
considered part of args.

HTH

Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to package-recipes

[Amirouche Boubekki]

Hello,

Like Pjotr I think it's a very good idea and the way forward.

Find below my comments with some modulation.

Le jeu. 1 nov. 2018 à 10:39, swedebugia  a écrit :
>
> Hi
>
> I am a contributor to OSM and have seen how combining OSM and 
> Wikidata/Wikipedia (WP) has been very useful.
>
> I got the idea of adding Wikidata-entries to guix package objecs would be 
> fruitful because:

The idea is to add a wikidata identifier for guix packages.

For those that are not familiar with wikidata here is a little summary
of my own.

wikidata is wikimedia project that put together structured data about the world.
wikidata is itself a wiki like wikipedia that anybody can improve it. The goal
of the project is to have a machine readable form of knowledge. One of the use
case for that, is to easily keep wikipedia (and other wik) up-to-date regarding
metadata. Simply said, one could generate, so called, info boxes on wikipedia
from wikidata.

See https://www.wikidata.org/wiki/Q937466 for GNU mailman wikidata entity.

> It makes it possible to a more useful list of packages e.g. by showing links 
> to WP entries for the program in the users local language.
> (E.g. by firing up a browser from emacs or the shell, or by populating a (per 
> channel) html package list (with screenshots, local WP-links, etc.)
> and firing up a throw-away web-server instance serving this with e.g. guix 
> package --list-available-packages-html)

The benefits for guix project:

Immediate benefit:

- It will be easier to translate description and synopsis
- Improve guix packages discover-ability via wikidata SPARQL endpoint
(e.g. give me all guix packages that deal with biology)
- Grab screenshot and other media or metadata about a given package

Other benefits:

- If upstream and other distro adopt wikidata as the Single Source Of
Truth, it will help with packaging and keeping guix up-to-date
- Everything is connected!

> It would also perhaps be of benefit to WP-contributors because we could 
> easily make statistics for how many of the packages
> in guix a Wikidata-entry and/or WP-entry exists. Thus perhaps leading to 
> creating of more articles for notable packages or improving
> WP-articles with outdated release information.

This will be of great benefit for wikidata.

>
> Implementation:
>
> It could be implemented by adding the fields to package-objects.

nitpick, those are records in guile scheme.

> The rationale for adding screenshot-url to the recipe is that this parsing of 
> wikidata->en-WP->url-for-first-image
> for every package in our list is quite expensive. Better to do it once and 
> perhaps update all the screenshot-urls
> once a year or so.

I think the screenshot-url field will not be very helpful that can be
fetched based on wikidata identifier.

>
> The rationale for adding WP (list of Wikipeidas with an article in the 
> wikidata entry, e.g. ("en" "sv" "es")
> to the recipe is that this parsing of wikidata->WP for every package in our 
> list is quite expensive. Better
> to do it once and perhaps update  once a year or so.

Based on the wikidata entry, you can use SPARQL to retrieve the
wikipedia page in various language
and use wikipedia commons links to fetch screenshot.

Simply said, I think we should not add more fields than necessary to
build the package and push to wikidata
the information guix might need for other purposes than distribution and build.

The benefit of this approach is that package definition is not
overloaded with fields and non-code contributors
can still contribute to guix by submitting a screenshot to wikipedia
commons and editing wikidata.

Re: GNU Mes 0.17 released [alpha]

[Amirouche Boubekki]

Le mar. 21 août 2018 à 23:43, Arne Babenhauserheide  a écrit :
>
>
> Jan Nieuwenhuizen  writes:
>
> > We are delighted to announce the release of GNU Mes 0.17, representing
> > 64 commits over 6 weeks.
> >
> > Mes is now an official GNU package and we have bootstrapped gcc-4.7.4
> > for x86-linux with a reduced binary seed (i.e., without regular toolchain).
>
> You are awesome! Thank you!

Very inspiring work!  Thanks for sharing!

Re: FOSDEM 2019 - devroom proposal

[Amirouche Boubekki]

Le ven. 31 août 2018 à 19:49, Pjotr Prins  a écrit :
>
> On Fri, Aug 31, 2018 at 07:40:35PM +0200, Amirouche Boubekki wrote:
> > > How about a dev-room for 'fun freedom programming languages'. It may get
> > > a
> > > white space talk. Then, if I think of the work on MES and Guix it may
> > > not be that great a fit. My point is that we should name the room that
> > > will fit these projects
> > >
> > > - MES reproducible from soucre bootstrap
> > > - Guile Guix
> > > - Guile Cuirass
> > > - Guile JIT
> > > - Guile Sheperd
> > > - Lua JIT
> > >
> > > and then more...
> >
> > I agree.
> >
> > Is it ok if I rework http://community.schemewiki.org/?FOSDEM2019
> > so that it claims that there is a 'minimalistic language' devroom proposal
> > that will be made taking into account what people propose on that page?
>
> Yes, please.
>
> > Also, I would like to copy/paste the proposals from [0] to that wiki page so
> > that people see that there are actually more people interested in such a
> > room.
> >
> > [0] 
> > https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#A_list_of_proposed_talks_for_a_GNU_Guile.2FGuix_track_.40FOSDEM_2019
>
> Good idea.
>
> > > Note that 'fun freedom programming languages' is already too long a
> > > name for a devroom.
> > >
> >
> > Ok
> >
> > > > One has 6 months to prepare.
> > >
> > > But we only have 3 weeks to apply for a dev-room.
> >
> > ack
>
> I modified the subject to reflect this effort. It is quite separate
> from the Guix days.
>
> Ping me when you are done - I'll send a message to the FOSDEM mailing
> list too. See what they think.

Done @ http://community.schemewiki.org/?FOSDEM2019

I also pinged #scheme and racketeers.

What about LUA people?

>
> Thanks again! We'll have some fun :)
>
> Pj.
>

Re: FOSDEM 2019

[Amirouche Boubekki]

On 2018-08-31 11:35, Pjotr Prins wrote:

Thanks Amirouche,

On Thu, Aug 30, 2018 at 09:38:56PM +0200, Amirouche Boubekki wrote:

On 2018-08-30 20:20, Pjotr Prins wrote:
> Just to clarify, we will organize a two day Guix conference before
> FOSDEM. That is pretty much in the box. We have room at ICAB, the place
> we were last year.
>
>   http://icab.be/

About the specifically guix event, maybe it's a good time to organize
an install party. Also, let's be clear upfront if that the fringe 
event

can include those kind of work: poster, workshop, tutorial... anything
else to add?


I think we'll focus those days on the development effort.


Alright!



At FOSDEM it is possible to get a stand. That would be a good place to
help people start up. Or, if we get a dev-room, we can use it to
install stuff on the side. At least, make the offer.

Tutorials would fit there too.





Fun +1



:]


How about a dev-room for 'fun freedom programming languages'. It may 
get a

white space talk. Then, if I think of the work on MES and Guix it may
not be that great a fit. My point is that we should name the room that
will fit these projects

- MES reproducible from soucre bootstrap
- Guile Guix
- Guile Cuirass
- Guile JIT
- Guile Sheperd
- Lua JIT

and then more...


I agree.

Is it ok if I rework http://community.schemewiki.org/?FOSDEM2019
so that it claims that there is a 'minimalistic language' devroom 
proposal

that will be made taking into account what people propose on that page?

Also, I would like to copy/paste the proposals from [0] to that wiki 
page so
that people see that there are actually more people interested in such a 
room.


[0] 
https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#A_list_of_proposed_talks_for_a_GNU_Guile.2FGuix_track_.40FOSDEM_2019




Note that 'fun freedom programming languages' is already too long a
name for a devroom.



Ok


One has 6 months to prepare.


But we only have 3 weeks to apply for a dev-room.


ack

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

> > >If we want an
> > improved label for the Guix system distribution, the best one is
> > probably "GuixOS" since "OS" is a widely used and recognized
> > abbreviation ...
>
> Is exactly my opinion also, so it gets a +1
>

Top 3:

1) GuixOS
2) Guix
3) Guix System

Re: FOSDEM 2019

[Amirouche Boubekki]

On 2018-08-30 21:38, Amirouche Boubekki wrote:

Open Space Technology (OST) is a method for organizing and running a 
meeting or multi-day conference, where participants have been invited in 
order to focus on a specific, important task or purpose. OST is a 
participant-driven process whose agenda is created by people attending. 
At the end of each OST meeting, a document is created summarizing the 
work of the group.


I already participated in such event as part of software craftman paris 
meetup and django cong 2012




I have a book called 'Open Space Technology' it's about organizing
meetings and events. I will read skim over it tonight. And (try) 
provide

feedback about the latest advancement in psychohistory engineering.



That book has a wikipedia page : 
https://en.wikipedia.org/wiki/Open_Space_Technology

Re: FOSDEM 2019

[Amirouche Boubekki]

On 2018-08-30 20:20, Pjotr Prins wrote:

Just to clarify, we will organize a two day Guix conference before
FOSDEM. That is pretty much in the box. We have room at ICAB, the place
we were last year.

  http://icab.be/


About the specifically guix event, maybe it's a good time to organize
an install party. Also, let's be clear upfront if that the fringe event
can include those kind of work: poster, workshop, tutorial... anything
else to add?


In addition to the Guix conference there is the possibility to have a
dev-room at FOSDEM, but we need to apply for it. If the interest is as
underwhelming as it is now I think we better forget about it. These
things take effort to organize.

I think the 'minimalistic languages for big ideas' room has appeal to
a wider audience and some of our projects fit really well. Anyone
any project ideas? Or do we just forget about it? How about:

- Guile Guix build farm and Cuirass
- Sheperd (Guile)



Yes!

I posted previously a message on various Scheme related bulletin
boards, with not many responses except in Racket Group [0] that boils
down to "maybe we should do something".

[0] https://groups.google.com/forum/#!topic/racket-users/MehPv0ugBI4

I created a page at http://community.schemewiki.org/?FOSDEM2019

Like I wrote previously I was thinking out loud when I emailed 
guile-user

about a scheme dev room, with the hope more people would answer the call
but it did not happen.

What about the following names for the room:

- big fringe ideas
- define
- dev off
- off tracks

This names or others might allow even more developers (whatever that 
means...)
to join the event from a broad horizon. Let's remember the event is Free 
and

Open source Software Developers' European Meeting.

European make me think that about art, culture and history.

So this makes me think that it's about free. Art can be free. You feel 
free to dev

an art form like mezangelle / code poetry / executable poetry.

European is not the USA nor Asia maybe there is something interesting to 
find
to make it interesting for people from Europe and abroad to come to 
FOSDEM.

What about social / ethno / anthroposcene?

Well, I speak a lot about art. That's the way I think of coding. It's a 
way
(albeit new) to express oneself. It's a form of art and also a way to 
empower

others to create art and communicate. code imo is about communication.

What do other people think about the name that room must be?

I believe the schemewiki.org is more convenient because registration
is not required.

Another thing I'd like to stress, is that last year most talks I read 
about
were driven by big companies and stuff. And all the counter developer 
culture
was spread in various rooms. Let's make a room for alternatives maybe? 
No so big

communities that have a lot of potential or might just be moon shots.

I have a book called 'Open Space Technology' it's about organizing
meetings and events. I will read skim over it tonight. And (try) provide
feedback about the latest advancement in psychohistory engineering.

I hope to read some of your ideas.


Here is another one: #zehefyu93 undo s:/3nce 4 a peacefu/ prosperity.

Just to come back on the righteous track, maybe one can invite speakers.

Let's get inspiration from racketcon 2018 and 2017 or clojureconj or 
whatever..


stop brainwashing,
start brainstorming,
and have fun.

One has 6 months to prepare.

Re: Firefox 52's end of life, packaging Chromium

[Amirouche Boubekki]

Le jeu. 30 août 2018 à 00:35, Clément Lassieur  a écrit :
>
> Hi Amirouche,
>
> Thanks for your answer.
>
> Amirouche Boubekki  writes:
>
> > Let's choose our battle wisely. I want to remind that the core of the
> > guix users are GNU followers and are also anything but pro web or pro
> > web browser or a variation of that. I don't say every GNU follower is
> > against the www.  It's not the core of potential guix users
>
> Guix does not target GNU followers.

Good news.

> It targets all users.  GNU
> followers are a very small part of them and they are not a problem
> because they usually find their way around.

Yes.

> The problem is all users
> that are not GNU followers (and some GNU followers like me) who need a
> modern browser.

Out of curiosity, please let us know what you need from the "modern browser"?

On my side, I need a debugger for doing web frontends.

> We definitely don't want to frighten them with our
> nostalgic ideas about how the web should be and how a browser should be.

I don't want to be rude at all, especially with who has been nice to me.
But following that kind of logic cannot always be a good way forward.

> They just want a browser that works.  As long as it's free software,
> let's not complicate things for them.

I agree. I am wondering what that browser make it the browser they want.

> Otherwise we'll never grow.

Sorry again to disagree. I don't think the future of guix is in the desktop.
It has been said that GNU/Linux will kill windows on the desktop for a decade.
It did not happen. Nowadays, people use their computer only to run a browser
whatever the OS... Given that, It seems to defy the de facto
definition of a modern
OS not to provide a "good enough" web experience.

Snap!

>
> > 1) What firefox or chromium are useful for comparing to other graphical
> > web browsers?
> >
> > 2) What will chromium bring to guix and guix developers that they
> > can't do otherwise?
> >
> > 3) What are the minimal features for a graphical web browser to be
> > useful for a guix developer?
>
> Today I needed to browse some sites, at work, and I couldn't do it with
> anything else than Firefox and Chromium.  I'm not alone.  Lots of people
> need to browse complicated sites that they don't know in advance.

> We don't want them to wonder, every time: is it going to work with the 
> browser shipped with Guix?

Agreed.

Ok. I will try to help  with

a) chromium
b) investigate what people are expecting from a modern web browser
c) See whether qtwebkit is follows upstream security updates and test
it to see if it's stable
d) do the same with webkit-gtk

Re: Firefox 52's end of life, packaging Chromium

[Amirouche Boubekki]

Hello all :]

I will confess that if I use Ubuntu today, long story short, it's
because of the web browser.
I could not find my way around patchelf so I gave up and installed Ubuntu.

The matter relates to me a lot!

Le mer. 29 août 2018 à 11:03, Clément Lassieur  a écrit :
>
> Hi,
>
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.
>   Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

Here the list of known issues:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;include=subject:epiphany

>
>
> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].

>   It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?
>
> What do you think?
>
> Clément
>
> [1]: 
> https://blog.mozilla.org/futurereleases/2018/01/11/announcing-esr60-policy-engine/
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004#233


Not having access to a recent web browser can be a pain. That said
they are alternatives.
Many that don't involve more guix energy to be sucked into supporting
chromium or firefox
which I predict to be really painful in the future. Web browsers are
not just about getting the
initial package inside the main repository. It's a lot of pain.

What I think is that we choose our battle wisely. If this discussion
did not pop on the mailling list
I would be doing something else. Nevermind.

Let's choose our battle wisely. I want to remind that the core of the guix users
are GNU followers and are also anything but pro web or pro web browser or a
variation of that. I don't say every GNU follower is against the www.
It's not the
core of potential guix users

I won't help to bring firefox or chromium because I think even if done
ethically will
be a worthless time sink.

Let's be rational, and try to answer the following questions:

1) What firefox or chromium are useful for compared to other graphical
web browsers?

2) What will chromium bring to guix and guix developers that they
can't do otherwise?

3) What are the minimal features for a graphical web browser to be
useful for a guix developer?


I was going to say, let's find or build a minimal browser that use
qtwebkit but even that is
worthless because several people reported performance build issues
about it on IRC.

Sorry, it seems like a worthless timesink to me. The only thing
worthwhile is to build a
web browser using Guile but that will take several years before one
can use it instead
of Chromium... I still don't know why people would want to use that
except for SaaSS
stuff.

They are workarounds.

---

> The Internet was done so well that most people think of it as a
> natural resource like the Pacific Ocean, rather than something that
> was man-made. When was the last time a technology with a scale like
> that was so error-free? The Web, in comparison, is a joke. The Web was
> done by amateurs.

Alan Kay.

Re: Subscription Canceled

[Amirouche Boubekki]

Thank you for your help!

Le mer. 29 août 2018 à 20:31, Ricardo Wurmus  a écrit :

>
> Hi Amirouche,
>
> > I don't receive mails from guix-devel anymore on my other mail box
> > amirou...@hypermove.net.
> >
> > It is not the first time it happens.
> >
> > Do you know why?
>
> This sometimes happens when there has been excessive amount of bounces.
> My subscription has also been cancelled at least once.
>
> --
> Ricardo
>
>

Subscription Canceled

[Amirouche Boubekki]

Hello,


I don't receive mails from guix-devel anymore on my other mail box
amirou...@hypermove.net.

It is not the first time it happens.

Do you know why?



Best regards,


Amirouche

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

"There are only two hard problems in Computer Science: cache 
invalidation and naming things"



On 2018-07-30 03:23, Pjotr Prins wrote:

On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:

#+TITLE: Roadmap for Guix 1.0, 2018



* miscellaneous
** TODO “GuixSD” renamed to “Guix System”?


Guix System is not good because "system" is a word that is too generic.

What about "Guix OS"?


** TODO “Cuirass” renamed to “Guix CI”?


OK

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

Le lun. 20 août 2018 à 09:45, Ricardo Wurmus  a écrit :

>
> Amirouche Boubekki  writes:
>
> >> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> >> do or might want to do for 1.0, with the understanding that 1.0 should
> >> happen in 2018 (or early 2019 at the latest!).  :-)
> >>
> >>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
> >>
> >
> > I see no mention of containers. What is the status and goal about that
> > subject?
>
> What feature regarding containers would you like to know more about?
>

Thanks for your reply. I use containers (via LXC) as lightweight Virtual
Machines
as such I can emulate my use of LXC with guix already using a VM.

The difference I see between guix containers and LXC is that in LXC the
container
has its own network device and an IP. What I usually do with LXC:

a) start the lxc container
b) ssh into it and

proceed as if I was in a Xen Virtuam Machine.


Have nice day!

>
> “guix environment”, for example, supports isolation through container
>

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

Hello everyone,

On 2018-07-29 17:18, l...@gnu.org wrote:

Hello Guix!

I’ve pushed to guix/maintenance.git a list of things that IMO we should
do or might want to do for 1.0, with the understanding that 1.0 should
happen in 2018 (or early 2019 at the latest!).  :-)

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org




I see no mention of containers. What is the status and goal about that 
subject?



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

Re: System configuration on non-native Guix (SuSE/Debian)

[Amirouche Boubekki]

Le dim. 19 août 2018 à 08:02, Pjotr Prins  a
écrit :

> With the recent SuSE announcement I hope Guix gets taken up as a
> package manager on non-native Guix systems (Debian in particular).
>

What recent SuSE annoucement are you refering to?

Re: IRC freenode issue

[Amirouche Boubekki]

Le ven. 3 août 2018 à 00:15, Ricardo Wurmus  a écrit :

>
> Clément Lassieur  writes:
>
> > There seems to be an issue with #guix: I can't join anymore.  The error
> > is:
> >
> >   Cannot join channel (+i) - you must be invited
>
> I would be much happier if we could filter messages or automatically ban
> accounts posting these seemingly unchanging messages.  If someone has an
> idea on how to do this, please let us know!
>
>
I think wingo has a script to filter spam used on his weblog and Chris W.
has a bot.
It might be a way to achieve that using guile.


> --
> Ricardo
>
>

 amz3

Re: Web interface pushed

[Amirouche Boubekki]

Le jeu. 2 août 2018 à 20:49, Gábor Boskovits  a écrit :

> Clément Lassieur  ezt írta (időpont: 2018. aug. 2.,
> Cs, 18:49):
>
>> Hi Gábor,
>>
>> Gábor Boskovits  writes:
>>
>> > Also most of the time the results differing from the results in the
>> > previous evaluations are the most interesting.
>> > Can we get this kind of information somehow?
>>
>> About that, I am preparing a commit that would get Cuirass to stop
>> building all derivations, but only the ones that don't exist yet.
>> That's https://bugs.gnu.org/32190.  For example, Cuirass wouldn't build
>> anything when there is a new commit that just updates the documentation,
>> and the green red and grey buttons would show 0, 0, 0.  Is that what you
>> meant?
>>
>> > Not exactly. What I would be interested is to get a list of packages
> that
> > previous succeeded, and now they fail, and also a list of packages that
> were
> > failing, but now build.
>
>
>> Clément
>>
>
You do link the diff of each commit with the files that were impacted by
the change and must be re-evaluated?

Re: Web interface pushed

[Amirouche Boubekki]

I read some of the code, I like it :)

diff --git a/src/cuirass/base.scm b/src/cuirass/base.scm
index 82f49a4..af24a28 100644
--- a/src/cuirass/base.scm
+++ b/src/cuirass/base.scm
@@ -20,6 +20,10 @@
 ;;; You should have received a copy of the GNU General Public License
 ;;; along with Cuirass.  If not, see .

+;; Comment:
+
+;; This is called base because it interface with guix daemon.
+
 (define-module (cuirass base)
   #:use-module (fibers)
   #:use-module (cuirass logging)
diff --git a/src/cuirass/http.scm b/src/cuirass/http.scm
index 2d66ff9..0899cd1 100644
--- a/src/cuirass/http.scm
+++ b/src/cuirass/http.scm
@@ -117,6 +117,13 @@
 (map build->hydra-build builds)))

 (define (request-parameters request)
+  ;; REVIEW: this 'parameters' is ambigious in aiohttp. It's called
+  ;; request.query because the part after ? in the URL is called the "query
+  ;; string". Also parameters can be passed via the path part of the URL.
+
+  ;; here is what I use
+  ;;
https://github.com/a-guile-mind/guile-web/blob/master/src/web/decode.scm
+
   "Parse the REQUEST query parameters and return them under the form
   '((parameter . value) ...)."
   (let* ((uri (request-uri request))
@@ -125,11 +132,14 @@
 (map (lambda (param)
(match (string-split param #\=)
  ((key param)
-  (let ((key-symbol (string->symbol key)))
+  (let ((key-symbol (string->symbol (uri-decode key
 (cons key-symbol
   (match key-symbol
-('id (string->number param))
-('nr (string->number param))
+ ('id (string->number (uri-decode param)))
+ ;; I don't think this will scale in terms
of
+ ;; kind query pairs where the key part
can be
+ ;; many different things
+('nr (string->number (uri-decode param)))
 (_   param)))
  (string-split query #\&))
 '(
@@ -138,9 +148,10 @@
 ;;;
 ;;; Web server.
 ;;;
-;;; The api is derived from the hydra one. It is partially described here :
+;;; The exposed api is derived from the hydra one. It is partially
described
+;;; here :
 ;;;
-;;; https://github.com/NixOS/hydra/blob/master/doc/manual/api.xml
+;;;   https://github.com/NixOS/hydra/blob/master/doc/manual/api.xml
 ;;;

 (define (request-path-components request)
@@ -217,6 +228,8 @@
 (with-critical-section db-channel (db)
   (db-get-specifications db)
 (("build" build-id)
+ ;; REVIEW: don't inline that much code in same procedure aka.
procedures
+ ;; for the win1
  (let ((hydra-build
 (with-critical-section db-channel (db)
   (handle-build-request db (string->number build-id)
@@ -234,6 +247,7 @@
   (let ((uri (string->uri-reference
   (string-append "/log/"
  (basename output)
+;; create a procedure for that when you will have forms.
 (respond (build-response #:code 302
  #:headers `((location . ,uri)))
  #:body "")))
@@ -241,7 +255,10 @@
   ;; Not entry for BUILD-ID in the 'Outputs' table.
   (respond-json-with-error
500
+   ;; 500 is very strong error, it's must not be used for
expected failure
+   ;; by the way this is rendering logic, it should be in it's
own procedure.
(format #f "Outputs of build ~a are unknown." build-id)))
+
  (#f
   (respond-build-not-found build-id)))
(respond-build-not-found build-id
@@ -251,13 +268,25 @@
 (nr (assq-ref params 'nr)))
(if nr
(respond-json (object->json-string
+  ;; don't nest here the code. Because http
handlers should follow
+  ;; the following pattern:
+  ;;
+  ;;   (define (handler request body)
+  ;;  (let ((input (snarf-input request body)))
+  ;;  (shallow-validate-with-exception
input)
+  ;;  (deep-validate-with-exception input
(db))
+  ;;  (let ((out (domain-code-goes-here)))
+  ;; (sxml->response (handler-template
out
+  ;;
+  ;; Basically, the current code requires top down
and bottom up
+  ;; reading. Declaring intermediate variables
helps readbility.
   (with-critical-section db-channel (db)
 (db-get-evaluations db 

Re: Ensuring we don't break user systems

[Amirouche Boubekki]

Le lun. 30 juil. 2018 à 23:17, Nils Gillmann  a écrit :

> We just have 2 different views here.
>
> When Guix started, which was about 3 years before I joined, the model
> was okay. Between 2015 and now the amount of breakage has been
> extremely reduced due to discussions about more reasonable development
> models. For a while now we have an informal rfc for bigger changes -
> this is a result from "please don't do that without asking first"
> because some of us got upset about assuming that all changes are okay.
>
> I sympathize with your point of view - in production even a couple of
> breaking commits are bad.
>
> We have grown over the last years, but developing reasonable deployment
> models which fit our group takes time.
>
> I'm okay with defining a branching model and use it once we have the
> tooling and infrastructure for it.
>
> Dan Partelly transcribed 2.4K bytes:
> > No I did not shown or proofed this affirmation. I believe it is
> sensible.  It is a undeniable reality of software development  that bugs
> are introduced during development. Having the update to the package manager
> (which in GuixSD is very central to the distro itself)
> > result in a broken system "even if you can roll back” is a very bad
> thing. It is my opinion that the current model is both technically bad
> (exposing users to broken software , security bugs and so on) and socially
> bad ( having the package manager crap on itself due to bugs introduced in
> the development cycle may prompt a lot of people to look in to an
> alternative and creates bad publicity. It also results in end users wasting
> time, and time is the most precious comodity we have. I do not want the OS
> I use to waste my time. I want to install the software I need and work with
> and go on with my life and work  ). Ironically, the problem is easily
> solved . DO not expose people to your devel branch where they will get
> first contact wiith guix bugs and guile bugs. The situation with GuixSD is
> somehow complicated by the fact that the package metadata is compiled as
> code, but yeah, a stable branch which is proven to be compilable and
> preferably regression tested is the first step IMO towards a better future
> with GuixSD. Treat is as a product which offers a rock solid platform for
> the users.
> >
> > And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot.
> That is a fact, unfortunately.
> > > Dan Partelly  writes:
> > >
> > >> I pointed this out 4-5 weeks ago when trying GuixSD, on this very
> list. Thanks for reaffirming  the idea In all honesty the current model is
> very badly broken, and you should not wait for 1.0. I had no other Linux
> distro break up faster than GuixSD. A stable branch is not enough by
> itself,  (but is the mort important part) you need to ensure that all
> substitutes are built correctly, and atomically update all substitutes
> following a successful build of all packages.
> > >>
> > >> You should not inflict  current model on your users , not  even for
> an 0.1
>

You say there is not enough guix developpers.


> > > While this might apply to some software. I don't believe, and I don't
> > > think you've shown that this reasoning is appropriate or useful to
> apply
> > > to Guix.
> > >
> > > Saying that something doesn't work for you is fine, and can be helpful,
> > > but such a unevidenced extreme view is unhelpful.
> >
> >
>
>

Re: Web interface pushed

[Amirouche Boubekki]

Le lun. 30 juil. 2018 à 18:03, Clément Lassieur  a
écrit :

> Hartmut Goebel  writes:
>
> > Am 30.07.2018 um 11:11 schrieb Clément Lassieur:
> >> On https://cuirass.lassieur.org:8081/ for now, and on
> >> https://berlin.guixsd.org/ when Ricardo guix pulls and guix
> reconfigures
> >> it :-)
> >
> > Wow, this is much, much quicker then the old UI. I'm just curious how I
> > could get the build log. Anything I misses?
>
> It's a todo :-)
>

(display "win\n")

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Amirouche Boubekki]

Fwiw, you can use bootstrap without js.

Causal reply,

Amirouche

Le jeu. 19 juil. 2018 à 22:11, Tatiana Sholokhova  a
écrit :

> Hi Clément,
>
> Thank you for the clarifications on the job structure!
>
> I have read your changes to the web interface and everything looks good to
> me. Also, it works nicely on your server. So, let's prepare for the merge.
> Let me know if you want me to make some fixes before the merge. In the
> meantime, I continue working on the next features for the interface locally
> and then integrate them into the updated codebase.
>
> Best regards,
> Tatiana
>
> ср, 18 июл. 2018 г. в 12:37, Clément Lassieur :
>
>> Hi Tatiana,
>>
>> Tatiana Sholokhova  writes:
>>
>> > Could you please review the last 3 commits and maybe find some more
>> issues
>> > besides that?
>>
>> I've integrated your work onto my Cuirass instance[1], and I really like
>> it!  I had to fix a few things and adapt it[2] so that it works with
>> multiple inputs.
>>
>> I will do a review as soon as possible, and then we can merge it.  I'm a
>> bit late: going through the whole conversation history took more time
>> than I expected.
>>
>> Clément
>>
>> [1]: https://cuirass.lassieur.org:8081/
>> [2]: https://git.lassieur.org/cgit/cuirass.git/
>>
>

Re: Videos

[Amirouche Boubekki]

On 2018-05-29 16:48, Ricardo Wurmus wrote:

Hi Guix,

I’d like us to produce a series of short videos (< 4 mins each) that
introduce functional package management with Guix.

This is supposed to be aimed at people who are intimidated by the 
manual

and wouldn’t know where to begin reading.  Each of the videos should
focus on a single feature and be on the point.  The final seconds 
should

point the viewer to the manual to learn more.

Who would like to be involved in the planning and production of the
videos?  There are many tasks such as:

* collecting topics that should be covered
* writing canonical narration scripts for each episode
* translating the scripts into different languages
* recording the narrations in different languages
* drafting the storyboard for each video (i.e. what exactly is to be
  shown and for how long)
* recording the video portions
* mixing different audio tracks and the video track
* designing intro and outro frames
* recording or finding freely licensed music for the intro / outro
* coordinating with all volunteers

What do you think?



Guix videos! Great idea! FWIW, I think it's a lot of
efforts, but if the community manage to pull it off,
very great!

FWIW, I record screencast using the following script:

  ~/src/scheme/video$ cat record.sh
  #!/bin/sh
  ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+0,0 -f 
pulse -ac 2 -i default $1


Then run the script with something like:

  $ ./record.sh guix-functional-package-manager.mp4

I've been recording some guile hacking session, that you
can find on youtube with the name "GNU Guile Hacking".
Or using the following command:

  youtube-dl 
https://www.youtube.com/playlist?list=PL_jCPpfzyfeqtG9Jm4-WkiyX3kP4GiZp5


It's far away from anything like a MOOC but some people
enjoy them.  I am not looking to spam the mailing with
my poor attempts at marketing GNU Guile but rather suggest
that anyone can create such video focusing on guix. And
without much prepartion, can do much better than me.

Anyway, good luck!

Re: Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Amirouche Boubekki]

Wow very great, thanks for sharing.

On Wed, Apr 11, 2018 at 11:17 PM Roel Janssen  wrote:

>
> Ricardo Wurmus  writes:
>
> > Hey all,
> >
> > I’m happy to announce that the group I’m working with has released a
> > preprint of a paper on reproducibility with the title:
> >
> > Reproducible genomics analysis pipelines with GNU Guix
> > https://www.biorxiv.org/content/early/2018/04/11/298653
> >
> > We built a collection of bioinformatics pipelines and packaged them with
> > GNU Guix, and then looked at the degree to which the software achieves
> > bit-reproducibility (spoiler: ~98%), analysed sources of non-determinism
> > (e.g. time stamps), discussed experimental reproducibility at runtime
> > (e.g. random number generators, kernel+glibc interface, etc) and
> > commented on the idea of using “containers” (or application bundles)
> > instead.
> >
> > The middle section is a bit heavy on genomics to showcase the features
> > of the pipelines, but I think the introduction and the
> > discussion/conclusion may be of general interest.
>
> This looks really great!  I also like how you leverage GNU Autotools.
>
> Finally there is a paper that uses GNU Guix as deployment tool for
> scientific purposes. :)
>
> Kind regards,
> Roel Janssen
>
>

Re: Use guix to distribute data & reproducible (data) science

[Amirouche Boubekki]

Hello again Ludovic,

On 2018-02-09 18:13, ludovic.cour...@inria.fr wrote:

Hi!

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


tl;dr: Distribution of data and software seems similar.
   Data is more and more important in software and reproducible
   science. Data science ecosystem lakes resources sharing.
   I think guix can help.


I think some of us especially Guix-HPC folks are convinced about the
usefulness of Guix as one of the tools in the reproducible science
toolchain (that was one of the themes of my FOSDEM talk).  :-)

Now, whether Guix is the right tool to distribute data, I don’t know.
Distributing large amounts of data is a job in itself, and the store
isn’t designed for that.  It could quickly become a bottleneck.


What does it mean technically that the store “isn't designed for that”?


That’s one of the reasons why the Guix Workflow Language (GWL)
does not store scientific data in the store itself.


Sorry, I did not follow the engineering discussion around GWL.
Looking up the web brings me [0]. That said the question I am
asking is not answered there. In particular there is no rationale
for that in the design paper.

[0] http://lists.gnu.org/archive/html/guix-devel/2016-10/msg01248.html

I think data should probably be stored and distributed out-of-band 
using

appropriate storage mechanisms.


Then, in a follow up mail, you reply to Konrad:


Konrad Hinsen <konrad.hin...@fastmail.net> skribis:


[...]


It would be nice if big datasets could conceptually be handled in the
same way while being stored elsewhere - a bit like git-annex does for
git. And for parallel computing, we could have special build daemons.


Exactly.  I think we need a git-annex/git-lfs-like tool for the store.
(It could also be useful for things like secrets, which we don’t want
to have in the store.)




-

" The most basic of all human needs is the need to understand and be 
understood " Ralph Nichols

Re: Use guix to distribute data & reproducible (data) science

[Amirouche Boubekki]

On Thu, Feb 15, 2018 at 6:11 PM zimoun  wrote:

> Hi,
>
> Thank you for this food for thought.
>
>
> I agree that the frontier between code and data is arbitary.
>
> However, I am not sure to get the picture about the data management in
> the context of Reproducible Science. What is the issue ?
>
> So, I catch your invitation to explore your idea. :-)
>

[...]


> For me, just talking about code, it is not a straightforward task to
> define what are the properties for a reproducible and fully controled
> computational environment. It is --I guess-- what Guix is defining
> (transactional, user-profile, hackable, etc.). Then, it appears to me
> even more difficult about data.
>


> What are such properties for data management ?
>

In other words, on the paper, what are the benefits of a management of
> some piece of data in the store ? For example for the applications of
> weights of a trained neural network; or of the positions of the atoms in
> protein structure.
>

Given version-ed datasets you could want to switch
the input dataset of a given "pipeline" to see how different data
produce different results.

Also, it is desirable to be able to re-start a "pipeline" when a
datasets is updated.

For me --maybe I have wrong-- the way is to define a package (or
> workflow) that fetches the data from some external source, cleans if
> needed, does some checks, and then puts it to /path/to/somewhere/
> outside the store. In parallel computing, this /path/to/somewhere/ is
> accessible by all the nodes. Moreover, this /path/to/somewhere/ contains
> something hash-based in the folder name.
>
> Is it not enough ?
>

It is not enough, you could need to make a diff between two
datasets which is not easily done if the data is stored in tarballs.
But that is not a case that can be handled by guix.

Why do you need the history of changes ? as git provide ?
>

Because, if the dataset introduce a change that is not handled by
the rest of the code you can get to know it by looking up the diff. For
instance, a column that is an enumeration of three values that has now a
fourth. But again, it's not a case that's meant to be handled by guix.

Like others have said, there is different kind of data and - even if it was
possible to handle large datasets in guix store - it would require also a
lot of space and computation power. ConceptNet 5.5.5 is 10G which takes
more than a dozen of hours to build and AFAIK is not reproducible since it
takes its input directly on live instance of the wiktionary. WikiData is
100G, but requires no processing power. Those are structured data that you
could want to version in something like git. But, things like spacy models
 that are around 1G take I guess around a few
hours to build, are not structured. Those are the data that I know about
and there very few of them compared to small datasets (see data.gouv.fr)

I think they are various opportunities around reproducible data science. In
particular, I see two main opportunities :

a) Packaging data and work with upstream to keep the data clean. A work
that is already handled by privaters and in initiatives like
http://datahub.io/

b) Cooperate around the making of datasets, some kind of *git for data* for
which there is few or no initiatives. FWIW, I started such a project I call
neon .

Thanks for the feedback.

Re: Use guix to distribute data & reproducible (data) science

[Amirouche Boubekki]

On Fri, Feb 9, 2018 at 8:16 PM Konrad Hinsen <konrad.hin...@fastmail.net>
wrote:

> Hi,
>
> On 09/02/2018 18:13, Ludovic Courtès wrote:
>
> > Amirouche Boubekki <amirou...@hypermove.net> skribis:
> >
> >> tl;dr: Distribution of data and software seems similar.
> >> Data is more and more important in software and reproducible
> >> science. Data science ecosystem lakes resources sharing.
> >> I think guix can help.
> >
> > Now, whether Guix is the right tool to distribute data, I don’t know.
> > Distributing large amounts of data is a job in itself, and the store
> > isn’t designed for that.  It could quickly become a bottleneck.  That’s
> > one of the reasons why the Guix Workflow Language (GWL) does not store
> > scientific data in the store itself.
>
> and then distributed via standard channels (Zenodo, ...)


Thanks for the pointer!


> For big datasets, some other mechanism is required.
>

Big as in bigger than ram?


> I think it's worth thinking carefully about how to exploit guix for
> reproducible computations. As Lispers know very well, code is data and
> data is code. Building a package is a computation like any other.
>

What I was thinking about, is use guix to distribute data packages just like
we distribute softwares from pypi. The advantage of using guix seems
obvious,
but apparantly it's not desirable or possible and I don't understand why.

Scientific workflows could be handled by a specific build system. In
> fact, as long as no big datasets or multiple processors are involved, we
> can do this right now, using standard package declarations.
>

Ok, good to know.


> It would be nice if big datasets could conceptually be handled in the
> same way while being stored elsewhere - a bit like git-annex does for
> git.


Thanks again for the pointer.

And for parallel computing, we could have special build daemons.
>

That's where OWL comes in?

Use guix to distribute data & reproducible (data) science

[Amirouche Boubekki]

Héllo all,

tl;dr: Distribution of data and software seems similar.
   Data is more and more important in software and reproducible
   science. Data science ecosystem lakes resources sharing.
   I think guix can help.

Recently I stumbled upon open data movement and its links with
data science.

To give a high level overview, there is several (web) platforms
that allows administrations and companies to publish data and
_distribute_ it. Example of such platforms are data.gouv.fr [1] and
various other platforms based on CKAN [2].

[1] https://www.data.gouv.fr/
[2] https://okfn.org/projects/

I have worked with data.gouv.fr in particular. And the repository
is rather poor in terms of quality. Making very difficult to use.

The other side of this open data and data based software is the
fact that some software provide their own mechanism to _distribute_
data or binary blobs called 'models' that are sometime based on
libre data. Example of such softwares are spacy [2], gensim [3],
nltk [4] and word2vec.

[2] https://spacy.io/
[3] https://en.wikipedia.org/wiki/Gensim
[4] http://www.nltk.org/

My last point is that it's common knowledge that data wrangling
aka. cleaning and preparing data is 80% of data scientist job.
It's required because data distributors don't do it right, because
they don't have the man power and the knowledge to do it right.

To summarize:

1) Some software and platforms distribute _data_ themselves in some
   "closed garden" way. It's not the role of software to distribute
   data especially when that data can be reused in other contexts.

2) models are binary blobs that you use in the hope they do what they
   are supposed to do. How do you build the model? Is the model
   reproducible?

3) Preparing data must be re-done all the time, let's share resource
   and do it once.

It seems to me that guix has all the required feature to handle data
and models distribution.

What do people think? Do we already use guix to distribute data and 
models.


Also, it seems good to surf on AI frenzy ;)

Re: Pre-built binaries vs. performance

[Amirouche Boubekki]

Le 31 janv. 2018 3:08 PM, "Ludovic Courtès"  a
écrit :

Hello Guix!

This post is a followup to our previous discussions on how to handle
architecture-specific optimizations:

  https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-
binaries-vs-performance/

Comments welcome!

Ludo’.


Tx for the update.

Optimised binaries are not only useful for HPC.  I stayed with GNU/Linux
also because it delivered good performance for my old hardware. Even if I
am not helping, I am happy to know that it's a matter that is known to
guixers.

Re: Dinner in Brussels?

[Amirouche Boubekki]

In for dinner on Friday.

Le 30 janv. 2018 2:11 PM, "Gábor Boskovits"  a écrit :

> 2018-01-30 14:09 GMT+01:00 Julien Lepiller :
>
>> Le 30 janvier 2018 13:34:46 GMT+01:00, l...@gnu.org a écrit :
>>>
>>> Hello Guix!
>>>
>>> To those going to the Guix workshop in Brussels this Friday: who’s in
>>> for dinner (+ drink) on Friday evening?
>>>
>>> Even better: who would like to book something (I’m looking at you,
>>> Brusselers ;-))?
>>>
>>> Actually I’m arriving on Thursday afternoon, so if people are around,
>>> I’d be happy to have dinner on Thursday evening too!  :-) Let’s arrange
>>> something.
>>>
>>> Ludo’.
>>>
>>>
>> I'm in for dinner!
>>
>
> I'm in for dinner also!
>
>> --
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser
>> ma brièveté.
>>
>
>

Re: Manual (was: fully functional desktop installation)

[Amirouche Boubekki]

Does the manual want to avoid the fact that minimal knowledge of Scheme is
required maybe we should add a small intro to guile or guix manual
something maybe like my book called "a guile mind book"

Le 15 janv. 2018 3:20 PM, "ng0"  a écrit :

> Ludovic Courtès transcribed 1.7K bytes:
> > Hi Quiliro!
> >
> > Quiliro  skribis:
> >
> > > On Mon, 02 Jan 2017 22:11:01 +0100
> > > l...@gnu.org (Ludovic Courtès) wrote:
> >
> > [...]
> >
> > >> The desktop example contains all of GNOME, when choosing GNOME, which
> > >> provides an email client, Web browser, and lots of other things.
> > >
> > > I don't find the email client.
> > > The web browser will not reproduce videos.
> >
> > This is a bug that needs to be treated separately.  Clearly Nautilus
> > should be able to play videos.
>
> I can confirm this for some file, I just had the opinion Nautilus wasn't
> very capable and didn't report it when I first noticed it.
>
> > > I have no idea how to chat in Gnome. (Of course I will investigate.)
> >
> > There’s Pidgin, but maybe it’s not really part of GNOME.
> >
> > > What you say makes sense. But what users that cannot learn to install
> > > need to work on their own matters is very important in order for them
> to
> > > be able to advocate the free system. Perhaps we do not want to promote
> > > the use of Flash or Microsoft Office formats. These issues are
> > > critical. But they are not against the FSDGs. And the user must notice
> > > we are able to offer those capabilities. We must always insist in
> > > suggesting to use the libre alternatives. In this case, we should not
> > > avoid including the ability to read those formats.
> >
> > I agree, but again, I think GNOME provides everything for these tasks.
> > Also, at this point, the target audience of GuixSD is not “users that
> > cannot learn to install”—if someone managed to install GuixSD, surely
> > they’ll find out how to install LibreOffice.
>
> In my opinion we could extend examples in the Manual.
> We already expect people to read the Manual, even if it's hard to
> digest for newcomers in some passages (different problem). To add
> an 'from 0 to full Desktop' walk through or just extension of the existing
> material with references to the appropriate sections would be good.
>
> Even if we don't expect people who are not willing to play around, break
> parts
> and play around with the system, we need clear examples. Even people who
> are
> experienced want some kind of help instead of high expertise expectation.
>
> People keep asking me obvious question that should be in the manual.
> Sometimes things which could be snippets in an example chapter.
> For example (home-directory (string-append "/home/" name)). Super obvious,
> I know.
>
> > > I have also had problems with Mimetypes. Many files will not open
> > > because the Gnome will not identify which program is appropriate.
> >
> > Sounds like a bug.  Could you report all the details to
> > bug-g...@gnu.org: how to reproduce, what you expected, and what you got?
> >
> > Thank you!
> >
> > Ludo’.
> >
> >
> >
> >
>
> --
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
>

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/<Alice’s key>/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). A

gnunet-guile reboot & guix

[Amirouche Boubekki]

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.

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

You can install a recent-ish gnunet using the following command:

  guix package -f guix.scm

Then, you can do usual cli dance:

  ./bootstrap && ./configure && make

Ahem, now it's time to run gnunet services. I put together
gnunet configuration that might not be very good even if it
works. For instance, it seems like gnunet manages to reach
the outside world. It's based on configuration files found
in gnunet distribution:

  gnunet-arm -c etc/p2.conf -s

At this point you will be able to test the bindings.

To publish a FILE, use the following command:

  ./pre-inst-env ./gnunet-guile publish etc/p2.conf FILE

To download the above file into OUT, you need to copy paste
the gnunet:// URI from the previous command output and execute
the following command:

  ./pre-inst-env ./gnunet-guile download etc/p2.conf URI OUT

That is all!

There is no support for identity and various stuff are missing.
There might be memory leaks and other issues (like proper disjoint
types for pointers). I just finished the code.

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


TIA!

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

Help understand some guix concepts

[Amirouche Boubekki]

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

Re: Automatically detect other OSs and generate grub entries

[Amirouche Boubekki]

On Mon, Jul 17, 2017 at 3:39 PM Ludovic Courtès  wrote:

> Arun Isaac  skribis:
>
> > Instead of having to manually specify custom grub entries in config.scm,
> > can Guix use os-prober to automatically detect other operating system
> > and generate grub entries?
> >
> > https://joeyh.name/code/os-prober/
>
> I think there is value in having everything in the GuixSD config, which
> can then be put under version control.
>
> Now, I have a single OS on my machines so I’m probably not part of the
> target audience.  :-)
>
> Thoughts?
>

My understanding is that os-probe could generate part of GuixSD config.


>
> Ludo’.
>
>

[PATCH] gnu: guile-bytestructures: Update to 91d042e

[Amirouche Boubekki]

From 9315163a42c57dd39ca16296cea5d60ec3697113 Mon Sep 17 00:00:00 2001
From: Amirouche 
Date: Sat, 22 Apr 2017 13:54:12 +0200
Subject: [PATCH] gnu: guile-bytestructures: Update to 91d042e

* gnu/packages/guile.scm (guile-bytestructures): Update to 91d042e.
---
 gnu/packages/guile.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 6d9f58c..9dd524e 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -1441,16 +1441,16 @@ is no support for parsing block and inline level HTML.")
 (define-public guile-bytestructures
   (package
 (name "guile-bytestructures")
-(version "20160726.53127f6")
+(version "20170402.91d042e")
 (source (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/TaylanUB/scheme-bytestructures;)
-(commit "53127f608caf64b34fa41c389b2743b546fbe9da")))
+(commit "91d042e3427e1d7740b604b6296c616cf2eec13d")))
   (file-name (string-append name "-" version "-checkout"))
   (sha256
(base32
-"0l4nx1vp9fkrgrgwjiycj7nx6wfjfd39rqamv4pmq7issi8mrywq"
+"04lgh0nk6ddnwgh20hnz4pyhczaik0xbd50kikjsxcwcl46shavb"
 (build-system trivial-build-system)
 (arguments
  `(#:modules ((guix build utils))
-- 
2.9.3

Another cli interface for guix/sd

[Amirouche Boubekki]

Héllo,

This is a reply to a previous conversation that was started last year
http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00724.html

To help you avoid the need to read the above long thread here is
summary:

a) We need to do something regarding guix cli
b) We need to move commands inside "guix package"
b prime) we do not need to move commands inside "guix package" because it's
more to type.
c) We need to turn "guix package" options into separate sub-commands
d) We need to handle the fact that some commands operate on store items,
derivations, etc.
e) We need to avoid having 20 or something commands in the first level (*)
f) We need separate commands/cli for user and devs
f bis) We need a single "guix" full featured guix command
g) We need a "guix install" alias
h) Do we need to keep the ability add/remove packages in a single txn (* to
this I reply we should improve the profile generation manipulation with for
instance something like git rebase -i)
i) we must use flags/options/switches to nuance how a given command should
be executed
k) we should empower the user aka. one must understand how things works via
the cli

So I summed things in the following cli mockup:

xote container attach NAME
xote container init NAME SPEC
xote container start NAME

xote helper download URL
xote helper hash FILE

xote package archive export [-r] PACKAGE
xote package archive import
xote package build PACKAGE
xote package challenge PACKAGE
xote package edit PACKAGE
xote package graph PACKAGE
xote package import IMPORTER ARGS
xote package lint PACKAGE
xote package pack PACKAGE
xote package size PACKAGE
xote package search PACKAGE

xote profile delete-generations
xote profile enter
xote profile init
xote profile install
xote profile leave
xote profile list-generations
xote profile list-installed
xote profile manifest
xote profile rebase
xote profile refresh
xote profile remove
xote profile rollback
xote profile switch-generations

xote publish

xote pull

xote store gc

xote system build
xote system container
xote system disk-image
xote system extension-graph
xote system init
xote system reconfigure
xote system refresh
xote system rollback
xote system shepherd-graph
xote system switch-generation
xote system vm
xote system vm-image

In particular:

- guix environement is gone, because it can be replaced with guix profile
- I think the cli should reflect the underlying inner working but also the
usage. For instance, one might argue that containers are just systems (or
profiles) but for the user it makes a great difference to have the commands
spread as several multiple commands instead of a single command that does
everything required.
- There is surely missing commands in the "store" section, input welcome!
- There is two single commands without subcommands called "pull" and
"publish". I am not sure where to put them.

Also, I did not look into it too much, but when I try to import guix inside
a guile REPL I can't. So my current work is in a fork of guix repository.
Is it possible to create a guix project without it being in the guix
repository?

Feedback welcome!

PS: the "xote" name comes from quixote.

Re: guix is the guildhall that we always wanted!

[Amirouche Boubekki]

Héllo wingo!

On 2017-03-16 19:25, Andy Wingo wrote:

Hi all!



[...]


But it turns out that we can use the same strategy to distribute
reproducible binaries for any package that Guix includes.  Notably, if
you run:

  guix pack -S /opt/guile-fibers-1.0.0=/ guile-next guile-fibers
glibc-utf8-locales

Then what you get is a tarball that has Guile, Fibers, and everything
they depend on.  It's safe to extract in / because it only adds files 
to

/gnu/store, and then it adds a symlink for /opt/guile-fibers-1.0.0.



cf. http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n2392



So:

  * local development using packaged libraries: check.
  * distribution of your work to people without $package-manager: 
check.

  * easy addition of your code to a common NPM-like registry: ?

For this last bit, we have two options.  One is to add your package to
Guix.  It's relatively easy; here's what I added for Fibers:

(define-public guile-fibers
  (package
(name "guile-fibers")
(version "1.0.0")
(source (origin
  (method url-fetch)
  (uri (string-append 
"https://wingolog.org/pub/fibers/fibers-;

  version ".tar.gz"))
  (sha256
   (base32

"0vjkg72ghgdgphzbjz9ig8al8271rq8974viknb2r1rg4lz92ld0"

(build-system gnu-build-system)
(native-inputs
 `(("texinfo" ,texinfo)
   ("pkg-config" ,pkg-config)))
(inputs
 `(("guile" ,guile-next)))
(synopsis "Lightweight concurrency facility for Guile")
(description
 "Fibers is a Guile library that implements a a lightweight 
concurrency

facility, inspired by systems like Concurrent ML, Go, and Erlang.
A fiber is
like a \"goroutine\" from the Go language: a lightweight 
thread-like

abstraction.  Systems built with Fibers can scale up to millions
of concurrent
fibers, tens of thousands of concurrent socket connections, and
many parallel
cores.  The Fibers library also provides Concurrent ML-like 
channels for

communication between fibers.

Note that Fibers makes use of some Guile 2.1/2.2-specific features 
and

is not available for Guile 2.0.")
(home-page "https://github.com/wingo/fibers;)
(license license:lgpl3+)))

OK, so this uses gnu-build-system, which requires a tarball; we need to
extend this to have a "guile-build-system" for modules that are just
Scheme, in which we just "guild compile" everything.  That way you can
have a repo on gitlab or whatever and you just specify the URL and the
revision and you are done.  I don't know if we can get around 
specifying
the sha256 when we specify the git revision; probably not a good idea 
in

light of the SHA1 breakage.  Anyway, that's a thing.

But while getting your package into guix is easier than you think, it's
not automatic.  I think there's room for a middle ground that's a bit
more decentralized than Guix, but more centralized than people using
GUIX_PACKAGE_PATH to add random directories of Guix package files.


Ok, I like the idea!



So!  My proposal for this new "guildhall" would be:

1. a web service



What would be the cli interface associated with that web service?
Some thing like the following will do:

  $ guildhall register

Register a package against the guildhall repository.
You must have a package.scm in the current working
directory that follows package specification of guix.
http://link/to/guix/doc/that/I/dont/know

Does it require login/password?

That is all I can think of.


2. on which users registers projects

3. a project is a name + a git repository with a /package.scm file


We can have that using guile-git: current commit + remote origin.

4. the package.scm contains Guix package definitions for that 
project


5. the web service administers a git repository collecting those
   packages
   - without any hydra.gnu.org overhead


What do you mean, by no hydra.gnu.org overhead? Where are
done the 'guix pack' command?


   - without any manual checks
   - in a form that you can just check out once and add to 
GUIX_PACKAGE_PATH




Ok, the 'guix pack' can be done by the maintainer and
'guix register' does upload the lz file to guildhall
website.


6. adding a new tag to a project's git repo of the form vX makes a
   release X and updates the guildhall package
   - it could be the web service has to poll git repos
   - or maybe you have to invoke some command to update guildhall


It's painful to have to "watch" git repositories, except if the git
repository is a remote of the develloper's git. Basically it requires
a manual intervention from the maintainer. Otherwise, guildhall website
need to pull regularly all git repositories.


7. probably we need to steal many ideas from npm.org


I think about their dependency resolution algorithm. I think
civodul should 

Re: FOSDEM 2017 audio/video volunteers needed

[Amirouche Boubekki]

On 2017-01-11 09:05, Ricardo Wurmus wrote:

Pjotr Prins  writes:


On Tue, Jan 10, 2017 at 04:02:32AM +, Pjotr Prins wrote:

Hi all,

FOSDEM provides live streaming of talks and archiving. We need
volunteers to man the FOSS setup that handles the camera and mike.
Ideally two people who expect to be in the room all day :). It is
mostly automated and does not require special skills.


No response. We need help! Two people can take turns over the day.
Please volunteer, it is important we capture all talks.


I could do some of it, but I’m also giving talks, so we need at least
one more person to help out.


I hope I will be up to the task; count me in.

Re: FOSDEM social dinner

[Amirouche Boubekki]

On 2017-01-09 14:37, Catonano wrote:

2017-01-06 10:46 GMT+01:00 Alex Sassmannshausen
:


Hello,

Guile has a dev room at FOSDEM this year — for a whole day! The
dev
room will be on Sunday.

Whilst organising it, we had the idea that it would be fun to have a
Guile/Guix user & dev dinner on the Saturday evening. I'm hereby
officially opening registration for that :-D

I have not chosen a restaurant yet, but it will be something that
provides a varietary of dietary options (omnivore, veggie, vegan).
If
you are interested in coming along, just drop me a line to confirm.

So — who's in for Guile social dinner on Saturday 4 February 2017
in
Brussels?

Best wishes,

Alex


It seems that  I will manage to be there, too.

So count me in !

I'm an omnivore !


Me too.

Re: FOSDEM 2017 Schedule is there! Change of schedule!:wq

[Amirouche Boubekki]

On 2017-01-03 15:46, Pjotr Prins wrote:

In other good news: we have a full day instead of a half day!

  https://fosdem.org/2017/schedule/track/gnu_guile/

All talks have more time and we can still add a few talks. The final
schedule has to be ready by this Saturday.


Great news :)


So, if anyone has ideas, please shoot. Also note it is now on Sunday.


None on my side.



Pj.

On Mon, Dec 19, 2016 at 08:37:44AM +0100, Alex Sassmannshausen wrote:


Pjotr Prins writes:

> Check it out K.3.201 - looks awesome!
>
> https://fosdem.org/2017/schedule/day/saturday/

Indeed, most excellent!  Looking forward to this greatly :-)

Alex



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

Re: [PATCH] gnu: link-grammar: New module.

[Amirouche Boubekki]

Thx for the review and explanation.

I am not in a hurry, I will wait for the 5.3.12 release.

On Mon, Oct 24, 2016 at 7:03 PM Amir P  wrote:

> On Sun, 23 Oct 2016 17:20:11 -0400 Leo Famulari wrote:
> > If sqlite and zlib are only used when building, but not when running
> > link-grammar, then they should be native-inputs.
> >
> > Otherwise, we will need to figure out how to make link-grammar retain
> > references to these libraries.
>
> The link-grammar library doesn't use the zlib library directly or
> indirectly.
> What happens is that zlib.h is needed for the compilation of its
> sat-solver code
> because it is included in a header file of the minisat library which is
> indirectly
> included by the sat-solver code. So zlib (actually zlib.h) is only used
> when building.
>
> However, if the sqlite library+headers exist when using "configure",
> HAVE_SQLITE will get defined, which will bring in code that can use sqlite
> (sqlite3_open etc. are referenced in the result link-grammar library).
> As this code is currently not fully functional, a solution may be to
> "configure"
> link-grammar without the presence of the sqlite library+headers.
> A better solution may be to add a link-grammar "configure" option like
> "--enable-sqlite".
> If you think it is indeed better, I will open an issue there for adding it
> - to be
> included in the next version - 5.3.12.
> In any case, 5.3.12 is needed to overcome additional problems in 5.3.11
> (some
> of them are already fixed in the repository, and for some others
> pull-requests are
> still pending).
>

[PATCH] gnu: link-grammar: New module.

[Amirouche Boubekki]

From 391889d22f102368cc44d6a0a928fccd20810269 Mon Sep 17 00:00:00 2001
From: Amirouche <amirou...@hypermove.net>
Date: Sun, 23 Oct 2016 16:46:12 +0200
Subject: [PATCH] gnu: link-grammar: New module

* gnu/packages/link-grammar.scm: New module.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add new file.
---
 gnu/local.mk  |  1 +
 gnu/packages/link-grammar.scm | 52 +++
 2 files changed, 53 insertions(+)
 create mode 100644 gnu/packages/link-grammar.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index eb8322e..31ad798 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -221,6 +221,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/libunwind.scm			\
   %D%/packages/libupnp.scm			\
   %D%/packages/lighting.scm \
+  %D%/packages/link-grammar.scm			\
   %D%/packages/links.scm			\
   %D%/packages/linux.scm			\
   %D%/packages/lirc.scm\
diff --git a/gnu/packages/link-grammar.scm b/gnu/packages/link-grammar.scm
new file mode 100644
index 000..6d1b302
--- /dev/null
+++ b/gnu/packages/link-grammar.scm
@@ -0,0 +1,52 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Amirouche Boubekki <amirou...@hypermove.net>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages link-grammar)
+  #:use-module (guix packages)
+  #:use-module (guix build-system gnu)
+  #:use-module ((guix licenses) #:select (lgpl2.1+))
+  #:use-module (guix download)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages databases)
+  #:use-module (gnu packages compression))  
+
+(define-public link-grammar
+  (package
+(name "link-grammar")
+(version "5.3.11")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.abiword.org/downloads/link-grammar/;
+ version "/link-grammar-" version ".tar.gz"))
+ (sha256
+  (base32
+   "1mqc2zhq360k2xslsjw5x8nfmbsk55x03dvyhb7bzpf75vl3mjkk"
+(build-system gnu-build-system)
+(inputs `(("sqlite" ,sqlite)
+  ("zlib" ,zlib)))
+(home-page "http://www.abisource.com/projects/link-grammar/;)
+(synopsis "Syntactic parser for several language")
+(description
+ "Link Grammar is a syntactic parser of English, Russian, Arabic and
+Persian (and other languages as well), based on Link Grammar, an original
+theory of syntax and morphology.  Given a sentence, the system assigns to it a
+syntactic structure, which consists of a set of labelled links connecting
+pairs of words.  The parser also produces a \"constituent\" (HPSG style phrase
+tree) representation of a sentence (showing noun phrases, verb phrases,
+etc.). ")
+(license lgpl2.1+)))
-- 
2.10.0

Re: [PATCH] Add scheme-bytestructures

[Amirouche Boubekki]

On Thu, Oct 20, 2016 at 4:00 PM Ludovic Courtès <l...@gnu.org> wrote:

> Hello,
>
> Amirouche Boubekki <amirouche.boube...@gmail.com> skribis:
>
> > find-files does the right thing, there is no need to filter what it
> returns.
> > From ea88bf4b53a63ba0d54f71622d055c32cd7e346e Mon Sep 17 00:00:00 2001
> > From: Amirouche <amirou...@hypermove.net>
> > Date: Sun, 9 Oct 2016 12:31:20 +0200
> > Subject: [PATCH] gnu: Add guile-bytestructures
> >
> > * gnu/packages/guile.scm (guile-bytestructures): New variable.
>
> I had to make these extra modifications (the package you sent built but
> the result was a bunch of empty directories because ‘find-files’ was
> called from the wrong directory):
>
>
> However, with those changes, I get:
>
> --8<---cut here---start->8---
>

[...]


> ERROR: In procedure scm-error:
> ERROR: Failed to compile "bytestructures/r7/base.scm" to
> "/gnu/store/m0lqx4wli55dfj45nsjhlhlvgql1p974-guile-bytestructures-20160726.53127f6/share/guile/site/2.0/bytestructures/r7/base.go"!
> --8<---cut here---end--->8---
>
> Could you look into it and submit and updated patch?
>

It was the r7 files that could not be compiled. I filtered them.
From a40c2f8da528b4d1010cdf9d1ce96059ec084078 Mon Sep 17 00:00:00 2001
From: Amirouche <amirou...@hypermove.net>
Date: Sun, 9 Oct 2016 12:31:20 +0200
Subject: [PATCH] gnu: Add guile-bytestructures

* gnu/packages/guile.scm (guile-bytestructures): New variable.
---
 gnu/packages/guile.scm | 81 ++
 1 file changed, 81 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 43071e6..2325a25 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2016 Eraim Flashner <efr...@flashner.co.il>
 ;;; Copyright © 2016 Alex Kost <alez...@gmail.com>
 ;;; Copyright © 2016 Adonay "adfeno" Felipe Nogueira <https://libreplanet.org/wiki/User:Adfeno> <adf...@openmailbox.org>
+;;; Copyright © 2016 Amirouche <amirou...@hypermove.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1267,4 +1268,84 @@ is no support for parsing block and inline level HTML.")
 (define-public guile2.2-commonmark
   (package-for-guile-2.2 guile-commonmark))
 
+(define-public guile-bytestructures
+  (package
+(name "guile-bytestructures")
+(version "20160726.53127f6")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/TaylanUB/scheme-bytestructures;)
+(commit "53127f608caf64b34fa41c389b2743b546fbe9da")))
+  (file-name (string-append name "-" version "-checkout"))
+  (sha256
+   (base32
+"0l4nx1vp9fkrgrgwjiycj7nx6wfjfd39rqamv4pmq7issi8mrywq"
+(build-system trivial-build-system)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils)
+  (ice-9 match)
+  (ice-9 popen)
+  (ice-9 rdelim))
+ (let* ((out (assoc-ref %outputs "out"))
+(guile (assoc-ref %build-inputs "guile"))
+(effective (read-line
+(open-pipe* OPEN_READ
+(string-append guile "/bin/guile")
+"-c" "(display (effective-version))")))
+(module-dir (string-append out "/share/guile/site/"
+   effective))
+(source (assoc-ref %build-inputs "source"))
+(doc (string-append out "/share/doc/scheme-bytestructures"))
+(scm-files (filter (lambda (path)
+ (not (string-prefix? "bytestructures/r7" path)))
+   (with-directory-excursion source
+ (find-files "bytestructures" "\\.scm$"
+(guild (string-append (assoc-ref %build-inputs "guile")
+  "/bin/guild")))
+   ;; Make installation directories.
+   (mkdir-p doc)
+
+   ;; Compile .scm files and install.
+   (chdir source)
+   (setenv "GUILE_AUTO_COMPILE" "0")
+   (for-each (lambda (file)
+   (let* ((dest-file (string-append module-dir "/"
+file))
+   

Re: [PATCH] Add scheme-bytestructures

[Amirouche Boubekki]

Updated the patch.

On Tue, Oct 18, 2016 at 4:28 PM Ludovic Courtès <l...@gnu.org> wrote:

> Amirouche Boubekki <amirouche.boube...@gmail.com> skribis:
>
> > On Mon, Oct 10, 2016 at 10:46 PM Ludovic Courtès <l...@gnu.org> wrote:
> >
>

[...]


> >> Please let’s not list all the files.  :-)  Could it instead use
> >> something like (find-files "bytestructures" "\\.scm$")?
> >>
> >
> > The above is a subset of all files. Do you prefer to use `find-files` and
> > exclude some files?
>
> Whichever is the most concise and most maintainable approach (I suspect
> it’s ‘find-files’ + exclude specific files.)
>
> Ludo’.
>

find-files does the right thing, there is no need to filter what it returns.
From ea88bf4b53a63ba0d54f71622d055c32cd7e346e Mon Sep 17 00:00:00 2001
From: Amirouche <amirou...@hypermove.net>
Date: Sun, 9 Oct 2016 12:31:20 +0200
Subject: [PATCH] gnu: Add guile-bytestructures

* gnu/packages/guile.scm (guile-bytestructures): New variable.
---
 gnu/packages/guile.scm | 78 ++
 1 file changed, 78 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 43071e6..a03cb44 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -1267,4 +1267,82 @@ is no support for parsing block and inline level HTML.")
 (define-public guile2.2-commonmark
   (package-for-guile-2.2 guile-commonmark))
 
+(define-public guile-bytestructures
+  (package
+(name "guile-bytestructures")
+(version "20160726.53127f6")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/TaylanUB/scheme-bytestructures;)
+(commit "53127f608caf64b34fa41c389b2743b546fbe9da")))
+  (file-name (string-append name "-" version "-checkout"))
+  (sha256
+   (base32
+"0l4nx1vp9fkrgrgwjiycj7nx6wfjfd39rqamv4pmq7issi8mrywq"
+(build-system trivial-build-system)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils)
+  (ice-9 match)
+  (ice-9 popen)
+  (ice-9 rdelim))
+
+ (let* ((out (assoc-ref %outputs "out"))
+(guile (assoc-ref %build-inputs "guile"))
+(effective (read-line
+(open-pipe* OPEN_READ
+(string-append guile "/bin/guile")
+"-c" "(display (effective-version))")))
+(module-dir (string-append out "/share/guile/site/"
+   effective))
+(source (assoc-ref %build-inputs "source"))
+(doc (string-append out "/share/doc/scheme-bytestructures"))
+(scm-files (find-files "bytestructures" "\\.scm$"))
+(guild (string-append (assoc-ref %build-inputs "guile")
+  "/bin/guild")))
+   ;; Make installation directories.
+   (mkdir-p (string-append module-dir "/bytestructures/guile"))
+   (mkdir-p (string-append module-dir "/bytestructures/r6"))
+   (mkdir-p (string-append module-dir "/bytestructures/body"))
+   (mkdir-p doc)
+
+   ;; Compile .scm files and install.
+   (chdir source)
+   (setenv "GUILE_AUTO_COMPILE" "0")
+   (for-each (lambda (file)
+   (let* ((dest-file (string-append module-dir "/"
+file))
+  (go-file (string-append module-dir "/"
+  (substring file 0
+ (string-rindex file #\.))
+  ".go")))
+ ;; Install source module.
+ (copy-file file dest-file)
+ ;; Install compiled module.
+ (unless (zero? (system* guild "compile"
+ "-L" source
+ "-o" go-file
+ file))
+   (error (format #f "Failed to compile ~s to ~s!"
+  file go-file)
+ scm-files)
+
+   ;; Also copy over the README.
+  

Re: [PATCH] Add scheme-bytestructures

[Amirouche Boubekki]

On Mon, Oct 10, 2016 at 10:46 PM Ludovic Courtès  wrote:

> Hi Amirouche,


[...]


> >> +(scm-files (string-split
> "bytestructures/guile/explicit-endianness.scm
> >> +bytestructures/guile/numeric-metadata.scm
> >> +bytestructures/guile/ffi.scm
> >> +bytestructures/guile/vector.scm
> >> +bytestructures/guile/union.scm
> >> +bytestructures/guile/numeric-all.scm
> >> +bytestructures/guile/utils.scm
> >> +bytestructures/guile/pointer.scm
> >> +bytestructures/guile/base.scm
> >> +bytestructures/guile/numeric.scm
> >> +bytestructures/guile/struct.scm
> >> +bytestructures/guile/bitfields.scm
> >> +bytestructures/r6/bytevectors.scm
> >> +bytestructures/body/base.syntactic.scm
> >> +bytestructures/body/explicit-endianness.scm
> >> +bytestructures/body/vector.scm
> >> +bytestructures/body/union.scm
> >> +bytestructures/body/utils.scm
> >> +bytestructures/body/base.scm
> >> +bytestructures/body/numeric.scm
> >> +bytestructures/body/struct.scm
> >> +bytestructures/body/bitfields.scm
> >> +bytestructures/guile.scm"
>
> Please let’s not list all the files.  :-)  Could it instead use
> something like (find-files "bytestructures" "\\.scm$")?
>

The above is a subset of all files. Do you prefer to use `find-files` and
exclude some files?

Regards,

Amirouche

[PATCH] Add scheme-bytestructures

[Amirouche Boubekki]

Warning: scheme-bytestructures works on various implementation of Scheme
but this patch adds it only for guile-2.0.

This is a pure scheme package there is no autotools that's why I use the
trivial-build-system.

This doesn't run the test suite, yet.
From fb2eb7ffd88ec4fba09411195a54b59d67d9c137 Mon Sep 17 00:00:00 2001
From: Amirouche 
Date: Sun, 9 Oct 2016 12:31:20 +0200
Subject: [PATCH] gnu: Add scheme-bytestructures

* gnu/packages/guile.scm (scheme-bytestructures): New variable.

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 0890f19..383990e 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -1265,4 +1265,105 @@ is no support for parsing block and inline level HTML.")
 (define-public guile2.2-commonmark
   (package-for-guile-2.2 guile-commonmark))
 
+(define-public scheme-bytestructures
+  (package
+(name "scheme-bytestructures")
+(version "20160726.53127f6")
+(source (origin
+	  (method git-fetch)
+	  (uri (git-reference
+		(url "https://github.com/TaylanUB/scheme-bytestructures;)
+		(commit "53127f608caf64b34fa41c389b2743b546fbe9da")))
+	  (file-name (string-append name "-" version "-checkout"))
+	  (sha256
+	   (base32
+		"0l4nx1vp9fkrgrgwjiycj7nx6wfjfd39rqamv4pmq7issi8mrywq"
+(build-system trivial-build-system)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+	 (use-modules (guix build utils)
+		  (ice-9 match)
+		  (ice-9 popen)
+		  (ice-9 rdelim))
+
+	 (let* ((out (assoc-ref %outputs "out"))
+		(guile (assoc-ref %build-inputs "guile"))
+		(effective (read-line
+			(open-pipe* OPEN_READ
+	(string-append guile "/bin/guile")
+	"-c" "(display (effective-version))")))
+		(module-dir (string-append out "/share/guile/site/"
+	   effective))
+		(source (assoc-ref %build-inputs "source"))
+		(doc (string-append out "/share/doc/scheme-bytestructures"))
+		(scm-files (string-split "bytestructures/guile/explicit-endianness.scm
+bytestructures/guile/numeric-metadata.scm
+bytestructures/guile/ffi.scm
+bytestructures/guile/vector.scm
+bytestructures/guile/union.scm
+bytestructures/guile/numeric-all.scm
+bytestructures/guile/utils.scm
+bytestructures/guile/pointer.scm
+bytestructures/guile/base.scm
+bytestructures/guile/numeric.scm
+bytestructures/guile/struct.scm
+bytestructures/guile/bitfields.scm
+bytestructures/r6/bytevectors.scm
+bytestructures/body/base.syntactic.scm
+bytestructures/body/explicit-endianness.scm
+bytestructures/body/vector.scm
+bytestructures/body/union.scm
+bytestructures/body/utils.scm
+bytestructures/body/base.scm
+bytestructures/body/numeric.scm
+bytestructures/body/struct.scm
+bytestructures/body/bitfields.scm
+bytestructures/guile.scm"
+	 #\newline))
+		(guild (string-append (assoc-ref %build-inputs "guile")
+  "/bin/guild")))
+	   ;; Make installation directories.
+	   (mkdir-p (string-append module-dir "/bytestructures/guile"))
+	   (mkdir-p (string-append module-dir "/bytestructures/r6"))
+	   (mkdir-p (string-append module-dir "/bytestructures/body")) 
+	   (mkdir-p doc)
+
+	   ;; Compile .scm files and install.
+	   (chdir source)
+	   (setenv "GUILE_AUTO_COMPILE" "0")
+	   (for-each (lambda (file)
+		   (let* ((dest-file (string-append module-dir "/"
+			file))
+			  (go-file (string-append module-dir "/"
+		  (substring file 0
+ (string-rindex file #\.))
+		  ".go")))
+			 ;; Install source module.
+			 (copy-file file dest-file)
+			 ;; Install compiled module.
+			 (unless (zero? (system* guild "compile"
+		 "-L" source
+		 "-o" go-file
+		 file))
+			   (error (format #f "Failed to compile ~s to ~s!"
+	  file go-file)
+		 scm-files)
+
+	   ;; Also copy over the README.
+	   (install-file "README.md" doc)
+	   #t
+(inputs
+ `(("guile" ,guile-2.0)))
+(home-page "https://github.com/TaylanUB/scheme-bytestructures;)
+(synopsis "Structured access to bytevector contents for Guile")
+(description
+ "Scheme bytestructures offers a system imitating the type system
+of the C programming language, to be used on bytevectors.  C's type
+system works on raw memory, and Scheme works on bytevectors which are
+an abstraction over raw memory.  It's also more powerful than the C
+type system, elevating types to first-class status.")
+(license gpl3)))
+
 ;;; guile.scm ends here
-- 
2.10.0

Re: FOSDEM 2016 was awesome! Let's do FOSDEM 2017 (we are IN!)

[Amirouche Boubekki]

On 2016-10-05 16:09, Pjotr Prins wrote:

Good news!

We have just been informed that GNU Guile/Guix has a half day devroom
for FOSDEM 2017 again.

  https://fosdem.org/2017/

Book your resp. flights/trains/boats!

Pj.



Yeah! That is good news! I will prepare my slides (and finish my project 
;)

Re: Guix world tour

[Amirouche Boubekki]

Héllo,

On Fri, Sep 30, 2016 at 11:45 AM Ludovic Courtès  wrote:

> The CUFP talk was in this very nice room with 60 people or so.  I
> focused on why and how we use Scheme extensively, explicitly comparing
> to Nix{,OS}, which the majority of the attendance already knew.  Among
> the questions I had, one was “how do I upgrade from Nix?” ;-), and
> another one was the inevitable (given the venue) “what do you think a
> static type system would bring you?”.
>

 What is the answer to the last question about static type system?


Thanks!

Re: FOSDEM 2016 was awesome! Let's do FOSDEM 2017

[Amirouche Boubekki]

On 2016-07-26 04:19, Pjotr Prins wrote:

FOSDEM 2017 call for proposals has started:

  https://fosdem.org/2017/news/2016-07-20-call-for-participation/

We need help with writing the proposal (we can build on last years
this time), we need help on selecting talks and we need help creating
the schedule. Finally, if we get a slot, we need help to organise the
day.

Who wants to be part of this exciting day?


I would love to have time to talk about guile-wiredtiger or another
project if it works out well.

I hope this goes as planned!




Pj.

On Tue, Feb 02, 2016 at 11:35:45AM -0800, Christopher Allan Webber 
wrote:

Alex Sassmannshausen writes:

> Hello,
>
> Ludovic Courtès writes:
>
>> Hi there!
>>
>> I just came back from FOSDEM where we had an awesome Guile devroom with
>> nice people and great talks!
>
> I really want to echo Ludo's sentiments.  I had a great time in our dev
> room and it was really nice to put faces to the names I see popping up
> in IRC and on the mailing list. I really hope we'll be able to do this
> again next year!

An extra echo from me.

>> The room of 80 seats was full pretty much all the time, and I think we
>> were all excited to see so many people stop by the devroom.  Many shared
>> the impression that we were at an important moment of Guile’s history.
>> The transition with the Lua track that followed was also insightful and
>> a pleasant experience.

I was optimistic about this being a big moment in Guile's history, but
after this FOSDEM, my enthusiasm and excitement has doubled, maybe
tripled!  I can't wait to see what's happening in the year ahead!

>> I would like to send a big Thank You to Pjotr Prins who took the
>> initiative and organized all this masterfully, from applying for the
>> devroom, to contacting potential speakers (dozens and dozens of
>> messages!), to getting up early on Saturday to make sure everything
>> would be fine in the devroom…  Pjotr, you did an awesome job!
>>
>> Thanks to Paul van der Walt who also woke up early to help out with
>> video in the devroom, and obviously, thanks to all the speakers and
>> attendees!
>
> +1 for sure.  Thank you very much for the commitment in time and energy!
>
> Alex

Yes, thank you! :)


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

Re: GNU Guix diagram

[Amirouche Boubekki]

Le 2016-03-04 04:31, myglc2 a écrit :
Upon installing GuixSD a month ago I found it difficult to get a grip 
on

GNU Guix' stucture. Because I like pictures I made a diagram showing
what I think I now understand about how GNU Guix' works. I am thinking
it might be helpful to Guix newcomers. Comments &/or corrections would
be most welcome. - George


This kind of incorrect because there is a directory which stores every
installed (or past installed) software which is linked inside profiles
(system, users, and custom profiles).

Users can't install program in the system profile, it can only be done
through system config.scm.

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

Re: Guix as a Guile package manager

[Amirouche Boubekki]

On 2016-01-09 15:06, Fabio Pesari wrote:

On 01/09/2016 02:05 PM, Amirouche Boubekki wrote:

There is a package manager https://github.com/ijp/guildhall with a
package
repository with automatic package publishing without review.


Asking users to install a separate package manager might work in some
cases (Leiningen, Composer) but it usually leads to fragmentation and
confusion (as it was the case with many Lisps, especially CLs).



That's one of the reason why I advocate for guix as package manager of 
guile.


I'm not a core developer, but I don't think it makes sens to fork. 
Most

if not all features of guix are required by language package manager.
This includes virtualenv since guix can do them via 'guix 
environment'.


I called for a fork because having Guix as both a general-purpose
package manager and a Guile-specific package manager is very confusing
and doesn't follow the UNIX philosophy.



Can you explain what a Guile specific fork of guix will bring over guix?


User should be able to upload packages but each package should be
carefully reviewed (possibly by the community itself).


This is not how pypi works for instance.


Somewhat related: even if I never saw a package rejected in guix, I
think
most contributors have some expectations regarding the quality of
packages
included in guix *main* repository. Otherwise said, I don't mind 
pushing

a
alpha software or snippet on pypi, but this is not the case with guix.

So maybe, it will be nice to have a guix repository dedicated to guile
modules where the expectations will much lower and where guilers
can freely share their small and not so small contributions.


I agree with you that users should be able to submit packages easily -
that's why I called for a fork, so that the standards for package
inclusion can be much lower (except for freedom, which is imperative)
and the Guile packages are by default separated from all other 
software.


This could also be achieved with a separate repo (like "guile-contrib"
or something along these lines) for Guix, sure, but I'd still like a
separate repo with a separate database and site, so that important
things like user ratings can be implemented independently from the 
other

Guix repos.



I just checked the documentation [1] and it's possible to have third 
party

repositories but the policy is to not fork the effort and package guile
softwares in guix.

[1] 
https://www.gnu.org/software/guix/manual/guix.html#index-GUIX_005fPACKAGE_005fPATH



Also, this will be a visible example of how to extend guix with third
party
package repository which is a significant asset is some commercial
situations.


I'm not against the idea of third party package repositories (I see no
reason why this functionality should not be implemented) but Guix 
should

focus on having every decent quality free program in its repositories,
so that people are not encouraged to use third-party repos.

I find it self-defeating that in distros like Parabola (or upstream,
Arch), fully functional and semi-popular programs like OpenArena,
pngquant and yuicompressor can only be found in the user repository 
(the

AUR), which also distribute proprietary software.

If people are encouraged to include third-party repos, freedom goes out
of the window pretty easily, so the official repositories should be as
complete as possible (I know it's easier said than done, but it should
be much easier for Guix compared to other package managers).


My question is: what must do a guix fork that guix doesn't have already?

Re: Guix as a Guile package manager

[Amirouche Boubekki]

Héllo,

On 2016-01-09 11:35, Fabio Pesari wrote:

Package managers have been immensely successful in increasing the
popularity of programming languages - think about Perl's CPAN or Ruby's
Gem. But Guile doesn't a package manager, and that in my opinion slows
down its adoption.


There is a package manager https://github.com/ijp/guildhall with a 
package

repository with automatic package publishing without review.


The Guix repos distribute a lot of useful Guile libraries (like
guile-json or guile-opengl) which can't be found on most distro
repositories and it already provides Guile APIs and package management
capabilities...


my question is, can Guix be forked into a full-blown Guile package 
manager

like gem from Ruby?


I'm not a core developer, but I don't think it makes sens to fork. Most
if not all features of guix are required by language package manager.
This includes virtualenv since guix can do them via 'guix environment'.

I think what could/should/must be done is settle on guix being the 
package
manager of Guile *and* document how to create package recipes for pure 
and
non-pure guile non autotools modules. Maybe declare guix the optional 
official

package manager something like that..


I know that an argument could be made that Guix can already be used in
this way, but there are many Scheme coders who don't need a system-wide
package manager


This is not an issue since IIRC you can install guix as a user. Not sure
what the status of this mode of operation is.

Also binary installation of guix is trivial, so it's not like something
that can forbid people using it. Having guix in other distros would be
of great help too.


and would rather use a program that can manage Guile
packages under a user root like ~/.guile and allow them to easily
distribute their packages


Again there is guildhall even if it doesn't have the polish (nice web 
ui)

of pypi or cpan, it's said to work.


(something like Python's virtualenvs would also be useful).


This is supported by guix.


Perhaps some of the Guix code can be moved to a library, so that both
the Guix and the Guile package manager binaries can reuse the same 
code.

Moving Guix' core to a library would also facilitate its inclusion in
things like PackageKit, as well as make it easier to create front-ends.

I'm not a package management expert so I'm not sure this idea is
feasible but I would really like Guile to become more
popular, and this I think would be a step in the right direction.


To repeat myself, I think we need more guidance and incentive on how to
include guile modules that are not autotools ready. For my usecase and a
lot of other modules I don't think it makes sens to have autotools if 
you
have guix. People who happen to not want to use/install guix, can 
resolve

dependencies themself and I don't see how autotools help anyway.

Somewhat related: even if I never saw a package rejected in guix, I 
think
most contributors have some expectations regarding the quality of 
packages
included in guix *main* repository. Otherwise said, I don't mind pushing 
a

alpha software or snippet on pypi, but this is not the case with guix.

So maybe, it will be nice to have a guix repository dedicated to guile
modules where the expectations will much lower and where guilers
can freely share their small and not so small contributions.

Also, this will be a visible example of how to extend guix with third 
party
package repository which is a significant asset is some commercial 
situations.


--
Amirouche ~ amz3 ~ http://www.hypermove.net

[PATCH] Add jpegoptim

[Amirouche Boubekki]

From 571d55ef3270adfcd2c8cf80d400aec5e12528ab Mon Sep 17 00:00:00 2001
From: Amirouche Boubekki <amirou...@hypermove.net>
Date: Fri, 13 Nov 2015 15:09:08 +0100
Subject: [PATCH] gnu: images: Add jpegoptim 1.4.3

* gnu/packages/images.scm (jpegoptim): New variable jpegoptim
---
 gnu/packages/image.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index bde327c..52717e7 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2014, 2015 Alex Kost <alez...@gmail.com>
 ;;; Copyright © 2014 Ricardo Wurmus <rek...@elephly.net>
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer <taylanbayi...@gmail.com>
+;;; Copyright © 2015 Amirouche Boubekki <amirou...@hypermove.net>
 ;;; Copyright © 2014 John Darrington <j...@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
@@ -104,6 +105,29 @@ image files in PBMPLUS PPM/PGM, GIF, BMP, and Targa file formats.")
 (sha256 (base32
  "1cz0dy05mgxqdgjf52p54yxpyy95rgl30cnazdrfmw7hfca9n0h0"))
 
+(define-public jpegoptim
+  (package
+   (name "jpegoptim")
+   (version "1.4.3")
+   (source (origin
+(method url-fetch)
+(uri (string-append "http://www.kokkonen.net/tjko/src/jpegoptim-;
+version ".tar.gz"))
+(sha256 (base32
+ "0k53q7dc8w5ashz8v261x2b5vvz7gdvg8w962rz9gjvkjbh4lg93"
+   (build-system gnu-build-system)
+   (inputs `(("libjpeg" ,libjpeg)))
+   (arguments
+;; no tests
+'(#:tests? #f))
+   (synopsis "Optimize JPEG images")
+   (description
+"jpegoptim provides lossless optimization (based on optimizing
+the Huffman tables) and \"lossy\" optimization based on setting 
+maximum quality factor.")
+   (license license:gpl2)
+   (home-page "http://www.kokkonen.net/tjko/projects.html#jpegoptim;)))
+
 (define-public libtiff
   (package
(name "libtiff")
-- 
2.4.3

Re: Should we start a Guix users wiki?

[Amirouche Boubekki]

Le 2015-09-08 00:08, Craig Barnes a écrit :

Hi Guix,

Some time ago I asked on IRC about a guix users wiki.  Someone suggest
that I propose one here (sorry it's taken so long).

I think that a wiki would be a good complement to the manual, which
while quite complete, lacks exhaustive examples (which would be
impractical).

I have found myself searching through the mailing list archives for
solutions, and trawling through relevant threads on a number of
occasions.  If this information was organized in a dedicated wiki it
would be much more accessible and would make it maintainable.


And it will make the community more visible.



As an example, Arch(Gnu)Linux's wiki is one of it's stronger points.  I
often end up there when searching for answers to application questions
for other distros.


Same over the gentoo/emacs wiki.

I would be more than happy to help maintain a Guix(SD) wiki, if needed 
I

would be happy to host it somewhere.


It seems to me that it was kind of some trouble that the wiki was hosted
by a third party at gentoo.



What do you think?



The only thing that I can think of, is that given the fact that guix 
will be soon distributed over gnunet. It makes more sens to have the 
official wiki also hosted on gnunet and make a copy of it available for 
reading on the www. Sure it's not done yet, and it needs to be coded. I 
think that we have all the pieces to make something like that happen.

Re: [GSoC update] Porting Guix to GNU/Hurd

[Amirouche Boubekki]

Le 2015-08-19 22:27, taylanbayi...@gmail.com a écrit :

Manolis Ragkousis manolis...@gmail.com writes:


[...]

But nevertheless we can safely say we have ported Guix to Hurd. :-)

[...]


Amazing news! :-)

Thanks so much for working on this.  I haven't tried out Hurd so far 
but
am meaning to do so eventually; sounds like my first Hurd system will 
be

GuixSD at the same time.  So much awesome in one system.


I second that. Thanks :)


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

Re: [PATCH] scripts: package: Add --install-from-file option.

[Amirouche Boubekki]

Le 2015-08-19 15:04, Thompson, David a écrit :

On Wed, Aug 19, 2015 at 4:27 AM, Amirouche Boubekki
amirou...@hypermove.net wrote:

Le 2015-08-09 17:59, David Thompson a écrit :


In my personal projects, I keep a 'package.scm' file in the root of 
the

source tree for use with 'guix environment -l'.  However, it's also
handy to install that package by using 'guix package -e':

guix package -e '(primitive-load package.scm)'

This patch adds a shorthand for this:

guix package -f package.scm



What about dispatch `guix package -i` depending on the argument. In
principle there will be no *.scm$ packages so the above could be

  guix package -i package.scm

The idea behind that is to keep the number of command to minimum. In 
this

case, IMO, it makes sens to merge both logic inside the same UI.


That won't work because it creates ambiguities in the package spec
syntax.


Thanks.


How can one tell if a package spec or a file name was passed
with 100% accuracy?


Honestly I have the feeling that you are pushing your idea more than 
trying to make things better.


- Adding the `-f` modifier won't help make guix package command easy to 
the mind.


- Especially since the command it will replace is simple

- The command targets developpers and is only useful in the context of 
building project from sources which are not released. It can go inside a 
Makefile.


For this reason I don't like it being inside guix.


You can't, and we'd have to use a heuristic that
would surely fail in some awful way for someone.  It's best for this
to be a separate argument.


You know you are wrong. You can simply ban packages which ends with .scm 
which is not too difficult to do and is already possible with current 
packages.


My opinion, is that instead of adding options/modifiers to guix 
package, it should be split into guix package install, guix package 
search, guix package show and guix package generation. It might not 
be obvious and is afaik not a cli layout that is widespread but it will 
greatly help people get their hands on guix.


I get lost and don't remember all the apt-foo commands and what they are 
supposed to do. Using this scheme will keep each subcommand --help (or 
just help) more readable.

Re: [PATCH] scripts: package: Add --install-from-file option.

[Amirouche Boubekki]

Le 2015-08-09 17:59, David Thompson a écrit :

In my personal projects, I keep a 'package.scm' file in the root of the
source tree for use with 'guix environment -l'.  However, it's also
handy to install that package by using 'guix package -e':

guix package -e '(primitive-load package.scm)'

This patch adds a shorthand for this:

guix package -f package.scm


What about dispatch `guix package -i` depending on the argument. In 
principle there will be no *.scm$ packages so the above could be


  guix package -i package.scm

The idea behind that is to keep the number of command to minimum. In 
this case, IMO, it makes sens to merge both logic inside the same UI.


On a similar note, I like a lot the idea of Andy Wingo `guix install` 
and `guix search`.




The motivation for this is to ultimately encourage other people to keep
a 'package.scm' file in their own repos for building reproducible
development environments and easily testing development snapshots, like
what we do with our 'guix-devel' package.

I'd like to add the same option for 'guix build', if this is approved.

Re: [PATCH] scripts: package: Add --install-from-file option.

[Amirouche Boubekki]

Le 2015-08-19 10:27, Amirouche Boubekki a écrit :

Le 2015-08-09 17:59, David Thompson a écrit :
In my personal projects, I keep a 'package.scm' file in the root of 
the

source tree for use with 'guix environment -l'.  However, it's also
handy to install that package by using 'guix package -e':

guix package -e '(primitive-load package.scm)'

This patch adds a shorthand for this:

guix package -f package.scm


What about dispatch `guix package -i` depending on the argument. In
principle there will be no *.scm$ packages so the above could be

  guix package -i package.scm

The idea behind that is to keep the number of command to minimum. In
this case, IMO, it makes sens to merge both logic inside the same UI.

On a similar note, I like a lot the idea of Andy Wingo `guix install`
and `guix search`.


To be precise I prefer, `guix package install` and `guix package search` 
(which is not the subject of patch of Andy Wingo).

Re: FOSDEM 2016

[Amirouche Boubekki]

Le 2015-08-18 12:32, Pjotr Prins a écrit :
We should propose a Guile + Guix developers track for FOSDEM. They 
usually have
Ruby/Perl/Python dev tracks, so Guile will fit right in. I am sure we 
can
generate enough interesting talks on aspects of Guix packaging, for 
one.


Deadline for dev room proposals is half September.

Anyone want to help organise this or even take the lead? And talks that 
can be

had? We can have a hackathon one day before (or after) FOSDEM too.

And who else can (with some likelihood) come to Brussels if February? 
FOSDEM is
my favorite conference and there is something for everyone involved in 
FOSS.


People who go tend to come back. It's messy, it's fun.

Pj.


Good idea. I may come, but I'm not in position to propose a talk!

Re: question and suggest

[Amirouche Boubekki]

Le 2015-08-14 10:17, Dika Setya Prayogi a écrit :

q: I heard guixsd have a guixsd hurd under development, is that true ?


Yes, have look at the mailling list archive [1] to learn more about the 
state of the project.


[1] 
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=HURDsubmit=Searchidxname=guix-devel

s: (wish) I suggest a recent package updates page in guixsd web, this 
is

useful for packagers


The dev team is small enough to not require that feature right now, I 
think. If you want to know whether a package was added recently you only 
need to update the package repository and do a search:


$ guix pull
$ guix package -A $PACKAGE_NAME

`guix web` does not use a dedicated database, underneath it use basicaly 
`guix` command so at the time of writing the information you can access 
via `guix web` is more or less the information that is available in 
`guix`.


FWIW the simplest way to add this feature is to parse `git log` output 
(and maybe `git show`) or code guile bindings for libgit2. Maybe guix 
and guix web dev know better.

Re: Call for testing : guix-tox, a version of tox that uses guix environment.

[Amirouche Boubekki]

On 2015-07-10 03:38, Christopher Allan Webber wrote:

Cyril Roelandt writes:


Hey!

Those of who you write Python code probably know tox[1], a tool used 
to

manage tests/builds for Python. It uses virtualenv[2], which allows
developers to create isolated environments and install packages
without polluting their systems.

I hacked tox to replace virtualenv with guix environment. The code 
is

available at https://git.framasoft.org/Steap/guix-tox , in the
guix-tox branch (the master branch is just a mirror of tox). Note 
that

I will probably use git push -f on this branch :) I explained the
details in README.rst.

If there are Python developers on this list, I would love to know what
they think about this.


This is great! I'll have a look at it this week end.


I intend to propose a 20 minute talk about
guix-tox at the next PyConFR.


Nice!


This is great!  I've also been very interested in guix environment as
a universal virtualenv.  Replacing tox is an excellent example/usage!


I wondering whether it is possible to use the same recipe for `guix 
environment` and `guix container`. The idea behind that is that one can 
use environment for dev and container for deployment.

Re: [PATCH] gnu: Add rhythmbox.

[Amirouche Boubekki]

On 2015-07-05 19:45, Amirouche Boubekki wrote:

On 2015-07-05 17:28, David Hashe wrote:

Hi Ludo and Ricardo,

The 'uridecodebin' error is a result of GST_PLUGIN_SYSTEM_PATH not
being set. However, the recent patch to gstreamer adds that to its
native search paths, so that error should be resolved now on an
updated system. I had a line defining GST_PLUGIN_SYSTEM_PATH in my
.bashrc, but I was able to remove it after that patch was applied.
Rhythmbox is working without errors for me.

I've also realized that some of the packages I put under inputs should
probably be propagated inputs, so I'm attaching an updated patch which
changes that.

I am currently using guix over ubuntu.


I use GuixSD. I patched my guix git repository just after they were 
published.


It works, or more precisly it can work:

- I have the following in my .bashrc:

export GST_PLUGIN_SYSTEM_PATH=$HOME/.guix-profile/lib/gstreamer-1.0
export GRL_PLUGIN_PATH=$HOME/.guix-profile/lib/grilo-0.2

- Also I installed several gstreamer packages.

I only tried to play mp3 and ogg. Ogg works. I did not try burning 
audio cds.

I will try later today or tomorrow.


Both cd burning and ripping doesn't work:

- audio burn: the plugin appears in the list of plugins and can be 
activated. When activated it doesn't appear in the player UI to actually 
burn playlists

- ripping: no mention of it at all in the UI







Thanks,

David

On Sun, Jul 5, 2015 at 6:44 AM, Ricardo Wurmus rek...@elephly.net
wrote:


So, I applied the patch, built rhythmbox, and installed it into a
separate profile. It starts up fine and begins importing files

from

~/Music but I get a *lot* of import errors:

“Couldn’t create ‘uridecodebin’ element”

I see this for a great many ogg and mp3 files in my ~/Music

directory

under “Import Errors”. In fact, none of my audio files in

~/Music were

imported at all.




I used to have errors when I did not install gstreamer plugins.

Re: Third party guix repositories could be used for housing guile modules and other things.

[Amirouche Boubekki]

On 2015-06-22 18:27, crocket wrote:

Guile hasn't had an official repository. That's why guile hasn't
accumulated thousands of modules.
Since the official gnu guix repository is mainly for GuixSD, it makes
sense to make another guix repository for guile modules to be used on
multiple linux distributions. I'm not sure if guix works on windows
and Mac OS, too.

If you made it possible to add third party guix repository URLs,
people would add third party repositories later without upfront
coordination with guix developers.


To be honest I could be interested to have another repository with guix
recipes where it's easier to contribute and/or dedicated to guile.

But this will still be only available only to GNU/Linux users.

Also, I'd better stay focus on guix. There is guildhall for guile, take 
it as the official Guile package manager if you


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

Re: Guix package steps

[Amirouche Boubekki]

On 2015-06-22 15:42, Daniel Pimentel wrote:

On 2015-06-22 03:09, Mark H Weaver wrote:

Daniel Pimentel d...@openmailbox.org writes:


On 2015-06-17 00:57, Mark H Weaver wrote:

Daniel Pimentel d...@openmailbox.org writes:


I tried create new packages (ipcalc, nmap, xfburn and others) but
without success.

My steps (based on talk GNU Guix packaging by Andreas Enge):
0. Git clone guix repository by savannah;
1. Copy gnu/package/indent.scm to mypackage.scm in this same 
folder;

2. Add module to gnu-system.am
3. Download mypackage;
4. Edit mypackage.scm and add hash, license and other information;
5. ./pre-inst-env guix build mypackage -K
6. Erro: bash: ./pre-inst-env: No such file or directory

But there is pre-inst-env.in only. The script pre-inst-env not 
exist

in repository. So where is pre-inst-env?


You have to build guix before you can run it.  See
doc/contributing.texi, especially the Building from Git section.
Also, you should pass --localstatedir=/var to ./configure.

 Mark


I tried again, follow README file but there's a error (dot command?)
when I run make:

/bin/sh /home/dani/Desktop/development/git/guix/build-aux/missing dot
-Tpng -Gratio=.9 -Gnodesep=.005 -Granksep=.5 -Nfontsize=9
-Nheight=.1 -Nwidth=.1  doc/images/bootstrap-graph.dot 
doc/images/bootstrap-graph.png.tmp
/home/dani/Desktop/development/git/guix/build-aux/missing: line 81:
dot: command not found


'dot' is part of the graphviz package, which is listed as a required
package in the Building from Git section that I cited above.

  Mark


Hi Guix,

After:
-clone Guix repository - ok
-Read README and install requirements - ok
-guix environment guix - ok
-./configure --with-libgcrypt-prefix=$HOME/.guix-profile/ - ok
-make - ok
-make check - error: FAIL: tests/lint.scm

I tried again build (./pre-inst-env guix build ipcalc -K): guix build:
error: failed to connect to
`/usr/local/var/guix/daemon-socket/socket': No such file or directory



You need to run the guix daemon [1], but before create as root the guix 
builders [2]:


# groupadd --system guix-builder
# for i in `seq 1 10`;
  do
useradd -g guix-builder -G guix-builder   \
-d /var/empty -s `which nologin`  \
-c Guix build user $i --system  \
guix-builder$i;
  done

The guix-daemon program may then be run as root with:

# guix-daemon --build-users-group=guix-builder

Also don't forget to add hydra pub key as discribed in [3]:

# guix archive --authorize  hydra.gnu.org.pub

[1] 
https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix_002ddaemon
[2] 
https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
[3] 
https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation

Re: [PATCH] import: pypi: Detect inputs.

[Amirouche Boubekki]

On 2015-06-21 22:56, l...@gnu.org wrote:

Amirouche Boubekki amirou...@hypermove.net skribis:


If I'm not mistaken this patch relies only on the presence of
requirements.txt. This is not a required file in python
packaging. otherwise said, we miss a lot using this method. I think
the best way to do that would be to:

- download the package and extract it
- create an environment (#)
- create a virtual env with access to system site package of the
environment (#)
- enter the venv and install the package
- use `pip freeze -l` to retrieve the full set of dependencies


Cyril, WDYT?

I’m not familiar with the details, but my feeling is that reading
requirements.txt is more lightweight, simpler, and more robust than 
what

you propose.

So I’d be inclined to apply Cyril’s patch ASAP.


Yes of course, it super helpful. It's not comprehensive, that's all I 
liked to say, that is all.

Re: [PATCH] guix: scripts: Add --dependencies=PACKAGE commmand

[Amirouche Boubekki]

Sorry my patch was missing a file.

On 2015-06-20 18:45, Amirouche Boubekki wrote:

This is a first patch to request the interest and the feedback of the
community to have something like that in guix and how it should be
done.

 guix packacge --dependencies=PACKAGE

That will output the dot program required to generate a graph with 
graphviz.


The full bash line can be:

 guix package --dependencies=qsynth | dot -Tpng  qsynth-deps.png 
icecat qsynth-deps.png


There is a *bug*: I am using `find-packages-by-name` which returns
several packages,  but when the output is passed to graphviz only one
of the package is drawn.

There is also an interactive web output [1].


HTH,

[1] 
http://www.hyperdev.fr/_drafts/guix-dependencies-in-sigmajs/sigmajs/


--
Amirouche ~ amz3 ~ http://www.hyperdev.frFrom fca3a1020af9d4abe71ab8ab4e2a52011688f272 Mon Sep 17 00:00:00 2001
From: amz3 amirou...@hypermove.net
Date: Sat, 20 Jun 2015 18:23:26 +0200
Subject: [PATCH] guix: scripts: add --dependencies=PACKAGE command

exemple usage:

  guix package --dependencies=qsynth | dot -Tpng  qsynth-deps.png

* guix/scripts/package.scm: add --dependencies command
* guix/scripts/dependencies.scm: graph datastructure and helpers
---
 guix/scripts/dependencies.scm | 312 ++
 guix/scripts/package.scm  |  23 
 2 files changed, 335 insertions(+)
 create mode 100644 guix/scripts/dependencies.scm

diff --git a/guix/scripts/dependencies.scm b/guix/scripts/dependencies.scm
new file mode 100644
index 000..448d83d
--- /dev/null
+++ b/guix/scripts/dependencies.scm
@@ -0,0 +1,312 @@
+;; FIXME: copyright
+
+(define-module (guix scripts dependencies)
+  #:use-module (srfi srfi-9)
+  #:use-module (srfi srfi-9 gnu)
+  #:use-module (srfi srfi-11)
+  #:use-module (ice-9 rdelim)
+  #:use-module (guix packages)
+  #:use-module (gnu packages audio)
+  #:export (display-dependencies))
+
+
+;; Immutable graph datastructure
+
+;; FIXME: Taken from Guile, should be in (srfi srfi-99)
+;;adapted to make it possible to declare record type like `abc' and keep
+;;field accessor bracket free. record name *must* have brackets or everything
+;;is broken
+;;
+;; Usage:
+;;
+;;   (define-record-type abc field-one field-two)
+;;   (define zzz (make-abc 1 2))
+;;   (abc-field-one zzz) ;; = 1
+;;
+;; FIXME: maybe this is less useful than the immutable record of (srfi srfi-9 gnu)
+;;Right I will use `set-field` and `set-fields`
+(define-syntax define-record-type*
+  (lambda (x)
+(define (%id-name name) (string-symbol (string-drop (string-drop-right (symbol-string name) 1) 1)))
+(define (id-name ctx name)
+  (datum-syntax ctx (%id-name (syntax-datum name
+(define (id-append ctx . syms)
+  (datum-syntax ctx (apply symbol-append (map syntax-datum syms
+(syntax-case x ()
+  ((_ rname field ...)
+   (and (identifier? #'rname) (and-map identifier? #'(field ...)))
+   (with-syntax ((cons (id-append #'rname #'make- (id-name #'rname #'rname)))
+ (pred (id-append #'rname (id-name #'rname #'rname) #'?))
+ ((getter ...) (map (lambda (f)
+  (id-append f (id-name #'rname #'rname) #'- f))
+#'(field ...
+ #'(define-record-type rname
+ (cons field ...)
+ pred
+ (field getter)
+ ...))
+
+(define-record-type* node identifier label outgoings incomings properties)
+
+
+;;;
+;;; Store
+;;;
+;;; Memory bound immutable association
+;;;
+
+
+;; XXX: It's assumed that keys are strings.
+;;
+;; This replace scheme assoc, because:
+;; 1) there is no immutable `assoc-set` in scheme
+;; 2) `acons` (and friends) can replace `assoc-set` but memory will grow without bound
+;; 3) `assoc-ref` (and friends) always return `#f` when no values is found
+;; 4) `vlist` and else can not be easily written to disk
+;; 5) It's fun
+
+
+(define (store-set store key value)
+  Return a copy of STORE where KEY is set to VALUE
+  (let loop ((assoc store)
+ (out '()))
+(if (null? assoc)
+(cons (cons key value) out)
+(if (equal? (caar assoc) key)
+(append (list (cons key value)) out (cdr assoc))
+(loop (cdr assoc) (cons (car assoc) out))
+
+
+(define (store-ref store key)
+  Return the value of KEY in STORE, if KEY is not found return #nil
+  (let loop ((assoc store))
+(if (null? assoc)
+#nil
+(if (equal? (caar assoc) key)
+(cdar assoc)
+(loop (cdr assoc))
+
+(define (store-del store key)
+  Return a copy of STORE where the KEY association doesn't exists
+  (let loop ((assoc store)
+ (out '()))
+(if (null? assoc)
+store
+(if (equal? (caar assoc) key)
+(append out (cdr assoc))
+(loop (cdr assoc) (cons (car assoc) out))
+
+
+;;;
+;;; Graph
+;;;
+
+(define

[PATCH] guix: scripts: Add --dependencies=PACKAGE commmand

[Amirouche Boubekki]

This is a first patch to request the interest and the feedback of the 
community to have something like that in guix and how it should be done.


 guix packacge --dependencies=PACKAGE

That will output the dot program required to generate a graph with 
graphviz.


The full bash line can be:

 guix package --dependencies=qsynth | dot -Tpng  qsynth-deps.png  
icecat qsynth-deps.png



There is a *bug*: I am using `find-packages-by-name` which returns 
several packages,  but when the output is passed to graphviz only one of 
the package is drawn.


There is also an interactive web output [1].


HTH,

[1] http://www.hyperdev.fr/_drafts/guix-dependencies-in-sigmajs/sigmajs/

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

Re: [PATCH] import: pypi: Detect inputs.

[Amirouche Boubekki]

On 2015-06-19 17:32, Christopher Allan Webber wrote:

Amirouche Boubekki writes:


Héllo,


If I'm not mistaken this patch relies only on the presence of
requirements.txt. This is not a required file in python packaging.
otherwise said, we miss a lot using this method. I think the best way 
to

do that would be to:

- download the package and extract it
- create an environment (#)
- create a virtual env with access to system site package of the
environment (#)
- enter the venv and install the package
- use `pip freeze -l` to retrieve the full set of dependencies


Using pip freeze is an interesting idea.

Setting up a virtualenv... that's interesting.  Would it be written to 
a

temporary directory?


My bad, it's probably not a good idea to have that without containers, 
as it execute some code that we don't know what it does - the setup.py. 
The best way to go is to parse the setup.py *and* requirements.txt.


I attached a script that does what I described without the `guix 
environment`.


Using `guix environment` might be a good idea to prepapre a recipe 
without polluting its own profile.


HTH.
if [ $1 ]
then
wget -q $1 -O - | tar xz  .pypi-guess-deps.log 21
virtualenv .venv  .pypi-guess-deps.log 21
source .venv/bin/activate  .pypi-guess-deps.log 21
cd *  python setup.py install  .pypi-guess-deps.log 21
pip freeze -l
else
   echo Usage: pypi-guess-deps.sh PACKAGE-URL

log is written to `pypi-guess-deps.log`

fi

Re: guix edit

[Amirouche Boubekki]

On 2015-06-17 21:15, l...@gnu.org wrote:

Amirouche Boubekki amirou...@hypermove.net skribis:


A usecase, I have in mind from experience, is being in vm/container
and having to edit the recipe for that specific vm *but* that recipe
is in the main normal repository. Like for instance, gcc for a
specific target. `guix edit gcc:4.5' should open or clone the correct
recipe.


Yes, ‘guix edit gcc-4.7’ edits the recipe for GCC 4.7.4.


I'm not sure this is real usecase for guix or maybe it's not required at 
all and was specific to the way we were working in my company. I think 
it's not supported right now in guix, but in Gentoo it does. You can 
have serveral repositories and some repositories specific to one target. 
GCC 4.7 can be overriden in the target specific repository. The reason 
this is helpful, is that when we put a software version in stable - 
ready to be built, we are sure it has no impact on other targets.


Right now it can of work with the env variable that guix package use to 
look for packages.




Regards

Re: inside the Guile REPL

[Amirouche Boubekki]

On 2015-06-16 09:04, Pjotr Prins wrote:

I have started to document how to use Guix from the Guile REPL.
Tips/hints wanted from experienced hackers! This is not only to keep
my memory fresh, it may be useful for others.


https://github.com/pjotrp/guix-notes/blob/master/HACKING.org#debugging-the-package

If this is covered elsewhere I would like to know. I find the Guix
documentation itself accurate, but maybe a little terse ;). Using
Org-mode is probably the way to do it, though I find Ludo's work on


https://en.wikisource.org/wiki/Functional_Package_Management_with_Guix/Build_expressions_and_package_descriptions

to be quite useful.


Both resource are super useful. Thanks both of you.


Pj.


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

Re: guix edit

[Amirouche Boubekki]

On 2015-06-16 22:26, l...@gnu.org wrote:

While looking at another package manager for ideas to steal, I found
this one to be a good candidate:

  guix edit gcc-4.8

will open $EDITOR (aka. “emacsclient”) on the definition of that
package.  This is pretty handy for developers (even when otherwise 
using

Geiser, I think.)

For “regular users,” it’s less useful because most of the time it will
open an immutable file.


It's nice, even in read-only mode, to explore how guix is made.


However, I envision a --clone option that would
create a file with a module declaration and a template like:

  (define my-gcc
(package (inherit gcc)
  ;; Complete here...
  )

(This part is left as an exercise to the reader.)

WDYT?


A usecase, I have in mind from experience, is being in vm/container and 
having to edit the recipe for that specific vm *but* that recipe is in 
the main normal repository. Like for instance, gcc for a specific 
target. `guix edit gcc:4.5' should open or clone the correct recipe.





Thanks,
Ludo’.


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

Re: GuixSD tee-shirts and hoodies available

[Amirouche Boubekki]

I got hoodie, I hope it will warm me a little more than the one I wear
right now :)

2015-04-09 13:42 GMT+02:00 Daniel Pimentel d...@openmailbox.org:
 On 2015-04-08 16:09, Luis Felipe López Acevedo wrote:

 Hi,

 I just created a GuixSD tee-shirt and hoodie in teespring:
 http://teespring.com/guixsd-for-the-libre-geek .

 For those who can afford it, I hope you enjoy it :)

 Great work!

 --
 Daniel Pimentel (d4n1)

Re: [ART] Website mockup rev1

[Amirouche Boubekki]

On Wed Feb 18 2015 at 12:29:43 AM Luis Felipe López Acevedo 
felipe.lo...@openmailbox.org wrote:

 Hi,

 Here is a revision of the last website mockup [1].

 White header
 http://sirgazil.bitbucket.org/static/temp/img/guixsd/home-
 view-white-rev1.png


+1


 Black header
 http://sirgazil.bitbucket.org/static/temp/img/guixsd/home-
 view-black-rev1.png

 Adam Pribyl commented, The other thing is that the page design
 outperforms the state of the distribution - sorry to say that, but while
 page feel very user friendly, the distribution has a way to go... [2]

 I understand Adam's worry, but I think that a global message box could
 be used to warn the readers:

 http://sirgazil.bitbucket.org/static/temp/img/guixsd/alpha-message.png

 Or, instead of the global message box, the same message could be used in
 the Download page.


 What do you think?


I'm not sure.

+ Alpha software is alpha software and should be understood as such.

+ The message blend nicely with the page and also invite the user to join
the project, so it can be a better option than alpha alone which can be
understood as it's fully broken, with no support and it will delete all
your data including connected usb devices...


 Thanks.



 [1] https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00450.html
 [2] https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00482.html


 --
 Luis Felipe López Acevedo
 http://sirgazil.bitbucket.org/

Re: [ART] Updated GRUB background with GuixSD logo

[Amirouche Boubekki]

On Mon Feb 16 2015 at 5:27:28 PM Taylan Ulrich Bayırlı/Kammer 
taylanbayi...@gmail.com wrote:

 Luis Felipe López Acevedo felipe.lo...@openmailbox.org writes:

  I think that the gradients that give the illusion of twist are still a
  bit hard to see. So here is variant C with retouched gradients:
 
  http://sirgazil.bitbucket.org/static/temp/img/guixsd/C-grub-
 retouched-twist.png
 
  I think it looks better. But here is a D variant which includes the
  retouched twist of C and adds a drop shadow:
 
  http://sirgazil.bitbucket.org/static/temp/img/guixsd/D-grub-
 retouched-drop-shadow.png
 
  This shadow is more subtle than the one used in the current GRUB image,
  but it may still flatten the logo because it is bevelled.
 
  I like C and D, but would go with C to avoid the problem you mention.
 
  What do you think?

 I really like D.  C is great too.  Just my 2 layperson cents.

 Taylan


+1

Re: [ART] Website mockup

[Amirouche Boubekki]

2015-02-16 18:23 GMT+01:00 Luis Felipe López Acevedo
felipe.lo...@openmailbox.org:
 El lun, 16-02-2015 a las 11:09 +, Amirouche Boubekki escribió:
  http://sirgazil.bitbucket.org/static/temp/img/guix/home-yellow-header.png


 - less constrast
 - logo is good but I'm not sure it will work the same over a white
 background

 The header background is supposed to stay yellow in this version, if you
 go to another page, for example. It is just that it matches the current
 background color of the section below it.

Ok, I wasn't thinking about that.

What wanted to say: if the logo must appear in the frontpage or like
in this case in the header
it must be the official logo for consistency reason, so that the GSD
visual identidy is easier to remember.

I'm not sure what is the official logo, that said the one used in the
yellow header doesn't have enough contrast over a white background. I
don't know maybe it can work.





 Here my first few impressions:


 About the part just below the header :


 - in the text, emphase done in black seems bizarre to me
 - the monitor looks good, maybe the screen has too much shadow


 I like those two things though :)


 - the banner is good  convincing


 - the button are too dark and the text shadow shifts too far
 - the color of the button goes with the background found in the
 monitor, what happens when the background change?

 Usually, the default background of the system changes only with major
 releases, and websites tend to be updated as well for the new version,
 so I guess the buttons would change accordingly.

You are right.

 - I'm not sure about the button color (complementary color).


 But I'm with you on this one. I'm not sure either :)



 - Maybe a button like http://clojurescriptone.com/ might work better
 (without the font and smaller)
 - I think that only the download button (with last version number
 somewhere) is required. Overview is already visible in screenshot
 section  header.


 I like that idea: just the download button (with version number), and
 include a link to the overview in the screenshots section.


 - I'm not sure the wave separator is the best thing. That's what makes
 it more casual.


 I feel the same way.


 In the screenshot section, maybe a link to overview is required.


 There is no blog link in the header
 There is no about link in footer. I'm not sure an about page is
 required, since the frontpage can do that job.


 That's confusing, isn't it? I'll fix header and footer mismatch.

 As for the About section, I was thinking on something like what is
 used in blender.org.

Again, I agree.


 There is no mention of guix package manager.

 I was thinking on doing that on the Overview and Packages pages. But
 I think I can try adding something in the front page as well (advanced
 package manager called GNU Guix).


 Maybe doing a mockup including a FSF campaign banner, to avoid akward
 design in this situations.


 I don't think I understand what you mean here.

I can't find an example right now. It's wikipedia that does that for
its crowdfunding campaign.



 The overall looks very good. It's looks unique  modern. The page is
 not too large  the font size not too small. Very good job. Among all
 the above, it's really the complementary color that looks odd. It has
 its strength, but it seem old fashioned to me.


 Thank you very much for the great feedback, Amirouche. I'm taking note
 of all these for a next mockup.

Re: [ART] Website mockup

[Amirouche Boubekki]

,

Luis Felipe López Acevedo felipe.lo...@openmailbox.org writes:

 Hi,

 Here is a mockup for the website:

 http://sirgazil.bitbucket.org/static/temp/img/guix/home-black-header.png

The black header looks strange because the rest of the page is very light.


 And some variants with white and yellow headers:

 http://sirgazil.bitbucket.org/static/temp/img/guix/home-white-header.png

I prefer that one because the logo looks better  header contrast is better.
It doesn't look strange with the next part, which has a strong color.

 http://sirgazil.bitbucket.org/static/temp/img/guix/home-yellow-header.png

- less constrast
- logo is good but I'm not sure it will work the same over a white
background

Here my first few impressions:

About the part just below the header :

- in the text, emphase done in black seems bizarre to me
- the monitor looks good, maybe the screen has too much shadow
- the banner is good  convincing

- the button are too dark and the text shadow shifts too far
- the color of the button goes with the background found in the monitor,
what happens when the background change?
- I'm not sure about the button color (complementary color).
- Maybe a button like http://clojurescriptone.com/ might work better
(without the font and smaller)
- I think that only the download button (with last version number
somewhere) is required. Overview is already visible in screenshot section 
header.
- I'm not sure the wave separator is the best thing. That's what makes it
more casual.

In the screenshot section, maybe a link to overview is required.

There is no blog link in the header
There is no about link in footer. I'm not sure an about page is required,
since the frontpage can do that job.

There is no mention of guix package manager.

Maybe doing a mockup including a FSF campaign banner, to avoid akward
design in this situations.

The overall looks very good. It's looks unique  modern. The page is not
too large  the font size not too small. Very good job. Among all the
above, it's really the complementary color that looks odd. It has its
strength, but it seem old fashioned to me.




On Mon Feb 16 2015 at 10:14:17 AM Taylan Ulrich Bayırlı/Kammer 
taylanbayi...@gmail.com wrote:

 Luis Felipe López Acevedo felipe.lo...@openmailbox.org writes:

  Hi,
 
  Here is a mockup for the website:
 
  http://sirgazil.bitbucket.org/static/temp/img/guix/home-black-header.png
 
  And some variants with white and yellow headers:
 
  http://sirgazil.bitbucket.org/static/temp/img/guix/home-white-header.png
 
  http://sirgazil.bitbucket.org/static/temp/img/guix/home-
 yellow-header.png
 
  As always, feedback is very welcome.

 Great!  I like it how friendly the page is.  My only beef is that I
 dislike plastic looks, but that might be just my personal preference.
 Would have preferred a more professional look to give a hint of the
 technical superiority of the system. ;-)

 I think I like the yellow header most.

 Taylan

Re: [ART] Logo proposal

[Amirouche Boubekki]

 I like all logos I have seen so far, but as Taylan I think we should not
 brand GSD too much and stay as close as we can to the GNU brand

Luis GSD logo is really close to GNU branding. Looks more modern. Maybe it
should use the same colors?

On Mon Feb 09 2015 at 1:38:01 PM Andreas Enge andr...@enge.fr wrote:

 Hello!

 I like all logos I have seen so far, but as Taylan I think we should not
 brand GSD too much and stay as close as we can to the GNU brand.

 And send more packages - I have the impression our rate slowed down since
 we reached the 1000 packages milestone ;-)

 Andreas

Re: Large git repositories

[Amirouche Boubekki]

On Mon Jan 12 2015 at 11:03:48 PM Andreas Enge andr...@enge.fr wrote:

 Hello,

 I am trying to package the droid font family. It appears to be available
 only via the android git at:
https://android.googlesource.com/platform/frameworks/base/+
 /android-4.4.4_r2.0.1/data/fonts/
 where
https://android.googlesource.com/platform/frameworks/base.git
 defines the git repository.

 This page contains a tgz download link:
https://android.googlesource.com/platform/frameworks/base/+
 archive/android-4.4.4_r2.0.1/data/fonts.tar.gz
 Unfortunately, the file seems to be generated on the fly and have a
 different hash value each time.

 The git-reference method seems to clone all of the repository, which has
 about 1.5 GB. I tried several methods by hand, such as
git clone -b android-4.4.4_r2.0.1 https://android.googlesource.
 com/platform/frameworks/base.git data/fonts
 or
git init; git fetch https://android.googlesource.
 com/platform/frameworks/base.git android-4.4.4_r2.0.1
 but all of them apparently download the full repository.

 I also tried
git archive --remote=https://android.googlesource.com/platform/
 frameworks/base.git android-4.4.4_r2.0.1 data/fonts
 but the git server apparently does not support this:
 fatal: Operation not supported by protocol.
 (and I am also not sure that the output would have a fixed hash).

 Do you see any solution to this problem?


Google web fonts has droid font available in zip format via http [1],
not sure if the link is works across updates.

There is also the mercurial repository hosting all web fonts [2]. It's
quite big 4,1G and AFAIK there is no “hg clone --depth=1”


[1]
http://www.google.com/fonts#UsePlace:use/Collection:Droid+Sans:400,700|Droid+Sans+Mono|Droid+Serif:400,700,400italic,700italic

[2] https://code.google.com/p/googlefontdirectory/source/checkout

Andreas

Re: guix pull fails for me

[Amirouche Boubekki]

2015-01-01 19:41 GMT+01:00 Adam Pribyl pri...@lowlevel.cz:
 On Thu, 1 Jan 2015, Amirouche Boubekki wrote:

 Hi,

 guile-json is missing for some reason. Maybe you can install it


 Installing guile-json as root makes no difference.

 manually or from a guix git checkout. I'm curious can you provide the
 guix --version:


 guix package -i git is quite a job... even this is a devel list I am just a
 user here.

Like every first time, it can be overhelming. I think the simplest thing to do
is to create another disk image with guix 0.8 (for real). I could do
that, but it's less
pedagogical.

Once you have git repo configured and compiled you can do that yourself. And
you might not need it at all if you can install guile-json from there.

I'm not sure in which situation you are:

- installed guix systems from 0.8 disk install,
- or in the 0.8 disk install

Can you still install packages with guix? ie. guix package -i dwm?

There might be another solution, that doesn't involve using guix from git:

- Using guile json tarball https://github.com/aconchillo/guile-json#installation
- use --prefix=/var/guix/profiles/system/profile/share
- install as root
- do guix pull as root
- and install guile-json (again as root), to put things in order

If you are missing some autotools, and you can't use guile-json install script,
you can copy manually things to
/var/guix/profiles/system/profile/share/guile/site/2.0:

  # cp -r json* /var/guix/profiles/system/profile/share/guile/site/2.0

 Got the git clone git://git.savannah.gnu.org/guix.git, but it is not obvious
 what to do with it. The README in Installation says
 See manual:
   info -f doc/guix.info (guix) Installation
 there is nothing like this in cloned repo.

Yes, before doing make the documentation is still in texi format, doc/guix.texi.

There is also relevant documentation in HACKING file, the .texi file
is available in html
online http://www.gnu.org/software/guix/manual/guix.html

 Same doc with Installing Guix from Guix requires me to run configure/make
 but there is no configure in the cloned repo.

 Running bootstrap ends with:

It's correct, refer to HACKING file, to know how to fix this. You
probably need to run:

guix package --install autoconf automake bzip2 gcc-toolchain gettext \
 guile libgcrypt pkg-config sqlite

 configure.ac:55: error: possibly undefined macro: PKG_CHECK_MODULES
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.
 autoreconf:
 /gnu/store/50qbjh51jaay21gdpv91bff81k1fcqjh-autoconf-2.69/bin/autoconf
 failed with exit status: 1

 Every way I try ends in a dead end.

 - as a user
 - as root


 Both
 guix --version
 guix (GNU Guix) 0.7


 - ./pre-inst-env guix --version in git.


 I am not able to get that far...

 Thanks anyway.

 Adam Pribyl



 ERROR: no code for module (json)
 Backtrace:
 In ice-9/boot-9.scm:
  157: 12 [catch #t #catch-closure c655a0 ...]
 In unknown file:
?: 11 [apply-smob/1 #catch-closure c655a0]
 In ice-9/boot-9.scm:
   63: 10 [call-with-prompt prompt0 ...]
 In ice-9/eval.scm:
  432: 9 [eval # #]
 In ice-9/boot-9.scm:
 2401: 8 [save-module-excursion #procedure c82880 at
 ice-9/boot-9.scm:4045:3
 ()]
 4050: 7 [#procedure c82880 at ice-9/boot-9.scm:4045:3 ()]
 1724: 6 [%start-stack load-stack #procedure c95820 at
 ice-9/boot-9.scm:4041:10 ()]
 1729: 5 [#procedure c98c60 ()]
 In unknown file:
?: 4 [primitive-load
 /gnu/store/blq0man8glfr3rsb4mya4sgn292z3gr3-guix-latest-guile-builder]
 In ice-9/eval.scm:
  387: 3 [eval # ()]
 In

 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:
  121: 2 [build-guix
 /gnu/store/1w0y78nvmivv6a688ljcdnl35dy8m8i7-guix-latest ...]
   75: 1 [p-for-each #procedure 1034300 at

 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14
 (file) ...]
 In unknown file:
?: 0 [scm-error misc-error #f ...]

 ERROR: In procedure scm-error:
 ERROR: process failed #procedure 1034300 at

 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14
 (file) 256
 builder for `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv'
 failed with exit code 1
 killing process 13118
 guix pull: error: build failed: build of
 `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' failed


 Regards

 Adam Pribyl

Re: guix pull fails for me

[Amirouche Boubekki]

Hi,

guile-json is missing for some reason. Maybe you can install it
manually or from a guix git checkout. I'm curious can you provide the
guix --version:

- as a user
- as root
- ./pre-inst-env guix --version in git.


 ERROR: no code for module (json)
 Backtrace:
 In ice-9/boot-9.scm:
  157: 12 [catch #t #catch-closure c655a0 ...]
 In unknown file:
?: 11 [apply-smob/1 #catch-closure c655a0]
 In ice-9/boot-9.scm:
   63: 10 [call-with-prompt prompt0 ...]
 In ice-9/eval.scm:
  432: 9 [eval # #]
 In ice-9/boot-9.scm:
 2401: 8 [save-module-excursion #procedure c82880 at ice-9/boot-9.scm:4045:3
 ()]
 4050: 7 [#procedure c82880 at ice-9/boot-9.scm:4045:3 ()]
 1724: 6 [%start-stack load-stack #procedure c95820 at
 ice-9/boot-9.scm:4041:10 ()]
 1729: 5 [#procedure c98c60 ()]
 In unknown file:
?: 4 [primitive-load
 /gnu/store/blq0man8glfr3rsb4mya4sgn292z3gr3-guix-latest-guile-builder]
 In ice-9/eval.scm:
  387: 3 [eval # ()]
 In
 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:
  121: 2 [build-guix
 /gnu/store/1w0y78nvmivv6a688ljcdnl35dy8m8i7-guix-latest ...]
   75: 1 [p-for-each #procedure 1034300 at
 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14
 (file) ...]
 In unknown file:
?: 0 [scm-error misc-error #f ...]

 ERROR: In procedure scm-error:
 ERROR: process failed #procedure 1034300 at
 /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14
 (file) 256
 builder for `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv'
 failed with exit code 1
 killing process 13118
 guix pull: error: build failed: build of
 `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' failed


 Regards

 Adam Pribyl

Re: Installing guix

[Amirouche Boubekki]

2014-12-15 23:54 GMT+01:00 Ludovic Courtès l...@gnu.org:
 Amirouche Boubekki amirouche.boube...@gmail.com skribis:

 My machine is kind of recent, and previously with other distro I had
 all sort of trouble with uefi. Not this time, I don't know what is the
 configuration of guix, I've just setup my bios to avoid uefi.

 Yeah, Guix doesn’t support UEFI.  (I’m not sure exactly what it takes,
 but we should discuss that in a bug.)

 The 0.8 release has not wpa_supplicant and I didn't want to move the
 machine around, so I modified the system/install.scm in guix-0.8 and
 ran:

# guix system disk-image gnu/system/install.scm

 I dropped --image-size=800MiB otherwise the image failed build.

# dd if=/gnu/store/.image-disk of=/dev/sdb

 When I boot the disk, I find out guix is version 0.7.

 Maybe the ‘guix’ command above is 0.7, no?

I don't remember. In the 0.8 release there is:

- guix is guix-devel 0.7
- guix-0.7

And no guix 0.8

 I was under the impression that this wasn't compatible with my system
 config.scm. So I went back to guix-0.8 and changed
 package-mangement.scm recipe so that guix is guix 0.8 instead of
 0.7. There is also guix-devel but... This was not very user friendly
 but hey, guix is alpha.

 When the disk boots I connect to the wifi with the following commands

# wpa_passphrase ssid passphrase  wpa.conf
# wpa_supplicant -B -winterface name -cwpa.conf

 Then:

   # dhclient interface name

 OK.

 To create partitions I used the graphical cfdisk command, then format them 
 with:

   # mkfs.ext4 -L name device

 I used two partition one for root another for home. I mounted only the
 root partition (previous attempts I learned that it's not required to
 mount home, but you need to create the home directory with the correct
 permissions...):

   # mount -L root /mnt/

 I copy pasted the config.scm to /mnt/etc/ that I had cooked started
 cow-store with

   # deco start cow-store /mnt

 I went swimming and when back GNU Guix was on my system :)

 Nice.  Guix is good for your health!  :-)


 I did quite a bit of experiments to get nouveau drivers (libre nvidia
 drivers) working. I remember trying them previously and they are (can
 be) quiet good. I just tested http://minetest.net it reports that
 nouveau drivers are kicking.

 Good.

 With slim-service, Xorg will look for a .xsession in $HOME and not
 .xinitrc!

 Could you email bug-g...@gnu.org for that?

 I attached my .xsession file, but do not use it if you don't have all
 the command available, otherwise xorg will loop-restart indefinitly...

 I think .xsession should end with “exec dwm”, no “dwm”.

For the last command it's not required.


 Also, see http://bugs.gnu.org/19119.

Yes, I needed to source my .bashrc to be able to execute commands that
were installed as a user.


 It's not the case anymore but at some point I had several version of
 guix 0.7, 0.8-devel, and 0.9. Now I have only 0.9.

 - Also su and sudo doesn't source /etc/profile.

 This should be fixed with the recent changes in that area.

 - xterm was aweful, I installed st cf. suckless.scm I use ``guix -L
 `pwd` -e (let ((x (use-modules (suckless st)`` command to
 install st. I'm wondering if there is better way to do.

 “guix -L $PWD st” should work, provided $PWD/suckless.scm exists.

 BTW, you’re welcome to submit these new packages!

Yes, I'll do (after some guile hacking ;)

 - I find my nouveau hack quiet ugly, but I'm not sure how the
 situation can be improved (cf. config.scm)

 I thought xf86-video-nv (already in xorg.scm) is Nouveau, but apparently
 it’s not?

nv is the old the driver without 3D acceleration: http://www.x.org/wiki/nv/


 You’re more knowledgeable than me in this area as you can see ;-), so
 please do submit the packages and tricks that appear in your config.scm
 so we can make things work out-of-the-box for future Nouveau users.

 - During my test, I failed to get XORG_DRI_DRIVER_PATH working (cf
 (gnu services xorg)) , nix-os is the only distro to use it.
 LIBGL_DRIVERS_PATH doesn't work either.

 Could you be more precise?

 - I'm not sure anymore about .guix-profile link, whether it gets
 created or not at some point.

 ~/.guix-profile is created the first time ‘guix package’ is used.

 - I don't know if it's on purpose but $HOME/.guix-profile/sbin is
 missing from $PATH

 Right.  I think it’s fine this way.  WDYT?

 - I need a hat.

 Sorry, can’t help with that.

 At some point, I'm not sure why anymore, I had to chroot into the
 installed guix from the installation disk, here is what I did:

 Well, I’m not sure why either.  :-)

 I still need a service for wpa-supplicant at some point, but my
 current configuration is good.

 So far, so good.

 Great.  Well, thanks for the detailed feedback!  I think you owe us a
 couple of bug reports and a bunch of new packages now.  :-)

I will come back to guix avant-garde ;) after some guile hacking for sure.

Installing guix

[Amirouche Boubekki]

Hello,


I installed GNU Guix distribution on my other machine to use it more
often. This will be a bit a long explanation.

My machine is kind of recent, and previously with other distro I had
all sort of trouble with uefi. Not this time, I don't know what is the
configuration of guix, I've just setup my bios to avoid uefi.

Here is what I've done:

The 0.8 release has not wpa_supplicant and I didn't want to move the
machine around, so I modified the system/install.scm in guix-0.8 and
ran:

   # guix system disk-image gnu/system/install.scm

I dropped --image-size=800MiB otherwise the image failed build.

   # dd if=/gnu/store/.image-disk of=/dev/sdb

When I boot the disk, I find out guix is version 0.7. I was under the
impression that this wasn't compatible with my system config.scm. So I
went back to guix-0.8 and changed package-mangement.scm recipe so that
guix is guix 0.8 instead of 0.7. There is also guix-devel but... This
was not very user friendly but hey, guix is alpha.

When the disk boots I connect to the wifi with the following commands

   # wpa_passphrase ssid passphrase  wpa.conf
   # wpa_supplicant -B -winterface name -cwpa.conf

Then:

  # dhclient interface name

To create partitions I used the graphical cfdisk command, then format them with:

  # mkfs.ext4 -L name device

I used two partition one for root another for home. I mounted only the
root partition (previous attempts I learned that it's not required to
mount home, but you need to create the home directory with the correct
permissions...):

  # mount -L root /mnt/

I copy pasted the config.scm to /mnt/etc/ that I had cooked started
cow-store with

  # deco start cow-store /mnt

I went swimming and when back GNU Guix was on my system :)

I did quite a bit of experiments to get nouveau drivers (libre nvidia
drivers) working. I remember trying them previously and they are (can
be) quiet good. I just tested http://minetest.net it reports that
nouveau drivers are kicking.

With slim-service, Xorg will look for a .xsession in $HOME and not
.xinitrc! I attached my .xsession file, but do not use it if you don't
have all the command available, otherwise xorg will loop-restart
indefinitly...


It's not the case anymore but at some point I had several version of
guix 0.7, 0.8-devel, and 0.9. Now I have only 0.9.

- Also su and sudo doesn't source /etc/profile.
- xterm was aweful, I installed st cf. suckless.scm I use ``guix -L
`pwd` -e (let ((x (use-modules (suckless st)`` command to
install st. I'm wondering if there is better way to do.

- I find my nouveau hack quiet ugly, but I'm not sure how the
situation can be improved (cf. config.scm)
- During my test, I failed to get XORG_DRI_DRIVER_PATH working (cf
(gnu services xorg)) , nix-os is the only distro to use it.
LIBGL_DRIVERS_PATH doesn't work either.
- I'm not sure anymore about .guix-profile link, whether it gets
created or not at some point.
- I don't know if it's on purpose but $HOME/.guix-profile/sbin is
missing from $PATH
- I need a hat.

At some point, I'm not sure why anymore, I had to chroot into the
installed guix from the installation disk, here is what I did:

# sh ./connect-to-wifi.sh
# mount --bind /dev /mnt/dev
# mount -t proc /proc /mnt/proc
# cp /etc/resolv.conf /mnt/etc/
# chroot /mnt /bin/sh
# source /etc/profile
# guix-builder --build-users-group=guixbuild 
# guix foo bar baz


I still need a service for wpa-supplicant at some point, but my
current configuration is good.

So far, so good.


Thanks guix people, all the best!


config.scm
Description: Binary data


.xsession
Description: Binary data


suckless.scm
Description: Binary data

Re: Gluglug X60 Guix howto

[Amirouche Boubekki]

2014-11-25 13:42 GMT+01:00 Ludovic Courtès l...@gnu.org:

 Alex Sassmannshausen alex.sassmannshau...@gmail.com skribis:

  I received a request for instructions on how to get Guix running as
  standalone on the Gluglug X60 — my work is ongoing (I haven't
  reconfigured the Grub BIOS, nor have I got wireless working yet), but
  a first draft may help other owners.

 Nice job!

 Do you know what WiFi chipset is included?  If it’s an Atheros thing,
 for which we have the free firmware, it shouldn’t be too hard.


I also have a gluglug x60. I'm doing the installation right now.

The wireless card is showing up in iwconfig and lspci (driver ath9k).
Still, I can't connect using it because wpa_supplicant is missing. So it
will wait that the system is finished installing.

Re: guix-shell?

[Amirouche Boubekki]

2014-08-26 22:31 GMT+02:00 David Thompson dthomps...@worcester.edu:

 Andreas Enge andr...@enge.fr writes:

  Hello,
 
  could you maybe provide a specification of what guix-shell is supposed
 to do?
  Not knowing nix-shell, I admit to being somewhat lost as to which problem
  you are trying to solve.
 
  Andreas
 

 I think the Nix manual explains it best:
 http://nixos.org/nix/manual/#sec-nix-shell



 Basically, it creates a shell environment in which some packages
 specified in an input file are available.




 A great use-case for this is setting up development environments for
 software projects.


The core idea behind this is to be able to have an easy way to develop
applications
without requiring a heavy VM. This is kind of a container but at the shell
level. It's more
lightweight than VM, or LXC or docker but doesn't help with security, it's
only for development.

You install libraries and else in this shell environment and they have a
higher priority
than user and root libraries, so they are used by the application your are
developing.

In Python at least, it is called virtualenv. It has been merged into python
dev branch. The thing
is that you can only reliably install pure python packages in the
virtualenv. Anything that requires
non python dependencies can be of trouble. For instance, I never used
virtualenv to use
another version of mysql... an example of non-pure python package that
gives trouble is ipython.
If I recall correctly cython based dependencies are also troublesome.

That's said, it's very helpful. Most of the time you have no constraint or
bugs because of binary stuff.
You would have to be - multitasking a lot - to need to install two versions
of PostgreSQL in parallel.

One of the cons DevOps argue against the use of virtualenv is that it
bypass the rigourous
process of Debian stable  security *and* you have to manage two kinds of
dependencies which makes
devops work more difficult.

For developpers and DevOps another cons is that you must be very rigorous
with dependencies. Sometime
the dev will install a library globally, the shell env will require it and
find it in the global namespace and it will
use it. When time arrive to reproduce the dev/prod environement you
discover that a library is missing... with no
information about the version to use.


 A 'shell.nix' file would live in the root of a project's source tree.  A
 new developer would clone the repository, run 'nix-shell' and have an
 environment that has everything needed to build and run the software.


Another solution might to use docker containers [nix docker
http://zef.me/6049/nix-docker#introducing-nix-docker][recursive docker
http://blog.docker.com/2013/09/docker-can-now-run-within-docker/]. I'm
not sure what this solution will bring over nix-shell except that since
it's a container, no global library will be used by the application.
Otherwise said, you will need to
track dependeciens from the very beginning.

Docker is all the rage. VMware added support to it recently. This is seems
to be the preferred method to do all things Cloud cf. EC2 and Google
appengines clones (like heroku) for more data.



 Does that help?

 --
 David Thompson
 Web Developer - Free Software Foundation - http://fsf.org
 GPG Key: 0FF1D807
 Support the FSF: https://fsf.org/donate