Contributing your ebuild to Gentoo main repo?

[dr-diem]

Hi,

I see you maintain Gentoo ebuilds in this repo. I recently installed DXX-Rebirth using the ebuild in Gentoo's main repo and found it to be very out of date (0.59.100) - do you mind if I clone your repo so as to track your ebuilds and issue pull requests to the main Gentoo repo? It seems a good idea to keep the core Gentoo repo up to date.

Cheers,

Ian

[vLKp]

The ebuilds are under GPL v2, and any use compliant with that license does not need further permission (though I do appreciate being asked, and apprised that someone is working on this). I'd find it a bit surprising if what you need to do managed to fall even close to a grey area of the GPL. ;) I hope that the ebuilds are suitable for submission without further change. If they aren't, please point me to the rejection messages, so that I can address concerns with them.

The ebuilds have fallen behind a bit, so before you submit the snapshot ebuilds (the ones that are not -9999), they should be updated to point to a more recent commit. This is probably just a matter of changing the git commit to which they refer. You're welcome to try to make that change, or I can make it in my next round of updates.

If you run into any issues getting the ebuilds to work, please report that to this issue tracker, too. My goal is that, like the source itself, you should be able to get it all working just by following the published instructions. If you can't, then the instructions need work.

[dr-diem]

Thanks!

I'll start with updating the snapshot ebuid to a newer commit (changing the filename appropriately if I step past a release commit) to get a feel for things.

The first major hurdle will be that the current main Gentoo ebuilds reference separate ebuilds for the descent1 and descent2 data, which does feel like a good idea (I leveraged that and that associated USE flags to focus on getting the two executables working individually). If you are in agreement, I will see if I can merge that approach into your (otherwise superior IMO!) ebuild and clone the sub-ebuilds here.

Unrelated, but indeed the installaltion instructions here still make reference to a bug in a point release of gcc 4 - suggest removing that entirely?

[vLKp]

The first major hurdle will be that the current main Gentoo ebuilds reference separate ebuilds for the descent1 and descent2 data

Are you referring to this in the Gentoo ebuild?

https://github.com/gentoo/gentoo/blob/4d96b15775c4144cec3224c8913fac01bf6bd003/games-action/dxx-rebirth/dxx-rebirth-0.59.100.ebuild#L41-L44

If so, that appears to match:

dxx-rebirth/contrib/gentoo/games-action/dxx-rebirth/dxx-rebirth-9999.ebuild

