Fedora Account System
Red Hat Associate
Red Hat Customer
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.
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
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.
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.
On my system, whether installed or in BUILD/views, they're 0755.
Upstream say that that blank file is just a placeholder: http://drupal.org/node/220326 so it can be ignored.
Ok. I'll leave it in place in case it's used. What about the perms issue? I can't reproduce it.
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.
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?
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?
(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.
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).
My bad, it has a -dev version! But that dosn't affect the above.
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.
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.
Drupal 6.0 hitting rawhide, 6.x version of this module not yet ready.
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.beta4.fc9.src.rpm Updated for drupal 6.0, ready to review.
[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.
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
(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?
(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.
(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.
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
cvs done.
Built, update requested.
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.
Package Change Request ====================== Package Name: drupal-views New Branches: el5 el6 Owners: limb
Git done (by process-git-requests).