Re: a Trytond service

[Catonano]

2017-09-09 12:39 GMT+02:00 Christopher Baines :

> On Fri, 8 Sep 2017 21:42:24 +0200
> Catonano  wrote:
>
> > I'm trying to write a service for Trytond
> >
> > There are tons of things i don't know/understand
> >
> > But this is the first one:
> >
> > The Tryton manual states that I need to indicate a "data directory"
> > to the daemon and that such directory should be:
> >
> > "The directory where Tryton stores files and so the user running
> > trytond must have write access on this directory.
> > Default: The db folder under the user home directory running trytond."
> >
> > See here (notice that this is in the "database" section of te
> > configuration)
> >
> > http://doc.tryton.org/4.4/trytond/doc/topics/configuration.html#database
> >
> > My idea was that Tryton would have used a postgres managed by the
> > omonimous service, so my user and my home folder shouldn't be
> > concerned, here
> >
> > I don't know enough of the Unix assumptions here
>
> Some users for services use some /var/run directory as there home
> directory, which works if the data doesn't need to survive reboots.
> Otherwise, the data should go in to /var/lib.
>
> The Tryton documentation isn't very clear to me either, Using PostgreSQL
> sounds like a good place to start, and ideally it would be flexible
> enough that any of the options are available when using the Guix
> service.
>

Thank you Christopher

Hartmut, good to know that there is a fellow trytonista here ;-)

I asked on their mailing list and the answer I got is that the data older
could be used for attachments, for example.

So I think we are in the situation where the folder has to be writable to
trytond AND its contents should be resilient to reboots.

That is clarified, so far

Their mailing list is hosted on google groups so I can only point you
there, for reference
https://groups.google.com/forum/#!topic/tryton/KEeGDBNjXBs

postgresql again

[Catonano]

I have a postgresql service in my config.scm file

but I don't use it

Today I needed it to figure out how postgres works (because of my attempt
to create a service for Tryton) and I discovered that it's stopped

~$ sudo herd status
...
Stopped:
 - postgres
 - user-homes

and if I try to start it, it fails
~$ sudo herd start postgres
Service postgres is currently disabled.
herd: failed to start service postgres

I can "enable" and then start it but that doeesn't resist a reboot

This was discussed in the past and it had to do with postgres being updated
BUT it was reported back then that there were messages in var/log/messages
about how the data folder had been initializzed with a previous version of
postgres and that was incompatible with the new one

In my case nothing shhows up with

sudo cat /var/log/mesages | grep postgresql

and

~$ sudo cat /var/lib/postgresql/data/PG_VERSION
9.6

and

$ pg_config
...
VERSION = PostgreSQL 9.6.5

I reconfigured and updated my installation in August, before coming to the
GHM

could anyone here verify if they can run postgresql with a reasonably
recent version of GuixSD ?

Thanks in advance

Re: postgresql again

[Jan Nieuwenhuizen]

Catonano writes:

> could anyone here verify if they can run postgresql with a reasonably recent 
> version of GuixSD ?

I installed GuixSD two days ago, guix pull/master, with postgresql.  Using only

   (postgresql-service)

Greetings,
janneke

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

Mes 0.10 released

[Jan Nieuwenhuizen]

I am pleased to announce the release of Mes 0.10, representing 82
commits over 6 weeks.  Mescc now compiles a bootstrappable-modified
TinyCC into a mes-tcc that in turn can successfully compile a trivial
C program.

* About

Mes[0] aims to create full source bootstrapping for GuixSD[1] as
part of the bootstrappable builds[2] project.

It currently consists of a mutual self-hosting [close to Guile-]
Scheme interpreter prototype in C and a Nyacc-based C compiler in
[Guile] Scheme.  This C prototype will be rewritten in stage0[3]
M1 assembly (or possibly stage2 slow-LISP, or ...).

The Scheme interpreter prototype (mes.c) has a Garbage Collector,
a library of loadable Scheme modules-- notably Dominique Boucher's
LALR[4], Pre-R6RS portable syntax-case[5] with R7RS ellipsis, Matt
Wette's Nyacc[6], Guile's PEG[7] --and test suite just barely
enough to support a simple REPL (repl.mes) and simple C-compiler
(mescc.mes).

The simple C compiler can compile a modified TinyCC[8] that is
starting to work!  A gcc-compiled tcc is known[9] to compile GCC.

Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10]
-- John McCarthy page 13, GNU Guix's source/binary packaging
transparency and Jeremiah Orians's stage0 ~300 byte self-hosting
hex assembler.

* Download

git clone https://gitlab.com/janneke/mes

wget https://gitlab.com/janneke/mes/repository/archive.tar.gz?ref=v0.10 -O 
mes-0.10.tar.gz

Mes runs from the source tree and can also be built, packaged and
installed in Guix[SD] by the usual

guix package -f guix.scm

* Changes in 0.10 since 0.9
 ** Core
 *** 2 new functions
 logand, lognot.
 ** Mescc
 *** Mes now includes M1 sources for full source bootstrapping up to tcc.
 *** Mescc now depends on Nyacc 0.81.0.
 *** Mescc now compiles a mes-tcc that compiles a trivial C to a running a.out.
 *** Mescc now supports several (as used by tinycc) struct by value assignments.
 *** Mescc now has _start in a separate crt1.c.
 *** Mescc now supports initializer arithmetic.
 *** Mescc now supports arrays of struct of arbitrary size.
 *** Mescc now supports pointer arithmetic.
 *** Mescc now defines __i386__, __linux__.
 *** Mescc now supports --*p, ++*p.
 *** Mescc now supports int foo[bar] = {baz,...}.
 *** Mescc now supports \x00 in strings in M1.
 *** Mescc now supports complex enum expressions.  Thanks, rain1!
 *** Mescc now supports short.
 *** Mescc now supports foo.bar = foo.baz = bla.
 *** Mescc now supports foo = bar < baz and comparison permutations.
 *** Mescc now supports (anonymous) structs in unions.
 *** Mescc now writes M1 strings if possible.
  2 improved mlibc functions
 malloc, realloc.
  13 new mlibc functions
 fclose, fgetc, fprintf, fwrite, memcpy, memmove, memset, snprintf, strcat,
 strchr, strrchr, strtoull, vnsprintf.
  15 new tinycc-support tests
 76-pointer-arithmetic.c, 77-pointer-assign.c, 78-union-struct.c,
 79-int-array.c, 7a-struct-char-array.c, 7b-struct-int-array.c,
 7c-dynarray.c, 7d-cast-char.c, 7e-struct-array-access.c,
 7f-struct-pointer-arithmetic.c, 7g-struct-byte-word-field.c,
 7h-struct-assign.c, 7i-struct-struct.c, 7j-strtoull.c,
 7k-for-each-elem.c.
 ** Noteworthy bug fixes
 *** Mescc has many fixes for foo.bar[baz], foo[bar].baz with ./-> permutations.
 *** Many bugs and limitations in mescc have been fixed and removed.

Greetings,
janneke

[0] https://gitlab.com/janneke/mes
[1] https://www.gnu.org/software/guix
[2] http://bootstrappable.org
[3] https://github.com/oriansj/stage0
[4] https://github.com/schemeway/lalr-scm
[5] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html
[6] https://www.nongnu.org/nyacc/
[7] https://www.gnu.org/software/guile/docs/master/guile.html/PEG-Parsing.html
[8] https://gitlab.com/janneke/tinycc
[9] https://lists.gnu.org/archive/html/tinycc-devel/2017-05/msg00103.html
[10] 
http://www.softwarepreservation.org/projects/LISP/book/LISP%25201.5%2520Programmers%2520Manual.pdf

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

Re: Please put the system-configuration into the image

[Ludovic Courtès]

Hi,

Hartmut Goebel  skribis:

> If somebody is downloading the ISO-image and installing GuixSD on some
> machine – stand-alone, no other GuixSD systems around: He/she would
> store the system-config somewhere on the machine, change it and
> "reconfigure" and hack around. (At least this is what I would do.) So
> why there is no starting-point for system-config in the image? Why would
> the user need to download it from some (no quite obvious) internet-address?

As a user, you do *not* want to use the installation OS¹ as a template
for your own system: it’s way too specific to a live installation image
and more complicated than a “regular” system.

Instead, you’ll want to use one of the three templates that are
provided.  They’re in the manual² (which is on tty2 when you’re
installing), and also in /etc/configuration during the installation.  No
need to download them from a non-obvious internet address.

Am I missing something?

Thanks,
Lud’.

¹ https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm#n296
² 
https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html

Re: Question about multiple licenses

[Ludovic Courtès]

Dave Love  skribis:

> Ludovic Courtès  writes:
>
>> Dave Love  skribis:
>>
>>> Alex Vong  writes:
>>>
 Based on the above general argument, I think we should list all the
 licenses instead of just GPLv2+ since it would be inaccurate to say that
 the whole program is under just GPLv2+.
