[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]



Hi Ted,

Paul Gevers <elbrus@debian.org> (2021-05-20):
> On 20-05-2021 00:11, Theodore Y. Ts'o wrote:
> > Ping to the debian-release bug.
> 
> Unfortunately, there was no release.debian.org bug to track this.  Due
> to the current high volume to our list, this fell from the radar. To
> avoid this I now generate a pre-approval unblock request to discuss
> this, because than it shows up in our tools. Please follow up there.

Yes, and I see a question was raised for the Installer team but
debian-boot@ wasn't cc'd, and we aren't psychic. :)

> > Do you want me to upload a fix to this bug where e2fsprogs fails its
> > regression test (and thus its package build) when armhf and armel
> > are running on a 64-bit ARM platform, but they were built
> > successfully when run on a 32-bit ARM builder?
> 
> e2fsprogs is on the (build-)essential list [1], so I'm glad you ask
> before uploading as we ask in the freeze-policy [2].
> 
> > No question this is a real bug, and it is fixed upstream already.
> > But do you want me to upload a fix *now*, during the hard freeze,
> > given the impact on the installer, et. al.?
> 
> Can you elaborate where you see the *risks* of the patch? Is this
> patch backwards compatible? I.e. does it work correctly on data
> generated with the old e2fsprogs? If not, what must the user do to
> avoid issues? Should it be mentioned in the release notes?
> 
> Apart from the failing test cases, I see in the patch description that
> there's also real use cases impacted (corner cases if I interpret them
> right). IIUC these are no regressions but I'd like to be sure. And
> what's the impact for users of those corner cases (especially the new
> Linux feature, I would expect that some users would be going to use
> those).

If that's fine for the release team, I'd be happy to have the package in
unstable so that can be tested via daily builds of the installer (they
pull udebs from unstable). I'm not sure how much testing those daily
builds get from people running arm* systems, but it would be better to
have the fix at least exposed to some testing than just ponder looking
at the source debdiff (I know alignment issues are not my forte…).


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


Reply to: