The new compression format .xz which is the successor of .lzma is not yet supported by texinfo, especially not by install-info. This is a problem, because it means that portage will generate inappropriate info/dir files when PORTAGE_COMPRESS="xz" is used. The attached patch solves this problem.
Created attachment 191196 [details, diff] Patch against texinfo-4.13 to support xz compression format
Martin, have you proposed this patch upstream? What do they say?
> Martin, have you proposed this patch upstream? No, I have bad experience reporting to GNU.
(In reply to comment #3) > No, I have bad experience reporting to GNU. Are you aware what consequences applying feature-patches downstream comes with? Maybe give them another chance?
> Are you aware what consequences applying feature-patches downstream > comes with? Yes, unfortunately, I maintain several local patches (usually for GNU) which are not included upstream. I do not mind if somebody else reports it, but I will not do it: I will of course not claim a copyright for such a tiny straightforward patch, but I am not willing to sign a huge contract whose full consequences are hard to estimate because of this.
If we start including feature patches down at distro level we have to port that patch over for each bump we do. That slows bumps down and is error prone. I myself wanted to have pcmanfm patches included downstream back then. Now I see it's good that it wasn't included. I propose that you maintain ebuilds including your patches in an overlay. We can include your overlay in the list of registered overlays (layman-global.txt) if you want. If you agree with me please close this bug. Otherwise please propose an alternative to applying the patch from the ebuild.
It is of course up to you to decide whether or not you want to include a patch. However, I suggest to leave the bug open anyway so that people running into the same problem will find it more easily: Rejecting to fix a problem is ok but does not solve it. > I propose that you maintain ebuilds including your patches in an overlay. Thanks for the offer, but I do not have the means (i.e. accessible systems) to provide an overlay which people can access. If a new release comes out which requires a different patch (I suppose this will not be very often) I will perhaps attach it to this bug (if I find the time to write it).
(In reply to comment #7) > It is of course up to you to decide whether or not you want to include > a patch. However, I suggest to leave the bug open anyway so that people > running into the same problem will find it more easily: Rejecting to fix > a problem is ok but does not solve it. Agreed. > > I propose that you maintain ebuilds including your patches in an overlay. > > Thanks for the offer, but I do not have the means (i.e. accessible systems) > to provide an overlay which people can access. If you know the basics of Git that's easy. There are several places you can get your repo hosted on. More on that via private mail if you're interested, I would say. > If a new release comes out > which requires a different patch (I suppose this will not be very often) > I will perhaps attach it to this bug (if I find the time to write it). Sure. Or link to your new overlay :-)
Upstreeam has a patch to add xz support in CVS. http://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=bfae00d02b5fb3a2ce34c09d2dbf0ca2f96b154f
Apparently the url I posted earlier isn't working. http://git.savannah.gnu.org/gitweb/?p=texinfo.git;a=commit;h=bfae00d02b5fb3a2ce34c09d2dbf0ca2f96b154f
added upstream patch (with crap fixed/cleaned up) to 4.13-r1
