Re: icon cache scriplets, using %posttrans
by Rex Dieter
Rex Dieter wrote:
> Callum Lerwick wrote:
>> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote:
>>> Because, frankly, poo-pooing the current proposal/guidelines in favor
>>> of some handy-wavy theoretical lacking-actual-implementation
>>> solution, is no solution.
>>
>> Well, the point is, the current proposal does not address the "multiple
>> packages needlessly updating caches multiple times" problem at all.
>
> Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My
> findings so far are promising.
How about something like this? %posttrans operations run at the end of
the rpm transaction(1), only the first gtk-update-icon-cache would take
any real cpu time (subsequent runs of gtk-update-icon-cache are smart
enough to know the cache is not stale, and run virtually instantly).
I'll look into patching xdg-icon-utils into doing a "smart" update
operation (like gtk-update-*), but until then, we need to use
gtk-update-icon-cache here.
##########################
%post
touch --no-create %_datadir/icons/hicolor ||:
%postun
touch --no-create %_datadir/icons/hicolor ||:
# Keep this until http://bugzilla.redhat.com/170335 is fixed
%posttrans
gtk-update-icon-cache -q %_datadir/icons/hicolor >& /dev/null ||:
##########################
In my testing using a fair-to-middlin laptop, gtk-update-icon-cache
takes 0.5-1.0 seconds to regenerate a stale cache, so doing it this way,
if I had to install/update 10 icon-using apps, I'd save ~5-10 seconds
install time. Not too shabby.
(1) This same trick could be used for other expensive scriptlet
operations too. ldconfig, in general, is not a good candidate for this,
since items installed by one rpm may be needed by subsequent items
within the same transaction.
-- Rex
17 years, 4 months
Re: rawhide report: 20061219 changes
by Jason L Tibbitts III
>>>>> "RC" == Remi Collet <Liste(a)FamilleCollet.com> writes:
> php-5.2.0-8
> -----------
> * Tue Dec 05 2006 Joe Orton <jorton(a)redhat.com> 5.2.0-8
> - fix filter.h installation path
> - fix php-zend-abi version (Remi Collet, #212804)
RC> I think this new virtual provides give us the opportunity to
RC> modify the "Guidelines for packaging PHP addon modules" for all
RC> pecl packages to require this (fc6 and fc7)
Could you elaborate on that a bit? We currently have mandate
Requires: php-abi = version; how would we use php-zend-abi?
- J<
17 years, 4 months
More Mono confusion
by Paul Howarth
I have a mono-based package called "lat", which I believe follows the
current packaging guidelines, i.e. it installs lat.exe and its
associated DLLs into %{_libdir}/lat.
The package has dependencies on some mono packages from Core,
particularly avahi-sharp. On x86_64, the avahi-sharp package contains:
/usr/lib/mono/avahi-sharp
/usr/lib/mono/avahi-sharp/avahi-sharp.dll
/usr/lib/mono/gac/avahi-sharp
/usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5
/usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll
/usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll.config
/usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll.mdb
/usr/lib64/pkgconfig/avahi-sharp.pc
So avahi-sharp.dll is in /usr/lib rather than %{_libdir}
When I try to start lat on x86_64, I get:
$ lat
lat [09776] INFO Starting lat (version 1.2.1.1)
** (lat:9776): WARNING **: The following assembly referenced
from /usr/lib64/lat/lat.exe could not be loaded:
Assembly: avahi-sharp (assemblyref_index=14)
Version: 1.0.0.0
Public Key: 4d116c78973743f5
The assembly was not found in the Global Assembly Cache, a path listed
in the MONO_PATH environment variable, or in the location of the
executing assembly (/usr/lib64/lat).
** (lat:9776): WARNING **: Could not load file or assembly 'avahi-sharp,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d116c78973743f5' or
one of its dependencies.
lat [09776] ERROR Error occured: Could not load file or assembly
'avahi-sharp, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=4d116c78973743f5' or one of its dependencies.
lat [09776] INFO Exiting lat
I can work around this though:
$ MONO_PATH=/usr/lib/mono lat
That works.
So my question is: is my package in error, or is it avahi-sharp? Should
I set $MONO_PATH in /usr/bin/lat?
Paul.
17 years, 4 months
what policy for python egg files
by José Abílio Matos
I am reviewing
[Bug 219751] Review Request: python-TurboMail
In the spec file Luke has packaged the egg files for that package. What is
Fedora policy regarding this issue. Should we package the egg files or should
we leave them?
I remember that we have discussed this sometime ago but I don't remember the
outcome.
Regards,
--
José Abílio
17 years, 4 months
File deps outside "/etc {/usr,}/{s,}bin/"
by Thorsten Leemhuis
%pre: fedora-packaging(a)redhat.com CCed, reply-to set to
fedora-extras-list(a)redhat.com -- I suspects mailman will eat it; please
simply reply to fedora-extras-list manually to avoid further
crossposting and slitted discussions; tia!
Hi,
skvidal mentioned in #fedora-extras we should consider going through all
packages and look out for unnecessary file deps outside of "/etc
/usr/sbin/ /usr/bin/ /sbin/ /bin/". Those are covered by the primary
dataset yum loads normally. Yum has do load a second, (often big) file
to depsolve the others; that often slows down depsolving packages a lot
-- most of us were probably bitten by this already in the past and know
what I'm talking about.
So, should we try to get rid of such deps as much as possible? And maybe
even put a short note into the packaging guidelines that file based deps
outside of "/etc {/usr,}/{s,}bin/" slow down yum and therefore should be
avoided if possible?
Options?
BTW, I did a quick lookup on a x86-64 FC-6 machine with repoquery; we
seems to have 32 file based deps outside of "/etc {/usr,}/{s,}bin/" in
Extras:
/usr/lib64/ctapi
/usr/lib64/libpcsclite.so.1
/usr/lib64/pgsql
/usr/share/pgsql
/usr/include/linux
/usr/lib64/util-vserver
/usr/share/fonts/bitstream-vera/Vera.ttf
/usr/share/themes
/var/www/cgi-bin
/var/www/html
/usr/lib64/pkgconfig
/usr/share/X11/app-defaults
/usr/lib64/php/modules
/usr/share/icons/hicolor/scalable
/usr/lib64/mozilla/plugins
/usr/share/xml
/usr/lib/python2.4/site-packages
/usr/include/sysfs/libsysfs.h
/usr/lib64/mozilla/plugins
/usr/lib64/util-vserver
/usr/share/sgml/html/4.01
/usr/share/sgml/xhtml1/xhtml1-20020801/DTD
/usr/share/X11/rgb.txt
/usr/share/aclocal
/usr/lib64/pkgconfig
/usr/share/desktop-menu-patches/redhat-audio-player.desktop
/usr/lib64/ctapi
/usr/share/emacs/site-lisp
/usr/share/fonts
/usr/lib64/util-vserver
/usr/lib64/util-vserver/sigexec
/usr/share/basemap
At least some of them look suspicious:
/usr/lib/python2.4/site-packages
-> simply python
/usr/lib64/util-vserver
-> simply util-vserver-core
/usr/lib64/ctapi
-> simply ctapi-common
/usr/lib64/pkgconfig
-> simply pkgconfig
...
/usr/lib64/mozilla/plugins and some other dirs are probaly okay.
CU
thl
P.S.:Core has some more:
/usr/lib64/python2.4
/usr/lib/news/lib/innshellvars.pl
/usr/lib64/python2.4
/usr/lib/libgcj.so.7rh
/usr/lib/libz.so
/usr/lib64/python2.4
/usr/lib64/libstdc++.so.6
/usr/share/openldap/migration/migrate_common.ph
/usr/lib/libstdc++.so.6
/usr/lib/lsb/install_initd
/usr/lib/lsb/remove_initd
/usr/lib64/libgcj.so.7rh
/usr/lib64/libz.so
/usr/share/magic.mime
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib64/python2.4
/lib64/security/pam_loginuid.so
/usr/lib64/python2.4/site-packages
/usr/share/gnome-screensaver/lock-dialog-system.glade
/usr/share/desktop-menu-patches/gnome-gdmsetup.desktop
/lib64/security/pam_loginuid.so
17 years, 4 months
Revived License: tag proposal
by Jason L Tibbitts III
I have revived the License: tag proposal, simplified to a basic
standardization of the tags used for some common licenses. I have not
attempted to pick a list of those common licenses, although I have
provided some data on what License: tags are in use.
http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag
Again, I wish to remind folks that this is just a proposal.
- J<
17 years, 4 months
Missing the meeting
by Toshio Kuratomi
Hey guys,
I'll be traveling during the time the packaging meeting is taking place
tomorrow. I can catch up with the meeting logs after and would be glad
to use email for anything that comes up for a vote.
-Toshio
17 years, 4 months
Re: [Mimedefang] More on mimedefang and x86_64
by Philip Prindeville
Moving to fedora-packaging...
Seeking assistance from .x86_64 packaging gurudom.
Issues we're trying to solve here are:
* The package should be buildable without having all of the
run-time requirements met (there are things that are called
out as both BuildRequires: and Requires: that are really only
the latter.
* When building on an x86_64 architecture, we should look
for the libmilter stuff in /usr/lib64 and /lib64 also. (Wasn't
sure if this goes in the configure.in file, or should be an
additional conditional argument passed into %configure
instead...)
* It's not building any symbol-table exports for the debuginfo
package, and I don't know why.
Can someone walk me through these issues?
David will post patches if we can get official blessings.
Thanks,
-Philip
P.s. Can the list admin please take .eml off the prohibited
attachment suffix list?
Philip Prindeville wrote:
>Hmmm...
>
>I run sendmail/cyrus-imapd/spamassassin/mimedefang on an
>x86_64 machine (FC5 on an Athalon64 2800+) and it works fine.
>
>To keep the mail server simple, however, I wanted to build
>mimedefang-2.58 on a different machine, so I went ahead and
>grabbed all of the dependencies.
>
>I have to say, I was a bit configured. It seems that the build-time
>dependencies have been muddled with the run-time dependencies.
>
>You don't need:
>
>BuildRequires: perl-Digest-SHA1 perl-MIME-tools perl-IO-stringy perl-MailTools
>
>
>in the .spec file, do you? Can we yank this? I just pulled it out
>and things built fine (oh, after adding "--disable-check-perl-modules"
>to the ./configure line).
>
>Further, if you install sendmail-devel but don't actually
>have sendmail installed on the machine (since your building,
>but not actually running)... then you might run afoul of the
>following scenario. sendmail-devel installs (on an x86_64
>architecture) /usr/lib64/libmilter.a only.
>
>So, from configure.in:
>
>AC_PATH_PROG(LIBMILTER, libmilter.a, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
>SMPATH=`echo ../sendmail-*/obj.*/libsm`
>AC_PATH_PROG(LIBSM, libsm.a, no, $SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
>
>dnl find libmilter.so in case we have shared libraries
>AC_PATH_PROG(LIBMILTERSO, libmilter.so, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
>
>
>should we add /lib64 and /usr/lib64 before /lib and /usr/lib,
>respectively?
>
>I changed the .spec file to include:
>
> ./configure ... --with-libmilter=/usr/lib64 ...
>
>and it seems to build... but it might make more sense to
>fix this in the configure.in file instead, as above.
>
>Opinions?
>
>Oh, and do we need the symbol file for /usr/bin/mimedefang
>to put into mimedefang-debuginfo-2.58?
>
>-Philip
>
>
>
--- mimedefang.spec 2006-11-19 17:22:04.000000000 -0700
+++ mimedefang2.spec 2006-11-19 19:00:14.000000000 -0700
@@ -132,21 +132,22 @@
%{?_without_antivirus: %{expand: %%define with_antivirus 0}}
Summary: Email filtering application using sendmail's milter interface
Name: mimedefang
Version: 2.58
-Release: 1
+Release: 2
License: GPL
Group: Networking/Mail
Source0: http://www.roaringpenguin.com/%{name}/%{name}-%{version}.tar.gz
Url: http://www.roaringpenguin.com/%{name}
Vendor: Roaring Penguin Software Inc.
Buildroot: %{_tmppath}/%{name}-root
Requires: sendmail > 8.12.0
Requires: perl-Digest-SHA1 perl-MIME-tools perl-IO-stringy perl-MailTools
BuildRequires: sendmail-devel > 8.12.0
-BuildRequires: perl-Digest-SHA1 perl-MIME-tools perl-IO-stringy perl-MailTools
+BuildRequires: autoconf > 2.55
+Patch99: mimedefang-libmilter64.patch
%description
MIMEDefang is an e-mail filter program which works with Sendmail 8.11
and later. MIMEDefang filters all e-mail messages sent via SMTP.
MIMEDefang splits multi-part MIME messages into their components and
@@ -165,13 +166,17 @@
willingness of your e-mail users to commit to security, or they will
complain loudly about MIMEDefang.
%prep
%setup -q -n %{name}-%{version}
-./configure --prefix=%{_prefix} \
+%patch99 -p0 -b .libmilter64
+autoconf
+%configure --prefix=%{_prefix} \
--mandir=%{_mandir} \
+ --enable-debug \
--sysconfdir=/etc \
+ --disable-check-perl-modules \
--with-spooldir=%{dir_spool} \
--with-quarantinedir=%{dir_quarantine} \
%if %{with_antivirus}
--with-user=%{user}
%else
--- /dev/null 2006-10-20 13:24:12.475602750 -0600
+++ ../SOURCES/mimedefang-libmilter64.patch 2006-11-19 17:17:55.000000000 -0700
@@ -0,0 +1,19 @@
+*** configure.in.bak 2006-11-06 08:01:23.000000000 -0700
+--- configure.in 2006-11-19 17:17:06.000000000 -0700
+***************
+*** 625,631 ****
+
+ dnl find libmilter.a and libsm.a
+ SMPATH=`echo ../sendmail-*/obj.*/libmilter`
+! AC_PATH_PROG(LIBMILTER, libmilter.a, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
+ SMPATH=`echo ../sendmail-*/obj.*/libsm`
+ AC_PATH_PROG(LIBSM, libsm.a, no, $SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
+
+--- 625,631 ----
+
+ dnl find libmilter.a and libsm.a
+ SMPATH=`echo ../sendmail-*/obj.*/libmilter`
+! AC_PATH_PROG(LIBMILTER, libmilter.a, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib64:/lib:/usr/lib64:/usr/lib:/usr/lib/libmilter)
+ SMPATH=`echo ../sendmail-*/obj.*/libsm`
+ AC_PATH_PROG(LIBSM, libsm.a, no, $SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter)
+
17 years, 4 months
Re: RPM weirdness [moved from fedora-list]
by Philip Prindeville
Philip Prindeville wrote:
>> I'm a flailing at cluefulness here. Maybe someone can set me straight.
>>
>> I run "yum" nightly (as as service), but I see a lot of "*.rpmnew" files
>> being left around.
>>
>> What's most bizarre is that the original RPM files haven't been changed,
>> and often the two files have the same size, contents (and hence MD5
>> signature), permissions, ownership, etc. Even the same file modification
>> date in most cases.
>>
>> So why do they get left behind?
>>
>> # cd /etc/security
>> # ls -ltr chroot*
>> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf.rpmnew
>> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf
>> # diff -c chroot.conf.rpmnew chroot.conf
>> # mv chroot.conf.rpmnew chroot.conf
>> #
>>
>>
>> Thanks,
>>
>> -Philip
Bingo:
# ls -l /etc/security/chroot.conf*
-rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf
-rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf.rpmnew
# perl -e 'print join(", ", stat("/etc/security/chroot.conf")), "\n"'
64768, 721510, 33188, 1, 0, 0, 0, 82, 1154431139, 1154431139, 1156023232, 4096, 8
# perl -e 'print join(", ", stat("/etc/security/chroot.conf.rpmnew")), "\n"'
64768, 719917, 33188, 1, 0, 0, 0, 82, 1154431128, 1154431128, 1156023323, 4096, 8
# perl -e 'print scalar localtime((stat("/etc/security/chroot.conf.rpmnew"))[9]), "\n"'
Tue Aug 1 05:18:48 2006
# perl -e 'print scalar localtime((stat("/etc/security/chroot.conf"))[9]), "\n"'
Tue Aug 1 05:18:59 2006
#
And there you have it.
Why are the packages being generated with a few seconds jitter?
This seems to be generating a lot of .rpmnew files gratuitously.
-Philip
17 years, 4 months