security patching of 'patch' package

[Léo Le Bouter]

Hello!

I could find that the 'patch' package was vulnerable to numerous CVEs
that other distros like Debian have patched. Here's the list reported
by 'guix lint -c cve patch':

patch@2.7.6: probably vulnerable to CVE-2019-13636, CVE-2019-13638,
CVE-2019-20633, CVE-2018-1000156, CVE-2018-20969, CVE-2018-6951, CVE-
2018-6952

Can I use latest commit from master to build 'patch' then graft
original package?

i.e. https://git.savannah.gnu.org/git/patch.git

There's not that many commits since last release, but lots of time: 
https://git.savannah.gnu.org/cgit/patch.git/log/

Thank you,
Léo


signature.asc
Description: This is a digitally signed message part

Generate diff with git-diff and use in patches field of packages

[Léo Le Bouter]

Hello!

While patching packages for security issues, I often am needing to get
some patches from git repos because upstream does not make releases.

Including patch in "patches" directory etc. is a bit troublesome, I
would rather have some Scheme code do this with: upstream git url,
commit selector range or not, with hash checking like origins.

Is that possible?

Thank you


signature.asc
Description: This is a digitally signed message part

squid package vulnerable to CVE-2021-28116

[Léo Le Bouter]

CVE-2021-28116  09.03.21 23:15
Squid through 4.14 and 5.x through 5.0.5, in some configurations,
allows information disclosure because of an out-of-bounds read in WCCP
protocol data. This can be leveraged as part of a chain for remote code
execution as nobody.

Upstream did not release a patch yet. CVE entry to be monitored for a
fix.

https://www.zerodayinitiative.com/advisories/ZDI-21-157/ - says it is a
low impact issue.


signature.asc
Description: This is a digitally signed message part

Re: Opposition to new single-letter package name "t"

[Mark H Weaver]

Nicolas Goaziou  writes:

> Raghav Gururajan  writes:
>
>> Makes sense. I have attached the patch.
>
> Applied. Thank you.
>
> Sorry for the mess!

No worries, it's no mess at all.  Thanks to Nicolas and Raghav for
taking care of renaming it, and also to everyone who contributed to the
bike-shed discussion :)

   Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Ricardo, Chris,

Ricardo Wurmus  writes:
> We have “guix graph --path from to”, but frustratingly it won’t cover
> build system packages, [...]

Chris Marusich  writes:
> The "--paths" option with "--type=bag" shows you this (results
> below were, of course, taken before applying the patch above):
>
> --8<---cut here---start->8---
> marusich@suzaku:~/repos/guix$ ./pre-inst-env guix graph --type=bag --path 
> gtk+ rust
> gtk+@3.24.24
> gdk-pixbuf+svg@2.42.2
> librsvg@2.50.3
> rust@1.49.0
> --8<---cut here---end--->8---

Thanks to you both for pointing this out!

 Regards,
   Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Chris Marusich  writes:

> Actually, I've realized that that patch wasn't quite right.  I've
> attached a corrected version to this email.
>
> Although the %current-system parameter will look like "x86_64-linux"
> because it's a Guix system name, the %current-target-system parameter
> will look like "x86_64-linux-gnu" (or whatever the user happens to
> supply, e.g. via the --target option of "guix build") because it's a GNU
> triplet.

Indeed, good catch.

> The attached patch accomplishes the same goal as before, but
> it uses string-prefix? to check whether we're building for an x86_64
> machine, rather than matching on an exact string.

Your proposed patch looks good to me, as a temporary measure to make
Guix a bit more usable on non-Intel systems until we get Rust working on
them.  I would be in favor of pushing it to 'core-updates'.

 Thanks!
   Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Christopher Baines  writes:
> I've gone ahead and pushed the patch I proposed to master, I think it's
> a step forward.

On second thought, maybe you have the right idea.  It's becoming
increasingly clear that we cannot continue to postpone fixing our Rust
packages on non-Intel platforms.  We will need to make this a priority,
and your patch is a step toward that goal.  Also, the Rust build on
'aarch64-linux' got further than I expected, as shown in
.

 Thanks,
   Mark

Re: Release on April 18th?

[Vincent Legoll]

Hello Chris,

I'm all for that, what can I do to help ?

I don't have a Talos, though...

So only cross- or emulated- stuff...

Willing to help, but needs directions.

-- 
Vincent Legoll

Re: Release on April 18th?

[Chris Marusich]

Hi,

zimoun  writes:

> Is it doable to have core-updates merged in the next weeks?  Or not at
> all.

Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
port; see below for details.

The wip-ppc64le branch, which ports Guix to an architecture that can be
run on freedom-friendly POWER9 systems like the Talos II and Blackbird
from Raptor Computing Systems, is "almost" done, and I would really like
to try to get it into the next release if possible.

However, there is still some work to do, and I wouldn't necessarily want
to block the release just for sake of the powerpc64le-linux port.

In fact, the wip-ppc64le branch was "fully functional" for a little
while.  By "fully functional," I mean that "make check" succeeded, "make
guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
could be installed on a fresh Debian ppc64le system, the binary could
successfully build and run GNU Hello, and the binary could successfully
run "guix pull", and the newly installed "guix pull" could do the same.

However, that was using glibc 2.31.  On core-updates, glibc has been
updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
must upgrade GCC from 7 to 8 (or greater), and that is what we have done
on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
through build failures that occurred as a result, but I'm optimistic that
we can resolve those in the coming weeks.

The real question, I think, is when do we plan to upgrade GCC on
core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
require GCC 8 or greater, since core-updates is now using glibc 2.32.

-- 
Chris


signature.asc
Description: PGP signature

Re: Opposition to new single-letter package name "t"

[Nicolas Goaziou]

Hello,

Raghav Gururajan  writes:

> Makes sense. I have attached the patch.

Applied. Thank you.

Sorry for the mess!

Regards,
-- 
Nicolas Goaziou

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[zimoun]

Hi Tobias,

On Tue, 9 Mar 2021 at 18:14, Tobias Geerinckx-Rice  wrote:

> For most upstreams whether or not dashes were in vogue[0] when
> they named their project is literally arbitrary.  We'd penalise
> many other packages like texlive-todonotes, open{ssh,vpn,*},
> ktexteditor, r-performanceanalytics, qutebrowser, ...  It's not a
> net win.

I am not sure to understand what you mean here.

> If I might pet my own peeve, I think clever heuristics appear
> necessary in part because %package-metrics grossly overscores
> package names.  Rank them *below* synopsis & description--which
> will contain the name anyway--with a metric of 1, maybe 2.  Enough
> to keep the relevant stuff above the irrelevant stuff (python- >
> ruby-, etc.) without distorting things as they do now.

I really did math, i.e., write the scoring function, something like
(to simplify)

  score(package, query) = sum_{term in query} (wS cS + wD cD + w)

where wS, wD, wN are the weights for synopsis, description, name and
cS, cD, cN are the number of occurrences.  Then for example computed
Jacobian and so on in order to see the relation between the weights w*
and the number of occurrence c*.  Or I gave a look at the condition to
have:

  score(package_1, query) = score(package_2, query)

and basically, using the linear relevance as it is currently, the
weight (%package-metrics) are not so bad; you cannot find a really
better heuristic.  Another conclusion is: it really depends on the
number of terms the query has.  Basically, if you type one term, you
know what you are looking for and it is the package name but your are
not sure.  For more terms, currently the result strongly depends on
the quality of the synopsis and description.  For instance, try:

  guix search gnu compiler

and compare the description of all the packages with a relevance
higher than 4 (gcc-toolchain).  Well, with a linear and local scoring
function as it is currently, you cannot improve much, IMHO.  By local,
I mean only considering the words of one package independently of the
words of other packages.  That's why TF-IDF [1].  For a concrete
example, see 
.
  Once you have a TF-IDF, the natural scoring is BM25 [2].  Well, it
is included in Xapian and there is a patch by Arun using Xapian as a
backend for "guix search", see
.  It is missing a good
evaluation, i.e., queries examples.  I have asked such examples (what
query an user type and what they are expecting) here

but no one replied and since I am enough comfortable with searching
with Guix and other bugs are more annoying for my workflow, I moved to
other stuff.

For another discussion on the topic, see
.


Since 2020, I have read pieces of "word embdeding" (part of vogue[0]
graph neural nets), and I think it would a great project: first some
vogue[0] stats to evaluate how the packages cluster together, i.e., is
emacs-foo closer to emacs-bar or python-foo?  and second depending on
the results, implement such embdeding to improve "guix search".  The
first means use Julia (or package PyTorch for Guix ;-)) and the second
means implement targeting Guile (it could awesome to have an
equivalent to Zygote [3,4] for Guile).

0: Not a joke. :-)
1: 
2: 
3: 
4: 


Cheers,
simon

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[Tobias Geerinckx-Rice]

Taylan,

Taylan Kammer 写道：
This discussion made me realize that "guix search" might benefit 
from
the following improvement though:  I think the relevance score 
for a
search result should be increased significantly if the searched 
word is
a standalone (not substring) part of a package's name when the 
name is

split into dash-separated words.


Thanks for remembering ‘guix search’!  It didn't occur to me at 
all.


For most upstreams whether or not dashes were in vogue[0] when 
they named their project is literally arbitrary.  We'd penalise 
many other packages like texlive-todonotes, open{ssh,vpn,*}, 
ktexteditor, r-performanceanalytics, qutebrowser, ...  It's not a 
net win.


If I might pet my own peeve, I think clever heuristics appear 
necessary in part because %package-metrics grossly overscores 
package names.  Rank them *below* synopsis & description--which 
will contain the name anyway--with a metric of 1, maybe 2.  Enough 
to keep the relevant stuff above the irrelevant stuff (python- > 
ruby-, etc.) without distorting things as they do now.


Kind regards,

T G-R

[0]: Not a joke.


signature.asc
Description: PGP signature

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[zimoun]

Hi,

On Tue, 9 Mar 2021 at 14:37, Taylan Kammer  wrote:

> This discussion made me realize that "guix search" might benefit from
> the following improvement though:  I think the relevance score for a
> search result should be increased significantly if the searched word is
> a standalone (not substring) part of a package's name when the name is
> split into dash-separated words.

Currently, perfect match uses the weight of 5 and substring match uses
1.  You are proposing to add something between, say 3, for perfect
match on substring delimited by dash.  Why not.

> For instance, the package "emacs-hl-todo" should get a much higher score
> than "emacs-mastodon" when searching for "todo".  Currently the Mastodon
> one has score 11 and the todo one only 9.

Here how the relevance score reads:

query: todo
| field   |  emacs-hl-todo |  emacs-mastodon | weight |
|-++-+|
| name|  1 |   1 |  4 |
| synopsis|  1 |   1 |  3 |
| description |  1 |   2 |  2 |
|-++-+|
| total   | 1*4+1*3+2*1= 9 | 1*4+1*3+2*2= 11 ||

Therefore, something looks wrong here: the score for emacs-hl-todo
should be 1*4+1*5*3+1*5*2= 29 because the term TODO should be
considered as a perfect match for the query todo.


> The same thing goes for the synopsis and description of the package, but
> with respectively lower increases to the score.  (I.e. name > synopsis >
> description.)

Your proposal just needs the tweak of 'score' in the function
'relevance' from (guix ui).  The weight for the field is another part
(see %package-metrics in (guix ui))


> Handling of plurals like "todos" instead of "todo" would also be great
> but could be left to a later step.

The issue with this is that it is strongly connected to the language.
Therefore, an external library implementing Natural Language should be
added.  And I am not convinced it is worth at the CLI level.


> Any thoughts about / objections to this idea?  To be honest I haven't
> checked if there's maybe already a bug report about this.

If you are interested, there is such discussion in this heavy thread:



And the 'relevance' function could be improved, for sure.  For
example, I proposed TF-IDF here:



and I did some tiny math calculs (optimization) to compute "better"
relevance weight (%package-metrics) but the current choice are not so
bad and simple enough. :-)

Previous week, I have started to examine a strategy based on
Bag-Of-Word and some word embedings strategies; mimicking a simple
autoencoder [1] such as Word2Vec [2] but since the Guile tools are
poor in this field, I have started to use Julia first to look if it is
worth to implement or not such solution.  My idea is to see how the
packages cluster based on the synopsis+description information, then
ideally based on this, we should be able to define package similarity
and "synonyms".

Well, if you are student and you are looking for a cool project about
Machine Learning and Data Science, ping me. :-)

1: 
2: 


Cheers,
simon

Search improvements (Was: Opposition to new single-letter package name "t")

[Taylan Kammer]

On 09.03.2021 12:38, Tobias Geerinckx-Rice wrote:
> Raghav Gururajan 写道：
>> Since, we already mention "todo list manager" in description, I think
>> "ti-cli" is better.
> 
> It says nothing about the package and does not uniquely identify it:
> 
>  bundlerApp {
>    pname = "t";
>    [...]
> 
>    meta = with lib; {
>  description = "A command-line power tool for Twitter";
>  homepage    = "http://sferik.github.io/t/;;
>  [...]
>    };
>  }
> 
> It's “t”!  It's “CLI”!  It's... a totally different package[0]!
> 
> Please: t-todo-manager (t-todo-whatever, I don't care) or
> $something_a_mainstream_distro_uses, but not yet another bikeshedded
> unique name, fun as they are to do.
> 
> Kind regards,
> 
> T G-R
> 
> [0]:
> https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix
> 

I agree that t-todo-manager is the superior choice.  (With a secondary
preference for "t-todo-list-manager".)

This discussion made me realize that "guix search" might benefit from
the following improvement though:  I think the relevance score for a
search result should be increased significantly if the searched word is
a standalone (not substring) part of a package's name when the name is
split into dash-separated words.

For instance, the package "emacs-hl-todo" should get a much higher score
than "emacs-mastodon" when searching for "todo".  Currently the Mastodon
one has score 11 and the todo one only 9.

The same thing goes for the synopsis and description of the package, but
with respectively lower increases to the score.  (I.e. name > synopsis >
description.)

Handling of plurals like "todos" instead of "todo" would also be great
but could be left to a later step.

Any thoughts about / objections to this idea?  To be honest I haven't
checked if there's maybe already a bug report about this.


- Taylan

Re: Opposition to new single-letter package name "t"

[Raghav Gururajan]

Hi Tobias!

Please: t-todo-manager (t-todo-whatever, I don't care) or 
$something_a_mainstream_distro_uses, but not yet another bikeshedded 
unique name, fun as they are to do.


Makes sense. I have attached the patch.

Regards,
RG.
From 04066b34518fc01290f12093910387e10c04fa08 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan 
Date: Tue, 9 Mar 2021 07:37:28 -0500
Subject: [PATCH] gnu: Rename "t" to "t-todo-manager".

* gnu/packages/task-management.scm (t): Rename to t-todo-manager.
---
 gnu/packages/task-management.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/task-management.scm b/gnu/packages/task-management.scm
index 9667df6030..3edf01a9f5 100644
--- a/gnu/packages/task-management.scm
+++ b/gnu/packages/task-management.scm
@@ -44,12 +44,12 @@
   #:use-module (guix build-system meson)
   #:use-module (guix build-system python))
 
-(define-public t
+(define-public t-todo-manager
   ;; Last release is more than 10 years old.  Using latest commit.
   (let ((changeset "89ad444c000b")
 (revision "97"))
 (package
-  (name "t")
+  (name "t-todo-manager")
   (version (git-version "1.2.0" revision changeset))
   (source
(origin
-- 
2.30.1



OpenPGP_signature
Description: OpenPGP digital signature

Re: Hurd substitute availability (27.5%) and next steps?

[Svante Signell]

On Mon, 2021-03-08 at 22:47 +, Christopher Baines wrote:
> Vincent Legoll  writes:

> > > often I'll be unable to SSH in
> > 
> > Couldn't you get a console from a virtual serial port from the VM ?
> 
> Maybe, I also want to look at getting the serial port output logged
> to a file (if that's even possible).

Hello, this runs a qemu image with serial output in a log file:

Add to grub.cfg in the hurd image:
+ serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1
+ terminal_input serial
+ terminal_output serial

- multiboot /boot/gnumach.gz root=device:hd0s1 -s --crash-debug
+ multiboot /boot/gnumach.gz root=device:hd0s1 console=com0 -s --crash-
debug

Running with graphic and serial console, log file in serial.log:
qemu-system-x86_64 -chardev
stdio,id=char0,logfile=serial.log,signal=off -serial chardev:char0 --
enable-kvm -m 2048 hurd-cross-serial.img

Note: The mailer wraps the command lines.

Thanks!

Re: Opposition to new single-letter package name "t"

[Ricardo Wurmus]

Julien Lepiller  writes:

> Well, python-t should be unique, right? There can't be a collision on pypi. 
> Well, except if that package is not on pypi?

Since it’s not a library we shouldn’t name it “python-”.

I agree with Tobias and others who suggested “t-todo-manager” or
similar; not “t-cli”, please.

-- 
Ricardo

Re: Opposition to new single-letter package name "t"

[Julien Lepiller]

Well, python-t should be unique, right? There can't be a collision on pypi. 
Well, except if that package is not on pypi?

Le 9 mars 2021 06:38:04 GMT-05:00, Tobias Geerinckx-Rice  a 
écrit :
>Raghav Gururajan 写道：
>> Since, we already mention "todo list manager" in description, I 
>> think 
>> "ti-cli" is better.
>
>It says nothing about the package and does not uniquely identify 
>it:
>
>  bundlerApp {
>pname = "t";
>[...]
>
>meta = with lib; {
>  description = "A command-line power tool for Twitter";
>  homepage= "http://sferik.github.io/t/;;
>  [...]
>};
>  }
>
>It's “t”!  It's “CLI”!  It's... a totally different package[0]!
>
>Please: t-todo-manager (t-todo-whatever, I don't care) or 
>$something_a_mainstream_distro_uses, but not yet another 
>bikeshedded unique name, fun as they are to do.
>
>Kind regards,
>
>T G-R
>
>[0]: 
>https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix

Re: Opposition to new single-letter package name "t"

[Tobias Geerinckx-Rice]

Raghav Gururajan 写道：
Since, we already mention "todo list manager" in description, I 
think 
"ti-cli" is better.


It says nothing about the package and does not uniquely identify 
it:


 bundlerApp {
   pname = "t";
   [...]

   meta = with lib; {
 description = "A command-line power tool for Twitter";
 homepage= "http://sferik.github.io/t/;;
 [...]
   };
 }

It's “t”!  It's “CLI”!  It's... a totally different package[0]!

Please: t-todo-manager (t-todo-whatever, I don't care) or 
$something_a_mainstream_distro_uses, but not yet another 
bikeshedded unique name, fun as they are to do.


Kind regards,

T G-R

[0]: 
https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix


signature.asc
Description: PGP signature

Re: Opposition to new single-letter package name "t"

[Leo Prikler]

Am Dienstag, den 09.03.2021, 01:08 -0500 schrieb Raghav Gururajan:
> > I like Mark's suggestion of "t-todo-list-manager" as well as
> > Raghav's suggestion for "t-cli"; in that order.
> > 
> > Either name sounds good to me, though.
> 
> Cool!
> 
> Since, we already mention "todo list manager" in description, I
> think 
> "ti-cli" is better.
I personally disagree.  Let's assume we do have a collision and the
other program also happens to be a CLI – then we're back to square one.
Also, assuming it is a GUI instead of a CLI and the package can be
named "t-gui", there will be the implication that the two are related
when they need not be.

On a related note, the description treads awfully close to advertising
territory.

I'd say "t-todo-list-manager", perhaps shortened to "t-todos". 
Alternatively, we might borrow some bits from the go-build-system
convention and name it com-stevelosh-t.

Regards,
Leo

Re: Joining the Guix family

[Tobias Geerinckx-Rice]

Lars-Dominik Braun 写道：
I’m mainly working on Python and R packaging as part of my job 
at
leibniz-psychology.org. Apart from that I’ll be looking into 
improving
package quality, for example through my changes to 
python-build-system.


Sounds wonderful.  Welcome, Lars!

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: [Outreachy] Internship ending

[Magali Lemes]

Hi!

On 03/03/2021 11:05, Ludovic Courtès wrote:

Hi Magali,

Magali Lemes  skribis:


My Outreachy internship officially ends on March 2nd, next
Tuesday. It's been wonderful contributing to Guix, and I have learned
quite a lot in these last three months. This community is truly
welcoming, and the project is amazing.
Having said that, I would like to inform that you can see what I
worked on on the 'wip-guix-log' branch and also on my Gitlab
repository . Invoking './pre-inst-env
guix git log --help' from there should tell you all the options and
what they do. In a previous email, I detailed the features as well:
. Any
review and/or feedback is appreciated :D

Thank you, it was nice to have you on board!  Hopefully together with
Simon, Gábor (and maybe you!) we can review your work to integrate it
soonish.  There’s demand for this tool!


Fine, please let me know the next steps for reviewing and integrating it.



I hope it’s been a useful and pleasant experience and that it will allow
you to contribute to Guix or other free software projects in the future.
I think you’ve demonstrated the technical and social skills to be
successful at that.


It certainly was an awesome experience. Getting to know Guix and the 
people was definitely great.




Good luck with your future endeavors!


Thank you very much!


Cheers,

Magali

Re: Hurd substitute availability (27.5%) and next steps?

[Efraim Flashner]

On Tue, Mar 09, 2021 at 07:57:33AM +, Christopher Baines wrote:
> 
> jbra...@dismail.de writes:
> 
> > I'd be happy to reformat this as a guix blog post, unless you'd rather
> > I not.
> 
> I think another blog post on the Hurd would be nice, although I'm not
> sure what the main takeaway should be. The substitute availability stat
> I led this email thread with doesn't really convey to a wider audience,
> since they're substitutes from my test substitute server setup.

At a minimum it keeps everyone knowing that we're still working on it. I
had a blog post which was mostly a list of packages which still weren't
building on aarch64-linux a few years ago. It'd also be a good way to
group together some of the know-how on how to configure a childhurd with
swap and other stuff.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Joining the Guix family

[Efraim Flashner]

Welcome!

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: guix environment --profile with --ad-hoc

[Lars-Dominik Braun]

Hi Pierre,

> Do you have a link?
sorry, I meant, I wrote the patch that added the --profile switch, see
https://issues.guix.gnu.org/46291

> I'd love to see this merged! :)
The patch above is already merged.

Cheers,
Lars



signature.asc
Description: PGP signature

Re: core-updates: Emacs is only supported on x86_64-linux?

[Chris Marusich]

Chris Marusich  writes:

> How about a patch like the following - would it be acceptable to you?

Actually, I've realized that that patch wasn't quite right.  I've
attached a corrected version to this email.

Although the %current-system parameter will look like "x86_64-linux"
because it's a Guix system name, the %current-target-system parameter
will look like "x86_64-linux-gnu" (or whatever the user happens to
supply, e.g. via the --target option of "guix build") because it's a GNU
triplet.  The attached patch accomplishes the same goal as before, but
it uses string-prefix? to check whether we're building for an x86_64
machine, rather than matching on an exact string.

-- 
Chris
From 0eb5583f243a399293ae52a3e78ccf7d3a153a47 Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Mon, 8 Mar 2021 23:13:39 -0800
Subject: [PATCH] gnu: Restore emacs' supported systems.

Recently, librsvg was updated to depend upon rust.  That change inadvertently
restricted the "supported" systems of emacs (among other package) to
x86_64-linux only, since that is the only system declared in the rust
package's list of supported systems.  This unintentionally made emacs
unavailable on all other systems.

This change fixes that by removing the rust dependency from some packages.
The packages remain unchanged from the perspective of an x86_64-linux system,
but from the perspective of other systems, the packages are now supported
again (albeit without certain optional SVG features).

* gnu/packages/gtk.scm (gtk+, gtk+-2)[propagated-inputs]: If compiling for
x86_64, use gdk-pixbuf+svg as the "gdk-pixbuf" input, as usual.  Otherwise,
use gdk-pixbuf, which avoids adding librsvg (thus rust) to the closure of
inputs.  Note that both gtk+ and gtk+-2 are in the transitive closure of
inputs of emacs, so these two changes are necessary.
* gnu/packages/emacs (emacs)[inputs]: If compiling for x86_64, add librsvg to
the inputs, as usual.  Otherwise, do not add it, which avoids adding rust to
the closure of inputs.
---
 gnu/packages/emacs.scm |  8 +++-
 gnu/packages/gtk.scm   | 14 --
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae0..fe5b3b25b3d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg)
   #:use-module (guix utils)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1))
 
 (define-public emacs
@@ -236,7 +237,12 @@
("libpng" ,libpng)
("zlib" ,zlib)
 
-   ("librsvg" ,librsvg)
+   ;; librsvg is an optional dependency that pulls in rust.  Rust is not
+   ;; supported well on every architecture yet.
+   ,@(if (string-prefix? "x86_64" (or (%current-target-system)
+  (%current-system)))
+ `(("librsvg" ,librsvg))
+ '())
("libxpm" ,libxpm)
("libxml2" ,libxml2)
("libice" ,libice)
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index f458366fb6a..d396425d9a6 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -776,7 +776,12 @@ is part of the GNOME accessibility project.")
(outputs '("out" "bin" "doc"))
(propagated-inputs
 `(("atk" ,atk)
-  ("gdk-pixbuf" ,gdk-pixbuf+svg)
+  ;; SVG support is optional and requires librsvg, which pulls in rust.
+  ;; Rust is not supported well on every architecture yet.
+  ("gdk-pixbuf" ,(if (string-prefix? "x86_64" (or (%current-target-system)
+  (%current-system)))
+ gdk-pixbuf+svg
+ gdk-pixbuf))
   ("pango" ,pango)))
(inputs
 `(("cups" ,cups)
@@ -843,7 +848,12 @@ application suites.")
(propagated-inputs
 `(("at-spi2-atk" ,at-spi2-atk)
   ("atk" ,atk)
-  ("gdk-pixbuf" ,gdk-pixbuf+svg)
+  ;; SVG support is optional and requires librsvg, which pulls in rust.
+  ;; Rust is not supported well on every architecture yet.
+  ("gdk-pixbuf" ,(if (string-prefix? "x86_64" (or (%current-target-system)
+  (%current-system)))
+ gdk-pixbuf+svg
+ gdk-pixbuf))
   ("libepoxy" ,libepoxy)
   ("libxcursor" ,libxcursor)
   ("libxi" ,libxi)
-- 
2.26.2



signature.asc
Description: PGP signature

Re: Joining the Guix family

[Pierre Neidhardt]

Welcome!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature