[Bug 870853] New: Review Request: haven - Next Generation Backup System
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=870853
Bug ID: 870853
QA Contact: extras-qa(a)fedoraproject.org
Severity: medium
Clone Of: 768894
Version: rawhide
Priority: unspecified
CC: dbenini(a)gmail.com, dbenini(a)redhat.com,
leamas.alec(a)gmail.com, notting(a)redhat.com,
package-review(a)lists.fedoraproject.org,
tchollingsworth(a)gmail.com, tibbs(a)math.uh.edu,
turchi(a)ntsc.com
Assignee: nobody(a)fedoraproject.org
Summary: Review Request: haven - Next Generation Backup System
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: dbenini(a)gmail.com
Type: ---
Documentation: ---
Hardware: All
Mount Type: ---
Status: NEW
Component: Package Review
Product: Fedora
+++ This bug was initially created as a clone of Bug #768894 +++
Spec URL: http://www.dbenini.com/haven/fedora/haven.spec
SRPM URL: http://www.dbenini.com/haven/fedora/haven-0.0.2-2.fc16.src.rpm
Description:
SafeHaven is a next generation backup system, from desktop personal backup to
enterprise disaster recovery.
Features:
* Personal backup
* Enterprise backup
* Disaster recovery
* Heavy deduplication & compression
Notes:
- This is my first Fedora package and I'm looking for sponsorship.
- The package builds in mock.
--- Additional comment from dbenini(a)redhat.com on 2011-12-19 05:58:59 EST ---
rpmlint output:
haven.spec:57: W: configure-without-libdir-spec
haven.spec: W: invalid-url Source1: haven-icons-0.0.2.tar.gz
haven.spec: W: invalid-url Source0: haven-0.0.2.tar.gz
--- Additional comment from tchollingsworth(a)gmail.com on 2011-12-20 09:38:26
EST ---
(In reply to comment #1)
> haven.spec: W: invalid-url Source1: haven-icons-0.0.2.tar.gz
> haven.spec: W: invalid-url Source0: haven-0.0.2.tar.gz
If you can't provide the full URL to these sources in SourceN for some reason,
you need to add a comment indicating how to obtain them. For more information,
see:
http://fedoraproject.org/wiki/Packaging:SourceURL
You used "haven-gtkgui" as the subpackage for the GUI application, but most
Fedora packages use subpackages like "haven-gtk". Consider changing it to be
consistent with existing packages.
You call the "-full" subpackage the "Basic version" in the summary. I think
you got that backwards. ;-)
Also, consider briefly articulating the difference between the full and basic
versions in the %description, to assist users in deciding which one to install.
(See "yum info vim-minimal vim-enhanced" for an example.)
--- Additional comment from tchollingsworth(a)gmail.com on 2011-12-20 09:41:22
EST ---
One More Thing...unless the GUI is guaranteed to work with any version of the
software always and forever, you probably want to version that dependency,
e.g.:
Requires: haven = %{version}-%{release}
--- Additional comment from dbenini(a)redhat.com on 2011-12-24 14:48:47 EST ---
Hi T.C.,
thank you very much for the review.
I've made the suggested changes to the spec file and re-packaged the
application:
Spec URL: http://www.dbenini.com/haven/fedora/haven.spec
SRPM URL: http://www.dbenini.com/haven/fedora/haven-0.0.2-3.fc16.src.rpm
* Koji scratch build info:
https://koji.fedoraproject.org/koji/taskinfo?taskID=3603971
* rpmlint output:
$ rpmlint -v haven.spec
haven.spec:60: W: configure-without-libdir-spec
haven.spec: W: invalid-url Source1: haven-icons-0.0.2.tar.gz
haven.spec: I: checking-url
http://downloads.sourceforge.net/safe-haven/haven-0.0.2.tar.gz (timeout 10
seconds)
0 packages and 1 specfiles checked; 0 errors, 2 warnings.
$ rpmlint -v haven
haven.x86_64: I: checking
haven.x86_64: I: checking-url http://sourceforge.net/projects/safe-haven/
(timeout 10 seconds)
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint -v haven-enhanced
haven-enhanced.x86_64: I: checking
haven-enhanced.x86_64: I: checking-url
http://sourceforge.net/projects/safe-haven/ (timeout 10 seconds)
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint -v haven-gtk
haven-gtk.x86_64: I: checking
haven-gtk.x86_64: I: checking-url http://sourceforge.net/projects/safe-haven/
(timeout 10 seconds)
haven-gtk.x86_64: W: no-documentation
haven-gtk.x86_64: W: no-manual-page-for-binary ghaven
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
--- Additional comment from jamielinux(a)fedoraproject.org on 2012-02-08 06:39:24
EST ---
Some comments:
1) BuildRoot tag is no longer required
2) Removing %{buildroot} in the %install section is no longer required
3) %clean section no longer required
4) defattr in %files section is no longer required
--- Additional comment from dbenini(a)redhat.com on 2012-02-12 18:51:58 EST ---
Thank you Jamie,
I removed useless sections and tags as suggested.
* Updated spec file and source RPM:
Spec URL: http://www.dbenini.com/haven/fedora/haven.spec
SRPM URL: http://www.dbenini.com/haven/fedora/haven-0.0.2-4.fc16.src.rpm
* Koji scratch build info:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3784798
--- Additional comment from leamas.alec(a)gmail.com on 2012-02-23 06:24:17 EST
---
No, I'm no reviewer. Still, I have some remarks and questions:
The upstream version is 0.0.2, whereas the specfile's version is 0_0_2,
indirectly set using a macro. Basically, the Version: tag should reflect
the upstream version i. e. "Version: 0.0.2". Note that from that point
an implicit %{version} macro is defined, which you can use to derive
0_0_2 which is used in many places.
The "%global _configure ../../configure" macro is not used and can be removed.
The %{__mkdir_p} type of macros are not used in Fedora, plain 'mkdir -p' is
fine
See http://fedoraproject.org/wiki/Packaging:Guidelines#macros
The source seems to be GPLv3 or later i. e., "License: GPLv3+" ?
Backup software is sensitive... Maybe you should enable PIE? See
http://fedoraproject.org/wiki/Packaging:Guidelines#PIE
Why have you called the desktop file ghaven.desktop? The normal convention
is to use the package name i. e., haven.desktop or haven-gtk.desktop? The
same question applies to the icons.
In the %files section, you have entries like %{_mandir}/man1/haven.1.gz.
These are better written %{_mandir}/man1/*, partly for simplicity, partly
because the .gz suffix might change in the future.
Since the %check target is empty, you might as well remove it.
You have a configure-without-libdir-spec warning. Add --libdir=%{_libdir} to
the configure calls so that configure knows where to install (lib/lib64).
You have an empty-debuginfo-package rpmlint warning. This might be because of
the install-strip targets used, if they indeed strip the code. Basically,
you should not strip the code but instead build it with debugging enabled.
rpmbuild strips it while postprocessing, using the debuginfo in the debug
package.
Hope this helps,
--a
--- Additional comment from mschwendt(a)gmail.com on 2012-03-21 17:02:39 EDT ---
Non-trivial to review because a few more iterations will be needed, it seems.
> The upstream version is 0.0.2, whereas the specfile's version is 0_0_2,
> indirectly set using a macro.
Not true. Let's take a look:
| %global src_verstr 0.0.2
| %global rpm_verstr %(echo %src_verstr | sed -e 's/-/_/g')
|
| Version: %rpm_verstr
It would substitute '-' with '_', but currently there is no '-' in "0.0.2".
This has been taken over from the spec included in the tarball.
It's dubious for a few reasons.
If the upstream version string ever contained a '-', the entire version would
need to be mapped into Fedora's versioning schemes. (For example: 0.0.2-beta1
=> apply Fedora's pre-release versioning scheme, which is *not* 0.0.2_beta1.)
In general, it can be beneficial to do
%global tar_ver 0.0.2
Version: 0.0.2
...
if %tar_ver frequently contains stuff like "-alphaX", "-rcX", which need to be
moved into the %release value. Then one can use the different %tar_ver and
%version in other places of the spec file.
What shouldn't be done is something close to
%global version 0.0.2
Version: %version
because the "Version" tag already defines %version, and it makes no sense to
redefine it.
An example from the spec that can lead to problems:
> Requires: %{name} = %{src_verstr}-%{release}
Here you should use %version instead of %src_verstr, or else you could not
split wisely between RPM-compatible and Fedora-compatible version values and
upstream version values.
Btw, the following applies, too:
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
But why do the subpackages depend on the "haven" package? Is it for files in
that package? A comment in the spec should explain the dependency.
> Requires(post): /usr/bin/gtk-update-icon-cache
> Requires(postun): /usr/bin/gtk-update-icon-cache
That's not Fedora's way to add such dependencies:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
> The "%global _configure ../../configure" macro is not used and can
> be removed.
It _is_ used to alter the %configure macro.
> You have a configure-without-libdir-spec warning. Add --libdir=%{_libdir}
rpmlint false positive, it seems.
> %description
> Haven backup system.
>
> Next Generation Backup System, from desktop personal backup to
> Enterprise Disaster Recovery.
This description is somewhat strange. No full sentences and weird usage of
uppercase characters. Why not
"Haven aims at becoming a next generation backup system, from desktop personal
backup to enterprise-class disaster recovery."
> %install
...
> mv "icons" "%{buildroot}/%{_datadir}/"
Caution! Please don't break --short-circuit installs. Copy or install files
from within the build dir, don't move them.
--- Additional comment from dbenini(a)redhat.com on 2012-03-23 09:19:43 EDT ---
Alec, Michael,
thank you for your comments.
I will analyse your suggestions (and discuss some of them with upstream) and
then I'll come back with a new version of the package.
--- Additional comment from tibbs(a)math.uh.edu on 2012-07-03 22:35:15 EDT ---
So, over three months later, was there ever any progress here?
--- Additional comment from dbenini(a)redhat.com on 2012-07-08 17:39:07 EDT ---
Sorry for the long delay,
I've made the following changes to the spec file and re-packaged the
application:
- removed macro forms of system executables, i.e. %{__mkdir_p} macros
- changed license from GPLv3 to GPLv3+
- enabled PIE
- replaced .gz man files suffix with .* in %files section
- removed %check target since it was empty
- replaced "install-strip" make rule with plain "install"
- removed %src_verstr and %rpm_verstr definition to avoid confusion.
%src_verstr will be reintroduced if necessary, but at the moment only %version
is used
- removed subpackages dependency from the "haven" (base) package including
licence texts in each subpackage
- removed /usr/bin/gtk-update-icon-cache requirement
- changed description
- files are now copied, not moved, from within the build dir
* Updated spec file and source RPM:
Spec URL: http://www.dbenini.com/haven/fedora/haven.spec
SRPM URL: http://www.dbenini.com/haven/fedora/haven-0.0.2-5.fc16.src.rpm
* Koji scratch build info:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4225990
--- Additional comment from mschwendt(a)gmail.com on 2012-09-08 18:44:28 EDT ---
When I wanted to take another look at it, it failed to build for Fedora 17 due
to the header changes in glib2 ("Only <glib.h> can be included directly.").
--- Additional comment from tibbs(a)math.uh.edu on 2012-10-01 11:38:13 EDT ---
Indeed, fails to build for me in rawhide as well.
--- Additional comment from dbenini(a)gmail.com on 2012-10-10 18:53:18 EDT ---
Hi all,
Unfortunately my previous Bugzilla account has been disabled and I'm still
trying to figure out how to move this package review to my new account.
Anyway, I fixed the Fedora 17+ build issue:
Spec URL: http://www.dbenini.com/haven/fedora/haven.spec
SRPM URL: http://www.dbenini.com/haven/fedora/haven-0.0.2-6.fc17.src.rpm
* Koji scratch build info:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4575069
http://koji.fedoraproject.org/koji/taskinfo?taskID=4575082
http://koji.fedoraproject.org/koji/taskinfo?taskID=4575129
--- Additional comment from mschwendt(a)gmail.com on 2012-10-11 11:36:08 EDT ---
Since mere mortals cannot change the "Reporter" field in bugzilla, one way to
transfer the ticket to you would be to clone it,
https://bugzilla.redhat.com/enter_bug.cgi?cloned_bug_id=768894
and then continue there.
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 10 months
[Bug 1331818] New: Review Request: singularity - Portable
application stack packaging and runtime utility
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1331818
Bug ID: 1331818
Summary: Review Request: singularity - Portable application
stack packaging and runtime utility
Product: Fedora
Version: rawhide
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: d.love(a)liverpool.ac.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Spec URL: https://loveshack.fedorapeople.org/review/singularity.spec
SRPM URL:
https://loveshack.fedorapeople.org/review/singularity-1.0-6.e7409ff5.el6....
Description:
Singularity is a portable application stack packaging and runtime utility.
There are several methods to implement portable application stacks at
present. Among them are containers and virtual machines. When using these
solutions to package a single application (or application stack), one ends
up having to manage the entire operating system overhead (security, updates,
size/bulk, etc..) just to distribute a single application or workflow. While
virtual machines and containers have strong usage benefits, application
portability and distribution is not an efficient use of these technologies.
Singularity works on a completely different perspective. Contrary to building
and managing an entire operating system environment (for the sake of
portability and reproducibility of an application stack), Singularity works
on the opposite premise. By configuration of an application stack spec via a
configuration file, coupled with automatic dependency resolution to achieve
portability, Singularity can create minimalistic singlet "app" which can
easily be copied from system to system and run using Singularity on different
systems.
Fedora Account System Username: loveshack
Builds: https://copr.fedorainfracloud.org/coprs/loveshack/livhpc/build/181964/
and https://copr.fedorainfracloud.org/coprs/loveshack/livhpc/build/181966/
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
6 years, 10 months
[Bug 1429680] New: Container Review Request:
httpd - Platform for running Apache HTTP Server
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1429680
Bug ID: 1429680
Summary: Container Review Request: httpd - Platform for running
Apache HTTP Server
Product: Fedora
Version: rawhide
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: hhorak(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Dockerfile URL: https://hhorak.fedorapeople.org/httpd-docker/Dockerfile
Other files URL: https://hhorak.fedorapeople.org/httpd-docker/
Description: Apache HTTP 2.4 available as docker container, is a powerful,
efficient, and extensible web server. Apache supports a variety of features,
many implemented as compiled modules which extend the core functionality.
These can range from server-side programming language support to authentication
schemes. Virtual hosting allows one Apache installation to serve many different
Web sites.
You can find more information on the Apache HTTP Server project from the
project Web site (https://httpd.apache.org).
Fedora Account System Username: hhorak
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
6 years, 10 months