>>>
>>> Indeed.  Not only do you need to list the licences (according to all
>>> "legal advice" I've seen for distributions), but normally also
>>> distribute the relevant licence texts, even for permissive licences if
>>> they require that (e.g. BSD).  I raised this recently, as it's not
>>> generally being done, so some Guix binary packages appear to be
>>> copyright-infringing.
>>
>> There’s no such thing as a “Guix binary package” though, which makes it
>> different from traditional distros.
>>
>> In Guix a package is a Scheme object that refers to the source and build
>> method of upstream software.
>
> Sure, but if you use guix pack and distribute the result, it seems
> clearly a copyright infringement, because even BSD requires
>
>   2. Redistributions in binary form must reproduce the above copyright
>  notice, this list of conditions and the following disclaimer in the
>  documentation and/or other materials provided with the distribution.

[...]

> Well, from what I know about copyright, that isn't the licence of glibc,
> which is the sum of all the licences involved, and you'd have to know
> how to find them if you didn't just unpack the tarball.  With pack
> output in a lot of cases you don't have the information.

Right, ‘guix pack’ makes things more complicated—although I would argue
that, contrary to Dockerfiles and the like (which nobody seems to
complain about), Guix makes it easier to do provenance tracking since
there’s an unambiguous source → binary mapping.

How do Debian and Fedora determine the relevant files to copy?  We could
investigate ways to do that, but it won’t scale unless we have a mostly
automated way to do it.

(It won’t scale to the size of Stackage, CPAN, Pypi, etc. either…)

Thoughts?

Ludo’.

Re: missing licence files and incomplete licence lists

[Ludovic Courtès]

Hi,

Dave Love  skribis:

> Ludovic Courtès  writes:

[...]

>> Guix is much less comprehensive than Debian.  The ‘license’ field is
>> meant to list the license that applies to the combined work.
>>
>> For glibc, it’s LGPLv2+; glibc includes BSD-licensed work, but that
>> doesn’t matter from this perspective.
>
> Is that based on FSF legal advice?

No.

>>> Should bugs just be filed against each case, or can things be checked
>>> systematically?
>>
>> Given the meaning of ‘license’ above, if you find errors, you’re of
>> course welcome to report them.  But keep in mind that ‘license’ is
>> looser than the info you’d fine in Debian ‘copyright’ files.
>
> Is it meant to be equivalent of the RPM License field in Fedora/SuSE?
> If not, exactly what does it mean?

I don’t know about Fedora/SuSE.

> Sorry if this seems too picky, but it's meant to be friendly advice from
> long observation!  A GNU project should follow FSF legal advice, but I'd
> expect Debian and Fedora to be fairly good models in the areas they
> clearly agree.

Understood.

If you look at , you’ll see
“License:LGPL”, which is already more vague than what we have (following
FSF legal advice?).  If you look at GitHub repos (yack!), Pypi, CPAN,
Hackage, npm (doh!), well, that’s yet another level.

I’m interested in concrete proposals to improve the situation that take
into account the bigger picture as well as scalability considerations.

Thoughts?

Ludo’.

Re: postgresql again

[Catonano]

2017-09-10 20:11 GMT+02:00 Jan Nieuwenhuizen :

> Catonano writes:
>
> > could anyone here verify if they can run postgresql with a reasonably
> recent version of GuixSD ?
>
> I installed GuixSD two days ago, guix pull/master, with postgresql.  Using
> only
>
>(postgresql-service)
>
> Greetings,
> janneke
>
>
sigh. Thank you Janneke

Would anyone want to give me any diections about how to troubleshoot this ?

Re: Removing the need for ./configure --localstatedir=/var ?

[Ludovic Courtès]

Christopher Allan Webber  skribis:

> Every now and then I rebuild Guix and hit the problem where I run
> ./configure and then I am reminded that I need to instead do:
>
>   ./configure --localstatedir=/var
>
> IIRC this is because of GNU standards about default paths and pretty
> much no other reason that we don't default to /var.  But I think Guix is
> a special case.
>
> Should we ask maybe for an exception?

No need to ask.  :-)

> There's no reason for users to bump into this.  It's annoying even for
> me, and at least I know (or think I do) why.

I think it would be surprising to users who install from source if
localstatedir is not under $prefix by default (someone who wants to
install to /opt/foo would be surprised to find out that some files go to
/var instead of /opt/foo/var.)

There’s also the question of “make dist”, which should still DTRT.

We could have $prefix default to /… but that’s not quite what one might
expect either.

I think the current situation is a good middle ground, even though I can
also sympathize with your frustration.

Thoughts?

It’s weird how a simple question like this can be seemingly this complex
to address.  :-)

Ludo’.

Re: [WIP][PATCH] download: Don't report the progress too fast

[Ludovic Courtès]

Hi!

iyzs...@member.fsf.org (宋文武) skribis:

> Hi, sorry for my late response.

No problem, it was worth waiting.  ;-)

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

[...]

>> (Also, longer-term, we’d want to do that other way around, which is to
>> update the report every N milliseconds, as opposed to just printing
>> something when a chunk has been transferred.)
>>
>
> Yes, so the elapsed time won't be freezed, and here is my try using
> thread:

[...]

