Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Fri, Feb 16 2024, Andreas Enge wrote:

> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>> Would it makes sense to have a "does-not-apply" tag too?
>
> Should this not appear in the QA page, assuming that once all the new
> issues are closed, older ones will bubble to the top and be treated by QA?
> (I am not sure if just looking at the n latests issues is how QA works,
> but I think so.)

I think it would be useful (at least for me) if I browse a list of
patches that I want to review, to document why a review can't be done.

Also, so that other people won't try to apply it.

It would be great that QA does that job, I imagine when it does it it
can also add that tag.

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Tue, Feb 06 2024, Suhail wrote:

> Steve George  writes:
>
>> elsewhere in the thread someone mentions some tags we could use
>> consistently so maintainers can find patches that have been reviewed
>> easily.
>
> It seems on the [dev manual] we already have "reviewed-looks-good"
> documented.  Thus, I'd like to propose the below *mutually exclusive*
> Debbugs tag set:
>
> - "not-yet-reviewed" :: automatically set for all submissions
> - "reviewed-needs-fix" :: set explicitly by the reviewer
> - "needs-another-review" :: automatically set if there's a revised
>   patch, unless "not-yet-reviewed" (in which case no change)
> - "reviewed-looks-good" :: set explicitly by the reviewer

Would it makes sense to have a "does-not-apply" tag too?

I believe that would help sorting old those old patches that don't apply
anymore.

> In addition to the above, it might also help for there to be an
> additional tag of "might-not-need-review" (or simpler,
> "review-not-needed") which gets automatically set, provided we implement
> a way to label some changes (for some packages) as being "trivial enough
> that they're okay as long as build succeeds".
>
> On a related note, is it possible for a reviewer who isn't a committer
> to set debbugs tags?
>
> [dev manual]: 
> 
>
>> It would be great to agree those - try them for a bit - and document
>> them in a 'howto' so that everyone uses the same process.
>
> In addition to documenting the tags in the "Debbugs Usertags" section of
> the manual, it would help for there to be a "howto" which focuses more
> on the transition between the tags (i.e., the contribution workflow).

Re: torbrowser

[Clément Lassieur]

Hi Gottfried,

This is great!  Thanks for letting me know.

Kind regards,
Clément

On Thu, Feb 15, 2024, at 11:36 AM, Gottfried wrote:
> Hi Clement,
> 
> now after updating my manifest it worked:
> It downloaded torbrowser additional to icecat and ungoogled-chromium
> 
> 
> gfp@Tuxedo ~$ guix package -p /home/gfp/Projekte/Icecat/guix-profil -m 
> /home/gfp/Projekte/Icecat/icecat.scm
> Die folgenden Pakete werden installiert:
> icecat 115.7.0-guix0-preview1
> torbrowser 13.0.9
> ungoogled-chromium 112.0.5615.165-1
> 
> I am happy
> thanks for your help
> 
> Kind regards
> 
> Gottfried
> 
> 
> Am 18.01.24 um 15:57 schrieb Clément Lassieur:
> > No problem
> > 
> > Maybe you are not in the good place
> > 
> > can you show the output of:
> > 
> >  pwd
> > 
> > ?
> > 
> > Also, where is "gfp" located?
> > 
> > On Thu, Jan 18, 2024, at 3:01 PM, Gottfried wrote:
> >> Am 18.01.24 um 15:39 schrieb Clément Lassieur:
> >> > so what is the file that contains
> >> >
> >> >  ;; Icecat Manifest
> >> >  (specifications->manifest '("icecat" "ungoogled-chromium"
> >> > "torbrowser"))
> >> >
> >>
> >> The file is :
> >>
> >> icecat.scm
> >>
> >> it is located unter:
> >>
> >> gfp/Projekte/Icecat/
> >>
> >>
> >> May be I don't understand something.
> >>
> >> Sorry for the inconvenience.
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > On Thu, Jan 18, 2024, at 2:42 PM, Gottfried wrote:
> >> >> Am 18.01.24 um 15:20 schrieb Clément Lassieur:
> >> >> > does the file exist?
> >> >> >
> >> >> > What is the output of:
> >> >> >
> >> >> >  cat gfp/Projekte/Icecat/icecat.scm
> >> >>
> >> >>
> >> >> gfp@Tuxedo ~$ cat gfp/Projekte/Icecat/icecat.scm
> >> >> cat: gfp/Projekte/Icecat/icecat.scm: No such file or directory
> >> >>
> >> >>
> >> >> >
> >> >> > And what is the output of:
> >> >> >
> >> >> >  guix package -m gfp/Projekte/Icecat/icecat.scm
> >> >> >
> >> >>
> >> >>
> >> >> gfp@Tuxedo ~$ guix package -m gfp/Projekte/Icecat/icecat.scm
> >> >> guix package: error: failed to load 'gfp/Projekte/Icecat/icecat.scm':
> >> >> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to
> >> >> find file "guix/gfp/Projekte/Icecat/icecat.scm" in load path
> >> >>
> >> >> Kind regards
> >> >>
> >> >> Gottfried
> >> >>
> >> >>
> >> >> *Attachments:*
> >> >>
> >> >>   * OpenPGP_0x61FAF349C9FB7F94.asc
> >> >>   * OpenPGP_signature
> >> >
> >>
> >> -- 
> >> Kind regards
> >>
> >> Gottfried
> >>
> >>
> >>
> >> *Attachments:*
> >>
> >>   * OpenPGP_0x61FAF349C9FB7F94.asc
> >>   * OpenPGP_signature
> > 
> 
> -- 
> 
> 
> *Attachments:*
>  • OpenPGP_0x61FAF349C9FB7F94.asc
>  • OpenPGP_signature

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Mon, Feb 05 2024, Felix Lechner via wrote:

> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU 
>> System distribution." wrote:
>>
>> I see no evidence here.  And I'm unsure which plan you are talking
>> about (the plan?).
>
> Two people can look at the same thing and reach different conclusions. I
> see no evidence that large numbers of non-committers are eager to review
> patches.

I believe very few people (commiter or not) are eager to review patches.

>> What do you mean with "bottom"?
>
> I'm sorry to put words into your mouth. I meant to quote an executive at
> a bank who explained that strategy to me. The word "bottom" was his and
> should have been a quote.
>
> The executive referred to people without the authority to act on behalf
> of the group.
>
> I believe Guix would be better off to delegate responsibility (rather
> than competency) by handing out commit access more generously but
> imposing limits as to the type of changes a person may make.
>
> The honor system will work fine.
>
>> Reviewing != Closing
>
> Maybe they should be the same. Two people looking at a patch (submitter
> and committer) are more efficient than three people, i.e. a submitter, a
> reviewer, and a committer.

Committers are trusted, and obviously it takes time to be trusted, so
not everyone can be at once.  Reviewing requires less trust because the
committer can do a quick check that everything is in order before
submitting the patch.

It's less efficient if you compare flows for two patches, but for 1000
patches, it makes it easier to find reviewers, so in the end it's more
efficient.

> It's one of several bottlenecks at Guix. Another is that committers
> should commit what they think is right rather than ask for revised
> patches.

I sometimes update the commit a little bit before pushing, and then
explain what I changed in my email.  But if the changes are big, I often
believe it makes more sense to ask for a v2.

> Please give authorship to the submitter.

I think it's the case?

Cheers,
Clément

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU 
System distribution." wrote:

> Hi Clément,
>
> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> I don't think reviewers have to be committers.
>
> How much more evidence does the project need to see in order to realize
> that the plan is not working?

The best review I've had in years was done by a person who is not a
committer.  I see no evidence here.  And I'm unsure which plan you are
talking about (the plan?).

> I'll spare the list a lengthy analysis of the social dynamics but the
> delegation of competency to the bottom is an unsuccessful practice in
> many places.

What do you mean with "bottom"?

> Maintainers must close bugs in service to the public. There is no other
> way.

Reviewing != Closing

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

Hello,

On Mon, Feb 05 2024, Steve George wrote:

> Hi,
>
> Our goal for the discussion:
>
>   How do we double the number of patches that are *reviewed* and
>   *applied* to Guix in the next six months?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers - more people to do the
> work

I don't think reviewers have to be committers.  If a patch is marked as
‘reviewed’ by a non-commiter, another person can just apply the patch
and push.  Although the commiter will take some responsibility in doing
so, and make sure the review was done correctly, it still makes their
work way easier.

My point is that not being committer shouldn't discourage people to
review patches.

Clément

Re: Using gexps in wireguard-service-type postup

[Clément Lassieur]

On Sun, Jan 28 2024, Richard Sent wrote:

