Guix, Nix flakes, and object capabilities

[Jonathan Frederickson]

Hello Guix,

I recently had a discussion in #spritely on Libera.Chat about Guix and
Nix, and in particular a (relatively) new feature of Nix called flakes
that Guix doesn't currently have an analogue for.

I've been a Guix user for a while, but I've only recently started
looking at using Guix for development via ~guix shell~ as in this blog
post by David Thompson[0]. The Guile port of Spritely has been using it,
so I've been trying it out for one of my own projects as a result. And
it seems pretty nice; you're using the same package definitions you
might use when contributing a package upstream to Guix, which feels
pretty natural as someone already pretty familiar with Guix as a user.

However, I noticed something about the resulting dependency graph that
feels somewhat unsatisfying. When you define a package, the
dependencies you provide in e.g. ~inputs~ are references to
packages. And the way you get those is, of course, by importing
modules containing those packages.

But the package you end up with each time you do that... depends on
which revision of Guix you're running when you run ~guix shell~! So if
I point someone to a project with a ~guix.scm~ file, they might not be
able to use it if their Guix revision is too old. (Or too new, if
packages have been renamed or removed.) More generally, it means that
they do not end up with the same dependency graph that I do. This
makes troubleshooting potentially tricky, because if something breaks
you have to check the resulting profile to see which versions of your
package's dependencies (and transitive dependencies) are actually
installed.

For those who haven't used Nix, it has a solution to this called
flakes. Flakes let you specify git repositories explicitly as inputs for
your project[1]. (It also maintains a flake.lock file so you can lock to
a specific revision automatically while still using a named branch in
your inputs directly, but I believe you could in theory refer to a
specific rev in your inputs.) Effectively, the channels you're using for
dependencies are specified by the project you're building, not whatever
happens to be configured on your local machine.

I think something like this would be useful for Guix for many of the
same reasons it's useful in Nix. But there's a bit of a security
conundrum here. Loading Guix package definitions involves code
execution, which as far as I can tell isn't currently sandboxed at all!
And that's a problem. When you load package definitions from a channel
that you've configured on your system, you've explicitly trusted that
channel's maintainers. But with a flake-like system... even if you might
be okay depending on someone else's code, that doesn't necessarily mean
you fully trust them. You might ultimately choose to sandbox the
resulting binary, but that's moot if you can't fetch its dependencies
without running arbitrary code with all of your user's authority.

I think there is a solution to this, though. Right now when you
evaluate Guix package definitions, you're basically running arbitrary
Guile code. This of course can do anything you can do. But it doesn't
have to! If you're familiar with Christine Lemmer-Webber's work on
Spritely, you'll probably know what I'm getting at here: I think using
object capabilities[2] would fix this. I recommend reading the linked
blog post for a good explainer on what object capabilities are, as I
won't do it justice here, but to perhaps oversimplify: code in a
capability system only has access to the things you give it, and no
more. It's like lexical scope, but taken very seriously.

If you think about what a typical package definition needs to be able to
do to your system directly, I think it's not actually that much? My
(admittedly basic, possibly flawed) understanding of how Guix works is
that most of the heavy lifting is done by ~guix-daemon~, which itself is
pretty heavily sandboxed, and that most of what the ~guix~ subcommands
are doing is building derivations which instruct ~guix-daemon~ to
perform build actions. So while you're building these derivations,
unless I'm misunderstanding:

- You don't need network access
- You don't need (much) filesystem access

I think object capabilities provide a good answer to this
problem. Rather than evaluating package definitions from a channel as
you would normally run Guile code, evaluate them in a restricted
environment that only has access to things you've passed in. In
JavaScript, this might look like this (taken from this blog post[3]
about the event-stream incident):

#+BEGIN_SRC javascript
  const addHeader = require('./addHeader', {fs, https});
#+END_SRC

