packaging June 2012

packaging@lists.fedoraproject.org

22 participants
13 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

Building the freemedforms suite
by Ankur Sinha 28 Jun '12

28 Jun '12

Hello, Freemedforms[1] a suite of medical software. It contains a few applications: freemedforms-emr freediams freeaccounts others are still under development ... At the time I packaged the freemedforms-emr (and when my review for freediams was approved), upstream released separate tars for each of these. They were therefore straight forward packages (I hadn't gotten down to building freediams for Fedora yet. I've now built it, but it's segfaulting. I'm waiting on upstream for a fix) I recently updated the freemedforms package for fedora. I also went ahead and split the package into meaningful subpackages based on their functions. Spec[2] I've found that upstream now releases a single tar[3] for all these applications which has made the packaging incredibly messy. These applications also share private libraries that are required for each of them during both build and runtime (I've placed these in a freemedforms-common-libs package in the spec). Upstream maintains the package for debian. This is the "rules" file[4]. You'll notice upstream uses a single "spec" file to build all the applications. I was wondering if I should follow this? It will involve multiple invocations of qmake in the spec. Is that permitted? There doesn't seem to be a single command to build the entire suite at the moment. It'll also increase the number of subpackages, but I think I can handle the complexity. Another issue is that upstream is still working on other applications which are part of the suite. If I use a single spec, when these applications are ready, how does a packager include them? I'd like each of them reviewed before inclusion. We can't just modify an existing spec (another packager may not have access to the spec either) How should I proceed? Should I keep the applications as different packages as I currently plan to? Should I look to use a single spec and generate the entire suite? I've tried to fix as many issues as I could in the spec. If you do observe any, please let me know. I've only built at the moment, and not pushed any updates. [1] http://www.freemedforms.com/en/ [2] http://pkgs.fedoraproject.org/gitweb/?p=freemedforms.git;a=blob;f=freemedfo… [3] http://code.google.com/p/freemedforms/downloads/list [4] http://code.google.com/p/freemedforms/downloads/list -- Thanks, Warm regards, Ankur: "FranciscoD" Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/

1 0

Adjust old ruby guidelines to new ruby guidelines
by Till Maas 28 Jun '12

28 Jun '12

Hi, I noticed that the old ruby guidelines[0] and the new ruby guidelines[1] use different macro names, for example gemname and gem_name. Since the old guidelines need to be used for several years in EPEL, I propose to adjust the old guidelines to the new guidlines as much as possible: - use consistent macro names - define macros provided in rubygems-devel in F17+ in spec files according to the old guidelines Are there any general objections? Otherwise I will prepare a Packaging Draft with above changes. Regards Till [0] https://fedoraproject.org/wiki/Packaging:Old_Ruby [1] https://fedoraproject.org/wiki/Packaging:Ruby

2 1

Where Can I Find Previous Versions?
by Joseph D. Wagner 27 Jun '12

27 Jun '12

I've noticed that mirrors no longer appear to contain previous versions of packages. For example, when kernel-3.4.3 was released, kernel-3.4.2 disappeared from all the mirrors. I recently had regression troubles, and I wanted to downgrade to a previous version to resolve the issue. However, I was surprised to find the previous version was gone. My only option was to downgrade to the original version that came with the distribution. I was very disappointed with that. Is there some place I can find the previous version? If not, is it possible to change this so at least 1 previous version is left in the mirrors? Joseph D. Wagner

2 1

Python compiled files without .py in a name
by Martin Krizek 27 Jun '12

27 Jun '12

Hi, a project I am packaging contains a few python scripts that do not have .py in a name. I gather only files containing .py are bytecompiled during RPM building. And so if there is a file called "script" in the site-packages, it is bytecompiled once the file is used and "scriptc" is created. Then after uninstalling the package, "scriptc" is left on the filesystem. What is the correct/proper way to handle such files? Or even, am I missing something? Thanks, Martin

2 1

Questions about feature "Systemd unit cleanup and enhancement"
by Simone Caronni 19 Jun '12

19 Jun '12

Hello, I have a couple of questions regarding the new feature just approved, in particular regarding the "scope" section: https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup#Scope 1) Change PIDFile=/var/run/foo fields to point to PIDFile=/run/foo instead Is there a rpm macro for the "/run" directory? I was using "--with-pid-dir=%{_localstatedir}/run" in a SPEC file for %configure. Maybe there's something similar already declared into the expansion of %configure for Fedora 18? What should I do if the pid directory is specified into the configuration file of the daemon I'm mantaining? Can the user still run with its own config upon successful upgrade to Fedora 18? 2) Remove various entries in units which are no longer necessary since they are systemd defaults for unit simplification Where can I get such list? (Git, wiki pages, man pages) Thanks & regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).

3 3

PHP library must not requires Apache
by Remi Collet 14 Jun '12

14 Jun '12

Here is a small change proposal to PHP Guildelines https://fedoraproject.org/wiki/PackagingDrafts/PHP Please comment before I submit this to FPC. Remi.

4 7

Re: [Fedora-packaging] PHP library must not requires Apache
by Remi Collet 11 Jun '12

