Re: [suggest] problem with perl-DateTime version numbers
On Mar 23, 2011, at 6:52 AM, Matthew Vale wrote: I have discovered a problem with the version numbers listed for Perl-DateTime The latest version in your repo is 0.53-1 Unfortunately yum is unable to install this version because you have in the repo 0.4305-1 which is considered higher than the 0.53-1. This is because the version number is being treated as a rpm version string rather than a floating point number so considered greater (4305 53) I have no experience with building rpms so rebuilding the rpms to expand out to 4 digit version numbers is not really an option for me hi Matthew! thanks for your report! we need to pull that problematic RPM from the repository. for the time being, however, you don't need to rebuild the RPMs to work around this problem; just place the following line in /etc/yum.repos.d/rpmforge.repo under the [rpmforge] stanza: exclude = perl-DateTime-0.4305* -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706) PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] perl: Math::Random::Secure
On Dec 28, 2010, at 4:27 PM, Max Kanat-Alexander wrote: Hello! Could I get Math::Random::Secure and all of its dependencies packaged? If there are any problems with packaging it, let me know--I'm the maintainer of the module. http://search.cpan.org/dist/Math-Random-Secure/ heya Max! off the top of my head, the first issue (and it's a minor one) is that Dist::Zilla inserts a dependency on ExtUtils::MakeMaker 6.31, and el5 provides ExtUtils::MakeMaker 6.30. i've been manually patching that out in specfiles for other modules, and i haven't seen it cause a problem yet, but this behavior is making me dislike Dist::Zilla. if it's not too much trouble, can you make it not do that? thanks and happy new year, -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706) PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] perl-Devel-NYTProf update
On Jul 29, 2010, at 9:55 AM, David Steinbrunner wrote: We currently have Devel::NYTProf 3.11 while the latest on CPAN is 4.04. This is a request to sync up with CPAN. David, i've committed an updated spec. thanks for the tip! -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] Re: perl-DateTime-Format-Strptime-1.1000-1.el5.rf.noarch: glibc_date_format missing
On Jul 15, 2010, at 9:04 AM, Gerd v. Egidy wrote: Can't locate object method glibc_date_format via package DateTime::Locale::en_US at /usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780 After downgrading to perl-DateTime-Format-Strptime-1.1000-1.el5.rf.noarch everything worked again. Is this a problem in perl-DateTime-Format-Strptime-1.2000-1.el5.rf.noarch, some missing dependency or some misconfiguration on my side? the issue is the following: 1) the DateTime-Locale Perl distribution is generally versioned like 0.XX, 0.XY etc., as you can see from the Changelog: http://cpansearch.perl.org/src/DROLSKY/DateTime-Locale-0.45/Changes however, on May 19, 2008, the developer released version 0.4001, intending that version to sort between versions 0.40 and 0.41. from a Perlish standpoint, this is not unreasonable. 2) rpm's version comparison algorithm, however, sorts 0.4001 after 0.41 (Google for rpmvercmp if you want a more detailed explanation of why this is). 3) RPMforge has a perl-DateTime-Locale-0.4001 package, and many people (including you) have it installed on your system. 4) DateTime-Format-Strptime = 1.2000 requires DateTime-Locale = 0.45. 5) RPMforge has a perl-DateTime-Locale-0.45 package; however, yum (and rpm) don't see it as an available update because of point #2 above. so, what's the fix for this situation? one fix is as follows: $ yumdownloader perl-DateTime-Locale-0.45 $ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime $ sudo rpm -U ./perl-DateTime-Locale-0.45* $ sudo yum install perl-DateTime-Format-Strptime after this, put an exclusion in your yum config so that your yum won't see the spurious perl-DateTime-Locale-0.4001 package. we intend to remove perl-DateTime-Locale-0.4001 from the repo entirely, and i'll post to the users list when that is done. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Newer driver version in dkms-nvidia-x11-drv?
On Jun 29, 2010, at 8:38 AM, Yury V. Zaytsev wrote: Therefore, unless you have a very important reason for using RPMForge dkms packages you really ought to migrate to ELRepo kmod packages instead. cf. http://dag.wieers.com/blog/improved-rhel-centos-and-scientific-linux-hardware-support -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] perl-Date-Manip
On Jun 29, 2010, at 10:01 AM, Aaron Scamehorn wrote: Would it be possible to get a more recent version of Date::Manip? Current in rpmforge is 5.54. Latest Date::Manip is 6.11. Date-Manip-6.11 requires Perl 5.10, so we can't provide that at present; check back after el6 is out. i've checked in an update that brings the package to 5.56. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Re: Latest XML::LibXSLT needed
On Jun 7, 2010, at 11:31 AM, Christoph Maser wrote: As I am for a much more strict policy at rpmforge I vote for a complete removal of perl-XML-LibXMl and perl-XML-LibXSLT or at most provide an old version for perl-XML-LibXSLT wich works with the perl-XML-LibXML version from base. It is much better to not have a particular piece then to have a broken version. Chris, i did some digging into this (see SVN r8817), and we need at the very minimum: perl-XML-LibXML = 1.69 perl-XML-LibXML-Common (bring it back from the vault) perl-XML-LibXSLT = 1.63 and we need Dag to remove any later versions from the repo. if we want to roll all the way back to the versions from upstream, we have to go back to perl-XML-LibXSLT = 1.59 (there's already a spec for this in SVN). for packages that are as widely used as these, i'm OK with offering versions that replace packages from upstream, since their absence is really crippling. -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Update: bzr
On May 13, 2010, at 8:39 AM, Max Kanat-Alexander wrote: Hey hey. Could somebody update the bzr package to the latest stable release? At the moment, that's 2.1.0. It would be really helpful for us, because 2.1.0 fixes a bug that causes loggerhead (the bzr web viewer) to crash frequently and need restarting. updated in SVN. -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] memcached
On Feb 8, 2010, at 3:08 PM, David Steinbrunner wrote: Any chance we can get the latest 1.4.x release packaged or at least the latest 1.2.x maintenance release? 1.4.4 is in SVN. thanks for your request! -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] geoip and geoip-devel updates?
On Feb 2, 2010, at 4:47 AM, Yury V. Zaytsev wrote: Sorry for maybe being unclear. I'm not speaking about the builddeps of geoip, but about the packages which need geoip to build. In case if these exist, they will have to be updated accordingly. a brief survey indicates that the only packages that depend on GeoIP are tor, perl-Geo-IP, perl-Geo-IP-PurePerl, python-geoip and ntop, and ntop seems to download GeoIP as an additional Source: and do some internal shenanigans with it, so that's not really relevant to this discussion. i'll bump geoip and python-geoip and see if i see any problems. -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] geoip and geoip-devel updates?
On Feb 2, 2010, at 9:09 AM, Steve Huff wrote: i'll bump geoip and python-geoip and see if i see any problems. looks like a smooth upgrade; i've committed the changes. thanks for your request, Michael! -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] optipng
On Feb 2, 2010, at 10:31 AM, David Steinbrunner wrote: Simply requesting a package for this project: http://optipng.sourceforge.net/ that was pretty straightforward; committed to svn. -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] rrdtool-1.3.8 for el4
On Jan 14, 2010, at 7:00 AM, Ingvar Hagelund wrote: Is it possible to update the rpmforge version of in el4 to rrdtool-1.3.8? An epel4 mock build of rrdtool-1.3.8-2.rf.src.rpm (which exists in the el4 src directory) seems to build fine, given a backport of intltool from el5 is available. Ingvar, our svn currently has a spec for rrdtool-1.4.2; looking at the buildlogs, it looks like recent versions of rrdtool haven't been building for el4 because of some missing evolution28 libraries. Christoph, do you know what's going on here? You're the one who seems to have been updating rrdtool lately. -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Advanced Policy Firewall RPM?
On Dec 15, 2009, at 11:11 PM, Amos Shapira wrote: Could you please package Advanced Policy Firewall (http://www.rfxn.com/projects/advanced-policy-firewall/) for CentOS? i've committed the package. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] OpenSSH 4.9 (or later?)
On Dec 2, 2009, at 1:49 AM, Victor wrote: Just wondering what the thought is with having OpenSSH 4.9 or later included as available download on RPM (or even on the official CentOS repo's... but don't think i can request that here). as a general principle, we try not to explicitly clobber packages that come from upstream, and a package that's as critical as ssh strikes me as particularly untouchable. i'd recommend that you request its inclusion in Fedora, so that it can eventually make its way into RHEL. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es/ PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] perl-Captcha-reCAPTCHA
On Nov 5, 2009, at 3:25 PM, David Steinbrunner wrote: Just requesting the Captcha::reCAPTCHA perl module be packaged. committed to svn; provided it builds ok on the buildsystem, you should see it in the repo after the next package rebuild. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] rTorrent 0.8.5 / libTorrent 0.12.5
On Oct 24, 2009, at 8:35 AM, Alessandro Calorì wrote: Please, update rTorrent and libTorrent. I can't make the old version to work on CentOS 5.3 (seems like a curl/c-ares bug): it doesn't announce to any tracker. updated in svn; after the next package rebuild, you should see them in the repository. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] perl-dbd-mysql package naming
On Oct 22, 2009, at 2:52 PM, Dan Pritts wrote: I admit I am always annoyed when i need to type the mixed-case name, but this is basically a gratuitous change. Dag, any chance you can rename the package in the repo? $ sudo echo 'exclude = perl-DBD-mysql' /etc/yum.conf that will fix your problem quite well without requiring us to break with our naming convention :) -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] possible bug in packaging perl-WWW-Mechanize
On Oct 16, 2009, at 3:21 PM, Marc DeTrano wrote: On a CentOS 5.3 system, if I update the WWW::Mechanize perl with the latest package from rpmforge, perl-WWW- Mechanize-1.56-1.el5.rf.noarch.rpm, and then try to use it, I get this error: LWP::UserAgent version 5.827 required--this is only version 2.033 at /usr/lib/perl5/vendor_perl/5.8.8/WWW/Mechanize.pm line 106 On this distro, the LWP::UserAgent module comes from the perl-libwww- perl package, from the CentOS base repository. My work around for the time being is to force install of an older version: yum install perl-WWW-Mechanize-1.34 However, any general update will attempt to upgrade that older version (and break my perl using that module). that is indeed the issue :) a similar situation has recently been discussed over here: http://lists.rpmforge.net/pipermail/users/2009-October/002771.html -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] mplayer: -rtsp-stream-over-tcp requires the LIVE555 Streaming Media or libnemesi libraries.
On Sep 8, 2009, at 1:15 PM, Aleksey Nogin wrote: The earlier versions of the mplayer package did not have a problem with the -rtsp-stream-over-tcp option, but with mplayer-1.0-0.40.svn20090711.el5.rf I get the error message: -rtsp-stream-over-tcp requires the LIVE555 Streaming Media or libnemesi libraries. Would it be possible to rebuild the mplayer package with the libnemesi library? Aleksey, There's a bit of a dependency chain before we can add this feature to mplayer. libnemesi requires netembryo, which requires lksctp development libraries. I have packaged and committed lksctp-tools and netembryo (they should show up after the next package rebuild, provided they build OK on the build system), but libnemesi does not actually have a release tarball yet, and the link from their webpage for downloading a snapshot didn't work for me. If you'd like to help move this task forward, you could do either (or both) of the following: 1) Contact the libnemesi developers and ask them to roll up and release a version of libnemesi, or at least to give you some idea of their timeline for the first release. 2) Figure out the appropriate URL that will generate a snapshot of libnemesi from git, and post it to this list. Once we have this final dependency in rpmforge, I (or one of the other maintainers, or you) can try to build mplayer with libnemesi support. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Request: Required Perl Packages for Bugzilla 3.4
On Jul 27, 2009, at 6:36 AM, Chris Eveleigh wrote: anyway, when there is a requirement of the form at least one of these alternates i've heard about virtual provides where each of the possible provider packages adds a generic provide - e.g. Provides: perlDBdriver - so that the dependency can be satisfied by any of the available packages and yum/rpm/whatever will only complain if the user attempts to remove the last of those packages. for example, the bugzilla package depends on webserver which can be satisfied by httpd or lighttpd or whatever. i think there's another one for mailserver. for another example of this procedure, look at rpmforge's perl-JSON- Any. using the -alternative syntax might be a good way of making it obvious that one is looking at a virtual provide. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es PGP.sig Description: This is a digitally signed message part ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] missing Perl dependencies in perl-Email-Store
hello folks! perl-Email-Store-0.255-1 requires Class::DBI, Class::Data::Inheritable, Ima::DBI, all of which are currently in RPMforge, but these dependencies are not captured in the spec. the patch is attached! -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es perl-Email-Store-0.255-2_perldeps.patch Description: Binary data ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] imapsync needs perl-TermReadKey and perl-Mail-IMAPClient-2.2.9
On Jun 30, 2009, at 2:39 PM, Philip Durbin wrote: Can two dependencies please be added to the imapsync package? 1. perl-TermReadKey (to avoid Can't locate Term/ReadKey.pm in @INC) 2. perl-Mail-IMAPClient-2.2.9 (to avoid imapsync needs perl lib Mail::IMAPClient release 2.2.9 exactly, future imapsync release may suppoort 3.0.x, but sorry not now. See file BUG_IMAPClient_3.xx) in the spirit of helpfulness, the patch is attached :) -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es imapsync-1.255-2_perldeps.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] missing Perl dependency (HTTP::Response::Encoding) for WWW::Mechanize
hello folks! perl-WWW-Mechanize-1.54-1 requires perl(HTTP::Response::Encoding), which, as best i can tell, is not provided by rpmforge or by upstream (RHEL5). am i missing something? thanks, -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es smime.p7s Description: S/MIME cryptographic signature ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] request for additional Perl modules
On 6/9/09 4:52 PM, Christoph Maser wrote: On Tue, 2009-06-09 at 22:36 +0200, Steve Huff wrote: Please add the following Perl modules to the repository, if possible. I have included a specfile for Mail::ListDetector (generated by cpan2rpm). Email::Store Mail::ListDetector Class::DBI::DATA::Schema I see the new packages on packages.sw.be, but yum can't see them, even when querying against apt.sw.be. Is this an issue of metadata not yet generated? thanks, -Steve -- Steve Huff - Systems Administrator, HMDC - sh...@hmdc.harvard.edu ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] Net::Twitter::Lite-0.02002
Net::Twitter::Lite-0.02002 was just now pushed to CPAN (it may not yet have synced out to all the mirrors). it contains a fix for a broken dependency that prevented the module from functioning correctly on RHEL4 and RHEL5. the Makefile.PL still specifies a dependency on ExtUtils::MakeMaker that is newer than the one provided by stock perl on RHEL5, but the package seems to build and function OK in spite of this. please consider adding this package to rpmforge. thanks, -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es smime.p7s Description: S/MIME cryptographic signature ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Missing Dependency perl-JSON-Any
On Jun 11, 2009, at 4:02 PM, Christoph Maser wrote: The module JSON::Any needs at least one of JSON, JSON::XS or JSON::DWIW to function. In its current state the RPM for perl-JSON-Any does not have a dependency on any of those packages. Perhaps a dependency on the noarch JSON module would be appropriate? Well that would be a solution but not a correct one. Consider someone using JSON::Any and explicitly want to have _only_ JSON::XS. With this solution you would force him to install JSON. Actually with the features RPM provides I don't see any correct solution to this. 1) in the scenario above, the user could write 'use JSON::Any qw( XS );', which would limit his code to only using JSON::XS. if he's bound and determined to not have JSON installed on his system, he can always do a `rpm -e --nodeps perl-JSON` after installing perl-JSON- Any. 2) as an alternative, since rpmforge is packaging all of the modules in question, another solution would be to add some distinctive string (maybe 'perl-JSON-Any-alternative') as a Provides: for *all* of the various rpmforge-packaged JSON alternatives (perl-JSON, perl-JSON-XS, perl-JSON-DWIW, perl-YAML-Syck), and then add 'Requires: perl-JSON-Any- alternative' to perl-JSON-Any. this would at least prevent perl-JSON- Any from being able to install in a broken state and make sure the user is aware that it's essential to install at least one of the supporting modules. personally, i would prefer the first solution; perl-JSON is only ~344K, there's a programmatic workaround to make sure that it doesn't get called by JSON::Any, and imo it's better not to ship a package that installs in a nonfunctional state without emitting any error or warning message. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es smime.p7s Description: S/MIME cryptographic signature ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] tor-0.2.0.30
On Aug 21, 2008, at 6:13 PM, Greg Swallow wrote: http://archives.seul.org/or/talk/Jun-2008/msg00209.html ...saying to try removing the --enable-openbsd-malloc configure options in the spec file. yup! i can confirm that that works. trivial patch (hey, and it even works for SuSE! :) ) -steve tor-0.2.0.30.patch Description: Binary data --- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
