Re: avoid wrapper scripts when possible

[John Kehayias]

Related is #50798 which I just filed 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50789 This is a similar issue in 
the executable path picked up by a program (finding the -real one) and using 
that for writing a .desktop file.

Not sure if there is anything more general to do here, other than having to 
find these cases and patch manually? Is there a preferred way of making these 
patches?

Thanks,
John

Re: guix environment --load vs. --file inconsistency

[Robin Templeton]

Ludovic Courtès  writes:

> Hi Attila,
>
> Attila Lendvai  skribis:
>
>> i was writing the documentation of a guix.scm file, and i realized that 
>> there's an inconsistency among the three most used commands in this context:
>>
>> so, there's:
>> - guix build --file
>> - guix package --file
>>
>> and then there's:
>> - guix environment --load
>> - guix pack # has neither
>>
>> i'd propose to change guix environment to also use --file, but maybe i'm 
>> overlooking something, so, please speak up if you think it's a bad idea!
>>
>> i never used guix pack, but maybe that also deserves a --file argument?
>
> Good point.  ‘--file’ predates ‘--manifest’; we could perhaps deprecate
> ‘--file’ in favor of ‘--manifest’, though I think there’s one special
> case not handled elsewhere:
>
>   guix build -f foo.json
>
> We need to do something about it.
>
> ‘guix environment --load’ could be similarly deprecated, either to be
> eventually removed or to be renamed to ‘--file’.
>
> Thoughts?

FWIW, I use 'guix build -f' all the time, 'guix package -f'
occasionally, and 'guix environment -l' once in a while, too -- much
more frequently than the manifest-oriented versions. (And I do find it
confusing that 'environment' uses '-l' rather than '-f'; IMHO it would
be a nice improvement for UI consistency to have '-f'/'--file' permitted
as an alternative for '-l'/'--load' there.) I often write simple
packages in individual files, outside of the guix repo or any kind of
proper channel setup, and I don't see much point in requiring every such
package to have its own single-package manifest, although it wouldn't be
too difficult if it were required (just extra boilerplate for standalone
package files).

Re: Please explain these fundamental terms to me?

[Sage Gerard]

Excuse my mistake in missing the definition of binary seed mentioned here 
"opaque ascii or binary seeds that are injected during build time." Disregard 
that part.

On 9/24/21 2:35 PM, Sage Gerard wrote:

> Hello!
>
> I'm confused about fundamental definitions from the manual.
>
>> Possibly one of the most harmless, but certainly by far the biggest binary 
>> seed that all software distributions inject are the so [called] bootstrap 
>> binary seed. Bootstrap binaries are the initial binary seeds that are used 
>> to start building the distribution. -- 
>> https://www.gnu.org/software/mes/manual/html_node/Bootstrappable-Builds.html
>
> This definition of bootstrap binary seeds confused me because
>
> - "Binary seed" itself is not defined. After some searching, my understanding 
> is that this is a verified binary you inject among source code to produce 
> more software. Is that correct?
> - it switches from singular to plural form. "The biggest binary seed is the 
> bootstrap binary seed", followed by "Bootstrap binaries are the initial 
> binary seeds." How do these sentences reconcile?
>
> Also, in reading section 1.4 I didn't come away knowing what a full source 
> bootstrap even is. Does that mean you reproduce the hex0 binary, and then use 
> progressive stages to eventually reproduce the source code for a version of 
> Guix? Or does it mean that you reproduce an exact disk image for an OS for 
> the same CPU architecture as the hex program, with a copy of the Guix source 
> ready to go on that system?

Please explain these fundamental terms to me?

[Sage Gerard]

Hello!

I'm confused about fundamental definitions from the manual.

> Possibly one of the most harmless, but certainly by far the biggest binary 
> seed that all software distributions inject are the so [called] bootstrap 
> binary seed. Bootstrap binaries are the initial binary seeds that are used to 
> start building the distribution. -- 
> https://www.gnu.org/software/mes/manual/html_node/Bootstrappable-Builds.html

This definition of bootstrap binary seeds confused me because

- "Binary seed" itself is not defined. After some searching, my understanding 
is that this is a verified binary you inject among source code to produce more 
software. Is that correct?
- it switches from singular to plural form. "The biggest binary seed is the 
bootstrap binary seed", followed by "Bootstrap binaries are the initial binary 
seeds." How do these sentences reconcile?

Also, in reading section 1.4 I didn't come away knowing what a full source 
bootstrap even is. Does that mean you reproduce the hex0 binary, and then use 
progressive stages to eventually reproduce the source code for a version of 
Guix? Or does it mean that you reproduce an exact disk image for an OS for the 
same CPU architecture as the hex program, with a copy of the Guix source ready 
to go on that system?

Guix Packaging Meetup - Tommorrow (Saturday) from 14:00 ET (18:00 PM UTC)

[jgart]

Hi Guixers!

I'd like to invite you to a guix packaging meetup tomorrow (Saturday) Sep 25 at 
14:00 ET (18:00 PM UTC).

Meetup Link (no password): 

https://meet.jit.si/guix-meetup

Hope to see you there!

jgart

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

Xinglu Chen schreef op vr 24-09-2021 om 17:39 [+0200]:
> 
[...]
> I didn’t know about the parent mechanism; that could be an approach to
> take.  But since ‘define-configuration’ is based on (guix records),
> would it make sense to adapt (guix records) to (rnrs records syntactic)
> instead of SRFI-9 records?

(rnrs records syntactic) or the underlying mechanism for (srfi srfi-9) and
(rnrs records syntactic) (search for record-modifier in the guile manual).

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: IT jobs in Switzerland OFF TOPIC JOKE

[Jonathan McHugh]

(I got this mail from other channels, bleurgh...).

Zig, Switzerland would be more cool.

CVs are only accepted in APL format.


Jonathan McHugh
indieterminacy@libre.brussels

September 24, 2021 5:22 PM, "Joshua Branson"  wrote:

> Gábor Boskovits  writes:
> 
>> Hello guix,
>> 
>> The firm where I am working now is hiring.
>> 
>> Location: Zug, Switzerland. People willing to work in office will be 
>> preferred. The firm helps with
>> relocation if needed.
>> 
>> Profile: HFT crypto startup
>> 
>> Codebase: c++, python
>> Tooling: k8s, gitlab
> 
> I'm an expert ping pong player, and master mattress tester. You may
> have heard of me. I should warn you...I am expensive to hire. :)
> 
>> Positions: quantitative trader, quantitative researcher, c++ developer, 
>> devops
>> 
>> Experience with AWS is a plus.
>> 
>> If someone is willing to give this a try, please come back to me and I can 
>> provide more details.
>> 
>> Regards,
>> g_bor
> 
> P.S. I'm just kidding this job description is a little beyong me, but
> best of luck recruiting talented people!
> 
> --
> Joshua Branson (jab in #guix)
> Sent from Emacs and Gnus
> https://gnucode.me
> https://video.hardlimit.com/accounts/joshua_branson/video-channels
> https://propernaming.org
> "You can have whatever you want, as long as you help
> enough other people get what they want." - Zig Ziglar

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Xinglu Chen]

On Fri, Sep 24 2021, Maxime Devos wrote:

> Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
>> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>> 
>> > Hi,
>> > 
>> > Xinglu Chen  skribis:
>> > 
>> > > Some services might be useful to have in both Guix System and Guix Home;
>> > > for instance, Guix System currently has a service for configuring
>> > > Syncthing, and I think it makes sense to also have one for Guix Home,
>> > > this would mean that people not using Guix System (me :-)) could also
>> > > have Guix manage Syncthing.  With the current approach, we would have to
>> > > copy and paste quite a bit of code, and if the Syncthing service for
>> > > Guix System changes, then the one for Guix Home might have to change as
>> > > well.
>> > 
>> > Silly question, but why do we need to have two different configuration
>> > record types in the first place?
>> 
>> The problem is that the configuration records for system and home
>> service don’t necessarily have the same fields.  The Syncthing service
>> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
>> any use in Guix Home, as the only user would be the user invoking ‘guix
>> home’.
>> 
>> > Sharing configuration between Home and System sounds important to me: it
>> > means users can easily move services from one to the other, which is
>> > pretty big deal.  It also means we’d have much less code to maintain.
>> 
>> Agreed, that’s what I would like to see as well.
>> 
>> > Would that be feasible?  (Apologies if this has already been
>> > discussed!)
>> 
>> Since it might not make sense to have the same records fields for a
>> system service and home service, I proposed (in the mail you replied to)
>> a ‘define-configuration’ form that would generate a configuration record
>> for a system service and optionally one for a home service, without
>> having to maintain two records separately.
>> 
>> --8<---cut here---start->8---
>> (define-configuration syncthing-configuration
>>   (package
>>(package syncthing)
>>"Syncthing package to use.")
>>   (arguments
>>(list-of-strings ’())
>>"Command line arguments to pass to the Syncthing package.")
>>   (log-flags
>>(integer 0)
>>"Sum of logging flags.")
>>   (user
>>(maybe-string 'disabled)
>>"The user as which the Syncthing service is to be run."
>>(home-service? #f))  ; not for Guix Home
>>   (group
>>(string "users")
>>"The group as which the Syncthing service is to be run."
>>(home-service? #f))  ; likewise ^^
>>   (home
>>(maybe-string 'disabled)
>>"Common configuration and data directory.")
>>   (home-service? #t))
>> --8<---cut here---end--->8---
>> 
>> It would generate  and
>> .  The only difference being that
>>  doesn’t have a ‘user’ and a ‘group’
>> field.
>
> The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
> here (after adapting it to define-configuration), to define three record 
> types:
>
> The record type with all fields common to the home configuration and system 
> configuration
> ( + common-syncthing-configuration?)
> and the record types for the home and system configuration
> ( + syncthing-configuration? and 
> 
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and 
> home-syncthing-configuration?
> are common-syncthing-configuration?.

I didn’t know about the parent mechanism; that could be an approach to
take.  But since ‘define-configuration’ is based on (guix records),
would it make sense to adapt (guix records) to (rnrs records syntactic)
instead of SRFI-9 records?



signature.asc
Description: PGP signature

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Joshua Branson]

Xinglu Chen  writes:

> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Xinglu Chen  skribis:
>>
>>> Some services might be useful to have in both Guix System and Guix Home;
>>> for instance, Guix System currently has a service for configuring
>>> Syncthing, and I think it makes sense to also have one for Guix Home,
>>> this would mean that people not using Guix System (me :-)) could also
>>> have Guix manage Syncthing.  With the current approach, we would have to
>>> copy and paste quite a bit of code, and if the Syncthing service for
>>> Guix System changes, then the one for Guix Home might have to change as
>>> well.
>>
>> Silly question, but why do we need to have two different configuration
>> record types in the first place?
>
> The problem is that the configuration records for system and home
> service don’t necessarily have the same fields.  The Syncthing service
> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
> any use in Guix Home, as the only user would be the user invoking ‘guix
> home’.

Apologies if I'm speaking for something I know very little
about...Wouldn't it be nice if guix home services would accept a user
and a group field?  For the syncthing service, perhaps the user wants to
limit Syncthing's runtime permissions.  So instead of running as the
user, the user would run synthing as a different user with less permissions?

Please note it may be much better to just container-ize the synthing
service.  Does guix home have that ability?

https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/

>
>> Sharing configuration between Home and System sounds important to me: it
>> means users can easily move services from one to the other, which is
>> pretty big deal.  It also means we’d have much less code to maintain.
>
> Agreed, that’s what I would like to see as well.
>
>> Would that be feasible?  (Apologies if this has already been
>> discussed!)
>
> Since it might not make sense to have the same records fields for a
> system service and home service, I proposed (in the mail you replied to)
> a ‘define-configuration’ form that would generate a configuration record
> for a system service and optionally one for a home service, without
> having to maintain two records separately.
>
> (define-configuration syncthing-configuration
>   (package
>(package syncthing)
>"Syncthing package to use.")
>   (arguments
>(list-of-strings ’())
>"Command line arguments to pass to the Syncthing package.")
>   (log-flags
>(integer 0)
>"Sum of logging flags.")
>   (user
>(maybe-string 'disabled)
>"The user as which the Syncthing service is to be run."
>(home-service? #f))  ; not for Guix Home
>   (group
>(string "users")
>"The group as which the Syncthing service is to be run."
>(home-service? #f))  ; likewise ^^
>   (home
>(maybe-string 'disabled)
>"Common configuration and data directory.")
>   (home-service? #t))
>
> It would generate  and
> .  The only difference being that
>  doesn’t have a ‘user’ and a ‘group’
> field.
>
> It’s probably going to be quite complicated, so it would be good to get
> some feedback/thoughts on it.  Cc Maxim since he has done some work with
> (gnu services configuration).
>
> Also, it’s probably time to properly document (gnu services
> configuration) in the manual.  ;-)
>
>> Also, I proposed earlier a possible way to generate a Home service type
>> from the corresponding System service type—or, IOW, to generate a Home
>> service type graph from the System graph.  Does that sound feasible?
>
> I am not sure exactly what you mean here, could you elaborate?
>

-- 
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

Re: IT jobs in Switzerland OFF TOPIC JOKE

[Joshua Branson]

Gábor Boskovits  writes:

> Hello guix,
>
> The firm where I am working now is hiring.
>
> Location: Zug, Switzerland. People willing to work in office will be 
> preferred. The firm helps with relocation if needed.
>
> Profile: HFT crypto startup
>
> Codebase: c++, python
> Tooling: k8s, gitlab

I'm an expert ping pong player, and master mattress tester.  You may
have heard of me.  I should warn you...I am expensive to hire.  :)

>
> Positions: quantitative trader, quantitative researcher, c++ developer, devops
>
> Experience with AWS is a plus.
>
> If someone is willing to give this a try, please come back to me and I can 
> provide more details.
>
> Regards,
> g_bor
>

P.S.  I'm just kidding this job description is a little beyong me, but
best of luck recruiting talented people!

-- 
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
> On Thu, Sep 23 2021, Ludovic Courtès wrote:
> 
> > Hi,
> > 
> > Xinglu Chen  skribis:
> > 
> > > Some services might be useful to have in both Guix System and Guix Home;
> > > for instance, Guix System currently has a service for configuring
> > > Syncthing, and I think it makes sense to also have one for Guix Home,
> > > this would mean that people not using Guix System (me :-)) could also
> > > have Guix manage Syncthing.  With the current approach, we would have to
> > > copy and paste quite a bit of code, and if the Syncthing service for
> > > Guix System changes, then the one for Guix Home might have to change as
> > > well.
> > 
> > Silly question, but why do we need to have two different configuration
> > record types in the first place?
> 
> The problem is that the configuration records for system and home
> service don’t necessarily have the same fields.  The Syncthing service
> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
> any use in Guix Home, as the only user would be the user invoking ‘guix
> home’.
> 
> > Sharing configuration between Home and System sounds important to me: it
> > means users can easily move services from one to the other, which is
> > pretty big deal.  It also means we’d have much less code to maintain.
> 
> Agreed, that’s what I would like to see as well.
> 
> > Would that be feasible?  (Apologies if this has already been
> > discussed!)
> 
> Since it might not make sense to have the same records fields for a
> system service and home service, I proposed (in the mail you replied to)
> a ‘define-configuration’ form that would generate a configuration record
> for a system service and optionally one for a home service, without
> having to maintain two records separately.
> 
> --8<---cut here---start->8---
> (define-configuration syncthing-configuration
>   (package
>(package syncthing)
>"Syncthing package to use.")
>   (arguments
>(list-of-strings ’())
>"Command line arguments to pass to the Syncthing package.")
>   (log-flags
>(integer 0)
>"Sum of logging flags.")
>   (user
>(maybe-string 'disabled)
>"The user as which the Syncthing service is to be run."
>(home-service? #f))  ; not for Guix Home
>   (group
>(string "users")
>"The group as which the Syncthing service is to be run."
>(home-service? #f))  ; likewise ^^
>   (home
>(maybe-string 'disabled)
>"Common configuration and data directory.")
>   (home-service? #t))
> --8<---cut here---end--->8---
> 
> It would generate  and
> .  The only difference being that
>  doesn’t have a ‘user’ and a ‘group’
> field.

The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
here (after adapting it to define-configuration), to define three record types:

The record type with all fields common to the home configuration and system 
configuration
( + common-syncthing-configuration?)
and the record types for the home and system configuration
( + syncthing-configuration? and 

+ home-syncthing-configuration?).

Using this mechanism, all syncthing-configuration? and 
home-syncthing-configuration?
are common-syncthing-configuration?.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Merging wip-guix-home to master

[Xinglu Chen]

On Thu, Sep 23 2021, Andrew Tropin wrote:

> The core part of Guix Home project has been moved from rde
> repository[fn:1] to wip-guix-home branch of guix repository.
>
> I'm about a week on wip-guix-home branch completely and Guix Home works
> fine.  There are no any major issues on rde-devel and guix-devel mailing
> lists and it seems that branch is ready to be merged.
>
> My guix describe looks like:
> --8<---cut here---start->8---
> Generation 114Sep 17 2021 13:33:55(current)
>   rde 31f8003
> repository URL: https://git.sr.ht/~abcdw/rde
> branch: without-guix-home
> commit: 31f800353a781cef25fc80c05ad824a068a049c8
>   guix a2324d8
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: wip-guix-home
> commit: a2324d8b56eabf8117bca220a507cc791edffd2e
> --8<---cut here---end--->8---
>
>
> There is a discussion[fn:2] on moving home services to (gnu services
> ...)  modules, which is likely to happen, but it's possible to do the
> migration relatively painless by re-exporting necessary symbols in
> (gnu home-services ...) at first and removing them completely later.
>
> Another important part of the work related to Guix Home project is
> covering related modules and cli with tests, but it can be done in
> parallel and is not a blocker for merging.

I noticed that the ‘guix home import’ subcommand is included, but I
think it needs more thought and feedback from people before it makes its
way into ‘master’; it also seems to lack documentation.

I just realized that it generates the following service declaration

--8<---cut here---start->8---
(service
 home-bash-service-type
 (home-bash-configuration
  (bashrc
   (list (slurp-file-gexp
  (local-file "/home/yoctocell/.bashrc"))
--8<---cut here---end--->8---

but when running ‘guix home reconfigure’, the ~/.bashrc file will be
moved, so when running ‘guix home reconfigure’ for the second time, it
would read the ~/.bashrc which is itself a symlink to a file the store.
‘guix home import’ clearly isn’t in a usable state as of right now…



signature.asc
Description: PGP signature

Re: guix environment --load vs. --file inconsistency

[zimoun]

Hi,

On Thu, 23 Sept 2021 at 22:49, Ludovic Courtès  wrote:

> ‘guix environment --load’ could be similarly deprecated, either to be
> eventually removed or to be renamed to ‘--file’.

I would like to point this really really long thread [1] about
modifying the CLI vs backward compatibilities.

1: 

Cheers,
simon

Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Xinglu Chen]

On Thu, Sep 23 2021, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen  skribis:
>
>> Some services might be useful to have in both Guix System and Guix Home;
>> for instance, Guix System currently has a service for configuring
>> Syncthing, and I think it makes sense to also have one for Guix Home,
>> this would mean that people not using Guix System (me :-)) could also
>> have Guix manage Syncthing.  With the current approach, we would have to
>> copy and paste quite a bit of code, and if the Syncthing service for
>> Guix System changes, then the one for Guix Home might have to change as
>> well.
>
> Silly question, but why do we need to have two different configuration
> record types in the first place?

The problem is that the configuration records for system and home
service don’t necessarily have the same fields.  The Syncthing service
for Guix System has a ‘user’ and a ‘group’ field, which is not really of
any use in Guix Home, as the only user would be the user invoking ‘guix
home’.

> Sharing configuration between Home and System sounds important to me: it
> means users can easily move services from one to the other, which is
> pretty big deal.  It also means we’d have much less code to maintain.

Agreed, that’s what I would like to see as well.

> Would that be feasible?  (Apologies if this has already been
> discussed!)

Since it might not make sense to have the same records fields for a
system service and home service, I proposed (in the mail you replied to)
a ‘define-configuration’ form that would generate a configuration record
for a system service and optionally one for a home service, without
having to maintain two records separately.

--8<---cut here---start->8---
(define-configuration syncthing-configuration
  (package
   (package syncthing)
   "Syncthing package to use.")
  (arguments
   (list-of-strings ’())
   "Command line arguments to pass to the Syncthing package.")
  (log-flags
   (integer 0)
   "Sum of logging flags.")
  (user
   (maybe-string 'disabled)
   "The user as which the Syncthing service is to be run."
   (home-service? #f))  ; not for Guix Home
  (group
   (string "users")
   "The group as which the Syncthing service is to be run."
   (home-service? #f))  ; likewise ^^
  (home
   (maybe-string 'disabled)
   "Common configuration and data directory.")
  (home-service? #t))
--8<---cut here---end--->8---

It would generate  and
.  The only difference being that
 doesn’t have a ‘user’ and a ‘group’
field.

It’s probably going to be quite complicated, so it would be good to get
some feedback/thoughts on it.  Cc Maxim since he has done some work with
(gnu services configuration).

Also, it’s probably time to properly document (gnu services
configuration) in the manual.  ;-)

> Also, I proposed earlier a possible way to generate a Home service type
> from the corresponding System service type—or, IOW, to generate a Home
> service type graph from the System graph.  Does that sound feasible?

I am not sure exactly what you mean here, could you elaborate?



signature.asc
Description: PGP signature

Re: Guix, ispell.el and FHS

[Liliana Marie Prikler]

Hi,

Am Freitag, den 24.09.2021, 11:51 + schrieb Ekaitz Zarraga:
> Hi Andre
> 
> > I'm relatively new to the GNU/Linux world, so I apologise for any
> > silliness.
> > 
> > I was looking ispell.el and saw:
> > 
> > --8<---cut here---start->8---
> > (defcustom ispell-look-command
> >   (cond ((file-exists-p "/bin/look") "/bin/look")
> > ((file-exists-p "/usr/local/bin/look") "/usr/local/bin/look")
> > ((file-exists-p "/usr/bin/look") "/usr/bin/look")
> > (t "look"))
> >   "Name of the look command for search processes.
> > This must be an absolute file name."
> >   :type 'file
> >   :group 'ispell)
> > --8<---cut here---end--->8---
> > 
> > That's the usual path for most GNU/Linus distro (FHS
> > compliant).  But for Guix System users it lives at /run/current-
> > system/profile/bin/look.
> > 
> > It's obvious I can set the variable properly myself.
> > 
> > My question is: what should be done in such cases?  I can think of
> > the following:
> > 
> > - Patch the Guix package
> > - Patch the program itself
> > - Nothing (apart from setting things myself)
> > 
> > Thank you.
> 
> I'm not a Guix maintainer or anything so get this with a pinch of
> salt.
> 
> First the program itself should be able to find this stuff in a more
> general way, not just checking some specific folders.
"Finding things in a more general way" typically means inspecting
search paths or something, which *may work*, but should not be a
requirement for a program to function.  In particular, if this look-
command is important (can't say that it is, but I'm only using ispell
through flyspell, so ymmv).

> Second, if the program does not add that change we can patch the guix
> package too.
In particular, to substitute variables like this we do have both emacs-
substitute-sexps and emacs-substitute-variables and with ~60 uses it
does have some relevance.

Cheers

Re: Guix, ispell.el and FHS

[Ekaitz Zarraga]

Hi Andre

> I'm relatively new to the GNU/Linux world, so I apologise for any silliness.
>
> I was looking ispell.el and saw:
>
> --8<---cut here---start->8---
> (defcustom ispell-look-command
>   (cond ((file-exists-p "/bin/look") "/bin/look")
>   ((file-exists-p "/usr/local/bin/look") "/usr/local/bin/look")
>   ((file-exists-p "/usr/bin/look") "/usr/bin/look")
>   (t "look"))
>   "Name of the look command for search processes.
> This must be an absolute file name."
>   :type 'file
>   :group 'ispell)
> --8<---cut here---end--->8---
>
> That's the usual path for most GNU/Linus distro (FHS compliant).  But
> for Guix System users it lives at /run/current-system/profile/bin/look.
>
> It's obvious I can set the variable properly myself.
>
> My question is: what should be done in such cases?  I can think of the
> following:
>
> - Patch the Guix package
> - Patch the program itself
> - Nothing (apart from setting things myself)
>
> Thank you.


I'm not a Guix maintainer or anything so get this with a pinch of salt.

First the program itself should be able to find this stuff in a more general
way, not just checking some specific folders.

Second, if the program does not add that change we can patch the guix package
too.

Cheers,

Ekaitz

Re: data.guix.gnu.org problem with revision 33d2574

[zimoun]

Hi Chris,

On Tue, 21 Sep 2021 at 21:31, Christopher Baines  wrote:

>> A question. :-) The “Builds” field shows bordeaux.guix.gnu.org and not
>> ci.guix.gnu.org, right?  Does data.guix.gnu.org still process Berlin?
>
> Correct, the version of Cuirass currently deployed on ci.guix.gnu.org
> doesn't support sending data to the Guix Data Service.

Thanks for the information.

Has something changed on the Cuirass side?  Or conversely on Data
Service side?

Cheers,
simon

Re: data.guix.gnu.org problem with revision 33d2574

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> guix-data-service: computing the derivation-file-name for mips64el-linux
>> Computing Guix derivation for 'mips64el-linux'...
>
> [...]
>
>> @ build-started
>> /gnu/store/l89jsjd4881jv5pgc06z76vfw02hr7xs-guile-bootstrap-2.0.drv
>> - mips64el-linux
>> /var/log/guix/drvs/l8//9jsjd4881jv5pgc06z76vfw02hr7xs-guile-bootstrap-2.0.drv.bz2
>> 28674
>> @ build-started
>> /gnu/store/ibk4hi6nxsh2j0v69i5fc55lw923s98z-gcc-4.8.2.tar.xz.drv -
>> mips64el-linux
>> /var/log/guix/drvs/ib//k4hi6nxsh2j0v69i5fc55lw923s98z-gcc-4.8.2.tar.xz.drv.bz2
>> 28680
>> Downloading 
>> https://ci.guix.gnu.org/nar/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz...
>> . linux-libre-4.14.67-gnu.tar.xz 94.7MiB 0B/s 00:00 [ ]
>> 0.0%. linux-libre-4.14.67-gnu.tar.xz 94.7MiB 62KiB/s 00:00 [ ]
>> 0.0%@ unsupported-platform
>> /gnu/store/l89jsjd4881jv5pgc06z76vfw02hr7xs-guile-bootstrap-2.0.drv
>> mips64el-linux
>> while setting up the build environment: a `mips64el-linux' is
>> required to build
>> `/gnu/store/l89jsjd4881jv5pgc06z76vfw02hr7xs-guile-bootstrap-2.0.drv',
>> but I am a `x86_64-linux'
>> builder for 
>> `/gnu/store/l89jsjd4881jv5pgc06z76vfw02hr7xs-guile-bootstrap-2.0.drv' failed 
>> with exit code 1
>
> It seems to be working as expected, no?  Computing the derivation for
> mips64el-linux entails building mips64el-linux derivations (due to
> grafts), and that fails.

Well, it's subtle that things are quite wrong. There's this bit, which
looks fine:

  Authenticating channel 'guix', commits 9edb3f6 to 33d2574 (1 new commits)...

Later on though, this is one of the clearer signs that whatever being
processed doesn't actually correspond to that revision:

  warning: no (guix lint) module found


signature.asc
Description: PGP signature

Guix, ispell.el and FHS

[André A . Gomes]

Hi Guix,

I'm relatively new to the GNU/Linux world, so I apologise for any silliness.

I was looking ispell.el and saw:

--8<---cut here---start->8---
(defcustom ispell-look-command
  (cond ((file-exists-p "/bin/look") "/bin/look")
((file-exists-p "/usr/local/bin/look") "/usr/local/bin/look")
((file-exists-p "/usr/bin/look") "/usr/bin/look")
(t "look"))
  "Name of the look command for search processes.
This must be an absolute file name."
  :type 'file
  :group 'ispell)
--8<---cut here---end--->8---

That's the usual path for most GNU/Linus distro (FHS compliant).  But
for Guix System users it lives at /run/current-system/profile/bin/look.

It's obvious I can set the variable properly myself.

My question is: what should be done in such cases?  I can think of the
following:

- Patch the Guix package
- Patch the program itself
- Nothing (apart from setting things myself)

Thank you.


--
André A. Gomes
"Free Thought, Free World"

Re: “What’s in a package”

[Ludovic Courtès]

Hello,

Katherine Cox-Buday  skribis:

> That sounds like a great start. I tossed out some other ideas elsewhere in 
> the thread. Most of them involve meta-inspection of the package, Guix 
> ecosystem, runtime environment and logs. It would be nice in general to have 
> a kind of "agent" that you could run repeatedly over the course of packaging 
> that would suggest next steps on ~stderr~ and next logical packaging 
> definition on ~stdout~. Kind of like pair-programming with Guix :)
>
> It would perform different operations dependent on what stage in the 
> life-cycle the package is at, i.e. ~import~ when no package definition 
> exists, build when one does, and possibly running the result in a container 
> when the package build succeeds.
>
> E.g. your PyTorch example, starting from scratch (note: ~guix import~ may not 
> always feel like the right command to invoke in this example. This may be 
> some larger concept than import; also, the example always redirects to 
> package.scm for brevity, but the user would probably want to look at it 
> first):
>
> #+begin_example
>   $ guix import upstream pytorch
>
>   stderr: This looks like it might be python package (heuristics.scm:123 - 
> package name starts with py), try this instead:
>   stdout: guix import upstream pypi pytorch

[...]

I like these ideas!

> etc., etc. Typing that out, it feels dangerously close to Microsoft's Clippy, 
> but hopefully more helpful :)

Heh, Clippy was cute.  ;-)

> Heuristics, by definition, wouldn't be correct all the time, but this kind of 
> thing could help new contributors (or experienced contributors with bad 
> memories like me!), and in some cases actually do some of the programming.
>
> And every time someone comes to the mailing list or IRC with a question, we 
> can ask ourselves if this is a common question, and maybe create a new 
> heuristic.

Agreed.

Let’s see if we can get there…

Thanks,
Ludo’.

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-23 22:08, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen  skribis:
>
>> Some services might be useful to have in both Guix System and Guix Home;
>> for instance, Guix System currently has a service for configuring
>> Syncthing, and I think it makes sense to also have one for Guix Home,
>> this would mean that people not using Guix System (me :-)) could also
>> have Guix manage Syncthing.  With the current approach, we would have to
>> copy and paste quite a bit of code, and if the Syncthing service for
>> Guix System changes, then the one for Guix Home might have to change as
>> well.
>
> Silly question, but why do we need to have two different configuration
> record types in the first place?

1. Different fields (for example system services in many cases wants to
know the username, which will be used to run process from, home services
will probably use the user's username and won't rely on this field, home
services on the other hand can have something like xdg-flavor? or
anything else unrelated to system services).

Even if fields are not conflicting with each other, it's very likely
that it will introduce a confusion: user of Guix Home on foreign distro
will be guessing why there is a field in configuration record, which
doesn't make sense for a home service.

2. Different default values.  $HOME/mail or /var/spool/mail? Even if we
can technically bypass those problems, semantically the values will be
incorrect.

There are possible solutions to that, like making home-extra-settings
and system-extra-settings fields, which will contain records with
fields, which are different for those services, but I'm not sure if all
the hussle is worth it.

>
> Sharing configuration between Home and System sounds important to me: it
> means users can easily move services from one to the other, which is
> pretty big deal.  It also means we’d have much less code to maintain.
>
> Would that be feasible?  (Apologies if this has already been discussed!)

I find records to be a very rigid and hard to reuse and probably we have
to have separate sets of configuration records as I mentioned earlier in
the thread, but the auxiliary functions seems quite reusable.

>
> Also, I proposed earlier a possible way to generate a Home service type
> from the corresponding System service type—or, IOW, to generate a Home
> service type graph from the System graph.  Does that sound feasible?

Not sure what you mean here, can you share a link to the proposal or
elaborate one more time, please.

>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-23 22:45, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>
> Yay!  I’d like to take another look (I know I’ve been terribly MIA,
> apologies!), and I hope other folks familiar with Guix System can
> comment as well.

Sure, let's wait for reviews/comments until next Thursday.

>
>> There is a discussion[fn:2] on moving home services to (gnu services
>> ...)  modules, which is likely to happen, but it's possible to do the
>> migration relatively painless by re-exporting necessary symbols in
>> (gnu home-services ...) at first and removing them completely later.
>
> I know it can be annoying to existing Guix Home users, but I’d prefer
> not to carry pre-merge baggage; that is, we’d just rename and not
> provide those modules under their former names at all.
>

Yep, it is very likely that it will be annoying, but I think it's
doable.  It should be a relatively simple migration for users.

>> Another important part of the work related to Guix Home project is
>> covering related modules and cli with tests, but it can be done in
>> parallel and is not a blocker for merging.
>
> Do you have ideas of a possible testing strategy?

Yep, I think we can do the same thing to tests/guix-system.sh, check
that `guix home build` provides desired results on simple configurations
and `guix home search` shows correct results on different input strings.

>
> We should be able to test at least the CLI, either arranging to avoid
> large builds (as in tests/guix-build.sh) or talking to the “real”
> guix-daemon (as in tests/guix-pack-relocatable.sh) if we’re going to
> need packages.
>
> It’d be great to have this part ready soonish.

I hope to work on it next week.

>
> The way I see it, in 1.4 (2.0?), we’d mark Guix Home as a “technology
> preview” in the manual with a prominent note.  That will allow us to get
> feedback from new users and to fine-tune code correspondingly, and
> that’ll make it clear to users that things are still subject to change.

Marked it as a subject to change in Home Configuration section of the
manual, patch in the reply to Oleg.

>
> Thoughts?
>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-23 10:27, Katherine Cox-Buday wrote:

> Andrew Tropin  writes:
>
>> The core part of Guix Home project has been moved from rde
>> repository[fn:1] to wip-guix-home branch of guix repository.
>>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>
> I just want to thank you for the work. I don't think I'll use this 
> everywhere, but it is definitely going to be helpful in some environments. 
> Thank you!

My pleasure)


signature.asc
Description: PGP signature