Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13245 - grep + debian patches

Attached to Project: Arch Linux
Opened by Xavier (shining) - Thursday, 12 February 2009, 21:58 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 06 March 2009, 21:22 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

There is a new version of grep : 2.5.4, but as expected the majority of the existing fixes are still needed.
See  FS#7141  for the one that really bugged me.
It looks quite easy to just re-use all the debian patches by directly taking their diff.gz. That would mean very little work from the maintainer for the future upstream updates, just pickup the new debian diff.gz file, bump the version, and you are done.
Currently, if you want to update the PKGBUILD, you have to extract manually the needed patches from debian diff.gz or try to grab it from some other distribs.
   PKGBUILD (0.9 KiB)
(application/x-gzip)    grep_2.5.4-1.diff.gz (17 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 06 March 2009, 21:22 GMT
Reason for closing:  Not a bug
Comment by Jan de Groot (JGC) - Thursday, 12 February 2009, 22:23 GMT
Just applying a random combined patch from another distribution doesn't look like a good idea to me. IMHO the maintainer has to know why a patch is applied.
Comment by Xavier (shining) - Thursday, 12 February 2009, 22:49 GMT
Well ok, I am not too decided about this. Grep upstream looks quite weird though, but well.
It is still possible to get the same ease of use by using directly the debian diff.gz but only applying the needed patches, see attached PKGBUILD-v2.
Otherwise we can stick with the current methods, see PKGBUILD-v1 and the attached patch 64-egf-speedup.patch .
And for applying all patches, see PKGBUILD-v3 which is the one I attached originally + a small fix for successive builds (rm -r debian).

   PKGBUILD-v1 (0.9 KiB)
   PKGBUILD-v2 (0.9 KiB)
   PKGBUILD-v3 (1 KiB)
   64-egf-speedup.patch (18 KiB)
Comment by Loui Chang (louipc) - Sunday, 22 February 2009, 08:14 GMT
Isn't is possible to push the patches upstream?
Comment by Xavier (shining) - Sunday, 22 February 2009, 09:53 GMT
Most of these patches were submitted to upstream years ago : http://savannah.gnu.org/patch/?group=grep
The one which interests me the most is the egf speedup one, since I noticed the huge performance slowdown in utf8 locale myself. That patch was submitted upstream 4 years ago : http://savannah.gnu.org/patch/?3803

Last time I checked, redhat/fedora and debian patchset for grep were pretty similar. I would think most of these patches are valid, but I agree that it would require a closer look to at least know which issues are addressed.
So I am fine with just applying 64-egf-speedup.patch
Comment by Andreas Radke (AndyRTR) - Sunday, 22 February 2009, 13:23 GMT
64-egf-speedup.patch is already included. for everything else I see no need. request one by one if you need more features/fixes.
Comment by Xavier (shining) - Wednesday, 25 February 2009, 17:07 GMT
  • Field changed: Percent Complete (100% → 0%)
The request is not to apply all debian patches. My suggestion is only to use the debian diff.gz directly, for easier release bump of grep (2.5.4 is out). I remember the egf-speedup patch was dropped once with a new upstream release because it didn't apply anymore. however, it was still required. Then if we decide to apply other patches from the debian diff,gz as well, it will be very easy and straightforward. You can of course reject that suggestion but you did not make it clear.
Comment by Andreas Radke (AndyRTR) - Wednesday, 25 February 2009, 17:35 GMT
I cannot see any reason to apply more than that one 64-egf-speedup.patch - I know where to get it. I have no intention to add further non-upstream patches. As stated above request one by one if you find an important(!) bug or major feature missing. I guess you know our patching rules... ;)

And 2.5.4 was in testing and is in core meanwhile.

Loading...