Re: [HTCondor-users] Debian Bullseye build fails, Re: HTCondor 8.8.11 Released

[Steffen Grunewald <steffen.grunewald@xxxxxxxxxx>]

On Fri, 2020-10-23 at 14:38:04 +0200, Steffen Grunewald wrote:
> On Fri, 2020-10-23 at 13:13:42 +0200, Steffen Grunewald wrote:
> > In a Buster build, I get
> >
> > -- Configuring for Debian package on Debian-10--amd64
> >
> > while for Bullseye, this reads
> >
> > -- Configuring for Debian package on Debian---amd64
> >
> > - apparently "testing" doesn't have all the /etc/os-release information in
> > place yet?
> > ... but this leads, in  astraight manner, to
> >
> > -- SYSTEM_NAME: Debian-
> > -- Boost components: python;unit_test_framework
> > CMake Error at /usr/lib/x86_64-linux-gnu/cmake/BoostDetectToolset-1.71.0.cmake:8 (list):
> >   list index: 1 out of range (-1, 0)
> > Call Stack (most recent call first):
> >   /usr/lib/x86_64-linux-gnu/cmake/boost_python-1.71.0/boost_python-config.cmake:24 (include)
> >   /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:117 (find_package)
> >   /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 (boost_find_component)
> >   /usr/share/cmake-3.18/Modules/FindBoost.cmake:448 (find_package)
> >   externals/bundles/boost/1.66.0/CMakeLists.txt:88 (find_package)
> >
> > Is there a way to outsmart Debian version detection? Unlike Ubuntu Focal, Bullseye
> > isn't official yet...
> 
> It was a wise choice for the naming of Debian unstable: that Sid guy has the
> potential to destroy everything.
> 
> build/cmake/macros/SystemSpecificInformations.cmake seems to be the place to go.
> I'm not familiar with CMake syntax, but there's a special case where /etc/issue
> has "Debian .*/sid" in it (and no version number like officially released distros).
> It should be sufficient to use something like 99.9 in that case, and only if there's
> no "sid" match in the "Debian" line use the existing code from lines 171ff.

I did it, and indeed got a 'Debian-99' string, but unfortunately this did not resolve
the primary issue.
Having a closer look into BoostDetectToolset-1.71.0.cmake, this seems to be an issue
with identifying the GCC - but why didn't this show up for others? In particular,
why didn't this stop the "focal" build? Since there's no build log publicly available,
perhaps Tim can tell me which GCC version had been used?

I also went back and walked through the build logs of previous versions - while GCC 9
was still current, there had been no problems, but this was also with boost 1.67. 
8.8.9 failed for different reasons, and for 8.8.10 I had already reported the issue
but haven't seen a response since.

How to proceed?

- S