Bug 22771 - Backport candidate: Godot 3.0.6 (godot3)
Summary: Backport candidate: Godot 3.0.6 (godot3)
Alias: None
Product: Mageia
Classification: Unclassified
Component: Backports (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: MGA6-64-OK
Keywords: Backport, has_procedure, validated_backport
Depends on:
Reported: 2018-03-14 11:57 CET by Rémi Verschelde
Modified: 2018-08-31 22:04 CEST (History)
4 users (show)

See Also:
Source RPM: godot3-3.0.6-1.mga6
Status comment:

Godot project - Space shooter for workshops (298.71 KB, application/zip)
2018-07-17 02:19 CEST, Rémi Verschelde

Description Rémi Verschelde 2018-03-14 11:57:54 CET
As upstream maintainer of Godot Engine, I'd like to ship the new version 3.0.x as a backport to Mageia 6.

I'm not proposing it as an update as it's incompatible with projects made in Godot 2.x, and we currently ship 2.1.3 in Core Release (I will soon push 2.1.5 as an update candidate, once it's released).

RPMs in core/backports_testing:


SRPM in core/backports_testing:

Comment 1 Rémi Verschelde 2018-03-14 12:36:22 CET
Actually since Godot 3.x is not compatible with Godot 2.x games, and we ship some in Mageia 6 with an unversioned dependency on godot-runner, I've decided to rename to backport to "godot3" to prevent conflicts:

RPMs in core/backports_testing:


SRPM in core/backports_testing:


TO SYSADMINS: the packages in comment 0 should NOT be validated, they should be removed from backports_testing.
Comment 2 Herman Viaene 2018-03-15 11:59:14 CET
MGA6-32 on Dell Latitude D600 Mate
No installation issues
Launching godot3 from CLI gives:
Error: Could not obtain OpenGL3.3 context.
I will investigate this later on.

CC: (none) => herman.viaene

Comment 3 Herman Viaene 2018-03-18 10:45:19 CET
Hm, while on my desktop I get:
$ glxinfo | grep "OpenGL version"
OpenGL version string: 3.3.0 NVIDIA 340.106
on the old laptop with ATI graphics I get as OpenGL version 1.3.
Looks like this program does not work anymore on older HW ????
Comment 4 Lewis Smith 2018-04-09 20:42:12 CEST
M6/64 real hardware

After invoking Core Backports Testing for installation, doing:
 # urpmi.update --no-ignore "Core Backports Testing"
 # urpmi godot3
gave "No packet named godot3". What more should I do to get these packages?
With AMD/ATI/Radeon HD7310 graphics:
 $ glxinfo | grep "OpenGL version"
 OpenGL version string: 3.0 Mesa 17.3.6
so I do not know why Herman has 3.3 and me 3.0 !
Can you please give a clue about what the 3 pkgs do, what you need to test this? Does Godot3 work alone, or does it need the other two?

CC: (none) => lewyssmith

Comment 5 Len Lawrence 2018-04-09 21:39:50 CEST
Lewis, I think you need all three.  As far as I can tell godot can be invoked from the commandline without starting the other two.  That must all be done behind the scenes.  

Looking at distrib coffee updates-testing, the packages all have godot 2.1.4-1 versions - no sign of godot3.  The renaming must have slipped through the cracks.

CC: (none) => tarazed25

Comment 6 Len Lawrence 2018-04-09 22:01:38 CEST
This is what the godot site says:
The game engine you waited for.

Godot provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.

Godot is completely free and open source under the very permissive MIT license. No strings attached, no royalties, nothing. Your game is yours, down to the last line of engine code.

I backed out at that point.

godot-demos is installed at the same time.  You find it at /usr/share/godot/demos.
$ ls demos
2d/  3d/  gui/  LICENSE.md  misc/  plugins/  README.md  viewport/
Comment 7 Lewis Smith 2018-04-10 09:48:23 CEST
Thanks Len for all your advice. And a useful clue.
 # urpmi --searchmedia 'core backports testing' godot3
Dim pecyn o'r enw godot3   [No package of this name]
 # urpmi --searchmedia 'core backports testing' godot
Dim pecyn o'r enw godot    [No package of this name]

BUT, contrary to comment 1:
 # urpmi --searchmedia 'core updates testing' --test godot3
Dim pecyn o'r enw godot3   [No package of this name]
 # urpmi --searchmedia 'core updates testing' --test godot
I fodloni dibyniaethau, gosodir y pecynnau canlynol:
(prawf yn unig, ni fydd yn cael ei osod)
  Pecyn                          Fersiwn      Rhifyn        Arch    
(cyfrwng "Core Updates Testing")
  godot                          2.1.4        1.mga6        x86_64  
  godot-demos                    2.1.4        1.mga6        noarch  (argymhellir)
Defnyddir 53MB o le ychwanegol ar y disg.
Estynnir 25MB o becynnau.
Parhau i osod 2 becyn? (Y/n) n

1) The packages are in Core Updates Testing, not Core Backports Testing.
 Where should they be?
2) They are still called godot* and not godot3* .
 Asking for feedback on these things.

Keywords: (none) => feedback

Comment 8 Len Lawrence 2018-04-25 22:54:48 CEST
This is all a bit strange.  When backports testing is enabled, after urpmi.update -a and MageiaUpdate, all that is presented is three godot packages and godot launches OK.

# urpmi godot3-3.0.2-1.mga6
pulls in godot3 from backports testing and the same for the other two packages and godot3 launches OK as well.
It looks like the godot* packages were lodged in backports testing and then another set added with the name changed.  Possibly the godot* packages were copied from updates testing but not deleted afterwards.

Running the checks as in comment 7 confirms what Lewis says.
# urpmi --searchmedia 'core updates testing' --test godot3
No package named godot3
# urpmi --searchmedia 'core updates testing' --test godot
A requested package cannot be installed:
godot-2.1.4-1.mga6.x86_64 (in order to keep godot-3.0.2-1.mga6.x86_64)
Continue installation anyway? (Y/n) n
# urpmi --searchmedia 'core backports testing' --test godot3
Package godot3-3.0.2-1.mga6.x86_64 is already installed
# urpmi --searchmedia 'core backports testing' --test godot
Package godot-3.0.2-1.mga6.x86_64 is already installed

My feeling is that we should go along with the godot3* from backports testing and get sysadmins to remove the godot* packages from both repositories.

godot-demos is available.
The other strange thing is that Herman was able to install godot3 on i586 - he does not mention any problems.  We might need advice from Rémi about older 32-bit hardware though in view of the OpenGL problem.
Comment 9 Len Lawrence 2018-04-26 00:41:45 CEST
This may be more complicated than I thought so we may need Rémi's feedback.

Trying to make sense of what is said in the Description:
godot-2.1.3 in core release
godot-2.1.4 in updates testing
Intention of supplying godot-2.1.5 for updates testing

This implies that godot* should be kept

godot* from backports testing should probably be dumped and godot3 backports testing kept.

$ rpm -qa | grep godot-demos
Could that be a problem for testing godot3?

More checks:
$ ll godot*
-rwxr-xr-x 1 root root 43288464 Mar  4 13:53 godot*
-rwxr-xr-x 1 root root 43268440 Mar 14 11:32 godot3*
-rwxr-xr-x 1 root root 23888680 Mar 14 11:32 godot3-runner*
-rwxr-xr-x 1 root root 42180072 Mar 14 11:32 godot3-server*
-rwxr-xr-x 1 root root 23897856 Mar  4 13:53 godot-runner*
-rwxr-xr-x 1 root root 42199888 Mar  4 13:53 godot-server*
$ rpm -q godot
$ rpm -q godot3
Comment 10 Len Lawrence 2018-04-26 20:39:05 CEST
Running godot3 it was possible to access the 2.1.4 demos so there is no incompatibility.
Comment 11 Len Lawrence 2018-04-26 22:08:15 CEST
The file command shows that that godot 3.x and godot3 3.x are different builds but since Rémi intends to release godot3.x as godot3 we should test just that and ignore godot in backports testing.

@Lewis, addressing point 1)
We still have to carry godot 2.x because godot3 is not backwards compatible with projects made in godot 2.x (according to Rémi).
There does not seem to be a bug posted for godot 2.1.4 so we should leave that alone for the time being.

Regarding comment 10 - had my wires crossed there.  From the initial gui window it was possible to *download* the project demos and select any one.  Not competent to take that any further but everything looks solid.

Which just leaves the OpenGL problem that Herman experienced - comment 3.
Comment 12 Rémi Verschelde 2018-05-13 18:59:00 CEST
Answering some of the above questions, sorry for the delay.

@Herman: Godot 3.0.x requires OpenGL 3.3, so it's normal that it won't run on your older machine. Godot 2.1.x (in Core Release) requires OpenGL 2.1, so it wouldn't run there either a priori.

>  # urpmi.update --no-ignore "Core Backports Testing"
>  # urpmi godot3

That works for me, make sure to actually update the "Core Backports Testing" repo (e.g. with `urpmi.update ""` to update all repos, whether enabled or not).

Most of the confusion about the godot/godot3 packages and where they are located seems to come from the fact that you had not downloaded any repo data for "Core Backports Testing".

Only "godot3*-3.0.2-1.mga6" packages should be considered in this backport candidate.
The "godot-3.0.2-1.mga6" packages in backports testing should not be used/validated, and I will get sysadmins to remove them eventually.
The "godot-2.1.4-1.mga6" packages in core/updates_testing are for a separate *update* (not backport) to the existing "godot-2.1.3-1.mga6" package in Core Release.

> With AMD/ATI/Radeon HD7310 graphics:
> $ glxinfo | grep "OpenGL version"
> OpenGL version string: 3.0 Mesa 17.3.6
> so I do not know why Herman has 3.3 and me 3.0 !

The OpenGL version supported depends on your GPU and the drivers installed. This result means that the Mesa drivers in version 17.3.6 only provide OpenGL 3.0 support for the HD 7310, so it won't be able to run Godot 3.

> Can you please give a clue about what the 3 pkgs do, what you need to test
> this? Does Godot3 work alone, or does it need the other two?

The "godot3" package contains the Godot game engine with its editor (binary "godot3"). It's the only package you need to test.

The "godot3-runner" is necessary to package Godot 3 FOSS games in Mageia, but currently there are none included (there are a couple Godot 2 games using "godot-runner" though, "minilens" and "tanks-of-freedom").

The "godot3-server" binary is for people who want to host a server for their Godot game. It doesn't need to be particularly tested.

> $ rpm -qa | grep godot-demos
> godot-demos-2.1.4-1.mga6
> Could that be a problem for testing godot3?

No, those demos are not compatible with Godot 3, but having them installed doesn't hurt. They are only useful with godot (2), and don't need to be installed/tested as part of this backport candidate.

> We still have to carry godot 2.x because godot3 is not backwards compatible
> with projects made in godot 2.x (according to Rémi).
> There does not seem to be a bug posted for godot 2.1.4 so we should leave that
> alone for the time being.

Correct, the update candidate for godot 2.1.4 should be ignored for now, I'm waiting for godot 2.1.5 to push this. (So Mageia 6 will have godot 2.1.3 in Core Release, godot 2.1.5 in Core Updates and godot3 3.0.2 in Core Backports).

> Which just leaves the OpenGL problem that Herman experienced - comment 3.

Godot should print a message explaining that the supported OpenGL version is too low to run Godot, so that's a matter of not fulfilling the minimal hardware or software requirements. It's nothing that we can improve in Mageia, it just means that Godot can only run on mid to high end hardware (understandably, since it's meant to develop resource heavy video games).

Note that after showing this error, Godot should *crash*. That's currently the expected behaviour upstream, so it shouldn't prevent pushing this backport candidate. It will be improved eventually to close down gracefully, but it's not a bug per se.

Hope this helps and sorry for the confusion :)
Comment 13 Rémi Verschelde 2018-05-13 18:59:47 CEST
I'll take this one back for now as Godot 3.0.3 might not be too far from being released. I'll get sysadmins to clean up the old backport and update candidates in the meantime for clarity.

Keywords: feedback => (none)
Assignee: qa-bugs => rverschelde

Comment 14 Rémi Verschelde 2018-07-17 02:01:38 CEST
I've updated the backport candidate to 3.0.5. Note that only the `godot3*` packages in *Core Backports Testing* should be tested.

RPMs in core/backports_testing:


SRPM in core/backports_testing:


Source RPM: godot-3.0.2-1.mga6 => godot3-3.0.5-1.mga6
Summary: Backport candidate: Godot 3.0.2 => Backport candidate: Godot 3.0.5

Comment 15 Rémi Verschelde 2018-07-17 02:19:56 CEST
Created attachment 10283 [details]
Godot project - Space shooter for workshops

Tested successfully on Mageia 6 x86_64, installed with `urpmi --searchmedia backports godot3{,-runner,-server}`.

I used the attached zipped project folder to test it. After unzipping it, run `godot3` and import the unzipped folder into Godot. You can then edit it and run it.
Alternatively, run `godot3 -e` directly in the unzipped folder.

Once the project was ran once with the editor and the resources are imported, the game can be run with `godot3` directly in the project folder (via the editor), or with the optimized `godot3-runner` binary. No need to bother testing the `godot3-server` binary too much.
Rémi Verschelde 2018-07-17 02:20:19 CEST

Keywords: (none) => Backport, has_procedure
Whiteboard: (none) => MGA6-64-OK

Comment 16 Rémi Verschelde 2018-08-11 13:10:37 CEST
I updated the backport candidate to version 3.0.6 which fixes a security vulnerability (same as Godot 2.1.5 update in bug 23361).

It should now be ready for new tests and validation.

Assignee: rverschelde => qa-bugs
Source RPM: godot3-3.0.5-1.mga6 => godot3-3.0.6-1.mga6
Summary: Backport candidate: Godot 3.0.5 => Backport candidate: Godot 3.0.6 (godot3)
Whiteboard: MGA6-64-OK => (none)

Comment 17 Len Lawrence 2018-08-15 18:52:45 CEST
Installed godot3 3.0.6-1 from Backports Testing and downloaded godot-shooter-workshop.zip.

Unzipped the shooter file and moved to the project directory.  Invoked the editor.
$ godot3 -e
Resources were imported.  Tried to install some of the games but do not know where they went.
Added some meteoroids of various sizes to the playing field then exported the project and exited.

$ godot3 --help
Provided lots of information.

$ godot3 -p
Opened the project manager.  Looked at some of the demos and installed them.

$ godot3
Up came the new version but I did not know how to run it.  Move left with A, space for shoot but the missiles went through their targets.

$ godot3-runner
That also launched the space-shooter.

$ godot3-server
ERROR: initialize: AudioDriverManager: all drivers failed, falling back to dummy driver
   At: servers/audio_server.cpp:16

$ godot3-runner "2D Kinematic Collision Demo"
OpenGL ES 3.0 Renderer: GeForce GTX 970/PCIe/SSE2
ERROR: _load: Method/Function Failed, returning: RES()
   At: core/io/resource_loader.cpp:186.
ERROR: start: Condition ' !scene ' is true. returned: false
   At: main/main.cpp:1688.
WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:1989.
ERROR: clear: Resources Still in use at Exit!
   At: core/resource.cpp:418.
Segmentation fault (core dumped)

Had a look around but could not figure out where the demos were installed.
Ahh.  Just looked back at the previous comments and see that these demos are not meant to be used with godot3 anyway.
Comment 18 Rémi Verschelde 2018-08-16 01:27:33 CEST
The "ERROR" for the server binary is normal, albeit a bit weird.

The errors on `godot3-runner "2D Kinematic Collision Demo"` are also expected as it's an invalid command, but the segmentation fault isn't. I could reproduce it locally, including with the development version of Godot, so I opened this issue: https://github.com/godotengine/godot/issues/21060

It's a minor issue though so I wouldn't have it block this update. I'll include a fix once available in a future update.
Comment 19 Len Lawrence 2018-08-16 08:22:04 CEST
With your blessing then Rémi giving this the OK for 64-bits.

Whiteboard: (none) => MGA6-64-OK

Comment 20 Rémi Verschelde 2018-08-22 12:35:08 CEST

Keywords: (none) => validated_backport

Comment 21 Thomas Backlund 2018-08-31 22:04:41 CEST

Resolution: (none) => FIXED
CC: (none) => tmb

Note You need to log in before you can comment on or make changes to this bug.