Patch cplay to use mplayer with speed-control
Hi everyone, I tried patching cplay to use mplayer(>=1.0pre7) which can also do speed-control on audio-files. My patch creates and uses a fifo to control mplayer and adds some keybindings to cplay (decr: [, incr: ], reset: =). I tried to write the patch as clean and stable as possible and provide my first trial on my webpage. I would be glad to receive some reviews and comments how to improve my code quality and some ideas what to do with my patch: - Should I mail it to the author of cplay? - Should I mail it to the maintainer of the debian package? - Should I fill a bugreport "feature-request" providing my patch? You can find further information, the patch and a patched version of cplay on my webpage: http://www.argafal.de/cgi-bin/index.pl?page=projcplay Thank you! -daniel- -- http://www.blackamp.de GPG-Key: 0x53BE81EC Fingerprint: A854 4C0A FF1A 09DF 5433 0EF8 1CF0 0213 53BE 81EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#375047: ITP: srtp -- Secure RTP (SRTP) and UST Reference Implementations
Jonas Smedegaard wrote: > (Include the long description here.) > Yes. Please do so. Writing the long description in the ITP allows debian-devel to help spot any mistakes in, and make suggestions for improvement to, the long description. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72140: Setting up libraries too slow
Tim Connors wrote: > only the occasional slowness as apt > replaces libc6 and the /sbin/ldconfig program gets restored. I move it > back out of the way when I notice that apt is taking so long, and all is > fine. man dpkg-divert That should help with your libc6 upgrades. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375047: ITP: srtp -- Secure RTP (SRTP) and UST Reference Implementations
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard <[EMAIL PROTECTED]> * Package name: srtp Version : 1.4.2 Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://srtp.sourceforge.net/srtp.html * License : BSD Programming Lang: C Description : Secure RTP (SRTP) and UST Reference Implementations (Include the long description here.) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc3-powerpc Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: swap on a LVM volume in debian-installer
On Thu, Jun 22, 2006 at 10:46:59PM +0200, David Härdeman wrote: > > I'm currently considering whether to change partman-auto-lvm so that the > swap partition is created as a lvm lv rather than a separate partition, > and I'd like to ask for some comments and feedback before doing so. ack. cool, already using since long, as swap on lvm allows much more flexibility. > o suspend-to-disk > There have been concerns that suspend/resume may not work with swap on a > lvm volume. > > Using initramfs-tools, it seems perfectly possible to resume from a swap > partition on lvm (I do so daily). I am not sure whether yaird supports > this feature. works right now fine on initramfs-tools. thanks for addressing the trouble of multiple volume groups. good work. :) -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: swap on a LVM volume in debian-installer
David Härdeman <[EMAIL PROTECTED]> writes: > The patch allows root and swap to be on different LVM VG's and should > be included in the next initramfs-tools version after 0.64 (which is > in incoming right now) according to maks on IRC. Also, if you and partman-auto-lvm later move to use swap in lvm might have more code share for crypto support in lvm too :-D That might be awesome :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house."
Re: RFC: swap on a LVM volume in debian-installer
On Thu, Jun 22, 2006 at 06:58:27PM -0300, Otavio Salvador wrote: David Härdeman <[EMAIL PROTECTED]> writes: o suspend-to-disk There have been concerns that suspend/resume may not work with swap on a lvm volume. A patch was send today for initramfs-tools to address some issues of it and in new upload should be fine. Am I right maks? Yes, that patch was from yours truly. Previously initramfs-tools would activate the LVM VG which contained the root LV, so if swap was on the same VG, it would be activated as a side-effect (and this is indeed how things are laid out with partman-auto-*). The patch allows root and swap to be on different LVM VG's and should be included in the next initramfs-tools version after 0.64 (which is in incoming right now) according to maks on IRC. Regards, David
Re: RFC: swap on a LVM volume in debian-installer
David Härdeman <[EMAIL PROTECTED]> writes: > o suspend-to-disk > There have been concerns that suspend/resume may not work with swap on > a lvm volume. A patch was send today for initramfs-tools to address some issues of it and in new upload should be fine. Am I right maks? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house."
RFC: swap on a LVM volume in debian-installer
Hi all, in debian-installer, there is a package - partman-auto-lvm - which can setup an entire disk to be used for the debian installation with the use of lvm for most partitions. Currently it sets up one boot partition, one swap partition and one lvm PV which is used for the rest of the partitions (usually root and possibly home depending on the recipe used). I'm currently considering whether to change partman-auto-lvm so that the swap partition is created as a lvm lv rather than a separate partition, and I'd like to ask for some comments and feedback before doing so. The last discussion of this feature seems to have been in this thread: http://lists.debian.org/debian-boot/2005/10/msg00842.html === So far, I've seen the following advantages and disadvantages of swap-on-lvm mentioned: Advantages == o makes more partitions available to LVM This means that the swap space can also be managed via the regular lvm tools. Swap space can be reclaimed, enlarged and shrunk using the regular tools when needed. E.g. if a larger swap space is needed, one can do a swapoff, lvextend, mkswap, swapon. In general, to get the most out of lvm, as many partitions as possible should use it. Disadvantages = These are mostly gathered from the above thread: o lowmem I'm not sure this is an issue. If root is already accessed via lvm, will accessing swap via lvm make a difference in lowmem situations? o suspend-to-disk There have been concerns that suspend/resume may not work with swap on a lvm volume. Using initramfs-tools, it seems perfectly possible to resume from a swap partition on lvm (I do so daily). I am not sure whether yaird supports this feature. o overhead Accessing swap via the LVM layer might introduce additional overhead. However, the LVM maintainer disagreed in the above thread, noting that swap should be an io-bound operation and I tend to agree. Note that these disadvantages might be i386 oriented, are there any other disadvantages on other arches, or on i386 for that matter, that I've overlooked? Discussion of additional advantages would also be welcome of course :) === The reason that I'm personally interested is that swap-on-lvm as the default for a lvm install would allow the experimental partman-auto-crypto (a package which uses partman-crypto and partman-auto-lvm to automatically partition a disk so that any partition except /boot will be encrypted) to share 90% of its code with partman-auto-lvm. Comments welcome. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy way to incorporate Ubuntu improvements back into Debian?
> See http://lists.debian.org/debian-x/2006/04/msg02216.html for the current > problem list. If anyone wants to help make Xgl in Debian a reality, I'd > love the help, but right now it's not looking very likely any time soon. For whatever it is worth: I'm using compiz-vanilla (which is a snapshot built regularly, approx 2-3 times a week) deb http://www.beerorkid.com/compiz dapper main on Debian unstable I had to grab one of the depends (one of the libraries) from debian experimental -- don't recall now which one... Also I've tried to build compiz on the box but it failed, it seems that libwnck18 (and its -dev) wasn't recent enough to include necessary function (wnck_window_has_name) for config test to pass and to build gnome decorator. Actually it seems from the most recent changelog.Debian entry for libwnck18 from beerorkid that it might work now: libwnck (2.14.2-0ubuntu2) dapper; urgency=low * Add compiz support. -- reggaemanu <[EMAIL PROTECTED]> Sun, 18 Jun 2006 02:29:07 +0200 -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpepWGvH80Hl.pgp Description: PGP signature
Bug#375014: ITP: libtap -- Unit test building library for the Test Anything Protocol
Package: wnpp Severity: wishlist Owner: Tyler MacDonald <[EMAIL PROTECTED]> * Package name: libtap Version : 0.0.0 Upstream Author : Nik Clayton <[EMAIL PROTECTED]> * URL : http://jc.ngo.org.uk/svnweb/jc/browse/nik/libtap/trunk/ * License : MIT-like Programming Lang: C Description : Unit test building library for the Test Anything Protocol libtap is a C library that provides simple functions to assist in writing unit tests that conform to the Test Anything Protocol (TAP). . TAP is a simple text output of unit test results that can easily be parsed by utilities such as prove(1) and complex QA applications such as Smolder (http://sourceforge.net/projects/smolder/). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374997: ITP: utf8-migration-tool -- tool to migrate a Debian system to UTF-8
Package: wnpp Severity: wishlist Owner: "Martin-Éric Racine" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: utf8-migration-tool Version : 0.4 Upstream Authors: Tollef Fog Heen <[EMAIL PROTECTED]>, Martin-Éric Racine <[EMAIL PROTECTED]> * URL : http://q-funk.iki.fi/debian/pool/u/utf8-migration-tool/ * License : GPL Programming Lang: Python, GTK2+ Description : tool to migrate a Debian system to UTF-8 This wizard upgrades legacy system locales to their UTF-8 equivalent. It also informs users whenever files in their home directory still utilize legacy encodings. * This started as an Ubuntu tool to enable easy migration to UTF-8 for both locale settings and user file encodings. Tollef says that since Ubuntu has been UTF-8 by default for a few releases already, they are not likely to further develop it and invited me to take over development, so I have. I have found this tool very usefull to help me locate remaining files in my home directory that are still in a legacy encoding and to check system files for UTF-8 locales utilization. Given how Etch is going to be the first Debian release with UTF-8 locales by default, I figure that it could be a usefull migration tool for others as well. Frans Pop suggest it could be worth mentioning in Etch's Release Notes and recommended that I filed an ITP. I would gladly welcome co-maintainance with Debian's i10n/i18n team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEmsN7eXr56x4Muc0RAhtMAKCuRqxDyPaY7a3G4AQBfG+RkJEBMwCfYd0J 4USvSEZsYeCHkFPW6WeBsEU= =F2n4 -END PGP SIGNATURE-
debian-devel@lists.debian.org
أدلة المعجزة الكبرى في مكة والكعبة تجد الموضوع على هذا الرابط http://alryssalah.ektob.com/entry.php?u=Alryssalah&e_id=15994 نرجو عدم حرماننا من إطلالتكم النيرة والإشتراك معنا على الرابط التالي http://groups.yahoo.com/group/Alryssalah/join أو إرسل رسالة فارغة إلى هذا العنوان [EMAIL PROTECTED] ولزيارة مجموعتنا على الرابط التالي http://groups.yahoo.com/group/Alryssalah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian-devel@lists.debian.org
أدلة المعجزة الكبرى في مكة والكعبة تجد الموضوع على هذا الرابط http://alryssalah.ektob.com/entry.php?u=Alryssalah&e_id=15994 نرجو عدم حرماننا من إطلالتكم النيرة والإشتراك معنا على الرابط التالي http://groups.yahoo.com/group/Alryssalah/join أو إرسل رسالة فارغة إلى هذا العنوان [EMAIL PROTECTED] ولزيارة مجموعتنا على الرابط التالي http://groups.yahoo.com/group/Alryssalah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374968: ITP: castpodder -- Multithreaded GUI Podcast Receiver
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: castpodder Version : 5.0 Upstream Author : CastPodder Team * URL : http://www.castpodder.net/ * License : GPL Programming Lang: Python Description : Multithreaded GUI Podcast Receiver CastPodder is a full-featured Podcast receiver (aggregator). It can be used to download audio or video Podcasts from the Internet and store or play them. . CastPodder features include a podcast download scheduler, multithreaded podcast updates, multithreaded podcast downloads, taskbar icon, OPML feed import/export, and podcast directory interface (iPodder.org and similar). . CastPodder is a fork and enhancement of the popular iPodder podcast receiver. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.18 Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374965: ITP: myspell-pt-pt -- European Portuguese dictionary for myspell
Package: wnpp Severity: wishlist Owner: Rafael Laboissiere <[EMAIL PROTECTED]> * Package name: myspell-pt-pt Version : 20060602 Upstream Author : Jose Joao de Almeida <[EMAIL PROTECTED]> Rui Vilela <[EMAIL PROTECTED]> Alberto Simões <[EMAIL PROTECTED]> * URL : http://linguateca.di.uminho.pt/dics/dics.html * License : GPL and BSD Description : European Portuguese dictionary for myspell This is the European Portuguese dictionary for use with the myspell spellchecker which is currently used within OpenOffice.org and the mozilla spellchecker. The package is already available at: http://people.debian.org/~rafael/pt-spell/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Online Job Offer...
MM Group Handling Unit 15 Carlyon Road Industrial Estate. Atherstone Warwickshire CV9 1LQ United kingdom Tel: +44-703-185-1879 Fax: +44-703-192-8279 Dear Sir/Madam, Ref:234/U, I am Mr. Richard.H.Manson Managing Director MM Group Handling. We are a trading company that is into the hire,sales and service of electrical trucks,fork truks and associated materials handling equipments and diverse range of battery electric vehicles which can be readily adapted for customers specific requirements to the USA,Canada and selected locations in Europe. We are searching for individuals or a company who can act as our representative/payment agent in your country and earn 10% of every payment made through you to us. For further details, do endeavour to forward the following below below to us OR call +44-703-185-1879 1. Full Names: 2. Company Name: 3. Full Contact Address: 4. Tel and Fax Numbers: 5. Aged: Regards, Richard.H.Manson Managing Director. Copyright © 1994-2006 MM Group Handling!!! All rights reserved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72140: Setting up libraries too slow
#include * Tim Connors [Thu, Jun 22 2006, 06:03:41PM]: > > On Sun, Sep 24, 2000 at 02:24:43PM +0200, Torsten Landschoff wrote: > > > On Sat, Sep 23, 2000 at 01:54:17PM -0400, [EMAIL PROTECTED] wrote: > > > > [EMAIL PROTECTED] /usr/bin/gkrellm > > > > /usr/bin/gkrellm: error in loading shared libraries: libXi.so.6: cannot > > > > open > > > > shared object file: No such file or directory > > > > > > Right, forgot about this. The dynamic linker does not actually use > > > /etc/ld.so.conf but only /etc/ld.so.cache. So if you don't have the lib > > > in the system path it may well be not found. > > > > > > > I think setting one envoromnment variable is slightly faster than > > > > running > > > > ldconfig :) > > > > > > Yep, but this is more error prone. You can easily forget to do that since > > > you need to do it in all postinst which depend on that library... > > > > > > Contrary ldconfig needs to be run in the lib installation script. > > > > > > > PS. Anyone know what other distro's (redhat?) do? Installing rpm's > > > > seems > > > > faster than .deb's, but I dont know if that has anything to do with this > > > > issue. > > > > > > I think they don't call ldconfig. > > > > > > Summary: Perhaps we should > > > > > > a) remove that ldconfig call from the library postinsts > > > b) make dpkg call ldconfig if any of /usr/lib, /lib or the dirs in > > > /etc/ld.so.conf has been touched since starting dpkg > > > c) demand that postinst which call programs with libs outside > > >/lib and /usr/lib sets LD_LIBRARY_PATH > > > > How about: > > > > a) remove the ldocnfig call from the library postinsts > > b) make dpkg set the LD_LIBRARY_PATH if its installing a library > >This would be a global setting that every program inherits, and would > > not > >require each library to modify its postinst, and set variables.. > > c) call ldconfig at the end of the install/upgrade > > This bug is still here, as bad as ever, after 6 years. > > ldconfig is still dog slow. I am using an ext3 fs, and ldconfig and Yed, ldconfig calls suck. I noticed that on a machine with "low memory" (less than 256MB), too many programs do too much things in postinst, so the VFS cache seems to become useless and the contents is exchanged all the time. Please read http://people.debian.org/~terpstra/message/20060312.125613.c03ce487.en.html and following. I stopped working on a proof-of-concpet after writting the base specs (see wiki link there) because of not having enough spare time and the requirement of dpkg modification (for LD_LIBRARY_PATH export/preset). If you wish to take it over, let us know and go ahead. > However, for the past 12 months, I have been symlinking /sbin/ldconfig to > /bin/true after moving ldconfig to ldconfig.real, with much success. No > crashes so far, no missing libraries, only the occasional slowness as apt > replaces libc6 and the /sbin/ldconfig program gets restored. I move it > back out of the way when I notice that apt is taking so long, and all is > fine. *g*... yes, AFAICS only the programs working with dlopen and non-standard paths do not cope with not having the up-to-date ld.so.cache. We could forbid the usage of such programs in the postinst via policy, make dpkg prepend a NOOP-symlink for ldconfig in the $PATH and everything should be fine RSN. > Perhaps, instead of changing policy, a quick fix: You don't need to > implement triggers properly -- you could just write something that logs > that ldconfig needs to be called later, call it /usr/lib/dpkg/ldconfig, > prepend /usr/lib/dpkg: to $PATH for everything dpkg spawns, and the new > file gets invoked in preferance to /sbin/ldconfig. That was the quick fix I suggested, the "better" solution is the dpkg-hook idea. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to execute a data-file's preferred app from the cmd-line?
On Thu, 2006-06-22 at 09:23 +0300, Török Edvin wrote: > On 6/22/06, Sune Vuorela <[EMAIL PROTECTED]> wrote: > > On 2006-06-22, David H. Cook <[EMAIL PROTECTED]> wrote: > > > So, my question is: Is there an equivalent cmd for 'start' (e.g. for > > > KDE)? > > > > kfmclient exec foobar.odt > What if I am using gnome? Should I use gnome-open then? > Ah, and how do I determine if I am running gnome or kde? > (look in the output of `ps x'?) Use xdg-open, from the Portland Project. http://portland.freedesktop.org/wiki/ It detects the DE and will use kfmclient/gnome-open/xfce-whatever as relevant. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Bug#72140: Setting up libraries too slow
> On Sun, Sep 24, 2000 at 02:24:43PM +0200, Torsten Landschoff wrote: > > On Sat, Sep 23, 2000 at 01:54:17PM -0400, [EMAIL PROTECTED] wrote: > > > [EMAIL PROTECTED] /usr/bin/gkrellm > > > /usr/bin/gkrellm: error in loading shared libraries: libXi.so.6: cannot > > > open > > > shared object file: No such file or directory > > > > Right, forgot about this. The dynamic linker does not actually use > > /etc/ld.so.conf but only /etc/ld.so.cache. So if you don't have the lib > > in the system path it may well be not found. > > > > > I think setting one envoromnment variable is slightly faster than running > > > ldconfig :) > > > > Yep, but this is more error prone. You can easily forget to do that since > > you need to do it in all postinst which depend on that library... > > > > Contrary ldconfig needs to be run in the lib installation script. > > > > > PS. Anyone know what other distro's (redhat?) do? Installing rpm's seems > > > faster than .deb's, but I dont know if that has anything to do with this > > > issue. > > > > I think they don't call ldconfig. > > > > Summary: Perhaps we should > > > > a) remove that ldconfig call from the library postinsts > > b) make dpkg call ldconfig if any of /usr/lib, /lib or the dirs in > > /etc/ld.so.conf has been touched since starting dpkg > > c) demand that postinst which call programs with libs outside > >/lib and /usr/lib sets LD_LIBRARY_PATH > > How about: > > a) remove the ldocnfig call from the library postinsts > b) make dpkg set the LD_LIBRARY_PATH if its installing a library >This would be a global setting that every program inherits, and would > not >require each library to modify its postinst, and set variables.. > c) call ldconfig at the end of the install/upgrade This bug is still here, as bad as ever, after 6 years. ldconfig is still dog slow. I am using an ext3 fs, and ldconfig and hence dpkg is not quicker the second time around -- one suspects ldconfig is trying to read so much cruft that any information has been long purged out of the filesystem cache before ldconfig is invoked the second time. However, for the past 12 months, I have been symlinking /sbin/ldconfig to /bin/true after moving ldconfig to ldconfig.real, with much success. No crashes so far, no missing libraries, only the occasional slowness as apt replaces libc6 and the /sbin/ldconfig program gets restored. I move it back out of the way when I notice that apt is taking so long, and all is fine. Occasionally, if I feel like it, I manually run /sbin/ldconfig.real, but I notice no difference whether the cache is updated or not. I only notice it when it is being run during an package uprade or installation and it takes 3 minutes per invocation, which tells me the cache is largely useless. I think the ldconfig calls should be removed from all packages, after changing policy. It seriously takes 10 times longer to update my system if those useless calls are made. If you really need to, make a log in each postinst that *thinks* it needs ldconfig, and if one package thought it needed it, run it at the end just before dpkg exits. Don't just blindly run it everytime dpkg is invoked, because I may well have installed just one package rather than upgrading the system, and it may well have not required ldconfig. Perhaps, instead of changing policy, a quick fix: You don't need to implement triggers properly -- you could just write something that logs that ldconfig needs to be called later, call it /usr/lib/dpkg/ldconfig, prepend /usr/lib/dpkg: to $PATH for everything dpkg spawns, and the new file gets invoked in preferance to /sbin/ldconfig. -- TimC -- http://http://astronomy.swin.edu.au/staff/tconnors/ >Cats are intended to teach us that not everything in nature has a function. You're saying cats are the opposite of bijectiveness? -- ST in RHOD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
