example kernel-module package
by Thorsten Leemhuis
Hi guys,
sorry, I was mostly away the last two days so you had to fight with
kernel-modules alone. I'll try to catch up and reply where I think it's
needed.
Anyway, I created a example package with kernel-modules for ndiswrapper
to play a bit with the discussed scheme. It
I maintain ndiswrapper (and some other kernel-module-packages) already
for livna. I just chooesed it for this example cause it's small, builds
fast and needs a userspace-program and a kernel-module.
I followed the example in the wiki and some posts on this list. I split
the package in a userland package that creates a %{name}-kmsrc.rpm that
is used by the kernel-module-package as source. Something like this
would be neat package like nvidia als ati drivers where a single srpm is
quite big if you want to rebuild only the kernel-module (yes, it seems a
lot of users of livna users do that).
Find the specs and SRPMS at
http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/
Comments?
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
18 years, 2 months
Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad)
by Ignacio Vazquez-Abrams
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
> On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
> > As an aside, I didn't think Extras was ready to tackle the issue of
> > kernel module packages yet.
>
> Right, at least three issues remain: how to name the modules, how to
> make depsolvers do the right thing with them, and how to request builds
> for i586 and i686 from the build system for the same package.
Screw i586 for now. As for naming, the kernel version needs to be stored
*somewhere*. And we need to finalize the naming issue before we can
decide what behavior depsolvers need.
> But we should really fix the remaining issues with kernel module builds,
> I'd like to get LIRC modules shipped too, and there may be other stuff
> queued up from others. Anybody willing to (re)start or join this
> discussion somewhere? fedora-packaging?
Works for me. Here's my first submission:
https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00965.html
I've had to make a few changes for FC4, and I'll post those later today
when I get a chance.
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
18 years, 2 months
%check script issues
by Marius Feraru
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello folks.
Current Packaging Guidelines [1] don't say anything about the
%check script, so the only source of _documentation_ for now is the mere
paragraph from Maximum RPM [2] which states:
"
This script's primary function is to run the test suite of the built
software to ensure that the binaries work correctly. Some typical
commands to run in this script are make test or make check.
"
Ok, nothing new for now, but there is one footnote [3] there:
"
One popular hack to make spec files containing the %check script
work with RPM versions older than 4.2 roughly similarly as in newer
versions is to include it immediately after the %install script in the
spec file and append '|| :' to it, like:
%check || :
"
Fedora Extras team (seeing provided template specs from fedora-rpmdevtools)
and everybody in fact (reviewing prior discussions on the various Fedora
related channels - mailing list, websites) seems to agree on this and
already started using this procedure on some of the current packages in
Fedora Core/Extras.
The hack suggested in [3] ("%check || :" _after_ %install) and the
testing done determined that this %check is done after %install (sort of
"%__spec_install_post").
So, here come my issues:
a) Maybe I really don't get it (reading [2] again and again), but it
seems more appropiate to append this %check to %build (or even prepend
it to %install), but I see no point for doing it _after_ %install.
b) What is the "easy" way to disable %check? "--define 'check exit 0'"
doesn't sound as "easy" as e.g. "--without check".
Ok, b) is more like a rant or something, but a) bothers me a lot. Before
knowing about this %check, I was adding a %{!?_without_test:make test}
to the %build script and this seems good enough for me. Why should I
"upgrade" to using this %check script?
TIA.
References:
[1] http://fedoraproject.org/wiki/PackagingGuidelines
[2] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html
[3] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html#FTN.AEN8053
- --
Marius Feraru http://www.altblue.com/
"It isn't easy being the parent of a three-years-old.
However, it's a pretty small price to pay for having somebody
around the house who understands computers."
-----BEGIN PGP SIGNATURE-----
iD8DBQFCvzM3n0ZKufYp8iURAgwbAJ9vq/rGlUqL/iO+wOmtcqmg0F6uiACfTGFm
4v5UcwUaSoVvhiJtDq7FUUA=
=3s5Z
-----END PGP SIGNATURE-----
18 years, 2 months
tetex packaging question
by Michael A. Peters
I'm packaging a package for personal use at the moment, I don't think
I'll be submitting it to Extras any time soon as it has some issues (see
bottom), but I want to make sure my personal packaging is what would be
expected if it were to be submitted.
package is latex2rtf
It is suppose to translate a latex package to rtf
http://mpeters.us/testing/latex2rtf.spec
http://mpeters.us/testing/latex2rtf-1.9.15.destdir.patch
http://mpeters.us/testing/latex2rtf-1.9.15-0.1.src.rpm
Packaging questions -
upstream ctan is a zip archive, but unlike most ctan archives - this
archive contains a bunch of archives within it, including the source
tar.gz tarball I'm using for the package (and an older version). So what
I did is referenced where the ctan archive came from in a comment,
noting the source tarball is contained within. That seemed better to me
than having prep do everything inside a zip archive full of stuff that
wasn't going to be used.
Secondly - I'm not using the tetex namespace. Since upstream has latex
in the name already, and it isn't a package that you would call from
within a tetex document, I didn't think that was necessary.
Thirdly - the package in the Makefile wants to put its .cfg files
in /usr/local/share/latex2rtf
I'm instead putting them in /usr/share/texmf/tex/latex/latex2rtf
Since it doesn't have any .sty files and isn't a package that a latex
document would use, though, I'm not sure that that is the right thing to
do. The reason I'm putting them there is because I wanted the
documentation in texmf so that texdoc would find the documentation.
Since it isn't a tetex package that other packages would use, is what
I'm doing wrong?
Thanks for comments.
-=-
The compile gives a LOT of warnings when compiled with $RPM_OPT_FLAGS -
but it works OK. The tex file I'm trying it out on has some png images
and some complex math equations (some inline, some not) - but was
created in LyX and I think needs some cleaning, there's some latex
warnings - the resulting rtf has some unwanted text at the beginning of
all non inline complex equations as part of the image "Created using
babel.pl from version 3.7 ..." and the document is missing the table of
contents and a few other minor things, but I don't know how much of that
is a problem with latex2rtf or how much of it is caused by LyX exporting
to tex in a possibly less than ideal way - but I'll figure that out when
I have cleaned up the latex ;)
18 years, 3 months
Using self-Obsoletes instead of Epoch bumps?
by Ville Skyttä
Has anyone ever experimented with or considered using self-Obsoletes as
an alternative to Epoch bumps using plain rpm CLI and various
depsolvers?
Assuming there's a finite and known set of "supported" packages, listing
all of them as an explicit, exact (note: always "=")
Obsoletes: %{name} = $v-$r
for each such (E)VR could possibly be thought of as a 3rd party friendly
substitute for an Epoch bump. Sure, it would be a larger maintenance
burden than the bump, but how much so, and would it even work in
practice? Good/incrediby-stupid/something-in-between idea?
18 years, 3 months
"License" tag for GPL w/ exception
by Ian Pilcher
I'm finally getting around to cleaning up the nedit SRPM (from Fedora
CVS) for inclusion in Extras, and rpmlint is complaining about the
"License: distributable" tag in the SPEC file. nedit is licensed under
the GPL, with the following exception:
In addition, as a special exception to the GNU GPL, the copyright
holders give permission to link the code of this program with the
Motif and Open Motif libraries (or with modified versions of these
that use the same license), and distribute linked combinations
including the two. You must obey the GNU General Public License in all
respects for all of the code used other than linking with Motif/Open
Motif. If you modify this file, you may extend this exception to your
version of the file, but you are not obligated to do so. If you do not
wish to do so, delete this exception statement from your version.
So what is the appropriate tag?
Thanks!
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
18 years, 3 months
