Packaging kernel modules
by Nguyen Kim Son
Hello,
I'd like to package a kernel module for my company repository ( I know that
fedora doesn't accept kernel module for official repo). I have followed the
link
http://rpmfusion.org/Packaging/KernelModules/Kmods2
But when I build the spec file, there are always some errors like:
*kernel-devel-uname-r = 2.6.32.14-127.fc12.i686.PAEdebug.PAE is needed by
mymodule-kmod-0.0-1{?dist}.1.src*
that I don't have any idea about.
Actually, I don't really understand this mechanism: if for example, I want
to install foo on my machine with kernel 2.6.32.14 but there is only
kmod-foo-2.6.32.12, does yum take this package automatically? Or do I need
to make a package for kernel 2.6.32.14? What kmod does exactly?
Thank you in advance,
Son.
--
---------------------------------------------------------
Son NGUYEN KIM
Antibes 06600
Tel: 06 48 28 37 47
13 years, 10 months
Update on packages violating the Static Library guidelines
by Michael Schwendt
* 19 packages fixed since May 21st. Tom Callaway has done almost all of
the work.
* 2 packages left to be fixed.
* "gcc" has returned due to another static library in its packages,
and no news on "binutils-devel". It still enforces static linkage by
using ld scripts.
The following source rpms don't "BuildRequires: binutils-static" but
binutils-devel:
alleyoop-0:0.9.7-1.fc13.src
avarice-0:2.10-1.fc13.src
CodeAnalyst-gui-0:2.8.54-21.fc13.src
kernel-0:2.6.34-43.fc14.src
ksplice-0:0.9.9-1.fc12.src
latrace-0:0.5.7-1.fc12.src
libdwarf-0:0.20090324-5.fc12.src
lush-0:1.2.1-6.fc12.src
mutrace-0:0.2-1.fc13.src
sblim-wbemcli-0:1.6.0-5.fc12.src
stapitrace-0:2.0.0-0.20090304cvs_alpha.fc12.1.src
sysprof-0:1.1.6-1.fc14.src
* Bugzilla status for packages violating the Static Library guidelines:
http://mschwendt.fedorapeople.org/staticbugstat.html
acl 556036 -> CLOSED
atlas 556037 -> CLOSED
attr 556038 -> CLOSED
audit 556039 -> CLOSED
binutils 556040
brltty 556041 -> CLOSED
Canna 556034 -> CLOSED
cdparanoia 547682 -> CLOSED
comedilib 556043 -> CLOSED
dnssec-tools 556044 -> CLOSED
e2fsprogs 545144 -> CLOSED
expat 556046 -> CLOSED
fftw2 556047 -> CLOSED
file 556048 -> CLOSED
gcc 556049
gdbm 556050 -> CLOSED
ghostscript 556051 -> CLOSED
gnutls 556052 -> CLOSED
gpsim 556053 -> CLOSED
gtk+extra 556054 -> CLOSED
hpic 556055 -> CLOSED
isdn4k-utils 556056 -> CLOSED
js 556057 -> CLOSED
ldns 556058 -> CLOSED
libaio 556059 -> CLOSED
libannodex 556060 -> CLOSED
libbtctl 556061 -> CLOSED
libcaca 556062 -> CLOSED
libcddb 556063 -> CLOSED
libcdio 556064 -> CLOSED
libcmml 556065 -> CLOSED
libdnet 556066 -> CLOSED
libevent 556067 -> CLOSED
libftdi 556068 -> CLOSED
libnl 556069 -> CLOSED
liboggz 556070 -> CLOSED
libotr 556071 -> CLOSED
librx 556072 -> CLOSED
libsemanage 556073 -> CLOSED
libsndfile 556074 -> CLOSED
libstatgrab 556075 -> CLOSED
libtranslate 556076 -> CLOSED
libtwin 556077 -> CLOSED
libuninameslist 556078 -> CLOSED
libxslt 556079 -> CLOSED
link-grammar 556080 -> CLOSED
linux-atm 556081 -> CLOSED
linuxwacom 556082 -> CLOSED
lockdev 556083 -> CLOSED
meanwhile 556084 -> CLOSED
mpich2 545149 -> CLOSED
munipack 556086 -> CLOSED
nfs-utils-lib 556087 -> CLOSED
numactl 556088 -> CLOSED
opencdk 556089 -> CLOSED
openldap 556090 -> CLOSED
proj 556091 -> CLOSED
python 556092 -> CLOSED
QuantLib 556035 -> CLOSED
rubberband 556093 -> CLOSED
shapelib 556094 -> CLOSED
syck 556095 -> CLOSED
sysfsutils 556096 -> CLOSED
texlive 556097 -> CLOSED
torque 556098 -> CLOSED
util-vserver 556099 -> CLOSED
xbsql 556100 -> CLOSED
xen 556101 -> CLOSED
xfsprogs 556102 -> CLOSED
xmlsec1 556103 -> CLOSED
xqilla 562566 -> CLOSED
13 years, 10 months
Package dependant on kernel version
by Nguyen Kim Son
Hello,
I'am trying to package BLCR (Berkeley Lab Checkpoint/Restart) , whose
installation is different for kernel 2.6.31 and kernel 2.6.32.
I'd like to know, after packaging for each version of kernel, how yum can
know which one is right for him? Could it be done simply by adding the
kernel version to package name? And is there a way for example, the
2.6.32.12 and 2.6.32.5 ones could use the same rpm file?
BLCR create .ko file in /lib/modules/ kernel_version_in_packaging_machine.
Could I tell yum to change that kernel version to automatically ?
Thanks in advance,
Son.
--
---------------------------------------------------------
Son NGUYEN KIM
Antibes 06600
Tel: 06 48 28 37 47
13 years, 10 months
version in package name with a number in the name
by Patrice Dumas
Hello,
I would like to package a more recent version of hdf5 (in a private repo,
but the issue is clearly there for EPEL). According to the naming guideline,
with hdf5-1.8.4, the name could be along hdf518. But this is a bit annoying.
Wouldn't it be better to have an exception and allow hdf5-18?
--
Pat
13 years, 10 months
llvm case study: yum's handling of newly-converted noarch subpackages
by Michel Alexandre Salim
An LLVM user reported to me a problem updating LLVM (from the version
in F13-updates to the version that is then in Koji), and I suggested
that he filed a bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=600969
In the discussion that follows, James Antill diagnosed the problem as
due to llvm-doc being changed to be a noarch subpackage, as supported
by RPM 4.7 and above, and thus when using yum to update from
llvm-2.7-1 (with arched -doc) to 2.7-4 (noarch doc), llvm-2.7-1 causes
llvm-2.7-1.i686 to be pulled in to satisfy the dependencies)
To reproduce:
- on an x86_64 system, yum install llvm-doc
- Download llvm{,-doc} from Koji
http://koji.fedoraproject.org/koji/buildinfo?buildID=176782
- Try a yum localupdate or a yum localinstall
The suggested fix by James, and by some folks on #fedora-devel, is to
make the new -doc Obsoletes: the old doc. This, alas, does not quite
work:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2236690
- Download llvm-2.7-5 from the scratch builds above
- Retry localupdate / localinstall
the -doc update is considered but then dropped.
Any idea how to fix this? We should probably add a section to the
packaging guidelines, on how to migrate to noarch subpackages without
breaking upgrade paths.
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
13 years, 10 months
binutils once more
by Michael Schwendt
The saga "binutils does not adhere to Static Library Packaging Guidelines"
continues.
Temporarily the issue had been fixed, then it has been reverted by adding
"Provides" that violate the guidelines again. When I permitted my checker
script to reopen the bugzilla ticket, it was quickly closed as NOTABUG
this time.
binutils : does not adhere to Static Library Packaging Guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=556040
The ticket that lead to violating the guidelines again:
libbfd.so in binutils-devel needs libbfd.a in binutils-static
https://bugzilla.redhat.com/show_bug.cgi?id=576300
[...]
I'd appreciate if the Fedora Packaging Committee discussed this and either
officially excludes the binutils package from the guidelines or adjusts the
guidelines.
To brief all readers: binutils ships shared *and* static libs, but it
replaces the *.so files used for linking at build-time with ld scripts
that only link statically. It has been said that the library interfaces
are not stable enough to link shared.
$ rpmlsv -p binutils-2.20.51.0.7-3.fc14.i686.rpm | grep /lib
-rwxr-xr-x root root 881172 /usr/lib/libbfd-2.20.51.0.7-3.fc14.so
-rwxr-xr-x root root 561296 /usr/lib/libopcodes-2.20.51.0.7-3.fc14.so
$ rpmlsv -p binutils-static-2.20.51.0.7-3.fc14.i686.rpm|grep /lib
-rw-r--r-- root root 23878 /usr/include/libiberty.h
-rw-r--r-- root root 1104328 /usr/lib/libbfd.a
-rw-r--r-- root root 271 /usr/lib/libbfd.so
-rw-r--r-- root root 274322 /usr/lib/libiberty.a
-rw-r--r-- root root 589216 /usr/lib/libopcodes.a
-rw-r--r-- root root 202 /usr/lib/libopcodes.so
$ cat libbfd.so
/* GNU ld script */
/* Ensure this .so library will not be used by a link for a different format
on a multi-architecture system. */
OUTPUT_FORMAT(elf32-i386)
/* The libz dependency is unexpected by legacy build scripts. */
INPUT ( /usr/lib/libbfd.a -liberty -lz )
$ rpm -qp --provides binutils-static-2.20.51.0.7-3.fc14.i686.rpm
binutils-devel = 2.20.51.0.7-3.fc14
binutils-static = 2.20.51.0.7-3.fc14
binutils-static(x86-32) = 2.20.51.0.7-3.fc14
13 years, 10 months
cannot find -lsupc++ devel i686
by Philippe Makowski
Hi,
Is there someone to explain me why I get this error message for i686
build in devel
> /usr/bin/ld: cannot find -lsupc++
I did not get it in F-13, neither in local mockbuild x86_64
What am I missing ?
thanks
13 years, 10 months
Sponsorship model
by Parag Nemade
Hi all,
I see https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
says that
" The best ways for you to illustrate your understanding of the
packaging guidelines
are to submit quality packages and to assist with package reviews."
My question is that is it really mandatory for new contributors to
assist with pre-reviews of packages in NEW queue? Can we sponsor new
contributor based on his package submissions only( say he submitted 3
to 5 packages)?
Regards,
Parag.
13 years, 10 months
Inaccurate information about LiVES package
by salsaman
Hi all,
I am the main developer/maintainer of LiVES (http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page:
http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all,
LiVES is not dependant on ffmpeg. As in, you can perfectly well build and
run the application without ffmpeg being present on either the build system
or the end user system.
However, the ffmpeg libraries are recommended for end users, since LiVES
will make indirect use of them (via mplayer) for decoding some video
formats, and via mencoder for encoding some video formats.
I fail to see the reason for this to be sufficient cause for crossing out
LiVES. A long time ago, ffmpeg contained some allegedly patented code (AAC
audio IIRC), however this code was removed from the core of ffmpeg at least
5 years ago. However it seems that the FUD (and that is indeed what it is)
persists. Microsoft must be laughing hard at this one.
If you don't believe me, then how is it that both ffmpeg and LiVES are in
debian testing and unstable ? Please check for yourselves, and contact the
debian legal team if you are still in doubt.
It is particularly timely that I noticed this, as I would like to introduce
the new packager for LiVES in Fedora, Harry Rickards (harry(a)linux.com).
Harry is also the point of contact between LiVES and the debian multimedia
team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop
spreading (unintentional ?) FUD about ffmpeg, and most importantly give
Harry every assistance with the Fedora LiVES packages.
Regards,
Salsaman,
main developer, LiVES.
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
13 years, 10 months
Confusion regarding file location
by Rangeen Basu
Hi
I am tying to package GNUMed software which has server and client
separate. The server files consists of a few sql files, a few python
files and some shell scripts. There are some .conf files as well but
they are not config files in true sense as they never change. They are
more like static data files. The upstream provides the source where
the .conf files , .py files and shell scripts have to be in the same
directory. These files are used only once during the initial setup or
bootstrap and are never used again. Also the python files are just
scripts and not python modules which will never be imported by anyone.
Can all these files be put in the same location such as
/usr/lib/gnumed-server . Where should .sql files be put.
--
Regards
Rangeen Basu Roy Chowdhury
Fedora Ambassador
sherry151(a)gmail.com
13 years, 10 months
