Re: bug#26109: [PATCH 3/7] gnu: Add dcmtk.

[Leo Famulari]

On Sat, Mar 18, 2017 at 01:36:31PM -0400, John Darrington wrote:
> [CC guix-devel@gnu.org]
> 
> So we have to make a choice:
> 
> 1. Package a released program with a known vulnerability; or

Although all non-trivial software contains bugs, many of which can be
exploited, we should not add new packages with known exploitable
vulnerabilities.


signature.asc
Description: PGP signature

Re: Install hook

[John Darrington]

On Sun, Mar 19, 2017 at 02:41:09PM +0100, pelzflorian (Florian Pelz) wrote:

 No, normally gschemas.compiled is one file storing information about all
 GSettings application. It must thus be created from files provided by
 multiple packages.
 
 For example, gnome-calculator ships
 
 org.gnome.calculator.gschema.xml
 
 and gnome-maps ships
 
 org.gnome.Maps.gschema.xml
 
 and from both source files a file gschemas.compiled needs to be created
 when gnome-calculator and gnome-maps are installed to the same profile.
 This single file then stores settings of both packages.


I think I see what you are saying:  gschemas.compiled should not be part of the
the package derivation, but should be part of the profile derivation.

So then guix package --install or guix environment would need to run the 
necessary
stuff to create it.

I guess that could work, but would work probably need some changes at quite a 
low
level.

But what would happen if one had for example gnome-calculator in the system 
profile,
and gnome-maps in the user profile?  Would it work under those circumstances?

J'
 



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: bug#26109: [PATCH 3/7] gnu: Add dcmtk.

[Kei Kebreau]

John Darrington  writes:

> [CC guix-devel@gnu.org]
>
> So we have to make a choice:
>
> 1. Package a released program with a known vulnerability; or
> 2. Package an unreleased git snapshot.
>
> Which is the lesser evil?

I choose option two. I'm quite uncomfortable with packaging software
that is known to be vulnerable. To me it seems almost malicious if it
can be avoided.

Other opinions?

>
> J'
>
> On Sat, Mar 18, 2017 at 12:21:40PM -0400, Kei Kebreau wrote:
>> John Darrington  writes:
>> 
>> > On Fri, Mar 17, 2017 at 04:42:59PM -0400, Kei Kebreau wrote:
>> >  
>> >  Judging from the description of the software, it seems like this could
>> >  fit in gnu/packages/image.scm.
>> >  Also, the linter says that this package vulnerable to
>> >  CVE-2015-8979. Supposedly this* upstream patch fixes it. Could you see
>> >  if that fix works for this package?
>> >  
>> >  * https://github.com/commontk/DCMTK/commit/1b6bb76
>> >  
>> >
>> > Unfortunately this patch doesn't go in.  It seems that as well as fixing 
>> > this
>> > vulnerability it also makes some unrelated changes.  Furthermore, it 
>> > depends
>> > on a whole lot of other patches which are not in this release.
>> >
>> > Do we have a procedure on what to do in cases like this?
>> >
>> > J'
>> 
>> I don't know if we have an official procedure, though we could try using
>> a later git snapshot with the security patch already integrated.
>> Hopefully that provides functionality compatible to that of the stable
>> release, though it's at least a five year difference between release times.
>> 
>> http://git.cmtk.org/?p=dcmtk.git,a=tags


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Leo Famulari]

On Tue, Mar 21, 2017 at 02:22:11AM +0100, John Darrington wrote:
> * gnu/packages/fontutils.scm (arguments)[configure-flags]: Add 
> LDFLAGS=lpthread.
> * gnu/packages/image.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.

I'll wait for somebody else to review the code changes (I don't
understand their impact), but the commit message should be like this:

* gnu/packages/fontutils.scm (PACKAGE)[arguments]: Add LDFLAGS=lpthread
to #:configure-flags.

et cetera


signature.asc
Description: PGP signature

For core-updates.

[John Darrington]

This patch fixes a number of failures in core-updates.  I don't know
if there is a better way of doing it, or why it is suddenly necessary.

gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[John Darrington]

* gnu/packages/fontutils.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.
* gnu/packages/image.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.
---
 gnu/packages/fontutils.scm | 1 +
 gnu/packages/image.scm | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index 7e7234960..2512626d2 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -56,6 +56,7 @@
 (sha256 (base32
  "121gm15ayfg3rglby8ifh8384mcjb9dhmx9j40zl7yszw72b4frs"
(build-system gnu-build-system)
+   (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))
(native-inputs
 `(("pkg-config" ,pkg-config)))
(propagated-inputs
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 2989ea006..5280f477d 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -80,6 +80,8 @@
 (sha256
  (base32 "0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq"
(build-system gnu-build-system)
+   (arguments
+`(#:configure-flags '("LDFLAGS=-lpthread")))
 
;; libpng.la says "-lz", so propagate it.
(propagated-inputs `(("zlib" ,zlib)))
-- 
2.11.0

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Clément Lassieur]

Danny Milosavljevic  writes:

> Hi ng0,
>
> On Sun, 5 Mar 2017 14:50:26 +
> ng0  wrote:
>
>> What I take from the discussion is, all is good to go except for
>> subsystems. I'm okay with reviewing subsystems as an individual patch
>> later on. For me this works. Push the 3 patches, and send the subsystems
>> one later as a new discussion-bug.
>
> The 3 were pushed to master.
>
> Patch 4 not yet. So let's discuss.
>
> I have no preference for pairs or lists - it's just that the documentation 
> should say what it actually expects - because the user has to write the form 
> differently:
>
>   Pair: '(a . b)
>
>   List: '(a b)
>
> Those are not compatible with each other.
>
> (I think as the patch is written now it expects lists)
>
> And I'm against calling pairs "two-element tuple"s. It reminds me of these 
> math joke equations which write the value 2 in a really complicated way (but 
> correctly) :)
>
> And lists are definitely not two-element tuples. That would be seriously 
> confusing.
>
> What do you think?

Hi Danny,

I forgot to thank you for this explanation of pairs and lists.  I took
it into account here:
http://lists.gnu.org/archive/html/guix-patches/2017-03/msg00610.html.

Clément

Re: Being excellent to one another

[dian_cecht]

First of all, I have no clue why my email was explicitly listed in the
CC:; I'll assume that was in error.

Second, it is not my intention to insult or offend anyone here, but
some people seem to be rather thin-skinned about (possibly pretend)
slights. However, I feel I should toss my hat into the ring here for my
own reasons.

I should also make it known I have no clue who anyone in these emails
are apart from ng0 and Ludo', the rest of you could be a very advanced
Eliza for all I'm concerned, so it's pretty much impossible for me to
support anyone here.

Also feel free to ignore it if you so wish, though I'd appreciate
everyone at least read the first footnote for what will be obvious
reasons.

On Mon, 20 Mar 2017 11:17:28 +0100
Alex Sassmannshausen  wrote:

> John Darrington writes:
> > Regarding your other comments,  as we have discussed before, we
> > will have to agree to disagree about singular they.   I have not
> > the benefit of ever having learned English as a foreign language.
> > But I do remember in my elementary school being taught NOT to use
> > it *especially* not in written text.  And - perhaps because of this
> > early tuition - it still sounds clumsy and confusing to me.  
> 
> Perhaps we have to agree to disagree on singular they,

I just want to mention that most, if not all, my English teachers
thought the use of "they" and related was entirely incorrect, so John
isn't alone here. English, simply put, lacks any "correct"
gender-neutral pronouns, despite what common usage suggest. However, as
I'd hope John is aware, common usage these days was considered the
height of vulgarity a century before, at the very least.

For anyone who reads older books, mankind as a whole used to be refered
to as "he", and while one can certainly make an issue out of that (and
I'm sure plenty of people have), it does also set a precedent for using
the male gender as a gender-neutral option, which happens to have a
rather long history.

> but I hope we
> can still agree on the following statements from my earlier email:
> 
> -
> [...] it's super easy:
> - if you're not sure (or have forgotten), use "singular they", or ask
> - if you know someone has a preference for pronouns, use those
> - don't use pronouns when *you know* the other person does not
> identify with them.

I'm just going to point out that this whole 'gendering' issue is, at
least as far as I am concerned, a rather recent developement, and one
that I can't understand in the least [1]. I don't know about anyone
else, but gender == sex, and that is more-or-less that. Certainly some
people don't follow the traditional sex/gender roles (tomboys and
metrosexuals (I think that was the proper term for an effiminent male
used during the 90's, anyways) being the best examples I can come up
with), but this feels very much like hairsplitting to me, and
especially in the case of older generations use of English can very
easily work against decades of normal, /correct/, and proper usage.

> If you make a mistake, no-one will tear your head off

I haven't kept up with this thread for very long, but I will say the
tone, to me, an uninvolved (up until now) individual, sounds like a bit
witch hunt.

> In manuals we can just use "singular they", because it is a well
> established convention and does not cause confusion.

Another alternative that I just remembered running across was swapping
pronoun gender between chapters/sections. This is done with some of the
RPG books I have, so I thought I'd toss that option into the ring.

> 1. Try not to offend.
> 2. Try not to be offended.
> 3. Recognise that diversity is an asset.  
> 4. Respect the integrity and right to self-definition of all
> participants

IMO, the 4th guideline there is entirely redundant and already covered
by the 3rd.

I don't know if it is a cultural thing, or how I was raised, or what,
but as far as I am concerned part of basic social etiquette is roughly
summed up by the first two guidelines in the above list. Call me old
fasioned or a bigot or whatever, but calling a male "he" and a female
"she" is and should be perfectly acceptable, especially in this day and
age. If one takes offense to being called a "he" when they prefer
"she", then as far as I am concerned they are either looking for a
reason to be insulted (which is rather poor manners IMO) or rather
thin-skinned and thus easily injured (which is a handicap in general
social situations and also seems to assume that anyone 'misgendering'
them is making an effort at being insulting, when there is probably no
practical way for someone to identify their prefered pronoun unless
they happen to be a rather capable cross-dresser). For people who are
easily injured, I do feel sorry, and hopefully a capable psychologist
could help with that (I'd make other suggestions, but I don't feel
this is the place for such).

As far as I am concerned, being insulted or injured because someone
misgenders you 

Re: [PATCH] gnu: Add fpc. (version 2)

[Kei Kebreau]

Ricardo Wurmus  writes:

> Danny Milosavljevic  writes:
>
>> Hi,
>>
>>>+   (copy-file (assoc-ref inputs "fpc-binary")
>>>+  "fpc-bin.tar")
>>>+   (zero? (system* "tar" "xvf" "fpc-bin.tar")
>>
>> Why the copy-file and then untar ? Can't it be untarred immediately from 
>> where it is? If it is useful, maybe add a comment about the reason.
>>
>> Also, it might be easier to have a fpc-bootstrap package with the
>> bootstrap binaries that installs the binaries required to build fpc
>> normally and to make a fpc package depend on fpc-bootstrap as
>> native-inputs.  What do you think?  I myself don't have a strong
>> preference about it - but some other packages do it that way.
>
> It’s not so nice to depend on a binary bootstrap.  Can this be avoided?
> I tried packaging a version of the GNU Pascal compiler, which is
> unmaintained, in an effort to bootstrap a version of FPC from source.
>
> Have you attempted this?
>

Though I would prefer a source bootstrap, I haven't attempted this. I
anticipate that it would be no small feat getting the GNU Pascal
compiler to work. Were you using a recent version of GCC to try to
bootstrap FPC?

> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net


signature.asc
Description: PGP signature

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hi,

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

>> 2.1 The testing infrastructure
>> ──
>>
>>   Currently Cuirass is providing a small test suite consisting only of
>>   unit tests.  The integration tests are done manually with basic
>>   examples consisting in building small packages such as GNU Hello.
>>   This is not good, because actual packages take a consequent time to
>>   compile, and testing only basic examples leaves the interesting
>>   complex case out of the scope of testing.  The worst is that the
>>   result depend on the phase of the moon since every commit in Guix can
>>   potentially break the build.
>>
>>   The idea is to take inspiration from the Guix test suite by providing
>>   tiny mocked packages that will help having lightweight build
>>   specifications.  Those tests require launching another instance of the
>>   `guix-daemon' with a local temporary store.
>
> Sounds like a good idea.
>
> It would be nice to refine what it is we’re trying to test and that’s
> not addressed by unit tests.  At one end of the spectrum, I imagine we
> could be spawning a couple of GuixSD VMs connected together, one serving
> a Git repo, and the other one running Cuirass pulling from that repo (a
> system test).
>
> At the middle of the spectrum is something like you describe, I think:
> run Cuirass directly upon “make check”, though there are complications:
> what repo do we pull from, do we really want to build packages and if
> not how to we mock builds, etc.

The idea I had was to create fake vcs repositories programmatically.  I
imagine that it is possible to associate some dummy build script that we
can deterministically make fail.

> There are several components we’d like to test more closely IMO: SCM
> polling, evaluation, and job scheduling.  Perhaps some of that can also
> be achieved through unit tests?

Yeah, that would be better.

>> 2.2 HTTP API
>> 
>>
>>   Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a
>>   web server which is running in a separate thread of the `cuirass'
>>   process.  However the resources it provides are pretty limited since
>>   you can only query the lists of specifications currently watched.
>>   This is done with the `/specifications' or `/jobsets' resource names.
>>   "Jobsets" is the terminology used by Hydra and is used here for
>>   compatibility with its HTTP API.
>
> For a start, I think we should implement all or a subset of the Hydra
> API, as-is (it’s currently used by Emacs-Guix):
>
>   https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Controller/API.pm
>
> A large part of it is about monitoring the status of Hydra: queued
> builds, recently-completed builds, jobs, etc.  That is the most pressing
> need, I think.

OK.

>>   This roadmap lacks details about the concrete tasks and its associated
>>   timeline.  However I prefer having some feedback about this proposal
>>   first, before providing a complete roadmap.
>>
>>   • From May 30 to June 26, I will work on the testing infrastructure,.
>>   • From June 27 to August 29, I will work on the HTTP API.
>
> You may find that you’ll want to interleave tasks.  I don’t know about
> you, but sometimes I get bored if I keep working on the same task or
> domain for too long, so switching to something else for a while can be a
> relief.  :-)

I don't know, I have been rarely confronted to that issue personnaly
(more the opposite: too much context switching).  But I will
preventively adapt my roadmap.

> There are a couple of isolated tasks that come to mind, which do not
> really fit in the proposal but are worth looking into as time permits:
>
>   • improved error reporting upon evaluation failures and so on;
>
>   • improved error recovery;

I totally forgot to precise that the error handling issue is exactly the
reason I think we need a better test infrastructure for Cuirass.  Being
able to reproduce various errors or failues allows a better confidence
in the error being properly handled.  I find it hard to just imagine
and write the appropriate handler.

>   • use of Guile-Git instead of Git.

I Will add this to the plan.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

"pelzflorian (Florian Pelz)"  writes:

> On 03/12/2017 07:41 PM, Mathieu Lirzin wrote:
>> Hello Florian,
>> 
>> "pelzflorian (Florian Pelz)"  writes:
>> 
>>> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
 Sensitive requests should be done with an
   authentification mechanism which is not determined yet.  I currently
   have no experience with any and lack the knowledge to properly choose
   one.
>>>
>>> I’m new to Guix and Scheme and no expert in Web programming, but in
>>> order to prevent CSRF and in order not to rely on JavaScript, the server
>>> should run with HTTPS (of course) and
>>> · use a secret session token and
>>> · send a customized Web page to the client adapted so that each link and
>>> form to the server includes the session token as a GET or POST parameter.
>>>
>>> An alternative is Basic Access Authentication with HTTPS or Cookies with
>>> HTTPS but they are vulnerable to CSRF.
>>>
>>> See stackoverflow, for example
>>>
>>> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication
>> 
>> Thanks for your input.
>> 
>> Have you any experience/advice regarding OAuth or Json Web Token (JWT) ?
>> 
>
> Sorry, I have no experience with these. I think I’ve basically
> understood what OAuth is for after reading the OSM wiki, [1] but I’m not
> sure what you want to use it for.
>
> I assume the following scenario:
>
>
> The user wants to log in.
>
> · The Cuirass Web server would receive the log-in credentials as POST
> parameters from an HTML form.
>
> · Now it needs to check whether the password is correct, e.g. by looking
> up the salt stored for the supplied username, computing the bcrypt hash
> of the supplied password and stored salt and comparing it to the stored
> bcrypt hash for the user name.← This requires Cuirass to store a
> table containing user names, salts and bcrypt hashes. Do you intend to
> use some OAuth / OpenID / whatever thing to outsource the log-in
> management to an “identity provider”? I presume you don’t.
>
> · You generate a secret session token shared between server and client
> which you
>   — embed in each link and in each form you send to the client as part
> of the session and
>   — can verify the session token on the server.← I did not know
> about JWT, but from a first glance it seems very appropriate for this
> use. Instead of storing on the server which sessions are still active,
> the token stores all information about the log-in and its content is
> encrypted with the server’s secret key. This seems like a great idea,
> also there maybe is (or should be) a library to manage JWT. I learned
> something today. :)

I need to do my homework before being able to go further in this
discussion.  Thanks for you analysis.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

GuixSD download options

[pothos]

Hello,

since the installation process is quite manual, takes long and ends in a
VM image for users who don't want to replace their current system, I
think there should be at least an option to download a tar file with the
content of a preconfigured root file system.
Then one could just extract it and run with systemd-nspawn -bD folder
(or if needed, use a new network device to support ssh if login with
machinectl is not enough).

Additonally a VM image would also be interesting.

Maybe this was already considered?

Regards,
Kai

Re: 01/01: gnu: Add comments on why setting QT_QPA_PLATFORM for tests.

[Tobias Geerinckx-Rice]

Hartmut,

On 20/03/17 20:57, Hartmut Goebel wrote:
> htgoebel pushed a commit to branch master
> in repository guix.

[...]

> ;; make Qt render "offscreen", required for tests

A very minor detail, but since it's repeated here so many times:
whole-line, ‘;;’-style comments should be full sentences, with capital
letters and full stops:

  ;; Make Qt render "offscreen" as required by tests.

would have been perfect.

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] gnu: Add fpc. (version 2)

[Ricardo Wurmus]

Danny Milosavljevic  writes:

> Hi,
>
>>+   (copy-file (assoc-ref inputs "fpc-binary")
>>+  "fpc-bin.tar")
>>+   (zero? (system* "tar" "xvf" "fpc-bin.tar")
>
> Why the copy-file and then untar ? Can't it be untarred immediately from 
> where it is? If it is useful, maybe add a comment about the reason.
>
> Also, it might be easier to have a fpc-bootstrap package with the bootstrap 
> binaries that installs the binaries required to build fpc normally and to 
> make a fpc package depend on fpc-bootstrap as native-inputs.  What do you 
> think?  I myself don't have a strong preference about it - but some other 
> packages do it that way.

It’s not so nice to depend on a binary bootstrap.  Can this be avoided?
I tried packaging a version of the GNU Pascal compiler, which is
unmaintained, in an effort to bootstrap a version of FPC from source.

Have you attempted this?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
> evaluation of the “core” package set for that branch, and check for
> anything wrong.  From there on, forbid full-rebuild changes.
> 
>   • Once the “core” subset builds correctly on all the supported
> platforms (those that Hydra supports), merge ‘master’.  Maybe update
> a couple of things like GnuTLS while we’re at it.  From there on
> forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
> must change the “subset” argument to “all” in the config of the
> ‘core-updates’ jobset.)
> 
>   • Fix things.

We are at this stage... please help :)

