Re: [PATCH 07/11] gnu: Add python-ipaddress.

[Hartmut Goebel]

Am 11.09.2017 um 20:22 schrieb Cyril Roelandt:
> +(define-public python-ipaddress
> +  (package
> +(name "python-ipaddress")

This package already exists, only the Python2-variant is missing.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 10/11] gnu: Add python-pkginfo.

[Hartmut Goebel]

Am 11.09.2017 um 20:22 schrieb Cyril Roelandt:
> +(description
> +  "API to query the distutils metadata written in the PKG-INFO file 
> inside a
> +source distriubtion (an sdist) or a binary distribution (e.g., created by
> +running bdist_egg).  It can also query the EGG-INFO directory of an installed
> +distribution, and the *.egg-info stored in a “development checkout” (e.g,
> +created by running setup.py develop).")

Syntax error: Quotes inside quotes need to be escaped.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 09/11] gnu: Add python-tqdm.

[Hartmut Goebel]

Am 11.09.2017 um 20:22 schrieb Cyril Roelandt:
> +(synopsis "Fast, Extensible Progress Meter")
I suggest: "Fast and extensible progress bar for the console"
> +(description "Make for loops show a progress bar.")
This is a bit terse (and it's not only "for" loops, AFAICT). Maybe
something like

Make loops show a progress bar on the console by just wrapping any
iterable with @code{|tqdm(iterable)|}. Offers many options to define
design and layout.

> +(license license:asl2.0)))

The LICENCE file says: MPL and MIT. Please check again.

-- 

Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Thoughts and questions from a newcomer

[Julien Lepiller]

Le 12 septembre 2017 01:25:54 GMT+02:00, Andrew Erlanger 
 a écrit :
>Hello, Guix users,
>
>After a bit of love, I've got most of my personal computing environment
>running in GuixSD. As I get more comfortable with the system, I hope to
>naturally become a developer.
>
>At this point, I have a few thoughts and questions, which I'm looking
>for some feedback on, especially where I'm misguided.
>
>It seems that the main problem Guix is trying to address is about state
>and side-effects. In modern computers, a program running over here
>can affect the execution of a completely unrelated program running over
>there because of side-effects. The result is a large amount of
>unnecessary complexity. Effectively, the programs have many, many
>inputs, and with feedback loops between components, the system can
>exhibit chaotic behaivor.
>
>If I'm not mistaken, Guix attempts to provide a way of building
>programs so that all inputs to the build process are known exactly.
>Assuming that the build is a deterministic process (which I
>hope it is!), this ensures that the resuling executables are not
>tainted by side-effects.
>
>The main thing that has been confusing me about this process is in
>dealing with configuration files. Clearly the state of a program such
>as, for example, wpa_supplicant, depends on the configuration file used
>to start the process. So, if we are trying to effectively declare the
>state-machine of wpa_supplicant using Guile, shouldn't the config file
>be part of the Guile definition of wpa_supplicant?
>
>My main draw to Guix was my frustration with configuring Gentoo and
>other distros. After I spend a day exactly configuring a system, I want
>the state which I set up to be _exactly_ reproducible anytime I want.
>But clearly I don't need all the information of the entire disk image
>to reproduce that exact state; I just need a few configuration files
>worth of information.
>
>If I can't include the contents of configuration files as an input to a
>package build, then I can't really capture the state-machine of the
>package with a single declaration. I have to then use something like
>stow and git to manage my config, which is not really solving the
>problem.
>
>On the other hand, it seems that Guix might be more about mitigating
>side-effects rather than declaring state. So, which is it?
>
>Thanks for reading,
>
>Andrew

Hi Andrew !

We want to be able to distribute packages to people, so we can't make a package 
depend on some configuration file. As you noted, it would be unreproducible.

On the other hand, when using guixSD, you can use system services to declare 
your configuration. Our wpa-supplicant-service cannot be run alone, but if we 
had a better service, you could declare something like this in guile:

(service wpa-supplicant-service-type
  (wpa-supplicant-configuration
(ssid "my-wifi")
   ...))

This would create a configuration file in the store and create a new herd 
service for wpa_supplicant that would use this file. You may be interested in 
the system configuration section of the manual if you want to learn more.

So, you have a reproducible package and a reproducible config, therefore a 
reproducible behaviour.

With guixSD you have only one file to edit in order to configure your system 
entirely. At least that's part of what we would like to achieve. One of your 
first contribution could be this wpa-supplicant-service-configuration :).

Re: openjpeg-2 security updates vs stale openjpeg-1

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> I've just rebuilt my x86_64 GuixSD system to use 'openjpeg' from git
> (since I see many more fixes there that look security-relevant), and to
> use this fresh openjpeg in both 'poppler' and 'tracker'.  Unfortunately,
> the 'poppler' change required a massive rebuild, but with these updates
> my system seems to work just fine.
>
> I've attached my preliminary patches.
>
>Mark
>
> From abd9df8c4623cc44ef77be69977e2635c0fdd3bf Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Mon, 4 Sep 2017 23:48:55 -0400
> Subject: [PATCH 1/3] gnu: openjpeg: Update to 2.2.0-1.3a382d312.
>
> * gnu/packages/image.scm (openjpeg): Switch to using a git checkout, and
> update to 2.2.0-1.3a382d312.  Remove patches.
> * gnu/packages/patches/openjpeg-CVE-2017-12982.patch,
> gnu/packages/patches/openjpeg-CVE-2017-14040.patch,
> gnu/packages/patches/openjpeg-CVE-2017-14041.patch,
> gnu/packages/patches/openjpeg-CVE-2017-14151.patch,
> gnu/packages/patches/openjpeg-CVE-2017-14152.patch: Delete files.
> * gnu/local.mk (dist_patch_DATA): Remove them.

Should we graft this openjpeg variant?  “openjpeg@1” has 1,810
dependents.

Thanks for the heads-up, and apologies for the delay!

Ludo’.

Re: guix pull via cgit odd behavior or [guile-git] limitations?

[Ludovic Courtès]

Jan Nieuwenhuizen  skribis:

> ng0 writes:
>
>>   guix pull: error: Git error: invalid Content-Type: text/plain; 
>> charset=UTF-8
>>
>> so that I have to use git:// instead (which succeeds)? Is guile-git limited 
>> in
>> that aspect?
>
> I am struggling* to get going again with Cuirrass and suspect a similar
> thing.  On http:// urls with Cuirrass I now get
>
> Git error: no Content-Type header in response

Weird, I wonder why libgit2 insists on having Content-Type.

> janneke
>
> * cuirass' guix envronment -l guix.scm is broken, cuirass package runs a
>   script before patch-shebanging; the spec examples in the manual lacks
>   a (list (quote ..)...

Please report these issues and/or send a patch!  :-)

Ludo’.

Re: Mes 0.10 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:
> Arne Babenhauserheide writes:
>>> For details, see
>>>
>>> [8] https://gitlab.com/janneke/tinycc
>>>
>>> TinyCC uses (imho) unnecessarily complex C constructs.  Therefore it is 
>>> (imho)
>>> not too well suited as a bootstrap dependency, at least not in an
>>> unpatched state.
>> It still works with GCC, right?
> Yes.  Luckily, GCC can still handle simple C constructs ;-)
>
> When running i686-unknown-linux-tcc and mes-tcc to compile a trivial C
> program, the output produced by `lotsa debug printing' from both
> compiler runs is now identical, as is the resulting ELF binary.

That’s awesome!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: guix pull via cgit odd behavior or [guile-git] limitations?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> I am struggling* to get going again with Cuirrass and suspect a similar
>> thing.  On http:// urls with Cuirrass I now get
>>
>> Git error: no Content-Type header in response
>
> Weird, I wonder why libgit2 insists on having Content-Type.

Okay.  libgit2 does not support dumb http and `it never will'.

https://github.com/libgit2/libgit2sharp/issues/1094#issuecomment-112306072

That means the new cuirass lost dumb http support, possibly something to mention
in the manual.

