Re: 2 ideas

[Chris Marusich]

Nils Gillmann  writes:

> swedebugia transcribed 2.8K bytes:
>> 
>> In Arch there is a post-install hook that enables informing the user of 
>> additional steps needed to actually use the software as intended. 
>> 
>> I find that useful. Is there a guix alternative? 
>
> I think we discussed something similar briefly.

This sort of feature would be useful.  But I don't think anybody has
worked on implementing it yet.  Which means that it's fair game for
anyone to work on!  :-)

-- 
Chris


signature.asc
Description: PGP signature

Re: my latest blog post

[Catonano]

2018-06-10 2:51 GMT+02:00 Mark H Weaver :

> myg...@gmail.com writes:
>



>
> Are there any other acceptable responses, in your view?
>

I already proposed a way forward and I even asked you if you would refuse
to merge it

I see you attitute towards that, now.

Also:

yesterday night, before going to bed, I tought that you were nt answering
because you were "busy"

Maybe you were in a different time zone

the lack of an answer is not necessarily aggresion, someone of you noted

But then, when someone agrees with me, you reply instantly, with the usual
pathetic superiority and smugness

There, you have the Guile utter failure

You are a asshole, Mark

Regards

Re: my latest blog post

[Catonano]

2018-06-10 0:49 GMT+02:00 :

> On 06/07/2018 at 17:25 Catonano writes:
>
> > I just published my latest blog post
> >
> > In this post I discuss Guix
> >
> > And I discuss Guile too
> >
> > I understand that the language is strong and I expect someone to be upset
> >
> > But I feel this is due
> >
> > Happy reading
> >
> > http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Hi Catonano,
>
> Thank you for taking the time to contribute your thoughts. I am sorry to
> see you getting so beat up by the responses.  Unfortunately the
> nit-picking of criticisms and the "we are busy, why don't you dig in and
> fix it" responses occur too often on the Guix lists.
>
> Such responses are fundamentally unhelpful: A defensive response of
> counter-criticism that spirals out of control buries the original input
> and alienates potential new contributors. I agree with you that the
> suggestion that you dig in and fix something you are struggling with is
> a fundamentally unfriendly response.
>
> I appreciate the effort you made to learn Guix and the risk you took to
> report on the problems you experienced. I am interested in getting to
> the root causes of your frustration. I re-read your post and
> emails. Would it be fair to say ...
>
> 1) The monad/daemon/store is presented as central to Guix and is very
> difficult to understand. If a Guix user really needs to understand it,
> it needs to be explained better.
>
> 2) Sending Guix users upstream for Guile support is not working.
>
> If these are correct, the reality is that only a few people on the
> planet are in a position to address these issues. The rest of us have to
> hope that they can see why it is important to stop coding long enough to
> do so, perhaps in collaboration with a confused user or two ;-)
>
> - George
>

Thank you George, I appreciate this

I alredy had 2 people writing to me _in private_ acknowledging my efforts

I invited them to "come out" but they didn't

So much for Guile friendliness

People are scared to speak their minds

Now, don't worry I won't revelate who you are

I just want to record the sorry state of this community

Re: my latest blog post [everyone, please take a cooldown break]

[Nils Gillmann]

Hi,

I think it would be best if everyone involved would cool down for a couple of
days, restructure their thoughts and reflect on this thread. Look at what
they are doing, and at how they are reacting to other peoples reaction.
This topic is getting quiet heated, and other than the maintainers we
do not have established some kind of mderation. It can be hard to discuss
some topics online.
Text can sometimes fail to transport what we attampt to express, and
I have seen people step away from projects because of this.

Re: my latest blog post

[Catonano]

2018-06-10 8:55 GMT+02:00 Pjotr Prins :

> On Sat, Jun 09, 2018 at 08:51:59PM -0400, Mark H Weaver wrote:
> > myg...@gmail.com writes:
> > > Thank you for taking the time to contribute your thoughts. I am sorry
> to
> > > see you getting so beat up by the responses.  Unfortunately the
> > > nit-picking of criticisms and the "we are busy, why don't you dig in
> and
> > > fix it" responses occur too often on the Guix lists.
> > >
> > > Such responses are fundamentally unhelpful: A defensive response of
> > > counter-criticism that spirals out of control buries the original input
> > > and alienates potential new contributors. I agree with you that the
> > > suggestion that you dig in and fix something you are struggling with is
> > > a fundamentally unfriendly response.
> >
> > What kind of response would you consider acceptable?
> >
> > I suppose the most helpful response would be for one of us to volunteer
> > our time to fix the bug, or to implement the feature you desire.
> >
> > Are there any other acceptable responses, in your view?
> >
> >Mark
>
> And here we arrive at a fundamental problem that all *complex* free
> software projects that have with many users. And these discussions end
> up hurting/upsetting everyone involved!
>
> The fact is that only a few people really understand any chosen part
> of the project.
>
> And these people tend to have day jobs, families and work on the
> project in their spare time. In that spare time (maybe only a few
> hours a week) they make choices what to work on - and, yes, it tends
> to be what they think most important. Not what others think most
> important. The Clojure developers are considered haughty and give
> others the cold shoulder.  The Dlang people are very open, and get a
> lot of abuse and kranks on their forum in return. You just can't win!!
> It is easy to find examples about this. Some projects, notably Elixir,
> are exceptionally good at the balancing act. But, it is not for
> everyone. If you take Guile, what started this thread, it is really
> one core language maintainer. What talent! Nothing to stop you from
> jumping in...
>
> I think Guix is a great project. Not only does it scale (ref.
> the number of weekly contributors), the maintainers do a good job of
> being nice where it matters. Guix had a community day at FOSDEM and out
> of that came the recent work on 'guix pull' which is a great
> improvement, ultimately asked for by the user community! I think that
> is amazingly good.
>
> Mark, indeed, from a contributor perspective the natural response is
> to volunteer work on a topic users ask for. Since we write code, we
> think in terms of responding in code. But that is not what this thread
> is about. Here we have users who want *attention* for their
> concern(s).


Ok. So ... ?


> My response to such users is two-fold: (1) dig in and prove
> you understand the issue first. A lot of response goes by merit you
> acquire. People tend to spend time on people they like/respect. So,
> George, it is not a knee-jerk reaction. It is easy to talk, much less
> easy to do. And coders and project maintainers know that. And (2)
> bring up real issues on the bug tracker and try to fix them. That way
> you get attention.
>
> So, yes, dig in and try to fix it ;)
>

Ah, I see

So: nothing.

Pjotr I ALREADY offered a contribution

The manual discusses some internal APIs in a paragraph about something else

That's unrespectful of reader's time

I proposed some edits

I keep reading, all around, that also not coding contributions are valuable

Are they ?

I also argued that macros are a part of scheme but the debugging
infrastructure doesn't cover them, at all

But of course, this is "talking", maybe I'm too entitled



> As in chess or football, people who acquire merit get taken seriously.
> Not the person shouting on the side-line - unless they are respected
> in some other way (maybe by giving money or other resources).
>

I'm glad I'm flushing out, people

You are expressing all your jerkiness in all its glory :-)



> Talk is cheap. Coding is hard.


Thinking is even harder


We are always balancing this. I don't
> contribute much to Guix at this point (other than talk ;), but we face
> the exact same problems in other projects I am involved in. I get most
> upset by the sense of entitlement that people have just because they
> *use* my  work. Many an E-mail I wrote, but did not send, to users,
> just to vent steam. I have a feeling I am not the only one. I.e., it
> is not easy running a free software project. We want and like our
> users, but not at all cost.
>

All costs ?

I repeat: the manual sucks and I proposed an edit to make it suck a bit less


I think we should close this topic unless there are concrete
> suggestions on how to improve and scale Guix development. As George
> writes, we can encourage new contributors and users more,


like you're doing with me ?


> but I doubt
> the route is to take core contributors away from their

Re: my latest blog post

[Ricardo Wurmus]

Catonano,

this language is not at all acceptable anywhere on Guix as you can see
by referencing the Code of Conduct.

--8<---cut here---start->8---
Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others’ private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
--8<---cut here---end--->8---

It is one thing to call for a more welcoming community and quite another
to call people names and to assert that they act in bad faith as you
have been doing in the past days.  Please stop right now.

I encourage all to re-read the Code of Conduct.  You can find it in the
Guix git repository or online here:

http://git.savannah.nongnu.org/cgit/guix.git/plain/CODE-OF-CONDUCT

--
Ricardo

Re: my latest blog post

[Catonano]

2018-06-10 11:26 GMT+02:00 Ricardo Wurmus :

>
> Catonano,
>
> this language is not at all acceptable anywhere on Guix as you can see
> by referencing the Code of Conduct.
>
> --8<---cut here---start->8---
> Examples of unacceptable behavior by participants include:
>
> * The use of sexualized language or imagery and unwelcome sexual attention
> or
> advances
> * Trolling, insulting/derogatory comments, and personal or political
> attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> address, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
> --8<---cut here---end--->8---
>
> It is one thing to call for a more welcoming community and quite another
> to call people names and to assert that they act in bad faith as you
> have been doing in the past days.  Please stop right now.
>
> I encourage all to re-read the Code of Conduct.  You can find it in the
> Guix git repository or online here:
>
> http://git.savannah.nongnu.org/cgit/guix.git/plain/CODE-OF-CONDUCT
>
> --
> Ricardo
>


you chose to enfforce only some violations, not all of them

I am not surpried at all

Re: my latest blog post

[Ricardo Wurmus]

Catonano  writes:

> They made a conduct report but nothing happened, eventually they had to
> talk to Ludo directly

>From the Code of Conduct:

   Instances of abusive, harassing, or otherwise unacceptable behavior
   may be reported by contacting the project team at
   guix-maintain...@gnu.org. All complaints will be reviewed and
   investigated and will result in a response that is deemed necessary
   and appropriate to the circumstances.

Reports made to the maintainers (i.e. Ludovic and myself) are taken
seriously.

--
Ricardo

Re: my latest blog post

[Catonano]

2018-06-10 11:29 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > They made a conduct report but nothing happened, eventually they had to
> > talk to Ludo directly
>
> From the Code of Conduct:
>
>Instances of abusive, harassing, or otherwise unacceptable behavior
>may be reported by contacting the project team at
>guix-maintain...@gnu.org. All complaints will be reviewed and
>investigated and will result in a response that is deemed necessary
>and appropriate to the circumstances.
>
> Reports made to the maintainers (i.e. Ludovic and myself) are taken
> seriously.
>
> --
> Ricardo
>
>

I reported the assault David Pirotte made to me

it was not taken seriously

Re: 2 ideas

[Pierre Neidhardt]

Then intention of the Arch post-install script is good (that is,
informing the user) but I find the implementation brittle: if the
messages are too many or too long, it can be very easy to miss a
message.

Furthermore, the script cannot be triggered out-of-install, which means
that once the shell session is gone, the information is gone.  (It's
still in the log but it's not so convenient to read and you must know
what you are looking for in advance.)

--
Pierre Neidhardt


signature.asc
Description: PGP signature

[shepherd] herd status suggestion

[Nils Gillmann]

Hi,

right now we have this view:

abyayala$ sudo herd status tor
Status of tor:
  It is stopped.
  It is disabled.
  Provides (tor).
  Requires (user-processes loopback syslogd).
  Conflicts with ().
  Will be respawned.
  Last respawned on Sun Jun 10 08:08:45Z 2018.


Would it be an option to change the status output to,
if it conflicts with no other service:

  Conflicts with no other services.

instead of the representation of an empty list?

Re: my latest blog post

[Ricardo Wurmus]

Catonano  writes:

> 2018-06-10 11:29 GMT+02:00 Ricardo Wurmus :
>
>>
>> Catonano  writes:
>>
>> > They made a conduct report but nothing happened, eventually they had to
>> > talk to Ludo directly
>>
>> From the Code of Conduct:
>>
>>Instances of abusive, harassing, or otherwise unacceptable behavior
>>may be reported by contacting the project team at
>>guix-maintain...@gnu.org. All complaints will be reviewed and
>>investigated and will result in a response that is deemed necessary
>>and appropriate to the circumstances.
>>
>> Reports made to the maintainers (i.e. Ludovic and myself) are taken
>> seriously.
[…]
>
> I reported the assault David Pirotte made to me
>
> it was not taken seriously

For the record:

1. I am not a maintainer of Guile
2. Ludovic and I are co-maintainers of Guix
3. Reports of Guix Code of Conduct violations should be made to the Guix
   maintainers.
4. I have not received a report about David Pirotte from you.  In fact,
   I have not received any report from you.

--
Ricardo

Re: my latest blog post

[Mark H Weaver]

Catonano  writes:

> By the way, a third person wrote me in private right now telling that
> Mark was an asshole to them too and they stopped contributing to guix
> altogether
>
> They made a conduct report but nothing happened, eventually they had
> to talk to Ludo directly

If you're accusing me of misconduct, please state your case.

  Mark

