Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.1-1.fc21.mattdm.src.rpm Description: Tools which revolve around fiddling with dates and times on the command line, with a strong focus on use cases that arise when dealing with large amounts of financial data. Fedora Account System Username: mattdm
Interesting, a guy just asked me 7 hours ago about packaging it... I will review it.
========== Manual Review ============ 1. %check section is needed for make check 2. Disable silent build by passing --disable-silent-rules to %configure, then you will see trouble 4. 3. Consider packaging octave binding(*optional*, as I don't find it useful so far, might not for others I think). 4. CFLAGS are being overriden by march=native(aarch64 doesn't support it) and even others, this is not not good, please patch. 5. These program names are too common, please consider passing --program-prefix='dateutils.', as it even conflicts with RHEL dapl-utils package(It's not in Fedora I checked).
About point 4 you could wait for dateutils-0.3.2, should be released today.
(In reply to Christopher Meng from comment #2) > 1. %check section is needed for > make check Sure, will add. > 2. Disable silent build by passing --disable-silent-rules to %configure, > then you will see trouble 4. Hmmm; maybe that should be standard? Good catch. > 3. Consider packaging octave binding(*optional*, as I don't find it useful > so far, might not for others I think). Is this bringing in baggage if you rebuild with octave-devel as a build-requires (or out of mock on a system with it installed)? I guess I could subpackage, but as it's not mentioned in the docs (is it? did I miss something?) I'm inclined to just leave it out. > 4. CFLAGS are being overriden by march=native(aarch64 doesn't support it) > and even others, this is not not good, please patch. Rüdiger Meier, I'll wait as suggested... presumably fixed? > 5. These program names are too common, please consider passing > --program-prefix='dateutils.', as it even conflicts with RHEL dapl-utils > package(It's not in Fedora I checked). I think that'd make them significantly less handy, and unless there are really strong feelings here, I think I'd prefer to leave as-is, or as a worst case change the initial 'd' to expanded 'date' — dateadd, dateconv, etc. (But that also seems like a big deviation from upstream!)
(In reply to Matthew Miller from comment #4) > > 4. CFLAGS are being overriden by march=native(aarch64 doesn't support it) > > and even others, this is not not good, please patch. > > Rüdiger Meier, I'll wait as suggested... presumably fixed? Yes, this will be fixed. > > 5. These program names are too common, please consider passing > > --program-prefix='dateutils.', as it even conflicts with RHEL dapl-utils > > package(It's not in Fedora I checked). > > I think that'd make them significantly less handy, and unless there are > really strong feelings here, I think I'd prefer to leave as-is, or as a > worst case change the initial 'd' to expanded 'date' — dateadd, dateconv, > etc. (But that also seems like a big deviation from upstream!) "dateutils." prefix looks a bit ugly but at least Debian is using the same. Other Distros are using it originally without prefix. Maybe they don't have collisions or they didn't checked. I guess upstream could be also convinced about adding a nice prefix.
It's not just that it looks ugly; it's also unwieldy for a command-line tool that by its nature is likely to get typed a lot (rather than a special-purpose util like the mentioned dapl-utils). Christopher, as I understand it there's no _current_ conflicts here; do you have a strong opinion on just leaving it? Rüdiger, it sounds like you're more in touch with upstream than I am; do you want to contact them and ask if they're open to going to dateadd, dateconv, etc?
(In reply to Rüdiger Meier from comment #5) > "dateutils." prefix looks a bit ugly but at least Debian is using the same. > Other Distros are using it originally without prefix. Maybe they don't have > collisions or they didn't checked. I guess upstream could be also convinced > about adding a nice prefix. Surprisingly, my solution is even 'conflicting' with Debian ;) You could choose another prefix like 'dateutils-', or something shorter even. But it will confuse guys who just wanna use it, and also upstream, too. (In reply to Matthew Miller from comment #6) > It's not just that it looks ugly; it's also unwieldy for a command-line tool > that by its nature is likely to get typed a lot (rather than a > special-purpose util like the mentioned dapl-utils). Christopher, as I > understand it there's no _current_ conflicts here; do you have a strong > opinion on just leaving it? I don't have experience with handling conflicting binary names in Fedora, as anything with such name conflicts would be a vexed problem... But I don't want to see a solution like 'ninja-build' in Fedora as well, it's undue.
The new 0.3.2 version isn't out, but I see from comments in the configure script that passing CFLAGS="$CFLAGS" to make will fix #4, so I did that, Also, added make check, and that passes even with our flags rather than the upstream preferred. So, updated spec and srpm: Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.1-2.fc21.mattdm.src.rpm
0.3.2 is out since a few hours https://github.com/hroptatyr/dateutils/releases
Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.2-1.fc21.mattdm.src.rpm
* This is an anachronism: %install rm -rf $RPM_BUILD_ROOT It is only required on very old RHELs. As you don't seem to support these outdated RHELs, you should remove this. * Missing: %license * rpmlint dateutils-0.3.2-1.fc23.x86_64.rpm dateutils.x86_64: W: manual-page-warning /usr/share/man/man1/dgrep.1.gz 12: warning: macro `>',' not defined
(In reply to Ralf Corsepius from comment #11) > * This is an anachronism: > %install > rm -rf $RPM_BUILD_ROOT Thanks; it was in the template, but you're right, I probably won't build for ancient RHEL. I'll remove it for next build. > * Missing: %license No separate license file is included. As the guidelines suggest, I've contacted upstream asking for one (but I think this is non-blocking, right?) > * rpmlint dateutils-0.3.2-1.fc23.x86_64.rpm > dateutils.x86_64: W: manual-page-warning /usr/share/man/man1/dgrep.1.gz 12: > warning: macro `>',' not defined Yeah, I'll also file that upstream.
Above issues are now fixed upstream.
ping Christopher -- does this look good now?
I've started the fedora-review process, but it's still incompleted yet... Maybe another few hours needed... Don't worry... Anyway, it's better to add Conflicts to the SPEC if you wanna package it into EPEL, I have no idea about dealing with RHEL team guys for such case.
*** Bug 1206777 has been marked as a duplicate of this bug. ***
Ping Christopher....
BTW about the program name conflicts ... upstream decided to rename dtest to datetest, etc. There are a few patches to install the new names inclusive old symlinks for compatibility. But for this new Fedora package you may consider to use the new names only right now. Something like this: for prog in add conv diff grep round seq sort test zone; do mv %{buildroot}/%{_bindir}/d$prog %{buildroot}/%{_bindir}/date$prog mv %{buildroot}/%{_mandir}/man1/d${prog}.1* %{buildroot}/%{_mandir}/man1/date${prog}.1* done
Okay, cool. Maybe I'll wait for the next upstream release?
Updated: Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.2-3.git35.3e322eb.fc22.mattdm.src.rpm this uses upstream snapshot with new command names (and eschews creation of the old links via ./configure --without-old-links. However, the old _man_ pages are still created. I'm going to file an upstream issue about that; for this package I just left them but I guess I could rm them if that's better.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Also, how long are those snapshot tarballs offered for download? If the latest snapshot replaces the current one, the information on how to recreate the tarball is missing: https://fedoraproject.org/wiki/Packaging:SourceURL#Github
I think that's in line with the snapshot naming guidelines, isn't it? (I'm retaining the upstream convention.) I'm also not planning to keep using the snapshots once next release is out and expect it to be an unusual condition for this package; I just figured we should start out with the new upstream (and epel-friendly) name.
Since this is an _upstream_ snapshot, I don't think the information-to-recreate part is relevant — that's all about if the _packager_ creates a snapshot from the repository. Here, it's an upstream release, just not the main one.
Yeah, it kinda circumvents the snapshot guidelines, if one manages to find an online service that can generate snapshot tarballs from github and other repos. Possibly short-lived tarballs that are not available for download as long as the release tarballs. You end up with a source tarball that's 404 not found with no info on how to recreate it. Anyway, that's not the full story. The snapshot you've packaged is version "0.3.3.GIT" in its configure script, not 0.3.2 as in your RPM package. That value enters the config.h header as VERSION and PACKAGE_VERSION macro and may find its way into the compiled sources, too: $ grep VERSION src/config.h #define PACKAGE_VERSION "0.3.3.GIT" #define VERSION "0.3.3.GIT" There's another version "0.3.2.git35.3e322eb" in the version.mk file, which matches the tarball but not the RPM spec file either. That version is added into the manual pages and executables, for example. It is also larger than 0.3.2: $ dateadd --version dateadd 0.3.2.git35.3e322eb So, you've packaged something that is not 0.3.2 with a package %version 0.3.2. It may be unimportant for dateutils, but the guidelines are not just about dateutils. If one considers the snapshot a post-release package, the guidelines say: | Also, packagers using the post-release scheme should put a comment | in their spec file with a brief description of the upstream conventions | for naming/versioning that are being worked around. That refers to moving ".git35.3e322eb" from %version into %release, so in the RPM system and the user your package appears as 0.3.2 although is something post-0.3.2 or pre-0.3.3. A minor detail only. Doubtful that many packagers add a comment like that even in trivial cases. [...] Something else: The built package contains several manuals with no corresponding executables. Notice all the short names, such as "dadd, dconv, ddiff". Something's broken there: $ rpmls dateutils -rwxr-xr-x /usr/bin/dateadd -rwxr-xr-x /usr/bin/dateconv -rwxr-xr-x /usr/bin/datediff -rwxr-xr-x /usr/bin/dategrep -rwxr-xr-x /usr/bin/dateround -rwxr-xr-x /usr/bin/dateseq -rwxr-xr-x /usr/bin/datesort -rwxr-xr-x /usr/bin/datetest -rwxr-xr-x /usr/bin/datezone -rwxr-xr-x /usr/bin/strptime drwxr-xr-x /usr/share/dateutils -rw-r--r-- /usr/share/dateutils/iata.tzmcc -rw-r--r-- /usr/share/dateutils/icao.tzmcc -rw-r--r-- /usr/share/dateutils/mic.tzmcc drwxr-xr-x /usr/share/doc/dateutils -rw-r--r-- /usr/share/doc/dateutils/LICENSE -rw-r--r-- /usr/share/doc/dateutils/README.md -rw-r--r-- /usr/share/info/dateutils.info.gz drwxr-xr-x /usr/share/licenses/dateutils -rw-r--r-- /usr/share/licenses/dateutils/LICENSE -rw-r--r-- /usr/share/man/man1/dadd.1.gz -rw-r--r-- /usr/share/man/man1/dateadd.1.gz -rw-r--r-- /usr/share/man/man1/dateconv.1.gz -rw-r--r-- /usr/share/man/man1/datediff.1.gz -rw-r--r-- /usr/share/man/man1/dategrep.1.gz -rw-r--r-- /usr/share/man/man1/dateround.1.gz -rw-r--r-- /usr/share/man/man1/dateseq.1.gz -rw-r--r-- /usr/share/man/man1/datesort.1.gz -rw-r--r-- /usr/share/man/man1/datetest.1.gz -rw-r--r-- /usr/share/man/man1/dateutils.1.gz -rw-r--r-- /usr/share/man/man1/datezone.1.gz -rw-r--r-- /usr/share/man/man1/dconv.1.gz -rw-r--r-- /usr/share/man/man1/ddiff.1.gz -rw-r--r-- /usr/share/man/man1/dgrep.1.gz -rw-r--r-- /usr/share/man/man1/dround.1.gz -rw-r--r-- /usr/share/man/man1/dseq.1.gz -rw-r--r-- /usr/share/man/man1/dsort.1.gz -rw-r--r-- /usr/share/man/man1/dtest.1.gz -rw-r--r-- /usr/share/man/man1/dzone.1.gz -rw-r--r-- /usr/share/man/man1/strptime.1.gz
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #25) > Yeah, it kinda circumvents the snapshot guidelines, if one manages to find > an online service that can generate snapshot tarballs from github and other > repos. Possibly short-lived tarballs that are not available for download as > long as the release tarballs. You end up with a source tarball that's 404 > not found with no info on how to recreate it. I guess I would agree if the packager does it, but here, it's upstream, linked from http://www.fresse.org/dateutils/. There's no upstream obligation to preserve tarballs for _any_ releases forever, so I'm not sure why this needs special handling. > $ dateadd --version > dateadd 0.3.2.git35.3e322eb > So, you've packaged something that is not 0.3.2 with a package %version > 0.3.2. It may be unimportant for dateutils, but the guidelines are not just > about dateutils. Okay, so I guess in this case I can just put all of 0.3.2.git35.3e322eb as the version. > Something else: > The built package contains several manuals with no corresponding > executables. Notice all the short names, such as "dadd, dconv, ddiff". > Something's broken there: Yes, noted above, and reported upstream at https://github.com/hroptatyr/dateutils/issues/34#issuecomment-94950060
(In reply to Matthew Miller from comment #26) > (In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment > #25) > > Yeah, it kinda circumvents the snapshot guidelines, if one manages to find > > an online service that can generate snapshot tarballs from github and other > > repos. Possibly short-lived tarballs that are not available for download as > > long as the release tarballs. You end up with a source tarball that's 404 > > not found with no info on how to recreate it. > > I guess I would agree if the packager does it, but here, it's upstream, > linked from http://www.fresse.org/dateutils/. There's no upstream obligation > to preserve tarballs for _any_ releases forever, so I'm not sure why this > needs special handling. http://www.fresse.org/dateutils/ links to "Downloads" https://bitbucket.org/hroptatyr/dateutils/downloads and "latest snapshot" https://drone.io/github.com/hroptatyr/dateutils/files
Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.2.git35.3e322eb-4.fc22.mattdm.src.rpm Michael, these should address your concerns. Treats upstream version as version, and removes the short-name manpages.
> Okay, so I guess in this case I can just put all of 0.3.2.git35.3e322eb > as the version. Yes, that is what the guidelines "permit", if next release will be higher than that, e.g. 0.3.3. It may be a bit ugly to treat a "snapshot release" like a "real release", but that's not my point. > There's no upstream obligation to preserve tarballs for _any_ releases > forever, so I'm not sure why this needs special handling. Ask yourself why Fedora's snapshot tarball guidelines have been created? If none of that mattered, packagers could simply check out code from revision control, give it some pre-/post-release version, create a tarball and be done. > Re: comment 27 Sure it's linked there, but how long will the individual snapshot tarballs be available for download?
> Ask yourself why Fedora's snapshot tarball guidelines have been created? I think, primarily, because we want to deal in upstream artifacts, and a tarball created by the packager instead needs explanation. Particularly in the pre-git days, release tarballs were often only loosely coupled to whatever vcs the upstream used and might go through some undefined transformation, which would mean that packager-generated tarballs might be "off". When the tarball itself comes from upstream, that seems like less of a worry. And, again, how long will _any_ release be available from download from upstream? An upstream project could delete their old major release tarballs monthly; there's nothing really magically different.
Reproducibility/comparability. A snapshot Source URL giving 404 Not Found is no better than a tarball created by the packager. It may contain too many changes compared with the last/current official release. => It may get difficult to compare its contents with upstream sources, unless there is documentation about how to recreate the tarball. => It may get difficult to check the tarball contents for trojans (e.g.), if you don't know how to recreate the tarball from an uncompromised source code management system. > An upstream project could delete their old major release tarballs monthly; Or become the victim of a break-in, not knowing whether any tarball releases and the SCM contents have been modified. That has happened before. Tarball checksums and copies found in a distribution's package collection then may be helpful. The checkout date of a snapshot (which may differ a lot from an RPM %changelog date) then can be helpful, too. Comparing the checkout dates of two packages also is much more readable than comparing e.g. "git35" and "git36". It's good that we've talked about it.
Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.2.git37.96a5495-1.fc21.mattdm.src.rpm This updates to a new upstream snapshot which fixes the short-named man pages problem, and I've added a comment showing the git tree from which the snapshot comes, which I hope addresses Michael's concern adequately. Christopher, does this look good to go now?
(In reply to Matthew Miller from comment #32) > Christopher, does this look good to go now? I don't know what Christopher is thinking, but I would insist on you addressing this point Michael came up with: > Comparing the checkout dates of two packages also is much more readable than > comparing e.g. "git35" and "git36". Please check the FPG - We have guidelines in place addressing this topic.
Ralf, I believe the current naming to be compliant. Specifically, this is a upstream post-release package with a "properly ordered simple version", and the guidelines say * Properly ordered simple versions. These are usually due to quick bugfix releases, such as openssl-0.9.6b or gkrellm-2.1.7a. As new versions come out, the non-numeric tag is properly incremented (e.g. openssl-0.9.6c) or the numeric version is increased and the non-numeric tag is dropped (openssl-0.9.7). In this case, the non-numeric characters are permitted in the Version: field. I also expect this to be a moot point very shortly, whenever upstream 0.3.3 is released.
(In reply to Matthew Miller from comment #34) > Ralf, I believe the current naming to be compliant. I do not agree c.f. https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL The problem with your release number is them not being helpful in long terms when something happens to the repo.
(In reply to Ralf Corsepius from comment #35) > (In reply to Matthew Miller from comment #34) > > Ralf, I believe the current naming to be compliant. > I do not agree > > c.f. > https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL > > The problem with your release number is them not being helpful in long terms > when something happens to the repo. That seems like a completely separate issue, and not one covered by the packaging guidelines in this case. Again, this isn't "my" release number; it is an upstream post-release package, unmodified and with the number used as is. But that's okay. We can agree to disagree. I'll push for an upstream 0.3.3 release and then this won't be a concern.
It is non-trivial. The guidelines would need to be much more complex to cover all scenarios. They would grow to the size of a book and result in many more packager(s) preferring dumping grounds such as Fedora Copr where Fedora's Package Review Process can be avoided. [...] The internal version inside the source tarball is greater than 0.3.2 and lower than 0.3.3, so %{version} becoming 0.3.2 or 0.3.3 would not be entirely right either. Agreed? I hope so. [...] What may not be an immediate problem for "dateutils", can result in problems for other packages with similar upstream versions. Think of versioned dependencies related to automatic Provides, versions in pkgconfig files, versions in config tools, versions advertised by program option --version, versions retrievable via API methods and similar. How to handle the RPM package %version in all cases cannot be decided with a one-size-fits-all rule, i.e. one cannot blindly give a post-release snaphot a %version matching the next upstream version. It may not be compatible enough with that future release and possibly may not be compatible with the previously released version anymore either. When installing from upstream source tarballs, there is no version upgrade check as when using RPM packages. Files get overwritten by "make install". That's all. The internal version of an upstream source package may be lower than the previous install. The next version of a tarball snapshot may be lower. Unless upstream ensures that every new release, whether snapshot or not, introduces a version higher than an older versions. Whether that's the case and whether that versioning scheme can be mapped to RPM versioning, is a different story, but one reason why the guidelines exist. Simply switching to another service provider that generates nightly snapshots may introduce a different tarball versioning scheme that may require work-arounds for the RPM package versions published so far. Food for thought. IMHO, during review, the most important thing is to raise awareness of the problem and the guidelines. It may not be an issue for dateutils, if 0.3.3 is near, but that's not the point of talking about it.
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #37) > The internal version inside the source tarball is greater than 0.3.2 and > lower than 0.3.3, so %{version} becoming 0.3.2 or 0.3.3 would not be > entirely right either. Agreed? I hope so. Right. It is, in fact, version 0.3.2.git37.96a5495 — higher than 0.3.2, lower than 0.3.3, and the git## numbers sort properly, so this is exactly the situation in the guidelines as noted in Comment #34. I agree that other situations might have other complications, but this one seems to be provided for.
Update to 0.3.3. This should resolve all concerns about snapshot naming, since it isn't one. And I don't think we'll need to use snapshots in the future, as the main reason to do that was to bring the package into compliance with other issues we ironed out in this review. So, I think this should be good to go -- it ends up being a fairly straightforward specfile. Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.3-1.fc22.mattdm.src.rpm
Looks good. Only nit: %{dist} → %{?dist} Christopher?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #40) > Looks good. Only nit: %{dist} → %{?dist} Oops, not sure how that happened. Good catch. Spec URL: http://mattdm.org/misc/fedora/dateutils.spec SRPM URL: http://mattdm.org/misc/fedora/dateutils-0.3.3-2.fc22.mattdm.src.rpm
I'll finish the review, since it seems that all issues have been covered, and the package is rather simple, so it doesn't make sense to wait anymore. == Issues == LICENSE is duplicated in doc and licenses dirs. Not a show-stopper, but nice-to-fix. Changelog entry is missing. Looks good. Package is APPROVED. ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "BSD (3 clause)", "GPL (v2 or later)", "GPL (v3 or later)", "Unknown or generated". 40 files have unknown license. Detailed output of licensecheck in /var/tmp/review-dateutils/licensecheck.txt dateutils-0.3.3/src/dexpr-parser.[ch] is covered by the bison exception. dateutils-0.3.3/build-aux/* is only used in the build process. So BSD license is valid. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in dateutils [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 bytes in 2 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: 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]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: dateutils-0.3.3-2.fc23.x86_64.rpm dateutils-0.3.3-2.fc23.src.rpm dateutils.x86_64: W: incoherent-version-in-changelog 0.3.3-1 ['0.3.3-2.fc23', '0.3.3-2'] dateutils.src: W: invalid-url Source0: https://github.com/hroptatyr/dateutils/releases/download/v0.3.3/dateutils-0.3.3.tar.xz HTTP Error 403: Forbidden 2 packages and 0 specfiles checked; 0 errors, 2 warnings. Rpmlint (debuginfo) ------------------- Checking: dateutils-debuginfo-0.3.3-2.fc23.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- dateutils.x86_64: W: incoherent-version-in-changelog 0.3.3-1 ['0.3.3-2.fc23', '0.3.3-2'] 2 packages and 0 specfiles checked; 0 errors, 1 warnings. Requires -------- dateutils (rpmlib, GLIBC filtered): /bin/sh info libc.so.6()(64bit) libdl.so.2()(64bit) rtld(GNU_HASH) Provides -------- dateutils: dateutils dateutils(x86-64) Source checksums ---------------- https://github.com/hroptatyr/dateutils/releases/download/v0.3.3/dateutils-0.3.3.tar.xz : CHECKSUM(SHA256) this package : 3eb0b1dbf4519c86bc890a12c78cc85eae2cc10c20ff894a90ed55140efeee7a CHECKSUM(SHA256) upstream package : 3eb0b1dbf4519c86bc890a12c78cc85eae2cc10c20ff894a90ed55140efeee7a Generated by fedora-review 0.5.3 (bcf15e3) last change: 2015-05-04 Command line :/usr/bin/fedora-review -n dateutils Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, C/C++ Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
New Package SCM Request ======================= Package Name: dateutils Short Description: Command-line date and time calculation, conversion, and comparison Upstream URL: http://www.fresse.org/dateutils/ Owners: mattdm Branches: f21 f22 epel7 InitialCC:
Thanks Zbigniew! Any idea what's going on with the duplicate license thing? I'm not sure what's causing it, since I just have '%doc README.md'.
make install installs it: make[2]: Nothing to be done for 'install-exec-am'. test -z "/usr/share/doc/dateutils" || /usr/bin/mkdir -p "/builddir/build/BUILDROOT/dateutils-0.3.3-2.fc23.x86_64/usr/share/doc/dateutils" /usr/bin/install -c -m 644 README.md LICENSE '/builddir/build/BUILDROOT/dateutils-0.3.3-2.fc23.x86_64/usr/share/doc/dateutils' make[2]: Leaving directory '/builddir/build/BUILD/dateutils-0.3.3' and %doc implicitly adds the whole package doc dir to %files. I find this behaviour of %doc very annoying (and an endless source of errors). You'd have to %exclude it, or remove it.
You can just remove install it to the right location, like this: configure --docdir=%{_docdir}/%{name} and remove in file section use only %doc %{_docdir}/%{name}
> and %doc implicitly adds the whole package doc dir to %files. I find this behaviour of %doc very annoying (and an endless source of errors). Ugh; I thought it only did that if you specified 'doc/' explicitly. Thanks for the explanation.
Git done (by process-git-requests).
dateutils-0.3.3-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dateutils-0.3.3-3.fc22
dateutils-0.3.3-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dateutils-0.3.3-3.fc21
dateutils-0.3.3-3.fc22 has been pushed to the Fedora 22 testing repository.
dateutils-0.3.3-3.fc22 has been pushed to the Fedora 22 stable repository.
dateutils-0.3.3-3.fc21 has been pushed to the Fedora 21 stable repository.