packaging March 2009

packaging@lists.fedoraproject.org

36 participants
26 discussions

gnome-do 0.8.0
by Luca Foppiano 04 Apr '09

04 Apr '09

Hi, here the updated gnome-do 0.8.0. SPEC: http://lfoppiano.fedorapeople.org/gnome-do.spec RPM (x86_64): http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.x86_64.rpm http://lfoppiano.fedorapeople.org/gnome-do-devel-0.8.0-1.fc10.x86_64.rpm SRPM: http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.src.rpm I just updated the package version and check it with mock and rpmlint (both finished without errors). Thanks in advance :) Luca -- Today is Prickle-Prickle, the 69th day of Chaos in the YOLD 3175 AIX - the Unix from the universe where Spock has a beard.

3 4

How to package a patched older version of libvmime in Fedora best?
by Robert Scheck 04 Apr '09

04 Apr '09

Good evening, I've the situation, that a package unluckily requires an older version of libvmime and some specific/individual patches as well. The question is now, how to package that best for Fedora and EPEL? What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1 which is unluckily ABI and API incompatible. There are now multiple solutions how to deal with this as I can't use 0.9.1 now and in foreseeable future: a) Build libvmime 0.7.1 + patches in before of the software requiring it and link statically against it. This would make sense in this case, even if static linking is discouraged in Fedora, but nothing except that piece of software requires actually libvmime 0.7.1 + individual patches. b) Build libvmime 0.7.1 + patches as own package and call it e.g. something like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or similar. That would bring me to -lfoobar-libvmime linking or something similar, right? Just providing a compat-libvmime seems not suitable, as compat-* in Fedora is only providing the library, not -devel stuff which is actually needed to build the other software requiring the old libvmime 0.7.1 + patches. As of overlapping *.so filenames, it is not possible to avoid renaming the patched version. Question is, which is better and which one will go through the package review or are there better ideas how to solve this? Yes, some far day, upstream will accept all of the individual patches and the other software will support latest libvmime version, but this won't be in the next time as libvmime support is somehow seemingly less interested in being backward compatible. Greetings, Robert

5 8

Re: Agenda for the 2009-03-31 Packaging Committee meeting
by Ralf Corsepius 31 Mar '09

31 Mar '09

Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-03-31 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. Due to Europe having shifted to DST, 17:00UTC is once again (as in previous years) hardly suitable for me. I'll very likely not be able to attend many upcoming FPC meetings, rsp. if I can attend, will have to leave early. Ralf

1 0

First post
by Philippe Makowski 27 Mar '09

27 Mar '09

Hi, I'm new to the Fedora Project. I'm Philippe Makowski, member of the Firebird AdminTeam (www.firebirdsql.org) I jump here to help packaging Firebird and it's related tools inside Fedora. I hope that we will solve this request quick (https://bugzilla.redhat.com/show_bug.cgi?id=488100) so after, we can add at least Flamerobin and the Python driver for Firebird packages. If need, I think I can find time to be co maintainer of Firebird and related tools package. Wish you all sucess.

1 0

Advice over mono and rebuilding for silverlight
by Paul F. Johnson 26 Mar '09

26 Mar '09

Hi, I've had a request from rpmfusion to rebuild mono with the --with-moonlight flag set. This builds in the functionality required to build Silverlight on rpmfusion. I am aware that Fedora itself cannot have Silverlight in (the licence is the MS "shared source" (cough) licence) due to the potential for MS to do it's usual trick of going back on their word and applying patents to cause problems. While adding in the smcs and silverlight code possibly does not break any of the fedora rules, I am of the thinking that we don't add the flag for the same reason that we have disabled xmms for mp3; it has the potential to cause us problems. This is probably a question for the legal people, but I'm asking it here as I don't have the legal people's email address and it is also a packaging problem. If I get the okay to build mono with the flag, I will. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

2 1

Re: Publican Issues
by Joshua Wulf 26 Mar '09

26 Mar '09

