Sam Varshavchik wrote:
Well, to me it makes much more sense to simply eliminate the uncertainty
from the process. If I take the tarball that I'm going to build today, if
I have to rebuild it next year, of a few years from -- the tarball will
remain the same. It's not going to change.
On 09:34:10 AM Saturday, July 02, 2011 Michał Piotrowski wrote:
Hi,
Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
9.1 is in beta2 now and it's scheduled for Q3 2011.
It would be nice to see Lucene Core in F16. There is an old Lucene
2.9.x for F16 - the latest
Tom Lane wrote:
I grow weary of debating this with somebody who can't recognize that his
particular situation is not universal. Many people build code for
themselves, for instance because their preferred platform isn't shipping
the particular version of a package they want (or not shipping it
Hi,
yum is complaining about this dependency (on F14)
6:kdelibs-4.6.2-1.fc14.i686 has installed conflicts kdevelop ('9', '4.1.80',
None): 9:kdevelop-3.5.5-1.fc12.i686
which is not correct, as kdevelop 3.5.5 is perfectly compatible with any kdelibs
(because it actually uses kdelibs3 instead).
On Sun, 2011-07-03 at 13:31 -0400, Tom Lane wrote:
Sam Varshavchik mr...@courier-mta.com writes:
To add to that: I never recall a single instance where I couldn't fix any
breakage in someone else's canned configure/makefile scripts without having
to rerun autoconf and automake.
On Tue, 2011-06-21 at 10:39 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Today or in next few days I'll plan update ImageMagick in rawhide to
version 6.7.0-8.
And we're still waiting... ;-)
Nils
--
Nils Philippsen Those who would give up Essential Liberty to purchase
Red Hat
On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
FWIW, I used to run autoconf during the builds of both the postgresql
and mysql packages for many years. That eventually became unnecessary
in both cases, but I don't recall that autoconf changes ever caused me
any trouble. (gcc, on
On 07/04/2011 12:39 PM, Richard W.M. Jones wrote:
On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
FWIW, I used to run autoconf during the builds of both the postgresql
and mysql packages for many years. That eventually became unnecessary
in both cases, but I don't recall that
Hi,
2011/7/4 Alexander Kurtakov akurt...@redhat.com:
On 09:34:10 AM Saturday, July 02, 2011 Michał Piotrowski wrote:
Hi,
Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
9.1 is in beta2 now and it's scheduled for Q3 2011.
It would be nice to see Lucene Core in F16.
Sorry for not quoting. Btw, i in rhel5 have packaged the latest autoconf,
automake and libtool in such a way that if installed the packager can use it
without upgrading the rhel5 package and without conflict of any sort : not so
hard to do with rpm. Dunno if my approch was the best, or if it is
Kevin Kofler writes:
Sam Varshavchik wrote:
Well, to me it makes much more sense to simply eliminate the uncertainty
from the process. If I take the tarball that I'm going to build today, if
I have to rebuild it next year, of a few years from -- the tarball will
remain the same. It's not
Sorry, but it is postponed [1] probably due to the bug in gcc [2]
[1] https://bugzilla.redhat.com/show_bug.cgi?id=715834
[2] https://bugzilla.redhat.com/show_bug.cgi?id=715336
On 07/04/2011 02:10 PM, Nils Philippsen wrote:
On Tue, 2011-06-21 at 10:39 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
On Mon, Jul 04, 2011 at 03:25:41PM +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Sorry, but it is postponed [1] probably due to the bug in gcc [2]
[1] https://bugzilla.redhat.com/show_bug.cgi?id=715834
[2] https://bugzilla.redhat.com/show_bug.cgi?id=715336
The latter is assigned to
Ralf Corsepius writes:
On 07/04/2011 01:18 PM, Sam Varshavchik wrote:
Both gcc and binutils are extensively regression-tested. Stuff that was
compiled years ago, still works.
To some extend, yes,
Nevertheless we all are permanently fixing gcc/binutils-compatibilities,
aren't we?
Right.
Compose started at Mon Jul 4 08:15:47 UTC 2011
Broken deps for x86_64
--
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api)
= 0:19
Nils Philippsen wrote:
I'd really love to be able to re-run current auto-tools on old
Makefile.am/configure.{in,ac} files and the results to work in all
cases, but right now that seems utopian to me.
Yet the competition ( http://www.cmake.org/ ) manages that very thing just
fine…
The whole
Richard W.M. Jones wrote:
I suspect Kevin's concern is that someone stuffs some hidden shell
code into ./configure which isn't in configure.ac. (Of the send all
your private ssh keys to remote host variety).
This concern has some legitimacy. But OTOH someone could stuff the
same code into
Roberto Ragusa wrote:
yum is complaining about this dependency (on F14)
6:kdelibs-4.6.2-1.fc14.i686 has installed conflicts kdevelop ('9',
'4.1.80', None): 9:kdevelop-3.5.5-1.fc12.i686
which is not correct, as kdevelop 3.5.5 is perfectly compatible with any
kdelibs (because it actually
On 07/04/2011 02:04 PM, Sam Varshavchik wrote:
Ralf Corsepius writes:
On 07/04/2011 01:18 PM, Sam Varshavchik wrote:
Both gcc and binutils are extensively regression-tested. Stuff that was
compiled years ago, still works.
To some extend, yes,
Nevertheless we all are permanently fixing
Ralf Corsepius writes:
I've got C++ code that's more than ten years old. Still builds just
fine, without any diagnostics.
Then you're lucky - May-be your C++ code is recent enough?
No. I have the source tree right here. Large chunks of it are quite old.
So far, most pre-ISO-C++ code I
Yes, I seen mistake.
Now ImageMagick built against new gcc.
On 07/04/2011 03:45 PM, Christophe Fergeau wrote:
On Mon, Jul 04, 2011 at 03:25:41PM +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Sorry, but it is postponed [1] probably due to the bug in gcc [2]
[1]
On Mon, 2011-07-04 at 15:07 +0200, Kevin Kofler wrote:
Nils Philippsen wrote:
I'd really love to be able to re-run current auto-tools on old
Makefile.am/configure.{in,ac} files and the results to work in all
cases, but right now that seems utopian to me.
Yet the competition (
On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Now ImageMagick built against new gcc.
Great, thanks!
Nils
--
Nils Philippsen Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
On Mon, 2011-07-04 at 06:25 +0200, Ralf Corsepius wrote:
On 07/04/2011 04:37 AM, Toshio Kuratomi wrote:
On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
Hi folks,
Thanks all for the input. I didn't realize the subject was *this*
controversial. I did find the other discussion
On Mon, 2011-07-04 at 16:33 +0200, Nils Philippsen wrote:
On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Now ImageMagick built against new gcc.
Great, thanks!
Now that I've rebuilt rss-glx against the new ImageMagick version I see
that it has the same library
Excerpts from Michał Piotrowski's message of Mon Jul 04 13:11:06 +0200 2011:
Hi,
2011/7/4 Alexander Kurtakov akurt...@redhat.com:
On 09:34:10 AM Saturday, July 02, 2011 Michał Piotrowski wrote:
Hi,
Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
9.1 is in beta2
On 07/04/2011 03:48 PM, Sam Varshavchik wrote:
Ralf Corsepius writes:
I've got C++ code that's more than ten years old. Still builds just
fine, without any diagnostics.
Then you're lucky - May-be your C++ code is recent enough?
No. I have the source tree right here. Large chunks of it are
On Sun, 2011-07-03 at 12:48 -0400, Sam Varshavchik wrote:
To add to that: I never recall a single instance where I couldn't fix any
breakage in someone else's canned configure/makefile scripts without having
to rerun autoconf and automake.
If there was a problem in the configure script,
Adam Williamson writes:
On Sun, 2011-07-03 at 12:48 -0400, Sam Varshavchik wrote:
To add to that: I never recall a single instance where I couldn't fix any
breakage in someone else's canned configure/makefile scripts without having
to rerun autoconf and automake.
If there was a problem in
There's something to consider about Chris Evans blog post as of July 3 [1]:
An incident, what fun! Earlier today, I was alerted that a vsftpd download
from the master site (vsftpd-2.3.4.tar.gz) appeared to contain a backdoor.
$ gpg ./vsftpd-2.3.4.tar.gz.asc
gpg: Signature made Tue 15 Feb
On Tue, 5 Jul 2011, Misha Shnurapet wrote:
The backdoor payload is interesting. In response to a :) smiley face in the
FTP username, a TCP callback shell is attempted.
There is no obfuscation.
I have a question: how does that relate to our package building process, and
are GPG signatures
On 07/04/2011 10:53 PM, Paul Wouters wrote:
It would be nice if we could upload/commit the .asc or .sig file, and have
the rpmbuild script
automatically check the tar ball.
Hm, yes. It would be nice to see Koji support checking source sigs. OBS
already does so. Seeing as Debian has done this
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Missing dependency in perl-SVK package
https://bugzilla.redhat.com/show_bug.cgi?id=718870
Summary: Missing dependency in perl-SVK package
Product:
33 matches
Mail list logo
