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
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
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
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
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 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 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
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
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 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
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 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, 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 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
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
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
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
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
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
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
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
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
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
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
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)
>
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 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
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
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
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 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 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, 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
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).
34 matches
Mail list logo