>> * cuirass' guix envronment -l guix.scm is broken, cuirass package runs a
>>   script before patch-shebanging; the spec examples in the manual lacks
>>   a (list (quote ..)...
>
> Please report these issues and/or send a patch!  :-)

I added smart http to our git server and now have cuirass somewhat
going...intend to send some patches soon.

janneke

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

Re: guix pull via cgit odd behavior or [guile-git] limitations?

[ng0]

Jan Nieuwenhuizen transcribed 1.0K bytes:
> Ludovic Courtès writes:
> 
> >> I am struggling* to get going again with Cuirrass and suspect a similar
> >> thing.  On http:// urls with Cuirrass I now get
> >>
> >> Git error: no Content-Type header in response
> >
> > Weird, I wonder why libgit2 insists on having Content-Type.
> 
> Okay.  libgit2 does not support dumb http and `it never will'.
> 
> https://github.com/libgit2/libgit2sharp/issues/1094#issuecomment-112306072
> 
> That means the new cuirass lost dumb http support, possibly something to 
> mention
> in the manual.
> 
> >> * cuirass' guix envronment -l guix.scm is broken, cuirass package runs a
> >>   script before patch-shebanging; the spec examples in the manual lacks
> >>   a (list (quote ..)...
> >
> > Please report these issues and/or send a patch!  :-)
> 
> I added smart http to our git server and now have cuirass somewhat
> going...intend to send some patches soon.
> 
> janneke
> 
> -- 
> Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
> Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
> 
> 

Thanks for clearing that up. I'll add git-smart-http to my server and see
if it solves the situation when I turn off the download option from cgit.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org


signature.asc
Description: PGP signature

Re: code review

[Christopher Baines]

On Mon, 11 Sep 2017 22:10:22 +0200
Catonano  wrote:

> I could use some code review on my Trytond service hypothesis
> 
> As far as I understand, there are 2 steps that need to be done in
> order for a Trytond service to be usable.
> 
> 1) as the "postgres" role (that is as the operating system "postgres"
> user), create a "tryton" role
> 
> 2) as the tryton user (hence under the tryton role) run the Tryton
> initialization script (trytond-admin -c  -d  name> --all)
> 
> I feel like I should extend the postgresql service in order to create
> te trytond role but I don't know how

I don't think there is any current approach for doing this.

Service extension could be one way of doing it. It's similar to how
other services in Guix interact with each other. 

However, I believe creating a role can only be done when the PostgreSQL
server is running, which means that you'd need to defer creating the
role until that point. Keeping this in a single shepherd service might
not be easy to implement, and even if you did, there are some usability
issues, e.g. if you add a new service to the system, and that service
also extends PostgreSQL, then you might run in to trouble creating the
role for the new service, without needlessly restarting the PostgreSQL
service in the process.

One approach I've implemented and used [1] is to do create roles for
PostgreSQL when you start the service that uses that role.

I also remember Ludo suggesting using additional services to handle
this kind of setup, which I understood to be something like a
tryton-postgresql-role shepherd service, which the tryton shepherd
service would require.

1: https://github.com/alphagov/govuk-guix

> Also, I create the trytond role with no password. But what if someone
> wants to use this service for a real server ?
>
> The role password should be a parameter somehow. Again, I'm not sure
> how

It looks to be configurable at the moment, as someone using the service
can pass through there own value for the config-file field in the
.

On the subject of database connections, again, when trying to make
something work with the govuk-guix project, I ended up making record
types for different database connections (e.g. [2]). This makes it easy
to work with as data, and then convert to a URI when you need one. I'd
be interested in seeing this in Guix, as I think it would be really
useful when trying to write services that use databases.

2:
https://github.com/alphagov/govuk-guix/blob/master/gds/services/utils/databases/postgresql.scm#L24
 
> I borrowed some code from the postgresql service code and somewhat
> edited it
> 
> But I feel like an amateur neurosurgeon :-/
> 
> I could really use a review of this code
> 
> Here it is
> 
> (define-module (gnu services trytond)
>   #:use-module (gnu services)
>   #:use-module (gnu services shepherd)
>   #:use-module (gnu system shadow)
>   #:use-module (gnu packages admin)
>  ;; do I really need to access the postgresql package, here ?
>   #:use-module (gnu packages databases)
>   #:use-module (gnu packages tryton)
>   #:use-module (guix modules)
>   #:use-module (guix records)
>   #:use-module (guix gexp)
>   #:use-module (ice-9 match)
>   #:export (trytond-configuration
> trytond-configuration?
> trytond-service
> trytond-service-type
> ))
> 
> ;;; Commentary:
> ;;;
> ;;; Trytond based services. Mainly Trytond and GNUHealth for now
> ;;;
> ;;; Code:
> 
> (define-record-type* 
>   trytond-configuration make-trytond-configuration
>   trytond-configuration?
>   (trytond trytond-configuration-trytond ;
>(default trytond))
> ;; do I really need to access the postgresql package, here ?
>   (postgresql  postgresql-configuration-trytond
>(default postgresql))
>   (locale trytond-configuration-locale
>   (default "en_US.utf8"))
>   (config-filetrytond-configuration-file)
>   (data-directory trytond-configuration-data-directory)
>   )
> 
> 
> (define %default-trytond-config
>   (mixed-text-file "trytond.conf"
>"[database]\n"
>;; how do I connect with a role that has no
> password  ? ;; I create the trytond role without the password
>;; but what if someone wants to use this service
> for a real server ?
>;; the password should be a parameter, somehow
>;;"uri = 'postgresql://trytond:password@/'\n"
>"uri = 'postgresql://trytond:@/'\n" ;; is this
> string gonna work ?
>"path = /var/lib/trytond"))
> 
> (define %trytond-accounts
>   (list (user-group (name "trytond") (system? #t))
> (user-account
>  (name "trytond")
>  (group "trytond")
>  (system? #t)
>  (comment "Trytond server user")
>  (home-directory "/var/empty")
>  (shell (file-append shadow "/sbin/nologin")
> 
> (define trytond-activation
>   (match-lambda
> (($  t

Re: [PATCH 07/11] gnu: Add python-ipaddress.

[Cyril Roelandt]

On 09/12/2017 09:31 AM, Hartmut Goebel wrote:
> This package already exists, only the Python2-variant is missing.
Oh apparently the Py2 version is there as well. I deleted this patch.
Thanks for the review!

Cyril.

[PATCH 08/10] gnu: Add python-tqdm.

[Cyril Roelandt]

* gnu/packages/python.scm (python-tqdm, python2-tqdm): New variables.
---
 gnu/packages/python.scm | 29 +
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 7f48b8dae..cfe97b495 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -16333,3 +16333,32 @@ ignoring formatting changes.")
 
 (define-public python2-nose-timer
   (package-with-python2 python-nose-timer))
+
+(define-public python-tqdm
+  (package
+(name "python-tqdm")
+(version "4.15.0")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "tqdm" version))
+ (sha256
+   (base32
+ "0lwrmby8qz23gvqwkpivfrv4q8nfh90cz9ml6slwvwmcxxsdrhbf"
+(build-system python-build-system)
+(native-inputs
+ `(("python-flake8" ,python-flake8)
+   ("python-nose" ,python-nose)
+   ("python-nose-timer" ,python-nose-timer)
+   ("python-coverage" ,python-coverage)
+   ("python-virtualenv" ,python-virtualenv)))
+(home-page "https://github.com/tqdm/tqdm";)
+(synopsis "Fast, Extensible Progress Meter")
+(description
+  "Make loops show a progress bar on the console by just wrapping any
+iterable with @code{|tqdm(iterable)|}.  Offers many options to define
+design and layout.")
+(license (list license:mpl2.0 license:expat
+
+(define-public python2-tqdm
+  (package-with-python2 python-tqdm))
-- 
2.14.1

Re: Question about multiple licenses

[Dave Love]

Ludovic Courtès  writes:

>> 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),

Well, 
they should -- I think there should be something from GNU on
the topic -- and it's what motivated the Fedora
policy to separate %licence.  That's supposed to go into containers as
I understand it, c.f. %doc, which isn't in spec files.

> Guix makes it easier to do provenance tracking since
> there’s an unambiguous source → binary mapping.

Right, though the binary can be under a subset licence, e.g. when
un-shipped tests are under a different licence.

> 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.

The submitter and reviewer have to put the right stuff in the package
definition -- %license for Fedora and the copyright file for Debian.
That should be checked to first order with licensecheck (automated in
the "fedora-review" tool).  You might be able to automate cross-checking
with Debian and Fedora to some extent.

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

I think it has to be got right even if they don't do so.  There's plenty
imported to Fedora and Debian from those.

Re: Question about multiple licenses

[Dave Love]

Andy Wingo  writes:

> More concretely... if this is necessary (and I suspect but don't know
> that it is,) probably the easiest thing would be for each package to
> install a copyright file in its output derivations.  Then a "guix pack"
> would include them automatically.  It would be good to symlink/dedup
> common copyright files of course, but that can be a later step.
>
> Andy

Exactly (for generalized values of "a copyright file" unless you
amalgamate multiple ones like Debian does).  There's a limit to simple
deduplication if "this notice" that you need to ship includes a
copyright notice as well as the licence text ("Copyright 2017 Fred
Bloggs ...").

Re: missing licence files and incomplete licence lists

[Dave Love]

Ludovic Courtès  writes:

> 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.

Yes, but...  To package something for Debian or Fedora with a
problematic (or missing) licensing, you have to resolve that, typically
with "upstream", too get it into the distribution.

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

I'd say consult FSF legal eagles initially, and see whether you can
piggy-back off the work the other distributions have done.  Once you
have the legal constraints, you can consider a concrete proposal.  I
think the package license field also needs generalizing somehow to allow
conjunctions and disjunctions.  I fully realize the pain of all this
from experience...

[PATCH 09/10] gnu: Add python-pkginfo.

[Cyril Roelandt]

* gnu/packages/python.scm (python-pkginfo, python2-pkginfo): New variables.
---
 gnu/packages/python.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index cfe97b495..0da26b9d9 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -16362,3 +16362,33 @@ design and layout.")
 
 (define-public python2-tqdm
   (package-with-python2 python-tqdm))
+
+(define-public python-pkginfo
+  (package
+(name "python-pkginfo")
+(version "1.4.1")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "pkginfo" version))
+(sha256
+  (base32
+"17pqjfpq3c6xzdmk8pski6jcjgjv78q00zjf2bgzb668pzm6l6mv"
+(build-system python-build-system)
+(arguments
+ ;; The tests are broken upstream.
+ '(#:tests? #f))
+(home-page
+  "https://code.launchpad.net/~tseaver/pkginfo/trunk";)
+(synopsis
+  "Query metadatdata from sdists / bdists / installed packages.")
+(description
+  "API to query the distutils metadata written in the PKG-INFO file inside 
a
+source distriubtion (an sdist) or a binary distribution (e.g., created by
+running bdist_egg).  It can also query the EGG-INFO directory of an installed
+distribution, and the *.egg-info stored in a \"development checkout\" (e.g,
+created by running setup.py develop).")
+(license license:expat)))
+
+(define-public python2-pkginfo
+  (package-with-python2 python-pkginfo))
-- 
2.14.1

Re: My experiences with GuixSD

[Maxim Cournoyer]

Jonathan Brielmaier  writes:

> Am 11.09.2017 um 18:39 schrieb Maxim Cournoyer:
>> 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. And without all those FOSS add-ons
>>> on addons.mozilla.org Icecat/Firefox is bad.
>> 
>> What do you mean *without these add-ons*? AFAIU you can still manually
>> visit that page and install anything you like. It's just not integrated
>> tightly, for good reasons (makes you think twice before installing some
>> random closed source add-on form the net in your browser).
>
> As described this didn't work. I haven't installed closed-surce add-ons
> on Firefox before. The wide majority on AMO is FOSS from my perspective.

Maybe something under Preferences -> Security. I see that I under
"Exceptions..." I have https://addons.mozilla.org set to Allow. I also
unchecked the "Block dangerous and deceptive content" on that same tab.

HTH,

Maxim