Re: Guix deploy --keep-going equivalent for machine connection failures

[Csepp]

Carlo Zancanaro  writes:

> On Mon, Jan 15 2024, Richard Sent wrote:
>> At present this can be worked around by commenting out entries on the
>> list, but this requires
>> a) Already knowing what machine is offline
>> b) Remembering to uncomment it later when the machine goes back online
>> c) Generally feels “ugly” in a way that most Guix commands don’t.
>> d) Makes version control a pain
>
> This is generally what I’ve done, but I see this as a manual form of
> something that could easily be added the machines.scm file itself.
>
> For instance, you could define a helper function and use it to filter
> the list of machines, like so:
>
>   (define (reachable-host? machine)
> (let ((configuration (machine-configuration machine)))
>   (cond
>((machine-ssh-configuration? configuration)
> (zero? (system* “ssh” (machine-ssh-configuration-host-name 
> configuration)
> “–” “true”)))
>(else
> #f
>
>   (filter
>reachable-host?
>(list
> (machine …)
> (machine …)))
>
> Using this sort of approach can implement whatever strategy you want, as
> long as you can determine the machines which you want to deploy to
> up-front (i.e. this can’t implement a strategy that handles failure
> partway through deployment).
>
> Carlo

One potential problem with this is that it might try to reconnect too often and 
wait too long for each timeout.

Re: rust-team branch merged

[Csepp]

Efraim Flashner  writes:

> The rust team is pleased to announce that the rust-team branch has been
> merged back into master.  There are 570 commits across the branch.
> Cross-compiling support for the cargo-build-system was added, including
> for librsvg.  Cross-compiling was tested for (nearly) all architectures
> supported in `guix build –list-targets`.  Upstream rust added
> ’i686-unknown-hurd-gnu’ as a target in rust-1.74, so that will need to
> wait until another time.  In the meantime, x86_64-w64-mingw32 at least
> compiles correctly and tests well under wine.
>
> Notable notes:
>
> * New rust version is 1.73.
> * 4001 packages use the cargo-build-system
> * Rust crates produced in the ’package’ phase of the cargo-build-system
> should now be reproducible (for real this time)
> * Packages added: eza, kibi, libgit2-1.6, libgit2-1.7, spotifyd, stgit-2
> * Packages updated: alfis, rust-analyzer, rust-cargo-c
> * Rust-analyzer is built from the rust sources now, updating it to 1.73.
> It can be installed as ’rust-analyzer’ or as ’rust:tools’
> * Cross-compiling support for the cargo-build-system was added
>
> Additional notes:
>
> * crates.io no longer accepts ’-’ instead of ’_’ in crate lookups, so
> there are a (probably large) number of packages which need to have their
> source adjusted.
>
> * Compiled rust packages currently have a ’package’ phase, which runs
> the command used to crate a ’crate tarball’, and is installed in
> %output/share/cargo/registry, with unpacked sources in
> %output/share/cargo/src.  In theory it should be possible to use these
> for local rust development.  The benefits include everything that comes
> with being a guix package, including pre-patched shebangs.  Currently no
> index file is created in $GUIX_ENVIRONMENT/share/cargo/registry/index,
> which is likely necessary to actually make use of this.  Additionally, I
> am unsure how to use ’$GUIX_ENVIRONMENT’ in ~/.cargo/config so that it
> is expanded and not taken as a literal string.

Congrats!  That is some excellent news.

Re: guix refresh --update Removes Needed Dependencies

[Csepp]

"jgart"  writes:

> Hi Guixers,
>
> `guix refresh --update` removes Tex Dependencies that are needed. This makes 
> it more tedious to update packages :(
>
> See the diff below which was the result of running:
>
> ./pre-inst-env guix refresh --update python-sphinx
>
> Diff:
>
> [jgart@fedora guix] [env]$ git diff
> diff --git a/gnu/packages/sphinx.scm b/gnu/packages/sphinx.scm
> index eee1f1c4a8..92658a3632 100644
> --- a/gnu/packages/sphinx.scm
> +++ b/gnu/packages/sphinx.scm
> @@ -64,14 +64,14 @@ (define-module (gnu packages sphinx)
>  (define-public python-sphinx
>(package
>  (name "python-sphinx")
> -(version "5.1.1")
> +(version "7.2.6")
>  (source
>   (origin
> (method url-fetch)
> (uri (pypi-uri "Sphinx" version))
> (sha256
>  (base32
> - "12cdy3m5c09lpf2bbxzbhm5v5y9fk7jgm94qrzggpq86waj28cms"
> + "1dasilib5w98hwr5rdnv1ri2dmdxv3fa42dscdcqss4hxbhn0lcs"
>  (build-system python-build-system)
>  (arguments
>   '(#:phases
> @@ -87,57 +87,39 @@ (define-public python-sphinx
> (setenv "HOME" "/tmp")   ;for test_cython
> (invoke "make" "test")))
>  (propagated-inputs
> - (list python-babel
> + (list python-alabaster
> +   python-babel
> +   python-colorama
> +   python-cython
> python-docutils
> -   python-jinja2
> +   python-docutils-stubs
> +   python-filelock
> +   python-flake8
> +   python-flake8-simplify
> +   python-html5lib
> python-imagesize
> python-importlib-metadata
> +   python-isort
> +   python-jinja2
> +   python-mypy
> python-packaging
> python-pygments
> +   python-pytest
> python-requests
> +   python-ruff
> +   python-setuptools
> python-snowballstemmer
> -   python-sphinx-alabaster-theme
> +   python-sphinx-lint
> python-sphinxcontrib-applehelp
> python-sphinxcontrib-devhelp
> python-sphinxcontrib-htmlhelp
> python-sphinxcontrib-jsmath
> python-sphinxcontrib-qthelp
> python-sphinxcontrib-serializinghtml
> -
> -   ;; The Sphinx LaTeX library '\RequirePackage' or \\usepackage
> -   ;; these:
> -   texlive-amsfonts ;amsmath, amssymb, amstext
> -   texlive-amsmath
> -   texlive-capt-of
> -   texlive-carlisle ;remreset
> -   texlive-cmap
> -   texlive-etoolbox
> -   texlive-fancyhdr
> -   texlive-fancyvrb
> -   texlive-float
> -   texlive-fncychap
> -   texlive-framed
> -   texlive-geometry
> -   texlive-hyperref
> -   texlive-kvoptions
> -   texlive-latex-bin
> -   texlive-ltxcmds
> -   texlive-needspace
> -   texlive-oberdiek ;hypcap
> -   texlive-parskip
> -   texlive-preview
> -   texlive-tabulary
> -   texlive-titlesec
> -   texlive-tools;multicol, longtable
> -   texlive-upquote
> -   texlive-varwidth
> -   texlive-wrapfig
> -   texlive-xcolor))
> +   python-sphinxcontrib-websupport
> +   python-types-requests))
>  (native-inputs
> - (list imagemagick  ;for "convert"
> -   python-cython
> -   python-html5lib
> -   python-pytest))
> + (list))
>  (home-page "https://www.sphinx-doc.org;)
>  (synopsis "Python documentation generator")
>  (description "Sphinx is a tool that makes it easy to create documentation

Temporary workaround: you could use git add --patch and not add the
removals.
But yeah, this is an annoying bug.

Re: "random check" approach to Guix QA?

[Csepp]

Andy Tai  writes:

> Hi, currently Guix QA tries to rebuild all dependent packages impacted
> by a change (in majority of cases updates to a new version of a
> package).  When there are a large number of dependent packages like
> say 500 or 1000 or more, rebuilding all that takes a long time and
> often the rebuild cannot complete, leaving the patch submission
> dangling with no results.
>
> For some things where safety is important, for example import food
> safety, the regulatory authority may use random check or random
> sampling as a way to check for safety, in case that there is no
> resource to physically check every package.
>
> Can the same approach be borrowed here, so when there is large number
> of impacted packages from a patch, say larger than 200, Guix QA just
> randomly select a subset sample out of these packages and build them,
> and in case of (new) failures ask the submitter to fix the (new)
> failure? And repeat this as needed.   This way patches can go thru the
> QA process more quickly.

I think it should always do that.  Assign a weight to all derivations
that have to be built and choose from them randomly.
Could use a combination of dependents and estimated build time to comput
the weight.

Re: The e(macs)lephant in the room and the Guix Bang

[Csepp]

Ricardo Wurmus  writes:

> Nathan Dehnel  writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
> return key.
>
> We can add a little toggle button to Guile Studio that does this.

Kinda tangential, but could Emacs be made to just use the system (GTK)
theme?
(In general there are a looot of places where Emacs should just stop
doing its own thing and properly integrate with the system services and
settings.)

Re: The elephant in the room and the Guix Bang.

[Csepp]

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> ...I'm talking about Emacs.
>
> In <87bkdzssgm@gmail.com> [1] Simon Tournier  
> writes:
>
> [1] https://yhetil.org/guix/87bkdzssgm@gmail.com/
>
> [...]
>
>> people are already engaging for improving the accessibility of editors
>> other than Emacs
>
> Simon gave me the opportunity to realize (once again) that IMO there is
> a foundamental misconception regarding Emacs.
>
> What is Emacs, exacly: is it an editor?
>
> I feel that a great deal of friction on the matter is due to the fact
> that Emacs is usually defined as an /editor/ (OK text editor, but it
> makes no difference)... **also** in its official page:
>
>
>  An extensible, customizable, free/libre text editor — and more.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language with extensions to support text editing.
>
> (https://www.gnu.org/software/emacs/)
>
> IMO to define Emacs as a sort of «text editor on steroids with batteries
> included (Emacs Lisp)» does not represent the real nature of the
> program; an /effective/ definition would be:
>
>
>  An extensible, customizable, free/libre user interface.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language, with extensions to use it as an interface to text
>  editing functions and many, many more: MUA, web browser, task
>  organizer...
>
>
> To define Emacs as a /user interface/ it's not just a cool way to
> "market it", it means to classify its /unique/ (?) user interface design
> as one among all the historical instances of user interfaces:
>
>
> 1. batch interface
> 2. command line interface
> 3. SAA User Interface or Text-Based User Interface
> 4. graphical user interface
> 5. (editor note) web user interface
>
> (https://en.wikipedia.org/wiki/User_interface#History)
>
> Someone may consider Emacs "just" a "text-based user interface (UI)"
> (point 3. of the above mentioned list) like the ones using curses and
> alike (e.g. vim, mutt, ranger, Norton Commander and so on) but IMO Emacs
> implements a very different design, centered around a specific UI
> element called "emacs buffer".
>
> I consider Emacs as a 6th class of user interface :-D
>
> Just to bring my limited personal experience: I was a mutt+vim user for
> email management, ranger for file management... and so on, and since I
> was was **very** happy with my vim user experience when editing text,
> for a very long time I looked at Emacs as "just" another text editor I
> didn't need, because **as text editors** both vim, Emacs and alike are
> /very/ powerful and I was never ever interested for just a sec to the
> funny "editor war" (and similar "wars").
>
> Then, one day, moved by curiosity and the fact that the Emacs interface
> is /integrated/ in the notmuch mail indexer I was already using, I
> started using Emacs as my preferred /user interface/ for notmuch... and
> some year later here I am, trying to use the Emacs interface for as much
> computing activities I can.
>
> Now I see Emacs in a very different way.
>
> Incidentally (?), AFAIU Emacs was the Guile IDE (integrated development
> environment, not text editor) used by Ludovic when he started
> programming Guix; he and probably some (many?) of the contributors was
> so happy with their tool that they started sharing their configuration
> snippets, as usual amoung a community of enthusiastic users... after
> many refinements and maybe some Emacs extentions progamming, they was so
> proud that they decided to recommend the same (set of) tool /and/
> configuration to other _collegues_, the famous "perfect setup" described
> in the Guix manual.
>
> I'm also suspecting that the spark that started the "Guix Bang" in
> Ludovic's mind, the very moment he realized nix could be better
> _extended_ using Guile in place of it's DSL, was /caused/ by the fact he
> was a Lisp programmer, the specific /dialect/ probably did not matter.
> But I'm just guessing.
>
> Now I see Guix in a different way. :-)
>
> In this context: is the Guix project biased in recommending using Emacs
> (a Lisp interpreter and compiler for Emacs Lisp) to contributors?  I
> don't think so.
>
> I'd rather say that - as in many other organizations and all similar
> projects - Guix adopts a "BYOT" (bring your own tool) organizational
> policy... and the first contributors brought theirs. :-D
>
> For sure vim/neovim - and other tools - can also be extended and *used*
> to provide /user interface/s for various external tools (e.g. see
> fugitive.vim/nvim-fugitive) that are useful when using and/or developing
> Guix, everyone is free to use and extend them, and also to share with
> the whole Guix community how their beloved BYOT are working well.
>
> Please see a recent message of mine (id:87pm2e4flj@xelera.eu [2])
> for some of my comments (nothing really new, I just reused concept
> already expressed by others) about the process needed to 

Re: WebAssembly target for Guix (Showcase)

[Csepp]

zamfofex  writes:

> Hello, Guix! I have recently worked on a WebAssembly target (for
> cross‐compilation) for Guix. It’s still in very early stages and thus
> fairly lacking, but it is enough to cross‐compile certain simple
> packages such as ‘lolcat’.
>
> Maybe people might find it useful and/or interesting in some way. I
> have shared it here: https://git.sr.ht/~zamfofex/guix-wasm
>
> The WebAssembly changes are applied on top of
> https://issues.guix.gnu.org/63088 (“Add Lc0”) because I had in my
> local Guix clone, and I didn’t bother to rebase.
>
> I’d love to know what y’all might think about it!

Hosting services on WASM would increase security by a lot, so I'm very
excited that someone is working on this.
Also cross-compiling GUIs with Guix would be a nice way to support
developing for browsers.  Qt for instance experimentally supports
compiling for WASM.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hello Csepp, 
>
> Csepp  writes:
>
> [...]
>
>> I don't think repeating that no forge sucks less advances the
>> conversation towards any solution other than keeping the status quo,
>> which can't really be called a solution.
>
> Are we really talking about changing the official Guix forge:
> https://savannah.gnu.org/projects/guix?

I definitely am.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hi Liliana,
>
> Liliana Marie Prikler  writes:
>
> [...]
>
>> For example, whenever people say that "forges would improve stuff", my
>> reply is (modulo phrasing) "yes, for the people who are already used to
>> forges".
>
> I just want to point out that actually Guix _do_have_ a forge. the
> software is Savane and it's hosted on savannah.gnu.org:
> https://savannah.gnu.org/projects/guix
>
> This is just to remind everyone that there are very different forges out
> there, and:
>
>   All forges suck, _no one_ sucks less

To quote the elementary HIG:
"Design is not just, like, your opinion, man"
https://docs.elementary.io/hig/design-philosophy#design-is-not-just-like-your-opinion-man

Just because two alternatives are both imperfect does not mean they are
equally bad.  Statistically speaking, 10 forges having the same
"suckiness" score has an infinitesimal chance.

A more meaningful argument would be that the alternatives have different
goals, but even that's shaky, since most of their goals are shared.
If it takes me 30 minutes to find a commit in a repo on one forge and 5
minutes on another, then one forge is *objectively* worse in *that
aspect*.

I don't think repeating that no forge sucks less advances the
conversation towards any solution other than keeping the status quo,
which can't really be called a solution.

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Csepp]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> On 2023-09-11, Simon Tournier wrote:
>> On Mon, 11 Sep 2023 at 16:23, Ludovic Courtès  wrote:
>>> Note that the patch series adds a hard dependency on Git.
>>> This is because the existing ‘git-fetch’ code depends on Git,
>>> which is itself motivated by the fact that Git supports
>>> shallow clones and libgit2/Guile-Git doesn’t.
> ...
>> Personally, I do not have a strong opinion about the Big Plan™.  I note
>> that the introduction of Git as a hard dependency is a slippery slope
>> considering the current state of libgit2.  Here, it starts with “git
>> clone”, then “git gc” (unsupported by libgit2) is also in the pipes
>> (#65720 [1]).
>
> What about making git an optional dependency, and only calling out to
> "git gc" if git is available in PATH? Maybe possible also with shallow
> clones?
>
> Then you have the best/worst of both worlds! Speaking to the worst, you
> have at least two disparate codepaths for a seemingly similar operation,
> and that might be annoying...
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

For what it's worth, I wrote a small (incomplete) tool for some commit
analysis that used specific --format arguments that were easy to parse.
It's not especially difficult.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 13:05, Giovanni Biscuolo  wrote:
>
>> In other words: you can contribute to a SourceHut hosted project with
>> patches (or just with comments to patches) because everyone can send an
>> email to an email address provided by the project maintainer(s).
>
> Just to point that what to put in the field To: or Cc: is not
> straightforward when contributing to a project hosted on a Sourcehut
> instance, from my experience.
>
> And it does not also appear to me straightforward to fetch past
> discussions.
>
> Cheers,
> simon

There are mbox downloads on lists.sr.ht.
Random example from my browser history:
https://lists.sr.ht/~lioploum/forevercomputer
There is an mbox download for the entire archive and another for the
last 30 days.
Then for a thread there is a "forward this thread to me" and again an
mbox download.
https://lists.sr.ht/~lioploum/forevercomputer/%3CCAGSYXA5kbt9Y3i%3D8UjQp0VNmczCRvcY89ZYyaCyc9VGpsPgyXg%40mail.gmail.com%3E

I think the UI is pretty clear.
I quite like that it makes offline work really easy.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
> [...]
>
>>>> Regarding the GNU changelog commits, I really dislike them. They're
>>>> redundant busy-work as far as I'm concerned. And while I'd like to say
>>>> they're no longer necessary, because we have better tooling
>>>
>>> As said before, I use them all the time through
>>>git log | grep "whatever I am looking for"
>>> or the interactive
>>>git log
>>> then "/" for searching inside the less command; I find it useful to a point
>>> that I have moved to this style for all my coding projects.
>>>
>>> So as far as I am concerned, they are tremendously useful. Well, that may
>>> be due to a lack of git knowledge, of course! But while in other projects
>>> I often find I need to look at the content of commits, in Guix it is often
>>> enough to just look at the changelog.
>>>
>>> Andreas
>>
>> What's wrong with grepping the contents as well?
>
> It's like a 100 times slower, at least on my low spec machine.  It's
> also not as obvious (you search for lines added or removed or changed,
> not easy language such as 'gnu: package-name: Add').

Hmm, that's a quite valid criticism.  I haven't tried grepping commit
contents on my netbook yet, but this suggests that it would be pretty
slow.
But some info is still redundant, like file names.  Git already supports
getting the history of a file, so file names might not be necessary in
the log.
I agree that important identifiers should still be mentioned, but I'm
not sure if the current format is the best way to do that.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Andreas Enge  writes:

> Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU 
> Guix and the GNU System distribution.:
>> >  - strict adherence to changelog style commit messages without a
>> >clearly worded and documented argument about why it's worth the
>> >effort in 2023. whenever 'C' fails to add an entry to the commit
>> >message in Emacs, i groan out loud.
>> Regarding the GNU changelog commits, I really dislike them. They're
>> redundant busy-work as far as I'm concerned. And while I'd like to say
>> they're no longer necessary, because we have better tooling
>
> As said before, I use them all the time through
>git log | grep "whatever I am looking for"
> or the interactive
>git log
> then "/" for searching inside the less command; I find it useful to a point
> that I have moved to this style for all my coding projects.
>
> So as far as I am concerned, they are tremendously useful. Well, that may
> be due to a lack of git knowledge, of course! But while in other projects
> I often find I need to look at the content of commits, in Guix it is often
> enough to just look at the changelog.
>
> Andreas

What's wrong with grepping the contents as well?

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Maxim Cournoyer  writes:

> Hi Ricardo,
>
> Ricardo Wurmus  writes:
>
>> Vagrant Cascadian  writes:
>>
>>> The only thing clunky about this particular aspect of the workflow
>>> described is the fact that the guix community (maintainers?) have
>>> decided on a one patch per mail policy with a cover letter, rather than
>>> submitting the patches as attachments in the initial mail.
>>
>> You are right.  When I started contributing I actually did attach all
>> patches in one email.  I wonder why we stopped doing that.
>
> It's still allowed as far as I know.  But due to missing out on
> notifying team members automatically (handled by 'git send-email') and
> sometimes causing issues for reviewers to apply patches, it's
> understandable that 'git send-email' is the most recommended option.
>
>> I’ll say that many of my gripes with (the GNU instance of) Debbugs are
>> due to the fact that we can’t customize it to better suit our needs — it
>> is a shared resource with a complicated maintenance story.  So all
>> changes went into Mumi as crude workarounds.  I think this is a dead end
>> and we’d be better off leaving the shared GNU instance of Debbugs
>> behind.
>
> I'd be sad to loose at least two good things from Debbugs:
>
> 1. It's hosted by the GNU/FSF for us.  It always work, and the rare
> times it doesn't, the folks in #savannah are hard at work resolving the
> problems. While hosting sourcehut is probably not too difficult, keeping
> it up to date (Go...) and running would be yet another weigh on our
> meager sysadmin team.
>
> 2. Integration with Emacs.  emacs-debbugs is useful.  I think it's the
> only successful thing we have at keeping track of old tickets and
> resuming discussion or acting on these.

Doesn't Magit have a generic forge integration?

> I like how clean Mumi looks, compared to most forge issue trackers.  I'm
> not convinced by its search results (perhaps I'd need to get to know
> what Xapian is).

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Ricardo Wurmus  writes:

> paul  writes:
>
>>> Please go ahead and package the rest of Sourcehut, so we can host it and
>>> finally forget about Mumi and Debbugs.
>>
>> Again, this is not a competition between Sourcehut and Mumi. This is a
>> discussion between adults that care very much about the same
>> philosophical and political points about technological control and
>> autonomy.
>
> You seem to have managed to miss my point.  I emphatically agree that
> there is no competition.
>
> As the original author of Mumi I want it to become obsolete as it
> clearly has outlived its usefulness and better alternatives exist.  The
> way to get there is to add the replacement to Guix so we can host it.
>
> I won’t contribute to Mumi any more.  Giving it up doesn’t hurt my
> feelings.  I’d be glad to see it gone.

I think given the lack of dev resources, it's impressive that Mumi works
as well as it does, but I'm glad that we have some rough-consensus that
something better is needed.  I'll try to pick up the Sourcehut
packaging, now that I know there is a chance it would be accepted.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

wolf  writes:

> [[PGP Signed Part:Undecided]]
> On 2023-09-02 21:08:12 +0200, Csepp wrote:
>> 
>> paul  writes:
>> 
>> > Hello Giovanni,
>> >
>> > I get that you really don't find the web based workflow to bring
>> > enough advantages to justify the migration, but first please
>> > consider the picture that
>> > Katherine sent and that we are evaluating the adequateness of the email 
>> > medium as a FOSS contribution management tool over email. 
>> >
>> > If we lower the bar for contributions more people are gonna be
>> > invested in Guix and will have interest in becoming committer and
>> > reviewer. My
>> > impression today is not that there aren't enough resources to
>> > cover reviews, the bottleneck is the total time that committers
>> > are able to dedicate to
>> > reviewing (potentially re-reviewing if some other non-committer
>> > contributor has already done a first review) and actually
>> > commiting changes.
>> >
>> > I have many contributions opened more than a year ago where
>> > (sometimes also because of me obviously, we're all working after
>> > work here) the
>> > interactions on the issue are separated by many weeks, sometimes even 
>> > months.
>> >
>> > To ease that bottleneck we just need to give more time to
>> > committers or to increase the number of committers. All the
>> > automation and process changes
>> > we evaluate should be focused on either one of this two goals. I
>> > don't have evidence that any web forge will help (maybe someone
>> > has?), but I wouldn't
>> > throw it out of the window just because it does not ease the current 
>> > review process.
>> >
>> > cheers
>> >
>> > giacomo
>> 
>> To second this, I'd like to note for the record that on fedi at least
>> 1-2 people told me that they chose Nix over Guix because they don't want
>> to deal with the email based workflow.  At least one of these people is
>> a highly skilled programmer with decades of experience.
>
> Since we are collecting anecdotal data here, I pretty much stopped 
> contributing
> to Alpine after they stopped using the mailing list.  The friction (for me)
> increased a lot compared to just calling git send-email.
>
> From my circle of acquaintances, all people who picked Nix did it because they
> did not like Guix' purism regarding software freedom and wanted something that
> "gets the job done".
>
> I am skeptical regarding people picking based on web vs. email flows, there 
> are
> more important differences.
>
>> 
>> While I mostly argued for Sourcehut, I think the pull-based alternatives
>> should also be kept in mind.
>> 

The FOSS purism is a bigger deciding factor for sure.  Maybe I'm
conflating things and they said they didn't want to bother
*contributing* to Guix, but I think they also stopped being Guix users.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

paul  writes:

> Hello Giovanni,
>
> I get that you really don't find the web based workflow to bring enough 
> advantages to justify the migration, but first please consider the picture 
> that
> Katherine sent and that we are evaluating the adequateness of the email 
> medium as a FOSS contribution management tool over email. 
>
> If we lower the bar for contributions more people are gonna be invested in 
> Guix and will have interest in becoming committer and reviewer. My
> impression today is not that there aren't enough resources to cover reviews, 
> the bottleneck is the total time that committers are able to dedicate to
> reviewing (potentially re-reviewing if some other non-committer contributor 
> has already done a first review) and actually commiting changes.
>
> I have many contributions opened more than a year ago where (sometimes also 
> because of me obviously, we're all working after work here) the
> interactions on the issue are separated by many weeks, sometimes even months.
>
> To ease that bottleneck we just need to give more time to committers or to 
> increase the number of committers. All the automation and process changes
> we evaluate should be focused on either one of this two goals. I don't have 
> evidence that any web forge will help (maybe someone has?), but I wouldn't
> throw it out of the window just because it does not ease the current review 
> process.
>
> cheers
>
> giacomo

To second this, I'd like to note for the record that on fedi at least
1-2 people told me that they chose Nix over Guix because they don't want
to deal with the email based workflow.  At least one of these people is
a highly skilled programmer with decades of experience.

While I mostly argued for Sourcehut, I think the pull-based alternatives
should also be kept in mind.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hello Katherine,
>
> thank you for having summarized (part of) this thread in a list of
> actionable tasks
>
> now Someone™ have the chance to decrease the cognitive overhead for
> contributors by _increasing_ her cognitive overhead to sort out and
> complete each task
>
> as a general comment, it seems to me that you put very much attention to
> the process of contributing v1 of a patch but you underestimate the
> cognitive overhead of the collective patch reviewing process and
> committing to Guix proper process
>
> AFAIU, observing what is happening in Guix since 2019, what is actually
> critical for Guix is _not_ the cognitive overhead needed to send a patch
> to guix-devel, but what comes after and _around_.
>
> last but not least, to be fair we should see at what other distribution
> (not single software projects) are doing for their contributing process:
> I know a little about Debian and in my experience it's far easier to
> contribute to Guix than to Debian (but I know little, I emphasize)
>
> Katherine Cox-Buday  writes:
>
>> Summary of my conclusions:
>>
>> 1. We should use sourcehut or continue to improve mumi
>
> Please forgive me if I insist, but the one and _only_ benefit of using
> SourceHut is the web-UI /helper/ to prepare an email message to send,
> it's "just" a web-UI version of the "git format-patch" CLI; the rest of
> the "patch management workflow" is email **and** CLI (git am) based;
> it's documented.
>
> Furthermore, users that are comfortable with the SourceHut web UI are
> free to use that as their personal working repo, there is no need for
> Guix to use a SourceHut remote as the official one.

How easy related issues are to find matters a great deal.  So does TODO
management.
Mumi currently fails at its main function of being a search engine for
issues.  I can't even find my own messages with keyword searches,
because for some reason Mumi connects each words with a logical or and
doesn't rank search results based on how many hits there are, not to
mention handling fuzzy hits, or synonyms, etc.

As I see it, this is an issue of developer resources.  Mumi and Debbugs
have no chance of catching up to any alterntive that already has a
sustainable financial model and professional developers working on it.

Why are we trying to compete with Sourcehut?  What's the end goal?

Re: collection of “guix pull“ bug reports

[Csepp]

Simon Tournier  writes:

> Hi Maxim,
>
> On Sat, 26 Aug 2023 at 22:34, Maxim Cournoyer  
> wrote:
>
>>> https://issues.guix.gnu.org/issue/62830
>>> https://issues.guix.gnu.org/issue/63451
>>> https://issues.guix.gnu.org/issue/63830
>>> https://issues.guix.gnu.org/issue/64489
>>> https://issues.guix.gnu.org/issue/64659
>>> https://issues.guix.gnu.org/issue/64753
>>> https://issues.guix.gnu.org/issue/64963
>
> [...]
>
>>> Any idea about what could be unexpected or what needs some love?
>>
>> I haven't checked the above links, but I think something that would help
>> in this regard is better handling of network issues.  E.g, don't print a
>> backtrace on the first connection failure; retry maybe 3 times then
>> print a helpful error mentioning the network appears unreliable.
>
> IMHO, this collection raises two questions:
>
>   1. Why does it happen?  To say it explicitly, I am almost sure that
>   something is not smoothly working as expected on server side.  For
>   instance, I had ‘guix pull’ troubles with a machine and I am doubtful
>   that this machine has network issue (this machine is using the fast
>   network link of my Univ. employer :-))
>
>   2. What could be done on client side for reducing the annoyance?  I
>   agree that substitute failures should be better handled.  For example,
>   retry 3 times then display an error message.  Etc.
>
>
> Cheers,
> simon
>
> PS: About #2, please give a look at these annoyances:
>
>   + Issue 1 and 2: Options --fallabck and --no-substitutes
>   + Issue 3: Non consistent message for substitutes and/or fallback
>
> from .

There also needs to be an option to just retry forever IMHO.  On my
netbook it is very costly to re-run guix pull's non-substitutable parts
so I'd rather Guix just kept trying in case of network errors.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Giovanni Biscuolo  writes:

> ...
>> What are the blockers in Guix's policies for moving in this direction?
>
> Guix is a GNU project, GNU have an infrastructure, a set of services and
> a policy for their projects.  Maybe one day GNU will provide a self
> hosted SourceHut service, now GNU have https://savannah.gnu.org/ and
> https://debbugs.gnu.org/
>
> ...and please remember: "all forges and all issue trackers suck, some
> just sucks less" (stolen from mutt motto)

I hope GNU is not so inflexible that it won't support Guix if it
switches to a better maintained forge.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
> [...]
>
>> but as soon as something breaks, you are thrown into the deep end,
>> having to dissect logs, bisect commit ranges, learn strace, gdb (which
>> still doesn't work well on Guix)
>
> Hm?  Why GDB on Guix may be sometimes more challenging than say, on
> Fedora, I only know of one problem, that is related to grafts (see: #48907).
>
> For running binaries wrapped in shell script, I have this 'run-gdb'
> wrapper which reads:
>
> --8<---cut here---start->8---
> #!/usr/bin/env bash
>
> wrapper=$(cat $(which $1))
> shift
> . <(echo "$wrapper" | grep ^export)
> binary=$(echo "$wrapper" | grep ^exec | grep -o -E '/gnu/store[^"]*')
> gdb --args "$binary" "$@"
> --8<---cut here---end--->8---
>
> Hope that helps,

Thanks, it does somewhat, but this is the kind of thing that should be
either packaged in Guix, documented in the cookbook, or preferably fixed
upstream.
At the very least I try to document these helper Guix-specific helper
scripts on the mailing list.  I've asked where it would be appropriate
to put them (cookbook, package, guix module, etc) but I don't think I
got a response.
This is exactly what I mean by core devs having their own scripts that
others don't have an easy way to find and/or access.

The other problem is the difficulty of accessing debug symbols.
One problem is the need to recompile the package you need symbols for,
the other is loading external symbols.  The first is a CI issue as far
as I know: all the debug outputs would take up too much space
(probably).  This may not be fixable in the short term without
additional funding.  The second is purely technical though.
Maybe someone fixed it since the last time I tried to use GDB, but if
not, it should be a priority IMHO.  Guix packages often have bugs and we
should do everything in our power to make fixing future problems easier,
otherwise the project risks the death of a thousand cuts.
This is why I chose to work on Mirage, to get a better understanding of
the importer and cross-compilation tooling.

questionable advice about Geiser load path setting

[Csepp]

The docs contain this recommended Emacs setting:

@lisp
;; @r{Assuming the Guix checkout is in ~/src/guix.}
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))
@end lisp

I haven't been using it for a while because I remember it causing
trouble whenever I was working on other Guile projects.  I have been
running Emacs inside ./pre-inst-env instead, which seems to work just as
well, if not better.

I'd like to make an amendment to the relevant docs, but would welcome
some info on why it was originally written this way, maybe there are use
cases I'm missing.

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Katherine Cox-Buday  writes:

> Summary: for people who don't contribute to Guix a lot, each
> contribution has
> very high cognitive overhead. Can we work to reduce that?
>
> Hey all,
>
> Contributing to Guix is currently pretty difficult for me. I'm a Mom with a
> full-time job, and anything outside of my job that requires a lot of
> executive
> functioning (e.g. lots of manual, detailed, steps) is very difficult
> for me to
> get correct. That last part is what I wanted to discuss, because
> that's the part
> that prevents me from contributing more than I do, and I think there are
> probably others whom are impacted by this.
>
> When I have some time to contribute, I usually stall out at the
> "submit this for
> review" because of the amount of cognitive overhead required. I've written a
> script for myself that tries to perform all the steps including
> running the git
> command to submit the patch, and this has helped me, but that this is
> necessary
> for me to do might be something that, if addressed, could help others.
>
> Here are some examples of things that cause issues for me. This is not
> a list of
> grievances; it's my way of attempting to demonstrate the "shape" of
> the issue:
>
>     I signed up on Savannah with the intention of applying to be a
> committer.
>     Savannah closed my account one or two days later due to inactivity.
>
>     I can't ever seem to get the GNU style commit messages correct. I
> use the
>     templates provided, but those don't cover all cases, and I've even
> gotten
>     feedback in a review to change a message it created.
>
>     I don't use the email-based patch workflow day-to-day, so this is
> another
>     area where I spend a lot of time trying to make sure I'm doing things
>     correctly.
>
>     My script runs `guix style` and `guix lint`, but its suggestions aren't
>     always correct. I suspect I've submitted some patches with nonsensical
>     changes due to implicitly trusting these tools.
>
>     Maybe
> https://lists.gnu.org/archive/html/guile-devel/2023-02/msg00030.html
>     addresses this, but manually managing Guile imports is laborious. As a
>     fledgling schemer, I often forget which imports I needed just for
>     development.

This definitely falls into the IDE tooling issue that I complained about
a bunch of times.  There seems to be a reality distortion field around
Lisp that makes some users believe that s-expressions automatically lead
to a good IDE experience.  And yet, Java IDEs have had automatic import
management for at least 15 years (around the time I first used Eclipse),
but Guile still doesn't have anything of the sort.
It looks like the only way to move forward is for people to share these
helper scripts they've been using and forging them into a consistent
developer environment, maybe based on Guile Studio.  Hopefully I can
make some contributions towards such a project.

> I think I would summarize the core of these examples as:
>
>     "At every step of the contribution process, I must manually check that
>     multiple things are correct. With limited available executive
> functioning,
>     and no automation, this is very difficult to do correctly, and an
> easy place
>     for contributors to stop."
>
> I think that if I were working on Guix more frequently, I would build
> habits I
> didn't have to think about, and these wouldn't be the large issues they are
> for me. But because of the nature of a project like Guix, we want
> contributions
> from people of all kinds of backgrounds, not just people who have the
> privilege
> to work on Guix a lot.
>
> I have given a list of issues to a group of people who are presumably
> analytical, and I think the natural inclination is to go
> point-by-point and make
> arguments for/against. Instead of that[*], I invite you to address the more
> abstract issue: (should/how do) we reduce friction for making contributions?
>
> Here are some things I've considered:
>
> * Contributing to Guix is not for you
>
>     I would be really sad if someone ever said this, but I guess it's a
>     possibility. Maybe someone like me just can't be a contributor to
> Guix until
>     I have the bandwidth to manage all the details. I would
> preemptively argue
>     that diversity of thought and experiences usually leads to better
> things.

I really hope we can lower the barrier to entry without sacrificing code
quality precisely because of this.  Lots of important use cases that
Guix could serve are ignored because the people who need them are not
represented in our community and/or they can't contribute and no one is
able/willing to write code for them.

> * It's OK to make lots of mistakes
>
>     The people who have reviewed my code have been generous both with
> their time
>     and fixing my mistakes and then applying. Maybe this model is OK?
> I still
>     feel guilty every time a reviewer has to correct an oversight I've
> made. I
>     also want to become a committer, but I don't 

Re: Reusing code for a build-phase?

[Csepp]

Hartmut Goebel  writes:

> Am 06.08.23 um 14:49 schrieb Csepp:
>> Maybe you could create a build system that inherits from the one these
>> packages use, but adds the extra phase.
>
> I was thinking about this, too. But this seems to be too much, as
> there are not hundreds of Vagrant plugins. Also a build-system
> requires documentation, wich is another pile of work.

There already are special purpose build systems, like the Minetest one.
I think you can just define it locally in the module and document it
with a comment, you don't necessarily have to make a module for it.
Alternatively you could write a function that modifies a package to add
the necessary phase.

I'm glad you brough this up, because I should test these ideas on my
MirageOS branch.  FWIW I think I'll go with the build system solution.

Re: Reusing code for a build-phase?

[Csepp]

Hartmut Goebel  writes:

> Hi,
>
> I'm currently packaging vagrant and some plugins. For all plugins an 
> additional phase is required, generating a json file, see below. Since this 
> is quite
> some code, I'd like to put it into some definition or some wrapper. Since it 
> uses (this-package-verion), my attempts failed.
>
> At best, a plugin would then be defined like
>
>   (define-public vagrant-abc (vagrant-plugin-wrapper (package …
>
> Anyhow I'd be happy to when being able to use some function in the phase 
> instead of duplicating the code.
>
> Any ideas? Many thanks in advance
>
> (arguments
>  (list
>   #:tests? #f ; tests involve running vagrant and downloading a box
>   #:phases
>   #~(modify-phases %standard-phases
>   (add-after 'install 'install-plugin.json
> (lambda _
>   (let* ((plugins.d (string-append
>  #$output "/share/vagrant-plugins/plugins.d"))
>  (plugin.json (string-append
>plugins.d "/" #$name ".json")))
> (mkdir-p plugins.d)
> #$(with-extensions (list guile-json-4)
> #~(begin
> (use-modules (json))
> (call-with-output-file plugin.json
>   (lambda (port)
> (scm->json
>  '((#$name
> .
> (("ruby_version"
>   . #$(package-version (this-package-input 
> "ruby")))
>  ("vagrant_version"
>   . #$(package-version (this-package-input 
> "vagrant")))
>  ("gem_version" .  "")
>  ("require" . "")
>  ("sources" . #()
>  port)))

Maybe you could create a build system that inherits from the one these
packages use, but adds the extra phase.

Re: Kdump

[Csepp]

Christina O'Donnell  writes:

> Hi guix and guixesses,
>
> I'm still enjoying my guix machine crashing every other week despite changing 
> all the software and half the hardware. So I'm trying to get kdump
> working so I can get to the real reason behind it. However I see that 
> kdump-tools haven't been packaged yet. I see this as an opportunity for me to
> contribute to Guix, but it'll be my first time.
>
> - How interested would people be in me packaging kdump and related tools?

More debugging tools (and docs!) are always welcome IMHO.

> - Is there a reason why it's not there already?
>
> - Has it been tried before?

Searching the mailing lists doesn't turn up much, so I assume no one has
tried it:
https://yhetil.org/guix/?q=kdump

> The scope seems to be around 3-4 packages and a system service. Does that 
> sound about right or could there be more I'm missing?
>
> On Debian there's:
>
> crash/testing,now 8.0.2-1 amd64 [installed,automatic]
>   kernel debugging utility, allowing gdb like syntax
>
> kdump-tools/testing,now 1:1.8.1 amd64 [installed]
>   scripts and tools for automating kdump (Linux crash dumps)
>
> libkdumpfile-dev/testing 0.5.1-1 amd64
>   libkdumpfile development libraries and header files
>
> libkdumpfile-doc/testing,testing 0.5.1-1 all
>   Kernel coredump file access (documentation)
>
> libkdumpfile10/testing 0.5.1-1 amd64
>   Kernel coredump file access
>
> python3-libkdumpfile/testing 0.5.1-1 amd64
>   Python bindings for libkdumpfile
>
> I'd want to package all of these except the python bindings. I see that 
> kexec-tools is already in guix which is good!
>
> Is this a sensible direction?
>
> Kind regards,
>  - Christina

I'd say go for it!  If they are mostly written in C then you probably
don't have to package a lot of transitive dependencies.  Looking in
gnu/packages/linux.scm could be a good starting point for packaging
kernel related tools.

Re: A Forum for Guix Users

[Csepp]

Ahmed Khanzada  writes:

> I like this forum idea.
>
> In fact, I really think a forum / presence for GNU more generally would
> be excellent.
>
> Yes, you can find dedicated spaces for Emacs, Guix, etc, and there is
> #gnu on Libera and some mailing lists.
>
> But I think we are sorely missing a central point where users can go and
> see how they might use Guix, Emacs, etc in conjunction. As well as join
> a community centered on GNU as an OS.
>
> I document using Guix, Emacs, exwm and etc together on various
> proprietary online spaces like GitHub, Medium, and Reddit. This is
> because there is good foot traffic in these spaces. Both old and new
> hackers are present in these spaces. But their proprietary nature is
> unfortunate. It would be more ideal to document how to use GNU on an
> official GNU platform.
>
> As of right now, if you approach the GNU community, it just feels like a
> disconnected set of packages. I spend a lot of time explaining to people
> how GNU is a unique libre operating system which you can extend using
> Lisp. I show them examples of how I have a "fullstack" Lisp workstation
> with Guix, Emacs, and exwm. After seeing such an example, the concept of
> GNU really "clicks" for them.
>
> I make my living deploying and monitoring applications on servers, so
> let me know if I can help setup a social GNU presence.

I'm not sure if focusing so much on GNU is a good idea.

Re: A Forum for Guix Users

[Csepp]

Pjotr Prins  writes:

> On Fri, Jul 14, 2023 at 02:10:49PM -0700, Felix Lechner via Development of 
> GNU Guix and the GNU System distribution. wrote:
...
>> 1. Our community is small, and possibly shrinking.
>
> I doubt that is true in absolute terms. You should see where we were
> 10 years ago :). Guile and Racket made impressive gains the last
> years.
>
> In relative terms we can't compete and should not aim
> to do so with either Guix or Guile.
>
>> 2. Scheme is a niche language that is not being promoted enough.
>
> Lisp will always be niche. Why would it change in half a century? The
> power of Lisp comes from its syntax - but it is a barrier to entry at
> the same time. I am always amazed they came up with that early in CS
> history.

Like I've mentioned on fedi before, advocates of Lispy languages tend to
talk a lot about what's *possible* with the language, but the truth is
that the actual tooling that matters simply isn't very good, and having
an S-expression based syntax doesn't magically make writing the kinds of
refactoring tools that Java developers have been enjoying for 10+ years
significantly easier.
For that we need good *static analysis*, and unbounded dynamism and too
much syntax magic makes that *more* difficult.
At the very least I want to be able to rename variables across the whole
project and jump to definitions reliably.

Before trying to convince me otherwise in replies, please go and try
Eclipse, or even JetBrains if you have access to it (I think it has an
open source version??), just so you know what you are up against as a
free software advocate trying to convince developers to use Scheme.
I was set out to hate JetBrains when I had to use it in uni this
semester, but I was pleasantly surprised by how easy it was to use.
I'm not saying this to advertise Java tools, I'm saying this to snap
Lispers out of the reality distortion bubble some of them seem to be
stuck in.

TLDR: instead of looking for excuses for why no one gets Lisp, we should
be actually addressing the complaints.  Then maybe people will start
getting Lisp.

ps.: As far as I can tell, the Lisps with good IDEs are image based, not
source based, that's why they have an easier time doing metaprogramming,
because the runtime helps a lot.  But an image based system is not
exactly in line with Guix's goal of reproducibility.

Re: Add hare compiler

[Csepp]

Ekaitz Zarraga  writes:

> Hi
>
> I made a possible package for the Hare compiler:
> https://harelang.org/installation/
>
> But I'm not sure how we should handle a couple of things.
>
> The dependencies are propagated while maybe we should mention which are the 
> inputs and set them to be called from the store directly, should we?
> And also the way they manage to make the configuration for the compiler 
> driver is adding a config.mk file ourselves. I decided to ignore it and add 
> the config as environment variables in order to simplify the process but I'm 
> not sure if you find any other way that fits better with our needs.
>
> Also the language is kind of a beta and they don't have a release schedule 
> yet. Are we ok packaging software in that status?
>
> Thanks,
> Ekaitz

Doesn't sound any worse than Idris or Vlang and we have packages for
both. :shrug:
(Also that seL4 microkernel project the Hare folkx are building is cool,
I wonder if Guix could run on it. :3)

Re: A Forum for Guix Users

[Csepp]

Robby Zambito  writes:

> Hi Sarthak,
>
>> As of now, it's a bit difficult for beginners to find answers to their 
>> problems in the mailing list or in IRC logs as they aren't very
>> easy to navigate compared to forum threads.
>
> I personally think that it would be wiser to improve the documentation
> relating to the mailing lists and IRC logs, rather than fragmenting the
> places that someone should look for answers. Maybe a new / additional
> frontend that is more approachable for new users would also be good.

Sourcehut has full-time employees working on making these accessible, so
it really boggles my mind why we aren't using that instead of Savannah
and Debbugs.
We could also bridge IRC to Matrix (even though the company behind it
has some people who... let's say like the taste of leather too much).
Pine64 has a great chat setup actually, their channels are bridged to a
whole bunch of services.  Not saying we must also bridge with Discord,
but at least the libre options should be considered.

> I have never found myself participating in distro-specific forums; I
> have always used them as read-only sources of information. Yet here I am
> participating in the Guix mailing lists :). I bet I am not alone in this
> experience.
>
> Also FWIW, Guix was basically my introduction to participating in
> mailing lists. So I wouldn't say I am biased in my old ways of doing
> things - I just genuinely think it's a good way to handle communication.
>
> Robby

Guix is also the first project I contributed to in a major way over
mailing lists and my experience is that if you don't keep up to date
with the list, the lackluster search and linking will be a major pain in
the buttocks.  It is usable for experts, but is absolutely not
beginner-friendly.
But even experts would benefit from a better workflow.

Re: guidelines for package names (namespaces?)

[Csepp]

John Kehayias  writes:

> Hi Andy,
>
> On Mon, Jul 03, 2023 at 01:55 PM, Andy Tai wrote:
>
>> Hi, in Guix there seems no guidelines for package  names/namespaces
>> although there are conventions like Python packages prefixed with
>> python-...  (good).  However, this does not cover cases like Gnome
>> applications. For example, I submitted the original definition for
>> (the GNOME terminal package) terminator, and later I tried to rename
>> that gnome-terminator but that was rejected by reviewers.
>>
>
> This is a good question and one I wonder about when packaging
> sometimes. The general guideline I've seen expressed in Python land at
> least (not sure if this is in the manual, but this discussion can go
> towards clarifying) is that generally "libraries" get the "python-"
> prefix but end user "applications" don't. I believe this is true for
> Golang as well, though exceptions abound.
>
> The line is not necessarily clear. As an example, the "autokey"
> package is written in Python and I would guess almost always used as
> an application as is, but you can script with autokey itself as well.
>
>> Or GNU Guix maintainers may want to consider some type of name space
>> support in the package name space because I think name collisions will
>> be more and more likely as more packages are submitted for inclusion
>> in Guix.
>
> I don't have any insight or knowledge on the internals here but the
> general practice of a language prefix for libraries and the like has
> so far worked well I think.
>
> John

One problem: sometimes a package can be used both as a library and as a
command, which means that when you try to import something that depends
on it and you didn't follow the naming convention for libraries, Guix
will try to import it again.  I've ran into this with Yggdrasil.

But this might be a missing feature of importers and not a naming issue.

Re: modifying (rather than fully replacing) a build phases

[Csepp]

John Kehayias  writes:

> My question remains, but I've updated the patch in question to use
> #:make-flags (thanks to mirai for the idea), separating out these
> parameters from the build command and making this a much easier
> change.
>
> Still, we have examples of just copying some phase by hand to make
> adjustments, is there anything better we can/should do?
>
> On Tue, Jun 27, 2023 at 12:29 PM, John Kehayias wrote:
>
>> Hi Guixers,
>>
>> A question that is either relatively simple or else getting into the
>> weeds a bit, that I came across in my proposed patch
>>  The general question is: how can I
>> modify a build phase without replacing it completely? More
>> specifically (as seen in the proposed patch) there is a build phase
>> consisting of just an "apply invoke" call where I want to remove one
>> of the arguments given. Is there a simple way to do this rather than
>> just manually copying and deleting that string?
>>
>> I would assume so, but I wasn't sure how to do it and couldn't quite
>> grep any examples. Some light exploring in the guix repl shows me that
>> package-arguments is a keyword list (not sure the proper terminology
>> in Guile) with #:phases a big gexp. Essentially I want to modify that
>> to remove a string. I suppose it is a question of manipulating a gexp
>> directly. (I'm sure macros can do all this but there doesn't seem to
>> be a need for that at this level, right?)
>>
>> Thanks in advance!
>> John

I think I've used assoc-ref to find the build phase I wanted and then
called it from something else.  It's not super pretty, but it works.

Re: Maybe a way to get a few more developpers to work on Guix ?

[Csepp]

Nicolas Graves  writes:

> On 2023-06-24 13:08, Csepp wrote:
>
>> Nicolas Graves via "Development of GNU Guix and the GNU System 
>> distribution."  writes:
>>
>>> https://www.bpifrance.fr/nos-appels-a-projets-concours/appel-a-projets-communs-numeriques-pour-lintelligence-artificielle-generative
>>>
>>> Here's a call for proposal in French which could match a Guix project
>>> with a focus on code generation through LLMs. This could itself help
>>> Guix generate (and fix) package definitions.
>>
>> Mandatory reading for anyone interested in this:
>> https://limited.systems/articles/climate-cost-of-ai-revolution/
>
> I fully agree on that as well. I don't think training a full-fetched LLM
> is nowhere worth it, but I've heard that just fine-tuning an open model
> with quantized weights might get the job done training and energy costs
> down to a few hundred bucks.

>From the "Key points" section right at beginning of the linked article:
"Training of large AI models is not the problem"
"Large-scale use of large AI models would be unsustainable"

It's not the cost in money that I care about, it's the cost in
emissions, which is not included in the few hundred bucks.
(ie.: it's an externality)

However, using other machine learning models that can actually run
efficiently might make sense.
But really, what we need for package availability is more support code
in the form of better importers and updaters, better testing, better
coverage, more accessible workflows - the email workflow could certainly
be improved by *a lot* - better bug tracking, and so on.

There are also very well founded concerns about the quality of the code
that LLMs produce.

Re: Maybe a way to get a few more developpers to work on Guix ?

[Csepp]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> On 2023-06-24, Nicolas Graves via "Development of GNU Guix and the GNU System 
> distribution." wrote:
>> On 2023-06-24 13:08, Csepp wrote:
>>> Nicolas Graves via "Development of GNU Guix and the GNU System 
>>> distribution."  writes:
>>> IMHO LLMs for Guix are so damn not worth the effort.  It will not fix
>>> any of the actual issues with Guix, like the huge performance gap
>>> between it and traditional package managers.
>>
>> I've also opened another discussion on the subject on guix-devel
>> recently. Do you have any benchmark material to back this up?
>
> Well, I just ran "apt update" on Debian, and it took approximately 7
> seconds, which was mostly spent downloading moderately sized files from
> Debian mirrors (~1MB).
>
> A corresponding "guix pull" took 299 seconds, downloading at least 8MB
> (from a quick eyeball calculation as guix does not summarize the results
> for me), and compiling all the various guix-*.drv that make up guix
> pull. The vast majority of the time was spent compiling
> derivations. This was also using a local copy of guix.git, so having to
> update guix.git over the network would take even longer... (and it did
> even spend a fair amount of time copying from the local guix.git on a
> fast NVMe device)
>
> Obviously, guix pull is doing a lot more, but it is ... doing a lot
> more!
>
> "apt install hello" (~2.3 seconds) and "guix install hello" (~1.5
> seconds) were actually in a similar ballpark, which honestly surprised
> me. Guix is much faster with "guix remove hello" ... although arguably
> "guix remove hello && guix gc --delete $(guix build hello)" would be a
> more similar operation, and although I did not time it, it was
> reasonably fast, too.
>
> So, presuming substitutes are available, the main slowness with guix
> seems to be guix pull?

NVMe (or even an SSD) helps a lot.  And I suspect your system also has a
good amount of RAM for IO caching and at least 4 modern 64 bit cores.
Try running guix pull on a 32 bit machine with 1 GB of RAM and an HDD
with LUKS for storage (and a lot of swap), you'll see a wy wider
performance gap.
Even simple operations like guix edit take much longer than they should.
Yes, Guix does more, but a lot of what it does could be sped up.

Re: Update on Parameterized Packages

[Csepp]

Sarthak Shah  writes:

> Hello guix-devel!
>
> I got a bunch of really helpful suggestions from the last thread about my 
> Google Summer of Code project on bringing Package Parameterization to
> Guix. 
> I've incorporated a lot of those suggestions and tried to address some of the 
> worries as I've been working on the project.
>
> Here is a new post covering the work that I've done in the past few weeks:
> https://blog.lispy.tech/parameterized-packages-an-update.html
> I would appreciate any questions, suggestions or comments!
>
> Cheers,
> Sarthak.

Looks very promising!

Re: Maybe a way to get a few more developpers to work on Guix ?

[Csepp]

Nicolas Graves via "Development of GNU Guix and the GNU System distribution." 
 writes:

> https://www.bpifrance.fr/nos-appels-a-projets-concours/appel-a-projets-communs-numeriques-pour-lintelligence-artificielle-generative
>
> Here's a call for proposal in French which could match a Guix project
> with a focus on code generation through LLMs. This could itself help
> Guix generate (and fix) package definitions.

Mandatory reading for anyone interested in this:
https://limited.systems/articles/climate-cost-of-ai-revolution/

IMHO LLMs for Guix are so damn not worth the effort.  It will not fix
any of the actual issues with Guix, like the huge performance gap
between it and traditional package managers.
But then again, wasteful software is the hot new trend thanks to AI and
crptocurrencies, so what do I know. :)

Re: distributed substitutes: file slicing

[Csepp]

Csepp  writes:

> I have a question / suggestion about the distributed substitutes
> project: would downloads be split into uniformly sized chunks or could
> the sizes vary?
> Specifically, in an extreme case where an update introduced a single
> extra byte at the beginning of a file, would that result in completely
> new chunks?
>
> An alternative I've been thinking about is this:
> find the store references in a file and split it along these references,
> optionally apply further chunking to the non-reference blobs.
>
> It's probably best to do this at the NAR level??
>
> Storing reference offsets is already something that we should be doing to
> speed other operations up, so this could tie in nicely with that.

I was sent this link that others might find interesting:
https://alternativebit.fr/posts/nixos/future-of-nix-substitution/

distributed substitutes: file slicing

[Csepp]

I have a question / suggestion about the distributed substitutes
project: would downloads be split into uniformly sized chunks or could
the sizes vary?
Specifically, in an extreme case where an update introduced a single
extra byte at the beginning of a file, would that result in completely
new chunks?

An alternative I've been thinking about is this:
find the store references in a file and split it along these references,
optionally apply further chunking to the non-reference blobs.

It's probably best to do this at the NAR level??

Storing reference offsets is already something that we should be doing to
speed other operations up, so this could tie in nicely with that.

Re: Guix / Nix Benchmarks

[Csepp]

kiasoc5  writes:

> On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the
> GNU System distribution. wrote:
>> One of the criticism that can be read online about Guix (compared to
>> Nix) is its speed. I have never tried Nix and probably won't in a near
>> future, but I was wondering if some work has been made to compare them
>> on basic tasks (package installation, removal...) (the reason why I ask
>> is to be able to give an honest answer to someone hesitating between
>> both).
>> 
>
> At least package installation is faster with Nix. One reason is that
> Hydra (their "substitute server") has faster download speeds compared
> to CI/Bordeaux, likely due to multiple geographical locations/mirrors.

Conversely, Nix itself is likely to be slower than Guile.  I remember
search being so memory intensive with Nix that it got OOM killed even
with 4 GB of RAM, although they may have fixed that since.

FOSS tooling grant that Guix devs might be interested in

[Csepp]

https://sovereigntechfund.de/en/challenges/

"Grants go up to €300,000 per application and cover three main topics: 
1. Improve FOSS Developer Tooling
2. Securing FOSS Software Production
3. FOSS Infrastructure Documentation

With this program the Sovereign Tech Fund seeks to stimulate an open
digital infrastructure: fundamental technologies that enable the
creation of other software."

Re: Faster “guix search” (was Re: How many bytes do we add (closure of guix) when adding one new package?)

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Tue, 30 May 2023 at 21:10, Csepp  wrote:
>
>>  It makes zero sense to load full package definitions from
>> disk for most queries, such as guix search, with an SoA representation
>> we could load only the fields that we care about.
>
> That’s already the case; see
> ~/.config/guix/current/lib/guix/package.cache.
>
> For instance, “guix package -A” exploits it and the performances are
> acceptable.  Two past summers, wow already! I tried to augment it and
> exploit it for “guix search”.  The implementation and benchmark is in
> #39258 [1].  Well, the whole thread of #39258 appears to me worth to
> consider because it spots various bottleneck specific to “guix search”
> and explains why the improvement is not straightforward.

That's a good improvement, but it's in addition to the ELF files, so it
doesn't save any space, and as far as I know it doesn't speed up
non-textual queries, like searching for packages that use a specific
build system.

> Well, I have started months ago to write a Guix extension using
> guile-xapian.  My aim is to tackle two annoyances: 1. the speed and
> 2. the relevance.
>
> About the relevance #2, the issue is that the current scoring considers
> only the local information of one package without considering the global
> information of all the others.  Well, see [2,3,4] for some details. :-)
>
> 1: https://issues.guix.gnu.org/39258#119
> 2: 
> https://yhetil.org/guix/CAJ3okZ3E3bhZ5pROZS68wEKdKOcZ8SpXsvdi-bnB=9jz3mp...@mail.gmail.com
> 3: 
> https://yhetil.org/guix/CAJ3okZ3+hn0nJP98OhnZYLWJvhLGpdTUK+jB0hoM5JArQxO=z...@mail.gmail.com
> 4: 
> https://yhetil.org/guix/caj3okz0lajzwdba7bjqzew_jamtt1rj9pjhevwrtbia_cox...@mail.gmail.com

Thanks for the links, gonna read them in more detail later.

>> ps.: Now I'm even more glad that I'm using a file system with
>> transparent compression on all my Guix systems.
>
> Did you benchmarked the performances for some Guix operations on these
> compressed vs uncompressed file system?

I haven't, but I have recently tried to move to a larger drive and
accidentally did a btrfs send without compression and the system didn't
fit.

Re: How many bytes do we add (closure of guix) when adding one new package?

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On ven., 26 mai 2023 at 18:21, Ludovic Courtès  wrote:
>
>> I agree that .go files are quite big (.scm files as well, but we’ve
>> improved information density somewhat by removing input labels :-)).
>>
>> The size of .go files went down when we switch to the baseline compiler
>> (aka. -O1):
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00071.html
>>
>> That thread has ideas of things to do to further reduce .go size.
>
> Just to put a figure on what means “big”: currently the .go files are 5
> times bigger than their associated .scm.
>
> Somehow, it’s the trap of DSL. :-) Packages are declarative and the
> information they declare is not dense.  However, because they are
> bytecompiled to a general programming language, their specificity is not
> exploited.  In an ideal world, the compiled binary representation of the
> packages should be smaller than their human-readable text-file
> counterpart.
>
> The mentioned improvement is nice.  And it’s visible:
>
> --8<---cut here---start->8---
> 145M 
> /gnu/store/nqrb3g4l59wd74w8mr9v0b992bj2sd1w-guix-d62c9b267-modules/lib/guile/3.0/site-ccache/gnu
> 117M 
> /gnu/store/s6rqlhqr750k44ynkqqj5mwjj2cs2yln-guix-a09968565-modules/lib/guile/3.0/site-ccache/gnu
> 127M 
> /gnu/store/ndii4bpyzh2rc05ya61s89rig9hdrl4k-guix-a0178d34f-modules/lib/guile/3.0/site-ccache/gnu
> 164M 
> /gnu/store/ni63a203jf61dwxlv8kr9b8x3vb1pdsp-guix-8e2f32cee-modules/lib/guile/3.0/site-ccache/gnu
> --8<---cut here---end--->8---
>
> However, it has almost no impact on the whole size; scaled by the number
> of packages.
>
>> Download size has to be treated separately though.  For example, ‘git
>> pull’ doesn’t redownload all of the repo or directory, and it uses
>> compression heavily.  Thus, a few hundred bytes of additional .scm text
>> translate in less than that.
>>
>> As for the rest, download size can be reduced for example by choosing a
>> content-address transport, like something based on ERIS.
>>
>> I think we must look precisely at what we want to optimize—on-disk size,
>> or bandwidth requirement, in particular—and look at the whole solution
>> space.
>
> I think one direction is to tackle the way *package-modules* is built.
> Because of that, Guix is building too much and the design is not optimal
> – whatever technical solutions we implement for improving after that.
>
> On my poor laptop, Guix is becoming unusable because many operations are
> becoming so slow – when it’s still acceptable with APT of Debian.  For
> instance, it’s something like 20 minutes for running “guix pull” without
> substitutes.  And when I am traveling without a fast Internet
> connection, it’s often too much for the network at hand.
>
> Currently, “guix pull” is either building too much and downloading too
> much; by design.
>
>
> Cheers,
> simon

Something I've been considering is if Guix could make use of database
optimizations on its packages.  Having access to Scheme for everything
is nice, but using it as a storage solution is kind of silly when we are
mostly just storing structs.  Some kind of struct-of-arrays optimization
could definitely reduce their size by a lot, might even speed up some
operations.  It makes zero sense to load full package definitions from
disk for most queries, such as guix search, with an SoA representation
we could load only the fields that we care about.

ps.: Now I'm even more glad that I'm using a file system with
transparent compression on all my Guix systems.

Re: How Can We Make G-Expressions Even More Interactive At The REPL?

[Csepp]

"("  writes:

> "jgart"  writes:
>> Hi Guixers,
>>
>> How can we make g-expressions even more interactive at the REPL?
>>
>> For example, thing to explore is what can we print instead of 
>> '(*approximate*)?
>
> It's physically impossible to print anything other than a placeholder
> there without actually building any derivations, which is the thing
> GEXP->APPROXIMATE-SEXP is supposed to /avoid/ :)
>
>> WDYT if we had even more convenience meta-commands for interactive 
>> development with g-expressions?
>
> You'd need to give some concrete examples; what can't you do now that
> you think could be a good REPL command?
>
>   -- (

I would very much welcome if the REPL commands (like ,build) were actual
first class functions, because right now it's quite a hassle to write
Guile scripts that depend on the output of a build.
Motivation: I'm trying to hack together a helper script that detects
generated OPAM dependency lists. 

Re: Understanding a Golang importer error

[Csepp]

Felix Lechner via "Development of GNU Guix and the GNU System distribution." 
 writes:

> Hi,
>
> The command
>
>   guix import go -r github.com/google/certificate-transparency-go
>
> produces the output below. Which repo is missing the v0.41.1 tag,
> please? Thanks!
>
> Kind regards
> Felix
>
> * * *
>
> Backtrace:
> In srfi/srfi-1.scm:
>586:29 19 (map1 _)
>586:29 18 (map1 _)
>586:29 17 (map1 _)
>586:29 16 (map1 _)
>586:29 15 (map1 _)
>586:29 14 (map1 _)
>586:17 13 (map1 (("go.opentelemetry.io/contrib/instrumentat…" …) …))
> In guix/import/utils.scm:
>630:33 12 (lookup-node "go.opentelemetry.io/contrib/instrumentat…" …)
> In guix/memoization.scm:
>  98:0 11 (mproc "go.opentelemetry.io/contrib/instrumentation/go…" …)
> In unknown file:
>   10 (_ # …)
> In guix/import/go.scm:
>685:10  9 (_ _ #:version _ #:repo _)
> In ice-9/exceptions.scm:
>406:15  8 (go-module->guix-package* . _)
> In ice-9/boot-9.scm:
>   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/import/go.scm:
>511:19  6 (go-module->guix-package "go.opentelemetry.io/contrib/…" …)
> In guix/git.scm:
> 291:4  5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …)
>277:19  4 (resolve _)
> In git/reference.scm:
>  60:8  3 (_ _ _)
> In git/bindings.scm:
>  77:2  2 (raise-git-error _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1683:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1683:16: In procedure raise-exception:
> Git error: reference 'refs/tags/v0.41.1' not found

Try re-running the commands with COLUMNS=0, I thiiink that's the magic
incantation to un-break the logs.
And for the record this is why I think truncating lines in Guile traces
is a very terrible idea.  It usually hides a lot of important info and
makes it necessary to re-run expensive computations for no reason.

Re: bug#55358: docker containers stopped when doing guix install or guix shell

[Csepp]

Remco van 't Veer  writes:

> Hi Maxim and Zimoun,
>
> 2023/02/09 13:26, Remco van 't Veer:
>
>> I think I know what is causing the issue.  Both the "standard" mysql and
>> postgres containers use user-id 999 to run the database service (this
>> seems like a common practice because the redis container is configured
>> similarly).  That user-id is also configured as guixbuilder01 so I guess
>> the guix daemon is killing those when processes when it finishes doing
>> builds.
>
> I found a solution / workaround for this problem by using
> "userns-remap".  This feature allows the remapping of uids and guids to
> different ranges.  I tried it by hacking the required files into my
> etc-directory and it works; guix no long kills my database containers.
>
> I'd like to add this feature to docker-service-type having a new
> configuration option named enable-userns-remap? which introduces a new
> user and group (both named dockremap) to do the remapping by adding some
> configurable number to the uids and guids of the running container.  In
> /etc/subuid and /etc/subgid it would look like:
>
>   dockremap:10:65536
>
> See https://docs.docker.com/engine/security/userns-remap/ for
> documentation about this.
>
> WDYT?
>
> Cheers,
> Remco

The rootless podman example that was shared a few months ago could be
relevant to this, since that also adds a subuid/subgid mapping.

Re: Order of manifest and overlapping binaries

[Csepp]

Greg Hogan  writes:

> I could not find documentation on this circumstance or how to resolve.
> Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> can go in the $GUIX_PROFILE.
>
> Creating a container, the latter package overshadows the former
> package, as below. Unclear if this is consistent. In my manifest the
> former package overshadows the latter (I'd prefer to have parallel's
> parallel, but by default I have sorted the listing alphabetically). Is
> there a better way to fix this?
>
> Greg
>
> --8<---cut here---start->8---
> $ guix shell --container moreutils parallel which coreutils
> [env]$ readlink -f `which parallel`
> /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
>
> guix shell --container parallel moreutils which coreutils
> [env]$ readlink -f $(which parallel)
> /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> --8<---cut here---end--->8---
>
>
> This is operating from a recent guix pull:
>
> --8<---cut here---start->8---
> $ guix describe
> Generation 44   May 11 2023 17:02:53(current)
>   guix d6f6b57
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> --8<---cut here---end--->8---

You could create a package that just copies the contents of moreutils
to $output, but renames some files, then include the resulting package
in your manifest.  If moreutils is not propagated from any other
package, then you don't even have to do an input rewrite.

Re: Fwd: Writing an Accessible Guix ISO

[Csepp]

Hunter Jozwiak  writes:

> Howdy,
>
> Here is a project I am interested in getting into Guix in some fashion, 
> copied from my email I sent to help-guix a while back. Any mentorship
> and/or help pointers would be appreciated, and I appologize for the double 
> posting.
>
> -- Forwarded message -
> From: Hunter Jozwiak 
> Date: Sun, May 7, 2023 at 3:50 AM
> Subject: Writing an Accessible Guix ISO
> To: 
>
> Greetings, 
>
> I have been hacking for quite some time now on the Guix installer, trying to 
> get it to run with the espeakup screenreader which I have the
> module and package for in Guix already.

Hi!
Glad to see someone working on this!  I've been meaning to try my hands
at it, but having to mess close to the boot process again was
intimidating, so I kept putting it off.
I can't promise much coding help, but I'd be glad to test it out.

Re: Discussion on Parameterized Packages

[Csepp]

Sarthak Shah  writes:

> 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

A hardening flag would be very welcome, I think Guix definitely needs to
be much more serious about this if we want it to be used widely for
hosting internet facing services.
NixOS already has hardening by deafult as far as I know.

Also I think a lot of flags you mentioned would be better expressed as
outputs, both to avoid combinatorial explosion for testing, and so
people don't have to re-build everything.  Or at least they should be
implemented with outputs underneath.

I think Alpine solve this very well, they split packages up by
functionality, and also make it very easy to install certain subpackages
of all packages by just installing a virtual package, like "doc".

The idea of using flags to reduce package sizes is good, but let's not
do it at the expense of CPU hours.

TLDR: we should avoid big recompiles when changing flags.

Re: Deploying experimental versions of Guix

[Csepp]

david larsson  writes:

> 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

You could also use that file with guix time-machine for one off tests.

Re: Imagemagick with OpenEXR support

[Csepp]

Théo Maxime Tyburn  writes:

> Csepp  writes:
>
>> Théo Maxime Tyburn  writes:
>>
>>> ```
>>> checking for OpenEXR >= 1.0.6... no
>>> [...]
>>> Delegate library configuration:
>>> OpenEXR   --with-openexr=yes  no
>>> ```
>>
>> If we are going by semver, then 1.0.6 is incompatible with 3.x.  Maybe
>> it expects an older version?
>
> Hum. But it seems to look for a version that is greater or equal
> 1.0.6. Shouldn't 3.x be matched ? Maybe I misunderstand semver.
> You mean 3.x could have incompatibilities so that is what is is not
> matched ?

A major version bump is supposed to mean a backwards incompatible
change, so depending on how the greater-than operator works, 1.x might
not be "smaller" than 3.x.  It's not a total ordering, I think it's a...
semilattice?  Or something along those lines.

Re: i686 core-updates failure.

[Csepp]

Andreas Enge  writes:

> Am Thu, Apr 13, 2023 at 01:23:15PM + schrieb jgart:
>> My thoughts on this are that unless someone has the time to maintain
>> those broken packages we should just remove them and clean up shop a
>> bit.
>> Is there a reason to keep around the broken packages?
>
> Well, we can certainly remove a few hopeless, outdated, non-maintained
> broken packages. But if we start to remove packages such as wget, and
> Java, and Haskell, and much of R, and big chunks of Python, for i686,
> this amounts to removing the architecture altogether. It is a decision
> we may want to take at some point in time, but we should not do so casually.
> And definitely not in this core-updates merge.
>
> One argument for keeping i686 was that problems there were often indicative
> of problems in "more exotic" architectures, whereas i686 is relatively easy
> to build on x86_64 without specific (often slow) hardware. I am not sure
> if this still holds for the 32 bit problems we have seen recently; so there
> is a certain argument to make for removing the 32 bit architectures i686
> and armhf (x86_64 will soon celebrate its 25th birthday, aarch64 is half
> as old; I do not expect much hardware for the corresponding 32 bit
> architectures to be around any more).
>
> Andreas

That is a pretty terrible direction to take.  There are still plenty of
people who rely on old hardware who can't afford to buy new machines.
When discussing these issues, it is important to keep in mind that the
people who have enough spare time to contribute to this project and hang
out on the mailing lists come from a rather privileged background.  What
you think is reasonable to categorize as obsolete might be the only
machine a poor family could afford on the second hand market.
If Linux distros keep dropping support for old hardware, then they are
not liberatory, no matter how "free" their licenses are.

We are also in the middle of a massive climate crisis, so we should aim
to prolong the usefulness of existing hardware and not give in to this
planned obsolescence BS.

Re: Imagemagick with OpenEXR support

[Csepp]

Théo Maxime Tyburn  writes:

> Hi guixers,
>
> I am trying to add OpenEXR to the current Imagemagick.
>
> I tried this out
>
> ```
> (package
>   (inherit imagemagick)
>   (inputs (append `(("openexr" ,openexr)) (package-inputs imagemagick
> ```
>
> but in the configure phase:
> ```
> checking for OpenEXR >= 1.0.6... no
> [...]
> Delegate library configuration:
> OpenEXR   --with-openexr=yes  no
> ```
>
> I'm not sure why OpenEXR is not visible at configure time. There doesn't
> seem to be any manual addition of references to include or lib
> directories from the store in the current imagemagick package
> definition. So I assume it should just work fine.
>
> Any idea?
>
> Théo

If we are going by semver, then 1.0.6 is incompatible with 3.x.  Maybe
it expects an older version?

Re: OCaml (was Re: Graphical login broken on core-updates)

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On mer., 12 avril 2023 at 17:39, Simon Tournier  
> wrote:
>
>> Well, OCaml is not in good shape.  The update of grep breaks
>> ocaml-ppxlib-0.25.1 and so many OCaml packages.
>
> Fixed by v2 of .
>
> The only still broken packages is ocaml-uring which is not blocking for
> the merge, IMHO.
>
> Cheers,
> simon

I'm pretty sure I added uring for Mirage stuff, which no one uses yet
except me, so yeah, not blocking.
Although I'm not looking forward to fixing it on my next rebase.

Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)

[Csepp]

Nathan Dehnel  writes:

>  a) Bit-identical re-train of ML models is similar to #2; other said
> that bit-identical re-training of ML model weights does not protect
> much against biased training.  The only protection against biased
> training is by human expertise.
>
> Yeah, I didn't mean to give the impression that I thought
> bit-reproducibility was the silver bullet for AI backdoors with that
> analogy. I guess my argument is this: if they release the training
> info, either 1) it does not produce the bias/backdoor of the trained
> model, so there's no problem, or 2) it does, in which case an expert
> will be able to look at it and go "wait, that's not right", and will
> raise an alarm, and it will go public. The expert does not need to be
> affiliated with guix, but guix will eventually hear about it. Similar
> to how a normal security vulnerability works.
>
>  b) The resources (human, financial, hardware, etc.) for re-training is,
> for most of the cases, not affordable.  Not because it would be
> difficult or because the task is complex, this is covered by the
> point a), no it is because the requirements in term of resources is
> just to high.
>
> Maybe distributed substitutes could change that equation?

Probably not, it would require distributed *builds*.  Right now Guix
can't even use distcc, so it definitely can't use remote GPUs.

Re: Hello GUIX

[Csepp]

Shivam Madlani  writes:

> Thanks a lot for the feedback!!
>
>>  Reading from a disk maybe should happen automagically if it can be
>>  detected (and is enabled in some configuration). This might also
>>  require some integration with udisks. The complexity of this should
>>  not be underestimated.
>
> We can set it up in such a way that on running `guix install {xyz}` it will 
> first check for mounted drives in /media
> directory and install {xyz} if it's present in the drive. 
>
>> Writing packages to a USB stick seems to be closer to a `guix
>>  publish` or `guix deploy`. Maybe you can read up on those commands
>>  and think of a nice way to publish or deploy a set of packages to a
>>  USB stick. This is also relevant for publishing to other p2p
>>  networks (IPFS, GNUnet, etc.).
>
> Perhaps, We can introduce a new utility? (maybe something like `guix sneak`). 
> This will scan for external drives
> and on detecting a drive it will encode and store the nars into it.
> The size of the drive can cause an issue here in case the content to be 
> encoded is very large. In this case an
> appropriate error message will be displayed. Although this is rare as flash 
> drives/hard drives have a lot of storage
> capacity these days but it's still a thing to consider.
>
> Another way would be to use `guix publish` itself to do all of this. We can 
> introduce a flag `--sneak` which instead
> of spawning an HTTP server, encodes and stored into the drive. But i don't 
> think we should modify an already
> existing utility for this. I would like to hear your thoughts on this.

The NNCP utility might be worth taking a look at.  There is a way to set
it up alongside udev to automatically transfer files from connected USB
storage.

Re: The  Shepherd gets a service collection

[Csepp]

Adam Faiz  writes:

> On 3/16/23 22:14, Ludovic Courtès wrote:
>> The main limitation of mcron for such thing is that it’s entirely
>> static: it reads a list of job specs upfront and then goes on to
>> schedule them.  There’s no communication protocol to talk to it and
>> add/remove jobs on the fly, which is what ‘at’ would need.
> Would it be easier to add dynamic job spec support to mcron than adding a new 
> command scheduler?

Adding timers to Shepherd means Shepherd services can depend on timers
and vice-versa.

But maybe Shepherd could still reuse mcron code internally.

>>> Regarding syslogd, I think a better approach is to tell the services to 
>>> send their output to stdout and stderror,
>>> so that logs don't depend on a separate logging service in the first place.
>> Yes, but:
>>1. Some daemons include syslog support even today, sometimes
>> optional,
>>   sometimes mandatory.
>>2. Syslog is a bit more structured than just stdout/stderr
>> output:
>>   there are facilities and levels, for instance—see syslog(3);
>>   syslogd provides interesting filtering capabilities.
>>
> Thanks, it looks like syslog is still important for structured logs.
>
> Are there issues of logs sent to syslog being lost even when the syslogd 
> service is specified as a requirement of services that use it?
> If not, I think it's not necessary to add a syslogd implementation to the 
> shepherd.
>  >> Per-service logging is already implemented in the Shepherd, but
>could be streamlined to have a default logs directory:
>>> https://skarnet.org/software/s6/s6-log.html#loggingchain
>> Interesting read, thanks!
>> Regarding the default logs directory, there’s /var/log already, or
>> did
>> you mean something else?
> I do mean /var/log, I felt like #:log-file in make-forkexec-constructor could 
> be improved.
> Rather than always having to specify the absolute log file path,
> #:log-file could just be set as #t and would then default to
> /var/log/$canonical-name of the service.

That is problematic on flash storage and read-only storage.
Syslog has the advantage of working very nicely in memory only.
Also the structure is very nice, you get to see every event on the
system in a chronological order.  You don't get that with log files.
Honestly /var/log should be redirectable to syslog.

Re: Fwd: [gnu-soc] GNU Guix Project: Decentralized substitute distribution

[Csepp]

Shivam Madlani  writes:

> -- Forwarded message -
> From: Shivam Madlani 
> Date: Fri, 3 Mar 2023 at 12:42
> Subject: [gnu-soc] GNU Guix Project: Decentralized substitute distribution
> To: 
>
> Hello all,
> My name is Shivam Madlani aiming for GSoC'23, and I am particularly
> interested in The Guix project. I took a look at the project idea and
> installed a fresh version of Guix on a VM and started playing around in it.
> I have a few questions regarding the project which I think you guys can
> help me with:
>
> 1) The project title states "decentralized"... which i don't get. How
> exactly is it decentralized? Similar to a P2P file sharing tech or
> something else (BitTorrent)?
> 2) As per the project idea I interpreted that the technologies involved
> would be c/c++, shell and a bit of networking. Is this correct or am I
> missing something?
> 3) What would be the duration of the project? (175hrs/350hrs).
>
> Thank you all and I hope to hear from you soon. :)
>
> Regards

Moving this to guix-devel, since this is more a development focused
question, not a user support one.

See this issue for some related code:
https://issues.guix.gnu.org/52555

As for languages, you would definitely need to write Guile Scheme on the
Guix side, but it would probably make use of libraries written in other
languages, which would likely include C and C++, but also quite possibly
Rust and Go, since a lot of newer decentralized file distribution
protocols have implementations written in them.

As for other details, I CC'd Pukkamustard, who will be the mentor for
this project if I'm not mistaken, and should be able to fill in the
blanks.

ps.: Personally I'd really love to see NDN based substitutes, but NDN is
not even packaged in Guix yet, so my guess is that at first it's best if
you added support for something that already works on Guix System, like
IPFS.

Re: Oniro or Guix on Zephyr kernel?

[Csepp]

Peter Polidoro  writes:

> I just stumbled across Oniro[1], the Eclipse Foundation's new
> operating system.
>
> It seems that its main goal is to be able to run a common operating
> system on multiple embedded kernels, either the Linux kernel for
> larger devices or the Zephyr kernel for smaller ones.
>
> Since Guix System can run on both the Linux kernel and the Hurd
> kernel, could it, in theory, also run on the Zephyr kernel?
>
> Could Guix System be an alternative to the Oniro project or is there
> something about Guix System which would make it unsuitable for
> embedded devices on an RTOS kernel?
>
> Footnotes:
> [1]
> https://blogs.eclipse.org/post/mike-milinkovich/introducing-oniro-vendor-neutral-open-source-os-next-gen-devices

This doesn't quite answer your question but it's worth noting:
You can use Guix as a build system to compile to any kernel with a Linux
based cross compile toolchain.

I'm currently working on using it to compile MirageOS unikernels.

Reading about the kinds of devices Oniro and OpenHarmony supports, it
seems unlikely that you could run the Guix build system on the lower end
of the spectrum.  Guix already barely copes with lower end ARM and older
i386 devices.  It needs at least 1GB of RAM and plenty of storage,
preferably flash based.

If your device meets those requirements then there is not much reason to
run an embedded OS and if it doesn't then your only chance is cross
compiling to it.

There is actually quite a bit to be gained from using Guix to cross
compile to embedded devices or unikernels, but a lot more work is needed
IMHO.  Help with cross-toolchains is I think always welcome. UwU

Re: Estimated overhead of building an orthogonal Musl-based LFS within Guix build system

[Csepp]

vtkq2fq...@liamekaens.com writes:

> Hi,
>
> I'm wondering what the overall estimated work or effort might look
> like to leverage Guix to build a co-existing family of packages that
> are in some sense "orthogonal" to the rest of Guix, based upon
> different package versions and perhaps musl libc - similar to
> https://github.com/dslm4515/CMLFS for example.
>
> Could a series of such packages be built up in the same way that these
> LFS type builds bootstrap themselves? For example, starting with the
> most primitive dependencies and going on upward.
>
> For this to work, different package versions for the same kind of
> package would need to coexist - which I don't believe is inherently a
> problem. But also, these builds would need to refer exclusively to
> paths and prefixes that are wholly self-contained and orthogonal to
> the rest of Guix.
>
> The overall aim here is to consider building some select packages for
> example with musl libc, or perhaps building a "stable track" of
> software that is unaffected by the rest of Guix evolving packages.
>
> The measurement of effort can be subjective. Perhaps it involves
> modifying existing recipes and adapting these to point to different
> packages/versions. Maybe there is a similar precedent somewhere.
>
> Any thoughts are appreciated.

I would love to see this but similar ideas have already come up (eg.:
BSD port) and the response from core contributors (based on experience
with Nix) was that maintaining multiple libc's is not worth the effort.

I would definitely want a more Alpine-y Guix though.

Re: Licence of the Guix blog posts

[Csepp]

Csepp  writes:

> I thought I agreed when I sent my part, but in case I haven't:
> I agree to licensing your contribution under CC-BY-SA 4.0 and GFDL
> version 1.3 or later, with no Invariant Sections, no Front-Cover Texts,
> and no Back-Cover Texts.

s/your/mine/

I copied the text from the email I was sent and apparently didn't edit
it properly.

Re: Licence of the Guix blog posts

[Csepp]

I thought I agreed when I sent my part, but in case I haven't:
I agree to licensing your contribution under CC-BY-SA 4.0 and GFDL
version 1.3 or later, with no Invariant Sections, no Front-Cover Texts,
and no Back-Cover Texts.

Re: Guix Games Collection

[Csepp]

Tobias Platen  writes:

> I had submitted a talk for LibrePlanet called "Gaming on a Talos II -
> how I avoid using Steam". Unfortunately, there were so many high
> quality talks that it was impossible to fit them all in the program.
> So I will do a lightning  talk [1], about my work in progress Guix
> Games Collection, a list of games that are playable on a freedom
> respecting machine such as the Talos II or Thinkpad X200 (with
> Libreboot) on the Guix System. I also plan to make a haunt page with
> screenshots/videos for each game, similar to the Steam storepages. 
>
> [1]:
> https://libreplanet.org/wiki/LibrePlanet:Conference/2023/Lightning_Talks

I guess we'll find out from the talk anyways, but I'm curious:
do you only play games on it that are fully free (including assets,
missions, etc) or are games where only the code is libre also allowed.
Thinking of examples like Kandria, Quadrilateral Cowboy, etc, which have
GPL codebases but you still need to buy the game to get the assets.

Re: CLI flag to ignore guix channel

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On jeu., 03 nov. 2022 at 21:51, jgart  wrote:
>
>> I'd like a CLI flag to be able to ignore channels.
>>
>> Where should I look if I'd like to implement something like this?
>>
>> I prefer not to edit and comment out channels in ~/.config/guix/channels.scm
>>
>> I'd prefer to do the following
>>
>> guix import crate behemoth-rust-package-foo -r --ignore-channel=guixrus
>
> Well, this would be nice but we have nothing in this direction.
>
> From my point of view, the best is to have several channels.scm files
> where some or other channels are defined.  Then, you switch using “guix
> time-machine”, for example:
>
> guix time-machine -C path/to/channels-wo-guixrus.scm \
>  -- import crate behemoth-rust-package-foo -r
>
> HTH,
> simon

How fast is that?  If new commits come in during time-machine
invocations, won't it keep doing new builds of guix?

Re: etc/commiter.scm should not commit

[Csepp]

Ekaitz Zarraga  writes:

> --- Original Message ---
> On Tuesday, January 24th, 2023 at 2:50 AM, Csepp  wrote:
>
>
>> There have been countless times when I was using etc/commiter.scm and it
>> commited more than it should have and then slapped an incorrect message
>> on it.
>> I think it would make a lot more sense if adding changes was left up to
>> the human at the keyboard (at least by default) and the script was
>> invoked only when editing the commit message.
>
> That could be done on a git hook but developers would need to configure it.

It does not need to be a hook, it can be done by setting EDITOR or
VISUAL, or commiter.scm can even retain its current interface and just
internally git add everything and call the script that would decide the
message based on the staged diff.

etc/commiter.scm should not commit

[Csepp]

There have been countless times when I was using etc/commiter.scm and it
commited more than it should have and then slapped an incorrect message
on it.
I think it would make a lot more sense if adding changes was left up to
the human at the keyboard (at least by default) and the script was
invoked only when editing the commit message.

Re: Packages grow, no longer fit on a 

[Csepp]

Akib Azmain Turja  writes:

> [[PGP Signed Part:Undecided]]
> Paul Jewell via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
>> Evening all,
>>
>> On 14/01/2023 23:07, Ludovic Courtès wrote:
>>> Hello!
>>> Over the course of a few years, the size of our packages has
>>> apparently
>>> kept growing.  Example:
>>> --8<---cut here---start->8---
>>> $ guix time-machine --commit=v1.2.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
>>> 139.3  16.2%
>>> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
>>> 131.3  15.3%
>>> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
>>> 106.2  12.4%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>>> 53.2   6.2%
>>> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
>>> 49.0   5.7%
>>> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
>>> 38.1   4.4%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>>> 36.7   4.3%
>>> […]
>>> total: 859.7 MiB
>>> $ guix time-machine --commit=v1.3.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
>>> 148.6  16.9%
>>> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
>>> 141.6  16.1%
>>> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
>>> 106.4  12.1%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>>> 53.2   6.0%
>>> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
>>> 49.1   5.6%
>>> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
>>> 38.1   4.3%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>>> 36.7   4.2%
>>> […]
>>> total: 880.5 MiB
>>> $ guix time-machine --commit=v1.4.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
>>> 250.6  15.7%
>>> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
>>> 169.6  10.6%
>>> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
>>> 149.5   9.4%
>>> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
>>> 128.5   8.1%
>>> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
>>> 65.4   4.1%
>>> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
>>> 58.6   3.7%
>>> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
>>> 54.4   3.4%
>>> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
>>> 52.0   3.3%
>>> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
>>> 48.6   3.1%
>>> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
>>> 219.139.1   2.5%
>>> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
>>> 38.0   2.4%
>>> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
>>> 36.6   2.3%
>>> […]
>>> total: 1592.7 MiB
>>> --8<---cut here---end--->8---
>>> I think something went wrong here.  :-)
>>> In particular with Emacs itself (due to JIT + dependency on
>>> libgccjit,
>>> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>>> And then MESA and LLVM have always been problematically big.
>>> We should do better.  I mean, it’s just a text editor, isn’t it?
>>> Ludo’.
>>> 
>>
>> Please forgive my ignorance if I have missed anything but:
>>
>> - does anyone actually install from a CD these days?
>
> I don't know, but I'd just use a pendrive if I need an external storage.
> (If I don't need, I'd just use a 2 GB HDD partition, which I made just
> for very purpose.  ;)  )
>
>> - Can an ISO be bigger than a CD then be installed on a memory stick?
>
> Yes.
>
>>
>> It strikes me that this is like King Canute holding back the
>> tide. Package size growth is pretty inevitable, and even if work now
>> can bring the size down to that of a CD, the same problem will occur
>> in the not too distant future.
>>
>
> But we should really try to keep them low.
>
>> Is it really a problem?
>
> YES!
>
> Big packages means, it takes more space.  If a package grows by 700 MB,
> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
> could use that precious storage to save your dad's photo, your favorite
> music, your child's video calling you "daddy/mummy" for the first time,
> etc.  You would need to get more storage for that storing those
> invaluable things, so you would need more storage 

Re: IDEA: Give Our Generations a Name

[Csepp]

Liliana Marie Prikler  writes:

> Am Dienstag, dem 17.01.2023 um 01:52 + schrieb Csepp:
>> 
>> "jgart"  writes:
>> 
>> > Hi Guixers,
>> > 
>> > What do you think if we would be able to give past generations a
>> > name?
>> > 
>> > I'm thinking of the way you can do the following with git:
>> > 
>> > git stash -m "My description of this important stash."
>> > 
>> > I think this would help differentiate slight differences that would
>> > be hard to tell what the state of that generation was by just
>> > looking at the differences of profile package content.
>> > 
>> > to bloat? or not to bloat? that is the question
>> 
>> Since generations are just symlinks to profiles in the store and a
>> profile can be in multiple generations, this would require wrapping
>> the profile with some additional metadata.  I guess it's technically
>> as simple as adding a "dummy" package that just contains the name in
>> a file in output/etc/generation-name.txt or something, that would get
>> unioned into the profile, and then it's a simple matter of outputting
>> that info in --list-generations.
>> Right?
> I actually have a better idea.  Note how each generation has the name
> ${common-identifier}-$generation-link.  You could thus simply store a
> tag by using ${common-identifier}-$tag and simply pointing that at the
> right link.  Downside is, that you're limited to the "standard"
> alphanumeric + dash character set, plus the first character shouldn't
> be a number, but I'd say this is good enough for most practical
> purposes.
>
> Cheers

Hmm, yup, much simpler.
Although for system generations it doesn't help much, but that could be
handled by setting the name in the OS record.

Re: IDEA: Give Our Generations a Name

[Csepp]

"jgart"  writes:

> Hi Guixers,
>
> What do you think if we would be able to give past generations a name?
>
> I'm thinking of the way you can do the following with git:
>
> git stash -m "My description of this important stash."
>
> I think this would help differentiate slight differences that would be
> hard to tell what the state of that generation was by just looking at
> the differences of profile package content.
>
> to bloat? or not to bloat? that is the question

Since generations are just symlinks to profiles in the store and a
profile can be in multiple generations, this would require wrapping the
profile with some additional metadata.  I guess it's technically as
simple as adding a "dummy" package that just contains the name in a file
in output/etc/generation-name.txt or something, that would get unioned
into the profile, and then it's a simple matter of outputting that info
in --list-generations.
Right?
I would actually like this for system profiles quite a lot.  When you're
working on something like a new file-system or service integration and
have some nondeterministic errors and are trying to track down which
generations reproduce it, it's nice to know in what way generation 24 is
different from generations 15 through 23.
(Also it still sucks that we can't have a single generation with
multiple config variants to choose from at boot, but I digress.)

threading macro instead of modify* macros

[Csepp]

Here is what I'm trying to do:
I have a package that inherits from the ocaml package.  Because of
Various Reasons (tm) I am using substitute-keyword-arguments and
modify-phases and I need to duplicate the shebang patching phase after
multiple phases.
What I wanted to do was write a helper function like:
(duplicate-after 'conf-2 'patch-sh 'patch-sh-again)
Then I realized I'd have to patch modify-phases to add this to its
grammar.
Then came the realizations that in Haskell this would instead be a
composition of curried applications, that's the thing that the cut macro
emulates in Scheme.
So, (modify-phases foo (add-after 'a 'b f) (delete 'c)) is really:
```
(compose
  (cut add-after <> 'a 'b f)
  (cut delete <> 'c))
```
And from having used Fennel a bit I know that it copied a very nice
syntactic feature from Clojure, called the threading macros, which
implements this exact idiom without having to write cut everywhere.

Guix currently has at least a few modify-whatever and
substitute-whatever macros that all hardcode a few operations.  Couldn't
they be made much cleaner and more general by using a solid library of
data manipulation functions and threading macros?
The phases list could be treated like the actual data type it is, an
ordered key-value mapping.

ps.: On that note, Guile has generics, why doesn't any code use it?
When I have to write things like string

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Csepp]

Simon Tournier  writes:

> Hi,
>
> As bug#60200 [1], the issue is one that many of us often hit: packages
> with several versions and when the highest one is not the default.
>
> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for these very same compilers
> and tools.  It leads to the issue when selecting the name of a compiler
> or tool (command line or manifest).  The user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: 
> /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> For other cases, such issue is avoided by appending the suffix -next to
> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>
> Personally, I find the -next trick useful because the package name
> reflects that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

As I *just* ran into some OCaml and GCC related issues a few days ago,
I'm in favor of either the default flag or expanding the -next suffix
naming convention to more packages.

unified cgroups / rootless podman

[Csepp]

I'm trying to set up a Debian container to test some things and thought
I'd try rootless podman instead of a simple chroot which requires root
privileges.
TLDR I ran into some problems which on other distros are apparently
solved by configuring the init system.
>From the StackOverflow answer:
> From what I see, you need to set rc_cgroup_mode="unified" in the rc.conf file.
> If you were using systemd instead, you'd need to run # grubby
> --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1".

What - if anything - is the equivalent on Guix/Shepherd?

Re: unacknowledged patches

[Csepp]

Csepp  writes:

> (asking this here as well, in addition to IRC)
>
> Hey, I sent a large patch set last night (39 patches) but only recieved
> confirmation for 13 of them.  What do I need to do to get the rest
> acknowledged?
> Here are the ones that made it to debbugs:
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
> It's part of my thesis project for getting MirageOS unikernels deployed
> with Guix, so it would help if they were accepted sooner rather than
> later.
> Either way I'll be adding more code during January, so it's not a
> showstopper if it's not merged, but I'd rather be upstreaming things
> early, so I don't have to rework huge chunks of it later.

Thanks to nckx, I managed to merge the accepted ones, but now it looks
like all (?) have been merged into
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60673
even the ones that did not get an issue number before.

So I think the mystery has been solved.

unacknowledged patches

[Csepp]

(asking this here as well, in addition to IRC)

Hey, I sent a large patch set last night (39 patches) but only recieved
confirmation for 13 of them.  What do I need to do to get the rest
acknowledged?
Here are the ones that made it to debbugs:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
It's part of my thesis project for getting MirageOS unikernels deployed
with Guix, so it would help if they were accepted sooner rather than
later.
Either way I'll be adding more code during January, so it's not a
showstopper if it's not merged, but I'd rather be upstreaming things
early, so I don't have to rework huge chunks of it later.

Re: Packaging OCaml repositories that define multiple packages?

[Csepp]

pukkamustard  writes:

> Csepp  writes:
>
>> But there are packages that were added by others that already
>> specify
>> which subpackage they build, and yet seem to be accepted as
>> subpackages.
>
> Do you have an example?
>
> And maybe send in your patches, that may provide more context around
> this discussion.

I submitted them last night, but only 13 out of the 39 got acknowledged.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
The one with the aliases is among the unacknowledged ones.

Re: Packaging OCaml repositories that define multiple packages?

[Csepp]

Csepp  writes:

> Thanks!  Yeah, the alias solution was not pretty.  Guess I'll use
> inherits and set the package argument.
>
> Julien Lepiller  writes:
>
>> The importer will not support such a package. As you say, it wants to
>> build them separately because they are separate opam packages. So,
>> either we build them separately too, or we build all at once.
>>
>> If we build all at once, that's fine. You could name the package
>> ocaml-mirage and not use any #:package argument. Dune will then build
>> all packages from the repository.
>>
>> One issue with that is that the importer will not know about it and will try
>> to import subpackages again whenever a packages depends on it, instead
>> of using ocaml-mirage.
>>
>> I don't like the alias solution, though it should work, since the importer
>> would see them.
>>
>> Le 8 janvier 2023 15:04:35 GMT+01:00, Csepp 
>> a écrit :
>>
>>  I'm going through my MirageOS commits for what is hopefully
>>  the last
>> time before I send the patches and I realized that a problem that I
>> thought was isolated is a lot more widespread than I thought.
>>
>> As an example look at https://github.com/mirage/mirage/
>>
>> It defines functoria, functoria-runtime, mirage, and mirage-runtime.
>>
>> It is possible to build all 4 as one package.
>>
>> The opam importer seems to not be able to handle situations like this,
>> since it defines a new package for each sub-package.
>>
>> How should I proceed?  I definitely want to merge all redundant packages
>> into one, but then what?  How should the package description reflect
>> this?  What should the package be named when it corresponds to 4 OPAM
>> packages at once?
>>
>> For now I defined a few aliases for cases like this, but I'm not sure if
>> this is ideal.  They look like this (made up but possible example):
>> (define ocaml-mirage ocaml-mirage-runtime)

Switching to bottom replying, I hope you don't mind.

So, I converted most definitions to variants, as discussed.  That
covered all the packages that I introduced that had subpackages, like
the {mirage,functoria}[-runtime] foursome.
But there are packages that were added by others that already specify
which subpackage they build, and yet seem to be accepted as subpackages.
I worked around these using the somewhat aesthetically unpleasant
aliasing solution.

Re: Packaging OCaml repositories that define multiple packages?

[Csepp]

Thanks!  Yeah, the alias solution was not pretty.  Guess I'll use
inherits and set the package argument.

Julien Lepiller  writes:

> The importer will not support such a package. As you say, it wants to
> build them separately because they are separate opam packages. So,
> either we build them separately too, or we build all at once.
>
> If we build all at once, that's fine. You could name the package
> ocaml-mirage and not use any #:package argument. Dune will then build
> all packages from the repository.
>
> One issue with that is that the importer will not know about it and will try
> to import subpackages again whenever a packages depends on it, instead
> of using ocaml-mirage.
>
> I don't like the alias solution, though it should work, since the importer
> would see them.
>
> Le 8 janvier 2023 15:04:35 GMT+01:00, Csepp 
> a écrit :
>
>  I'm going through my MirageOS commits for what is hopefully
>  the last
> time before I send the patches and I realized that a problem that I
> thought was isolated is a lot more widespread than I thought.
>
> As an example look at https://github.com/mirage/mirage/
>
> It defines functoria, functoria-runtime, mirage, and mirage-runtime.
>
> It is possible to build all 4 as one package.
>
> The opam importer seems to not be able to handle situations like this,
> since it defines a new package for each sub-package.
>
> How should I proceed?  I definitely want to merge all redundant packages
> into one, but then what?  How should the package description reflect
> this?  What should the package be named when it corresponds to 4 OPAM
> packages at once?
>
> For now I defined a few aliases for cases like this, but I'm not sure if
> this is ideal.  They look like this (made up but possible example):
> (define ocaml-mirage ocaml-mirage-runtime)

Packaging OCaml repositories that define multiple packages?

[Csepp]

I'm going through my MirageOS commits for what is hopefully the last
time before I send the patches and I realized that a problem that I
thought was isolated is a lot more widespread than I thought.

As an example look at https://github.com/mirage/mirage/

It defines functoria, functoria-runtime, mirage, and mirage-runtime.

It is possible to build all 4 as one package.

The opam importer seems to not be able to handle situations like this,
since it defines a new package for each sub-package.

How should I proceed?  I definitely want to merge all redundant packages
into one, but then what?  How should the package description reflect
this?  What should the package be named when it corresponds to 4 OPAM
packages at once?

For now I defined a few aliases for cases like this, but I'm not sure if
this is ideal.  They look like this (made up but possible example):
(define ocaml-mirage ocaml-mirage-runtime)

Re: Search in One Channel

[Csepp]

"jgart"  writes:

> Hi Guixers,
>
> Below are the channels that I'm currently subscribed to. 
>
> I'd like to search just in the guix-emacs channel with `guix search`. 
>
> Is there a way to do that currently? 

You could filter based on the location field of the output.
There might be a builtin recutils function for that.

Re: Drafting a Guix blog post on the FHS container

[Csepp]

Jim Newsome  writes:

> Sorry for (presumably) breaking threading; I came across this online
> and don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:
>
>
> ```
> guix shell \
>   --container \
>   --network \
>   --emulate-fhs \
>   --preserve='^DISPLAY$'
>   --share=/run/user/$(id -u)/gdm \
>   openssl@1 \
>   libevent \
>   pciutils \
>   dbus-glib \
>   bash \
>   libgccjit \
>   libcxx \
>   gtk+ \
>   coreutils \
>   grep \
>   sed \
>   file \
>   alsa-lib \
>   -- \
>   ./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
> get access to the display. I'm not sure the second parameter is
> universally correct; I reverse-engineered it via roughly `ps aux |
> grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.
>
> -Jim
>
> [Tor Browser Bundle]: https://www.torproject.org/download/

Any idea how to use this for running appimages?  Or anything that
requires FUSE in general?

security tracking NLNet grant

[Csepp]

Anyone knows who is/was working on this and what happened to the
project?
The site only links to general Guix pages.

https://nlnet.nl/project/GUIX-securitytracking/

Re: Packaging big generated data files?

[Csepp]

Denis 'GNUtoo' Carikli  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> Is there any policies or past decisions of the Guix project on
> packaging big generated data files?
>
> I've added packages for software like kiwix-tools and navit that both
> work offline but that also need data files to be useful.
>
> Navit is a (car) navigation software that need maps. The maps can be
> generated from OpenStreetMap dumps with a tool available in Navit
> source code (maptool)[1] which is not packaged yet. Binary map files can
> also be downloaded directly from various sources.
>
> Right now the biggest file possible for such maps is about 47 GiB
> (for the whole planet).
>
> As for kiwix-tools, it can serve offline versions of websites like
> Wikipedia, and there too it needs files to work. The biggest file seems
> to be the complete version of English Wikipedia with scaled down
> pictures[2] and it takes about 89 GiB. I didn't look yet how these files
> were generated but I guess that they somehow can be generated from
> Wikipedia dumps.
>
> Packaging the binary files (without generating them) can be useful as
> it simplifies a lot the maintenance as one can just update the package
> version and checksum to update these. It also enables to keep the
> information (download URL, checksum, license) in one place and it
> enables easy reuse by Guix services and/or configuration files.
>
> If these files were generated in packages, it would also enable to
> tweak the data, for instance by adding height data in navit maps. As
> for kiwix compatible files, it would probably enable to decide when to
> make the snapshots or enable to package additional wikis
> (like the Libreplanet Wiki) or websites.
>
> The issue here is probably the size of the generated files: they are
> huge, so if they are packaged, they will most likely take significant
> resources in the Guix infrastructure.
>
> So what would be the way to go here? Would Guix accept patches to add
> packages for these files in Guix proper?  
>
> If so, does it needs to be done like with the ZFS (kernel module)
> package where "#:substitutable? #f" is used to avoid redistributing
> package builds? Or are other ways better for such use cases?
>
> Note that so far I've only packaged locally only kiwix compatible files
> for various wikis by just downloading already prepared files, so I
> didn't look yet into navit maps or into generating all these files, so
> I might miss some details about generating them.
>
> References:
> ---
> [1]https://navit.readthedocs.io/en/latest/maps.html#processing-osm-maps-yourself
> [2]https://mirror.download.kiwix.org/zim/wikipedia/wikipedia_en_all_maxi_2022-05.zim
>
> Denis.
>
> [[End of PGP Signed Part]]

Could ZIM files be downloaded over bittorrent as fixed output
derivations?  They can be pretty huge.  Also if the system started
seeding them as well, that would be pretty cool.

guile profiling / speeding up derivations on slow storage

[Csepp]

I'd really like to speed up guix pull on my netbook and have been
thinking about ways to do so for a while.

First of all, I'm curious, how do other Guile developers profile code?
Could we add a profiling flag for the CLI similar to the existing
debugging flags?
On a related note, has anyone tried to write a causal profile for Guile,
or a similar Scheme implementation?

One thing that definitely needs improvements is memory usage.  That
should speed things up a lot too, since it would result in less swapping
on machines like mine.
I would love to hear some tips on doing memory profiling on Guile from
someone who has done that.  I also looked into porting the ideas from
Scalene to Guile, but haven't gotten far since I'm busy with uni and
other Guix projects.

I also thought about some possible ways of caching expensive
computations that are not built using the store.  Since Guix is mostly
purely functional in practice, I wonder if we could take some notes from
languages like Yatima.  Or just use a plain old database for some
operations that are currently done by Scheme.

I know some of this must have already been discussed, but it's pretty
hard to track it down, and I think the roadmap for performance
improvements really should be centralized somewhere.

Re: Guile debugger workgroup? (was: Coding style: similarly-named variables)

[Csepp]

Maxim Cournoyer  writes:

> Hi Simon,
>
> zimoun  writes:
>
>> Hi Maxim,
>>
>> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer  
>> wrote:
>>
>>> In practice since using breakpoints/a debugger to debug Guile code
>>> rarely works as intended (in my experience hacking on Guix!), we
>>> typically sprinkle the source with 'pk', and that point becomes moot.
>>
>> I totally agree!  Preparing some materials for introducing Guile to
>> GuixHPC folk, I am trying to collect some tips and, if I am honest, the
>> debugging experience with Guile is really poor; compared to others (as
>> Python).  For example, DrRacket provides an easy and nice user
>> experience [1] – where it is easy to compare each intermediary result in
>> the debugger.  For what it is worth, I have not been able to have some
>> similar inspections as in [1].  Maybe, I am missing something…
>>
>> Well, IMHO, we are somehow suffering from some Guile limitations and
>> improvements in this area are an hard task.
>
> I also agree!  It's hard to convince people to pick Guile for their
> project when there is:
>
> 1. Lack of a debugger that can break and step anywhere in your source
> code
> 2. Lack of debugger integration to an IDE (it's not even integrated into
> Emacs)
>
> Perhaps we should assemble a Guile debugger workgroup that'd review
> what's broken, what's missing, what can be borrowed from other Scheme or
> languages for inspiration, and hopefully improve the Guile debugging
> experience? :-)

Can we also get a profiler like Python's Scalene?
I'm pretty sure there are some performance bottlenecks it could help
identify, both in Guix and in Guile itself.

Re: splitting up and sorting commits?

[Csepp]

Andreas Enge  writes:

> Hello,
>
> Am Wed, Nov 02, 2022 at 12:05:54AM + schrieb Csepp:
>> * It is very easy for package to get added before their dependencies, so
>> even though by the end of the commit chain everything builds perfectly
>> fine, there are intermediate commits that can't be tested on their own.
>
> maybe it can be handled by a different workflow? I usually use the git stash
> to perform a depth first traversal of the dependency graph like so:
> - Add package A. Try to build it and see that it needs dependency B.
>   "git stash".
> - Add package B *instead*. Try to build it...
> (da capo ad libitum)
> - "git commit" with package B.
> - "git stash pop". Try to build package A etc.
> - "git commit" with package A.
>
> The only drawback is that B and A are often defined next to each other,
> which creates a spurious merge conflict during "git stash pop", but that
> is easy to solve and requires an additional "git stash drop" in the end.
>
> Sometimes I even give up on package A in the end, but then at least B
> has been added to Guix :)
>
> Andreas

I tried that, the merge conflicts drove me nuts.  And juggling the stash
stack was a nightmare.

Instead I ended up committing each package individually without caring
about dependencies, then doing an interactive rebase where every command
was edit.  If I saw warnings about undefined variables I ran git rebase
--edit-todo **without** magit, because it made simple textual edits
needlessly hard (this is why I use Kakoune and Emacs side by side),
opened .git/rebase-merge/done, cut the last line, pasted it in todo
after its dependency, ran git reset --hard "HEAD^" **ONLY** if HEAD was
actually that commit, if it was not yet committed because there was a
merge conflict, I ran git rebase --skip.  Yep, figuring out when to
reset and when to skip took a few tries. :)

splitting up and sorting commits?

[Csepp]

Hey all!

I'm working on a fairly sizeable MirageOS branch, just getting the
hello-world kernel running involved adding about 40 packages.  Very
often I run into a scenario where an imported package needs some other
package to compile, and then that needs another, and then that another,
and so on and so on, so by the time I can commit the first I have a
plethora of new packages that should in theory all get their own
commits.
There are two problems with this:
* Splitting up the commit is a pain, even with git add --patch, because
hand editing the diff sucks and splitting does not work, possibly due to
there not being enough space between defines for git's taste.
* It is very easy for package to get added before their dependencies, so
even though by the end of the commit chain everything builds perfectly
fine, there are intermediate commits that can't be tested on their own.

How should one solve this?  I already spent way too much time on a
script that I foolishly thought would be able to automatically sort
commits based on their dependencies, but now I'm throwing in the towel,
it's not getting anywhere.

Re: Antioxidant (new rust build system) update - 100% builds

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> 100% (rounded up) of the packages build with antioxidant, though a
> very few still fail to build:
> .

Heck yeah!  This is some super exciting work. UwU

Re: elogind configuration

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Antonio Carlos Padoan Junior  skribis:
>
>> I do not know why but "suspend" stopped working on my computer
>> after a recent upgrade (pull & reconfigure).
>
> By that you mean that ‘loginctl suspend’ doesn’t have any effect?
>
> I’ve just tried on my laptop and it works for me with this system
> generation:
>
> $ guix system describe
> Generation 204  Oct 10 2022 00:29:29(current)
>   file name: /var/guix/profiles/system-204-link
>   canonical file name: /gnu/store/yvaj9yi25rm16q9j6jccviaf5i55hk83-system
>   label: GNU with Linux-Libre 5.19.14
>   bootloader: grub-efi
>   root device: label: "root"
>   kernel: 
> /gnu/store/8s41d36dgb700p3g5jbgl5vy7wi7lbsw-linux-libre-5.19.14/bzImage
>   channels:
> guix:
>   repository URL: https://git.savannah.gnu.org/git/guix.git
>   branch: master
>   commit: e827d45db92d6e1f9dc68199cd40cb5d67de9d46
>   configuration file: 
> /gnu/store/p4w6x2q9x9cakslb0n6qcqyydn5y0a8m-configuration.scm
>
>
>> However I'm intrigued because my
>> /run/current-system/profile/etc/elogind/logind.conf
>
> As Tobias wrote, it’s a trap.  :-)
>
> The config file that’s actually use can be found like so:
>
> $ sudo herd status elogind
> Status of elogind:
>   It is started.
>   Running value is 347.
>   It is enabled.
>   Provides (elogind).
>   Requires (dbus-system).
>   Conflicts with ().
>   Will be respawned.
> $ sudo cat /proc/347/environ |xargs -0
> ELOGIND_CONF_FILE=/gnu/store/z14j9xi29aci66d2akcflbgxzwm4lg8q-logind.conf
>
> I guess we could improve that user interface.
>
> Ludo’.

I have that issue on my netbook which uses Slim as a display manager to
launch an i3wm session.  It looks like Slim isn't launching dbus, which
also breaks a host of other things, like managing removable storage
devices.

The problem is not present on my x64 machine where I manually launch Sway
with dbus-run-session.

Re: crate importer throws

[Csepp]

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Oct 15, 2022 at 02:58:53PM +0200, Csepp wrote:
>> 
>> Maxime Devos  writes:
>> 
>> > Could you check if
>> >
>> > $ guix shell --pure -- "$(which guix)" import crate the-way
>> >
>> > (i.e. a pure environment without any packages) works for you?  Maybe
>> > somehow there is some other guile-semver in your usual environment
>> > that breaks Guix.
>> 
>> Weirdly enough it works.
>> ...oh it also works without importing guile-semver.
>> HhmmMM!
>> Maybe my channels config makes a difference?
>
> More likely something in your .bashrc

It's a standard Guix System bashrc and bash_profile.
...oh, I actually use zsh, so not sure why I even checked that.  But
yeah, that is not customized much either, I just added the GRML config.

Re: Add earlyoom service to %desktop-services?

[Csepp]

Pkill9  writes:

> I think that the earlyoom service is a necessity for a Guix system
> desktop.
>
> For those who don't know what it does, EarlyOOM (early out-of-memory)
> is a daemon that kills applications when the amount of memory available
> falls below a certain percentage of the maximum, by default 10%. There
> is already an OOM killer in the kernel, but it's too lax and
> applications that consume too much memory can cause the system to
> freeze.
>
> I've used this for a while and many times it has kicked in and works
> well for my laptop. I think adding it to the default desktop services
> will give Guix System on desktop greater stability, which would
> encourage adoption of Guix System on the desktop
>
> What do you, reader, think?

Good idea, iff it works on i686.  Last time I checked it wasn't
building, or rather the docs weren't.  That's why I can't use it on my
netbook, which needs it the most.

Re: crate importer throws

[Csepp]

Maxime Devos  writes:

> Could you check if
>
> $ guix shell --pure -- "$(which guix)" import crate the-way
>
> (i.e. a pure environment without any packages) works for you?  Maybe
> somehow there is some other guile-semver in your usual environment
> that breaks Guix.

Weirdly enough it works.
...oh it also works without importing guile-semver.
HhmmMM!
Maybe my channels config makes a difference?

Re: crate importer throws

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
>
>
> On 12-10-2022 17:50, jgart wrote:
>> On Wed, 12 Oct 2022 14:24:26 +0200 Maxime Devos  
>> wrote:
>> That still throws:
>> guix shell guile-semver -- guix import crate the-way
>> [...] WDYT
>
> I think you need to add 'guile' as well (profiles don't properly
> compose yet w.r.t. search paths):
>
> $ guix shell guile guile-semver -- guix import crate the-way
>
> Can't reproduce locally though ('guix import crate the-way' works for
> me even without 'guix shell guile guile-semver').
>
> $ guix describe
> Generatie 14  18:45:20 10 okt 2022(huidig)
>   guix f0a6aaf
> bewaarplaats-URL: https://git.savannah.gnu.org/git/guix.git
> tak: master
> commit: f0a6aafa22c2e7c7f33786dd7de7083a64401d01
>
> Greetings,
> Maxime.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

This works without adding guile:
guix shell --pure guile-semver -- "$(which guix)" import crate the-way
Any idea why?  I didn't add guix to the shell because I wanted it to use
the same guix profile.

Re: crate importer throws

[Csepp]

jgart  writes:

> On Wed, 12 Oct 2022 14:24:26 +0200 Maxime Devos  
> wrote:
>
> That still throws:
>
> guix shell guile-semver -- guix import crate the-way
> ;;; Failed to autoload string->semver-range in (semver ranges):
> ;;; no code for module (semver ranges)
> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>8 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 724:2  7 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  6 (_ #(#(#)))
> In guix/ui.scm:
>2263:7  5 (run-guix . _)
>   2226:10  4 (run-guix-command _ . _)
> In guix/scripts/import.scm:
> 92:11  3 (guix-import . _)
> In guix/scripts/import/crate.scm:
> 95:24  2 (guix-import-crate . _)
> In guix/import/crate.scm:
> 287:9  1 (crate->guix-package "the-way" #:version _ # _ #:repo _)
>260:26  0 (find-crate-version #< name: "the-way" latest-v…> …)
>
> guix/import/crate.scm:260:26: In procedure find-crate-version:
> error: string->semver-range: unbound variable
>
>
> WDYT

Weird, that exact command worked for me, but it's likely we are on
different commits.  And yes, the error message could be clearer,
although I'm not sure where that should be fixed.  Guile doesn't know
what packages correspond to what modules and it should probably stay
that way.

```
$ guix describe
Generation 162  Oct 01 2022 00:15:38(current)
  guix 1266b9e
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1266b9ed111bff7b860cba6921e4540bc1f61c9e
```

Re: crate importer throws

[Csepp]

jgart  writes:

> ```
>  λ guix import crate the-way
> ;;; Failed to autoload string->semver-range in (semver ranges):
> ;;; no code for module (semver ranges)
> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>8 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 724:2  7 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  6 (_ #(#(#)))
> In guix/ui.scm:
>2263:7  5 (run-guix . _)
>   2226:10  4 (run-guix-command _ . _)
> In guix/scripts/import.scm:
> 92:11  3 (guix-import . _)
> In guix/scripts/import/crate.scm:
> 95:24  2 (guix-import-crate . _)
> In guix/import/crate.scm:
> 287:9  1 (crate->guix-package "the-way" #:version _ # _ #:repo _)
>260:26  0 (find-crate-version #< name: "the-way" latest-v…> …)
>
> guix/import/crate.scm:260:26: In procedure find-crate-version:
> error: string->semver-range: unbound variable
> ```
>
> WDYT

Try re-running it with guile-semver in the environment:
guix shell guile-semver -- guix import crate the-way

Re: Supported architectures

[Csepp]

Efraim Flashner  writes:

> Firstly, I'd like to mention that we, in general, have a minimum system
> requirement of 2GB of RAM, and IIRC there aren't a lot of armhf boards
> out there which have that much. We do have a difference between building
> natively and cross building / building with '--target'.

This really needs to be lowered IMHO.  2GB being the minimum should be
treated as a bug.

> I'd like to comment on armhf for a moment. My memory is a but rusty, but
> I'm pretty sure that in December of 2021 mesa was bumped from 21.2.x to
> 21.3.x, and at that time it stopped building on/for armhf. I noticed in
> May of 2022 (5 months later) and got the build working again. That we
> went 5 months without anyone saying anything in bug reports that mesa
> wasn't building shows that either everyone who is using it is using
> software that doesn't use mesa, or we really don't have any armhf-linux
> users. I'm not advocating dropping the architecture, but it does feel
> like we're already at a best-effort level with it. As far as the pieces
> needed for bootstrapping aarch64 software (go and probably others),
> those get built anyway as needed by aarch64, so there's no worry about
> losing support for those software bits.

Personally I'm not using Guix on my armhf machines *because* armhf is
buggy.  I would certainly love to use it, but right now postmarketOS is
sooo much better on armhf.  It would be great to be in a position where
I could submit bug reports from armhf but just doing it on i686 is
already a challenge.

Re: Guix System For Kids

[Csepp]

jgart  writes:

> On Mon, 03 Oct 2022 00:17:52 +0200 Csepp  wrote:
>> EndlessOS has a system for teaching kids, it's calle Hack, it might be
>> worth checking out.
>
> Does it run on GNU Guix System?

No idea, I haven't tried to compile it or look at its source code.

Re: Guix System For Kids

[Csepp]

jgart  writes:

> What do people think of having an education distro for kids?
>
> Similar to these:
>
> https://itsfoss.com/educational-linux-distros/
>
> Could we use that Guix GUI written in smalltalk to get started?

EndlessOS has a system for teaching kids, it's calle Hack, it might be
worth checking out.

Re: GNU Guix on iPad2 (A1395)

[Csepp]

Jacob Hrbek  writes:

> Context: I have this iPad 2 that I got as a gift from a friend who was 
> upgrading on the newer version to try
> to get me to like Apple. I hate it and it was in my storage unused for many 
> years so now I am trying to get
> GNU Guix on it with GNOME.
>
> To achieve this I merged the required packages in guix 
> (https://issues.guix.gnu.org/57902 and
> https://issues.guix.gnu.org/57871) and thanks to the jailbreaking community i 
> can use Checkm8 exploit
> (https://github.com/axi0mX/ipwndfu) to get full write access to the device 
> and unlock the bootloader to
> boot unsigned OS and linux-libre seems to have all required drivers to run on 
> the device, see the current
> progress in https://git.dotya.ml/kreyren/kreyren/issues/30
>
> The issue is that i can't get libusbmuxd (the daemon used to communicate with 
> iDevices from Linux) to
> work on GNU Guix likely due to a configuration error in guix to perform the 
> exploit and install guix, can
> someone help? https://github.com/libimobiledevice/ideviceinstaller/issues/147
>
> Any relevant info on how to get iPad 2 or other iDevices to work with GNU 
> Guix also appreciated.
>
> -- Jacob "Kreyren" Hrbek

Not a real answer, but have you tried contacting projects like
postmarketOS?  They have much more experience with this sort of thing
and might be able to help with configuration issues.

Re: substitute derivation: also substitute grafts?

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
>
>
> On 15-09-2022 16:46, Csepp wrote:
>> Ricardo Wurmus  writes:
>> 
>>> [...]
>>> Did I say *all items*? Well, … grafts are not included, because
>>> graft
>>> derivations are marked as not substitutable.
>>>
>>> Can we change that conditionally? I would really like to avoid
>>> having
>>> to build grafts on B when they have already been built on A.
>> I would love this too, because IO can be incredibly slow on HDDs and
>> large packages.  My netbook would be thankful.
>>
>
> There are some some opportunities for optimizations in the grafting
> code before substituting more -- for example, to avoid seek times, it
> would be possible to rewrite multiple files concurrently (maybe using
> 'par-for-each' to process each file in a directory in parallel).
>
> This is already done in (guix build grafts), except that:
>
>  * 'find-files' itself is not parallelised, even though parallelising it
> could potentially reduce the time spent seeking (*)
>  * it uses (parallel-job-count), which is (IIUC) 1 by default because
>--cores=1 by default.  As grafts are more IO intensive than CPU
>intensive, maybe it would be reasonable to impose a _minimum_ amount
>of parallelism, I don't, know, 2 or 4 or so?
>
> (I'm assuming the main problem here is seek times.)
>
> Also combinable with the proposal of having substitutes for grafts.
>
> Greetings,
> Maxime.
>
> (*) IIUC, the time for N parallel seeks should, in theory, ≃ 1 seek,
> for small values of N, because of elevator algorithms.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

Could we store the offsets of references somewhere at build time?

Re: substitute derivation: also substitute grafts?

[Csepp]

Ricardo Wurmus  writes:

> Hi Guix,
>
> I really like the fact that Guix can substitute derivations.  It’s a
> great way to transfer a profile from one powerful machine to a weak
> machine without having to set up SSH for “guix copy” first.
>
> I just build a profile on machine A, and then on the weak machine B I
> do
>
>   guix build --substitute-urls="http://A:8000;
> /gnu/store/…-profile.drv
>
> and all items for that profile are copied to B.
>
> Did I say *all items*? Well, … grafts are not included, because graft
> derivations are marked as not substitutable.
>
> Can we change that conditionally? I would really like to avoid having
> to build grafts on B when they have already been built on A.

I would love this too, because IO can be incredibly slow on HDDs and
large packages.  My netbook would be thankful.

Re: image derivation for deploy

[Csepp]

muradm  writes:

> [[PGP Signed Part:Undecided]]
>
> Hi, I'm also using Guix on few of my Linodes.
>
> In my backlog I have an item which says:
> - implement Linode API in guile
>
> So basically I would prefer seeing such integration
> via Linode API directly from Guile, instead of using
> linode-cli.
>
> muradm

Personally, I'm not keen on implementing an OpenAPI compiler, but if
someone (maybe you?) is up for it, they can.

For this project, it's too much effort for not much benefit.