| View previous topic :: View next topic |
| Author |
Message |
saturnalia0
Apprentice
Joined: 13 Oct 2016
Posts: 153
|
 Posted: Wed Aug 07, 2024 5:50 pm Post subject: [SOLVED] Would such a patch be welcome in this ebuild? |
 |
|
app-misc/ranger is maintained upstream, but the release cycle is very slow (last release was in 2019), see discussion here https://github.com/ranger/ranger/issues/2702
There are several patches upstream already merged, but not yet released, which affect Gentoo users. For example https://github.com/ranger/ranger/commit/82eef55b1664a66c774df969673435eb7bc82091
The ebuild simply fetches the tgz from upstream https://gitweb.gentoo.org/repo/gentoo.git/tree/app-misc/ranger/ranger-1.9.3-r1.ebuild
The aforementioned diff is easy enough to apply
| Code: |
$ git checkout v1.9.3
Previous HEAD position was bd9b37fa properly decode file:// urls given to ranger as argument (fixes #2900)
HEAD is now at 6045dc10 Tax loss harvesting release, nothing to see here
$ git cherry-pick 642d594b8328880d73d151852e4e41e7675ded6c
Auto-merging ranger/gui/color.py
[detached HEAD 6901b033] gui.color: Change dummy key
Author: toonn <toonn@toonn.io>
Date: Tue Mar 7 17:11:03 2023 +0100
1 file changed, 1 insertion(+), 1 deletion(-)
$ git cherry-pick 82eef55b1664a66c774df969673435eb7bc82091
Auto-merging ranger/gui/color.py
[detached HEAD 9262c992] color: Catch Color number is greater than COLORS-1
Author: toonn <toonn@toonn.io>
Date: Tue Mar 7 17:27:59 2023 +0100
1 file changed, 7 insertions(+)
|
This fixes the issue I'm having (crashes when previewing a JSON file).
Would that patch be something welcome in the ebuild, or is it generally frowned upon having such manual patches in ebuilds, relying on upstream release instead?
Last edited by saturnalia0 on Wed Aug 07, 2024 11:54 pm; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22382
|
| Posted: Wed Aug 07, 2024 6:05 pm Post subject: |
|
|
| I do not speak for the Gentoo maintainer for this project. However, my observation has been that most maintainers would prefer that you nudge upstream to issue a release with the relevant fixes. Failing that, there is plenty of precedent for an ebuild that applies a backported patch from upstream's repository. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1833
|
| Posted: Wed Aug 07, 2024 6:08 pm Post subject: |
|
|
It is not uncommon for an ebuild maintainer to import an important commit which has a fix that would be beneficial to a user.
This is often not new features and should be tiny in nature.
Filing bugs is the best way with an explanation of why a patch should be included in a pervious release |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2765
|
| Posted: Wed Aug 07, 2024 11:28 pm Post subject: |
|
|
Upstream really needs to do a new release, release version is also broken with python3.13 and been hoping won't have to figure out what needs backporting by the time of the python3.13 switch next year. I did try to ping them about this before but got no response. Would also rather not do a snapshot given haven't kept up with the state of things.
That aside, while I wouldn't want to backport new features or unimportant fixes, a small backport to fix an actual crash is always fair.
Normally this needs a bug filed to get maintainer attention, but I just happened to see this thread and I maintain ranger's ebuild, so I went ahead and did (hopefully haven't missed anything):
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bf46138dbd6 |
|
| Back to top |
|
|
saturnalia0
Apprentice
Joined: 13 Oct 2016
Posts: 153
|
| Posted: Wed Aug 07, 2024 11:54 pm Post subject: |
|
|
| Thank you very much. |
|
| Back to top |
|
|
|
Portage & Programming
