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 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.
>
> > If there wa
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, o
On Sun, Jul 03, 2011 at 11:09:06PM -0400, Tom Lane wrote:
> Kevin Kofler writes:
> > FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> > matter of policy, even if we aren't changing anything,
>
> To what end? If you need to change configure.ac, that's one thing ...
>
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 :
> 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
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 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?
> The same cannot be said of autot
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 gc
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. B
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
bibletime
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 co
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 act
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 per
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 h
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] https://bugzilla.re
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 ( htt
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
n...@
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 ot
On Mon, Jul 04, 2011 at 03:07:14PM +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 competitio
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 lib
Excerpts from Michał Piotrowski's message of Mon Jul 04 13:11:06 +0200 2011:
> Hi,
>
> 2011/7/4 Alexander Kurtakov :
> > 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
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 chunk
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 scr
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 proble
On Mon, 2011-07-04 at 15:12 -0400, Sam Varshavchik wrote:
> But, personally, I don't mind the extra work, see. I just have this odd idea
> of assigning a somewhat higher priority to having a reproducible build
> script, that produces the same results each and every time. I guess I've
> just
Adam Williamson writes:
On Mon, 2011-07-04 at 15:12 -0400, Sam Varshavchik wrote:
> But, personally, I don't mind the extra work, see. I just have this odd
idea
> of assigning a somewhat higher priority to having a reproducible build
> script, that produces the same results each and every ti
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 s
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 th
34 matches
Mail list logo
