sbcl-py4cl does not appear in --list-dependent output

[jgart]

Hi Guixers,

Does anyone happen to know why sbcl-py4cl doesn't appear in this output?

guix refresh --list-dependent python-numpy

Building the following 1490 packages would ensure 3164 dependent packages are 
rebuilt: python-pytest-pudb@0.7.0 python-fpylll@0.5.7 python-flint@0.3.0 
aoflagger@3.2.0 python-fitsio@1.2.1 audio-to-midi@2020.7 crossmap@0.6.1 
rseqc@3.0.1 python-pyfit-sne@1.2.1 shorah@1.99.2 seqmagick@0.8.4 
python-bcbio-gff@0.6.9 python-nose-randomly@1.2.6 python-tweepy@4.4.0 
rtv@1.27.0 tuir@1.29.0 python-flask-oidc@1.4.0 
python-google-auth-oauthlib@1.1.0 python-wsgi-intercept@1.2.2 
python-google-api-client@2.102.0 ceph@17.2.5 r-cistopic@2.1.0 
r-cistopic-next@0.3.0-1.04cecbb r-chromunity@0.0.2-1.712e56c feedgnuplot@1.60 
python-django-bulk-update@2.2.0 python-django-simple-math-captcha@1.0.9 
python-django-ninja@0.22.2 python-django-localflavor@3.1 
python-django-taggit@1.3.0 python-django-contrib-comments@1.9.2 
python-django-debug-toolbar-alchemy@0.1.5 python-django-sortedm2m@3.0.2 
python-django-contact-form@1.9 python-django-override-storage@0.3.0 
python-django-logging-json@1.15 python-django-assets@2.0 python-django-rq@2.7.0 
python-django-url-filter@0.3.15 python-django-configurations@2.4.1 
python-django-auth-ldap@4.1.0 python-django-netfields@1.3.0 
python-django-statici18n@2.1.0 patchwork@3.1.1 postorius@1.3.6 
python-openid-teams@1.1 python-openid-cla@1.2 dynaconf@3.1.7 
python-django@4.2.5 python-haversine@2.7.0 r-snapatac@2.0 r-insol@1.2.2 
r-rastervis@0.51.6 r-leaflet@2.2.1 r-mlrmbo@1.1.5.1 
r-cicero-monocle3@1.3.2-1.fa2fb65 r-ggvenndiagram@1.2.3 r-rnaturalearth@0.3.4 
r-bien@1.2.6 r-tmaptools@3.1-1 r-zonebuilder@0.0.2 r-ggpattern@1.0.1 
r-sungeo@1.1.1 r-zoon@0.6.5 r-zonator@0.6.0 python-hyperkitty@1.3.5 
postgis@3.2.1 osmium-tool@1.15.0 osm2pgsql@1.9.2 python-h3@4.0.0b2 
gnome-plots@0.6.2 mypaint@2.0.1 rmlint@2.10.2 gbonds@2.0.3-1.3054ee2 
transmission-remote-gtk@1.4.2 dia@0.97.3-4.b903dd8 five-or-more@3.32.3 
vala-language-server@0.48.3 gnome-sudoku@42.0 libskk@1.0.5 snixembed@0.3.3 
dnssec-trigger@0.17 gromit-mpx@1.4.2 nicotine+@3.2.1 gammastep@2.0.9 
xfce4-statusnotifier-plugin@0.2.3 rust-notmuch@0.6.0 aerc@0.15.2 bower@1.0 
alot@0.10 neomutt@20230517 notmuch-addrlookup-c@9 afew@3.0.1 
emacs-consult-notmuch@0.8.1 emacs-piem@0.5.0 emacs-ol-notmuch@2.0.1 
emacs-notmuch-maildir@0.2.2 emacs-helm-notmuch@1.2 
emacs-wanderlust@2.15.9-803.3e8cf26 emacs-counsel-bbdb@0.0.5 
emacs-counsel-notmuch@1.0-0.a4a1562 muchsync@7 emacs-treemacs-extra@3.1 
emacs-mu4e-jump-to-list@1.0-1.358bba0 emacs-mu4e-dashboard@0.1.1-0.16ffbb2 
emacs-git-email@0.2.0-0.b5ebade emacs-mu4e-alert@1.0-0.3c9af8c 
emacs-mu4e-conversation@0.0.1-5.98110bb emacs-helm-mu@20180513-1.77e6fea jj@2 
mcabber@1.1.2 freetalk@4.2 createrepo-c@0.20.1 pam-u2f@1.0.8 book-sparc@1.1.0 
solfege@3.23.5pre2 bluez-alsa@3.0.0 emacs-bluetooth@0.3.1 xmp@4.1.0 
espeakup@0.90 emacspeak@53.0 snapcast@0.27.0 cava@0.8.3 libsoundio@2.0.0 
csfml@2.5.1 mars@0.7.5-2.84664cd schiffbruch@1.2.1-0.e41916d 
extremetuxracer@0.8.2 marble-marcher@0-1.e580460 allegro@5.0.11 
opensurge@0.6.0.3 cl-liballegro@0.2.15-1.49f632c 
ecl-cl-liballegro@0.2.15-1.49f632c minetest-mobs-animal@2021-11-14 
minetest-basic-trains@1.0.1 minetest-unified-inventory@2021-12-26 
minetest-mobs-monster@2022-12-10 minetest-mesecons@1.2.1-63.27c3c51 
minetest-ethereal@1.29-0.7670c1d minetest-worldedit@1.3 
minetest-oneblock@2022-09-01 minetest-coloredwood@2021-04-14-1 
minetest-homedecor-modpack@2022-05-18 minetest-technic@2022-10-30 
minetest-wielded-light@2022-06-24 minetest-throwing-arrows@1.1-0.059cc89 
wasm4@2.5.4 csound@6.16.2 darkice@1.4 cli-visualizer@1.8 volctl@0.9.3 
conky@1.19.6 aws-sdk-cpp@1.9.306 rust-libpulse-binding@2.28.1 
rust-libpulse-simple-sys@1.21.1 rust-libpulse-simple-binding@2.28.1 
rust-libpulse-sys@1.21.0 emacs-pulseaudio-control@0.1-0.34a6114 
ecl-cl-raylib@0.0.1-0.985ceeb cl-raylib@0.0.1-0.985ceeb superstarfighter@0.6.5 
kappanhang@1.3 praat@6.4 gnubg@1.07.001 linsmith@0.99.33 gnome-planner@0.14.6 
ocaml4.07-utop@2.4.3 ocaml4.07-frontc@3.4.2 ocaml4.07-sqlite3@5.0.2 
ocaml4.07-cstruct@5.1.1 ocaml4.07-base64@3.2.0 ocaml4.07-sedlex@2.1 
ocaml4.07-uri@2.2.0 ocaml4.07-batteries@2.10.0 coq-ide@8.16.1 laby@0.7.0 
usync@0-1.09a8059 ocaml5.0-merlin@4.7.1-500 ocaml5.0-eio-main@0.8.1 
emacs-eval-in-repl-ocaml@0.9.7 ocaml-down@0.1.0 ocaml-ocb-stubblr@0.1.1 
ocaml-mirage-bootvar-unix@0.1.0 ocaml-hmap@0.8.1 ocaml-markup@0.8.0 
ocaml-mirage-time@3.0.0 ocaml-psq@0.2.1 ocaml-expect@0.0.6 frama-c@24.0 
ocaml-mirage-logs@1.2.0 ocaml-ssl@0.5.13 ocaml-guile@1.0 ocaml-uring@0.5 
ocaml-merlin@4.7-414 ocaml-sqlite3@5.1.0 ocaml-async@0.15.0 ocamlformat@0.24.1 
ocaml-cohttp@5.0.0 ocaml-mirage-unix@5.0.1 ocaml-mirage-xen@8.0.1 
ocaml-mirage@4.3.3 ocaml-digestif@1.1.3 bap@2.6.0-alpha-0.f995d28 
guile-gnome@2.16.5 aisleriot@3.22.9 python-pycanberra@0.1.1 hexchat@2.16.1 
rawtherapee@5.9 kitty@0.21.2 nerd-dictation-xdotool@0-1.0eb44b7 alure@1.2 
ecl-radiance-contribs@1.0.0-1.710b3e1 

Re: Failed to build in QA

[Reza Housseini]

Hi Christopher

I submitted a new revision to the issue, but the QA link shows

Issue not found
This could mean the issue does not exist, it has no patches or has been 
closed.


do you know what the problem is here?

Thanks for your help,
Best,
Reza

Re: Failed to build in QA

[Christopher Baines]

Reza Housseini  writes:

> Hi Christopher
>
> I submitted a new revision to the issue, but the QA link shows
>
> Issue not found
> This could mean the issue does not exist, it has no patches or has
> been closed.
>
> do you know what the problem is here?

There's two issues, one is the machine running Patchwork is low on disk
space, and that keeps stopping new messages being processed. I've
resolved that for now.

The other issue with the v4 series is that Patchwork has got confused
and only picked out the first of the v4 patches. The threading also
looks weird to me in my email client, but I'm not quite sure why. How
did you send the v4 patches?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Failed to build in QA

[reza.housse...@gmail.com]

>There's two issues, one is the machine running Patchwork is low on disk
>space, and that keeps stopping new messages being processed. I've
>resolved that for now.

Thanks!

>The other issue with the v4 series is that Patchwork has got confused
>and only picked out the first of the v4 patches. The threading also
>looks weird to me in my email client, but I'm not quite sure why. How
>did you send the v4 patches?

