On Sun, Jun 04, 2017 at 01:29:08PM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.43.4-2
> Severity: wishlist
> User: [email protected]
> Usertags: rebootstrap
>
> I'm having difficulties figuring the intended behaviour of e2fsprogs for
> mips* hosts. Can you clarify the following questions and update the
> packaging accordingly?
>
> * e2fsprogs Build-Depends: gcc-multilib [mips mipsel], yet it only
> actually builds 64bit libs during native builds. I think that either
> the build dependency should be annotated with <!cross> to indicate
> that gcc-multilib is not used during cross builds or e2fsprogs should
> build the 64bit libs during cross builds. What is preferred?
>
> * Having native builds differ from cross builds is considered bad
> practise. Ideally, we want to validate cross builds against native
> builds using diffoscope, i.e. we aim for reproducible cross builds.
> Please rethink whether this difference is really necessary. Building
> cross toolchains with multilib support is feasible. I've been doing
> that for like 2 years now. If opting out of these builds is
> necessary, the <nobiarch> build profile should be used rather than
> doing so unconditionally for cross builds.
>
> * It seems that the extra libraries are called libext2fs-nopic.a and
> lib64ext2fs-nopic.a (i.e. static libraries). Are they really still in
> use? They were added for #329074. As far as I understand that bug
> report, they were added for arcboot, which got removed November last
> year. So maybe these can go away as well?
I'm going to confess complete ignorance to what's going on with mips.
In the past my modus operandi is that I would make changes in response
to requests to the MIPS porters, in some cases with incomplete
understand why they were needed in the first place.
My bias would be to remove *all* of the mips specific exceptions in
the debian directory, and then see if things still build on mips, and
if there are any known problems caused by the mips installer or mips
bootpath. And if we do need to add back any exceptions for the MIPS
architecture, let's make sure it's very clearly documented why they
are there. Because at the moment, I'm a bit embarassed at my
inability to answer your perfectly reasonable questions. :-)
Does that seem reasonable? Are you willing to work with me to figure
out whether such a plan is going to cause problems with the installer
team, et. al? And I assume that because we're just about to release
Debian stable, this is really a post stretch activity, yes? Or is the
current state sufficient undesirable that it rises to the level of
release critical? (I don't think so, but I'm willing to be
pursuaded.)
Cheers,
- Ted
