Re: Need help about guix home "home-run-on-first-login-service-type"

2024-08-06 Thread Marek Paśnikowski
Seems like Gnus cleaned up the message for me, so I can see a bit more.

"花不见海" <2694273...@qq.com> writes:

> (define download-ohmyzsh-install
>   (with-imported-modules '((guix build utils))
> #~(begin
> (use-modules (guix build utils))
> (invoke
>   "curl"
>   "-L"
>   
> "https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh";
>   "-O"
>   "install.sh")
> (invoke "sh" "install.sh"
>
> (home-environment
>   [packages ...]
>   (services
> (list
>   (service home-run-on-first-login-service-type download-ohmyzsh-install)
>   (service home-zsh-service-type (home-zsh-configuration)
>

I tried to refute the service declaration by looking at the service
source code, but I was not able to find any issues this way.

> \builder for `/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv' failed 
> with exit code 1
> build of /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv failed
> View build log at 
> '/var/log/guix/drvs/3s/zcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv.gz'.

This line here, "View build log at $path", is the most important one.
Everything else does not matter.  Post the contents of that log using
zcat, which is a variant of cat that does decompression.



Re: Indication of build failure from substitute servers?

2024-08-06 Thread Ricardo Wurmus
Marek Paśnikowski  writes:

> The proof of availability is in workflow itself. The project committers
> NEVER commit anything to the master branch. Only the CI system
> does. Instead, the committers push to a "pre-main" branch, and the CI
> system picks the commits up one by one and attempts to build them as
> usual. IMPORTANT POINT: *if* the commit builds correctly, it gets pushed
> by CI to master branch, and the substitute is already available. *If*
> the commit does not build, it gets rejected, and it never goes to
> master.
>
> I currently do not know enough about Git to confidently propose a
> solution to the problem of how to handle the reordering of the queued
> work on a build failure, but I have a feeling it is not that hard to
> solve.

Prior art: https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html

An open problem is preserving commit signatures or perhaps changing the
meaning of signatures by signing not the commit but the changes only.

-- 
Ricardo



Re: Indication of build failure from substitute servers?

2024-08-06 Thread Ricardo Wurmus
"Jonathan Frederickson"  writes:

> Would it make sense to have some mechanism for substitute servers to be able 
> to provide a sort of "non-existence proof" for a given
> package? Something that the CI system could publish to indicate that its 
> build attempt for that package failed, and that clients could use
> to optionally abort without attempting a local build?

It's something I've been wanting for the past decade.  The CI system
knows when a build has failed but when checking for substitutes there is
no endpoint to ask whether the CI build has failed.

In the past we had discussed enhancements to the substitution mechanism
(with the background of making use of information from "guix challenge")
that would allow people to have a bit more control over it.  In the
meantime we have added a way to let "guix pull" determine the latest
commit with substitutes for the derivations needed for "guix pull" ---
in the same vein we could enhance the substitution mechanism to check an
endpoint on CI and abort if the remote build has been marked as failed.

If you'd like you could think this through and come up with a minimal
set of proposed changes needed to make it work.  Then we could discuss
this here and decide which of the possibile approaches would be most
appropriate.

-- 
Ricardo



Edit: Need help about guix home "home-run-on-first-login-service-type"

2024-08-06 Thread jidibinlin
Mail conent show the unhandled whitespace because you read the mail in text way
but not html. Any way. I resend it in text way here.



I want to use home-run-on-first-login-service-type to automatic install 
on-my-zsh
when first login to shell.

But I got an error when I try to guilx home container home-configuration.scm

—— home-configuration.scm –

;; This “home-environment” file can be passed to ’guix home reconfigure’
;; to reproduce the content of your profile.  This is “symbolic”: it only
;; specifies package names.  To reproduce the exact same profile, you also
;; need to capture the channels being used, as returned by “guix describe”.
;; See the “Replicating Guix” section in the manual.

(use-modules (gnu home)
  (gnu packages)
  (gnu services)
  (guix gexp)
  (gnu home services shells)
  (gnu home services))

(define download-ohmyzsh-install
  (with-imported-modules ’((guix build utils))
#~(begin
(use-modules (guix build utils))
(invoke
  “curl”
  “-L”
  
“”
  “-O”
  “install.sh”)
(invoke “sh” “install.sh”

(home-environment
  ;; Below is the list of packages that will show up in your
  ;; Home profile, under ~/.guix-home/profile.
  (packages (specifications->packages (list “guile”
“clojure”
“node”
“gopls”
“go”
“emacs-pgtk”
“curl”
“direnv”)))

;; Below is the list of Home services.  To search for available
;; services, run ’guix home search KEYWORD’ in a terminal.
(services
  (list
(service home-run-on-first-login-service-type download-ohmyzsh-install)
(service home-zsh-service-type (home-zsh-configuration)



———– error output ——-

substitute: updating substitutes from ’https://mirror.sjtu.edu.cn/guix/’… 100.0%
The following derivations will be built:
  /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv
  /gnu/store/8483bafsq7izr33l9v3qcw51vkxgl260-provenance.drv

building /gnu/store/8483bafsq7izr33l9v3qcw51vkxgl260-provenance.drv…
building /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv…
\builder for `/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv’ failed with 
exit code 1
build of /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv failed
View build log at 
’/var/log/guix/drvs/3s/zcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv.gz’.
guix home: error: build of 
`/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv’ failed


Re: Need help about guix home "home-run-on-first-login-service-type"

2024-08-06 Thread jidibinlin
Marek Paśnikowski  writes:

> Seems like Gnus cleaned up the message for me, so I can see a bit more.
>
> “花不见海” <2694273...@qq.com> writes:
>
>> (define download-ohmyzsh-install
>>   (with-imported-modules ’((guix build utils))
>> #~(begin
>> (use-modules (guix build utils))
>> (invoke
>>   “curl”
>>   “-L”
>>   
>> “”
>>   “-O”
>>   “install.sh”)
>> (invoke “sh” “install.sh”
>>
>> (home-environment
>>   [packages …]
>>   (services
>> (list
>>   (service home-run-on-first-login-service-type download-ohmyzsh-install)
>>   (service home-zsh-service-type (home-zsh-configuration)
>>
>
> I tried to refute the service declaration by looking at the service
> source code, but I was not able to find any issues this way.
>
>> \builder for `/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv’ failed 
>> with exit code 1
>> build of /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv failed
>> View build log at 
>> ’/var/log/guix/drvs/3s/zcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv.gz’.
>
> This line here, “View build log at $path”, is the most important one.
> Everything else does not matter.  Post the contents of that log using
> zcat, which is a variant of cat that does decompression.


Oh! I thought the log file compressed is a directory. So I used tar -xvf 
$logfile
to see the log.

When I use zcat I got this

——- zcat $logfile ———-
Backtrace:
   2 (primitive-load “/gnu/store/zhanp30hpki5l4ym1jw8d471x0z?”)
In ice-9/eval.scm:
619:8  1 (_ #f)
In unknown file:
   0 (symlink “/gnu/store/8dp41h3wd0zqalffgr67xwzmpjx63h7b-?” ?)

ERROR: In procedure symlink:
In procedure symlink: File exists


Edit: Need help about guix home "home-run-on-first-login-service-type"

2024-08-06 Thread 2694273649
For my first mail`s code block may hard to read (but it looks fine when
i read it from browser), so I edit it with emacs hope can correct the
whitespace


 home-configuration.scm 

;; This "home-environment" file can be passed to 'guix home reconfigure'
;; to reproduce the content of your profile.  This is "symbolic": it only
;; specifies package names.  To reproduce the exact same profile, you also
;; need to capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(use-modules (gnu home)
  (gnu packages)
  (gnu services)
  (guix gexp)
  (gnu home services shells)
  (gnu home services))

(define download-ohmyzsh-install
  (with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils))
(invoke
  "curl"
  "-L"
  
"https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh";
  "-O"
  "install.sh")
(invoke "sh" "install.sh"

(home-environment
  ;; Below is the list of packages that will show up in your
  ;; Home profile, under ~/.guix-home/profile.
  (packages (specifications->packages (list "guile"
"clojure"
"node"
"gopls"
"go"
"emacs-pgtk"
"curl"
"direnv")))

  ;; Below is the list of Home services.  To search for available
  ;; services, run 'guix home search KEYWORD' in a terminal.
  (services
(list
  (service home-run-on-first-login-service-type download-ohmyzsh-install)
  (service home-zsh-service-type (home-zsh-configuration)



--output for guix home container home-configuration.scm -

substitute: updating substitutes from 'https://mirror.sjtu.edu.cn/guix/'... 
100.0%
The following derivations will be built:
  /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv
  /gnu/store/8483bafsq7izr33l9v3qcw51vkxgl260-provenance.drv

building /gnu/store/8483bafsq7izr33l9v3qcw51vkxgl260-provenance.drv...
building /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv...
\builder for `/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv' failed with 
exit code 1
build of /gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv failed
View build log at 
'/var/log/guix/drvs/3s/zcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv.gz'.
guix home: error: build of 
`/gnu/store/3szcc1q867q7hrqigsns4xf8bvrc2l5h-home.drv' failed




Re: Proposal: Differentiate products more clearly (Cycle 01)

2024-08-06 Thread pelzflorian (Florian Pelz)
Hello Luis.

I very much like your Guix download page mock-ups that make the download
pages give clear instructions.  They avoid referring to the manual; this
is better at least to many users (who currently probably download the
Guix tarball before they learn it was useless).

The question of wording is if it would be an improvement to use terms
popularized elsewhere.  I have opinions, but perhaps I’m wrongly
conservative in this regard.

Guix is all about packages, therefore it is a package manager.  I
believe the shell and container and system, home support are still about
packages.  Despite other package managers not doing it.

Also you write in the system download page mock-up, Guix System were a
distribution of the GNU operating system.  I believe this is wrong; Guix
(not Guix System) is a distribution of the GNU operating system.

The definition of OS should not be something like Windows, running on
top of an IBM Bios or Intel Management Engine.

Regards,
Florian



Re: Proposal: Differentiate products more clearly (Cycle 01)

2024-08-06 Thread Marek Paśnikowski
"pelzflorian (Florian Pelz)"  writes:

> The question of wording is if it would be an improvement to use terms
> popularized elsewhere.  I have opinions, but perhaps I’m wrongly
> conservative in this regard.
>
> Guix is all about packages, therefore it is a package manager.  I
> believe the shell and container and system, home support are still about
> packages.  Despite other package managers not doing it.
>

If I may, I would like to interject with my own thought here — I have
come to understand Guix as a service manager.  This is because packages
are objects of a profile service, one of many services declarable with
Guix.  As a result of this understanding, I stopped using the 'packages'
fields of operating-system and home-environment, preferring to declare
the packages in profile services' extensions.



Re: Edit: Need help about guix home "home-run-on-first-login-service-type"

2024-08-06 Thread Development of GNU Guix and the GNU System distribution.
Hi 花不见海,

On Tue, Aug 06 2024, jidibinlin wrote:

> Mail conent show the unhandled whitespace because you read the mail in
> text way but not html.

You are right that the HTML version looked fine.

I also saw the HTML entity   in the "text/plain" multipart of your
message.  Many people here turn off HTML email.

Kind regards & thanks for using Guix!
Felix



Re: Proposal: Differentiate products more clearly (Cycle 01)

2024-08-06 Thread pelzflorian (Florian Pelz)
Marek Paśnikowski  writes:
> "pelzflorian (Florian Pelz)"  writes:
>> Guix is all about packages, therefore it is a package manager.  I
>> believe the shell and container and system, home support are still about
>> packages.  Despite other package managers not doing it.
> If I may, I would like to interject with my own thought here — I have
> come to understand Guix as a service manager.  This is because packages
> are objects of a profile service, one of many services declarable with
> Guix.  As a result of this understanding, I stopped using the 'packages'
> fields of operating-system and home-environment, preferring to declare
> the packages in profile services' extensions.

Interesting.  Yes, in Guix System and Guix Home, we can view packages as
objects of services, but not in the rest of Guix.  The term “Package
manager” is more encompassing.

Regards,
Florian



Re: Indication of build failure from substitute servers?

2024-08-06 Thread pelzflorian (Florian Pelz)
Marek Paśnikowski  writes:
> The proof of availability is in workflow itself. The project committers
> NEVER commit anything to the master branch. Only the CI system
> does. Instead, the committers push to a "pre-main" branch, and the CI
> system picks the commits up one by one and attempts to build them as
> usual. IMPORTANT POINT: *if* the commit builds correctly, it gets pushed
> by CI to master branch, and the substitute is already available. *If*
> the commit does not build, it gets rejected, and it never goes to
> master.

In theory we have QA badges on patches at the top of
e.g. .  Committers could wait for it
and for its substitutes.

In practice, QA is too slow or does not prioritize enough yet. [1]

Regards,
Florian

[1]
https://lists.gnu.org/archive/html/bug-guix/2024-05/msg00116.html
https://yhetil.org/guix-bugs/87le4czh0z@gmail.com/