On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote:
> pgordon glabels
> pgordon lucidlife
Thanks for the FYI email. I rebuilt both of these yesterday with no
problems and no source changes necessary.
Regards.
--
Peter Gordon (codergeek42)
Who am I? :: http://thecodergeek.com/about-me
signa
On Mon, 07 Nov 2011 17:35:53 +0200, VS (Ville) wrote:
> > * The %configure macro (at least since F-16) does
> > LDFLAGS="${LDFLAGS:--Wl,-z,relro }"; export LDFLAGS;
> >so one cannot simply export a customized $LDFLAGS in the spec file
> >without disturbing the macro.
>
> That's wha
On 11/07/2011 12:16 PM, Tim Waugh wrote:
> On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote:
>> twaugh ghostscript
>> twaugh gutenprint
> I've rebuilt these two.
>
> Tim.
> */
>
(Apologies for replying to your reply, Tim, but I wasn't subscribed at
the start of this thread.)
I'm a graphviz upst
On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote:
> twaugh ghostscript
> twaugh gutenprint
I've rebuilt these two.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Mon, 2011-11-07 at 10:50 -0500, Tom Callaway wrote:
> On 11/07/2011 10:35 AM, Ville Skyttä wrote:
> > On 11/07/2011 01:57 PM, Michael Schwendt wrote:
> >
> >> * The %configure macro (at least since F-16) does
> >> LDFLAGS="${LDFLAGS:--Wl,-z,relro }"; export LDFLAGS;
> >>so one cannot
On 11/07/2011 10:35 AM, Ville Skyttä wrote:
> On 11/07/2011 01:57 PM, Michael Schwendt wrote:
>
>> * The %configure macro (at least since F-16) does
>> LDFLAGS="${LDFLAGS:--Wl,-z,relro }"; export LDFLAGS;
>>so one cannot simply export a customized $LDFLAGS in the spec file
>>without
On 11/07/2011 01:57 PM, Michael Schwendt wrote:
> * The %configure macro (at least since F-16) does
> LDFLAGS="${LDFLAGS:--Wl,-z,relro }"; export LDFLAGS;
>so one cannot simply export a customized $LDFLAGS in the spec file
>without disturbing the macro.
That's what I meant by "(in
On Sat, Nov 05, 2011 at 01:02:15PM -0400, Tom Lane wrote:
> rjones gtkglarea2
> rjones guestfs-browser
> rjones nekovm
> rjones ocaml-lablgtk
I've rebuilt all of these packages. They all built without any
source changes.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.r
On Sun, 06 Nov 2011 17:56:40 +0200, VS (Ville) wrote:
> > Puzzles me. The F-16 build doesn't depend on libpng* directly:
> >
> > $ rpm -qR geeqie|grep png
> > $ rpm -q geeqie
> > geeqie-1.0-13.fc16.x86_64
>
> I noticed a similar thing with gkrellm-volume -- the F-15 build did have
> a dependency
On 11/06/2011 12:26 AM, Michael Schwendt wrote:
> Puzzles me. The F-16 build doesn't depend on libpng* directly:
>
> $ rpm -qR geeqie|grep png
> $ rpm -q geeqie
> geeqie-1.0-13.fc16.x86_64
I noticed a similar thing with gkrellm-volume -- the F-15 build did have
a dependency on it, but the F-16 o
On Sat, 05 Nov 2011 19:35:21 -0400, TL (Tom) wrote:
> > On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote:
> >> My list was just the result of "repoquery --whatrequires".
>
> > The last Rawhide build of "geeqie" also doesn't depend on libpng*.
> > F-15 does, however, which might be where you've
Chris Adams wrote:
> Hmm, I didn't know that. Which does RPM use when generating
> dependencies? It would appear that it is is using ldd; should that be
> changed?
No, RPM does not pull in recursive soname dependencies, only direct ones.
Kevin Kofler
--
devel mailing list
devel@lists.
Once upon a time, Ville Skyttä said:
> How are you checking whether your executable ended up linked with
> something? If with ldd, note that it's recursive. AFAIU for example
> "eu-readelf -d /path/to/something | grep NEEDED" shows a better picture
> which is also mirrored in package dependencie
Michael Schwendt writes:
> On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote:
>> My list was just the result of "repoquery --whatrequires".
> The last Rawhide build of "geeqie" also doesn't depend on libpng*.
> F-15 does, however, which might be where you've run repoquery.
Hmm ... actually I di
On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote:
> > On Sun, 06 Nov 2011 00:03:28 +0200, VS (Ville) wrote:
> >> How are you checking whether your executable ended up linked with
> >> something?
>
> > Admittedly, I trusted Tom Lane's list of affected packages, looked at
> > ldd -u -r output and
Michael Schwendt writes:
> On Sun, 06 Nov 2011 00:03:28 +0200, VS (Ville) wrote:
>> How are you checking whether your executable ended up linked with
>> something?
> Admittedly, I trusted Tom Lane's list of affected packages, looked at
> ldd -u -r output and then examined the source.
My list was
On Sun, 06 Nov 2011 00:03:28 +0200, VS (Ville) wrote:
> How are you checking whether your executable ended up linked with
> something?
Admittedly, I trusted Tom Lane's list of affected packages, looked at
ldd -u -r output and then examined the source.
> If with ldd, note that it's recursive. A
On 11/05/2011 11:20 PM, Michael Schwendt wrote:
> On Sat, 05 Nov 2011 22:02:42 +0100, KK (Kevin) wrote:
>
>>> Lots of executables end up linked with libpng12 due to other libs (cairo,
>>> gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added
>>> explicitly.
>>
>> Not due to them bei
On Sat, 05 Nov 2011 22:02:42 +0100, KK (Kevin) wrote:
> > Lots of executables end up linked with libpng12 due to other libs (cairo,
> > gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added
> > explicitly.
>
> Not due to them being LINKED with it, but due to them shipping .pc or .l
Michael Schwendt wrote:
> Lots of executables end up linked with libpng12 due to other libs (cairo,
> gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added
> explicitly.
Not due to them being LINKED with it, but due to them shipping .pc or .la
files (probably .pc, since we normally
On Sat, 05 Nov 2011 20:12:28 +0200, VS (Ville) wrote:
> On 11/05/2011 07:02 PM, Tom Lane wrote:
> > The list of packages that need to be rebuilt is attached.
>
> I suggest maintainers take this opportunity to review whether all these
> packages really need to be linked against libpng - I'm positi
On Sat, Nov 5, 2011 at 2:34 PM, Tom Lane wrote:
> Richard Shaw writes:
>> This is my first time as a contributor to run into this.
>> Do I simply need to increment by release by 1 (or .1?) and build?
>
> If no source-code changes are needed, then yes, it's sufficient to
> increment the release nu
Richard Shaw writes:
> This is my first time as a contributor to run into this.
> Do I simply need to increment by release by 1 (or .1?) and build?
If no source-code changes are needed, then yes, it's sufficient to
increment the release number (either way that suits you) and rebuild
in rawhide.
Ville Skyttä wrote:
> I suggest maintainers take this opportunity to review whether all these
> packages really need to be linked against libpng - I'm positive that the
> list contains a lot of packages that don't. -Wl,--as-needed in LDFLAGS
> (in addition to RPM_LD_FLAGS) is one easy way that can
On 11/05/2011 07:02 PM, Tom Lane wrote:
> The list of packages that need to be rebuilt is attached.
I suggest maintainers take this opportunity to review whether all these
packages really need to be linked against libpng - I'm positive that the
list contains a lot of packages that don't. -Wl,--as
If it is a new version from upstream then the release will be 1 but if you
are updating the SPEC file you would increment the release number.
On Sat, Nov 5, 2011 at 12:20 PM, Richard Shaw wrote:
> This is my first time as a contributor to run into this.
>
> Do I simply need to increment by relea
This is my first time as a contributor to run into this.
Do I simply need to increment by release by 1 (or .1?) and build?
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
The list of packages that need to be rebuilt is attached. I'm not too
sure about ordering dependencies, but I do know that gd and libsexy
need to be rebuilt before some of the others.
Some of these packages will require source code changes. See
yesterday's discussion for hints about where to fin
28 matches
Mail list logo
