games-strategy/openra-20150424 final release http://www.openra.net/news/release-20150424/ Reproducible: Always
tman, please do not zero-day bump request. Maintainers need to he given a little time to work out a bump. See: https://wiki.gentoo.org/wiki/Bugzilla/Guide#Zero-day_bump_requests for more information.
please keep zero-day bumping, because I disagree with that wiki link statement The only problem is that bugzilla currently doesn't have a Component "bump request". I have already updated openra here https://github.com/hasufell/games-overlay/commit/4c86fee8bb382c92a7584f687f63ce85782c342d Since I don't work on the CVS tree much, but only import stuff there once in a while, until the gentoo workflow gets unbroken.
What is the difference between your and the upstream tarball?
(In reply to Christoph Junghans from comment #3) > What is the difference between your and the upstream tarball? The upstream tarball does not compile, because it fetches dependency files (not necessarily real packages) via "nuget" (which is not even in the tree) during build-time.
Did you try replacing the nuget calls with noget calls? https://github.com/OpenRA/OpenRA/blob/bleed/thirdparty/noget.sh
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1537bbcee03d1319b059a84a90f51931ec32212
(In reply to Julian Ospald (hasufell) from comment #4) > (In reply to Christoph Junghans from comment #3) > > What is the difference between your and the upstream tarball? > > The upstream tarball does not compile, because it fetches dependency files > (not necessarily real packages) via "nuget" (which is not even in the tree) > during build-time. I really think it is bad behavior to publish your own tarball instead of using the one from upstream and patching it. I remember having a discussion along these lines some time ago, but I couldn't find the related policy. Question @ QA: is there a policy about patching upstream tarballs? Also openra.net recommends using the ebuild from dr overlay: <https://github.com/cerebrum/dr/blob/master/games-strategy/openra/openra-20150628.ebuild>, which gets around that issue!
(In reply to Christoph Junghans from comment #7) > (In reply to Julian Ospald (hasufell) from comment #4) > > (In reply to Christoph Junghans from comment #3) > > > What is the difference between your and the upstream tarball? > > > > The upstream tarball does not compile, because it fetches dependency files > > (not necessarily real packages) via "nuget" (which is not even in the tree) > > during build-time. > I really think it is bad behavior to publish your own tarball instead of > using the one from upstream and patching it. I have contributed to the upstream Makefile numerous times and I don't have the time or energy to keep up with every release that gets worse. > I remember having a discussion > along these lines some time ago, but I couldn't find the related policy. > Question @ QA: is there a policy about patching upstream tarballs? > This is up to my discretion. If you don't provide a working patch, you don't get to complain. I might just fix it for the next release if creating the tarball gets too tedious for me. > Also openra.net recommends using the ebuild from dr overlay: > <https://github.com/cerebrum/dr/blob/master/games-strategy/openra/openra- > 20150628.ebuild>, which gets around that issue! That is wrong information. It does NOT solve that issue. It just fetches during build time which is a fundamental QA violation.
(In reply to Julian Ospald (hasufell) from comment #8) > (In reply to Christoph Junghans from comment #7) > > (In reply to Julian Ospald (hasufell) from comment #4) > > > (In reply to Christoph Junghans from comment #3) > > > > What is the difference between your and the upstream tarball? > > > The upstream tarball does not compile, because it fetches dependency files > > > (not necessarily real packages) via "nuget" (which is not even in the tree) > > > during build-time. > > I really think it is bad behavior to publish your own tarball instead of > > using the one from upstream and patching it. > I have contributed to the upstream Makefile numerous times and I don't have > the time or energy to keep up with every release that gets worse. Which pull request on https://github.com/openra/openra? > > I remember having a discussion > > along these lines some time ago, but I couldn't find the related policy. > > Question @ QA: is there a policy about patching upstream tarballs? > This is up to my discretion. If you don't provide a working patch, you don't > get to complain. I might just fix it for the next release if creating the > tarball gets too tedious for me. Sure, but do you really want me to post a patch between your and their tarball now? If you made the changes already, it is trivial to create a patch out of them. To clarify, I am not complaining about the changes you made, but simply the way how you incorporated them!
(In reply to Christoph Junghans from comment #9) > (In reply to Julian Ospald (hasufell) from comment #8) > > (In reply to Christoph Junghans from comment #7) > > > (In reply to Julian Ospald (hasufell) from comment #4) > > > > (In reply to Christoph Junghans from comment #3) > > > > > What is the difference between your and the upstream tarball? > > > > The upstream tarball does not compile, because it fetches dependency files > > > > (not necessarily real packages) via "nuget" (which is not even in the tree) > > > > during build-time. > > > I really think it is bad behavior to publish your own tarball instead of > > > using the one from upstream and patching it. > > I have contributed to the upstream Makefile numerous times and I don't have > > the time or energy to keep up with every release that gets worse. > Which pull request on https://github.com/openra/openra? > Search the git history. > > > I remember having a discussion > > > along these lines some time ago, but I couldn't find the related policy. > > > Question @ QA: is there a policy about patching upstream tarballs? > > This is up to my discretion. If you don't provide a working patch, you don't > > get to complain. I might just fix it for the next release if creating the > > tarball gets too tedious for me. > Sure, but do you really want me to post a patch between your and their > tarball now? > If you made the changes already, it is trivial to create a patch out of them. > To clarify, I am not complaining about the changes you made, but simply the > way how you incorporated them! I am not sure I can follow. The primary changes would involve stuffing a lot of things into SRC_URI manually and then emulating all the "noget" calls the build system does in src_unpack().
(In reply to Julian Ospald (hasufell) from comment #10) > (In reply to Christoph Junghans from comment #9) > > (In reply to Julian Ospald (hasufell) from comment #8) > > > (In reply to Christoph Junghans from comment #7) > > > > (In reply to Julian Ospald (hasufell) from comment #4) > > > > > (In reply to Christoph Junghans from comment #3) > > > > > > What is the difference between your and the upstream tarball? > > > > > The upstream tarball does not compile, because it fetches dependency files > > > > > (not necessarily real packages) via "nuget" (which is not even in the tree) > > > > > during build-time. > > > > I really think it is bad behavior to publish your own tarball instead of > > > > using the one from upstream and patching it. > > > I have contributed to the upstream Makefile numerous times and I don't have > > > the time or energy to keep up with every release that gets worse. > > Which pull request on https://github.com/openra/openra? > Search the git history. Thanks for the hint, <https://github.com/OpenRA/OpenRA/pull/3500> I guess? > > > > I remember having a discussion > > > > along these lines some time ago, but I couldn't find the related policy. > > > > Question @ QA: is there a policy about patching upstream tarballs? > > > This is up to my discretion. If you don't provide a working patch, you don't > > > get to complain. I might just fix it for the next release if creating the > > > tarball gets too tedious for me. > > Sure, but do you really want me to post a patch between your and their > > tarball now? > > If you made the changes already, it is trivial to create a patch out of them. > > To clarify, I am not complaining about the changes you made, but simply the > > way how you incorporated them! > > I am not sure I can follow. The primary changes would involve stuffing a lot > of things into SRC_URI manually and then emulating all the "noget" calls the > build system does in src_unpack(). Now, you made me very curious! The diff between your and upstream's version looks like: diff -uar OpenRA-release-20150424/Makefile openra-20150424/Makefile --- OpenRA-release-20150424/Makefile 2015-04-22 15:24:44.000000000 -0600 +++ openra-20150424/Makefile 2015-05-07 17:44:09.000000000 -0600 @@ -295,7 +295,6 @@ cd thirdparty && ./fetch-thirdparty-deps-windows.sh && cd .. cli-dependencies: - cd thirdparty && ./fetch-thirdparty-deps.sh && cd .. @ $(CP_R) thirdparty/*.dll . @ $(CP_R) thirdparty/*.dll.config . Only in openra-20150424/thirdparty: FuzzyLogicLibrary.dll Only in openra-20150424/thirdparty: ICSharpCode.SharpZipLib.dll Only in openra-20150424/thirdparty: MaxMind.Db.dll Only in openra-20150424/thirdparty: MaxMind.Db.xml Only in openra-20150424/thirdparty: MaxMind.GeoIP2.dll Only in openra-20150424/thirdparty: MaxMind.GeoIP2.XML Only in openra-20150424/thirdparty: Mono.Nat.dll Only in openra-20150424/thirdparty: Moq.dll Only in openra-20150424/thirdparty: Newtonsoft.Json.dll Only in openra-20150424/thirdparty: Newtonsoft.Json.xml Only in openra-20150424/thirdparty: nunit.framework.dll Only in openra-20150424/thirdparty: nunit.framework.xml Only in openra-20150424/thirdparty: RestSharp.dll Only in openra-20150424/thirdparty: RestSharp.xml Only in openra-20150424/thirdparty: SharpFont.dll Only in openra-20150424/thirdparty: SharpFont.dll.config Only in openra-20150424/thirdparty: SharpFont.xml Only in openra-20150424/thirdparty: StyleCop.CSharp.dll Only in openra-20150424/thirdparty: StyleCop.CSharp.Rules.dll Only in openra-20150424/thirdparty: StyleCop.dll Only in openra-20150424/thirdparty: StyleCopPlus.dll The Makefile could be easily patched or changed using sed in the ebuild, but bundling dll files is an absolute no-no as these files are surely not under GPL-3 as LICENCE in the ebuild suggests. @license: What is the license dll files usually come under? My original concern was that you published a tarball with different content, but named the same as upstream's tarball, which is just bad behavior, but adding some files to it without clarify that to the user via some means (e.g. license change, readme, different naming convention) is not ok.
(In reply to Christoph Junghans from comment #11) > @license: What is the license dll files usually come under? Whatever license their author or copyright holder chooses for them. thirdparty/README says "MIT license" for Eluant.dll and "zlib license" for SDL2-CS.dll.
(In reply to Christoph Junghans from comment #11) > The Makefile could be easily patched or changed using sed in the ebuild, but > bundling dll files is an absolute no-no as these files are surely not under > GPL-3 as LICENCE in the ebuild suggests. > @license: What is the license dll files usually come under? > I am not sure you did listen. You would have to manually figure out the exact versions of all the files that are fetched during build time, add them to SRC_URI, unpack all the stuff in src_unpack into the right folders and so on. And that for every version bump. Bundling these dll files would be what UPSTREAM should do (but that will complicate their release workflow). If you want to break OpenRA, you can try to write ebuilds for all these dlls. Some of them are not even part of a real package, afaik. Anyway, I have just removed the ebuild from the tree and will wait until upstream fixes these issues. Until then, it is available in my overlay. You can speed up the process by providing ebuilds for all dependencies. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=29d335a43d6fec7cecd02fb2755b856e7a132fdd
I did some hackery, so I don't have to repackage the tarball, but use dummy-get functions for all the stuff and then append the whole crap to SRC_URI. Despite taking a lot of time it is also error prone and sucks, because some files are not versioned upstream, so people may randomly get checksum errors. As in: not going to happen in-tree.