Re: my latest blog post

[Mark H Weaver]

Catonano  writes:

> Now, please, tell me: is it worth that I edit the manual to include in
> a reasonable way the notions that you provided my with about macro
> stepping ?
>
> Or would you refuse to merge it ?

My position is that the manual is not an appropriate place to document
wishlist items for our TODO list, which is what this is.  So no, I would
not merge it into our manual.

However, I agree with you that a macro stepper would be a very useful
thing to have, to help people to debug and understand macro libraries.
I believe that the appropriate place for this is as a ticket in our bug
tracking system.  That is our preferred way to keep track of unsolved
bugs and TODO list items.

I would encourage you to file a ticket by sending an email to
bug-gu...@gnu.org with all of the relevant information.

I would also ask that you consider the possibility that I am
not your enemy.

   Mark

Re: 2 ideas

[Thorsten Wilms]

On 10.06.2018 11:54, Pierre Neidhardt wrote:

Then intention of the Arch post-install script is good (that is,
informing the user) but I find the implementation brittle: if the
messages are too many or too long, it can be very easy to miss a
message.

Furthermore, the script cannot be triggered out-of-install, which means
that once the shell session is gone, the information is gone.  (It's
still in the log but it's not so convenient to read and you must know
what you are looking for in advance.)



What if each package with such a message would install it as a text-file 
in a specific directory? With a separate mechanism to bring each new 
message file to the user's attention, plus a means of stepping through 
all of them.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: [shepherd] herd status suggestion

[Ricardo Wurmus]

Hi Nils,

> abyayala$ sudo herd status tor
> Status of tor:
>   It is stopped.
>   It is disabled.
>   Provides (tor).
>   Requires (user-processes loopback syslogd).
>   Conflicts with ().
>   Will be respawned.
>   Last respawned on Sun Jun 10 08:08:45Z 2018.
>
>
> Would it be an option to change the status output to,
> if it conflicts with no other service:
>
>   Conflicts with no other services.
>
> instead of the representation of an empty list?

This sounds like a good idea.  The only argument in favour of keeping it
the way it is now is too weak to take serious: it makes it slightly
easier to parse the output of “herd status”.

Could you please prepare a patch to change the output?  It’s also worth
checking how gettext is used in shepherd (I don’t know more than that it
uses “l10n” as a “gettext” alias) to make sure that the string can be
translated.

Thanks for this proposal!

--
Ricardo

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Ricardo Wurmus]

Hi Nils,

> I think we discussed something similar briefly. Or at least package
> attached metadata which ends up in a '/guix' folder of the output.
> I've been following (not yet implementing) a similar idea, where
> such messages are either local mail and/or end up in a (mapped to guix:)
> '/guix/doc/' folder, where files are named like 
> $applicationname-$version.number.NAME.note
> where '.note' is just a basic txt file.
> These notes could contain messages specific to the OS, the architecture, 
> general
> advice, etc.
>
> Not really well thought through yet, but that's a start.
>
> Think of it not as description or synopsis part, but rather let's say
> (in theory):
> (note "STRING") or (note (list "NOTE 1"
>"NOTE 2")).

This is not a bad idea, in my opinion.  It could be useful to have
application-specific setup notes in a well-known location that is
gathered when the profile is built.

I would not like these notes to be printed automatically upon
installation, but generating a file with important notes seems like a
good idea in general.

--
Ricardo

Re: 2 ideas

[Gábor Boskovits]

2018-06-10 13:26 GMT+02:00 Thorsten Wilms :

> On 10.06.2018 11:54, Pierre Neidhardt wrote:
>
>> Then intention of the Arch post-install script is good (that is,
>> informing the user) but I find the implementation brittle: if the
>> messages are too many or too long, it can be very easy to miss a
>> message.
>>
>> Furthermore, the script cannot be triggered out-of-install, which means
>> that once the shell session is gone, the information is gone.  (It's
>> still in the log but it's not so convenient to read and you must know
>> what you are looking for in advance.)
>>
>
>
> What if each package with such a message would install it as a text-file
> in a specific directory? With a separate mechanism to bring each new
> message file to the user's attention, plus a means of stepping through all
> of them.
>
>
>
I think it might be nice to have something like --show-post-install-doc in
guix package, if we decide to implement this.++


> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>

Re: my latest blog post

[Pjotr Prins]

On Sun, Jun 10, 2018 at 11:07:21AM +0200, Catonano wrote:
>I'm glad I'm flushing out, people
>You are expressing all your jerkiness in all its glory :-)

It is obvious by now that this person is trolling. Is there any reason
to listen to them?

Pj.

Re: my latest blog post

[Ricardo Wurmus]

Catonano  writes:

>> Andy’s time is still limited.  What other people can do is discuss
>> *specific* cases on guile-devel and work towards a solution.  But please
>> do not demand of others to explain everything in detail.  (I’m directing
>> this at everyone who heeds my advice to go to guile-devel, not at any
>> one person in particular.)  In order to have a positive impact you also
>> need to learn enough about the state of the art to ensure that the
>> discussions can be productive.
>>
>
> I think I demonstrated I am ready to put some effort into this
>
> And I think this remark is unfair

I wrote this:

   But please do not demand of others to explain everything in detail.
   (I’m directing this at everyone who heeds my advice to go to
   guile-devel, not at any one person in particular.)

Rephrasing: I’d like to point this out to people who take this
opportunity to bemoan the lack of other features or who disagree with
what they think are different priorities.  You do not feel addressed if
you know you’ve made efforts in this area.

> And saying I should come on guile-dev and actually provide what I thin is
> useful, nowing that I can't (not immediately is not a fair answer either
>
> Because it's equivalent to a "fuck you"

Wow.  No.

I think that’s an *extremely* uncharitable reading of what I wrote.  I
will refrain from further comments in this thread lest what I write will
be misconstrued in a similar fashion.

>> With regards to the shouting match on #guile that you linked in your
>> blog post, I can only say that I would have likely stepped in had this
>> happened when I was around.  Textual communication certainly should not
>> reach these levels of apparent aggression.
>>
>
> What do you mean with "apparent" ?

I’m pretty bad at gauging emotion in textual communication and it’s
generally not easy to infer the intended tone in short text messages.
That said, the exchange you linked to appeared to me to be of an
aggressive nature.  That’s what I mean by “apparent”.

--
Ricardo