11 Jun '12

Le 11/06/2012 20:20, Tom Callaway a écrit : > On 06/11/2012 01:51 PM, Remi Collet wrote: >> Le 11/06/2012 19:04, Tom Callaway a écrit : >>> >>> Why? Is there something that requires explicitly Apache httpd that >>> merits this removal? >> >> php requires httpd >> >> From : repoquery --whatrequires php (quickly filtered) >> >> mlt-php-0:0.7.8-1.fc17.x86_64 >> php-IDNA_Convert-0:0.6.3-5.fc17.noarch >> php-Kohana-0:2.4-1.rc2.fc17.1.noarch >> php-LightweightPicasaAPI-0:3.3-4.fc17.noarch >> php-Smarty-0:2.6.26-3.fc17.noarch >> php-ZendFramework-0:1.11.11-2.fc17.noarch >> php-doctrine-Doctrine-0:1.2.4-2.fc17.noarch >> php-email-address-validation-0:0-0.5.20090910svn.fc17.noarch >> php-feedcreator-0:1.7.2-6.fc17.noarch >> php-geshi-0:1.0.8.10-2.fc17.noarch >> php-getid3-0:2.0.0b5-4.fc17.noarch >> php-hkit-0:0.5-6.fc17.noarch >> php-laconica-0:0.5.0-7.fc17.noarch >> php-libguestfs-1:1.18.0-1.fc17.x86_64 >> php-markdown-0:1.0.1n-3.fc17.noarch >> php-oauth-0:1.0-0.10.svn1262.fc17.noarch >> php-pdb-0:1.3.4-6.fc17.noarch >> php-pear-Payment-Process-0:0.6.6-7.fc16.noarch >> php-pecl-selinux-0:0.3.1-8.fc17.x86_64 >> php-phpSmug-0:2.1-3.fc17.noarch >> php-swift-Swift-0:4.1.7-1.fc17.noarch >> php-symfony-symfony-0:1.4.8-4.fc17.noarch >> php-voms-admin-0:0.6-2.fc17.noarch >> php-xmpphp-0:0.1-0.9.rc2_r77.fc17.noarch >> rrdtool-php-0:1.4.7-5.fc17.x86_64 >> >> So installing one of this library will pull httpd. > > Yes, but do they need _Apache_ httpd, or will any webserver suffice? No, a library don't need any webserver. > > ~tom > > == > Fedora Project >

1 0

imapsync packaging in fedora
by Mihamina Rakotomandimby 11 Jun '12

11 Jun '12

Hi, given http://lists.debian.org/debian-legal/2011/01/msg00044.html What's the status of imapsync? -- RMA.

2 1

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 07 Jun '12

07 Jun '12

Here is the latest set of changes to the Fedora Packaging Guidelines: --- In Fedora, you can assume that the default shell (/bin/sh) is bash. Thus, all scriptlets can safely assume that if they are running in shell code, they are running within bash. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Default_Shell --- A bundling exception was granted for calibre to bundle their forked version of pyPdf. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- A new set of MinGW guidelines are in place for Fedora 17+. These guidelines reflect the existence of mingw32 and mingw64. https://fedoraproject.org/wiki/Packaging:MinGW Older guidelines remain in place for older versions of Fedora (and RHEL 6 or older): https://fedoraproject.org/wiki/Packaging:MinGW_Old --- A section of the Ruby Guidelines concerning the appropriate place to copy C extensions in the spec file template has been clarified and enhanced: https://fedoraproject.org/wiki/Packaging:Ruby#Building_gems --- Guidelines for usage of tmpfiles.d have been updated to better reflect the current stage of Fedora and other Fedora guidelines. In summary: * Dropped the irrelevant talk of "both systemd and upstart" * Prefer talking of /run everywhere instead of /var/run * Ship the packaged files in %{_prefix}/lib/tmpfiles.d/, not %{_sysconfdir}/tmpfiles.d/. * Do not mark the files as %config and add an explanation why. * Use the more usual 'd' specifier instead of 'D'. * Nudge packagers into thinking about the permission mode of their directories, rather than copying the "0710" dogmatically. https://fedoraproject.org/wiki/Packaging:Tmpfiles.d --- The systemd guidelines have been update to reflect the fact that unit files should avoid using StandardOutput= or StandardError=. The default is the right choice for almost all cases, and using the default allows users to change global defaults in /etc/systemd/system.conf. Also, all references to "After=syslog.target" have been dropped, as that is no longer correct or relevant in current versions of Fedora. https://fedoraproject.org/wiki/Packaging:Systemd --- The packaging guidelines now mention that the %make_install macro (*not* to be confused with %makeinstall) may be used instead of "make DESTDIR=%{buildroot}". http://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_m… --- A new section was added to the guidelines to indicate that Fedora uses gcc as the compiler (for all languages that gcc supports). Packages may only build with an alternative compiler to gcc if upstream does not support gcc. https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to Kevin Fenzi, Hans de Goede, Vít Ondruch, Erik van Pienbroek, Petr Pisar, Lennart Poettering, Michal Schmidt, Rahul Sundaram, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2012