Thanks for your response and suggestions Toshio. I think it's more venting frustration than actually blaming the FPC for being a roadblock. *Anything* that we can do to resolve these issues, keeping in mind the limited resources we are working with and the need to work together and forge stronger relationships going forward, will be great. Josh Toshio Kuratomi wrote: > Joshua Wulf wrote: > Thanks Joshua, > > >> I think that Jeff and Chris are referring to this: >> https://bugzilla.redhat.com/show_bug.cgi?id=476471 >> >> > IIUC, this boils down to: > 1) Publican creates a different documentation package for each Fedora > Release as it considers them to be separate documents. ie: > Fedora-10-Security-Guide, Fedora-11-Security-Guide. > > 2) This means a new package review for each documentation package each > release. > > If you're willing to go through a new review each release, there's no > problem. > > If you want a single review to cover you for all releases, we need a new > Guideline. I think if it's a potential goal to be able to install the > Fedora-10-Security-Guide on Fedora-11, then I'd be against such a > Guideline as separate packages really are what you want. If it's > specifically a non-goal to do that, then it's a possibility although > changing the name to not have the version in it strikes me as the better > option there. Following onto that, I'm not sure why you wouldn't want > to use publican to create an initial spec file and then modify it to > meet the specifics of the situation. This is the workflow for CPAN2RPM, > rpmdev-newspetemplate, and other tools. > > Another option is to look at a streamlined set of review items for > publican-created doc packages... We've never explicitly done this but in > practice, people know they don't have to check, for instance, shared > library guidelines when writing and reviewing a pure python module. > > >> and possibly this as well: >> https://bugzilla.redhat.com/show_bug.cgi?id=482972 >> >> > What's the problem here? That the .desktop is created inline in the > spec file instead of as a separate file? If that's all it is, I can > propose to the FPC to amend that. I can't recall a reason that it had > to be included in the SRPM as a file specifically. > > Note that neither of these issues had reached the FPC's radar (they > still haven't, really, as I'm only one member and this isn't the > packaging mailing list) so blaming the FPC as the roadblock is a bit > misplaced. > > -Toshio > > -- Joshua J Wulf Engineering Content Services Red Hat Asia Pacific eml: jwulf(a)redhat.com tel: +61 (0)7 3514 8140 mob: +61 (0)431 929 675 tmz: GMT +10 (0) - omit when dialling internationally

1 0

Re: Publican Issues
by Joshua Wulf 26 Mar '09

26 Mar '09

Joshua Wulf wrote: >> > I think that Jeff and Chris are referring to this: > https://bugzilla.redhat.com/show_bug.cgi?id=476471 Comment #58 by Jens Petersen: I am not veto'ing parallel install per se, but maybe it is worth considerng what is so special about docs packages that warrants/necessitates parallel install since we don't really do this for any other packages except libraries/tools needed occasionally for back-compatibility. The idea here is that people who are using Fedora in a production capacity, rather than just as a beta test of RHEL, are able to install multiple documentation sets. The use case would be like this: I'm a system administrator with a number of different servers on my network running different versions of Fedora. Some are internal servers and running the ancient Fedora 10. There is one running Fedora 15 that I'm intending to upgrade later. The ones on the firewall I run at latest-1, and are currently on Fedora 19. I'm running Fedora 20 on my personal workstation, and I have a virtual machine running Fedora Rawhide. On my Fedora 20 workstation I have the documentation for all of these different versions installed (F10, F15, F19, F20, Rawhide), so that I can refer to the relevant docs in my graphical user environment as I administer them remotely via ssh. That's the idea. It doesn't make much sense if you envision Fedora as a RHEL beta test that you scrap each time a new version comes out, but if it's a viable OS that can be deployed and used in a production capacity like that described above, parallel documentation installation will be useful. What are your thoughts on this? Josh -- Joshua J Wulf Engineering Content Services Red Hat Asia Pacific eml: jwulf(a)redhat.com tel: +61 (0)7 3514 8140 mob: +61 (0)431 929 675 tmz: GMT +10 (0) - omit when dialling internationally

1 0

Binary FreeDOS image
by Lubomir Rintel 25 Mar '09

25 Mar '09