This way, you could import modules including packages you'd like to
use as dependencies, and if you don't pass those modules access to the
rest of your filesystem they won't have it, and can't do things like
cryptolocker your home directory. (At least not until you run some
software installed from it, but that's a separate issue!)

Of course, easier said than 

Re: Hoping to donate/sell a Talos II motherboard

[Luke Kenneth Casson Leighton]

On Tuesday, February 28, 2023,  wrote:
> Hello you fabulous developers!
>
> My friend has a spare Talos II motherboard that is currently sitting in
his house
> in Indiana USA collecting dust.
>
> https://www.raptorcs.com/TALOSII/
>
> I have convinced him to donate/sell it to an open source project or
developer.
>
> I reached out to Richard Stallman, and he agreed to take the board.  I am
certain that the
> FSF would put it to good use.  My friend and I have not yet decided, to
whom we will give
> the motherboard.  Is it possible that I could give it to someone or
project, such that all
> parties here would benefit?

i am reasonably certain that Toshaan Bharvani would be
prepared to do that although he would need to speak for
himself.

the other option would be to donate it to the University of
Oregon who already have POWER9 systems that are accessible
to FOSS projects via the "OpenPOWER Hub".  cc'ing Sameer
as well.

(in case that wasn't clear: FOSS projects can *already*, right
now, apply for access to POWER9 systems, do i have that right,
Sameer?)

> Is there any project or developer here that would be willing to take this
motherboard and create
> virtual machines that other projects could have access to?
>
> Thoughts?
>
> Thanks,
>
> Joshua Branson
> FOSS enthusiast
> https://gnucode.me
>
>

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Interest in Participating for GSoC '23

[Sarthak Shah]

Hi everyone,

Hello! I'm interested in contributing to the GNU Guix project through the
Google Summer of Code program.
My programming expertise mainly lies with Scheme, Common Lisp, Clojure and
C/C++, but I can also write code in other languages when needed.
Additionally, I have some experience as a system administrator of my
university's HPC system.
I am also the president of my college's equivalent of a GNU/Linux advocacy
group, through which I have organized and facilitated GNU/Linux
installation workshops to introduce my classmates and juniors to free
software.

I would love to work on a project utilizing GNU Guile if possible.
Of the projects listed on the website
, I found the following
interesting:
- Continued Rewrite of the Build Daemon in Guile

(Mentors
mentioned: Ludovic (+ David, +...?))
 (If I understand correctly, this will be a continuation of reepca's work
in 2017
)
- Guile-based build tool

(Mentors
mentioned: Pjotr Prins and other Guix members)
- Guix Data Service revision processing instrumentation and performance

(Mentors
mentioned: Christopher Baines & Gábor Boskovits)
I understand that the mentors listed here may not necessarily be free to
mentor this year, however I would really appreciate getting to work on any
of these projects.

Apart from the listed projects, I'm also interested in having parameterized
packages
 in
Guix.
Unlike most package managers, Guix is source-based and I believe that
parametrized packages would be a fine way to use that to Guix's advantage.

It's tradition for potential GSoC participants to help resolve issues
before applying in preparation for the actual task, so I would appreciate
suggestions on problems I could help with.
Additionally, a rough timeline of when I'd be expected to submit a draft
proposal would be appreciated.

Happy Hacking!
Sarthak
IRC nick: cel7t

Re: Qt in core-updates

[Andreas Enge]

Am Wed, Mar 01, 2023 at 12:54:04AM +0100 schrieb Andreas Enge:
> Well, I gave it a try, and it seems to be okay.

I spake too fast. Somehow I took samba/fixed from core-updates instead
of samba/pinned from master, and since I do not quite follow which is what,
I will give up and let someone else figure it out... I am too afraid of
making security relevant wrong choices here or incidentally downgrading
packages by choosing the wrong version.

Anyway, I still think it would be good to merge master into core-updates,
to get rid of (qt)webkit, and thus to advance on pyqt and consorts.
Thanks!

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 09:55:28PM +0100 schrieb Andreas Enge:
> Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge:
> > Maybe it is time to merge master back into core-updates?
> Where the vague "it is time to" could be read as "could you please?".
> It is something I have never done, so it makes me nervous. Well, I suppose
> I could just merge and try to fix the merge conflicts?

Well, I gave it a try, and it seems to be okay. So far I pushed it as a
separate branch, wip-andreas-merge. It does compile. If you agree, I
could also push it to core-updates (assuming that merge commits can be
pushed just like every other commit; I am a bit doubtful what happens if
someone else pushes other commits in the meantime; probably then I will
have to merge a second time, to core-updates, instead of just pushing
there?).

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge:
> Maybe it is time to merge master back into core-updates?

Where the vague "it is time to" could be read as "could you please?".
It is something I have never done, so it makes me nervous. Well, I suppose
I could just merge and try to fix the merge conflicts?

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 01:20:08PM -0500 schrieb Leo Famulari:
> Qtwebkit has been removed from the master branch.

Oh right, I even remember now that you sent messages about it.
Maybe it is time to merge master back into core-updates?

(Although the problem here seems to be unrelated to webkit, it already
occurs for compiling the flavour of python-pyqt *without* webkit.)

Andreas

Guix v1.1.0 (~2020) and Software Heritage & friends

[Simon Tournier]

Hi,

Here I would like to report my attempt to simulate a “network collapse”
– as discussed with Mathieu at Guix Days. :-)

What is the minimal set of machines for running “guix time-machine” from
a current Guix to an older one?

Using this,

archive.softwareheritage.org
disarchive.guix.gnu.org
git.savannah.gnu.org

is not enough.  It fails for many.  For instance,

ed-1.15
gcc-core-2.95.3
ghostscript-9.27
guile-2.2.6
linux-libre-4.19.56-gnu
linux-libre-headers-stripped-4.14.67-i686-linux
mes-0.19
mes-minimal-stripped-0.19-i686-linux

do not seem backed up with SWH + Disarchive.  Well, basically after
these, I stop because it’s boring and I add ftp.gnu.org to the list.  It
still fails,

nyacc-0.86.0
static-binaries

First lesson: we have holes in sources.json and maybe Disarchive too; I
will give a look.

To be continued…

Cheers,
simon

- - -

Using Guix b8f6ead (~February 2023) and trying to go to v1.1.0 (~April
2020) corresponding to this commit,

--8<---cut here---start->8---
$ cat /tmp/v1.1.0.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(commit
  "d62c9b2671be55ae0305bebfda17b595f33797f2")))
--8<---cut here---end--->8---

All is fine when substitutes is allowed and the network is fine.  So let
garbage collect all and restart reaching the minimal set of network.

Now, let disable the network name resolution and only resolve for
archive.softwareheritage.org. Then using the exact same command line as
previously, I get:

--8<---cut here---start->8---
$ guix time-machine -C /tmp/v1.1.0.scm -- help
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%guix 
substitute: warning: ci.guix.gnu.org: host not found: Name or service not known
substitute:
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   
0.0%guix substitute: warning: bordeaux.guix.gnu.org: host not found: Name or 
service not known
substitute:
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%
retrying download of '/gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm' 
with other substitute URLs...
guix substitute: warning: bordeaux.guix.gnu.org: host not found: Name or 
service not known
guix substitute: error: failed to find alternative substitute for 
'/gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm'
substitution of /gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm failed
building /gnu/store/4a2p4vylpw1l0wz5szvyh4xgm0x5pl7f-config.scm.drv...
guix time-machine: error: some substitutes for the outputs of derivation 
`/gnu/store/lf70hiwqyz5qx418zjz7chn2lwq7nhic-module-import-compiled.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source
--8<---cut here---end--->8---

which is a bit unexpected.  I miss why Guix does not fallback by itself
but that’s another story I guess.

Let re-run using --fallback as explained,

--8<---cut here---start->8---
$ guix time-machine -C /tmp/v1.1.0.scm --fallback -- help
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%guix 
substitute: warning: ci.guix.gnu.org: host not found: Name or service not known
substitute:
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   
0.0%guix substitute: warning: bordeaux.guix.gnu.org: host not found: Name or 
service not known
substitute:
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%
retrying download of '/gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm' 
with other substitute URLs...
guix substitute: warning: bordeaux.guix.gnu.org: host not found: Name or 
service not known
guix substitute: error: failed to find alternative substitute for 
'/gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm'
substitution of /gnu/store/8kv98fjwjp26ry1ixjdz28i1vjj9xfqi-config.scm failed
building /gnu/store/4a2p4vylpw1l0wz5szvyh4xgm0x5pl7f-config.scm.drv...
building /gnu/store/0xpdpf1az8p2i1zppn4s1w407f5b2ngg-git.scm.drv...
building /gnu/store/c70kbbbw6v9vj10fab7jnbjl9yv3s23j-hash.scm.drv...
building /gnu/store/cq303xhw6g86b5nyn1xc1gqr2i5bgn91-module-import.drv...
building /gnu/store/z4f6cy8lp1c90wvjzh738kdznxbii2vf-module-import.drv...
building 
/gnu/store/wjbqf99lhpyx84c6nqdvvl1lyhgi7igw-module-import-compiled.drv...
building 
/gnu/store/lf70hiwqyz5qx418zjz7chn2lwq7nhic-module-import-compiled.drv...
building 

Re: Qt in core-updates

[Leo Famulari]

Qtwebkit has been removed from the master branch.

On Tue, Feb 28, 2023, at 13:09, Andreas Enge wrote:
> Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge:
>> Now I am trying to build all
>> the Qt packages before applying the patch to core-updates; it looks good
>> so far.
>
> It went well with all the qt* packages.
>
> Then python-pyqt-without-qtwebkit fails already in its configure phase,
> hopefully an easily solved problem.
>
> Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge:
> Now I am trying to build all
> the Qt packages before applying the patch to core-updates; it looks good
> so far.

It went well with all the qt* packages.

Then python-pyqt-without-qtwebkit fails already in its configure phase,
hopefully an easily solved problem.

Andreas

Re: Qt in core-updates

[Andreas Enge]

In the context of security problems and package removal, I just noticed
(by "./pre-inst-env guix package -A ^qt") that we still have a qtwebkit
package. The latest release dates from 2020, and this also the last
release, if I understand correctly that the project has been abandoned.

However:
Building the following 31 packages would ensure 43 dependent packages are 
rebuilt: kdewebkit@5.98.0 psi@1.5 lmms@1.2.2 python-pymol@2.5.0 hplip@3.22.4 
toutenclic@7.00 cura@4.13.1 electron-cash@4.2.12 trezor-agent@0.14.4 
electrum@4.3.2 frescobaldi@3.1.3 flyer-composer@1.0rc2 
rapid-photo-downloader@0.9.18 asymptote@2.84 python-woob@3.0 orange@3.32.0 
pyzo@4.12.4 offlate@0.6.1 qgis@3.26.2 openmolar@1.0.15-gd81f9e5 autokey@0.95.10 
nanovna-saver@0.5.3 qspectrumanalyzer@2.1.0 gnss-sdr@0.0.17 gqrx@2.15.9 
urh@2.9.3 python-setools@4.4.0 plover@4.0.0.dev12 manuskript@0.14.0 dream@2.2 
aseba@1.6.0-0.3b35de8

So it looks like there is some work ahead to update or remove these packages.

Andreas

Re: Question on the process of packge withdrawal

[Simon Tournier]

Hi,

On Tue, 28 Feb 2023 at 17:26,  wrote:

> IMO, it's a matter of storing the junk where it will not be a toxic liability
> and nuisance, yet easily discovered by someone looking for "parts."

Well, I will not call that "junk". :-)

IMHO, this is discoverable since it is part of the Git history of
Guix.  The Git history of Guix also acts as an inventory.

Cheers,
simon

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Tue, Feb 28, 2023 at 03:57:33PM +0100, Andreas Enge wrote:
> Updating packages that noone is interested in is an unnecessary drag
> on volunteers' time.

This is the key point, in my opinion.

Those who wanted to use this package were very welcome to do something
about it. And they are still welcome to contribute a working package.
They will even receive help and advice on IRC and the mailing lists :)
But they must lead the effort.

This whole conversation seems contrived because, clearly, nobody was
using jrnl in Guix, since it was broken for 4(!) years.

Guix is a distro for using programs. Not a graveyard, a junkyard, or a
collection of historical artifacts.

Re: Question on the process of packge withdrawal

[bokr]

Hi,

On +2023-02-28 11:30:21 +0100, Simon Tournier wrote:
> 
> I proposed to remove the package because it was broken and no one was
> willing to fix it.  What is the point to keep broken packages?
>

What is the purpose of a junk-yard for broken cars?

I think there is some use :) I kept an old VW going many decades
by more than once in my youth going with tools to a junk yard
where the deal was:
  Find what you need in some wreck, detach it with your own tools,
  bring it to the office, and negotiate a price.
  (the office guy could usually point you to the likely wrecks
  if you described what you needed, and would even offer to rent you
  some tools and help, all negotiable :)

IMO, it's a matter of storing the junk where it will not be a toxic liability
and nuisance, yet easily discovered by someone looking for "parts."

Software "parts" are a little different, but the R (remove & replace)
aspect seems similar ;-)

And it should be easy to keep an inventory of junk-yard contents by bug numbers.
Maybe somone would enjoy curating "junk" :)

Disclaimer: I am a terrible pack-rat ;/
(with no time to be junk curator, though I appreciate their work, along with
any{one,thing} helping me find what I want (rather than the other way around) :)

[...]
> Cheers,
> simon
> 
--
Regards,
Bengt Richter

[job] Semantic CSS Developer to implement new visual identity of a Guix based company

[Giovanni Biscuolo]

Hello Guix developers,

[You can also find our announcement on the web: 
https://beta.softwareworkers.it/en/jobs/2023-css-developer/]

We build our Content Management System (CMS) as a static site generator
based on Emacs Org mode and Guix to manage all software dependencies.

We are looking for a CSS developer to implement the new visual identity,
to be applied on our sites [0]. The assignment will be governed by the
Open Contract for Agile Development [1].

Those wishing to apply are invited to check their willingness to adhere
to our CMS design principles [2].

Knowledge of Git distributed version control system, literate
programming, Emacs Org mode authoring system and LASS [3] or similar
Lisp/Scheme based CSS pre-processors are valued as a plus.

All code and documentation will be released with a free copyleft
license.

If interested, please write to j...@softwareworkers.it.

Happy hacking! Gio'

__
Footnotes:

[0] The versions under development are:
https://beta.softwareworkers.it/ (institutional website)
https://beta.meup.io/ (operational portal)
https://doc.meup.io/ (documentation)

[1] 
https://gitlab.com/softwareworkers/swws/-/blob/develop/documentation/source/doc.swws/en/legal/sprint-agreement/index.org

[2] https://doc.meup.io/colophon/#cms-design-principles

[3] https://shinmera.github.io/LASS/

-- 
Giovanni Biscuolo

Software Workers - IT Infrastructures


signature.asc
Description: PGP signature

Re: Qt in core-updates (was: KDE in core-updates)

[Andreas Enge]

Hello Philip, Kiasoc5, Efraim,

thanks a lot for your input!

Indeed I got my information that Qt 5 was phased out from Wikipedia,
which mentioned May 2021 as the end of support. I did not expect there
to be more versions! But then discovered the 5.15.8 version, probably
related to the commercial support available until May this year?

Anyway, I updated in my own branch wip-andreas-core-updates (since I wanted
to avoid rebuilding core-updates with its recent world-rebuilding changes);
just qtwebengine takes 6 hours on my laptop... (And it required the update,
since it would not build at version 5.15.5.) Now I am trying to build all
the Qt packages before applying the patch to core-updates; it looks good
so far.

Andreas

Re: Python

[Andreas Enge]

Am Mon, Feb 27, 2023 at 08:14:54PM +0100 schrieb Lars-Dominik Braun:
> I don’t think we should follow PyPi’s names strictly. python-cheetah3
> makes much more sense than python-ct3. That’s what upstream-name is for.

Okay, I am fine with doing nothing :)

Andreas

Re: Question on the process of packge withdrawal

[Andreas Enge]

Hello,

Am Sun, Feb 26, 2023 at 08:11:52PM + schrieb Sharlatan Hellseher:
>   If we check
>   
> 
>   commit removing jrnl variable which has it's source pointing to
>    which is an old fork of original
>   active project .

the reason is in the commit message:
The last release of the package dates from 2019.
It depends on the cryptography library python-pycrypto, which has had
its last release in 2013 and "is unmaintained, obsolete, and contains
security vulnerabilities" according to its homepage.

The github repository says
   This branch is 811 commits ahead, 1580 commits behind jrnl-org:develop
Difficult to know what is the good version... (We were two to think the
projet was dead upstream.)

I am happy to put it back in (the cryto apparently comes from
python-cryptography now). However, the previous version 1.9.7 was from 2014,
there was a version 2.0 in 2019, and the current version is 3.3.
Is there sufficient compatibility to "upgrade" (by reverting the removal
commit and updating as usual)? Or should it be treated like a new package?
Have you used the 1.9.7 package recently? Has anybody used it recently?
Otherwise I would be enclined to leave it out until someone wishes to put
it in again as a "new" package. Updating packages that noone is interested
in is an unnecessary drag on volunteers' time.


Concerning the process, I think we should have one :)
It would be nice to document the process in the manual.
This should differentiate between the different reasons for removal:
security problems, not building, etc.

Andreas

Re: Requesting permission to post a job search in guix-devel

[Tobias Geerinckx-Rice]

Hi Andrea [on-list],

So, good news.

A majority of maintainers has awoken, and all agree that job 
searches are welcome on guix-devel@ as long as they:


 1. are related to Guix, obviously not an issue here;
 2. do not promote non-free software.

Promotion would include applicants being ‘encouraged’ or required 
to produce non-free software to get (or increase their chances of 
getting) the job.


Certainly not the vibe I got from your company, so if you/Gio' can 
vouch for that, feel welcome to share your post!


Best of luck,

T G-R


signature.asc
Description: PGP signature

Re: Follow-up on julia import script

[Simon Tournier]

Hi,

On lun., 27 févr. 2023 at 19:01, Nicolas Graves via "Development of GNU Guix 
and the GNU System distribution."  wrote:

> That's what I meant, but it seems indeed impossible. In the hypothesis
> this juliahub script gets merged, what should we do? Really cloning the
> repository and getting it or rather just provide a given (false) hash?

Well, many importers are downloading the source for hashing it, so yes
it appears to me something the importer should do.

Moreover, cloning it would allow to extract various inputs /
propagated-inputs / native-inputs.

Thank you for pushing forward. :-)

Cheers,
simon

Re: Question on the process of packge withdrawal

[Simon Tournier]

Hi,

On dim., 26 févr. 2023 at 20:11, Sharlatan Hellseher  
wrote:

>   Other example
>   
> 
>   the reason it's not updated at  -
>   development was moved to .

I proposed to remove the package because it was broken and no one was
willing to fix it.  What is the point to keep broken packages?

Here, the timeline:

Report broken:4 Dec 2018 (4 years, 12 weeks, 1 day ago)
Try update:  13 Jul 2022 (32 weeks, 5 days, 20 hours ago)
Propose removal: 17 Oct 2022 (19 weeks, 14 hours, 57 seconds ago)
Send patch:  21 Jan 2023 (5 weeks, 2 days, 18 hours ago)
Commit patch:21 Jan 2023

Well, the two “improvements“ here could be, IMHO:

 a) send patch to guix-patches instead of the bug report itself,
 b) wait some days between send and commit.


>   That tendency concerns me as a packager it's not clear for me which
>   criterias were used to make a division to withdraw the package(s). The
>   age of project is not always a good measure for example example,
>   [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
>   touched since the last commit) but still in active use (check
>   [pgloader])

>From my point of view, the first rule is if the package still builds or
not.  If the package is broken, let try to fix and if it is not possible
because unmaintained or else, then let drop it.

The second rule is if the package is a leaf or not.  More dependants the
package has and more effort should be put in fixing it, IMHO.

The third rule is about security.  From my point of view, old packages
with known vulnerabilities are not appealing for working on fixing it.

Else, if the package still builds, I do not see why it would be removed.
Old unmaintained (or barely maintained) packages* are very common in
scientific context and they just still works very well. :-)

*as linear algebra libraries wrote long time ago using good ol’
 Fortran. ;-)  Still the state of art.


Cheers,
simon