Created attachment 431184 [details] runescape-launcher-2.2.2.ebuild Hi, Please find attached runescape-launcher-2.2.2.ebuild and it's related files (metadata.xml & license file). This ebuild installs (from unpacked upstream .deb) the launcher for the recently released (18th April) native game client for the free-to-play MMORPG, RuneScape (http://www.runescape.com). There's some minor mangling of the included .desktop file & launcher script in src_prepare, via sed, but otherwise a fairly straight forward and simple ebuild. RDEPEND versions are as per the Packages.gz descriptor in the publisher's official apt repository. I've merged this ebuild locally and can confirm no runtime issues with default USE flags. I did note one runtime issue, where the launcher will segfault after some period of time if net-libs/webkit-gtk has been merged with the non-default "jit" flag enabled. With this in mind, would it be appropriate to amend the RDEPEND line for webkit-gtk to include [-jit]? Regards, Jack
Created attachment 431186 [details] License file
Created attachment 431188 [details] RuneScape-EULA
Created attachment 431190 [details] metadata.xml
Created attachment 431192 [details] metadata.xml
Also to note, this ebuild is only applicable to amd64 as the upstream binary is only provided for that arch.
Created attachment 431534 [details] runescape-launcher-2.2.2.ebuild Added missing libpng dependency
Is it presumed that you wish to proxy maintain this package. I do not recall coming across a request via the alias of the project. The metadata for one needs an entry for the project itself. A user maintainer does not stand alone in a package's metadata.xml
(In reply to Ian Delaney from comment #8) > Is it presumed that you wish to proxy maintain this package. I do not recall > coming across a request via the alias of the project. The metadata for one > needs an entry for the project itself. A user maintainer does not stand > alone in a package's metadata.xml I can maintain this package if desired. If the entry in metadata.xml is not correct / as per process, can you please direct me to the documentation for what I should include here? I've not submitted an ebuild before so I may not be entirely up to speed as to just what's expected.
Yes sorry I ought to have added this in the first place. https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers See the sample metadata.xml: <maintainer type="project"> <email>proxy-maint@gentoo.org</email> <name>Proxy Maintainers</name> </maintainer> will cover that. At this point, in the metadata file, the kde use flag is not required since it exists as a global IUSE flag. Also the license is probably not required. See the portage tree, there is a folder licenses. There are already a number of licenses there that pertain to EULA and one of those is highly likely to match. Feel free to join the irc channel #gentoo-proxy-maint for further sypport. Thank you
There are corrections required in the ebuild itself but let's start slowly and get those other elements set first, then the ebuild leading to addition to the tree
Created attachment 433144 [details] metadata.xml
I've added the new metadata.xml as per the example one for proxy maintainers. I had a look through the license files in the main tree and believe this package specific one is still required, although most likely only the first section, as the latter sections are simply verbatim copies of the licenses of dependencies. What changes are required in the ebuild itself?
I think you re-added the old metadata.xml. It does not differ. SRC_URI=" amd64? ( http://content.runescape.com/downloads/ubuntu/pool/non-free/r/runescape-launcher/runescape-launcher_${PV}_amd64.deb ) "To begin with, the line is a mile long. runescape-launcher is the PN so please substitute with ${PN}, twice. Then we do not wish for a name with .deb, but I am uncertain about what to do with a .deb file.
See https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/deb-sources/
Created attachment 433836 [details] metadata.xml Correct metadata.xml
Created attachment 433838 [details] runescape-launcher-2.2.2.ebuild Replace literal package name with ${PN} in src_uri. I'm not sure what can be done with the .deb based src - while it's certainly technically possible to manually extract it and rehost the content as suggested by your link (if I am understanding it correctly), I don't believe redistribution of the deb's content would be legally permissible under the EULA.
Since it is a binary -- perhaps install into /opt . -> https://devmanual.gentoo.org/general-concepts/filesystem/
(In reply to Jack Coulter from comment #17) > I'm not sure what can be done with the .deb based src - while it's certainly > technically possible to manually extract it and rehost the content as > suggested by your link (if I am understanding it correctly), I don't believe > redistribution of the deb's content would be legally permissible under the > EULA. There are a number of packages in the tree that use .deb sources - you can find them (to use as examples) with > qgrep -H '.deb"'
> There are a number of packages in the tree that use .deb sources - you can find them (to use as examples) with Yep, I was mainly working off chrome-binary-plugins when putting together this ebuild, which also uses a .deb source and installs its files in the appropriate locations under /usr - not in /opt. I can amend the ebuild to put the files from this .deb in opt instead of their current locations at the appropriate subtrees within /usr, but I imagine some files will still need to be installed in /usr - such as the .desktop files which, unless I'm mistaken, will not be found by the menu systems of various desktop environments unless they're in /usr/share/applications, and similar for the icon files also.
Just to make sure I'm understanding things correctly, currently the complete list of files installed by this ebuild is as follows: /usr /usr/bin /usr/bin/runescape-launcher /usr/libexec /usr/libexec/runescape /usr/share /usr/share/applications /usr/share/applications/runescape-launcher.desktop /usr/share/doc /usr/share/doc/runescape-launcher-2.2.2 /usr/share/doc/runescape-launcher-2.2.2/changelog.bz2 /usr/share/doc/runescape-launcher-2.2.2/copyright.bz2 /usr/share/icons /usr/share/icons/hicolor /usr/share/icons/hicolor/16x16 /usr/share/icons/hicolor/16x16/apps /usr/share/icons/hicolor/16x16/apps/runescape.png /usr/share/icons/hicolor/24x24 /usr/share/icons/hicolor/24x24/apps /usr/share/icons/hicolor/24x24/apps/runescape.png /usr/share/icons/hicolor/256x256 /usr/share/icons/hicolor/256x256/apps /usr/share/icons/hicolor/256x256/apps/runescape.png /usr/share/icons/hicolor/32x32 /usr/share/icons/hicolor/32x32/apps /usr/share/icons/hicolor/32x32/apps/runescape.png /usr/share/icons/hicolor/48x48 /usr/share/icons/hicolor/48x48/apps /usr/share/icons/hicolor/48x48/apps/runescape.png /usr/share/icons/hicolor/512x512 /usr/share/icons/hicolor/512x512/apps /usr/share/icons/hicolor/512x512/apps/runescape.png /usr/share/icons/hicolor/64x64 /usr/share/icons/hicolor/64x64/apps /usr/share/icons/hicolor/64x64/apps/runescape.png If I understand both the page you linked (https://devmanual.gentoo.org/general-concepts/filesystem/) and the relevant freedesktop.org standards, the files that currently go into /usr/share should remain there. The main launcher script should go to /opt/bin, and the binary that's currently in libexec should go into /opt/${PN}. Is this correct?
(In reply to Jack Coulter from comment #20) > Yep, I was mainly working off chrome-binary-plugins when putting together > this ebuild, which also uses a .deb source and installs its files in the > appropriate locations under /usr - not in /opt. Traditionally, binary applications are installed to the /opt tree rather than host-built binaries installed to /usr, but I'm not sure about the policy with games, and not familiar with this package myself. > I can amend the ebuild to put the files from this .deb in opt instead of > their current locations at the appropriate subtrees within /usr, but I > imagine some files will still need to be installed in /usr - such as the > .desktop files which, unless I'm mistaken, will not be found by the menu > systems of various desktop environments unless they're in > /usr/share/applications, and similar for the icon files also. Yes, desktop files, icons, and, if relevant, configuration files that would normally go in /etc would still be installed to their normal location, it's the application files itself that would go into /opt (if the package needs to be installed there at all).
Created attachment 433900 [details] runescape-launcher-2.2.2.ebuild I've changed the installation paths as discussed. The installed file list now looks like: /opt /opt/bin /opt/bin/runescape-launcher /opt/runescape-launcher /opt/runescape-launcher/runescape /usr /usr/share /usr/share/applications /usr/share/applications/runescape-launcher.desktop /usr/share/doc /usr/share/doc/runescape-launcher-2.2.2 /usr/share/doc/runescape-launcher-2.2.2/changelog.bz2 /usr/share/doc/runescape-launcher-2.2.2/copyright.bz2 /usr/share/icons /usr/share/icons/hicolor /usr/share/icons/hicolor/16x16 /usr/share/icons/hicolor/16x16/apps /usr/share/icons/hicolor/16x16/apps/runescape.png /usr/share/icons/hicolor/24x24 /usr/share/icons/hicolor/24x24/apps /usr/share/icons/hicolor/24x24/apps/runescape.png /usr/share/icons/hicolor/256x256 /usr/share/icons/hicolor/256x256/apps /usr/share/icons/hicolor/256x256/apps/runescape.png /usr/share/icons/hicolor/32x32 /usr/share/icons/hicolor/32x32/apps /usr/share/icons/hicolor/32x32/apps/runescape.png /usr/share/icons/hicolor/48x48 /usr/share/icons/hicolor/48x48/apps /usr/share/icons/hicolor/48x48/apps/runescape.png /usr/share/icons/hicolor/512x512 /usr/share/icons/hicolor/512x512/apps /usr/share/icons/hicolor/512x512/apps/runescape.png /usr/share/icons/hicolor/64x64 /usr/share/icons/hicolor/64x64/apps /usr/share/icons/hicolor/64x64/apps/runescape.png
This being a specialised AND binary package, it is best to get final checks and ticks from the dev who work in them. aka gentoo-desktop. It has a channel. Take it from there. While the package's ebuild looks fine from here, the cost of it not being quite as expected can be high. Proxy maintainers project potentially covers the full scope of gnetoo, but it lacks a rep of every specialty. Get en endorsement form one of those and we can add it.
(In reply to Ian Delaney from comment #24) > This being a specialised AND binary package, it is best to get final checks > and ticks from the dev who work in them. aka gentoo-desktop. It has a > channel. Take it from there. While the package's ebuild looks fine from > here, the cost of it not being quite as expected can be high. > Proxy maintainers project potentially covers the full scope of gnetoo, but > it lacks a rep of every specialty. Get en endorsement form one of those and > we can add it. Thanks Ian, I will ask around on IRC as suggested.
If you install .desktop files in /usr/share/applications, you must run update-desktop-database as appropriate. You can use xdg.eclass phases for that; or xdg-utils.eclass provided helper functions if you provide your own phases. I think fdo-mime.eclass was doing this earlier, with xdg* being the new ones preferred now, but not 100% sure. If you install icon files in /usr/share/icons, you should update gtk icon caches. gnome2-utils.eclass has helpers for this. Call gnome2_icon_savelist in pkg_preinst, and then gnome2_icon_cache_update in pkg_postinst and pkg_postrm. Various ebuilds in the tree do this as an example (many of them use old fdo-mime based update-desktop-database as well there, use xdg or xdg-utils instead there).
What for are you inheriting multilib?
(In reply to Mart Raudsepp from comment #27) > What for are you inheriting multilib? I was originally working off the chrome-binary-plugins ebuild as an example. I've removed the redundant multilib inherit now
Created attachment 434130 [details] runescape-launcher-2.2.2.ebuild Now inherits xdg and gnome2-utils and updates .desktop and icon caches on post{inst,rm}
Thank you leio for assisting user here.
Created attachment 434270 [details] runescape-launcher-2.2.2.ebuild Fix path .desktop file to match the new launcher script location in /opt/bin
@Licenses team: AFAICS the license should be added to the @EULA group. The download page at https://www.runescape.com/download says "By downloading this software you agree to our End User License Agreement." and when clicking the "Linux" button, a text field pops up with commands to install it from the console on Ubuntu ("apt-get install"). I wonder if we need fetch restriction, or if mirror restriction will be enough here?
ulm where does this leave https://bugs.gentoo.org/attachment.cgi?id=431188
(In reply to Ian Delaney from comment #33) > ulm where does this leave https://bugs.gentoo.org/attachment.cgi?id=431188 We don't have this, so it would have to be added as a new license file.
I don;t know if this came up before but the build install displays a QA notice, in red. * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /opt/runescape-launcher/runescape These in fact ware erroneous since it is a binary pre-built. See vars QA_FLAGS_IGNORED QA_PREBUILT /usr/lib/portage/pythonVersion/install-qa-check.d/10ignored-flags You set assign the file listed ^^ as the value to the var. Beyond that it should have reached all QA checks
Created attachment 434764 [details] runescape-launcher-2.2.2.ebuild I've added the QA_FLAGS_IGNORED part, however I didn't get the message you were seeing on my system even without this change - Is there an extra FEATURE or something else that needs to be enabled to see such QA warnings?
(In reply to Ulrich Müller from comment #32) > @Licenses team: AFAICS the license should be added to the @EULA group. > > The download page at https://www.runescape.com/download says "By downloading > this software you agree to our End User License Agreement." and when > clicking the "Linux" button, a text field pops up with commands to install > it from the console on Ubuntu ("apt-get install"). I wonder if we need fetch > restriction, or if mirror restriction will be enough here? Sounds like mirror is enough. There's no "you must click this before downloading" type of clause.
(In reply to Jack Coulter from comment #36) > Created attachment 434764 [details] > runescape-launcher-2.2.2.ebuild > > I've added the QA_FLAGS_IGNORED part, however I didn't get the message you > were seeing on my system even without this change - Is there an extra > FEATURE or something else that needs to be enabled to see such QA warnings? This comes with the latest portage repoman combo release only a couple of days ago. You can also get this to be triggered by adding -frecord-gcc-switches to CFLAGS in make.conf the other *FLAGS are then assigned to the value of CLFAGS except for LDFLAGS.
NO QA_PREBUILT="/opt/runescape-launcher/runescape" This says set the value of "/opt/runescape-launcher/runescape" to QA_PREBUILT which then tells portage or emerge / ebuild.sh that this file ix exempt form this QA notice. I shall put it in for you, take not for the future. This is the only element needed to go. Also I mentioned I think to take out the amd64? ( ) With KEYWORDS="-* ~amd64" your only possible state is amd64 so I have take it out. commit 48c915cd290f9aa32f7580373c0620744ec5abff Author: Ian Delaney <idella4@gentoo.org> Date: Fri May 20 21:20:52 2016 +0800 games-rpg/runescape-launcher: new ebuild, (binary) initial vn. 2.2.2 To be maintained by user Jack Coulter under the Proxy Maintainers Project initial ebuild supplied as attachment via the gentoo bug. This package required a new license, added under the group 'EULA' Gentoo-bug: #580486
(In reply to Ian Delaney from comment #39) > NO > > QA_PREBUILT="/opt/runescape-launcher/runescape" > This says set the value of "/opt/runescape-launcher/runescape" to QA_PREBUILT > which then tells portage or emerge / ebuild.sh that this file ix exempt form > this QA notice. > > I shall put it in for you, take not for the future. This is the only element > needed to go. Ah, I see now, thank you for fixing that for me. > Also I mentioned I think to take out the amd64? ( ) > With KEYWORDS="-* ~amd64" your only possible state is amd64 so I have take > it out. Right, I understand now - ~amd64 is the only possible keyword hence the conditional in SRC_URI is redundant. Thank you for all your help & patience with this.
I created my own version of this ebuild, and had to add a section to /opt/bin/runescape-launcher: gcc_dir=`gcc-config --get-lib-path | cut --delimiter=":" --fields=1` export LD_LIBRARY_PATH=/usr/lib64/opengl/ati/lib:/lib64:/usr/lib64:${gcc_dir} Without adding a LD_LIBRARY_PATH I get seg faults. Note that I am using ati-drivers