Here is a list of packages that are failing on core-updates but not on
the master branch:

https://hydra.gnu.org/eval/109549?compare=master=1#tabs-now-fail

It might take a while to load the web page; please have patience :)

Once you load it, take note of the brown and red icons.

The brown icon means, "we did not try to build this yet, because one of
the dependencies failed to build".

The red icon means, "we tried to build this and it failed." You should
probably focus on these failed builds.

I'm sorry if the color-coding is not sufficient for you; we know it's
not a good system for people who have impaired vision. My vision is
pretty good and I find it hard to pick out the red icons.

Once you have found an interesting build failure, read its log (the
"raw" log is most useful, in my opinion) and try to reproduce and fix it
on your machine. Then send a patch!

Sometimes there is a spurious build failure: The SSH connection used for
offloading fails, or the build machine is out of memory. Reply to this
thread with a link to the failing build and we will restart it.

Thanks in advance :)


signature.asc
Description: PGP signature

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 04:49:13PM +0100, Ludovic Court??s wrote:
 
 John, people have explained things at length already; you can re-read
 the project???s code of conduct if in doubt.  This isn???t up for debate.
 Please stop playing this game right now.
 
Ludo,

* I am not playing a game - I think this is very serious.
* I have not breached the code of conduct (at your request I have just read 
  it again).
* I am trying my *utmost* to act with restraint and consideration in the face
  of persistent provocation.
* I have said on several occasions that we should all agree to live with
  our differences and let this thread stop.

John

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[Ludovic Courtès]

John Darrington  skribis:

> On Mon, Mar 20, 2017 at 10:09:33AM -0500, Christopher Allan Webber wrote:
>  John Darrington writes:
>  
>  > On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
>  > ... and yes.  If an individual specifically requests to be referred to 
> by
>  > a partcular set of pronouns I will attempt to do so, but may 
> occasionally
>  > forget if that person wants feminine pronouns and is 6'4" and has an 
> enormous
>  > black wiry beard.
>  
>  This was a needlessly hurtful comment, and if you can't see that, I
>  worry about it.  John, I respect your technical contributions to the
>  Guix project, but this isn't okay.
>
> I'm sorry - but WHY is it hurtful?  Whom does it hurt?   How is that person
> hurt?
>
> Please explain.

John, people have explained things at length already; you can re-read
the project’s code of conduct if in doubt.  This isn’t up for debate.
Please stop playing this game right now.

Ludo’.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Clément Lassieur  writes:
>
>> Ludovic Courtès  writes:

[...]

>>> As of right now, ‘guix pack’ can create Docker image (‘guix archive’
>>> can no longer do that):
>>>
>>>   guix pack guile-next -S /opt/guile-2.2.0= -f docker
>>>
>>> I’d be grateful if someone could check with Docker that I didn’t break
>>> anything though.  Any takers?  :-)
>>
>> I just tested it (although I'm probably not the first) and it works
>> (with "docker load").  Thanks!
>
> I also tested it successfully:
>
> image=$(guix pack -f docker -S /opt/gnu/bin=bin r)
> docker load < $image
> id=$(docker images -q profile | tail -n 1)
> docker run --rm --tmpfs /tmp:rw,size=787448k,mode=1777 -ti $id 
> /opt/gnu/bin/R
>
> This creates an image for R, loads it, starts (and eventually removes)
> a container in which R runs.

Awesome, thank you both for testing!

> For people who find this cumbersome: use containers with Guix instead.
> Here’s how:
>
> guix environment --container --ad-hoc r -- R

Indeed!  :-)

Ludo’.

Re: Introducing ‘guix pack’

[Alex Sassmannshausen]

Excellent article, thanks for writing and sharing!

Alex


Ludovic Courtès writes:

> Hi again!
>
> I’ve written about ‘guix pack’ here:
>
>   https://gnu.org/s/guix/news/creating-bundles-with-guix-pack.html
>
> Thanks to rekado & jonsger on IRC for the quick review!
>
> Ludo’.

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 10:09:33AM -0500, Christopher Allan Webber wrote:
 John Darrington writes:
 
 > On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
 > ... and yes.  If an individual specifically requests to be referred to by
 > a partcular set of pronouns I will attempt to do so, but may occasionally
 > forget if that person wants feminine pronouns and is 6'4" and has an 
enormous
 > black wiry beard.
 
 This was a needlessly hurtful comment, and if you can't see that, I
 worry about it.  John, I respect your technical contributions to the
 Guix project, but this isn't okay.

I'm sorry - but WHY is it hurtful?  Whom does it hurt?   How is that person
hurt?

Please explain.


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Introducing ‘guix pack’

[Ricardo Wurmus]

Clément Lassieur  writes:

> Ludovic Courtès  writes:
>
>> Hello Guix!  Hello 2.2 Guilers!
>>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> I’d like to move support for Docker (currently in ‘guix archive’) to
>>> this new command because I think it’s more appropriate: ‘guix archive’
>>> is supposed to be rather low-level so it would not create a profile, for
>>> instance.
>>
>> As of right now, ‘guix pack’ can create Docker image (‘guix archive’
>> can no longer do that):
>>
>>   guix pack guile-next -S /opt/guile-2.2.0= -f docker
>>
>> I’d be grateful if someone could check with Docker that I didn’t break
>> anything though.  Any takers?  :-)
>
> I just tested it (although I'm probably not the first) and it works
> (with "docker load").  Thanks!

I also tested it successfully:

image=$(guix pack -f docker -S /opt/gnu/bin=bin r)
docker load < $image
id=$(docker images -q profile | tail -n 1)
docker run --rm --tmpfs /tmp:rw,size=787448k,mode=1777 -ti $id 
/opt/gnu/bin/R

This creates an image for R, loads it, starts (and eventually removes)
a container in which R runs.

For people who find this cumbersome: use containers with Guix instead.
Here’s how:

guix environment --container --ad-hoc r -- R

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 03:27:48PM +0100, Ludovic Court??s wrote:
 Howdy!
 
 John Darrington  skribis:
 
 > As I recall, their request was that I always use "singular they" and 
never to 
 > mention other possible alternatives to anyone.  I acknowledge their 
request and 
 > recognise their every right to make it.  But I feel no obligation to 
comply with
 > their request.  Ng0's reaction to my declining, I interpreted to mean 
that they 
 > considered it not to be a request, but a demand.  If this interpretation 
was 
 > wrong, then I apologise to them.
 
 John, I think you???re playing on words here.

I'm glad you noticed!   If you (or anyone else wishes) I will retype the 
above text using the pronoun of your choice, because I mean what I say.
 
 In this case, what matters is respecting the other participant who
 explicitly asked to be referred to using non-gendered pronouns.  It???s a
 very simple request; honoring it costs us nothing but it can make a big
 difference to this person.

I fully agree.  And I have already said that I have no problem with that, and
will do so without argument.
 
 I don???t want anyone of us to make someone else???s life harder by
 disregarding what they present as important to them.

Nobody should ever set out to make the life of another person harder.  Also,
nobody should ever start believing that what is important to them  must take
priority over what is important to another.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[Ludovic Courtès]

Howdy!

John Darrington  skribis:

> As I recall, their request was that I always use "singular they" and never to 
> mention other possible alternatives to anyone.  I acknowledge their request 
> and 
> recognise their every right to make it.  But I feel no obligation to comply 
> with
> their request.  Ng0's reaction to my declining, I interpreted to mean that 
> they 
> considered it not to be a request, but a demand.  If this interpretation was 
> wrong, then I apologise to them.

John, I think you’re playing on words here.

It’s as simple as Alex wrote it:

> - if you're not sure (or have forgotten), use "singular they", or ask
> - if you know someone has a preference for pronouns, use those
> - don't use pronouns when *you know* the other person does not identify
>   with them.

In this case, what matters is respecting the other participant who
explicitly asked to be referred to using non-gendered pronouns.  It’s a
very simple request; honoring it costs us nothing but it can make a big
difference to this person.

I don’t want anyone of us to make someone else’s life harder by
disregarding what they present as important to them.

Thanks,
Ludo’.

PS: It’s a non-technical discussion but one that’s important to have to
make sure our group works correctly.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hi,

Federico Beffa  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Federico,
>>
>> Federico Beffa  skribis:
>>
>>> Say, developer A distributes such an archive A and developer B
>>> distributes archive B (a different program/library) and someone C
>>> installs both.
>>
>> Interestingly composability (what happens when you unpack both A and B
>> on the same system) is better than what you’d get with Docker: the
>> unpacked items that are identical are shared, and those parts that
>> differ don’t collide.
>
> Packs share identical items, but it becomes essentially impossible to
> remove one component out of many.

Yes, of course.  It’s really a frozen system snapshot.

>> The intended use case is mostly “one-off” packs where you just want
>> people to easily test something, as opposed to putting it in
>> production.  This was the case for the Guile 2.2.0 release.  In those
>> cases, people would essentially “rm -rf /gnu” when they’re done.
>
> If you provide an archive such as
> 'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main
> project page (especially without any warning about its intended
> purpose), I bet that many peoples will install it and keep it.  If more
> projects follow this example, we land to the above scenario where "rm
> -rf /gnu" is not practical at all.

I agree, there’s always a risk.  I think what we can do is communicate
about these risks, and avoid using distributing packs in situations that
make it too likely that people will keep the pack without ever
upgrading.

>> For code that is meant to be kept over time, I would recommend to either
>> use Guix, or to include Guix in the pack so that people can eventually
>> upgrade.
>
> This is clear to me, but there are many peoples who do not know about
> Guix, or just don't want it.  They may still be interested in, say,
> Guile 2.2.
>
> With the 'pack' command it seems to me that Guix is being promoted as a
> convenient development environment where at the end you can produce
> binary bundles for distribution on any system that it supports.  But,
> without providing at least a way to remove things, it seems to be
> heading toward a dangerous direction.

Sure.  I think it’s a handy but potentially dangerous tool.  In my view
the goal is not to promote Guix as a tool to make bundles, but rather
allow people to solve problems in specific circumstances, with the above
caveats.  Those caveats largely apply to other “app bundle” solutions,
and I’d argue that this one is “less bad” that most other bundling
solutions.

Thanks for your feedback!

Ludo’.

Re: Introducing ‘guix pack’

[Clément Lassieur]

Ludovic Courtès  writes:

> Hello Guix!  Hello 2.2 Guilers!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> I’d like to move support for Docker (currently in ‘guix archive’) to
>> this new command because I think it’s more appropriate: ‘guix archive’
>> is supposed to be rather low-level so it would not create a profile, for
>> instance.
>
> As of right now, ‘guix pack’ can create Docker image (‘guix archive’
> can no longer do that):
>
>   guix pack guile-next -S /opt/guile-2.2.0= -f docker
>
> I’d be grateful if someone could check with Docker that I didn’t break
> anything though.  Any takers?  :-)

I just tested it (although I'm probably not the first) and it works
(with "docker load").  Thanks!

> The archive build process is bit-reproducible too, which is pretty cool
> (Docker images created in January, 1970!).
>
> That’s it!
>
> Ludo’.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hi again!

I’ve written about ‘guix pack’ here:

  https://gnu.org/s/guix/news/creating-bundles-with-guix-pack.html

Thanks to rekado & jonsger on IRC for the quick review!

Ludo’.

Re: 01/02: gnu: Add itpp.

[John Darrington]

On Mon, Mar 20, 2017 at 02:05:11PM +0300, Alex Kost wrote:

 You don't need any additional "plugins" for this, as Emacs couldn't miss
 it!
 
 To check it, run "emacs -Q", paste this:
 
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://sourceforge/itpp/itpp/"
   version "/itpp-"
   version ".tar.gz"))
   (sha256
 (base32
  "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"
 
 to some buffer, run "M-x scheme-mode" there, move the point to the
 beginning of this sexp and press "C-M-q" ("indent-sexp" command).  And
 you'll see that (sha256) is at the same column as (origin).

I thought I did that.  Possibly, I forgot to do it one last time, before I
committed.   

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 12:53:38PM +0100, Pjotr Prins wrote:
 Erm. Despite the obvious intelligence of all Guix participants I think
 we ought to stick to technical issues on this mailing list (i.e.,
 guix-technical). 
 
 Maybe we can fork these recent discussions to guix-ethical or
 guix-culture? We all have good intentions, that is the general
 assumption! But I think these discussions will hurt the project as a
 whole. 

I fully agree and have made the same sugggestion a few days ago.


J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[ng0]

Pjotr Prins transcribed 0.4K bytes:
> Erm. Despite the obvious intelligence of all Guix participants I think
> we ought to stick to technical issues on this mailing list (i.e.,
> guix-technical). 
> 
> Maybe we can fork these recent discussions to guix-ethical or
> guix-culture? We all have good intentions, that is the general
> assumption! But I think these discussions will hurt the project as a
> whole. Take it elsewhere, ladies and gentleman.
> 
> Pj.
> 

Discussions about how the project is perceived and acts through the
actions of one of its members with implicit ignorance and refusal to
simply acknowledge problems, acknowledge differences, language barriers, and the
hint to read and learn (wow, new knowledge, you could actually grow on this),
are not hurting the community. It is what we need. I did not want to
follow this discussion, but it seems as it is necessary. I agree to an
earlier point which was made, and extend it: I don't want to be part of
a project which looks and behaves like almost every other project out
there, an exclusive boysclub.
I understand that the majority at least in the scope of this project is
acting and behaving welcoming,friendly and understanding.
When there are problems, the way to cope with them is not to move them
elsewhere.
This is not only about pronouns. I wished it was that easy, but it
isn't.
The default of John, if you go through irc logs, is to correct
repeatedly people who make mistakes in english. I'm asking to
acknowledge the existence of people who do not define their gender as
binary, to not regard them as exceptional or unusal, and to respect!
people who are not speaking or writing english daily. If you can't
understand them, ask politely.
To correct them without them asking for corrections is a top-down view
you can only allow yourself to have if you have more privileges than the
other person.

Now what I'm personally requesting, it shouldn't be necessary that I have
to do this: don't try to attack me. don't chery pick arguments. I don't
expect everyone to be friendly, I've lived long enough to know that this
won't work out.
We are working on this in our freetime. (as an example, not directly
related to this thread) I would not hang out in my free
time with facists, sexists, or otherwise unfriendly people.

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 12:21:59PM +0100, Alex Sassmannshausen wrote:

 My intention was to call-back to my impression of other parts of this
 conversation where it seemed you were point-blank refusing to
 acknowledge ng0's request.

As I recall, their request was that I always use "singular they" and never to 
mention other possible alternatives to anyone.  I acknowledge their request and 
recognise their every right to make it.  But I feel no obligation to comply with
their request.  Ng0's reaction to my declining, I interpreted to mean that they 
considered it not to be a request, but a demand.  If this interpretation was 
wrong, then I apologise to them.
 
 Say whaat?  Way to blow our discussion out of proportion.  Are you
 seriously suggesting the consensus established through conversation and
 convention in a small community is in any way comparable to the pile of
 dung that is the contemporary ridiculously complex and terrifyingly
 non-egalitarian state of global authoritarian politics?

I believe the current state of global politics has come about through populism.
In part, that means some people have been coerced into supporting what
they would not otherwise have supported - because of peer pressure.  I do
support what I believe to be wrong - ethically, technically or gramatically -
simply because a majority of other people say I should.
 

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[Pjotr Prins]

Erm. Despite the obvious intelligence of all Guix participants I think
we ought to stick to technical issues on this mailing list (i.e.,
guix-technical). 

Maybe we can fork these recent discussions to guix-ethical or
guix-culture? We all have good intentions, that is the general
assumption! But I think these discussions will hurt the project as a
whole. Take it elsewhere, ladies and gentleman.

Pj.

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Mon, Mar 20, 2017 at 11:17:28AM +0100, Alex Sassmannshausen wrote:
>
>  Perhaps we have to agree to disagree on singular they, but I hope we can
>  still agree on the following statements from my earlier email:
>
> I agree to a slightly edited version:
>
>  -
>  [...] sometimes there is not a simple solution, however :
>  - if you know someone has a preference for particular pronouns, use 
> those when
>refering to that person.
>  - don't use pronouns when *you know* the other person does not identify
>with them.
>  - if unsure, ask the person how he or she would like to be referenced.
>
>  If you make a mistake, an apology will show your intention was not 
> malicious.
>
>  In manuals we can just use "singular they",  or another non-gender 
> specific
>  form of reference.
>  -

In the end, when you communicate informally, there is no arbiter of what
you write, so, to be clear, the first part above is not some form of
official guideline — just thinking out loud of what it means to engage
respectfully in a public, anonymous space.  I believe you approach in a
similar vein, which I appreciate.

The problem with your above suggestion is that it leaves out the default
case:
How will you write emails to the list?  Will you assume a default "he"?
Or a default "she"?  And what about non-binary identifying people?   We
don't know who's sitting at the other end.

Also, in the context of a default "he" usage (which you may not do, you
mentioned in the past that you sometimes default to "she"), I'm
concerned that emails are archived: they become a written representation
of what our community is like — and I do not want our community to
reinforce in a written form, that "only boys hang out around Guix / are
geeks".

>  Alternatively it would be incumbent on you to provide an
>  alternative that is not just "I will bloody-mindedly stick to
>  gendering people when I don't know anything about them".
>
> It is this tendency to call any difference of opinion by terms such as
> "bloody-minded" which offends me  - I try not to take offence - but I find
> hard not to.  I'm sorry.

My intention was to call-back to my impression of other parts of this
conversation where it seemed you were point-blank refusing to
acknowledge ng0's request.

But I can accept that you may find that an unfair characterisation, and
I phrased my sentiment too sharply in this case. My apologies for this.

> To answer your question:  How about saying "he or she" or "the person".

As mentioned above, the first renders non-binary identifying people
invisible.  For the second, if you can write a section of a manual using
"the person" in such a way that it won't sound clumsy, then by all
means.

Personally I would still suggest that "they/them/their" is wonderfully
short, to the point and unambiguous.  Also, it's a wheel that was
already invented: it has widespread usage outside of our community.

>  In the formal context, well??? I think there is broad consensus that
>  "singular they" is awesome.
>
> There is a broad concensus that Donald Trump, Rodrigo Duterte and
> Recep Erdogan are awesome.However I do not agree.

Say whaat?  Way to blow our discussion out of proportion.  Are you
seriously suggesting the consensus established through conversation and
convention in a small community is in any way comparable to the pile of
dung that is the contemporary ridiculously complex and terrifyingly
non-egalitarian state of global authoritarian politics?

>  > People having been talking about being "welcoming".  Well, I beleive 
> the way
>  > to achieve that is threefold:
>  >
>  > 1. Try not to offend.
>  > 2. Try not to be offended.
>  > 3. Recognise that diversity is an asset.
>
>  Absolutely, wonderful sentiment.  To that I would add:
>
>  4. Respect the integrity and right to self-definition of all participants
>
> I agree.  Put that one in too.

Nice :-)

>From my perspective, I'm probably done with this conversation for now,
though will respond if specific queries are addressed at me.

Alex

Re: Being excellent to one another

[Catonano]

2017-03-20 11:44 GMT+01:00 John Darrington :

>
> There is a broad concensus that Donald Trump, Rodrigo Duterte and
> Recep Erdogan are awesome.However I do not agree.
>

It seems to me that, on some issues you perfectly agree with those three.

Re: 01/02: gnu: Add itpp.

[Alex Kost]

John Darrington (2017-03-20 07:38 +0100) wrote:

> On Mon, Mar 20, 2017 at 02:18:39AM -0400, Leo Famulari wrote:
>  On Mon, Mar 20, 2017 at 07:03:03AM +0100, John Darrington wrote:
>  >  > +(source (origin
>  >  > +  (method url-fetch)
>  >  > +  (uri (string-append 
> "mirror://sourceforge/itpp/itpp/"
>  >  > +  version "/itpp-"
>  >  > +  version ".tar.gz"))
>  >  > +   (sha256
>  >  > +(base32
>  >  > + 
> "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"
>
>  (sha256) should be indented from (origin).
>
> Ahh. You are right (of course).  Emacs must have missed that one - perhaps 
> it'll
> do a better job now I have the plugin installed.

You don't need any additional "plugins" for this, as Emacs couldn't miss
it!

To check it, run "emacs -Q", paste this:

(source (origin
  (method url-fetch)
  (uri (string-append "mirror://sourceforge/itpp/itpp/"
  version "/itpp-"
  version ".tar.gz"))
  (sha256
(base32
 "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"

to some buffer, run "M-x scheme-mode" there, move the point to the
beginning of this sexp and press "C-M-q" ("indent-sexp" command).  And
you'll see that (sha256) is at the same column as (origin).

-- 
Alex

Re: 01/01: gnu: Add niftilib.

[Alex Kost]

Kei Kebreau (2017-03-19 17:03 -0400) wrote:

> This is interesting. Which module contains the definition for the
> 'every' procedure?

(srfi srfi-1)

You can read the documentation for 'every' in the Guile manual:
(info "(guile) SRFI-1 Searching")

-- 
Alex

Re: Should synopsis handle texinfo markup?

[Alex Kost]

Ludovic Courtès (2017-03-16 23:29 +0100) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2017-03-15 17:14 +0100) wrote:
>>
>>> Alex Kost  skribis:
>>>
 Hello, I've noticed that several packages contain "@code" structures in
 their synopses, but only 'description' field supports texinfo markup.
 For example, look at:

   guix package -s ruby-minitest-bonus-assertions

 So I wonder, should these synopses be adjusted to remove @code things,
 or would it be better to make sysnopses support it?
>>>
>>> Maybe we should support Texinfo in synopses after all.  I don’t think
>>> there were good reasons not to do it.
>>>
>>> Thoughts?
>>
>> I'm not aware of potential problems so I think it would be good to add
>> this support to synopses.
>
> Cool.  Would you or anyone like to give it a try?  Alternatively we can
> mail it to bug-guix for later.

I gave it a try (the patch is attached).  I hope I didn't miss anything.

>From 8d8a79d69619b68dd3a798e7456bfd871fcb8395 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Mon, 20 Mar 2017 13:41:41 +0300
Subject: [PATCH] ui: Support Texinfo markup in package synopses.

* guix/ui.scm (package-field-string): New procedure.
(package-description-string): Use it.
(package-synopsis-string): New procedure.
(package->recutils): Use it.
* guix/scripts/lint.scm (check-synopsis-style)[check-texinfo-markup]:
New procedure.  Use it in checks.
* gnu/packages/perl.scm (perl-try-tiny)[synopsis]: Adjust for the
Texinfo markup.
---
 gnu/packages/perl.scm |  2 +-
 guix/scripts/lint.scm | 22 +++---
 guix/ui.scm   | 17 +
 3 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 840e0b7..c415208 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -7580,7 +7580,7 @@ Tree::Simple::Visitor::* objects.")
  "068vdbpacfawc3lkfs0b82xxl27h3l0gj14iada3vlwk8rps9yv0"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/Try-Tiny;)
-(synopsis "Minimal try/catch with proper preservation of $@")
+(synopsis "Minimal try/catch with proper preservation of $@@")
 (description "This module provides bare bones try/catch/finally statements
 that are designed to minimize common mistakes with eval blocks, and nothing
 else.")
diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index 66c82f0..811f167 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015, 2016 Mathieu Lirzin 
 ;;; Copyright © 2016 Danny Milosavljevic 
 ;;; Copyright © 2016 Hartmut Goebel 
+;;; Copyright © 2017 Alex Kost 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -347,10 +348,25 @@ the synopsis")
 (_ "synopsis should not start with the package name")
 'synopsis)))
 
+  (define (check-texinfo-markup synopsis)
+"Check that SYNOPSIS can be parsed as a Texinfo fragment.  If the
+markup is valid return a plain-text version of SYNOPSIS, otherwise #f."
+(catch #t
+  (lambda () (texi->plain-text synopsis))
+  (lambda (keys . args)
+(emit-warning package
+  (_ "Texinfo markup in synopsis is invalid")
+  'synopsis)
+#f)))
+
   (define checks
-(list check-not-empty check-proper-start check-final-period
-  check-start-article check-start-with-package-name
-  check-synopsis-length))
+(list check-not-empty
+  check-proper-start
+  check-final-period
+  check-start-article
+  check-start-with-package-name
+  check-synopsis-length
+  check-texinfo-markup))
 
   (match (package-synopsis package)
 ((? string? synopsis)
diff --git a/guix/ui.scm b/guix/ui.scm
index 3a0a650..345bf49 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -4,7 +4,7 @@
 ;;; Copyright © 2013 Nikita Karetnikov 
 ;;; Copyright © 2014 Cyril Roelandt 
 ;;; Copyright © 2014 Cyrill Schenkel 
-;;; Copyright © 2014, 2015 Alex Kost 
+;;; Copyright © 2014, 2015, 2017 Alex Kost 
 ;;; Copyright © 2015 David Thompson 
 ;;; Copyright © 2015, 2016 Mathieu Lirzin 
 ;;; Copyright © 2016 Roel Janssen 
@@ -81,6 +81,7 @@
 fill-paragraph
 texi->plain-text
 package-description-string
+package-synopsis-string
 string->recutils
 package->recutils
 package-specification->name+version+output
@@ -848,10 +849,18 @@ converted to a space; sequences of more than one line break are preserved."
   (with-fluids ((%default-port-encoding "UTF-8"))
 (stexi->plain-text (texi-fragment->stexi str
 
+(define 

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 11:17:28AM +0100, Alex Sassmannshausen wrote:

 Perhaps we have to agree to disagree on singular they, but I hope we can
 still agree on the following statements from my earlier email:
 
I agree to a slightly edited version:

 -
 [...] sometimes there is not a simple solution, however :
 - if you know someone has a preference for particular pronouns, use those 
when
   refering to that person.
 - don't use pronouns when *you know* the other person does not identify
   with them.
 - if unsure, ask the person how he or she would like to be referenced.
 
 If you make a mistake, an apology will show your intention was not 
malicious.
 
 In manuals we can just use "singular they",  or another non-gender specific
 form of reference.
 -

 
 Alternatively it would be incumbent on you to provide an
 alternative that is not just "I will bloody-mindedly stick to
 gendering people when I don't know anything about them".

It is this tendency to call any difference of opinion by terms such as 
"bloody-minded" which offends me  - I try not to take offence - but I find
hard not to.  I'm sorry.

To answer your question:  How about saying "he or she" or "the person".  

 In the formal context, well??? I think there is broad consensus that
 "singular they" is awesome.

There is a broad concensus that Donald Trump, Rodrigo Duterte and 
Recep Erdogan are awesome.However I do not agree.

 > People having been talking about being "welcoming".  Well, I beleive the 
way
 > to achieve that is threefold:
 >
 > 1. Try not to offend.
 > 2. Try not to be offended.
 > 3. Recognise that diversity is an asset.
 
 Absolutely, wonderful sentiment.  To that I would add:
 
 4. Respect the integrity and right to self-definition of all participants

I agree.  Put that one in too.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Mon, Mar 20, 2017 at 09:57:04AM +0100, Alex Sassmannshausen wrote:
>  >
>  > ... and yes.  If an individual specifically requests to be referred to 
> by
>  > a partcular set of pronouns I will attempt to do so, but may 
> occasionally
>  > forget if that person wants feminine pronouns and is 6'4" and has an 
> enormous
>  > black wiry beard.
>  
>  [I really don't know what your intention is with that last paragraph ??? 
> I
>  will just ignore it, as I wouldn't want to ascribe malice???]
>
> OMG! What is wrong here?  Why would you (or anyone) think this is malicious?  
> The 
> intention, which I thought was clear, is that if people make unusual requests
> we should try to accommodate those requests, but the requestor should not be
> suprised or offended if people don't always remember.  Surely that was 
> obvious?

Not obvious at all, thanks for the clarification.

> [...]
>
> Regarding your other comments,  as we have discussed before, we will have to
> agree to disagree about singular they.   I have not the benefit of ever 
> having learned English as a foreign language.  But I do remember in my 
> elementary
> school being taught NOT to use it *especially* not in written text.  And - 
> perhaps because of this early tuition - it still sounds clumsy and confusing 
> to 
> me.

Perhaps we have to agree to disagree on singular they, but I hope we can
still agree on the following statements from my earlier email:

-
[...] it's super easy:
- if you're not sure (or have forgotten), use "singular they", or ask
- if you know someone has a preference for pronouns, use those
- don't use pronouns when *you know* the other person does not identify
  with them.

If you make a mistake, no-one will tear your head off — it may well feel
like an awkward social faux pas to you, but, c'est la vie! And an
apology will show your intention was not malicious.

In manuals we can just use "singular they", because it is a well
established convention and does not cause confusion.
-

I think if you agree with the sentiment, but dislike singular they as
the "general fall-back" then the above approach provides an inherent
method for you not to have to use that ("just ask") in the informal
context.

Alternatively it would be incumbent on you to provide an
alternative that is not just "I will bloody-mindedly stick to
gendering people when I don't know anything about them".

In the formal context, well… I think there is broad consensus that
"singular they" is awesome.

> People having been talking about being "welcoming".  Well, I beleive the way
> to achieve that is threefold:
>
> 1. Try not to offend.
> 2. Try not to be offended.
> 3. Recognise that diversity is an asset.

Absolutely, wonderful sentiment.  To that I would add:

4. Respect the integrity and right to self-definition of all participants

Ta,

Alex

Re: Being excellent to one another

[John Darrington]

On Mon, Mar 20, 2017 at 09:57:04AM +0100, Alex Sassmannshausen wrote:
 >
 > ... and yes.  If an individual specifically requests to be referred to by
 > a partcular set of pronouns I will attempt to do so, but may occasionally
 > forget if that person wants feminine pronouns and is 6'4" and has an 
enormous
 > black wiry beard.
 
 [I really don't know what your intention is with that last paragraph ??? I
 will just ignore it, as I wouldn't want to ascribe malice???]

OMG! What is wrong here?  Why would you (or anyone) think this is malicious?  
The 
intention, which I thought was clear, is that if people make unusual requests
we should try to accommodate those requests, but the requestor should not be
suprised or offended if people don't always remember.  Surely that was obvious?

It is the same with the Linux vs. GNU/Linux thing.   When speaking for GNU, I
request people to say GNU/Linux when talking about the operating system.  
However,
I recognise that some people have been exposed to "Linux" for a long time, and
it is hard to break the habit of a lifetime instantly.   Therefore, I don't jump
on someone saying "Gotcha" if they once forget.  I will however give them a
polite and gentle reminder.

Regarding your other comments,  as we have discussed before, we will have to
agree to disagree about singular they.   I have not the benefit of ever 
having learned English as a foreign language.  But I do remember in my 
elementary
school being taught NOT to use it *especially* not in written text.  And - 
perhaps because of this early tuition - it still sounds clumsy and confusing to 
me.

People having been talking about being "welcoming".  Well, I beleive the way
to achieve that is threefold:

1. Try not to offend.
2. Try not to be offended.
3. Recognise that diversity is an asset.


J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
>  On Sun, 19 Mar 2017 17:40:27 -0500
>  Christopher Allan Webber  wrote:
>  > The important thing is to not assume someone's preferred pronouns
>  > without knowing them.  Singular they isn't your only option; I also
>  > happen to like Spivak pronouns:
>  >
>  >   https://en.wikipedia.org/wiki/Spivak_pronoun
>
>  The problem here is that I'd be suprised if many people have even heard
>  about these. I used to play MUDs quite a bit and have /never/ heard any
>  of those. They are certainly not a part of common usage, and I'd say
>  should be avoided for something more standard (them et al). It's a nice
>  idea, but overall seems like it would cause confusion, and probably
>  more than a few "Hey, there is a typo in the manual"-type bugs than
>  anything.
>
>  At least, if I picked up a random bit of documentation and saw things
>  like "e" used constantly, I'd assume it was a typo and not some archaic
>  gender-neutral pronoun.
>
> [...]

> When writing texts, such as this email, and absolutely  *have* to use a 
> personal
> definite pronoun, I default to "she" because whereas vigilantes will pounce 
> upon
> you whenever they see "he" (ironically those people are invariably male), I've
> never had anyone complain when "she" occurs where the gender of the subject
> might well be masculine.
>
>
> ... and yes.  If an individual specifically requests to be referred to by
> a partcular set of pronouns I will attempt to do so, but may occasionally
> forget if that person wants feminine pronouns and is 6'4" and has an enormous
> black wiry beard.

[I really don't know what your intention is with that last paragraph — I
will just ignore it, as I wouldn't want to ascribe malice…]

John, really, it's super easy:
- if you're not sure (or have forgotten), use "singular they", or ask
- if you know someone has a preference for pronouns, use those
- don't use pronouns when *you know* the other person does not identify
  with them.

If you make a mistake, no-one will tear your head off — it may well feel
like an awkward social faux pas to you, but, c'est la vie! And an
apology will show your intention was not malicious.

In manuals we can just use "singular they", because it is a well
established convention and does not cause confusion.

Someone who's learning English as a second language would hopefully have
been exposed to "singular they" in their class.  If not, they should ask
for their money back.

Regardless, it would be great for our manual to introduce them to
this lovely convention that is so widely used.

Cheers,

Alex

Re: Introducing ‘guix pack’

[Federico Beffa]

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

> Hi Federico,
>
> Federico Beffa  skribis:
>
>> Say, developer A distributes such an archive A and developer B
>> distributes archive B (a different program/library) and someone C
>> installs both.
>
> Interestingly composability (what happens when you unpack both A and B
> on the same system) is better than what you’d get with Docker: the
> unpacked items that are identical are shared, and those parts that
> differ don’t collide.

Packs share identical items, but it becomes essentially impossible to
remove one component out of many.

>> Now developer A fixes a security hole and produces a new archive.  How
>> can C remove the library with the security hole from his system?  If he
>> just overlays the new version, the library with the security problem
>> stays on the system and could be exploited.  Deleting everything is also
>> less than ideal.
>>
>> This seems to me similar to encouraging the much criticized practice of
>> bundling required libraries with your program.
>>
>> Maybe 'pack' could at least include a 'remove-myself' thing.  Or have
>> you thought about the hole program life-cycle?
>
> Good question.  There’s a fine line here.  In Guix circles we’re very
> good at explaining why “app bundles” are a bad thing (composability- and
> security-wise notably), and here that’s precisely what we’re producing.
>
> The intended use case is mostly “one-off” packs where you just want
> people to easily test something, as opposed to putting it in
> production.  This was the case for the Guile 2.2.0 release.  In those
> cases, people would essentially “rm -rf /gnu” when they’re done.

If you provide an archive such as
'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main
project page (especially without any warning about its intended
purpose), I bet that many peoples will install it and keep it.  If more
projects follow this example, we land to the above scenario where "rm
-rf /gnu" is not practical at all.

> For code that is meant to be kept over time, I would recommend to either
> use Guix, or to include Guix in the pack so that people can eventually
> upgrade.

This is clear to me, but there are many peoples who do not know about
Guix, or just don't want it.  They may still be interested in, say,
Guile 2.2.

With the 'pack' command it seems to me that Guix is being promoted as a
convenient development environment where at the end you can produce
binary bundles for distribution on any system that it supports.  But,
without providing at least a way to remove things, it seems to be
heading toward a dangerous direction.

Fede

Re: 01/02: gnu: Add itpp.

[John Darrington]

On Mon, Mar 20, 2017 at 02:18:39AM -0400, Leo Famulari wrote:
 On Mon, Mar 20, 2017 at 07:03:03AM +0100, John Darrington wrote:
 >  > +(source (origin
 >  > +  (method url-fetch)
 >  > +  (uri (string-append 
"mirror://sourceforge/itpp/itpp/"
 >  > +  version "/itpp-"
 >  > +  version ".tar.gz"))
 >  > +   (sha256
 >  > +(base32
 >  > + 
"14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"
 
 (sha256) should be indented from (origin).

Ahh. You are right (of course).  Emacs must have missed that one - perhaps it'll
do a better job now I have the plugin installed.

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: 01/02: gnu: Add itpp.

[Leo Famulari]

On Mon, Mar 20, 2017 at 07:03:03AM +0100, John Darrington wrote:
>  > +(source (origin
>  > +  (method url-fetch)
>  > +  (uri (string-append "mirror://sourceforge/itpp/itpp/"
>  > +  version "/itpp-"
>  > +  version ".tar.gz"))
>  > +   (sha256
>  > +(base32
>  > + "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"

(sha256) should be indented from (origin).


signature.asc
Description: PGP signature