Re: rakarrack - alternative desktop categories
by Development discussions related to Fedora
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.
14 years, 8 months
Revised Haskell Guidelines 2008.08.13
by Yaakov Nemoy
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
14 years, 9 months
How to handle unversioned upstream tarballs?
by Philip Prindeville
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
14 years, 9 months
Simple cvs extras suggestion
by Robin Norwood
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
14 years, 9 months
Calling graphical tools generically e.g. text editor
by Tim Jackson
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
14 years, 9 months
Re: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13
by Rajesh Krishnan
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.
14 years, 9 months
Re: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13
by Jens-Ulrik Petersen
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
14 years, 9 months
Game data packaging
by Marcin Zajączkowski
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
14 years, 9 months
problem with mock, builds only static library
by Bruno Postle
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...
..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
14 years, 9 months