Wookey dixit:
>And it worked beatifully. Thanks.
Nice!
>I'll try doing openjdk-20 next.
You’ll want 21 as 20 has not got the t64 treatment.
gl hf,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
On 2024-03-27 22:30 +, Thorsten Glaser wrote:
> >OK, got those. but that's just binaries. It was the source changes I
> >was looking for (or did I misunderstand and you didn't actually make
> >any of those?),
>
> Yes, I did not make any source changes. These were the last binaries
> from
Hi Wookey,
>OK, got those. but that's just binaries. It was the source changes I
>was looking for (or did I misunderstand and you didn't actually make
>any of those?),
Yes, I did not make any source changes. These were the last binaries
from before the t64 transition (I downloaded the .deb files
On 2024-03-27 15:27 +, Wookey wrote:
> On 2024-03-26 22:28 +, Thorsten Glaser wrote:
>
> > I hacked that, and I tried to do armel and armhf as well but
> > dak stopped me, whereas mini-dak was not as strict.
>
> What was the actual problem with uploading the images you built? Just
> not
On 2024-03-26 22:28 +, Thorsten Glaser wrote:
> I hacked that, and I tried to do armel and armhf as well but
> dak stopped me, whereas mini-dak was not as strict.
What was the actual problem with uploading the images you built? Just
not having any corresponding source? Or something more
On 2024-03-26 13:56:26 +, Simon McVittie wrote:
> I think binNMUs for packages involved in
> https://release.debian.org/transitions/html/auto-sphinxbase.html
> would be useful. If I'm reading correctly, that would unblock ffmpeg
> on armel/armhf (or at least get some way towards it), and
On Wed, 27 Mar 2024, Wookey wrote:
>I looked at this last week, but got stuck because openjdk-17's
>build-deps included graphviz
Build-Depends-Indep: graphviz, pandoc
You don’t need that. Use dpkg-checkbuilddeps -B, or manual
inspection of the .dsc (packages.d.o does show the difference
between
On 2024-03-26 10:35 +, Simon McVittie wrote:
> It seems that some of the dependency chains for packages that are still
> waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
> default Java version for most architectures and Build-Depends on itself
> (with an alternative
On Tue, 26 Mar 2024, Jeffrey Walton wrote:
>Nothing beats a native compile in your basement.
Yes, definitely.
>> Do they run stock Debian armhf?
>
>So the CubieTruck is embarrassingly down level:
Oofff…
>The Wandboard is doing better:
Right, close enough anyway.
>I don't mind shipping to
On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser
wrote:
>
> I’m answering back from the $dayjob address because Googlemail
> cannot communicate with normal mailservers.
>
> >I can send you two dev boards, if you want them. The first is
> >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second
Hi Jeffrey,
I’m answering back from the $dayjob address because Googlemail
cannot communicate with normal mailservers.
>I can send you two dev boards, if you want them. The first is
>Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
>CubieTruck 5 (Cortex-A7, ARMv7 with NEON and
On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote:
>
> [...]
>
> The options for the armel/armhf porters are to either get the
> .debs from me, install them in a chroot, and then the other B-D,
> and rebuild the packages, or to use dpkg --force-depends to
> install the dependencies (which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I
I think binNMUs for packages involved in
https://release.debian.org/transitions/html/auto-sphinxbase.html
would be useful. If I'm reading correctly, that would unblock ffmpeg
on armel/armhf (or at least get some way towards it), and ffmpeg is
involved in a bunch of other sub-transitions.
(I hope
It seems that some of the dependency chains for packages that are still
waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
default Java version for most architectures and Build-Depends on itself
(with an alternative dependency on openjdk-16, but that no longer exists).
On 2024-03-13 02:08, Emanuele Rocca wrote:
> When it comes to actually satisfying build-depends properly it seems
> that as of right now the missing ones are libcurl4-gnutls-dev and
> libgit2-dev.
Cargo is now done. With libcurl4-gnutls-dev and libgit2-dev available I
could bootstrap it on
Hi,
On 2024-03-12 05:55, Emanuele Rocca wrote:
> I did manage to get cargo to build in a armhf chroot by manually
> installing the various deps
When it comes to actually satisfying build-depends properly it seems
that as of right now the missing ones are libcurl4-gnutls-dev and
libgit2-dev. curl
On Tue, Mar 12, 2024 at 05:55:59PM +0100, Emanuele Rocca wrote:
> [ debian-rust added to CC ]
>
> Hi,
>
> On 2024-03-12 11:03, Simon McVittie wrote:
> > In the medium term, cargo needs re-bootstrapping on the affected
> > architectures (armel and armhf, plus a bunch of -ports architectures
> >
[ debian-rust added to CC ]
Hi,
On 2024-03-12 11:03, Simon McVittie wrote:
> In the medium term, cargo needs re-bootstrapping on the affected
> architectures (armel and armhf, plus a bunch of -ports architectures
> where as far as I can see cargo was never available in the past) -
> that's
Control: block -1 by 1065787 1066049
One dependency chain that is blocking a lot of rebuilds right now is
this one:
... => curl -> stunnel4 -> python-cryptography => cargo => ...
key: => mandatory dependency
-> nocheck dependency
In the medium term, cargo needs
On Sat, Mar 02, 2024 at 02:16:59PM +0100, Sebastian Ramacher wrote:
> On 2024-03-02 15:06:15 +0200, Adrian Bunk wrote:
> > On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote:
> > >...
> > > This needs to be built with dpkg-dev (>= 1.5.22), ...
> > >...
> >
> > The correct version is
On 2024-03-02 15:06:15 +0200, Adrian Bunk wrote:
> On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote:
> >...
> > This needs to be built with dpkg-dev (>= 1.5.22), ...
> >...
>
> The correct version is 1.22.5 (and >= 1.5.22 therefore a nop).
There was already an upload by the
On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote:
>...
> This needs to be built with dpkg-dev (>= 1.5.22), ...
>...
The correct version is 1.22.5 (and >= 1.5.22 therefore a nop).
cu
Adrian
On 2024-03-01 23:10:22 -0800, Steve Langasek wrote:
> Please binNMU fyba on armhf and armel. The maintainer uploaded it without
> versioned build-deps so it is renamed but has wrong ABI.
>
> This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1).
Scheduled everywhere since it
Please binNMU fyba on armhf and armel. The maintainer uploaded it without
versioned build-deps so it is renamed but has wrong ABI.
This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
On 2024-02-29 23:08:45 -0800, Steve Langasek wrote:
> We are going to need a lot of binNMUs for the time_t transition of course,
> but we're not quite ready to do the mass binNMUs.
>
> In the short term, can you please binNMU apt for libgnutls30t64?
>
> This needs to be built with dpkg-dev (>=
We are going to need a lot of binNMUs for the time_t transition of course,
but we're not quite ready to do the mass binNMUs.
In the short term, can you please binNMU apt for libgnutls30t64?
This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1),
and libgnutls28-dev (>=
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
Dear Release Team,
I had started a thread on debian-devel[1] about the need to migrate 32-bit
architectures to 64-bit time_t in preparation for 2038, an ABI-breaking
change.
As the
28 matches
Mail list logo
