Bug 752169

I will the review the package, but someone else needs to sponsor you.

Some initial comments.

Use 3.2 as version, because this is a gnome-3.2 theme
No need to add the deviantart tag id in release.

no need to require on gnome-tweak-tool, it is not a hard requirement.

Maybe splitting the gnome-shell theme and the gtk themes into separate sub packages would be a good idea.
You should be able to use the gnome-shell theme without the gtk themes

Let me know what you think

(In reply to comment #1)
> I will the review the package, but someone else needs to sponsor you.


Thank you very much!
 

> Some initial comments.
> 
> Use 3.2 as version, because this is a gnome-3.2 theme
> No need to add the deviantart tag id in release.
> 
> no need to require on gnome-tweak-tool, it is not a hard requirement.


Done.
 

> Maybe splitting the gnome-shell theme and the gtk themes into separate sub
> packages would be a good idea.
> You should be able to use the gnome-shell theme without the gtk themes
> 
> Let me know what you think


In my opinion, having an only package would be better, because
* the GTK themes and the Gnome Shell theme have been created explicitly to be used together;
* anyway, one can still choose to apply the GTK themes or the Gnome Shell theme alone through Gnome Tweak Tool, if he prefers.
But this is only a beginner's point of view. If other reasons exist to prefer creating separate subpackages, please let me know.

Here are the new spec and SRPM:

Spec URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_2/gnome-shell-theme-zukitwo.spec

SRPM URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_2/gnome-shell-theme-zukitwo-3.2-1.fc16.src.rpm

Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported architecture.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[x]: 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 is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package meets the Packaging Guidelines.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generates any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint output is silent.

rpmlint gnome-shell-theme-zukitwo-3.2-1.fc17.src.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


rpmlint gnome-shell-theme-zukitwo-3.2-1.fc17.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/tim/udv/work/FedoraReview/src/752169/zukitwo_by_lassekongo83-d3df2ot.zip :
  MD5SUM this package     : 9b03ca87116cf368de5a94b9573a3fd1
  MD5SUM upstream package : 9b03ca87116cf368de5a94b9573a3fd1

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[x]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: SHOULD Package functions as described.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD SourceX is a working URL.
[!]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[-]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

APPROVED

You should add something to description about the package also is containing gtk-themes and not just a shell theme

I've just updated the package to the 2011.12.05 version of the theme:

Spec URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_3/gnome-shell-theme-zukitwo.spec

SRPM URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_3/gnome-shell-theme-zukitwo-3.2-2.fc16.src.rpm

(In reply to comment #4)

> You should add something to description about the package also is containing
> gtk-themes and not just a shell theme

Done in the latest version of the package (see Comment 5).

(In reply to comment #2)
> In my opinion, having an only package would be better, because
> * the GTK themes and the Gnome Shell theme have been created explicitly to be
> used together;
> * anyway, one can still choose to apply the GTK themes or the Gnome Shell theme
> alone through Gnome Tweak Tool, if he prefers.
> But this is only a beginner's point of view. If other reasons exist to prefer
> creating separate subpackages, please let me know.
You should *really* split this package, as justified here:
   https://bugzilla.redhat.com/show_bug.cgi?id=744952#c5
The gtk2/gtk3/metacity theme can be used independently each other, and outside GNOME.
You should also rename your SRPM name, as explained here:
   https://bugzilla.redhat.com/show_bug.cgi?id=744952#c8

(In reply to comment #7)
> (In reply to comment #2)
> > In my opinion, having an only package would be better, because
> > * the GTK themes and the Gnome Shell theme have been created explicitly to be
> > used together;
> > * anyway, one can still choose to apply the GTK themes or the Gnome Shell theme
> > alone through Gnome Tweak Tool, if he prefers.
> > But this is only a beginner's point of view. If other reasons exist to prefer
> > creating separate subpackages, please let me know.
> You should *really* split this package, as justified here:
>    https://bugzilla.redhat.com/show_bug.cgi?id=744952#c5
> The gtk2/gtk3/metacity theme can be used independently each other, and outside
> GNOME.
> You should also rename your SRPM name, as explained here:
>    https://bugzilla.redhat.com/show_bug.cgi?id=744952#c8

I agree, you split the gtk parts up in sub packages and let the gnome3 theme require them, then it will be possible to use them outside gnome

This is an example of how the splitting can be achieved:
   http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec
By the way, you should *really* ask uipstream to set versions on its themes archive. You can't track new versions of the theme otherwise.

(In reply to comment #9)
> This is an example of how the splitting can be achieved:
>    http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec
> By the way, you should *really* ask uipstream to set versions on its themes
> archive. You can't track new versions of the theme otherwise.

Look good to me.

The versioning is a problem with most deviantart stuff, they just upload a zip with the latest stuff, no versioning at all :(

(In reply to comment #10)
> The versioning is a problem with most deviantart stuff, they just upload a zip
> with the latest stuff, no versioning at all :(
In a such a case, the timestamp of the archive should be used as a version; this should be here 20111205, for example.

(In reply to comment #9)
> This is an example of how the splitting can be achieved:
>    http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec

(In reply to comment #11)
> In a such a case, the timestamp of the archive should be used as a version;
> this should be here 20111205, for example.

Thank you, Tim and Mohamed.
Here's the new version of the package, corrected according to your valuable suggestions:

Spec URL: http://db.tt/NHscmjFS

SRPM URL: http://db.tt/wf9g2TAC

By the way, since the name of the package has changed, should I file a new review request or can I go on with this one?

(In reply to comment #12)
> By the way, since the name of the package has changed, should I file a new
> review request or can I go on with this one?
You can go on with this one, you just have to edit the title of the bug report to reflect the new name of the .spec file.

Look good to me, so the package is still APPROVED.

Packages updated to the 2011.12.29 version of the theme:

Spec URL: http://db.tt/xOZgxcBz

SRPM URL: http://db.tt/XoDkNQnb

_________________________________________________________________________________

For those who want to install the themes, here are the RPM packages for Fedora 16:

GTK+2 theme: http://db.tt/vzf2JnoU
GTK+3 theme: http://db.tt/ast9bEmg
Metacity theme: http://db.tt/MRH5FyzA
GNOME Shell theme: http://db.tt/UKtzafdQ
Xfwm4 theme: http://db.tt/QMxORubq

Tim, are you still happy with the package as updated? I can sponsor Mattia if nobody else has done so.

Mattia, just in case, please confirm that you're still interested, as it's been a month.

@Michel.

Still looks fine to me, so please sponsor

(In reply to comment #16)
> Tim, are you still happy with the package as updated? I can sponsor Mattia if
> nobody else has done so.
> 
> Mattia, just in case, please confirm that you're still interested, as it's been
> a month.

Sure I'm interested.

(In reply to comment #17)
> @Michel.
> 
> Still looks fine to me, so please sponsor

Thank you both.

Packages updated to the 2012.04.26 version of the theme:

Spec URL: http://db.tt/w7EhTdZj

SRPM URL: http://db.tt/F6hkNBs1

NOTE (IMPORTANT): From now on, this theme will be compatible only with GNOME 3.4 (i.e. Fedora 17). The latest compatible with GNOME 3.2 (i.e. Fedora 16) is version 2011.12.29, linked in comment #15.
_________________________________________________________________________________

For those who want to install the theme, here are the RPM packages for Fedora
17:

GTK+2 theme: http://db.tt/rezvGDVG
GTK+3 theme: http://db.tt/ljyudPHP
Metacity theme: http://db.tt/1VJFCQRQ
GNOME Shell theme: http://db.tt/4AyjHKKe
Xfwm4 theme: http://db.tt/TkSJAK8f

Packages updated to the 2012.04.29 version of the theme:

Spec URL: http://db.tt/GJvcxURB

SRPM URL: http://db.tt/Jc4kx5zG
_________________________________________________________________________________

RPM packages for Fedora 17:

GTK+2 theme: http://db.tt/m5zJLrya
GTK+3 theme: http://db.tt/m5zJLrya
Metacity theme: http://db.tt/9lEZvIHE
GNOME Shell theme: http://db.tt/rz6Hj8GR
Xfwm4 theme: http://db.tt/yE954TWa

The link to the RPM package of the GTK+3 theme in comment #20 is wrong. Sorry.
Here's the right one:

GTK+3 theme: http://db.tt/Er9JqwEw

Just tested the F17 builds and they look fine. Mattia, what's your FAS username?

(note that you can get space on fedorapeople.org -- see http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org -- and put your review packages there)

(In reply to comment #22)
> Mattia, what's your FAS username?

My user name on the Fedora Account System is "odysseus".
Thank you!

OK, you're sponsored. Feel free to request a repository for your package now -- and don't hesitate to email if you have any packaging question. Cheers (and thanks for packaging this, my Eclipse, Emacs, and Qt programs finally fit into my desktop)

(In reply to comment #24)
> OK, you're sponsored. Feel free to request a repository for your package now --
> and don't hesitate to email if you have any packaging question.

Thank you very much!

> Cheers (and thanks for packaging this, my Eclipse, Emacs, and Qt programs 
> finally fit into my desktop)

You're welcome.

New Package SCM Request
=======================
Package Name: zukitwo
Short Description: The Zukitwo themes for GTK+2, GTK+3, Metacity, GNOME Shell and Xfwm4, created by lassekongo83.
Owners: odysseus
Branches: f17
InitialCC:

I've been sponsored for almost a day, but I can't change the "fedora‑cvs" flag to "?" yet, as needed to request a repository for this package.
Any suggestions?
_________________________________________________________________________________

Since I haven't been able to set up everything so far yet, I still link the latest (i.e. 2012.05.03) version of Zukitwo (for Gnome 3.4/Fedora 17 only!) here:

Spec URL: http://db.tt/XQQBqjk6
SRPM URL: http://db.tt/L4XA6LxK

RPM packages for Fedora 17:

GTK+2 theme: http://db.tt/2AAOvVpc
GTK+3 theme: http://db.tt/J65iTN4C
Metacity theme: http://db.tt/nPSn6NqR
GNOME Shell theme: http://db.tt/hDGlZey4
Xfwm4 theme: http://db.tt/vlIU8MGi

Enjoy!

(In reply to comment #27)
> I've been sponsored for almost a day, but I can't change the "fedora‑cvs" flag
> to "?" yet, as needed to request a repository for this package.
> Any suggestions?

Hi Mattia,

Looks like you changed your Bugzilla email address to your @fedoraproject.org alias -- this is not allowed, and is probably why you can't change the flags. 

You need to have the same address listed in FAS (currently mattiameneguzzo) as the address you use for Bugzilla. Let me know if that still doesn't work (probably give it a couple of hours to settle).

(In reply to comment #28)
> Hi Mattia,
> 
> Looks like you changed your Bugzilla email address to your @fedoraproject.org
> alias -- this is not allowed, and is probably why you can't change the flags. 
> 
> You need to have the same address listed in FAS (currently
> mattiameneguzzo) as the address you use for Bugzilla.

The problem is it looks like I cannot change my email address again: "Preferences"->"Name and password" shows me the "Confirmed email address" only (i.e. the "@fedoraproject.org" one) but no entry to enter a new one.

Odd, this is what I get:

https://bugzilla.redhat.com/userprefs.cgi?tab=account


Name and Password

Please enter your existing password to confirm account changes.
Password:	
New password:	
Confirm new password:	
Your real name (optional, but encouraged):	
New email address:	

So you basically managed to change your email from hotmail -> fp.o with this form, but now it's no longer let you change it again... hm. I'll ask one of the admins

(In reply to comment #30)
> Odd, this is what I get:
> 
> https://bugzilla.redhat.com/userprefs.cgi?tab=account
> 
> 
> Name and Password
> 
> Please enter your existing password to confirm account changes.
> Password: 
> New password: 
> Confirm new password: 
> Your real name (optional, but encouraged): 
> New email address: 
> 
> So you basically managed to change your email from hotmail -> fp.o with this
> form, but now it's no longer let you change it again... hm. I'll ask one of the
> admins

Yes, exact. This is the "Name and Password" tab as it appears now: http://db.tt/gLyXcMdY
Maybe there's a minimum time interval between two consecutive changes of email address, but this is only a guess.
Thanks for your help.

It does say "Completion date: 2012-05-08 10:49:36 CEST" -- so I'm guessing you'd have to wait till then :)

I didn't notice that - I don't know why. Sorry! :-(

Hey Mattia, I could change your login email address in bugzilla to the email address you have listed in the Fedora Account System (since odysseus just forwards there).  Would that work for you?

(In reply to comment #34)
> Hey Mattia, I could change your login email address in bugzilla to the email
> address you have listed in the Fedora Account System (since odysseus just
> forwards there).  Would that work for you?

If the reason for me not being able to set the "fedora-cvs" flag is my current login email address, please proceed. Thanks in advance.

OK, I've been able to change my login email address and to set the "fedora-cvs" flag.

For the new package SCM request, go to comment #26.

The SCM request is processed automatically, I believe -- could you just comment again with the request? I'm not sure it works if the request is in a preceding comment. Thanks :)

New Package SCM Request
=======================
Package Name: zukitwo
Short Description: The Zukitwo themes for GTK+2, GTK+3, Metacity, GNOME Shell and Xfwm4, created by lassekongo83.
Owners: odysseus
Branches: f17
InitialCC:

Git done (by process-git-requests).

zukitwo-20120511-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120511-1.fc17

The package for the latest (i.e. 2012.05.11) version of Zukitwo is in Bodhi (see comment #40). Please try it, if you wish.

I seize this opportunity to warmly thank you all for your precious support!

zukitwo-20120511-1.fc17 has been pushed to the Fedora 17 testing repository.

zukitwo-20120516-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120516-1.fc17

I think default font in gnome-shell.css should be changed to something else, since "ubuntu" fonts are not available in Fedora repos.

I'm closing this review request, as stated in https://fedoraproject.org/wiki/Package_Review_Process#Contributor .

Thanks again to everyone who helped me! :-)

zukitwo-20120523-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120523-1.fc17

zukitwo-20120526-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120526-1.fc17

zukitwo-20120602-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120602-1.fc17

zukitwo-20120602-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120602-2.fc17

zukitwo-20120607-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120607-1.fc17

zukitwo-20120607-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

I've been told that, when multiple subpackages share common directories/files, it's better to define a "*-common" subpackage which owns them.

As for Zukitwo, the situation is a bit complicated:

- all subpackages share documentation files and a common main directory: "/usr/share/themes/Zukitwo"

- all subpackages except "gnome-shell-theme-*" share two subdirectories: "/usr/share/themes/Zukitwo/Zukitwo" and "/usr/share/themes/Zukitwo/Zukitwo-Dark"

- only "gnome-shell-theme-*" owns "/usr/share/themes/Zukitwo/Zukitwo-Shell"

If the "*-common" subpackage owned "/usr/share/themes/Zukitwo" only, then ownership of the above-mentioned two subdirs would be repeated in all subpackages except "gnome-shell-theme-*".
Instead, if it owned also the two subdirs, it would be useless when installing only "gnome-shell-theme-*".

What do you suggest me to do? Thank you.

Is it viable to make the "*-common" subpackage create and own also "/usr/share/themes/Zukitwo/Zukitwo-Shell" (in addition to "/usr/share/themes/Zukitwo/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo-Dark" and documentation files)?
The only issue is that, if one opted not to install "gnome-shell-theme-*", the (empty) "Zukitwo-Shell" directory would exist anyway.
What do you think?

Another alternative could be to 

- move the content of "/usr/share/themes/Zukitwo/Zukitwo-Shell" (i.e. the "gnome-shell" directory) into "/usr/share/themes/Zukitwo",

- not to create the "Zukitwo-Shell" directory at all and

- to have "*-common" own "/usr/share/themes/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo-Dark".

The GNOME Shell theme should work anyway, shouldn't it?

(In reply to comment #54)
> Another alternative could be to 
> 
> - move the content of "/usr/share/themes/Zukitwo/Zukitwo-Shell" (i.e. the
> "gnome-shell" directory) into "/usr/share/themes/Zukitwo",
> 
> - not to create the "Zukitwo-Shell" directory at all and
> 
> - to have "*-common" own "/usr/share/themes/Zukitwo",
> "/usr/share/themes/Zukitwo/Zukitwo",
> "/usr/share/themes/Zukitwo/Zukitwo-Dark".
> 
> The GNOME Shell theme should work anyway, shouldn't it?

I didn't noticed that doing as I proposed in comment #54 would produce the side effect of creating the empty directories ".../Zukitwo/Zukitwo" and "...Zukitwo/Zukitwo-Dark" even if one installed only "gnome-shell-theme-*".

(In reply to comment #52)
> I've been told that, when multiple subpackages share common
> directories/files, it's better to define a "*-common" subpackage which owns
> them.
> 
> As for Zukitwo, the situation is a bit complicated:
> 
> - all subpackages share documentation files and a common main directory:
> "/usr/share/themes/Zukitwo"
> 
> - all subpackages except "gnome-shell-theme-*" share two subdirectories:
> "/usr/share/themes/Zukitwo/Zukitwo" and
> "/usr/share/themes/Zukitwo/Zukitwo-Dark"
> 
> - only "gnome-shell-theme-*" owns "/usr/share/themes/Zukitwo/Zukitwo-Shell"
> 
> If the "*-common" subpackage owned "/usr/share/themes/Zukitwo" only, then
> ownership of the above-mentioned two subdirs would be repeated in all
> subpackages except "gnome-shell-theme-*".
> Instead, if it owned also the two subdirs, it would be useless when
> installing only "gnome-shell-theme-*".
> 
> What do you suggest me to do? Thank you.

Any suggestion about the above issue, please?
I'd like my package to be as much compliant to the quality standard of Fedora as possible, but for this I need your help.

the gnome shell theme packages should be installed in and only own that dir

/usr/share/themes/Zukitwo/gnome-shell
/usr/share/themes/Zukitwo-Dark/gnome-shell

gtk-2 theme should be installed in and only own that dir.

/usr/share/themes/Zukitwo/gtk-2
/usr/share/themes/Zukitwo/gtk-3
etc.

The licens package should go into every package

if there is some other generel docs you can put it into at -common package and let the other packages require the -common package

Thank you.

(In reply to comment #57)

> The licens package should go into every package
> 
> if there is some other generel docs you can put it into at -common package
> and let the other packages require the -common package

I think you mean "license file".
As for the other packages I am maintaining, I put also the license file (i.e. COPYING) into the "*-common" subpackage only, since I thought that common should contain every shared file with no exceptions (please, see, e.g., http://pkgs.fedoraproject.org/cgit/zukiwi.git/tree/zukiwi.spec ).
So, in your opinion, I should also correct the other packages to make the license file be included in every single package (excluding "*.common" only)?

As far as I remember it is ok to put the license file in a common as long as every other package requires the -common package.
So that the license file is install no matter what sub package you are installing

I modified the Spec file according to your suggestions.
Here it is: http://pkgs.fedoraproject.org/cgit/zukitwo.git/plain/zukitwo.spec?h=f17&id=e184ac37baf151b2804cb108cdc5bd78d657dc55

Please note that now the "gnome-shell" directory and its content are present in both "/usr/share/themes/Zukitwo/" and "/usr/share/themes/Zukitwo-Dark" (before a sole copy of them existed in "/usr/share/themes/Zukitwo-Shell/").

Look fine to me.
A more cosmetic issue is having multiple requirement i a single line, it makes it hard to read, I would prefer that you add one require line for each requirement.

Ex.

Requires:       %{name}-common = %{version}-%{release}, gtk-murrine-engine >= 0.98.1.1 gtk2-engines

should be.

Requires:       %{name}-common = %{version}-%{release}
Requires:       gtk-murrine-engine >= 0.98.1.1
Requires:       gtk2-engines

It also make git diff easier to read when doing updates to requirement

By the way, just to avoid wasting disk space, I've replaced the copy of the "gnome-shell" directory inside "Zukitwo-Dark" with a symlink to that placed inside "Zukitwo". Rpmlint doesn't complain and the package installs and works fine.

(In reply to comment #61)
> A more cosmetic issue is having multiple requirement i a single line, it
> makes it hard to read, I would prefer that you add one require line for each
> requirement.
> 
> Ex.
> 
> Requires:       %{name}-common = %{version}-%{release}, gtk-murrine-engine
> >= 0.98.1.1 gtk2-engines
> 
> should be.
> 
> Requires:       %{name}-common = %{version}-%{release}
> Requires:       gtk-murrine-engine >= 0.98.1.1
> Requires:       gtk2-engines
> 
> It also make git diff easier to read when doing updates to requirement

I've already submitted the package to Koji; I'm going to do that cosmetic changed in the next release.
Thanks for your help!

(In reply to comment #62)
> I'm going to do that cosmetic >>>changed<<< in the next release.

Typo: "I'm going to do that cosmetic >>>changes<<< in the next release."