search

build2-packaging / glfw

build2 package for glfw
0 stars 1 forks source link

All builds fail for submitted 3.3.6 packages #5

Closed boris-kolpackov closed 2 years ago

boris-kolpackov commented 2 years ago

All builds appear to be failing on queue for the 3.3.6 package: https://queue.cppget.org/glfw/3.3.6

Any idea what might be going on?

Swat-SomeBug commented 2 years ago

Hi @boris-kolpackov thanks a lot for reporting this. I think I understand what happened.

boris-kolpackov commented 2 years ago

Linux was always failing as CI is headless. I will disable Linux build going forward.

Actually, I would prefer if we can make things building on Linux. My understanding is that certain X11 libraries are missing and I would be happy to install them. Do you think you can come up with a list? In fact, if you could give me a list of headers you include, I could easily map them to Debian packages to install.

This breaks post install as config variables are not written to pkgconfig. I believe there was a feature request for this but at the moment, I may have a work around solution for glfw.

There is good news pending on this front. I will ping you shortly (most likely tomorrow).

MacOS fail is very surprising. [...] Strange thing is GitHub CI passes so I’m not sure what’s going on there.

Yes, that is strange, we try hard to make CI from git be as close as possible to a build from an archive. Let me know if you still cannot figure out the cause and I will take a look.

Swat-SomeBug commented 2 years ago

Actually, I would prefer if we can make things building on Linux. My understanding is that certain X11 libraries are missing and I would be happy to install them. Do you think you can come up with a list? In fact, if you could give me a list of headers you include, I could easily map them to Debian packages to install.

This would be good. However, I believe the tests would still fail on linux. By default, the linux build uses X11 and all tests require DISPLAY to be set and available to connect. glfw does support off screen rendering to get around this which can be enabled by setting config.glfw.useosmesa=true. Nonetheless the required Ubuntu packages to get a build passing are:

There is good news pending on this front. I will ping you shortly (most likely tomorrow).

Great. Would be very interesting. I tried to probe c.libs from an installed glfw, aiming to search for pattern by using

import libs = glfw%lib{glfw}
glfw_c_libs = [strings] $($libs: c.libs)

However, glfw_c_loptions is [null] for an installed package but gives the correct set of libraries for a config initialized glfw package. So, I don't basically have a solution so far.

Yes, that is strange, we try hard to make CI from git be as close as possible to a build from an archive. Let me know if you still cannot figure out the cause and I will take a look.

I found that glfw-tests fails on macos with clang-13 but pass with clang-12 (test only, not tests-installed). The CI is here. Github CI uses clang-11 which potentially explains the pass. At the moment, I'm unsure if the issue is isolated to apple-clang only. This requires more debug.

Swat-SomeBug commented 2 years ago

On cppget the MacOs failure maybe actually correct. Thinking a bit more, glfw-tests/exe{monitors} probes the system for attached monitors and prints each monitor’s properties. An empty STDOUT is still valid, indicating no monitors attached and makes sense for servers without a physical display attached. PR #6 basically allows STDOUT to be empty.

Side note: GitHub CI passing on v3.3.6 indicates that the MacOS machine has a physical monitor attached.

boris-kolpackov commented 2 years ago

Thanks for the packages, will aim to install them before the upcoming release.

Regarding the metadata storage in pkg-config, the functionality is available in the latest staged toolchain and is described in this HOWTO article: https://github.com/build2/HOWTO/blob/master/entries/convey-additional-information-with-exe-lib.md

It would be great if you could give it a try and report any issues (while you won't be able to publish the result yet, 0.15.0 is hopefully only a few weeks out).

FYI, you can CI the result on https://ci.stage.build2.org (which the staged toolchain uses by default).

Side note: GitHub CI passing on v3.3.6 indicates that the MacOS machine has a physical monitor attached.

Hm, that would be surprising unless they are running rack-fulls of iMacs, which would be pretty insane (but everything is possible, especially with Microsoft). My best guess is they are running things on physical machines (but without monitors attached) while we run things in VMs (into which we logic with VNC) -- maybe this makes the difference?

boris-kolpackov commented 2 years ago

Ok, I've added a set of Linux GCC 12 configs to stage CI that have all these packages installed: https://ci.stage.build2.org/?build-configs=gcc-12+

It would be great if you could try them and confirm nothing is missing before I start replicating this to all the other Linux configs. Thanks!

Swat-SomeBug commented 2 years ago

Ok, I've added a set of Linux GCC 12 configs to stage CI that have all these packages installed: https://ci.stage.build2.org/?build-configs=gcc-12+

It would be great if you could try them and confirm nothing is missing before I start replicating this to all the other Linux configs. Thanks!

Hi @boris-kolpackov Thank you very much for adding in these packages. The CI task can be found here. glfw builds successfully in this case, however, tests fail as expected because DISPLAY env variable is not defined and available, which is a requirement for on X11 (default) and Wayland builds on Linux.

Swat-SomeBug commented 2 years ago

Fixed in v3.3.6+1

boris-kolpackov commented 2 years ago

glfw builds successfully in this case, however, tests fail as expected because DISPLAY env variable is not defined and available

FYI, that GCC 12 CI configuration now has X server (Xvfb) running and DISPLAY set. Again, it would be great if you could test it and see if anything is missing. Note that we will most likely have this setup for all the Linux configurations eventually but it's unlikely we will mess with this for FreeBSD, etc. So I think the tests should still be prepared to run headless.

Swat-SomeBug commented 2 years ago

Hi @boris-kolpackov I tried to run another CI but it seems GCC 12 config is missing at the time of my run. Is this only momentary? I remember there was a gcc-12+ config which I don't find anymore.

image
boris-kolpackov commented 2 years ago

I think you are looking at ci.cppget.org -- this GCC 12 config is currently only available on ci.stage.build2.org. You can submit to this CI service with bdep ci --server https://ci.stage.build2.org (the staged toolchain submits there by default).

Swat-SomeBug commented 2 years ago

Oh yes... my mistake, didn't switch to the stage version of the toolchain when submitting the CI. Please find the CI task here. Everything seems to work out fine and for glfw in default configuration (X11).

I believe Xvfb doesn't work with Wayland (not sure). But Weston should already have something similar to Xvfb built-in. I can try to submit into a Wayland config and report back.

But for the moment, it seems default configuration works well and it would be great if other configs could also get these packages.

boris-kolpackov commented 2 years ago

But for the moment, it seems default configuration works well and it would be great if other configs could also get these packages.

Yes, that's the plan. Thanks for testing!

I believe Xvfb doesn't work with Wayland (not sure). But Weston should already have something similar to Xvfb built-in. I can try to submit into a Wayland config and report back.

I think we will start with Xvfb for this release and maybe add additional configurations for Wayland and/or Weston if necessary later. I am not even sure at this stage what would that involve.

Swat-SomeBug commented 2 years ago

New version has been released. Preliminary testing with ci.cppget.org is complete with success. This issue will be closed.