Bug 474787 - Review Request: stxxl - C++ STL drop-in replacement for extremely large datasets
Review Request: stxxl - C++ STL drop-in replacement for extremely large datasets
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Denis Arnaud
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 07:02 EST by D Haley
Modified: 2009-07-13 11:18 EDT (History)
5 users (show)

See Also:
Fixed In Version: 1.2.1-8.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-11 13:16:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
denis.arnaud_fedora: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description D Haley 2008-12-05 07:02:12 EST
SPEC URL: http://dhd.selfip.com/427e/stxxl-1.spec
SRPM URL: http://dhd.seflip.com/427e/stxxl-1.2.1-1.fc9.src.rpm

rpmlint:
  SPEC: empty
  SRPM: empty
  RPM:  W: devel-file-in-non-devel-package /usr/lib/libstxxl.a
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

Why is a ".a" library considered to be devel? Something I don't understand properly most likely. Its kinda the key file in all of this.

Scratch build:
$ koji build --scratch dist-f9 ../SRPMS/stxxl-1.2.1-1.fc9.src.rpm 
Uploading srpm: ../SRPMS/stxxl-1.2.1-1.fc9.src.rpm
[====================================] 100% 00:00:35 667.63 KiB  18.62 KiB/sec
Created task: 980984
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=980984
Watching tasks (this may be safely interrupted)...
...
  980988 buildArch (stxxl-1.2.1-1.fc9.src.rpm, i386): open (x86-5.fedora.phx.redhat.com) -> canceled
  0 free  0 open  3 done  2 failed


Comments:
*The install section is a bit of a mess as the project rolls its own makefiles. I had to write the install section myself.

*PPC arch build fails, as latex cannot be run (permissions problem?). I can simply drop PDF/DVI user manual generation for this arch if this is a problem.
http://koji.fedoraproject.org/koji/getfile?taskID=980985&name=build.log
Comment 1 manuel wolfshant 2008-12-05 07:15:33 EST
http://dhd.selfip.com/427e/stxxl-1.spec is not a valid URL and under http://dhd.selfip.com/427e/ I see nothing relevant.


Usually .a are statically build libs and they require special packaging. See http://fedoraproject.org/wiki/Packaging/Guidelines#Exclusion_of_Static_Libraries

According to http://koji.fedoraproject.org/koji/getfile?taskID=980986&name=build.log, your package does not respect the mandatory Fedora compiler flags, as described by http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags.

And not only the ppc build fails, all of them do.
Comment 2 D Haley 2008-12-05 07:21:53 EST
Disabling the latex generation causes all arches to build successfully. 

Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=981048
Comment 3 D Haley 2008-12-05 10:10:18 EST
SPEC URL:	http://dhd.selfip.com/427e/stxxl-2.spec
SRPM URL:	http://dhd.selfip.com/427e/stxxl-1.2.1-2.fc9.src.rpm

Changelog

* Sat Dec 06 2008 <mycae(a!t)yahoo.com> 1.2.1-2
- Removed latex build & buildrequires
- Patched makefiles to provide shared instead of static libs
- made doxygen log to file, due to excessively verbose output

Rpmlint:
SRPM:empty
SPEC:empty
RPM:
$ rpmlint -iv RPMS/i386/stxxl-1.2.1-2.fc9.i386.rpm 
stxxl.i386: I: checking
stxxl.i386: W: devel-file-in-non-devel-package /usr/lib/libstxxl-0.so
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

Now this is causing problems, If i put the link in the devel package it says it must be part of the package proper and emits an error. If I put it in the main, as I have done now, it emits this warning. The libstxxl-0.so is simply a symlink to libstxxl.so.0. Running ldconfig -n during %install instead of hand-cranking the symlink makes no difference, as the net result is the same. It simply makes the symlink using the soname of the so. This soname is the same value that I have set in the build patch (patch0).

Koji scratch: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=981419
All succeeded.

Issues:
I don't build the user manual. This however can be grabbed from their sf page by users, so unless someone knows the solution off the top of their head to the latex problem, I will probably leave it.
Comment 4 D Haley 2008-12-28 06:09:26 EST
3 week ping?
Comment 5 Michael Schwendt 2009-01-13 15:15:11 EST
* "Summary" of -devel package is not "short and concise" as recommended by the guidelines, but two sentences squeezed into an overlong line.

* Run rpmlint also on your src.rpm

* src.rpm download URL gives 404 Not Found

* %description of the -devel package is the same as the description of the main package. That can't be right. Typically, you can cut down on that and simply say something like: "This package contains development files for compiling software that uses %{name}."

* -devel pkg typically must "Requires: %{name} = %{version}-%{release}" to stay in sync with the main package.

Note : That could also be the answer to your problem with the .so symlink. The symlink must be in the -devel package, and the -devel package requires the main package which contains the library file.

* %files devel section is missing %defattr parameter

* %files devel section contains unowned directories! Either add the missing

  %dir %{_docdir}/stxxl-1.2.1
  %dir %{_includedir}/stxxl

or use equivalent entries to include these directories and their contents recursively. You would do this by removing the "*" wildcard that you use currently.
Comment 6 D Haley 2009-01-14 07:31:36 EST
SPEC URL: http://dhd.selfip.com/427e/stxxl-3.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-3.fc10.src.rpm

Rpmlint:
SRPM:	empty
SPEC:	empty
RPM:	empty

>"Summary" of -devel package is not "short and concise" as recommended by the
>guidelines, but two sentences squeezed into an overlong line.
I shortened it in the main package, though I thought it was pretty short to begin with. In the devel section it has been corrected, as it was clearly overlong. The main summary is slightly shortened but cannot be shortened further without losing information.

>Run rpmlint also on your src.rpm

My apologies if I had not -- I thought I had, as stated in comment 3. Clearly not, as running it produces a myriad of errors.

>src.rpm download URL gives 404 Not Found
Again, that's just sloppy on my part -- I didn't transfer it to the server. Both the old and the new have been uploaded.

> %description of the -devel package is the same as the description of the main
package.
Fixed. 

> -devel pkg typically must "Requires: %{name} = %{version}-%{release}" to stay
in sync with the main package.
Fixed

> %files devel section contains unowned directories! 
Fixed --  would have been evident had i run rpmlint correctly.

>%files devel section is missing %defattr parameter
Done.

>Note : That could also be the answer to your problem with the .so symlink. The
>symlink must be in the -devel package, and the -devel package requires the main
>package which contains the library file.

It wasn't that -- I worked it out in the end with the help of 
http://en.opensuse.org/Shared_Library_Packaging_Policy . Which was very clear, both in procedure and rationale. Seems to keep rpmlint happy and matches what is happening in other packages in my /usr/lib/.


I hope this package is less sloppy than the last attempt!
Comment 7 Peter Lemenkov 2009-04-23 15:12:44 EDT
I'll review it.
Comment 8 Peter Lemenkov 2009-05-23 07:54:52 EDT
Notes:

* The %build section still doesn't honour %optflags. You should fix your spec in the following way:

- echo OPT=-O2 -fPIC >> make.settings.local
+ echo "OPT=%{optflags}" >> make.settings.local

* Regarding %install section - you may shorten it a bit by replacing

mkdir %{buildroot}
mkdir -p %{buildroot}/%{_libdir}/
cp ./lib/libstxxl.so %{buildroot}/%{_libdir}/libstxxl.so.%{version}

with

install -p -D -m 0755 ./lib/libstxxl.so %{buildroot}/%{_libdir}/libstxxl.so.%{version}

* You also don't need to explicitly install doc-files. Just enumerate them in %files section properly. Let's assume, that you wish to install TROUBLESHOOTING file as %doc - all you need is to add 

%files
%doc TROUBLESHOOTING

and rpmbuild will cd into rpmbuild/BUILD/stxxl-1.2.1 directory and will search TROUBLESHOOTING here.

So you should remove the following lines:

mkdir -p %{buildroot}/%{_docdir}/
#Install Documentation
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/doxy
cp -pr doc/doxy/* %{buildroot}/%{_docdir}/stxxl-1.2.1/doxy
#cp -pr doc/tutorial/tutorial.pdf %{buildroot}/%{_docdir}/stxxl-1.2.1/
#cp -p doc/tutorial/tutorial.dvi %{buildroot}/%{_docdir}/stxxl-1.2.1/
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/examples/
cp -p doc/tutorial/examples/* %{buildroot}/%{_docdir}/stxxl-1.2.1/examples/
cp -p config_example %{buildroot}/%{_docdir}/stxxl-1.2.1/

and just add

%doc doc/doxy/* doc/tutorial/examples/* config_example

to "%files devel" section. Of course, docs will be installed into %{_docdir}/stxxl-devel-1.2.1/ directory.

* Consider adding README and TROUBLESHOOTING to %doc.
Comment 9 D Haley 2009-05-24 05:21:02 EDT
SPEC URL: http://dhd.selfip.com/427e/stxxl-4.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-4.fc10.src.rpm


>* Regarding %install section - you may shorten it a bit by replacing
Done.

> The %build section still doesn't honour %optflags. You should fix your spec in the following way:

I added optflags, but the macro doesn't (on my system) contain -fPIC, therefore removing PIC causes errors when running rpmlint hence I now have

echo "OPT=%{optflags} -fPIC" >> make.settings.local

In any case, duplicate -fPICs are not going to cause any harm when seen by GCC.

>You also don't need to explicitly install doc-files. Just enumerate them in %files section properly.
Doc section updated.


> Consider adding README and TROUBLESHOOTING to %doc.  
Done.

* Sun May 24 2009 <mycae(a!t)yahoo.com> 1.2.1-4
- Used doc macro to install docs previously manually installed
- Added README and TROUBLESHOOTING to docs
- Added otpflags macro to build settings
- Use "install" program rather than cp for the install of lib


RPM Lint:
$ rpmlint -vi  stxxl.spec ../SRPMS/stxxl-1.2.1-4.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-4.fc10.i386.rpm 
stxxl.src: I: checking
stxxl.i386: I: checking
2 packages and 1 specfiles checked; 0 errors, 0 warnings.
Comment 10 Denis Arnaud 2009-05-27 07:13:06 EDT
(In reply to comment #2)
> Disabling the latex generation causes all arches to build successfully. 
> 
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=981048  

Within Fedora versions prior to 10 (as well as for all the RedHat/CentOS versions, including EL-5), the Latex package was TeTex, whereas it is now TexLive. An example of how to handle the different packages corresponding to different versions is given in http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/rmol.spec.in?revision=214&view=markup

Basically, you may use the following:
%if 0%{?fedora} >= 10
BuildArch:      noarch
BuildRequires:  texlive-latex, texlive-dvips
%endif
%if 0%{?fedora} < 10
BuildRequires:  tetex-latex, tetex-dvips
%endif
BuildRequires:  doxygen, ghostscript
Comment 11 D Haley 2009-05-29 10:28:04 EDT
Thanks for the pointers. I have re-enabled the latex documentation.

SPEC URL: http://dhd.selfip.com/427e/stxxl-5.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-5.fc10.src.rpm

$ rpmlint -vi  stxxl.spec ../SRPMS/stxxl-1.2.1-5.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-5.fc10.i386.rpm 
stxxl.src: I: checking
stxxl.i386: I: checking
2 packages and 1 specfiles checked; 0 errors, 0 warnings.

Koji:
F9: http://koji.fedoraproject.org/koji/taskinfo?taskID=1383288
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1383287
Comment 12 Denis Arnaud 2009-05-31 21:32:15 EDT
[My machine crashed just before I pressed the commit button of the review :( ]

Note that, as I have not the sponsor status, that is not an official review. However, there are a number of issues (some important, some others less) that I can point to you (in no particular order).

1. Doxygen, as it is configured, generates .map files (in the doc/html sub-directory), due to the use of the DOT tool (belonging to the graphviz package). On some configurations (e.g., my Fedora rawhide/11, with rpmbuild), some of those files are generated with a zero-length, which rpmlint then complains of.

There are, at least, two solutions/work-arounds:
  1.a. Just drop the use of DOT in the Doxygen configuration file:
  HAVE_DOT = NO
  as in http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/doc/doxygen_html.cfg.in?revision=183&view=markup
  As Doxygen replaces with other, simpler, diagrams, that should not be a so big issue.
  1.b. Keep the use of DOT, but:
    - Add a 'BuildRequires: graphivz' directive.
    - Remove any zero-length-map files after the Doxygen generation (http://cvs.fedoraproject.org/viewvc/rpms/asterisk/F-11/asterisk.spec?revision=1.51&view=markup):
      find doc/html -name '*.map' -size 0 -delete

Note that with mock, there is, as is, no zero-length-map-file issue, but the .map files are not generated, due to the missing 'BuildRequires: graphviz' directive. Note also that you can not see that in the build.log (http://koji.fedoraproject.org/koji/getfile?taskID=1383290&name=build.log) of Koji, as you have re-directed the output log of Doxygen into a file removed by mock.

2. Avoid re-directing the output log of Doxygen, so that that log be present in the build.log generated by mock (and Koji):
make doxy > doxymake.log 2> doxymake.stderr
==>
make doxy

3. You may consider creating a separate -doc sub-package for both the HTML Doxygen-generated documentation and the Latex-generated tutorial (https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation).

4. I would rather keep the PDF version of the tutorial, rather than the DVI one. Moreover, we could alter the Makefile so that it generates only the PDF version (which is now the default with latex).

5. In the %files section, you should take ownership of the %{_includedir}/bits directory (https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership):
%dir %{_includedir}/bits/

6. Still in the %files sections, it may be better to use a wildcard for the libraries, as it will still hold for future versions of the library:
%{_libdir}/libstxxl.so.*

7. You may replace instances of stxxl with the %{name} macro, and of 1.2.1 with the %{version} macro (https://fedoraproject.org/wiki/Packaging/Guidelines#Macros). For instance:
---------------------------------------------------
URL:     http://%{name}.sourceforge.net
Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
Patch0:  %{name}-build-shared.patch
Patch1:  %{name}-build-shared-makefile.patch
---------------------------------------------------

x. The build system (makefiles) appears to be very specific to that package, and it may not be portable. For instance, you have to install the files manually yourself in the specification file. If you consider to bring a GNU Autotools environment (and submit the corresponding patch upstream), and if I can help you, do not hesitate.
Comment 13 Denis Arnaud 2009-05-31 21:37:09 EDT
If it may help, the above comments (plus a few small others) have been integrated into a new version of the specification file:
Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/6/stxxl.spec
(as well as the corresponding Source RPM: http://denisarnaud.fedorapeople.org/stxxl/121/6/stxxl-1.2.1-6.fc10.src.rpm)
Comment 14 Michael Schwendt 2009-06-01 05:01:18 EDT
All members of the "packager" group may do official package-reviews and package-approvals.
Comment 15 D Haley 2009-06-01 06:50:13 EDT
I agree with all of the changes made in your SRPM, and support its promotion pending review. I suppose this makes you co-maintainer? Do we need another reviewer?

Here are koji builds for the above SRPM, F9 failed, but F10 and F11 are OK. F9 is relatively close to EOL, so I suppose its not a big problem.

F9 : http://koji.fedoraproject.org/koji/taskinfo?taskID=1386757
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1386748
F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1386762

>If you consider to bring a GNU Autotools environment (and submit the >corresponding patch upstream), and if I can help you, do not hesitate.  

I think it is not necessarily a good idea to bring a different build system to STXXL, but instead to help upstream to improve their chosen method. I would hesitate to recommend a change of build sys to upstream, unless they expressed an interest in doing so. For this reason I do not have any plans to do such a thing, unless upstream indicate they would be interested.

In any case, I don't see this as important to this package for this version. Maybe in a newer upstream version after some petitioning...
Comment 16 D Haley 2009-06-01 06:57:43 EDT
Hmm I spoke a bit too soon. The use of noarch is causing problems with rpmlint, as noarch is being applied to the main package. If we remove noarch from the -doc section, all is well.
Comment 17 Peter Lemenkov 2009-06-01 07:05:31 EDT
(In reply to comment #12)

> Note that, as I have not the sponsor status, that is not an official review.
> However, there are a number of issues (some important, some others less) that I

Denis, feel free to reassign this ticket to yourself (and, therefore, proceed with reviewing further). As you're a packager, then you may do the formal review (actually, you're almost finished reviewing this package :))
Comment 18 Denis Arnaud 2009-06-01 18:14:00 EDT
That's fine, if you like, I shall be honoured to go on with the review (thanks Peter and Michael!).

As for the failing build on Fedora 9, I just forgot to enclose the 'BuildArch: noarch' directive within the '%if 0%{?fedora} >= 10 [...] %endif' condition...

It now works well, as Koji shows: http://koji.fedoraproject.org/koji/taskinfo?taskID=1388361

Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl.spec
(as well as the corresponding Source RPM:
http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl-1.2.1-7.fc10.src.rpm)

As I have changed only the BuildArch directive, it does not imply any change on Fedora 10, 11 and 12. So, if you agree with that new version, I shall approve the package.

----------------

As for the build system, I proposed to ADD a new one, not to replace the existing one. Hence, (part of) the upstream team may still work with their current building system, if they are happy with it (though I do not understand how they install that library, since there is apparently no such possibility in the current build system!). And an additional GNU Autotools build system would allow (plenty of) other developers to build, install and package in a standard way, without too much maintenance. That is simply what I suggested, and see no reason why the upstream team should be against.

Without such a standard build system, it means that, as the main maintainer of the package, you will have more work every time a new upstream will be released. But, that is my $0.02, and as far as I understand, it should not interfere with Fedora packaging :)
---------------
Comment 19 D Haley 2009-06-02 06:21:29 EDT
SPEC URL: http://dhd.selfip.com/427e/stxxl-8.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-8.fc10.src.rpm

rpmlint:
$ rpmlint stxxl.spec ../SRPMS/stxxl-1.2.1-8.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-8.fc10.i386.rpm ..//RPMS/i386/stxxl-devel-1.2.1-8.fc10.i386.rpm ../RPMS/i386/stxxl-doc-1.2.1-8.fc10.i386.rpm ../RPMS/i386/stxxl-debuginfo-1.2.1-8.fc10.i386.rpm
5 packages and 1 specfiles checked; 0 errors, 0 warnings.

koji:
F9:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389134
F10:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389156
F11:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389127

I removed the noarch entirely, as my rpm does not support this directive per sub-package, but rather attempts to provide it across all packages. This causes rpmlint to be annoyed about libs in a noarch package.

The wiki says that this feature is coming *soon* but is not here yet, but maybe both it and I are out of date?: https://fedoraproject.org/wiki/Features/NoarchSubpackages

So here is my revision. The only difference from -7 is the removal of the noarch directive.

With regards to the build system, at this time it is more work to make it autoconf friendly than to just keep the current "system" chugging along. Maybe next release :-).
Comment 20 Michael Schwendt 2009-06-02 09:26:44 EDT
> I removed the noarch entirely, as my rpm does not support this
> directive per sub-package,

It works in Fedora 10 (RPM 4.6.0) and above.

> This causes rpmlint to be annoyed about libs in a noarch package.

rpmlint must be new enough:
https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2946
Comment 21 Denis Arnaud 2009-06-02 13:18:58 EDT
(In reply to comment #20)
> It works in Fedora 10 (RPM 4.6.0) and above.

Yes, of course, my version (1.2.1-7) works on Fedora 10 and above. I just shows the result of Koji for Fedora 9, as it was the only remaining non-working version.

So, I suggest to keep the version 1.2.1-7 (or to have 1.2.1-9 version identical to the 1.2.1-7). Is that fine for you?
Comment 22 D Haley 2009-06-03 03:35:53 EDT
Absolutely fine. Sorry for the fuss.

I updated my rpm tools, and now everything is fine. I was a bit confused by the wiki: "Right now the Fedora infrastructure does not support this feature" but it seems out of date.
Comment 23 Denis Arnaud 2009-06-03 06:07:41 EDT
I forgot to add a <tab> between the 'BuildArch:' and 'noarch' parts of the 'BuildArch:<tab>noarch' directive, and rpmlint was complaining. So, I have made an 8-th release (where only the <tab> was added):
Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/8/stxxl.spec
(as well as the corresponding Source RPM:
http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl-1.2.1-8.fc10.src.rpm)

$ sha1sum stxxl-1.2.1-8.fc10.src.rpm stxxl-1.2.1.tar.gz stxxl-build-*
d04266f98f6e83e4a2307b3c5bc06ed259cf5e49  stxxl-1.2.1-8.fc10.src.rpm
bafa3c065395908e257ae76d19fa6883b374323f  stxxl-1.2.1.tar.gz
6f99ae374c44fe6de98713f26d5b308e2c054d29  stxxl-build-shared-makefile.patch
e0a01a5d7b5633a58f7f0c439df157b2407535ba  stxxl-build-shared.patch

APPROVED
Comment 24 Denis Arnaud 2009-06-03 06:20:53 EDT
The wiki (https://fedoraproject.org/wiki/Features/NoarchSubpackages) may have to be updated, as it is stated that that feature targets F12 (only). However, since the fix of rpmlint (https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2946 , as mentioned by Michael above), having noarch sub-package does work with Fedora from version above 10. Since the wiki is the description of a feature, the owners (Florian Festi <ffesti@redhat.com> and Jindrich Novy <jnovy@redhat.com>) could maybe be contacted to have them aware of that good news.
Comment 25 D Haley 2009-06-03 08:28:54 EDT
New Package CVS Request
=======================
Package Name: stxxl
Short Description: C++ STL drop-in replacement for extremely large datasets
Owners: mycae
Branches: F-9 F-10 F-11
InitialCC:
Comment 26 D Haley 2009-06-03 09:20:04 EDT
Also requesting EL-5

New Package CVS Request
=======================
Package Name: stxxl
Short Description: C++ STL drop-in replacement for extremely large datasets
Owners: mycae
Branches: F-9 F-10 F-11 EL-5
InitialCC:
Comment 27 Jason Tibbitts 2009-06-03 12:51:36 EDT
CVS done.
Comment 28 Fedora Update System 2009-06-05 11:17:00 EDT
stxxl-1.2.1-9.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-9.fc9
Comment 29 Fedora Update System 2009-06-05 11:18:07 EDT
stxxl-1.2.1-8.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-8.fc10
Comment 30 Fedora Update System 2009-06-05 11:19:06 EDT
stxxl-1.2.1-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-8.fc11
Comment 31 Fedora Update System 2009-06-15 21:29:22 EDT
stxxl-1.2.1-8.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6038
Comment 32 Fedora Update System 2009-06-15 21:32:08 EDT
stxxl-1.2.1-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6055
Comment 33 Fedora Update System 2009-06-15 22:00:41 EDT
stxxl-1.2.1-9.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-6266
Comment 34 Fedora Update System 2009-07-11 13:16:19 EDT
stxxl-1.2.1-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 35 Fedora Update System 2009-07-11 13:20:18 EDT
stxxl-1.2.1-9.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 36 Fedora Update System 2009-07-11 13:30:39 EDT
stxxl-1.2.1-8.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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