Re: my latest blog post [everyone, please take a cooldown break]

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Hi,
>
> I think it would be best if everyone involved would cool down for a couple of
> days, restructure their thoughts and reflect on this thread. Look at what
> they are doing, and at how they are reacting to other peoples reaction.
> This topic is getting quiet heated, and other than the maintainers we
> do not have established some kind of mderation. It can be hard to discuss
> some topics online.
> Text can sometimes fail to transport what we attampt to express, and
> I have seen people step away from projects because of this.

+1000

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[swedebugia]

Hi Ricardo 

On June 10, 2018 1:35:00 PM GMT+02:00, Ricardo Wurmus  
wrote:
>
>Hi Nils,
>
>> I think we discussed something similar briefly. Or at least package
>> attached metadata which ends up in a '/guix' folder of the output.
>> I've been following (not yet implementing) a similar idea, where
>> such messages are either local mail and/or end up in a (mapped to
>guix:)
>> '/guix/doc/' folder, where files are named like
>$applicationname-$version.number.NAME.note
>> where '.note' is just a basic txt file.
>> These notes could contain messages specific to the OS, the
>architecture, general
>> advice, etc.
>>
>> Not really well thought through yet, but that's a start.
>>
>> Think of it not as description or synopsis part, but rather let's say
>> (in theory):
>> (note "STRING") or (note (list "NOTE 1"
>>"NOTE 2")).
>
>This is not a bad idea, in my opinion.  It could be useful to have
>application-specific setup notes in a well-known location that is
>gathered when the profile is built.
>
>I would not like these notes to be printed automatically upon
>installation, but generating a file with important notes seems like a
>good idea in general.

Would you agree to print a hint about these notes having been installed and how 
to access them easily?

Would this be a useful utility:

$giux notes
-> shows all notes relating to previously installed packages. 

And

$guix notes 
-> show notes related to a specific package whether it is installed or not. 
-- 
Cheers Swedebugia

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Nils Gillmann]

swedebugia transcribed 1.6K bytes:
> Hi Ricardo 
> 
> On June 10, 2018 1:35:00 PM GMT+02:00, Ricardo Wurmus  
> wrote:
> >
> >Hi Nils,
> >
> >> I think we discussed something similar briefly. Or at least package
> >> attached metadata which ends up in a '/guix' folder of the output.
> >> I've been following (not yet implementing) a similar idea, where
> >> such messages are either local mail and/or end up in a (mapped to
> >guix:)
> >> '/guix/doc/' folder, where files are named like
> >$applicationname-$version.number.NAME.note
> >> where '.note' is just a basic txt file.
> >> These notes could contain messages specific to the OS, the
> >architecture, general
> >> advice, etc.
> >>
> >> Not really well thought through yet, but that's a start.
> >>
> >> Think of it not as description or synopsis part, but rather let's say
> >> (in theory):
> >> (note "STRING") or (note (list "NOTE 1"
> >>"NOTE 2")).
> >
> >This is not a bad idea, in my opinion.  It could be useful to have
> >application-specific setup notes in a well-known location that is
> >gathered when the profile is built.
> >
> >I would not like these notes to be printed automatically upon
> >installation, but generating a file with important notes seems like a
> >good idea in general.
> 
> Would you agree to print a hint about these notes having been installed 

Not really, because in most cases you will not be able to catch all
notifications. My approach is to notify the user and/or root user with
a local email (after first install, first system generation install),
which then can include a note about the existence of these notes. This
draws a bit of inspiration from Gentoo and OpenBSD mail-on-first-use.

Unless you can think of an example for a non-interactive environments.
I think there's at least one, but what you describe is already an
extension to the basic idea, especially the tool below.
One could use that, but it's questionable since guix already has quiet
a large number of commands. It would be a good initial extension to the
idea, but no permanent solution.

Is it bad that guix has a large number of commands? I'm not sure. I'm
biased with spending too much time on minimal envivonments and ask
friends and random strangers opinions about these kinds of things to
form a less biased opinion.

> and how to access them easily?
> 
> Would this be a useful utility:
> 
> $giux notes
> -> shows all notes relating to previously installed packages. 
> 
> And
> 
> $guix notes 
> -> show notes related to a specific package whether it is installed or not. 
> -- 
> Cheers Swedebugia

Re: my latest blog post [everyone, please take a cooldown break]

[Gábor Boskovits]

+1

2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber :

> Nils Gillmann writes:
>
> > Hi,
> >
> > I think it would be best if everyone involved would cool down for a
> couple of
> > days, restructure their thoughts and reflect on this thread. Look at what
> > they are doing, and at how they are reacting to other peoples reaction.
> > This topic is getting quiet heated, and other than the maintainers we
> > do not have established some kind of mderation. It can be hard to discuss
> > some topics online.
> > Text can sometimes fail to transport what we attampt to express, and
> > I have seen people step away from projects because of this.
>
> +1000
>
>

Re: [shepherd] herd status suggestion

[Nils Gillmann]

Ricardo Wurmus transcribed 982 bytes:
> 
> Hi Nils,
> 
> > abyayala$ sudo herd status tor
> > Status of tor:
> >   It is stopped.
> >   It is disabled.
> >   Provides (tor).
> >   Requires (user-processes loopback syslogd).
> >   Conflicts with ().
> >   Will be respawned.
> >   Last respawned on Sun Jun 10 08:08:45Z 2018.
> >
> >
> > Would it be an option to change the status output to,
> > if it conflicts with no other service:
> >
> >   Conflicts with no other services.
> >
> > instead of the representation of an empty list?
> 
> This sounds like a good idea.  The only argument in favour of keeping it
> the way it is now is too weak to take serious: it makes it slightly
> easier to parse the output of “herd status”.
> 
> Could you please prepare a patch to change the output?  It’s also worth
> checking how gettext is used in shepherd (I don’t know more than that it
> uses “l10n” as a “gettext” alias) to make sure that the string can be
> translated.
> 
> Thanks for this proposal!
> 
> --
> Ricardo
> 
> 

Thanks!

I will look into this, I've looked at the file for the first time (ever? in a 
long time?) today.
If I can't figure out how to do all of it, I'll send further questions.



Related and similar: Would it be reasonable to change the output from 
list-style,
like:
  Depends on: (foo bar irks boot)

to the probably tiny bit better readable:

  Depends on: foo, bar, irks, boot

for humans?


I'm thinking that even though it is very obvious what we are looking at, we 
could almost entire sentences?
However, it's "interesting" to form sentences here without sounding like 
Captain Obvious...

Status of the service 'tor':
   It is stopped.
   It is disabled.
   Provides (tor).   <- 'tor' provides a service for running tor.(? I 
haven't looked at the shepherd and our use of it, so this is just assuming this 
is possible.)
   Requires (user-processes loopback syslogd).  <- 'tor' requires these 
