Update on packages violating the Static Library guidelines
by Michael Schwendt
* A dozen packages fixed since February.
* 23 packages left to be fixed.
* To the remaining tickets I've added comments about whether anything
in the package collection links static with a library. I've experimented
with tools that examine koji build.log output in addition to verifying
the existence of SONAME dependencies in the builds.
In some cases, this has lead to finding packages which don't produce
verbose build.log output, however (because of not using Fedora's
CMake invocation or because of silencing Make or the compiler), e.g.
http://bugzilla.redhat.com/show_bug.cgi?id=556079#c1
* Bugzilla status for packages violating the Static Library guidelines:
http://mschwendt.fedorapeople.org/staticbugstat.html
acl 556036 -> CLOSED
atlas 556037 -> CLOSED
attr 556038 -> CLOSED
audit 556039 -> CLOSED
binutils 556040 -> CLOSED
brltty 556041
Canna 556034 -> CLOSED
cdparanoia 547682 -> CLOSED
comedilib 556043
dnssec-tools 556044
e2fsprogs 545144 -> CLOSED
expat 556046 -> CLOSED
fftw2 556047
file 556048 -> CLOSED
gcc 556049
gdbm 556050 -> CLOSED
ghostscript 556051 -> CLOSED
gnutls 556052 -> CLOSED
gpsim 556053 -> CLOSED
gtk+extra 556054 -> CLOSED
hpic 556055 -> CLOSED
isdn4k-utils 556056
js 556057 -> CLOSED
ldns 556058 -> CLOSED
libaio 556059 -> CLOSED
libannodex 556060 -> CLOSED
libbtctl 556061 -> CLOSED
libcaca 556062
libcddb 556063 -> CLOSED
libcdio 556064 -> CLOSED
libcmml 556065
libdnet 556066 -> CLOSED
libevent 556067
libftdi 556068 -> CLOSED
libnl 556069
liboggz 556070 -> CLOSED
libotr 556071
librx 556072 -> CLOSED
libsemanage 556073 -> CLOSED
libsndfile 556074
libstatgrab 556075 -> CLOSED
libtranslate 556076 -> CLOSED
libtwin 556077
libuninameslist 556078 -> CLOSED
libxslt 556079
link-grammar 556080
linux-atm 556081
linuxwacom 556082 -> CLOSED
lockdev 556083 -> CLOSED
meanwhile 556084 -> CLOSED
mpich2 545149 -> CLOSED
munipack 556086
nfs-utils-lib 556087
numactl 556088 -> CLOSED
opencdk 556089 -> CLOSED
openldap 556090 -> CLOSED
proj 556091 -> CLOSED
python 556092 -> CLOSED
QuantLib 556035 -> CLOSED
rubberband 556093
shapelib 556094 -> CLOSED
syck 556095 -> CLOSED
sysfsutils 556096 -> CLOSED
texlive 556097 -> CLOSED
torque 556098
util-vserver 556099
xbsql 556100 -> CLOSED
xen 556101
xfsprogs 556102 -> CLOSED
xmlsec1 556103
xqilla 562566 -> CLOSED
14 years
Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong
by Oliver Falk
I had similar issues already and I totally agree with Christoph!
The maintainer should not redirect the bugreporter to the upstream bugreporting plattform. I already have plenty of accounts on upstream bugzillas because of exactly this...
-of
Christoph Wickert <christoph.wickert(a)googlemail.com> schrieb:
>I am irritated by the way the KDE SIG and the KDE bugzappers handle
>bugs. For most bugs that are reported they demand the reporter to file
>an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If
>the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But
>if the bug has been reported upstream, the Fedora bug gets closed
>UPSTREAM. Ether way, the bug gets closed, no matter if it was actually
>fixed or not.
>
>IMHO filing bugs upstream is a maintainers duty. We are doing the same
>in Xfce or I do the same with all my packages. The only exception I make
>are feature requests, because I cannot support a request that I don't
>understand or that I am not convinced of. The use of a feature should be
>discussed upstream with the developers because they are in no way
>specific to the distribution, but bugs that affect Fedora need to be
>tracked in Fedora.
>
>The wiki says:
>> Deal with reported bugs in a timely manner
>> * [...]
>> * If there are bugs which you aren't capable of fixing yourself
>> because they deal with intricacies of the source code which
>> you don't fully understand, then you still need to address
>> these bugs. It can be helpful to work with the upstream
>> maintainer of the code, obtain help from more code-oriented
>> people on fedora-devel, or check other distributions for
>> patches. Always be sure to post to the bug report what you
>> have done so that the reporter knows what it happening and
>> what to expect. It is recommended that non-coder packagers
>> should find co-maintainers who are familiar with the
>> programming language used by their package(s), and can help
>> with such bugs as a kind of 'second line support'.
>
>https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_w...
>
>The Fedora KDE maintainers and bugzappers already have a KDE bugzilla
>account, while most of our users don't. Thus it is easier for them to
>file the bug than it is for the user. The maintainer has to act as a
>proxy between the reporter and the developer.
>
>By closing down the bugs, our bugzilla is effectively rendered useless
>because there is no way of searching for bugs that affect our KDE
>packages. Bugzilla is for tracking bugs, not for blindly closing bug
>reports no matter if they are fixed or not!
>
>I'd like the KDE SIG and their bugzappers to reconsider their policy:
> 1. Forward bugs to the upstream developers
> 2. Leave bugs open until they are fixed upstream and in Fedora
>
>Regards,
>Christoph
>
>--
>devel mailing list
>devel(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel
14 years