Suggested ScriptletSnippets (icon cache) changes
by Ville Skyttä
Hello,
I'd suggest the following changes to the "GTK+ icon cache" entry in
Packaging:ScriptletSnippets:
1) Rename the entry to "Icon cache". It's not all about GTK+ but KDE as well.
2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not
available when the package is removed, I find it more than likely that GTK+
or KDE are not there to benefit from icon cache updates any longer
either. /usr/share may also be mounted read only with %_netsharedpath.
3) Append " &>/dev/null" to the "touch" line in %post. If "touch" is not yet
available, neither should be kdelibs, and thus there is no reason to touch
the dir. kdelibs itself does a forced update in its %post. /usr/share may
also be mounted read only with %_netsharedpath. (This avoids the need to add
unnecessary "Requires(post): coreutils" to every package that installs icons
just to quiet down a pretty rare and harmless warning.)
4) Remove the -x test and --quiet option to gtk-update-icon-cache, redirect
all output (including stderr) to /dev/null. gtk-update-icon-cache may not be
installed, /usr/share may be mounted read only with %_netsharedpath, etc...
and the --quiet tells me that there was no interest in seeing g-u-i-c's
stdout anyway.
5) Wrap %post in "if [ $1 -eq 1 ] ; then ..." to take care of the initial
installation and let %postun handle package upgrade cases in order to
eliminate one touch and one g-u-i-c invocation per package upgrade. I
suppose this would be "safe enough" to do, it'd just result in possibly stale
icon caches for the duration of the upgrade transaction. (Icons change
relatively rarely, and even if they do, does this smallish stale cache window
really matter at all?)
So the scriptlets would become:
%post
if [ $1 -eq 1 ] ; then
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi
%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
15 years, 2 months
rpmbuild and false dependancies when installing new rpm
by Gregory Machin
Hi all.
I'm quite new to building rpms.
I’m trying to build an rpm for lightsquid . I have got the rpm to build without any issues but now when I try and install it, it dies with missing dependencies the files are in the install list.
[root@gregory-workstation ~]# rpm -i /home/builder/rpm/RPMS/noarch/lightsquid-1.7-1.noarch.rpm
error: Failed dependencies:
perl(common.pl) is needed by lightsquid-1.7-1.noarch
perl(lightsquid.cfg) is needed by lightsquid-1.7-1.noarch
[root@gregory-workstation ~]#
I have also used mc to browse the contents on the rpm and the files are in it.. so why do I get this error ?
I have also removed the "Requires" reference from the spec file and this did not help.
I have attacked my lightsquid.spec file for review maybe a guru will see what my green eyes have missed.
Thanks
Regards
Gregory Machin
Email: gmachin(a)techconcepts.co.za
Cell: +27 (0) 72 524 5098
gtalk: gmachin.techconcepts(a)gmail.com
Support
helpdesk(a)techconcepts.co.za
Tell: +27 (0) 11 803 2169
Fax: +27 (0) 11 803 2189
After Hours
Cell: +27 (0) 82 790 0796
15 years, 2 months
review cgilib issues
by Lucian Langa
Hello,
I'm currently reviewing cgilib package (#450050).
The same functionality is provided by a similar package already in
fedora libcgi.
I would initially suggest using Conflicts for cgilib as those two
package will most obviously conflict.
Mamoru was kind enough to detail this issues a little further:
* For these packages both packages the library named "libcgi.so.1",
which is really a problem.
- In this case a simple conflict method (like "Conflicts: libcgi"
on cgilib") won't work as you desire, where there are some packages
which Requires libcgi.so.1, because
- An admin tries to install the package by "yum install foo"
(where foo has the dependency for libcgi.so.1)
- yum tries to resolve the dependency on foo, then finds that
two packages have "Provides: libcgi.so.1".
- Then yum will install either of libcgi or cgilib according to
yum's implementation, i.e. we cannot expect which will actually
be installed. However foo requires one of them, and perhaps
foo won't work with the other one.
- Here "Conflicts" does not work, because yum will try to
install one of them, not both.
* Another problem is that the soname major version "1" on libcgi.so."1"
in libcgi (in Fedora) was, actually, arbitrarily chosen by
Fedora maintainer, not by the upstream. And unfortunately
this decision now conflicts with cgilib.
- You can check this from libcgi srpm, especially
libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream
tarball only creates libcgi.so with no soname, however the Fedora
maintainer seems to have created a patch to add the proper
soname to libcgi.so. Then the soname "libcgi.so.1" seems to have
chosen.
Actually on Debian (as far as I checked debian's libcgi)
the soname is libcgi.so."0" (and here .0 was arbitrarily chosen
by Debian's maintainer).
Any thoughts on this ?
Thank you,
--lucian
15 years, 2 months
Rawhide's Mono stack
by Michel Salim
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Fedora Mono developers,
(ps if you are not in http://fedoraproject.org/wiki/SIGs/Mono, I get
your name from the changelog of relevant *-sharp packages; please
consider adding your name)
The current Mono stack in post-alpha Rawhide is rather broken -- as of
today, on my machine (x86_64) none of these packages work:
- - monodevelop
- - banshee
- - tomboy
- - f-spot
It seems that the entire stack of libraries need to be recompiled --
gtk-sharp2, etc., and as such we should probably coordinate the
rebuilding process. If B depends on A, does a rebuild of A affect B with
Mono packages? Not so sure about this; if not, it makes life easier.
If there are dependencies, then one way I could suggest is that we all
commit updated specs, and then someone (Paul?) could do a chain build of
all the packages.
Another item: as I proposed in -devel recently, we could probably get
more Infrastructure support.
- - our own disttag, similar to the one for the gcc44 test rebuilds earlier
- - that would probably require our own mailing list, to coordinate
matters like this
Thoughts? Suggestions?
Thanks in advance,
- --
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkmQLWYACgkQWt0J3fd+7ZCnZgCdFCbgxeipw/BiW6zzyt1k8Do4
mXAAnjXi9gPVJziqPakbU8uLcKUsMCCN
=UBGD
-----END PGP SIGNATURE-----
15 years, 2 months
MimeType error in desktop file
by Eric Tanguy
Building a package for rawhide i obtain this error :
/builddir/build/BUILDROOT/scidavis-0.1.4-1.fc11.i386/usr/share/applications/fedora-scidavis.desktop:
error: value "application/x-sciprj;;" for key "MimeType" in group
"Desktop Entry" contains value "" which does not look like a MIME type
Someone could explain where the problem come from and how to solve it ?
Thanks
Eric
15 years, 2 months
awesome tiling window manager
by Haluk Dogan
Hi,
I was trying to build awesome for few days, unfortunately I got several
errors. When I looked its official web site, they made a package for many
linux distribution except fedora. I wonder that would someone able to make
an rpm package and put it to repository? Many thanks in advance.
Regards Haluk
---
HD
15 years, 2 months
