packaging December 2011

packaging@lists.fedoraproject.org

26 participants
11 discussions

Get paid to package! (Etherpad Lite)
by Rich Jones 20 Feb '13

20 Feb '13

Hey all! I didn't post this bounty, but it came across our system and it seems like you guys might be able to earn a quick bit of money on this one: http://gun.io/contracts/16/rpm-based-install-for-etherpad-lite-on-rhel-128 Any takers? -- Rich Jones Director, Gun.io

7 6

Packaging guidelines with regards to packages that use Clam Antivirus scanner
by Jóhann B. Guðmundsson 22 Dec '11

22 Dec '11

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

3 5

A little help with TuDu, please
by Eric Christensen 21 Dec '11

21 Dec '11

-----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-----

2 1

fedora-usermgmt
by Simone Caronni 20 Dec '11

20 Dec '11

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).

7 12

Fwd: Re: (re)introducing - fedora-review - tool to help with package reviews
by Brendan Jones 17 Dec '11

17 Dec '11

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

3 4

python-2.6 on el5
by Thomas Spura 14 Dec '11

14 Dec '11

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

6 13

Update to Emacs packaging guidelines
by Jonathan Underwood 07 Dec '11

07 Dec '11

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.

1 0

Packaging Guidelines and Servers
by Jeff Johnston 07 Dec '11

07 Dec '11

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.

2 1

Emacs packaging guideline change of 22nd March 2011 - discussion?
by Jonathan Underwood 07 Dec '11

07 Dec '11

Hi, I see that the packaging guidelines for Emacs add-ons were changed on 22nd March 2011 this year, but I completely missed any discussion of this change: https://fedoraproject.org/w/index.php?title=Packaging%3AEmacs&action=histor… The guideline as it now stands presents a few problems, but before I go about proposing a fix-up I'd like to find the discussion that led to this change - any pointers? Thanks, Jonathan

2 2

Viewing Fedora git source files
by Brad Bell 07 Dec '11

07 Dec '11

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 ?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2011