Bug 359911 - Review Request: drupal-views - Provides a method for site designers to control content presentation
Review Request: drupal-views - Provides a method for site designers to contro...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 359941
  Show dependency treegraph
 
Reported: 2007-10-31 07:13 EDT by Gwyn Ciesla
Modified: 2010-10-16 17:11 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-16 19:28:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
opensource: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Gwyn Ciesla 2007-10-31 07:13:48 EDT
Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
SRPM URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-1.6-1.fc7.src.rpm
Description: The views module provides a flexible method for Drupal site designers
to control how lists of content (nodes) are presented. Traditionally,
Drupal has hard-coded most of this, particularly in how taxonomy and
tracker lists are formatted.

This tool is essentially a smart query builder that, given enough 
information, can build the proper query, execute it, and display the 
results. It has four modes, plus a special mode, and provides an 
impressive amount of functionality from these modes.
Comment 1 Benjamin Lewis 2008-02-10 18:20:52 EST
rpmlint is complaining about:
drupal-views.noarch: E: non-standard-dir-perm
/usr/share/drupal/modules/views/modules 02755
drupal-views.noarch: E: non-standard-dir-perm /usr/share/drupal/modules/views/po
02755
drupal-views.noarch: E: zero-length
/usr/share/drupal/modules/views/modules/views_forum.inc
Comment 2 Gwyn Ciesla 2008-02-11 07:21:25 EST
Odd, I just rebuilt based on this spec on f8 and I only get:

drupal-views.noarch: E: zero-length
/usr/share/drupal/modules/views/modules/views_forum.inc

Which isn't a problem, not sure.
Comment 3 Benjamin Lewis 2008-02-11 07:32:15 EST
I do a lot of work with Drupal, so I'll ask upstream about that zero-length file
(I've got a few of them on different servers, and I'm wondering why its like that).

I'm definitely still getting those rpmlint errors... and when I rpm -i the
package they are set mode 02755. If you untar the source then they are set to
that mode in there, which is probably the problem.
Comment 4 Gwyn Ciesla 2008-02-11 07:43:42 EST
On my system, whether installed or in BUILD/views, they're 0755.
Comment 5 Benjamin Lewis 2008-02-11 13:12:12 EST
Upstream say that that blank file is just a placeholder:
http://drupal.org/node/220326 so it can be ignored.
Comment 6 Gwyn Ciesla 2008-02-13 11:09:25 EST
Ok.  I'll leave it in place in case it's used.  

What about the perms issue?  I can't reproduce it.
Comment 7 Benjamin Lewis 2008-02-13 14:12:06 EST
I don't know, sorry, and I'm not sponsored so i can't actually approve this, I
havn't looked too deeply, but it seems ok to me.
Comment 8 Gwyn Ciesla 2008-02-13 14:16:48 EST
Ok.  Thanks!  I'd sponsor you myself but I'm not a sponsor. :)

I assume you have a review request out there that indicates you need a sponsor?
Comment 9 Benjamin Lewis 2008-02-13 14:32:11 EST
Actually, no. I was originally going to take over the Yakuake package, but was
beaten to it. I'm actually thinking of packaging up some Drupal modules and
themes myself now, thats why I 'reviewed' this.

I thought of an odd issue though, to do with Drupal Module versioning schemes:
Say a module is currently 5.x-2.0, it would be packaged as 2.0, yes, but when
that module is ported to core 6.0 it would now be 6.x-1.0, necessitating an
epoch bump if we wish to call it version 1.0? Is that the intention?
Comment 10 Gwyn Ciesla 2008-02-13 14:53:27 EST
(In reply to comment #9)
> Actually, no. I was originally going to take over the Yakuake package, but was
> beaten to it. I'm actually thinking of packaging up some Drupal modules and
> themes myself now, thats why I 'reviewed' this.

I see.  Practice makes perfect. :)

> I thought of an odd issue though, to do with Drupal Module versioning schemes:
> Say a module is currently 5.x-2.0, it would be packaged as 2.0, yes, but when
> that module is ported to core 6.0 it would now be 6.x-1.0, necessitating an
> epoch bump if we wish to call it version 1.0? Is that the intention?

Well, not necessarily.  As this is the first drupal module in Fedora, this would
be the place to decide that.  The versioning as I have it now strips ouit the
drupal core version and leaves just the module version.  I handle the drupal
core requirement in the Requires.

My assumption going forward is that there will only be one major version of
drupal in each Fedora release, so that I should probably put a 'less than'
clause in the Requires.  The catch is that this would mean that I'd really need
to coordinate the updating of drupal core with all the modules.  I suppose I
could look at perl and it's modules as a model for how to handle that.  