Lines 86 to 91 in d197ba4

	DXX_RDEPEND_ENGINE_FRAGMENT='
	d${ENGINE}x? (
	!<games-action/d${ENGINE}x-rebirth-0.59.100
	|| (
	games-action/descent${ENGINE}-data
	games-action/descent${ENGINE}-demodata

The only difference I see is that Gentoo has a USE flag data that can be disabled to completely eliminate the dependency on game data, whereas mine will always require you to install some sort of data package for the games you build. This could be seen as a nuisance if the user wants to manage their game data outside the package manager. I originally considered it a feature since the games are useless without some sort of data, and people who want to try them out can get the freely redistributable shareware data to satisfy the dependency.

Unrelated, but indeed the installaltion instructions here still make reference to a bug in a point release of gcc 4 - suggest removing that entirely?

The note was added because a then-supported version of Debian was shipping the bad version of gcc, and someone was impacted by the bug. Once there are no supported major distributions shipping impacted compiler versions, removing the note would be appropriate. In the case of Debian, that would mean that they have pushed a fixed version in every release of Debian that still receives updates and that every release of Debian which will not receive the update has been declared end-of-life upstream, so that people using it are aware that they are unsupported. Until then, I would prefer to leave it in.

[dr-diem]

Ah yes, you're right. That's good news then, things will be simpler since I won't need to re-implement the dependency on separate game data ebuilds. I agree with you about the data USE flag. If it is easy enough to re-implement it in your ebuild I'll do so, but if it proves incompatible I won't sweat it too much if it is lost. I've a feeling I might be the first person in 4 years to install from the Gentoo ebuild; it only works with gcc 6.5.0 (which I discovered by emerging old versions by trial and error!) whilst the current default is 9.2.0.

Understood regarding the install note about gcc 4; perhaps it is worth adding a reference explaining why it is retained? In my no-prior-experience reading of the installation instructions I took it as a signifier that the instructions hadn't been updated since gcc 4 was the current release ;o)

[vLKp]

According to git blame, I only added the explicit note about gcc-4.9.2 at the end of 2019. As I read the Debian releases page:

• Debian Jessie ships with gcc-4.9, reached its first end-of-life 2018-06-17, and will reach its LTS end-of-life around 2020-06-03. Even now, it is considered the "oldoldstable" distribution.
• Debian Stretch ships with gcc-6.3, will reach its first end-of-life sometime this year, and will reach its LTS end-of-life sometime in 2022. It is currently considered the "oldstable" distribution.
• Debian Buster ships with gcc-7 and gcc-8, will reach end-of-life sometime in 2022, and has no LTS end-of-life date reported. It is currently considered the "stable" distribution.

From that, it's probably safe to drop the note any time. Although Debian Jessie is not entirely out of support, and thus does not quite match the criterion I described above, it is close to end-of-life. More importantly, it seems unlikely at this point that anyone would try to package a tip-of-tree Rebirth for Jessie with the end-of-life so close, since Jessie is only receiving major security updates. Even if they did, the referenced bug may or may not be an issue. It is a wrong-code bug, which is unfortunate, but I eliminated all known triggers of it. If it were an obvious build break, renouncing the broken compiler versions would be much easier.

[vLKp]

• Raised the minimum version of gcc to gcc-7. This is the oldest gcc still considered supported by the gcc developers.
• Removed the note about gcc-4.9.2. Updated various documentation to remove mention of <gcc-7.
• Added USE=data support to the Gentoo ebuild.
• Resynchronized the snapshot ebuild with the live ebuild, which gives the snapshot ebuild support for USE=valgrind.
• Updated the snapshot ebuild to the latest snapshot, and removed older snapshot ebuilds.

I expect those last few changes should make it easier to get the ebuilds added to the Gentoo tree.

[dr-diem]

Thank you - these changes make my life a ton easier!

I will get the Gentoo ebuild updated this week and also add the live one. From there on in I will follow them and update them across as you make releases. I'll follow up here once I've place the pull requests and again when they are accepted.

[chewi]

Hello! Gentoo Games lead here. It may surprise you that this is a game I care about a lot. I poured many hours into Decent back in '95. 😉 I did try to bump the package to v0.60 Beta 2 back when it was fresh but it had some non-trivial issues so I waited for the next release... which never really happened. Distros generally prefer actual releases but if you're just going to be doing these occasional snapshots every so often for the foreseeable future then that's fair enough. Ian, I look forward to seeing your work.

[dr-diem]

Hi James, Thanks for the rapid reply and approval to go ahead! Great to hear you're a fellow OG Descent-er :o) I've found the relevant page for how to submit new ebuilds, so I'll (naturally!) do a local test first then file the Bugzilla bug report. If I find similar non-trivial bugs then I'll look to modifying the existing ebuild to indicate that it has a dependency on gcc-6.5.0-r1 (a hoop I had to jump through to get it installed last month!) Actually, I've also got a question; since I plan to submit both the latest snapshot build and a live build, is it proper form to fill in Bugzilla reports for them individually? Thanks, Ian

…

On Mon, 20 Apr 2020, at 18:21, James Le Cuirot wrote: Hello! Gentoo Games lead here. It may surprise you that this is a game I care about a lot. I poured many hours into Decent back in '95. 😉 I did try to bump the package to v0.60 Beta 2 back when it was fresh but it had some non-trivial issues so I waited for the next release... which never really happened. Distros generally prefer actual releases but if you're just going to be doing these occasional snapshots every so often for the foreseeable future then that's fair enough. Ian, I look forward to seeing your work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#502 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVPRODVHAFNMNI45EWL6PLRNTDIFANCNFSM4MGB2XXQ>.

[vLKp]

chewi wrote:

I did try to bump the package to v0.60 Beta 2 back when it was fresh but it had some non-trivial issues

If you run into packaging problems again, please feel free to open an issue here about it. I'd like to see all the major Linux distributions able to package and distribute Rebirth with a minimum of downstream patching required. Patching to make it conform better to distribution policies (preferred filenames and paths, preferred compile options, etc.) is fine if the distribution wants to make changes, but all the basic functionality should work from a fresh checkout without requiring the distribution to patch anything.

which never really happened.

Sorry about that. I've never been interested in dealing with the release process, because to me a major part of the release process was offering up prebuilt binaries for Windows users, for Mac users, and possibly for some of the Linux distributions that prefer to ship binaries. I left that to the other contributors, but they haven't had much time to mess with it in years, so it ended up just not happening.

but if you're just going to be doing these occasional snapshots every so often for the foreseeable future then that's fair enough.

At this point, I think I am the only person working on Rebirth upstream with any regularity at all. I can't do Mac builds, and I don't particularly want to deal with providing prebuilt binaries for any of the supported platforms. If tagging particular commits as releases would be helpful to the Linux distributions, that's easy and I am fine doing that and trying to offer some level of support for the tagged points.

dr-diem wrote:

If I find similar non-trivial bugs then I'll look to modifying the existing ebuild to indicate that it has a dependency on gcc-6.5.0-r1

I'd prefer that you just ask me to change the code to fix those problems instead of pinning the build on an old compiler, especially since you just talked me into declaring gcc-7 the new minimum. 😉

[dr-diem]

Thanks for the details chewi, and do you know what? As soon as I wrote about modifying the existing ebuild I thought to myself "That's lame - better to tackle the issues!" :)

…

On Mon, 20 Apr 2020, at 23:34, vLKp wrote: chewi wrote: > I did try to bump the package to v0.60 Beta 2 back when it was fresh but it had some non-trivial issues If you run into packaging problems again, please feel free to open an issue here about it. I'd like to see all the major Linux distributions able to package and distribute Rebirth with a minimum of downstream patching required. Patching to make it conform better to distribution policies (preferred filenames and paths, preferred compile options, etc.) is fine if the distribution wants to make changes, but all the basic functionality should work from a fresh checkout without requiring the distribution to patch anything. > which never really happened. Sorry about that. I've never been interested in dealing with the release process, because to me a major part of the release process was offering up prebuilt binaries for Windows users, for Mac users, and possibly for some of the Linux distributions that prefer to ship binaries. I left that to the other contributors, but they haven't had much time to mess with it in years, so it ended up just not happening. > but if you're just going to be doing these occasional snapshots every so often for the foreseeable future then that's fair enough. At this point, I think I am the only person working on Rebirth upstream with any regularity at all. I can't do Mac builds, and I don't particularly want to deal with providing prebuilt binaries for any of the supported platforms. If tagging particular commits as releases would be helpful to the Linux distributions, that's easy and I am fine doing that and trying to offer some level of support for the tagged points. dr-diem wrote: > If I find similar non-trivial bugs then I'll look to modifying the existing ebuild to indicate that it has a dependency on gcc-6.5.0-r1 I'd prefer that you just ask me to change the code to fix those problems instead of pinning the build on an old compiler, especially since you just talked me into declaring gcc-7 the new minimum. 😉 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#502 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVPROHU5VUIVLH7BXUCDE3RNUH4JANCNFSM4MGB2XXQ>.

[dr-diem]

Ok, I learnt how to set up a local (Gentoo) repository, cloned your ebuilds there, and have built and run them both with no issues at all using gcc 9.3.0. FWIW my testing has been limited to 'does my last savegame load and can I move, shoot and destroy a robot'; let me know if you have a standard test suite I should go through. The only change I made was to set the KEYWORDS values to ~ in the live (9999) ebuild to mark it as 'testing'; I'll raise a pull request if you like though hardly necessary for adding two ~ chars :o)

Next step is to submit them to Gentoo's master repo and let the gears turn..

[chewi]

Sorry if you were waiting on me for anything. I get a constant stream of new bug reports and requests on a daily basis and it's impossible to keep up. I try my best to value contributors such as yourself though. Ultimately we need more official developers who can take responsibility for their commits without having to go through someone else first, even if it's just for a package or two. Unfortunately the bar for entry is a bit high.

[dr-diem]

chewi wrote:

Sorry if you were waiting on me for anything. I get a constant stream of new bug reports and requests on a daily basis and it's impossible to keep up.

No not at all! I was just being distracted by other projects ;o)

I try my best to value contributors such as yourself though. Ultimately we need more official developers who can take responsibility for their commits without having to go through someone else first, even if it's just for a package or two. Unfortunately the bar for entry is a bit high.

Thanks, and by return I'll try not to add to your burden! Just one question - is this git procedure the correct way forward? That's to say, no need to use the Bugzilla process to notify Gentoo (you?!) of my request to commit new ebuilds?

[vLKp]

let me know if you have a standard test suite I should go through

I do not have a formal play test suite. I have slowly added some unit tests for various pieces, but they cover only a tiny portion of the total code.

The only change I made was to set the KEYWORDS values to ~ in the live (9999) ebuild to mark it as 'testing'; I'll raise a pull request if you like though hardly necessary for adding two ~ chars :o)

I thought that the Gentoo convention for live ebuilds was that they have no KEYWORDS, not even ~arch, because a live ebuild tracks upstream, so the Gentoo maintainers cannot promise any particular level of quality. If I'm wrong on this and the ebuild should carry keywords, I'm happy to change it.

https://devmanual.gentoo.org/keywording/index.html says:

Note: Usually, "live" ebuilds (see Version Control System (VCS) Sources) do not specify a KEYWORDS variable, or assign the empty string to it.

I think that the preferred way for you to test it would be to use package.accept_keywords to accept the special keyword ** for the package, which overrides the keyword check and allows you to emerge it despite the lack of keywords.

[dr-diem]

Yes, you're right, thanks for pointing that out. I had since added the PROPERTIES+=" live" so I'll now remove the KEYWORDS line entirely.

[vLKp]

Good idea. I added PROPERTIES=live to the -9999 ebuild in the Rebirth tree, to reduce drift between what I store and what you submit. I probably should change the KEYWORDS line too, but have not done that yet. I'll wait and see how your submission goes, and review what gets included for other changes to pull back in.

You may also want to look at the RESTRICT=mirror in the Rebirth ebuild. I put that there because otherwise Portage tries to contact Gentoo mirrors to download the source, which doesn't work because Gentoo mirrors don't carry the source since Gentoo isn't carrying this ebuild. There is no licensing reason Gentoo shouldn't mirror the source, and once the source is on the Gentoo mirrors, that RESTRICT line should be removed from the ebuild.

[dr-diem]

Yes, another good point - I'd noticed the RESTRICT and will remove it from both ebuilds before committing.

[dr-diem]

@vLKp could you correct my partial guesses as to what the following USE flags do:

midi - enable support for MIDI synthesizers
editor - enable support for the level editor?
debug - enable debugging output
sdl2 - ?
tracker - ?

[vLKp]

• midi: enforce that SDL-mixer is used and has midi support
• editor: yes
• debug: enable various debugging code paths and sanity checks, not just output. Some of these checks date back to the retail build, and choke on some custom levels because the game was never coded to sufficiently distrust inputs.
• sdl2: use libSDL2, SDL2-mixer instead of libSDL-1* and SDL-mixer-1*
• tracker: enable support for @Mako88's PHP-based multiplayer game tracker.

[dr-diem]

