I have mentioned in http://bugs.gentoo.org/show_bug.cgi?id=329747#c4 that the Makefile used in the mp3gain-1.5.2 source is not perfect, its "install" target has unwanted tabular character. As a remedy, a new corrected source tarball was uploaded to the SRC_URI on a new name "mp3gain-1_5_2_r1-src.zip". Please manifest this ebuild (patch) to the official portage tree. Thanks! Reproducible: Always Steps to Reproduce:
Created attachment 241407 [details] ebuild (patch) for mp3gain 1.5.2 version
Created attachment 241409 [details, diff] diff from old to new ebuild
There is more problems in the upstream Makefile, such as (I'm assuming you are upstream too: Respect CC (full compiler name) from environment: -CC= gcc +CC?= gcc Respect CFLAGS from environment, drop forced optimization: -CFLAGS= -Wall -O2 -DHAVE_MEMCPY +CFLAGS+= -Wall -DHAVE_MEMCPY Respect LDFLAGS from environment: - $(CC) -o mp3gain $(OBJS) $(RC_OBJ) $(LIBS) + $(CC) $(LDFLAGS) -o mp3gain $(OBJS) $(RC_OBJ) $(LIBS) Futhermore, for us: -r1 is Gentoo revision versioning _p1 is Upstream patchlevel, which matches this case
(In reply to comment #3) I have tried to find out how an "upstream patch" should be handled here, but I'm lost. Despite I searched for a project containing upstream patches, for example dev-libs/mpfr has ones, and analyzed its ebuild files, I cannot figure out what I should do. BTW thanks for your changes to the Makefile (mp3gain was mainly created for Windows, but it has an ancient unix Makefile)! First of all I applied these changes to respect the environment variables during building, so I have changed the Makefile (again). I made a new sourceball from the whole source of the project and uploaded it into Sourceforge on this name: mp3gain-1_5_2-r2.zip. I also modified the ebuild to use this file in its SRC_URI. Finally I tried this new ebuild locally, it does work. The name of this ebuild is mp3gain-1.5.2_p2.ebuild. Everything is fine, but separate patch in fact is not used here, the patch is included in a new source tarball, it looks like a new version. I'm afraid it will not not acceptable by you. I can also make real upstream patch files containing the changes. There would be 2 patch files containing the changes made on the Makefile (1.5.2 -> 1.5.2-r1, 1.5.2-r1 -> 1.5.2-r2)., they would be also uploaded to the upstream server. (In this case the complete source balls containing these patches can be removed from the server.) How would the ebuild look like in this case? SRC_URI would contain mp3gain_1_5_2-src.zip and the 2 patches? Or the 2 patches are not downloaded from the upstream server (during the ebuild manifest), I have to attach them separately in this bug report? I'm confused. (Could you tell me a project/ebuild where these upstream patches are handled correctly?)
Created attachment 241481 [details] ebuild (patch) for mp3gain 1.5.2 version
Created attachment 241483 [details, diff] diff from old to new ebuild
It seems I'm on my own, so I tried to make a real upstream patched ebuild, please omit my comments from #4 to #6. The new ebuild is mp3gain-1.5.2_p1.ebuild, it has 2 upstream patch files named 1.5.2-01-makefile-install.patch and 1.5.2-02-makefile-respect.patch. I've tested this new ebuild in my local portage on amd64.
Created attachment 241685 [details, diff] patch to current (mp3gain-1.5.2.)ebuild, new one is mp3gain-1.5.2_p1.ebuild
Created attachment 241687 [details, diff] upstream patch #1 - it must be inserted under files directory
Created attachment 241689 [details, diff] upstream patch #2 - it must be inserted under files directory
From general perspective: If you are upstream of the package, you can simply roll a new tarball with the patches applied. Call it "mp3gain-1_5_2_1-src.zip" or "mp3gain-1_5_2_p1-src.zip" for example. From Gentoo perspective: The install patch is not useful for us, we use Portage's internal command for install. The second patch is handled by sed's in the ebuild. So if these 2 patches are the only difference to 1.5.2, it's not worth for us to even bump it... it would only trigger pointless rebuild for users.
(In reply to comment #11) > From general perspective: > > If you are upstream of the package, you can simply roll a new tarball with the > patches applied. Call it "mp3gain-1_5_2_1-src.zip" or > "mp3gain-1_5_2_p1-src.zip" for example. So I should not have dropped comment #4 :) > > From Gentoo perspective: > > The install patch is not useful for us, we use Portage's internal command for > install. The second patch is handled by sed's in the ebuild. So if these 2 > patches are the only difference to 1.5.2, it's not worth for us to even bump > it... it would only trigger pointless rebuild for users. All right, I knew that "make install" was not used by Gentoo. Because there are no more changes apart from the Makefile, please mark this bug closed or invalid. The sed usage in mp3gain-1.5.2.ebuild contains only a small part of the "respect" patch. If you wish, I can make a Gentoo revision containing my 2nd patch but using sed commands. Nevertheless by the next mp3gain version, these patches will be included, they are already in the upstream source...
(In reply to comment #12) > Because there are no more changes apart from the Makefile, please mark this > bug closed or invalid. Will mark as resolved upstream, which seems fairer to you. Thank you :)