> From 4036ce5de7bf3b98327010bbfbf75029f3d0b572 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
> Date: Fri, 8 Sep 2017 22:49:03 +0800
> Subject: [PATCH] download: Report the progress asynchronously in another
>  thread.
>
> * guix/utils.scm (): New record type.
> (call-with-progress-reporter): New procedure.
> * guix/build/download.scm (dump-port*, progress-reporter/file): New
> procedures.
> (ftp-fetch, http-fetch): Use them.
> (progress-proc): Remove procedure.
> * guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of
> .
> (process-substitution): Adjust accordingly.

Impressive!

I have a couple of concerns though:

  1. Using a thread “just” for progress reporting seems quite
 heavyweight, though maybe that’s OK.

  2. As per POSIX, we cannot mix ‘fork’ and threads, so programs that
 use ‘primitive-fork’ should not also use threads.  One such program
 is (guix scripts substitute), via ‘decompressed-port’.  Guile
 rightfully emits a warning when a multithreaded program calls
 ‘primitive-fork’:

   https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c#n1224

   3. “Atomic boxes” are a Guile 2.2 feature, but we still support 2.0.

To address these, I would use ‘abort-to-prompt’ & co., possibly with
“suspendable ports”, but this is a 2.2 feature.  (It may be that we
should use Fibers directly.)

Tricky!  Not sure what to do here.

Thoughts?

Ludo’.

Re: My experiences with GuixSD

[Ludovic Courtès]

Hello!

"Thompson, David"  skribis:

> On Fri, Sep 8, 2017 at 6:58 PM, Jonathan Brielmaier
>  wrote:

[...]

>> 1. I had a hard time during installation on the "live-system" to figure
>> out how to do the GRUB setup the right way. The error was quite simple:
>> I only have to write "target /dev/sda" instead of "target /dev/sda1".
>>
>> => Beside I'm not very experienced with setting up GRUB, something like
>> "guix lint" for the system config would be nice :)
>
> I agree. Something that would detect that you are trying to install
> GRUB to a partition instead of the disk itself would be nice.

Right, I agree.

At the GHM there were also discussions about detecting other issues at
‘init’ time, such as the use of wrong UUIDs or file system labels.  We
actually already have everything we need to check whether there really
is a file system with the given UUID/label, so it wouldn’t be hard to
add.  Yet, it would make a big difference since that’s apparently a
common mistake.

> Thanks for the feedback.  Sorry that GuixSD doesn't work for you.  I
> would say that the GPU and IceCat things are "won't fix" (these aren't
> GuixSD problems, nor really problems at all, they are facts of life
> for running a system that fully respects your freedom), and the GRUB
> and font thing could definitely be improved with some effort.

Agreed.

I wonder what happened with the font issue.  Jonathan, if you could
reproduce the issue in ‘guix system vm’ (you can do that on your foreign
distro), that would allow us to investigate.

Thanks for your feedback!

Ludo’.

Re: My experiences with GuixSD

[Mark H Weaver]

Jonathan Brielmaier  writes:

> 4. Icecat... I had to restart it like every five minutes because it
> doesn't show websites. Yes, I disabled all those add-ons (LibreJS etc.).
> It was not usable for me, really not.

Could you elaborate more precisely on how IceCat misbehaved?  I've been
using IceCat as my primary web browser for a couple of years now, and
have found it to work very well.  I've not heard other GuixSD users
reporting problems like this.

> And without all those FOSS add-ons on addons.mozilla.org
> Icecat/Firefox is bad.

It is true that addons.mozilla.org is not the default site that is
visited from within the "Get Add-ons" portion of the built-in
"about:addons" page.  However, as far as I know, you should be able to
manually visit addons.mozilla.org and install the add-ons there.  Did
you try that?

> => Could we not just have a Firefox ESR version without DRM, Pocket and
> the other closed-source stuff, but _with_ the ability to install add-ons
> and stability?

This is exactly what IceCat is meant to be, and what I've found it to
be.  I'm not sure why it worked so poorly for you.

> After lots of hours (10-20h) investing in the setup of GuixSD I decided
> to install Ubuntu as the system was not "usable" for me :(

Okay.  I'm sorry that the system worked so poorly for you, and I very
much appreciate you taking the time to tell us of your experience.

Regards,
  Mark

Re: Thunderbird

[Arun Isaac]

> I was wondering if anyone would work on Astroid mail
> https://astroidmail.github.io/
>
> It seems simpler to package than Thunderbird and it could be extremely
> useful in the short/medium term

Astroid requires external programs like mpop or offlineimap to fetch
mail. So it cannot quite replace Thunderbird for the casual mail
user. Perhaps, claws-mail or blasa are better alternatives. Both
claws-mail and balsa are already packaged for Guix.