Bug 563598 - Review Request: sugar-settings-manager - Settings manager for the Sugar environment
Review Request: sugar-settings-manager - Settings manager for the Sugar envir...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: SOAS-3
  Show dependency treegraph
 
Reported: 2010-02-10 11:59 EST by Sebastian Dziallas
Modified: 2010-06-11 00:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-01 14:25:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
bochecha: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Sebastian Dziallas 2010-02-10 11:59:17 EST
Spec URL: http://sdz.fedorapeople.org/rpmbuild/sugar-settings-manager.spec
SRPM URL: http://sdz.fedorapeople.org/rpmbuild/sugar-settings-manager-0.87.2-1.fc12.src.rpm

Koji Scratch Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1974866
Description: This is a dependency from the Sugar packaging effort.
Comment 1 Mathieu Bridon 2010-02-12 16:10:44 EST
The source archive bundles:
- xsettings-common.{c,h}
- xsettings-manager.{c,h}

Those four files can also be found in the xsettings-kde source rpm.

Is it intentional that those files are copied in both RPMs?
Comment 2 Sebastian Dziallas 2010-02-12 16:26:21 EST
...and so does gnome-settings-daemon, I just figured. :)

I guess almost every xsettings-relying application (I didn't check the Xfce daemon, but could very well imagine to find it there, too) has these four somewhere. I've found a cvs repository at freedesktop.org, too.

How do we proceed here?
Comment 3 Mathieu Bridon 2010-02-14 06:30:16 EST
The licence says « MIT », which is confirmed by the « COPYING » file and the source file headers.

However, there are two scripts (« missing » and « depcomp ») that are licensed under the GPLv2+.

Shouldn't the license field be « MIT and GPLv2+ » instead?

I'm blocking FE-Legal on this as I'm not sure, meanwhile I'll go on with the rest of the review.
Comment 4 Sebastian Dziallas 2010-02-14 06:43:40 EST
Both of these two files in question seem to contain this note, so sticking with MIT should be fitting, no?

# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.
Comment 5 Mathieu Bridon 2010-02-14 06:47:52 EST
(In reply to comment #4)
> Both of these two files in question seem to contain this note, so sticking with
> MIT should be fitting, no?
> 
> # As a special exception to the GNU General Public License, if you
> # distribute this file as part of a program that contains a
> # configuration script generated by Autoconf, you may include it under
> # the same distribution terms that you use for the rest of that program.    

You're right, I hadn't seen this notice :-/

Sorry about the confusion, unblocking FE-Legal.

+:ok, =:needs attention, -:needs fixing

MUST Items:
[+] MUST: rpmlint must be run on every package.
$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/sugar-settings-manager-*
3 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint SPECS/sugar-settings-manager.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[+] MUST: The package must be named according to the Package Naming Guidelines.
[+] MUST: The spec file name must match the base package %{name}
[+] MUST: The package must be licensed with a Fedora approved license and meet
the Licensing Guidelines.
  => MIT

[+] MUST: The License field in the package spec file must match the actual
license.
[+] MUST: 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 must be included in %doc.
[+] MUST: The spec file must be written in American English.
[+] MUST: The spec file for the package MUST be legible.
[+] MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL.
$ sha1sum sugar-settings-manager-0.87.2.tar.gz 
7d0ce6b2dbffbb1b83f5ce4971c38b448dbb46fa  sugar-settings-manager-0.87.2.tar.gz
$ sha1sum SOURCES/sugar-settings-manager-0.87.2.tar.gz 
7d0ce6b2dbffbb1b83f5ce4971c38b448dbb46fa  SOURCES/sugar-settings-manager-0.87.2.tar.gz

[+] MUST: The package must successfully compile and build into binary rpms on
at least one supported architecture.
[+] MUST: All build dependencies must be listed in BuildRequires
[+] MUST: Every binary RPM package which stores shared library files (not just
symlinks) in any of the dynamic linker's default paths, must call ldconfig in
%post and %postun.
  => not applicable

[+] MUST: A package must own all directories that it creates. If it does not
create a directory that it uses, then it should require a package which does
create that directory.
[+] MUST: A package must not contain any duplicate files in the %files listing.
[+] MUST: Permissions on files must be set properly. Executables should be set
with executable permissions, for example. Every %files section must include a
%defattr(...) line.
[+] MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: Each package must consistently use macros, as described in the macros
section of Packaging Guidelines.
[+] MUST: The package must contain code, or permissible content. This is
described in detail in the code vs. content section of Packaging Guidelines.
[+] MUST: If a package includes something as %doc, it must not affect the
runtime of the application.
[+] MUST: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
[+] MUST: Packages containing GUI applications must include a %{name}.desktop
file, and that file must be properly installed with desktop-file-install in the
%install section.
  => not applicable

[+] MUST: Packages must not own files or directories already owned by other
packages.
[+] MUST: At the beginning of %install, each package MUST run rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: All filenames in rpm packages must be valid UTF-8.

SHOULD Items:
[+] SHOULD: The reviewer should test that the package builds in mock.
[+] SHOULD: The package should compile and build into binary rpms on all
supported architectures.
  => I rebuilt it in Koji to be 100% sure the DSO link change didn't affect the package:
  => http://koji.fedoraproject.org/koji/taskinfo?taskID=1985386
  
This package is APPROVED.
Comment 6 Mathieu Bridon 2010-02-14 06:50:21 EST
(In reply to comment #2)
> ...and so does gnome-settings-daemon, I just figured. :)
> 
> I guess almost every xsettings-relying application (I didn't check the Xfce
> daemon, but could very well imagine to find it there, too) has these four
> somewhere. I've found a cvs repository at freedesktop.org, too.
> 
> How do we proceed here?    

I forgot to comment on this one. Rdieter (maintaining xsettings-kde) on IRC confirmed it was normal to include those 2 files.
Comment 7 Sebastian Dziallas 2010-02-14 07:02:07 EST
New Package CVS Request
=======================
Package Name: sugar-settings-manager
Short Description: Settings manager for the Sugar environment
Owners: sdz bochecha
Comment 8 Kevin Fenzi 2010-02-15 22:52:36 EST
CVS done (by process-cvs-requests.py).

(Remember to assign package reviews to the reviewer)
Comment 9 Sebastian Dziallas 2010-03-01 14:25:05 EST
And this one is in, too - thanks!
Comment 10 Peter Robinson 2010-06-10 16:50:24 EDT
Package Change Request
======================
Package Name: sugar-settings-manager
New Branches: EL-6
Owners: pbrobinson sdz
Comment 11 Kevin Fenzi 2010-06-11 00:49:03 EDT
cvs done.

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