Not being a heavy drupal customizer myself, I'm curious how quickly after a
major version release modules get updated.
Comment 11 Benjamin Lewis 2008-02-13 15:08:36 EST
I'm thinking of the CAPTCHA module is currently on version 5.x-3.1, whenever
that is ported to Drupal 6 (and I may have to do it myself for a client in a
week or so if it isn't) its version number will become 6.x-1.0, hence the
problem as the upgrade path 3.1 -> 1.0 would be broken, requiring and epoch bump
so it becomes 1:3.1 -> 2:1.0 (I _think_ that is what happens).
Comment 12 Benjamin Lewis 2008-02-13 15:09:29 EST
My bad, it has a -dev version! But that dosn't affect the above.
Comment 13 Gwyn Ciesla 2008-02-13 15:26:14 EST
Yeah, maybe including major version would help.  You're right, an epoch bump
would be required in that instance, if they restart the module versioning at
1.0.  I'll play with it.
Comment 14 Gwyn Ciesla 2008-02-14 13:20:02 EST
Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
SRPM URL:
http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-5.x.1.6-1.fc8.src.rpm

Altered version format to address the above.
Comment 15 Gwyn Ciesla 2008-02-22 13:22:09 EST
Drupal 6.0 hitting rawhide, 6.x version of this module not yet ready.
Comment 17 Till Maas 2008-08-08 18:03:47 EDT
[OK] rpmlint output: silent under normal conditions
[OK] Spec in %{name}.spec format

[OK] license allowed: GPLv2
[OK] license matches shortname in License: tag
LICENSE.txt indicates GPLv2
[OK] license in tarball and included in %doc:

[OK] package is code or permissive content:
[OK] Source0 is a working URL
[OK] Source0 matches Upstream:
7c69feceffdef7e12ca42a479335f2bc  views-6.x-2.0-beta4.tar.gz

[OK] Package builds on all platforms: noarch
[OK] BuildRequires are complete (mock builds)
(OK) No file dependencies outside of /etc /bin /sbin /usr/bin /usr/sbin 

[OK] Prefix: /usr not used (not relocatable)

[OK] Owns all created directories
[NOT OK] no duplicates in %files
The following files are also copied in /usr/share/drupal/modules/views
CHANGELOG.txt LICENSE.txt README.txt drupal-views-fedora-README.txt

[OK] %defattr(-,root,root,-) is in every %files section
[OK] Does not own files or dirs from other packages
[OK] included filenames are in UTF-8

[OK] %clean is rm -rf %{buildroot} or $RPM_BUILD_ROOT 
[OK] %install starts with rm -rf %{buildroot} or $RPM_BUILD_ROOT 

[OK] Consistent macro usage

[OK] large documentation is -doc subpackage
[OK] %doc does not affect runtime

{OK} no pre-built binaries (.a, .so*, executable)

{Ok} well known BuildRoot
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

{Ok} PreReq not used

{Ok} no duplication of system libraries

{OK} no rpath

{NOT OK} Timestamps preserved with cp and install
https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps
The drupal-views-fedora-README.txt file is copied without preserving the
timestamp, install -p -m 0644 would be probably the best option

{OK} Requires(pre,post) style notation not used

{Ok} only writes to tmp /var/tmp $TMPDIR %{_tmppath} %{_builddir} (and %{buildroot} on %install and %clean)

{Ok} no Conflicts

{Ok} nothing installed in /srv

{Ok} Changelog in allowed format
https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

{OK} does not use Scriptlets

<Ok> Architecture independent packages have: BuildArch: noarch

{NOT OK} Follows Naming Guidelines
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages
The Release is missing and additional integer, it should be:

0.1.beta4%{?dist}
  ^- this is missing

The second number needs to be bumped every time you change something, until it
is properly released.

Additional:
The Copying SOURCE1 should go into %prep, because it is not a build step. You
can leave the %build section empty.


In conclusion:
- The duplicate .txt files should not be copied
- The timestamp of SOURCE1 should be preserved
- The release should be created according to the Naming Guidelines
Iirc, these issues are present in your other drupal review requests.


Btw. I also see the 02755 permissions warnings, but I know why they are there!
;-) The BUILD directory of by rpmbuild user has this permissions and therefore
every directory that is created there, too. You could run a recursive chmod on
everything after copying it, to avoid this.
Comment 18 Gwyn Ciesla 2008-08-11 14:17:54 EDT
Fixed all but the last chmod comment.  I don't see the error you mention, are these in rpmlint?  rpmlint -i is clean for me.

Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
SRPM URL:
http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-6.x.2.0-0.1.beta4.fc9.src.rpm
Comment 19 Till Maas 2008-08-12 09:04:02 EDT
(In reply to comment #18)
> Fixed all but the last chmod comment.  I don't see the error you mention, are
> these in rpmlint?  rpmlint -i is clean for me.

You see the error after you run "chmod g+s BUILD" where BUILD is the BUILD directory you use for rpmbuild, afaik the default is ~/rpmbuild/BUILD. I normally build rpms as a differenty user and therefore I set the BUILD directy sgid, to have some permissions as my normal user. But this is not really something that needs to be fixed, because in Fedora the rpms are built within mock.

> Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
> SRPM URL:
> http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-6.x.2.0-0.1.beta4.fc9.src.rpm

Everything you fixed looks good. I was about to approve the package, but then I noticed the 6.x in the version tag. I am not sure, whether it should be there or better be a part of the package name:

Name: drupal-views-6.x
Version: 2.0

Because there are seveveral releases for several drupal branches listed on http://drupal.org/project/views

What is your opinion about this?
Comment 20 Gwyn Ciesla 2008-08-12 10:25:14 EDT
(In reply to comment #19)
> (In reply to comment #18)
> > Fixed all but the last chmod comment.  I don't see the error you mention, are
> > these in rpmlint?  rpmlint -i is clean for me.
> 
> You see the error after you run "chmod g+s BUILD" where BUILD is the BUILD
> directory you use for rpmbuild, afaik the default is ~/rpmbuild/BUILD. I
> normally build rpms as a differenty user and therefore I set the BUILD directy
> sgid, to have some permissions as my normal user. But this is not really
> something that needs to be fixed, because in Fedora the rpms are built within
> mock.

I don't see were in the spec or build process this happens.  Maybe it's just the time of day and my caffiene level, but. . .

> > Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
> > SRPM URL:
> > http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-6.x.2.0-0.1.beta4.fc9.src.rpm
> 
> Everything you fixed looks good. I was about to approve the package, but then I
> noticed the 6.x in the version tag. I am not sure, whether it should be there
> or better be a part of the package name:
> 
> Name: drupal-views-6.x
> Version: 2.0
> 
> Because there are seveveral releases for several drupal branches listed on
> http://drupal.org/project/views
> 
> What is your opinion about this?

I was thinking it's best left in the version, for easier dependency referencing, and so we don't need a whole new review for each module when Drupal bumps it's major version number.
Comment 21 Till Maas 2008-08-12 11:01:55 EDT
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Fixed all but the last chmod comment.  I don't see the error you mention, are
> > > these in rpmlint?  rpmlint -i is clean for me.
> > 
> > You see the error after you run "chmod g+s BUILD" where BUILD is the BUILD
> > directory you use for rpmbuild, afaik the default is ~/rpmbuild/BUILD. I
> > normally build rpms as a differenty user and therefore I set the BUILD directy
> > sgid, to have some permissions as my normal user. But this is not really
> > something that needs to be fixed, because in Fedora the rpms are built within
> > mock.
> 
> I don't see were in the spec or build process this happens.  Maybe it's just
> the time of day and my caffiene level, but. . .

It does not happen anywhere. I set the BUILD directory on my build machine to sgid and then I get the 02755 errors from rpmlint for packages that do not set the permissions explicitly.  It only meant to explain how one can get the rpmlint error because Benjamin experienced them, too.

> > > Spec URL: http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views.spec
> > > SRPM URL:
> > > http://zanoni.jcomserv.net/fedora/drupal-views/drupal-views-6.x.2.0-0.1.beta4.fc9.src.rpm
> > 
> > Everything you fixed looks good. I was about to approve the package, but then I
> > noticed the 6.x in the version tag. I am not sure, whether it should be there
> > or better be a part of the package name:
> > 
> > Name: drupal-views-6.x
> > Version: 2.0
> > 
> > Because there are seveveral releases for several drupal branches listed on
> > http://drupal.org/project/views
> > 
> > What is your opinion about this?
> 
> I was thinking it's best left in the version, for easier dependency
> referencing, and so we don't need a whole new review for each module when
> Drupal bumps it's major version number.

ok. I noticed there is atleast one other packages with this version-scheme in Fedora, so I guess it is not a problem. This packages is hereby APPROVED.
Comment 22 Gwyn Ciesla 2008-08-12 13:01:31 EDT
Ah, I see.  Many thanks!


New Package CVS Request
=======================
Package Name: drupal-views
Short Description: Provides a method for site designers to control content presentation
Owners: limb
Branches: F-9
InitialCC:
Cvsextras Commits: yes
Comment 23 Kevin Fenzi 2008-08-12 13:15:01 EDT
cvs done.
Comment 24 Gwyn Ciesla 2008-09-15 13:36:40 EDT
Built, update requested.
Comment 25 Fedora Update System 2008-09-16 19:28:07 EDT
drupal-views-6.x.2.0-0.1.beta4.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Gwyn Ciesla 2010-10-14 10:01:48 EDT
Package Change Request
======================
Package Name: drupal-views
New Branches: el5 el6
Owners: limb
Comment 27 Kevin Fenzi 2010-10-16 17:11:38 EDT
Git done (by process-git-requests).

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