Re: Freenode Administration

[François]

Hello,

On Wed, May 19, 2021 at 01:54:45PM -0400, Bone Baboon wrote:
> Will Guix continue to use Freenode?
> 
> Will Guix create #guix channels on other IRC networks? (Several of the
> resignation letters refer to )

The channel #guix will probably continue to exist on Freenode but most
users are switching to libera.chat.

As we talk the logs on http://logs.guix.gnu.org/guix are now those of
#guix on libera.chat

I have the feeling that the Guix website will be updated soon to reflect
this move.

> Will Guix start it's own IRC server(s)?

It is not an option discussed and I think it would be a misplacement of
Guix scarce resources.

> # IRC alternatives / compliments

On alternatives you missed Matrix[1] which is federated (like email)
and have several clients includig weechat for text-based interface.

Several people (and I am one of them) already uses Matrix clients to
access IRC networks with bridges (which libera.chat does not already
have but work is in progress).

There is even some ongoing work ([2], [3]) on making Matrix more
peer-to-peer but it is still completely experimental.


[1]: https://matrix.org
[2]: https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network
[3]: https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix

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. 

One more criteria.  Is an Emacs client available.  Inspired by
.

> Some alternatives that come to mind that would need further
> investigation include the following.  I do not know if any of these meet
> all the criteria I mention above.
>
> * Scuttlebutt
> ** https://scuttlebutt.nz/
> ** Is there a client that works without a graphical environment?
>
> * DAT
> ** Are there messaging application for DAT?
> ** https://www.datprotocol.com/
>
> * IPFS
> ** Are there messaging application for IPFS?
> ** https://ipfs.io/
>
> * Jami
> ** https://jami.net/
> ** Swarms specifically
> *** 
> https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
> *** Swarms are fully distributed and peer-to-peer text conversations,
> with a potentially unlimited number of participants.
> **  on Freenode #jami said:
>"https://github.com/AmarOk1412/jami-cli/ no video/audio support but
>support swarm"
>
> * RetroShare
> ** http://retroshare.cc/
> ** Is there a client that works without a graphical environment?

Here is what I have discovered after some further preliminary
exploration.  I have added XMPP and Tox.

## Scuttlebutt



* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** scat 
** scatzero 
** scuttle-chat 
* IRC capabilities - ?
* Emacs client - no

## DAT



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

## IPFS



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

## Jami



* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** jami-cli 
* 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
* IRC capabilities - yes
* Emacs client - no

## XMPP



* Free libre - yes
* Peer to peer - no
** federated servers
* Non graphical client - yes
** Mcabber 
** Poezio 
** Profanity 
** Aparte 
* IRC capabilities - yes
* Emacs client - yes
** jabber.el 

## Tox



* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** Toxic 
* IRC capabilities - not currently
** Would get IRC capabilities if this gets added
    
* Emacs client - no

Re: Freenode Administration

[Tobias Geerinckx-Rice]

Hi Bone,

Bone Baboon 写道：

Will Guix continue to use Freenode?


No.  #guix is now on Libera Chat[0], the new name of what was 
‘Freenode’ before yesterday's hostile takeover of the freenode.net 
infra.


I updated the docs and the Web site yesterday.  It probably took a 
while to refresh.


Many thanks to Taylan for grabbing Libera's #guix before squatters 
could and for giving us administrative access.  I've applied for 
more official ‘project’ status like we had at old Freenode.


The old #guix channel still exists.  Users will see the new 
network name advertised in the /topic and ENTRYMSG if supported by 
their client, but I don't plan on ‘closing’ it unless it becomes a 
problem somehow.


Will Guix create #guix channels on other IRC networks? (Several 
of the

resignation letters refer to )


Over the years multiple authors of those letters have been 
extremely helpful, responsive, and downright friendly to me 
whenever I bothered them with my noob questions.  It never felt 
like I was talking to overworked volunteers.  I didn't hesitate 
for a moment to trust their judgment.



Will Guix start it's own IRC server(s)?


François is right: starting and running an IRC server is a serious 
commitment, not something you do on Sundays.  Leave it to 
competent people who are passionate about doing their thing well.


Don't get me wrong: I <3 self-hosting.  Perhaps we can host one of 
the mentioned IRC alternatives, but I urge anyone volunteering: 
bridge it with IRC so's not to split the community further.


Kind regards,

T G-R

[0]: https://libera.chat/


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hello Guix!

Here’s a proposal for a soft revolution: getting rid of input labels
in package definitions.  Instead of writing:

(native-inputs
 `(("autoconf" ,autoconf)
   ("automake" ,automake)
   ("pkg-config" ,pkg-config)
   ("guile" ,guile-3.0)))

one can write:

(native-inputs (list autoconf automake pkg-config guile-3.0))

With this patch set, this is just syntactic sugar: ‘package-inputs’
and friends still return a list of tuples.  (These patches are
against ‘core-updates’ but that works equally well on ‘master’,
without a world rebuild.)

My understanding of the code is that this change adds no overhead
for packages written in the old style, and negligible overhead for
packages written in the new style (calling ‘package-name’
instead of referring to a literal string for the label.)  I haven’t
tried to measure it though as it would require a massive conversion
to the new style to be really measurable.

I don’t think I need to expound on the benefits.  :-)

There are issues and open questions:

  • This hides labels, but they’re still visible as soon as one
fiddles with ‘package-inputs’ & co.  So this lowers the barrier
to entry, but the difficulty of dealing with input tuples
does not disappear entirely.

  • Both styles would be supported for a long time so contributors
would still have to know about input tuples anyway.

  • There are packages that use custom labels as some sort of an
abstraction.  For instance, the “kernel-headers” label is
associated either with ‘linux-libre-headers’ or with
‘hurd-headers’.  In this case, the simplified style would
use the package name as the label, which isn’t appropriate,
or at least would require adjustments in packages that
rely on this.

  • There are packages with same-named but different inputs,
and they rely on having a different input label.

  • Some packages rely on labels that differ from the package
name (this is what the ‘guix lint -c input-labels’ patch
detects).  For instance, commencement.scm has things like:

  `(("guile" ,%bootstrap-guile))

Automatic labeling would convert it to:

  `(("guile-bootstrap" ,%bootstrap-guile))

Not necessarily a problem: we can keep the old style for these.
Common Lisp packages typically lack the “cl-” prefix in
input labels but most likely they don’t actually refer to
those labels, so we should be fine.

  • Packages such as ‘tzdata’ use labels to refer to non-package
inputs.  These cannot be converted to the automatic labeling
style, or not without extra changes.

  • Currently, something like:

  (inputs (list glib))

is converted to:

  (inputs `(("glib" ,glib)))

