Re: Emacs dependent package input question

[Liliana Marie Prikler]

Am Samstag, dem 05.04.2025 um 16:27 -0700 schrieb Ian Eure:
> Yes, this definitely solves it at a direct package level, but 
> leaves much to be desired for cases of transitive dependencies. 
> For example, emacs-orgit-forge depends on emacs-forge, which 
> depends on emacs-emacsql, which depends on mariadb and postgresql, 
> which none of the other packages actually use.  I know there’s 
> been some work on recursively rewriting package trees for cases 
> like this, but I don’t believe any of it has merged, and I believe 
> this sort of thing is far out of reach for new/casual Guix users.
Have you tried --with-input=postgresql=your-postgresql?  Because I
think it ought to do exactly that.  (While obviously also rebuilding
much of your Emacs tree)


Cheers

Re: Guix on the MNT/Reform

[Vagrant Cascadian]

On 2025-03-19, Denis Carikli wrote:
> On Mon, 17 Mar 2025 12:30:29 -0700
> Vagrant Cascadian  wrote:
>> On 2025-03-16, Denis 'GNUtoo' Carikli wrote:
>> > On Thu, 13 Mar 2025 00:37:09 -0700
>> > Vagrant Cascadian  wrote:  
>> >> One could not be enabled due to DEBLOBBING the wifi drivers, and
>> >> the other may need a closer look. Although the second was for a
>> >> platform I am not currently using, so... :)  
>> > What is the WiFi chip being used[1]?  
>> 
>> Heh. Hard to tell, because I am running linux-libre. :)
> Using 'sudo dmesg' usually prints something with DEBLOBBED and the
> driver name.

Turns out... it was not in fact DEBLOBBING issues... :)


> Another option is to use lspci like that:
>> # lspci -s 02:00.0
>> 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network
>> Adapter (PCI-Express) (rev 01)
> root@primary_laptop /home/gnutoo# lspci -s 02:00.0 -v
>> 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network
>> Adapter (PCI-Express) (rev 01)
>>   [...]
>>  Kernel driver in use: ath9k
>>  Kernel modules: ath9k

Thanks! I used to know to look with lspci and whatnot, but have focused
on getting hardware I know will work for so long... it simply slipped my
mind!


>> Looking at the card through the transparent case bottom (yes!):
>> 
>>   WLE200NX 7A
>> 
>> A quick search says some Compex dual-band wifi, but not sure what that
>> translates to in linux driver terms...
>> 
>> The original MNT/Reform used the Atheros ath9k, if I recall correctly
>> ... could possibly switch back to that too, presumably, if that has
>> libre drivers.
> It does. There are also ath9k compatible chips that support both
> 2.4 GHz and 5GHz. If you want WiFi to work in conferences or other
> very crowded environments (like a flat with a ton of people) you need a
> chip which support 5GHz.

Well, turns out that it was simply missing the kernel configuration
for...

CONFIG_ATH9K=m

... now it at least partly works and sees some access points, although
there are issues that prevent associating successfully... I recall
similar symptoms when using the ath9k_htc usb dongle before, and there
was a workaround for it. Possibly related, reform-tools has this:

  
https://source.mnt.re/reform/reform-tools/-/blob/main/NetworkManager/default-wifi-powersave-off.conf

I suspect only one of the supported GHz frequencies is enabled in the
kernel too as it sees one access point but not another (and I forget
which is which, they're on the same physical machine).  But at least I
know this is likely to work with a bit more fiddling!


>> > An option could also be to upstream as much as possible of the DTS
>> > somehow (basically only send the easy dts patches) to be able to
>> > more easily track what is missing upstream and so find out why this
>> > or that patches are really needed.  
>> 
>> Yes, that is indeed the eventual goal and best outcome, but for the
>> near future we still have to use patches
> Indeed, I was just pointing in addition to shipping a patched kernel
> (which is required to make the hardware work), some very
> limited upstream contributions are a good idea to get reliable
> information on what patches are really required because things evolve
> upstream.

I could prune it down for what is required for my specific mnt/reform
variant(rk3588), and technically could also test the imx8mq variant,
though would like to avoid physically swapping out the module
frequently, or honestly, at all. But definitely not all the permutations
of available hardware.


> Reading or trying to remove some of the patches you currently use to
> try to understand the consequences is probably still be required anyway,
> but just having that done doesn't provide some easy way to test things
> on more recent kernel versions.

But sure, getting it down to the most minimal necessarry patches would
be helpful for upstreaming...


>> There is some good news on that front, too:
>> 
>>   
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts?h=next-20250317
> Nice. I'm currently offline so I'll try to remember to take a look later
> on. Also note that I don't have an MNT Reform but I'm very curious about
> them.

The curiosity is well placed, but I am biased. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Thoughtful updates to TexLive

[Andreas Enge]

Am Tue, Mar 25, 2025 at 03:21:15PM +0100 schrieb Nicolas Goaziou:
> The upgrade process is explained at length in the comments of the
> "tex.scm" module in case anyone is curious about it.
> I don’t keep track of anything. I let the importer tell me what packages
> disappeared, and what are the new ones.

Thanks for the pointer to this very helpful text.

> > And does it make sense to follow the yearly release schedule? Texlive
> > has a Mastodon account, and they regularly post updates of single
> > packages.

Actually I am wrong, it is CTAN, not Texlive. And CTAN contains rather
obscure packages, such as the thesis format for this or that university,
which I suppose are not shipped as part of Texlive.

> Currently, the `texlive' importer and updater is only able to handle
> "yearly" releases, but it is possible to specify manually any SVN
> revision for the TeX Live packages.
> I think this granularity is sufficient, in particular when we consider
> the sheer number of rebuilds changes to TeX Live packages usually
> entail.

Yes, definitely; I also brought it up in case more continuous upgrades
would simplify the work by spreading the load, but it looks as if it is
the other way round. I do not think we need more frequent updates.

Andreas

Re: Applying Patches for Review

[Noé Lopez]

Gabriel Santos  writes:

> Greetings,
>
> I found an interesting patch, viz. 76910, and I want to
> help it out with a review by trying the patch out.
>
> I tried looking into how this is done but couldn't find
> anything in the manual.
>
> So, the question is: how can one apply a patch submitted
> to Guix?
>
> Regards,
>
> -- 
> Gabriel Santos

Hi Gabriel,

Using the mumi package, you should be able to do the following in your
guix repository:
 mumi current 76910
 mumi am

This is documented in (guix)Debbugs User Interfaces.

Another way I know of is to download the mailbox from the issue’s
debbugs page and apply it with “git am”.

Have a nice day,
Noé


signature.asc
Description: PGP signature

Re: [PATCH 00/48] Extend bag-build to gexps.

[Nicolas Graves]

On 2025-03-21 11:20, Sergio Pastor Pérez wrote:

>
> The version 2 has less patches. Do I need to apply only v2?

Yes, I merged some patches because my mail are capped to 200/hour and I
reached that in v1.

-- 
Best regards,
Nicolas Graves

Re: [Shepherd] Disappearing timer

[Rutherther]

Hello Felix,

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

> Hi,
>
> My timer join-irc-channels [1] starts when being 'deployed' but is gone
> after a reboot, even though the Shepherd configuration includes a
> reference to it. [2]  There is no trace:
>
> # herd status join-irc-channels
> herd: error: service 'join-irc-channels' could not be found
>
> The system generation was updated properly.  Any ideas are welcome.

I think you should see an exception in /var/log/messages, or there
really isn't anything?
I tried to get parts of your operating system (didn't want to build
the whole thing) and I am getting unbound variable for
make-timer-constructor. (Since I don't have the whole system
this could be potentially other error than your actual one.
On the other hand I really think this is it - see next paragraph)

This is because the %default-modules[1] of shepherd-service do not
contain (shepherd service timer) which has make-timer-constructor. It's strange 
it
works for you on reconfigure and not boot though. Maybe the module
is loaded somewhere in the running shepherd proces...

I am not sure if this is an oversight on guix channel side,
or if the timers module really shouldn't be in hte default modules...

>
> P.S. Do I need to start services explicitly when they appear in
> another's 'requirements'?

Nope, because shepherd starts all services
(unless you set auto-start of them to #f) in correct order
according to requirements.

Regards,
Rutherther

PS I think that the help-guix mailing list is better suited for
questions about problems.

[1] gnu/services/shepherd.scm (%default-modules)

Re: “Build daemon drops its privileges” 👈 blog post

[Ludovic Courtès]

Hey,

Cayetano Santos  skribis:

> One comment in paragraph about "Migrating an existing installation ...",
> which sounds bad. It suggest that users are at their own (unless this is
> documented somewhere ?); "we may provide a helper script in the future
> ..." feels like guix-foreigners are second class citizens, which I know
> is usually absolutely not the case.

Well, “Guix foreigners” are the first ones to get the new feature.  :-)

But yes, providing a script for those who want to migrate would be nice.

Ludo’.

Re: emacs-next periodic updates

[Gabriel Santos]

Greetings,

I'll send a patch today, after I get all packages built again.
It's based on a newer commit - 467aba6 - and I also enabled the
QEMU service to compile for different architectures on my
system.

I decided to deprecate emacs-next-pgtk-xwidgets,
pointing it to emacs-next-pgtk instead.

I wrote a longer commit message for this, linking to this
discussion thread.

Regards,

-- 
Gabriel Santos

[Shepherd] Default value for #:wait-for-termination?

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

Hi,

Should we change the default for the #:wait-for-termination? parameter
in the Shepherd's make-timer-constructor to #t?

It seems safer.  I added to all my timers.

Kind regards
Felix

Re: Per-user Guix installations

[Ludovic Courtès]

Hello,

Konrad Hinsen  skribis:

>> But then, the problem is that ‘guix pull’ or in fact any ‘guix’ command
>> will give you non-relocatable binaries.  So you need to somehow map,
>> say, ~/.local/state/guix/store to /gnu/store for all the user sessions,
>> as seamlessly as possible.
>
> Or change the location of the store and give up on substitutes. Not
> good, I know.

Changing the store file name would be impractical (it must take close to
one CPU-day to get to ‘coreutils’!) and unnecessary since we rely on
unprivileged user namespaces anyway.

Ludo’.

Re: A silly concern about substitute servers

[Christopher Baines]

Pan Xie  writes:

> 1. Does a substitute server keeps all the packages it build? If the
> answer is yes, won't it consume huge storage resources? If the answer
> is no, then the user who use time-machine travel back to
>
>     years before have to build all the packages from scratch?

For the bordeaux build farm [1], the answer is yes, ignoring some things
going wrong, everything that has been built has been kept. Note that the
bordeaux build farm has only been around for the last 4 to 5 years, and
won't have substitutes for Guix revisions before that (although this
could change in the future).

There are some public stats about this [2], but it needs to be displayed
in a nice way. There are nearly 8 million nars, which take up around
26TiB of space. The project makes use of two copies of these nars, one
which I host and another hosted at the MDC.

1: https://bordeaux.guix.gnu.org/
2: https://bordeaux.guix.gnu.org/metrics

Note that I do actually want to start removing nars, but only nars which
aren't relevant to the master branch. Since the bordeaux build farm
builds branches and patches, it's not helpful to store nars for these
builds indefinitely, unless of course they're relevant to the master
branch.

> 2. If I am going to create a mirror of guix's official substitute
> server, what is the requirement of the storage?

If you want to store all the bordeaux nars, then you'd need at least
26TiB, but for running the mirrors listed on bordeaux.guix.gnu.org, they
operate as a caching reverse proxy. For that approach, you only need say
60GiB of space, enough for the nar-herder database plus a few cached
nars. If you want NGinx to cache more nars, then you simply increase the
space allotted.

> 3. Does a package really has lots of build on a substitute server? For
> example, emacs-29.1 has lots of inputs. I guess each time there is a
> commit to guix repository which change the inputs, there will be a
> build
>
>     of it, so there must be lots of emacs-29.1 builds, with different
> hash numbers. Or am I wrong?

Nope, you're right. If you want to explore the nar-herder database for
bordeaux.guix.gnu.org, you can download a dump of it here [3] (it's 19G
in size). You can also see the outputs changing over time through the
data service [4].

3: https://bordeaux.guix.gnu.org/latest-database-dump
4: 
https://data.guix.gnu.org/repository/1/branch/master/package/emacs/output-history


signature.asc
Description: PGP signature

Emacs dependent package input question

[Ian Eure]

Hi Guixers,

I’ve seen a few patches for Emacs packages lately which have the 
form:


   (package emacs-whatever
 (name "emacs-whatever")
 (description "Emacs interface for Whatever")
 (inputs (list whatever))
 (arguments
  (list
   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'set-whatever-path
   (lambda (#:key inputs #:allow-other-keys)
 (emacs-substitute-variables "whatever.el"
   ("emacs-whatever-program"
(search-inputs-file inputs 
"/bin/whatever")


...and looking in emacs-xyz.scm, many packages do this.  I 
understand why this pattern exists -- making the inferior an input 
means that installing the Emacs package Just Works -- but it also 
means increased disk consumption and somewhat less user 
flexibility.


On the flexibility side, it means that if you install 
emacs-whatever and my-personal-whatever-fork, emacs-whatever will 
continue using the stock whatever, not your fork; making this work 
requires transforming emacs-whatever to replace the input.  I 
think that because this behavior is so different from how most 
other operating systems work, it’s surprising, and the solution 
isn’t obvious.


On disk space, it means that many packages come with inputs to 
serve many possible usecases, whether those are relevant or not.


One fairly trivial example: emacs-emms has inputs for mpg321, 
mid3v2, ogg123, ogginfo, and opusinfo.  My music library is 100% 
FLAC, so these programs are never used, but consume disk on my 
Guix install.  And on the other hand, I often use EMMS to play 
videos, but mpv *isn’t* an input, so this usecase is broken out of 
the box.


Another example is emacs-plantuml-mode, which has plantuml as an 
input, which has icedtea as an input -- meaning an install of the 
Emacs package comes with a whole Java runtime.


For another example, emacs-emacsql is most often used to access a 
SQLite database, but supports MySQL and PostgreSQL as well.  The 
Guix package has mariadb and postgresql in its inputs, so it can 
set their program paths.  As a consequence, those packages (which 
I don’t use otherwise) are consuming 800mb:


$ du -shc $(find /gnu/store -maxdepth 1 -type d -name 
\*-postgresql-\* -or -name \*mariadb\*) | tail -1

804Mtotal

I’m not picking on any individual package or contributor here -- 
as I said, the pattern is widespread -- and I have multiple 
generations in the store, which increase those numbers.  But this 
feels like an area that could be improved.


I’m not sure how to do that, though.  I can think of a few 
options:


a) Leave it as is.  Don’t love it, but if there’s concensus that 
this is the right way, then okay.


b) Make packages that align better with specific usecases, 
ex. emacs-emacsql-sqlite, -mysql, etc.  This feels fraught to me, 
and I don’t think it works if you get emacs-emacsql-sqlite as an 
input to some other emacs-* package, but want emacs-emacsql-mysql 
as a user.  Perhaps metapackages which only exist to combine 
dependencies would make this a workable approach.


c) Don’t set them at all, and use the same $PATH late binding as 
is typical of other Emacs setups.  This would mean that 
installing Emacs packages wouldn’t Just Work, and users would 
have to install the inferiors (and know what packages those are 
in) themselves.


d) Have some better policies around when to use inputs and when 
not to.  This might be the most pragmatic approach, though it 
means inconsistency from package to package.


e) Build a suggested package mechanism into Guix.  This has been 
floated a couple times before.  If it defaults to not installing 
suggested packages, but telling the user about them, this would 
be like option C, but making it easier to find which packages you 
might need; if it installs them by default, it would work like 
the current setup, but give users some kind of out to avoid the 
extra bandwidth/disk usage.  I don’t know how this would work for 
declarative package setups -- how would I express to Guix Home 
that it should install emacs-emms with flac (for metaflac), but 
without mpg321, vorbis-tools, and mp3info?


I’d love to hear others’ thoughts.

Thanks,

 -- Ian

Re: How is security managed in Guix? Should there be a team?

[Nicolas Graves]

On 2025-04-04 16:21, John Kehayias via "Development of GNU Guix and the GNU 
System distribution." wrote:

> Hello,
>
> (CCing some more security people)
>
> On Fri, Apr 04, 2025 at 05:51 PM, Simon Josefsson via \"Development of GNU 
> Guix and the GNU System distribution.\" wrote:
>
>> Nicolas Graves  writes:
>>
>>> Hi Guix!
>>>
>>> I think one of the things where Guix could be better is security /
>>> ensuring CVEs are fixed quickly.
>>>
>>> In 76819 I developped some missing functionality in the CVE linter, so
>>> that it will be easier to get proper missing libraries.
>>>
>>> A few ideas/questions to advance on that :
>>> - there are still a lot of linted CVEs for toolchains (former go
>>>   versions etc) that users should in principle not be exposed to.
>>>   Should we handle or ignore those?
>
> I think we should definitely handle all CVEs, as best we can. Toolchain
> updates will be slower unfortunately, but we have grafts we can do of
> course (already too many).
>
>>> - Maybe having a team or a responsible person for this is a good
>>> idea.
>
> Do you mean for package-level CVEs and the like? We do have a
> security-team:  (linked from the
> About menu on the Guix homepage).

Yes, I meant package-level CVEs.  I'm not qualified enough to help on
Guix internal CVEs.

> Admittedly, we could use more people and rotate out, with some set terms.
> It has been mentioned before but not done. I'm on the team and we could
> do better. Some things take a while (though I think we have been pretty
> good about Guix-specific issues in the recent past), though generally it
> is quite low traffic. Prioritizing package updates to do CVEs can and
> should be done by us all though.
>
>>> - A good practice could be to setup a daily job to get notified of all
>>>   CVEs, so that we can quickly handle them.
>>
>
> That does sound helpful, though also running `guix lint` on any
> submission or review of a patch should catch CVEs as well. A set
> job/notification sounds helpful.

Yes, but a CVE can happen for a package after submission or review,
that's why I think such a job could be helpful in the middle term.

I think we can start by focussing first on fixing existing CVEs.  WDYT
about :
1) Reviewing / merging 76819 (adding package properties to better match
CVEs to packages in Guix)
2) Run a system-level guix lint -c cve to list/prioritize/organize the
work on existing CVEs.
3) After most existing CVEs are fixed, then try to implement our daily
automatic script/webhook/whatever to get notified when a CVE is spotted
among guix packages.  This way even when it's a "false alarm" (bad
cpe-name etc), we can simply edit package-properties to get gradually
better matches on what is relevant and what is not.

Hopefully in the long term, we can achieve some workflow like
CVE found with fix -> guix security team notified -> quickfix with graft
if necessary -> CVE fixed ! within a few days

It's trickier when the CVE is released with no known patch, but at least
there Guix would not lag behind any other distribution on security.

> Perhaps you also meant a public security list for things like speedier
> review of patches with "security-updates" or CVEs listed? I'm not sure
> if we want that together or not with a private list for undisclosed
> vulnerabilities, but for sure a way to ping some extra people for such
> (public) security updates would be great. Presumably we can leverage
> what is done for CCing teams to look for those keywords and CC security?
> I try to keep an eye open when I can but that is no substitute.

I think team-like cc is a good idea.

> Oh, while I'm here: we need to ungraft! I would like some sort of
> cadence for this, perhaps:
>
> 1. Any graft immediately has an ungraft patch applied to, say,
> "ungrafting-branch" or some branch focused on that.
>
> 2. This is built and merged every month (?) or once a certain number of
> ungrafts/package rebuilds are needed (insert favorite arbitrary number),
> whichever comes first.
>
> Maybe this needs a proper GCD? I think we could just try something as
> this is more basic build management than a change to the project,
> because right now we keep falling behind and easily spend more time
> grafting than building on user systems.

I also agree on the ungrafting part, I like the idea!

-- 
Best regards,
Nicolas Graves

Re: How is security managed in Guix? Should there be a team?

[Nicolas Graves]

On 2025-04-04 23:51, Simon Josefsson via "Development of GNU Guix and the GNU 
System distribution." wrote:

> I think a Guix security team have at least two different tasks:
>
> 1) Answer privately about any security coordination needed, especially
> about Guix-specific problems.

So this one seems in place IIRC.

> 2) Work on updating packages in Guix with known security issues, wether
> publicly or not.

My main concern was indeed this second task.

> Comparing with Debian, that security team also works to actually publish
> updates of packages when external events happen.  For example, comparing
> with the debian-security-announce list, who is tasked with noticing and
> making a package update of the 'atop' tool for this problem?
>
> https://www.openwall.com/lists/oss-security/2025/03/29/1
>
> For me, I would like to see a distribution I use for production use to
> have a track record of say 1 year of publicly acknowledging and
> announcing fixes to various world events around it.  Otherwise it feels
> quite opaque to trust it, how am I to know if very common security
> problems are patched or not?

I agree this is an important point to address for any distribution to
consider using in real-life scenarii.

> Of course, for each and every particular
> issue, I can research the Guix git history.  But that's not what I am
> looking for: instead I'd like to see some continous mailing list or RSS
> flow with security fixes that a Guix security team is monitoring and
> applying.

-- 
Best regards,
Nicolas Graves

Heads up: LibreWolf 137.0-1 withdrawn due to a bug

[Ian Eure]

I pushed a commit for LibreWolf 137.0-1 Thursday night, and pushed 
a revert yesterday afternoon.  The upstream release was pulled, as 
it contains a bug.  Upstream Firefox 137.0 changed the profile 
storage location from ~/.firefox to ~/mozilla/firefox, which 
resulted in LibreWolf’s profile location changing to 
~/.mozilla/librewolf, which means it can’t find your 
configuration.  The upstream bug tracking this is 
https://codeberg.org/librewolf/issues/issues/2400


If you upgraded during this time, I recommend that you downgrade 
back to 136.0.4-1.  Alternately, you can move or symlink 
~/.librewolf to ~/.mozilla/librewolf, though you’ll need to take 
additional action once the root issue is fixed.


Thanks,

 -- Ian

Re: Thoughtful updates to TexLive

[Andreas Enge]

Hello,

Am Thu, Mar 20, 2025 at 07:09:46PM +0100 schrieb Nicolas Goaziou:
> > This looks a lot like https://issues.guix.gnu.org/75893 .
> > I should test with your fix on the tex-team branch.
> I would indeed appreciate some feedback!

as mentioned in the issue, your fix appears to work very well.

I have just pushed the 2025 update to the monolithic texlive.
This is the first time that the temxf tarball is bigger than 4GB
(the previous one was already bigger than 4*10^9, but still smaller
than 4*2^30). Unless I have made a mistake, I think this has had some
incidence: As usual, I had done a "guix download" from a local file,
but "guix shell -D texlive" has still downloaded the tarball again.
I wonder if there is a bug somewhere in the Guix code for files bigger
than 4GB. And I also wonder what will happen on 32 bit systems...

So maybe once the fix for issue 75893 is pushed and the modular texlive
updated to version 2025, it will finally be time to retire the
monolithic package.

Well, I do not know how complicated it will be to update the modular
texlive, with package additions, maybe removals, and updates of the
collections and schemes. How do you keep track of the changes between
one version and another one? And does it make sense to follow the yearly
release schedule? Texlive has a Mastodon account, and they regularly
post updates of single packages.

Andreas

Re: Debbugs changes on #guix

[Rutherther]

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

> Hi,
>
> I enabled an experimental barebones feature that broadcasts Debbugs
> changes on #guix.  It's another technical feature that could improve the
> speed at which bugs are being closed.

Hello, this seems like a good idea in general.

>
> Please let me know what you think!

I have a few notes:

- Wouldn't it make more sense to put it to a different channel dedicated
  for this, where people, who want to follow it, can see it?
- Seems like all issues are sent, not just those filtered for Guix. Does
  that make sense? I am not that interested in other project issues
- Could at least the project be printed?
- Currently it seems that only id and 'changed' is printed, what about printing
  what changed how - name of the issue + created/closed/other state
  update, new message (if that is a thing) etc.

I don't remember ids of issues and I doubt there are people who do,
so it seems to me like printing just the id without any more context
(name) doesn't really serve much value and one has to open the issue
somewhere else.

Also, I don't really have much experience with Debbugs, so pardon the
simple question, but is it possible to somehow list issues with recent
activity somewhere? Like if I used emacs debbugs? (not necessarily new
issues, but even old issues with a new message)

Regards,
Rutherther

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[pinoaffe]

Simon Tournier  writes:
> For instance, magit-forge does not work with Codeberg although their
> documentation says so.  Well, neither Ludo or I have succeeded in
> configuring it, although we asked advice on Mastodon [1,2].

magit-forge has practically no support for forgejo yet, it only knows
how to find the urls of certain web pages related to a project such as
the issues page.  The documentation is just a bit unclear about that.
As I understand it, proper forgejo support is planned, and it is
intended to be the next supported forge in magit-forge

Re: Mirroring the mirror?

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

> I’m just discovering the Forgejo instance of sourceware:
>
> https://forge.sourceware.org/explore/organizations
>
> Here, mirror of GCC, Glibc and others are already hosted.
>
> Therefore, it would make sense to check their willing and capacity to
> backup Guix; I have in mind to ask for hosting read-only copies of all
> the PRs, i.e., a plan B for the history of all the PRs.

I checked with people at Sourceware: they’re unable to to provide any
guarantees around mirroring Guix at the moment, their Forgejo setup
being experimental and with limited capacity (but they do hope to set up
mirrors and federation eventually).

Ludo’.

Re: Guix booth at JDLL in Lyon, France?

[Tanguy Le Carrour]

On Sun Mar 23, 2025 at 12:29 PM CET, Julien Lepiller wrote:
> I just received a confirmation that our booth is accepted!

🥳

Re: GNU & Guix

[Tobias Geerinckx-Rice]

Hi Caleb,

Caleb Herbert  wrote:

[To pinoaffe:]

>That's a disingenuous suggestion

[To Andreas:]

>You're denying the truth.

You've been around long enough to know that you're out of line without needing 
to be told.  You should apologise to at least pinoaffe and Andreas.  I can't 
assume good faith if you can't.

What do you expect this kind of disruptive behaviour to achieve?  It is 
comically unclear.

The Guix Days are not pre-planned.  Anyone can attend, anyone present can 
suggest a topic, and anyone present can express interest in discussing it.  
Then that discussion ends up in the notes.  That's it.

I wasn't there.  Clearly, Andreas was not.  At most, 1 of 3 maintainers were.  
0 is equally likely because we haven't yet managed to clone Efraim.

So contrary to what some like to believe, there's no leadership(lol)-level 
scheming in Guix to 'leave' GNU.  No such plans from the maintainership.

However, those pesky passive maintainers (hello) have been mostly ignoring the 
issue and should probably…  not?  We might even need to make a decision (eek).

So thanks for reminding everyone of that, even if it wasn't your intention.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ludovic Courtès]

Hello,

Simon Tournier  skribis:

> Currently, the name of specifications reads [1]:
>
> forgejo-pull-requests-guix-science-carputils-91
> forgejo-pull-requests-guix-science-equinox-cherrypick-84
> forgejo-pull-requests-guix-science-ghdl-87
> forgejo-pull-requests-guix-science-master-47
> forgejo-pull-requests-guix-science-nonfree-IPHC-dev-31
> forgejo-pull-requests-guix-science-pyvhdlmodel-86
> forgejo-pull-requests-guix-science-typst-languagetool-92
>
> and that’s annoying: it’s difficult to find the relevant specifications.

Improving this is among the things that have been on our mind for a
while; it looks better now:

  https://guix.bordeaux.inria.fr/pull-requests

We’re making progress, at our own pace.  :-)

Ludo’.

Re: Emacs dependent package input question

[Ian Eure]

Hi Nicolas,

Nicolas Graves  writes:


On 2025-04-05 09:38, Ian Eure wrote:

Hi Ian, thanks for this discussion.

This is my (d) (better policy proposition): 

 a) Leave it as is.  Don’t love it, but if there’s concensus 
 that 
 this is the right way, then okay.


I'd argue sometimes it's indeed the better solution, especially 
when
the core of the package needs the binary to work properly, not 
when it's
an additional option or feature.  I'll refer to that as 
"essential

binary" in the rest.


I appreciate this line of thinking, but suspect that whether a 
binary is essential or not depends on the user’s usecase, which is 
unknowable at package build time.  For a user using EMMS to play 
MP3s, flac isn’t essential, and mpg321 is; for someone using it to 
play FLACs, the inverse is true.


(This is the case where not having the binary is absurd because 
it

renders the emacs package unusable).


I think it’s important to distinguish between "unusable" and "not 
usable unless the user takes some action."


 e) Build a suggested package mechanism into Guix.  This has 
 been 
 floated a couple times before.  If it defaults to not 
 installing 
 suggested packages, but telling the user about them, this 
 would 
 be like option C, but making it easier to find which packages 
 you 
 might need; if it installs them by default, it would work like 
 the current setup, but give users some kind of out to avoid 
 the 
 extra bandwidth/disk usage.  I don’t know how this would work 
 for 
 declarative package setups -- how would I express to Guix Home 
 that it should install emacs-emms with flac (for metaflac), 
 but 
 without mpg321, vorbis-tools, and mp3info?


I agree this is nice, but maybe it's enough to do that in Emacs 
packages
themselves (ensuring they suggest the missing binary when it's 
not

found) rather than in Guix Home itself.


I also like this idea; do you have an idea what an implementation 
for that would look like?  Presumably upstream package authors 
wouldn’t want Guix-specific stuff in packages that need to work on 
any OS/distro.


 -- Ian

Re: Emacs dependent package input question

[Ian Eure]

Liliana Marie Prikler  writes:


Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure:

Hi Guixers,

I’ve seen a few patches for Emacs packages lately which have 
the 
form:


    (package emacs-whatever
  (name "emacs-whatever")
  (description "Emacs interface for Whatever")
  (inputs (list whatever))
  (arguments
   (list
    #:phases
    (modify-phases %standard-phases
  (add-after 'unpack 'set-whatever-path
    (lambda (#:key inputs #:allow-other-keys)
  (emacs-substitute-variables "whatever.el"
    ("emacs-whatever-program"
 (search-inputs-file inputs 
 "/bin/whatever")

Side note: the ordering of fields here looks rather displeasing.


Yes, this is a contrived example, and aggressively wrapped.


...and looking in emacs-xyz.scm, many packages do this.  I 
understand why this pattern exists -- making the inferior an 
input 
means that installing the Emacs package Just Works -- but it 
also 
means increased disk consumption and somewhat less user 
flexibility.


On the flexibility side, it means that if you install 
emacs-whatever and my-personal-whatever-fork, emacs-whatever 
will 
continue using the stock whatever, not your fork; making this 
work 
requires transforming emacs-whatever to replace the input.  I 
think that because this behavior is so different from how most 
other operating systems work, it’s surprising, and the solution 
isn’t obvious.
You obviously can still customize it to use a PATH lookup.  You 
are

wasting disk space if you do so.


If you don’t use the inputs to the Emacs packages, you’re wasting 
disk (and bandwidth) whether you do that or not.



Alternatively, input rewriting such as the --with-input command 
line
flag replace whatever with your- personal-whatever-fork and thus 
do

exactly what you want.


Yes, this definitely solves it at a direct package level, but 
leaves much to be desired for cases of transitive dependencies. 
For example, emacs-orgit-forge depends on emacs-forge, which 
depends on emacs-emacsql, which depends on mariadb and postgresql, 
which none of the other packages actually use.  I know there’s 
been some work on recursively rewriting package trees for cases 
like this, but I don’t believe any of it has merged, and I believe 
this sort of thing is far out of reach for new/casual Guix users.




[…]
I’m not sure how to do that, though.  I can think of a few 
options:


 a) Leave it as is.  Don’t love it, but if there’s concensus 
that 
 this is the right way, then okay.


 b) Make packages that align better with specific usecases, 
 ex. emacs-emacsql-sqlite, -mysql, etc.  This feels fraught to 
me, 
 and I don’t think it works if you get emacs-emacsql-sqlite as 
an 
 input to some other emacs-* package, but want 
emacs-emacsql-mysql 
 as a user.  Perhaps metapackages which only exist to combine 
 dependencies would make this a workable approach.


 c) Don’t set them at all, and use the same $PATH late binding 
as 
 is typical of other Emacs setups.  This would mean that 
 installing Emacs packages wouldn’t Just Work, and users would 
 have to install the inferiors (and know what packages those 
are 
 in) themselves.


 d) Have some better policies around when to use inputs and 
when 
 not to.  This might be the most pragmatic approach, though it 
 means inconsistency from package to package.


 e) Build a suggested package mechanism into Guix.  This has 
been 
 floated a couple times before.  If it defaults to not 
installing 
 suggested packages, but telling the user about them, this 
would 
 be like option C, but making it easier to find which packages 
you 
 might need; if it installs them by default, it would work like 
 the current setup, but give users some kind of out to avoid 
the 
 extra bandwidth/disk usage.  I don’t know how this would work 
for 
 declarative package setups -- how would I express to Guix Home 
 that it should install emacs-emms with flac (for metaflac), 
but 
 without mpg321, vorbis-tools, and mp3info?

f) Implement parametrized packages 😉

I think in practice, transformations and hopefully some day 
parameters

will be a preferable solution to most of our Emacs-related
customization woes.


Indeed.

Thanks for your thoughts,

 -- Ian

Re: Search alerts and Watch issue on mumi

[Gabriel Santos]

>I tried this, and it brings the "Projects" link higher up, but leaves
>the little dropdown arrow where it is. I'll probably go with Luis'
>suggestion in https://issues.guix.gnu.org/77513#1

Nice to see someone suggested a fix already!

-- 
Gabriel Santos

Slow guix pull? (was Re: Please don't leave GNU)

[Simon Tournier]

Hi Florian,

On Sun, 30 Mar 2025 at 12:55, "pelzflorian (Florian Pelz)" 
 wrote:
> Caleb Herbert  writes:

>> * Guix is slow at package management, even slower than DNF.
>
> Git-based Guix pull is slow because of Git, yes.  But it must use a big
> Git repo for its reproducibility, transactions and it uses only one big
> slow repository because its package dependencies are so intertwined.

I would not say “guix pull” is slow because of Git.  Well, libgit2 adds
some bits here or there but that’s not the main bottleneck,, IMHO.
Neither fetching commits – although the first “guix pull” requires to
clone a large repository; possibly mitigated by some shallow clone,
another story. :-)

Well, the Git-based part of “guix pull” mainly depends on your network
capacity.  For sure, many things could improved; for example the number
of requests, see bug#65787 [1], etc.  But that’s not why “guix pull”
appears very slow.

To my knowledge, the main bottleneck on most machines is the part
“Computing Guix derivation...“ and sadly it’s not substitutable.

And roughly speaking, it’s because 1. Files are not compiled yet, i.e.,
they are interpreted and 2. It needs to have Guile, i.e., to load the
module (gnu packages guile) which ends up to load hundreds of other
packages – in one word: inter-dependency modules, e.g., try “guix graph
-t module guile”. :-)

We are locked by the current implementation that does not scale.

Happily, we have paths to move forward [2].  But they require to revamp
how it currently works.  Good, let’s experiment with that! :-)

Cheers,
simon


1: bug#65787: time-machine is doing too much network requests
Simon Tournier 
Wed, 06 Sep 2023 18:26:18 +0200
id:87wmx3mfo5@gmail.com
https://issues.guix.gnu.org/65787
https://issues.guix.gnu.org/msgid/87wmx3mfo5@gmail.com
https://yhetil.org/guix/87wmx3mfo5@gmail.com

2: Re: Guix pull speed
Ludovic Courtès 
Thu, 14 Sep 2023 11:58:18 +0200
id:87il8ddqkl@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/87il8ddqkl@gnu.org

Re: Search alerts and Watch issue on mumi

[Arun Isaac]

> Love it. Really. Thanks a lot for all those improvements to mumi, which
> is getting more and more useful with time.

Thank you very much for the encouragement. :-) I hope I can continue to
hack on mumi for a while.

>> Search alerts and issue watching are all powered by Atom feeds under the
>> hood. Atom is a web standard.
>
> Free, open and distributed, I must say (emacs people, give elfeed a
> try).

Yes, elfeed is really good. I use elfeed. Maybe gnus can work too.
https://www.gnu.org/software/emacs/manual/html_node/gnus/Atom.html

Then, there's Newsboat and many others for those who don't want to use
Emacs.
https://newsboat.org/index.html

Re: Emacs dependent package input question

[Liliana Marie Prikler]

Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure:
> Hi Guixers,
> 
> I’ve seen a few patches for Emacs packages lately which have the 
> form:
> 
>     (package emacs-whatever
>   (name "emacs-whatever")
>   (description "Emacs interface for Whatever")
>   (inputs (list whatever))
>   (arguments
>    (list
>     #:phases
>     (modify-phases %standard-phases
>   (add-after 'unpack 'set-whatever-path
>     (lambda (#:key inputs #:allow-other-keys)
>   (emacs-substitute-variables "whatever.el"
>     ("emacs-whatever-program"
>  (search-inputs-file inputs 
>  "/bin/whatever")
Side note: the ordering of fields here looks rather displeasing.

> ...and looking in emacs-xyz.scm, many packages do this.  I 
> understand why this pattern exists -- making the inferior an input 
> means that installing the Emacs package Just Works -- but it also 
> means increased disk consumption and somewhat less user 
> flexibility.
> 
> On the flexibility side, it means that if you install 
> emacs-whatever and my-personal-whatever-fork, emacs-whatever will 
> continue using the stock whatever, not your fork; making this work 
> requires transforming emacs-whatever to replace the input.  I 
> think that because this behavior is so different from how most 
> other operating systems work, it’s surprising, and the solution 
> isn’t obvious.
You obviously can still customize it to use a PATH lookup.  You are
wasting disk space if you do so.  Alternatively, input rewriting such
as the --with-input command line flag replace whatever with your-
personal-whatever-fork and thus do exactly what you want.

> […]
> I’m not sure how to do that, though.  I can think of a few 
> options:
> 
>  a) Leave it as is.  Don’t love it, but if there’s concensus that 
>  this is the right way, then okay.
> 
>  b) Make packages that align better with specific usecases, 
>  ex. emacs-emacsql-sqlite, -mysql, etc.  This feels fraught to me, 
>  and I don’t think it works if you get emacs-emacsql-sqlite as an 
>  input to some other emacs-* package, but want emacs-emacsql-mysql 
>  as a user.  Perhaps metapackages which only exist to combine 
>  dependencies would make this a workable approach.
> 
>  c) Don’t set them at all, and use the same $PATH late binding as 
>  is typical of other Emacs setups.  This would mean that 
>  installing Emacs packages wouldn’t Just Work, and users would 
>  have to install the inferiors (and know what packages those are 
>  in) themselves.
> 
>  d) Have some better policies around when to use inputs and when 
>  not to.  This might be the most pragmatic approach, though it 
>  means inconsistency from package to package.
> 
>  e) Build a suggested package mechanism into Guix.  This has been 
>  floated a couple times before.  If it defaults to not installing 
>  suggested packages, but telling the user about them, this would 
>  be like option C, but making it easier to find which packages you 
>  might need; if it installs them by default, it would work like 
>  the current setup, but give users some kind of out to avoid the 
>  extra bandwidth/disk usage.  I don’t know how this would work for 
>  declarative package setups -- how would I express to Guix Home 
>  that it should install emacs-emms with flac (for metaflac), but 
>  without mpg321, vorbis-tools, and mp3info?
f) Implement parametrized packages 😉

I think in practice, transformations and hopefully some day parameters
will be a preferable solution to most of our Emacs-related
customization woes.

Cheers

Re: Emacs dependent package input question

[Nicolas Graves]

On 2025-04-05 09:38, Ian Eure wrote:

Hi Ian, thanks for this discussion.

This is my (d) (better policy proposition): 

>  a) Leave it as is.  Don’t love it, but if there’s concensus that 
>  this is the right way, then okay.

I'd argue sometimes it's indeed the better solution, especially when
the core of the package needs the binary to work properly, not when it's
an additional option or feature.  I'll refer to that as "essential
binary" in the rest.

(This is the case where not having the binary is absurd because it
renders the emacs package unusable).

>  b) Make packages that align better with specific usecases, 
>  ex. emacs-emacsql-sqlite, -mysql, etc.  This feels fraught to me, 
>  and I don’t think it works if you get emacs-emacsql-sqlite as an 
>  input to some other emacs-* package, but want emacs-emacsql-mysql 
>  as a user.  Perhaps metapackages which only exist to combine 
>  dependencies would make this a workable approach.
>
>  c) Don’t set them at all, and use the same $PATH late binding as 
>  is typical of other Emacs setups.  This would mean that 
>  installing Emacs packages wouldn’t Just Work, and users would 
>  have to install the inferiors (and know what packages those are 
>  in) themselves.

IMO this is the best solution when it's not an "essential binary" :

Maybe when the package properly signals the absence of the desired input
to the user AND the package behaving properly as soon as it's in a
profile is enough (and we wouldn't need to ensure inputs in this case).

This means that we could participate in emacs packages by improving
their management of missing binaries, so that we can ensure normal guix
use with smaller profiles.

>  d) Have some better policies around when to use inputs and when 
>  not to.  This might be the most pragmatic approach, though it 
>  means inconsistency from package to package.
>
>  e) Build a suggested package mechanism into Guix.  This has been 
>  floated a couple times before.  If it defaults to not installing 
>  suggested packages, but telling the user about them, this would 
>  be like option C, but making it easier to find which packages you 
>  might need; if it installs them by default, it would work like 
>  the current setup, but give users some kind of out to avoid the 
>  extra bandwidth/disk usage.  I don’t know how this would work for 
>  declarative package setups -- how would I express to Guix Home 
>  that it should install emacs-emms with flac (for metaflac), but 
>  without mpg321, vorbis-tools, and mp3info?

I agree this is nice, but maybe it's enough to do that in Emacs packages
themselves (ensuring they suggest the missing binary when it's not
found) rather than in Guix Home itself.


In summary :

Is the input essential to the core functionality of the emacs package?
+ Yes: (a)
+ No: Is the package signalling the absence of its input in a
Guix-understandable way?  Does adding the input fix the issue?
 - Both yes : (c)
 - At least a No: Submit a patch to the upstream package to ensure both
 yes.
  
-- 
Best regards,
Nicolas Graves

Re: Search alerts and Watch issue on mumi

[Arun Isaac]

Hi Gabriel,

Thank you for your quick response!

> mumi.css 1970:2
>> line-height: var(--line-height);
>
> Brought "Projects" to the same height as "Search Alert".

I tried this, and it brings the "Projects" link higher up, but leaves
the little dropdown arrow where it is. I'll probably go with Luis'
suggestion in https://issues.guix.gnu.org/77513#1

Cheers!
Arun