Github SWT Linux verification builds fail on ubuntu-latest

[jukzi]

Each and every recent PR after #1627 sees

Error:  Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (build-native-binaries) on project org.eclipse.swt.gtk.linux.x86_64: An Ant BuildException has occured: exec returned: 2
Error:  around Ant part ...<exec failonerror="true" dir="${build_dir}" executable="sh">... @ 24:73 in /home/runner/work/eclipse.platform.swt/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64/target/antrun/build-main.xml
Error:  -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (build-native-binaries) on project org.eclipse.swt.gtk.linux.x86_64: An Ant BuildException has occured: exec returned: 2
around Ant part ...<exec failonerror="true" dir="${build_dir}" executable="sh">... @ 24:73 in /home/runner/work/eclipse.platform.swt/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64/target/antrun/build-main.xml
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:206)
    at java.lang.reflect.Method.invoke (Method.java:569)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute (DispatchUtils.java:99)
    at org.apache.tools.ant.Task.perform (Task.java:350)
    at java.util.Vector.forEach (Vector.java:1365)
    at org.apache.tools.ant.taskdefs.Sequential.execute (Sequential.java:67)
    at net.sf.antcontrib.logic.IfTask.execute (IfTask.java:197)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:569)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute (DispatchUtils.java:99)
    at org.apache.tools.ant.TaskAdapter.execute (TaskAdapter.java:155)
    at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:299)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:569)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute (DispatchUtils.java:99)
    at org.apache.tools.ant.Task.perform (Task.java:350)
    at org.apache.tools.ant.Target.execute (Target.java:449)
    at org.apache.tools.ant.Target.performTasks (Target.java:470)
    at org.apache.tools.ant.Project.executeSortedTargets (Project.java:1401)
    at org.apache.tools.ant.Project.executeTarget (Project.java:1374)
    at org.apache.maven.plugins.antrun.AntRunMojo.execute (AntRunMojo.java:297)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:206)
    at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run (SmartBuilderImpl.java:71)
    at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1136)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635)
    at java.lang.Thread.run (Thread.java:840)

@HannesWell is this caused by #1627 ?

I am frustrated that @eclipse-platform-committers keep submitting with failed builds without even creating a bug for it.

Please see "If tests are broken then they should either be fixed or documented (create a new issue or mention an existing one)." https://github.com/eclipse-platform/.github/blob/6ea5eef770ddcf1983d92590ffe14aef71091511/CONTRIBUTING.md?plain=1#L138

@eclipse-platform/eclipse-platform-project-leads

[akurtakov]

My only proposal is to make certain checks mandatory and thus disallow merging (maybe with a PL exception for emergencies). That's a general remark that would work good for other platform repos but for swt will create real blockage as e.g. an infra update will put everything on hold for all OSes until issue is fixed (current failures are real and major ones for distros using newer webkitgtk and no problem at all for older ones).

[HannesWell]

@HannesWell is this caused by #1627 ?

That PR has only changed the way how the kubernetes pod to compile the SWT natives for Linux. X86_64 is provisioned in Jenkins.
But this should have no influence on the GitHub workflows because they always recompile for their running platform.

But I understand your frustration and will try to have a look at this.

[laeubi]

The linux build currently fails because we use deprecated GTK APIs... any help to fix them are welcome.

[HannesWell]

Right. I forgot that again...
If one is interested, you can search the build-log for -Werror=deprecated-declarations.

[fedejeanne]

Are there any plans to solve or work around this?

Would it be possible to let the build fail when new usages of deprecated methods arise, like it's done for other projects?

[fedejeanne]

Hm, I see this is nothing new --> #652

And a possible solution is to move the deprecated methods to GTK3.java --> #652 (comment)

Some methods have been moved already --> #1482

Maybe @ptziegler can assist here?

[fedejeanne]

The linux build currently fails because we use deprecated GTK APIs... any help to fix them are welcome.

@laeubi What I don`t get is how is this became a problem only recently. I mean warnings have been treated as errors for almost 4 years now, right? --> 023954e

What changed recently and triggered the build failures?

[ptziegler]

What changed recently and triggered the build failures?

My guess is a newer version of GTK4 on the docker images. Most of the API has only been deprecated starting with GTK 4.10 and 4.14, so you wouldn't get those warnings when building with an older version.

And a possible solution is to move the deprecated methods to GTK3.java

Just as a remark: While this should be the long-term goal, it is not something that can be achieved anytime soon. As an example, there are 1000 references to the TreeModel API that was deprecated in GTK4...

[laeubi]

Just as a remark: While this should be the long-term goal, it is not something that can be achieved anytime soon.

I have now created as an idea how to solve the issue until we can further proceed here, but ti might fail as soon as a deprecated method is actually removed and the runner is updated.

• Disable deprecation warning in GTK at github validataion #1692

I also wanted to note that even GTK4 is still a top priority of Eclipse IDE WG I like to highlight the important parts here (as of today):

• has high priority for many members/companies
• unclear whether we can cover all the issue with given budget
• companies depending on Linux/GTK need to jump in
• additional issue: reviewing
• work currently mostly done by Alexander, but has less time to do it
• other committers also need to review/merge, even if they are no highly experienced SWT/GTK developers --> better than not doing any progress
• proposal: more focus in testing that reviewing, can also be done by non-committers
• a "how to test" section should be provided in according PRs
• testing on Windows via WSL is not sufficient, but might be better than nothing
• proper labels for those PRs indicating that tests are wanted (and may also be done by rather unexperienced contributors) could be useful

So currently this is all community driven... any help is appreciated especially as I don't see these warnings on my system and can only "guess" about ways to disable them temporary.