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
27 matches
Mail list logo
