packaging September 2005

packaging@lists.fedoraproject.org

26 participants
12 discussions

kernel-module-proposal 2 and yum: some tests
by Thorsten Leemhuis 29 Sep '05

29 Sep '05

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>

8 15

Installing man pages
by Ralf Corsepius 28 Sep '05

28 Sep '05

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

4 6

Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan 19 Sep '05

19 Sep '05

-----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-----

3 3

Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan 19 Sep '05

19 Sep '05

-----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-----

2 1

Re: [Fedora-packaging] Python Packaging Hints
by Alan Milligan 17 Sep '05

17 Sep '05

-----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-----

2 1

Python Packaging Hints
by Jeff Pitman 17 Sep '05

17 Sep '05

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/thre… thoughts? -- -jeff

2 1

Name of x11 applet packages (common preffix?)
by José Abílio Matos 16 Sep '05

16 Sep '05

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

3 5

gnome-screensaver packaging problem
by Ricardo Veguilla 15 Sep '05

15 Sep '05

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>

8 16

packages which add user accounts: is fedora-usermgmt the way?
by Matthew Miller 12 Sep '05

12 Sep '05

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.

17 80

Re: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way?
by Jef Spaleta 08 Sep '05

08 Sep '05

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2005