Tcl packaging guidelines proposal
by Michael Thomas
I sent this proposal to f-m-l about a week ago to gather comments, and
there were no serious disagreements with the proposal which have not yet
been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl
extensions, as we already have guidelines for other popular scripting
languages. In addition to making Tcl packages more consistent with each
other, it will also help work toward fixing my pet-peeve bug (bz #226893)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft
guidelines adopted.
Thanks,
--Wart
15 years, 9 months
Octave package standard
by Orion Poplawski
I'm currently working with octave upstream to get their new package
management system in line with Fedora so that we can easily build RPMs
with it. I'd like to get a Fedora package standard configured and
approved at the same time. I've put a draft on the wiki at:
http://fedoraproject.org/wiki/PackagingDrafts/Octave
Some further information:
- Currently octave uses the /usr/libexec tree to install the .oct files.
These are really shared libraries. It does use an arch/api versioned
directory, e.g.:
/usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/
Some other package files (PKG_ADD/PKG_DEL) get added there too.
- Currently the entire octave forge collection is part of the
octave-forge package. I will releasing this for F8, with the
understanding that this will be replaced by individual packages later.
The octave forge package will have provides like:
Provides: octave-gsl = 1.0.1
to try to provide a better upgrade path. We may want to keep the
octave-forge as a meta package that pulls in the others. Let me know if
this doesn't seem correct.
- DISTPKG (%{octave_distpkg}) is a flag that this is being built by a
package manager. The contents get inserted into an informational
message, but otherwise does not mean much.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
16 years
error on DistTag wiki page?
by John Dennis
I think there might be an error on the following wiki page
http://fedoraproject.org/wiki/Packaging/DistTag
There are examples there like this:
# If on Fedora 8, Requires: foo
%{?fc8: Requires: foo}
But if fc8 is defined you get an rpm error stating
Unknown tag: Requires: foo
After much fooling around I think I tracked the problem down to the fact
RPM won't tolerate any white space in front of the "Requires:", I
finally recalled that RPM will choke if it sees indentation in certain
places in the spec file. The net effect of the macro on the wiki was
that "Requires:" was indented by 1 space.
It seems like it has to be:
%{?fc8:Requires: foo}
I will update the wiki but I thought I would sanity check my conclusion
first.
IMHO RPM's parsing is way too fragile, it took me a while before it
occurred to me it was the space character causing the error. The error
message wasn't very helpful either, did anybody else notice there were
two spaces between the "Unknown tag:" and the "Requires" in the error
message implying the tag was " Requires" and not "Requires"?
John
16 years
tex related packages naming
by Patrice Dumas
Hello,
Could it be possible for the packaging commitee to decide on that issue,
please? The proposals are:
* prefix with tex-
* no specific naming. Prefix with tex- when another package has the same
name
Could it be possible to have a vote/decision on that issue?
In any case I think that a (long) period should be left for packagers
to change their package names.
--
Pat
16 years
"gconfd-2: no process killed" messages
by Thorsten Leemhuis
Hi,
I'm running rawhide these days again and during yum update I quite often
see messages like
> Updating : gedit ##################### [173/382]
> gconfd-2: no process killed
> Updating : deskbar-applet ##################### [174/382]
> gconfd-2: Kein Prozess abgebrochen
> Updating : gnome-terminal ##################### [175/382]
Looking closer at the spec and at the Gconf session on
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets
it seems they run
killall -HUP gconfd-2 || :
to make sure any running gconfd-2 pick up newly installed schemes. But
well, as you can see from above output there might be cases when no
gconfd-2 is running, thus killall will print a warning.
I think we should avoid such useless warnings -- thus it would seem
better to me to use killall with "--quiet" or use
killall -HUP gconfd-2 2> /dev/null || :
instead. What do you guys think?
Cu
knurd
16 years
rpmdevtools required for rebuilding packages on F7
by Marcin Zajączkowski
Hi,
Recently my friend (which isn't a Fedora packager) was rebuilding my
package on F7 and he got an error. It seems that there is check-rpaths used:
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
/var/tmp/rpm-tmp.39128: line 43: /usr/lib/rpm/check-rpaths: No such file
or directory
error: Bad exit status from /var/tmp/rpm-tmp.39128 (%install)
There is no that call in FC5 and it was probably introduced in F7.
check-rpaths is provided by rpmdevtools which isn't on "the minimum
build environment" list:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63c...
(maybe because it was in Extras prior to F7)
So the question, shouldn't it be added to mentioned list?
Regards
Marcin
16 years
Apologize for missing the meeting
by Jason L Tibbitts III
My apologies for missing Tuesday's meeting; I have been in hospital with a
nasty case of some food-borne illness and am only now strong enough to
sit up at a computer.
I don't think I have a proper log of the meeting, and I still have a
tonne of mail to go through. If the meeting hasn't been summarized
yet, could someone take care of that for me?
- J<
16 years
Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call?
by Thorsten Leemhuis
Hi all,
the Fonts section on
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
contains this:
> Use this when your package installs new fonts.
>
> {{{
> %post
> if [ -x %{_bindir}/fc-cache ]; then
> %{_bindir}/fc-cache %{_datadir}/fonts
> fi
> %postun
> if [ "$1" = "0" ]; then
> if [ -x %{_bindir}/fc-cache ]; then
> %{_bindir}/fc-cache %{_datadir}/fonts
> fi
> fi
> }}}
Is there a specific reason why there is no "|| :" at the end of
"%{_bindir}/fc-cache %{_datadir}/fonts"? I think there should be one, as
this happened to me during a F-7 -> rawhide update (that's still in
progress while I'm writing this mail, so more errors might show up):
> Updating : bitstream-vera-fonts ################### [ 383/1850]
> /usr/share/fonts/default/Type1: failed to write cache
> /usr/share/fonts/default/ghostscript: failed to write cache
> error: %post(bitstream-vera-fonts-1.10-8.noarch) scriptlet failed, exit status 2
[...]
> Updating : fontconfig ################### [ 416/1850]
> /usr/share/fonts/default/Type1: failed to write cache
> /usr/share/fonts/default/ghostscript: failed to write cache
> /usr/share/X11/fonts/Type1: failed to write cache
> error: %post(fontconfig-2.4.2-5.fc8.x86_64) scriptlet failed, exit status 3
[...]
> Updating : dejavu-lgc-fonts ################### [ 548/1850]
> /usr/share/fonts/default/ghostscript: failed to write cache
> error: %post(dejavu-lgc-fonts-2.19-1.noarch) scriptlet failed, exit status 1
> Updating : liberation-fonts ################### [ 549/1850]
> /usr/share/fonts/default/ghostscript: failed to write cache
> error: %post(liberation-fonts-0.2-1.fc8.noarch) scriptlet failed, exit status 1
CU
knurd
16 years