I sent them with git send-mail but I also noticed that the order got mixed up 
in issues.guix.gnu.org, no idea how this happened...

Re: Add anchors in HTML documentation

[Christian Miller]

Hi,

> There are anchors for index entries, but you typically need to jump to
> 
> to get the link, or to click on the symbol in a code snippet.

I did not think about that.  This is even better than what I did.

> I agree that anchor symbols in the text would help.  We’d need to tweak
> the Texinfo output and/or use @anchor more frequently in the Texinfo
> source of the manual.

It should do it automatically instead of using @anchor everytime,
since this would be repetitive.  I also saw that Emacs has sometimes
the same problem.  If this affects Texinfo to generate a different
output, we may should move it to the Texinfo ML (do they have one?).
Therefore not only Guix would profit from it.

-- 
Christian Miller

Re: [maintenance] Compressed JSON files and served file extension?

[Simon Tournier]

Hi,

On mar., 28 nov. 2023 at 16:50, Tomas Volf <~@wolfsden.cz> wrote:

> You could invoke the wget with -E flag I guess.

Thanks.  I will try to apply that consistently. :-)


On mar., 28 nov. 2023 at 21:05, Attila Lendvai  wrote:

>(remember: if it's not backwards, it's not
> compatible! :) 

Thanks for explaining. :-)


Cheers,
simon

Feedback (was Re: Meet Guix at Capitole du Libre in Toulouse)

[Simon Tournier]

Hi,

Thanks all people!  It was a very interesting experience for me and a
very good moment.  I hope that we will do again in the near future.

As a record for the next time, let me mention two points that help:

 1. Demos!  It seems very helpful to have both: Guix System and Guix on
foreign distro.  Depending on the people, some are interested by one
or the other.  Mainly, what mark points (main selling arguments ;-))

Guix on foreign distro:

  a) do not interact with foreign distro
  => good complement and rolling release
  b) containerized  shell
  => please developers

Guix System:

  a) roll-back
  b) transactional
  c) roll-back at GRUB level

 2. An explanation about what makes Guix different compared to X

where X is:

i) classical distro as Arch, Gentoo, Debian, etc.
ii) Nix and NixOS

Sadly, we do not have a clear story for ii) IMHO.

Well, from my point of view, the main difference is the continuous*
approach of Guix – the same “language“ from declaring packages or OS
configuration to Guix core; except the daemon, another story. ;-) Well,
that “language” allows to implement a powerful solution as G-expression
tackling, among other things, string interpolation.

It could be nice if we could collectively draft a short FAQ about what
Guix is and Guix is not, answering such common questions.


Cheers,
simon


*continuous approach: The Emacs Thesis :-)
--

The story of Guile is the story of bringing the development experience
of Emacs to the mass of programs on a GNU system.

   Emacs, when it was first created in its GNU form in 1984, was a new
take on the problem of “how to make a program”.  The Emacs thesis is
that it is delightful to create composite programs based on an
orthogonal kernel written in a low-level language together with a
powerful, high-level extension language.

   Extension languages foster extensible programs, programs which adapt
readily to different users and to changing times.  Proof of this can be
seen in Emacs’ current and continued existence, spanning more than a
quarter-century.

   Besides providing for modification of a program by others, extension
languages are good for _intension_ as well.  Programs built in “the
Emacs way” are pleasurable and easy for their authors to flesh out with
the features that they need.

   After the Emacs experience was appreciated more widely, a number of
hackers started to consider how to spread this experience to the rest of
the GNU system.  It was clear that the easiest way to Emacsify a program
would be to embed a shared language implementation into it.

Re: Building and caching old Guix derivations for a faster time machine

[Simon Tournier]

Hi,

On mer., 22 nov. 2023 at 19:27, Ludovic Courtès  wrote:

> For long-term storage though, we could choose to keep lzip only (because
> it compresses better).  Not something we can really do with the current
> ‘guix publish’ setup though.

It looks good to me.  For me, the priority list looks like:

 1. Keep for as longer as we can all the requirements for running Guix
 itself, e.g., “guix time-machine”.  Keep all the dependencies and all
 the outputs of derivations.  At least, for all the ones the build farms
 are already building.

 2. Keep for 3-5 years all the outputs for specific Guix revision, as
 v1.0, v1.1, v1.2, v1.3, v1.4.  And some few others.

Cheers,
simon

Re: guix shell init

[Simon Tournier]

Hi jgart,

On mer., 25 oct. 2023 at 14:12, "jgart"  wrote:

>> Could you explain what “Nix flake” means using Guix terminology?
>
> Here's TLDR list of nix flake features and their guix equivalents
> (maybe):

Thanks for explaining.

If I understand correctly, Guix does not miss some feature from Nix
flakes, right?

If yes, could someone explain what would be such feature?


> There's also some comparison of Guix and Nix flakes here:
>
> https://blog.benoitj.ca/2023-10-23-guix-home-configuration-part1-packages/
> https://blog.benoitj.ca/2023-10-20-how-guix-compare-to-nix-and-vice-versa/

Thanks for the links.

Cheers,
simon

Re: Upgrading Guix's security team

[Simon Tournier]

Hi,

On mer., 22 nov. 2023 at 19:16, Ludovic Courtès  wrote:

> Leo, Tobias, and John: What would be a good end-of-term date for each
> one of you?  As I see it, it wouldn’t mean you cannot do an additional
> term but rather that you’ll have an opportunity to leave and that you’ll
> do your best to be around by then.

I think all this should be encoded in some RFC as proposed in:

Request-For-Comment process: concrete implementation
Simon Tournier 
Tue, 31 Oct 2023 12:14:42 +0100
id:87h6m7yrfh@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-10
https://yhetil.org/guix/87h6m7yrfh@gmail.com

Well, this RFC proposal appears to me a good opportunity for clarifying
the scope. role. end-of-term, etc. about the Security Team.

Cheers,
simon

Re: Failed to build in QA

[Attila Lendvai]

> > The other issue with the v4 series is that Patchwork has got confused
> > and only picked out the first of the v4 patches. The threading also
> > looks weird to me in my email client, but I'm not quite sure why. How
> > did you send the v4 patches?
>
>
> I sent them with git send-mail but I also noticed that the order got
> mixed up in issues.guix.gnu.org, no idea how this happened...


i also see this every once in a while. i guess it's because the SMTP 
server-farm receives mutliple emails in close proximity, and they end up 
reaching debbugs in a different order.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“In matters of conscience, the law of majority has no place.”
— Mahatma Gandhi (1869–1948)

Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)

[Attila Lendvai]

> lines of code. I think hyper-focusing on syntax to make services
> "nicer" might be the wrong approach here: You could greatly reduce the
> complexity by making them procedures instead of syntax and still keep
> most of the configuration readable to a great extent.


i agree. in my experience, it's good practice in general to try to make a 
functional API as convenient as possible, and if that is still too verbose or 
cumbersome, only then add a thin layer of syntactic abstractions that expand to 
code that uses this functional API.

such code is much easier to work with, especially when debugging stuff 
interactively (i.e. it's possible to recompile a function that will then affect 
every place in the code where the macrology is used).

the downside of generating countless macros is that they won't show up in 
backtraces, and they cannot be found when grep'ping the codebase, and as such 
make the codebase much less approachable. the size of their expansion can also 
become an issue if they are used often enough.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“They muddy the water, to make it seem deep.”
— Friedrich Nietzsche (1844–1900)

Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)

[Development of GNU Guix and the GNU System distribution.]

Hi Attila,

On Wed, Nov 29 2023, Attila Lendvai wrote:

> i agree. in my experience, it's good practice in general to try to
> make a functional API as convenient as possible, and if that is still
> too verbose or cumbersome, only then add a thin layer of syntactic
> abstractions that expand to code that uses this functional API.
>
> [...]
>
> the downside of generating countless macros is that they won't show up
> in backtraces, and they cannot be found when grep'ping the codebase,
> and as such make the codebase much less approachable.

Reading your words really helped me feel that I'm not alone. You more or
less summarized my feelings about the Guix codebase, which I have been
reading now for over a year. Guile's syntax features make the code more
symbolic and less approachable to newcomers.

Of course, syntax features are helpful and necessary in some places.

Any large project like GNU Guix, however, must continue to engage a
cadre of skilled maintainers. Between Guile records and syntax features,
code can get hairy pretty fast. Some files seem to have received more
hurried attention recently. In the long run, it's not good for Guix to
make code hard to read.

Please forgive me, everyone, for speaking up. I did not follow the
discussion here at all. Attila's commentary merely resonated with me as
I tried to deal with my own shortcomings in contributing to the Guix
codebase.

Eventually, I hope to make meaningful suggestions to the bootloader
interaction with system profiles, and to the automatic "wrapping" of
executables, which is currently done by hand.

The changes Edouard and Michal may well be very valuable. Please do not
allow my comments to reflect on their well-meant ideas and hard work, or
on any other contributions to the software we love.

Thank you all for contributing to GNU Guix!

Kind regards
Felix