Bug 1111691 - Review Request: qore - multithreaded programming/scripting language
Review Request: qore - multithreaded programming/scripting language
Status: NEW
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-NEEDSPONSOR
  Show dependency treegraph
 
Reported: 2014-06-20 14:16 EDT by David Nichols
Modified: 2015-09-08 01:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Nichols 2014-06-20 14:16:28 EDT
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11-1.fc20.src.rpm
Description: Qore is a scripting language supporting threading and embedded logic/sandboxing, designed for applying a flexible scripting-based approach to enterprise interface development but is also useful as a general purpose language.
Fedora Account System Username: davidnichols

This is my first package request, and I will be needing a sponsor.

I've been building RPMs for redhat and Fedora (and other RPM-based distributions) for some time; I have read the Fedora packaging guidelines and tested the source and binary RPMs files with rpmlint (there are still a few warnings; I hope nothing serious), so I hope that the qore packages will be accepted into Fedora.

There are some warnings in the libqore5 package regarding Provides: lines, but these are needed due to the way that the qore library works with binary modules loaded at runtime; basically there is are internal API versions that are matched between the library and the module, and the Provides: lines (along with  Requires: lines the the module spec files) allow the rpm system to correctly determine if dependencies are matched between the qore library's internal API code and the one that the module requires.  Basically the qore library supports many internal API versions allowing it to load modules linked with older versions of the library.

Also please note that I am also the upstream developer of the package and the spec file is part of the distribution.

I use Fedora on all my Linux machines (work & home) and would be happy to become the maintainer of this package, if that would be possible.

I will try to resolve any issues found in the package review ASAP.

Thanks a lot for your patience with my first package request to Fedora.

thanks,
David
Comment 1 Jason Taylor 2014-06-20 20:46:27 EDT
Hi David,

I would take a look at https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL for your Source URL information.

http://fedoraproject.org/wiki/Packaging:DistTag also provides some information on conditionals to clean up the rh_dist you define in the spec.

I am not sure if the suse/sles related conditional logic is allowable since it isn't pertinent, someone else may be able to offer insight.

The duplicate License: declaration also seems unnecessary

%defattr is unnecessary

%clean is unnecessary unless supporting el5

http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean
Comment 2 Christopher Meng 2014-06-20 22:29:28 EDT
Please drop those futile opensuse macros in Fedora packages.
Comment 3 Christopher Meng 2014-06-20 23:12:59 EDT
More detailed initial review thought(Note you need a sponsor, I can't help, I will address this at the end):

1. The packaging style looks like a decade ago.

%define qore_ver 0.8.11

You should put 0.8.11 in Version tag and use %{version} instead of custom macro, we have some fundamental macros which you should avoid using custom macro replaced

2. I don't think you've read the guideline, for example, %define -> %global:

https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define

3. Remove those non-Fedora conditional bits:

4. # see if we can determine the distribution type
%if 0%{!?dist:1}
%define rh_dist %(if [ -f /etc/redhat-release ];then cat /etc/redhat-release|sed "s/[^0-9.]*//"|cut -f1 -d.;fi)
%if 0%{?rh_dist}
%define dist .rhel%{rh_dist}
%else

---------

Please learn how to use macro %{?el}/%{?fedora}

4. Drop obsoleted RPM macros which are still heavily used by other distros:

BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%defattr(-,root,root,-)

%clean

%defattr(-,root,root,-)

5. You are polluting dist tag:

http://fedoraproject.org/wiki/Packaging:DistTag

6. Drop BuildRequires: gcc-c++:

https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

7. Never make BuildRequires: fdupes in any Fedora specs, we don't need it.

8. You should avoid packaging libraries with version as its package name:

libqore5

You'd better change it to libqore or qore-libs

9. I still don't understand those Provides:  in libqore, can't RPM handle this?

10. %ifarch x86_64 ppc64 x390x
c64=--enable-64bit
%endif
# need to configure with /usr as prefix as this will be used to derive the module directory
./configure RPM_OPT_FLAGS="$RPM_OPT_FLAGS" --prefix=/usr --disable-debug --disable-static $c64 --libdir=%{_libdir}

a) %configure macro should be used

b) Does qore work on ARM? We will have AArch64(ARM v8) in the future.

11. /usr/bin/ -> %{_bindir}

%{_prefix}/include/ -> %{_includedir}

/usr/share/man/ -> %{_mandir}

I think you don't need to care about RHEL5 nowadays.

12. Why not merge 2 doc packages into 1 -doc?

13. mkdir -p $RPM_BUILD_ROOT/usr/bin
mkdir -p $RPM_BUILD_ROOT/%{module_dir}/%{qore_ver}
mkdir -p $RPM_BUILD_ROOT/usr/man/man1

I think install script should do that(create in install script or with install -p), since you are the upstream, these could be enhanced.

13. https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

14. %post -n libqore5
ldconfig %{_libdir}

%postun -n libqore5
ldconfig %{_libdir}

http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries

------------------------------------
Anyway, read and follow this if you want to be sponsored:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Comment 4 David Nichols 2014-06-21 09:34:45 EDT
(In reply to Jason Taylor from comment #1)
> Hi David,
> 
> I would take a look at
> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL
> for your Source URL information.

ok done

> 
> http://fedoraproject.org/wiki/Packaging:DistTag also provides some
> information on conditionals to clean up the rh_dist you define in the spec.
> 

ok done

> I am not sure if the suse/sles related conditional logic is allowable since
> it isn't pertinent, someone else may be able to offer insight.

ok removed

> 
> The duplicate License: declaration also seems unnecessary
> 
> %defattr is unnecessary
> 
> %clean is unnecessary unless supporting el5
> 
> http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean

ok - all done

thanks very much for the excellent review and help!

David
Comment 5 David Nichols 2014-06-21 09:35:32 EDT
(In reply to Christopher Meng from comment #2)
> Please drop those futile opensuse macros in Fedora packages.

ok - done

I wanted to have one spec file for all rpm-based distros, but since it's a problem I've made a spec file just for fedora/rhel

thanks
david
Comment 6 David Nichols 2014-06-21 09:51:16 EDT
(In reply to Christopher Meng from comment #3)
> More detailed initial review thought(Note you need a sponsor, I can't help,
> I will address this at the end):
> 
> 1. The packaging style looks like a decade ago.
> 
> %define qore_ver 0.8.11
> 
> You should put 0.8.11 in Version tag and use %{version} instead of custom
> macro, we have some fundamental macros which you should avoid using custom
> macro replaced
> 

you are right, this spec file was born a long time ago.

this has been fixed

> 2. I don't think you've read the guideline, for example, %define -> %global:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#.
> 25global_preferred_over_.25define
> 

I did not read them closely enough, you are right.

this is now fixed.

> 3. Remove those non-Fedora conditional bits:
> 

sll removed

> 4. # see if we can determine the distribution type
> %if 0%{!?dist:1}
> %define rh_dist %(if [ -f /etc/redhat-release ];then cat
> /etc/redhat-release|sed "s/[^0-9.]*//"|cut -f1 -d.;fi)
> %if 0%{?rh_dist}
> %define dist .rhel%{rh_dist}
> %else
> 
> ---------
> 
> Please learn how to use macro %{?el}/%{?fedora}
> 

fixed

> 4. Drop obsoleted RPM macros which are still heavily used by other distros:
> 
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
> 
> %defattr(-,root,root,-)
> 
> %clean
> 
> %defattr(-,root,root,-)
> 

removed / fixed

> 5. You are polluting dist tag:
> 
> http://fedoraproject.org/wiki/Packaging:DistTag
> 

ok done

> 6. Drop BuildRequires: gcc-c++:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2
> 

dropped / done

> 7. Never make BuildRequires: fdupes in any Fedora specs, we don't need it.
> 

removed (was there for opensuse)

> 8. You should avoid packaging libraries with version as its package name:
> 
> libqore5
> 
> You'd better change it to libqore or qore-libs
> 

changed to libqore for fedora / rhel

> 9. I still don't understand those Provides:  in libqore, can't RPM handle
> this?
> 

actually, no (at least not AFAIK).  the Provides are there so that qore binary modules, which are loaded at runtime by libqore, can be matched with the module ABI of the qore library.

I plan on making submission requests for qore module packages later (hopefully after I can get sponsorship to main qore for Fedora - I realize that this is not a given and anyway will take time and commitment on my part).  There are quiet a few of these already.

The modules then will declare Requires: for the specific module API that they are compiled against.  These modules will be binary-loadable by future libqore packages that declare the old module ABI.  The RPM system then will not complain when libqore is upgraded and a module compiled against a previous version of qore (and using an older, but still compatible qore module ABI) is still on the system.

Otherwise without this mechanism, I would have to add an explicit dependency to libqore in the modules' spec files, which would be more restrictive than what is actually necessary, since future versions of libqore normally maintain ABI compatibility with earlier versions.

It was my impression that the spec files Provides: lines for such artificial dependencies was to handle this sort of situation.

> 10. %ifarch x86_64 ppc64 x390x
> c64=--enable-64bit
> %endif
> # need to configure with /usr as prefix as this will be used to derive the
> module directory
> ./configure RPM_OPT_FLAGS="$RPM_OPT_FLAGS" --prefix=/usr --disable-debug
> --disable-static $c64 --libdir=%{_libdir}
> 
> a) %configure macro should be used
> 
> b) Does qore work on ARM? We will have AArch64(ARM v8) in the future.
> 

I have moved all the 64-bit detection stuff to configure and added support for 64-bit ARM (aarch64)

> 11. /usr/bin/ -> %{_bindir}
> 
> %{_prefix}/include/ -> %{_includedir}
> 
> /usr/share/man/ -> %{_mandir}
> 
> I think you don't need to care about RHEL5 nowadays.
> 

done - removed

> 12. Why not merge 2 doc packages into 1 -doc?
> 

The reason for this is because the devel-doc package is only needed for programmers programming against the C++ API (ie for qore binary modules).  This doc package is large, but most users won't need it (I expect).

Most users will only need the doc package, which has the Qore documentation telling programmer's how to program in the Qore language.

So From my point of view it makes sense to have two packages for the two very different kinds of documentation provided by qore.

However, if this is a blocking issue for acceptance by Fedora, then let me know, and I will merge them both.

> 13. mkdir -p $RPM_BUILD_ROOT/usr/bin
> mkdir -p $RPM_BUILD_ROOT/%{module_dir}/%{qore_ver}
> mkdir -p $RPM_BUILD_ROOT/usr/man/man1
> 
> I think install script should do that(create in install script or with
> install -p), since you are the upstream, these could be enhanced.
> 

you are right, this was not necesary, configure generates a Makefile that performs these actions automatically.

This has been removed from the spec file.

> 13.
> https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
> 

done

> 14. %post -n libqore5
> ldconfig %{_libdir}
> 
> %postun -n libqore5
> ldconfig %{_libdir}
> 
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries
> 

done

> ------------------------------------
> Anyway, read and follow this if you want to be sponsored:
> 
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

thanks for that!  I had indeed read that and had already verified my package with a koji scratch build.

I plan on following up on the other activities recommended for achieving sponsorship in the near future.

I realize that this will take some time, and that I will need to demonstrate a commitment to Fedora's processes and quality standards.

Thank you very much for your very detailed review and the time you took to make it.

I very much appreciate it.

The new SRPM and spec file have been uploaded to the URLs above (copied here) with all the changes from the comments here.

- Spec URL: http://qore.org/srpms/qore.spec
- SRPM URL: http://qore.org/srpms/qore-0.8.11-1.fc20.src.rpm

thanks,
David
Comment 7 Michael Schwendt 2014-06-21 10:17:49 EDT
https://fedoraproject.org/wiki/Packaging:FrequentlyMadeMistakes

| Increase the "Release" tag every time you upload a new package to avoid
| confusion. The reviewer and other interested parties probably still have
| older versions of your SRPM lying around to check what has changed between
| the old and new packages; those get confused when the revision didn't change. 

The %changelog also doesn't document any of the changes you've supplied.
https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs


> mv $RPM_BUILD_DIR/%{name}-%{version}/test $RPM_BUILD_DIR/%{name}-%{version}/examples

"mv test examples" should suffice.

At the beginning of each of the main spec file sections, you are within the primary builddir already as specified via %setup (or its default -n %name-%version).


> %configure --disable-debug --disable-static

This belongs at the beginning of the %build section.
Also see "rpm -E %configure".


> %build
> %{__make}

https://fedoraproject.org/wiki/Packaging:Guidelines#Parallel_make


> %package doc
> Summary: API documentation, programming language reference, and Qore example programs
> Group: Development/Languages

Rather "Group: Documentation" unless you want to drop the Group tag altogether:
https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag

> Requires: libqore%{?_isa} = %{version}-%{release}

Plain documentation packages (which contain files that can be displayed with arbitrary HTML/PDF viewers) typically do not need to depend on base libraries, or else you could not install the documentation without pulling in dependency bloat.


> %package -n libqore
> Summary: The libraries for the qore runtime and qore clients
> Group: Development/Languages

The Group tag for runtime library base packages has been "System Environment/Libraries" for many years.


> %package devel
> Summary: The header files needed to compile programs using the qore library
> Group: Development/Languages

The Group tag for build-time library -devel packages has been "Development/Libraries" for many years.


> Provides: qore-module-api-0.18
> Provides: qore-module-api-0.17
> Provides: qore-module-api-0.16
> Provides: qore-module-api-0.15
> Provides: qore-module-api-0.14
> Provides: qore-module-api-0.13
> Provides: qore-module-api-0.12
> Provides: qore-module-api-0.11
> Provides: qore-module-api-0.10
> Provides: qore-module-api-0.9
> Provides: qore-module-api-0.8
> Provides: qore-module-api-0.7
> Provides: qore-module-api-0.6
> Provides: qore-module-api-0.5

Odd. And rather limited. You could not do "Requires: qore-module-api >= 0.10", for example. Why not

  Provides: qore-module(api) = 0.5
  Provides: qore-module(api) = 0.6
  Provides: qore-module(api) = 0.7
  ...

and so on?

[...]

Have you pointed the fedora-review tool at this ticket yet?
"fedora-review -b 1111691"
Comment 8 Michael Schwendt 2014-06-21 10:25:41 EDT
> %package doc

Plus, documentation very often is not arch-specific, so a -doc subpackage could be "BuildArch: noarch". In that case, an arch-specific dependency on a library base package would not be possibly anyway.
Comment 9 David Nichols 2014-06-21 11:51:19 EDT
(In reply to Michael Schwendt from comment #7)
> https://fedoraproject.org/wiki/Packaging:FrequentlyMadeMistakes
> 
> | Increase the "Release" tag every time you upload a new package to avoid
> | confusion. The reviewer and other interested parties probably still have
> | older versions of your SRPM lying around to check what has changed between
> | the old and new packages; those get confused when the revision didn't
> change. 

done - new URLs below

> 
> The %changelog also doesn't document any of the changes you've supplied.
> https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
> 

ok done

> 
> > mv $RPM_BUILD_DIR/%{name}-%{version}/test $RPM_BUILD_DIR/%{name}-%{version}/examples
> 
> "mv test examples" should suffice.
> 
> At the beginning of each of the main spec file sections, you are within the
> primary builddir already as specified via %setup (or its default -n
> %name-%version).
> 

ok, thanks, done

> 
> > %configure --disable-debug --disable-static
> 
> This belongs at the beginning of the %build section.
> Also see "rpm -E %configure".
> 

done

> 
> > %build
> > %{__make}
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Parallel_make
> 
> 

ok done

> > %package doc
> > Summary: API documentation, programming language reference, and Qore example programs
> > Group: Development/Languages
> 
> Rather "Group: Documentation" unless you want to drop the Group tag
> altogether:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag
> 

ok done

> > Requires: libqore%{?_isa} = %{version}-%{release}
> 
> Plain documentation packages (which contain files that can be displayed with
> arbitrary HTML/PDF viewers) typically do not need to depend on base
> libraries, or else you could not install the documentation without pulling
> in dependency bloat.
> 
> 

ok done

> > %package -n libqore
> > Summary: The libraries for the qore runtime and qore clients
> > Group: Development/Languages
> 
> The Group tag for runtime library base packages has been "System
> Environment/Libraries" for many years.
> 
> 

ok fixed

> > %package devel
> > Summary: The header files needed to compile programs using the qore library
> > Group: Development/Languages
> 
> The Group tag for build-time library -devel packages has been
> "Development/Libraries" for many years.
> 
> 

ok done

> > Provides: qore-module-api-0.18
> > Provides: qore-module-api-0.17
> > Provides: qore-module-api-0.16
> > Provides: qore-module-api-0.15
> > Provides: qore-module-api-0.14
> > Provides: qore-module-api-0.13
> > Provides: qore-module-api-0.12
> > Provides: qore-module-api-0.11
> > Provides: qore-module-api-0.10
> > Provides: qore-module-api-0.9
> > Provides: qore-module-api-0.8
> > Provides: qore-module-api-0.7
> > Provides: qore-module-api-0.6
> > Provides: qore-module-api-0.5
> 
> Odd. And rather limited. You could not do "Requires: qore-module-api >=
> 0.10", for example. Why not
> 
>   Provides: qore-module(api) = 0.5
>   Provides: qore-module(api) = 0.6
>   Provides: qore-module(api) = 0.7
>   ...
> 
> and so on?
> 
> [...]

ok, this makes sense.  The reason I did not do it like this before is because I did not come up with this solution when I was first researching this topic.

however there are already a set of dependent module RPMs out in the wild (for Fedora, RHEL, and other distributions) that assume the old non-versioned Provides: are available.

I would be happy to change it, because I agree that it looks better/cleaner, however I'm afraid of breaking the existing RPMs.

So I'm not sure what to do here - any advice you can give would be greatly appreciated.

> 
> Have you pointed the fedora-review tool at this ticket yet?
> "fedora-review -b 1111691"

I'm running it now against the new SRPM and spec file with: "fedora-review -n qore".  It's still running at the moment, so I'll react when I get some output.

Thanks for this tip; I did not know about this until now.

Thanks a lot for your in-depth review and excellent constructive comments.  My packaging knowledge is slowly improving with the state of the qore packaging for Fedora.

URLs with updated spec and new SRPM:
- Spec URL: http://qore.org/srpms/qore.spec
- SRPM URL: http://qore.org/srpms/qore-0.8.11-2.fc20.src.rpm

thanks,
David
Comment 10 David Nichols 2014-06-21 12:16:49 EDT
(In reply to Michael Schwendt from comment #8)
> > %package doc
> 
> Plus, documentation very often is not arch-specific, so a -doc subpackage
> could be "BuildArch: noarch". In that case, an arch-specific dependency on a
> library base package would not be possibly anyway.

thanks, excellent tip, this was also done in revision 2 as in the links above.

Also I finished running fedora-review on the updated SRPM and spec, and as far as I can see from that output the only thing left to resolve (besides what I hope are minor/acceptable rpmlint warnings) is the Provides: lines for the library ABIs.  As I mentioned before, I'm not sure what to do about those without causing problems with older module RPMs.

thanks,
David
Comment 11 David Nichols 2014-06-22 03:08:50 EDT
(In reply to Michael Schwendt from comment #7)
> Odd. And rather limited. You could not do "Requires: qore-module-api >=
> 0.10", for example. Why not
> 
>   Provides: qore-module(api) = 0.5
>   Provides: qore-module(api) = 0.6
>   Provides: qore-module(api) = 0.7
>   ...
> 
> and so on?

Also I have to say that this would have just a cosmetic benefit.  Module APIs (in reality they are ABIs) are not necessarily backwards-compatible.  

Each module will always only declare one Requires: line for the particular ABI it needs.  It's libqore that will declare all the ABIs it supports with the Provides: declarations that allow the RPM system to manage the dependencies properly.

Therefore something like:
Requires: qore-module-api >= 0.10

would not be used anyway, since 0.11 or higher may not be compatible with 0.10.  What the RPM system needs is to know that ABI 0.10 is supported by libqore, which is provided by the Provides: line (now Provides: qore-module-api-0.10).

So this is a much better explanation of why I'm using unversioned artificial dependencies.

I had gone through this so many years ago that I had forgotten the reasoning behind it until I thought it through again now.

thanks,
David
Comment 12 Michael Schwendt 2014-06-22 05:27:05 EDT
Versioned Provides do not imply that you must use '>='. It would be perfectly acceptable to only use '=' in dependencies.

  $ rpm -q --provides audacious-libs|grep api
  audacious(plugin-api) = 40
  audacious(plugin-api) = 41
  audacious(plugin-api) = 42
  audacious(plugin-api) = 43
  audacious(plugin-api)(x86-64) = 40
  audacious(plugin-api)(x86-64) = 41
  audacious(plugin-api)(x86-64) = 42
  audacious(plugin-api)(x86-64) = 43

  $ repoquery --whatrequires 'audacious(plugin-api)(x86-64)'|wc -l
  19

All require the latest API version 43:

  $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) == 43'|wc -l
  19

Versioned capabilities, however, allow for versioned queries with "rpm", repoquery and other package tools (if not considering Requires, Obsoletes, Conflicts and BuildRequires):

Does anything in the repos support a newer plugin API already? For example, the next development release in alternative packages?

  $ repoquery --whatprovides 'audacious(plugin-api)(x86-64) > 43'|wc -l 
  0

Apparently not.

Does anything in the repos support an older plugin API? For example, a compat package?

  $ repoquery --whatprovides 'audacious(plugin-api)(x86-64) < 40'|wc -l
  0

Apparently not.

Assume we need to drop support for API 41 and older, does anything in the repo require any old Plugin API?

  $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) <= 41' |wc -l
  0

Apparent not.

Assume the next release drops support for API older than 50, does anything in the repo still require any older API?

  $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) < 50'|wc -l
  19

All, but 3rd party repos not included in the query.

[...]

I don't claim the "Provides: qore-module-api-0.18" is not sufficient for what it is being used so far -- an exact dependency on that thing. There are 14 such Provides in the package already. There is a version in them, but in the wrong place. That's unusual and inconvenient.

What to do about it also depends on 3rd party packages that already use these strict dependencies and how many shall be included in the package collection. In that case, proper Obsoletes tags would need to be added anyway. There could also be a transition to versioned Provides only for new API versions, while the old ones would be kept as long as they will still be supported.

[...]

Any comment on fedora-review licensecheck.txt and rpmlint.txt?

Plus:

* https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
Comment 13 David Nichols 2014-06-22 10:22:04 EDT
(In reply to Michael Schwendt from comment #12)
> Versioned Provides do not imply that you must use '>='. It would be
> perfectly acceptable to only use '=' in dependencies.
> 
>   $ rpm -q --provides audacious-libs|grep api
>   audacious(plugin-api) = 40
>   audacious(plugin-api) = 41
>   audacious(plugin-api) = 42
>   audacious(plugin-api) = 43
>   audacious(plugin-api)(x86-64) = 40
>   audacious(plugin-api)(x86-64) = 41
>   audacious(plugin-api)(x86-64) = 42
>   audacious(plugin-api)(x86-64) = 43
> 
>   $ repoquery --whatrequires 'audacious(plugin-api)(x86-64)'|wc -l
>   19
> 
> All require the latest API version 43:
> 
>   $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) == 43'|wc -l
>   19
> 
> Versioned capabilities, however, allow for versioned queries with "rpm",
> repoquery and other package tools (if not considering Requires, Obsoletes,
> Conflicts and BuildRequires):
> 
> Does anything in the repos support a newer plugin API already? For example,
> the next development release in alternative packages?
> 
>   $ repoquery --whatprovides 'audacious(plugin-api)(x86-64) > 43'|wc -l 
>   0
> 
> Apparently not.
> 
> Does anything in the repos support an older plugin API? For example, a
> compat package?
> 
>   $ repoquery --whatprovides 'audacious(plugin-api)(x86-64) < 40'|wc -l
>   0
> 
> Apparently not.
> 
> Assume we need to drop support for API 41 and older, does anything in the
> repo require any old Plugin API?
> 
>   $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) <= 41' |wc -l
>   0
> 
> Apparent not.
> 
> Assume the next release drops support for API older than 50, does anything
> in the repo still require any older API?
> 
>   $ repoquery --whatrequires 'audacious(plugin-api)(x86-64) < 50'|wc -l
>   19
> 
> All, but 3rd party repos not included in the query.
> 
> [...]
> 
> I don't claim the "Provides: qore-module-api-0.18" is not sufficient for
> what it is being used so far -- an exact dependency on that thing. There are
> 14 such Provides in the package already. There is a version in them, but in
> the wrong place. That's unusual and inconvenient.
> 
> What to do about it also depends on 3rd party packages that already use
> these strict dependencies and how many shall be included in the package
> collection. In that case, proper Obsoletes tags would need to be added
> anyway. There could also be a transition to versioned Provides only for new
> API versions, while the old ones would be kept as long as they will still be
> supported.
> 
> [...]
>

