On Thu, 2021-04-15 at 10:00 +, bo0od wrote:
> Guix need to improve itself when first time initiated, Please check
> other projects like NixOS,Triskel,Mint,Ubuntu...etc
>
>
> If you dont like that live graphical gui access, then do it as debian
> is
> doing it which give you proper gui
On Thu, 2021-04-08 at 20:01 -0400, Leo Famulari wrote:
> On Tue, Apr 06, 2021 at 06:51:47PM -0400, Leo Famulari wrote:
> > Yeah. Given this report, we could also just build Syncthing with
> > the
> > bundled source code, which is freely licensed.
>
> I've attached the patch.
I tested this patch
Fixed by 2b605ef3b145ec136530f08ee7aa27382aa64b46
signature.asc
Description: This is a digitally signed message part
CVE-2021-21404 06.04.21 22:15
Syncthing is a continuous file synchronization program. In Syncthing
before version 1.15.0, the relay server `strelaysrv` can be caused to
crash and exit by sending a relay message with a negative length field.
Similarly, Syncthing itself can crash for the same
On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
> Hi Léo,
>
> Léo Le Bouter writes:
>
> > I think that probably replacing arbitrary paths in built binaries
> > is a
> > risky and maybe unreliable engineering choice and that mechanisms
> > inside kernels should be preferred to give
Read:
https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/
I have not had time to investigate deeply, posting here so the info is
not lost. I have already fixed one issue related to perl-data-validate-
ip in 8ec03ed5475ca7919a7d11541ff8cbf33a9ffe67, but it seems there's
I think that probably replacing arbitrary paths in built binaries is a
risky and maybe unreliable engineering choice and that mechanisms
inside kernels should be preferred to give processes a different view
of the file system (retaining the path but changing the contents of the
folder).
OTOH,
CVE-2021-30046 15:15
VIGRA Computer Vision Library Version-1-11-1 contains a segmentation
fault vulnerability in the impex.hxx read_image_band() function, in
which a crafted file can cause a denial of service.
Upstream issue: https://github.com/ukoethe/vigra/issues/494
No fix provided yet.
I am no expert cryptographer, it is likely that if I try backporting
such patches I will get something wrong that introduces more flaws.
https://security-tracker.debian.org/tracker/CVE-2021-20305 - no patch
backported yet
https://packages.ubuntu.com/source/focal/nettle - no patch backported
upstream released 2.11 which fixed the issue.
Update to 2.11 pushed as 45136b3673bcdba21fa0d1fd6edb3d388a645fcc
signature.asc
Description: This is a digitally signed message part
Upstream created and merged a probable patch:
https://github.com/pupnp/pupnp/pull/306
Reporter still needs to confirm if it fixes the issue.
signature.asc
Description: This is a digitally signed message part
Still no fix available from upstream (unclear)
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-04-06 at 00:17 +1000, Ben Sturmfels wrote:
> On Thu, 01 Apr 2021, Ben Sturmfels wrote:
>
> > 7. Work out why H264 support is missing.
>
> This is now fixed MediaGoblin's master branch guix-env.scm by adding
> gst-libav to propagated inputs.
Hello!
I suggest not using
Fixed in dda88cda120d75f7d139e54367c0d76e574091dc
signature.asc
Description: This is a digitally signed message part
Hello!
Like 'guix edit hello' we could have 'guix system edit screen-locker'
for easy access to customize services.
What do you think? Is this hard to do?
Léo
signature.asc
Description: This is a digitally signed message part
It seems running 'make clean' then 'make check-system' again solved the
issue. Probably some build system inconsistency issue.
signature.asc
Description: This is a digitally signed message part
Hello!
$ ./pre-inst-env guix describe
Git checkout:
repository: /home/lle-bout/src/guix
branch: master
commit: 8d89d3c9bf7cacd9c79b4aacf348044d4fe7800b
$ make check-system
Compiling Scheme modules...
ice-9/eval.scm:142:16: In procedure compile-top-call:
error: channel-source->package:
To me, that last patch is ready to merge.
Please push if you feel that's OK too, don't wait for me!
Thanks!
signature.asc
Description: This is a digitally signed message part
Fixes CVE-2021-22876 and CVE-2021-22890.
* gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/curl.scm (curl/fixed): New variable. Apply patch.
(curl)[replacement]: Graft.
---
gnu/local.mk
Fixes CVE-2021-22876 and CVE-2021-22890.
* gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/curl.scm (curl/fixed): New variable. Apply patch.
(curl)[replacement]: Graft.
---
gnu/local.mk
On Fri, 2021-04-02 at 14:22 -0400, Leo Famulari wrote:
>
> Can we try grafting an "upgrade" to 7.76.0? In my experience, most
> curl
> upgrades are graftable.
>
> Curl's developers are very careful with their ABI and even maintain
> their own page on the subject:
* gnu/packages/patches/curl-CVE-2021-22876.patch,
gnu/packages/patches/curl-CVE-2021-22890.patch: New patches.
* gnu/local.mk (dist_patch_DATA): Register them.
* gnu/packages/curl.scm (curl): Apply patches.
---
gnu/local.mk | 2 +
gnu/packages/curl.scm
curl-CVE-2021-22876.patch was rebased onto 7.74.0, but curl-CVE-2021-22890.patch
does not apply and please I need help rebasing it, it looks quite complex.
I pushed an upgrade of curl to 7.76.0 which has been much much easier to
core-updates already as
CVE-2021-22890 01.04.21 20:15
curl 7.63.0 to and including 7.75.0 includes vulnerability that allows
a malicious HTTPS proxy to MITM a connection due to bad handling of TLS
1.3 session tickets. When using a HTTPS proxy and TLS 1.3, libcurl can
confuse session tickets arriving from the HTTPS proxy
CVE-2021-28165 01.04.21 17:15
In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and
11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a
large invalid TLS frame.
CVE-2021-28164 01.04.21 17:15
In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default
compliance
Another:
CVE-2021-20296 01.04.21 16:15
A flaw was found in OpenEXR in versions before 3.0.0-beta. A crafted
input file supplied by an attacker, that is processed by the Dwa
decompression functionality of OpenEXR's IlmImf library, could cause a
NULL pointer dereference. The highest threat from
CVE-2021-29938 07:15
An issue was discovered in the slice-deque crate through 2021-02-19 for
Rust. A double drop can occur in SliceDeque::drain_filter upon a panic
in a predicate function.
Upstream PR: https://github.com/gnzlbg/slice_deque/pull/91
I suggest we wait for merge then update our
CVE-2021-29939 07:15
An issue was discovered in the stackvector crate through 2021-02-19 for
Rust. There is an out-of-bounds write in StackVec::extend if size_hint
provides certain anomalous data.
No fix released upstream yet:
https://github.com/Alexhuszagh/rust-stackvector/issues/2
Out of
Another wave it seems:
CVE-2021-3479 31.03.21 16:15
There's a flaw in OpenEXR's Scanline API functionality in versions before
3.0.0-beta. An attacker who is able to submit a crafted file to be processed by
OpenEXR could trigger excessive consumption of memory, resulting in an impact
to
I asked the maintainer to fix the issues because they were unfixed
since a while, they have done so recently:
https://git.savannah.gnu.org/cgit/cflow.git/commit/?id=b9a7cd5e9d4efb54141dd0d11c319bb97a4600c6
They have not made a recently, also it seems they fixed other issues
that could be
CVE-2021-3474 30.03.21 20:15
There's a flaw in OpenEXR in versions before 3.0.0-beta. A crafted
input file that is processed by OpenEXR could cause a shift overflow in
the FastHufDecoder, potentially leading to problems with application
availability.
Fix:
Hello!
Simon,
I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your
patch. Thank you for it. Let's watch for upstream zstd fix also.
I pushed 9feef62b73e284e106717a386624d6da90750a3d to master.
Ubuntu released a patch in the mean time, so while we couldnt make such
patch in a
On Sun, 2021-03-28 at 18:25 +0200, Ludovic Courtès wrote:
> When updating the ‘guix’ package, what you need to run is:
>
> ./pre-inst-env guix build guix
>
> It’s similar to other packages.
>
> In general, we update it when there are changes to the daemon and its
> helper programs (‘guix
On Sat, 2021-03-27 at 09:27 -0400, Mark H Weaver wrote:
> Your patch looks good to me, but I've just posted an alternative
> patch
> set to 'guix-devel' which should enable us to keep ImageMagick
> up-to-date without grafting, and which fixes this security flaw and
> more.
>
>
On Sat, 2021-03-27 at 00:12 +0100, Maxime Devos wrote:
> This patch seems about right to me. However,
>
> $ guix lint -c cve imagemagick
> gnu/packages/imagemagick.scm:132:2: imagemagick@6.9.12-2g: probably
> vulnerable to CVE-2021-20176, CVE-2021-20243, CVE-2021-20244, CVE-
> 2020-25663,
Another:
CVE-2021-20284 18:15
A flaw was found in GNU Binutils 2.35.1, where there is a heap-based
buffer overflow in _bfd_elf_slurp_secondary_reloc_section in elf.c due
to the number of symbols not calculated correctly. The highest threat
from this vulnerability is to system availability.
CVE-2021-20193 18:15
A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw
allows an attacker who can submit a crafted input file to tar to cause
uncontrolled consumption of memory. The highest threat from this
vulnerability is to system availability.
Patch available here:
CVE-2021-20197 18:15
There is an open race window when writing output in the following
utilities in GNU binutils version 2.35 and earlier:ar, objcopy, strip,
ranlib. When these utilities are run as a privileged user (presumably
as part of a script updating binaries across different users), an
* gnu/packages/patches/imagemagick-CVE-2020-27829.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/imagemagick.scm (imagemagick/fixed): Apply patch to existing
graft.
---
gnu/local.mk | 1 +
gnu/packages/imagemagick.scm
CVE-2020-27829 18:15
A heap based buffer overflow in coders/tiff.c may result in program
crash and denial of service in ImageMagick before 7.0.10-45.
Upstream patch available at
https://github.com/ImageMagick/ImageMagick/commit/6ee5059cd3ac8d82714a1ab1321399b88539abf0
Not yet backported to 6.x
On Thu, 2021-03-25 at 21:23 -0400, Mark H Weaver wrote:
>
> Just a reminder that, just as with 'mysql/fixed', 'sqlite/fixed'
> should
> *not* use 'package/inherit', since the package you're defining is the
> replacement for the package you're inheriting from.
>
> Otherwise, it looks good to me!
On Thu, 2021-03-25 at 21:16 -0400, Mark H Weaver wrote:
>
> Looks good to me. Please push. Thank you!
>
> Mark
Thank you for the review, pushed as
52c8d07a4f7033534a71ac7efeec21a65d35c125.
signature.asc
Description: This is a digitally signed message part
$ ./pre-inst-env guix refresh exiv2
gnu/packages/image.scm:1343:2: warning: 'generic-html' updater failed
to determine available releases for exiv2
It seems applying this patch does not help either:
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index d04a247976..8ede48eea5 100644
On Fri, 2021-03-26 at 00:24 +0100, Ludovic Courtès wrote:
> Léo Le Bouter skribis:
>
> > Full log: https://ci.guix.gnu.org/build/117996/log/raw
>
> Speaking of which: please always build packages before pushing. :-)
>
> Thanks,
> Ludo’.
I ran 'guix pull' but turns out that wasnt sufficient.
v3 tested and builds fine:
$ ./pre-inst-env guix build mariadb
/gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev
/gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib
/gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-mariadb-10.5.8
Since we don't have PoC, I can't verify the
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
On Fri, 2021-03-19 at 12:35 +0100, zimoun wrote:
> Instead of grafting, I would fix first check the compatibility
> between
> mariadb and zstd. Because mariadb@10.5.8 does not build with
> zstd@1.4.9, at least on my machine.
Can you post build logs and repro scenario? mariadb@10.5.8 built fine
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
FAIL: tests/print
=
test-name: simple package
location: /tmp/guix-build-guix-1.2.0-18.86dd54f.drv-
0/source/tests/print.scm:70
source:
+ (test-equal
+ "simple package"
+ `(define-public test ,pkg-source)
+ (package->code pkg))
expected-value: (define-public test (package
I could test the graft with GNU Guix's test suite by manually replacing
the sqlite input with sqlite/fixed like so:
diff --git a/gnu/packages/package-management.scm
b/gnu/packages/package-management.scm
index 888f54322d..70f5c2dad3 100644
--- a/gnu/packages/package-management.scm
+++
It seems this is due to guile 3.0.5, GNU Shepherd 0.8.1 does not work
with it, it works with guile 3.0.2 however.
Thanks to Efraim on IRC for hints.
It would be great if people knowledgeable with Scheme, GNU Shepherd and
Guile could fix it, it blocks GNOME upgrade work on top of core-
updates.
One more:
CVE-2021-20227 23.03.21 18:15
A flaw was found in SQLite's SELECT query functionality (src/select.c).
This flaw allows an attacker who is capable of running SQL queries
locally on the SQLite database to cause a denial of service or possible
code execution by triggering a
CVE-2021-20270 23.03.21 18:15
An infinite loop in SMLLexer in Pygments
versions 1.5 to 2.7.3 may lead to denial of service when performing
syntax highlighting of a Standard ML (SML) source file, as demonstrated
by input that only contains the "exception" keyword.
Upstream version 2.8.1 is not
I pushed a9d540cfa87ef3a5de3296188f650fb0d037efbd on core-updates, how
to fix it on master considering the amount of dependents remains to be
agreed on.
signature.asc
Description: This is a digitally signed message part
* gnu/packages/xml.scm (java-mxparser): New variable.
---
gnu/packages/xml.scm | 28
1 file changed, 28 insertions(+)
diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index 2a72fc6ad2..96287b3174 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@
Upstream has made a release: 1.4.16 - which fixes all the issues,
following is an unfinished patchset that fixes the issues, java-
mxparser package does not build and help from some more experienced
Java packagers is welcome to fix and push this patchset.
signature.asc
Description: This is a
Fixes CVE-2021-21341, CVE-2021-21342, CVE-2021-21343, CVE-2021-21344,
CVE-2021-21345, CVE-2021-21346, CVE-2021-21347, CVE-2021-21348,
CVE-2021-21349, CVE-2021-21350 and CVE-2021-21351.
* gnu/packages/xml.scm (java-xstream): Update to 1.4.16.
[inputs]: Replace java-xpp3 with java-mxparser, the
CVE-2021-28957 21.03.21 06:15
lxml 4.6.2 places the HTML action attribute into defs.link_attrs (in
html/defs.py) for later use in input sanitization, but does not do the
same for the HTML5 formaction attribute.
Upstream fixed it in 4.6.3 (
I made a patch, please review and push if you think that's OK, I will otherwise
push it myself after some time.
The patch produces some test error, not sure if deterministic, looks related to
networking disabled in build sandboxes, log:
The servers were restarted 778 times
Spent 6689.041 of 234
* gnu/packages/databases.scm (mariadb/fixed): New variable.
(mariadb)[replacement]: Graft.
---
gnu/packages/databases.scm | 33 +
1 file changed, 33 insertions(+)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 8be83f5cbe..6fdb22d7fb
Hello!
pillow-simd is a fork of pillow (
https://github.com/uploadcare/pillow-simd), it's currently still at
version 7.x and it does not seem like it backports security patches
from pillow.
$ ./pre-inst-env guix refresh -l python-pillow-simd
No dependents other than itself:
CVE-2021-27928 04:15
A remote code execution issue was discovered in MariaDB 10.2 before
10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before
10.5.9; Percona Server through 2021-03-03; and the wsrep patch through
2021-03-03 for MySQL. An untrusted search path leads to eval
Hello!
$ ./pre-inst-env guix refresh mediainfo
gnu/packages/video.scm:3852:2: warning: 'generic-html' updater failed
to determine available releases for mediainfo
I tried adding a release-monitoring-url and hardcoding the name into
the url instead of using the variable 'name' but that did not
On Thu, 2021-03-18 at 21:41 +0100, Ludovic Courtès wrote:
> I think it’s more of a discussion for guix-devel than a bug
> report. :-)
Yes but then I was thinking how do we track progress without losing it
in the pile of emails from guix-devel people receive everyday which
made me create a bug in
On Thu, 2021-03-18 at 14:38 +0100, Ludovic Courtès wrote:
> I don’t think all the testing that needs to be done when grafting can
> be
> automated.
Not all but part of it?
> In particular, packagers who want to introduce a replacement for a
> library should use libabigail’s ‘abi-diff’ tool to
Fixed by 1155a88308df7649fe74bd5bb8279a4d103ce386
signature.asc
Description: This is a digitally signed message part
Thanks a lot to the reporter and for working on this!
signature.asc
Description: This is a digitally signed message part
According to
https://www.sqlite.org/versionnumbers.html major versions of sqlite remain ABI
and file format backwards
compatible.
It means we could graft without trouble, 3.32.3 fixes all CVEs, however
3.32 introduces a test failure in Python 3.8.2 which is an errorneous
test testing internal
Hello!
I am having an hard time testing grafts in GNU Guix while I think we
could have better tooling around this.
For example, we could have a package transformation that can add a
phase before 'check (or others) to graft any intermediate build binary
and all dependencies (if not done already)
Hello!
We had an issue after grafting ImageMagick fixed by <
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd
>.
Basically Inkscape did not work because ImageMagick's soname had been
bumped (probably for forward compat?):
On Wed, 2021-03-17 at 04:05 -0400, Mark H Weaver wrote:
> I've made an attempt to improve this situation in commit
> 1a265842e634656411bc7304c4648273f174f65e on the 'master' branch.
> Especially note the changes made in guix/build-system/python.scm.
>
> You might find that commit
We could do it without cloning the repos, for example the "fennel"
package:
$ git ls-remote --tags https://git.sr.ht/~technomancy/fennel
e54a85b3525a44ac16d6a4e35d19a1d5d6948ce2refs/tags/0.1.0
5c58b24f5261734caff25b9cbe2e8b551027a8bdrefs/tags/0.1.1
After applying:
diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index edb3f85109..36fd1eb066 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -1175,6 +1175,8 @@ enabled.")
(snippet
'(begin
(delete-file "fennelview.lua")
Hello!
Please see:
-
https://www.gnu.org/software/libc/manual/html_mono/libc.html#Hardware-Capability-Tunables
- https://www.phoronix.com/scan.php?page=news_item=glibc-hwcaps-RFC
- https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html
This could help GNU Guix create binaries that
I applied such patch:
diff --git a/gnu/packages/sqlite.scm b/gnu/packages/sqlite.scm
index eeb77749d8..35cf0168e0 100644
--- a/gnu/packages/sqlite.scm
+++ b/gnu/packages/sqlite.scm
@@ -65,6 +65,8 @@
(sha256
(base32
On Tue, 2021-03-16 at 13:57 +0100, Konrad Hinsen wrote:
> With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building
> git fails because of a hash mismatch when downloading the man pages
> (see
> log below).
>
Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply
./pre-inst-env guix lint -c cve python-urllib3@1.26.2
Here this should return at least CVE-2021-28363 but it does not because
the CVE database contains urllib3 and not python-urllib3 (which AFAICT
the cve linter searches for).
Annotating each and every python-, go-, and rust- package with
NOTE: SecureBoot on GNU Guix is not something common at all, so the
urgency to fix this issue is not as great as if we explicitly
advertised support for SecureBoot.
signature.asc
Description: This is a digitally signed message part
As outlined by:
-
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a01bfa7deed1d556fc75ab5588517442054bc5a9
-
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=db87d6ddafd26c5ad657178cf7fdab524d05c522
Two commits needed to be made to fix the issue both in the python2 and
python3
On Tue, 2021-03-16 at 09:08 +0100, Léo Le Bouter via Bug reports for
GNU Guix wrote:
> There is no new upstream release so patching this appears to be some
> kind of sport.
There seems to be a release candidate available:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg0021
As outlined by
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021
we have a new wave of GRUB security vulnerabilities around SecureBoot.
There is no new upstream release so patching this appears to be some
kind of sport.
Debian has patched it in this commit:
Some tests fail:
FAIL: tests/no-home.sh
FAIL: tests/status-sexp.sh
PASS: tests/misbehaved-client.sh
FAIL: tests/replacement.sh
PASS: tests/file-creation-mask.sh
PASS: tests/restart.sh
PASS: tests/one-shot.sh
FAIL: tests/basic.sh
PASS: tests/respawn-throttling.sh
PASS: tests/signals.sh
PASS:
I tried something, using patch git repo's master instead of release tarballs, I
am not sure the git repo contains all the fixes, we could alternatively just
pull patches from Debian.
This attempt does not work yet however, it fails on some gnulib source file not
being found for some reason:
gcc:
* gnu/packages/base.scm (patch/fixed): New variable.
(patch)[replacement]: Graft.
---
gnu/packages/base.scm | 39 +++
1 file changed, 39 insertions(+)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 9aa69cfe77..a71b47ac4f 100644
---
Hello!
Latest version is 89.0.4389.90
ungoogled-chromium upstream has it:
https://github.com/Eloston/ungoogled-chromium/commit/64cbcbcfee33fd56760173b3a17d2de52cd77258
Debian also upgraded:
https://salsa.debian.org/chromium-team/chromium/-/commit/8a1f530bdc3fc90993cdc1499e77f9e91468a686
I am
I am also affected by this issue (non-deterministically) it seems.
Requires me to run 'guix system reconfigure ..' several times for
things to work.
signature.asc
Description: This is a digitally signed message part
Hello!
I noticed using --keep-failed implies that offloading is disabled. For
development of GNU Guix I offload all compilation from my laptop to a
powerful server, not having offload with --keep-failed makes it
troublesome to debug issues.
I don't know if it's easy to implement but would be
Hello!
It looks like the proposed fix at
858898e348eb300a94b74115328ee39191829bda is causing other issues:
$ guix describe
Generation 27 Feb 17 2021 09:39:49(current)
guix 861ba52
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit:
Hello!
I have been looking at this, since Cargo has a feature to add third
party repositories already I am thinking we can remove the concept of a
default repository in Cargo by patching it.
Cargo has multiple roles in relation with crates.io - it can search,
install and publish packages. I am
89 matches
Mail list logo
