[Pkg-sssd-devel] Bug#1069450: Bug#1069450: Bug#1069450: socket_wrapper and the time_t 64-bit is hard

[Chris Hofstaedtler]

On Mon, Sep 23, 2024 at 10:29:47PM +0200, Simon Josefsson wrote:
> Chris Hofstaedtler <zeha at debian.org> writes:
> > On Mon, Sep 23, 2024 at 02:32:20PM +0200, Simon Josefsson wrote:
> >> I am in the process of uploading a new upstream version into unstable
> >> that disables armel+armhf builds.
> >
> > You don't need to explicitly disable the architecutres, if your
> > package won't successfully build on them.
> > Just have the existing binaries removed from unstable and you should
> > be good. And downgrade this bug's severity, of course.
> 
> Thanks.  I'm trying to work out what the best way to proceed is.  I
> believe downgrading this bug report is now okay, since after the recent
> 1.4.3-1 upload armel/armhf is simply no longer supported, so build
> failures on those archs shouldn't happen any more.  I chose to keep the
> bug report open as a reminder to patch upstream's code to support
> armel+armhf.

Makes sense. It's good to have the build failure documented.

> I used the 'Build-Depends: not-supported-on [armel armhf]' approach to
> disable builds on armel and armhf for 1.4.3-1.
> 
> What would you recommend doing now?  Is one or more of the following
> ideas relevant?  Thanks for guidance.
> 
> 1) Drop the B-D hack so that instead builds on armel+armhf will just
> fail forever?

Basically your choice. Some maintainers consider it cleaner to have
the "Architecture:" field list just the supported archs, or use a
"Build-Depends:" variant to fail building, or just fail building.

For architectures that are not armel or armhf I suppose it's nicer
to just fail building, as porters could then work on your package.
For armel and armhf it seems unlikely that such porters would show
up, so I wouldn't spend extra time on it.

"not-supported-on" is a bit weird as an invention, but workable. I
would probably have used "architecture-is-64-bit", as that's an
actual virtual package that has defined properties. But as said, it
doesn't really matter.

> Won't that stall migration or lead to other problems?

No. A package can fail to build on most architectures, and that's
"just fine". But please see the answer to 4) below.


> 2) Is requesting removal of libsocket-wrapper from unstable on
> armel+armhf necessary?

Yes. You need to request this by filing a bug against
ftp.debian.org.

> Or will it happen automatically, since the version in unstable on
> those archs are now not the latest?  I don't know
> the unstable cleanup policy.

It doesn't happen automatically.

> 3) Should I open bug reports on the packages that Build-Depends on
> libsocket-wrapper armel/armhf?

Yes. I'm not sure what the severity for such bugs should be; I think
if you already made the change in unstable, then these bugs can
immediately be release critical.

> What should the recommendation be?  I suspect most usages of this
> package is optional and not required for building, so maybe a
> 'Build-Depends: libsocket-wrapper [!armel !armhf]' would work?

Yeah, if it is really optional, then that would work. Otherwise the
packages build-depending on libsocket-wrapper will also have to stop
being built; again that could just be because libsocket-wrapper will
be unavailable as a Build-Depends on armel armhf, or by explicitly
failing the build in some way.

> 4) Are any removal requests of reverse dependencies necessary or
> relevant?

Yes. You also should arrange for these removals before (or maybe
together) with the removal of libsocket-wrapper itself. One option
is to file all these bugs and have the bug for ftp.debian.org being
blocked by them.

> Will libsocket-wrapper migrate to testing without that?

No.

Testing migration will be blocked upon these things:

1) as long as old versions of your package exist in testing, build
failures are considered blocking. To get rid of the old versions in
testing, you have to ask for removal from unstable (!). (This sounds
weird, but it correct.)

2) if your package has autopkgtests and they previously succeeded on
an arch that you stop building for, the now "failing" autopkgtests
*may* block testing migration. If this happens, you'll have to ask
the release team to help you. The release team documents that they
want bugs to keep track of things, but sometimes asking nicely on
IRC in #debian-release also works.

3) as long as other packages need your package, either as
(Pre-)Depends or Build-Depends, testing migration will be blocked.
These need to be fixed.


Hope that helps!

Chris