packaging August 2008

packaging@lists.fedoraproject.org

42 participants
27 discussions

Re: rakarrack - alternative desktop categories
by Development discussions related to Fedora 12 Oct '08

12 Oct '08

Fernando Lopez-Lezcano wrote: > 0.2.x is now in Planet CCRMA thanks to Arnaud from IRCAM. Great if you > can/want to migrate it to Fedora! I did submit a package review that I think meets the Fedora guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=455953 > I would appreciate it if you could > keep the extra categories in the desktop file, they are used to classify > audio apps in an extra menu I added to Planet CCRMA (and rakarrack would > drop out of it if they were ommited). The question you ask is a good one, and I understand where you are coming from: {ccrma .spec} ===== # desktop file categories BASE="X-Fedora Application AudioVideo" XTRA="X-Digital_Processing X-Jack" %{__mkdir} -p %{buildroot}%{_datadir}/applications desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ `for c in ${BASE} ${XTRA} ; do echo "--add-category $c " ; done` \ %{SOURCE1} ===== As I understand it, a Fedora package can use only the categories present in the freedesktop.org spec: http://fedoraproject.org/wiki/Packaging/Guidelines#.desktop_file_creation http://standards.freedesktop.org/menu-spec/latest/apa.html Can a package use it's own categories, or must they meet the standards ? If there will be many audio apps {aka ccrma} packages, it would be best to have them grouped in the same menu; the AudioVideo menu on my machine is already overflowing more than a screenful, so I think it would be good if these audio {only} apps get their own menu ? DaveT.

2 3

Are there *any* guidelines for what "Group:" an application should go in?
by Vasile Gaburici 18 Sep '08

18 Sep '08

Furthermore, are there any guidelines for the creation of new groups?

3 3

Revised Haskell Guidelines 2008.08.13
by Yaakov Nemoy 01 Sep '08

01 Sep '08

Hi Lists, I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed. * %buildsubdir is not a common way of doing things ** we need this macro in the install phase to get at the working dir we used to compile the package. This was only needed by the rather scary looking file seeking code, so I put it into a macro that is called by another macro, and hid it from public view. The user should not need this in the spec file anymore. * this looks scary, use macros ** done, the guidelines include them * how do runtime requirements work, vis a vis build time, etc... ** GHC apparently uses static linking for haskell libraries and dynamic for C libraries. *** This is quite similar to OCaml ** all the dynamic links to C libraries can be automagically detected by RPM's wonderful automagic. ** the -devel packages still need to be put in by hand in the BuildRequires ** most packages only need their dependency libraries at build time. ** Some packages, notably xmonad, do code generation and require the dependencies at run time. *** the packager is responsible for tracking this bit * this file detection stuff is scary ** I've put it into a series of macros and documented it * this register stuff looks kinky ** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, whcih it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it. Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadeline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later. -Yaakov

7 13

How to handle unversioned upstream tarballs?
by Philip Prindeville 29 Aug '08

29 Aug '08

I was working on bug 452636 ( https://bugzilla.redhat.com/show_bug.cgi?id=452636 ), and reached an impasse. One of my last reviews (from Joe Orton) said: > non-formal review: > > > > > > 4) Source: http://apache.webthing.com/mod_proxy_html/mod_proxy_html.tgz > > > is bad - do upstream not provide versioned URLs? > > > > > Unfortunately, they do not. > > > upstream should be educated then ;) > > You'll need to work around that and version the tarball manually, I think this > is covered in the wiki somewhere. > Well, I've (a) tried to get the owners to rename the tarball with an embedded version number, so far without success, and (b) went looking through the maintainers wiki on how to handle cases where the tarball isn't versioned (and it must be done manually) but didn't find it. Can someone point me in the correct direction? Thanks, -Philip

6 11

Simple cvs extras suggestion
by Robin Norwood 28 Aug '08

28 Aug '08

Hi, With the goal of opening up ACLs on 'most' packages, I'd like to suggest that the New Package CVS Request template on this page: https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Change the last line from: Cvsextras Commits: To: Cvsextras Commits: yes Since the whole point of the template is for people to cut and paste it, this will make 'yes', truly the default option. Also, the text could be changed to be more descriptive. Something like 'Other Fedora members can commit' or change it around to 'Restrict commit access'. Sure, the user should read the documentation half a page down and choose 'yes', but how many people don't? And, more to the point, the term 'cvsextras' isn't really defined anywhere on the page. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching

6 7

Calling graphical tools generically e.g. text editor
by Tim Jackson 28 Aug '08

28 Aug '08

I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular: - a text editor e.g. gedit - a diff viewer of some sort (ideally graphical e.g. meld) - a graphical directory browser (e.g. nautilus) Currently, these require manual configuration by the user. It would be nice if they worked "out of the box" and respected the user's normal desktop preferences (including respecting different desktop environments - GNOME/KDE/other etc.). I'm not aware of a "clean" way of doing this. Is there any generic command which means "run the user's preferred text editor for the current environment"? Any other bright ideas about how this might be achieved or partially achieved? Bug #459909 refers to this problem. Thanks for any input, Tim

4 10

Re: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13
by Rajesh Krishnan 28 Aug '08

28 Aug '08

Bryan, I have forked cabal-rpm (with due credits to you, and the code is still GPL) that does generation of the Fedora specific SPEC file only, with the new macros. I chose to do that because there were too many changes I needed to get some things right, and get rid of other stuff (like executing rpmbuild) that were irrelevant for my purposes. I would publish the code once it becomes half stable and somewhat working. Please don't take this otherwise, as your code is absolutely great Haskell work and I learned some finer Haskell coding styles while studying your code. -Rajesh On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote: > On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan <fedora(a)krishnan.cc> wrote: > >> If we're using cabal-rpm for packaging > >> then we really don't need to add rpm macros IMHO. > > > > I am very much in favor of having good set of base macros (under > > /etc/rpm/). > > I like to have both the macros and cabal-rpm, where the latter assumes > the presence of the former.

1 0

Re: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13
by Jens-Ulrik Petersen 28 Aug '08

28 Aug '08

Hi, Bryan O'Sullivan さんは書きました: > Frankly, I think that the current version of the guidelines is fine. > It's much better to have something not quite perfect where we can make > progress than to be permanently stuck. So moving forwards with what we > have suits me. I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines... Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO. Thanks for all the comments. Jens

3 2

Game data packaging
by Marcin Zajączkowski 27 Aug '08

27 Aug '08

Hi, I'm currently preparing package for one small game. It uses standard automake. Game assumes that its data will be in $datadir/games/gamename and there is no easy way to change it (except patching configure.in). I checked my system and there is only one game (gbrainy) with data in /usr/share/games(/gbrainy). I would like to ask is there any advise to put game data in games subdir or it should be treated as a normal application? Regards Marcin

4 6

problem with mock, builds only static library
by Bruno Postle 27 Aug '08

27 Aug '08

I'm looking at packaging TinySVM for fedora and I have a src.rpm that builds fine with rpmbuild: http://bugbear.postle.net/~bruno/apt/fedora/linux/9/x86_64/SRPMS.panorama/T… ..except that when I build in mock, all I get is a static library and no dynamic libraries. The error message is: *** Warning: This library needs some functionality provided by -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. This doesn't make sense, the root seems to have everything needed. What am I missing? -- Bruno

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2008