This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 528332 - Review Request: GNUnet - Secure peer-to-peer networking framework
Review Request: GNUnet - Secure peer-to-peer networking framework
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Felix Kaechele
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW 528333 528379
  Show dependency treegraph
 
Reported: 2009-10-11 07:15 EDT by Alexander Kahl
Modified: 2011-06-30 15:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-16 04:40:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexander Kahl 2009-10-11 07:15:07 EDT
Spec URL: http://akahl.fedorapeople.org/GNUnet/GNUnet.spec
SRPM URL: http://akahl.fedorapeople.org/GNUnet/GNUnet-0.8.0c-1.fc11.src.rpm
Description:
GNUnet is a framework for secure peer-to-peer networking that does not use any
centralized or otherwise trusted services. A first service implemented on top
of the networking layer allows anonymous censorship-resistant
file-sharing. Anonymity is provided by making messages originating from a peer
indistinguishable from messages that the peer is routing. All peers act as
routers and use link-encrypted connections with stable bandwidth utilization to
communicate with each other. GNUnet uses a simple, excess-based economic model
to allocate resources. Peers in GNUnet monitor each others behavior with
respect to resource usage; peers that contribute to the network are rewarded
with better service.
Comment 1 Felix Kaechele 2009-11-18 05:51:01 EST
A first check after a mock build yields:
GNUnet.src: W: strange-permission gnunetd.init 0755
Can be solved by setting that file to chmod 644 and installing it with install -m 755 instead of using cp.

GNUnet.x86_64: W: non-standard-uid /var/run/gnunetd gnunet
GNUnet.x86_64: W: non-standard-gid /var/run/gnunetd gnunet
GNUnet.x86_64: W: non-standard-uid /var/log/gnunetd gnunet
GNUnet.x86_64: W: non-standard-gid /var/log/gnunetd gnunet
Can be ignored

GNUnet.x86_64: W: log-files-without-logrotate /var/log/gnunetd
GNUnet.x86_64: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/gnunetd
GNUnet.x86_64: W: incoherent-subsys /etc/rc.d/init.d/gnunetd $prog
Please fix.

I also get a flood of GNUnet.x86_64: W: unused-direct-shlib-dependency when running rpmlint on the installed packages. Please check this as well.

Furthermore please add comments to the patches as to where they come from and if they have been brought to upstream's notice at some point (bugzilla etc.).
Comment 2 Alexander Kahl 2009-11-20 05:43:52 EST
Spec URL: http://akahl.fedorapeople.org/GNUnet/GNUnet.spec
SRPM URL: http://akahl.fedorapeople.org/GNUnet/GNUnet-0.8.0c-1.fc12.src.rpm

> A first check after a mock build yields:
> GNUnet.src: W: strange-permission gnunetd.init 0755
> Can be solved by setting that file to chmod 644 and installing it with install
> -m 755 instead of using cp.
Hmm odd. Done.

> GNUnet.x86_64: W: log-files-without-logrotate /var/log/gnunetd
Done. Also added "Requires: logrotate".

> GNUnet.x86_64: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/gnunetd
This is a false positive and even contradicts with the guidelines:
"Each Fedora SysV-style initscript which needs to start by default in any
runlevel must include this line in the LSB Header (if the # Default-Start: line
is present, then there must also be a # Default-Stop: line.). If the service
does not start by default in any runlevel, this line should be omitted."
(https://fedoraproject.org/wiki/Packaging:SysVInitScript#.23_Default-Stop:_line)

There is no Default-Start contrary to what rpmlint utters and there should never
be for GNUnet:
"(Default-Start:) Only services which are really required for a vital system
should define runlevels here."
(https://fedoraproject.org/wiki/Packaging:SysVInitScript#.23_Default-Start:_line)

> GNUnet.x86_64: W: incoherent-subsys /etc/rc.d/init.d/gnunetd $prog
rpmlint is just too stupid to interpolate sh variables - if you replace all
instances of $prog with its value ("gnunetd"), the warning vanishes. The
line in question should be:
lockfile=/var/lock/subsys/$prog

Really want me to change that?


> I also get a flood of GNUnet.x86_64: W: unused-direct-shlib-dependency when
> running rpmlint on the installed packages. Please check this as well.
Looks like all dload'able plugins are linked against the same set of so:s;
definitely an issue for upstream. Shall I report to upstream first to have this
fixed? Should be an issue of splitting up some Makefile.am:s.

> Furthermore please add comments to the patches as to where they come from and
> if they have been brought to upstream's notice at some point (bugzilla etc.).
All patches written by myself;
patch0: GNUnet build assumes postgres includes use the "postgresql" prefix which
        is not true for Fedora.
patch1: GNUnet build assumes Qt4's moc and uic preprocessing tools to be
        available under that name but for Fedora it's moc-qt4 and uic-qt4.
patch2: GNUnet build assumes dialog's headers to be in $prefix/include but for
        Fedora it uses a prefix with the same name (dialog).
patch3: This fixes really a GNUnet bug naming cpp defines wrong when using
        dialog, for cdialog the bug is not present but cdialog is not available
        for Fedora.
patch4: This one is also a real bug where GNUnet's plugin path is always assumed
        to be $prefix/lib/GNUnet despite $plugindir being used in other places
        correctly which is expanded to the arch-dependent lib dir at build time.

For patches 0-2 we have to find out whether Fedora uses file locations and names
from the vanilla build of postgres, Qt4 and dialog; in this case, upstream most
probably uses Debian-specific locations and names (seems to be their primary
development distro) so it'd be their issue. In any other case, the problem is
ours and subject of further investigation with the corresponding packages'
maintainers.
The problem addressed by patch4 *could* be caused by Debian-specific behavior of
GNUnet, do you know whether Debian uses /usr/lib for plugins independent from
installed architecture?

Patch3 is obviously an issue for upstream.

Shall we fix the upstream-related stuff before proceeding any further? I can
report everything after investigation.
Comment 3 Alexander Kahl 2009-12-31 07:34:58 EST
Ping
Comment 4 Enrico Scholz 2010-01-01 08:48:49 EST
It would be nice when the modules and database backends are packaged in separate subpackages; e.g. the current monolithic package requires all the gtk, postgresql, mysql, qt... stuff.  People might want to run a GNUnet server in a dmz where gtk + qt are not wanted and where only one database backend is needed.
Comment 5 Christoph Maser 2010-01-01 08:56:50 EST
While you are at it there is 0.8.1 available now, maybe that makes some of the patches unnecessary already.
Comment 6 Enrico Scholz 2010-01-01 09:13:03 EST
fwiw, the dialog, postgresql and qt4 location patches can be alternatively solved by

----
%prep
...
mkdir -p _dialog _postgresql/include
ln -s %_includedir/dialog _dialog/include
ln -s %_includedir        _postgresql/include/postgresql


%build
...
# put qt4 stuff into $PATH
p=`pkg-config --variable=bindir Qt`
PATH=$p:/usr/bin:/bin

%configure ... \
	--with-dialog=`pwd`/_dialog		\
	--with-postgres=`pwd`/_postgresql	\
----

The hardcoded 'lib' can and should be solved as in patch4 (the whole dynamic stuff in GNUNET_get_installation_path() is very flaky and not needed for Fedora).
Comment 7 Enrico Scholz 2010-01-01 09:55:02 EST
You might want to hack in '-Wl,--as-needed' LDFLAGS, e.g. by

---
%configure ... \
	LDFLAGS='-Wl,--as-needed'

sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool
---

Generated binaries/libraries add too much dependencies else; e.g. 'ld -u -r' shows unused libraries like

WARN: /usr/bin/gnunetd: linked against unused libraries
    /lib64/libz.so.1
    /usr/lib64/libextractor.so.1
    /usr/lib64/libadns.so.1
    /lib64/libgcrypt.so.11
    /lib64/libgpg-error.so.0
    /usr/lib64/libgmp.so.3
    /usr/lib64/libltdl.so.7
    /lib64/libm.so.6
    /lib64/libpthread.so.0
    /lib64/libdl.so.2


See http://people.redhat.com/drepper/dsohowto.pdf, "3.9 Inter-Object File Relations" for more information.
Comment 8 Alexander Kahl 2010-01-11 06:44:12 EST
Update:
http://akahl.fedorapeople.org/GNUnet/GNUnet.spec
http://akahl.fedorapeople.org/GNUnet/GNUnet-0.8.1-1.fc12.src.rpm

Changes:
- update to 0.8.1
- use local symlinks instead of patches to fix include path issues
  (Kudos to Enrico Scholz)
- use same trick for mysql libdir, hardwired to /usr/lib
- run gnunet-update as root in post (changes /etc/gnunetd.conf) and don't void
  possible warnings
- updated Patch4 (still necessary)
- new Patch5, fixes obvious copy'n'paste bug in configure.ac for pgsql
  cppflags/ldflags
- use --as-needed linker option to avoid superfluous dso linking
  (Kudos to Enrico Scholz)
- split up libs offering optional bindings (gtk, qt, mysql, pgsql)

Enrico: I've assigned Kudos to you on ohloh.net ;)
Comment 9 Felix Kaechele 2010-01-11 08:19:31 EST
I'm currently on off-the-job training so my internet access is limited to mobile broadband.
Thus I'll probably not be able to review this package until the end of this week. But I will be taking care as soon as possible. Sorry.

By the way: You can remove
BuildRequires:  gcc
BuildRequires:  gcc-c++
See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2

The rest of the spec file looks promising. I will have to test the compile process and linking stuff still.
Comment 10 Alexander Kahl 2010-01-12 04:01:53 EST
(In reply to comment #9)
> Thus I'll probably not be able to review this package until the end of this
> week. But I will be taking care as soon as possible. Sorry.
No need to sorry, I'm busy at times as well ;)

> By the way: You can remove
> BuildRequires:  gcc
> BuildRequires:  gcc-c++
> See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2
Done.

> The rest of the spec file looks promising. I will have to test the compile
> process and linking stuff still.    
Do we already need to take care of the ongoing changes for F13 were explicit linking is required..? (see https://fedoraproject.org/wiki/UnderstandingDSOLinkChange)
Comment 11 Alexander Kahl 2010-01-31 11:46:44 EST
Ping :)
Comment 12 Felix Kaechele 2010-05-13 14:37:50 EDT
Today I tried building GNUnet version 0.8.1b on F13. It fails with the message that it requires libextractor. However libextractor as well as libextractor-devel are installed during build. Maybe you could further investigate.
Comment 13 Benny 2010-10-01 03:52:40 EDT
Same problem with libextractor here...

Note You need to log in before you can comment on or make changes to this bug.