Should it, instead, be converted to:

 (inputs `(("glib" ,glib)
   ("glib:bin" ,glib "bin")))

?  This would make the concise style strictly less
expressive, but maybe good enough?

Ludovic Courtès (4):
  records: Support field sanitizers.
  DRAFT packages: Allow inputs to be plain package lists.
  DRAFT gnu: Change inputs of core packages to plain lists.
  DRAFT lint: Add 'input-labels' checker.

 gnu/packages/base.scm  | 30 +++
 gnu/packages/guile.scm | 87 ++
 gnu/packages/mes.scm   | 23 ---
 guix/lint.scm  | 35 +
 guix/packages.scm  | 35 +++--
 guix/records.scm   | 65 ---
 tests/records.scm  | 38 ++
 7 files changed, 198 insertions(+), 115 deletions(-)

-- 
2.31.1

[PATCH RFC 3/4] DRAFT gnu: Change inputs of core packages to plain lists.

[Ludovic Courtès]

This is transparent: the resulting derivations are unchanged.

* gnu/packages/base.scm (grep, sed, tar, patch, diffutils)
(coreutils, gnu-make, make-glibc-utf8-locales): Change input fields to
plain package lists.
* gnu/packages/guile.scm (guile-1.8, guile-json-1, guile-json-3)
(guile-gdbm-ffi, guile-sqlite3, guile-bytestructures)
(guile-git, guile-zlib, guile-lzlib, guile-zstd): Likewise.
* gnu/packages/mes.scm (nyacc-0.86, nyacc-0.99)
(nyacc, nyacc-1.00.2, mes-0.19, mes): Likewise.
---
 gnu/packages/base.scm  | 30 +++
 gnu/packages/guile.scm | 87 ++
 gnu/packages/mes.scm   | 23 ---
 3 files changed, 42 insertions(+), 98 deletions(-)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 33c4952415..6656742c06 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -109,8 +109,8 @@ command-line arguments, multiple languages, and so on.")
   "0gipv6bzkm1aihj0ncqpyh164xrzgcxcv9r1kwzyk2g1mzl1azk6"))
 (patches (search-patches "grep-timing-sensitive-test.patch"
(build-system gnu-build-system)
-   (native-inputs `(("perl" ,perl))) ;some of the tests require it
-   (inputs `(("pcre" ,pcre)))
+   (native-inputs (list perl))   ;some of the tests require it
+   (inputs (list pcre))
(arguments
 `(#:phases
   (modify-phases %standard-phases
@@ -161,8 +161,7 @@ including, for example, recursive directory searching.")
 (modules '((guix build utils)
(build-system gnu-build-system)
(synopsis "Stream editor")
-   (native-inputs
-`(("perl" ,perl)));for tests
+   (native-inputs (list perl));for tests
(description
 "Sed is a non-interactive, text stream editor.  It receives a text
 input from a file or from standard input and it then applies a series of text
@@ -215,7 +214,7 @@ implementation offers several extensions over the standard 
utility.")
;; When cross-compiling, the 'set-shell-file-name' phase needs to be able
;; to refer to the target Bash.
(inputs (if (%current-target-system)
-   `(("bash" ,bash))
+   (list bash)
'()))
 
(synopsis "Managing tar archives")
@@ -248,7 +247,7 @@ standard utility.")
 (if (%current-target-system)
 `(#:configure-flags '("gl_cv_func_working_mktime=yes"))
 '()))
-   (native-inputs `(("ed" ,ed)))
+   (native-inputs (list ed))
(synopsis "Apply differences to originals, with optional backups")
(description
 "Patch is a program that applies changes to files based on differences
@@ -271,7 +270,7 @@ differences.")
  (base32
   "09isrg0isjinv8c535nxsi1s86wfdfzml80dbw41dj9x3hiad9xk"
(build-system gnu-build-system)
-   (native-inputs `(("perl" ,perl)))
+   (native-inputs (list perl))
(synopsis "Comparing and merging files")
(description
 "GNU Diffutils is a package containing tools for finding the
@@ -330,16 +329,16 @@ used to apply commands with arbitrarily long arguments.")
   "1yjcrh5hw70c0yn8zw55pd6j51dj90anpq8mmg649ps9g3gdhn24"))
 (patches (search-patches "coreutils-ls.patch"
(build-system gnu-build-system)
-   (inputs `(("acl"  ,acl); TODO: add SELinux
- ("attr" ,attr)   ;for xattrs in ls, mv, etc
- ("gmp"  ,gmp);bignums in 'expr', yay!
+   (inputs `(,acl ;TODO: add SELinux
+ ,attr;for xattrs in ls, mv, etc
+ ,gmp ;bignums in 'expr', yay!
 
  ;; Do not use libcap when cross-compiling since it's not quite
  ;; cross-compilable; and use it only for supported systems.
  ,@(if (and (not (%current-target-system))
 (member (%current-system)
 (package-supported-systems libcap)))
-   `(("libcap" ,libcap)) ;capability support in 'ls', etc.
+   `(,libcap);capability support in 'ls', etc.
'(
(native-inputs
 ;; Perl is needed to run tests in native builds, and to run the bundled
@@ -348,7 +347,7 @@ used to apply commands with arbitrarily long arguments.")
 ;; for help2man.
 (if (%current-target-system)
 '()
-`(("perl" ,perl
+(list perl)))
(outputs '("out" "debug"))
(arguments
 `(#:parallel-build? #f; help2man may be called too early
@@ -443,8 +442,8 @@ standard.")
   "06cfqzpqsvdnsxbysl5p2fgdgxgl9y4p7scpnrfa8z2zgkjdspz0"))
 (patches (search-patches "make-impure-dirs.patch"
(build-system gnu-build-system)
-   (native-inputs `(("pkg-config" ,pkg-config)))  ; to detect Guile
-   (inputs `(("guile" ,guile-3.0)))
+   (native-inputs (list pkg-config

[PATCH RFC 2/4] DRAFT packages: Allow inputs to be plain package lists.

[Ludovic Courtès]

DRAFT: Is it a good idea?  If it is, add tests and doc.

* guix/packages.scm (add-input-label, sanitize-inputs): New procedures.
()[inputs, propagated-inputs, native-inputs]: Add 'sanitize' property.
---
 guix/packages.scm | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index ba19174646..fc3290b8e8 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -366,6 +366,32 @@ name of its URI."
   ;; .
   (fold delete %supported-systems '("mips64el-linux")))
 
+(define (add-input-label input)
+  "Add an input label to INPUT."
+  (match input
+((? package? package)
+ (list (package-name package) package))
+(((? package? package) output);XXX: ugly?
+ (list (package-name package) package output))
+((? gexp-input?)   ;XXX: misplaced because 'native?' field is ignored?
+ (let ((obj(gexp-input-thing input))
+   (output (gexp-input-output input)))
+   `(,(if (package? obj)
+  (package-name obj)
+  "_")
+ ,obj
+ ,@(if (string=? output "out") '() (list output)
+(x
+ `("_" ,x
+
+(define-inlinable (sanitize-inputs inputs)
+  "Sanitize INPUTS by turning it into a list of name/package tuples if it's
+not already the case."
+  (cond ((null? inputs) inputs)
+((and (pair? (car inputs))
+  (string? (caar inputs)))
+ inputs)
+(else (map add-input-label inputs
 
 ;; A package.
 (define-record-type* 
@@ -380,11 +406,14 @@ name of its URI."
  (default '()) (thunked))
 
   (inputs package-inputs  ; input packages or derivations
-  (default '()) (thunked))
+  (default '()) (thunked)
+  (sanitize sanitize-inputs))
   (propagated-inputs package-propagated-inputs; same, but propagated
- (default '()) (thunked))
+ (default '()) (thunked)
+ (sanitize sanitize-inputs))
   (native-inputs package-native-inputs; native input packages/derivations
- (default '()) (thunked))
+ (default '()) (thunked)
+ (sanitize sanitize-inputs))
 
   (outputs package-outputs; list of strings
(default '("out")))
-- 
2.31.1

[PATCH RFC 1/4] records: Support field sanitizers.

[Ludovic Courtès]

* guix/records.scm (make-syntactic-constructor): Add #:sanitizers.
[field-sanitizer]: New procedure.
[wrap-field-value]: Honor F's sanitizer.
(define-record-type*)[field-sanitizer]: New procedure.
Pass #:sanitizer to 'make-syntactic-constructor'.
* tests/records.scm ("define-record-type* & sanitize")
("define-record-type* & sanitize & thunked"): New tests.
---
 guix/records.scm  | 65 +--
 tests/records.scm | 38 +++
 2 files changed, 89 insertions(+), 14 deletions(-)

diff --git a/guix/records.scm b/guix/records.scm
index 3d54a51956..ed94c83dac 100644
--- a/guix/records.scm
+++ b/guix/records.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Ludovic 
Courtès 
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 
Ludovic Courtès 
 ;;; Copyright © 2018 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -120,7 +120,8 @@ context of the definition of a thunked field."
 "Make the syntactic constructor NAME for TYPE, that calls CTOR, and
 expects all of EXPECTED fields to be initialized.  DEFAULTS is the list of
 FIELD/DEFAULT-VALUE tuples, THUNKED is the list of identifiers of thunked
-fields, and DELAYED is the list of identifiers of delayed fields.
+fields, DELAYED is the list of identifiers of delayed fields, and SANITIZERS
+is the list of FIELD/SANITIZER tuples.
 
 ABI-COOKIE is the cookie (an integer) against which to check the run-time ABI
 of TYPE matches the expansion-time ABI."
@@ -130,6 +131,7 @@ of TYPE matches the expansion-time ABI."
 #:this-identifier this-identifier
 #:delayed delayed
 #:innate innate
+#:sanitizers sanitizers
 #:defaults defaults)
  (define-syntax name
(lambda (s)
@@ -169,19 +171,30 @@ of TYPE matches the expansion-time ABI."
  (define (innate-field? f)
(memq (syntax->datum f) 'innate))
 
+ (define field-sanitizer
+   (let ((lst (map (match-lambda
+ ((f p)
+  (list (syntax->datum f) p)))
+   #'sanitizers)))
+ (lambda (f)
+   (or (and=> (assoc-ref lst (syntax->datum f)) car)
+   #'(lambda (x) x)
+
  (define (wrap-field-value f value)
-   (cond ((thunked-field? f)
-  #`(lambda (x)
-  (syntax-parameterize ((#,this-identifier
- (lambda (s)
-   (syntax-case s ()
- (id
-  (identifier? #'id)
-  #'x)
-#,value)))
- ((delayed-field? f)
-  #`(delay #,value))
- (else value)))
+   (let* ((sanitizer (field-sanitizer f))
+  (value #`(#,sanitizer #,value)))
+ (cond ((thunked-field? f)
+#`(lambda (x)
+(syntax-parameterize ((#,this-identifier
+   (lambda (s)
+ (syntax-case s ()
+   (id
+(identifier? #'id)
+#'x)
+  #,value)))
+   ((delayed-field? f)
+#`(delay #,value))
+   (else value
 
  (define default-values
;; List of symbol/value tuples.
@@ -291,6 +304,19 @@ can access the record it belongs to via the 'this-thing' 
identifier.
 A field can also be marked as \"delayed\" instead of \"thunked\", in which
 case its value is effectively wrapped in a (delay …) form.
 
+A field can also have an associated \"sanitizer\", which is a procedure that
+takes a user-supplied field value and returns a \"sanitized\" value for the
+field:
+
+  (define-record-type*  thing make-thing
+thing?
+this-thing
+(name  thing-name
+   (sanitize (lambda (value)
+   (cond ((string? value) value)
+ ((symbol? value) (symbol->string value))
+ (else (throw 'bad! value)))
+
 It is possible to copy an object 'x' created with 'thing' like this:
 
   (thing (inherit x) (name \"bar\"))
@@ -307,6 +333,14 @@ inherited."
  (field-default-value #'(field properties ...)))
 (_ #f)))
 
+(define (field-sanitizer s)
+  (syntax-case s (sanitize)
+((field (sanitize proc) _ ...)
+ (list #'field #'proc))
+((field _ properties ...)
+ (field-sanitizer #'(field properties ...)))
+(_ #f)))
+
 (define-field

[PATCH RFC 4/4] DRAFT lint: Add 'input-labels' checker.

[Ludovic Courtès]

DRAFT: Good idea? If yes, add tests and doc.

* guix/lint.scm (check-input-labels): New procedure.
(%local-checkers): Add 'input-labels' checker.
---
 guix/lint.scm | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/guix/lint.scm b/guix/lint.scm
index 1bebfe03d3..95f82dba60 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -383,6 +383,37 @@ of a package, and INPUT-NAMES, a list of package 
specifications such as
  (package-input-intersection (package-direct-inputs package)
  input-names
 
+(define (check-input-labels package)
+  "Emit a warning for labels that differ from the corresponding package name."
+  (define (check input-kind package-inputs)
+(define (warning label name)
+  (make-warning package
+(G_ "label '~a' does not match package name '~a'")
+(list label name)
+#:field input-kind))
+
+(append-map (match-lambda
+  (((? string? label) (? package? dependency))
+   (if (string=? label (package-name dependency))
+   '()
+   (list (warning label (package-name dependency)
+  (((? string? label) (? package? dependency) output)
+   (let ((expected (string-append (package-name dependency)
+  ":" output)))
+ (if (string=? label expected)
+ '()
+ (list (warning label expected)
+  (_
+   '()))
+(package-inputs package)))
+
+  (append-map (match-lambda
+((kind proc)
+ (check kind proc)))
+  `((native-inputs ,package-native-inputs)
+(inputs ,package-inputs)
+(propagated-inputs ,package-propagated-inputs
+
 (define (package-name-regexp package)
   "Return a regexp that matches PACKAGE's name as a word at the beginning of a
 line."
@@ -1493,6 +1524,10 @@ them for PACKAGE."
  (name'inputs-should-not-be-input)
  (description "Identify inputs that shouldn't be inputs at all")
  (check   check-inputs-should-not-be-an-input-at-all))
+   (lint-checker
+ (name'input-labels)
+ (description "Identify input labels that do not match package names")
+ (check   check-input-labels))
(lint-checker
  (name'license)
  ;; TRANSLATORS:  is the name of a data type and must not be
-- 
2.31.1

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

[Vincent Legoll]

Hello,

On Thu, May 20, 2021 at 5:03 PM Ludovic Courtès  wrote:
> Instead of writing:
>
> (native-inputs
>  `(("autoconf" ,autoconf)
>("automake" ,automake)
>("pkg-config" ,pkg-config)
>("guile" ,guile-3.0)))
>
> one can write:
>
> (native-inputs (list autoconf automake pkg-config guile-3.0))

What about

> (native-inputs
>  `(,autoconf
>("truc" ,muche)
>"pkg-config"
> ))

i.e. allowing package objects, tuples and names, and it would DTRT ?

Wouldn't something like that be possible ?

-- 
Vincent Legoll

Re: Scala package

[Shyam Saran]

Many people want to move all their development work on guix

example android sdk app development, yes scala, gradle, kotlin, groovy etc
(even blockstack, ethereum) required to be packaged
As many of you, and Julien trying this.

So more than contributing code, please provide a blog post from which, who
all want to help
can also get guidance.


Thanks

syam





On Wed, 19 May 2021 at 21:06, Katherine Cox-Buday 
wrote:

> Ludovic Courtès  writes:
>
> >> I think the best way to bootstrap would be to reimplement Scala in
> > another language. I tried that too, but even the parser is crazy.
>
> Yes, the syntax is complex. Maybe even worse than C++ in terms of
> parsing. I abandoned scala awhile ago, but I saw that with its latest
> release, maybe some things got simplified. Maybe it's worth another
> look?
>
> > Could you share a link to that so everyone realizes just how far you
> > went?  :-)
>
> Before I outright abandoned the language, I was looking into
> bootstrapping this too. I did not go nearly as far, but was strongly
> dissuaded by core scala contributers from even trying (to be fair, they
> probably don't hold bootstrapping in high regard as we do).
>
> The only thought I have to contribute is: would it be possible to
> bootstrap off of a binary seed, and then do what's possible to grow that
> down to prior versions as much as possible? It's a compromise, but it at
> least gets Guix into the scala ecosystem and provides scaffolding to
> work off of. Of course this might run contrary to Guix's goals/needs.
>
> --
> Katherine
>
>

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

[Maxime Devos]

Ludovic Courtès schreef op do 20-05-2021 om 16:58 [+0200]:
> Hello Guix!
> 
> Here’s a proposal for a soft revolution: getting rid of input labels
> in package definitions.  Instead of writing: [...]
>
> one can write:
> 
> (native-inputs (list autoconf automake pkg-config guile-3.0))
> [...]

This concept LGTM (but I haven't looked closely at the patches), but
as noted on #guix, some issues with eliminating labels completely:

A package definition of P may require both Q@1.0 and Q@2.0 as inputs,
in which case a ‘label collision’ would be created if we generate
labels package-name. More specifically, I'm thinking of packaging
go-ipfs-migrations (or what's its name ...). It would be a good idea
to add an (additional?) test to actually try to migrate from
go-ipfs@first-version to go-ipfs@another-version.

Greetings,
Maxime.


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

Re: Scala package

[Julien Lepiller]

I'll think about that. Note that we already have Groovy, as it's properly 
bootstrapped :)

Le 20 mai 2021 15:09:08 GMT-04:00, Shyam Saran  a 
écrit :
>Many people want to move all their development work on guix
>
>example android sdk app development, yes scala, gradle, kotlin, groovy
>etc
>(even blockstack, ethereum) required to be packaged
>As many of you, and Julien trying this.
>
>So more than contributing code, please provide a blog post from which,
>who
>all want to help
>can also get guidance.
>
>
>Thanks
>
>syam
>
>
>
>
>
>On Wed, 19 May 2021 at 21:06, Katherine Cox-Buday
>
>wrote:
>
>> Ludovic Courtès  writes:
>>
>> >> I think the best way to bootstrap would be to reimplement Scala in
>> > another language. I tried that too, but even the parser is crazy.
>>
>> Yes, the syntax is complex. Maybe even worse than C++ in terms of
>> parsing. I abandoned scala awhile ago, but I saw that with its latest
>> release, maybe some things got simplified. Maybe it's worth another
>> look?
>>
>> > Could you share a link to that so everyone realizes just how far
>you
>> > went?  :-)
>>
>> Before I outright abandoned the language, I was looking into
>> bootstrapping this too. I did not go nearly as far, but was strongly
>> dissuaded by core scala contributers from even trying (to be fair,
>they
>> probably don't hold bootstrapping in high regard as we do).
>>
>> The only thought I have to contribute is: would it be possible to
>> bootstrap off of a binary seed, and then do what's possible to grow
>that
>> down to prior versions as much as possible? It's a compromise, but it
>at
>> least gets Guix into the scala ecosystem and provides scaffolding to
>> work off of. Of course this might run contrary to Guix's goals/needs.
>>
>> --
>> Katherine
>>
>>

Re: RISC-V is giving away developer boards

[Pjotr Prins]

$99 boards with 1GB RAM. Getting there! 

https://liliputing.com/2021/05/nezha-is-a-99-single-board-pc-with-a-risc-v-processor.html

On Tue, May 04, 2021 at 08:53:05PM +, Ekaitz Zarraga wrote:
> >
> > And if someone EU-based is interested to work full time for 6 months
> > we should apply for an NLNet grant. Is it an idea to set up a matrix
> > room for this?
> >
> > Pj.
> 
> Depending on the needs and all that I would like to work on it
> I'm not a Guix expert but I know quite a bit about RISC-V and
> I think I could help on that. I'm EU based too.
> 
> Count me in!