you should not change flag fedora-review to ? , it should be done by the official package reviewer for this package.

Removed :)

Informal review:

1. License is at least partially LGPL, so it should probably be "LGPL, GPL+ with exceptions" or something like that.

Licenses found:
     "GPL", "LGPL (v2 or later)", "GPL (v2 or later)", "GPL (v3 or later)",
     "Unknown or generated", "ISC GPL (v3 or later)", "BSD (3 clause) GPL (v3
     or later)", "BSD GPL (v2 or later)", "*No copyright* Public domain",
     "LGPL (v3 or later)", "ISC GPL (v2 or later)", "LGPL (v3.1 or later)",
     "LGPL (v2.1 or later)", "GPL (v3)".

2. Source0 — just use http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=snapshot;h=%{githead};sf=tgz

3. Requires: remove sed, see https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions

4. Provides: why "bundled(gnulib)"? gnulib doesn't bundle gnulib.

5. There's no need to explictly specify permissions: install -dm755, etc, should not be needed. Just say 'mkdir -p ...', and 'cp -p'. This will reduce the noise in the spec file, making it easier to understand.

6. Why is gnulib-tool installed in %{_datadir} instead of %{_bindir} directly?
If it won't function correctly otherwise, then just add a comment in the spec explaining this. Debian package doesn't do this, so it probably isn't necessary.

7. /usr/share/gnulib/tests should be a separate package.
   The docs should be a separate package too.

gnulib seems to confuse the hell out of rpmlint, but in the noise there are some good suggestions:

8. Texinfo files are installed using install-info in %post and %preun if
  package has .info files.
  Note: Texinfo .info file(s) in gnulib
  See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Texinfo

9. If (and only if) the source package includes the text of the license(s) in
  its own file, then that file, containing the text of the license(s) for the
  package is included in %doc.
  Note: Cannot find COPYING.LESSERv2 in rpm(s)

10. [!]: Uses parallel make %{?_smp_mflags} macro.

11. gnulib.noarch: W: incoherent-version-in-changelog 20131022-git25fb29a-1 ['20131022.git25fb29a-1.fc19', '20131022.git25fb29a-1']

12. Check http://packages.debian.org/sid/gnulib, they have man pages. It would be nice to copy them.

Out of curiosity, what do you intend to use this package for? 

Most/all consumers of gnulib just copy source files they need... packaging it seems odd.

It is nice to be able to use it without bundling in the sources: just use gnulib-tool with appropriate options to copy stuff at build time. This way one always "bundles" the version that is available at build time, without updating manually. Kind of like running autoreconf instead of keeping configure in git.

ok, fair enough. Just wanted to make sure you didn't think you could unbundle gnulib from all the packages that have it currently. :) Carry on.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> It is nice to be able to use it without bundling in the sources:
No. This is not the way gnulib is supposed to be used.
gnulib files are supposed to be updated from git and the results to be bundled inside of a source-tree.


(In reply to Kevin Fenzi from comment #4)
> Out of curiosity, what do you intend to use this package for? 
> 
> Most/all consumers of gnulib just copy source files they need... packaging
> it seems odd.
Packaging gnulib is against gnulibs working principles. 

=> -1 from me on this package.

(In reply to Ralf Corsepius from comment #7)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> > It is nice to be able to use it without bundling in the sources:
> No. This is not the way gnulib is supposed to be used.
> gnulib files are supposed to be updated from git and the results to be
> bundled inside of a source-tree.
This is one of the approaches.

Another one is to update those sources regularly during development(gnulib-tool --update), and only release releases with a specific snapshot.

But even assuming that gnulib files are copied and kept in tree, as you say, there's a question how to best do that. During normal development of C code, if I'm about to gnulib-ify my project, it is much more continent to say 'yum install gnulib && gnulib-tool --import', than to say 'cd /var/tmp/ && git clone <some-address-I'll-have-to-look-up> && make -C gnulib && cd - && $OLDPWD/gnulib/gnulib-tool --import'. For the developer, keeping gnulib git tree updated is an additional chore, which is nicely solved by updating the gnulib snapshot through yum.

RE-review ::

1. Done
2. Done
3. Done
4. Done
5. Done
6. Done
7. Done
8. Done
9. Done
10. ??? Explain , make (all) isn't do any thing !
11. Done
12. Done

Ok guys : 

I need this package to build this one :)
https://bitbucket.org/sortsmill/sortsmill-tools

---------------------------

Uploading >>>

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131022.git25fb29a-2.oji.fc19.src.rpm

(In reply to Mosaab Alzoubi from comment #9)
> RE-review ::
> 
> 1. Done
> 2. Done
The URL should be the content of Source0, not in the comments.
Use:

Source0: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=snapshot;h=%{githead};sf=tgz;name=gnulib-25fb29a.tar.gz
Source1:			http://erislabs.net/gitweb/?p=gnulib.git;a=blob_plain;hb=HEAD;f=debian/manpages/check-module.1
Source2:			http://erislabs.net/gitweb/?p=gnulib.git;a=blob_plain;hb=HEAD;f=debian/manpages/gnulib-tool.1

> 3. Done
> 4. Done
> 5. Done
> 6. Done
> 7. Done
> 8. Done
> 9. Done
> 10. ??? Explain , make (all) isn't do any thing !
You call 'make info' and 'make html'. It should be:

'make %{?_smp_mflags} info html'

> 11. Done
> 12. Done

13. So, once docs have been built, there's no need to install the sources.
gnulib-doc should contain:
gnulib.info
gnulib.html

(and the main package should *not* have them).

14. README is useless, do not package it.

15. Also, all those chmod's are *not* necessary: some of those are executable files, and the permissions in the git archive on them are OK.

16. .gitattributes should also be removed.

> Ok guys : 
> 
> I need this package to build this one :)
> https://bitbucket.org/sortsmill/sortsmill-tools
Like Ralf pointed out implicitly, you don't really *need* to:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions
https://fedorahosted.org/fpc/ticket/174

I find https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git great for testing gnulib... With your current package, gnulib-tool --import seems to work, gnulib-tool --test too, so I think we're on the proper path here.

2. Done
10. Done
13. Done
14. Done
15. Done
16. Done

> https://fedorahosted.org/fpc/ticket/174

Removed

================

Building & Uploading >>>

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131022.git25fb29a-3.oji.fc19.src.rpm

(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> (In reply to Ralf Corsepius from comment #7)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> > > It is nice to be able to use it without bundling in the sources:
> > No. This is not the way gnulib is supposed to be used.
> > gnulib files are supposed to be updated from git and the results to be
> > bundled inside of a source-tree.
> This is one of the approaches.
No, please read http://www.gnu.org/software/gnulib/

Please carefully read the download section.

Packaging it and dynamically update a package is abusing gnulib.

May be we should leave the decision the upstream maintainers?

Although I personally use gnulib in lots of projects, I have never once wanted to use a distro's packaging of it.  On the other hand, I know that some people do want it in the distro, if only because Debian has attempted it with what originally started as a once-a-month effort but has lately been less frequent:
http://packages.debian.org/unstable/devel/gnulib

How does your packaging attempt compare to their attempt?  What release cadence are you planning to maintain?  An out-of-date gnulib package is less useful than just using gnulib from upstream.  I'm not opposed to the packaging as one of the upstream gnulib maintainers, but I don't see myself ever wanting to use it as a downstream Fedora developer.

Consider asking upstream to bundle gnulib or stop this review.

I don't build this package just for it, I need this package to build :

https://bitbucket.org/sortsmill/sortsmill-tools

Sorts Mill uses gnulib-tool at building time.

Sorts Mill necessary to build Amiri Fonts :

https://bugzilla.redhat.com/show_bug.cgi?id=1015701

Also I don't want to show Fedora poor of any tool may we use or need some day.

-----

So I hope to accept this Gnulib >
Regards

(In reply to Mosaab Alzoubi from comment #18)
> I don't build this package just for it, I need this package to build :
> 
> https://bitbucket.org/sortsmill/sortsmill-tools
> 
> Sorts Mill uses gnulib-tool at building time.

Upstream design flaw ;)

You probabably can work around this it by adding the missing files offline and to apply the generated files as a patch.

Created attachment 816430 [details]
updated spec file

=== packaging ===

I still see some minor issues:
- modules/COPYING should not be removed: it is very important because it gives a right to use the modules almost freely. 
- in a couple of places '-n %{name}-<subpackage>' is used, but '<subpackage>' suffices.
- MODULES.html can be packaged too.

I prepared an updated .spec file (attached) with those changes. 

=== the rest ===

> How does your packaging attempt compare to their attempt?  What release 
> cadence are you planning to maintain?  An out-of-date gnulib package is less 
> useful than just using gnulib from upstream.

That is a very good question. I think there's a place for gnulib in the distribution, but indeed, only if it is regularly updated. Mosaab, I'd be happy to co-maintain the package with you, to ensure that there's always somebody to prepare the update.

> Mosaab, I'd be happy to co-maintain the package with you, 

ME too :)

Updated ::

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131027.git5191b35-1.oji.fc19.src.rpm

Oops, I run fedora-review on this, and there still are issues:

1. "Bundled jar/class files should be removed before build"
There's lib/javaversion.class, which should be recompiled from sources.

%prep
...
rm libs/javaversion.class

%build
...
javac -d lib -source 1.3 -target 1.3 lib/javaversion.java

- Packages have proper BuildRequires/Requires on jpackage-utils
I think R:java-devel is enough.

2. Actually the -docs package also needs R: %{name} = %{version}-%{release}.

It used to be independent, but I missed that MODULES.html links to files in the base package, so it doesn't make sense to install it alone.

3. Licensing was not described properly according to https://fedoraproject.org/wiki/Packaging:LicensingGuidelines.

License: Public Domain and BSD and GPLv2+ and GPLv3 and GPLv3+ and LGPLv2 and LGPL2+ and LGPLv3+

No problem, all will be fixed.

* java-devel is enough
* Can we write (GPL2+) instead of (GPLv2+ and GPLv3 and GPLv3+) ?

License names are taken from https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Software_License_List. There's only GPLvX not GPLX in that list. And GPLv2+ means "GPL v2 or any later", GPLv3+ means "GPL v3 or any later", so they are not "additive".

Fixes after Zbigniew Jędrzejewski-Szmek revision:

- Remove prebuilt java class.
- gnulib-docs require gnulib.
- List all licenses.
- Replace define by global.

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131027.git5191b35-2.oji.fc19.src.rpm

Thank You.

Oops, more issues, but they're getting incrementally smaller:

1. rpmlint: Note: Directories without known owners: /usr/share/gnulib

2. Note: Macros in: gnulib-docs (description)
   Hm, this should be %{name}, not %{gnulib}. I think I added that by mistake.

3. Requires:java-headless must be added because of the java class

4. W: invalid-license LGPL2+

(In reply to Eric Blake from comment #16)
> Although I personally use gnulib in lots of projects, I have never once
> wanted to use a distro's packaging of it.

On the other hand, I would _welcome_ an independent packaging of gnulib's git-merge-changelog, rather than having to always build and locally install it myself to make use of it.  Are you planning on providing a pre-built git-merge-changelog as a subpackage?

I had no idea about git-merge-changelog. Looks very useful, and I think it should definitely be packaged in compiled form.

BTW. there's another reason for packaging gnulib: building MODULES.html takes >10 min, so it's nice to be able to easily install it for offline browsing.

ok 

>1. rpmlint: Note: Directories without known owners: /usr/share/gnulib
How to solve ?
>2. Note: Macros in: gnulib-docs (description)
>   Hm, this should be %{name}, not %{gnulib}. I think I added that by mistake.
Done
>3. Requires:java-headless must be added because of the java class
added.
>4. W: invalid-license LGPL2+
corrected.

> Are you planning on providing a pre-built git-merge-changelog as a subpackage?
Eric , I think if you write important modules for built as single packages, that's look nice.
Note new packages called ::
gnulib-%{module}

>I had no idea about git-merge-changelog. Looks very useful, and I think it
>should definitely be packaged in compiled form.

Zbigniew , It looks easy just must done before changing (dir) at gnulib-tool.

For git-merge-changelog just these command (from docs) :
gnulib-tool --create-testdir --dir=%{somedir} git-merge-changelog
cd %{somedir}
configure,make.....

:)

Regards

gnulib-tests is required for building modules, so added to Requires.

First Sample :

# Module Sample:
# %package %{module}
# Summary: %{summary_of_module}
# License: %{license_of_module}
#
# %build %{module}
# gnulib-build --create-testdir --dir=%{somedir} %{module}
# cd %{somedir}
# ./configure --prefix=/usr
# make %{?_smp_mflags}
#
# %install %{module}
# make install DESTDIR=%{buildroot}
# help2man -N --no-discard-stderr %{buildroot}%{_bindir}/%{module} > %{buildroot}%{_mandir}/man1/%{module}.1
#
# %files %{module}
# %{_bindir}/%{module}
# %{_mandir}/*/%{module}.*

Any ideas :)

* gnulib-build = copy of gnulib-tool before edited :)

(In reply to Mosaab Alzoubi from comment #31)
> ok 
> 
> >1. rpmlint: Note: Directories without known owners: /usr/share/gnulib
> How to solve ?
C'mon, just add /usr/share/gnulib to %files.

Actually, if the gnulib requires gnulib-tests, and gnulib-tests require gnulib, there's no point in keeping them separate, so gnulib-tests can go, and then %files is simplified, since everything under /usr/share/gnulib is owned by the main package.

> >2. Note: Macros in: gnulib-docs (description)
> >   Hm, this should be %{name}, not %{gnulib}. I think I added that by mistake.
> Done
> >3. Requires:java-headless must be added because of the java class
> added.
> >4. W: invalid-license LGPL2+
> corrected.
> 
> > Are you planning on providing a pre-built git-merge-changelog as a subpackage?
> Eric , I think if you write important modules for built as single packages,
> that's look nice.
Sorry, I can't parse that.

> Note new packages called ::
> gnulib-%{module}
Why not just 'git-merge-changelog'?
 
> >I had no idea about git-merge-changelog. Looks very useful, and I think it
> >should definitely be packaged in compiled form.
> 
> Zbigniew , It looks easy just must done before changing (dir) at gnulib-tool.
> 
> For git-merge-changelog just these command (from docs) :
> gnulib-tool --create-testdir --dir=%{somedir} git-merge-changelog
> cd %{somedir}
> configure,make.....
Right.

Maybe add to %build (only partially tested):
./gnulib-tool --create-testdir --dir=build-g-m-c git-merge-changelog
pushd build-g-m-c
%configure
make %{_smp_mflags} -C gllib git-merge-changelog
popd

Then there's the question if additional build requirements are needed. Maybe not, since gcc is guaranteed to be present.

(In reply to Mosaab Alzoubi from comment #34)
> * gnulib-build = copy of gnulib-tool before edited :)
I think there's no need to copy, I think. This can be done after the part which
creates MODULES.html.

> Why not just 'git-merge-changelog'? 
Because we working at (gnulib SRPM)
We can use ( Provides ) function.
> Then there's the question if additional build requirements are needed.
All gnulib R need to be BR to build any module package :)

