Bug 1022283 - (GNULIB) Review Request: gnulib - GNU Portability Library
Review Request: gnulib - GNU Portability Library
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-22 18:55 EDT by Mosaab Alzoubi
Modified: 2014-09-13 06:44 EDT (History)
9 users (show)

See Also:
Fixed In Version: gnulib-0-4.20131219git.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-22 00:39:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
zbyszek: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
updated spec file (3.65 KB, text/plain)
2013-10-26 14:08 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details
Comment (361.75 KB, text/plain)
2013-12-17 14:09 EST, Zbigniew Jędrzejewski-Szmek
no flags Details

  None (edit)
Description Mosaab Alzoubi 2013-10-22 18:55:44 EDT
Spec URL: http://ojuba.org/oji/SPECS/gnulib.spec
SRPM URL: http://ojuba.org/oji/SRPMS/gnulib-20131022.git25fb29a-1.oji.fc19.src.rpm
Description: 

The GNU portability library is a macro system and C declarations and
definitions for commonly-used API elements and abstracted system behaviors.
It can be used to improve portability and other functionality in your programs.

Fedora Account System Username: moceap
Comment 1 Parag AN(पराग) 2013-10-23 01:50:53 EDT
you should not change flag fedora-review to ? , it should be done by the official package reviewer for this package.
Comment 2 Mosaab Alzoubi 2013-10-23 03:50:17 EDT
Removed :)
Comment 3 Zbigniew Jędrzejewski-Szmek 2013-10-23 16:05:29 EDT
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.
Comment 4 Kevin Fenzi 2013-10-23 16:09:58 EDT
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.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-10-23 16:13:34 EDT
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.
Comment 6 Kevin Fenzi 2013-10-23 16:19:31 EDT
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.
Comment 7 Ralf Corsepius 2013-10-24 03:03:13 EDT
(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.
Comment 8 Zbigniew Jędrzejewski-Szmek 2013-10-24 10:14:06 EDT
(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.
Comment 9 Mosaab Alzoubi 2013-10-24 13:40:42 EDT
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 >>>
Comment 11 Zbigniew Jędrzejewski-Szmek 2013-10-24 16:16:46 EDT
(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.
Comment 12 Mosaab Alzoubi 2013-10-24 16:53:51 EDT
2. Done
10. Done
13. Done
14. Done
15. Done
16. Done

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

Removed

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

Building & Uploading >>>
Comment 14 Ralf Corsepius 2013-10-24 18:15:49 EDT
(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.
Comment 15 Ralf Corsepius 2013-10-24 18:20:32 EDT
May be we should leave the decision the upstream maintainers?
Comment 16 Eric Blake 2013-10-24 23:16:21 EDT
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.
Comment 17 Christopher Meng 2013-10-24 23:30:52 EDT
Consider asking upstream to bundle gnulib or stop this review.
Comment 18 Mosaab Alzoubi 2013-10-25 07:44:57 EDT
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
Comment 19 Ralf Corsepius 2013-10-25 10:23:07 EDT
(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.
Comment 20 Zbigniew Jędrzejewski-Szmek 2013-10-26 14:08:39 EDT
Created attachment 816430 [details]
updated spec file
Comment 21 Zbigniew Jędrzejewski-Szmek 2013-10-26 14:09:03 EDT
=== 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.
Comment 22 Mosaab Alzoubi 2013-10-26 18:14:49 EDT
> Mosaab, I'd be happy to co-maintain the package with you, 

ME too :)
Comment 24 Zbigniew Jędrzejewski-Szmek 2013-10-27 11:50:47 EDT
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+
Comment 25 Mosaab Alzoubi 2013-10-27 16:39:16 EDT
No problem, all will be fixed.

* java-devel is enough
* Can we write (GPL2+) instead of (GPLv2+ and GPLv3 and GPLv3+) ?
Comment 26 Zbigniew Jędrzejewski-Szmek 2013-10-27 21:14:32 EDT
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".
Comment 27 Mosaab Alzoubi 2013-10-28 03:00:49 EDT
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.
Comment 28 Zbigniew Jędrzejewski-Szmek 2013-10-28 18:09:11 EDT
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+
Comment 29 Eric Blake 2013-10-28 18:14:43 EDT
(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?
Comment 30 Zbigniew Jędrzejewski-Szmek 2013-10-28 18:58:11 EDT
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.
Comment 31 Mosaab Alzoubi 2013-10-29 02:30:51 EDT
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
Comment 32 Mosaab Alzoubi 2013-10-29 03:25:00 EDT
gnulib-tests is required for building modules, so added to Requires.
Comment 33 Mosaab Alzoubi 2013-10-29 10:55:43 EDT
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 :)
Comment 34 Mosaab Alzoubi 2013-10-29 10:56:43 EDT
* gnulib-build = copy of gnulib-tool before edited :)
Comment 35 Zbigniew Jędrzejewski-Szmek 2013-10-29 12:39:27 EDT
(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.
Comment 36 Mosaab Alzoubi 2013-10-29 14:20:48 EDT
> 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.
Comment 37 Zbigniew Jędrzejewski-Szmek 2013-10-29 14:53:37 EDT
(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.
Comment 38 Mosaab Alzoubi 2013-10-29 18:58:10 EDT
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 ?
Comment 39 Michael Schwendt 2013-10-30 04:34:42 EDT
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.
Comment 40 Mosaab Alzoubi 2013-10-30 05:17:56 EDT
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.
Comment 41 Mosaab Alzoubi 2013-10-30 11:36:40 EDT
- 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
Comment 42 Zbigniew Jędrzejewski-Szmek 2013-10-30 18:57:35 EDT
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."
Comment 43 Mosaab Alzoubi 2013-10-31 20:05:22 EDT
- 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
Comment 44 Zbigniew Jędrzejewski-Szmek 2013-11-01 16:43:54 EDT
Looks fine to me.
Comment 45 Mosaab Alzoubi 2013-11-12 18:31:21 EST
- 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
Comment 46 Michael Schwendt 2013-11-13 05:45:20 EST
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).
Comment 47 Eric Blake 2013-11-13 08:45:55 EST
(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.
Comment 48 Michael Schwendt 2013-11-13 10:19:23 EST
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.
Comment 50 Eric Blake 2013-11-13 12:45:41 EST
(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.
Comment 51 Mosaab Alzoubi 2013-11-13 13:38:16 EST
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

???
Comment 52 Michael Schwendt 2013-11-13 15:03:26 EST
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.
Comment 53 Mosaab Alzoubi 2013-11-14 04:39:30 EST
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
Comment 54 Mosaab Alzoubi 2013-12-01 22:46:26 EST
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
Comment 55 Zbigniew Jędrzejewski-Szmek 2013-12-17 14:09:04 EST
Created attachment 915825 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 56 Mosaab Alzoubi 2013-12-19 14:29:26 EST
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
Comment 57 Zbigniew Jędrzejewski-Szmek 2013-12-19 15:40:07 EST
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.
Comment 58 Mosaab Alzoubi 2013-12-20 00:45:42 EST
Thank You ^_^

New Package SCM Request
=======================
Package Name: gnulib
Short Description: GNU Portability Library
Owners: moceap zbyszek
Branches: f19 f20
Comment 59 Jon Ciesla 2013-12-20 07:45:43 EST
Git done (by process-git-requests).
Comment 60 Fedora Update System 2013-12-20 14:00:57 EST
gnulib-0-4.20131219git.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gnulib-0-4.20131219git.fc20
Comment 61 Fedora Update System 2013-12-20 14:03:02 EST
gnulib-0-4.20131219git.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gnulib-0-4.20131219git.fc19
Comment 62 Fedora Update System 2013-12-22 00:39:53 EST
gnulib-0-4.20131219git.fc20 has been pushed to the Fedora 20 stable repository.
Comment 63 Fedora Update System 2013-12-30 20:59:42 EST
gnulib-0-4.20131219git.fc19 has been pushed to the Fedora 19 stable repository.
Comment 64 Zbigniew Jędrzejewski-Szmek 2014-09-06 21:12:54 EDT
Package Change Request
======================
Package Name: gnulib
New Branches: epel7
Owners: moceap zbyszek

Requested in #1138377 .
Comment 65 Jon Ciesla 2014-09-08 07:56:36 EDT
Git done (by process-git-requests).
Comment 66 Mosaab Alzoubi 2014-09-13 06:44:44 EDT
I'll do SOON ^_^

Note You need to log in before you can comment on or make changes to this bug.