Re: RISC-V is giving away developer boards

[Pjotr Prins]

On Sat, May 01, 2021 at 06:14:14AM +0200, Bengt Richter wrote:
> Could some riscv-model-version.scm be written to use qemu to create
> an exact virtual metal RISC-V board (of the kind being sampled, for starters)
> for use on our laptops and PCs?
> 
> I think that might get more people involved, and would ideally produce
> images that would "just work" on the bare metal boards.
> 
> Maybe guix could become a preferred RISC-V development environment :)
> 
> Thoughts?

QEMU supports RISC-V and boots. Currently there are some Linux
development images floating around. A port should be possible.

But I think that real hardware is a major incentive. Besides industry
may pick up interest in our work (offering free boards shows they want
more development) if it runs on actual hardware. GNU Mes was ported by
Danny to arm64, so the port should not be too hard and Jan and
colleagues are happy to help. One can even apply for a grant at NLNet
that pays for a year of work:

https://nlnet.nl/news/2021/20210401-call.html

Note that GNU Mes kicked off with such a grant, as well as the arm
port.  We are happy to help with writing the grant too.

RISC-V is very exciting and will be performant. It is small, runs
cooler and therefore many more independent cores fit on the dye. Think
GPU without the disadvantages. Next to IoP RISC-V will power desktops
and perhaps supercomputers.

Pj.

GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hello Guix!

A first RC for the upcoming 1.3.0 release is now available for testing:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.3.0rc1.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz

  system installation:

https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.i686-linux.iso.xz

https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.x86_64-linux.iso.xz

  virtual machine image:

https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz

SHA256 hashes:

46525e84d2a1d30a53bb40569de23bb1813b8df78731d09b5eac977818106ea7  
guix-1.3.0rc1.tar.gz
2427e73f5f18c51446174cd230b6dc19c8461838641bec6f66761537e7aa7ad4  
guix-binary-1.3.0rc1.aarch64-linux.tar.xz
89028139d049e1a868d41c5d1155f6b3be1b1b0407d93bfa86b7c713a87c1daf  
guix-binary-1.3.0rc1.armhf-linux.tar.xz
5da4edf9075c87d575d653140b53fe316305f94b58179aa935af223f037b36c2  
guix-binary-1.3.0rc1.i686-linux.tar.xz
f7c2a42f9f48fc6b2d7ba672ed49c3a6fc483cb3fbe261a8a79385b8381205ec  
guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
3348ec2fd116ed97c1806f8eac777ab2f7cff2b466b7c0dc5c2d1a904e4395f7  
guix-binary-1.3.0rc1.x86_64-linux.tar.xz
429deb5af3a956e7530cd0ed4cab7d5b13a7f1d22a0fe690f6714ab89a846db6  
guix-system-install-1.3.0rc1.i686-linux.iso.xz
a1772a8d08729471e7b1c04ac4d9213f4db077458aeacc59d14ff9f2399357b2  
guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
58ccabbc61cd00d9b1ec1f417360827aa2f8428567f1cfb0a83dc2191e67897e  
guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
.

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download .  Uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
 should pick up 1.3.0rc1 automatically.

  2. Testing the graphical installer of Guix System.

  3. Testing the VM image.

In any case, please report success, failure, and annoyances in this
thread.

The remaining outstanding issues, which you can track here [0], are as
follow and affect the installer:

47567 Installer crash in 'uuid->string' for a FAT16 partition
44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID

If everything goes well, the final release is planned for the 10th of
May, which gives us about a week to test and fix any remaining issues.

Thanks in advance!

Maxim

[0]  http://issues.guix.gnu.org/47297

Re: Leaving the GNU Guix community

[Chris Marusich]

Hi Léo,

I'm sorry to hear that you feel that you need to leave the community.  I
can understand why you feel that way, but I hope you'll remember that
(to my knowledge) nobody has said that they don't want you here.

I realize that in this moment, it must sting terribly to have your
commit rights temporarily revoked.  However, even before you gained
commit access, you contributed great things to Guix: patches, ideas,
computing resources, your energy and enthusiasm, and so on.  I
personally know that we would not have ported Guix successfully to
POWER9 without your help!  I guess what I'm trying to say is that even
without commit access, it's possible to be a contributor and a community
member.  And in any case, the maintainers have made it clear that the
commit access suspension does not need to be permanent:

https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html

They said:

"I'm sorry to say your commit privileges have been temporarily
suspended.  After one month, you are invited to get in touch with the
maintainers collective and discuss next steps."

They have explicitly left the door open.

By the way, speaking of contributions, I think your latest email here
raises some very good points.  I don't have good solutions to suggest
for any of them, I'm afraid, but I can say that I share many of your
concerns.  The "user experience" can definitely be better in many ways.
I also agree that the line between "user" and "developer" can and should
be blurred (programs like Emacs or LibreOffice or RenPy come to mind).
The more the line can be blurred successfully, the more it can empower
the user/developer, but it is tricky to do.  I mean, how many
non-programmers do you know who really use Emacs (or Vim)?  Personally,
I know none.  I know a lot of people who use Excel, though, or programs
like RenPy which are easy to "script" - i.e., program.  There are ways.

I also think it is more difficult than necessary to get started
contributing to Guix.  I wish it were easier, but I don't have any good
suggestions for that right now, either.  I think a lot of people who
have played with Guix code and participated in the Guix community also
experience these same difficulties, but I guess maybe people don't talk
about it too much because it's truly hard to come up with better
solutions than what we have.  There is also the issue of lack of time;
for those contributors (like myself, currently) who work on the project
only as volunteers in their spare time, it can sometimes be difficult to
find the time.  People tend to contribute in areas they are interested
in, which is fair, and there is always far more work to do than any
single person can finish on their own.

I wish you the very best in whatever you do, and I hope you'll return to
the Guix community when you feel that we can collaborate together again.

-- 
Chris


signature.asc
Description: PGP signature

Re: RISC-V is giving away developer boards

[Bengt Richter]

Hi all,

On +2021-04-30 21:35:22 +0200, Pjotr Prins wrote:
> It is probably a good idea to apply from an academic institution to
> increase chances of getting a free board. I am happy to help with the
> application.
> 
> We already have the 2GB RAM polarfire which we mostly use for toy
> stuff right now:
> 
> https://www.cnx-software.com/2020/07/20/polarfire-soc-icicle-64-bit-risc-v-and-fpga-development-board-runs-linux-or-freebsd/
> 
> If anyone is serious about a GNU Mes and/or GNU Guix port I can help
> find a RISC-V board one way or another. Sounds like time and money
> well spent to me.
> 
> Pj.

Could some riscv-model-version.scm be written to use qemu to create
an exact virtual metal RISC-V board (of the kind being sampled, for starters)
for use on our laptops and PCs?

I think that might get more people involved, and would ideally produce
images that would "just work" on the bare metal boards.

Maybe guix could become a preferred RISC-V development environment :)

Thoughts?

> 
> On Fri, Apr 30, 2021 at 01:15:49PM -0400, Leo Famulari wrote:
> > On Fri, Apr 30, 2021 at 06:36:29PM +0200, Ludovic Courtès wrote:
> > > Could interested developers raise their hands?  :-)
> > 
> > I previously applied for early access to the BeagleV:
> > 
> > https://beagleboard.org/beaglev
> > 
> > I wasn't selected and I decided to focus on aarch64 for now.
> > 
> > Hopefully some other people can step up and apply via this new program!
> > 
> 

-- 
Regards,
Bengt Richter

Re: Leaving the GNU Guix community

[Tobias Geerinckx-Rice]

Léo,

Leo Le Bouter 写道：

I feel like what has happened is really a disaster,


I'm relieved that we share, at least, this.  I think everyone 
does.


I don't feel like contributing to GNU Guix anymore in the 
future.


That's a great pity.  I hope to welcome you back some day.  Guix 
is better off with your fixes.


Yet I'm convinced that the decision to suspend commit access was 
the right one.  It wasn't easy.  Nobody was happy about it.


I also hope that you can accept your role in the events that lead 
to it and learn from them and make adjustments.


I'm disappointed that you still deflect the brunt of the 
responsibility to others and refuse to acknowledge that this, 
itself, is a problem.  Saving face consistently took precedence 
over accepting feedback.  That's a dangerous blind spot to have.



I think that the GNU
Guix maintainers justify unacceptable behavior and have acted 
upon
things without understanding them, not understanding why 
incidents have

happened


We have a much better understanding of the *complete* situation 
than you imply.  It's far too common and too convenient to claim 
that people you don't agree with are (at best) uninformed.


We've certainly made mistakes over the years.  Being buggy humans 
we'll be sure to make more.


Several contributors expressed (in at least one case: severe) 
unease with your attitude long before Mark sent his own unpleasant 
message, and I think we did too little and waited too long to 
publicly address either in a coordinated manner.  Lesson 
hard-learnt.


that many people have spread misinformation that other believed 
also. 


I refuse to credit this vague insinuation.  My mind was made up by 
nothing but your own posts to this list and your blunt refusal to 
answer questions.


Kind regards,

T G-R

PS: I wanted to keep this short, but thank you for sharing your 
thoughts or Free software development.  I read them with interest.


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

On Fri, 30 Apr 2021 18:05:15 +0100
Christopher Baines  wrote:

> >
> > Task 1: Add instrumentation to identify the slow parts of processing
> > new revisions:
> >
> >   - Implementing a chart over time to identify slow parts:
> > - The chart should consider two aspects, the time took by
> >   each specific part, and its name, for identification
> >   purpose. A bar chart is a good candidate for this task, it is
> >   simple and can show the whole picture of the time taken by the
> >   system to process a new revision;
> > - The bars on the chart should be sorted in order of
> >   precedence of the process in the X axis, and its height, which
> >   is determined by the time it takes, measured in the Y
> >   axis;  
> 
> I'm not sure what you mean by "precedence of the process" here?

As we are concerned only with the time each process takes, and each bar
on the chart will be presented side by side, the order of the bars would
be the order that the processes appear. If you prefer, they could be
sorted alphabetically, or by time taken.

> > - The charts should work as picture-logs for timing;
> > - A chart should be generated for each new revision in real
> >   time; 
> 
> It would be good to say explicitly how the chart will be stored, since
> "the same way as the logs already are" is quite vague.

I misunderstood this point so this part about storing the chart is
completely messed. But I think now I got it. Let me correct the last
point and add some more:
  ...
- The time is already being computed for each part and it
  is shown in the logs, the same data can be used to build the charts.
  The data to build the chart for each revision could be
  stored as a new table in the database*, first in parts, for
  when a revision is still being processed, then combining their
  parts when the processing is finished.
- The new table on the database should store three information:
  the job_id, the action, and the time taken.
- Then, when one wants to see the chart, this table is queried
  and the chart is rendered as html.

* Although the information is already in the log, it is stored as a
  text, so it is harder to get the names of the actions and the time
  taken by each, so I think that create a new table, with only these
  values, is more suitable. 
> 
> Great, this is more like it.

:)

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

Unfortunate statefulness of Guix Install image

[Vladilen Kozin]

Hello Guix.

This may or may not be a "bug", but thought I'd report something I run
into. I found that GUI install never worked for me but booting off
Guix Install USB and then following
https://guix.gnu.org/manual/en/html_node/Manual-Installation.html
worked perfectly fine. Except, when you try to do the manual install
off the same USB ... twice. That is, having installed a system once
off that USB, you then try to install another and your `guix system
init path/to/config.scm /mnt` would almost immediately fail with error
saying that some expected derivation have not been found in the store.

My best guess from what I've read in the manual is this. Store is not
the only place where derivations appear. /var/guix/db stores metadata
about said derivations. So the first time you do `herd start cow-store
/mnt` trick it'll create the store there but will populate the db on
that USB drive. Next time you try to install from that same USB on a
different machine it'll have its db reference derivations that are no
longer available. I worked around this by stupidly `mv /var/guix/db
/var/guix/db.old` and `guix system init` went without trouble.

I guess my complaint is that at least the manual way (maybe GUI
install, too) is completely stateful and turns that USB stick into
"consumable good" unless you know about the database.

Sorry, dunno enough about Guix, so maybe I've been doing something wrong.
-- 
Best regards
Vlad Kozin

Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

[Vincent Legoll]

Thanks Christopher, Mathieu & Ludo to help us understand what's going on

-- 
Vincent Legoll

Re: A "cosmetic changes" commit that removes security fixes

[Pjotr Prins]

On Fri, Apr 30, 2021 at 07:40:36PM +0200, Pierre Neidhardt wrote:
> I trust that it is the case, but being the devil's advocate, I could
> argue that from reading this thread does not make it obvious.  Maybe the
> decision process should be made more transparent?

Let's not make this a big thing. I am not a core committer - don't
want to be one. What I know is that commit rights are given to people
who are expected to play by the rules of the project.

Is that hard to understand?

When someone does not play by the rules and is unapologetic - and it
happens multiple times - it is completely justified to take away those
rights.

Being a core committer is *not* a badge of honour. It does not give
special privileges beyond what is expected. It does not give you
money, a degree or a knighthood. It only allows you to push code
directly where it interferes with the work of others :)

Everyone will be *happy* to give the commit rights again, provided the
person plays by the rules.

Pj.

Re: RISC-V is giving away developer boards

[Pjotr Prins]

It is probably a good idea to apply from an academic institution to
increase chances of getting a free board. I am happy to help with the
application.

We already have the 2GB RAM polarfire which we mostly use for toy
stuff right now:

https://www.cnx-software.com/2020/07/20/polarfire-soc-icicle-64-bit-risc-v-and-fpga-development-board-runs-linux-or-freebsd/

If anyone is serious about a GNU Mes and/or GNU Guix port I can help
find a RISC-V board one way or another. Sounds like time and money
well spent to me.

Pj.

On Fri, Apr 30, 2021 at 01:15:49PM -0400, Leo Famulari wrote:
> On Fri, Apr 30, 2021 at 06:36:29PM +0200, Ludovic Courtès wrote:
> > Could interested developers raise their hands?  :-)
> 
> I previously applied for early access to the BeagleV:
> 
> https://beagleboard.org/beaglev
> 
> I wasn't selected and I decided to focus on aarch64 for now.
> 
> Hopefully some other people can step up and apply via this new program!
> 

Re: RISC-V is giving away developer boards

[Mark H Weaver]

Ludovic Courtès  writes:
> Could interested developers raise their hands?  :-)

I'd be glad to help with development of the port, but I do not have
enough spare cycles at present to help with the process of applying to
get the hardware.

   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Leaving the GNU Guix community

[Pierre Neidhardt]

Hi,

Ludovic Courtès  writes:

> You write that “the difference between the beginner and the experienced
> is a construction”.  I sympathize with your rejection of the
> student-professor domination.  However, I think newcomers can and should
> benefit from guidance by the experienced; that’s the only way we can
> truly blur the experienced/beginner distinction.  As an “experienced”
> person in this project, I consider it part of my work to help others.  I
> believe knowledge sharing can be achieved without it becoming a
> domination relation.  That is at least what I think most people here
> strive for.

I have been wanting to raise this issue for a while, so maybe now is the
right time! :)

On the educational level, I fully agree with Ludo.

I wonder, however, if this educational hierarchy does not transpire into
political hierarchies.

In other words, if we certainly need experienced users to teach and help
newcomers, do we need experienced users to take more executive decisions
than newcomers?

At the moment, it seems that the right to police others is reserved to a
privileged group.  Should it really be this way?  It does not seem
obvious to me that this separation benefits the community, maybe there
would be an interesting discussion to have here.

For instance, if a long-term, experienced contributor misbehaves (be it
with commits or communication), can they be policed?  The same way that
less experienced users are policed?  By whom?
Can a less experienced user police an experienced one?

There is a lot to discuss here, including transparency of communication,
class of privileges, protocols for exclusion, etc.

I don't know if these issues have been raised and addressed in the Guix
community; maybe there is room for improvement.  Anyhow, discussing more
about these things can only help organizing ourselves better and
building a stronger community! :)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: RISC-V is giving away developer boards

[Vincent Legoll]

Hello,

On Fri, Apr 30, 2021 at 7:08 PM Ludovic Courtès  wrote:
> Mark H Weaver  skribis:
>
> > This might be of interest:
> >
> >   https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/
> >
> > Perhaps the Guix project would like to apply to get one of these?
> > What do you think?
>
> That’d be great; a few people were interested in a port to RISC-V.
>
> Could interested developers raise their hands?  :-)

I am interested.

-- 
Vincent Legoll

Re: wip-ungrafting builds stuck

[Leo Famulari]

On Fri, Apr 30, 2021 at 06:32:54PM +0200, Ludovic Courtès wrote:
> I’ve just merged ‘wip-ungrafting’ in master!  It was at 76% according to
> , with mostly ARM builds missing compared to
> ‘master’.  Now we have fresh binaries to download (or build)!

Hooray!

> Thanks Leo for getting it into shape!

Hopefully it is in good shape. All that I did let the build farm work
and then upgraded / reconfigured my x86_64 systems based on it.

I don't expect any problems. I decided what to ungraft based on the
criteria explained in this thread:

https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00331.html

Re: RISC-V is giving away developer boards

[Leo Famulari]

On Fri, Apr 30, 2021 at 06:36:29PM +0200, Ludovic Courtès wrote:
> Could interested developers raise their hands?  :-)

I previously applied for early access to the BeagleV:

https://beagleboard.org/beaglev

I wasn't selected and I decided to focus on aarch64 for now.

Hopefully some other people can step up and apply via this new program!

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> Hi,
>
> On Thu, 29 Apr 2021 21:14:10 +0100
> Christopher Baines  wrote:
>
>> Great, can you add more detail to this bit? Given the instrumentation
>> is a really important part, it would be good to have some working
>> ideas for what this chart might look like, and what goes in to making
>> it (like where the data comes from and if and where it's stored).
>
> Task 1: Add instrumentation to identify the slow parts of processing
> new revisions:
>
>   - Implementing a chart over time to identify slow parts:
>   - The chart should consider two aspects, the time took by
> each specific part, and its name, for identification purpose.
> A bar chart is a good candidate for this task, it is simple
> and can show the whole picture of the time taken by the
> system to process a new revision;
>   - The bars on the chart should be sorted in order of precedence
> of the process in the X axis, and its height, which is
> determined by the time it takes, measured in the Y
> axis;

I'm not sure what you mean by "precedence of the process" here?

>   - The charts should work as picture-logs for timing;
>   - A chart should be generated for each new revision in real
> time;
>   - The time is already being computed for each part and it is
> shown in the logs, the same data can be used to build the
> charts. This way data does not need to be stored, because the
> chart can be built in real time, but the chart itself needs
> to be stored, in the same way as the logs already are.

It would be good to say explicitly how the chart will be stored, since
"the same way as the logs already are" is quite vague.

>> I'd try to set out more of a strategy, so what might be causes of
>> slowness, how would you investigate them, and what are common
>> approaches to making those things faster?
>
> Task 2: Improve the performance of these slow parts:
>
>   - Select candidate parts to be analyzed;
>   - Identify the causes of slowness:
>   - If it uses queries, perform query analysis, for example using
> EXPLAIN and ANALYZE, get its statistics and improve them when
> needed;
>   - On the code, investigate the structure, for example, using
> Tracing to discover if a recursion is too long and if it can
> be modified to be tail recursive.
>   - Implement the required improvements.
>
> In fact, I have never performed improvements on queries or code this
> way, but I am studying. Please, tell me if I am missing important
> details. See what you think about that.

Great, this is more like it.


signature.asc
Description: PGP signature

Re: RISC-V is giving away developer boards

[Andreas Enge]

Hello Mark,

Am Fri, Apr 30, 2021 at 11:29:59AM -0400 schrieb Mark H Weaver:
> This might be of interest:
>   https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/
> Perhaps the Guix project would like to apply to get one of these?
> What do you think?

interesting offer, thanks for sharing it! It says that to obtain a board,
one needs to be a "RISC-V member", then the "join" link goes to a mailing
list on HPC. But there are more details on membership at:
   https://riscv.org/membership/

Individuals can become "community member" without fee, or we could also
have Guix Europe be a "community member" as a "registered non-profit".

Then there are pages and pages of fine print, which I did not yet take
the time to read.

Individuals affiliated to one of the existing members (among which there
are research institutes and so on) could also apply, I think.

In any case, we would first need volunteers for working on the port
before looking into the details.

Andreas

Re: RISC-V is giving away developer boards

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> This might be of interest:
>
>   https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/
>
> Perhaps the Guix project would like to apply to get one of these?
> What do you think?

That’d be great; a few people were interested in a port to RISC-V.

Could interested developers raise their hands?  :-)

If a couple people are interested in working on the port, we can apply
on behalf of the project and then make it available to those people.  If
things go well, we can eventually plug it in ci.guix as our first build
machine for the new architecture.

Who’s interested in coordinating the effort and applying?

Thanks,
Ludo’.

Re: wip-ungrafting builds stuck

[Ludovic Courtès]

Hey there!

I’ve just merged ‘wip-ungrafting’ in master!  It was at 76% according to
, with mostly ARM builds missing compared to
‘master’.  Now we have fresh binaries to download (or build)!

For the record, ‘wip-ungrafting’ was merged in ‘version-1.3.0’ a few
days ago already.

Thanks Leo for getting it into shape!

Ludo’.

Re: Leaving the GNU Guix community

[Ryan Prior]

On Thursday, April 29th, 2021 at 11:43 PM, Leo Le Bouter  
wrote:

> I feel like what has happened is really a disaster, I don't feel like 
> contributing to GNU Guix anymore in the future.

Hey Léo, thank you for writing & for all your contributions. As a security 
professional I feel you deeply on the points you brought up and see how it 
would be frustrating for you to continue. Hope to catch you around & continue 
hacking together sometimes, it's been a pleasure!

Ryan

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

Hi,

On Thu, 29 Apr 2021 21:14:10 +0100
Christopher Baines  wrote:

> Great, can you add more detail to this bit? Given the instrumentation
> is a really important part, it would be good to have some working
> ideas for what this chart might look like, and what goes in to making
> it (like where the data comes from and if and where it's stored).

Task 1: Add instrumentation to identify the slow parts of processing
new revisions:

  - Implementing a chart over time to identify slow parts:
- The chart should consider two aspects, the time took by
  each specific part, and its name, for identification purpose.
  A bar chart is a good candidate for this task, it is simple
  and can show the whole picture of the time taken by the
  system to process a new revision;
- The bars on the chart should be sorted in order of precedence
  of the process in the X axis, and its height, which is
  determined by the time it takes, measured in the Y
  axis;
- The charts should work as picture-logs for timing;
- A chart should be generated for each new revision in real
  time;
- The time is already being computed for each part and it is
  shown in the logs, the same data can be used to build the
  charts. This way data does not need to be stored, because the
  chart can be built in real time, but the chart itself needs
  to be stored, in the same way as the logs already are.

> I'd try to set out more of a strategy, so what might be causes of
> slowness, how would you investigate them, and what are common
> approaches to making those things faster?

Task 2: Improve the performance of these slow parts:

  - Select candidate parts to be analyzed;
  - Identify the causes of slowness:
- If it uses queries, perform query analysis, for example using
  EXPLAIN and ANALYZE, get its statistics and improve them when
  needed;
- On the code, investigate the structure, for example, using
  Tracing to discover if a recursion is too long and if it can
  be modified to be tail recursive.
  - Implement the required improvements.

In fact, I have never performed improvements on queries or code this
way, but I am studying. Please, tell me if I am missing important
details. See what you think about that.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

RISC-V is giving away developer boards

[Mark H Weaver]

Hello Guix,

This might be of interest:

  https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/

Perhaps the Guix project would like to apply to get one of these?
What do you think?

  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

[Ludovic Courtès]

Hello!

Mathieu Othacehe  skribis:

> We have already discussed the Cuirass vs Build coordinator situation in
> the past. I haven't changed by mind on that subject. The Guix Build
> Coordinator is more or less the equivalent of the Cuirass remote build
> mechanism[2].

Yes.  So to answer Vincent’s question with my own words and as an
outsider: the Guix Build Coordinator focuses on distributing builds
across several machines that may come and go dynamically.  This is
similar to cuirass-remote-worker.

One difference I see is that cuirass-remote-worker uses ZMQ for
communication while the Coordinator uses HTTP, which makes it easier to
use in a more distributed and dynamic context (HTTP goes through all
firewalls).  Cuirass-remote-worker can discover the central server via
Avahi discovery, which makes it easy to add new workers but is limited
to LANs.  On berlin, a WireGuard VPN was set up to address this (the
non-x86 build nodes are far away from the rest of the build farm).

Another one is that, because the Coordinator focuses on builds, it
brings specific features, such as retrying failed builds.

I like that the Coordinator is quite orthogonal; you can use it together
with the Data Service, or you can use it as an alternative to the
daemon’s offload mechanism.

Conversely, Cuirass is more of an all-in-one solution.  Depending on how
you look at it, it can be a weakness, but it’s also a strength when it
comes to deploying a “build farm” kind of service (I think it’s a good
fit for ci.guix).  Its monitoring features and dashboards have become
very nice and well adapted to someone willing to build packages from a
bunch of channels.

> Integrating the Build coordinator in the Berlin build farm would mean
> hooking in to Cuirass as an alternative to the remote build mechanism. I
> don't think it would be wise because:

[...]

> It really makes me sad that we have two pieces of software that are
> stepping on each other toes. The Build coordinator has a nice concept
> and represents a huge amount of work. However, integrating it to Berlin
> is not an option for me.
>
> I think that the next challenges on the CI front are:
>
> * Increase the number of ARM machines in the build farm.
>
> * Work on substitutes mirrors.
>
> * Find a way to make Cuirass and the Data Service work together.
>
> and we should face those issues together, rather than having competing
> software sharing the few build machines we own.

Right, I think the fruitful way to frame it is not “which one is
better”, but rather how can we take the good things from each approach.

For example, I believe the Guix Data Service relied on the former
Cuirass notification mechanism to learn about build status.  That
mechanism is gone, so “we” (i.e., you :-) Chris & Mathieu) should make
sure the Data Service can take advantage of the new notification
mechanism, possibly adjusting it so there’s a good match.

There are certainly other opportunities for cooperation in this area.
The Data Service does things that Cuirass doesn’t do, such as linting.
It wouldn’t make sense IMO to extend Cuirass to do these things; instead
we should find ways to aggregate and present all this information in the
Data Service.  It already does that to a large extent, but maybe we can
think of tighter integration, such as providing QA-oriented pages
instead of the more generic interface it currently provides.

Thoughts?

Ludo’.

Re: Guix Home upstreaming plan

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin  skribis:

> There is a goal[0] to make Guix Home[1] a part of GNU Guix.  It will reduce
> the duplications between projects, increase integrity and will provide
> Guix users with a missing tool for declarative configuration of home
> environments improving out of the box experience and allowing Guix users
> on foreign distros to have Guix System-like experience.

So, I have yet to go ahead and use it for myself to get a better feel.
In the meantime, I looked at
, and I like what I
see!  It’s great that you already have clear documentation and that
everything looks consistent with the rest of Guix.

Since this kind of tool is rather unusual (there’s no real equivalent
I’m aware of in other distros), I think the manual will have to
carefully explain what problems this solves and explain why someone
would want to use it.  For example, I think the term “home environment”
should be defined upfront (I’d summarize it as user configuration files
+ user services, from my reading.)

> civodul, can we create a separate guix-home branch to work against it?

I’m all for it.  We’ll have to discuss it together, in particular among
maintainers, but an option would be to give you commit access for the
purposes of developing this branch.

I would also like to know what Julien thinks; I think it’s in our
interest to see cooperation and not competition between the two
approaches you developed.  Julien, WDYT of the plan?  More specifically,
is there anything about the design that you’d like to discuss before we
go further?  Are there guix-home-manager features that could eventually
make it in Guix Home?

I find the steady progress on Guix Home and the level of polish already
achieved pretty exciting.  If people agree, I think we could aim for
merging it in the next Guix release, which would leave us a few months.

Thank you!

Ludo’.

Re: Neovim plugin/addon packaging

[Efraim Flashner]

On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
> Greetings Guix,
> 
> I'd like to improve the experience of installing Neovim plugins/add-ons with
> Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
> nvim (the Neovim executable name) will be able to find plugins installed by
> guix at …/share/nvim/site.

I guess my first question is does it work? I think I first tried
something similar for vim with 'share/vim/vimfiles' but it didn't
actually work for vim.

> Currently, we only have one such package, neovim-syntastic. I'd like to add
> more. Many plugins are compatible with both vim and nvim. However, they
> search for plugins at different paths. Therefore, the vim-syntastic and
> neovim-syntastic packages, which use the copy-build-system, differ only in
> the destination directories of the install-plan (and changing "Vim" to
> "Neovim" in the description).
> 
> My initial inclination is to remove the duplication of maintaining two
> install-plans (and other arguments) by creating a procedure that would take
> as input a Vim package that uses copy-build-system and output a Neovim
> package with the install-plan re-written.
> 
> Perhaps that solution would be overwrought. How would you recommend handling
> this situation?

My first idea would be to have the one package install the files into
both directories and combine them, but I feel like it falls apart when
it comes to searching for vim/neovim plugins and naming. One package
with two names? Call it vim-neovim-syntastic?

If vim/neovim move more apart and actually need separate plugins in the
future then I guess it would make more sense to have two actual packages
that can be installed by name (vim-foo and neovim-foo).

> [0] https://issues.guix.gnu.org/48112
> 
> Best,
> Jack


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Leaving the GNU Guix community

[Leo Prikler]

Hello,

Am Freitag, den 30.04.2021, 01:43 +0200 schrieb Leo Le Bouter:
> I think that the GNU Guix maintainers justify unacceptable behavior 
1. What makes you think that?
2. How do you justify your own behaviour, specifically the kind of
behaviour, that others have asked you to justify?

> [The Guix maintainers] have acted upon things without understanding
> them, not understanding why incidents have happened
Where specifically?

> [M]any people have spread misinformation that other believed also.
What kind of misinformation was spread?

> I don't feel like there's any way forward to this, we really do not
> understand each other
Mutual understanding does not spring into existence from nowhere, it
requires effort.  You have always been quick to point out when you feel
misunderstood by others, but I don't feel you try to understand them in
turn.

> I don't know how to communicate the culture in some feminist/queer
> squats in France around Paris where I live, where we really feel
> together on the same page when it comes to these questions and where
> also we exclude people who don't understand these goals, in which I
> feel so good and where really every confrontation is avoided and has
> many values that building an inclusive community like GNU Guix wants
> to be.
I agree that avoiding conflict is a good heuristic when it comes to
being inclusive, but I don't think that purges are the way towards
inclusivity.

> I think that the technicality of software development must be
> redefined so that the hierarchy between the experienced and the
> beginner disappears, I think that to cast as a beginner or an
> experienced is an attitude, many people who are experienced cast
> themselves as beginners for various reasons and that some other
> people cast themselves as experienced for various other reasons. 
The notions of "beginner" and "experienced user" are already very weak
within Guix.  Of course, those who have a longer history of
contributing have accustomed to our rituals and thus feel less
alienated by them than someone who has to set up 'git send-email' for
the first time.  Such technical hurdles certainly exist, but I don't
think they bar anyone from contribution.  I feel the opposite is the
case.  Of all the software projects I've so far contributed to, Guix
was the easiest to get into.

> I think the difference between the beginner and the experienced is a
> construction, I think that such must be worked on so that every
> individual contributor can feel independent and empowered and also
> not have to define themselves towards the experienced. 
Guix already empowers its users long before they start contributing. 
As far as contributions are concerned I know of no process better than
peer review.

> I think that the technicality of software development implies a
> special kind of relationship with knowledge and experience, I think
> that also must be re-invented, and in other social environments like
> the feminist/queer squats I live in knowledge and experience is a
> really sensitive topic and people who have knowledge and experience
> are not always welcome to say what they know or what they think
> unsolicited and if they are solicited, there's also a way to say that
> to never imply a domination of student-professor, that to accept that
> someone does not want to hear about supposed knowledge and
> experience, and also needs and wants to feel proud and independent
> about what they are doing without the help of people with said
> knowledge or experience. 
I have no idea what to make of this blurb.  Are people really waving
around their commit log saying "I've contributed so and so many
packages, I am an expert™"?

> I think that in a sense, everyone must become a beginner. 
Everyone is a beginner.  Maybe not always, but also at no point never
again.

> I think it approaches a very fundemental topic of software
> development especially in Free Software communities that is to among
> others end meritocracy. I think that the world of Free Software and
> Open Source is tainted by that meritocratic spirit and that if we
> want to bootstrap inclusive communities we must embrace that
> underrepresented people also are of very varrying skill levels and
> that we must empower and include everyone no matter their skill
> level, and that this notion even of skill level disappears and that
> all people of varrying skill levels are also not interested in
> feeling submitted to a pre-existing group of people with knowledge or
> experience. 
I don't feel that Guix is tainted in the way you imply.  People
contribute according to their skill so as to satisfy their own and
other's needs.  When I say "contribute according to their skill", I
mean they use their (pre-existing or otherwise) knowledge of Scheme/the
Guix package API in particular to hack together mostly package
definitions, but also build systems, UI, the whole backend code, etc. 
And yes, that is certainly a skill to have.  You won't get package

Re: Leaving the GNU Guix community

[Ludovic Courtès]

Hi Léo,

I’m sad you reached the conclusion that our inability to understand each
other cannot be overcome; perhaps you’re right, though I like to believe
there’s always a way forward.  I hope we can meet each other again, in
Guix or other spaces in more favorable conditions, under less stress.

There’s a lot of food for thought in your message.  I think it’s fair to
say that maintainers and in fact most contributors have been paying
attention to welcoming people regardless of their experience level; the
manual, although technical, also strives to assume little knowledge in
the field.  We can certainly improve on both fronts, but at least this
is already a goal of the project.

You write that “the difference between the beginner and the experienced
is a construction”.  I sympathize with your rejection of the
student-professor domination.  However, I think newcomers can and should
benefit from guidance by the experienced; that’s the only way we can
truly blur the experienced/beginner distinction.  As an “experienced”
person in this project, I consider it part of my work to help others.  I
believe knowledge sharing can be achieved without it becoming a
domination relation.  That is at least what I think most people here
strive for.

Thanks again for your contributions.  I wish you the best for your
future endeavors.  We will welcome you back whenever you feel we can
work together again.

Ludo’.

Re: #:cargo-inputs don't honor --with-input

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel  skribis:

> FYI: yet another rust issue: #:cargo-inputs don't honor --with-input.

Uh.  More generally, Rust packages kinda create a “shadow dependency
graph” via #:cargo-inputs & co., which breaks all the tools that are
unaware of it.  It was discussed several times on this list, and
apparently it’s unfortunately unavoidable at this time.  :-/

Thanks,
Ludo’.