Thanks - pull request now created (gentoo/gentoo#15903) - let's see how it goes.

[dr-diem]

Hmmm - the automated QA checks threw a fair number of errors. I will need to alter the layout of the copyright message, we might need the tagged commit to be a tarball instead of a zip, and I fear that it cannot understand the programmatic way you have specified the dependencies :(

[vLKp]

• PkgBadlyFormedXml: I do not provide a metadata.xml. It looks like you added one.
• InvalidCopyright: I do not know what this wants changed.
• InvalidLicenseHeader: This looks simply broken: invalid license header: '#'
• MissingUnpackerDep: I thought unzip was in @system, but it seems not. However, this may be irrelevant due to the TarballAvailable complaint below.
• NonexistentDeps: RDEPEND: nonexistent packages: games-action/descent1-freedata, games-action/descent2-freedata. These packages exist in my tree. You may need to get them submitted first in order to resolve this. You could choose to drop these from the Gentoo version of the ebuild.
• NonsolvableDepsInDev: This might be fallout from the prior point. If not, I do not know what this wants changed.
• TarballAvailable: I have no objection to using a tarball instead.
• WhitespaceFound: I do not see any trailing whitespace on line 179. There is a trailing whitespace on line 205 to work around a bash syntax highlighting quirk. On reviewing your ebuild, I see you removed various lines, including the project's standard phrasing about copyright. Why did you remove that? Line 205 in the reference ebuild is the issue.

As a general statement, I discourage modifying copyright-related statements without good cause.

I fear that it cannot understand the programmatic way you have specified the dependencies :(

What diagnostic led you to this statement?

[dr-diem]

Thanks for the detailed feedback!

I do apologize about the copyright statement removal. That was a mistake - it is the historical text statement referencing the code merge that I intend to remove. My next commit will restore the project's standard copyright phrasing, and add a reinforciing statement on the first line (to suit the preferred ebuild style and answer the 'Invalid Copyright' warning).

The diagnostic was actually just lack of coffee. I realised later that I hadn't brought in the dependent packages to my local git repo.

If you could switch your latest ebuild to use tar then I can handle the more minor boilerplate items? The metadata.xml I've already corrected locally.

Thanks again for assisting with this!

Ian

[dr-diem]

Okay, things are now in reasonable state. All fatals have been resolved, and the only remaining warnings are complaints that the ebuilds are not Copyright Gentoo Authors (tough!) and missing USE flag metadata for the legacy 0.59 ebuild.

I guess I now wait for the pull request to be merged - @chewi is this on you to progress?

[vLKp]

If you could switch your latest ebuild to use tar then I can handle the more minor boilerplate items?

Done, and snapshot ebuild resynchronized with the -9999 ebuild.

[dr-diem]

Hi @vLKp - does your build now automatically include the 'free' maps, or are they still only available separately (as with the existing 0.59.100 ebuild)? I would like to avoid losing features that the existing gentoo ebuild offers you see.

[dr-diem]

Will do @vLKp . There are some additional comments for the freedata packages on the pull request review here, just in case you think they too should be fed back.

[dr-diem]

Back to working on this today. A couple of questions and comment about your recent changes @vLKp :

• it's not clear to me why you don't have KEYWORDS in your ebuild - surely we need to indicate the supported architectures? I have ~amd64 ~x86; they're set as testing to match the old 0.59 ebuild - I got a CI warning or error if I tried to put them as stable directly.
• since how long has the valgrind keyword been supported? i.e. should I add it to the 20190720 ebuild I am in the process of submitting to Gentoo?
• our favourite the copyright line - given that it is acceptable to have a non-Gentoo copyright, I prefer the older "DXX Rebirth project contributors" since it is clearer than "Rebirth contributors" if someone were to only have the Gentoo ebuild and was trying to work backwards from there to find the original copyright holder. Similarly I favour retaining the detail lines in the freedata packages for similar reasons.

[chewi]

We generally don't mark games as stable any more as we don't find the extra work it generates worthwhile. I would expect ~amd64 and ~x86 to be there initially. I could test arm at some point too. Others may want to test further architectures. I'll leave it to @vLKp to decide whether to reflect that here or indeed have any keywords at all.

[dr-diem]

Thanks @chewi . @vLKp to add to my comments above, I suspect that this recent change:

 DXX_DEPEND_USE_SDL_VERSION_FRAGMENT='
 	media-libs/lib${SDL_version}[joystick?,opengl?,sound,video]
+	media-libs/sdl${SDL_version}-image
 	music? ( media-libs/${SDL_version}-mixer )
 '

is not quite correct. According to repoman, ${SDL_version} expands to "sdl" or "sdl2", so prefixing it with "sdl" results in "sdlsdl2" or "sdlsdl" after brace expansion. I think this is correct:

+ media-libs/${SDL_version}-image

[vLKp]

@dr-diem wrote:

• it's not clear to me why you don't have KEYWORDS in your ebuild

I do:

dxx-rebirth/contrib/gentoo/games-action/dxx-rebirth/dxx-rebirth-9999.ebuild

Line 18 in e25ecbb

KEYWORDS=

dxx-rebirth/contrib/gentoo/games-action/dxx-rebirth/dxx-rebirth-9999.ebuild

Line 33 in e25ecbb

KEYWORDS="~amd64 ~x86"

The branch for the live ebuild has KEYWORDS explicitly blank, as it is my understanding that is desired for live ebuilds. The branch for a snapshot ebuild has KEYWORDS set to ~amd64 ~x86.

• since how long has the valgrind keyword been supported?

According to git blame, I first added support for this in 07176ec, which was posted in September 2014.

---

@chewi wrote:

Others may want to test further architectures. I'll leave it to @vLKp to decide whether to reflect that here or indeed have any keywords at all.

I can easily test amd64 and x86. I accept issue reports from other architectures, but have limited ability to debug issues specific to them. If you or others report how well the game reports on other architectures, I am happy to update KEYWORDS to reflect that.

---

@dr-diem wrote:

I suspect that this recent change:

You are correct. I verified that ebuild would run to completion after the change, but did not run repoman on it. I will correct this.

[dr-diem]

Thanks @vLKp - another small issue. The new postint function causes the following error to be thrown:

>>> Failed to execute postinst for games-action/dxx-rebirth-0.61.0_pre20190720
>>> Jobs: 2 of 2 complete                           Load avg: 1.53, 0.85, 0.82

 * Messages for package games-action/dxx-rebirth-0.61.0_pre20190720:

 * FAILED postinst: 1
 * ERROR: games-action/dxx-rebirth-0.61.0_pre20190720::carbonrepo failed (postinst phase):
 *   default_pkg_postinst() is not supported in EAPI='7' in phase pkg_postinst
 * 
 * Call stack:
 *            ebuild.sh, line  125:  Called pkg_postinst
 *          environment, line 2242:  Called default
 *   phase-functions.sh, line  855:  Called default_pkg_postinst
 *   phase-functions.sh, line  848:  Called die

I resolved it by simply removing the "default" line at the start of the postinst function - I trust this does not break any intended functionality?

[chewi]

I don't think the default pkg_postinst function does anything so that should be fine but the presence of this function is shadowing xdg_pkg_postinst, which is important, so you should call that instead.

[dr-diem]

Thanks @chewi - duly added. My local testing is now completed successfully. Barring disaster, by some point this evening I will have completed the commit admin that is still outstanding and consequently have a set of three packages ready for your review.

[dr-diem]

Changes all committed; awaiting your feedback @chewi

[dr-diem]

Hi again @chewi . As discussed by email, given the interleaved commits for the three new packages I found it simpler to retract the PR and raise a new one comprising three clean, single-package commits rather than continue to attempt to rebase. The new PR is here: gentoo/gentoo#16308

Let me know what you think,

Ian

[dr-diem]

Hi @vLKp - now that the ebuilds are upgraded to EAPI=7, you should alter both to use xdg_pkg_postinst instead of default in pkg_postinst, per @chewi's comment a couple of weeks ago.

[vLKp]

Already done as of several days ago. I've been busy and had not pushed out my recent changes.

[dr-diem]

Closing this issue now that a testing and live ebuild have been accepted into the Gentoo main repository.

[chewi]

Hello. A couple of things.

@dr-diem, I thought you were going to follow up with the removal of the old ebuild version. It needs to go now due to its use of Python 2, are you good for me to go and do that?

@vLKp, I've just been asked about the copyright header and it turns out there was a reason why repoman was it flagging up. I didn't know that the string needs to be added to this AUTHORS file to be considered valid. Please could you file a Gentoo bug report about this as it instructs to get this resolved. I would do it but it probably needs to come from you.

[dr-diem]

On Mon, 14 Sep 2020, at 16:17, James Le Cuirot wrote: Hello. A couple of things. @dr-diem <https://github.com/dr-diem>, I thought you were going to follow up with the removal of the old ebuild version. It needs to go now due to its use of Python 2, are you good for me to go and do that?

Yeah, I wanted to leave it a while until we got no bug reports for the new one, and figured it was a 'low-traffic' ebuild so that I should leave it a good 6 months. That said, I am more than happy for you to drop it now as part of the general Python 2 EOL (goodbye and good riddance!). Ironic really - just this weekend I was assaying what Python 2 dependencies I still have.

@vLKp <https://github.com/vLKp>, I've just been asked about the copyright header and it turns out there was a reason why repoman was it flagging up. I didn't know that the string needs to be added to this AUTHORS <https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/AUTHORS> file to be considered valid. Please could you file a Gentoo bug report about this as it instructs to get this resolved. I would do it but it probably needs to come from you.

Ah! Glad you got to the bottom of that, because it did seem odd. Ian

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#502 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVPROE3GB2WIKJVPROTAWLSFZ25DANCNFSM4MGB2XXQ>.

[chewi]

@vLKp I've been pinged about this again and if we don't resolve this, it's highly likely that all this hard work will have to be dropped. This should only take a couple of minutes of your time, which is far less than it will take me to recreate these ebuilds from scratch without consulting the existing ones.

[ulm]

<Gentoo license team>
Just for my understanding, I suppose that "DXX Rebirth project contributors" is not a legal entity of its own, but simply a wild-card for the copyright holder, in a similar way that "Gentoo Authors" is?

Our policy in the main Gentoo repository is that the copyright header must say "Gentoo Authors" without any exceptions. The ebuild authors can be listed in our metadata/AUTHORS file if they want (but as you can see in the file, very few of them actually choose to be).
</Gentoo license team>

[chewi]

As stated above, my understanding of the AUTHORS file was slightly wrong. You can add to this file but ebuilds themselves must carry the Gentoo header. @vLKp, I recognise this is not what you wanted but I don't make the rules. I'm just very upset that users will end up losing out if we cannot resolve this.

You said that you didn't believe you had used Gentoo's ebuilds as inspiration for yours but it's been pointed out to me that you most likely did. I'm not at all suggesting you were trying to mislead here as you didn't seem sure and it can be hard to remember. Indeed, I would have realised this sooner if I'd remembered the details myself. I certainly have no desire to be territorial regarding this code, I just hope this discovery can defuse the situation.

The first combined dxx-rebirth ebuild was submitted to the gamerlay overlay by @Totktonada in 2016 before you committed yours in 2017. In particular, some of the local USE flag names and variable names in src_install match in a way that cannot be coincidental. Granted, gamerlay is not really an official Gentoo repository and @Totktonada has never been a Gentoo developer. However, the ebuild was committed bearing the Gentoo header and when I contacted @Totktonada on 2017-03-06 about bringing his work into the main repository, he was very much in favour. As you saw, I didn't actually get it into the main repository until 2017-04-27, after I'd made some changes.

[dr-diem]

Hi @vLKp ,

I'm re-opening this issue in hopes that doing so will bring @chewi's recent posts to your attention. I sincerely hope you'll agree to the proposal - we would so much like to integrate DXX-Rebirth into Gentoo in an ongoing manner!

Please let us know your thoughts,

Ian

[vLKp]

@chewi wrote:

@vLKp I've been pinged about this again and if we don't resolve this, it's highly likely that all this hard work will have to be dropped. This should only take a couple of minutes of your time, which is far less than it will take me to recreate these ebuilds from scratch without consulting the existing ones.

What is there to resolve? The ebuilds are already under a license that should cover everything you need. They are in the main tree, and I have not made further changes to them since June. I suppose I should bump the snapshot ebuild to current, but that's mechanical, and probably not what you mean.

@ulm wrote:

Just for my understanding, I suppose that "DXX Rebirth project contributors" is not a legal entity of its own, but simply a wild-card for the copyright holder, in a similar way that "Gentoo Authors" is?

That is correct.

Our policy in the main Gentoo repository is that the copyright header must say "Gentoo Authors" without any exceptions. The ebuild authors can be listed in our metadata/AUTHORS file if they want (but as you can see in the file, very few of them actually choose to be).

That seems like a strange policy.

@chewi wrote:

As stated above, my understanding of the AUTHORS file was slightly wrong. You can add to this file but ebuilds themselves must carry the Gentoo header. @vLKp, I recognise this is not what you wanted but I don't make the rules. I'm just very upset that users will end up losing out if we cannot resolve this.

What I wanted was not to deal with this strange policy, which has already cost me far more time than it seems likely ever to save me. I even offered a suggestion back on 2020-05-31 that, I thought, would satisfy the enforcement tool that seems to be driving your request. As I stated back then, my concern is about letting people who have one git history find the right point in the other git history, so that forward/backward ports are not unnecessarily painful.

To be clear, I'm not the one saying you need to remove the ebuild from the Gentoo tree. I have no objection to the ebuild in the Gentoo tree, at least as it stands in the commit I see now. If users get hurt because a Gentoo developer chooses to remove the ebuild, that is on whoever removed it.

You said that you didn't believe you had used Gentoo's ebuilds as inspiration for yours but it's been pointed out to me that you most likely did. I'm not at all suggesting you were trying to mislead here as you didn't seem sure and it can be hard to remember.

Github is currently hiding my prior comments behind a collapsible banner that it refuses to open, so I cannot go back and see exactly what was written. I probably would have inspected emerge -pv output for the main tree, and matched USE flags to ease the upgrade path. Was there something more? Perhaps more importantly, why is this relevant?

Since you want to discuss history, I will note that based on my commit message in e53e969, I think I did at that point spend the time to do a line-by-line comparison between the then-current Gentoo ebuild and the one I was maintaining. The result of that comparison included "match layout with that ebuild where possible, to simplify sharing changes.", as well as a bulleted list of places that were intentionally different (in most cases, because I thought the then-current Gentoo ebuild was incomplete (no support for enabling the editor), incorrect (useless patches), or insufficiently flexible (overzealous blocker relation, mandatory joystick support)).

The first combined dxx-rebirth ebuild was submitted to the gamerlay overlay by @Totktonada in 2016 before you committed yours in 2017.

I'm not familiar with the gamerlay overlay. I very much doubt I would have inspected anything in it, or even been aware the ebuild was there.

@dr-diem wrote:

I'm re-opening this issue in hopes that doing so will bring @chewi's recent posts to your attention.

Good choice. If I am short on time, which these days is quite often, I visit the issues list without logging in (which by default shows only open issues), look for any recent activity of interest, and log in only if I see something for which a login is required. Closed issues are invisible to me in this state, and show up only if I log in and check pending notifications.

I sincerely hope you'll agree to the proposal - we would so much like to integrate DXX-Rebirth into Gentoo in an ongoing manner!

If you are referring to the proposal I previously rejected, where I sign and send in a copyright assignment, I will reiterate my position: I have no interest in making such an assignment. I see no value to me, or to Rebirth generally, in doing so. I am frankly rather annoyed that I have now spent more time dealing with pointless policy arguments than I have dealing with actual technical issues.

[dr-diem]

Thanks for taking the time to reply @vLKp, and I apologize that these policy wranglings are taking more time than the actual technical work. For what it's worth I too don't understand Gentoo's intransigence with respect to the ebuild copyright header, but we are not able to alter it. As someone who is affiliated neither with the Gentoo nor Rebirth projects, I can contribute my two cents as to the value I see in transferring copyright of the file, in hopes of changing your mind.

The benefit that I see to you and the Rebirth project is that Gentoo remains one of the handful of thriving 'long term' Linux distributions that has a vigorous group of gaming users and, perhaps most importantly, it cares strongly about good quality software, as clearly do you. In the end, having an ebuild in Gentoo's own repo will grow the userbase of Rebirth, which can surely only be a good thing?

Whether spurious or not, Gentoo's policy means that if we cannot transfer copyright in the ebuild, they will drop the ebuild entirely and we'll be back to square one, wherein Gentoo users are forced to either create themselves a local overlay in order to use your ebuild (not trivial) or alternatively install dependencies manually and build Rebirth from source. Should Rebirth be available only to those who know their way around compilation? That seems a great shame to me.

I agree that Gentoo's ebuild policy is strange (@chewi could you point us at an explanation of why it is what it is? Is there a GLEP or discussion thread that led to the current position?), but surely growing the user base and simplifying installation for users of one Linux distro are benefits that are of value to the Rebirth project?

Whatever the historical truth, whatever the ethics of transferring copyright, I think that the community gets a net benefit if, thanks to all your hard work, Descent and Descent 2 can be played by the largest community possible. I appeal to your better nature to reconsider.

[ulm]

Whether spurious or not, Gentoo's policy means that if we cannot transfer copyright in the ebuild, [...]

There seems to be a misunderstanding here. Gentoo is neither asking for signing of a CLA nor for any transfer of copyright. Copyright of all contributions stays with their authors.

I agree that Gentoo's ebuild policy is strange (@chewi could you point us at an explanation of why it is what it is? Is there a GLEP or discussion thread that led to the current position?), [...]

There were many discussions, but I believe that the following two postings from 2018 summarize the rationale:
https://archives.gentoo.org/gentoo-project/message/9b3b723aa81fb212c7bf0e75efdffe05
https://archives.gentoo.org/gentoo-project/message/ff2533bd5aa32ebf71fcda91ca1e06ec

[dr-diem]

Thanks for the clarifications @ulm!

Does this help @vLKp? No transfer of copyright is requested. DXX Rebirth Project Contributors would be listed in the AUTHORS file and, for the purposes of the ebuild, you would be considered to be part of "Gentoo Authors". What do you think (in concert with my other appeal above :) ?

[vLKp]

The linked explanation seems to further confuse the issue. The second post, written by @ulm, closes with a paragraph that seems to directly contradict the need to revisit any of this:

The purpose of the proposal explicitly is *not* to stop anybody from
adding an ebuild with a preexisting copyright notice.  However, we should
make it clear that we strongly prefer the simplified form for ebuilds in
the Gentoo repository, entirely for practical reasons.

@dr-diem added an ebuild with a non-conforming copyright line, and everything was fine for months. Then suddenly this became a problem again. Apparently, "strongly prefer" became "require" sometime after that thread was written.

Regardless, if Gentoo policy requires using a misleading attribution line, go ahead and change it to say "Gentoo Authors" to satisfy whatever mindless tool is complaining about this. As @ulm noted in that mailing list post, the presence or absence of accurate attribution doesn't mean anything. (Also, as I noted in my very first comment responding to @dr-diem, I am doubtful someone would find a useful way to use the ebuild such that the conduct was disallowed by the GPL.)

[dr-diem]

Thank you @vLKp, your decision is, genuinely, heartily appreciated. I'll make the changes described above and we can move on to the future where I'm able maintain the Gentoo support for Rebirth in the long term.

Thanks all for your input,

Ian