Packaging guidelines with regards to packages that use Clam Antivirus scanner
by Jóhann B. Guðmundsson
I'm in the midst of converting legacy sysv init scripts that use
/usr/share/clamav/clamd-wrapper to native systemd units and I have
noticed some discrepancy in their packaging which indicate a lack of
guidelines.
Granted that I'm no clamav expert but from what I can tell the packages
that use the clamd-wrapper should all be doing the same thing and the
package that does it most right from my point of view is exim-clamd and
the worst one being dansguardian ( which seems to be yet another package
we ship that is neglected by it's maintainer(s) I come across in the
migration process).
If an guideline does exist it would be good if someone could point me
to it so I can review it and propose improvements to it if not I
recommend that we come up with one and standardize how things are being
done before things get more out of hand than they currently are ( we
have low number of packages mostly with minor differences between them
hence this situation can be dealt with ) and deliver to our user base an
working out of the box solution.
Once an guideline has been written it should be a relatively easily for
an proven packager to fix the current packages and at the same time ship
the native unit file.
JBG
11 years, 9 months
A little help with TuDu, please
by Eric Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I'm having a little problem with updating my TuDu package. Since my last update upstream removed the Makefile that I had patched to make things work. I've temporarily commented out several lines in my spec file[0] to test things but I can't get around the following error:
RPM build errors:
File not found: /root/rpmbuild/BUILDROOT/tudu-0.8.1-1.fc17.x86_64/usr/bin/tudu
File not found by glob: /root/rpmbuild/BUILDROOT/tudu-0.8.1-1.fc17.x86_64/usr/share/man/man1/tudu*
File not found: /root/rpmbuild/BUILDROOT/tudu-0.8.1-1.fc17.x86_64/usr/share/tudu
File not found by glob: /root/rpmbuild/BUILDROOT/tudu-0.8.1-1.fc17.x86_64/etc/*
File not found: /root/rpmbuild/BUILDROOT/tudu-0.8.1-1.fc17.x86_64/etc/tudurc
You can also see the entire build log[1] as I'm sure that will be helpful.
I'm sure I'm missing something simple (and I probably shouldn't be trying to do these types of things late at night) but if someone could help me out with this I'd be greatful.
[0] http://sparks.fedorapeople.org/tudu.spec
[1] http://sparks.fedorapeople.org/tudu.error
- - -- Eric
- - --------------------------------------------------
Eric H Christensen eric(a)christensenplace.us
"Sparks" sparks(a)fedoraproject.org
.... .. .-.. .-.. --- .-- --- .-. .-.. -..
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- - --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJO8XOHAAoJEIB2q94CS7PRU0oP/0syYtdN0mZvCqCxny77tW7q
oxjsk+tm8xcFxV6bcTAU4Iadp4gV5qFH76ova4FgKzD0E7wVhqV6IY1HxpKGZR2z
IQtPKHrUhSaKYfmnxB5wUthlUE7dYRESiE3FeL7R8HjoMDwz0PkR0VKZ1RHhTdRf
7GpYoDeyVoVP1Q+2tlo54JmrNgzDk3cI5DwM7z7yRrcSNsppJ2t3PlnaEgJeNjd4
XVcANO8nmTgCVi4NdMzojdwIj26K2mk41dd5ttUZRYxdEUC6UIpoDIziXe5P1XNp
NGywPpOlfQkkrdu/kl8eHr/ZXVdE787pJodlUj+HZR+mzy3M0u2R7YhISYjs40JO
iALmDM4dEYecHlyGYaKh1CXE7ITbHZz8yvF6DHZTeyOm9SFH28W7IM1Be0GkEx/K
O2CzOP3N4KDIMq7dy6rifT+ldY3V8rFggQGRj7780DYuDxYVuDJqiPUp9lPQWUUG
+J4cfbKnQuS5GGWDEqN5KHwr8d+3iTK0M3HWVSd0wI0uAzhnllSpkqBa8HCGYVxB
5o7tefeiJyhAl4KoI+abW8LIQQYZD9Cb+u0QoC9vhD490vtPvl7HwaJaAfTcRUCE
8dEu7dIMVi36mSi4jGZXfAs+5uYzdiWcLYrR4FSEpm1tUL/oQCW3WoofaufcQLN4
VRZkj7Nm6XyiiWSCswlR
=ikWi
-----END PGP SIGNATURE-----
11 years, 9 months
fedora-usermgmt
by Simone Caronni
Hello,
I'm currently committing on bacula and I've stepped into a few
problems with fedora-usermgmt.
I think the process is a bit convoluted. It is not even in the
guidelines for packaging, so I'm guessing if I can be removed it from
the package.
According to this page, the yellow box points to another links and
states clearly is not part of the packaging guidelines.
http://fedoraproject.org/wiki/PackageUserCreation
- Packages for RHEL 4/5/6 get a dependency on the EPEL repository,
which many users would like to avoid on production systems.
- Building the package gets a dependency on the EPEL repository for
the fedora-usermgmt-devel package even if it is not used at
installation time; so again the package cannot be built on RHEL
without the EPEL repository.
- "%bcond_without fedora", as suggested by the pages, does not work
with RHEL 4, as the directive is invalid.
- Koji does not accept "--without" arguments even for scratch builds,
so I cannot pass the argument as suggested by the page.
- Even if building only for RHEL 5+ I cannot build the same package on
Koji but need to upload a different package for RHEL.
I also tried setting statically a lot %if / %else and distro tags to
get a static with/without_fedora inside the spec file but I didn't
make any success with it.
After a day of frustration I looked at other packages spec files that
define uid/gid <100, and I saw that many of them don't use
fedora-usermgmt at all (i.e. NetworkManager-openconnect):
fedoraproject.org/wiki/PackageUserRegistry
Basically I will remove all of this stuff:
%if 0%{?fedora} > 0
%define with_fedora 1
%else
%define without_fedora 1
%endif
(or the non-working "%bcond_without fedora")
%global uid 33
%global username bacula
BuildRequires: fedora-usermgmt-devel
%{?FE_USERADD_REQ}
%pre common
%__fe_groupadd %uid -r %username &>/dev/null || :
%__fe_useradd %uid -r -s /sbin/nologin -d /var/spool/bacula -M \
-c 'Bacula Backup System' -g %username %username &>/dev/null || :
%postun common
%__fe_userdel %username &>/dev/null || :
%__fe_groupdel %username &>/dev/null || :
With:
Requires(pre): shadow-utils
%pre common
%{_sbindir}/groupadd -g 33 -r bacula &>/dev/null || :
%{_sbindir}/useradd -u 33 -r -s /sbin/nologin -d /var/spool/bacula -M \
-c 'Bacula Backup System' -g bacula bacula &>/dev/null || :
%postun common
test "$1" != 0 || %{_sbindir}/userdel bacula &>/dev/null || :
test "$1" != 0 || %{_sbindir}/groupdel bacula &>/dev/null || :
Can I simplify everything removing fedora-usermgmt as a requirement?
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
11 years, 9 months
Fwd: Re: (re)introducing - fedora-review - tool to help with package reviews
by Brendan Jones
On 11/21/2011 02:14 PM, Stanislav Ochotnicky wrote:
> Hello fellow devs,
>
> I am sure quite a few of you have done some reviews and thought "Hey,
> a,b,c and d could be automated. For E I could use some more
> information that can be automatically gathered". Some of you even
> wrote your own tools to do some of these things.
>
Hi Stan,
great idea. Will try to use this prior to any forthcoming reviews.
I find the most time consuming task in the review process is the license
check. I use a combination of find/head/grep commands to try and
determine if some of the source files have differing licenses to the
stated one in the spec. None of my methods guarantee 100% license
detection, given the sheer number of licenses out there, although if we
could consolidate all of the methods reviewers use for this we would
have a nifty tool indeed.
Not sure if this is something which should be part of this package or
another entirely?
regards,
Brendan
11 years, 9 months
python-2.6 on el5
by Thomas Spura
Hi list,
I'm the maintainer of python-zmq and it would be nice, if I could use
it also on el5, but I need python26 for that.
Would it be ok, to use it and provide a python26-zmq or is an extra
review request needed for that?
Couldn't find any guideline, that forbits it, but there doesn't seem
to be any naming guideline for el, isn't it?
Greetings,
Tom
11 years, 9 months
Update to Emacs packaging guidelines
by Jonathan Underwood
Hi,
I've submitted a trac ticket for updated Emacs packaging guidelines.
Trac ticket: https://fedorahosted.org/fpc/ticket/124
Link to draft: https://fedoraproject.org/wiki/PackagingDrafts/Emacs-Dec2011
This draft addresses 2 functional points:
1/ In March of this year, the guidelines were updated to allow for the
use of the recently added emacs-filesystem and xemacs-filesystem
packages (sub-packages of Emacs and Xemacs respectively). The
intention here was to allow packages which contained support files for
(X)Emacs not to have to split off extra emacs-foo sub-packages.
However, unfortunately we neglected to mention exactly how the
Requires: emacs-filesystem should appear in packages - it needs to be
a versioned Require to ensure compatibility between byte compiled
elisp files and the version of the (X)Emacs installed. this is now
clearly outlined and exemplified.
2/ Previously, we required packages which were primarily add-ons for
(X)Emacs to split out the source elisp files into separate
sub-packages, so we'd have emacs-foo and emacs-foo-el. However, this
makes packaging more complicated, and in any case having the source
elisp installed alongside the byte compiled elisp aids in debugging
when an error occurs, and also for describing variables within Emacs'
help system (they are somewhat analogous to .py anbd .pyc files for
python). For this reason the updated guideline requires both source
and compiled elisp files to be together in a single package, greatly
simplifying the guidelines.
In addition I have gone to great lengths to remove a lot of
unnecessary duplication in the guidelines, hopefully adding clarity
along the way.
Comments welcome,
jonathan.
11 years, 9 months
Packaging Guidelines and Servers
by Jeff Johnston
Hello,
There doesn't seem to be any clear documentation in the Packaging
Guidelines concerning servers that aren't meant to start on boot so I
thought I would ask for clarification.
I found the following in the systemd guidelines:
> Each package that contains software that wants/needs to start a
traditional service at boot MUST have a systemd unit file.
which I interpret as meaning a script is not required in the case of a
server that doesn't mean to start at boot.
Is this correct?
The reason I am asking is that I maintain the eclipse-rse package
(Remote System Explorer). In addition to the normal Eclipse plug-ins
and features, the upstream project also packages a server for linux that
is used to allow exploring of a linux host via the Eclipse client
software. The eclipse-rse package has not packaged the server in the
past and I wish to do so now.
The server is currently packaged upstream as a tarball to be expanded
into a single directory (/opt/rseserver is suggested). It contains perl
scripts, jar files, and some property files. The perl scripts are the
front-end and they end up using java to invoke classes found in the jar
files. The property files are used to set certain features, most
notably, ssl support. Ssl support requires some additional set-up to
work properly such as setting up a Java Keystore.
I have split up the tarball into the configuration property files which
I placed in /etc/sysconfig/rseserver, the java jar files which I put
into /usr/share/java/eclipse-rse-server and the perl scripts which I
placed into /usr/share/eclipse-rse-server. I modified the perl scripts
so that they would work with the files moved as they were.
Is my break-up of the upstream package reasonable?
Regards,
-- Jeff J.
11 years, 9 months
Viewing Fedora git source files
by Brad Bell
It used to be that one could view the Fedora cvs source files on-line.
Now that Fedora has switched to using git, where are the on-line source
files located ?
11 years, 9 months
