Bug 989847 - Review Request: mingw-plibc - MinGW package for plibc
Review Request: mingw-plibc - MinGW package for plibc
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Erik van Pienbroek
Fedora Extras Quality Assurance
Depends On:
Blocks: 989850
  Show dependency treegraph
Reported: 2013-07-30 00:22 EDT by Michael Cronenworth
Modified: 2014-05-16 10:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-05-16 10:06:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
erik-fedora: fedora‑review+
limburgher: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Michael Cronenworth 2013-07-30 00:22:39 EDT
Spec URL: http://michael.cronenworth.com/RPMS/mingw-plibc.spec
SRPM URL: http://michael.cronenworth.com/RPMS/mingw-plibc-0.1.7-1.0.20130513svn.fc19.src.rpm
Description: plibc - POSIX compliant libc extension for Windows
Fedora Account System Username: mooninite
Comment 1 Kevin Kofler 2013-07-31 18:07:02 EDT
This thing contains the printf and scanf implementation from the GPLv2 dietlibc, with a LGPL license header stuck on it. Considering http://www.fefe.de/nowindows/ , I have strong doubts that the author approved the relicensing.
Comment 2 Erik van Pienbroek 2013-08-01 12:37:48 EDT
I'm afraid Kevin's observation is correct. The printf.c in plibc does contain traces of dietlibc code. This can also be seen in the comments at the beginning of http://plibc.svn.sourceforge.net/viewvc/plibc/trunk/plibc/src/printf.c?revision=139&view=markup which contain this comment:

/* Stolen from Felix von Leitners "diet libc" 0.28 */

I didn't check the scanf.c in plibc but I guess the same also applies there.

This looks like a licensing violation by plibc as it contains pieces of code from dietlibc which is GPLv2 while the plibc library itself is LGPLv2+. Before we can allow this package in Fedora the offending code has to be removed upstream.
Comment 3 Michael Cronenworth 2013-08-30 21:04:43 EDT
Upstream has removed the violating code.

New spec: http://michael.cronenworth.com/RPMS/mingw-plibc.spec
New SRPM: http://michael.cronenworth.com/RPMS/mingw-plibc-0.1.7-1.0.20130812svn.fc19.src.rpm
Comment 4 František Dvořák 2013-11-02 19:47:38 EDT
Several comments to the packaging:

* missing build dependency on automake - mock complains "Can't exec "aclocal": No such file or directory"

* it would be better to replace the "mv COPYING ../" command in %install by:
 - something like "cp -p plibc/COPYING ." in %prep
 - or using plibc/COPYING in %doc directly?

* it seems sourceforge has some problems with the snapshot URL, maybe there could be added comment how to obtain the given version? Something like:
# svn checkout -r 147 svn://svn.code.sf.net/p/plibc/code/trunk plibc-code-147-trunk

* you can use %{summary} in the subpackages (just a tip, it is not needed :-))

* if I'm not mistaken, the release version could be simplified to "1.20130812svn%{?dist}", but there is no technical problem with the current scheme "1.0.20130812svn%{?dist}" (http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_packages)
Comment 5 Erik van Pienbroek 2013-11-17 11:39:31 EST
Hey Michael,

My apologies for the late response. Been too busy with other stuff recently..
But let's continue with the review

* rpmlint complains that the download url (to the svn snapshot) isn't
  available any more. Apparently SourceForge automatically purges
  (generated) svn snapshots from time to time..
  As upstream hasn't done any new releases recently I think it would
  be better to add an additional comment to the spec file to indicate
  how the tarball can be reproduced. For inspiration, see the comment in
* When packaging SVN snapshots I personally find it more convenient
  when the revision number is also mentioned in the release tag (along
  with the snapshot date), so that for example you end up with
  Release: 1.0.svn20130812.r147%{?dist}
  I leave it up to you whether to use this convention or not
* As mentioned by František above, the package doesn't build on mock
  due to a missing dependency on automake
* The BuildRequires: mingw32-binutils mingw64-binutils is redundant (as they're
  already pulled in by mingw32-gcc and mingw64-gcc) so they can be removed
* The 'cd plibc/' and 'mv COPYING ../' steps can be eliminated with these small changes:

--- mingw-plibc.spec.orig	2013-11-17 17:36:24.980268511 +0100
+++ mingw-plibc.spec	2013-11-17 17:36:33.772418619 +0100
@@ -48,21 +48,18 @@
-%setup -q -n plibc-code-147-trunk
-%patch100 -p1 -b .mingw-include
+%setup -q -n plibc-code-147-trunk/plibc
+%patch100 -p2 -b .mingw-include
-cd plibc/
 sh ./bootstrap
 %mingw_make %{?_smp_mflags}
-cd plibc/
 %mingw_make_install DESTDIR=$RPM_BUILD_ROOT
-mv COPYING ../
 # Drop all .la files
Comment 6 Kevin Kofler 2013-11-29 18:09:29 EST
> Release: 1.0.svn20130812.r147%{?dist}

Actually, the packaging guidelines say to use 20130812svn147, not svn20130812.r147.
Comment 8 Erik van Pienbroek 2014-02-09 10:30:14 EST
$ rpmlint mingw-plibc.spec
mingw-plibc.spec:13: W: macro-in-comment %{snapshot_rev}
mingw-plibc.spec: W: invalid-url Source0: plibc-code-147-trunk.zip
0 packages and 1 specfiles checked; 0 errors, 2 warnings.

$ rpmlint mingw-plibc-0.1.7-0.2.20130812svn147.fc20.src.rpm 
mingw-plibc.src: W: spelling-error %description -l en_US libc -> lib, lib c
mingw-plibc.src:13: W: macro-in-comment %{snapshot_rev}
mingw-plibc.src: W: invalid-url Source0: plibc-code-147-trunk.zip
1 packages and 0 specfiles checked; 0 errors, 3 warnings

$ rpmlint mingw32-plibc-0.1.7-0.2.20130812svn147.fc20.noarch.rpm mingw64-plibc-0.1.7-0.2.20130812svn147.fc20.noarch.rpm 
mingw32-plibc.noarch: W: spelling-error %description -l en_US libc -> lib, lib c
mingw32-plibc.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/mingw32-plibc/COPYING
mingw32-plibc.noarch: E: incorrect-fsf-address /usr/share/doc/mingw32-plibc/COPYING
mingw32-plibc.noarch: E: incorrect-fsf-address /usr/i686-w64-mingw32/sys-root/mingw/include/plibc.h
mingw32-plibc.noarch: E: incorrect-fsf-address /usr/i686-w64-mingw32/sys-root/mingw/include/langinfo.h
mingw64-plibc.noarch: W: spelling-error %description -l en_US libc -> lib, lib c
mingw64-plibc.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/mingw64-plibc/COPYING
mingw64-plibc.noarch: E: incorrect-fsf-address /usr/share/doc/mingw64-plibc/COPYING
mingw64-plibc.noarch: E: incorrect-fsf-address /usr/x86_64-w64-mingw32/sys-root/mingw/include/plibc.h
mingw64-plibc.noarch: E: incorrect-fsf-address /usr/x86_64-w64-mingw32/sys-root/mingw/include/langinfo.h
2 packages and 0 specfiles checked; 6 errors, 4 warnings.

$ rpm --query --requires mingw32-plibc
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
mingw32-filesystem >= 95
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw64-plibc
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
mingw64-filesystem >= 95
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw32-libmicrohttpd-static
mingw32-libmicrohttpd = 0.9.33-1.fc20
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw64-libmicrohttpd-static
mingw64-libmicrohttpd = 0.9.33-1.fc20
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --provides mingw32-plibc
mingw32-plibc = 0.1.7-0.2.20130812svn147.fc20

$ rpm --query --provides mingw64-plibc
mingw64-plibc = 0.1.7-0.2.20130812svn147.fc20

+ OK
! Needs to be looked into
/ Not applicable

[!] Compliant with generic Fedora Packaging Guidelines
[+] Source package name is prefixed with 'mingw-'
[+] Spec file starts with %{?mingw_package_header}
[+] BuildRequires: mingw32-filesystem >= 95 is in the .spec file
[+] BuildRequires: mingw64-filesystem >= 95 is in the .spec file
[+] Spec file contains %package sections for both mingw32 and mingw64 packages
[+] Binary mingw32 and mingw64 packages are noarch
[+] Spec file contains %{?mingw_debug_package} after the %description section
[+] Uses one of the macros %mingw_configure, %mingw_cmake, or %mingw_cmake_kde4
    to configure the package
[+] Uses the macro %mingw_make to build the package
[+] Uses the macro %mingw_make to install the package
[/] If package contains translations, the %mingw_find_lang macro must be used
[+] No binary package named mingw-$pkgname is generated
[+] Libtool .la files are not bundled
[+] .def files are not bundled
[+] Man pages which duplicate native package are not bundled
[+] Info files which duplicate native package are not bundled
[+] Provides of the binary mingw32 and mingw64 packages are equal
[!] Requires of the binary mingw32 and mingw64 packages are equal

The invalid-url rpmlint warning can be ignored as you're using a SVN checkout
The spelling rpmlint warnings can also be ignored
The wrong-file-end-of-line-encoding and incorrect-fsf-address rpmlint warnings
should be reported upstream, but they're not blocking for this review

The mingw32 package seems to depend on libgcc_s_sjlj-1.dll while the mingw64
package doesn't. I've also seen this on various other packages so we can
ignore this for now

 The package mingw-plibc is APPROVED by epienbro
Comment 9 Michael Cronenworth 2014-02-09 15:51:29 EST
New Package SCM Request
Package Name: mingw-plibc
Short Description: MinGW package for plibc
Owners: mooninite
Branches: f20
Comment 10 Gwyn Ciesla 2014-02-10 08:23:18 EST
Git done (by process-git-requests).
Comment 11 Erik van Pienbroek 2014-05-16 10:06:40 EDT
Package is in Fedora 20 and rawhide. Closing review request

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