Multiple file ownership allowed nowadays?
by Christoph Wickert
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_Ow...
11 years, 4 months
New owner for clamav?
by Philip Prindeville
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
11 years, 4 months
Error in PREUN scriptlet in rpm package.
by Jóhann B. Guðmundsson
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
11 years, 4 months
Shipping only binaries for open source software
by Shakthi Kannan
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
11 years, 4 months
Bug in Octave packaging guideline
by Susi Lehtola
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
11 years, 4 months
external source files for clementine
by Orcan Ogetbil
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
11 years, 4 months
Override with -D_FORTIFY_SOURCE=0 as workaround allowed?
by Robert Scheck
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
11 years, 4 months
