Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On 23 November 2014 at 11:23, Ron <ron@debian.org> wrote:
> On Sat, Nov 22, 2014 at 08:51:41PM +0000, Dimitri John Ledkov wrote:
>> On 22 November 2014 at 16:21, Ron <ron@debian.org> wrote:
>> >
>> > Dimitri wrote:
>> >> Thus multiarch cross tooling is not so relevant for fresh bootstraps,
>> >> and/or targeting non-debian architectures, or otherwise incomplete
>> >> systems (e.g. those that do not have compatible set of pre-compiled
>> >> binaries that use multiarch-paths
>> >
>> > I'll leave it to Helmut to talk about his existing work with bootstraps
>> > that's been stalled by reverting this patch.
>> >
>> > I can categorically say though that we are currently using a toolchain
>> > built this way on Jessie before it was broken by this change, both for
>> > embedded systems that do run Debian, and for microcontrollers that
>> > couldn't possibly run it (memory measured in kB, no MMU). It works
>> > just fine for all of those cases.
>> >
>> > The *only* problem we have at present is that we can no longer update
>> > the Jessie systems this was being done on, because our ability to do
>> > this was removed and there appears to be no actually working replacement
>> > for it.
>
>> Also since it is a source package change, rebuild outside the archive,
>> one is free to patch it, thankfully the source packaging is open
>> source which one can patch when rebuilding toolchains in the partially
>> new to jessie ways.
>
> So ... you're saying that ... if someone manually restores this
> for themselves, they can have back the only behaviour that has been
> tested and is known to work (well or at all) for Jessie with m-a,
> but if it is restored in advance, so our users don't have to do that
> manually ... then the universe somehow comes to a cataclysmic end?
>
no, you are mangling my words, and not being constructive with me.
I don't know what's your involvement in this is, but I don't like
working with you.
Please stop.
"The only behaviour that has been tested and is known to work (well or
at all) for Jessie with m-a" has been available for a long time, and
is unchanged from stable and in testing. Which bit do you not
understand from this? And/or any parts of documentation I've sent in
the other email?
> Can you point us to the actual explanation of what *breaks*?
>
""""
The newly introdued mualtiarch cross building in jessie to a few packages:
* cannot be build on standard debian buildds
* cannot build multilib toolchains
* and thus resulting toolchains cannot rebuild non-trivial & core
debian packages
These reasons have been pointed out to the people raising this bug
report before. If anyone missed that for any reason, it is pointed out
now.
""""
I'm not sure if you are deliberately missing portions I've emails that I sent.
> The people who have actually been working on this _in Debian_ are
> well aware of what is not perfect about it and what extra work
> remains for post-Jessie to make it more so, and they are actually
> working on those things.
>
> They even have packages based on this uploaded to sid, so that the
> other work on fixing those things can continue, e.g.:
>
> https://packages.debian.org/sid/gcc-4.9-arm-linux-gnueabi
>
This package is not build on Debian and cannot be ever rebuild on
Debian. And RC bug reports are filed. This concrete example is very
good way to show that its upload is pre-mature. The reason is quite
simple, that we do not have foreign architectures enabled on the
builders, nor any easy way to enable them (being or has been fixed in
sbuild), however on-demand enabling foreign architectures will not be
in place until only after one stable release where it is possible to
do so and buildds getting upgraded to such release.
>
> What nobody has explained to us is what problem is *fixed* by
> gratuitously breaking this for existing users of Jessie.
>
The problem is introducing incomplete & broken things into archive.
E.g. the above uploaded package into sid FTBFS on any release: sid,
testing or stable. This is obsurd to call it as "actually working",
and no changes to gcc-4.X packages will make cross-gcc-4.9-armel
finally build from source on debian infrastructure.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766625
>
>
>> >> Can we all settle and move these developments to experimental
>> >> targeting for stretch, instead?
>> >
>> > Nobody is suggesting that other options can't be, or shouldn't be,
>> > explored for post-Jessie. Restoring the functionality that existed
>> > before this was removed will not in any way prevent or hinder that,
>> > it just means we won't repeat the sad state of Wheezy where this
>> > became no longer possible at all.
>> >
>> > Nothing you said here explains why we can't have the best of both
>> > worlds with this. If having this working for Jessie is "not so
>> > relevant" to you, that's fine - but it's very relevant to quite a
>> > few other people and was working for them until a few weeks ago
>> > when support for it was simply removed.
>> >
>> > We have people prepared to do the work to keep it working.
>> > What we don't have is an explanation of what it actually broke,
>> > if anything, to warrant removing it, without comment or warning,
>> > at this late stage of the Jessie release.
>
>> This bug report annoys me a lot, given the amount of inaccuracies it
>> has in portraying the current state of the affairs - that is
>> exaggerating the regression, when simply a desired feature by some,
>> failed pear-review was found feature incomplete and was not fully
>> included into jessie.
>
> You haven't actually pointed out anything inaccurate that anyone has
> said here, and having this working is actually a pre-requisite for
> some of the other work that you're saying isn't yet done, to be done.
>
early bug history has a mini-edit war on the topic, and frames newly
added 'multiarch-multiarch' crossbuilding as the only way available in
the debian packaging. when in fact, i stand by no existing features in
stable are not broken in unstable/testing.
> Yes, it's still a bit more awkward to build a toolchain than we all
> would like, but this is still infinitely easier and cleaner than
> anything we've ever had before. What do we gain by denying people
> the ability to easily use and experiment with that, in real life
> use cases, while we work on improving the other things too?
>
multiarch-multiarch is infinitely easier but for a very narrow use
case & very narrow timing.
Not useful for re-bootstrap - as pre-existing bootstrap binaries are
required (foreign multiarch debs).
Not useful for new arch bootstrap - as pre-existing bootstrap binaries
are required (foreign multiarch debs).
In-archive toolchain maintenance is also akward - as all
build-dependencies must be install-able and of all the same version
across build & host architecture. This is often affected by
architecture skew (and/or builder's speed - # of builders), but even
worse release team often binNMUs things with a skew - that is binNMU
select architectures instead of all of them. Then things are
essentially permanently multiarch non-co-installable. Until a said
package re-uploaded, or requested to binNMU to even things out.
"infinitely easier and cleaner" and a whole lot more fragile.
> Can you point us to this "pear-review" that you say occurred?
>
> The only thing I can see is that this functionality was quietly
> removed on the eve of the freeze, without any discussion with the
> people working on this _in Debian_, and that trying to discuss that
> is what led to this going pear-shaped and needing to be escalated
> to the -ctte for mediation.
>
Whenever I spoke with doko or wookey, they are all well aware of these
3 reasons, myself including.
I think it's irrelevant where it is. If you desprately need it, please
see bullet points in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#192
Which came with a warning: "If anyone missed (editor. reasoning) for
any reason, it is pointed out now."
>
>> Given a zero sum game rules,
>
> Fortunately, this isn't a zero sum game. We can have the Good now
> without ruining anyone's chances of making that Perfect later.
>
> Why is it in the interest of Debian or the users of Jessie to not
> (continue to) have that?
>
"zero sum game" was reference to the time I have, and where I can
contribute it in Debian, unrelated to the bug.
;-)
it's not "the Good" if a few people think it's "the Dangerous" or "the
Bad" =))))))
> Ron
>
>
--
Regards,
Dimitri.
Reply to: