This is my first package, and I am seeking a sponsor.

I wanted to make a note that in the spec file I claim the license of this app is
gpl/bsd/mit but thats because the code I found in its src has all of them. I
wasnt sure which of the 3 to use.

If a package is covered by the gpl and another licence, then the whole
must be under the GPL. So the licence for the package is GPL, unless you
have split it such that all the files of a subpackage have the other
licence.

Quoting the GPL:
   b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

You should readd FE-NEW.

You should use %configure.

The glibc related buildrequires are unneeded as said here:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30

Patrice, thanks for looking this one over too. I got the above things fixed and
the new spec is here: http://errr.fluxbox-wiki.org/fedora_stuff/conky/3/conky.spec
and the srpm is here:
http://errr.fluxbox-wiki.org/fedora_stuff/conky/3/conky-1.4.2-3.fc5.src.rpm

You also need to block FE-NEEDSPONSOR too ;-) 

Some comments:

* your changelog entries are not very informative. You could have
  better said something along
- use the GPL as licence since the whole package is GPL
- use %%configure

  and so on.

* NEWS is empty, no need to ship it

* The part 'originally based on the torsmo code' in the summary
  seems unneeded to me.

* the summary shouldn't end with a dot

* your changelog entries are badly formatted. The version should
  be at the end of the line beginning with *.

* a BR (BuildRequires) for libXext-devel is mmissing, and libX11-devel
  is required by libXext-devel.

* In xmms.c it seems that a file is created in /tmp with a predictible
  name. If it is the case, there is a security issue, since it allows
  a symlink attack.

* still in xmms.c it seems that conky dlopens some libs to do something
  with the music players. This won't work since the .so are in the 
  devel packages. Is this code used in your package? If it is the case
  there is certainly something wrong upstream, and maybe the dlopened
  files should be below /usr/lib/xmms/, or conky should be linked
  against libxmms and not dlopen it.

* is it on purpose that there are no requires for xmms/bmp...?

* When I start conky I get a trace:
$ conky
*** buffer overflow detected ***: conky terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x9f2161]
/lib/libc.so.6(__strcpy_chk+0x43)[0x9f1663]
conky[0x8064eed]
/lib/libc.so.6(__libc_start_main+0xdc)[0x926f2c]
conky[0x804ab91]
======= Memory map: ========
00111000-00116000 r-xp 00000000 03:03 379787     /usr/lib/libXdmcp.so.6.0.0
00116000-00117000 rwxp 00004000 03:03 379787     /usr/lib/libXdmcp.so.6.0.0
00196000-0019d000 r-xp 00000000 03:03 2412643    /lib/librt-2.4.90.so
0019d000-0019e000 r-xp 00006000 03:03 2412643    /lib/librt-2.4.90.so
0019e000-0019f000 rwxp 00007000 03:03 2412643    /lib/librt-2.4.90.so
002c7000-002cb000 r-xp 00000000 03:03 379797     /usr/lib/libXfixes.so.3.1.0
002cb000-002cc000 rwxp 00003000 03:03 379797     /usr/lib/libXfixes.so.3.1.0
0034e000-00360000 r-xp 00000000 03:03 377780     /usr/lib/libXft.so.2.1.2
00360000-00361000 rwxp 00012000 03:03 377780     /usr/lib/libXft.so.2.1.2
005b5000-005ce000 r-xp 00000000 03:03 2408357    /lib/ld-2.4.90.so
005ce000-005cf000 r-xp 00018000 03:03 2408357    /lib/ld-2.4.90.so
005cf000-005d0000 rwxp 00019000 03:03 2408357    /lib/ld-2.4.90.so
00624000-00649000 r-xp 00000000 03:03 2408914    /lib/libm-2.4.90.so
00649000-0064a000 r-xp 00024000 03:03 2408914    /lib/libm-2.4.90.so
0064a000-0064b000 rwxp 00025000 03:03 2408914    /lib/libm-2.4.90.so
006fd000-0077a000 r-xp 00000000 03:03 374846     /usr/lib/libfreetype.so.6.3.10
0077a000-0077d000 rwxp 0007d000 03:03 374846     /usr/lib/libfreetype.so.6.3.10
00911000-00a49000 r-xp 00000000 03:03 2408410    /lib/libc-2.4.90.so
00a49000-00a4b000 r-xp 00138000 03:03 2408410    /lib/libc-2.4.90.so
00a4b000-00a4c000 rwxp 0013a000 03:03 2408410    /lib/libc-2.4.90.so
00a4c000-00a4f000 rwxp 00a4c000 00:00 0 
00a9c000-00aaf000 r-xp 00000000 03:03 2410955    /lib/libpthread-2.4.90.so
00aaf000-00ab0000 r-xp 00012000 03:03 2410955    /lib/libpthread-2.4.90.so
00ab0000-00ab1000 rwxp 00013000 03:03 2410955    /lib/libpthread-2.4.90.so
00ab1000-00ab3000 rwxp 00ab1000 00:00 0 
00b21000-00c21000 r-xp 00000000 03:03 362396     /usr/lib/libX11.so.6.2.0
00c21000-00c25000 rwxp 000ff000 03:03 362396     /usr/lib/libX11.so.6.2.0
00c56000-00c61000 r-xp 00000000 03:03 2420666    /lib/libgcc_s-4.1.1-20060926.so.1
00c61000-00c62000 rwxp 0000a000 03:03 2420666    /lib/libgcc_s-4.1.1-20060926.so.1
00d1c000-00d1e000 r-xp 00000000 03:03 364990     /usr/lib/libXdamage.so.1.0.0
00d1e000-00d1f000 rwxp 00001000 03:03 364990     /usr/lib/libXdamage.so.1.0.0
00d48000-00d4a000 r-xp 00000000 03:03 2408862    /lib/libdl-2.4.90.so
00d4a000-00d4b000 r-xp 00001000 03:03 2408862    /lib/libdl-2.4.90.so
00d4b000-00d4c000 rwxp 00002000 03:03 2408862    /lib/libdl-2.4.90.so
00d52000-00d54000 r-xp 00000000 03:03 379786     /usr/lib/libXau.so.6.0.0
00d54000-00d55000 rwxp 00001000 03:03 379786     /usr/lib/libXau.so.6.0.0
00d57000-00d66000 r-xp 00000000 03:03 379793     /usr/lib/libXext.so.6.4.0
00d66000-00d67000 rwxp 0000e000 03:03 379793     /usr/lib/libXext.so.6.4.0
00d69000-00d88000 r-xp 00000000 03:03 2408514    /lib/libexpat.so.0.5.0
00d88000-00d8a000 rwxp 0001e000 03:03 2408514    /lib/libexpat.so.0.5.0
00df3000-00dfb000 r-xp 00000000 03:03 379789     /usr/lib/libXrender.so.1.3.0
00dfb000-00dfc000 rwxp 00007000 03:03 379789     /usr/lib/libXrender.so.1.3.0
00e89000-00eb0000 r-xp 00000000 03:03 361587     /usr/lib/libfontconfig.so.1.1.0
00eb0000-00eb8000 rwxp 00027000 03:03 361587     /usr/lib/libfontconfig.so.1.1.0
0324b000-032e8000 r-xp 00000000 03:03 2408445    /lib/libglib-2.0.so.0.1200.3
032e8000-032e9000 rwxp 0009c000 03:03 2408445    /lib/libglib-2.0.so.0.1200.3
032eb000-032f3000 r-xp 00000000 03:03 379812     /usr/lib/libSM.so.6.0.0
032f3000-032f4000 rwxp 00007000 03:03 379812     /usr/lib/libSM.so.6.0.0
032f6000-0330d000 r-xp 00000000 03:03 379811     /usr/lib/libICE.so.6.3.0
0330d000-0330e000 rwxp 00016000 03:03 379811     /usr/lib/libICE.so.6.3.0
0330e000-03310000 rwxp 0330e000 00:00 0 
08048000-08071000 r-xp 00000000 03:03 380814     /usr/bin/conky
08071000-08073000 rwxp 00028000 03:03 380814     /usr/bin/conky
08073000-0807b000 rwxp 08073000 00:00 0 
090b3000-090d4000 rwxp 090b3000 00:00 0 
b7fa30Abandon

Patrice, thanks for looking at this one so close for me.

* Your first few comments should be a simple enough fix. 

* The xmms issue you speak of I am getting with the developers of the app about
because I am not sure.

* The reason I dont have a require for xmms/bmp is because I wanted support for
them but not to require them since they are not needed for the app to function

I will fix these issue and post an update soon, thanks for you help.

* Hints for upstream:
 - remove the huge autom4te.cache directory from the source tarball


* Re: comment 6 : dlopening the *.so lib symlinks is an upstream bug.
They ought to dlopen the versioned libs instead.


* BuildRequires glib2-devel _and_ glib-devel? We do have glib2, and it
is found and built with, so old glib1 is not needed.


* BuildRequires xorg-x11-server-Xorg asks for an explanation in the spec
file, since this requirement is not obvious.


> ./configure: line 22513: AM_ICONV: command not found
> configure: WARNING: Could not find libiconv

??? -> /usr/include/iconv.h -> glibc-devel -> available by default


> checking for X... no

???


* %doc file INSTALL is irrelevant to RPM package users


* Backtrace at run-time:

(gdb) bt
#0  0x0083f402 in __kernel_vsyscall ()
#1  0x00a22d40 in raise () from /lib/libc.so.6
#2  0x00a24591 in abort () from /lib/libc.so.6
#3  0x00a5818b in __libc_message () from /lib/libc.so.6
#4  0x00adb161 in __chk_fail () from /lib/libc.so.6
#5  0x00ada663 in __strcpy_chk () from /lib/libc.so.6
#6  0x08064ecd in main (argc=1, argv=0xbf969144) at conky.c:6582
#7  0x00a0ff2c in __libc_start_main () from /lib/libc.so.6
#8  0x0804ab71 in _start ()

 => Blocker!

Insecure programming leads to this crash. "temp" array is too small
for the length of our locale env values. When started as
"LC_ALL=C conky" it works. Lines around 6582 of conky.c:

#ifdef X11
	char *s;
	char temp[10];        /* !!! */
	unsigned int x;

	if (((s = getenv("LC_ALL")) && *s) || ((s = getenv("LC_CTYPE")) && 
		     *s) || ((s = getenv("LANG")) && *s)) {
		strcpy(temp, s);     /* !!! */

Hello,

About licensing: are you sure the whole package should be GPL? The majority of
conky code is under BSD license and the COPYING file is in the tarball contains
BSD license. However, some components are under GPL/LGPL (specificly: music
detection for xmms-based players, portmon stuff for linux and libmpdclient and
maybe something else I forgot).

(In reply to comment #9)
> Hello,
> 
> About licensing: are you sure the whole package should be GPL? 

You can have a look at comment #2 where I explain that the GPL
cause the whole to be under the GPL (that's the 'viral' component
of the GPL). It may be relevant to add a file descripting the 
licences covering the different components, or add that in 
comment in the spec.

http://errr.fluxbox-wiki.org/fedora_stuff/conky/5/conky.spec

http://errr.fluxbox-wiki.org/fedora_stuff/conky/5/conky-1.4.3-1.src.rpm

A new release has come out, they removed the dlopen() stuff and xmms and bmp
support completely. Im not sure at this time if it will build in mock, but I did
build from my home dir and it works fine thus far. Once I finish setting up my
local repos again I will build in mock. In the mean time how does this lokk.. no
rpmlint errors..

OK, this builds fine in mock for fc6, but not on fc5 due to the audacious-devel
BR. While I was looking though this new source I found that it includes a vim
and nano syntax highlighting files, should I include this into the build as
well?? I am pretty sure both editors are installed by default on the system..
what are your thoughts on this??

I don't see a need for glib2, glib, X, twm and hddtemp as buildrequires.
conky links against a lot of libraries it doesn't need, all of them are
pulled in by audacious.pc. I think audacious.pc is buggy, it should have
some Requires.static instead of only Requires.

regarding the syntax highlighting files, you can do subpackages which 
requires the editors, with files installed at the right place, or 
add them in %doc.

I still think that 'originally based on the torsmo code' in summary
isn't needed.

Also maybe doc/docs.html and doc/conkyrc.sample could be in %doc.

rpmlint gives:
W: conky macro-in-%changelog configure

I am waiting on this for the next release, since I submitted the last package
they released a 1.4.4 and the word I got from the devs in IRC the other day was
that 1.4.5 was coming soon cause of some other bugs that have been reported. I
am not going to sub package the vim and nano syntax files. I was thinking of
including them with the docs and the sample config; how does this sound?? 

Patrice, if you think the audacious.pc is buggy maybe I shouldnt build the
package to support it??

(In reply to comment #14)

> am not going to sub package the vim and nano syntax files. I was thinking of
> including them with the docs and the sample config; how does this sound?? 

Sounds fine.

> Patrice, if you think the audacious.pc is buggy maybe I shouldnt build the
> package to support it??

No, it is not a blocker, building support for audacious is the right thing
to do. The only downside of having bogus dependencies on sonames is that
if those sonames change you'll have to rebuild conky even though it 
doesn't depend on those sonames (in that case audacious only depends 
on those sonames, and audacious only would have to be rebuilt). I am 
trying to popularise this issue such that there are less bogus 
dependencies. Unneeded linking is detected by running
ldd -u -r
on installed apps and libraries. The solution is, in general, to use
pkgconfig, and use the Requires.private and Libs.private right.

http://errr.fluxbox-wiki.org/fedora_stuff/conky/conky-1.4.4-1.src.rpm
http://errr.fluxbox-wiki.org/fedora_stuff/conky/conky.spec

comment #13 is still relevant for buildrequires and additional
docs.

I think that you shouldn't put the vim and nano files in 
%_datadir, but simply use:

%doc extras/* 

http://errr.fluxbox-wiki.org/fedora_stuff/conky/conky-1.4.4-3.src.rpm

The audacious header /usr/lib/audacious/beepctrl.h does expose glib to clients
such as conky that use this interface for audacious status.  I don't disagree
that audacious.pc exposes too much, but I would also characterize this issue as
something for the audacious devs to address.

Meantime, building conky with:

AUDACIOUS_CFLAGS="`pkg-config --cflags glib-2.0`" \
AUDACIOUS_LIBS="-laudacious `pkg-config --cflags glib-2.0`" \
./configure --enable-audacious ...

can be used to override the "pkg-config --cflags --libs audacious" excess and
will yield a trimmer set of "true" deps for the conky binary (w.r.t. audacious)

Phil (drphibes, conky dev)

typo sry: /usr/include/audacious/beepctrl.h

(In reply to comment #19)
> The audacious header /usr/lib/audacious/beepctrl.h does expose glib to clients
> such as conky that use this interface for audacious status.  I don't disagree
> that audacious.pc exposes too much, but I would also characterize this issue as
> something for the audacious devs to address.

Indeed. But it is something which annoys the conky packager ;-)

> Meantime, building conky with:
> 
> AUDACIOUS_CFLAGS="`pkg-config --cflags glib-2.0`" \
> AUDACIOUS_LIBS="-laudacious `pkg-config --cflags glib-2.0`" \
> ./configure --enable-audacious ...
> 
> can be used to override the "pkg-config --cflags --libs audacious" excess and
> will yield a trimmer set of "true" deps for the conky binary (w.r.t. audacious)

I don't think this is the proper way to handle that issue, the
right fix is to fix what is broken (the audacious pkgconfig file).
It is not such a problematic issue that it needs a workaround.

(In reply to comment #19)
> The audacious header /usr/lib/audacious/beepctrl.h does expose glib to clients

Does conky uses directly the glib functions? If not, it is better
to have glib-devel as an indirect dependency through audacious-devel.
Thus if audacious stops using the glib, conky wouldn't need to be modified.
If glib-devel is a direct dependency of conky it would be better to
list it in buildrequires, but it doesn't seems to be the case since
conky itself don't include the glib headers (unless I am missing 
something).

* rpmlint is silent
* follow guidelines
* sane provides
* buildrequires seem right
* match upstream
c856556d4372226f99cf7e9a888e9118  conky-1.4.4.tar.bz2
* doc not content

A remark (not a blocker, may be changed later, the group is not
used for anything currently), but Applications/System seems wrong
to me, something like 'User Interface/X' would be better in my 
opinion.

A blocker: the COPYING is a BSD like license, while the whole is
under the GPL. First of all (especially if upstream authors listen 
that report ;-) the GPL notice should also be in the tarball, along
with the BSD license, named, for example COPYING.GPL. But it is
not an obligation for you as a packager to add the license if it isn't
done upstream. However, in cases like conky, where there are more than 
one license covering parts of code, and especially in that case, with
a COPYING which doesn't match the package license, some clarification
is required. I see 2 way to do that clarification:

* add a file with the appropriate name, stating something along

Most of the conky code is covered by the BSD license in COPYING,
some files are GPL, and other files lack attribution and seem to be in 
the public domain.

* do an audit of the code and add file with the summary, with
something like (you can also have a look at what I did for grads, in
/usr/share/doc/grads-1.9b4/grads-copyright_summary)


Files under the GPL:
libtcp-portmon.h      
libtcp-portmon.c      
audacious.h
....

Files covered by the BSD license in COPYING:
conky.h
conky.c
remoted.c
....

Files covered by a BSD license (from http://www.musicpd.org):
libmpdclient.c
libmpdclient.h

No clear license, GPL compatible?
 * Besed on code published in _Mastering Algorithms in C_
 * by Kyle Loudon (O'Reilly 1999).
 * Modified by Philip Kovacs 
hash.h
hash.c

No clear license, seems to be public domain:
 *  $Id: ftp.h 130 2005-08-21 22:10:54Z brenden1 $
ftp.c
ftp.h

 * $Id: mpd.c 598 2006-03-16 18:29:23Z jasper_la $
mpd.c

 *  $Id: linux.c 738 2006-11-08 03:06:42Z pkovacs $
linux.c

No license, no author, certainly public domain
xmms2.c
netbsd.c
....




Doing a full audit of the source takes more time, but it allows 
to find problematic files. In that case, we have

hash.h
hash.c
 which have clearly 2 authors, but no license. No license (since the 
Bern convention) means a restrictive license (no right to redistribute
or modify). So it needs clarification from Philip.

For ftp.c, ftp.h, mpd.c and linux.c, I am not sure that a rcs Id acts
as an author identification, but if it is the case, then there is the
same issue than for hash.c, otherwise they may be considered public
domain.

(as a side note, if I recall well interfaces cannot have their 
copyright enforced, so if I am not wrong so the .h licenses are 
not really problematic).

(In reply to comment #22)
> (In reply to comment #19)

> Does conky uses directly the glib functions? If not, it is better
> to have glib-devel as an indirect dependency through audacious-devel.
> Thus if audacious stops using the glib, conky wouldn't need to be modified.
> If glib-devel is a direct dependency of conky it would be better to
> list it in buildrequires, but it doesn't seems to be the case since
> conky itself don't include the glib headers (unless I am missing 
> something).

Yes, conky uses glib directly in audacious.c, i.e. #include <glib.h>.
The audacious status interface allocates gchar * strings that must be
freed by the client with g_free() -- song titles, etc.

(In reply to comment #23)
> Doing a full audit of the source takes more time, but it allows 
> to find problematic files. In that case, we have
> 
> hash.h
> hash.c
>  which have clearly 2 authors, but no license. No license (since the 
> Bern convention) means a restrictive license (no right to redistribute
> or modify). So it needs clarification from Philip.

That code originates from here:

http://www.kyleloudon.com/books, specifically the "Read a sample" link:
http://www.oreilly.com/catalog/masteralgoc/chapter/ch08.pdf

I believe the licensing falls under the O'Reilly policy stated here:

http://www.oreilly.com/pub/a/oreilly/ask_tim/2001/codepolicy.html

I have emailed the author for clarification in any event.

Phil

(In reply to comment #24)

> Yes, conky uses glib directly in audacious.c, i.e. #include <glib.h>.
> The audacious status interface allocates gchar * strings that must be
> freed by the client with g_free() -- song titles, etc.

Oops, I missed it. A Buildrequires on glib2-devel would be appropriate
(but not mandatory, since audacious-devel also brings it in).

(In reply to comment #25)
> (In reply to comment #23)

> > hash.h
> > hash.c

> http://www.oreilly.com/catalog/masteralgoc/chapter/ch08.pdf

The amount of code is such that it doesn't fall in the fair use case.

> I believe the licensing falls under the O'Reilly policy stated here:
> 
> http://www.oreilly.com/pub/a/oreilly/ask_tim/2001/codepolicy.html

It is clearly not GPL compatible due to the restrictions on commercial
use. Maybe the author could accept to relicense it under a GPL
compatible license? You could also consider adding the isbn to
the license notice. Seems to be 1565924533.

(In reply to comment #27)

> It is clearly not GPL compatible due to the restrictions on commercial
> use. Maybe the author could accept to relicense it under a GPL
> compatible license? You could also consider adding the isbn to
> the license notice. Seems to be 1565924533.

OK. I removed the hash modules from the project completely and reprogrammed 
using GLib's GHashTable.  Conky 1.4.5 will reflect this change.

Conky 1.4.5 has been released.

http://sourceforge.net/projects/conky/

http://errr.fluxbox-wiki.org/fedora_stuff/conky/conky-1.4.5-1.src.rpm

There are still timed_thread.c and timed_thread.h with an author and 
no license, which means a restrictive license:


/* timed_thread.c
 * Author: Philip Kovacs

I missed them in my previous audit, but it is Philip who is the
author, so it shouldn't be problematic...

Also NEWS is now relevant so should be shipped.

So is shipping NEWS the only thing needed for this to get added or is there
another blocker??

Shipping the NEWS file is not a blocker, but the license issue
is a blocker. We need a word from Philip on timed_thread.c.

Sorry, I forgot to affix the Lesser GPL licens to my original modules.

The following now appears on the timed_thread modules in svn:

/*
 * timed_thread.h: Abstraction layer for timed threads
 *
 * Copyright (C) 2006  Philip Kovacs pkovacs.net
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301
 * USA.
 *
 */

The NEWS file is in the tarball, but I forgot to update it for 1.4.5.
That too has been updated in svn.   I hope these minor points don't
hold up inclusion for you.

NEWS
----
Summary of changes for Conky release 1.4.5:
-------------------------------------------
Added config items:
- max_specials
- max_port_monitor_connections

Removed config items:
- min_port_monitors
- min_port_monitor_connections

Added variables:
- entropy_avail
- entropy_poolsize
- entropy_bar

Added length specifier to audacious_title.

Split battery var into:
- battery and battery_time

Fixed broken texeci variable.
Fixed build error with --disable-x11.
Fixed build error with --disable-xdamage.
Fixed acpi battery issues.
Fixed mem var overflows when >= 4GB.
Close pop3/imap sockets properly.
Improved internal thread handling.
Converted tcp_portmon internal hash to GLib for GPL compatibility.

I attach the svn patch, adding it would be satisfying in my opinion.

The review was already done in comment #23.

still match upstream.
4625c052852f2919a5e7ce2eb7c31189  conky-1.4.5.tar.bz2

APPROVED

with the patch applied.

Created attachment 143549 [details]
diff against svn with NEWS and licenses updates

I also would like to thanks Philip for helping with the review.

My pleasure. Thank you for including conky in your distribution.

Patrice, that patch wont apply cleanly.. I just made a diff -Naur of the
timed_thread.c and .h files and of the News file, will that be fine??

http://errr.fluxbox-wiki.org/fedora_stuff/conky/conky-1.4.5-2.src.rpm

(In reply to comment #40)
> Patrice, that patch wont apply cleanly.. I just made a diff -Naur of the
> timed_thread.c and .h files and of the News file, will that be fine??

Yes, it's fine, you can import it.

(In reply to comment #39)
> My pleasure. Thank you for including conky in your distribution.

I think that you should consider adding the GPL and LGPL license
texts in your package, for example with names like COPYING.LGPL, 
COPYING.GPL. Otherwise it may be possible that one (a judge) consider 
the GPL/LGPL to be invalid for your code.

Created attachment 143672 [details]
conky-1.4.5 patch for fedora

Attached is a patch that will work against the conky 1.4.5 tarball.

The svn keyword $Id$ was the problem.  Working copies have expanded 
keywords, but the svn repository does not.

tar -xjf conky-1.4.5.tar.bz2
cd conky-1.4.5
patch -p0 < patchfile

That should work cleanly.

Created attachment 143674 [details]
conky-1.4.5 patch for fedora (signature)

My signature for the patch.  My public key:

http://home.comcast.net/~147F2970/pubkey.asc

Philip

Package Change Request
======================
Package Name: conky
New Branches: el6
Owners: mlichvar

Git done (by process-git-requests).

Package Change Request
======================
Package Name: conky
New Branches: epel7
Owners: mlichvar moceap

Git done (by process-git-requests).