Hi, I'm just reviewing a DOSEmu package, where the package author includes a tarball of FreeDOS installation (binary images of a couple of basic DOS utilities, shell and the kernel). I believe that it's probably illegal (provided it's GPL code, I have not checked) to do this unless we distribute sources as well. Would anyone mind if I told the maintainer just to include the source tarball in SRPM for now? Building the whole thing from source, while cleanly being possible, would add a huge amount of work at this point. Thanks, -- Lubomir Rintel <lkundrak(a)v3.sk>

5 6

Directory ownership guidelines
by Mattias Ellert 25 Mar '09

25 Mar '09

Hi! It was suggested to me to bring this issue to this list. The packaging guidelines says that a package should not own a directory that is owned by a package on which it depends. The packaging guidelines also says that packages should own all directories needed in order not to leave orphaned directories after a package de-installation. The way rpm/yum currently works these guidelines are contradicting and you must choose which one to implement in your packaging. My question is - is this a bug in yum/rpm, or a flaw in the packaging guidelines? Here is an example that implements the first guideline - and violates the second - spec file attached. The spec builds a main package, 8 packages (A-H) that depend on the main package and 8 devel packages that each depends on one of the packages (A-H). If I install all 17 packages and then do "yum remove mytest", all packages should be removed cleanly if the Requires are influencing the order the packages are uninstalled, which it must do if both guidelines is supposed to be implementable simultaneously. This is not what happens: [root@localhost ~]# rpm -ivh /home/ellert/rpmbuild/RPMS/i386/mytest-* Förbereder... ########################################### [100%] 1:mytest ########################################### [ 6%] 2:mytest-A ########################################### [ 12%] 3:mytest-B ########################################### [ 18%] 4:mytest-C ########################################### [ 24%] 5:mytest-D ########################################### [ 29%] 6:mytest-E ########################################### [ 35%] 7:mytest-F ########################################### [ 41%] 8:mytest-G ########################################### [ 47%] 9:mytest-H ########################################### [ 53%] 10:mytest-A-devel ########################################### [ 59%] 11:mytest-B-devel ########################################### [ 65%] 12:mytest-C-devel ########################################### [ 71%] 13:mytest-D-devel ########################################### [ 76%] 14:mytest-E-devel ########################################### [ 82%] 15:mytest-F-devel ########################################### [ 88%] 16:mytest-G-devel ########################################### [ 94%] 17:mytest-H-devel ########################################### [100%] [root@localhost ~]# yum remove mytest Loaded plugins: refresh-packagekit Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package mytest.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest for package: mytest-A --> Processing Dependency: mytest for package: mytest-E --> Processing Dependency: mytest for package: mytest-G --> Processing Dependency: mytest for package: mytest-B --> Processing Dependency: mytest for package: mytest-F --> Processing Dependency: mytest for package: mytest-C --> Processing Dependency: mytest for package: mytest-D --> Processing Dependency: mytest for package: mytest-H --> Running transaction check ---> Package mytest-A.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-A = 1.0-1.fc10 for package: mytest-A-devel ---> Package mytest-B.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-B = 1.0-1.fc10 for package: mytest-B-devel ---> Package mytest-C.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-C = 1.0-1.fc10 for package: mytest-C-devel ---> Package mytest-D.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-D = 1.0-1.fc10 for package: mytest-D-devel ---> Package mytest-E.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-E = 1.0-1.fc10 for package: mytest-E-devel ---> Package mytest-F.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-F = 1.0-1.fc10 for package: mytest-F-devel ---> Package mytest-G.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-G = 1.0-1.fc10 for package: mytest-G-devel ---> Package mytest-H.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-H = 1.0-1.fc10 for package: mytest-H-devel --> Running transaction check ---> Package mytest-A-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-B-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-C-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-D-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-E-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-F-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-G-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-H-devel.i386 0:1.0-1.fc10 set to be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: mytest i386 1.0-1.fc10 installed 0.0 Removing for dependencies: mytest-A i386 1.0-1.fc10 installed 6.0 mytest-A-devel i386 1.0-1.fc10 installed 7.0 mytest-B i386 1.0-1.fc10 installed 6.0 mytest-B-devel i386 1.0-1.fc10 installed 7.0 mytest-C i386 1.0-1.fc10 installed 6.0 mytest-C-devel i386 1.0-1.fc10 installed 7.0 mytest-D i386 1.0-1.fc10 installed 6.0 mytest-D-devel i386 1.0-1.fc10 installed 7.0 mytest-E i386 1.0-1.fc10 installed 6.0 mytest-E-devel i386 1.0-1.fc10 installed 7.0 mytest-F i386 1.0-1.fc10 installed 6.0 mytest-F-devel i386 1.0-1.fc10 installed 7.0 mytest-G i386 1.0-1.fc10 installed 6.0 mytest-G-devel i386 1.0-1.fc10 installed 7.0 mytest-H i386 1.0-1.fc10 installed 6.0 mytest-H-devel i386 1.0-1.fc10 installed 7.0 Transaction Summary ================================================================================ Install 0 Package(s) Update 0 Package(s) Remove 17 Package(s) Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Erasing : mytest-E-devel 1/17 Erasing : mytest-H-devel 2/17 Erasing : mytest-A 3/17 Erasing : mytest-C 4/17 Erasing : mytest-D 5/17 Erasing : mytest-E 6/17 Erasing : mytest-G 7/17 Erasing : mytest-H 8/17 Erasing : mytest-C-devel 9/17 Erasing : mytest-F-devel 10/17 Erasing : mytest-F 11/17 Erasing : mytest-A-devel 12/17 Erasing : mytest-D-devel 13/17 Erasing : mytest 14/17 Erasing : mytest-G-devel 15/17 Erasing : mytest-B 16/17 Erasing : mytest-B-devel 17/17 Removed: mytest.i386 0:1.0-1.fc10 Dependency Removed: mytest-A.i386 0:1.0-1.fc10 mytest-A-devel.i386 0:1.0-1.fc10 mytest-B.i386 0:1.0-1.fc10 mytest-B-devel.i386 0:1.0-1.fc10 mytest-C.i386 0:1.0-1.fc10 mytest-C-devel.i386 0:1.0-1.fc10 mytest-D.i386 0:1.0-1.fc10 mytest-D-devel.i386 0:1.0-1.fc10 mytest-E.i386 0:1.0-1.fc10 mytest-E-devel.i386 0:1.0-1.fc10 mytest-F.i386 0:1.0-1.fc10 mytest-F-devel.i386 0:1.0-1.fc10 mytest-G.i386 0:1.0-1.fc10 mytest-G-devel.i386 0:1.0-1.fc10 mytest-H.i386 0:1.0-1.fc10 mytest-H-devel.i386 0:1.0-1.fc10 Complete! After the removal there are orphaned directories: [root@localhost ~]# find /usr/share/mytest /usr/share/mytest /usr/share/mytest/C /usr/share/mytest/G /usr/share/mytest/B /usr/share/mytest/D /usr/share/mytest/A [root@localhost ~]# rpm -q --whatprovides `find /usr/share/mytest` filen /usr/share/mytest tillhör inget paket filen /usr/share/mytest/C tillhör inget paket filen /usr/share/mytest/G tillhör inget paket filen /usr/share/mytest/B tillhör inget paket filen /usr/share/mytest/D tillhör inget paket filen /usr/share/mytest/A tillhör inget paket

4 5

Perl Question
by Conner Finlay 25 Mar '09

25 Mar '09

Hello list, I have searched Google high and low, but I have not found an answer. I have a spec file that requires some perl modules, ie Net::IP, XML::Simple, etc. For all but one there is an RPM available for it. In the SPEC file I have them as Requires: perl(Net::IP) and the spec file builds fine(rpmbuild -ba -v) but when I go to install the RPM it complains about the missing perl modules. If I do a `yum install perl-xyz` and rebuild the SPEC file, it will not complain about the missing perl modules. How can I have the SPEC file download/install the perl modules/packages? If it is easier, I can also post the SPEC file itself. Thanks, Conner -- Conner Finlay

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2009