There is a new upstream version 4.2.2-stable available. Please update godot in Debian to the newest upstream version.
Hello Games Team, I have been slowly working towards packaging Godot 4.3 now that the stable release is out. I'm relatively new to Debian packaging and this is a major version bump so I'm hoping you all could guide me towards something worth uploading :) I created an MR [0] in Salsa with the current draft of my packaging efforts. Currently, it builds successfully on my x86_64 machine but there are still some failing unit tests to investigate. I'm also hoping to get the documentation packaged for offline use as well, but it is in a separate repository that doesn't have tagged releases. Things off the top of my head that need wider discussion: 1. Does it make sense to rename the Salsa repo from godot3 to just godot? 2. Does the Salsa repo belong better under the Games Team or where it currently is (plain debian/). 3. Should a separate 3.x package continue to be maintained? Looking forward to hearing people's thoughts, especially current users of Godot in Debian. Cheers, Travis [0] https://salsa.debian.org/debian/godot3/-/merge_requests/3
Hi, We can have both godot3 and godot4 for Trixie, under Games Teams, that would be the best ! (then maybe drop Godot3 after release) Le lun. 16 sept. 2024 à 07:00, Travis Wrightsman <travis@wrightsman.org> a écrit :
So technically this would mean an new src:godot4 that will generate a new gogod4 binary package. Le mar. 10 déc. 2024 à 08:26, Alexandre Detiste <alexandre.detiste@gmail.com> a écrit :
It would confuse the BTS and might make more work for FTP-masters. The good thing is that end users don't need to care about the src: name. Le mar. 10 déc. 2024, 18:24, Travis Wrightsman <travis@wrightsman.org> a écrit :
I'm curious why a src:godot4 rather than keeping src:godot at 4.x and introducing a new src:godot3? To me it makes more sense to have src:godot track the latest stable version.
Hi, Sorry for cross-posting to both bug, package maintainer mailing list and team mailing list, but I just wanted to ensure that previous maintainers are aware that Travis adopted this package in September, and as I stepped up to mentor him recently, we are now at the point that a new Godot version will be uploaded in coming days. Please speak up if you strongly object to this. Otherwise, I will proceed with upload. You can see a diff of how the files and `debian/control` changed after some excellent work from Travis to use more dependencies from Debian instead of the bundled ones: https://salsa.debian.org/games-team/godot3/-/merge_requests/10#note_560215 The above link is the main MR for the 3.6 import. Full commit list of course at https://salsa.debian.org/games-team/godot3/-/commits/debian/latest Note also that we fixed the Salsa CI, so it both runs the whole pipeline, and jobs pass and are green. If you have feedback/suggestions of changes before upload, you can either share feedback here or submit a Merge Request for exact change requests. We will also later work on Godot 4.3, and the goal is to have both 3.6 and 4.3 (or 4.4 if it comes out in time) exist in Debian repositories in parallel at least in of Trixie. Details of our plan for that will follow later. This email was sent for the purpose of heads-up of imminent upload. - Otto PS. While doing this packaging we leveraged as much as possible of all state-of-the-art tooling in Debian, such as git-buildpackage dual tarball and git tag import, DEP-14 branches, Salsa CI, code reviews, proper git commits etc. I skimmed through the games team docs at https://wiki.debian.org/Games/VCS, https://wiki.debian.org/Games/Development/BuildProcess, https://wiki.debian.org/Games/ToolsDiscuss but intentionally decided to not follow those guidelines as they seem outdated (describing mostly alioth and svn stuff from 10 years ago).
Hi, Note that if you want to try this new Godot 3.6 for Debian version, you can download the binaries from the build job artifacts at https://salsa.debian.org/games-team/godot3/-/jobs/6758691/artifacts/browse/debian/output/ I also did a test build and multiple architectures at https://launchpad.net/~otto/+archive/ubuntu/ppa/+builds?build_text=&build_state=all, which also allows the built binaries to be downloaded and run locally if anyone wants to test.
It is somewhat unusual for multiple versions of an app to be available in a single Debian release. Why do you want to do it in this case? If you do think it's necessary, I consider it best practice to package the newer version with the unversioned package name. In other words, latest godot is godot. And then you would have a godot3 package for people needing the older version. Thank you, Jeremy Bícha
Le Fri, 20 Dec 2024 09:54:27 -0500, Jeremy Bícha <jeremy.bicha@canonical.com> a écrit : available) using the Debian-provided Godot 3 runtime instead of the binaries vendored by the game distributor. Unless the Godot 4 runtime is backwards-compatible with games built with Godot 3, I would like at least the runner (maybe not the development tools) to be kept in Debian repositories.
Thanks for sharing your view. This is indeed our plan at the moment. We are still polishing godot (3) and will finalize the plan on godot3/godot/godot4 probably next week, and happy to hear if anyone else has input about the pros and cons of the various options here.
The Godot game engine is an unusual case at the moment for a few reasons: 1) Godot 4.x has dropped support for GLES2 and therefore lots of (slightly) older hardware that is still targetable in 3.x. 2) The 4.x engine can't run 3.x games directly. It must do a one-time migration on the codebase which is not guaranteed to work. 3) It took a while for 4.x to become a trustable base for developers to start new games on. So while 4.x is over a year old, my understanding is that the 3.x engine is still used for new games today (particularly for reason #1). 4) 3.x is still actively maintained and even receives new and backported features from 4.x. Upstream describes Godot 3.x as "a mature and stable codebase, which is well suited to development for low-end hardware" [0]. The language they use heavily implies 3.x is almost a different product from 4.x. Of course, these reasons may not be convincing enough for the wider Games Team / Debian project to co-support 3.x and 4.x. I hope many others can chime in with their thoughts and needs. At least a few Games Team members have expressed [1,2,3] a desire to have both versions in Debian for one or more of the reasons above. We also don't have to maintain 3.x forever. Perhaps Godot 4.x adds GLES2 support or there is no longer a desire for 3.x by the end of trixie and the package is dropped from testing. Regarding naming, I have no strong opinion on whether Godot 4.x is named godot or godot4. Godot 3.x is and will certainly stay godot3. [0] https://godotengine.org/article/godot-3-6-finally-released/ [1] https://lists.debian.org/debian-devel-games/2024/12/msg00002.html [2] https://salsa.debian.org/games-team/godot3/-/merge_requests/3#note_558965 [3] Discussions in #debian-games
Hi, I just wanted to let you know that we have been working on a couple of fixes for Godot 3 at https://salsa.debian.org/games-team/godot3 and I plan to upload 3.6+ds-2 within a couple of days. Once 3.6+ds-2 is uploaded, I will branch it to godot3/debian/latest and change the source package name to godot3 in preparation for having Godot 3.6 and 4.3 in Trixie in parallel. The work for Godot 4.3 will continue on branch debian/latest and using the source package name godot. The binary packages will be versioned following the current pattern. The branch debian/latest will have the watch file updated to always look at the most recent version possible (4.x) while the godot3/debian/latest watch file will continue to look at latest in 3.x series. We might of course still tweak some plans in discussion with Travis, or discover something while implementing this, but overall things look good, and there are no known blockers or need for help. This email is mostly to share information with those vested earlier in the package. The main reason things are smooth is 1) we got Salsa CI working and passing for this package, which quickly helped find and validate fixes for all remainin issues and 2) Travis already made a mock import and things are looking great for Godot 4.3 I also wanted to voice that Travis is doing an excellent work, paying attention to all the details at play in Debian packaging. I hope he will continue doing more in Debian! If you want to participate in packaging, feel free to check out the package status and file Merge Requests with whatever improvements you wish to see in Godot. - Otto
Hi there! No updates since then and still Godot packages (apart from godot3) in Debian unstable. So... I guess we won't have Godot 4 in Trixie after all, right? Thanks for your work! E
Hi Emilio, godot3 and godot (4.x) have been in NEW for a few months. They are large packages and so may take a while to be reviewed. Unfortunately we are in soft freeze for trixie, meaning that even if Godot 4.x passes NEW now it will not be allowed to migrate into trixie. Best, Travis
Hi, Quick update to this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070845 The Godot 4 package was in the Debian NEW queue (https://ftp-master.debian.org/new.html) since January and finally got reviewed by FTP Masters for the first time yesterday. Unfortunately they had some feedback about the debian/copyright file, and the upload was rejected. We will be doing a new upload but since it is now end of April and Trixie freeze is on, there the new version has no chance of being included in Trixie. Trixie will ship with only Godot 3.6, but luckily it is at least the latest in the 3.6 series.
I've been quite busy at work since FTP masters reviewed Godot 4.3 but am slowly starting to have more time to circle back to this. I imported 4.4.1 to my local repo and am happy to report that it builds all three configurations (editor + templates) without error and without modifications to the 4.3 packaging. Unfortunately there are a couple of unit tests now failing for the editor and I will have to debug these, likely asking for help upstream. Then I'd like to take another shot at reducing the vendored libraries since FTP masters requested clarification on which third party code is being used. I think the easiest way to address that is just dropping unused third party code from the copyright and therefore the Debian orig.tar.gz.