ruby gem and library in C and debuginfo
by Dan Horák
Hi,
I am doing a review for a ruby gem package that includes a library
written in C (https://bugzilla.redhat.com/show_bug.cgi?id=497640) and
there are problems with proper generation of the debuginfo package. It
cannot find the source files, because the paths in the debugsources.list
contains the "ext/<libname>" part twice and that's wrong.
+ /usr/lib/rpm/find-debuginfo.sh
--strict-build-id /home/dan/rpmbuild/BUILD/rubygem-RedCloth-4.1.9
extracting debug info
from /home/dan/rpmbuild/BUILDROOT/rubygem-RedCloth-4.1.9-3.fc10.x86_64/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/redcloth_scan.so
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c: Cannot stat: No such file or directory
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c.rl: Cannot stat: No such file or directory
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c: Cannot stat: No such file or directory
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c.rl: Cannot stat: No such file or directory
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c: Cannot stat: No such file or directory
cpio:
rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c.rl: Cannot stat: No such file or directory
Dan
14 years, 5 months
Question about triggers
by Alan Evans
Can triggers be assigned to arbitrary capabilities or only by actual packages?
All the docs I have read give me the impression that triggers are only triggered by packages and not arbitrary capabilities.
Regards,
-Alan
14 years, 5 months
FPC meeting time proposal
by Jason L Tibbitts III
I wasn't sure if I should just directly mail this to the FPC members,
but I figured this should work as well.
At the last meeting those present discussed moving the meeting to
better accommodate folks who have a tough time making it now.
My understanding is that we can go at most two hours earlier because
that puts the meeting at 8AM US Pacific time. We have to move at
least one hour earlier to accommodate our friends in CET/CEST.
The proposal discussed at the meeting is to move to Wednesdays at
15:00UTC. This would give us a two hour block and still give us (me)
sufficient time before the FESCo meeting to get a report in.
Unfortunately Toshio realized this morning that he would have to miss
the first 30 minutes of that meeting due to another commitment.
Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes
of channel time. I'd like to see a reply from each of the committee
members indicating whether this works or not. Otherwise I'll mail you
personally.
- J<
14 years, 5 months
Allowing only one package to provide a virtual capability
by Alan Evans
I am sorry if this is the wrong place but it seems that the rpm-list
does not exist any more and this list looks to be the best fit
otherwise.
I am trying to create a few packages that all provide a virtual
capability but would like to allow only one of these packages to be
installed at a time. Has to be compatible with RPM 4.2 and greater.
(RHEL4 and RHEL5)
<snip>
Name: package-a
Provides: package-a config(package)
</snip>
<snip>
Name: package-b
Provides: package-b config(package)
</snip>
<snip>
Name: package-c
Provides: package-c config(package)
</snip>
I could obviously add Conflicts: package-b package-c to package
package-a and so on, but every time I add a new package-X I have to
manually go through my spec files and update the Conflicts tags. Again
I suppose I could script the update but it seems less elegant.
I tried:
<snip>
Name: package-a
Provides: package-a config(package)
Conflicts: config(package)
</snip>
But the result is:
config(package) conflicts with package-a-1.1-1.svn20090428.noarch
I thought I saw something like this in another list, will post link if I
can find it. Where the goal was to only allow one package that provides
a particular virtual capability.
Anyone know how to accomplish this or if this is the wrong list can you
direct me to a better resource?
Regards,
-Alan
14 years, 5 months
about compiler flags
by Orcan Ogetbil
I have 2 questions. The first one is brought to my attention by a
first time reviewer and he has got an interesting point.
The guidelines at
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
say:
"Adding to and overriding or filtering parts of these flags is
permitted if there's a good reason to do so; the rationale for doing
so should be reviewed and documented in the specfile especially in the
override and filter cases."
As you probably know that some packages add their own compiler flags
on top of what we specified as %optflags. Until now, I did not do
anything about these flags unless they override our %optflags. Now,
having a second thought, I realized that the above statement can be
interpreted in two ways:
1- The extra flags are added by the packager: This is the way I used
to interpret the guideline, and I always document if I add additional
flags on top of %{optflags}
2- The extra flags are added by the build script of upstream: Here is
the question: Do we need to document such cases in the specfile? I
know that we have hundreds (maybe thousands) of packages which don't
document this case in the specfile. Are such packages violating the
above guideline?
Second question: From the same link above:
"Compilers used to build packages should honor the applicable compiler
flags set in the system rpm configuration."
Does this apply to the stage where the compiler is doing the linking,
i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in
this stage too? Again, I know many packages that don't pass %optflags
to the compiler during the linking. Do these pakcages violate the
guideline?
Orcan
14 years, 5 months
Packaging guideline draft for globus toolkit
by Toshio Kuratomi
Mattias Ellert has proposed guidelines for packaging things from the
Globus toolkit. It's a long document so I figured I'd give people a
heads up so you don't come to the Meeting expecting to read it all there ;-)
I've added a few small comments to the talk page:
https://fedoraproject.org/wiki/Talk:PackagingDrafts/Globus
Since I'm writing this, I'll add them here as well:
* Could ./globus-spec.pl be put into a package?
* Obtaining sources should also include copying over the the license
file
Mattias, let me know if it's better for you to have discussion on
fedora-packaging list or on the talk page.
-Toshio
14 years, 5 months
Sysreport is still in rawhide - why?
by Jussi Lehtola
Hi,
why is sysreport still available in rawhide?
# yum --enablerepo=rawhide list sysreport
Loaded plugins: downloadonly, refresh-packagekit
Available Packages
sysreport.noarch 1.4.4-3
rawhide
# yum install sysreport
Loaded plugins: downloadonly, refresh-packagekit
Setting up Install Process
Parsing package install arguments
Package sysreport is obsoleted by sos, trying to install
sos-1.8-9.fc10.noarch instead
Package sos-1.8-9.fc10.noarch already installed and latest version
Nothing to do
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
14 years, 5 months
