On Fri, Oct 08, 2021 at 09:00:22PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/8/21 20:52, Rob Browning wrote:
> > Then, once that's uploaded were you planning to handle the reverse dep
> > rebuilds, and/or what coordination might we need there?
>
> We can just rebuild all of these reverse dep
On 10/8/21 20:52, Rob Browning wrote:
> Then, once that's uploaded were you planning to handle the reverse dep
> rebuilds, and/or what coordination might we need there?
We can just rebuild all of these reverse dependencies, yes. Adrian Bunk is
probably happy to take care of that job, he has access
John Paul Adrian Glaubitz writes:
> But again, we're doing this all the time and this affects a non-release
> architecture. I never said this flag should be passed for amd64 or arm64.
Understood. I was specifically thinking about any existing alpha
deployments and what the constraints might be.
On 10/8/21 05:08, Michael Cree wrote:
> I am still of the opinion that we should try in the first instance
> to find the real problem in the toolchain and fix it there. The bug
> affects packages other than guile and only on SMP systems.
I'm not arguing against fixing this bug. But without buildi
On 10/8/21 03:13, Rob Browning wrote:
> And while we can, of course, rebuild all the reverse deps (presumably
> only acceptable for testing/sid), doing so may still break things for
> anyone outside debian who's been relying on our packages (if we'd ever
> had any in testing -- sounds like maybe we
On Fri, Oct 08, 2021 at 03:03:38AM +0200, John Paul Adrian Glaubitz wrote:
> On 10/8/21 03:00, Rob Browning wrote:
> > If we've never had a 3.0 viable for alpha, for example, then we can of
> > course do whatever we like, with the realization that if we disable
> > threads there now, we may be stuc
John Paul Adrian Glaubitz writes:
> The alpha architecture is not part of any distribution which is why this
> argument is moot. I was not asking for this option to be set to an release
> architecture.
>
> Also, *if* we break the ABI, we can just rebuild all affected packages. We
> do that with b
Rob Browning writes:
> Given that, I think we may have at least these constraints:
Oh, and I haven't figured out what the current situation is wrt the
affected architectures on this front yet -- was just describing the
constraints.
If we've never had a 3.0 viable for alpha, for example, then we
John Paul Adrian Glaubitz writes:
> Without --without-threads, guile would not build on SMP systems and even
> the built package would crash on SMP systems.
>
> If disabling threads would break the ABI, we could just rebuild the affected
> reverse dependencies on the builds using the normal binNM
On 10/8/21 03:00, Rob Browning wrote:
> If we've never had a 3.0 viable for alpha, for example, then we can of
> course do whatever we like, with the realization that if we disable
> threads there now, we may be stuck with that choice until 3.2.
We can always break the ABI in a controlled manner.
Hello Rob!
On 10/8/21 02:56, Rob Browning wrote:
> I've checked with upstream, and while they were not certain that
> changing the --with-threads setting still breaks the library API, they
> thought it probably did, which I believe means we have to assume that it
> does (or could in the future), i
Hi Rob!
On 10/3/21 20:27, Rob Browning wrote:
> John Paul Adrian Glaubitz writes:
>
>> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
>> support. Passing --without-threads to configure disables thread
>> support and fixes the build.
>
> Hmm, I'm not certain we can do this un
Source: guile-3.0
Version: 3.0.7-1
Severity: normal
Tags: patch
User: debian-alpha@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-alpha@lists.debian.org
Hello!
Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
support. Passing --without-threads to configure disables thread
13 matches
Mail list logo
