y
> metadata and install the sources. Do you think that this strategy is
> still possible with the new data model?
I'm experimenting on the Guix Rust Registry, currently at
<https://codeberg.org/hako/guix-rust-registry/>. It's basically
managing rust-crates and rust-sources m
oaches don't involve supporting
Rust
libraries in `guix shell`.
Hi Hilton, thanks for the response. I am aware that the existing
approaches have this feature gap in `guix shell`, but the question
is whether, in your opinion, the recent changes make it any easier
or harder to close the gap in t
Hilton Chain writes:
> Hilton Chain writes:
>
>> On Tue, 18 Mar 2025 15:30:30 +0800,
>> Hilton Chain wrote:
>>>
>>> Patch series without packages sent to #77093!
>>
>> Finally added the lockfile importer to rust-team branch! #77093 is left
Jason Conroy writes:
> Hilton Chain writes:
>
>> Hilton Chain writes:
>>
>>> On Tue, 18 Mar 2025 15:30:30 +0800,
>>> Hilton Chain wrote:
>>>>
>>>> Patch series without packages sent to #77093!
>>>
>>> F
Hilton Chain writes:
Hilton Chain writes:
On Tue, 18 Mar 2025 15:30:30 +0800,
Hilton Chain wrote:
Patch series without packages sent to #77093!
Finally added the lockfile importer to rust-team branch!
#77093 is left for
documentation and will be a merge blocker.
Blog post sumbitted
Hilton Chain writes:
> On Tue, 18 Mar 2025 15:30:30 +0800,
> Hilton Chain wrote:
>>
>> Patch series without packages sent to #77093!
>
> Finally added the lockfile importer to rust-team branch! #77093 is left for
> documentation and will be a merge blocker.
Bl
On Sat, May 10, 2025 at 10:52:08AM +0200, Rutherther wrote:
>
> >
> > The reason why 32-bit is not supported in our Rust and natively in Zig
> > upstream is simple: memory requirement to bootstrap the compiler.
>
> I would still be interested in the details, is it
>
> The reason why 32-bit is not supported in our Rust and natively in Zig
> upstream is simple: memory requirement to bootstrap the compiler.
I would still be interested in the details, is it known how much memory
is necessary, and what processes are taking this much memory, is it
Rutherther writes:
> Hi Hilton,
>
> Hilton Chain writes:
>
>> Hi Guix,
>>
>> (Cc'd bootstrap, rust and zig teams)
>>
>> Currently we have Zig only available for x86_64-linux and aarch64-linux.
>> Our Rust doesn't support 32 bit eit
Hi Hilton,
Hilton Chain writes:
> Hi Guix,
>
> (Cc'd bootstrap, rust and zig teams)
>
> Currently we have Zig only available for x86_64-linux and aarch64-linux.
> Our Rust doesn't support 32 bit either.
>
> This is causing issues (e.g. librsvg, multiarch cont
not
>>> > yet supported architectures.
>>>
>>> Sounds reasonable, but only if we cannot support those architectures
>>> natively IMO.
>>
>> I actually got fairly close on rust-1.54 for i686-linux. Ignoring that
>> for the moment, unless/until GHC
f we cannot support those architectures
>> natively IMO.
>
> I actually got fairly close on rust-1.54 for i686-linux. Ignoring that
> for the moment, unless/until GHC upstream releases prebuilt binaries for
> more architectures we have no other way of supporting some of our
> a
On Tue, May 06, 2025 at 09:52:19AM +0200, Ludovic Courtès wrote:
> Hi,
>
> Hilton Chain writes:
>
> > Currently we have Zig only available for x86_64-linux and aarch64-linux.
> > Our Rust doesn't support 32 bit either.
>
> Are 32-bit architectures support
Hi,
Hilton Chain writes:
> Currently we have Zig only available for x86_64-linux and aarch64-linux.
> Our Rust doesn't support 32 bit either.
Are 32-bit architectures supported upstream?
> 1. Support cross-compilation of these compilers.
>
> 2. Cross compile them from x
Hi Guix,
(Cc'd bootstrap, rust and zig teams)
Currently we have Zig only available for x86_64-linux and aarch64-linux.
Our Rust doesn't support 32 bit either.
This is causing issues (e.g. librsvg, multiarch container) and it would
be difficult to implement support following o
On Thu, 17 Apr 2025 20:44:06 +0800,
Hilton Chain wrote:
>
> On Thu, 17 Apr 2025 15:39:44 +0800,
> Ludovic Courtès wrote:
> >
> > Hello,
> >
> > Hilton Chain writes:
> >
> > >> Just realized cross-compilation support (rust-sysroot) is mi
Hilton Chain writes:
> 153k -> 42k lines for dependencies, sounds good? :)
Awesome. :-)
lton Chain wrote:
> > > >
> > > > Patch series without packages sent to #77093!
> > >
> > > Finally added the lockfile importer to rust-team branch! #77093 is left
> > > for
> > > documentation and will be a merge blocker.
> >
&g
On Thu, 17 Apr 2025 15:39:44 +0800,
Ludovic Courtès wrote:
>
> Hello,
>
> Hilton Chain writes:
>
> >> Just realized cross-compilation support (rust-sysroot) is missing when
> >> using
> >> other build systems.
> >
> > I think this issue
Hello,
Hilton Chain writes:
>> Just realized cross-compilation support (rust-sysroot) is missing when using
>> other build systems.
>
> I think this issue can't be really solved without exposing interface for
> target-inputs in all build systems.
>
> Luckily,
On Wed, 16 Apr 2025 12:51:52 +0800,
Hilton Chain wrote:
>
> On Sat, 12 Apr 2025 19:46:40 +0800,
> Hilton Chain wrote:
> >
> > On Tue, 18 Mar 2025 15:30:30 +0800,
> > Hilton Chain wrote:
> > >
> > > Patch series without packages sent to #77093!
> &
On Sat, 12 Apr 2025 19:46:40 +0800,
Hilton Chain wrote:
>
> On Tue, 18 Mar 2025 15:30:30 +0800,
> Hilton Chain wrote:
> >
> > Patch series without packages sent to #77093!
>
> Finally added the lockfile importer to rust-team branch! #77093 is left for
> documentati
t,,, guix, GNU Guix Reference Manual}).
>In the end we'll have the following definition:
>
>[Definition of cargo-audit using the new input system]
When running "guix import crate" from the rust-team branch
by using pre-inst-env, I got a resulting package with the
classic &qu
>The git repository is different from the one published to crates.io. crates.io
>only hosts individual crates.
>
>This git repository is a Cargo Workspaces which contains multiple crates.
>Workspace members are local so no enough information is available in
>Cargo.lock.
>
>You need to either pack
>>> The last issue I faced was that the pay-respects parser[3]
> >>> and utilities[4] weren't imported.
> >>
> >>I can't reproduce this. They are imported on my side.
> >
> >I'll try it again.
> >
>
> I still couldn't
lities[4] weren't imported.
>>
>>I can't reproduce this. They are imported on my side.
>
>I'll try it again.
>
I still couldn't get these packages imported, but I still
managed to add them manually to rust-crates.scm.
Here is a step-by-step process of what I
>> And that was it for me in the Cookbook, I didn't have to deal with
>> potentially bundled sources.
>>
>> The last issue I faced was that the pay-respects parser[3]
>> and utilities[4] weren't imported.
>
>I can't reproduce this. They are imported on my side.
I'll try it again.
--
Gabriel San
can
> >generate a draft definition via the crates.io importer
> >(@pxref{Invoking guix import,,, guix, GNU Guix Reference Manual}).
> >In the end we'll have the following definition:
> >
> >[Definition of cargo-audit using the new input system]
>
> When running
On Sat, 12 Apr 2025 20:55:45 +0800,
Gabriel Santos wrote:
>
> Em 12 de abril de 2025 08:46:40 BRT, Hilton Chain
> escreveu:
> >On Tue, 18 Mar 2025 15:30:30 +0800,
> >Hilton Chain wrote:
> >>
> >> Patch series without packages sent to #77093!
> >
&
Em 12 de abril de 2025 08:46:40 BRT, Hilton Chain
escreveu:
>On Tue, 18 Mar 2025 15:30:30 +0800,
>Hilton Chain wrote:
>>
>> Patch series without packages sent to #77093!
>
>Finally added the lockfile importer to rust-team branch! #77093 is left for
>documentation
On Tue, 18 Mar 2025 15:30:30 +0800,
Hilton Chain wrote:
>
> Patch series without packages sent to #77093!
Finally added the lockfile importer to rust-team branch! #77093 is left for
documentation and will be a merge blocker.
em: find command used in check-for-pregenerated-files rewritten in
> Guile (but kept grep), file tree will be scanned only once, not sure if this
> can
> save some time.
>
> For compatiblity with existing packages, check-for-pregenerated-files won't
> fail
> now (as it's mov
find command used in check-for-pregenerated-files rewritten in
> Guile (but kept grep), file tree will be scanned only once, not sure if this
> can
> save some time.
>
> For compatiblity with existing packages, check-for-pregenerated-files won't
> fail
> now (as it
this can
save some time.
For compatiblity with existing packages, check-for-pregenerated-files won't fail
now (as it's moved after configure).
Many tests and assets are also removed from rust-crates.scm sources.
The next is documentation :)
> Are you saying that if two dependents of a package A depend on the same
> package B, but with different features we need to build B with the
> union of those features?
>
Exactly, except in some cases where features are incompatible with each other,
but that's (very) rare. What's annoying is t
gt;
Are you saying that if two dependents of a package A depend on the same
package B, but with different features we need to build B with the
union of those features?
Is it possible to build B twice or will it conflict with itself when
building A?
> To be even more precise we could search only in
On Sun, 16 Mar 2025 16:30:08 +0800,
Hilton Chain wrote:
>
> On Sun, 16 Mar 2025 16:07:59 +0800,
> Efraim Flashner wrote:
> >
> > [1 ]
> > +CC Steve, new(ish) rust-team member
> >
> > On Sun, Mar 16, 2025 at 02:04:02PM +0800, Hilton Chain wrote:
> > &
On Sun, 16 Mar 2025 16:07:59 +0800,
Efraim Flashner wrote:
>
> [1 ]
> +CC Steve, new(ish) rust-team member
>
> On Sun, Mar 16, 2025 at 02:04:02PM +0800, Hilton Chain wrote:
> > I have made the following changes (currently locally):
> > - New procedure ‘cargo-inputs’.
&
I have made the following changes (currently locally):
- New procedure ‘cargo-inputs’.
(cargo-inputs NAME) returns a copy of (@ (gnu packages rust-crates)
NAME-cargo-inputs), with #f removed and symbols resolved to (@ (gnu packages
rust-sources) SYMBOL). Both modules can be configured via
ar 07 2025, Hilton Chain wrote:
> I think the approach I'm currently experimenting with for our Rust ecosystem
> can
> be applied to Go as well:
>
> 1. Import dependencies from lockfile as s
In guix-ruby I create a Gemfile.lock.scm file, which represents the
dependencies of a proje
decided to go for uv, which is a python package manager. The TODO
> comments were good, and I believe I unbundled everything from them. I
> mostly copied the snippets from the existing packages, but as we package
> more they'll transition over to rust-crates.scm and we'll be able
gt; These two were easy. I realized later that we could forgo running
> > 'cargo generate-lockfile' if we wanted to use the Cargo.lock that
> > already exists (if it does), but we probably want to make sure we have
> > more up-to-date dependencies as much as possible.
anted to use the Cargo.lock that
> already exists (if it does), but we probably want to make sure we have
> more up-to-date dependencies as much as possible. I could see, as part
> of a rust-team branch, going through and updating the lockfile every now
> and then even if there is no
On Wed, 26 Feb 2025 05:35:29 +0800,
Sharlatan Hellseher wrote:
>
> [1 ]
>
> Hi Guix,
>
> After reading the thread:
> How to move forward about Rust? antioxidant, cargo2guix, etc.
> <https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00417.html>
>
> I&#x
> > https://git.boiledscript.com/hako/guix/commits/branch/cargo
> >
> > I have continued to experiment on this branch (now based on rust-team), with
> > following changes:
> >
> > - Removed git checkout support for the importer, instead a warning of
> > missin
On Thu, 27 Feb 2025 22:22:29 +0800,
Efraim Flashner wrote:
>
> > > > Would it be easier to have 1 package per module, as in just the cargo
> > > > inputs for zoxide in gnu/packages/rust-crates/zoxide.scm, and then you
> > > > wouldn't need to worry
On Thu, 27 Feb 2025 22:26:59 +0800,
Hilton Chain wrote:
>
> Cargo workspace support!
>
> https://git.boiledscript.com/hako/guix/commits/branch/cargo
I have continued to experiment on this branch (now based on rust-team), with
following changes:
- Removed git checkout support for
hesis)
> > Perhaps its also a good time to add "--offline" to all cargo invokes to
> > effectively prevent it from executing online operations.
> > ---
> >
> > > Would it be easier to have 1 package per module, as in just the cargo
> > > inputs f
On Thu, 27 Feb 2025 19:16:39 +0800,
Hilton Chain wrote:
>
> > > > I have modified cargo2guix to support git checkouts but commented it
> > > > out due to
> > > > lack of cargo-build-system support.
> > >
> > > Looking at guix/build/cargo-build-system, the "easiest" option would be
> > > to take th
ld be
> > enough.
>
> This can be done when we have decided to switch to this model.
>
> > A fun fact is that after that change, we probably won't need a rust-team
> > branch, except for upgrades to the build-system itself ;)
There are worse things in the world :) W
add content of the list to
> > > REFERENCES.
> > > Otherwise add the definition name to VARIABLES
> > >
> > > UNUSED_VARIABLES = VARIABLES - REFERENCES
> > >
> > > Delete UNUSED_VARIABLES from MODULES in one go.
> > > --8<---
cro could help IMO. If we're going to change a checksum
> along with a checksum on most upgrades, a single line change should be
> enough.
This can be done when we have decided to switch to this model.
> A fun fact is that after that change, we probably won't need a rust-team
> branch, except for upgrades to the build-system itself ;)
:)
to add "--offline" to all cargo invokes to
> effectively prevent it from executing online operations.
> ---
>
> > Would it be easier to have 1 package per module, as in just the cargo
> > inputs for zoxide in gnu/packages/rust-crates/zoxide.scm, and then you
> &g
to implement it at the
> > moment:
> > --8<---cut here---start->8---
> > While reading file MODULE, find definitions
> > If the definition is ‘(delay (list ...))’, add content of the list to
> > REFERENCES.
> > Otherwi
, checksum)
A procedure or macro could help IMO. If we're going to change a checksum
along with a checksum on most upgrades, a single line change should be
enough.
A fun fact is that after that change, we probably won't need a rust-team
branch, except for upgrades to the build-sys
On Wed Feb 26, 2025 at 3:43 AM -03, Hilton Chain wrote:
> Time to try in your own channel!!!
I just did, it worked for helix. I'll be trying in some more rust packages in
the following days.
> * Package cargo-audio[1] and cargo-license[2] or similiar software, and write
> a
&g
e job
for now. We could always do a proper support for git checkouts later.
---
(A bit of a parenthesis)
Perhaps its also a good time to add "--offline" to all cargo invokes to
effectively prevent it from executing online operations.
---
> Would it be easier to have 1 package per mo
>8---
> While reading file MODULE, find definitions
> If the definition is ‘(delay (list ...))’, add content of the list to
> REFERENCES.
> Otherwise add the definition name to VARIABLES
>
> UNUSED_VARIABLES = VARIABLES - REFERENCES
>
> Delete UNUSED_VARIABLES from MOD
On Wed, Feb 26, 2025 at 03:35:13AM +0100, Nicolas Graves wrote:
>
> I rewrote this email 3 times already! I'm making a layout then.
> Sorry if the style is inconsistent.
>
>
> 1) About Antioxidant/rust-build-system
>
> Tremendous, back in the day I could rebuild
On Tue, 25 Feb 2025 06:26:57 +0800,
Hilton Chain wrote:
>
> I'm working on the generator in:
> https://git.boiledscript.com/hako/guix/commits/branch/origin-crates
>
> Next step is to integrate cargo2guix, I expect to have a working demo within
> this week.
Time to try in your own channel!!!
--8<-
I rewrote this email 3 times already! I'm making a layout then.
Sorry if the style is inconsistent.
1) About Antioxidant/rust-build-system
Tremendous, back in the day I could rebuild half the whole rust world in
about a day.
Complexity was a thing however (definitely): you had to chec
Hi Guix,
After reading the thread:
How to move forward about Rust? antioxidant, cargo2guix, etc.
<https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00417.html>
I've faced with the fact that Golang had a very close approach during
compilation as Rust, where each package defi
igins produce deterministic outputs, downloading of crates from different
channels can be deduplicated.
--8<---cut here---start->8---
(define-module (gnu packages rust-crates))
;; Generated crates.
(define-public rust-...
(origin ...)
...
;; Crates depen
On Mon, Feb 24, 2025 at 08:35:13AM -0800, Felix Lechner wrote:
> Hi Murilo,
>
> On Mon, Feb 24 2025, Murilo wrote:
>
> > generating guix package definitions from Cargo.lock.
>
> How else can we avoid packaging errors like this one? [1]
>
> Kind regards
> Feli
proposal is for a new build system (rust-build-system)
> in Guix best aligned with we already do for other languages, which is using
> libs shared and re-using previously pre-built stuff as inputs for a new
> package
> output.
In my tests a few years ago antioxidant was actually slightl
Hi Murilo,
On Mon, Feb 24 2025, Murilo wrote:
> generating guix package definitions from Cargo.lock.
How else can we avoid packaging errors like this one? [1]
Kind regards
Felix
P.S. I'm not a Rust person & behind on the conversation.
[1] https://issues.guix.gnu.org/76444
Hi Simon, thanks for bringing up the discussion again.
On Fri Feb 21, 2025 at 11:23 AM -03, Simon Tournier wrote:
> How does it compare with antioxidant? And your (Nicolas) ideas?
Antioxidant and Nicolas proposal is for a new build system (rust-build-system)
in Guix best aligned with we alre
contributor responsible for keeping the crates-*.scm (or
similar) files sorted and if so is there an automated way to insert
packages alphabetically?
3) Is crates-io.scm strictly for I/O related rust packages or is it the
de-facto "generic/xyz" file for rust?
tive dependencies as input, built straight
> from info in ‘Cargo.lock’ (as Murilo suggests, I believe).
>
> We could arrange to maintain a list of origins (not packages) in
> rust*.scm for all the libraries—anything that’s not a leaf—so we still
> have a view of code that is shared by se
of origins (not packages) in
rust*.scm for all the libraries—anything that’s not a leaf—so we still
have a view of code that is shared by several leaf packages.
Ludo’.
] does good
job too! In order to ease, I just copy below message from [1].
Hey what’s the status? What’s the plan for improving the whole Rust
story with Guix?
1: Idea for packaging rust apps
"Murilo"
Tue, 21 May 2024 23:04:44 -0300
id:D1FSEA12TP5X.3DXKC14DE114M@yumiko
https://lis
Efraim Flashner skribis:
> I ended up making the changes and pushing them to the rust-team branch.
> Rust-team is right after mesa-updates, so we should be landing it soon™
>
> ¹
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=rust-team&id=39c1a5f48e9f7a175be7b3c22a76d
On Sun, Dec 29, 2024 at 10:39:41PM +0100, Ludovic Courtès wrote:
> Hey Efraim,
>
> Ludovic Courtès skribis:
>
> >> + (package
> >> +(name "rust-ring")
> >> +(version "0.17.8.tar.gz") ; Hack to adjust the output name.
>
Hey Efraim,
Ludovic Courtès skribis:
>> + (package
>> + (name "rust-ring")
>> +(version "0.17.8.tar.gz") ; Hack to adjust the output name.
>> +(source (origin
>> (method git-fetch)
>> (uri (git-re
ts used for the computed-origin? (perl,
> nasm, go, etc?)
Yes.
> I'm pretty sure there are 3 options here:
> 1. Stop rebuilding the generated files. This is what we did in the past,
> and it allows rust-ring-0.14 to be used on riscv64-linux. I haven't
> talked with the
Thanks for bringing this up! rust-ring, while an interesting experiment
in how to package software which doesn't play well with rebuilding
sources, is certainly not something we want to have be the norm.
On Sat, Dec 14, 2024 at 11:37:53PM +0100, Ludovic Courtès wrote:
> Hello Guix,
&g
Hello Guix,
‘rust-ring-0.16-sources’ & co. are origins that use
‘computed-origin-method’ (the thing that’s internal and undocumented) to
generate object files from assembly source, things like that.
An origin is supposed to represent source code, and clearly, the end
result here is not sourc
Hello,
Efraim Flashner skribis:
> I don't want to go and parse Cargo.lock, automagically generate packages
> based on that, and then download those as cargo-inputs for packages. Not
> only does that potentially pull in old versions of libraries which may
> have necessary updates or patches, it d
I should point out that I am packaging Scryer-Prolog, which uses Rust in
its underbelly.
As it stands, the divergences of crate versioning means that my package
definition is nearly 60k LOC and Ive had to validate over 1.1k packages
already.
Naturally, some of these are duplicates of Guix
On Thu, Dec 05, 2024 at 11:13:07AM +0100, Ludovic Courtès wrote:
> Hello,
>
> Efraim Flashner skribis:
>
> > I still have a copy of the code on my machine but unfortunately it no
> > longer builds due to the constant churn of rust packages.
> >
> > One thin
Hello,
Efraim Flashner skribis:
> I still have a copy of the code on my machine but unfortunately it no
> longer builds due to the constant churn of rust packages.
>
> One thing I remember explicitly about it was that building end packages
> was faster than the current metho
I didn't manage to do it with substitute* though,
because that does the replacements line by line.
I also noticed that version 1.7.0-prerelease-2 depends on Rust 1.79,
where the behavior of temporary lifetimes in `if` and `match`
expressions was changed [2]. With version 1.7.0-prelease-1 (th
Hello,
thanks to all who replied to me!
Am Thu, Nov 21, 2024 at 09:21:10PM +0200 schrieb Efraim Flashner:
> Through some playing around I was able to build
> rust-core-graphics-types@0.1.3, but I had to disable the automatic
> linking. Since that crate is specifically for macOS I
0.23.2 [2], the
> corresponding `core-graphics-types` crate version (0.1.3) already has
> the "link" feature, but version 0.1.1 (the version in Guix) does not.
> This seems to be a mistake in the `core-graphics` crate.
>
> As `kanata` depends on `core-graphics` version 0.23.2,
be a mistake in the `core-graphics` crate.
As `kanata` depends on `core-graphics` version 0.23.2, you should add
a package for rust-core-graphics-types with version 0.1.3 (the latest
0.1.* version) and use that instead in the #:cargo-inputs of
rust-core-graphics-0.23.
Cheers,
David
[1] https
Hello,
I am interested in some software written in rust, and have used
"guix import -r" to reach the attached file. Compilation of kanata fails
with the following message:
starting phase `build'
error: failed to select a version for `core-graphics-types`.
... required b
Hi Guix,
I am probably becoming rust-team's worst nightmare after this but I just
sent ~100 new Rust packages required to build gnome-authenticator . I
divided them somewhat arbitrarily in these 4 issues with ~30 new patches
each:
1. https://issues.guix.gnu.org/73956
2.
wrote:
> >> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent
> >> >> wrote:
> >> >> >Note that we already have Rust 1.81 in rust-team, and I have already
> >> >> >sent a patch to update to 1.82 (the latest stable). Usual
Another thing to keep in mind is that packaging for development is different
than packaging for a distribution. Packaging for a distribution you only want
to pull in packages from stackage that are required to build eg. xmonad or
shellcheck.
However having robust importing for when those needs
Efraim Flashner writes:
> On Tue, Oct 22, 2024 at 07:51:07AM -0400, Brennan Vincent wrote:
>> Efraim Flashner writes:
>>
>> > On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote:
>> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent
>> >> w
On 22 October 2024 14:32:08 GMT, Lars-Dominik Braun wrote:
>Hi,
>
>> Is there a specific reason why we’re following the Stackage releases?
>> Stackage is one step slower in getting the updates. The current Stackage
>> Nightly is 9.8.2, while Hackage has 9.10.1. Is this due to some stability
>>
Hi,
> Is there a specific reason why we’re following the Stackage releases?
> Stackage is one step slower in getting the updates. The current Stackage
> Nightly is 9.8.2, while Hackage has 9.10.1. Is this due to some stability
> issues with Hackage?
Stackage’s package collection is coherent an
On Tue, Oct 22, 2024 at 07:51:07AM -0400, Brennan Vincent wrote:
> Efraim Flashner writes:
>
> > On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote:
> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent
> >> wrote:
> >> >Note that we already have
r.co.il
>
> Oggetto: Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement
> ([PATCH] gnu: rust: update to 1.82)
>
> By the way, if you want to use Rust 1.82.0 before it gets accepted for
> the default guix channel, you can use my channel (and install
> `rust-next`,
Efraim Flashner writes:
> On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote:
>> On 21 October 2024 18:08:44 GMT, Brennan Vincent
>> wrote:
>> >Note that we already have Rust 1.81 in rust-team, and I have already
>> >sent a patch to update to 1.82 (t
eparately or do I need to CC someone
>> >> specific?
>> >
>> > From the checkout, you can do this:
>> >./etc/teams.scm show rust
>> >
>> > ...
>> > members:
>> > + Efraim Flashner
>> >
>> > Well, so a team can
On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote:
> On 21 October 2024 18:08:44 GMT, Brennan Vincent
> wrote:
> >Note that we already have Rust 1.81 in rust-team, and I have already
> >sent a patch to update to 1.82 (the latest stable). Usually Efraim
> &
ut, you can do this:
> >./etc/teams.scm show rust
> >
> > ...
> > members:
> > + Efraim Flashner
> >
> > Well, so a team can be one person ;-)
> > I think Efraim reads this list, but feel free to cc him.
>
> Thanks for that tip, Andreas!
>
On 21 October 2024 18:08:44 GMT, Brennan Vincent wrote:
>Note that we already have Rust 1.81 in rust-team, and I have already
>sent a patch to update to 1.82 (the latest stable). Usually Efraim
>reviews these updates.
>
> Start of forwarded message ---
...@subvertising.org
Cc: guix-devel@gnu.org ; efr...@flashner.co.il
Oggetto: Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH]
gnu: rust: update to 1.82)
By the way, if you want to use Rust 1.82.0 before it gets accepted for
the default guix channel, you can use my channel (and
1 - 100 of 755 matches
Mail list logo
