packaging January 2012

packaging@lists.fedoraproject.org

38 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

Multiple file ownership allowed nowadays?
by Christoph Wickert 30 Jan '12

30 Jan '12

My package gtkhash can now build both against gtk2 and gtk3. I am about to package the two versions as gtkhash and gtkhash3, but both packages would share one file, /usr/share/gtkhash/gtkhash.xml. You can install both packages at the same time, at least here on F15 it works fine. However it is not allowed by the packaging guidelines: "Packages must not own files already owned by other packages." [1] I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a gtkhash-common package for only a single file. Can we allow multiple file ownership, at least when a file comes from the same srpm? Regards, Christoph [1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Owne…

7 11

New owner for clamav?
by Philip Prindeville 25 Jan '12

25 Jan '12

I've filed a few defects against different issues with clamav not installing correctly, missing files, and having the wrong permissions that precludes interactions with collaborating software such as postfix and mimedefang. I've not had traction on this, i.e. not heard back from the owner. I'd like to request that this package be considered orphaned and eligible for reassignment... and by the same occasion, ask if there's anyone willing to adopt it? It doesn't require a lot of patching. It just is finicky about being installed correctly with the correct users in place, group ownerships, etc. I will add that the support of sysvinit, upstart, and systemd makes this package a little more thorny than most, just so that if anyone steps up they don't do so uninformed. Thanks, -Philip

3 2

PHP 5.4 feature, change proposal to PHP Guidelines
by Remi Collet 25 Jan '12

25 Jan '12

Here is the FPC ticket https://fedorahosted.org/fpc/ticket/136 Here is the Packageging draft for change proposal https://fedoraproject.org/wiki/PackagingDrafts/PHP Remi.

1 0

Error in PREUN scriptlet in rpm package.
by Jóhann B. Guðmundsson 23 Jan '12

23 Jan '12

When updating a package I came across this "Error in PREUN scriptlet in rpm package". Now further inspection revealed that there was a misplaced semicolon in %preun section of the relevant spec file. Easily fixable but what is the proper procedure to fix this via update without having the user having to go to a terminal and run rpm -e --noscripts $oldpackage to remove the old package? JBG

3 4

Shipping only binaries for open source software
by Shakthi Kannan 17 Jan '12

17 Jan '12

Hi, I would like to know is there a way in Fedora to ship only binaries of a free/open source software. Upstream releases the sources under a free/open source software license, but, would like one to register (for free) at their website before downloading the source. They want to be able to track who downloaded the sources. So, would it be possible to ship such software as binaries in Fedora, without "yumdownloader --source" providing the sources? SK -- Shakthi Kannan http://www.shakthimaan.com

7 8

Bug in Octave packaging guideline
by Susi Lehtola 16 Jan '12

16 Jan '12

Hi, I noticed a bug in the Octave packaging guidelines http://fedoraproject.org/wiki/Packaging:Octave The noarch spec template should BuildRequires: octave-devel instead of octave, as the necessary rpm macros are in the octave-devel package. Could someone please fix this? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

external source files for clementine
by Orcan Ogetbil 13 Jan '12

13 Jan '12

Hello, I have a grey-area issue. The new version of the clementine player comes bundled with 3rd party source files: sha2 [1], echoprint-codegen [2]. There are no licensing issues. Unfortunately, neither of the two upstreams provide their source files as libraries. From the descriptions in their webpages [1] and [2], they seem to me as "take this code and use it in your project as you wish". The question is, how do you think this would play with our guidelines? Thanks, Orcan PS: A similar question arose during the package review of clementine for the bundled universalchardet source files. At the time, we allowed it through noting that there were other packages in Fedora bundling universalchardet sources. [1] http://www.aarongifford.com/computers/sha.html [2] https://github.com/echonest/echoprint-codegen

4 5

Override with -D_FORTIFY_SOURCE=0 as workaround allowed?
by Robert Scheck 11 Jan '12

11 Jan '12

Hello folks, am I allowed to override -D_FORTIFY_SOURCE=2 with -D_FORTIFY_SOURCE=0 for my Zarafa package until either upstream fixed their code or until glibc is making their protection check more flexible? I already read the Packaging Guidelines, but they still leave open, what's happening, if I am doing it. Our glibc > 2.14.90-8 contains a commit which adds range checking to FD_SET and friends (http://sourceware.org/ml/glibc-cvs/2011-q3/msg00235.html). I also found http://sourceware.org/bugzilla/show_bug.cgi?id=10352 meanwhile, and it's funny to see that Ulrich Drepper implemented what he didn't even want to revisit in the bug report. Finally, that FD_SET range checking causes Zarafa to segfault once it has been built using glibc > 2.14.90-8 (which is Fedora 16+), __fdelt_chk() is simply called as they use more than 1024 file descriptors. https://bugzilla.redhat.com/show_bug.cgi?id=760888 contains whole story, I sat down with Jan Kratochvil to identify the cause, communicated with the Zarafa developers and with Jeff Law, our glibc package maintainer. And also with Adam Jackson on IRC. The feedback from the Zarafa developers was, that the check in glibc is a good idea, but based on wrong assumptions. Together with the upcoming mass- rebuild they think, we could have a lot of fun, because many software will possibly run into __fdelt_chk(). I hope, I summarized them correct. I'm not a developer/programmer, but from what I get > 1024 file descriptors work under certain conditions and if correctly developed and thus the glibc range check is maybe not flexible enough. From the BSD 4.2 FD_SET man page (http://www.manpagez.com/man/2/FD_SET/): > [...] The default size FD_SETSIZE (currently 1024) is somewhat smaller > than the current kernel limit to the number of open files. However, in > order to accommodate programs which might potentially use a larger number > of open files with select, it is possible to increase this size within a > program by providing a larger definition of FD_SETSIZE before the > inclusion of <sys/types.h>. [...] I might be wrong, but that is what Zarafa is doing and what glibc code is not covering. Maybe somebody with proper knowledge can have a look to this once more? Thanks! > # Segmentation faults with glibc > 2.14.90-8, see RHBZ #760888 > export CXXFLAGS="${RPM_OPT_FLAGS/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=0}" Above is the snippet, that I would like to introduce into the spec file for the time being and to get the software up and running again. As you can see in the bug report, there are users running into this issue. Greetings, Robert

4 6

Fwd: [Bug 771941] Review Request: bacula-docs - Bacula documentation
by Simone Caronni 11 Jan '12

11 Jan '12

Hello, I created the review request for the bacula-docs spin-off package, but nobody seems to be taking care of it. As this is my first review I'm not sure I'm doing things correctly. Am I missing something in the procedure to bring it to the correct people attention? Thanks, --Simone ---------- Forwarded message ---------- From: <bugzilla(a)redhat.com> Date: 5 January 2012 18:14 Subject: [Bug 771941] Review Request: bacula-docs - Bacula documentation To: negativo17(a)gmail.com Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=771941 --- Comment #1 from Simone Caronni <negativo17(a)gmail.com> 2012-01-05 12:14:45 EST --- Updated; as suggested I created a bacula-devel subpackage that's required by bacula-docs to build. Thanks Tom Callaway: Spec URL: http://slaanesh.fedorapeople.org/bacula.spec SRPM URL: http://slaanesh.fedorapeople.org/bacula-docs-5.2.3-7.fc16.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug. -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2012