Fwd: Happy GNU Year!!!

[Adrienne G. Thompson]

Happy GNU Year!!!

Thank you for including GNU C-Graph in your distro.

https://drive.google.com/file/d/1MAjtX2LOMrq3ILSF8PzlJOaZkkEpjhPc/view


2023 is the year of the rabbit!
http://clipart-library.com/image_gallery/28254.jpg

I’ve saved your GNU Year greeting for the Lantern Festival of the Lunar NEW
Year!  The Lantern symbolises light - to lead the way forward. The Rabbit
symbolises new beginnings, rebirth/resurrection, intellect, creativity,
prosperity, abundance, fertility, growth, good luck – and the *moon*!

Like the rabbit in Alice in Wonderland - who mastered the art of delay –
we’re sending greetings Jamaica Time! [1] After a couple of years of
weathering storms in Boston and in Jamaica, 2023 will see the resurrection
of GNU C-Graph’s research and development program towards new releases
under Project 2.X for our 30 million worldwide userbase.

2023 is predicted to be a year of hope. GNU C-Graph will make it a
celebration as we develop the next releases! Celebrate our *moonshot *idea
with us!!!
https://drive.google.com/file/d/1SeGn7CnMxupfyle2EmdNDM_tcsnigC49/view


Cheers
Adrienne G. Thompson
Principal and Chief Code Artist, GNU C-Graph
--
Freedom - no pane, all gaiGN!


NOTES:

   1. https://www.jamaicaobserver.com/news/jamaica-time/


References:

   1. GNU C-Graph: http://www.gnu.org/software/c-graph
   2. Code Art Now: http://codeartnow.com
   3. Abertheid Campaign:
   http://www.abertheid.info/icc/pre-indictment-brief-05.10.2006.pdf
   4. Follow me on Twitter: @AdrienneGT 
   @GNUcgraph 
   5. Let's Link Up: https://www.linkedin.com/in/adriennegt/
   6. Knees On My Neck:
   https://twitter.com/AdrienneGT/status/1288648018783277068
   7. Rise Up for Richard Stallman: https://www.stallmansupport.org

What's the state of (guix build download-nar)?

[Christopher Baines]

Hey!

As part of the work on bordeaux.guix.gnu.org, I've stumbled upon (guix
build download-nar). I'm not sure I understand it very well, but it
relates to downloading nars from berlin.guix.gnu.org.

I guess this raises two things in my mind. I'm not sure this'll work
well given the not so recent changes to ci.guix.gnu.org. This module
looks to rely on gzipped or uncompressed nars. I'm not sure uncompressed
nars are available, and gzipped ones are no longer available.

The second question is around the relation to bordeaux.guix.gnu.org, is
it worth trying to support fetching nars from bordeaux.guix.gnu.org
here, and what would be the best way of doing that? It wouldn't be too
hard to add support for decomressed nars I think if that's a good
approach?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Request for review of: [bug#60899] [PATCH 00/25] gnu: golang: Add gopls

[Katherine Cox-Buday]

Katherine Cox-Buday  writes:

> Katherine Cox-Buday  writes:
>
>> This is a patch series to add the gopls package.
>>
>> I haven't contributed to many projects which use the e-mail flow, so
>> hopefully I'm doing this correctly. Please feel free to make
>> suggestions if not!
>>
>> Some of the diffs are a little busier than I'd like for version bumps.
>> This is due to running `guix style` over everything.
>>
>> For all of the packages I have:
>>
>> . Run guix style
>> . Run guix lint
>> . Built 2x
>> . Checked that the change is in the correct branch
>> . Built all dependencies
>> . Built the repository
>>
>> Katherine Cox-Buday (25):
>>   gnu: go-golang-org-x-sync: Update to 0.1.0-1.8fcdb60.
>>   gnu: go-golang-org-x-mod: Update to 0.7.0.
>>   gnu: Add go-golang-org-x-exp.
>>   gnu: Add go-github-com-jba-printsrc.
>>   gnu: Add go-github-com-google-safehtml.
>>   gnu: Add go-github-com-jba-templatecheck.
>>   gnu: go-github-com-google-go-cmp-cmp: Update to 0.5.9.
>>   gnu: go-github-com-pkg-diff: Update to
>> 0.0.0-20210226163009-20ebb0f2a09e.
>>   gnu: go-github-com-rogpeppe-go-internal: Update to 1.9.0.
>>   gnu: gopkg-in-errgo-fmt-errors: Rename package to
>> go-gopkg-in-errgo-fmt-errors.
>>   gnu: go-golang-org-x-tools: Update to 0.5.0.
>>   gnu: Add xurls.
>>   gnu: Add go-mvdan-cc-xurls.
>>   gnu: Add misspell.
>>   gnu: Add go-github-com-client9-misspell.
>>   gnu: Add go-github-com-google-go-cmdtest.
>>   gnu: Add unparam.
>>   gnu: Add go-mvdan-cc-unparam.
>>   gnu: Add govulncheck.
>>   gnu: Add go-golang-org-x-vuln.
>>   gnu: go-github-com-burntsushi-toml: Update to 1.2.1.
>>   gnu: go-honnef-co-go-tools: Update to 0.3.3.
>>   gnu: Add gofumpt.
>>   gnu: Add go-mvdan-cc-gofumpt.
>>   gnu: Add gopls.
>>
>>  gnu/packages/configuration-management.scm |   2 +-
>>  gnu/packages/golang.scm   | 695 ++
>>  2 files changed, 578 insertions(+), 119 deletions(-)
>>
>>
>> base-commit: 5c921977179489caef4a9e54ada6696fc86d2f0b
>
> Hello Guix! Acknowledging that everyone are volunteers, and busy (guilty
> myself), this is a humble request for a review of this patch-series I
> made two weeks ago so that it doesn't bit-rot.
>
> I have a `gopls` home service[1] waiting to be proposed after this
> patch-series is merged.
>
> Thank you very much!
>
> [1]
> https://github.com/kat-co/guix-channels/blob/upstream-staging/upstream/home/services/gopls.scm
>
> P.S. I think I am following etiquette for review reminders (i.e. waiting
> long enough, bringing this over to guix-devel), but I was having trouble
> finding examples. If I haven't waited long enough, or have reminded in
> the wrong way, please give me feedback.

Hello, this is another humble request for review :)

It looks like QA is passing, and I think I did a pretty thorough job of
making sure things follow standards and will apply cleanly.

-- 
Katherine

Re: Resurrecting top-notch continuous integration for Guile

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> There’s still much tweaking we can do, but the basics are in place, and
> I find it pretty cool.  :-)  If there are no objections, I’ll merge this
> branch into “main”.  It’s going to be nice to have a dashboard to look
> at before the next release!

Merged in Guile’s ‘main’ branch as commit
32f33756d0fbbf28e848f087375f75c265d0a46c!

If Guix is your thing, you can now get started hacking on Guile with:

  guix shell

The continuous integration jobs are visible at:

  https://ci.guix.gnu.org/jobset/guile

Happy hacking!

Ludo’.

Re: Getting tree-sitter grammars in Guix

[Simon Tournier]

Hi,

On sam., 04 févr. 2023 at 20:27, Demis Balbach  wrote:

> My understanding is that I need to provide emacs with tree-sitter
> support as an input for this to work, which I did, but it'll fail with
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such 
> file or directory" "treesit")
> --8<---cut here---end--->8---
>
> Maybe someone can help me here. I tried looking at other package
> definitions, but I don't know if there are any emacs packages that
> require tree-sitter packaged in Guix yet.

Could you share your definition of Emacs variant allowing tree-sitter?

Please note it is not clear for me if the tree-sitter parsers should be
provided by Guix since 1. they are auto-generated and so it is against
the effort to debootstrap and 2. they are often very large.

Cheers,
simon

Re: emacs packaging: do we need to pull existing dependencies ?

[Simon Tournier]

Hi,

On mer., 01 févr. 2023 at 08:44, Cayetano Santos 
 wrote:

> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4,
> which is not specified in the package definition, meaning we always
> pull the latest available. Do we have to, provided that emacs
> releases with org ? Maybe there is already a clear rule about this
> topic, but to me this is not clear. We have package definitions with
> both criteria.

Well, I think it is a collateral effect from the importer.

--8<---cut here---start->8---
$ guix import elpa -a melpa org-roam
[...]

  (propagated-inputs (list emacs-dash emacs-org emacs-emacsql
   emacs-emacsql-sqlite emacs-magit-section))
--8<---cut here---end--->8---

when MELPA indeed reads:

--8<---cut here---start->8---
Dependencies
dash 2.13 / emacs 26.1 / emacsql 3.0.0 / emacsql-sqlite 1.0.0 / 
magit-section 3.0.0 / org 9.4
--8<---cut here---end--->8---

Indeed, emacs-org-roam@2.2.2 should work with emacs@28.2 (provided by
default with the current Guix) and thus the propagated-inputs emacs-org
is totally not required.

Well, a curation would some work; first to find all the removable items,
then second to maintain after each package “refresh”.  Such curation
would fit in all the discussions around the closure diet of Guix
packages.

However, it appears to me that people currently maintaining all the
Emacs packages in Guix should decide; since it would be extra work for
them. :-)

Cheers,
simon

Re: git-fetch without a hash

[Simon Tournier]

Hi,

On dim., 05 févr. 2023 at 18:44, b...@bokr.com wrote:

>> From my understanding, we could have something like,
>> 
>>   (sha256 (no-hash))
>> 
>> where ’no-hash’ would return a string, say
>> "" or whatever else
>> that would satisfy this hypothetical  ’sha256’ sanitizer.

> For portability to any hash algorithm that returns a hex string,
> how about letting them hash a zero-length string (which can never
> represent a package tarball or other archive), and using the
> resulting strings as no-hash flags?

Instead of “”, you
are proposing “0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73”
which is the Guix hash of empty.

> $ sha256sum /dev/null
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/null

$ touch foo
$ guix hash foo
0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
$ guix hash foo -f hex -H sha256
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Yeah, probably better. :-)

> These strings must be unique for whatever hash algorithm,
> so a short table could be used to recognize them as
> no-hash indicators.

Well, I do not understand “These strings must be unique for whatever
hash algorithm”.  What do you mean?

Cheers,
simon

Re: Resurrecting top-notch continuous integration for Guile

[Maxim Cournoyer]

Hi!

Ludovic Courtès  writes:

> Hi!
>
> Ludovic Courtès  skribis:
>
>> There’s still much tweaking we can do, but the basics are in place, and
>> I find it pretty cool.  :-)  If there are no objections, I’ll merge this
>> branch into “main”.  It’s going to be nice to have a dashboard to look
>> at before the next release!
>
> Merged in Guile’s ‘main’ branch as commit
> 32f33756d0fbbf28e848f087375f75c265d0a46c!
>
> If Guix is your thing, you can now get started hacking on Guile with:
>
>   guix shell
>
> The continuous integration jobs are visible at:
>
>   https://ci.guix.gnu.org/jobset/guile
>
> Happy hacking!
>
> Ludo’.
>

Fun!  Nice symbiosis :-).

-- 
Thanks,
Maxim

Re: Getting tree-sitter grammars in Guix

[Pierre Langlois]

Hi all!

Simon Tournier  writes:

> Hi,
>
> On sam., 04 févr. 2023 at 20:27, Demis Balbach  wrote:
>
>> My understanding is that I need to provide emacs with tree-sitter
>> support as an input for this to work, which I did, but it'll fail with
>>
>> --8<---cut here---start->8---
>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such 
>> file or directory" "treesit")
>> --8<---cut here---end--->8---
>>
>> Maybe someone can help me here. I tried looking at other package
>> definitions, but I don't know if there are any emacs packages that
>> require tree-sitter packaged in Guix yet.
>
> Could you share your definition of Emacs variant allowing tree-sitter?
>
> Please note it is not clear for me if the tree-sitter parsers should be
> provided by Guix since 1. they are auto-generated and so it is against
> the effort to debootstrap and 2. they are often very large.

Seeing this discussion just now, you'll probably want to take a look at
the series I've been working on which addresses this (at least I hope
so, reviews on the source-only bootstrapping welcome!).

https://issues.guix.gnu.org/49946#215

I still need to work on it and address feedback, however I've not had
any time for Guix the last couple of months.

Hope this helps avoid work duplication! If people need this work in
sonner than later and I'm not able to see it through in time, I'm happy
for someone else to pick it up. Although hopefully I'll have some time
next weekend.

Thanks!
Pierre

>
> Cheers,
> simon