[service] Pull Request Request: bump ubuntu images to bionic

[ericLemanissier]

Community users are not allowed to do pull requests on CI files, so I'm making a PR request to bump ubuntu xenial to ubuntu bionic:
/~https://github.com/conan-io/conan-center-index/compare/master...ericLemanissier:bionic?expand=1

This follows:

• modern: bump base to Bionic conan-docker-tools#466

This blocks all PR to projects not suppoting Xenial (at least qt6)

[uilianries]

/cc @danimtb @davidsanfal

[ericLemanissier]

friendly ping @danimtb @davidsanfal
What is your feedback on this change ? we cannot do anything without you on this one. As a reminder, qt6 recipe has been frozen for 7 weeks because of this. An approximate time frame, or a clear "no" would be much appreciated

[jcar87]

What is your feedback on this change ? we cannot do anything without you on this one. As a reminder, qt6 recipe has been frozen for 7 weeks because of this. An approximate time frame, or a clear "no" would be much appreciated

Hi @ericLemanissier - we are currently working on this and would expect to have this completed before the end of November. We have already done the ground work for this and are in the process of testing this change and make sure it doesn't negatively impact anything that should continue working.

We are balancing this alongside other priorities, we appreciate your patience on this one.

[ericLemanissier]

@jcar87 Sorry to bother you again. I'm being curious: what is the updated plan for this bump ?

[jwillikers]

I would also like to see this updated, thanks!

[paulharris]

I didn't know about this issue until my QT refused to build.
Can we at least add an option to the QT recipe to allow it to build locally?
I'm assuming the validate() is set to prevent the recipe from building on the CIs until the CIs get upgraded, but the recipe can be built locally on dev machines, right?

[ericLemanissier]

Some possibilities:

• add a bolean option qt:on_C3I which would be true by default, and raise only if on_C3I is True
• add a string option qt:xcb_version which would have a default value inferior to 1.12, and raise only if xcb_version is less than 1.12
• raise only if an environment variable NOT_ON_C3I is not set

@SpaceIm @uilianries What do you think ?

[uilianries]

C3I does not provide a custom env var, but as it's running under Jenkins, so CI should be defined.

About Ubuntu 18.04 we still don't have a date, but it's listed to be done.

[paulharris]

re the CI var, I suppose other people running their own build machines on Jenkins would be affected too?
Perhaps just need to test for the special case that we are on this particular problematic platform?
Else just hold out a bit longer, I will survive with my hack but others will have to find their own way.

Perhaps for future, would be good to have a ON_CONAN_CCI_CI envvar to handle these situations?

[fdgStilla]

We had to create custom packages to remove the qt limitation in the recipe. We had the same issue for jasper, which does not build on the conan center CI. This is really annoying that all recipe consumer are prevented to build when the problem is on conan center CI. I totally understand that the CI may have issues sometimes but we should definitely have another way of keep integrating recipe on conan center with CI issues and still allow consumers to build on their own machine.

[ericLemanissier]

Could you please review/try #14734 ?

[Minimonium]

That's a rather unfortunate workflow to opt out of a blocking feature, considering that there is no explicit detection for the version of appropriate distribution dependency.

[Sil3ntStorm]

This is not feasible.
Even if you set

[env]
NOT_ON_C3I=1

in the profile used, qt/6.5.2 still refuses to build locally.
Being forced to modify the system environment for a CCI issue just feels wrong.

[AndreyMlashkin]

It's been already 2 years since the ticket was opened. Any idea of improvement?

[stevenwdv]

Hey, there is still a warning in the qt recipe referencing this issue, while it is closed. Can someone tell me what is going on?

[ericLemanissier]

Well, nothing is going on. I failed to create momentum on the conan team side, so I dropped the ball. If you have some energy and courage to try, don't hesitate to create a new issue referencing this one.

[stevenwdv]

@ericLemanissier Oh. I don't really understand a couple of things:

• What is the exact issue with newer compilers?
• Why do I have to specify I'm not Conan's CI, instead of the other way around?
• Why is this issue closed, while it is not fixed and still referenced?

[ericLemanissier]

@ericLemanissier Oh. I don't really understand a couple of things:

• What is the exact issue with newer compilers?

The issue is not actually related to compiler version, it is related to the distro used by conan-center's CI (C3I) to build packages with these compilers: this distro is outdated.

• Why do I have to specify I'm not Conan's CI, instead of the other way around?

please read the issue above. conan-center CI does not advertise itself in any way

• Why is this issue closed, while it is not fixed and still referenced?

as I said in my last message, I lost faith that the change will happen

[Minimonium]

We can potentially try to use detect_api.detect_glibc conan-io/conan#15683 to block the building on older distros, but it should be an opt-in env variable to skip the check in cases of exotic disros.

[ericLemanissier]

this would not help. in the case of qt the problem has nothing to do with glibc, but with the version of xcb-randr0 , which is too old for qt.

cf #12620 (comment)

[Minimonium]

You'd use the glibc version to wing the version of debian-based distros. The goal (at least mine haha) is to remove the requirements for users to explicitly pass the env variable when their systems are new enough.

Say 2.23 will indicate that we have a too old xcb-randr0. If you have an up too date xcb-randr0 but too old distro then you'll disable the check with env variable.

[ericLemanissier]

You have to decide if you can build or not in the validate(self) method, and raise an exception if you cannot build (too old libc/xcb-randr). The problem is that (IIRC), C3I runs all the validate method in an environment which is not the one used for actual build, and chooses which packages to build based on the results. This means that we can rely only on settings and options in validate(self), nothing else.

[stevenwdv]

Seems like this has been resolved by #22971, nice!