services: uer-processes, loopback, syslogd.
   Conflicts with ().   <-  There are no conflicting 
services./Conflicts with no other services. (when empty)  | alternative, when 
at least 1 element:  'tor' conflicts with: element.
   Will be respawned.   <- Upon crash, tor will be respawned.
   Last respawned on Sun Jun 10 08:08:45Z 2018.


But it could be that his is too long for output, and maybe could even be 
reduced to the simple statements we have.

Is there any documented work besides the code and documentation on why shepherd 
produces this output, any
logical conclusions or...?

Re: my latest blog post [everyone, please take a cooldown break]

[Kei Kebreau]

Gábor Boskovits  writes:

> +1
>
> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber :
>
>  Nils Gillmann writes:
>
>  > Hi,
>  >
>  > I think it would be best if everyone involved would cool down for a couple 
> of
>  > days, restructure their thoughts and reflect on this thread. Look at what
>  > they are doing, and at how they are reacting to other peoples reaction.
>  > This topic is getting quiet heated, and other than the maintainers we
>  > do not have established some kind of mderation. It can be hard to discuss
>  > some topics online.
>  > Text can sometimes fail to transport what we attampt to express, and
>  > I have seen people step away from projects because of this.
>
>  +1000

+1


signature.asc
Description: PGP signature

GSoC - "Continuing re-write of daemon in Guile Scheme" update

[Sandeep Subramanian]

Hi all,

Everyone has noticed that I am kind of quiet on the
IRC channel. The reason for that, and the reason that
I haven't been sending updates is that my current
situation is not giving me enough time to work on
this project.

I know that I promised in the application that I will
give my best to this project. At that point in time, it
was true. Now, because of some personal/family
reasons, I am unable to honor this commitment. It
would be worse for both the community and me if I
kept dragging this on for longer. So, with great regret
and guilt, I wish to quit on this GSoC project.

I could do a shoddy job and stay on the project, but the
community deserves a better effort than that. The entire
community at Guix has been so great to me and I would
feel like I am exploiting that niceness for the stipend
and I do not wish to do so. I know I took the opportunity
away from someone who would have been more
committed and right now I can not do anything but
apologize for that.

I knew this project would be tough on me, due to my
lack of sufficient exposure to Scheme and due to the
complexities involved, but at the time of writing the
proposal I sincerely thought that I would be able to do
it with a commitment of 40 hours a week. I didn't intend
to deceive anyone. I tried really hard to put in more
hours but  the last week showed me that it was difficult.

However, this is not the last you will see of me. While
I might not be able to spend 40 hours a week as expected,
I will spend some time every week working on this project
because I like it and I hope to produce something of value
to the community.

I already sent out a personal mail to my mentors a few days
ago. I wanted to let the community know too.

Sorry,
uniq10

Re: GSoC - "Continuing re-write of daemon in Guile Scheme" update

[Pierre Neidhardt]

Hey Sandeep,

Thanks for letting us know and for being so transparent!

It's life, setbacks happen, but this should not push anyone to give up
on anything: I think you have the right attitude, keep going and doing
what you like, you will eventually meet greater successes in the future!

GuixSD is a fantastic projects and every bit of help is always welcome,
in whichever form they can be provided.

Good luck and see you around!
Cheers!

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Maintaining implementations of similar utility functions like json-fetch

[Jelle Licht]

Ludovic Courtès  writes:

> Hey,
>
> Jelle Licht  skribis:
>
>> I basically added the robust features of `json-fetch*' to the exported
>> `json-fetch'
>> instead, and all existing functionality seems to work out as far as I can
>> see.
>
> So are you saying that we can get rid of ‘json-fetch*’?
>
>> I did notice that I now produce hash-tables by default, and some of the
>> existing usages of `json-fetch*' expect an alist instead. What would be a
>> guile-
>> appropriate way of dealing with this? I currently have multiple
>> `(hash-table->alist (json-fetch <...>))' littered in my patch which seems
>> suboptimal,
>> but always converting the parsed json into an alist seems like it might
>> also not be
>> what we want.
>
> Why insist on having an alist?  Perhaps you can just stick to hash
> tables?   :-)
>
> Ludo’.

Hey hey,

Sorry for the delay. Cue the drum roll; Attached is my initial draft of
this patch. I initially wanted to split it up into 2 or more patches, but
could not make this work in a way that I could wrap my head around.