OK I have updated the package to use the versioned capabilities and declare the old unversioned capabilities obsolete.

the new declarations are as follows:

Provides: qore-module(abi) = 0.18
Obsoletes: libqore5 < 0.8.12
Obsoletes: qore-module-api-0.18
Obsoletes: qore-module-api-0.17
Obsoletes: qore-module-api-0.16
Obsoletes: qore-module-api-0.15
Obsoletes: qore-module-api-0.14
Obsoletes: qore-module-api-0.13
Obsoletes: qore-module-api-0.12
Obsoletes: qore-module-api-0.11
Obsoletes: qore-module-api-0.10
Obsoletes: qore-module-api-0.9
Obsoletes: qore-module-api-0.8
Obsoletes: qore-module-api-0.7
Obsoletes: qore-module-api-0.6
Obsoletes: qore-module-api-0.5

> Any comment on fedora-review licensecheck.txt and rpmlint.txt?

licensecheck.txt:
I missed this one before - there were two GPL files taken from glibc (getopt_long.cpp and getopt_long.h) that I had forgotten about.   These files are not used in the Linux build, but regardless their presence precludes releasing Qore under an optional MIT license.

I have just replaced them with BSD-licensed variants (taken from FreeBSD).  The BSD-licensed versions will be present in the next release.

The mass of files with LGPL headers are from Qore, and this source has been now released under a less restrictive MIT license.

I will update all these source files to reflect the new licensing status and also the option to use them under the GPL and LGPL (Note: the qore library allows itself to be initialized under the GPL which allows it to load binary modules also tagged as under the GPL; if the qore library is not initialized under the GPL then GPL-tagged modules cannot be loaded).

This will take some time, so I will post another comment when the updated source packages are available.

rpmlint.txt:
The spelling errors can be ignored in my opinion - all except "Qore" (name of the project) are valid according to the New Oxford American Dictionary.

+ qore: manual-page-warning: I removed the undefined macros

+ libqore: obsolete-not-provided: I have to admit I do not understand the rpmlint -I explanation for this warning - AFAIK I should declare the old library name as obsoleted by the new one in case anyone has the old version installed

+ libqore: only-non-binary-in-usr-lib: this is due to the Qore-language module files being stored under lib*, this is because they are stored together with the binary modules.  The binary modules were first, then a few versions ago the qore library implemented support for "user modules" which are modules written in Qore instead of C++.  libqore includes the user modules, and they are stored in the same directory as the binary modules.  I had assumed (read: was hoping) that this would be acceptable, but if not, then I can make the appropriate changes to the language and the packaging to package them under /usr/share/qore-modules instead and have two locations for qore modules depending on the module type.

