Bug 1000829 - (linpack) Review Request: linpack - FORTRAN subroutines to analyze and solve linear equations
Review Request: linpack - FORTRAN subroutines to analyze and solve linear equ...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Meng
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ML-SIG
  Show dependency treegraph
 
Reported: 2013-08-25 14:21 EDT by Björn "besser82" Esser
Modified: 2017-02-06 23:33 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-28 05:56:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
i: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Björn "besser82" Esser 2013-08-25 14:21:12 EDT
Description:

  LINPACK is a collection of FORTRAN subroutines that analyze and solve linear
  equations and linear least-squares probles.  The package solves linear systems
  whose matrices are general, banded, symmetric indefinite, symmetric positive
  definite, triangular, and tridiagonal square.  In addition, the package
  computes the QR and singular value decompositions of rectangular matrices
  and applies them to least-squares problems.  LINPACK uses column-oriented
  algorithms to increase efficiency by preserving locality of reference.

  LINPACK was designed for supercomputers in use in the 1970s and early 1980s.
  LINPACK has been largely superseded by LAPACK which has been designed to run
  efficiently on shared-memory, vector supercomputers.


Koji Builds:

  el5:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851811
  el6:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851815
  F18:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851819
  F19:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851822
  F20:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851825
  Frh:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5851829


Issues:

  fedora-review shows no issues, rpmlint reports some false positives.


Fedora Account System Username:

  besser82


Urls:

  Spec URL: http://besser82.fedorapeople.org/review/linpack.spec
  SRPM URL: http://besser82.fedorapeople.org/review/linpack-19880411-1.fc19.src.rpm

#####

Thanks for review in advance!
Comment 1 Christopher Meng 2013-08-25 14:46:34 EDT
Some questions:

1. I can see ifarch here, why not use ifarch to install files, but just add more subpackages?

2. devel/static packages description are not good:

Example:

This package contains shared libraries for developing applications that use %{name}.

This package contains static libraries for developing applications that use %{name}.
Comment 2 Björn "besser82" Esser 2013-08-25 14:59:32 EDT
(In reply to Christopher Meng from comment #1)
> Some questions:
> 
> 1. I can see ifarch here, why not use ifarch to install files, but just add
> more subpackages?

%ifarch is used here for building linpack64-subpkgs with support for 64Bit INT.  Every subpkg, but the doc, carries just one or two files.  I don't know why to add even more subpackages?
 
> 2. devel/static packages description are not good:
> 
> Example:
> 
> This package contains shared libraries for developing applications that use
> %{name}.
> 
> This package contains static libraries for developing applications that use
> %{name}.

current %discription are ripped-off from LAPACK or BLAS.  I did this intentionally to keep this in consistancy with them, because they more or less come from the same family.
Comment 3 Christopher Meng 2013-08-25 15:17:21 EDT
OK.

cp -a ---> cp -pa

APPROVED.
Comment 4 Björn "besser82" Esser 2013-08-25 15:27:00 EDT
(In reply to Christopher Meng from comment #3)
> cp -a ---> cp -pa

cp -a == cp -cdpR


Thanks for the review, Christopher!

#####

New Package SCM Request
=======================
Package Name: linpack
Short Description: FORTRAN subroutines to analyze and solve linear equations
Owners: besser82
Branches: el5 el6 f18 f19 f20
InitialCC:
Comment 5 Ralf Corsepius 2013-08-26 00:45:18 EDT
Some remarks:

I personally hate reviews, which are rushed through in such a haste, they don't give anybody a chance to look into a packages.

In this case, it was LESS THAN AN HOUR, which, to me, excludes any possibility of a careful review. Simply running rpmlint or fedora-review also is not a careful review!


Back to this  package:

* This section from the spec is bogus and should be needs to be removed:
# compress man-pages
pushd man3
gzip -9 *
popd

* Any proof for this package being BSD-licensed? The license file contained in this package is added by Björn, but I can't find any upstream evidence linpack is actually licensed BSD. Googling also did not provide further information.

* I prefer packages to install their docs into /usr/share/doc/<package>. Installing docs into <package>-doc seems quite nonsensical to me.
Comment 6 Christopher Meng 2013-08-26 00:47:55 EDT
I've told him about the manpage generation script issue in gtalk.

For license problem, I think he should add some comments in the spec.

docdir waiting for Björn to answer.
Comment 7 Björn "besser82" Esser 2013-08-26 05:45:02 EDT
(In reply to Ralf Corsepius from comment #5)
> * This section from the spec is bogus and should be needs to be removed:
> # compress man-pages
> pushd man3
> gzip -9 *
> popd

I nuked this inside the updated spec.
 
> * Any proof for this package being BSD-licensed? The license file contained
> in this package is added by Björn, but I can't find any upstream evidence
> linpack is actually licensed BSD. Googling also did not provide further
> information.

http://www.netlib.org/linpack/archives/readme says:

  Questions/comments should be directed to lapack@cs.utk.edu.

Looking on their archives [1] I see some question about this from a few
years ago, which was answered:

  "Basically it is BSD."

The additional documentation from Universität Bayreuth was auto-generated
from the source-files, so I consider them covered by the same license as
the code-sources are.  Same goes for the DQRDC2 routine which is a modified
version from LINPACK's original DQRDC routine.

I added some clarifing comments about that inside the spec.


> * I prefer packages to install their docs into /usr/share/doc/<package>.
> Installing docs into <package>-doc seems quite nonsensical to me.

Is there any guideline telling me where the contents of a doc-subpkg has to be located? There are a lot of packages providing the documentation from the doc-subpkg inside <package>-doc:

  * boost-doc
  * gtk2-devel-docs
  * kernel-doc
  * xorg-x11-docs

Just to name a prominent few.  So I would consider doing so is somehow common pratice.

[1] http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00301.html

#####

Updated package:

  %changelog
  * Mon Aug 26 2013 Björn Esser <bjoern.esser@gmail.com> - 19990929-1
  - added some detailed comments about licensing
  - added DQRDC2 routine
  - removed compression of man-pages during %%build
  - added some pdf-documentation from CERN's public library

  * Sun Aug 25 2013 Björn Esser <bjoern.esser@gmail.com> - 19880411-1
  - Initial rpm release


Koji Builds:

  el5:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853614
  el6:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853620
  F18:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853624
  F19:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853627
  F20:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853635
  Frh:  https://koji.fedoraproject.org/koji/taskinfo?taskID=5853639


Urls:

  Spec URL: http://besser82.fedorapeople.org/review/linpack.spec
  SRPM URL: http://besser82.fedorapeople.org/review/linpack-19990929-1.fc19.src.rpm
Comment 8 Michael Schwendt 2013-08-26 06:00:54 EDT
> I prefer packages to install their docs into /usr/share/doc/<package>. 
> Installing docs into <package>-doc seems quite nonsensical to me.

While this would be nice, it won't work anymore in Fedora 20 due to the UnversionedDocdirs feature. And it has been troublesome for older releases, too, when packagers installed their -doc subpackage files into /usr/share/doc/%{name}-%{version} manually (temporarily %doc has even deleted manually installed files in the default docdir).

Using %doc in the base package conflicts with installing subpackage files into /usr/share/doc/%{name}. How? The %doc macro in the base package will include any files in /usr/share/doc/%{name} leading to duplicate documentation and conflicts. Examples? At the bottom of the UnversionedDocdirs tracker bug 993551 I've added a few.
Comment 9 Ralf Corsepius 2013-08-26 06:06:26 EDT
(In reply to Björn "besser82" Esser from comment #7)
> (In reply to Ralf Corsepius from comment #5)
> > * This section from the spec is bogus and should be needs to be removed:
> > # compress man-pages
> > pushd man3
> > gzip -9 *
> > popd
> 
> I nuked this inside the updated spec.
>  
> > * Any proof for this package being BSD-licensed? The license file contained
> > in this package is added by Björn, but I can't find any upstream evidence
> > linpack is actually licensed BSD. Googling also did not provide further
> > information.
> 
> http://www.netlib.org/linpack/archives/readme says:
> 
>   Questions/comments should be directed to lapack@cs.utk.edu.
> 
> Looking on their archives [1] I see some question about this from a few
> years ago, which was answered:
> 
>   "Basically it is BSD."
That's what I also saw, but ...

... that's insufficient.

For being able to ship something one needs a license from the copyright holder of the source code, otherwise you are at risk of committing license violations.

(Note: lack of licensing means "unlicense" and "non-redistributatble").

What you currently are doing in your tarball is you - Björn - adding a license and thus granting others a license to code you do not own.

> > * I prefer packages to install their docs into /usr/share/doc/<package>.
> > Installing docs into <package>-doc seems quite nonsensical to me.
> 
> Is there any guideline telling me where the contents of a doc-subpkg has to
> be located? There are a lot of packages providing the documentation from the
> doc-subpkg inside <package>-doc:
There is a guideline telling you documentation should accompany the package it is documenting.

This originally was referring to "move devel-docs" (e.g. man 3 man-pages) into the *devel packages and run-time docs (e.g. man 1 man-pages) into "run-time" docs.

> 
>   * boost-doc
>   * gtk2-devel-docs
>   * kernel-doc
>   * xorg-x11-docs
Yes, there are several packages, which IMO package their docs in this non-helpful way. 

In many cases, this likely had happened accidentally, when rpmlint started to rant on "big doc" packages, which caused packagers to start splitting them out of the main package.

There are also cases, in which doc-packages are "arched", despite this hardly rare makes sense.
Comment 10 Ralf Corsepius 2013-08-26 06:10:25 EDT
(In reply to Michael Schwendt from comment #8)
> > I prefer packages to install their docs into /usr/share/doc/<package>. 
> > Installing docs into <package>-doc seems quite nonsensical to me.
> 
> While this would be nice, it won't work anymore in Fedora 20 due to the
> UnversionedDocdirs feature.
Not true. It does work in Fedora 18 .. 20. And yes, it requires work.

> And it has been troublesome for older releases,
> too, when packagers installed their -doc subpackage files into
> /usr/share/doc/%{name}-%{version} manually (temporarily %doc has even
> deleted manually installed files in the default docdir).
Right, rpm's behavior wrt. %doc has changed, but the %_pkgdocdir combined with direct installation to _pkgdocdir works at least on Fedora and likely also on EPEL6.
Comment 11 Michael Schwendt 2013-08-26 06:23:21 EDT
> Not true.

Huh? Why would you say that?

It does not work anymore in Fedora 20. See bug 998149 (jsoncpp) for an example:

  %files
  %doc AUTHORS LICENSE NEWS.txt README.txt

  %files doc
  %doc AUTHORS LICENSE NEWS.txt README.txt
  %{_docdir}/%{name}

and the base package includes the whole docdir contents. This causes a conflict, if the noarch -doc pkg has been built on a different arch.

The only work-around would be to install all the %doc files manually.


> And yes, it requires work.

A lot of work, since you cannot use %doc anymore, such as with the more complicated bug 998168 (mathgl). 

[...]

A general repo check is still missing to find out where this leads to duplicated documentation. It's easy to find these cases if they conflict already, but where they don't conflict yet (out of coincidence), it's a time-bomb.
Comment 12 Ralf Corsepius 2013-08-26 06:41:13 EDT
(In reply to Michael Schwendt from comment #11)
> > Not true.
> 
> Huh? Why would you say that?
Because I just did that for a package.

see. libkni3 in git).
Comment 13 Björn "besser82" Esser 2013-08-26 07:14:13 EDT
(In reply to Ralf Corsepius from comment #9)
> (In reply to Björn "besser82" Esser from comment #7)
> > (In reply to Ralf Corsepius from comment #5)
> >   "Basically it is BSD."
> That's what I also saw, but ...
> 
> ... that's insufficient.
> 
> For being able to ship something one needs a license from the copyright
> holder of the source code, otherwise you are at risk of committing license
> violations.
> 
> (Note: lack of licensing means "unlicense" and "non-redistributatble").
> 
> What you currently are doing in your tarball is you - Björn - adding a
> license and thus granting others a license to code you do not own.

The LICENSE I put into the tarball actually meets the license from the authors.  Just got an answer from Jack Dongarra:

  LINPACK is licensed under the Modified 3 clause BSD license.
  Hope this helps,
  Jack Dongarra

  **********************************************************
  Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department;
  1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450;
  +1-865-974-8295; dongarra@eecs.utk.edu; http://www.cs.utk.edu/~dongarra/

Additionaly I send off an email about license-clarification to Ross Ihaka and Brian Ripley (BDR) about DQRDC2.  Will post this, when I get an answer from them.
Comment 14 Michael Schwendt 2013-08-26 07:47:33 EDT
> libkni3 in git

> %exclude %{_pkgdocdir}/html
> %exclude %{_pkgdocdir}/*.pdf

That's cheating. How many packages duplicate the docs because they don't %exclude anything?  And here's it *only* two files to exclude -> not (or hardly) practicable if there are many more files/dirs to exclude.

Anyway, I've mailed Ville privately about the %doc %_pkgdocdir conflicts.
Comment 15 Ralf Corsepius 2013-08-26 07:55:22 EDT
(In reply to Michael Schwendt from comment #14)
> > libkni3 in git
> 
> > %exclude %{_pkgdocdir}/html
> > %exclude %{_pkgdocdir}/*.pdf
> 
> That's cheating.
What's cheating about this? It's the normal way to split subdirs into different packages.

> How many packages duplicate the docs because they don't
> %exclude anything?  And here's it *only* two files to exclude
html is a directory filled with the usual doxygen stuff, and *pdf also is more than 1 package.

> -> not (or
> hardly) practicable if there are many more files/dirs to exclude.
Now you are cheating.
Comment 16 Ralf Corsepius 2013-08-26 07:57:39 EDT
(In reply to Björn "besser82" Esser from comment #13)
> (In reply to Ralf Corsepius from comment #9)
> > (In reply to Björn "besser82" Esser from comment #7)
> > > (In reply to Ralf Corsepius from comment #5)
> > >   "Basically it is BSD."
> > That's what I also saw, but ...
> > 
> > ... that's insufficient.
> > 
> > For being able to ship something one needs a license from the copyright
> > holder of the source code, otherwise you are at risk of committing license
> > violations.
> > 
> > (Note: lack of licensing means "unlicense" and "non-redistributatble").
> > 
> > What you currently are doing in your tarball is you - Björn - adding a
> > license and thus granting others a license to code you do not own.
> 
> The LICENSE I put into the tarball actually meets the license from the
> authors.  Just got an answer from Jack Dongarra:
> 
>   LINPACK is licensed under the Modified 3 clause BSD license.
>   Hope this helps,
>   Jack Dongarra
> 
>   **********************************************************
>   Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department;
>   1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450;
>   +1-865-974-8295; dongarra@eecs.utk.edu; http://www.cs.utk.edu/~dongarra/

OK, I'd recommed to include this mail into the package's docs and remove your extra license file.
Comment 17 Gwyn Ciesla 2013-08-26 08:29:18 EDT
Git done (by process-git-requests).
Comment 18 Michael Schwendt 2013-08-26 09:07:29 EDT
> It's the normal way to split subdirs into different packages.

Normal? Very unusual it is. In the following fragment,

  %doc LICENSE.txt readme.txt AUTHORS.txt
  %exclude %{_pkgdocdir}/html
  %exclude %{_pkgdocdir}/*.pdf

there is no path that includes

  %{_pkgdocdir}/html
  %{_pkgdocdir}/*.pdf

to begin with. Therefore it's nothing than a hack to %exclude those paths based on the knowledge that the %doc line not only copies local files into the docdir but includes the dir *and* everything (!) in it, regardless of which files are specified on that line, and that the whole thing will conflict in Fedora 20. The mathgl packager in the ticket I've linked also called that a hack some days ago, btw. ;)

Only when not using %doc to install any of those files I would agree with you calling it an ordinary subpackage split, because then dir/file ownership would not be automatic, and in many cases it would be possible to do it without %exclude statements even. %exclude is a last resort, not the norm.

Further, there's not even a "file listed twice" warning, if the excludes are missing. As I've mentioned, for a long time it has not even been possible to install into the versioned (!) default docdir and use %doc at the same time.
Comment 19 Ralf Corsepius 2013-08-26 11:46:33 EDT
(In reply to Michael Schwendt from comment #18)
> > It's the normal way to split subdirs into different packages.
> 
> Normal?
Yes.

> Very unusual it is.

Definitely no. It is one standard way how packages, which are "mixing subdirs" can be split into sub-packages. 

The fact we are talking about %doc is mostly irrelevant here.


> In the following fragment,
> 
>   %doc LICENSE.txt readme.txt AUTHORS.txt
>   %exclude %{_pkgdocdir}/html
>   %exclude %{_pkgdocdir}/*.pdf
> 
> there is no path that includes
> 
>   %{_pkgdocdir}/html
>   %{_pkgdocdir}/*.pdf

These are packaged into another package a couple of lines elsewhere in the package.

== sharing %{_pkgdocdir} between packages.
Comment 20 Michael Schwendt 2013-08-26 12:30:58 EDT
> These are packaged into another package a couple of lines
> elsewhere in the package.

You misunderstand it. :-/  One uses %exclude in a %files section, only if the same %files section includes the files, but if you want the files to be included in a subpackage instead. 

It's only a side-effect that "%doc LICENSE.txt readme.txt AUTHORS.txt" includes not only those three files, but everything in %{_pkgdocdir}.

I'll open a ticket in the FPC trac instance.
Comment 21 Björn "besser82" Esser 2013-08-27 05:45:25 EDT
(In reply to Ralf Corsepius from comment #16)
> (In reply to Björn "besser82" Esser from comment #13)
> > (In reply to Ralf Corsepius from comment #9)
> > > (In reply to Björn "besser82" Esser from comment #7)
> > > > (In reply to Ralf Corsepius from comment #5)
> > > >   "Basically it is BSD."
> > > That's what I also saw, but ...
> > > 
> > > ... that's insufficient.
> > > 
> > > For being able to ship something one needs a license from the copyright
> > > holder of the source code, otherwise you are at risk of committing license
> > > violations.
> > > 
> > > (Note: lack of licensing means "unlicense" and "non-redistributatble").
> > > 
> > > What you currently are doing in your tarball is you - Björn - adding a
> > > license and thus granting others a license to code you do not own.
> > 
> > The LICENSE I put into the tarball actually meets the license from the
> > authors.  Just got an answer from Jack Dongarra:
> > 
> >   LINPACK is licensed under the Modified 3 clause BSD license.
> >   Hope this helps,
> >   Jack Dongarra
> > 
> >   **********************************************************
> >   Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department;
> >   1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450;
> >   +1-865-974-8295; dongarra@eecs.utk.edu; http://www.cs.utk.edu/~dongarra/
> 
> OK, I'd recommed to include this mail into the package's docs and remove
> your extra license file.

Seems like I'll get DQRDC2 as BSD-3, too :)

  The code in R is GPL2+. I'd be happy to make this subroutine
  available as BSD or even public domain if Brian agrees.

But I think I'll need a bundling exception for this, since it seems to be compiled into libR as well.  On the other hand libR bundles some LINPACK code...

What's your thoughts, Ralf and Michael?
Comment 22 Mikolaj Izdebski 2013-08-27 12:33:15 EDT
(In reply to Ralf Corsepius from comment #16)
> OK, I'd recommed to include this mail into the package's docs and remove
> your extra license file.

That won't work.  If the package really is under BSD then full license text must be included to comply with licensing terms, see point 1 of the license: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."
Comment 23 Björn "besser82" Esser 2013-08-28 08:03:59 EDT
(In reply to Mikolaj Izdebski from comment #22)
> (In reply to Ralf Corsepius from comment #16)
> > OK, I'd recommed to include this mail into the package's docs and remove
> > your extra license file.
> 
> That won't work.  If the package really is under BSD then full license text
> must be included to comply with licensing terms, see point 1 of the license:
> "Redistributions of source code must retain the above copyright notice, this
> list of conditions and the following disclaimer."

So I need to include the LICENSE-file generated during creation of tarball, too, I think? Right?
Comment 24 Michael Schwendt 2013-08-31 04:26:44 EDT
If no such LICENSE file is included already, don't add it to the source tarball of the Fedora package. Without confirmation by upstream, it may or may not be the actual license terms they refer to. Follow
  https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
and add the file to the src.rpm as a separate file, which to include as %doc.

Same for an email response you receive. However, if the response is only a promise to clarify the licensing, that's not enough.

[...]

About the bundled code, this is still too vague to comment on, IMO. Is it just a subroutine, a copylib, or a copied (and possibly modified) library that exists as a separate upstream project?
Comment 25 Björn "besser82" Esser 2013-08-31 06:43:11 EDT
(In reply to Michael Schwendt from comment #24)
> If no such LICENSE file is included already, don't add it to the source
> tarball of the Fedora package. Without confirmation by upstream, it may or
> may not be the actual license terms they refer to. Follow
>   https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> and add the file to the src.rpm as a separate file, which to include as %doc.

So I sent the whole License-text to upstream ad he replied in meaning of "Yes, BSD-3-clause is the right license...".  So I think using the the reply of upstream can be used as %doc LICENSE here.  It actually has the full BSD-3-clause license in it.

> Same for an email response you receive. However, if the response is only a
> promise to clarify the licensing, that's not enough.

This is currently about the DQRDC2 routine. Here I'm actually waiting for some definitive response from upstream.  I could include this as GPLv2+ licensed code, since libR-upstreams confirmed license is such.

> [...]
> 
> About the bundled code, this is still too vague to comment on, IMO. Is it
> just a subroutine, a copylib, or a copied (and possibly modified) library
> that exists as a separate upstream project?

It's a modified version of LINPACK's DQRDC routine, which is included inside libR-sources.  Inside these source partialy modified subsets of LINPACK and BLAS are bundled, too.

The _real_ problem here is, that there is a bunch of software (e.g. scikit-learn or biolab's Orange) which needs LINPACK && DQRDC2, but you can't link against liblinpack AND libR into the same binary. Linking both into the same binary will either result in ld-errors (double-defined functions) or segfaults on runtime, because LINPACK and libR expose some identical symbols.  The other problem is, the subset of LINPACK, which get's bundled by libR has been modified and it's routines will not return the same results the pristine LINPACK will do. So you just can't link these executables against against libR, only.
Comment 26 Björn "besser82" Esser 2013-09-23 15:46:47 EDT
Package Change Request
======================
Package Name: linpack
Owners: ml-sig besser82
Branches: el5 el6 f18 f19 f20
Comment 27 Gwyn Ciesla 2013-09-23 16:13:04 EDT
Complete.
Comment 28 Björn "besser82" Esser 2013-09-28 05:56:13 EDT
This was meant to be a copy lib from upstream, so I opened: https://fedorahosted.org/fpc/ticket/349

I retired the package on all branches.  There has been no import nor a build for it.  Closing this as "CANTFIX".

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