kernel-module-proposal 2 and yum: some tests
by Thorsten Leemhuis
Hi All!
I (once again) played a bit around with kernel-modules and a scheme for
packaging those for fedora-extras. A patch for mock to pass the
kernel-version for which the kernel-module-pkg should be build and a
discussion about it and its usage in plague currently happens on
fedora-buildsys-list.
I also did some experiments with binary packages based on the
KernelModuleProposal 2 (
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal
) and how yum handles those. To make my life easier I hacked up a
test-script that creates a kernel-module testing-repo for yum. Those
interested can find everything needed at
http://www.leemhuis.info/files/fedorarpms/MISC.fdr/km-testing-yum
Warning, use at your own risk. create_testrepo.sh creates a testrepo
with ndiswrapper-rpms build from the two SRPMS (they are nearly
identical with those from the KernelModuleProposal 2 with some slightly
changes to simplify testing) in that dir. You need to install the SRPMS
to your rpmbuild folder manually. You probably also need to adjust some
variables in the script and copy two kernels from updates-testing over.
The problems that showed up during the tests (on a fresh FC4, only
UP-Kernel installed and yum updated to the latest version from
updates-released [no other update]) are described below. Note, this is
not meant as a rant against yum. I really like yum. It just meant as a
"that the state with kernel-module{s,-proposal} and yum ATM -- if we
like it or not". Seth (or anybody else), if you're interested in more
details, debug output or even bug reports filled: just say and I'll do
what I can.
If anybody else has ideas what also could or should be tested send a
mail and I'll add it.
#######################
Adding a repo with
> ndiswrapper-1.1-1.i386.rpm
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm
in it and typing
># yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper'
will result in:
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp
> step_1 3.3 k
> Installing for dependencies:
> kernel-smp i686 2.6.11-1.1369_FC4 base
> 13 M
> ndiswrapper i386 1.1-1 step_1
> 22 k
>
> Transaction Summary
> =============================================================================
> Install 3 Package(s)his
> [...]
Seems yum prefers to install the kernel-module for the smp kernel and
therefor also installs that kernel even when a UP-Kernel is installed
already. Not very nice :-(
#######################
Nearly the same problem as above happened when I used
># yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> ndiswrapper i386 1.1-1 step_1
> 22 k
> Installing for dependencies:
> kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp
> step_1 3.3 k
> kernel-smp i686 2.6.11-1.1369_FC4 base
> 13 M
>
> Transaction Summary
> =============================================================================
> Install 3 Package(s)
> [...]
>
#######################
Okay, next test; Both UP- and SMP-Kernel are installed now (as it
normally is the case on SMP-Systems). typing
> # yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper'
or
> # yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper
will result in something like this:
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp
> step_1 3.3 k
> Installing for dependencies:
> ndiswrapper i386 1.1-1 step_1
> 22 k
>
> Transaction Summary
> =============================================================================
> Install 2 Package(s)
> [...]
In and ideal world yum would install modules for both up and smp in that
case.
Note: The problems described up until here probably can happen with the
naming schemes currently used by Livna (where uname is in the name of
the package, e.g.
kernel-module-ndiswrapper-2.6.11_1.1369_FC4smp-1.1-1.i686.rpm), too. We
had some of those problems in the past.
#######################
Next test (only with SMP-kernel): New Ndiswrapper-Version. This is in
the repo now:
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm
> ndiswrapper-1.1-1.i386.rpm
> ndiswrapper-1.1-2.i386.rpm
Works now! Did not with older yum version. Problem was: kernel-modules
normally are installed, not updated. But in this case the pgk needs to
be updated cause the files in the package would conflict otherwise.
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> kernel-module-ndiswrapper i686 1.1-2.2.6.11_1.1369_FC4smp
> step_2 3.3 k
> Updating:
> ndiswrapper i386 1.1-2 step_2
> 21 k
> Removing:
> kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp
> installed 11
>
> Transaction Summary
> =============================================================================
> Install 1 Package(s)
> Update 1 Package(s)
> Remove 1 Package(s)
> [...]
#######################
I did two further test it this point (also only with SMP-kernel) and
they worked like they should:
- I added a new kernel (2.6.12-1.1447_FC4) to the repo but the
ndiswrapper-module was not yet in the repo -- yum updated the kernel
- later I added the module
(kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp); yum installed it
#######################
Last Test (for now). I placed another updated kernel and (at the same
time) a update of ndiswrapper itself in the repo:
> kernel-2.6.12-1.1447_FC4.i686.rpm
> kernel-2.6.12-1.1456_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4.i686.rpm
> kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp.i686.rpm
> kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4.i686.rpm
> kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm
> kernel-smp-2.6.12-1.1447_FC4.i686.rpm
> kernel-smp-2.6.12-1.1456_FC4.i686.rpm
> ndiswrapper-1.1-1.i386.rpm
> ndiswrapper-1.1-2.i386.rpm
> ndiswrapper-1.2-1.i386.rpm
Yum installs the new kernel, new ndiswrapper and new
kernel-module-ndiswrapper (as it should). But here we hit a problem with
our proposal. Older kernel-module-versions stay installed, but they
probably won't work with the new ndiswrapper-utils-package (maybe not in
the case of ndiswrapper, but ati-fglrx, nvidia-glx, qemu and other pkg.
likely will have this problem). I thought a Obsoletes in the
kernel-module-ndiswraper.spec like the following might help:
>Obsoletes: kernel-module-%{mainpkgname} < %{version}-%{release}
And it did -- a bit:
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> kernel-module-ndiswrapper i686 1.2-1.2.6.12_1.1456_FC4smp
> step_5 3.4 k
> replacing kernel-module-ndiswrapper.i686
> 1.1-2.2.6.11_1.1369_FC4smp
>
> kernel-smp i686 2.6.12-1.1456_FC4 step_5
> 14 M
> Updating:
> ndiswrapper i386 1.2-1 step_5
> 21 k
>
> Transaction Summary
> =============================================================================
> Install 2 Package(s)
> Update 1 Package(s)
> Remove 0 Package(s)
>
> Is this ok [y/N]: y
> Downloading Packages:
> Running Transaction Test
> Finished Transaction Test
> Transaction Test Succeeded
> Running Transaction
> Installing: kernel-smp #########################
> [1/4]
> Installing: kernel-module-ndiswrapper #########################
> [2/4]
> Updating : ndiswrapper #########################
> [3/4]
> Cleanup : ndiswrapper #########################
> [4/4]
>
> Installed: kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp
> kernel-smp.i686 0:2.6.12-1.1456_FC4
> Updated: ndiswrapper.i386 0:1.2-1
> Replaced: kernel-module-ndiswrapper.i686 0:1.1-2.2.6.11_1.1369_FC4smp
> kernel-module-ndiswrapper.i686 0:1.1-2.2.6.12_1.1447_FC4smp
> Complete!
But huuuh, why are they still installed? afterwards?
> $ rpm -qa 'kernel-module-ndiswrapper*'
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp
> kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp
> kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp
> $ rpm -Va 'kernel-module-ndiswrapper*' && echo okay
> okay
Something seems wrong here. Anybody any idea what?
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
18 years, 2 months
Installing man pages
by Ralf Corsepius
Hi,
A question:
Are packages legitimated to install man pages into
arbitrary /usr/share/man/man* directories outside those provided by the
"filesystem" package?
Background:
- the man-pages rpm installs its man-pages into
/usr/share/man/man0p
/usr/share/man/man1p
/usr/share/man/man3p
- the blas and lapack rpms install into
/usr/share/man/manl
Additionally, all these packages leave their man page installation
directories unowned:
# rpm -qf /usr/share/man/man?p /usr/share/man/manl
file /usr/share/man/man0p is not owned by any package
file /usr/share/man/man1p is not owned by any package
file /usr/share/man/man3p is not owned by any package
file /usr/share/man/manl is not owned by any package
I checked the FHS, but it once again seems intentionally vague to me
wrt. this topic, so I think we need a convention, here.
Ralf
18 years, 2 months
Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Toshio Kuratomi wrote:
>Hmmm... Yes; rhpl's Makefiles seem to make some rather problematic
>assumptions. What other packages do you know have similarly fragile
>upstream build scripts?
Since we're not accepting python-2.4, I've not downloaded very much of
the FC4 stack to discover exactly what's still broken. In this case, I
think I was curious to see if
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been
released as we need a proper extended url basic http authentication
syntax to allow up2date to connect to our servers. Again, these patches
were submitted almost a year ago, and we still have to maintain our own
forks :(
>>make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude}
>>LIBDIR=/lib
>Why the LIBDIR? That would seems to break things for x86_64 with no
>apparent gain.
Dunno - there was obviously something screwed with the link-edit step.
I'm a little surpised that /lib is not on the default link-library path
in the first place ...
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDLuf+CfroLk4EZpkRAluiAKDQPrvl1+dzlC/4cVU+j4XF9/WNdACfVRdC
zJ6eqgT+rBOTm+ZFXh2w4k0=
=IfYK
-----END PGP SIGNATURE-----
18 years, 2 months
Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Toshio Kuratomi wrote:
> Could you attach an FC4 spec that doesn't backport to FC3 without
> modification so we can see the mentioned issue?
Take rhpl.spec for example. In order to build this across python
versions, we need:
make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude}
LIBDIR=/lib
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDLgOYCfroLk4EZpkRAhLRAJ9LRGaRX3jHNuUrgi2FxHxleCXpXACeLnAU
8eEnYlaSIuTiAyPLgw1PTLE=
=mV4W
-----END PGP SIGNATURE-----
18 years, 2 months
Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Hi:
>
> Just some hints for packaging Python (iow, makes my life easier at
> http://python.org/pyvault).
> thoughts?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120635 represents a
number of thoughts by critically interested parties about this issue.
This request has been open for almost eighteen months now :(
Some of the respondents seem to think that only one or two macros are
necessary, I still beg to differ. We need to do this once, and do it to
please the widest possible audience.
A case in point is that we presently cannot migrate to Python2.4 until
Zope Corporation sign off a security audit on their app server. If
people didn't hard-code 2.4 into the build scripts, and if they use the
include macros for C-based python code, then we could almost certainly
backport any FC4 python SRPM's to our FC3 target without *any*
modification required.
This is simply not the case. We've already had to manage upgrades for
2.1, 2.2, and 2.3. A lot of things associated with Fedora development
are still retentive and frustrating.
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDLEPvCfroLk4EZpkRAvBHAKDaP2NtfzIMns+OTc5OEJrA9tXhRgCbBgQh
ZEM8QWaIM1bKoing17S37g4=
=xbsS
-----END PGP SIGNATURE-----
18 years, 2 months
Python Packaging Hints
by Jeff Pitman
Hi:
Just some hints for packaging Python (iow, makes my life easier at
http://python.org/pyvault).
1. Use %{__python} as opposed to python in any scriptlets. Especially be
wary of the %pyver definitions using a call to python to grab the
version.
2. Also, I need opinions on #!/usr/bin/python vs.
#!/usr/bin/pythonX.Y. Because if a package installs
into /usr/lib/pythonX.Y/site-packages, then any old /usr/bin/python
won't work, it'd have to be the version specific /usr/bin/pythonX.Y.
This might be a problem specific to my stuff, so you can ignore it if
it is.
http://groups.google.com/group/linux.debian.maint.python/browse_thread/th...
thoughts?
--
-jeff
18 years, 2 months
Name of x11 applet packages (common preffix?)
by José Abílio Matos
Hi all,
I have reviewed before wmacpi, a small x11 applet that shows the status of
the laptop battery. There are several other packages waiting for review in
Extras that are also small applications to report other kind of information,
disk activity, weather reports,...
A list of possible packages that follow in to this class can be found here:
http://dockapps.org/
Since those are small applications I propose to place them under a common
prefix, something like any of the following alternatives:
- x11-applets-...
- x11-dockapps-...
- x11-pluggins-...
My question to the list is if this is appropriate or am I trying to be more
papist than the Pope? Probably what I am trying to do unifying the package in
a single namespace is better done in metadata...
Is this senseless and we should try to abide to the upstream name?
Best regards,
--
José Abílio
18 years, 2 months
gnome-screensaver packaging problem
by Ricardo Veguilla
Hi, I was going to submit gnome-screensaver to Fedora Extras, and while
checking the spec file[1] for submission, I found the following
problems:
Problem #1 - Since gnome-screensaver is a gnome replacement for
xscreensaver, I decided to add "Provide: xscreensaver" but then to the
spec file. The problem is that upgrading xscreensaver will remove
gnome-screensaver (xscreensaver obsoletes itself).
Problem #2 - gnome-screensaver can use xscreensaver hacks if
xscreensaver-extras or xscreensaver-gl-extras are installed, but they
depend on xscreensaver-base, which introduces problem #1.
I think the user should be able to install:
gnome-screensaver
xscreensaver
xscreensaver-extras
or
gnome-screensaver
xscreensaver-extras
Any suggestions?
[1] Related files available at:
http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/
--
Ricardo Veguilla Gonzalez <veguilla(a)gmail.com>
18 years, 2 months
packages which add user accounts: is fedora-usermgmt the way?
by Matthew Miller
Is there an official policy for what packages that add users for their
processes to run as ought to do? I notice the recent clamav package still
uses fedora-usrmgmt, but I can't find any reference to that in the current
wiki, and that package still has the obsolete fedora.us wiki as its URL.
What's the Right Thing here?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.
18 years, 2 months
Re: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way?
by Jef Spaleta
On 9/8/05, Christian.Iseli(a)licr.org <Christian.Iseli(a)licr.org> wrote:
> No doubt about that. But up to now, IMHO requesting fedora-usermgt in
> pre/post scriptlets is a solution in search of a real problem.
Hmm... well usually when i see many people offering replacement
implementations to replace the existing tool implementation..i see
this as disagreement on exactly what the problem is... not that there
is a lack of a problem. You did offer a competing implementation in
this thread. The one thing I know for sure.. is that everyone seems to
be confused. Perhaps its best to dial back this conversation and ask
Enrico to give a "brief" summary as to primary problem being
addressed... with one or two common example situations. And if he can
dig up an old fedora.us mailinglist thread for reference where the
original design and of the wrapper implementation was discussed that
might help everyone refresh their memories as to the original reasons
this was created. We aren't going to get anywhere if we aren't all on
the same page.
-jef
18 years, 2 months
