Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-23 Thread Fabian Grünbichler
On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> > Hi Wesley, Yaroslav, Carsten and Mike,
> 
> Hi Fabian,
> 
> Let me start by thanking you for the work going into packaging rustc.
> 
> > while we try to keep rustc somewhat current in sid, this is not always
> > possible in a timely manner.
> 
> rustc 1.70 was released on June 1 and made it to unstable in September.
> We're now 7 months later.

yeah, most of the delay there was a result of bookworm and the freeze
(rustc as part of the toolchain set gets frozen early, and we found out
the hard way this time around that if we prepare release in experimental
we still have to go through bin-NEW - and of course, we've also had our
hands full with other getting-rustc-stuff-ready-for-bookworm things at
that time).

> At the time rustc 1.70 was released, unstable had... 1.63, which was
> released close to a year prior, at which time unstable had... 1.59.

see above. 4-5 versions is  not unheard of. when 1.70 was released, we
had 1.67 in experimental, for example.

> "rustc somewhat current in sid" might have been true in the past, but
> that has unfortunately not been the case for at least two years, now.
> I'm not discounting your work, merely stating the hard truth.

we might have different definitions of "somewhat current" :)

most stable projects are okay with about 6 months lag, which is about 4
rustc releases.  and that's not taking into account that we don't always
package the latest release the moment it's out of the door for things
depending on rustc/cargo either.

I do aim for less, of course, but it doesn't always work out as
intended.

> The sad part is, as you noted, the more outdated the version in unstable
> is, the worse it gets to update it...

well, the amount of work it takes is about the same, but the wait is of
course longer if the lag is bigger, yes.

> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

well, I'd be happy to share the workload ;)

but it requires a substantial commitment - reviewing an MR for an
update is not that much less work than doing it myself, since the
package is quite complex, and quite important. I can do that a few
times, but if it's not for somebody who wants to comaintain long-term
it's probably time better spent improving the tooling or specific bugs.

I do hope to at least get rid of two bottle necks soon that have
affected updates in the past
- the split between cargo and rustc, with cargo having its own set of
  problems that made updating harder, which should be mostly eliminated
  with the merge
- me just being a DM, with additional delays introduced by waiting for
  somebody else from the team somewhat familiar with the packages
  uploading to bin-NEW (I am a DD now, but my key/account is not active
  yet)

> At least for firefox, I managed to relax the rustc requirement back to
> 1.70, so the urgency is slightly less severe at least for that package,
> for now.

that's good to know, I'll still try to get the lag reduced ASAP!



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-22 Thread NoisyCoil
Package: rustc
Followup-For: Bug #1068008
X-Debbugs-Cc: noisyc...@tutanota.com

Hi,

I join the others in offering my help. If there is anything we can do please 
let us know!

Best,

NoisyCoil



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-22 Thread Wesley Schwengle


Hello all,

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
>
> >
> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

I second the "Is there anything we can do the make things better?". Are there
things we can do now already, that might speed up packaging rust to
1.77/1.78/1.79 besides waiting the t64 migration to be completed?

I can offer a day a week in help if needed.

Cheers,
Wesley



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-22 Thread Mike Hommey
On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> Hi Wesley, Yaroslav, Carsten and Mike,

Hi Fabian,

Let me start by thanking you for the work going into packaging rustc.

> while we try to keep rustc somewhat current in sid, this is not always
> possible in a timely manner.

rustc 1.70 was released on June 1 and made it to unstable in September.
We're now 7 months later.

At the time rustc 1.70 was released, unstable had... 1.63, which was
released close to a year prior, at which time unstable had... 1.59.

"rustc somewhat current in sid" might have been true in the past, but
that has unfortunately not been the case for at least two years, now.
I'm not discounting your work, merely stating the hard truth.

The sad part is, as you noted, the more outdated the version in unstable
is, the worse it gets to update it...

> I am sorry to say that I don't expect us to be caught up with 1.75
> (which is 5 trips through bin-NEW, one of them bigger than usual cause
> of the merge, and probably 20-40h of rebasing and testing work on my
> end) until at least the end of May :( I will make sure to include the
> requirements of thunderbird/firefox if things get stuck in NEW for too
> long.

And by end of May, we'll be close to the upstream release of rustc 1.79...

Is there anything we can do to make things better? Presumably, the
src:cargo merge should help here, at least a little (because cargo being
outdated has also been another source of recurring problems).

At least for firefox, I managed to relax the rustc requirement back to
1.70, so the urgency is slightly less severe at least for that package,
for now.

Mike



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-22 Thread Fabian Grünbichler
On Fri, 29 Mar 2024 11:14:44 -0400 Wesley Schwengle  
wrote:
> Package: rustc
> Version: 1.70.0+dfsg1-9
> Severity: wishlist
> X-Debbugs-Cc: wes...@schwengle.net
> 
> Dear Maintainer,
> 
> 
> I was trying to build a rust package from source when I noticed they use
> traits. Async traits are supported as of 1.75. It would be beneficial to 
> Debian that
> we can start developing rust with these traits.
> 
> Currently upstream sits at 1.77.x, it would be nice if we could get at least 
> to
> 1.75 , but 1.77.x would be preferred.
> 
> https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html
> 
> 
> Many thanks and cheers,
> Wesley

Hi Wesley, Yaroslav, Carsten and Mike,

while we try to keep rustc somewhat current in sid, this is not always
possible in a timely manner.

We are currently stuck on a few related issues:
- the planned src:cargo and src:rustc merge being delayed because of t64
- t64 still not being done for us because LLVM is broken on armel
- updating rustc can only be done version by version(!), or by a massive
  re-bootstrapping on each arch to jump versions

I am sorry to say that I don't expect us to be caught up with 1.75
(which is 5 trips through bin-NEW, one of them bigger than usual cause
of the merge, and probably 20-40h of rebasing and testing work on my
end) until at least the end of May :( I will make sure to include the
requirements of thunderbird/firefox if things get stuck in NEW for too
long.

I will prioritize the merge upload at the start of May, even if t64 is
not done by then. In the worst case, armel/armhf will have to be
rebootstrapped at some later point if they don't manage to catch up in
time.

Fabian



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-04-15 Thread Mike Hommey
On Fri, Mar 29, 2024 at 11:14:44AM -0400, Wesley Schwengle wrote:
> Package: rustc
> Version: 1.70.0+dfsg1-9
> Severity: wishlist
> X-Debbugs-Cc: wes...@schwengle.net
> 
> Dear Maintainer,
> 
> 
> I was trying to build a rust package from source when I noticed they use
> traits. Async traits are supported as of 1.75. It would be beneficial to 
> Debian that
> we can start developing rust with these traits.
> 
> Currently upstream sits at 1.77.x, it would be nice if we could get at least 
> to
> 1.75 , but 1.77.x would be preferred.
> 
> https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html

Firefox will require 1.74 in version 125 (which will be released in a
few hours), and at least 1.76 in version 127.

Mike



Bug#1068008: rustc: Please package rust 1.75 or higher

2024-03-29 Thread Wesley Schwengle
Package: rustc
Version: 1.70.0+dfsg1-9
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,


I was trying to build a rust package from source when I noticed they use
traits. Async traits are supported as of 1.75. It would be beneficial to Debian 
that
we can start developing rust with these traits.

Currently upstream sits at 1.77.x, it would be nice if we could get at least to
1.75 , but 1.77.x would be preferred.

https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html


Many thanks and cheers,
Wesley

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rustc depends on:
ii  binutils  2.42-4
ii  gcc   4:13.2.0-7
ii  libc6 2.37-15.1
ii  libc6-dev [libc-dev]  2.37-15.1
ii  libgcc-s1 14-20240315-1
ii  libstd-rust-dev   1.70.0+dfsg1-9

Versions of packages rustc recommends:
ii  cargo0.70.1+ds1-3
ii  llvm-16  1:16.0.6-24

Versions of packages rustc suggests:
ii  clang-16  1:16.0.6-24
pn  lld-16

-- debconf-show failed