Also, there is yet another 'json-fetch'-like function implemented in
`guix/ci.scm', but I was not sure whether the error-handling facilities
would be applicable there.

Anyway, I am open to comments. I have verified that at least the
(tests of the) importers still work as they did before. After the
comments, I could push it myself if that is okay.
From c60686975df206118c3a26cc9c2cef2a93b2 Mon Sep 17 00:00:00 2001
From: Jelle Licht 
Date: Sun, 10 Jun 2018 20:35:39 +0200
Subject: [PATCH] import: json: Consolidate duplicate json-fetch functionality.

* guix/import/json.scm (json-fetch): Return a list or hash table.
  (json-fetch-alist): New procedure.
* guix/import/github.scm (json-fetch*): Remove.
  (latest-released-version): Use json-fetch.
* guix/import/cpan.scm (module->dist-name): Use json-fetch-alist.
  (cpan-fetch): Likewise.
* guix/import/crate.scm (crate-fetch): Likewise.
* guix/import/gem.scm (rubygems-fetch): Likewise.
* guix/import/pypi.scm (pypi-fetch): Likewise.
* guix/import/stackage.scm (stackage-lts-info-fetch): Likewise.
---
 guix/import/cpan.scm |  9 +
 guix/import/crate.scm|  4 ++--
 guix/import/gem.scm  |  2 +-
 guix/import/github.scm   | 19 ++-
 guix/import/json.scm | 24 +---
 guix/import/pypi.scm |  4 ++--
 guix/import/stackage.scm |  2 +-
 7 files changed, 30 insertions(+), 34 deletions(-)

diff --git a/guix/import/cpan.scm b/guix/import/cpan.scm
index 58c051e28..08bed8767 100644
--- a/guix/import/cpan.scm
+++ b/guix/import/cpan.scm
@@ -88,9 +88,10 @@
   "Return the base distribution module for a given module.  E.g. the 'ok'
 module is distributed with 'Test::Simple', so (module->dist-name \"ok\") would
 return \"Test-Simple\""
-  (assoc-ref (json-fetch (string-append "https://fastapi.metacpan.org/v1/module/";
-module
-"?fields=distribution"))
+  (assoc-ref (json-fetch-alist (string-append
+"https://fastapi.metacpan.org/v1/module/";
+module
+"?fields=distribution"))
  "distribution"))
 
 (define (package->upstream-name package)
@@ -113,7 +114,7 @@ return \"Test-Simple\""
   "Return an alist representation of the CPAN metadata for the perl module MODULE,
 or #f on failure.  MODULE should be e.g. \"Test::Script\""
   ;; This API always returns the latest release of the module.
-  (json-fetch (string-append "https://fastapi.metacpan.org/v1/release/"; name)))
+  (json-fetch-alist (string-append "https://fastapi.metacpan.org/v1/release/"; name)))
 
 (define (cpan-home name)
   (string-append "http://search.cpan.org/dist/"; name "/"))
diff --git a/guix/import/crate.scm b/guix/import/crate.scm
index a7485bb4d..3724a457a 100644
--- a/guix/import/crate.scm
+++ b/guix/import/crate.scm
@@ -51,7 +51,7 @@
   (define (crate-kind-predicate kind)
 (lambda (dep) (string=? (assoc-ref dep "kind") kind)))
 
-  (and-let* ((crate-json (json-fetch (string-append crate-url crate-name)))
+  (and-let* ((crate-json (json-fetch-alist (string-append crate-url crate-name)))
  (crate (assoc-ref crate-json "crate"))
  (name (assoc-ref crate "name"))
  (version (assoc-ref crate "max_version"))
@@ -63,7 +63,7 @@
  string->license)
   '()))   ;missing license info
  (path (string-append "/" version "/dependencies"))
- (deps-json (json-fetch (string-append crate-url name path)))
+ (deps-json (json-fetch-alist (string-append crate-url name path)))
  (deps (assoc-ref deps-json "dependencies"))
  (input-crates (filter (crate-kind-predicate "normal") deps))
  (native-input-crates
diff --git a/guix/import/gem.scm b/guix/import/gem.scm
index 6e914d629..646163fb7 100

Re: my latest blog post

[Ludovic Courtès]

Hi Catonano,

Catonano  skribis:

> you chose to enfforce only some violations, not all of them

This is a channel of the Guix project, and our code of conduct applies
on this channel (the other issue you referred to was on the Guile
channel and is not related to Guix.)

The insults and derogatory comments you made in this thread are not
acceptable at all.  Therefore, I ask you to calm down right now and to
get in touch with the people you attacked.

Thanks in advance,
Ludovic.

Re: my latest blog post

[Ludovic Courtès]

Catonano  skribis:

> I just want to record the sorry state of this community

You and I both know this community, having interacted on-line for a
while and having met in person as well.  Like you wrote in the first
part of your blog post, the state of this community is anything but sad.
I find it great to be a part of it, and so did you, at least until
recently.

What makes me sad is that suddenly you’re painting this whole group as
unwelcoming.  Not nice and not constructive, to say the least.

Ludo’.

Re: New ‘guix pull’ dosen’t update the guix manual in GuixSD

[Ludovic Courtès]

Hello 宋文武!

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

> After run ‘guix pull’ twice, I have got ‘~/.config/guix/current’, then
> use it to do a system reconfigure for ‘/etc/profile’.
>
> But the guix manual doesn’t got updated, my ‘INFOPATH’ contains:
>
> - /home/iyzsong/.guix-profile/share/info
> - /run/current-system/profile/share/info
> - /home/iyzsong/.config/guix/current/share/info
> - /home/iyzsong/.guix-profile/share/info
> - /run/current-system/profile/share/info
>
> The last there are from the ‘export’ statement of ‘/etc/profile’, the
> first two are added by ‘source’ the profiles.  Since there is a guix in
> the system profile contains the old info manual, the current one won’t
> be picked.

Ooh!  I think the change below should be enough to ensure
~/.config/guix/current comes first:

--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -602,7 +602,7 @@ directory."
 # because they would require combining both profiles.
 # FIXME: See .
 export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
-export INFOPATH=$HOME/.config/guix/current/share/info:$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
+export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
 export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
 export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
 
@@ -630,7 +630,7 @@ then
   export `cat /etc/environment | cut -d= -f1`
 fi
 
-for profile in \"$HOME/.config/guix/current\" \"$HOME/.guix-profile\"
+for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
 do
   if [ -f \"$profile/etc/profile\" ]
   then
@@ -644,6 +644,8 @@ do
   fi
 done
 
+export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
+
 # Set the umask, notably for users logging in via 'lsh'.
 # See .
 umask 022

How does that sound?

(Note that in the meantime you can always work around the bug by using
‘info -f ~/.config/guix/current/share/info/guix.info’ or ‘C-u C-h i …’
in Emacs.)

Thanks for the heads-up!

Ludo’.

Re: [shepherd] herd status suggestion

[Ludovic Courtès]

Hello Nils,

Nils Gillmann  skribis:

> Ricardo Wurmus transcribed 982 bytes:
>> 
>> Hi Nils,
>> 
>> > abyayala$ sudo herd status tor
>> > Status of tor:
>> >   It is stopped.
>> >   It is disabled.
>> >   Provides (tor).
>> >   Requires (user-processes loopback syslogd).
>> >   Conflicts with ().
>> >   Will be respawned.
>> >   Last respawned on Sun Jun 10 08:08:45Z 2018.
>> >
>> >
>> > Would it be an option to change the status output to,
>> > if it conflicts with no other service:
>> >
>> >   Conflicts with no other services.
>> >
>> > instead of the representation of an empty list?

[...]

> Related and similar: Would it be reasonable to change the output from 
> list-style,
> like:
>   Depends on: (foo bar irks boot)
>
> to the probably tiny bit better readable:
>
>   Depends on: foo, bar, irks, boot
>
> for humans?

I agree with both proposals.  :-)

The output of ‘herd status’ is meant for humans to read, not for
machines to process, so it makes sense to make these changes IMO.  For
machines there’s a well-defined protocol that can be used, so we should
do our best to make ‘herd status’ useful to humans.

If you want to give it a try, this is all happening in
modules/shepherd/scripts/herd.scm.

Thank you,
Ludo’.

Re: GSoC - "Continuing re-write of daemon in Guile Scheme" update

[Ludovic Courtès]

Hello uniq10,

We’ve already discussed this before in private, and like I said, I’m
really grateful you notified us before too long.  You chose to be
transparent and fair, and that’s something I really appreciate.

I wish you the best with your endeavors and hopefully we’ll meet again
in the free software land!

Take care,
Ludo’.


signature.asc
Description: PGP signature

Re: [shepherd] herd status suggestion

[Nils Gillmann]

Ludovic Court??s transcribed 1.3K bytes:
> Hello Nils,
> 
> Nils Gillmann  skribis:
> 
> > Ricardo Wurmus transcribed 982 bytes:
> >> 
> >> Hi Nils,
> >> 
> >> > abyayala$ sudo herd status tor
> >> > Status of tor:
> >> >   It is stopped.
> >> >   It is disabled.
> >> >   Provides (tor).
> >> >   Requires (user-processes loopback syslogd).
> >> >   Conflicts with ().
> >> >   Will be respawned.
> >> >   Last respawned on Sun Jun 10 08:08:45Z 2018.
> >> >
> >> >
> >> > Would it be an option to change the status output to,
> >> > if it conflicts with no other service:
> >> >
> >> >   Conflicts with no other services.
> >> >
> >> > instead of the representation of an empty list?
> 
> [...]
> 
> > Related and similar: Would it be reasonable to change the output from 
> > list-style,
> > like:
> >   Depends on: (foo bar irks boot)
> >
> > to the probably tiny bit better readable:
> >
> >   Depends on: foo, bar, irks, boot
> >
> > for humans?
> 
> I agree with both proposals.  :-)
> 
> The output of ‘herd status’ is meant for humans to read, not for
> machines to process, so it makes sense to make these changes IMO.  For
> machines there’s a well-defined protocol that can be used, so we should
> do our best to make ‘herd status’ useful to humans.
> 
> If you want to give it a try, this is all happening in
> modules/shepherd/scripts/herd.scm.
> 
> Thank you,
> Ludo’.
> 

Thanks!

I will see when I find the time. If I can't work on this in time, I'll let you 
know.

Re: Maintaining implementations of similar utility functions like json-fetch

[Ludovic Courtès]

Hello Jelle!

Jelle Licht  skribis:

> Sorry for the delay. Cue the drum roll; Attached is my initial draft of
> this patch. I initially wanted to split it up into 2 or more patches, but
> could not make this work in a way that I could wrap my head around.

Better late than never!  :-)  It looks good to me.

> Also, there is yet another 'json-fetch'-like function implemented in
> `guix/ci.scm', but I was not sure whether the error-handling facilities
> would be applicable there.

I’d leave (guix ci) as-is.  It’s used by (guix scripts weather), which
has custom HTTP error handling in this case.

> From c60686975df206118c3a26cc9c2cef2a93b2 Mon Sep 17 00:00:00 2001
> From: Jelle Licht 
> Date: Sun, 10 Jun 2018 20:35:39 +0200
> Subject: [PATCH] import: json: Consolidate duplicate json-fetch functionality.
>
> * guix/import/json.scm (json-fetch): Return a list or hash table.
>   (json-fetch-alist): New procedure.
> * guix/import/github.scm (json-fetch*): Remove.
>   (latest-released-version): Use json-fetch.
> * guix/import/cpan.scm (module->dist-name): Use json-fetch-alist.
>   (cpan-fetch): Likewise.
> * guix/import/crate.scm (crate-fetch): Likewise.
> * guix/import/gem.scm (rubygems-fetch): Likewise.
> * guix/import/pypi.scm (pypi-fetch): Likewise.
> * guix/import/stackage.scm (stackage-lts-info-fetch): Likewise.

LGTM!

> --- a/guix/import/json.scm
> +++ b/guix/import/json.scm
> @@ -22,15 +22,25 @@
>#:use-module (guix http-client)
>#:use-module (guix import utils)
>#:use-module (srfi srfi-34)
> -  #:export (json-fetch))
> +  #:export (json-fetch
> +json-fetch-alist))
>  
>  (define (json-fetch url)
> -  "Return an alist representation of the JSON resource URL, or #f on 
> failure."
> +  "Return a representation of the JSON resource URL (a list or hash table), 
> or
> +#f if URL returns 403 or 404."
>(guard (c ((and (http-get-error? c)
> -  (= 404 (http-get-error-code c)))
> - #f))   ;"expected" if package is unknown
> -(let* ((port (http-fetch url #:headers '((user-agent . "GNU Guile")
> - (Accept . "application/json"
> -   (result (hash-table->alist (json->scm port
> +  (let ((error (http-get-error-code c)))
> +(or (= 403 error)
> +(= 404 error
> + #f))
> +;; Note: many websites returns 403 if we omit a 'User-Agent' header.
> +(let* ((port   (http-fetch url #:headers '((user-agent . "GNU Guile")
> +   (Accept . 
> "application/json"
> +   (result (json->scm port)))
>(close-port port)
>result)))
> +
> +(define (json-fetch-alist url)
> +  "Return an alist representation of the JSON resource URL, or #f if URL
> +returns 403 or 404."
> +  (hash-table->alist (json-fetch url)))

There’s an issue: some of the values in the hash tables may themselves
be hash tables as well, so we’d need to convert them as well.

The problem was already there though (and apparently it’s not much of a
problem :-)), so we can address it later.

Thank you!

Ludo’.

Re: GSoC - "Continuing re-write of daemon in Guile Scheme" update

[Gábor Boskovits]

>
>
>
Hello uniq10,

Thanks for letting us know!
I hope to see you again in the community when your issues
are resolved.

Best regards,
g_bor

GSoC 2018 Syntax and semantics of systemd units in the Shepherd - 1st update

[Ioannis Panagiotis Koutsidis]

Hi Guix!

As the 1st phase is coming to an end I decided to post my progress. I have
implemented the unit file parsing as well as some of the basic entries supported
by it, such as ExecStart, User, Group, Restart, etc. In addition, support for
the systemd Restart values (on-success, on-failure, on-abnormal, and on-abort)
was added to the Shepherd via the restart-systemd field in the  class,
letting services written in guile to also use that feature.

During the next phases I will focus on other common .service entries, .socket
support, as well as thoroughly testing the code.
From a0a46ead5e43cd2672a08adb4c16919c377514c2 Mon Sep 17 00:00:00 2001
From: Ioannis Panagiotis Koutsidis 
Date: Sat, 9 Jun 2018 16:17:27 +0300
Subject: [PATCH] Initial systemd unit support

---
 modules/shepherd/service.scm |  78 ---
 modules/shepherd/systemd.scm | 143 +++
 2 files changed, 194 insertions(+), 27 deletions(-)
 create mode 100644 modules/shepherd/systemd.scm

diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index 93d3779..5b0d72d 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -4,6 +4,7 @@
 ;; Copyright (C) 2014 Alex Sassmannshausen 
 ;; Copyright (C) 2016 Alex Kost 
 ;; Copyright (C) 2018 Carlo Zancanaro 
+;; Copyright (C) 2018 Ioannis Panagiotis Koutsidis 
 ;;
 ;; This file is part of the GNU Shepherd.
 ;;
@@ -165,6 +166,11 @@ respawned, shows that it has been respawned more than 
TIMES in SECONDS."
   (respawn? #:init-keyword #:respawn?
#:init-value #f
#:getter respawn?)
+  ;; For the systemd restart values.  Can be 'no (when respawn? is #f),
+  ;; 'on-success, 'on-failure, 'on-abnormal, 'on-watchdog, 'on-abort, or 
'always
+  (respawn-systemd #:init-keyword #:respawn-systemd
+   #:init-value 'always
+   #:getter respawn-systemd)
   ;; The action to perform to start the service.  This must be a
   ;; procedure and may take an arbitrary amount of arguments, but it
   ;; must be possible to call it without any argument.  If the
@@ -270,7 +276,7 @@ wire."
 (define-method (running? (obj ))
   (and (slot-ref obj 'running) #t))
 
-;; Return a list of all actions implemented by OBJ. 
+;; Return a list of all actions implemented by OBJ.
 (define-method (action-list (obj ))
   (map action-name (slot-ref obj 'actions)))
 
@@ -886,9 +892,12 @@ start."
 ;; Produce a destructor that sends SIGNAL to the process with the pid
 ;; given as argument, where SIGNAL defaults to `SIGTERM'.
 (define make-kill-destructor
-  (lambda* (#:optional (signal SIGTERM))
+  (lambda* (#:optional (signal SIGTERM)
+   (timeout #f))
 (lambda (pid . args)
   (kill pid signal)
+  ;; TODO: Make sure that the process has actually stopped by timeout.
+  ;; If it has not, send a SIGKILL
   #f)))
 
 ;; Produce a constructor that executes a command.
@@ -996,7 +1005,7 @@ otherwise by updating its state."
   ((0 . _)
;; Nothing left to wait for.
#t)
-  ((pid . _)
+  ((pid . status)
(let ((serv (find-service (lambda (serv)
(and (enabled? serv)
 (match (slot-ref serv 'running)
@@ -1007,13 +1016,13 @@ otherwise by updating its state."
  ;; SERV can be #f for instance when this code runs just after a
  ;; service's 'stop' method killed its process and completed.
  (when serv
-   (respawn-service serv))
+   (respawn-service serv status))
 
  ;; As noted in libc's manual (info "(libc) Process Completion"),
  ;; loop so we don't miss any terminated child process.
  (loop))
 
-(define (respawn-service serv)
+(define (respawn-service serv status)
   "Respawn a service that has stopped running unexpectedly. If we have
 attempted to respawn the service a number of times already and it keeps dying,
 then disable it."
@@ -1022,22 +1031,37 @@ then disable it."
(not (respawn-limit-hit? (slot-ref serv 'last-respawns)
 (car respawn-limit)
 (cdr respawn-limit
-  (if (not (slot-ref serv 'waiting-for-termination?))
-  (begin
-;; Everything is okay, start it.
-(local-output "Respawning ~a."
-  (canonical-name serv))
-(slot-set! serv 'last-respawns
-   (cons (current-time)
- (slot-ref serv 'last-respawns)))
-(start serv))
-  ;; We have just been waiting for the
-  ;; termination.  The `running' slot has already
-  ;; been set to `#f' by `stop'.
-  (begin
-(local-output "Service ~a terminated."
-  (canonical-name serv))
-(slot-set! serv 'waiting-for-termination? #f)))
+  (let* ([e (status:exit-val status)]
+  

Re: 2 ideas

[Chris Marusich]

Ricardo Wurmus  writes:

> It could be useful to have application-specific setup notes in a
> well-known location that is gathered when the profile is built.

Maybe we could begin by adding a simple, optional field
("post-install-notes", maybe?) to the  record type?  We could
maybe print the notes in the output of invocations like "guix package
--show=foo".  We could also add a profile hook to generate a simple
summary of such documentation for a given profile, in a specific
location (not sure where - depends on the format, maybe, but somewhere
in $GUIX_PROFILE/share?).

> I would not like these notes to be printed automatically upon
> installation, but generating a file with important notes seems like a
> good idea in general.

I also think it's a good idea.  It seems potentially more useful than
maintaining separate documentation in the manual or in a wiki, too
(although that is certainly useful, as well).  There is something to be
said for "self-documenting" package definitions.  It would have helped
me to learn, for example, that to play additional media types in
Rhythmbox (from the rhythmbox package), I needed to install additional
GStreamer plugins (from the gst-libav package, I think).

-- 
Chris


signature.asc
Description: PGP signature

Re: GSoC - "Continuing re-write of daemon in Guile Scheme" update

[swedebugia]

On June 10, 2018 9:45:37 PM GMT+02:00, l...@gnu.org wrote:
>Hello uniq10,
>
>We’ve already discussed this before in private, and like I said, I’m
>really grateful you notified us before too long.  You chose to be
>transparent and fair, and that’s something I really appreciate.
>
>I wish you the best with your endeavors and hopefully we’ll meet again
>in the free software land!

+1
-- 
Cheers Swedebugia

Re: my latest blog post [everyone, please take a cooldown break]

[swedebugia]

Hi

On June 10, 2018 4:37:17 PM GMT+02:00, Kei Kebreau  wrote:
>Gábor Boskovits  writes:
>
>> +1
>>
>> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber
>:
>>
>>  Nils Gillmann writes:
>>
>>  > Hi,
>>  >
>>  > I think it would be best if everyone involved would cool down for
>a couple of
>>  > days, restructure their thoughts and reflect on this thread. Look
>at what
>>  > they are doing, and at how they are reacting to other peoples
>reaction.
>>  > This topic is getting quiet heated, and other than the maintainers
>we
>>  > do not have established some kind of mderation. It can be hard to
>discuss
>>  > some topics online.
>>  > Text can sometimes fail to transport what we attampt to express,
>and
>>  > I have seen people step away from projects because of this.
>>
>>  +1000
>
>+1

+1
I would also like to point to resources that help me when I sometimes get into 
a heated discussion IRL and how to focus inward first to understand what is 
going on in me (with stimulus from the surrounding):
http://thework.com/en/do-work
https://www.youtube.com/watch?v=l7TONauJGfc
-- 
Cheers Swedebugia