> Clément Lassieur  writes:
>
> On 2024-01-28 09:04, Clément Lassieur wrote:
>> Hi Richard,
>> which would be se same as
>> 
>> (private-key #~(string-append #$sudo "/bin/sudo -u user <(pass 
>> ...)"))
>
> Thanks. I made some progress with this, although I wound up hitting
> another hurdle with the preshared-key.
>
> When setting private-key, the following works fine:
>
> (private-key
>  #~(string-append "<("
>   #$sudo "/bin/sudo" " -u richard "
>   #$password-store "/bin/pass ls " 
> #$wireguard-nickleslan-private-key-key
>   ")"))
>
>
> preshared-key, unfortunately, doesn't follow that same pattern. When
> setting preshared keys with the following snippet:
>
> (wireguard-peer
>  ...
>  (preshared-key
>   #~(string-append "<("
>#$sudo "/bin/sudo -u richard "
>#$password-store "/bin/pass ls " 
> #$wireguard-nickleslan-preshared-key-key
>")")))
>
>
> I wind up with a wireguard.conf file with the following line.
>
> PostUp = 
> /gnu/store/4cnl0h79zc599xryr5jh66d7yq643zk4-wireguard-tools-1.0.20210914/bin/wg
>  set %i private-key 
> <(/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3/bin/sudo -u 
> richard 
> /gnu/store/ppd5qmx2b5fadjhww65xw09zkjphll6r-password-store-1.7.4/bin/pass ls 
> System/WireGuard/NicklesBread/private.key) peer 
> EHoPXGJvQVVpQ6PZ/XQtHx0p5FWEVCS3y2oI2O+Y9zo= preshared-key (string-append <( 
> /gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3 /bin/sudo -u 
> richard  /gnu/store/ppd5qmx2b5fadjhww65xw09zkjphll6r-password-store-1.7.4 
> /bin/pass ls  System/WireGuard/NicklesBread/preshared.key ))

Indeed probably the service is not meant to be used this way with
G-exps.  As a workaround you can use the private-key field to add
everything you need there.  As in

(private-key #~(string-append #$sudo "/bin/sudo -u user <(pass ...) peer " 
#$peer " preshared-key " #$preshared-key))

> Emphasis on how everything after preshared-key is a Lisp sexp, not
> evaluated output. I'm guessing this is because in gnu/services/vpn.scm,
> the relevant code is
> l
>
> (format #f "PostUp = ~a set %i private-key ~a\
> ~{ peer ~a preshared-key ~a~}" #$(file-append wireguard "/bin/wg")
> #$private-key '#$peer-keys)
>
> Peer keys is quoted immediately before the ungexp. I'm curious why that
> would be done and how I can get preshared-key set correctly.
>
> I did try changing preshared-key to (preshared-key #~,(...)), but that
> didn't accomplish anything besides creating a wireguard.config file with
> `preshared-key (unquote (string-append ...))` I assume this is because a
> quote (') is used instead of a quasiquote (`).
>
> Is there anything on my end I can do to fix this or does it have to be
> resolved in Guix proper?

I haven't looked at it closely but probably the service needs at least a
way to add a raw configuration file as, say, the nginx service does (see
raw-content)...  Those raw configuration files can be built with g-exps.

Clément

Re: Using gexps in wireguard-service-type postup

[Clément Lassieur]

Hi Richard,

On Sat, Jan 27 2024, Richard Sent wrote:

> Hi all,
>
> I'm trying to create a wireguard service, but I've encountered an issue
> that I'm pretty sure I can only resolve using gexps and am having
> trouble with the syntax (or if it's even possible to use them in this
> case).
>
> I want to fetch my private key from password-store when running the
> service, and a PostUp command seems the best way of implementing
> that. Using the wg-quick manual as a base, I get a naive solution like:

I think, here you can just add

  (use-modules (gnu packages admin))

> (define* (get-secret-command key #:optional (user (sudo-user)))
>"Returns the shell command needed to read KEY from USER."
>(string-append "sudo -u " user " pass ls " key))
>
> (service wireguard-service-type
>  (wireguard-configuration
(private-key (file-append sudo "/bin/sudo -u user <(pass ...)"))

which would be se same as

(private-key #~(string-append #$sudo "/bin/sudo -u user <(pass ...)"))

>   ...
>   (post-up (list
> ;; Returns "wg set wg-nickleslan private-key <(sudo pass
> ;; ls wireguard-nickleslan-private-key-key)"
> (string-append "wg set " interface " private-key <("
>(get-secret-command 
> wireguard-nickleslan-private-key-key) ")")
> (string-append "wg set " interface " peer " 
> wireguard-nickleslan-public-key
>" preshared-key <("
>(get-secret-command 
> wireguard-nickleslan-preshared-key-key) ")")

This will add another "PostUp" field.

Clément

Re: Cannot build personal channel derivation during guix pull

[Clément Lassieur]

Hello Marek,

On Tue, Jan 23 2024, Marek Paśnikowski wrote:

> Dear All
>
> This is my first attempt to connect to my personal Guix channel. After 
> ironing 
> out server-side inadequacies in my configuration code, I encountered a very 
> resilient, cryptic error.
>
> After one day of experimentation, where nothing I did made the error change, 
> I 
> turn to your experience and knowledge. Could I ask to take a look at my 
> repository ( hosted on https://git.marekpasnikowski.pl/channel.git , branch 
> wip-channel - master has incorrect parens in authorization code ) and see if 
> I 
> missed anything in the file structure?
>
> Also, I would appreciate a confirmation whether the channel can be pulled on 
> your system. I do keep in mind a possibility of a local impurity or cache 
> poison.

I cloned your "channel.git" and checked out branch "wip-channel" but I
found nothing there that looks like a channel.  There are dotfiles, a
home and an os file, but that's not what a channel is.  A channel is a
bunch of guix modules (usually packages) that are meant to be shared.
It typically looks like guix or nonguix.

Dotfiles should not be in a channel because you don't want them to be in
your store.

If things are not meant to be shared, then there is no need to do a
channel.

Hope it helps,
Clément

P.S. Your parenthesis style doesn't help to read your code ;)

> Here is my current channels.scm:
>
> ( list
>   ( channel
> ( name 'guix )
> ( branch "master" )
> ( url "https://git.savannah.gnu.org/git/guix.git; )
> ( introduction
>   ( make-channel-introduction
> "9edb3f66fd807b096b48283debdcddccfea34bad"
> ( openpgp-fingerprint
>   "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA" ) ) ) )
>   ( channel
> ( name 'personal-channel )
> ( branch "wip-channel" )
> ( introduction
>   ( make-channel-introduction
> "f8ccfe8f3e5c8bafe06665cbd4b0c9301e1a64b6"
> ( openpgp-fingerprint
>   "590E 500F E39D 26B3 E60B 743B 6D81 B120 7711 899F" ) ) )
> ( url "https://git.marekpasnikowski.pl/git/channel.git; ) ) )
>
> And this is the COMPLETE build log I receive every single time:
>
> $ zcat /var/log/guix/drvs/hg/15jjf4dr5z7lsfvcj07z2mrw69kzvp-personal-
> channel.drv.gz
>
> (repl-version 0 1 1)
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
> (channel)) (value #f))

Re: Help packaging network-manager-sstp and sstp-client

[Clément Lassieur]

On Sun, Jan 21 2024, Felix Lechner via wrote:

> Hi Lars,
>
> On Fri, Jan 19 2024, Lars Rustand wrote:
>
>> ./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or 
>> directory
>
> I would use something like this [1]
>
> (arguments
>  (list
>   #:phases
>   #~(modify-phases %standard-phases
>   (add-before 'configure 'provide-shell
> (lambda _
>   (setenv "CONFIG_SHELL" (which "sh")))
> (native-inputs (list bash))
>
> although the (which "sh") is kind of lazy and should probably be
> replaced by something like
>
> #$(file-append bash "/bin/sh")

I forgot to say that in this snippet #$(file-append bash ...), bash
doesn't refer to the native input, it directly refers to the bash
package.  To refer to an input, you need to use ‘this-package-input’ or
‘this-package-native-input’.

Re: Help packaging network-manager-sstp and sstp-client

[Clément Lassieur]

Hello,

On Sun, Jan 21 2024, Felix Lechner via wrote:

> Hi Lars,
>
> On Fri, Jan 19 2024, Lars Rustand wrote:
>
>> ./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or 
>> directory
>
> I would use something like this [1]
>
> (arguments
>  (list
>   #:phases
>   #~(modify-phases %standard-phases
>   (add-before 'configure 'provide-shell
> (lambda _
>   (setenv "CONFIG_SHELL" (which "sh")))
> (native-inputs (list bash))
>
> although the (which "sh") is kind of lazy and should probably be
> replaced by something like
>
> #$(file-append bash "/bin/sh")

I don't think (which "sh") is bad, given the occurrences of (which "sh")
and (which "bash") in our code base.  (Actually I don't think being lazy
is bad in programming generally speaking.)

Also, I'm not sure it's necessary to specify bash as an input since it's
implicit in gnu-build-system.

See https://guix.gnu.org/manual/en/html_node/Build-Systems.html.

Cheers,
Clément

> Kind regards
> Felix
>
> [1] 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/config_002estatus-Invocation.html

Re: IRC

[Clément Lassieur]

On Thu, Jan 18 2024, Gottfried wrote:

> Hi Guix,
>
> to use IRC
>
> what do I have to install?

You can also just go to https://web.libera.chat/, join #guix and say
"Hi" :)

>
> I guess: Pidgin
> or are there other clients I should prefer?
>
> what else?
>
> Is it enough to install that client or do I have to add something in my
> config.scm?

Re: torbrowser

[Clément Lassieur]

No problem

Maybe you are not in the good place

can you show the output of:

pwd

?

Also, where is "gfp" located?

On Thu, Jan 18, 2024, at 3:01 PM, Gottfried wrote:
> Am 18.01.24 um 15:39 schrieb Clément Lassieur:
> > so what is the file that contains
> > 
> >  ;; Icecat Manifest
> >  (specifications->manifest '("icecat" "ungoogled-chromium" 
> > "torbrowser"))
> > 
> 
> The file is :
> 
> icecat.scm
> 
> it is located unter:
> 
> gfp/Projekte/Icecat/
> 
> 
> May be I don't understand something.
> 
> Sorry for the inconvenience.
> 
> 
> 
> 
> 
> > 
> > On Thu, Jan 18, 2024, at 2:42 PM, Gottfried wrote:
> >> Am 18.01.24 um 15:20 schrieb Clément Lassieur:
> >> > does the file exist?
> >> >
> >> > What is the output of:
> >> >
> >> >  cat gfp/Projekte/Icecat/icecat.scm
> >>
> >>
> >> gfp@Tuxedo ~$ cat gfp/Projekte/Icecat/icecat.scm
> >> cat: gfp/Projekte/Icecat/icecat.scm: No such file or directory
> >>
> >>
> >> >
> >> > And what is the output of:
> >> >
> >> >  guix package -m gfp/Projekte/Icecat/icecat.scm
> >> >
> >>
> >>
> >> gfp@Tuxedo ~$ guix package -m gfp/Projekte/Icecat/icecat.scm
> >> guix package: error: failed to load 'gfp/Projekte/Icecat/icecat.scm':
> >> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to
> >> find file "guix/gfp/Projekte/Icecat/icecat.scm" in load path
> >>
> >> Kind regards
> >>
> >> Gottfried
> >>
> >>
> >> *Attachments:*
> >>
> >>   * OpenPGP_0x61FAF349C9FB7F94.asc
> >>   * OpenPGP_signature
> > 
> 
> -- 
> Kind regards
> 
> Gottfried
> 
> 
> 
> *Attachments:*
>  • OpenPGP_0x61FAF349C9FB7F94.asc
>  • OpenPGP_signature

Re: torbrowser

[Clément Lassieur]

so what is the file that contains

;; Icecat Manifest
(specifications->manifest '("icecat" "ungoogled-chromium" "torbrowser"))

?

On Thu, Jan 18, 2024, at 2:42 PM, Gottfried wrote:
> Am 18.01.24 um 15:20 schrieb Clément Lassieur:
> > does the file exist?
> > 
> > What is the output of:
> > 
> >  cat gfp/Projekte/Icecat/icecat.scm
> 
> 
> gfp@Tuxedo ~$ cat gfp/Projekte/Icecat/icecat.scm
> cat: gfp/Projekte/Icecat/icecat.scm: No such file or directory
> 
> 
> > 
> > And what is the output of:
> > 
> >  guix package -m gfp/Projekte/Icecat/icecat.scm
> > 
> 
> 
> gfp@Tuxedo ~$ guix package -m gfp/Projekte/Icecat/icecat.scm
> guix package: error: failed to load 'gfp/Projekte/Icecat/icecat.scm':
> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to 
> find file "guix/gfp/Projekte/Icecat/icecat.scm" in load path
> 
> Kind regards
> 
> Gottfried
> 
> 
> *Attachments:*
>  • OpenPGP_0x61FAF349C9FB7F94.asc
>  • OpenPGP_signature

Re: torbrowser

[Clément Lassieur]

On Thu, Jan 18 2024, Gottfried wrote:

> Am 18.01.24 um 13:02 schrieb Clément Lassieur:
>> Hello!
>> On Thu, Jan 18 2024, Gottfried wrote:
>> 
>>>>> I added "torbrowser" to my icecat.scm
>>>>>
>>>>> ;; Icecat Manifest
>>>>> (specifications->manifest '("icecat" "ungoogled-chromium" "torbrowser"))
>>>
>>> I did it this way:
>>>
>>> gfp@Tuxedo ~$ guix package --upgrade
>>> --profile=/home/gfp/Projekte/Icecat/guix-profil
>>>
>>> I tried again today, but it updated only "icecat, ungoogled-chromium.
>>> Tor-browser was not installed.
>> Can you try this:
>> guix package -m icecat.scm
>> ?
>> Clément
>
>
>
> gfp@Tuxedo ~$ guix package -m icecat.scm~
> guix package: Fehler: „icecat.scm~“ konnte nicht geladen werden:
> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to find file
> "guix/icecat.scm~" in load path
>
>
> I have just running "guix confic.scm..."
> can this be the reason that it cant find "icecat.scm"?

I thought ‘icecat.scm’ was your manifest file.

Can you run “guix package -m ”

 is the file that contains

(specifications->manifest '("icecat" "ungoogled-chromium" "torbrowser"))

Re: torbrowser

[Clément Lassieur]

Hello!

On Thu, Jan 18 2024, Gottfried wrote:

>>> I added "torbrowser" to my icecat.scm
>>>
>>> ;; Icecat Manifest
>>> (specifications->manifest '("icecat" "ungoogled-chromium" "torbrowser"))
>
> I did it this way:
>
> gfp@Tuxedo ~$ guix package --upgrade
> --profile=/home/gfp/Projekte/Icecat/guix-profil
>
> I tried again today, but it updated only "icecat, ungoogled-chromium.
> Tor-browser was not installed.

Can you try this:

guix package -m icecat.scm

?

Clément

Re: trivial-build-system: ld can't find existing store files

[Clément Lassieur]

On Wed, Jan 17 2024, Simon Tournier wrote:

> Hi,
>
> On Sun, 14 Jan 2024 at 11:10, Christina O'Donnell  wrote:
>
>> So I'm trying to write a package with a single C file using
>> trivial-build-system[1].
>
> Despite its name, trivial-build-system is the less trivial
> build-system.  Hum, gnu-build-system appears to me better for one single
> C file, even if there is no Makefile.
>
> Felix provided how to use trivial-build-system.  Well – aside I am not
> convinced that %build-inputs is a good way – as we see, many thing need
> to be configured by hand, when gnu-build-system does it for you.

There is the copy-build-system too :)  Which is like the
gnu-build-system, without bootstrap, configure, build, check, install.
And you don't need all those stuff so...

Thanks for your contribution!
Clément

Re: When can package be added to Guix?

[Clément Lassieur]

On Sun, Jan 14 2024, Adam Faiz via wrote:

> Hi martin,
>> Hello, I follow a cool project, PrivacyBrowser, by Soren Stoutner.
>
>> I have been eagerly awaiting its inclusion in Guix, but for some reason it
>> has stalled, and no response has been given to the developer. See chain
>> here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64408
>
>> Can anything be done?
>
> I think you should follow Clément Lassieur's suggestions in the link above, 
> but I recommend web-browsers.scm as a more appropriate place than qt.scm for 
> adding PrivacyBrowser.

Indeed, web-browser.scm sounds perfect.

> Sometimes the developers forget about patches, so it's good to notify Guix 
> committers by IRC or emailing the appropriate package team listed in 
> etc/teams.scm.

Exactly!

Thank you

Re: torbrowser

[Clément Lassieur]

Hi,

> I added "torbrowser" to my icecat.scm
>
> ;; Icecat Manifest
> (specifications->manifest '("icecat" "ungoogled-chromium" "torbrowser"))
>
>
> in my icecat profile
>
>
> and updated my profile

How?

> but it didn't download and install torbrowser.

This is weird, can you show the commands you typed?
>
> May be there is still a problem.
>
> Any hint available?
>
>
> If I look up torbrowser in Guix packages
> and klick on the torbrowser
>
> it said
>
> Couldn't find any package named torbrowser 115.6.0esr-13.0-1-build2. But you
> can do the following:

This should be fixed now:
https://packages.guix.gnu.org/packages/torbrowser/13.0.8/, the web
interface was probably just taking time refreshing.

Kind regards,
Clément

Re: EFF [was: torbrowser]

[Clément Lassieur]

Hi,

On Thu, Dec 28 2023, Felix Lechner via wrote:

> Hi,
>
> On Thu, Dec 28 2023, Clément Lassieur wrote:
>
>> You can check https://coveryourtracks.eff.org to see if browser
>> settings make you unique.
>
> I personally would be cautious with EFF going forward.

Thanks for telling us, I've just been told about
https://fingerprintjs.github.io/fingerprintjs/, which I'll use too from
now on.

Re: torbrowser

[Clément Lassieur]

Hi, which guix are you using? (the sha?  What is the output of "guix
--version"?)

Re: torbrowser

[Clément Lassieur]

Hi,

On Thu, Dec 28 2023, Gottfried wrote:

> I saw that you offer "torbrowser" as a own package.
>
> Does that mean there is a new browser, and it is the torbrowser.

Yes, it is a new browser, the Tor Browser.

> What is then the difference between icecat working over the torbrowser and the
> torbrowser itself?

I guess you meant "icecat working over tor".

The difference is that a site can identify you based on your browser
settings easily if your browser is Icecat, whereas it's much harder if
it's Tor Browser.  You can check https://coveryourtracks.eff.org to see
if browser settings make you unique.

(Also Tor Browser makes it easy to start the Tor network.)

> Is it so that in icecat I can install several add-ons, but in torbrowser no
> ones or only some? Is that the main difference.

You can install add-ons on both browser, although it's discouraged to do
so with Tor Browser because add-ons can increase your footprint and thus
reduce your online anonymity.

> Sorry, for asking basic questions.
> I prefer to ask instead of guessing.

No problem, feel free to ask anything.

Clément

Re: Cuirass Web interface issue

[Clément Lassieur]

Reza Alizadeh Majd  writes:

> Hi Clément, 
>
> On Wed, Nov 27, 2019, at 2:14 PM, Clément Lassieur wrote:
>> I'm glad your issue was resolved!
>> 
>> This is weird though, Cuirass database shouldn't be incompatible accross
>> Cuirass versions.  There are SQL scripts[1] that should update it when a
>> new Cuirass version requires so.  Do you know exactly how to reproduce
>> the issue?  Or do you know what was missing in the SQL schema?
>> 
>> Thanks,
>> Clément
>> 
>> [1]: https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/sql
>>
>
> Unfortunately I don't know about how can we reproduce this issue, but I have 
> backup of database that this issue was occurred on. maybe having a comparison 
> between to database versions help us to find the issue source. 

Cool!  Thank you, I'll have a look when I find some time.

Re: Cuirass Web interface issue

[Clément Lassieur]

Hi Reza,

Reza Alizadeh Majd  writes:

> just to have an update on this thread: 
>
> it seems that database in new version of cuirass wasn't compatible with
> previous versions. so after I removed previous database and let the service to
> re-create it, this issue was resoled.

I'm glad your issue was resolved!

This is weird though, Cuirass database shouldn't be incompatible accross
Cuirass versions.  There are SQL scripts[1] that should update it when a
new Cuirass version requires so.  Do you know exactly how to reproduce
the issue?  Or do you know what was missing in the SQL schema?

Thanks,
Clément

[1]: https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/sql

Re: sha256 hash mismatch for mozjs-38.2.1.rc0

[Clément Lassieur]

Mark H Weaver  writes:

> Clément: I see that you added our 'mozjs-38' package about a year ago.
> Would you be willing to find a new source URL for it, and possibly to
> update to a newer 38.x version?  It might be easier to find a stable URL
> for a non-RC version, and it looks like several other distros now have
> mozjs-38.8.0.

Hi Mark and Platoxia,

I updated the URI.  I'm afraid I won't have time to update to 30.8.0
soon.

Thanks!
Clément

Re: python-minimal built too often

[Clément Lassieur]

Ricardo Wurmus  writes:

> Clément Lassieur  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Clément Lassieur  writes:
>>>
>>>> For some reason it was fixed by adding https://mirror.hydra.gnu.org.  I
>>>> don't understand why it was necessary, since it's not the official
>>>> substitute server according to the docs.  I thought https://ci.guix.info
>>>> would be good enough, but it's not the case yet.
>>>
>>> I checked and there is a completed build for python-minimal; maybe be
>>> don’t have the narinfo / cache files for it?
>
> Turns out that I was wrong and everything is fine.  I accidentally broke
> /etc/guix/acl, so ci.guix.info was not authorized any more…

Oh, it's nice that you found out!  Thank you.
Clément

Re: python-minimal built too often

[Clément Lassieur]

Ricardo Wurmus  writes:

> Clément Lassieur  writes:
>
>> For some reason it was fixed by adding https://mirror.hydra.gnu.org.  I
>> don't understand why it was necessary, since it's not the official
>> substitute server according to the docs.  I thought https://ci.guix.info
>> would be good enough, but it's not the case yet.
>
> I checked and there is a completed build for python-minimal; maybe be
> don’t have the narinfo / cache files for it?

Anyway I've found a workaround: I use 'guix copy' from my more powerful
laptop to my small GuixSD server to copy my whole profile.  And it works
pretty well!

Thank you for you help,
Clément

Re: python-minimal built too often

[Clément Lassieur]

Hi Ricardo,

I can't reproduce it right now because if I remove hydra, it starts
building other stuff (gettext...).  I'll tell you when I reproduce the
issue.

Thank you,
Clément

Ricardo Wurmus  writes:

> Hi Clément,
>
>> guix pull (building python-minimal)
>> guix reconfigure config.scm
>> small nginx config change in config.scm
>> guix reconfigure config.scm (building python-minimal, again)
>
> Can you tell us which variant of python-minimal it built both times?
> I’d like to check on berlin to see why there’s no substitute.

Re: python-minimal built too often

[Clément Lassieur]

For some reason it was fixed by adding https://mirror.hydra.gnu.org.  I
don't understand why it was necessary, since it's not the official
substitute server according to the docs.  I thought https://ci.guix.info
would be good enough, but it's not the case yet.

Clément Lassieur  writes:

> Also, I have https://ci.guix.info as substitute server, and I expect
> python-minimal to be built there ;-).
>
> Clément Lassieur  writes:
>
>> Sorry I sent the email too early.
>>
>> My small GuixSD machine builds python-minimal after a reconfigure that
>> only changes an nginx configuration.
>>
>> What I did is:
>>
>> guix pull (building python-minimal)
>> guix reconfigure config.scm
>> small nginx config change in config.scm
>> guix reconfigure config.scm (building python-minimal, again)
>>
>> It takes a long time for my machine to build python-minimal, so it's
>> pretty annoying.  Is it a bug?  A configuration error?  Any idea how I
>> could fix it?
>>
>> Thanks,
>> Clément
>>
>> Clément Lassieur  writes:
>>
>>> Hi,
>>>
>>> My small GuixSD machine builds python-minimal after a reconfigure that
>>> only changes an nginx

Re: python-minimal built too often

[Clément Lassieur]

Also, I have https://ci.guix.info as substitute server, and I expect
python-minimal to be built there ;-).

Clément Lassieur  writes:

> Sorry I sent the email too early.
>
> My small GuixSD machine builds python-minimal after a reconfigure that
> only changes an nginx configuration.
>
> What I did is:
>
> guix pull (building python-minimal)
> guix reconfigure config.scm
> small nginx config change in config.scm
> guix reconfigure config.scm (building python-minimal, again)
>
> It takes a long time for my machine to build python-minimal, so it's
> pretty annoying.  Is it a bug?  A configuration error?  Any idea how I
> could fix it?
>
> Thanks,
> Clément
>
> Clément Lassieur  writes:
>
>> Hi,
>>
>> My small GuixSD machine builds python-minimal after a reconfigure that
>> only changes an nginx

Re: python-minimal built too often

[Clément Lassieur]

Sorry I sent the email too early.

My small GuixSD machine builds python-minimal after a reconfigure that
only changes an nginx configuration.

What I did is:

guix pull (building python-minimal)
guix reconfigure config.scm
small nginx config change in config.scm
guix reconfigure config.scm (building python-minimal, again)

It takes a long time for my machine to build python-minimal, so it's
pretty annoying.  Is it a bug?  A configuration error?  Any idea how I
could fix it?

Thanks,
Clément

Clément Lassieur  writes:

> Hi,
>
> My small GuixSD machine builds python-minimal after a reconfigure that
> only changes an nginx

python-minimal built too often

[Clément Lassieur]

Hi,

My small GuixSD machine builds python-minimal after a reconfigure that
only changes an nginx

Re: Single user mode in GuixSD

[Clément Lassieur]

Joshua Branson  writes:

>  writes:
>
>> Hello, Guix Help! Once I've lost root password and need to restore root 
>> password in GuixSD.
>>
>
> If you've lost the root password, I don't believe there is much that we
> can do.  You might just have to reinstall.  :()

No, if you have physical access, you can read and modify everything on
your data storage device if you boot from another distro and thus use
the data storage device as an external device.  :-)

>> I've tried to press 'e' in GRUB, added init=/bin/sh and booted into it.
>>
>> But login screen appeared, if it was the usual boot. And I need to use 
>> usb-stick, mount file system, delay root hash from /etc/shadow.
>>
>> Please, how to get single-user mode in GuixSD?

Re: Configuring a service but not starting it on boot

[Clément Lassieur]

Hi Arun,

Arun Isaac  writes:

> I would like to have the a service (specifically the tor service) listed
> in my config.scm and configured using `guix system reconfigure
> config.scm'. But, I do not want the service to start up at boot time. I
> want to start/stop it using `herd' later as and when I require it. How
> do I achieve this?
>
> Thanks!

Attached is a hack I did a while ago.

Hope it helps,
Clément
commit 5ebc46a52e543c316924ac936bb65c3ae7f113bb
Author: Clément Lassieur 
Date:   Fri May 5 15:11:37 2017 +0200

guix: don't auto-start nginx

diff --git a/guix/configs/modules/rodion/web.scm b/guix/configs/modules/rodion/web.scm
index 5c26651..35fe3d3 100644
--- a/guix/configs/modules/rodion/web.scm
+++ b/guix/configs/modules/rodion/web.scm
@@ -1,6 +1,8 @@
 (define-module (rodion web)
   #:use-module (gnu services)
   #:use-module (gnu services web)
+  #:use-module (srfi srfi-1) ; find
+  #:use-module (gnu services shepherd) ; shepherd-root-service-type
   #:export (%my-nginx-service))
 
 (define my-nginx-configuration
@@ -18,5 +20,29 @@
  (uri "/")
  (body (list "index index.html;"))
 
+(define (my-nginx-shepherd-service nginx-conf)
+  (let ((nginx-shepherd-service
+ (service-extension-compute
+  (find (lambda (ext)
+  (eq? (service-extension-target ext)
+   shepherd-root-service-type))
+(service-type-extensions nginx-service-type)
+(list
+ (shepherd-service
+  (inherit (car (nginx-shepherd-service nginx-conf)))
+  (auto-start? #f)
+
+(define my-nginx-service-type
+  (service-type
+   (inherit nginx-service-type)
+   (extensions
+(cons
+ (service-extension shepherd-root-service-type
+my-nginx-shepherd-service)
+ (remove (lambda (ext)
+   (eq? (service-extension-target ext)
+shepherd-root-service-type))
+ (service-type-extensions nginx-service-type))
+
 (define %my-nginx-service
-  (service nginx-service-type my-nginx-configuration))
+  (service my-nginx-service-type my-nginx-configuration))

Re: Root guix dereferencing

[Clément Lassieur]

Thorsten Wilms  writes:

>> If you are using Ubuntu, you don't need to use that command though, but
>> you need your systemd's guix-daemon to point to a recent guix.  It could
>> be either the one updated by root's 'guix pull', or the one updated by
>> your current user's 'guix pull'.  I chose the latter because I want to
>> run 'guix pull' only once.
>
> You mean edit /etc/systemd/guix-daemin.service and change
> "/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon"?

Well...  The problem with the default one is that it's not updated by
'guix pull', rather it's updated when root's guix package[1] is updated
(that is: less often).  It's not a big deal though, because
'guix-daemon' is very stable, rarely changed.

(Actually, there is no difference at the moment, because I believe 'guix
pull' uses the daemon of the guix package.  But there might be a
difference in the future.)

tldr: you don't need to change your guix-daemon :/

> If so, to what, as there's no guix-daemon in
> /var/guix/profiles/per-user/root/guix-profile/bin/.

To /home//.config/guix/current/bin/guix-daemon or
/root/.config/guix/current/bin/guix-daemon, depending on whether you
want to use your user's Guix-daemon or root's Guix-daemon.

But your current situation is fine :)

> Is the whole reason to have /usr/local/bin/guix to make guix available for
> root without modifying root's PATH?

The reason is to make the 'guix' command available to every user,
because /usr/local/bin is supposedly in every user's PATH.  You don't
need it anymore if all your users already have their own 'guix' command.

> Things are a bit clearer now, thanks, Clément.

This stuff is pretty complicated anyway.  You're welcome :-)

Clément

[1]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/package-management.scm#n100

Re: Root guix dereferencing

[Clément Lassieur]

Thorsten Wilms  writes:

> On 19/11/2018 15.07, Clément Lassieur wrote:
>> It doesn't need to contain 'sudo' and 'root', because 'root' is just a
>> user, so everything works the same way.
>
> $: which guix
> /home/thorwil/.config/guix/current/bin/guix
>
> $: sudo which guix
> /usr/local/bin/guix
>
> $ sudo -E which guix
> /usr/local/bin/guix
>
> $: sudo -i
> root@charly:~# which guix
> /root/.guix-profile/bin/guix
>
> I wouldn't describe that as working the same way, especially since only the
> symlinks for the plain user are being updated.

If you check ~root/.config/guix/current/bin/guix, you'll see that it's
updated when you run 'guix pull' as root.  If you want that guix to be
used for your 'root' user, you just need to make sure
~root/.config/guix/current/bin/ is first in root's $PATH.

You can substitute 'root' with whatever else in the above statement.

'sudo', however, is more tricky to use.  I only use it for 'guix system
reconfigure' because it requires root's privileges.  'sudo -E guix
system reconfigure config.scm' would for example use my own environment
variables, thus my own guix, with root's privileges.

If you are using Ubuntu, you don't need to use that command though, but
you need your systemd's guix-daemon to point to a recent guix.  It could
be either the one updated by root's 'guix pull', or the one updated by
your current user's 'guix pull'.  I chose the latter because I want to
run 'guix pull' only once.

Does it make more sense?
Clément

Re: Root guix dereferencing

[Clément Lassieur]

Thorsten Wilms  writes:

> On 19/11/2018 11.20, Clément Lassieur wrote:
>
>> This is because the result of running guix pull is a profile available
>> under ~/.config/guix/current containing the latest Guix[1].
>>
>> So you may need to make sure it is at the beginning of your search path.
>
> Thanks, but the plain user `guix pull` works fine and ~/.config/guix/current
> is up-to-date.

In case it's not clear, '~' refers to root's home as well.  'root' is
just a user.  You don't even have to use it at all.  (I personally never
use it.)

>> [1]: 
>> https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pull.html
>
> I note that this page doesn't contain "sudo" at all and "root" only once, in
> "For instance, when user root runs guix pull, this has no effect on the
> version of Guix that user alice sees, and vice versa.".

It doesn't need to contain 'sudo' and 'root', because 'root' is just a
user, so everything works the same way.

Clément

Re: Root guix dereferencing

[Clément Lassieur]

Hi Thorsten,

This is because the result of running guix pull is a profile available
under ~/.config/guix/current containing the latest Guix[1].

So you may need to make sure it is at the beginning of your search path.

[1]: 
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pull.html

Thorsten Wilms  writes:

> On 19/11/2018 00.06, Leo Famulari wrote:
>> Can you help us by clarifying exactly what is wrong?
>>
>> In general, using sudo without either the --preserve-env or --login
>> options is not recommended, because it won't do what you want in any
>> case where environment variables are involved.
>
> /usr/local/bin/guix and /root/.guix-profile/bin/guix keep pointing to the
> original guix installation.
>
> I tried all of these, each time with
> --commit=0a41123f01d5d2466d6f533be3644ac8c9a2bdf9:
>
> sudo guix pull
> sudo -i guix pull
> sudo -E
>   guix pull
>
> None of these changed what /usr/local/bin/guix and/or
> /root/.guix-profile/bin/guix are pointing to.

Re: why does this system build but won't reconfigure?

[Clément Lassieur]

George Clemmer  writes:

> Oh DUH! Never mind, I guess my 'sudo guix system reconfigure' is using
> the ancient guix version installed in root. Arf!

Maybe you could try 'sudo -E guix system reconfigure', so that it uses
your current user's environment variables.

Cheers,
Clément

Re: Guixsd 0.15.0 Installation Fail

[Clément Lassieur]

mirror.hydra.gnu.org doesn't work well either, see
https://bugs.gnu.org/33151.  I think your best bet is to only use
https://berlin.guixsd.org.

Thorsten Wilms  writes:

> On 30/10/2018 19.27, Anthony Eslick wrote:
>> When I run "guix system init /mnt/etc/config.scm /mnt" I get a message that
>> infinitely scrolls across the screen
>>
>> substitute: guix substitute: warning: while fetching
>> 'https://mirror.hydra.gnu.org/nix-cache-info': 504 ("Gateway Time-out")
>> substitute: guix substitute: warning: ignoring substitute server at
>> '"https://mirror.hydra.gnu.org;'
>
> Hi!
>
> Assembled from several posts:
>
> hydra.gnu.org is currently down and mirror.hydra.gnu.org is just proxying it.
>
> See https://lists.gnu.org/archive/html/guix-devel/2018-10/msg00434.html
>
>
> Substitute-Server-Authorization:
> As described at
> https://www.gnu.org/software/guix/manual/en/guix.html#Substitute-Server-Authorization
>
> After `guix archive --authorize < berlin.guixsd.org.pub`
> you may run commands with:
> `--substitute-urls="https://berlin.guixsd.org`
>
>
> You may want to add this setting globally and permanently, so you don't have
> to specify it every time you run guix. You can do this by passing the option
> to the guix daemon
>
> - when using GuixSD, modify guix-service in your system configuration, by
> specifying the substitute-urls in the configuration. (see guix-configuration
> in https://www.gnu.org/software/guix/manual/en/html_node/Base-Services.html )
>
>
> Not applicable in your case:
>
> - when using guix on another distribution with systemd, you can modify the the
> ExecStart line in /etc/systemd/system/guix-daemon.service as follows:
>
> ExecStart=/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
> --build-users-group=guixbuild "--substitute-urls=https://mirror.hydra.gnu.org
> https://berlin.guixsd.org;;

Re: Re Recent hydra.gnu.org maintenance window

[Clément Lassieur]

Hi Nalin!

Nalin Ranjan  writes:

> Thank you so much Clement.
>
> Any idea by when it could be?

The Berlin build farm is back, so it would be a good idea, I think, to
use only berlin.guixsd.org as substitute (unless hydra.gnu.org is back?
But I haven't heard about it).

As per https://bugs.gnu.org/33151, it is recommended to avoid using
mirror.hydra.gnu.org while hydra.gnu.org is down.

> Also if someone can help me with the experience which I am going to write
> below, I will be really grateful.
>
> It's just that I am not trying to upgrade Guix, but have been trying to
> unsuccessfully install GuixSD for the first time ever on my laptop. In the
> past week or so I have ran the command system init like 7-8 times,and every
> time it fails into 504(Gateway timeout), or Patch not found(may be 404),
> and couple of occasions SHA mismatch. I tried running the default command
> as per documentation, also tried with --substitute-urls specified as
> mirror.hydra.gnu.org and/or berlin.guixsd.org a but end result being same.
> The install halts in the middle. When I specified --keep-going(and left for
> office), when I came back, I saw an infinite loop of 504s, just being
> printed out on the console repetitively for the same package.
>
> Then I tried specifying --fallback, which kind of seems to get the thing
> done. Though it takes innate amount of time to run(guess everything is
> getting compiled from bottom to top), but in the very last step it fails
> saying system error: grub failed to install. Phe, back to square one,
> yet another time.

I think your best bet is to use --fallback, with the minimum
installation image, that is: the bare bones setup[1].  You need to have
a good internet connection, and... be patient.

[1]: 
https://www.gnu.org/software/guix/manual/en/html_node/Using-the-Configuration-System.html

>  I have a ThinkPad T410 on which I am trying to do this. Currently I have a
> dual boot configuration running Ubuntu and Windows 7. Could that grub
> install failure because of my /boot not being empty and formatted afresh
> for GuixSD? If so, can anyone of you please help me in figuring out how to
> install GuixSD alongside those existing ones(other distros plus special Mr.
> Windows)? Do I need to reformat my /boot to make it fresh so that Grub
> install from GuixSD installation could succeed(not sure if this is the
> reason for failure).
>
> Since I have just this laptop, dedicating to GuixSD build from source is
> blocking me for a very long long time(Just now I spent a week so in trying
> to get it to completion, only to discover very late that a maintenance is
> up in progress). Please suggest as to how should I go about, having GuixSD
> installed along with preserving the older installations on my system?

I have no experience with Dual boot GuixSD, sorry!  Maybe someone else
can help you though.  There are plenty of people in #guix[2].  Don't
hesitate to come and ask questions!  If you don't get answers
immediately, it's a good idea to stay anyway because people may reply
hours later ;-)

[2]: https://www.gnu.org/software/guix/contact/irc/

> Let me know if I can help with any other information from my side. though
> new, I can always  dig in to extract the necessary information.
>
> PS:- I am so new to FSF and its software, I may not sound as appropriate as
> I should while putting up my concerns. So please feel free to comment,
> advise or dictate anything that you may feel will let me into the right
> direction.

You're very welcome :-)
Clément

Re: Re Recent hydra.gnu.org maintenance window

[Clément Lassieur]

Hi Nalin,

I don't think so.

And Berlin's Continuous Integration doesn't work anymore, so there is
currently no way to upgrade Guix.

Cheers,
Clément

Nalin Ranjan  writes:

> Hi Guys
> Is this Window over?
>
> Regards
> Nalin Ranjan

Re: hydra.gnu.org off-line for maintenance

[Clément Lassieur]

Hi,

Thomas Danckaert  writes:

> Also, you may want to add this setting globally and permanently, so you don't
> have to specify it every time you run guix.  You can do this by passing the
> option to the guix daemon
>
>  - when using guix on another distribution with systemd, you can modify the
> the ExecStart line in /etc/systemd/system/guix-daemon.service as follows:
>
> ExecStart=/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
> --build-users-group=guixbuild "--substitute-urls=https://mirror.hydra.gnu.org
> https://berlin.guixsd.org;

Note that https://mirror.hydra.gnu.org doesn't work well either[1].  You
might be better off with just https://berlin.guixsd.org.

But I noticed today that https://berlin.guixsd.org doesn't evaluate
anything anymore[2], so you will only get old evaluations from it.

At the moment I can't find any working solution.

[1]: https://bugs.gnu.org/33151
[2]: https://berlin.guixsd.org/jobset/guix-master

Cheers,
Clément

Re: impossible de telecharger autre que root

[Clément Lassieur]

guy fleury  writes:

> Salut clement,
>   je veux le temps pour aller sur le channel IRC.Est-ce que je peux
> poster en francais sur ce channel?

Oui tu peux poster en français !

Tu n'auras peut-être pas de réponse immédiate, mais ça vaut le coup
d'attendre (tu laisses la fenêtre ouverte).

Et comme c'est de la messagerie instantanée, c'est plus facile pour nous
de comprendre tes problèmes.

Re: impossible de telecharger autre que root

[Clément Lassieur]

Salut Guy,

Si tu veux, tu peux aller sur le channel IRC de Guix, où il y a plein de
gens super sympas qui pourraient t'aider plus facilement, en direct :-)

https://www.gnu.org/software/guix/contact/irc/

Bon courage,
Clément

guy fleury  writes:

> Le jeudi 18 octobre 2018 à 09:46 +0200, Pierre Neidhardt a écrit :
>> Bonjour Guy!
>> 
>> > je viens d'installer guix sur un debian en tant que root.
>> 
>> Comment ça "en tant que root"?
>je vais dire que j'ai installe en mode superutilisateur donc
>avec utilisateur root
>
>> As-tu suivi les procédures d'installation du manuel?  Chaque étape
>> est importante.
>je crois Oui avoir suivi tous les etapes
>> > Tout marche bien sauf que quand je me connecte a mon compte
>> > on montre cette erreur
> pardon je croyais avoir avoir le message d'erreur
>> Comment te connectes tu à ton compte?  Qu'est-ce qui "montre" et où
>> ça?
> ok!
> donc quand je me connecte a mon compte "guy" je 
> doit installer avec sudo sinon j'ai cet erreur:
>
> erreur : vous ne possédez pas le répertoire
> « /var/guix/profiles/per-user/guy »
> Veuillez définir "/var/guix/profiles/per-user/guy" comme propriétaire
> de « guy »
> 

Re: Updating guix for root

[Clément Lassieur]

Hi Konrad,

Konrad Hinsen  writes:

> Hi Guixers,
>
> I wonder what the correct way is to update Guix for the root user.
> I did "guix pull" and got the new Guix under /root/.config/guix/current.
> This also contains the daemon under
> /root/.config/guix/current/bin/guix-daemon. So far, fine.
>
> However, the systemd service still launches the daemon from 
> /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon. So if I
> uninstall the package "guix" for the root account (see
> https://www.mail-archive.com/bug-guix@gnu.org/msg09793.html), I will
> probably remove the guix-daemon that is used on system startup.
>
> Should I
>
>  1) update /etc/systemd/system/guix-daemon.service
> to point to the current daemon? If so, is
> /root/.config/guix/current/bin/guix-daemon
> the right (stable) path to use?
>
>  2) Get an updated guix-daemon.service from somewhere?
> If so, from where?
>
>  3) Do nothing, and keep using the old guix-daemon?
>
>  4) Do yet something else?
>
> Konrad.

If you are the only user on your computer, you probably don't need Guix
to be installed at all for the 'root' user, and can just make sure
/etc/systemd/system/guix-daemon.service points to
/home/user/.config/guix/current/bin/guix-daemon.  It will be updated
when you will 'guix pull' as a normal user, to the last guix package,
and hopefully, later, to the guix that was pulled.

Clément

Re: Guix on aarch64

[Clément Lassieur]

Hi Benjamin,

Benjamin Slade  writes:

> I'm trying to install the Guix (standalone) package manager on top of
> Void Linux (musl libc) on a raspberrypi3 using the aarch64 architecture,
> but when (from the processed described here:
> https://www.gnu.org/software/guix/manual/en/guix.html#Installation ), I
> get to the bit:
>
> `# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild`
>
> It just seems to hang. When I look at the process, it doesn't seem to be
> using cpu resources anything. I tried leaving it for a couple of hours,
> but it never seems to do anything.

It is its normal behaviour, because it's a long-running process; it
should be always running and the Guix command talks to it.  People
usually use an init manager to start it automatically (systemd, the
Shepherd...).  You can also add '&' at the end of the command so that it
goes in the background.

Clément

Re: Cuirass fibers crash // using with GUIX_PACKAGE_PATH

[Clément Lassieur]

Hi Ricardo,

Ricardo Wurmus  writes:

>>> Another problem is that Cuirass crashes on startup.  The Cuirass log
>>> shows me this:
>>>
>>> --8<---cut here---start->8---
>>> 2018-08-09T16:54:05 running Fibers on 4 kernel threads
>>> Uncaught exception in fiber ##f:
>>> In ice-9/eval.scm:
>>> 619:8  1 (_ #(#(# #< ?> ?)))
>>> In unknown file:
>>>0 (_ # # ?)
>>> ERROR: In procedure for-each: Wrong type argument: #f
>>> --8<---cut here---end--->8---
>>>
>>> The Cuirass process remains, but appears to be stuck.
>>
>> This is because your specification list is invalid.  I just noticed the
>> Guix manual about Cuirass is out of date.  Please, have a look at the
>> Cuirass manual instead.
>
> Can we prevent this unhelpful error message by validating the
> specifications?

We definitely should, I opened https://bugs.gnu.org/32422 to keep track
of it.

Clément

Re: Cuirass fibers crash // using with GUIX_PACKAGE_PATH

[Clément Lassieur]

Hi Ricardo,

Ricardo Wurmus  writes:

> Hi Guix,
>
> I have a server running GuixSD with Cuirass and it’s supposed to build a
> bunch of user-provided manifests continuously.  These manifests refer to
> packages that are defined in a separate repository that is on
> GUIX_PACKAGE_PATH, so really the Cuirass specification for them depends
> on two repositories.  Can we express this with specifications?

Yes, the Cuirass manual shows an example that does exactly what you
want:

  '((#:name . "foo-master")
(#:load-path-inputs . ("guix"))
(#:package-path-inputs . ("packages"))
(#:proc-input . "conf")
(#:proc-file . "drv-list.scm")
(#:proc . cuirass-jobs)
(#:proc-args (subset . "foo"))
(#:inputs . (((#:name . "guix")
  (#:url . "git://git.savannah.gnu.org/guix.git")
  (#:load-path . ".")
  (#:branch . "master")
  (#:no-compile? . #t))
 ((#:name . "conf")
  (#:url . "git://my-personal-conf.git")
  (#:load-path . ".")
  (#:branch . "master")
  (#:no-compile? . #t))
 ((#:name . "packages")
  (#:url . "git://my-custom-packages.git")
  (#:load-path . ".")
  (#:branch . "master")
  (#:no-compile? . #t)

> Previously I set up a cron job to update the second repository and
> added it on the load-path through the Cuirass service configuration.

That cron job is not needed anymore.  Also, that load-path isn't global
any longer: it's per specification (see #:package-path-inputs).

> Since a recent update to Cuirass and the service “load-path” is no
> longer a valid field, so it seems I can no longer do this.  Do you have
> any recommendations on how to accomplish my goal?

Indeed, that recent update you are talking about adds multiple inputs to
a Cuirass specification.  Its goal is to handle your use case in a
better way: the GUIX_PACKAGE_PATH (named "packages" in the above
example) is a new input, and a new evaluation will be triggered when a
new commit arrives in that input.  Its name doesn't matter, but
#:package-path-inputs needs to point to its name.

> Another problem is that Cuirass crashes on startup.  The Cuirass log
> shows me this:
>
> --8<---cut here---start->8---
> 2018-08-09T16:54:05 running Fibers on 4 kernel threads
> Uncaught exception in fiber ##f:
> In ice-9/eval.scm:
> 619:8  1 (_ #(#(# #< ?> ?)))
> In unknown file:
>0 (_ # # ?)
> ERROR: In procedure for-each: Wrong type argument: #f
> --8<---cut here---end--->8---
>
> The Cuirass process remains, but appears to be stuck.

This is because your specification list is invalid.  I just noticed the
Guix manual about Cuirass is out of date.  Please, have a look at the
Cuirass manual instead.

Clément

Re: LUKS-encrypted root and unencrypted /boot ?

[Clément Lassieur]

Benjamin Slade  writes:

> Thanks, Clément.

You're welcome!

>  > >  > Do you use Libreboot?
>  > >
>  > > Yes, I'm using Libreboot. Does this make a great difference over the
>  > > manufacturer firmware in this case?
>
>  > It might, because the GRUB used is the one shipped with Libreboot.
>  > So it has nothing to do with Guix.  I think talking to the libreboot
>  > people would help you more.  (Disclaimer: I have the same issue, I
>  > find that pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the
>  > process faster.)
>
> Thanks, I'll look into that. For the moment I've just switched to having
> an unencrypted root and encrypted /home partition (where the swapfile
> also lives),

> ...which seems to me better from a security standpoint (I can
> use --iter 500, sha512,  without an issue).

But it's easier put a malware in an unencrypted root ;)

Re: LUKS-encrypted root and unencrypted /boot ?

[Clément Lassieur]

Benjamin Slade  writes:

>  > Do you use Libreboot?
>
> Yes, I'm using Libreboot. Does this make a great difference over the
> manufacturer firmware in this case?

It might, because the GRUB used is the one shipped with Libreboot.  So
it has nothing to do with Guix.  I think talking to the libreboot people
would help you more.  (Disclaimer: I have the same issue, I find that
pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the process
faster.)

>  > I'm unsure [using an unencrypted /boot] would help, because GRUB
>  > would still have to unencrypt / to access the kernel (the kernel is
>  > in /gnu/store).
>
> Ah, I see. Is this an immutable design decision?  It would seem good to
> be able to keep the kernel in a separate space in order to avoid the
> issue of extremely long unlocking times when booting.

Nothing is immutable, but it's a strong design decision that all
packages data are put in /gnu/store.  Linux is just one of them.  Plus,
a characteristic of GuixSD is that you can revert to previous
configurations.  Those configurations appear as GRUB lines.  Each
configuration could have a different kernel and kernels take space, so
it wouldn't scale well.  Plus, I think some other stuff is needed as
well, like the initrd, which is large too, etc.

There are probably reasons I don't know about too :-)

Good luck!
Clément

Re: Error with mcron-configuration

[Clément Lassieur]

Jone  writes:

> *> But only it still does not work!*
>
> With current system version all Ok:
>
> #> sudo herd status mcron
> Status of mcron:
>   It is started.
>   Running value is 298.
>   It is enabled.
>   Provides (mcron).
>   Requires (user-processes).
>   Conflicts with ().
>   Will be respawned.
>
> ps ax | grep mcron
>   298 ?Ssl0:00
> /gnu/store/9dl8l4krszdd1dhaw94da0nv28ap8dvp-mcron-1.1.1/bin/mcron
> /gnu/store/vvf3frpvrffpchbd3xxlq8kmnxsywja6-mcron-job
> /gnu/store/jv9asgfm82f6k7srwxy6bf9ckk70z270-mcron-job
> /gnu/store/n4jbzmm6ihv70dd8j2ba9501hxs3q9ar-mcron-job
> /gnu/store/2yql34psrh6iiyczs48hj7pw5bgv6gh6-mcron-job
>   722 pts/0S+ 0:00 grep mcron

Hi Jone,

The --schedule option will help you debugging it.

You can do for example:

/gnu/store/9dl8l4krszdd1dhaw94da0nv28ap8dvp-mcron-1.1.1/bin/mcron \
/gnu/store/vvf3frpvrffpchbd3xxlq8kmnxsywja6-mcron-job \
/gnu/store/jv9asgfm82f6k7srwxy6bf9ckk70z270-mcron-job \
/gnu/store/n4jbzmm6ihv70dd8j2ba9501hxs3q9ar-mcron-job \
/gnu/store/2yql34psrh6iiyczs48hj7pw5bgv6gh6-mcron-job --schedule=10

It will compute the times the commands would be run and prints the
information to the screen, and then immediately exits.

See https://www.gnu.org/software/mcron/manual/mcron.html#Invoking-mcron.

Clément

Re: nginx et .htaccess

[Clément Lassieur]

I'm glad it works Andreas!

Clément

Andreas Enge  writes:

> Hello Clément,
>
> I think I never replied to your kind e-mail, apologies!
>
> On Fri, May 04, 2018 at 06:14:09PM +0200, Clément Lassieur wrote:
>> I do the same with my nginx configuration:
>> 
>> (nginx-server-configuration
>>   (listen '("443 ssl" "[::]:443 ssl"))
>>   (server-name (list "foo.org"))
>>   (root "/var/www/foo")
>>   (locations
>>(list
>> (nginx-location-configuration
>>  (uri "/")
>>  (body (list "index index.html;"
>>  "auth_basic \"closed site\";"
>>  ;; needs to be set manually
>>  "auth_basic_user_file /etc/nginx/htpasswd;")
>>   (ssl-certificate ...)
>>   (ssl-certificate-key ...))
>> 
>> /etc/nginx/htpasswd may contain:
>> user:
>
> This worked well, indeed, thanks a lot! It did not even occur to me that
> I could store state somewhere on the machine and use it in my operating
> system declaration...
>
> Andreas

Re: Problems with GNU Parallel and ulimit

[Clément Lassieur]

Eric Bavier  writes:

> Sending response to the list this time...
>
>> Arun Isaac  writes:
>> 
>> > Leo Famulari writes:
>> >
>> >> On Mon, Aug 14, 2017 at 12:46:25PM +1000, Ben Woodcroft wrote:
>> >>> On 14/08/17 12:31, Arun Isaac wrote:
>> >>> > Does `parallel' work for anybody? When I run
>> >>> > 
>> >>> > $ ls | parallel echo
>> >>> > 
>> >>> > I get the following error message, and nothing happens.
>> >>> It works fine for me using Guix on a foreign OS, and has since I
>> >>> can remember.
>> >>> ben
>> >>
>> >> Same here. Arun, can you give some more details about your system?
>> >
>> > This is probably a problem only on GuixSD systems. Could you try on
>> > GuixSD instead of using Guix on a foreign distro?
>> 
>> I tested it on GuixSD, works fine. Are you trying the command in a
>> folder with > 1024 files perhaps? What does `ulimit -n` print?
>
> The problem appears if you do not have 'perl' available in $PATH. GNU
> parallel calls it recursively for a few tasks:
>
> $ guix package -I | grep "perl"
> $ echo $?
> 1
> $ parallel echo ::: 1 2 3
> ...
> parallel: Warning: Raising ulimit -u or /etc/security/limits.conf may help.
> parallel: Error: No more processes: cannot run a single job. Something is 
> wrong at 1.
> $ guix environment --ad-hoc perl
> [dev]$ parallel echo ::: 1 2 3
> 1
> 2
> 3
>
> There is some path patching that goes on in the package recipe, but it
> must have gone out of sync in latest versions.  The 'post-install-test'
> phase wouldn't catch this particular error without '(setenv "PATH" "")'.
>
> I wouldn't feel quite comfortable doing a "blind" update of the regex,
> since some mentions of "perl" I think are meant to be executed by
> remote hosts and so shouldn't be patched to absolute store references.

Hi,

This is fixed by 4e7950fdce5b83db018c44a80ec4a4059612d716 (it adds a
wrap-program phase).

Clément

Re: Mount /tmp as tmpfs?

[Clément Lassieur]

Nils Gillmann  writes:

> Pierre Neidhardt transcribed 998 bytes:
>> 
>> I was wondering if it's commendable to mount /tmp as tmpfs with GuixSD.
>> I think it could be useful to speed up Guix builds.
>
> Guix maybe, for a developer system you run out of RAM for everything
> that has serious demands in RAM and/or Diskspace for building.
>
> If waste of writes is your concern, getting a separate disk for
> /tmp is a good choice. As long as you don't have to build big
> applications from source/without substitutes tmpfs is alright.
>
> Been there, tried that and considered it now only for machines that
> will never build anything big.

Well yes, my tmpfs works perfectly, but I forgot to say that I have 128G
RAM.

Re: Mount /tmp as tmpfs?

[Clément Lassieur]

Pierre Neidhardt  writes:

> I was wondering if it's commendable to mount /tmp as tmpfs with GuixSD.
> I think it could be useful to speed up Guix builds.
>
> What would be the best way to do so?
> Can't test now, but what about
>
>  (file-system
>(mount-point "/tmp")
>(device "tmpfs")
>(type "tmpfs")
>(flags '(no-dev no-suid))
>
> ?

I use:

(file-system
  (mount-point "/tmp")
  (device "none")
  (title 'device)
  (type "tmpfs")
  (check? #f))

And it works perfectly.

Re: nginx et .htaccess

[Clément Lassieur]

Hi Andreas,

Andreas Enge  writes:

> Hello,
>
> I would like to set up a web server with a password (only one user and
> the associated password), in the same way as the .htaccess file does for
> apache.
>
> When looking on the web, there are examples how to do this with Ubuntu etc.,
> by adding a file somewhere to /etc (with the hashed password) and editing a
> line in the configuration file.
>
> Does our nginx configuration allow us to do the same?

I do the same with my nginx configuration:

(nginx-server-configuration
  (listen '("443 ssl" "[::]:443 ssl"))
  (server-name (list "foo.org"))
  (root "/var/www/foo")
  (locations
   (list
(nginx-location-configuration
 (uri "/")
 (body (list "index index.html;"
 "auth_basic \"closed site\";"
 ;; needs to be set manually
 "auth_basic_user_file /etc/nginx/htpasswd;")
  (ssl-certificate ...)
  (ssl-certificate-key ...))

/etc/nginx/htpasswd may contain:
user:

(I don't remember how to generate that hashed password.)

Clément

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Clément Lassieur]

Mark H Weaver  writes:

> Hi Joshua,
>
> Joshua Branson  writes:
>> Maybe I'm being really silly, but don't you just do a guix pull as a
>> root user not as a normal user?
>
> No.  Guix is not like most distros where you have to be root to update
> the package list, and where root's package list is used by all other
> users.

Well, if guix-daemon points to root's profile (as it should if you
followed the documentation), you would need to do a guix pull as root in
order to update it.  I've no idea if it'll solve the problem though.

> In the Guix model, each user has their own version of Guix and its
> package list.  When a user runs "guix pull", it only updates Guix for
> that particular user, by changing the symlink ~/.config/guix/latest.
>
> If root runs "guix pull", it only updates the package list for root, by
> changing the symlink ~root/.config/guix/latest.
>
> Regards,
>   Mark

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Marius Bakke <mba...@fastmail.com> writes:

> Pierre Neidhardt <ambre...@gmail.com> writes:
>
>> Clément Lassieur <clem...@lassieur.org> writes:
>>
>>> Pierre Neidhardt <ambre...@gmail.com> writes:
>>>
>>>> vsftp: Very Secure FTP daemon
>>>> Upstream URL:  https://security.appspot.com/vsftpd.html
>>>> (It seems that there is not a single FTP server on Guix.  Strange... Can 
>>>> anyone
>>>> recommend anything better than vsftp for file sharing?  Not necessarily
>>>> FTP.)
>>>
>>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>>> and it runs over SSH.
>>
>> My use-case is the following: share files with random people with
>> zero-configuration on their end.  Because FTP is supported by most web
>> browsers it is one of the most available options I think.
>>
>> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
>> into that...
>
> I often start a HTTP server with `guix environment` for quick and dirty
> network sharing of the current directory:
>
> $ guix environment -C -N --ad-hoc python -- python3 -m http.server
>
> I suppose "wget" would be able to mass-download.

And there is 'woof' (packaged by Guix), it's a small HTTP server too,
very handy.  I use it very often at work to share files with my
collegues.  It serves the file only once unless specifed otherwise, and
'woof -U' provides an upload form, so that users can upload files
without having to install anything.  And it auto-tar directories.

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Pierre Neidhardt  writes:

> vsftp:Very Secure FTP daemon
> Upstream URL: https://security.appspot.com/vsftpd.html
> (It seems that there is not a single FTP server on Guix.  Strange... Can 
> anyone
> recommend anything better than vsftp for file sharing?  Not necessarily
> FTP.)

There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
and it runs over SSH.

Re: invoking info guix

[Clément Lassieur]

Catonano  writes:

> In a terminal I can issue this command
>
> ~$ info guix
>
> and have the guuix manual pop up
>
> In Emacs I can do
>
> M-x info
>
> but then I find myself in a general page, a sort of index and I have to
> search through it in order to find the guix "link"
>
> How can I end up in the Guix manual front page directly even when using
> Emacs ?
>
> Thanks

Hi Catonano,

As Arun and Oleg said, 'm' is very useful (maybe with C-u), and 'd'
too.  And there is the 'info-display-manual' command too.

But what you should really do (in my humble opinion :-)) is to read the
(info "info") manual.  It is very well done and explains everything in
an interactive way.

Clément

Re: Installation: Load non-free wifi firmware (iwlwifi)

[Clément Lassieur]

Pierre Neidhardt  writes:

> This was posted before:
>
> https://lists.gnu.org/archive/html/help-guix/2017-01/msg00041.html
>
> Unfortunately, I'm not able to acquire a wifi dongle at the moment.
> As far as I understand, linux-libre turns off the ability to load
> non-free firmware.  Why is it so?
>
> Is it possible to re-enable the feature?
> If not, are there other ways around the issue?

Hi Pierre,

Guix allows one to customize their packages through inheritance.  You
could create a custom linux package that inherits Guix's linux-libre,
with, say a differente source.  When linux-libre is updated, my-linux
would be updated as well, since it inherits linux-libre.  Thus, you
would have no maintainance to do.

(define-public my-linux
  (package
(inherit linux-libre)
(name "my-linux")
(source ...)))

This custom package's definition needs to be within GUIX_PACKAGE_PATH.
See
https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules
for more information.

Clément

Re: Herd seemed to fail to stop the 'postgres' service

[Clément Lassieur]

Jukka  writes:

> Someone on the IRC channel told me to post this here.
>
> But basically I've installed 'postgresql-service' in a system config, like 
> this:
>
>   (postgresql-service
>#:config-file (local-file "../psql/postgresql.conf")
>#:data-directory "/data/psql"
>#:locale "en_US.utf8")
>   %base-services)))
>
> I changed the contents of postgresql.conf (again), and re-ran "sudo guix 
> system reconfigure".
>
> Then I wanted to stop the postgres service, and I believe I ran: "sudo herd 
> stop postgres".
>
> The first time I did that, Herd told me it stopped postgres, but when called 
> again, this happens:
>
> ~$ sudo herd stop postgres
> herd: service 'postgres' could not be found
>
> (Why would the service "not be found", if it's installed?)

Hi Jukka,

This is a bug with the 'postgres' service: it does not stop.  I reported
it there:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29992

Thank you,
Clément

Re: guix pull fails on powerful server

[Clément Lassieur]

Ricardo Wurmus  writes:

> Is there another work-around I could try on this machine?

My workaround was to build Guix from sources.  But I'm sure you thought
about it.

Re: guix pull fails on powerful server

[Clément Lassieur]

I got it too for the first time yesterday on my 128G RAM and 32 CPU
cores server:

--8<---cut here---start->8---
substitute: updating list of substitutes from [...]
Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit 3140844e33254316348135b03762eaeb04764544...
substitute: updating list of substitutes from [...]
The following derivation will be built:
   /gnu/store/7143x1dd2r5kch8dldyylz1ljhp3nird-guix-latest.drv
copying and compiling to 
'/gnu/store/8a42yc4yxslrr1hf7wk5x5mddbs76yqm-guix-latest' with Guile 2.2.2...
loading...   25.3% of 632 filesrandom seed for tests: 1506279202
loading...   99.8% of 632 files
compiling... 94.8% of 632 filesice-9/threads.scm:289:22: In procedure loop:
ice-9/threads.scm:289:22: Syntax error:
guix/gexp.scm:530:8: return: return used outside of 'with-monad' in form 
(return output)

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for `/gnu/store/7143x1dd2r5kch8dldyylz1ljhp3nird-guix-latest.drv' 
failed with exit code 1
guix pull: error: build failed: build of 
`/gnu/store/7143x1dd2r5kch8dldyylz1ljhp3nird-guix-latest.drv' failed
--8<---cut here---end--->8---

And then, today, again:

--8<---cut here---start->8---
substitute: updating list of substitutes from [...]
Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit 0960ba75233ae5b6c539f43d97d06d64e9ad...
substitute: updating list of substitutes from [...]
The following derivation will be built:
   /gnu/store/dmv64icdan1fqrl00czgwx1an923fzda-guix-latest.drv
copying and compiling to 
'/gnu/store/slqcrr5gwhi1zqv21wjp0l973zs3dywc-guix-latest' with Guile 2.2.2...
loading...   25.3% of 632 filesrandom seed for tests: 1506327995
loading...   99.8% of 632 files
compiling... 94.8% of 632 filesice-9/threads.scm:289:22: In procedure loop:
ice-9/threads.scm:289:22: Syntax error:
guix/gexp.scm:539:10: return: return used outside of 'with-monad' in form 
(return (derivation->output-path drv))

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for `/gnu/store/dmv64icdan1fqrl00czgwx1an923fzda-guix-latest.drv' 
failed with exit code 1
guix pull: error: build failed: build of 
`/gnu/store/dmv64icdan1fqrl00czgwx1an923fzda-guix-latest.drv' failed
--8<---cut here---end--->8---

Re: mcron job with cd to directory?

[Clément Lassieur]

ng0  writes:

> Ludovic Courtès transcribed 0.9K bytes:

>> Something like:
>> 
>>   #~(job '(next-hour '(4))
>>   (lambda ()
>> (chdir …)
>> (system* …)))
>> 
>> See 
>> .
>> 
>> Ludo’.
>> 
>
> Thanks! This fixed at least the respawn-death of mcron. Now I just have to
> see if it does what I want.

I have found the '--schedule' option of mcron very useful for debugging.
Maybe it'll help you to see if it does what you want.

> But it's good to know that it is that easy.