packaging December 2006

packaging@lists.fedoraproject.org

36 participants
27 discussions

Re: icon cache scriplets, using %posttrans
by Rex Dieter 20 Dec '06

20 Dec '06

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

2 2

Re: rawhide report: 20061219 changes
by Jason L Tibbitts III 19 Dec '06

19 Dec '06

>>>>> "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<

1 0

More Mono confusion
by Paul Howarth 19 Dec '06

19 Dec '06

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.

3 2

what policy for python egg files
by José Abílio Matos 18 Dec '06

18 Dec '06

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

6 14

File deps outside "/etc {/usr,}/{s,}bin/"
by Thorsten Leemhuis 16 Dec '06

16 Dec '06

%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

2 2

iconcache proposal, v2
by Rex Dieter 15 Dec '06

15 Dec '06

I've updated the iconcache proposal: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache per the suggestions made at the recent fedora-packaging meeting. In short, simplify to use xdg-utils, and add (when needed): Requires(post): xdg-utils Requires(postun): xdg-utils We could likely optimize %postun to include if [ $1 -eq 0 ]; then ... fi but I'm not sure if it's worth it. -- Rex

4 11

Revived License: tag proposal
by Jason L Tibbitts III 14 Dec '06

14 Dec '06

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<

5 11

Missing the meeting
by Toshio Kuratomi 11 Dec '06

11 Dec '06

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

2 1

Re: [Mimedefang] More on mimedefang and x86_64
by Philip Prindeville 11 Dec '06

11 Dec '06

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) +

1 0

Re: RPM weirdness [moved from fedora-list]
by Philip Prindeville 11 Dec '06

11 Dec '06

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

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2006