+ qore-devel: no-documentation: all the READMEs, etc were provided with libqore.  The development documentation is provided in devel-doc.  I'm not sure what to do about this - maybe add a README?

+ qore-devel: no-manual-page-for-binary: I have not written man pages for these programs yet - I had assumed from the Fedora packaging guidelines that this was a "nice to have" but not an absolute must.   I am planning on writing man pages for these but do not have them yet.

+ qore.src: unversioned-explicit-provides: as above

> 
> Plus:
> 
> * https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

I re-added these as follows:
%build
export CXXFLAGS="%{optflags}"
%configure --disable-debug --disable-static
make %{?_smp_mflags}

I had misunderstood a review comment from Christopher Meng and $RPM_OPT_FLAGS before - I hope the solution above is better and future-proof.

It will take me a while to update the source with the updated license info, after which I'll post the URLs to the updated revision 3 sources for the qore packages.

Thanks again for your time and the detailed help with the review process.

thanks,
David
Comment 14 Michael Schwendt 2014-06-22 20:13:12 EDT
> obsolete-not-provided

First of all, while you can put anything in an Obsoletes tag, only package names (with/without a version-release range) will actually result in the specified package(s) getting replaced with another package (or multiple ones). 

Further, anything declared as obsolete breaks existing dependencies on it. Unless there is a corresponding "Provides" for the obsolete thing.

> Obsoletes: libqore5 < 0.8.12

If there's a "Requires: libqore5 …" anywhere, there would be a broken dependency, regardless of whether "libqore5" is a physical package %name, a virtual package name, or something else as a "Provides" tag.

http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

> Obsoletes: qore-module-api-0.18

Same here. This capability will be "gone", "hidden" from the depsolver, and anything that still depends on it will cause a broken dependency. The package that contains this Obsoletes tag does not implicitly "Provides" the obsolete thing.
Comment 15 David Nichols 2014-06-23 04:21:01 EDT
(In reply to Michael Schwendt from comment #14)
> > obsolete-not-provided
> 
> First of all, while you can put anything in an Obsoletes tag, only package
> names (with/without a version-release range) will actually result in the
> specified package(s) getting replaced with another package (or multiple
> ones). 
> 
> Further, anything declared as obsolete breaks existing dependencies on it.
> Unless there is a corresponding "Provides" for the obsolete thing.
> 
> > Obsoletes: libqore5 < 0.8.12
> 
> If there's a "Requires: libqore5 …" anywhere, there would be a broken
> dependency, regardless of whether "libqore5" is a physical package %name, a
> virtual package name, or something else as a "Provides" tag.
> 
> http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.
> 2FReplacing_Existing_Packages
> 
> > Obsoletes: qore-module-api-0.18
> 
> Same here. This capability will be "gone", "hidden" from the depsolver, and
> anything that still depends on it will cause a broken dependency. The
> package that contains this Obsoletes tag does not implicitly "Provides" the
> obsolete thing.

OK, I tried to read about this stuff, but I did not see this covered in any of the RPM or packaging guides.  I think that I understand now.

So then I will do this instead:

Provides: qore-module(abi) = 0.18
Provides: libqore5 = 0.8.11
Obsoletes: libqore5 < 0.8.12
# provided for backwards-compatibility with unversioned capabilities and will be removed when the ABI drops backwards-compatibility
Provides: qore-module-api-0.18
Provides: qore-module-api-0.17
Provides: qore-module-api-0.16
Provides: qore-module-api-0.15
Provides: qore-module-api-0.14
Provides: qore-module-api-0.13
Provides: qore-module-api-0.12
Provides: qore-module-api-0.11
Provides: qore-module-api-0.10
Provides: qore-module-api-0.9
Provides: qore-module-api-0.8
Provides: qore-module-api-0.7
Provides: qore-module-api-0.6
Provides: qore-module-api-0.5

Furthermore I hope to have the license text updated in the source by later today (CET).

Thanks again for your explanations and patience.

thanks,
David
Comment 16 David Nichols 2014-06-23 09:57:06 EDT
(In reply to David Nichols from comment #15)
> (In reply to Michael Schwendt from comment #14)
> > > obsolete-not-provided
> > 
> > First of all, while you can put anything in an Obsoletes tag, only package
> > names (with/without a version-release range) will actually result in the
> > specified package(s) getting replaced with another package (or multiple
> > ones). 
> > 
> > Further, anything declared as obsolete breaks existing dependencies on it.
> > Unless there is a corresponding "Provides" for the obsolete thing.
> > 
> > > Obsoletes: libqore5 < 0.8.12
> > 
> > If there's a "Requires: libqore5 …" anywhere, there would be a broken
> > dependency, regardless of whether "libqore5" is a physical package %name, a
> > virtual package name, or something else as a "Provides" tag.
> > 
> > http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.
> > 2FReplacing_Existing_Packages
> > 
> > > Obsoletes: qore-module-api-0.18
> > 
> > Same here. This capability will be "gone", "hidden" from the depsolver, and
> > anything that still depends on it will cause a broken dependency. The
> > package that contains this Obsoletes tag does not implicitly "Provides" the
> > obsolete thing.
> 
> OK, I tried to read about this stuff, but I did not see this covered in any
> of the RPM or packaging guides.  I think that I understand now.
> 
> So then I will do this instead:
> 
> Provides: qore-module(abi) = 0.18
> Provides: libqore5 = 0.8.11
> Obsoletes: libqore5 < 0.8.12
> # provided for backwards-compatibility with unversioned capabilities and
> will be removed when the ABI drops backwards-compatibility
> Provides: qore-module-api-0.18
> Provides: qore-module-api-0.17
> Provides: qore-module-api-0.16
> Provides: qore-module-api-0.15
> Provides: qore-module-api-0.14
> Provides: qore-module-api-0.13
> Provides: qore-module-api-0.12
> Provides: qore-module-api-0.11
> Provides: qore-module-api-0.10
> Provides: qore-module-api-0.9
> Provides: qore-module-api-0.8
> Provides: qore-module-api-0.7
> Provides: qore-module-api-0.6
> Provides: qore-module-api-0.5

This did not work because libqore then provides a capability that it's obsoleting.

Therefore I will update the version to 0.8.11.1 and then do the following:

Provides: qore-module(abi) = 0.18
Provides: libqore5 = %{version}
Obsoletes: libqore5 < %{version}
# provided for backwards-compatibility with unversioned capabilities and will be removed when the ABI drops backwards-compatibility
Provides: qore-module-api-0.18
Provides: qore-module-api-0.17
Provides: qore-module-api-0.16
Provides: qore-module-api-0.15
Provides: qore-module-api-0.14
Provides: qore-module-api-0.13
Provides: qore-module-api-0.12
Provides: qore-module-api-0.11
Provides: qore-module-api-0.10
Provides: qore-module-api-0.9
Provides: qore-module-api-0.8
Provides: qore-module-api-0.7
Provides: qore-module-api-0.6

I can also remove the unversioned Provides if it's a problem, I just would like to keep backwards compatibility with existing installed modules if possible, but if it's not acceptable for Fedora, then I will remove the lines.

I should have the new release ready in a few minutes.
Comment 17 Michael Schwendt 2014-06-23 11:35:06 EDT
> This did not work [...]

So-called "self-Obsoletes" do work, because the same package still Provides what it Obsoletes.

Self-Obsoletes sometimes are used to replace multiple packages (of no specific arch) with a single new package.

> Provides: libqore5 = 0.8.11
> Obsoletes: libqore5 < 0.8.12

Anything that "Requires: libqore5 <= 0.8.11" would still have worked, because it is still provided.

> Provides: libqore5 = %{version}
> Obsoletes: libqore5 < %{version}

This is cleaner, of course. Though, typically one hardcodes a specific maximum version-release in the Obsoletes tag to be really accurate and not obsolete more than necessary (e.g. if %version increments, the Obsoletes tag would adjust and also obsolete newer versions than what had been specified originally).
Comment 18 David Nichols 2014-06-23 13:22:42 EDT
(In reply to Michael Schwendt from comment #17)
> > This did not work [...]
> 
> So-called "self-Obsoletes" do work, because the same package still Provides
> what it Obsoletes.
> 
> Self-Obsoletes sometimes are used to replace multiple packages (of no
> specific arch) with a single new package.
> 
> > Provides: libqore5 = 0.8.11
> > Obsoletes: libqore5 < 0.8.12
> 
> Anything that "Requires: libqore5 <= 0.8.11" would still have worked,
> because it is still provided.
> 
> > Provides: libqore5 = %{version}
> > Obsoletes: libqore5 < %{version}
> 
> This is cleaner, of course. Though, typically one hardcodes a specific
> maximum version-release in the Obsoletes tag to be really accurate and not
> obsolete more than necessary (e.g. if %version increments, the Obsoletes tag
> would adjust and also obsolete newer versions than what had been specified
> originally).

OK I have it like this now:
Provides: qore-module(abi) = 0.19
Provides: qore-module(abi) = 0.18
Provides: libqore5 = %{version}
Obsoletes: libqore5 < 0.8.11.1

I also updated the module (and library) ABI because I moved the user (text) modules to $(datarootdir)/qore-modules (ie /usr/share/qore-modules/...) to address one of the fedora-review issues, and for this I also added additional symbols to the library.

However now I'm getting a new error in fedora-review as follows:
libqore.x86_64: E: useless-provides qore-module(abi)

Any clue what I'm doing wrong here?
Comment 19 David Nichols 2014-06-24 02:42:46 EDT
(In reply to David Nichols from comment #18)
> OK I have it like this now:
> Provides: qore-module(abi) = 0.19
> Provides: qore-module(abi) = 0.18
> Provides: libqore5 = %{version}
> Obsoletes: libqore5 < 0.8.11.1
> 
> I also updated the module (and library) ABI because I moved the user (text)
> modules to $(datarootdir)/qore-modules (ie /usr/share/qore-modules/...) to
> address one of the fedora-review issues, and for this I also added
> additional symbols to the library.
> 
> However now I'm getting a new error in fedora-review as follows:
> libqore.x86_64: E: useless-provides qore-module(abi)

I also checked https://apps.fedoraproject.org/packages/audacious/sources/spec and see that audacious-libs only uses one versioned Provides: declaration for audacious(plugin-api) (they also use %{?_isa} in the declaration, which I've added).

So basically the question is if:
Provides: qore-module(abi)%{?_isa} = 0.19
%{?_isa:Provides: qore-module(abi) = 0.19}
Provides: qore-module(abi)%{?_isa} = 0.18
%{?_isa:Provides: qore-module(abi) = 0.18}

is OK despite the error in fedora-review (libqore.x86_64: E: useless-provides qore-module(abi)).  I found another fedora package (rubygem-em-socksify) that passed review with this error, so maybe it's ok - not totally clear to me why it's not a warning if under some circumstances it's OK.

Anyway, assuming it's OK, the new URLs are:
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-1.fc20.src.rpm

Changes:
- added explicit versioned capability for library ABI compatibility for module RPMs
- added explicit versioned capability for libqore5 due to name change on fedora/rhel
- obsoletes previous versions of libqore5 in case of foreign RPM installation
- added %%{optflags} to configure
- updated license text in library source to reflect most liberal license option (MIT) with reference to LGPL and GPL options
- replaced GPL getopt_long.* files with BSD variants (not used on Linux builds)
- updated module and library ABI info
- moved user module directory to ${_datarootdir}
- moved module and user module directories to libqore package where they should be
- disabled dependency tracking in configure

The upstream source has been significantly updated with the license text updates as mentioned above.

There are still some GPL files included in licensecheck.txt: ltmain.sh (included by autotools from libtool) and parser.cpp/parser.hpp which are generated by Bison and subject to the Bison "special exception".

there are some rpmlint warnings still present, but I hope they are acceptable (the spelling ones are definitely OK I believe).  There are missing man pages for two programs used in C++ development for libqore, and the devel documentation is in a separate package due to its size, so there are no docs in the devel package.
Comment 20 Michael Schwendt 2014-06-24 04:49:11 EDT
> libqore.x86_64: E: useless-provides qore-module(abi)

rpmlint is mistaken in this case. A bug report had been filed years ago in bug 460872, but it has been closed due to a misunderstanding.


> Provides: qore-module(abi)%{?_isa} = 0.19

At some time, adding %{?_isa} to create arch-specific dependencies has become popular and can also help the depsolver. For example, when the depsolver encounters broken deps in a multiarch repo such as x86_64, it would try to resolve the deps with i686 packages (even older ones), which sometimes leads to pulling in lots of i686 packages.

If you choose to add %{?_isa}, there is not much reason to also add the non-%isa Provides. 

The audacious packages had started with non-%isa Provides, which should be dropped nowadays since nothing depends on them anymore.
Comment 21 David Nichols 2014-06-24 05:26:22 EDT
(In reply to Michael Schwendt from comment #20)
> > libqore.x86_64: E: useless-provides qore-module(abi)
> 
> rpmlint is mistaken in this case. A bug report had been filed years ago in
> bug 460872, but it has been closed due to a misunderstanding.

ok thanks for that info.

> > Provides: qore-module(abi)%{?_isa} = 0.19
> 
> At some time, adding %{?_isa} to create arch-specific dependencies has
> become popular and can also help the depsolver. For example, when the
> depsolver encounters broken deps in a multiarch repo such as x86_64, it
> would try to resolve the deps with i686 packages (even older ones), which
> sometimes leads to pulling in lots of i686 packages.
> 
> If you choose to add %{?_isa}, there is not much reason to also add the
> non-%isa Provides. 
> 
> The audacious packages had started with non-%isa Provides, which should be
> dropped nowadays since nothing depends on them anymore.

ok I see that makes sense - I also had the same thought, but thought it was safer to do it just like an already-accepted package.

new URLs:
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-2.fc20.src.rpm

only the qore-module(abi) Provides were updated to remove the non-%isa versions.

Michael, thanks a lot for your time, expertise, and help with this package submission review.
Comment 22 Christopher Meng 2014-06-24 06:39:25 EDT
Are these obsoletes lines needed? These are not available in the official repo but only in the qore 3rd party yum repo.
Comment 23 David Nichols 2014-06-24 07:17:54 EDT
(In reply to Christopher Meng from comment #22)
> Are these obsoletes lines needed? These are not available in the official
> repo but only in the qore 3rd party yum repo.

There is only Obsoletes line in the most recent spec file:
Obsoletes: libqore5 < 0.8.11.1

This is needed for people that have the 3rd-party rpm installed, since now the name will have changed since people should use the official yum repo in the future since it will ideally be fed directly from upstream.
Comment 24 David Nichols 2014-06-27 08:52:01 EDT
updated URLS:

new URLs:
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-3.fc20.src.rpm

changes:
- added license files and license READMEs to packages that can potentially be installed independently (doc and devel-doc)
- removed --disable-static from the configure call since it's the default
- created a new qore-stdlib package for noarch user module files in /usr/share, split from libqore
- removed ChangeLog from distribution sources

note that the source has not yet been uploaded to sourceforge - I will make the upstream release once I'm sure no more changes are needed for the package to be accepted in Fedora.

Jason Taylor (jason.taylor@secure-24.com) has offered to co-maintain this package when it's approved as well.
Comment 25 David Nichols 2014-06-27 09:51:40 EDT
koji builds of qore-0.8.11.1-3:

f20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7082844

rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7083028
Comment 26 David Nichols 2014-07-02 21:03:28 EDT
Could someone please let me know if the latest package attempt is OK?

I've taken care of all issues to the best of my knowledge with Release 3...
Comment 27 David Nichols 2014-07-06 08:10:15 EDT
I did my first informal review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1116548#c2
Comment 28 David Nichols 2014-07-07 19:18:02 EDT
another informal package review:
https://bugzilla.redhat.com/show_bug.cgi?id=1117022#c1
Comment 29 David Nichols 2014-07-08 14:34:51 EDT
updated URLS:

new URLs:
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-4.fc20.src.rpm

changes:
- added a %%check section using the new "make check" target
- simplified spec due to upstream changes (moved test/ subdir to examples/ in upstream)

koji builds of qore-0.8.11.1-4 for f21:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7118205
Comment 30 David Nichols 2014-07-08 21:49:11 EDT
I found some bugs in external module building related to changes made for Fedora packaging in this package, therefore I have updated URLS:

new URLs:
Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-5.fc20.src.rpm

changes:
- synced with upstream fixes for 64 bit ppc compilation and command-line enhancements for module directory handling

koji builds of qore-0.8.11.1-5 for f21:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7119247
Comment 31 David Nichols 2014-07-12 08:54:38 EDT
Upon further manual review of the RPMS, a packaging bug in the file specs in the qore-doc package was found which is fixed in the new release:

Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-6.fc20.src.rpm

changes:
- fixed doc and devel-doc file specs to fix packaging bugs for documentation

koji builds of qore-0.8.11.1-6 for f21:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7131746
Comment 32 David Nichols 2014-07-21 09:32:23 EDT
another informal review:
https://bugzilla.redhat.com/show_bug.cgi?id=1121601#c1
Comment 33 Adam Williamson 2014-09-11 03:39:52 EDT
I'm not a sponsor, but the package looks good to me, I see no errors.
Comment 34 David Nichols 2014-09-11 03:57:09 EDT
(In reply to Adam Williamson (Red Hat) from comment #33)
> I'm not a sponsor, but the package looks good to me, I see no errors.

thanks Adam, I appreciate you taking a look at it.

If I understand correctly, I should email sponsors individually and ask them if they would care to sponsor this package and me as a maintainer, is that correct?
Comment 35 Adam Williamson 2014-09-11 13:42:41 EDT
that would be a good way to try and find one, yeah - maybe look at their packages / reviews and see if you can find one who's interested in this general area of work. You could also ping folks on IRC. sorry for the delay in getting this approved!
Comment 36 David Nichols 2015-09-08 01:09:01 EDT
the scm repo has moved to github; the build has been updated accordingly:

Spec URL: http://qore.org/srpms/qore.spec
SRPM URL: http://qore.org/srpms/qore-0.8.11.1-7.fc22.src.rpm

koji builds of qore-0.8.11.1-6 for f23:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10995416

I'm back to actively looking for a sponsor.

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