Re: Guix Documentation Meetup

[adriano]

Il giorno sab, 11/12/2021 alle 05.40 +0700, Blake Shaw ha scritto:
> 
> hiya guix,
> 
> @cybersyn from IRC here, I recently contributed my first package,
> [notcurses]
> 
> --
> tldr: is there also room to discuss contributing -- and possibly
> doing a
> sizeable makeover to -- the *Guile* documentation? If so, I could
> give a
> short 5 - 10 minutes presentation of what I think should be done (and
> would volunteer to do).
> --

I'm reading this on december 21st

I suppose the documentation meetup happened already and I don't know if
you gave your illustration of your notes

I, for one, would LOVE to hear it

Yes the Guile experience is abysmal, awful, actively rejecting
beginners/newcomers

I've been wandering in the Guile manual, on and off, for years now and
I still can't make any sense of it

If I have a curiosity I still can't find my way around to such thing in
the manual, most of my discoveries have been by pure chance

Often, I try to re-read the same thing a few months later and I can't
find it again

Everytime I attempted something in Guile I've been frustrated

I myself have done a so called vlog where I show how to read a file in
Guile

I also have a general view of packaging and distributing Guile packages
that I gained by some very hard work that lasted a couple of years but
I was discouraged in doing more videos

Not only previous knowledge of the GNU system is a not declared hard
requirement

Often, previous knowledge of other things is required too

For example the new exceptions system is obscure, you're required to
know the one from Common Lisp in order to undertsand the one in Guile

Or,as another example, I stumbled in an example made in python of a
hashmap (similar to the ones very common in Clojure) and I got that

Good luck with data structured in Scheme

Or, the machinery for manipulating xml (and json ?) trees is discussed
in academic (!!) papers that present the code in Haskell, so you need
to learn Haskell in order to read that

The curse of knowledge in the Guile world is tragic



> I think I can personally offer a lot in terms of contributing to
> documentation. While I don't serious experience w/technical writing,
> prior to the pandemic I was doing my PhD in philosophy of
> mathematics,
> so I come from a cross-disciplinary background that involves the
> often
> difficult area of communicating new, formal ideas to previously
> unexposed readers. I've also made a living as a new media artist
> since
> 2009, working mostly in C and C++ based frameworks, so I also have
> some
> knowledge of the difficulties "crafters" have when learning new
> development systems.

That's all good. I love that you noticed the problem and are offering a
fresh perspective 

> I don't know if this is the correct forum for it, but I personally
> think
> the biggest documentation obstacle in Guix at the moment isn't so
> much
> in Guix, but instead in Guile. 

Absolutely, yes

> I found Guix via SICP & Racket about a
> year ago, and I remained a happy Racket hacker until a couple months
> ago
> when I decided to devote my free time to learning Guile in hopes of
> graduating to a Guix sensei one day.

Not only a Guix sensei but maybe a Guile sensei

Why has Guile only Guix ?

Why couldn't we have more nice things made in Guile ?

> While I've come to love Guile, compared to my experience with Racket
> its
> been quite burdensome for me to get in the hang of, something I
> attribute
> primarily to the structure of the docs, and not due to it being in
> any
> way more difficult than Racket. While with Racket I was writing
> useful programs in the standard #lang within my first week, with
> Guile
> I often find that what should be almost trivial winds up with a lot
> of
> time lost just trying to navigate and understand the docs. When I do
> figure things out, it turns out to be no more difficult than the
> equivalent
> in Racket, but a lack of consistency in the path that leads there in
> the
> docs cause hangups, which has made trivial scripts that should take
> an hour
> become weekend projects.
> 
> I know this isn't the Guile list, but when I've written on this topic
> in
> the IRC I've had no response, which make me think docs could be a
> bit of a bikeshedding topic in the community. But as Guile is
> fundamental to Guix and theres a lot of crossover btwn the
> communities,
> it seems like this could be a good time to raise these suggestions.

Oh I love this !

> I've jotted down some notes on several concrete examples of where the
> docs
> diverge from stylistic consistency, as well as some light analysis as
> to
> why such seemingly small inconsistencies can lead to such hangups in
> the learning
> process. If folks would be interested in me presenting a short 5-
> 10min
> presentation of these notes, I'd be happy to share.

yes plase !!!


> Sorry for such a long-winded message! Personally, good documentation
> is
> absolutely essential, and I feel like I could give Guile's docs a
> 

Re: extend ’guix archive’?

[Jack Hill]

On Mon, 20 Dec 2021, zimoun wrote:


Hi,

On Mon, 20 Dec 2021 at 23:07, Ludovic Courtès  wrote:


Regarding nar-herder, I think it’d be nice to have a solution to
mirroring in Guix proper, developed similarly to other components,
because it could be a fairly central tool.

‘guix publish’ is probably not extensible enough to support that, but we
could make it a new ‘guix mirror’ or ‘guix sync’ or whatever command.


Why not extend “guix archive”?


Hi all,

I'm quite interested in learning more and potentially trying out the 
nar-herder! Some thoughts that I'd like to add to the design space:


I think it would be great if one of the pastures to which we herd the nars 
would be a free and open source software mirror site. In my experience, 
these are usually some static web hosting in front of a large disk with a 
place to run scripts to sync the content. A database server may not be 
available. I'd like to support this use case because I think it is a great 
way to build bridges to the communities who run or gather around these 
mirrors.


I'd also like the ability fetch nars directly from the local-to-me mirror 
rather than having them be proxied through a far way server.


One of the things that I really like and find empowering about Guix is 
that the developer/system administration tools are as available, easy to 
use, and convenient as the every day tooling. To the extent possible, I 
think that we should strive to make our syncing/mirroring solution 
practical to run for local, small setups, and not require project-scale 
infrastructure or coordination between many programs that are not captured 
in a Guix service.


Best,
Jack

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

Hi,

On Mon, 20 Dec 2021 at 22:24, Ludovic Courtès  wrote:

> Same here.  But first it’d be nice to come up with a summary of what we
> did in ‘core-updates’ because I think we’ve all forgotten most of it.
> :-)

A summary as a ChangeLog or a summary as a blog post? :-)


Cheers,
simon

Re: Solstice infrastructure hackathon

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

> I personally think that having Bordeaux as an alternative build farm,
> running alternative software is a wrong direction for the project. I
> would personally prefer to put a stop to that situation.
>
> We should clearly host some services such as the Guix website on
> Berlin & Bordeaux to bring some redundancy. However, as far as
> substitutes building is concerned, redundancy is premature when
> maintaining a single system, with our limited human and hardware
> resources, proves to be so complex.
>
> What do other people think?

I agree with what Ricardo wrote, in particular that motivation is not
fungible.  In that sense, an extra effort is not a “waste of resources”
in that it doesn’t take anything from other efforts in terms of
workforce.

Now, I’d certainly like to see more collective thinking around the
infrastructure we’re building—just like we think and work collectively
on Guix and its packages.

We have one set of problems to solve: long-term storage, GC scalability,
distribution, mirroring, continuous integration, etc.  While it’s
valuable to approach them from difference angles, I also find it more
fruitful when we can iterate collectively on actual solutions, and
follow our shared set of processes—review, tests, doc, integration in
Guix proper when applicable, and so on.

Tomorrow is a day where we can hopefully take advantage of that
collective work to address part of our infrastructure needs.

Thanks,
Ludo’.

extend ’guix archive’?

[zimoun]

Hi,

On Mon, 20 Dec 2021 at 23:07, Ludovic Courtès  wrote:

> Regarding nar-herder, I think it’d be nice to have a solution to
> mirroring in Guix proper, developed similarly to other components,
> because it could be a fairly central tool.
>
> ‘guix publish’ is probably not extensible enough to support that, but we
> could make it a new ‘guix mirror’ or ‘guix sync’ or whatever command.

Why not extend “guix archive”?

However, without all the details so my remark is totally naive, I miss
what “nar-herder” is doing that “guix archive”+rsync+“guix publish” is
not doing – other said I miss why another SQL database is required to
serve stuff from one place to another.  I have read README but I did not
get the point.


Cheers,
simon

Re: Organising Guix Days

[zimoun]

Hi,

On Mon, 20 Dec 2021 at 18:51, Ludovic Courtès  wrote:

>> Also, we need to secure a BBB instance :)
>
> I think we can still use the same one as last year (zimoun?).  If that
> doesn’t work, there’s a couple of options, such as Inria’s instance.

If you refer to Fosshost instance,



well, I am not currently able to reach it.  And I have not re-read all
their recent updates but they changed a bit their way, and IIRC, they
removed not-used instances, as ’guixbbb’.

INRIA is an option.  Others* could be too.

Cheers,
simon

*others: asking people behind Guix Café.

Re: How to test modified shepherd services

[Nathan Dehnel]

Thanks, that worked.

On Mon, Dec 20, 2021 at 4:00 AM Attila Lendvai  wrote:
>
> i have just finished my first Guix service. for now it's a PR for that other 
> channel, so i'll copy-paste some stuff from it:
>
> Run with something like this:
>
> $(guix system --no-graphic vm path/to/swarm.scm) -m 2048
>
> $(./pre-inst-env guix system --no-graphic vm /path/to/swarm.scm) -m 2048
>
> this will build and boot an operating-system object in a Qemu VM, in the same 
> terminal.
>
> the file should return a simple-operating-system object, optionally wrapped 
> into a marionette-operating-system if you also want to write/run automated 
> tests.
>
> i'll send you the link to the actual code in a private email.
>
> - attila
> PGP: 5D5F 45C7 DFCD 0A39
>

Re: SSH service for Guix Home

[Ludovic Courtès]

Hi!

Xinglu Chen  skribis:

> On Wed, Dec 15 2021, Ludovic Courtès wrote:
>
>> Hi Andrew,
>>
>> One service I miss for Guix Home is ‘home-ssh-service-type’, which is in
>> the “original” Guix Home.
>>
>> Could you contribute a patch adding it?  (I could do it on your behalf,
>> but it sounds more logical to let you handle it.)
>
> Being the original author, I will hopefully try to work on it soon.  :-)

Neat.  :-)

[...]

>> Last, it’d be great to see the three of you (and more people!) back in
>> action regarding Guix Home.  I understand that life sometimes gets in
>> the way, but it seems that there’s been some confusion as to how to go
>> forward—e.g., —which may partly
>> explain why things stalled.  If there are patches waiting for review,
>> also don’t hesitate to ping!
>
> Yeah, apologies for not being very active in the last few months.

No, no need to apologize.

I think we need to come to a shared understanding of what the next steps
are.  Once we have that, we can clarify the current status in the manual
and release announcement, and open issues so that anyone who’d like to
contribute knows where to look at.

> I think one of the problems is that there is not really any style guide
> for now to write services (I do have a WIP patch in my local tree that
> will document most of (gnu services configuration) though :-)).

I see you’ve sent it in the meantime, neat!

> We also lack a way to properly test home services; we would need
> something similar to what Nix Home-manager has[1][2].
>
> [1]: Nix code for configuring a program
> 
> [2]: Expected content of the serialized configuration
> 

OK.  Given that ‘define-configuration’ works at a “meta” level, I wonder
if we could have tests that are less boring than this.

Thanks,
Ludo’.

Re: SSH service for Guix Home

[Ludovic Courtès]

Hello!

Andrew Tropin  skribis:

> On 2021-12-15 18:59, Ludovic Courtès wrote:

[...]

>> Also, could you (or Xinglu, or Oleg) write a blog post for guix.gnu.org,
>> targeting an audience who’s not familiar with this kind of tool, making
>> it clear what the rationale is and what it can bring to “normal users”?
>> It would be really helpful to have that published within a couple of
>> weeks or so, before the next release.
>
> I have a blog post task in my backlog, I want to upstream more home
> services before publishing the post.  It's not a blocker, but a nice
> thing to have.  There is another ongoing work, which I would like to
> finish before making a post.
>
> Another option is to publish this post some time after 1.4.0 release, so
> everything I want will be finished to that moment.  I don't see reasons
> to hurry, so it's a viable alternative too.

I think it’d be ideal to have the post before the release, so users know
what they’re getting.  :-)

It’s completely fine if there are still missing features, etc. IMO;
it’ll keep growing and there can be another post later.

> I burnt out a little during upstreaming process, it was quite slow and
> painful at the beginning and increased maintanance burden of rde for me.
> A little too early merge + uncoordinated changes of basic primitives and
> service configurations also hit me quite hard and forced to spend some
> time bringing rde back to working state without going a step further.
>
> I took a break and after that started to cleanup small Guix Home issues,
> develop/improve home services in rde repo and finally started to work on
> new rde features.  Still feel a little burnt out and I try not to do
> worse.

Oh I’m sorry to read that.  I certainly don’t want to add more on your
plate or to have you feel pressured to do more.

I think we can take our time on this; we can clarify in the manual and
announcement what it is that users are getting when the release is out.

(To be clear, the review process has been a burden on me too, and it’s a
strong commitment from the Guix maintainers going forward.)

[...]

> To continue upstreaming home services from rde to Guix I would like and
> actually need to have an established style guide on how to write service
> configurations to make sure service implementations are consistent.  I
> started to write a manual section, which we can collectively review,
> discuss and adjust it to get such a style guide.  Cause of burn out and
> a lot of unrewarding monkey work I've done recently it's a little hard
> to focus on this task, but I'll try to send first drafts to mailing list
> soon.

Yeah, there’s no style guide, but on the up side, there’s established
practice with system services that hopefully we can follow in most
cases.

Anyway, recovering from burnout and making sure it doesn’t happen again
should be the priority.

Thanks for your feedback,
Ludo’.

Re: Mid-December update on bordeaux.guix.gnu.org

[Ludovic Courtès]

Hello!

Christopher Baines  skribis:

> In summary, the space issue I mentioned in the previous update has
> effectively been addressed. All the paused agents are now unpaused and
> builds are happening again.

Yay!

> However, due to the time spent not building things, the backlog is
> longer than usual, and the substitute availability (especially for
> x86_64-linux and i686-linux) is lower than usual.

Yeah, ‘guix weather coreutils’ finds nothing on bordeaux.guix right now.

> ** Space issues and the nar-herder
>
> bordeaux.guix.gnu.org wasn't building things for 2 weeks as the space on
> bayfront was getting a little scarce. This week I started rolling out
> the nar-herder [2], a utility I've been thinking about for a while. This
> has enabled moving nars off of bayfront on to another machine which I've
> confusingly named lakefront.

Woow, neat!

Regarding nar-herder, I think it’d be nice to have a solution to
mirroring in Guix proper, developed similarly to other components,
because it could be a fairly central tool.

‘guix publish’ is probably not extensible enough to support that, but we
could make it a new ‘guix mirror’ or ‘guix sync’ or whatever command.

> The lakefront machine is hosted by Hetzner in Germany, and has 6TB of
> storage across 2 hard drives. When a nar is requested from bayfront, it
> will check it's local storage, and serve it from there if it exists,
> otherwise it will forward the request to lakefront. There might be a
> slight drop in the speed you can download nars, but apart from that this
> change shouldn't be visible.

Excellent, thanks for acting this promptly as problems crop up!

I think we should make sure this is funded by the project and that
credentials are shared.  As discussed before, I think it’s best to keep
things tidy in that respect, in the spirit of building and maintaining
this collectively.

> The nar-herder is now busy deleting nars on bayfront which are available
> on lakefront. Once it's got through the backlog, I'll enable NGinx
> caching for the nars on bayfront, which should help improve
> performance. I've tested downloading the largest nars (~2GB) though, and
> it seems to work fine.
>
> In addition to lakefront, I've also added a 6TB hard drive to hatysa,
> the HoneyComb LX2 machine that I host. Like lakefront, it's busy
> downloading the nars from bayfront. This will act as a backup in case
> lakefront is lost.
>
> In general this is an important step in being more flexible where the
> nars are stored. There's still a reliance on storing pretty much all the
> nars on a single machine, but which machine has this role is more
> flexible now. I think this architecture also makes it easier to break
> the "all nars on a single machine" restriction in the future as well.

That’s really cool.

> Going forward, it would be good to have an additional full backup of the
> nars that bayfront can serve things from, to provide more
> redundancy. I'm hoping the nar-herder will also enable setting up
> geographically distributed mirrors, which will hopefully improve
> redundancy further, and maybe performance of fetching nars too.
>
> Once I've had a chance to neaten up the code a little, I'll get a Guix
> package and service written, plus I'll draft a Guix blog post about the
> nar-herder.

Usually I’m the one asking for blog posts :-), but I’d really like us as
a project to collectively engage on the topic before we publicize this
specific approach.

[...]

> That means there's the following currently running build agents (by
> architecture):
>
>  - x86_64-linux + i686-linux (3 machines):
>- 4 core Intel NUC (giedi)
>- Max 16 cores for 1 concurrent build on bayfront
>- 32 cores on milano-guix-1 (slow storage though)
>  - aarch64-linux + armhf-linux (2 machines)
>- 16 core HoneyComb LX2 (hatysa)
>- 4 core Overdrive (monokuma)
>  - powerpc64le-linux (1 machine)
>- 64 core machine (polaris)

This is looking pretty nice!  I’m also all for streamlining machine
handling, both administratively (in maintenance.git) and financially.

> Ironically, I think that the most under-resourced area is x86_64-linux +
> i686-linux. bayfront is restricted in what it can do since it also runs
> the coordinator, and things go badly if the machine gets
> overloaded. bayfront and milano-guix-1 both have hard drive storage,
> which also can slow them down when building things (especially
> milano-guix-1).
>
> If we (as a project) want bordeaux.guix.gnu.org to have the capacity to
> keep up, it would be good to make a plan to add capacity. I think even a
> single high core count x86_64-linux machine with performant storage
> would make a big difference.

Yes, we should do that, we still have funds for it.

> ** IPv6 not supported (yet)
>
> I was slow to notice, but bordeaux.guix.gnu.org isn't available over
> IPv6 yet, since bayfront doesn't seem to have IPv6 connectivity. I want
> to address this, but I haven't worked out quite how to yet.

Should be almost 

Re: Release v1.4 (or 2.0): process and schedule ?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer  
> wrote:
>> zimoun  writes:
>
>>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes.  But that's just my personal opinion :-).  If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>
> I do not have a strong opinion either.

Same here.  But first it’d be nice to come up with a summary of what we
did in ‘core-updates’ because I think we’ve all forgotten most of it.
:-)

[...]

>>> In both case, what is the target for a release date?  I propose January
>>> 31rst.  WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> To me,
>
>  - adapt the importers with the new style is also a thing
>  - various guix home minor fixes discussed [1] by Xinglu, Andrew and
>Ludo, a blog post would be neat too. :-)

Agreed on all this.

I’d also like to see if we can avoid the two-step “make release” process
by updating the ‘guix’ package once only.

And also see if we can arrange for ‘guix system init’ to hard-link files
instead of copying them during the normal installation process
(currently it copies files from /tmp to /gnu on the installation media).

Probably at some point we should open a bug for the release and mark
other items as blockers, like we did for the previous release.  One of
us could then keep track of things and send weekly updates, say (it’s
best if it’s someone not too deeply involved with the actual release
hacks!).

Ludo’.

importers and input package lookup

[Attila Lendvai]

dear Guixers,

there are two, independent namespaces:
1) the scheme one, and
2) the guix package repository.

when i work on an importer (golang), it skips the packages that are already 
available in 2), but then it has no clue under what variable name they are 
stored in 1), and in which scheme module.

should the dependency lists in the package forms be emitted as 
(specification->package "pkgname@0.1.0") forms?

in the current codebase this emission is done in the shared 
guix/import/utils.scm, in package-names->package-inputs. if i change this, 
it'll affect every other importer (BTW, i have converted it to use the new 
format).

is specification->package fast enough that it all doesn't matter?

a bit of a tangent here, and a higher-level perspective, but... shouldn't the 
package definition DSL have support for this? then most package descriptions 
could be using package specifications instead of scheme variables, and 1) could 
be phased out. or would that be more error prone? maybe with a tool that warns 
for the equivalent of undefined variable warnings?

background:

the reason i'm facing this is that i'm using the machinery in an idiosyncratic 
way: i want to have an isolated module where a --recursive --pin-versions of 
the entire transitive closure of a project is captured. when some 
package/version is available already in guix, the importer skips it, but then 
refers to it through a missing variable reference. and if i want to have two of 
such golang packages (Swarm's bee, and geth) that share many of the 
dependencies/versions...

i know the arguments why it's considered a bad idea from the perspective of 
Guix, but then miscompiling the ethereum client can lead to losing money.

- attila
PGP: 5D5F 45C7 DFCD 0A39

bootstrapping scenario for a package

[Andy Tai]

Hi, I was trying to update mono to the current release version.  The
build step as documented actually says to download a minimal C#
compiler from the mono site which is then used to compile the rest of
the source to build the full system.   I looked and did not find the
source of this minimal compiler--so it is a black box in a way.

In free software it is ideal to build everything from source.   I
wonder how is such a package handled in Guix?   What is the strategy
for bootstrapping?   Thanks


(msg sent to help-guix first but this list may be more appropriate)

Re: Release v1.4 (or 2.0): process and schedule ?

[Bengt Richter]

Hi all,

On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote:
> Hi Simon,
> 
> zimoun  writes:
> 
> > Hi,
> >
> > Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
> > we go for v1.4 or v2.0?
> 
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes.  But that's just my personal opinion :-).  If the majority
> feels a 2.0.0 is more suitable, I won't mind.
> 
> > In both case, what is the target for a release date?  I propose January
> > 31rst.  WDYT?
> 
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.
> 
> [...]
> 
> >> The lesson of v1.0.1 [#,@] is: please help in testing the
> >> installer. :-)
> 
> Yes, I also feel we should give the installer a lot of testing; it seems
> many people have had issues with it, especially when dealing with newer
> EFI machines.  Unfortunately I don't have such a machine available for
> testing myself...
>

This seems, IIUC, like a FLOSS way to deliver multiple versions of guix
in the form of a collection of bootable ISOs in a single bootable image
for easy trial on various systems.
WDYT?

[0] https://www.theregister.com/2021/12/10/friday_foss_fest/?td=keepreading-btm
[1] git clone 'https://github.com/ventoy/Ventoy.git'

> >> How does it sound?
> >>
> >> Last, Guix is a “rolling-release“, so what does it mean ‘release’? :-)
> >> The main argument for releasing, IMHO, is communication and so attract
> >> potential new users. :-)
> 
> To me, it's a milestone that can be communicated and provides a more
> thoroughly tested (in theory) Guix installation image.
>
> Thanks for helping shape the release plan,
> 
> Maxim
> 
-- 
Regards,
Bengt Richter

Re: Organising Guix Days

[Ludovic Courtès]

Hello!

Julien Lepiller  skribis:

> I think it's time to start organising the Guix Days, traditionally held
> around Fosdem.
>
> During our guix-europe assembly, we discussed some options and everyone
> agreed they wanted a two-day event, online just as Fosdem. I attached a
> proposed blog post that we should put on the website as soon as we
> agree on the first details.
>
> I suggest that we have these days right after Fosdem, Monday and
> Tuesday. This should give us just a few more days to prepare, as I think
> we're starting pretty late already. If you prefer to have them before
> fosdem, I can change the blog post of course.

No strong opinion, but I wonder if some might prefer to have it a few
days later, so they can give their eyes and ears some rest.  :-)

> As for how it'll be organised. I propose to do something similar to
> what we need in November 2020. I'd love to get some talks from people
> outside the usual maintainers and commiters, to have an overview of the
> diversity of people and usage around Guix.
>
> Last year, we asked speakers to prepare a video in advance, and they
> would only have an extended Q/discussion session. I think this year
> we should have the same process, but ask for a short (3-5 minutes) talk
> at the start of the session to refresh our minds on the main points of
> the presentation before discussions start.

[…]

The whole program sounds great to me!

> Also, we need to secure a BBB instance :)

I think we can still use the same one as last year (zimoun?).  If that
doesn’t work, there’s a couple of options, such as Inria’s instance.

Thanks,
Ludo’.

p2p distributed substitutes; Swarm

[Attila Lendvai]

dear Guixers,

i have put together a Swarm service for Guix, that can start up Bee nodes of 
https://www.ethswarm.org/

Swarm is a censorship resistant p2p storage solution with a content addressable 
API, not unlike IPFS, but with crypto based incentives.

i'm considering adding Swarm as another backend to store and distribute 
substitute binaries. i lack the necessary overview of Guix substitutes, but i'm 
working closely with the Swarm developers.

is there anything written up anywhere about this topic? what i'm looking for is 
a very high-level bird's eye view of what components would be involved in such 
an endeavor, and what would need to be implemented in them.

is the architecture in question already prepared for multiple storage backends? 
or would it involve a refactoring of the Guix infrastructure?

i'm a seasoned CL coder, and getting accustomed in Scheme, too, but i'm a few 
months new to the Guix codebase.

as an answer i'd also appreciate any pointers to readings, including into the 
code, and even more so a wiki page where people interested in this project can 
draw the outlines, and coordinate on the implementation.

- attila
PGP: 5D5F 45C7 DFCD 0A39

PS: for now the Swarm service is in a PR for that other channel, because it 
fetches the binaries of Bee and the go ethereum clients. it's on my TODO to 
smarten up the go importer and put together a source based package for them 
that would be eligible for Guix proper.

Re: How to test modified shepherd services

[Attila Lendvai]

i have just finished my first Guix service. for now it's a PR for that other 
channel, so i'll copy-paste some stuff from it:

Run with something like this:

$(guix system --no-graphic vm path/to/swarm.scm) -m 2048

$(./pre-inst-env guix system --no-graphic vm /path/to/swarm.scm) -m 2048

this will build and boot an operating-system object in a Qemu VM, in the same 
terminal.

the file should return a simple-operating-system object, optionally wrapped 
into a marionette-operating-system if you also want to write/run automated 
tests.

i'll send you the link to the actual code in a private email.

- attila
PGP: 5D5F 45C7 DFCD 0A39

Re: Flag day for simplified package inputs

[Ludovic Courtès]

Hi,

Jelle Licht  skribis:

> From 69926c94fb576e503d7838836cfd83066c39abcc Mon Sep 17 00:00:00 2001
> From: Jelle Licht 
> Date: Mon, 13 Dec 2021 16:08:22 +0100
> Subject: [PATCH] maint: Ignore specified bulk changes in git blame.
>
> * etc/git/git-blame-ignore-revs: New file.
> * etc/git/gitconfig (blame): Add ignoreRevsFile.
> * doc/guix.texi ("Invoking guix style"): Document git-blame-ignore-revs usage.
>
> Signed-off-by: Jelle Licht 

LGTM, thanks!

Ludo’.

Guile documentation

[Ludovic Courtès]

Hi Blake,

Blake Shaw  skribis:

> While I've come to love Guile, compared to my experience with Racket its
> been quite burdensome for me to get in the hang of, something I attribute
> primarily to the structure of the docs, and not due to it being in any
> way more difficult than Racket. While with Racket I was writing
> useful programs in the standard #lang within my first week, with Guile
> I often find that what should be almost trivial winds up with a lot of
> time lost just trying to navigate and understand the docs. When I do
> figure things out, it turns out to be no more difficult than the equivalent
> in Racket, but a lack of consistency in the path that leads there in the
> docs cause hangups, which has made trivial scripts that should take an hour
> become weekend projects.

IWBN if we could take advantage of your fresh eye to restructure the
Guile manual in a way that makes it more convenient.

Guile has changed a lot since the manual was initially written, a lot of
sections were added, some removed, but we probably didn’t take the time
to sit down and see how to restructure it accordingly.

So if you have a specific structure in mind, or if you remember
precisely what was hard to find and located in a unexpected section,
please let’s take advantage of that!

Thanks,
Ludo’.

Re: core-updates-frozen branch merged

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).

I’m late to the party, but that’s because I’ve been contemplating my
updated Guixes for a week.  Thumbs up everyone and Maxim in particular
for getting it past the finish line!

That makes me wonder: do we even have a list of all the big changes that
made it into this branch?  Would be nice to come up with a summary.

Ludo’.

Re: build system option to allow CPU optimizations?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:

[...]

> It may very well be the wrong approach in principle, but I also think
> that it’s a neat escape hatch for specific use cases. Separating
> reproducibility patching makes the package transformation mechanism
> more powerful and appealing.  Much like respecting TESTS? makes it
> easy for users of modified packages to bypass a failing test suite,
> making patching of Makefiles to remove CPU tuning conditional would
> make for much less complex custom package definitions.
>
>> I found one case though where this is not possible: C++ header-only
>> libraries such as Eigen contain hand-optimized vectorized routines,
>> selected at build time, but we end up compiling Eigen users as the
>> x86_64/AArch64 baseline, which is a waste.  (If you do know of other
>> problematic cases, I’m interested in taking a look!)
>>
>> My solution to that is “package multi-versioning” via a
>> transformation
>> option.  Hopefully I’ll submit preliminary patches within a week or
>> so!
>
> Oh, exciting!

I forgot to mention it here, but it’s available for testing and probably
even ready to merge:

  https://issues.guix.gnu.org/52283

I think it makes an option to dismiss ‘-march’ removal unnecessary; or,
put differently, it achieves the same.

I’m interested in seeing which packages people would mark as “tunable”
and what performance gains it gives!

Thanks,
Ludo’.

Re: How to test modified shepherd services

[Simon South]

Nathan Dehnel  writes:
> I modified a shepherd service to accept a new field from config.scm
> and I was wondering how to test that it works correctly.

Assuming this is an existing Guix service, it's probably easiest to
update the corresponding system test suite under gnu/tests (if
necessary) to reflect your change, then run the suite with "make
check-system" (setting "TESTS" to limit it to the service in question)
to make sure everything works the way you expect.

If you're planning on contributing the change to Guix it would be good
to submit it along with an updated test suite anyway.

The Guix manual has a bit of information about this in Section 2.3,
"Running the Test Suite":

https://guix.gnu.org/en/manual/en/html_node/Running-the-Test-Suite.html#Running-the-Test-Suite

-- 
Simon South
si...@simonsouth.net

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

On Mon, 20 Dec 2021 at 10:04, zimoun  wrote:

>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.

>  - adapt the importers with the new style is also a thing
>  - various guix home minor fixes discussed [1] by Xinglu, Andrew and
>Ludo, a blog post would be neat too. :-)

Also this:

   http://issues.guix.gnu.org/issue/51319

Cheers,
simon

Demo: Debugging a flask app with pudb in a guix shell 1PM ET

[jgart]

Hi Guixers, 

I'm going to give a short demo over Big Blue Button on debugging a flask app 
with pudb Monday (today) at 1PM EST (approx +9 hours from now). 

I'll be using guix shell to set up a python development environment. 

Feel free to stop by:

https://meet.nixnet.services/b/jga-vi3-nyz-wgx

I had recently packaged pudb for guix: https://github.com/inducer/pudb

all best,

jgart

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

Hi Maxim,

On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer  wrote:
> zimoun  writes:

>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>> we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes.  But that's just my personal opinion :-).  If the majority
> feels a 2.0.0 is more suitable, I won't mind.

I do not have a strong opinion either.  On the other hand, all the
changes are incremental over a relatively large period of time, other
said, each change is not revolutionary but all in all, they can be
considered as.  The revolution of the Sun is made by 365 small changes
and each day compared one by one looks really similar – aside climate
change or tropical/equatorial latitude – and at the end, seasons appear.

Anyway, I won’t mind equally. :-)


>> In both case, what is the target for a release date?  I propose January
>> 31rst.  WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.

To me,

 - adapt the importers with the new style is also a thing
 - various guix home minor fixes discussed [1] by Xinglu, Andrew and
   Ludo, a blog post would be neat too. :-)


1: 



Cheers,
simon

Re: SSH service for Guix Home

[Andrew Tropin]

On 2021-12-17 15:21, Xinglu Chen wrote:

> Hi,
>
> On Wed, Dec 15 2021, Ludovic Courtès wrote:
>
>> Hi Andrew,
>>
>> One service I miss for Guix Home is ‘home-ssh-service-type’, which is in
>> the “original” Guix Home.
>>
>> Could you contribute a patch adding it?  (I could do it on your behalf,
>> but it sounds more logical to let you handle it.)
>
> Being the original author, I will hopefully try to work on it soon.  :-)
>

It works for me.  Would be very glad if you accomplish it.

>> Also, could you (or Xinglu, or Oleg) write a blog post for
>> guix.gnu.org, targeting an audience who’s not familiar with this kind
>> of tool, making it clear what the rationale is and what it can bring
>> to “normal users”?  It would be really helpful to have that published
>> within a couple of weeks or so, before the next release.
>
> That sounds like a good idea, I would be happy to help!
>

I will make a patch with skeleton of the post and will send it to you
and mailing list for review and discussion.  I think it is the easiest
way to cooperate on a blog post.

>> Last, it’d be great to see the three of you (and more people!) back in
>> action regarding Guix Home.  I understand that life sometimes gets in
>> the way, but it seems that there’s been some confusion as to how to go
>> forward—e.g., —which may partly
>> explain why things stalled.  If there are patches waiting for review,
>> also don’t hesitate to ping!
>
> Yeah, apologies for not being very active in the last few months.
>
> I think one of the problems is that there is not really any style guide
> for now to write services (I do have a WIP patch in my local tree that
> will document most of (gnu services configuration) though :-)).  We also
> lack a way to properly test home services; we would need something
> similar to what Nix Home-manager has[1][2].
>
> [1]: Nix code for configuring a program
> 
> [2]: Expected content of the serialized configuration
> 
>

Yep, having a workflow for writing guix service's tests will be also
cool.  I see a few files in test/services/, but it doesn't seem to have
a well-established approach, just a few functional tests.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature