Guix Packaging Meetup - This Saturday from 14:00 EST (18:00 PM UTC)

[jgart]

Hi Guixers!

I'd like to invite you to a guix packaging meetup this Saturday, May 29 at 
14:00 EST (18:00 PM UTC).

We usually talk over at mumble.libremiami.org while pair programming with tmate 
on a Guix System VPS. 

Here's a mobilizon page with more info on the event: 

https://events.nixnet.services/events/4c6f60aa-4ab7-4431-b2b3-285a7dfd0fea

Hope to see you there!

jgart

Re: Rust freedom issue claim

[Jack Hill]

On Thu, 27 May 2021, Joshua Branson wrote:


In terms of languages trying to be replacements for C:

- Zig is one of the most famous ones, and will probably be the first C
 alternatives to reach 1.0.  https://ziglang.org/

- Odin https://odin-lang.org/

- scopes which using S-expressions  https://sr.ht/~duangle/scopes/

- Drew Devault's (creator or sway) secret programming language.  It may
 be the second language on this list to reach 1.0


Thanks for this list. Clearly we are living in a world of riches. I am 
also aware of:


- Carp https://github.com/carp-lang/Carp (s-expressions, research project)

- Pony https://www.ponylang.io/ (actors)

Best,
Jack

Re: Which kernel series to use in the installer and for installed systems?

[Mark H Weaver]

Hi,

Vagrant Cascadian  writes:
> Would it be too complicated to include both the latest LTS kernel and
> the most recently packaged kernel in the installer, and default to using
> the same kernel for the installation?

Sounds good to me.  More specifically, I would suggest offering the user
a choice between using the latest stable kernel, or using the latest
kernel from the most recent LTS series at the time of installation.

If the user chooses the latter option, the installer would produce an OS
configuration containing "(kernel linux-libre-X.YY)", where X.YY is
latest LTS series at installation time.

The idea is that if they choose the LTS kernel option today,
'linux-libre-5.10' would be put into their OS config, so they would stay
on the 5.10 kernel series until they explicitly update to a later
series.  This is a good choice for production systems where stability is
more important than running the latest code, and even for ordinary users
who wish to have control over when major kernel updates are done.

I would recommend avoiding the 'linux-libre-lts' variable, because it
fails to provide the primary benefit that LTS kernels are meant to
provide: the ability to postpone potentially disruptive major kernel
upgrades until a time of the user's choosing, when the user is prepared
for possible breakage.  Users who put 'linux-libre-lts' in their OS
configurations should expect that a major kernel upgrade will happen
several years before it is needed, and could happen unexpectedly any
time they upgrade their system.  Unless they carefully inspect the
'guix' command output _every_ time they upgrade their system, users of
the 'linux-libre-lts' variable are unlikely to notice a major kernel
upgrade until it has already been done.

Thoughts?

 Thanks,
   Mark

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

Re: website: A little help running the website locally

[Luis Felipe]

On Wednesday, May 26, 2021 1:46 PM,  wrote:

> Just a heads up that due to this thread, I've been able to run the website 
> locally too, that was one of my first realworld usage of guix, I'm slow on 
> this journey, but I've started it :)

Great :)


> Regarding the website itself, I wanted to adjust the package page, so that it 
> has a direct link to the package description from the github repository and 
> I've not managed my guile foo (which is 0.0001) enough to figure how to 
> adjust the code already present in case of lint error.
>
> Maybe a current maintainer can wipe such change faster than waiting for me to 
> advance my journey, I think it would benefit the website users to have direct 
> link to the .scm from the package description page, or even having it pretty 
> printed right on the page ideally.

I'm not sure I understand. I see that in the details page of a package there is 
a "Package source" field which links to the file and line where the package 
definition starts. See for example:

https://guix.gnu.org/en/packages/audacity-2.4.2/

Which links to audio.scm 
(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/audio.scm#n683). 
Or is it that for some packages the link is not working?

In any case, I think it would be good to report any issue to the issue tracker 
(https://issues.guix.gnu.org/), if it isn't already reported.

Re: Which kernel series to use in the installer and for installed systems?

[Vagrant Cascadian]

On 2021-05-27, Leo Famulari wrote:
> On Thu, May 27, 2021 at 11:10:21AM -0700, Vagrant Cascadian wrote:
>> Would it be too complicated to include both the latest LTS kernel and
>> the most recently packaged kernel in the installer, and default to using
>> the same kernel for the installation?
>
> I'm a bit confused about what you are suggesting? Do you mean, offering
> both of those versions in a menu to the user?

Yes, at the installer's grub (or other bootloader) menu.


>> Of course, it bloats the installer having a second kernel on it... and
>> maybe the increased complexity to explain which to choose would be too
>> much...
>
> The installer does not "include" built packages, aside from what is used
> by the installer's OS.

Yes, but if you're using the installer, it will choose to install *some*
kernel on the installed system, so it could pick the most similar kernel
(e.g. linux-libre vs. linux-libre-lts) on the initial install...

There may be cases where a newer kernel wouldn't run on a particular
piece of hardware, or where the older LTS kernel wouldn't run, so making
it easy to pick between those two seems worth considering if there are
not too many other drawbacks.


So, my answer to the question "which kernel ...?" is ... maybe both!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [PATCH RFC 0/4] Getting rid of input labels?

[Maxime Devos]

Ludovic Courtès schreef op wo 26-05-2021 om 15:43 [+0200]:
> Hi Maxime,
>[...]
> In many cases, you don’t need the ability to refer to a specific input;
> you just need all the inputs to contribute to search path environment
> variables, and that’s enough.  A “label collision” does not matter at
> all in this case.
> 
> In some cases, you do need to refer to a specific input, as in:
> 
> [...]

> In this case, there are now two options:
> 
>   1. Arrange so that label is unique among your inputs, as is already
>  the case.
> 
>   2. [...]
>
> Do you think there are unaddressed issues with go-ipfs-migrations?

As long as there remains a possibility of overriding the ‘default‘ label
generated from the package name, then everything seems ok for the
(not-yet-packaged) go-ipfs-migrations. This appears to remain the case,
so ok?

Greetings,
Maxime.



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

Re: Which kernel series to use in the installer and for installed systems?

[Leo Famulari]

On Thu, May 27, 2021 at 11:10:21AM -0700, Vagrant Cascadian wrote:
> Would it be too complicated to include both the latest LTS kernel and
> the most recently packaged kernel in the installer, and default to using
> the same kernel for the installation?

I'm a bit confused about what you are suggesting? Do you mean, offering
both of those versions in a menu to the user?


> Of course, it bloats the installer having a second kernel on it... and
> maybe the increased complexity to explain which to choose would be too
> much...

The installer does not "include" built packages, aside from what is used
by the installer's OS.


signature.asc
Description: PGP signature

Re: Which kernel series to use in the installer and for installed systems?

[Vagrant Cascadian]

On 2021-05-27, Leo Famulari wrote:
> I'm not sure exactly how the situation could be improved. Maybe the
> installer and the operating-system declarations that it generates could
> instead use one of the "longterm" [1] kernel series?
>
> I'm not totally comfortable steering users to these longterm kernels
> series, since they are more buggy and less featureful than newer kernel
> series, but at least they do not change very much.
>
> What do you think?

Would it be too complicated to include both the latest LTS kernel and
the most recently packaged kernel in the installer, and default to using
the same kernel for the installation?

Then, if one kernel didn't work for someone, they could try the install
with the other kernel without having to download a separate image.

Of course, it bloats the installer having a second kernel on it... and
maybe the increased complexity to explain which to choose would be too
much...


live well,
  vagrant


signature.asc
Description: PGP signature

Which kernel series to use in the installer and for installed systems?

[Leo Famulari]

At the time of the recent 1.3.0 Guix release, the "default" linux-libre
kernel series was the 5.11 series [0]:

--
(define-public linux-libre-version linux-libre-5.11-version)
(define-public linux-libre-pristine-source linux-libre-5.11-pristine-source)
(define-public linux-libre-source  linux-libre-5.11-source)
(define-public linux-libre linux-libre-5.11)
--

In upstream parlance [1], 5.11 was a "stable" series, meaning it would
get updates until the next major release, 5.12.

Soon after the Guix 1.3.0 was released, we updated our default kernel to
5.12, because 5.11 became unsupported, as planned.

However, this caused a regression for at least one user [2].

I'm not sure exactly how the situation could be improved. Maybe the
installer and the operating-system declarations that it generates could
instead use one of the "longterm" [1] kernel series?

I'm not totally comfortable steering users to these longterm kernels
series, since they are more buggy and less featureful than newer kernel
series, but at least they do not change very much.

What do you think?

[0] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm?h=v1.3.0#n892
[1] https://www.kernel.org/category/releases.html
[2] https://bugs.gnu.org/48604

Re: Rust freedom issue claim

[Pjotr Prins]

Scopes sure looks cool!

Pj.

Re: Rust freedom issue claim

[Joshua Branson]

Pjotr Prins  writes:

> On Wed, May 26, 2021 at 04:32:03PM +0200, Ludovic Courtès wrote:
>> That’s a somewhat different topic.  FWIW, I’m both excited at the idea
>> of having a memory-safe replacement for C gaining momentum, and
>> frightened by the prospects of Rust being this replacement, for many
>> reasons including: Rust does not have a good bootstrapping story, as we
>> know all too well, Cargo encourages sloppy package distribution à la
>> npm, Rust in the kernel would give a false sense of safety (it’s still
>> that big monolithic blob!), and the Rust community is very much
>> anti-copyleft.
>
> Having adopted Rust for some of our bioinformatics work, I can fully
> agree. It is actually hard to use Rust without Cargo and it is an
> implosion npm-style waiting to happen if the most trivial program
> already imports 100+ external packages - some of doubtful quality.
>
> Another thing I have against Rust is its syntax - but that is
> (arguably) taste. I can't believe references are written with an
> ampersand - and they are so common it is in your face all the time.
> That is just noise. And sometimes the borrow checker really gets in
> the way (and I pine for GC). We are sticking with Rust though because
> the compiler works hard and is a sucker for detail, so it helps both
> less and more experienced programmers to avoid C/C++ traps. Also Rust
> has no OOP that people can use - I am very happy about that. In short
> it is a fairly pragmatic FP language with some nice compile time
> features. I don't love it but it is an OK compromise.

In terms of languages trying to be replacements for C:

- Zig is one of the most famous ones, and will probably be the first C
  alternatives to reach 1.0.  https://ziglang.org/

- Odin https://odin-lang.org/

- scopes which using S-expressions  https://sr.ht/~duangle/scopes/

- Drew Devault's (creator or sway) secret programming language.  It may
  be the second language on this list to reach 1.0

>
> For kernels I completely agree with you. Memory safety is a red
> herring because we face much deeper problems. Open hardware and
> message passing is the way forward.
>
> Oh, did you know Rust expands all sources into one 'blob' for
> compilation? At the crate level. It led to the meme: "The Rust
> programming language compiles fast software slowly."
>
> I have not hit real issues yet with compilation speed, but it feels
> like we regressed to huge C++ template expansion...
>
>> Guix, related projects such as Mes, Gash, and the Shepherd, together
>> with the Hurd, offer a very different and (to me) more appealing vision
>> for a user-empowering, safer, more robust, and yet POSIX-compliant OS.
>
> Good architecture is far more important than a borrow checker.
>
> Pj.
>

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

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> # IRC alternatives / compliments
>
> Some criteria that I have come up with are:
> * Free software
> * Can be used without a graphical user interface as many GPUs are not
>   compatible with Linux-libre and can not run Xorg or Wayland window
>   managers / desktops.
> * Peer to peer as a way to avoid the issue of a centralized
>   administrator changing their administration in undesirable ways. 

Here is one more criteria.  This would be important if being inclusive
of a diverse group of people is desirable.

* Works with slow and low bandwidth internet connections.

Some examples are dial up modems, mesh networks and satellite.

RE: guix and mirroring dataset

[zimoun]

Hi,

On Thu, 27 May 2021 at 04:37, "Cook, Malcolm"  wrote:

>>Your input is welcome. :-)
>
> I was expecting to find workflows that have been developed for
> mirroring (downloading) genomic resources from sites such as
> Ensembl/NCBI/UCSC, etc, and then creating on-prem derived resources
> (e.g. blast indexes).

Sorry, I missed that what you were asking. :-)

The answer is: nothing ready-to-use.  Well, feel free to start a
discussion on gwl-de...@gnu.org.

> I currently tend to do this with Gnu Make and shell scripting.

If you already have some shell scripts, I think the effort is not too
high to wrap around some GWL glue. ;-)

And maybe it could be worth to see if a common organisation makes sense
here for the various cases.


Cheers,
simon

Re: website: A little help running the website locally

[gauthier]

Just a heads up that due to this thread, I've been able to run the website 
locally too, that was one of my first realworld usage of guix, I'm slow on this 
journey, but I've started it :)

Regarding the website itself, I wanted to adjust the package page, so that it 
has a direct link to the package description from the github repository and 
I've not managed my guile foo (which is 0.0001) enough to figure how to 
adjust the code already present in case of lint error.

Maybe a current maintainer can wipe such change faster than waiting for me to 
advance my journey, I think it would benefit the website users to have direct 
link to the .scm from the package description page, or even having it pretty 
printed right on the page ideally.

May 22, 2021 8:04 PM, "Luis Felipe"  wrote:

> On Saturday, May 22, 2021 3:46 PM, Julien Lepiller  wrote:
> 
>> Le Fri, 21 May 2021 19:28:38 +,
>> Luis Felipe luis.felipe...@protonmail.com a écrit :
>> 
>> On Friday, May 21, 2021 7:24 PM, Julien Lepiller jul...@lepiller.eu
>> wrote:
>> 
>>> Ah no, I think we found the issue! So we should update the readme
>>> to not require passing GUIX_LOCPATH and set LANG to en_US.UTF-8 (or
>>> any other language listed in po/LINGUAS).
>> 
>> Will you update the README, or should I sent a patch?
>> 
>> I updated the README, so it should now give you correct directions.
>> Thanks for reporting the issue and for your time while we tried
>> debugging this :)
> 
> こちらこそ、どうもありがとう、みんな！

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> Here is what I have discovered after some further preliminary
> exploration.  I have added XMPP and Tox.

This is supplemental information in regards to raingloom's comment on
implementation languages.

> ## Scuttlebutt
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** scat 

scat is implemented in JavaScript.

> ** scatzero 

scatzero is implemented in JavaScript.

> ** scuttle-chat 

scuttle-chat is implemented in Rust.  The Readme says "Work in
Progress!!".

> * IRC capabilities - ?
> * Emacs client - no
>
> ## DAT
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** cabal-cli 

cabal-cli is implemented in JavaScript.

> * IRC capabilities - yes
> ** 
> * Emacs client - no
>
> ## IPFS
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - prototype
> ** orbit-textui 

orbit-textui is implemented in JavaScript.

> *** prototype
> * IRC capabilities - ?
> * Emacs client - no
>
> ## Jami
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** jami-cli 

jami-cli is implemented in Rust.

> * IRC capabilities - not yet
> ** Swarm requires more optimizations before pubic channels are added.
> ** Currently jami-cli has been tested for group of 5 (jami-cli's
>developer devices). 
> ** A group is invite only currently.
> * Emacs client - no
>
> ## RetroShare
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - no

RetroShare is implemented in C++.

> * IRC capabilities - yes
> * Emacs client - no
>
> ## XMPP
>
> 
>
> * Free libre - yes
> * Peer to peer - no
> ** federated servers
> * Non graphical client - yes
> ** Mcabber 

Mcabber is implemented in C.

> ** Poezio 

Poezio is implemented in Python 3.

> ** Profanity 

Profanity is implemented in C.

> ** Aparte 

Aparte is implemented in Rust.

> * IRC capabilities - yes
> * Emacs client - yes
> ** jabber.el 

jabber.el is implemented in Emacs Lisp.

>
> ## Tox
>
> 
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** Toxic 

Toxic is implemented in C.

> * IRC capabilities - not currently
> ** Would get IRC capabilities if this gets added
> 
> * Emacs client - no

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> ## Matrix

This is supplemental information in regards to raingloom's comment on
implementation languages.

>
> 
>
> * Free libre - yes
> * Peer to peer - no yet, currently federated servers
> ** 
> 
> ** 
> * Non graphical client - yes
> ** 

matrix-commander is implemented in Python 3.

> ** 

matrixcli is implemented in Python 3.

> ** 

gomuks is implemented in Go.  The Readme says "Basic usage is possible,
but expect bugs and missing features".

> ** 

weechat-matrix is support Python 2 and 3.  The Readme says
"weechat-matrix is in maintenance mode". 

 is implemented in Rust.
The Readme says "This project is a work in progress".


> * IRC capabilities - yes
> * Emacs client - yes
> ** 

matrix-client.el is implemented in Emacs Lisp.

Re: Rust freedom issue claim

[Bone Baboon]

Bone Baboon writes:

> This is an article from Hyperbola about the Rust trademark. It claims
> that Rust has a freedom issue.
> 
>
> I searched for this in the Guix bug and devel mailing list archive but
> did not see it.
>
> I would like to know how others interpret this claim of Rust having a
> freedom issue.
>
> # Linux-libre
>
> If Rust does have a freedom issue then there is potential that it could
> have an impact on Linux-libre.  Recently there was a RFC for adding
> support for Rust to the Linux kernel
> .  Linus Torvalds's response is
> here .
>
> # Responses on Freenode
>
> I asked about Hyperbola's claim of a Rust freedom issue on
> ##r...@ire.freenode.net and these were some of the responses I
> received.  However it appears that the core of Hyperbola's claim
> remains unaddressed by these responses.
>
> " the trademarks are now owned by the Rust Foundation
> rather than Mozilla, but the Rust Media Guide has not been updated to
> reflect this"
>
> " bone-baboon: https://github.com/rust-lang/rust/issues/53287
> is closed by https://github.com/rust-lang/rust/pull/59748;
>
> " bone-baboon: whether you consider is a freedom issue or not
> is a matter of viewpoint - debian doesn't seem to care at this point,
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=cargo
> shows no bugs open related to trademarks"

I asked about this on #hyperbola@Freenode.  I was told that it is still
an issue and this link was shared:
.

Re: Freenode Administration

[Bone Baboon]

raingloom writes:
> I don't think we can package NPM stuff.
>
> Both the Dat and SSB cores have non-JavaScript implementations AFAIK,
> but Cabal itself is JavaScript-only and so are all the SSB clients that
> I've seen, but admittedly I haven't looked at the state of the SSB
> ecosystem in a few months, so maybe that has changed.
> The various sbot implementations do not count as proper clients.

I have added information on the implementation languages for clients to
this tread.

Here is information on servers for XMPP and Matrix.

# XMPP Servers

* https://github.com/ortuman/jackal
** Implemented in Go

* https://github.com/maranda/metronome
** Implemented in Lua

* https://github.com/bjc/prosody
** Implemented in Lua

* https://github.com/igniterealtime/Openfire
** Implemented in Java

# Matrix Servers

* https://github.com/matrix-org/synapse
** Implemented in Python 3

* https://github.com/matrix-org/dendrite
** Implemented in Go

** https://gitlab.com/famedly/conduit
** Implemented in Rust

* https://github.com/matrix-construct/construct
** Implemented in C++

* https://gitlab.com/plasmahs/plasma
** Implemented in Elixir

* https://gitlab.com/mascarene/mascarene
** Implemented in Scala

* https://gitlab.com/ma1uta/jeon
** Implemented in Java