On 23 November 2014 at 11:23, Ron <r...@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 <r...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
