Submitting ebuilds to Gentoo?

[gkroon]

Hi, nice overlay. Have you considered pushing the ebuild to the Gentoo tree directly? Just curious.

[xartin]

I need to fix the sonarr ebuild that currently has a broken install path before that could be considered. i've never done that nor am I aware of a policy for doing such a thing.

It's a great idea i support having used gentoo for fifteen years but using git i'm certainly a big greenhorn :)

[gkroon]

Could you verify my proposed fix? Also, I've never submitted an ebuild to the Gentoo tree directly, but would you be open to the idea? It might also attract more support. :-)

[xartin]

I just tested the src_unpack change to the sonarr 2.0.0.5228 ebuild and the install path is still broken after modifying my local ebuild and remerging.

equery reports sonarr directory installed to

/usr/share/work/sonarr/

The ideal fix would be to have the install path set to /usr/share/sonarr after install so that the existing init scripts for openrc and systemd are both usable as is.

I'm certain something is off with the way that portage is interpreting src_unpack and utilizing that unpacked directory structure. This may also possibly be related to how src_install is configured for

    insinto "/usr/share/"
    doins -r "${S}"

Sometimes figuring these ebuild dilemmas is simple and obvious but more often than not despite my experiences with gentoo just falls on having a better day than some with as few complicated challenges as possible to visualize the solution to the problem :)

This ebuild was modified from a git 9999 ebuild that did not have a specific version and i've had some minor challenges adapting to using versioned release tarballs sourced from sonarr versioned releases on github rather than the unversioned sonarr provided domain download tarball.

[gkroon]

Could you check if it works now? On my system it now installs Sonarr to /usr/share/sonarr.

[gkroon]

Hmm, it seems the NzbDrone.exe isn't precompile in the archives. I'm thinking we either have to find a way to compile it using the ebuild, or replace it with the precompiled archives at http://download.sonarr.tv/v2/master/mono/. Or do both, and create a separate sonarr-bin ebuild that pulls in the precompiled binary package. What do you think?

[gkroon]

I chose the easy way out and went with the precompiled binary tarball. :confused: Please let me know if this is desired.

[xartin]

Oh if the tarballs from github were not precompiled i hadn't noticed. the radarr builds were precompiled so i may have just assumed sonarr was as well.

If it needs to be that way it needs to but maintaining a non versioned ebuild can be a pain when the download tarball checksum changes every time sonarr releases an update. If sonarr does offer a versioned precompiled archive that would be preferred to avoid having archive checksums make emerge fail due to incorrect package manifest errors.

If there is a way to compile the sonarr code using linux i'm not entirely aware of how that would be accomplished other than some general suggestions.

Gentoo portage behaves how gentoo portage was designed to and sometimes convincing portage to do what is desired or perhaps best practice often comes with it's own list of challenges.

[gkroon]

The Sonarr GitHub release tarballs are (sadly) not precompiled - the ones from Radarr (still) are, yes. Sonarr offers versioned precompiled tarballs over at: http://download.sonarr.tv/v2/master/mono/. The latest of which I've used in my proposed pull request.

I tried to create an ebuild that would compile the source from GitHub, but I couldn't figure it out, sorry. Hence why I chose the "easy way out" and resort to the versioned precompiled tarballs.

Personally I think we should rename the current ebuilds to ${PN}-bin if we continue to use precompiled binaries. Then, we can always create separate ebuilds without '-bin' if/when we figure out how to compile the source manually. Please let me know if this satisfies your idea on how to shape your ebuilds.

[xartin]

Wanted to mention I haven't forgotten about your generous contributions and recently noticed there was an update released for sonarr and perhaps this week i'll work on an updated ebuild for the new sonarr version.

https://github.com/Sonarr/Sonarr/releases

I've had more free time to tinker with things since my "homelab" has required far less maintenance to keep everything functional and winter is arriving very soon so outdoors is not as hospitable as the warmer months which usually leaves more time for gentoo nerding.

The last proposed commits looked good and there was great progress made but restricting sonarr and radarr from being able to auto update so it doesn't cause a conflict where gentoo portage will overwrite already updated existing files could be wise and was also why i removed the auto update features from the ebuild templates that were initially used.

I'm still a real novice with using git and the last proposed commits looked good but the auto update features being permitted to function concerned me. if radarr or sonarr auto updated then portage updated radarr or sonarr that may be a source of problems for either package.

I'm unfortunately uncertain how to accept the commits without the auto update directory permissions being added in the ebuilds or init file templates. if the directory permissions are not set sonarr and radarr will both still function but the auto update attempts will fail due to root user directory ownership versus radarr or sonarr users owning the application directories.

Package manager dominance over uncontrolled software updates has generally always been the approach to strive for when using gentoo.

I should also mention i don't use openrc anymore and largely prefer systemd so testing any openrc init issues would require spinning up a new gentoo vm on my server. It's not a huge inconvenience but i already maintain seven gentoo installs on physical hardware. Aid with any reported issues with openrc is certainly welcome.

I'm also considering adding an ebuild for plex media server as fearedbliss has apparently retired as a gentoo developer and there is currently no active maintainer for plex media server.

https://packages.gentoo.org/packages/media-tv/plex-media-server

I'm getting close to completion of a functional gentoo powered HTPC server masterpiece with a dual 10 core xeon with an LSI 12GB/s sas hba running zfs raidz2 array and sonarr, radarr, nzbnet and plex media server are necessary components. Thanks to fearedbliss contributions to gentoo i stand a good chance of mastering zfs

With regards to the -bin ebuild idea i have no objections to creating a -bin ebuild for precompiled sonarr build. I uncertain anyone would really want to go though the trouble of compiling sonarr and would that even work or reliably compile. it could be more effort to maintain a "needs to be compiled" ebuild just for sonarr than would be desired.

I already maintain seven gentoo installs lol :)

[xartin]

Todo list items per grknight@gentoo.org for both sonarr and radarr ebuilds

grknight drop "# $Header: $" everywhere grknight radarr-0.2.0.910.ebuild: remove src_unpack and set S="${WORKDIR}/${MY_PN}" instead; drop eutils grknight ditto for radarr-0.2.0.1120.ebuild

Regarding the auto update needing to be disabled.

ali3nx > disabling the webupdater i suspected would be wise to prevent a portage version conflict if the auto updater has been permitted to function grknight > I have no idea about that ali3nx > the auto update is fantastic for windows but linux package managed perhaps not so much grknight > but yes, packages installed by portage should be managed by portage

radarr and sonarr auto update is confirmed a no go for use with gentoo when managed by portage.

And regarding portage tree submission once the ebuilds and init templates are corrected.

candrews> just submit pull requests to https://github.com/gentoo/gentoo/ candrews> Take a look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers for background on that candrews> And especially https://devmanual.gentoo.org/ for how to create package and best practices