Re: Updates for Go

[david larsson]

On 2023-08-17 16:25, Katherine Cox-Buday wrote:
[..]


Even if you dislike Go, but can work your way through a package,
please consider signing up!


Hi,

Im not a fan of Go, but I've wanted to package some Go packages. Ive 
only managed to write 2 packages for my private channel so far, but they 
were simple. If there is a guide or so somewhere explaining how to do 
this, then maybe I could complete and contribute a package that I am 
working on (with its dependencies). In particular I got stuck packaging 
nwg-menu with its dependencies, such as gotk3, which will probably take 
me a long time to finish at my current skill level. I might be able to 
contribute other packages as well in the future when Ive learned more 
about it.


Thank you for giving Go in Guix some attention.

Best regards,
David

Re: Discussion on Parameterized Packages

[david larsson]

On 2023-05-13 20:26, david larsson wrote:

[..]



If this were a thing, Guix could avoid an LTS version, and just run
GuixLTS via package-parameters - which would be, uhm fun, IMO :-)


I do not mean LTS. I only meant a "stable" version, sorry for any 
confusion caused.


Best regards,
David

Re: Discussion on Parameterized Packages

[david larsson]

On 2023-05-11 17:08, Sarthak Shah wrote:

Hello Guix!
I'll be working on bringing Parameterized Packages to Guix for GSoC
2023 under the guidance of Gábor and Pjotr. I've been a Guix user for
a few years now as it works great for Common Lisp and Scheme projects,
and I've always wanted to contribute to it as it has one of the best
codebases I've seen. Parameterized Packages will serve as an awesome
feature that leverages Guix's dedication to ensuring that all packages
can be compiled from source.
Parameterized Packages will introduce functionality similar to
Gentoo's USE flags, making it possible to change compile-time options
for packages. This will provide users with a lot more freedom over
what features they'd like to include or exclude from packages, and
also aid with reducing the size of binaries.
I have provided a detailed outline of parameterized packages and the
proposed user interface for interacting with them (for both users and
maintainers) in this post on my blog:
https://blog.lispy.tech/2023/05/parameterized-packages.html

I would really appreciate feedback on

(1) parameters you'd like to see in Guix

(2) the user interface for searching/installing/packaging with
parameters


Im not sure this belongs as a parameter per se, but I would like to see 
something like a stable "parameter", that only uses stable features and 
stable versions of packages when applied on an operating system level 
(which was suggested as being a possible level to apply at in the blog 
post), thus:


  "guix build python-SOMEPACKAGE --with-parameter=stable"

would recursively use only the stable version of the package, including 
stable version of the dependencies.


If this were a thing, Guix could avoid an LTS version, and just run 
GuixLTS via package-parameters - which would be, uhm fun, IMO :-)


Maybe something to put into package-properties 
(https://github.com/guix-mirror/guix/blob/270db2a56bc50bcab5739de2c9393644ab65ac6c/guix/packages.scm#L611)


Best regards,
David

Re: Deploying experimental versions of Guix

[david larsson]

On 2023-05-02 15:44, Felix Lechner via "Development of GNU Guix and the 
GNU System distribution." wrote:

Hi,

I'd like to test changes to (gnu system pam). How may I configure my
system, preferably using "deploy," please, while also pulling from my
custom channels?


Hi Felix,

I think creating a custom profile with a channels file containing a 
'guix channel pointing to your modified guix version, and more custom 
channels as you wish (add to the same list), should solve it:


#+begin_src bash
guix pull -C custom-channels.scm --profile=/tmp/myguix-and-channels 
--disable-authentication

#+end_src

See: 
https://guix.gnu.org/manual/en/html_node/Using-a-Custom-Guix-Channel.html


You can then source the profile, and after that either reconfigure your 
system as normal, or I suppose guix deploy will use the current profile 
so that should also work:


#+begin_src bash
GUIX_PROFILE="/tmp/my-guix-and-channels"
. "$GUIX_PROFILE/etc/profile"
which -a guix
# should print /tmp/my-guix-and-channels/bin/guix
#+end_src



I briefly considered shipping a customized (gnu system pam) under a
different name in my own channel, but the module is being consumed in
too many places. Ideally, I would somehow shadow the official (gnu
system pam). Thanks!


I wish "shadowing" specific files was possible too. Would really make 
hacking on guix much easier via custom channels.


Best regards,
David

Re: Struggling to write Dissecting Guix, Part 2

[david larsson]

On 2023-01-26 07:34, ( wrote:

On Wed Jan 25, 2023 at 7:39 PM GMT, david larsson wrote:

https://towardsdatascience.com/monads-from-the-lens-of-imperative-programmer-af1ab8c8790c


I'm not too sure about this one, I'm afraid.

-- (


What are you not too sure about?

There is also pseudo-code (so not python) version of it on Wikipedia 
that's almost identical: 
https://en.wikipedia.org/wiki/Monad_(functional_programming)#Program_logging


I thought the wikipedia version is kind of clearer mainly because it's a 
little more "complete"-feeling. I added some stuff myself to the first 
article making it more like the wikipedia, etc, the and attached it here 
if anyone's interested. That's still in python, but if I ever were to 
write a monad in guile, I'd almost certainly start with trying to 
translate this one.



Best regards,
David
from typing import Tuple
def square(num: int) -> int:
return num * num
def double(num: int) -> int:
return num + num
def square_with_print_return(num: int) -> Tuple[int, str]:
logs = "Currrent num " + str(num) + ". "
return (square(num), logs)
def double_with_print_return(num: int) -> Tuple[int, str]:
logs = "Currrent num " + str(num) + ". "
return (double(num), logs)
def bind(func, tuple: Tuple[int, str]) -> Tuple[int, str]:
res = func(tuple[0])
return (res[0], tuple[1] + res[1])
def unit(number: int) -> Tuple[int, str]:
   return (number, "")

# Now you can do this, more or less nested:
#print(bind(square_with_print_return, unit(5)))
#print(bind(square_with_print_return, (bind(square_with_print_return, bind(square_with_print_return,bind(square_with_print_return,unit(5)))

# it's nicer with infix. This class is a hack.
class Infix:
def __init__(self, function):
self.function = function
def __ror__(self, other):
return Infix(lambda x, self=self, other=other: self.function(other, x))
def __or__(self, other):
return self.function(other)
def __rlshift__(self, other):
return Infix(lambda x, self=self, other=other: self.function(other, x))
def __rshift__(self, other):
return self.function(other)
def __call__(self, value1, value2):
return self.function(value1, value2)

x=Infix(lambda f,x: bind(f,x))
print( square_with_print_return |x| (double_with_print_return |x| unit(4) ) )

# And some extra functional stuff
def curry(f,x):
def curried_function(*args, **kw):
return f(*((x,)+args),**kw)
return curried_function
curry=Infix(curry)

import operator
add5 = operator.add |curry| 5
print(add5(6))

def add5_with_print_return(num: int) -> Tuple[int,str]:
logs = "Current num is " + str(num) + ". "
return (5+num,logs)

print( add5_with_print_return |x| (double_with_print_return |x| unit(4) ) )

Re: Struggling to write Dissecting Guix, Part 2

[david larsson]

On 2023-01-25 08:12, ( wrote:

Hello Guix,

I've been struggling to write Part 2 of Dissecting Guix; I'm just not
sure where to start to
explain monads.

It's hard for a variety of reasons, those being that:

  - Guile has no type system, so you can't express monads in terms of 
types

  - Guix doesn't implement very many monads (only state, identity, and
store), so it's
difficult to explain with a simpler monad, as there are no simpler 
monads

  - Guix doesn't have functors or monoids either, so it's hard to
"progressively" explain
first functors, then monoids, then monads
  - Monads are just difficult in general :P

Any suggestions? :/

-- (


Hi,
Im not an expert on monads by any means, but...

There's a monad tutorial fallacy to avoid: 
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
written by someone Brent: "Associate Professor of Computer Science at 
Hendrix College. Functional programmer, mathematician, teacher, pianist, 
follower of Jesus."


And, personally, I liked this tutorial: 
https://towardsdatascience.com/monads-from-the-lens-of-imperative-programmer-af1ab8c8790c


Maybe it helps, maybe not.

Best regards,
David

Re: Search in One Channel

[david larsson]

On 2022-12-29 00:45, jgart wrote:

[..]



Any thoughts or ideas on how I should approach implementing
search/filter search in one channel only?


I think something like this would be a start where the "pkg-dir" 
argument is the path to a package directory in a channel:


(define (packages-i-want mypkgname pkg-dir)

  (fold-packages (lambda (package result)

   (if (mypkg? package mypkgname)

   (cons package result)

   result))

 '()

 (fold-modules cons '() `(,pkg-dir

Best regards,
David Larsson

Re: Pinning package inputs using inferiors?

[david larsson]

On 2022-10-21 23:08, Phil wrote:
[..]


In the meantime I was wondering if anyone else had a similar use-case
for Guix and if they had tried something similar or different to handle
many versions in an automated way in the same channel commit?


To handle many versions in an automated way, I once wrote this: 
https://gitlab.com/methuselah-0/guix-cigmon/-/tree/master


It's a schedulable script that will check for updates in certain git 
repos (specified branches if you want), and create inherited package 
versions for the new commits which it can commit and push to a guix 
channel repository. Probably doesn't solve your problem completely, but 
might be useful.


Example contents of a new file python-nbdev-org-babel-rev.scm with 
versions of python-nbdev-org-babel, automatically added to a guix 
channel:


(define-module (python-nbdev-org-babel-revs) #:use-module 
(python-extras) #:use-module (guix packages) #:use-module (guix 
git-download))
(define-public python-nbdev-org-babel-4f195e9 (package (inherit 
python-nbdev-org-babel)(properties '(("generated-by" . "cigmon")))(name 
"python-nbdev-org-babel-4f195e9")(source (origin (method git-fetch) (uri 
(git-reference (commit "4f195e915eefe5cd4deec3c6aea27e4b61233f33")(url 
"https://github.com/methuselah-0/nbdev-org-babel.git;)))(sha256 (base32 
"0ayfxnw1s9rzs1qpqqyqwhf21xk6g8psffsqzfvvl0w5k1j88dqn"))
(define-public python-nbdev-org-babel-66079a5 (package (inherit 
python-nbdev-org-babel)(properties '(("generated-by" . "cigmon")))(name 
"python-nbdev-org-babel-66079a5")(source (origin (method git-fetch) (uri 
(git-reference (commit "66079a59aa9ee5e4479bdce597aac0f42f7fb565")(url 
"https://github.com/methuselah-0/nbdev-org-babel.git;)))(sha256 (base32 
"0krdpc6zbdljriw6s80g08fywy0d1nq8wi3q07v3qs0b6rfz68n4"))
(define-public python-nbdev-org-babel-master (package (inherit 
python-nbdev-org-babel-66079a5)(name "python-nbdev-org-babel-master")))



This way you can pin some packages to have an input like 
mypackage-<1234567>


Would that be useful?

Best regards,
David

Re: What happens when you build a Guix package at every step?

[david larsson]

On 2022-09-26 23:03, jbra...@dismail.de wrote:


I think you can also do a
,build derivation

This link has more info:

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



Yes, that is useful info, thx!

Re: What happens when you build a Guix package at every step?

[david larsson]

On 2022-09-25 19:28, jgart wrote:

What would be the best way to illustrate the levels of nesting and code
paths that get traversed when building a Guix package?

I'd like to make some sequence diagram notation or something else to
better understand what happens in a visual way.

wdyt


I like your idea! I'm probably not the most qualified person to answer 
it, since I am (also?) mainly using guix as a sparetime "hobby", but 
still very interested in learning more about it on a deeper level, which 
is a challenge. Some visual aids would definitely be helpful.


I think a shell of an answer would be to link together the following 
things in such a diagram:


1. gexps
2. the store
3. derivations
4. build systems
5. a package

Building a package in the repl, kind of illustrates the code paths via 
code modules used:


scheme@(guix-user)> ,use (guix gexp)
scheme@(guix-user)> ,use (guix store)
scheme@(guix-user)> ,use (guix derivations)
scheme@(guix-user)> ,use (gnu packages bash)

However, in my opinion, the reason we look for the diagram is partially 
bcs of that the concepts of the related things are relatively high level 
so that it takes a while to grasp them, just like monads or maybe higher 
order functions.


However, to continue the repl example:

scheme@(guix-user)> (define (sh-symlink)
  (gexp->derivation "sh"
#~(symlink (string-append #$bash "/bin/bash")
   #$output)))
scheme@(guix-user)> (build-derivations (open-connection) 
`(,(run-with-store (open-connection) (sh-symlink

$1 = #t

Now if you run just the (run-with-store (open-connection) (sh-symlink)) 
you will see the derivation path output, and if you then open a new 
terminal you can cat /gnu/store/shcvi6d1vgry26sq1i3qdmgsmh0n6wmi-sh.drv 
to see the build script without building it.


Now, to build a "package" after above code is loaded:
scheme@(guix-user)> ,use (guix packages)
scheme@(guix-user)> (build-derivations (open-connection) 
`(,(package-derivation (open-connection) bash)))
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%
fetching path 
`/gnu/store/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc'...
Downloading 
https://ci.guix.gnu.org/nar/lzip/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc...
bash-5.0.16-doc  290KiB  750KiB/s 00:00 [##] 
100.0%

$2 = #t

And to only "inspect" it (so you can cat the /gnu/store/paths):
scheme@(guix-user)> (package-derivation (open-connection) bash)
$4 = #/gnu/store/cklj3xvrzrc930qwj1brmwr2dz4zbgd6-bash-5.0.16.drv => 
/gnu/store/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc 
/gnu/store/v1xc4405s7xilmwhhkdj8z55wa2wlr8y-bash-5.0.16-include 
/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16 7fc3d283e500>


Concepts:
  - code staging or "delayed evaluation" concepts
  - what is the store and what is a build environment
  - what is a derivation
  - and finally build systems (normal build steps) and a package (incl. 
dependency graphs).


The start reference point: 
https://guix.gnu.org/manual/en/html_node/Defining-Packages.html



I hope above helps.

Best regards,
David

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[david larsson]

On 2022-08-09 22:53, Maxime Devos wrote:



Agreed (*), but I don't think that subsection claims those are the
only reasons for patches -- that section is only about fixing
technical issues, not adding new features, as implied by the name of
the section.


It definitely doesn't claim that. I phrased it poorly I think.



I can look at adding a new subsection 'Adding new functionality' for a 
v3.


Liliana's documentation contains some information not in my v2, I
intend to look into integrating that information as well.


Thanks, that sounds great!

Best regards,
David

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[david larsson]

On 2022-08-05 15:59, Maxime Devos wrote:

[..]



20.4.5.3 Fixing technical issues (compilation errors, test failures,
other bugs ...)

Usually, a bug fix comes in the form of a patch copied from upstream
or another distribution. In that case, simply adding the patch to the
'patches' field is the most convenient and usually does not cause any
problems; there is no need to rewrite it as a snippet or a phase.

If no ready-made patch already exists, then choosing between a patch
or a snippet is a matter of convenience. However, there are two things
to keep in mind:

First, when the fix is not Guix-specific, it is strongly desired to
upstream the fix to avoid the additional maintenance cost to Guix. As
upstreams cannot accept a snippet, writing a patch can be a more
efficient use of time. Secondly, if the fix of a technical issue
embeds a store file name, then it has to be a phase. Otherwise, if a
store file name was embedded in the source, the result of 'guix build
--source' would be unusable on non-Guix systems and likely also
unusable on Guix systems of another architecture.


There may be other reasons to add patches:

1. Functionality, that is not yet accepted upstream, because 
maintainer(s) do not have enough time to review all pull requests, or 
are simply slow to review. "if no response within X time from upstream, 
then guix may include your patch" might be a good policy here.


2. Bug fixes - as you mentioned - for such, it might be good with a: "if 
no response within X time from upstream, then guix may include your 
bug-fix patch".


3. Unmaintained projects - sometimes there are packages that are nice to 
include but which may no longer be maintained by upstream, and a few 
patches could still make the package usable and nice to have for Guix 
users. IMO such packages should generally be accepted, including minor 
patches that enhances the package. Examples would include guile-bash, 
and maybe emacs-company-tern (not in guix, but might be nice to have). 
There are probably more examples.


Im not a guix maintainer, so maintaining above varieties of patches 
might not be feasible, but there are potential benefits, like maybe guix 
is just "nicer" than other distros because of it. Or it might have the 
opposite effect if the maintenance burden is too high. Guix should 
spread more to mainstream IMO, and being able accept patches that are 
"nice", would benefit that purpose.


Best regards,
David

Re: developing javascript with guix

[david larsson]

On 2022-07-30 15:40, Luis Felipe wrote:


Using the original design of Guix website, this information could be
accessible from "Home page → Guix in Your Field → Software
developement". Clicking on that button would take the user to a
Software Development page, which would link to language specific
information to integrate Guix in one's workflow. So there would be
URLs like these:

https://guix.gnu.org/en/software-development/
https://guix.gnu.org/en/software-development/javascript/
https://guix.gnu.org/en/software-development/python/
https://guix.gnu.org/en/software-development/ruby/

The "Guix in Your Field" idea seems kind of forsaken, but I think it
is quite important.



I'd also like to have a place for this information collected and shared.

Another option, not to imply it's a better one, but maybe worth 
considering, is the libreplanet guix wiki. I think that basically anyone 
can edit the page there, and it would be a smaller barrier of entry to 
contribute (for good and bad).


For guile development there's the information in help-guix with subject: 
"Configuring geiser for load paths of Guix environment", that would be 
useful to add.


For python: I have a setup with emacs, emacs-jedi and jupyter in a nice 
way, and I was leaning towards just sharing it on some git repo of mine, 
which would be a waste when it can be shared with a wider guix audience 
if we had a set place for it. Personally, I'd be more likely to get 
around to share it on the libreplanet wiki, than by sending a patch to 
the guix website. Maybe the website can point to the correct wiki 
subpage from the "software development" (in your field) page?


Best regards,
David

Re: Guix home and operating-system

[david larsson]

I use this to browse a bug by number:
--8<---cut here---start->8---
#!/usr/bin/bash
# browse-bug

num="$(echo "$1"|tr -cs '0123456789' ' '|tr -d ' ')"

my_browser="${MY_BUG_BROWSER:-lynx}"
if [ -n "$num" ];then
$my_browser "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=$num;
else
echo "\
Usage: [MY_BUG_BROWSER=] browse-bug BUG_NUMBER (not
'$1' -> '$num')
BUG_NUMBER will be taken from \$1 word stripped of non-digits if 
any

If you set MY_BUG_BROWSER to firefox-esr, you can run this in the
background like
browse-bug '#56669' &
but lynx will want interaction from you on stdin, so no '&'
NB: if you Ctl-V the #, delete it or quote it, or bash will throw
it away as comment.
"
exit 1
fi
--8<---cut here---end--->8---


Useful idea, thanks!

Re: Teams

[david larsson]

On 4 June 2022 12:07:15 UTC, Ricardo Wurmus  wrote:

* Rust team

[...]

Tobias Geerinckx-Rice


OK what the hell.



Would you wanna create and be the Bash team person as well? :)

Best regards,
David

Re: Arun Isaac Presentation on guix-forge this Saturday

[david larsson]

On 2022-05-25 16:14, Olivier Dion via "Development of GNU Guix and the 
GNU System distribution." wrote:

On Tue, 24 May 2022, jgart  wrote:

hi guixers!

I'd like to invite you this Saturday to a presentation on guix-forge 
by Arun Isaac:


https://guix-forge.systemreboot.net/


Quick question about guix-forge.  Why laminar instead of cuirass as the 
CI?


If you want to use cuirass to build certain packages on new commits to 
those packages (or specific branches thereof), I wrote a script that 
does that about a year ago, it might be of interest:


https://gitlab.com/methuselah-0/guix-cigmon

Though no fancy interface comes included :)

Best regards,
David

Re: Formalizing teams

[david larsson]

On 2022-01-03 16:22, Ludovic Courtès wrote:


I suppose people could explicitly Cc: the team you’re on when they need
specific advice or review; that should already help.

Having some topic-specific streams I could tap into would allow me to 
be

a little more proactive.


This brings a related but slightly different topic: how to let people
filter incoming patches and bug reports in general.

How does it even work on git*.com?  Do they let you subscribe to
issues/merge requests that match certain patterns or touch certain
files?


github.com uses CODEOWNERS file which is well described here: 
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners


Best regards,
David

Re: Building a software toolchain that works

[david larsson]

On 2022-03-17 13:56, zimoun wrote:

Hi Olivier,


On another note, what I find fascinating is why Guix and Nix are not
more used in academic papers.


Indeed.

One part of the answer is, IMHO: it is difficult to spread the word.

For instance, with co-authors, we have tried to write a short paper
detailing what Guix solves, i.e., the computational environment part of
the “science crisis“, and targeting especially bioinfo folks.  We got
many refusals by the journals that bioinfo folks indeed read and we end
in a “specialized” journal.

On the top of that, add the fact that most of the time, people use what
other people in their lab or collaborators already use.

On the top of that, add the fact that the story of Guix on Windows or
Mac is not really good.  I am not arguing here, just to mention that
many people are still using Windows or Mac and few one Linux variant.

Therefore, all in all, the bootstrap of Guix is hard; as always. :-)

The initiative Guix-HPC is an attempt to address that.  The name is
probably not fully representative since now it looks like Guix in
scientific context; HPC being only one component.

From my point of view, the bootstrap of Guix in scientific world
requires more documentation materials for many common use cases and 
more
popular applications or usual scientific stack.  For instance PyTorch 
in

Guix is one step but many things are still really hard to do with Guix
when it is not elsewhere.  Another instance is RStudio for bioinfo 
folks

– it does not work out of the box with Guix when it does elsewhere.

Help in these both areas – howto materials and popular applications – 
is

very welcome. :-)

Join the fun, join guix-scie...@gnu.org :-)


Cheers,
simon


I run Guix including GUI applications from Windows via WSL2 (Windows 
Subsystem for Linux). It may help some to try it out if this setup was 
easier and more documented, though I suppose that is somewhat prevented 
to go via official channels by the FSDG guidelines.


Best regards,
David

Re: git clone with submodules

[David Larsson]

Hi Kandur!
Yes there is. Example:

...
(git-reference (url ...) (commit ...) (recursive? #t))
...

Best regards
David

On Thu, Dec 2 2021 at 08:12:35 +0100, Adam Kandur via Development of 
GNU Guix and the GNU System distribution.  wrote:

Hi guix!
Is there way to clone a project when i'm building a package with all 
git submodules?

Re: Succeed to run guile-bash on Guile 3.0.5

[david larsson]

On 2021-05-10 02:09, Oleg Pykhalov wrote:

Hello,

I succeed to run guile-bash on Guile 3.0.5.


[..]


Oleg.


Hi!

This is great news! I tested your instructions and it works for me as 
well.


Thanks and regards,
David

Re: A proposal for better quality in maintenance of packages by reducing scope

[david larsson]

On 2021-03-23 16:00, Léo Le Bouter wrote:

Hello!

There's lots of packages in GNU Guix and maintaining all of them is
tedious, even if we have tooling, there's only so much we can do.

I want to have a secure and reliable system, I would also like to only
depend on packages I know are easy to maintain for GNU Guix
contributors.

I would like to propose that we reduce the scope of the maintenance we
do in GNU Guix and establish a list of packages that we more or less
commit to maintaining because this is something that we can do and is
attainable, for example, we could remove desktop environments that we
can't maintain to good standards realistically and focus our efforts on
upstreams that don't go against our way of doing things, that are
cooperative, that provide good build systems we can rely on for our
purposes, etc.

I propose we also add some requirements before packages can go into
such a maintained state, like a working and reliable updater/refresher
with notifications directed to some mailing list when that one finds a
new release, a reduced amount of downstream patches and a cooperative
upstream with who we preferably have some point of contact to solve
issues or gather more insider knowledge about the software if we need,
a working and reliable CVE linter with proper cpe-name/vendor and
notifications going to a mailing list we all subscribe to, etc..
probably lots of other things are relevant but you see the idea.

It should also be possible to filter out packages that are not declared
to be in this maintained state, for example, in the GNU Guix System
configuration.

Some kind of quality rating for packages that users can trust.

What do you think?

Léo


Hi,

Related to your idea on having a relaible updater/refresher; I solved 
some maintenance for myself a while ago by writing a script(1) that I 
used with cuirass which automatically updates packages (both commit and 
hash) to the latest commit for a specified branch, and the same script 
also updates a manifest that is used by a cuirass instance to build 
packages. This way I could install - which 
would be continuously updated and built by cuirass, or 
- when I wanted to stay at a certain upstream 
commit. This is perhaps not the most secure solution, especially not for 
distributing as default, but maybe something similar can be used to help 
maintain the latest version of a subset of packages?


(1) https://gitlab.com/methuselah-0/guix-cigmon/-/tree/master

Best regards,
David

Re: Make guix commands pipeable

[david larsson]

On 2021-03-20 13:13, pkill9 wrote:

I would like to be able to pipe files into guix commands.

Specifically the `guix system build` command, so I can build a system
configuration on a remote Guix system over SSH, i.e. `cat config.scm |
ssh  guix system build -`, or perhaps using the
`--expression` flag which would make more sense, e.g. `cat config.scm |
ssh  guix system build -e -`.

While you can currently just copy over a file and then use that, it
would be a little cleaner and more stateless to use a pipe.

What do other people think?


I like pipes and this would be nice to have. Though an easy way to wrap 
things in bash and make them pipable at the same time is to use the -t 
check like this:


f(){ [[ ! -t 0 ]] && mapfile -t Args ; if [[ -n "${Args[@]}" ]]; then 
printf 'some_command %s ' "${Args[@]}" ; else printf 'some_command %s ' 
"$@"; fi ; }

printf '%s\n' a b c | f
f a b c

So you could define f as: f(){ [[ ! -t 0 ]] && mapfile -t -d '' Args ; 
if [[ -n "${Args[@]}" ]]; then ssh  guix system build -e 
"${Args[@]//$'\n'/}" ; else ssh  guix system build -e 
"$@"; fi ; }


and then I think you should be able to cat config.scm | f

Notice -d '' above which means use null as delimiter which will most 
often put everything in index 0 of the list. Also notice the parameter 
expansion which removes all newlines from the content.


I do agree though that it would be nicer to just have '-' as a guix 
input arg causing any guix command to read from stdin.


I hope it helps!

Best regards,
David

Re: Guix in Debian!

[david larsson]

This is great news!

I have to mention that I experienced a bug using Guix on Debian not so 
long ago that broke my Debian host install completely. I could only 
restore my Debian system via snapshot after. This happened when creating 
a Guix container and using Guix from inside it. May be worth looking 
into fixing that before Guix gets included in Debian, as to not make a 
bad first impression on possibly many Debian users.


https://lists.gnu.org/archive/html/bug-guix/2021-01/msg4.html

Best regards,
David

Re: guile-bash updated source url

[david . larsson]

On Wed, 8 May 2019, Mark H Weaver wrote:


FYI, David might not have seen my reply below, because my mail server is
unable to perform DNS lookups for his domain, and thus is unable to look
up the MX record to deliver mail to him.  I'm not yet sure what's going
wrong, maybe something in my firewall configuration.

 Mark


Hi,

Im not sure why, I do make some scheduled blocklist-updates and resets
around midnight which could have led to a temporary block. (Though I
think most MTA's just resends a few times before giving up so I
haven't concerned myself with this so far).




I made a commit since I was unable figure out how to create a
git-mirror from the Software Heritage website but was able to retrieve
the correct commit as a tarball. Then I guix init'ed the folder, and
made a commit in order to push it to gitlab.


Hmm.  If I understand correctly, it sounds like this will discard the
entire previous git history.  If you want to maintain this package and
host the repository yourself (as opposed to us relying on Software
Heritage), I would advocate trying again until you can properly clone
the existing repository.  We can help if needed.  It's important to get
this right now, because git history cannot be rewritten after the fact,
and it's important to preserve the existing history.


Yeah unfortunately the gitlab url I added don't have any git
history. If you can help me retrieve it from software heritage like a
git clone or so with the git version history that would be very
nice. I tried finding a way and looked at swh.scm but I couldn't
figure it out within any reasonable amount of time.

Sincerely,
David L

Re: guile-bash updated source url

[david . larsson]

Hi Andreas & Ludo,

On Fri, 3 May 2019, Ludovic Courtès wrote:


Hello David,

david.lars...@selfhosted.xyz skribis:


This is my first contribution to guix and it's just a minor fix for
the guile-bash package which had an outdated source url. I was able to
retrieve the same revision of the package via the software-heritage
project's website and upload it to gitlab. Then I installed it
successfully via guix package -f my-guile-bash.scm using the gitlab
url, then copied it to the existing guile-xyz.scm in gnu/packages.


[...]


--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -294,23 +294,21 @@ dictionary and suggesting spelling corrections.")
 (license license:gpl3+)))

 (define-public guile-bash
-  ;; This project is currently retired.  It was initially announced here:
-  ;; .
-  (let ((commit "1eabc563ca5692b3e08d84f1f0e6fd2283284469")
+(let ((commit "49099fe6a592aa3b8001e826b939869fe5811785")
 (revision "0"))


Why is the commit different?  Looks like it’s more than just a mirror.

If you made changes on top of the original code, that’s actually great.
However, I’d prefer to first see a patch that simply changes the URL,
not the commit and hash, and later updates to a different revision.

Does that make sense?



I made a commit since I was unable figure out how to create a
git-mirror from the Software Heritage website but was able to retrieve
the correct commit as a tarball. Then I guix init'ed the folder, and
made a commit in order to push it to gitlab.


Andreas Enge  skribis:


should the package not be retrieved automatically from Software Heritage
with the newest Guix API? And apart from that, will it be desirable to keep
around an unmaintained software for which the source has disappeared?


I don't know if the newest Guix API would fix it, but I haven't been
able to install guile-bash from source so far using e.g. guix
challenge. I can't really answer your second question, but I will
personally use the package and thought it would be nice to be able to
retrieve it from a standard Guix install and that it can be built and
challenged. Previously I had to add additional --substitute-url's to
guix install it.



I think David is in fact suggesting that they may well be maintaining
it, which is good news IMO.  :-)


I wish that was the case - maybe in the future, I am slowly learning
Guile at the moment :-)

Currently, I can at most support the package definition and change the
url if someone notifies me they want to start actively maintaining it.

So I don't know if you think the patch should be rejected or not.. maybe
the comment about the project being retired should remain, if so I can
resubmit a patch.

Thanks for your comments,
// David L

guile-bash updated source url

[david . larsson]

Hello Guix,

This is my first contribution to guix and it's just a minor fix for
the guile-bash package which had an outdated source url. I was able to
retrieve the same revision of the package via the software-heritage
project's website and upload it to gitlab. Then I installed it
successfully via guix package -f my-guile-bash.scm using the gitlab url, 
then copied it to the existing guile-xyz.scm in gnu/packages.


I have attached a patch-file with the changes.

--
Best Regards
David LFrom 75f8252f2c27f04961445f898041dd3f8a552e8a Mon Sep 17 00:00:00 2001
From: David Larsson 
Date: Sun, 28 Apr 2019 10:05:39 +0200
Subject: [PATCH] Updated source url for guile-bash package

---
 gnu/packages/guile-xyz.scm | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 03fd63837e..8f341be781 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -294,23 +294,21 @@ dictionary and suggesting spelling corrections.")
 (license license:gpl3+)))
 
 (define-public guile-bash
-  ;; This project is currently retired.  It was initially announced here:
-  ;; <https://lists.gnu.org/archive/html/guile-user/2015-02/msg3.html>.
-  (let ((commit "1eabc563ca5692b3e08d84f1f0e6fd2283284469")
+(let ((commit "49099fe6a592aa3b8001e826b939869fe5811785")
 (revision "0"))
 (package
   (name "guile-bash")
   (version (string-append "0.1.6-" revision "." (string-take commit 7)))
   (home-page
-   
"https://anonscm.debian.org/cgit/users/kaction-guest/retired/dev.guile-bash.git;)
+   "https://gitlab.com/methuselah-0/guile-bash;)
   (source (origin
 (method git-fetch)
 (uri (git-reference
   (commit commit)
-  (url home-page)))
+ (url "https://gitlab.com/methuselah-0/guile-bash.git;)))
 (sha256
  (base32
-  "097vny990wp2qpjij6a5a5gwc6fxzg5wk56inhy18iki5v6pif1p"))
+  "1cwyf7sd0chrfmfipkvaph5gf70hck6fj36sxcc4ncin49xlxv0l"))
 (file-name (string-append name "-" version "-checkout"
   (build-system gnu-build-system)
   (arguments
-- 
2.20.1