Re: Compile skribilo doc containing guix channel references

[Phil]

Hi,

Phil writes:

> My guess is there is a better approach - any suggestions?  Perhaps I can
> call the skribilo compiler from inside "guix repl" for example?

To somewhat answer my own question in case it's useful to anyone else or
if anyone has any suggestion on how to do it better - there are 2 ways
I've found to do this.  The most obvious is to abandon the skribilo DSL
and write the document directly as a scheme file which will evaluate and
write itself out as HTML - it can then be called as: guix repl -- foo.scm:

(with-output-to-file "foo.html"
  (lambda ()
(evaluate-document d e

See skribilo docs for full example.

This isn't ideal because you can't use a the skribe format which isn't
pure scheme.  To do that we have to call the scribilo compiler's main entry
point from inside scheme rather than from the command line - the below
example worked for me, but it's quite fiddly to get it to work.  It is
also called from guix repl.

To give a very simple example the document can use guix functions to
reference infomation in the channel I'm documenting:

(p [The ,(package-name my-package) package is set to ,(package-version 
my-package).])

The below script has to be one level above the package directory in my
channel, and the script must be called the directory which houses it.

The output should also go to the same directory.  I then moved the
output HTML afterwards, rather than putting the target path in --output
- this makes sure the links work.

The hardcoding of the load-path is also not ideal, I suspect this can be
improved.

(add-to-load-path 
"/gnu/store/ymvqgkljzykfv4g7vbw36pgghfjbhnps-skribilo-0.9.5/share/guile/site/3.0")
(add-to-load-path 
"/gnu/store/2160nv245ys30vxvhpjxgcbjm9rq67gw-guile-reader-0.6.3/share/guile/site/3.0")

(define local-repo-clone-path
  (dirname (current-filename)))
 
(define local-packages-clone-path
  (string-append local-repo-clone-path "/packages"))

(add-to-load-path local-packages-clone-path)

(use-modules (skribilo condition))

(call-with-skribilo-error-catch/exit
  (λ ()
(apply (module-ref (resolve-interface '(skribilo)) 'skribilo)
   `("--target=html"
 ,(string-append "--source-path=" local-packages-clone-path)
 ,(string-append local-repo-clone-path 
"/docs/my-channel-skribilo-doc.skb")
 "--output=index.html"

Re: How long does it take to run the full rustc bootstrap chain?

[Bengt Richter]

Hi again, thanks for your reply...

On +2022-10-27 10:35:02 -0400, Maxim Cournoyer wrote:
> Hi,
> 

(Oops, pasting back alternative I thought would be faster)
> > So above combo command line now gives me
> > --8<---cut here---start->8---
> > SIZE MODEL  TYPE  TRAN   VENDOR   NAME
> > 465.8G Samsung SSD 970 EVO Plus 500GB disk  nvmenvme0n1
> > 
> > 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 
> > Controller SM981/PM981
> > $ 
> > --8<---cut here---end--->8---

[...]

--8<---cut here---start->8---
> $ lsblk -o size,model,type,tran,vendor,name|grep -Ei 'ssd|model';echo;lspci 
> |grep -i nvme
>   SIZE MODEL  TYPE  TRAN   VENDOR   NAME
> 465.8G Samsung SSD 860 EVO 500GB  disk  sata   ATA  sda
> 931.5G Samsung SSD 840 EVO 1TBdisk  sata   ATA  sdc
> --8<---cut here---end--->8---
> 
> Building Rust is mostly CPU dependent; I think fast single thread
> performance is key as not that much happen in parallel, IIRC.  The 3900X
> is a 12 cores (24 logical) beast.
>

Hm, just TRAN sata, no nvme, so it's going to be slow, but
what is the effect on what you timed?

Is there an easy way to get a measure of how many GB went
through those SATA channels during what you timed? That
would give an idea of what faster phusical disk memory
access would do for you. If many people are waiting longer
that they like, maybe they would chip in to fund an upgrade,
to feed that 12(24)-core "beast" :-)

I'd bet it is waiting a lot, if not more than computing :)
--
Regards,
Bengt Richter

Re: Status of armhf-linux and powerpc64le-linux

[Tobias Platen]

On Fri, 2022-10-21 at 10:43 +0200, Ludovic Courtès wrote:
> Moin!
> 
> Mathieu Othacehe  skribis:
> 
> > >  - armhf-linux is disabled on ci.guix due to improper
> > > offloading
> > >    setup (probably along the lines of
> > >    ).  Should we try and
> > > reenable
> > >    it, or should we drop it?
> > > 
> > >  - powerpc64le-linux is disabled on ci.guix since today
> > >    (maintenance.git commit
> > >    d641115e20973731555b586985fa81fbe293aeca).  However it did
> > > work
> > >    until recently and we have one machine to offload to. 
> > > Should we
> > >    fix it or drop it?  Mathieu?
> > 
> > Yeah, we only have a single machine to offload to and each time it
> > is
> > not reachable, the "guix" specification fails on Cuirass.
> 
> How frequently does that machine become unreachable?
> 
> Its uptime right now is “only” 51 days, but it seems to have been
> reliably building things so far (surprisingly so!).
> 
> > That's because we need to offload to a powerpc64le-linux machine in
> > order to evaluate the guix derivation for that specific
> > architecture
> > (that's true for all the other architectures).
> 
> Maybe we should arrange to be more resilient to transient build
> machine
> outage.
> 
> For that we need redundancy; we have it for ARM, but not for POWER9. 
> A
> simple way to get redundancy today would be to set up transparent
> emulation for POWER9 on one of the x86_64 boxes.  That’ll be
> inefficient, but that’ll let Cuirass survive transient failures of
> that
> one POWER9 box.
> 
> WDYT?
> 
> Longer-term, people interested in POWER9 should look into:
> 
>   • Purchasing, setting up, and hosting POWER9 hardware (funds held
> at
>     the FSF are probably sufficient for that!).
Vikings also offers hosting of POWER9 hardware.
> 
>   • And/or: getting in touch with companies who could sponsor us by
>     providing hardware (the AArch64 port was started thanks to a
>     donation by ARM).
> 
> In Cuirass, we should arrange to support partial evaluations or
> per-system evaluations so that a single missing offload machine
> doesn’t
> cause the whole evaluation to fail.
> 
> > Given the lack of workers for powerpc64le-linux I think we should
> > drop
> > it.
> 
> We can do that, but I find embarrassing to drop the architecture
> after
> all the work people have put it “just” because of infrastructure
> issues.
> 
> > Regarding armhf-linux we can in theory rely on the overdrives but
> > we
> > are already struggling on aarch64-linux, we I think we should also
> > drop it for now.
> 
> In theory, ci.guix has at least 3 Honeycombs (2 are currently
> offline)
> and 2 Overdrives, so it’s not that bad, and they don’t seem to be all
> that busy.
> 
> So you’re right in a way, but at the same time this seems to be an
> infrastructure issue.
> 
> > Focusing on x86_64-linux, i686-linux and aarch64-linux for this
> > release
> > seems more pragmatic.
> 
> That’s radical, but maybe that’s the most reasonable option.
> 
> How about a plan like this: until next Thursday, we try to address
> the
> infrastructure issues discussed above to estimate feasibility.  Then
> we
> decide on the way forward.  WDYT?
> 
> If we end up dropping architectures, we’ll have to:
> 
>   1. Update the documentation (and eventually the web site).
> 
>   2. Offer a clear plan as to what it would take to reinstate those
>  architectures, and probably define clear criteria for
> architecture
>  support going forward.
> 
> Thanks,
> Ludo’.
> 

Re: Questions about Cuirass

[Maxime Devos]

On 30-10-2022 13:50, James Hobson wrote:

Sorry for not getting back to you.

Looks promising!

I wish I could release everything under a free license. Baby steps though! I’ve 
managed to release a few things under LGPL since I started! That’s 100% more 
than before!


Sounds good.


But anyway. The biggest hurdle I see is that updating in an air gapped 
environment doesn’t seem supported because guix’s git url is hard coded. Does 
this need to be the case? If not, I might see if I can find an nice way of 
making this more configurable


There is a default, yes, but it's not hardcoded, you can override it. 
Have a look at "Invoking 'guix pull'" in the manual, in particular its 
'--url=URL' argument.



James


> [...]

I prefer no top-posting; my e-mail client, and more generally almost all 
e-mail clients I think, keep a thread of previous messages.  I would 
prefer to not to have to scroll down to read the rest of the message 
only to discover there is none.


Greetings,
Maxime


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature