t;
> > > The packages are public but hidden
> >
> > Interesting! How does that work, please? I looked at the package
> > definition [1] but could not see fields that hide it. Thanks!
>
> As far as I can tell *all* versions except the "official" are hi
I looked at the package
> definition [1] but could not see fields that hide it. Thanks!
As far as I can tell *all* versions except the "official" are hidden. The
"base" package (rust-1.55) has this property:
(properties '((hidden? . #t)
...)
Al
Hi Efraim,
On Wed, Jun 26 2024, Efraim Flashner wrote:
> The packages are public but hidden
Interesting! How does that work, please? I looked at the package
definition [1] but could not see fields that hide it. Thanks!
Kind regards
Felix
[1] https://git.savannah.gnu.org/cgit/guix.git/tree/g
u, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> > > Hi Guixers,
> > >
> > > I want to update the Librewolf package, but it now
> > > depends on Rust
> > > >= 1.76, which is newer than what's in master. I see the
> > > >
1PM -0700, Ian Eure wrote:
> > > > Hi Guixers,
> > > >
> > > > I want to update the Librewolf package, but it now depends on Rust
> > > > >= 1.76, which is newer than what's in master. I see the >rust-team
> > > > branch has
On Tue, Jun 25, 2024 at 08:48:12AM -0700, Ian Eure wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
>
> > [[PGP Signed Part:Undecided]]
> > On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> > > Hi Guixers,
> > >
> > > I want to updat
Hi Efraim,
Efraim Flashner writes:
[[PGP Signed Part:Undecided]]
On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
Hi Guixers,
I want to update the Librewolf package, but it now depends on
Rust
>= 1.76, which is newer than what's in master. I see the
>rust-team
Hi Efraim,
On Fri, Jun 21 2024, Efraim Flashner wrote:
> I managed to burn myself out on rust stuff a few months ago
Thank you for your hard work. Rust is perhaps the most complex part in
the Guix packaging effort.
> After merging the current branch I hope to be able to move the versio
On Thu, Jun 20, 2024 at 05:10:11PM -0700, Ian Eure wrote:
> Hi Guixers,
>
> I want to update the Librewolf package, but it now depends on Rust >= 1.76,
> which is newer than what's in master. I see the rust-team branch has
> versions up to 1.77 — is there a timeline for
Hi Guixers,
I want to update the Librewolf package, but it now depends on Rust >= 1.76,
which is newer than what's in master. I see the rust-team branch has versions
up to 1.77 — is there a timeline for merging that, or a TODO list of things
that need to be done to merge it? I'
Hi MSavoritias,
> I wanted to ask, are you also aware of the antioxidant effort?
> https://notabug.org/maximed/cargoless-rust-experiments
I was not aware of it at all, thank you for enlightening me about the
effort.
> I was wondering of the differences since your build system
On 5/22/24 05:04, Murilo wrote:
Hello, I hope this is the right place for this, apologies if it isn't.
I'm working with a friend on a cargo importer that lowers the entry barrier
and the maintainability costs for packaging rust apps in general, without
sacrificing Guix dependency tr
Hello, I hope this is the right place for this, apologies if it isn't.
I'm working with a friend on a cargo importer that lowers the entry barrier
and the maintainability costs for packaging rust apps in general, without
sacrificing Guix dependency tracking and reproducibility of rus
cargo-build-system and used the cargo-registry profile hook to
merge all of those package artifacts into index files. I also
modified the hook to lift the full closure of source dependencies
into the profile for any rust packages in the manifest, borrowing
logic from `(guix build-system cargo)`.
On Wed, Apr 24, 2024 at 11:58:22AM -0400, Jason Conroy wrote:
>
> Efraim Flashner writes:
> > On the other hand, by generating it during the build of each package we
> > make sure to pull in all the crates which exist in the build, so we
> > could add into a profile/manifest just the crates liste
Efraim Flashner writes:
On the other hand, by generating it during the build of each
package we
make sure to pull in all the crates which exist in the build, so
we
could add into a profile/manifest just the crates listed in a
Cargo.toml
and then each crate would pull in its own dependencies,
On Thu, Apr 18, 2024 at 12:54:02PM -0400, Jason Conroy wrote:
>
> Efraim Flashner writes:
>
> > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then
> > you'd have both rand-0.*.crate files in the registry but only one of
> > them would be list
Efraim Flashner writes:
Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7
then
you'd have both rand-0.*.crate files in the registry but only
one of
them would be listed in share/cargo/registry/index/ra/nd/rand. I
need to
adjust the generation of that file to combine mul
On Tue, Mar 12, 2024 at 11:12 AM Efraim Flashner
wrote:
> On Thu, Mar 07, 2024 at 11:48:53AM -0500, Jason Conroy wrote:
> > On Thu, Mar 7, 2024 at 3:08 AM Efraim Flashner
> > wrote:
> >
> > > Until then
> > > I've been experimenting by manually listing the other crates I've
> needed
> > > but in
tem cargo)` but it's not exposed publicly. As interim
solutions go, what do you think about this one versus modifying `guix
shell`?
>
> I misread what you wrote as it was working. It's definitely something I
> want but wasn't ready to work on yet.
>
> > I
On Wed, Mar 6, 2024 at 4:06 AM Efraim Flashner
wrote:
> On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote:
> > Hello Efraim,
> >
> > Thanks for investigating this - a Rust development workflow using only
> > Guix-native crates is something I've
dn't be too hard to
merge that into `guix shell`, assuming we go that route.
> >
> > I misread what you wrote as it was working. It's definitely something I
> > want but wasn't ready to work on yet.
> >
> > > I took rust-rand as an example only b
On Thu, Feb 29, 2024 at 05:42:20PM -0500, Richard Sent wrote:
> Hi Guix,
>
> There isn't an unversioned symbol for rust-cargo defined or exported by
> the (gnu packages crates-io) module. I think it would be best if an
> unversioned rust-cargo symbol was created that was
On Wed, Mar 06, 2024 at 12:53:44PM -0500, Jason Conroy wrote:
> On Wed, Mar 6, 2024 at 4:06 AM Efraim Flashner
> wrote:
>
> > On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote:
> > > Hello Efraim,
> > >
> > > Thanks for investigating thi
On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote:
> Hello Efraim,
>
> Thanks for investigating this - a Rust development workflow using only
> Guix-native crates is something I've been waiting for!
>
> I was experimenting with your patches and it seems t
Hi Guix,
There isn't an unversioned symbol for rust-cargo defined or exported by
the (gnu packages crates-io) module. I think it would be best if an
unversioned rust-cargo symbol was created that was equal to the highest
rust-cargo release. (i.e. rust-cargo, not rust-cargo-0.76)
Alternat
On Thu, Feb 29, 2024, at 02:11, Efraim Flashner wrote:
> * Most of the packages in rust-apps have been upgraded.
> * rav1e was upgraded from 0.6.6 to 0.7.1
> * dav1d was upgraded from 1.0.0 to 1.3.0
> * libaom was upgraded from 3.5.0 to 3.8.0
Thanks for updating these AV1 video packages!
ause the default grub theme generates a .png from an .svg
>> > > ... using guile-rsvg, which uses librsvg, which uses rust ...
>> >
>> > How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the
>> > last version written in C?
>> >
>>
t; > > ... using guile-rsvg, which uses librsvg, which uses rust ...
> >
> > How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the
> > last version written in C?
> >
> > That’s easy to do and would address the immediate problem.
>
> I b
t;
> $ git log origin/master
> commit f29f80c194d0c534a92354b2bc19022a9b70ecf8 (origin/master, origin/HEAD)
> Merge: c034088e37 7947d47c9b
> Author: Efraim Flashner
> Date: Wed Feb 28 12:18:45 2024 +0200
> Merge branch 'rust-team'
> Change-Id: Iee31c5de29c357c822f60df4fa8ce758779
Hi Rust Team,
On Wed, Feb 28 2024, Andreas Enge wrote:
> Congratulations to the Rust team (aka Efraim) for this big endeavour!
How timely are your good news! Please let this article brighten your
day.
https://www.infoworld.com/article/3713203/white-house-urges-developers-to-dump-c-
37 7947d47c9b
Author: Efraim Flashner
Date: Wed Feb 28 12:18:45 2024 +0200
Merge branch 'rust-team'
Change-Id: Iee31c5de29c357c822f60df4fa8ce758779eb349
Congratulations to the Rust team (aka Efraim) for this big endeavour!
Andreas
Hello Efraim,
Thanks for investigating this - a Rust development workflow using only
Guix-native crates is something I've been waiting for!
I was experimenting with your patches and it seems that they do pull in the
source crates for requested packages, but not their dependencies (example
Efraim Flashner writes:
Hi,
> On Mon, Jan 29, 2024 at 05:36:52PM +0100, Ludovic Courtès wrote:
>> Hi,
>>
>> Vagrant Cascadian skribis:
>>
>> > This is because the default grub theme generates a .png from an .svg
>> > ... using guile-rsvg, which
On Mon, Jan 29, 2024 at 05:36:52PM +0100, Ludovic Courtès wrote:
> Hi,
>
> Vagrant Cascadian skribis:
>
> > This is because the default grub theme generates a .png from an .svg
> > ... using guile-rsvg, which uses librsvg, which uses rust ...
>
> How about u
uirass instance and some spot testing this morning, it
> > appears the change to source-highlight in commit 367bc2d198 has broken the
> > build of rust 1.73.
> > * `guix refresh -l source-highlight` reports modifying the package would
> > require a large number of rebuilds (&quo
Hi Kaeylyn,
On Monday, January 29th, 2024 at 12:26 PM, Kaelyn
wrote:
>
>
> Hi Efraim and guix-devel,
>
> Based on my local cuirass instance and some spot testing this morning, it
> appears the change to source-highlight in commit 367bc2d198 has broken the
> build of
Hi Efraim and guix-devel,
Based on my local cuirass instance and some spot testing this morning, it
appears the change to source-highlight in commit 367bc2d198 has broken the
build of rust 1.73.
* `guix refresh -l source-highlight` reports modifying the package would
require a large number of
Hi,
Vagrant Cascadian skribis:
> This is because the default grub theme generates a .png from an .svg
> ... using guile-rsvg, which uses librsvg, which uses rust ...
How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the
last version written in C?
That’s easy to do and
ed on bare-bones.tmpl with grub-efi)... it
pretty much needed to rebuild about 12 rust versions, as no substitutes
were available on aarch64-linux. *sigh*
I thought I tracked this down to guix-icons depending on librsvg, which
depends on rust... and guix-icons is in %base-packages.
So I dropped us
needed to rebuild about 12 rust versions, as no substitutes
were available on aarch64-linux. *sigh*
I thought I tracked this down to guix-icons depending on librsvg, which
depends on rust... and guix-icons is in %base-packages.
So I dropped use of %base-packages-artwork, which pulls in guix-icons
an
Sharlatan Hellseher writes:
> It might be addressed to rust/python teams.
> https://github.com/pydantic/pydantic-core
>
> During update of some packages from (gnu packages astronomy) I've faced with
> requirement for the fresh version of pydantic which
> depends on p
ith Rust flavor.
pydantic-core==2.0.1
https://github.com/pydantic/pydantic/blob/v2.0/pyproject.toml#L64
Pydantic core is built with maturin 1, <2:
https://github.com/pydantic/pydantic-core/blob/v2.0.1/pyproject.toml
Currently I've prepared updates for anything which requires minimum o
On Tue, Dec 26, 2023 at 12:27:38AM +, Sharlatan Hellseher wrote:
> Hi Guix!
>
>
> It might be addressed to rust/python teams.
> https://github.com/pydantic/pydantic-core
>
> During update of some packages from (gnu packages astronomy) I've faced
> with require
profile you need to adjust the path
to the value of your GUIX_ENVIRONMENT, and there's no way that I've
figured out to use $GUIX_ENVIRONMENT in a toml file.
Actually, it looks like I have the cargo registry patches sitting
unapplied on my machine, so I'm not even sure if it
Hi Guix!
It might be addressed to rust/python teams.
https://github.com/pydantic/pydantic-core
During update of some packages from (gnu packages astronomy) I've faced
with requirement for the fresh version of pydantic which depends on
pydantic-core built with rust and maturin.
This thre
hen doing development... WDYT
> Also, rust-analyzer is basically a convenience package around the
> rust-analyzer binary from rust:tools since we don't have a way to
> deprecate packages and point them to alternate outputs.
I was wondering why it existed as I looked inside the b
On Sun, Dec 24, 2023 at 08:35:36PM +, jgart wrote:
> Hi Guixers,
>
> What do you think I am missing?
>
> Completion works.
> Clippy works.
> Rustfmt works.
>
> `rust-compile` from emacs-rust-mode does not work :(
>
> I get the following error listed in the
Hi Guixers,
What do you think I am missing?
Completion works.
Clippy works.
Rustfmt works.
`rust-compile` from emacs-rust-mode does not work :(
I get the following error listed in the README when I try to compile the
following Rust Guix project:
https://git.sr.ht/~whereiseveryone/crab-meets
Efraim Flashner writes:
> The rust team is pleased to announce that the rust-team branch has been
> merged back into master. There are 570 commits across the branch.
> Cross-compiling support for the cargo-build-system was added, including
> for librsvg. Cross-compiling was tested
On Wed, Dec 13, 2023 at 10:34:11AM +0200, Efraim Flashner wrote:
> * Compiled rust packages currently have a 'package' phase, which runs
> the command used to crate a 'crate tarball', and is installed in
> %output/share/cargo/registry, with unpacked sources in
> %ou
Hi Efraim,
Efraim Flashner writes:
> The rust team is pleased to announce that the rust-team branch has been
> merged back into master. There are 570 commits across the branch.
> Cross-compiling support for the cargo-build-system was added, including
> for librsvg. Cross-compilin
The rust team is pleased to announce that the rust-team branch has been
merged back into master. There are 570 commits across the branch.
Cross-compiling support for the cargo-build-system was added, including
for librsvg. Cross-compiling was tested for (nearly) all architectures
supported in
there as I figured this was a more general
approach to trying to figure out how to package this kind of app.
I'll also add what I mentioned on irc, that packaging helix [1] would be
pretty similar also.
Maybe someone in the rust team would be willing to look at that and/or
try to mentor me
Hi Efraim!
Efraim Flashner writes:
[...]
>> > error: unnecessary parentheses around index expression
>> > -->
>> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:49:53
>> >|
>> > 49 |
f their (cargo-input) dependencies,
> > and so on. If any of them are missing then the build will fail. This is
> > also why we need to set #:skip-build? #t when we don't include the
> > desired cargo-development-inputs.
> >
> > The change is mainly a quality of
t when we don't include the
> desired cargo-development-inputs.
>
> The change is mainly a quality of life improvement; it decreases the
> time that guix people and CI spend building these crates, and it makes
> it easier to see which, if any, rust packages need to be checke
On Thu, Oct 05, 2023 at 03:52:46PM +0300, Efraim Flashner wrote:
> Currently for for rust crates we build the crates, run the tests, and
> then in %output we only have the license files and a repackaged version
> of the source.
>
> The build system goes:
> unpack source
>
On Mon, Oct 16, 2023 at 11:47:53AM -0400, Maxim Cournoyer wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
>
> > Currently for for rust crates we build the crates, run the tests, and
> > then in %output we only have the license files and a repackaged version
> > of
Hi Efraim,
Efraim Flashner writes:
> Currently for for rust crates we build the crates, run the tests, and
> then in %output we only have the license files and a repackaged version
> of the source.
>
> The build system goes:
> unpack source
> unpack crates
> patch sheba
Hi Felix,
Felix Lechner via "Development of GNU Guix and the GNU System
distribution." writes:
> In summary, I believe that #:test? should be turned off for all build
> systems. Guix should instead test installed versions like Debian's
> autopkgtest.
Let me just chime in and say that I agree: t
As a developer, the majority of the package build failures I encounter
are from failed tests, so I agree with this proposal.
I also like the idea of clients testing their own packages instead of
trusting the substitute server.
And if the new tests would catch more packaging bugs, that would be gr
Hi Ephraim,
On Thu, Oct 05 2023, Efraim Flashner wrote:
> I propose changing the cargo-build-system to have '#:tests? #f' by
> default
At first sight, it appears improper to turn off tests because they
fail. Please allow me to remind everyone that build-time tests cover
only a small proportion o
Currently for for rust crates we build the crates, run the tests, and
then in %output we only have the license files and a repackaged version
of the source.
The build system goes:
unpack source
unpack crates
patch shebangs
patch checksums of the crates
'build
'package
'check
'
Hi Nicolas,
Nicolas Graves writes:
> Hi all,
>
> Thanks for this discussion that I didn't expected to happen ;)
>
> I'll try and finish a version of the rust-build-system but I'd like to
> know if there are reasons to not want a direct and complete rewrite of
&
Hi all,
Thanks for this discussion that I didn't expected to happen ;)
I'll try and finish a version of the rust-build-system but I'd like to
know if there are reasons to not want a direct and complete rewrite of
all Rust packages before putting more time into this. My rational
Op 12-06-2023 om 15:05 schreef Maxim Cournoyer:
Hi Maxime,
Maxime Devos writes:
Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:
[...]
Yes. Overruling is a form of blocking, and blocking by authority
(whether de facto or de jure) is overruling.
There should not be a notion of 'overruling'
Hi Vagrant,
On Mon, Jun 12, 2023 at 8:09 AM Vagrant Cascadian wrote:
>
> everything kind of has a social component!
Thank you for pointing that out! Many technical discussions about
project governance claim high moral ground but remain incomplete.
Maxime possibly felt some righteous indignation
On 2023-06-11, Maxim Cournoyer wrote:
> Maxime Devos writes:
>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>>> A few months ago, Maxime Devos worked on a new rust-build-system to
>>> handle a few issues we were experiencing with cargo (see discussions on
>>&g
Hi Maxime,
Maxime Devos writes:
> Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:
>> Hi Maxime,
>> Maxime Devos writes:
>>
>>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>>>> A few months ago, Maxime Devos worked on a new rust-build-system to
>
Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:
Hi Maxime,
Maxime Devos writes:
Op 02-06-2023 om 20:02 schreef Nicolas Graves:
A few months ago, Maxime Devos worked on a new rust-build-system to
handle a few issues we were experiencing with cargo (see discussions on
antioxidant in guix
Hi Maxime,
Maxime Devos writes:
> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>> A few months ago, Maxime Devos worked on a new rust-build-system to
>> handle a few issues we were experiencing with cargo (see discussions on
>> antioxidant in guix-devel).
>> A mo
Hello,
I'd like to use GNU Guix to build embedded software using Rust.
Currently I'm thinking of using GNU Guix and Rust for embedded
development but currently Rust does not support cross-compilation
as libstd is only compiled for the "host" target.
I was thinking that GNU
Op 02-06-2023 om 20:02 schreef Nicolas Graves:
A few months ago, Maxime Devos worked on a new rust-build-system to
handle a few issues we were experiencing with cargo (see discussions on
antioxidant in guix-devel).
A month ago, we discussed about the possibility of the integration in
core guix
A few months ago, Maxime Devos worked on a new rust-build-system to
handle a few issues we were experiencing with cargo (see discussions on
antioxidant in guix-devel).
A month ago, we discussed about the possibility of the integration in
core guix, and the required steps. Maxime and I had a
On Tue, May 09, 2023 at 02:22:36PM +0100, Christopher Baines wrote:
>
> Andreas Enge writes:
>
> > Hello,
> >
> > Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner:
> >> The way its currently setup all we need to do is re-add aarch64-linux t
Andreas Enge writes:
> Hello,
>
> Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner:
>> The way its currently setup all we need to do is re-add aarch64-linux to
>> the supported-systems of rust-bootstrap and it'll be enabled again, and
>> build s
PS: Congratulations for getting the first team branch through!
And thanks for waiting until the core-updates merge :-)
Hello,
Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner:
> The way its currently setup all we need to do is re-add aarch64-linux to
> the supported-systems of rust-bootstrap and it'll be enabled again, and
> build successfully eventually.
I am confused by what hap
On Tue, May 09, 2023 at 09:33:46AM +0100, Christopher Baines wrote:
>
> Efraim Flashner writes:
>
> > I've merged the rust-team branch into master. I've dropped rust for
> > aarch64-linux again for now until I can get it built on cuirass so it's
> > not
Efraim Flashner writes:
> I've merged the rust-team branch into master. I've dropped rust for
> aarch64-linux again for now until I can get it built on cuirass so it's
> not holding up the branch any longer.
Do you know if it actually doesn't build, or whether it&
I've merged the rust-team branch into master. I've dropped rust for
aarch64-linux again for now until I can get it built on cuirass so it's
not holding up the branch any longer.
Unfortunately I forgot about the mesa update earlier so there's more
rebuilds than I expected.
e will realize it's a team of one ;)
>
> I'm thinking of tagging the rust stuff with [rust team] so it stands out
> and is easily searchable. if/when I send patches for other teams I'll
> probably tag those too and hope it catches on.
Sounds like something to automate u
On Thu, Apr 27, 2023 at 07:06:29PM +0200, Josselin Poiret wrote:
> Hi Efraim (and the rest of the Rust team),
>
> Efraim Flashner writes:
>
> > Now that core-updates has been merged into master it's time for a status
> > update from the rust team.
> >
> &
Hi Efraim (and the rest of the Rust team),
Efraim Flashner writes:
> Now that core-updates has been merged into master it's time for a status
> update from the rust team.
>
> Currently rust supports (in the order of gaining support) x86_64,
> aarch64 and riscv64. GDB-11 doe
Now that core-updates has been merged into master it's time for a status
update from the rust team.
Currently rust supports (in the order of gaining support) x86_64,
aarch64 and riscv64. GDB-11 doesn't currently build on aarch64 or
riscv64, so we're removing gdb-11 entirely and usi
Efraim Flashner writes:
> The Rust Team has been hard at work updating the rust compiler and a
> number of rust packages. We've tested a number of packages¹ to ensure
> that everything looks okay.
>
> Quick stats for the branch:
> 404 commits by 4 people.
> 181 pack
The Rust Team has been hard at work updating the rust compiler and a
number of rust packages. We've tested a number of packages¹ to ensure
that everything looks okay.
Real world testing has occurred on x86_64 and has started on riscv64 but
we'd like to request that a job be added to cui
Am Tue, Feb 14, 2023 at 10:07:12PM +0200 schrieb Efraim Flashner:
> > By "pull out" you mean revert them in staging and apply them on a separate
> > branch? That would also delay #61475 and maybe ease merging of the staging
> > branch.
> I was thinking more of cherry-picking them into a branch, not
On 2/14/23 1:08 PM, Efraim Flashner wrote:
Also I don't think there's a lot of overlap between go and rust so we
can probably have both going at the same time.
Oh, yes, I didn't mean to imply that the two were related, or
conflicted. I just wanted to point it out in case it
On Tue, Feb 14, 2023 at 09:36:46AM -0700, Katherine Cox-Buday wrote:
> Efraim Flashner writes:
>
> > As a project we haven't setup anything for starting the team-based
> > branches and upgrades, and the Rust Team volunteers to go first.
>
> Leo has attempted[1]
On Tue, Feb 14, 2023 at 05:36:13PM +0100, Andreas Enge wrote:
> Am Tue, Feb 14, 2023 at 12:14:04PM +0200 schrieb Efraim Flashner:
> > On behalf of the Rust Team™¹ we'd like to check our rust source tarballs
> > for any hidden binaries² and to do a mass upgrade of many of the c
Efraim Flashner writes:
> As a project we haven't setup anything for starting the team-based
> branches and upgrades, and the Rust Team volunteers to go first.
Leo has attempted[1] to setup a branch for Go, but we're waiting to hear from
sysadmins on why there's a bu
Am Tue, Feb 14, 2023 at 12:14:04PM +0200 schrieb Efraim Flashner:
> On behalf of the Rust Team™¹ we'd like to check our rust source tarballs
> for any hidden binaries² and to do a mass upgrade of many of the crates.
> Currently there are many crates queued up in the staging branch b
300 dependents
> are treated. This cap could be increased. Or it could be weighed with
> the build times of the packages.
>
>
> TEAMS
>
> - Issues could be tagged more often with responsible teams, or with
> severity information (blocking bug or not).
> - Each modul
On Tue, Nov 15, 2022 at 04:36:42AM -0800, Matthew James Kraai wrote:
> Hi,
>
> I'm trying to package Rust 1.65.0. When I try to build it, it fails with
> the following error:
>
> starting phase `build'
> Building rustbuild
> error: checksum for `windows_x86_64_
Hi,
I'm trying to package Rust 1.65.0. When I try to build it, it fails
with the following error:
starting phase `build'
Building rustbuild
error: checksum for `windows_x86_64_msvc v0.36.1` changed between lock files
this could be indicative of a few possible errors:
* the lo
7; and such; those could perhaps be used as a basis.
>
> That’s <https://issues.guix.gnu.org/53127> but it probably needs work if
> we want it to work reliably on all the packages. My understanding is
> that we’d need a “flag day” where we’d switch all Rust packages to
> Antioxyd
sh -l rust-..." won't be fixed until the source
code changes are done.
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
Maxime Devos skribis:
> On 02-11-2022 12:20, Ludovic Courtès wrote:
>> [. ..]
>> That’s <https://issues.guix.gnu.org/53127> but it probably needs work if
>> we want it to work reliably on all the packages. My understanding is
>> that we’d need a “fla
1 - 100 of 644 matches
Mail list logo