--- Working now, I'll upload new package after built.

(In reply to Mosaab Alzoubi from comment #36)
> > Why not just 'git-merge-changelog'? 
> Because we working at (gnulib SRPM)
> We can use ( Provides ) function.
The subpackage can be called anything we want. E.g. kernel.srpm delivers (among many other) perf.rpm.

Some problem (I can't solve)

Main package (gnulib) is noarch.
New sub package (git-merge-changelog) arched.

========

Now I can't build and have this message :

error: line 153: Only noarch subpackages are supported: BuildArch: noarch noarch


========

Any ideas ?

It means:

"BuildArch: noarch" at the top of the spec file turns all packages built by the src.rpm "noarch", not only the base package. You cannot override that for individual subpackages then.

Also remember, "BuildArch: noarch" in a subpackage is only a compromise for an otherwise arch-specific build. It doesn't affect the build of _the src.rpm_ and its single %prep, %build, %install, … sections. It doesn't protect the packager from including arch-specific builds in a noarch subpackage by accident.

Ok Michael, Thank You.

Gnulib isn't arched, but if we want to build modules new subpackage must arched.

So I create -core subpackage still noarched and contain gnulib, and main package still as meta package.

Now it's built (takes alot of time) , after that I'll uplode it.

- Update to 20131030.git5c508f6
- Create -core noarch package, because rpmbuild can't drive arched subpackage from nonarched main one.
- Some General Fixes.
- Add 1st sample form - Module Sample: (Alpha Version)
- Add 1st module single package - git-merge-changelog


Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131030.git5c508f6-1.oji.fc19.src.rpm

Looks nice, apart from the %description, which is too long and too detailed.
Maybe something like this:
"git-merge-changelog is a git merge driver for changelogs that combines parallel additions to the changelog without generating merge conflicts. It can be enabled for specific files by setting appropriate git attributes."

- Decrease description of git-merge-changelog
- Add license file to git-merge-changelog


Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131030.git5c508f6-2.oji.fc19.src.rpm

Looks fine to me.

- After more 6 years in 0.0, GnuLib 0.1 released.
- Replace version method to $ver.git$gitdate instead of $gitdate.git$githead.
- Update to 0.1.git20131112.

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-0.1.git20131112-1.oji.fc19.src.rpm

Just a comment on this:

> SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-0.1.git20131112-1.oji.fc19.src.rpm

It looks very unusual to have "git20131112" as part of the %{version}. Since this is a snapshot from git, the following applies:

  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

And if the internal version really is 0.1, you need to decide on whether it's a pre-release or post-release snapshot:

  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_packages

With 0.1.git2013112 in %version, you could not upgrade to 0.1 final, for example:

  $ rpmdev-vercmp 0.1.git20131112 0.1
  0.1.git20131112 > 0.1

With the versioning guidelines applied, the package will look like:

  gnulib-0.1-0.X.20131112git.fc19.src.rpm

with X being the release number you would increase for ordinary packaging changes (including rebuilds or newer/older snapshots).

(In reply to Mosaab Alzoubi from comment #45)
> - After more 6 years in 0.0, GnuLib 0.1 released.
> - Replace version method to $ver.git$gitdate instead of $gitdate.git$githead.
> - Update to 0.1.git20131112.
> 
> Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
> SRPM URL:
> http://ojuba.org/oji/SRPMS/gnulib-0.1.git20131112-1.oji.fc19.src.rpm

Gnulib v0.1 is a non-release event.  It has no significance other than to reduce the count of patches since the last tag to be fewer than 1000.

https://lists.gnu.org/archive/html/bug-gnulib/2013-10/msg00118.html

Upstream gnulib has no intention of making a formal release.

Then

  Version: 0
  Release: X.YYYYMMDDgit%{?dist}

would be good enough, since 0.X at the beginning of Release would not make an important difference.

What about this tag?
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=233419c39c6d13d84439b95766328a238ffb6518

(In reply to Mosaab Alzoubi from comment #49)
> What about this tag?
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;
> h=233419c39c6d13d84439b95766328a238ffb6518

What about it? Per comment 47, it has no purpose other than to stop gnulib from having more than 999 commits since the last non-release tag.  That particular commit carries no more significance upstream than any other commit.

OK, I read your first comment, but I see if the upstream taged that as 0.1, then why we defer?

Building take alot of time, so what finally method for last SRPM:

gnulib-0.1-0.2.20131112git.fc19.src.rpm

OR

gnulib-0-2.20131112git.fc19.src.rpm

???

If the "0.1" is not used anywhere in the code, and if it's true that it is not some form of "release version", then the 0.1 is meaningless for the Fedora RPM package. All that matters in that case would be the %{checkout} value as per
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

So,  gnulib-0-2.20131112git.fc19.src.rpm  is the way to go.

OK. All Done:

----------------------

Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-0-2.20131112git.oji.fc19.src.rpm

Update:
-------
Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-0-3.20131201git.oji.fc19.src.rpm

Created attachment 915825 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Thanx Alot Zbigniew, I know how much time you spent for building package and doing this review, Thank You.

0-4.20131219git
- Update.
- General tweaks.
- Remove META main package.
- Rename -core into -devel.
- Remove main package from other packages requires.
- -docs requires -devel.
- Move main requires to -devel ones.
- -devel provides main package.
- Remove un-need-to-list-BRs diffutils make coreutils patch.
- United path for documents for all packages.

-------
Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-0-4.20131219git.oji.fc19.src.rpm

Nice! All issues noted above are fixed, and even rpmlint is almost happy.

Rpmlint
-------
Checking: gnulib-docs-0-4.20131219git.fc20.noarch.rpm
          gnulib-devel-0-4.20131219git.fc20.noarch.rpm
          git-merge-changelog-0-4.20131219git.fc20.x86_64.rpm
          gnulib-0-4.20131219git.fc20.src.rpm
gnulib-docs.noarch: E: devel-dependency gnulib-devel
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/gitlog-to-changelog
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/prefix-gnulib-mk
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/update-copyright
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/announce-gen
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/tests/test-posix_spawn2.in.sh 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/ldd.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/useless-if-before-free
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/lib/config.charset 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/x-to-1.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/javaexec.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/csharpexec.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/csharpcomp.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/javacomp.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/tests/test-posix_spawn1.in.sh 0644L /bin/sh
gnulib-devel.noarch: W: file-not-in-%lang /usr/share/gnulib/tests/locale/fr/LC_MESSAGES/test-quotearg.mo

Those are tests and build scripts, so normal rules don't apply.

git-merge-changelog.x86_64: W: spelling-error %description -l en_US changelogs -> change logs, change-logs, changelings
gnulib.src: W: strange-permission gnulib-0ac90c5.tar.gz 0640L
That's a bit strange, but git doesn't store permissions, so when the package is imported this should go away.

gnulib.src:5: W: macro-in-comment %name
gnulib.src:7: W: macro-in-comment %{moduleX}
gnulib.src:8: W: macro-in-comment %{summary_of_moduleX}
gnulib.src:9: W: macro-in-comment %{license_of_moduleX}
gnulib.src:11: W: macro-in-comment %{moduleX}
gnulib.src:12: W: macro-in-comment %description
gnulib.src:15: W: macro-in-comment %{moduleX}
gnulib.src:15: W: macro-in-comment %{moduleX}
gnulib.src:18: W: macro-in-comment %{moduleX}
gnulib.src:19: W: macro-in-comment %_prefix
gnulib.src:24: W: macro-in-comment %{moduleX}
gnulib.src:25: W: macro-in-comment %{buildroot}
gnulib.src:27: W: macro-in-comment %{buildroot}
gnulib.src:27: W: macro-in-comment %{_bindir}
gnulib.src:27: W: macro-in-comment %{moduleX}
gnulib.src:27: W: macro-in-comment %{buildroot}
gnulib.src:27: W: macro-in-comment %{_mandir}
gnulib.src:27: W: macro-in-comment %{moduleX}
gnulib.src:29: W: macro-in-comment %{moduleX}
gnulib.src:30: W: macro-in-comment %{_bindir}
gnulib.src:30: W: macro-in-comment %{moduleX}
gnulib.src:31: W: macro-in-comment %{_mandir}
gnulib.src:31: W: macro-in-comment %{moduleX}
OK.

gnulib.src:149: W: unversioned-explicit-provides gnulib

Ooops, I think I suggested this, and it should be
Provides: gnulib = %{version}-%{release}

4 packages and 0 specfiles checked; 15 errors, 27 warnings.


Rpmlint (installed packages)
----------------------------
# rpmlint gnulib-devel gnulib-docs git-merge-changelog
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/gitlog-to-changelog
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/prefix-gnulib-mk
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/update-copyright
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/announce-gen
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/tests/test-posix_spawn2.in.sh 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/ldd.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: script-without-shebang /usr/share/gnulib/build-aux/useless-if-before-free
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/lib/config.charset 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/x-to-1.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/javaexec.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/csharpexec.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/csharpcomp.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/build-aux/javacomp.sh.in 0644L /bin/sh
gnulib-devel.noarch: E: non-executable-script /usr/share/gnulib/tests/test-posix_spawn1.in.sh 0644L /bin/sh
gnulib-devel.noarch: W: file-not-in-%lang /usr/share/gnulib/tests/locale/fr/LC_MESSAGES/test-quotearg.mo
gnulib-docs.noarch: E: devel-dependency gnulib-devel
git-merge-changelog.x86_64: W: spelling-error %description -l en_US changelogs -> change logs, change-logs, changelings
3 packages and 0 specfiles checked; 15 errors, 2 warnings.
# echo 'rpmlint-done:'

All OK.

Requires
--------
gnulib-devel (rpmlib, GLIBC filtered):
    /bin/sh
    /usr/bin/perl
    bison
    coreutils
    diffutils
    gettext-devel
    gperf
    libtool
    make
    patch
    perl(Digest::MD5)
    perl(File::Basename)
    perl(File::Find)
    perl(Getopt::Long)
    perl(IO::File)
    perl(POSIX)
    perl(constant)
    perl(strict)
    perl(warnings)
    texinfo

gnulib-docs (rpmlib, GLIBC filtered):
    /bin/sh
    gnulib-devel
    info

git-merge-changelog (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    rtld(GNU_HASH)

Provides
--------
gnulib-devel:
    gnulib
    gnulib-devel

gnulib-docs:
    gnulib-docs

git-merge-changelog:
    git-merge-changelog
    git-merge-changelog(x86-64)



AutoTools: Obsoleted m4s found
------------------------------
  AM_PROG_LIBTOOL found in: gnulib-
  0ac90c5/tests/havelib/rpathy/configure.ac:23, gnulib-
  0ac90c5/tests/havelib/rpathz/configure.ac:23, gnulib-
  0ac90c5/tests/havelib/rpathx/configure.ac:23

Package is APPROVED.

There's one issue with Provides noted above, but there's no need to upload another version, it can be fixed in the package.

Thank You ^_^

New Package SCM Request
=======================
Package Name: gnulib
Short Description: GNU Portability Library
Owners: moceap zbyszek
Branches: f19 f20

Git done (by process-git-requests).

gnulib-0-4.20131219git.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gnulib-0-4.20131219git.fc20

gnulib-0-4.20131219git.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gnulib-0-4.20131219git.fc19

gnulib-0-4.20131219git.fc20 has been pushed to the Fedora 20 stable repository.

gnulib-0-4.20131219git.fc19 has been pushed to the Fedora 19 stable repository.

Package Change Request
======================
Package Name: gnulib
New Branches: epel7
Owners: moceap zbyszek

Requested in #1138377 .

Git done (by process-git-requests).

I'll do SOON ^_^

remove the GNULIB alias to be able to search fo the bugs related to this package