Re: ObsoleteConffilesOfInstalledPackages
Mike Bird wrote: > Some people have expressed interested in obsolete config files > associated with currently installed packages. [...] Correct behavior is to remove obsolete _unmodified_ conffiles, as Roger mentioned. Which of the conffiles mentioned below were modified? No way to know just yet. I. Known bugs > 5.0.7 bittorrent 3.4.2-11.1 /etc/init.d/bittorrent > 5.0.7 bittorrent 3.4.2-11.1 /etc/default/bittorrent > 6.0 bittorrent 3.4.2-11.3 /etc/init.d/bittorrent > 6.0 bittorrent 3.4.2-11.3 /etc/default/bittorrent http://bugs.debian.org/550229 > 5.0.7 bluez-utils 3.36-3 /etc/modprobe.d/bluez > 5.0.7 bluez-utils 3.36-3 /etc/modutils/bluez http://bugs.debian.org/523050 II. Known non-bugs > 5.0.7 base-files 5lenny8 /etc/nsswitch.conf 2006-03-04, base-files (3.1.11): * The file /etc/nsswitch.conf is now created by postinst in the first install (made by debootstrap), and it's no longer a conffile. > 5.0.7 bash 3.2-4 /etc/bash_completion 2008-02-09, bash (3.1dfsg-9): * Remove bash-completion from the source. * Remove the conflict with bash-completion, recommend bash-completion. > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Editres.ad > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Emacs.ad > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/General.ad > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Motif.ad > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Tk.ad > 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Xaw.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Editres.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Emacs.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/General.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Motif.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Tk.ad > 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Xaw.ad 2008-12-27, gnome-settings-daemon (2.24.1-1): * Install .ad files in /etc/gnome/config to replace the ones from capplets-data which are still used. > 5.0.7 clamav-freshclam 0.96.5+dfsg-1~volatile1 > /etc/logrotate.d/clamav-freshclam > 6.0 clamav-freshclam 0.96.5+dfsg-1 /etc/logrotate.d/clamav-freshclam Still needed. /var/lib/ucf/hashfile keeps track of it. > 5.0.7 desktop-file-utils 0.15-1 /etc/gnome/defaults.list 2009-03-19, gnome-session (2.22.3-3): * defaults.list: move the defaults from gnome-vfs. + Add some subtypes of text/plain to gedit defaults. > 5.0.7 gconf2 2.22.0-1 /etc/gconf/2/path Intended to be present (included in new installations, not a ghost from the past). Not a conffile any more. III. Indeterminate (probably bugs but need checking) > 5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/13-915-resolution-set.sh > 5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/49-915-resolution-set.sh 2008-05-12, acpi-support (0.109-1): * Remove /etc/acpi/resume.d/49-915-resolution-set.sh. It will be moved to the 915resolution package. Closes: #447742, #467347. > 5.0.7 apache2.2-common 2.2.9-10+lenny9 > /etc/apache2/mods-available/sick-hack-to-update-modules 2007-07-01, apache2 (2.2.4-1): * remove sick-hack-to-update-modules > 5.0.7 bind9 1:9.6.ESV.R3+dfsg-0+lenny1 /etc/apparmor.d/apparmor-profile renamed to usr.sbin.named, 2008-03-01, bind9 (1:9.4.2-6): * Correct apparmor profile filename. LP: #200739 > 5.0.7 clamav-daemon 0.96.5+dfsg-1~volatile1 /etc/default/clamav-daemon > 6.0 clamav-daemon 0.96.5+dfsg-1 /etc/default/clamav-daemon 2008-11-29, clamav (0.94.dfsg.2-1), checked by interdiff: * The TemporaryDirectory option has been added long ago, no need for hacks via clamav-daemon.default anymore (closes: #253080) > 5.0.7 e2fsprogs 1.41.3-1 /etc/e2fsck.conf An odd one. Maybe /etc/lsb-release said Ubuntu once for some reason? > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/README > 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/README 2008-05-24, fontconfig (2.5.93-1): * Stick config README in /etc/fonts.conf.d (closes: 393999) > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/autohint.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-bitmaps.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-sub-pixel.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/sub-pixel.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/unhinted.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/yes-bitmaps.conf Strange. fontconfig.preinst should have taken care of this during the upgrade to >= 2.3.2-2. > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/20-lohit-gujarati.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/30-amt-aliases.conf > 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/40-generic.conf > 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/20-lohit-gujarati.conf > 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/30-amt-aliases.conf > 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/40-generic.conf Various upstream changes. Probably a bug (why are these conffile
Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files
On Sun, Jan 16, 2011 at 07:07:05PM +0100, Michal Čihař wrote:
[...]
> Does it really make sense to package EXIF library, which is two years
> dead and does not support any recently made cameras? Would not be
> better to rather use something alive like pyexiv2?
libexif is not very active but it's still alive (mainly bug and security
fixes). Last release: 2010-12-15 [1]
M.
[1] http://libexif.sourceforge.net/
--
Emmanuel Bouthenot
mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
xmpp: kol...@im.openics.org irc: kolter@{freenode,oftc}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110117085150.ga13...@openics.org
Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files
Hi Dne Mon, 17 Jan 2011 09:51:50 +0100 Emmanuel Bouthenot napsal(a): > On Sun, Jan 16, 2011 at 07:07:05PM +0100, Michal Čihař wrote: > [...] > > > Does it really make sense to package EXIF library, which is two years > > dead and does not support any recently made cameras? Would not be > > better to rather use something alive like pyexiv2? > libexif is not very active but it's still alive (mainly bug and security > fixes). Last release: 2010-12-15 [1] python-exif does not use libexif, it's python only implementation. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files
Hi Dne Mon, 17 Jan 2011 09:07:46 +0900 TANIGUCHI Takaki napsal(a): > I submitted ITP for simple-image-reducer (#607237). That depends on > python-exif, if python-exif has not good support, anyway I need this > package. Okay, in this case it probably makes sense. However the common practice for now seems to be embedding EXIF.py into the package, following packages already ship EXIF.py at various versions (dd-list attached): phatch-cli photon postr pyrenamer python-kaa-metadata python-moinmoin python-pythoncard So once this get's packaged, all these should switch to the packaged version. -- Michal Čihař | http://cihar.com | http://blog.cihar.com Adolfo González Blázquez pyrenamer Jeremie Corbier kaa-metadata (U) Kevin Coyner photon Freevo Debian Dream Team kaa-metadata Debian QA Group pythoncard Georg W. Leonhardt kaa-metadata (U) Stani M phatch (U) Emilio Pozuelo Monfort phatch (U) Piotr Ożarowski phatch (U) David Paleino postr Python Applications Packaging Team phatch Jonas Smedegaard moin signature.asc Description: PGP signature
Re: How to build a 32-bit package in Debian?
On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote: > On Mon, Jan 17, 2011 at 11:25 AM, Steve M. Robbins wrote: > > > What is the recommended course of action for such a package? > > For now: build on a 32-bit system or in a 32-bit chroot. > > Other options in increasing order of preference: > > Add deps to ia32-libs. > > Add lib32 packages for the deps. > > Help fix squeeze RC bugs then start work on multi-arch when the wheezy > cycle starts. There's a wonderful thing called "xapt", aka "multi-arch working today". Sadly, it can't be integrated into build-depends like real multi-arch will be, but getting all libraries you need is a matter of typing: # xapt -a pdp11 liblossage1 liblossage-dev -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117095358.ga16...@angband.pl
Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files
Hi, wouldn't it make sense to coordinate this in http://pkg-phototools.alioth.debian.org/ I recently learned about this group and its a shame that it is widely unknown and not even has a Wiki page. Kind regards Andreas. On Mon, Jan 17, 2011 at 10:37:03AM +0100, Michal Čihař wrote: > Hi > > Dne Mon, 17 Jan 2011 09:07:46 +0900 > TANIGUCHI Takaki napsal(a): > > > I submitted ITP for simple-image-reducer (#607237). That depends on > > python-exif, if python-exif has not good support, anyway I need this > > package. > > Okay, in this case it probably makes sense. However the common practice > for now seems to be embedding EXIF.py into the package, following > packages already ship EXIF.py at various versions (dd-list attached): > > phatch-cli > photon > postr > pyrenamer > python-kaa-metadata > python-moinmoin > python-pythoncard > > So once this get's packaged, all these should switch to the packaged > version. > > -- > Michal Čihař | http://cihar.com | http://blog.cihar.com > Adolfo Gonz??lez Bl??zquez >pyrenamer > > Jeremie Corbier >kaa-metadata (U) > > Kevin Coyner >photon > > Freevo Debian Dream Team >kaa-metadata > > Debian QA Group >pythoncard > > Georg W. Leonhardt >kaa-metadata (U) > > Stani M >phatch (U) > > Emilio Pozuelo Monfort >phatch (U) > > Piotr O??arowski >phatch (U) > > David Paleino >postr > > Python Applications Packaging Team >phatch > > Jonas Smedegaard >moin > -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117102952.gb23...@an3as.eu
Re: How to build a 32-bit package in Debian?
On Mon, 17 Jan 2011 10:53:58 +0100 Adam Borowski wrote: > On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote: > > On Mon, Jan 17, 2011 at 11:25 AM, Steve M. Robbins wrote: > > > > > What is the recommended course of action for such a package? > > > > For now: build on a 32-bit system or in a 32-bit chroot. > > > > Other options in increasing order of preference: > > > > Add deps to ia32-libs. > > > > Add lib32 packages for the deps. > > > > Help fix squeeze RC bugs then start work on multi-arch when the wheezy > > cycle starts. > > There's a wonderful thing called "xapt", aka "multi-arch working today". > Sadly, it can't be integrated into build-depends like real multi-arch will > be, but getting all libraries you need is a matter of typing: > > # xapt -a pdp11 liblossage1 liblossage-dev xapt is available as part of the pdebuild-cross package in Squeeze and Sid (in /usr/share) and as a standalone package in experimental - the later version in experimental is the updated version with more fixes. xapt is NOT multiarch, it still uses dpkg-cross to rename packages, but it is easier to use and more reliable than the old apt-cross package which has been removed from Squeeze and will be removed from Sid when Squeeze is released. xapt is just a handy way to get people through the removal of apt-cross until something more multiarch compatible turns up. In the xapt package is a tool called embuilddeps which automates reading the control information and identifying the packages to pass to xapt. The goal with both tools is simplicity - the tools tend to do more than you need so that you don't end up with a broken build. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpc8RAjQUK94.pgp Description: PGP signature
Re: Why is help so hard to find?
On Fri, Jan 14, 2011 at 04:52:13PM -0800, Russ Allbery wrote: > Roger Leigh writes: > > Yes, and this is what I did. It's just rather tedious to (IIRC) > > repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file > > is offending, run "dpkg -S $file", and then purge it. > I've not looked at the mechanism involved at all, but it does seem like we > should be able to print out all of the files that would cause failures. > Maybe it's hard to continue from an error long enough to find additional > files? It'd also be *much* nicer if it were possible to do the checks outside of dpkg-reconfigure, especially if you're using a frontend that doesn't make cut'n'paste easy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117115818.ga3...@sirena.org.uk
Re: Can insserv made better?
At the risk of contributing to what is already often an ill-tempered
and unconstructive thread:
Roger Leigh writes ("Re: Can insserv made better?"):
> You're saying that an unwieldy ad-hoc fixed list of numbers and names
> is superior to detailed dependency information? This is patently
> untrue.
The ad-hoc fixed list of numbers does in some sense contain or
represent some information which is not captured in the explicit
dependencies. This is because the fixed list of numbers has been
"debugged" (including, when irreconcilable problems arise due to
different setups needing different orders, by having arguments about
which setup is more common) to include a lot of dependencies which are
not necessarily declared for the new scheme.
Or to put it another way the fact that the new paradigm is more
powerful and correct does not mean that the _actual data_ we are using
is more correct. Indeed it seems that the actual data for the
dependency-based setup is in many respects less good than the actual
data for the old sequence with the result that arguably the
_actual_ old sequence has fewer bugs than the _actual_ new
dependencies. (Even though some of the old sequence's bugs cannot be
fixed without introducing new ones.)
Why are we insisting on the change to insserv being "recommended" by
the debconf question ?
It seems to me that we should be giving accurate guidance to the user
about a decision that they are to make. That guidance is probably
that:
- On a simple system with default configuration, insserv will
produce a faster boot and is unlikely to break, so is probably a
good idea.
- On a complicated or unusual system, insserv involves a significant
risk of breakage which can be difficult to fix - and the change
cannot be reverted. So it is not a good idea.
Furthermore, why does this debconf question have such a high priority?
High-priority questions should be used only for matters where there is
no good default. But existing systems which are currently working
will not be broken by doing the squeeze upgrade but not switching to
insserv - so there is a perfectly good default, which is not to
switch.
> Your (rejected) patch was not addressing the issue. Documenting the
> pros and cons of moving to dependency-based boot is entirely beside the
> point: we have moved to dependency-based boot. *Your* choice is not if
> to move, but when. [...]
New installs get insserv by default. During the lifetime of squeeze
we can hope that users of those new installs will file bugs for
missing dependencies as they discover them.
It seems to me that for existing installs, the best choice would be to
wait _at least_ until after sqeeze.
> I can't say I'm the biggest fan of insserv myself, but that's what
> is currently supported, and if you want something different, then
> you'll need to step up and start doing the work yourself. I do hope
> we'll have systemd (preferred) or upstart post-squeeze, but I don't
> see /any/ value in returning to fixed-order scripts:
No-one is suggesting "returning" to them, in the sense that no-one is
suggesting that any system which has changed to insserv (and still
works!) should be changed back.
But perhaps it would be wise to review our choice of defaults in the
light of our experience of the quality of the software ?
> we lived with their multitude of deficiencies for decades,
> and now we have a working solution to that. Your efforts would be best
> focussed on finding, fixing and reporting any issues which are causing
> you problems, not griping about decisions which were already taken. It
> was changed in July 2009 for crying out loud! You've had 18 months to
> report any issues?
That some people here did not report and/or fix bugs, is no excuse for
giving all of Debian's users suboptimal defaults. Even if not fixing
bugs in insserv is somehow blameworthy, it isn't the users' fault.
The failure of some people here to report and/or fix bugs is no excuse
ramming through a hasty transition to software which may not be of
acceptable quality.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19764.13849.75483.511...@chiark.greenend.org.uk
Re: Why is help so hard to find?
Don Armstrong writes ("Re: Why is help so hard to find?"):
> A possible hack would be to have insserv ignore any initscripts which
> are conffiles which when run without options exit with zero status.
It could probably safely invoke them with:
/etc/init.d/obsolete --fail-please
> But this probably has some ugly consequences which aren't totally
> obvious to me right this second.
Yes. Surely the right thing to do at this stage of the release cycle
is to tone down the extent to which we are pushing insserv, and to
revisit this questions after the release.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19764.14049.480878.221...@chiark.greenend.org.uk
packages with hook interfaces and no documented hook policy
After discovering two different unrelated packages abusing the pm-utils hooks, I started wondering if there are any generic guidance wrt such hooks. Can any package just provide the hook directories it want without an explicit policy? And can any package provide hooks in such directories, even if there is no policy for its usage? Does it make any difference if the hooks are configuration files? My claim is that packages like unattended-upgrades and pm-utils are completely unrelated to each other, and that a hook in unattended-upgrades which breaks pm-utils by preventing hibernation is a critical bug, even if the breakage seems intentional. But i may be wrong. Maybe it's OK to break any package with a hook interface and no policy for its usage, as the package itself then has provided the necessary infrastructure for breaking it? Thanks, Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqrv8lz8@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
On Mon, 17 Jan 2011 18:43:23 +0100 Bjørn Mork wrote: > Can any package just provide the hook directories it want without an > explicit policy? A general policy for all hooks sounds like a difficult thing to create - it could easily be so nebulous as to be unusable. Probably better for each package supporting hooks to handle their own. If the hook syntax is correct for the package running the hook, that would be the majority of such a policy being met. Hook policy is in the hands of whichever package is trying to run the hooks. If the hook meets the requirement of that package, it's not a bug to provide such a hook. > And can any package provide hooks in such > directories, even if there is no policy for its usage? Does it make > any difference if the hooks are configuration files? Arguably easier if they are configuration files so that the admin can optimise which hooks are used. Even so, there are situations where such hooks should *use* existing configuration files rather than necessarily being configuration files themselves. > My claim is that packages like unattended-upgrades and pm-utils are > completely unrelated to each other, I'd disagree - if one package provides a hook for another package, those packages are clearly related. One is executing a known API of the other - that's a definite relationship. > and that a hook in > unattended-upgrades which breaks pm-utils by preventing hibernation > is a critical bug, even if the breakage seems intentional. Sounds to me as if unattended-upgrades would have a perfectly good reason to prevent hibernation, if configured in that manner. I'm not sure it's a bug at all. Would be better if unattended-upgrades made this step configurable, true. Why use unattended-upgrades if the machine is not on a UPS? That would seem to be the typical use case to me (the UPS providing a period of time normally sufficient for an unattended upgrade to complete whilst on UPS power before shutting down). Other setups would need different configuration and maybe unattended-upgrades ought to support that. However, that would be a minor or wishlist bug. One alternative would be to conflict with pm-utils. > But i may be wrong. Maybe it's OK to break any package with a hook > interface and no policy for its usage, as the package itself then has > provided the necessary infrastructure for breaking it? The package providing the hook interface makes itself accessible to other packages which may provide hooks. As long as the hook syntax is correct, it is up to the package providing the hook to ensure that only relevant functionality is exposed via the hooks. If a package contains a hook for that program which uses valid syntax to make a particular change, it's not a bug if that functionality is changed in that manner by that hook. There may be a bug in the package supporting hooks if the changed functionality has adverse effects - that particular functionality may need to be inaccessible from hooks. There may be a bug in the package containing the hook if the hook breaks the package processing the hook but that bug is clearly a bug affecting two strongly related packages. This package may need to allow for such hooks to be disabled in the package configuration to fix such a bug. The hook should also take steps to ensure that it is only active in appropriate situations, in this case when an upgrade is actually in progress. Neither bugs would necessarily be RC - it all depends on whether there is data loss or some other reason for such severity. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWHRbzYiWiY.pgp Description: PGP signature
Re: packages with hook interfaces and no documented hook policy
On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork wrote: > My claim is that packages like unattended-upgrades and pm-utils are > completely unrelated to each other, and that a hook in > unattended-upgrades which breaks pm-utils by preventing hibernation is a > critical bug, even if the breakage seems intentional. Is this just a case of an upgrade pulling in a new kernel, which could cause pm-hibernate to disallow a hibernate[0]? If so, this isn't unattended-upgrades breaking pm-utils, but pm-utils properly preventing you from hibernating in a situation that you wouldn't be able to recover. The proper fix is to configure the unattended upgrade not to upgrade kernels, if possible. [0]: See /usr/lib/pm-utils/sleep.d/000kernel-change -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikGMX5Nwq=npqqdpwaaxsvzcom23p1ut6mdt...@mail.gmail.com
Re: packages with hook interfaces and no documented hook policy
James Vega writes:
> On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork wrote:
>> My claim is that packages like unattended-upgrades and pm-utils are
>> completely unrelated to each other, and that a hook in
>> unattended-upgrades which breaks pm-utils by preventing hibernation is a
>> critical bug, even if the breakage seems intentional.
>
> Is this just a case of an upgrade pulling in a new kernel, which could
> cause pm-hibernate to disallow a hibernate[0]?
No, that one I can understand. If the kernel changes, then you have to
reboot before you can hibernate. But that is part of the kernel upgrade
hooks and not really related to how the kernel is upgraded.
This is what I find unacceptable about unattended-upgrades:
case "${1}" in
hibernate)
python
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
;;
where the /usr/share/unattended-upgrades/unattended-upgrade-shutdown
script is documented as
# unattended-upgrade-shutdown - helper that checks if a
# unattended-upgrade is in progress and waits until it exists
So you have to wait for this job to finish before hibernation will
succeed. This may take significant time. When I push the hibernate
button, I expect the system to be frozen and hibernated as quickly as
possibly. I do not want for any random process to finish its work.
My claim is that *any* package installing a program which may be running
at hibernation time just as well could install something similar. There
is nothing special about the unattended-upgrade job which could possibly
justify that you need to wait for it to finish. It should be frozen
like any other process, and thawed like any other process on resume.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vyj8gt1@nemi.mork.no
Re: Why is help so hard to find?
Mike Bird dijo [Sat, Jan 15, 2011 at 10:51:43AM -0800]: > > KDE4 is crap, world+dog know that. Use GNOME, XFCE or whatever. If you > > want KDE3 in Debian, then put your money where your mouth is and > > come maintain it. > > That is well known. KDE 4 maintainers cannot keep up with > the bug reports now and will be totally overwhelmed when > Squeeze is released. That is not what people expect of > Debian Stable. > > The problem is that KDE 4 has moved to take over the package > namespace used by KDE 3.5. This is totally unnecessary. > KDE 4 - the new package suite - can and should use new > non-conflicting package names. > (...) Thing is, the KDE project evolved (for better or worse - I don't know, as I don't use either) from v3 to v4. Yes, many people disliked the change, and started off Trinity. However, the package namespace still belongs to KDE - As Trinity is a fork, and it is Trinity users who have to specify "I don't want to use official upstream KDE anymore". And yes, it is surely a PITA for you and for others who prefer sticking with the KDE3 way - I guess it is a matter of personal preference... But given that nobody has stepped up to package Trinity for Debian, I can only assume KDE4 is good enough for them. Who are neither few nor lazy nor incompetent - I know the KDE team is made of committed, professional people. If they feel KDE4 is stable and usable enough, then KDE4 is what stays for Debian. Of course, you and everybody else are welcome to disagree. And had you disagreed some months earlier (given the decision is not by far new), I am sure nobody would have opposed your ITPs to introduce Trinity to Debian. And having two migration paths for Lenny's KDE3, there would have been a real possibility for the KDE team to coordinate with the Trinity team and offer the pertinent information and way forward for users. Of course, that is purely speculative. Right now, we _know_ how Squeeze will look like. And it is _impossible_ for it to include Trinity, or to have all KDE packages renamed to somehtingelse. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117194605.gb23...@gwolf.org
Re: packages with hook interfaces and no documented hook policy
Neil Williams writes: > On Mon, 17 Jan 2011 18:43:23 +0100 > Bjørn Mork wrote: > >> Can any package just provide the hook directories it want without an >> explicit policy? > > A general policy for all hooks sounds like a difficult thing to create > - it could easily be so nebulous as to be unusable. Probably better for > each package supporting hooks to handle their own. > > If the hook syntax is correct for the package running the hook, that > would be the majority of such a policy being met. > > Hook policy is in the hands of whichever package is trying to run the > hooks. If the hook meets the requirement of that package, it's not a > bug to provide such a hook. Ah, I see that I was a bit unclear. What I meant to ask, was just that: Should a package providing hook infrastructure also define a policy for its usage? >> My claim is that packages like unattended-upgrades and pm-utils are >> completely unrelated to each other, > > I'd disagree - if one package provides a hook for another package, > those packages are clearly related. One is executing a known API of the > other - that's a definite relationship. Yes, I see that point. Which implies that if you provide some hook infrastructure without restricting its policy, then you are really opening for *anyone* to break your package. Kind of dangerous... >> and that a hook in >> unattended-upgrades which breaks pm-utils by preventing hibernation >> is a critical bug, even if the breakage seems intentional. > > Sounds to me as if unattended-upgrades would have a perfectly good > reason to prevent hibernation, if configured in that manner. I'm not > sure it's a bug at all. Would be better if unattended-upgrades made > this step configurable, true. Why use unattended-upgrades if the > machine is not on a UPS? That would seem to be the typical use case to > me (the UPS providing a period of time normally sufficient for an > unattended upgrade to complete whilst on UPS power before shutting > down). Other setups would need different configuration and maybe > unattended-upgrades ought to support that. However, that would be a > minor or wishlist bug. Huh? I use unattended-upgrades on my laptop as a way to keep it updated without having to create the cron job myself. But I don't expect it to force itself to run at times where I want to the laptop to sleep. > One alternative would be to conflict with pm-utils. Sorry, I still don't see what's so special about the unattended-upgrades cron job. Couldn't e.g. logrotate just as well argue that it should be allowed to finish its work before the machin is hibernated? Or any program for that matter? hibernate is supposed to freeze running processes, not wait for them to finish. >> But i may be wrong. Maybe it's OK to break any package with a hook >> interface and no policy for its usage, as the package itself then has >> provided the necessary infrastructure for breaking it? > > The package providing the hook interface makes itself accessible to > other packages which may provide hooks. As long as the hook syntax is > correct, it is up to the package providing the hook to ensure that only > relevant functionality is exposed via the hooks. If a package contains > a hook for that program which uses valid syntax to make a particular > change, it's not a bug if that functionality is changed in that manner > by that hook. OK, sounds kind of reasonable. Except that I think I have to remove pm-utils then I just cannot accept that the hibernate/resume process becomes as bloated as a full shutdown/reboot. > There may be a bug in the package supporting hooks if the changed > functionality has adverse effects - that particular functionality may > need to be inaccessible from hooks. > > There may be a bug in the package containing the hook if the hook > breaks the package processing the hook but that bug is clearly a bug > affecting two strongly related packages. This package may need to allow > for such hooks to be disabled in the package configuration to fix such > a bug. The hook should also take steps to ensure that it is only active > in appropriate situations, in this case when an upgrade is actually in > progress. > > Neither bugs would necessarily be RC - it all depends on whether there > is data loss or some other reason for such severity. OK, I understand that I have opened a couple of bugs which will have to be downgraded a bit. Thanks for taking the time to answer this. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o978fx7@nemi.mork.no
Re: Can insserv made better?
Mike Bird dijo [Sun, Jan 16, 2011 at 01:09:39PM -0800]: > No, I'm saying that Snn/Knn values boot some systems where > insserv fails. Therefore Snn/Knn is superior in some cases. > I readily concede that insserv is superior in some cases. > > In order to avoid breaking Debian systems we should give > people a balanced overview of the pros and cons rather > than blindly telling them that insserv is "recommended" > when it is unnecessary and may break their systems. > > I'm not asking for insserv to be removed. I'm asking > that Debian users be given accurate information upon > which to base their decisions rather than dangerously > misleading information. As it was already pointed out to you, such occurences were due to incomplete dependencies declared in the initscripts - And as such, they were bugs in the respective packages. The right way to fix them is to provide the needed dependency information in the startup scripts. Yes, upgrades (specially upgrades of complex, production systems) should be faced with care and after having thoroughly studied the relevant release notes. Now, there is a real intention from Debian's part to getting out of the 1980s Sxx/Kxx scheme. It is an obsolete scheme, not suitable for our amount of packages, which had effectively been squished to much less because of the inability to declare what depended on what, and assuming a flat world. Dependency-based boot ordering gives important benefits to our users. And yes, benefits will sometimes require an experienced sysadmin to learn a new trick, scratch a bit his head. The change is worth a little re-learning. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117195524.gc23...@gwolf.org
Re: Why is help so hard to find?
On 2011-01-17, Gunnar Wolf wrote: > Mike Bird dijo [Sat, Jan 15, 2011 at 10:51:43AM -0800]: >> That is well known. KDE 4 maintainers cannot keep up with >> the bug reports now and will be totally overwhelmed when >> Squeeze is released. That is not what people expect of >> Debian Stable. a guess is that more than half of the current open bug reports is actually filed against KDE's 3.x series ... > Thing is, the KDE project evolved (for better or worse - I don't know, > as I don't use either) from v3 to v4. Yes, many people disliked the > change, and started off Trinity. However, the package namespace still trinity started as a one man effort like a year or two ago. I think there currently is 2 or 3 active contributors. > Of course, you and everybody else are welcome to disagree. And had you > disagreed some months earlier (given the decision is not by far new), Mike Bird did already back then communicate to the team in his usual abusive way, only a while after he had done the same to the fedora KDE people. > I am sure nobody would have opposed your ITPs to introduce Trinity to > Debian. And having two migration paths for Lenny's KDE3, there would that would have required Mike Bird to put his time where his mouth is. > have been a real possibility for the KDE team to coordinate with the > Trinity team and offer the pertinent information and way forward for > users. I think I (and maybe other Debian-KDE people) objected to do packaging changes to make things coexisting on the system. The only people who has had KDE's 3.5 and 4.x series installed on the same system is distributions like Suse, because they have had KDE's 3.x series installed under /opt Gentoo, because they have invented /usr/kde/x.y/ as installation prefix and some (like kubuntu) temporarily providing things in a /usr/lib/kde4/ installation prefix (including /usr/lib/kde4/lib/kde4 for plugins, and/usr/lib/kde4/share for arch independant files) > Of course, that is purely speculative. Right now, we _know_ how > Squeeze will look like. And it is _impossible_ for it to include > Trinity, or to have all KDE packages renamed to somehtingelse. And a different thing that makes trinity packaging a nightmare. Trinity upstream happily breaks binary compatibility between releases of the trinity kdelibs. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnij9819.rvp.nos...@sshway.ssh.pusling.com
Bug#610347: ITP: dipy -- toolbox for analysis of MR diffusion imaging data
Package: wnpp Severity: wishlist Owner: NeuroDebian Team * Package name: dipy Version : 0.5.0~dev Upstream Author : Dipy Developers * URL : http://nipy.org/dipy * License : BSD Programming Lang: Python Description : toolbox for analysis of MR diffusion imaging Dipy is a toolbox for the analysis of diffusion magnetic resonance imaging data. It features: - Reconstruction algorithms, e.g. GQI, DTI - Tractography generation algorithms, e.g. EuDX - Intelligent downsampling of tracks - Ultra fast tractography clustering - Resampling datasets with anisotropic voxels to isotropic - Visualizing multiple brains simultaneously - Finding track correspondence between different brains - Warping tractographies into another space, e.g. MNI space - Reading many different file formats, e.g. Trackvis or NIfTI - Dealing with huge tractographies without memory restrictions - Playing with datasets interactively without storing -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117194054.19214.57751.report...@novo.onerussian.com
Re: packages with hook interfaces and no documented hook policy
On Mon, 17 Jan 2011 20:54:12 +0100 Bjørn Mork wrote: > Neil Williams writes: > > On Mon, 17 Jan 2011 18:43:23 +0100 > > Bjørn Mork wrote: > > Hook policy is in the hands of whichever package is trying to run > > the hooks. If the hook meets the requirement of that package, it's > > not a bug to provide such a hook. > > Ah, I see that I was a bit unclear. What I meant to ask, was just > that: Should a package providing hook infrastructure also define a > policy for its usage? It can, it doesn't have to. What matters is that the package only exposes appropriate functionality via hooks and makes appropriate settings configurable. > >> My claim is that packages like unattended-upgrades and pm-utils are > >> completely unrelated to each other, > > > > I'd disagree - if one package provides a hook for another package, > > those packages are clearly related. One is executing a known API of > > the other - that's a definite relationship. > > Yes, I see that point. Which implies that if you provide some hook > infrastructure without restricting its policy, then you are really > opening for *anyone* to break your package. > > Kind of dangerous... No. The hooks cannot do everything - the package controlling the hooks needs to handle the hooks sensibly. > > Sounds to me as if unattended-upgrades would have a perfectly good > > reason to prevent hibernation, if configured in that manner. I'm not > > sure it's a bug at all. Would be better if unattended-upgrades made > > this step configurable, true. Why use unattended-upgrades if the > > machine is not on a UPS? That would seem to be the typical use case > > to me (the UPS providing a period of time normally sufficient for an > > unattended upgrade to complete whilst on UPS power before shutting > > down). Other setups would need different configuration and maybe > > unattended-upgrades ought to support that. However, that would be a > > minor or wishlist bug. > > Huh? I use unattended-upgrades on my laptop as a way to keep it > updated without having to create the cron job myself. But I don't > expect it to force itself to run at times where I want to the laptop > to sleep. Use cron-apt instead? unattended-upgrades is more commonly used on servers with a PSU attached. I wouldn't ever use any form of automated upgrades on a laptop - no guarantee the laptop has a connection even if it is on. I'm afraid this comes down to error between chair and keyboard. Most people just wouldn't put those packages on a laptop. > Sorry, I still don't see what's so special about the > unattended-upgrades cron job. Couldn't e.g. logrotate just as well > argue that it should be allowed to finish its work before the machin > is hibernated? Or any program for that matter? hibernate is > supposed to freeze running processes, not wait for them to finish. Different package objectives. cron-apt may be what you are actually thinking of. Even then, I wouldn't use cron-apt on a laptop. The hibernate hook could just be configurable, that's all. In most cases, it probably is the right hook and on most laptops, automated upgrades are simply not useful. > OK, sounds kind of reasonable. Except that I think I have to remove > pm-utils then I just cannot accept that the hibernate/resume > process becomes as bloated as a full shutdown/reboot. No, that's just insane on a laptop, pm-utils is much more useful IMHO. Do you want a laptop that doesn't hibernate at all? Manage the updates yourself when you've got time or when you're doing something else. > > Neither bugs would necessarily be RC - it all depends on whether > > there is data loss or some other reason for such severity. > > OK, I understand that I have opened a couple of bugs which will have > to be downgraded a bit. You could also seek clarification of the package descriptions to make it clearer that unattended-upgrades is more commonly found on a server than a laptop. (Unless it's a laptop with a faulty battery and is largely used as a desktop anyway.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp0CtjW7qXcZ.pgp Description: PGP signature
Re: packages with hook interfaces and no documented hook policy
Neil Williams writes: > Different package objectives. cron-apt may be what you are actually > thinking of. Even then, I wouldn't use cron-apt on a laptop. Well, I do like security updates to just be there and I don't like to do sysadmin tasks. So I want some sort of automated package upgrades. I used to have just a "apt-get update && apt-get upgrade" cron job. But unattended-upgrades provided a few nice features I wanted, like the ability to restrict sources and packages are included in the automated upgrade. Will check out cron-apt, but I still don't see why unattended-upgrades should mess with hibernation. Even less so if it is intended for servers, which should never hibernate at all. > You could also seek clarification of the package descriptions to make > it clearer that unattended-upgrades is more commonly found on a server > than a laptop. (Unless it's a laptop with a faulty battery and is > largely used as a desktop anyway.) Sorry, I just don't see that. There's nothing here indicating that this package isn't suitable for any class of system: Description: automatic installation of security upgrades This package can download and install security upgrades automatically and unattended, taking care to only install packages from the configured APT source, and checking for dpkg prompts about configuration file changes. . This script is the backend for the APT::Periodic::Unattended-Upgrade option. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkqz6zbq@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
On Mon, Jan 17, 2011 at 2:35 PM, Bjørn Mork wrote:
> James Vega writes:
>> On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork wrote:
>>> My claim is that packages like unattended-upgrades and pm-utils are
>>> completely unrelated to each other, and that a hook in
>>> unattended-upgrades which breaks pm-utils by preventing hibernation is a
>>> critical bug, even if the breakage seems intentional.
>>
>> Is this just a case of an upgrade pulling in a new kernel, which could
>> cause pm-hibernate to disallow a hibernate[0]?
>
> No, that one I can understand. If the kernel changes, then you have to
> reboot before you can hibernate. But that is part of the kernel upgrade
> hooks and not really related to how the kernel is upgraded.
>
>
> This is what I find unacceptable about unattended-upgrades:
>
> case "${1}" in
> hibernate)
> python
> /usr/share/unattended-upgrades/unattended-upgrade-shutdown
> ;;
>
The bug[0] which was the impetus behind adding that script seems sound
to me. Delaying hibernation to ensure that the system isn't left in an
unbootable state is a fair trade-off.
[0]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/191514
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktink6kkal1fbntpxiz9bpxdrlrg7y_o8rgowx...@mail.gmail.com
Re: Why is help so hard to find?
Hi, Ian:
On Monday 17 January 2011 13:32:33 Ian Jackson wrote:
> Don Armstrong writes ("Re: Why is help so hard to find?"):
> > A possible hack would be to have insserv ignore any initscripts which
> > are conffiles which when run without options exit with zero status.
>
> It could probably safely invoke them with:
> /etc/init.d/obsolete --fail-please
>
> > But this probably has some ugly consequences which aren't totally
> > obvious to me right this second.
>
> Yes. Surely the right thing to do at this stage of the release cycle
> is to tone down the extent to which we are pushing insserv, and to
> revisit this questions after the release.
To that extreme I proposed a change in the to the postinst message[1]. Don't
sure if it will come across since the bug is already closed.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185#24
Cheers.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101172152.47949.jesus.nava...@undominio.net
More information about Archive Keys and recovery from comprimised keys
Hi all, I wouldn't stress the FTPmasters directly with my question and hope this is the right list. Is there any additional information beside http://ftp-master.debian.org/keys.html regarding keyhandling in Debian and what to do if key(s) (one or both) will be compromised? What are the rules for such a disaster? I have a small Debian package server with "reprepro" and one archive key and I would learn from Debian how I could minimize the damage if the key become lost or public. Thank you, Erik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d34af04.20...@gmx.de
Re: packages with hook interfaces and no documented hook policy
Hi,
On 2011-01-17, James Vega wrote:
>> This is what I find unacceptable about unattended-upgrades:
>> case "${1}" in
>> hibernate)
>> python
>> /usr/share/unattended-upgrades/unattended-upgrade-shutdown
>> ;;
> The bug[0] which was the impetus behind adding that script seems sound
> to me. Delaying hibernation to ensure that the system isn't left in an
> unbootable state is a fair trade-off.
the question here might be if it's fair to delay hibernation or if it should
abort hibernation to happen at all, no?
The user is left without any feedback while the unattended-upgrades step is
supposed to terminate at some point.
(FWIW, I feel critical is an inflated severity for this issue. It might be
worth fixing, though, albeit I guess that pm-utils doesn't provide the
infrastructure to provide failure causes back to the user? In the link you
gave there's also [1].)
Kind regards
Philipp Kern
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/191514/comments/13
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnij9cee.j41.tr...@kelgar.0x539.de
Trying to install Oracle9i R2 on
Hello, I'm trying to install Oracle9i Database server R2 on this Debian distibution: Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny1) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 01:53:57 UTC 2010 Running the Oracle Installer, show this error: oracle@alborhp-madrid:~/soft/CD1$ Initializing Java Virtual Machine from /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/java. Please wait... /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory I've created a simbolic link from my libstdc++-* to the name requested by the installer. But now the installer don't say nothing and die after some time. I'm new with Debian. Would to help me? Many thanks! Best regards Arturo -- Arturo Gutiérrez Gómez Formador/Consultor Tecnologias Oracle Oracle DBA Certified Professional OCP [7.3-10g] Oracle Real Application Clusters Certified profesional Movíl 61 64 70 190 * * * * * * / / -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d34ae90.1010...@googlemail.com
Bug#610356: ITP: lastfmlib -- An implementation of the Last.Fm Submissions Protocol v1.2
Package: wnpp Severity: wishlist Owner: Andreas Noteng * Package name: lastfmlib Version : 0.4.0 Upstream Author : Dirk Vanden Boer * URL : http://code.google.com/p/lastfmlib/ * License : GPL-2 Programming Lang: C++ Description : An implementation of the Last.Fm Submissions Protocol v1.2 lastfmlib is a C++ library that provides an implementation of the Last.fm Submissions Protocol v1.2. It allows you to scrobble your tracks on Last.fm Inclution of this package in Debian, will make it possible to rebuild Mediatomb with Last.FM scrobbling support. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117202128.15117.7525.reportbug@andreas-debian
Re: Trying to install Oracle9i R2 on
On Mon, Jan 17, 2011 at 10:03:12PM +0100, Arturo Gutierrez wrote: > Hello, > I'm trying to install Oracle9i Database server R2 on this Debian > distibution: > Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny1) (da...@debian.org) > (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu > Nov 25 01:53:57 UTC 2010 > > Running the Oracle Installer, show this error: > oracle@alborhp-madrid:~/soft/CD1$ Initializing Java Virtual Machine from > /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/java. Please wait... > > /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/i386/native_threads/java: > error while loading shared libraries: > libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file > or directory [...] This library file was part of the unofficial 'gcc 2.96' which Red Hat released some years ago (RHL 7.3 / RHEL 2.1). I don't think it was included in any Debian release, but you might be able to install it from an RPM using 'alien'. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117214612.gf3...@decadent.org.uk
Re: packages with hook interfaces and no documented hook policy
On 17.01.2011 20:54, Bjørn Mork wrote: > > OK, sounds kind of reasonable. Except that I think I have to remove > pm-utils then I just cannot accept that the hibernate/resume process > becomes as bloated as a full shutdown/reboot. > That sounds like the wrong way around. If you don't want unattended-upgrades to run on suspend/hibernate, then uninstall the unattended upgrades package or read the pm-suspend man page how to disable the unattend-upgrades hook (hint: rm /etc/pm/sleep.d/10_unattended-upgrades-hibernate , it's a conffile, so dpkg will preserve the removal of this file). Also; You said, the hook breaks suspend/hibernate. I don't agree this is the case. If there is no upgrade running, the hook will exit immediately. If there is an upgrade running, the hook simply blocks until the upgrade has finished. Suspend/Hibernate is still not 100% reliable, so this is probably a safe choice. There is indeed a problem though, that pm-utils has no API for long running jobs and communicating that pack to the caller (in most cases gnome-power-manager) But again, if you don't like the hook, disable it. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#610358: ITP: pagekite -- Run public servers without reconfiguring firewalls or routers. Easy http, https and ssh tunnels to a public frontend.
Package: wnpp Severity: wishlist Owner: Hrafnkell Eiriksson * Package name: pagekite Version : 0.3.10 Upstream Author : Bjarni Runar Einarsson * URL : http://pagekite.net/downloads/ * License : AGPL Programming Lang: Python Description : Run public servers without reconfiguring firewalls or routers. Easy http, https and ssh tunnels to a public frontend. PageKite removes the need to reconfigure firewalls or routers in order to run a public server from home or your mobile devices. . Pagekite.py is the Python implementation of the PageKite remote web front-end protocol, implementing a tunneled reverse proxy which allows you to run public HTTP or HTTPS servers on machines without direct connectivity to the Internet. Other protocols (SSH etc.) are partially supported as well. . This package implements both ends of the tunnel and is compatible with the (optional) front-end service provided by http://pagekite.net/. . Pagekite is distributed under the terms of the Affero General Public License. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117213701.23084.86660.reportbug@myther-main
Re: Can insserv made better?
On Mon January 17 2011 11:55:24 Gunnar Wolf wrote: > As it was already pointed out to you, such occurences were due to > incomplete dependencies declared in the initscripts - And as such, > they were bugs in the respective packages. The right way to fix them > is to provide the needed dependency information in the startup > scripts. Were Debian to replicate all of the dependencies implicit in the Snn/Knn approach it would require enormous numbers of dependencies, most of which have no value for most users. OTOH, to omit any of those dependencies could cause a failure on some systems. You simply do not know and cannot know what dependencies are out in the world in the Snn/Knn approach, and which can safely be removed on any given system. That is why sysadmins should be able to decide if and when to enable insserv based on accurate and unbiased information. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101171427.43947.mgb-deb...@yosemite.net
Re: packages with hook interfaces and no documented hook policy
On Mon, Jan 17, 2011 at 08:19:01PM +, Neil Williams wrote: > > Huh? I use unattended-upgrades on my laptop as a way to keep it > > updated without having to create the cron job myself. But I don't > > expect it to force itself to run at times where I want to the laptop > > to sleep. > > Use cron-apt instead? unattended-upgrades is more commonly used on > servers with a PSU attached. > > I wouldn't ever use any form of automated upgrades on a laptop - no > guarantee the laptop has a connection even if it is on. > > I'm afraid this comes down to error between chair and keyboard. Most > people just wouldn't put those packages on a laptop. sudo LC_ALL=C aptitude why unattended-upgrades i gnome Depends software-center i A software-centerDepends python-aptdaemon (>= 0.11+bzr342) i A python-aptdaemon Depends python-software-properties i A python-software-properties Depends unattended-upgrades Yes, this is a laptop answering. I did not install unattented-upgrades myself. NB: this may be a bug in any of the last three packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117223643.ga3...@oberon.tenebreuse.org
Re: Trying to install Oracle9i R2 on
Hi, On Montag, 17. Januar 2011, Ben Hutchings wrote: > This library file was part of the unofficial 'gcc 2.96' which Red Hat > released some years ago (RHL 7.3 / RHEL 2.1). I don't think it was > included in any Debian release, but you might be able to install it > from an RPM using 'alien'. http://snapshot.debian.org/package/gcc-2.96/ cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Why is help so hard to find?
On Mon January 17 2011 11:46:05 Gunnar Wolf wrote: > But given that nobody has stepped up to package Trinity > for Debian, I can only assume KDE4 is good enough for them. Trinity is packaged for Debian[1]. The problem is that KDE SC quite unnecessarily took over the KDE package namespace, making upgrades from Lenny to Squeeze unnecessarily difficult. --Mike Bird [1] http://trinity.pearsoncomputing.net/debian_installation.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101171444.31862.mgb-deb...@yosemite.net
Re: Why is help so hard to find?
Mike Bird dijo [Mon, Jan 17, 2011 at 02:44:31PM -0800]: > > But given that nobody has stepped up to package Trinity > > for Debian, I can only assume KDE4 is good enough for them. > > Trinity is packaged for Debian[1]. The problem is that KDE SC > quite unnecessarily took over the KDE package namespace, making > upgrades from Lenny to Squeeze unnecessarily difficult. > > --Mike Bird > > [1] http://trinity.pearsoncomputing.net/debian_installation.html ...Also the official Google Chrome browser is packaged for Debian (using their infamous "deb http://dl.google.com/linux/deb blah" line). I have some software I use but don't want to upload to Debian (as it lacks the quality my Debian work requires) available at http://www.iiec.unam.mx/apt/. That does not mean Debian has to accomodate it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117230116.gd23...@gwolf.org
Re: Trying to install Oracle9i R2 on
On Mon, Jan 17, 2011 at 11:43:27PM +0100, Holger Levsen wrote: > Hi, > > On Montag, 17. Januar 2011, Ben Hutchings wrote: > > This library file was part of the unofficial 'gcc 2.96' which Red Hat > > released some years ago (RHL 7.3 / RHEL 2.1). I don't think it was > > included in any Debian release, but you might be able to install it > > from an RPM using 'alien'. > > http://snapshot.debian.org/package/gcc-2.96/ Wow, that's a horrible mess (debian/CVS and debian/bugs in the source package). And it was built for ia64 only. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117230910.gg3...@decadent.org.uk
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Le Sun, Jan 16, 2011 at 01:17:23PM +0100, Christoph Anton Mitterer a écrit : > > I've also wondered whether it is allowed (or not), when having a Files > paragraph, that contains the verbatim license (not referring to a > standalone License tag), e.g.: > >Files: * > >License: FOO > > This is my wonderful license. > ...to omit the first line synopsis: > >Files: * > >License: > > This is my wonderful license. > ... and if so, whether a " " should follow the "License:" or not. Le Sun, Jan 16, 2011 at 01:19:40PM +0100, Christoph Anton Mitterer a écrit : > Oh, and I've also would like to see the "X-" on personal license short > names. Dear Christoph, licenses short names that are not specified in the DEP are considered private in the scope of the document being parsed. This means that FOO, or X-FOO, is not guaranteed to be the same license in two different copyright files. For that reason, I think that an X- prefix is not useful. Also, to reduce complexity of the parsing, it is required to pick a different short name for each license that is documented in the copyright file. If you encounter a license that is very rare and has no usual short name, pick one name that makes sense to you. As explained above, this will not go beyond the scope of your copyright file anyway. Would the following change clarify the DEP in regard to your first question ? --- a/dep5.mdwn +++ b/dep5.mdwn @@ -244,8 +244,9 @@ applies to all files and lists all applicable copyrights and licenses. alternatives (see *Short names* section for a list of standard abbreviations). If there are licenses present in the package without a standard short name, an arbitrary short - name may be assigned for these licenses. These arbitrary names - are only guaranteed to be unique within a single copyright file. + name must be assigned for these licenses. These arbitrary names + are only guaranteed to refer to the same license within a single + copyright file. * Remaining lines: if left blank here, the file **must** include a stand-alone **`License`** paragraph matching each license short name listed on the first line (see the *Standalone License Paragraph* Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117233646.ge3...@merveille.plessy.net
Re: Best practices for development workstations
Hi Manoj, Could you please briefly outline (or may be you have it described somewhere already) the setup of your SELinux-fortified building environment? I am still boiling the idea of securing/monitoring build environment, issue I have raised in "securing/monitoring Debian devel environment" thread thank you in advance! On Mon, 29 Mar 2010, Manoj Srivastava wrote: > > 2b. Xen, KVM, qemu, or VirtualBox > I have a desktop (and a separate laptop) both running Sid. I > have a virtual machine that runs SELinux in strict mode for package > building on the desktop. I do not test on the build virtual machine; > most of my testing is done on my desktop. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117235804.ga18...@onerussian.com
Re: Trying to install Oracle9i R2 on
On Tue, Jan 18, 2011 at 5:03 AM, Arturo Gutierrez wrote: > Hello, > I'm trying to install Oracle9i Database server R2 on this Debian > distibution: > Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny1) (da...@debian.org) (gcc > version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 > 01:53:57 UTC 2010 > > Running the Oracle Installer, show this error: > oracle@alborhp-madrid:~/soft/CD1$ Initializing Java Virtual Machine from > /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/java. Please wait... > > /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/i386/native_threads/java: > error while loading shared libraries: > libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or > directory > > I've created a simbolic link from my libstdc++-* to the name requested by > the installer. > But now the installer don't say nothing and die after some time. > > I'm new with Debian. > Would to help me? > I've installed oracle 9iR2 on debian 3.1, http://blogold.chinaunix.net/u/7667/showart_65291.html (in Chinese, but you may need command only). But for some package such as gcc-2.95 have already removed from current debian stable. you may not install oracle 9iR2 on Debian lenny. BTW: you can copy oracle 9.2 binary from other linux box(such as redhat Linux ) to Debian, it still works. -- Liang Guo http://bluestone.cublog.cn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=hz6637y8hxcdjticvaedr2kpo-x-s9wyso...@mail.gmail.com
before starting ...
Hi, 1st place, sorry by my english, i expected be understood :-) i wanna be future DM so have to get some things before right!?, i read it many docs before start like debian policy, the machine, and the others and now have to always tab the guide-maint, to see all steps, have the gpg sign key at subkeys.gpg.net and made account at mentors but have some questions to prepare the build enviroment. 1. i have amd64 debian installed in the laptop, what's happend here if i adopt the 1st package to start? it's will be created only for amd64 or have to install ia32 to mantain the packages ori into i386? 2. i'm suscribe to debian-devel, debian-amd64, debian-mentors, and others like security and user but in 3 1st list where i ask to obtain help specifically for build package? or packages keeping made in arch orig extrict? 3. if i like some orphaned package, to start mantain and the upstream author won't will be devel , and it's wrote in C can i do this options? 3.1 can't continues upload the package because for me no exist more new versions to packages and have to select other ones 3.2 i can rewrite in other language for example python, build and upload again, and in this time keep existing or have for better secure enviroment have my amd64 system and virtualize a machine as i386 and do the builds into? thanxs for advice cheers Tony
Re: packages with hook interfaces and no documented hook policy
Michael Biebl wrote: > Also; You said, the hook breaks suspend/hibernate. I don't agree this is the > case. If there is no upgrade running, the hook will exit immediately. > If there is an upgrade running, the hook simply blocks until the upgrade has > finished. Suspend/Hibernate is still not 100% reliable, so this is probably a > safe choice. ... unless the system is being suspended because it is critically low on battery, and is going to crash and lose the user's work and need a fsck otherwise. Suspend may not be 100% reliable on all hardware or in all circumstances, but that is not a good excuse to make it significantly less reliable, really. -- see shy jo signature.asc Description: Digital signature
Re: Trying to install Oracle9i R2 on
Arturo Gutierrez wrote: > /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/i386/native_threads/java: > error while loading shared libraries: > libstdc++-libc6.1-1.so.2: cannot open shared object file: No such > file or directory Fortunately this library is still available in the archive. http://archive.debian.net/en/woody/i386/libstdc++2.9-glibc2.1 The needed package is libstdc++2.9-glibc2.1 and is in this file: libstdc++2.9-glibc2.1_2.91.66-4_i386.deb Installing that should install the missing libstdc++-libc6.1-1.so.2 shared library. It was always needed to run Red Hat binaries. Download the file from one of the mirror sites listed. Then install it using dpkg. dpkg -i libstdc++2.9-glibc2.1_2.91.66-4_i386.deb > I've created a simbolic link from my libstdc++-* to the name > requested by the installer. > But now the installer don't say nothing and die after some time. You should remove the symlink. Then install the package. > I'm new with Debian. Would to help me? For future help the debian-u...@lists.debian.org mailing list would be a better place to ask these types of questions. Please ask future questions about using Debian there. Good luck! Bob signature.asc Description: Digital signature
Re: packages with hook interfaces and no documented hook policy
On 2011-01-17, Jean-Christophe Dubacq wrote: > On Mon, Jan 17, 2011 at 08:19:01PM +, Neil Williams wrote: >> > Huh? I use unattended-upgrades on my laptop as a way to keep it >> > updated without having to create the cron job myself. But I don't >> > expect it to force itself to run at times where I want to the laptop >> > to sleep. >> Use cron-apt instead? unattended-upgrades is more commonly used on >> servers with a PSU attached. >> I wouldn't ever use any form of automated upgrades on a laptop - no >> guarantee the laptop has a connection even if it is on. >> I'm afraid this comes down to error between chair and keyboard. Most >> people just wouldn't put those packages on a laptop. > sudo LC_ALL=C aptitude why unattended-upgrades > i gnome Depends software-center > i A software-centerDepends python-aptdaemon (>= 0.11+bzr342) > i A python-aptdaemon Depends python-software-properties > i A python-software-properties Depends unattended-upgrades > > Yes, this is a laptop answering. I did not install unattented-upgrades > myself. > > NB: this may be a bug in any of the last three packages. unattended-upgrades needed manual configuration to be activated on a machine, though. So the mere presence of the package shouldn't block any hibernation. Quoting its README: | This script can install security upgrades automatically and | unattended. However, it is not enabled by default. Most users | enable it via the Software Sources programm (available in | System/Administration), which has a simple radiobutton in the UI | for enabling unattended upgrades. | | If you would prefer to enable it from the command line, run | "sudo dpkg-reconfigure -plow unattended-upgrades". Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnijae7l.k0k.tr...@kelgar.0x539.de
Re: before starting ...
Tony Peña writes: > Hi, > 1st place, sorry by my english, i expected be understood :-) > > i wanna be future DM so have to get some things before right!?, i read it > many docs before start like debian policy, the machine, and the others > and now have to always tab the guide-maint, to see all steps, have the gpg > sign key at subkeys.gpg.net and made account at mentors You probably should ask those kind of question on the debian-mentor, not here. > > but have some questions to prepare the build enviroment. > > 1. i have amd64 debian installed in the laptop, what's happend here if i > adopt the 1st package to start? it's will be created only for amd64 or have > to install ia32 to mantain the packages ori into i386? Maintainer have to build the package for one architecture before uploading because there are so many of then. Then the Debian autobuilder will build it for all other "interested" arch. If there is a problem on a specific arch, then you will have to try to build it for this arch and look what append. > 2. i'm suscribe to debian-devel, debian-amd64, debian-mentors, and others > like security and user but in 3 1st list where i ask to obtain help > specifically for build package? or packages keeping made in arch orig > extrict? debian-mentor is the place for asking beginner question. > 3. if i like some orphaned package, to start mantain and the upstream author > won't will be devel , and it's wrote in C can i do this options? >3.1 can't continues upload the package because for me no exist more new > versions to packages and have to select other ones Main work for a debian maintainer consist in packaging the software. Some software are feature complete, and need no more development, but this do not mean they must disappeared. So you can That say if you don't know C, you will have problem to fix a security hole or any bug, even more if upstream development is dead. Learning some C will be a very good thing. >3.2 i can rewrite in other language for example python, build and upload > again, and in this time keep existing This is rally creating a new software, a clone of the first one. This is a more difficult things to do than it may seem, and you should name it differently than the old software. And this is upstream development, that should be preferably made outside of Debian, and should be included in Debian only when it will be mature enough. > or have for better secure enviroment have my amd64 system and > virtualize a machine as i386 and do the builds into? If there is something specific in your package with regard to i386. Otherwise using pbuilder/cowbuilder or something like that for finals building of your package might be a good idea, but you could use an amd64 as well than a i386 chroot. -- Rémi Vanicat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739oqadxm@debian.org
HOWTO: Source a common shell script between DEBIAN/config and DEBIAN/preinst
Given that i was told that you can deterministically determine which
file would run first DEBIAN/control _or_ DEBIAN/preinst, I have this
following query.
I want to source a common file between these two scripts to ensure
that if the package cant automatically detect sane values, it prompt
the user for input as the last resort. The values given itself are
trivial in nature, but if not done correctly would make the system
unusable by locking all the users out of the machine.
When i build a test package, called test and try to install it
I get the following output
dpkg -i test_0.1_all.deb
(Reading database ... 70118 files and directories currently installed.)
Unpacking test (from test_0.1_all.deb) ...
/var/lib/dpkg/tmp.ci/config: line 5: ./test: No such file or directory
dpkg: error processing test_0.1_all.deb (--install):
subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
test_0.1_all.deb
find ./DEBIAN/ -name "*" -print -exec cat '{}' \;
gives
./DEBIAN/test
function sayhello () { echo "(a)$#"; echo "(b) ${1}"; }
echo "file sourced"
./DEBIAN/control
Package: test
Version: 0.1
Section: base
Priority: optional
Architecture: all
Depends: bash,debconf
Maintainer: test team
Description: test package hai je
./DEBIAN/postinst
# Source debconf library.
. /usr/share/debconf/confmodule
. test
sayhello "sekon:postinst" "ohai"
./DEBIAN/config
#!/bin/sh -e
# Source debconf library.
. /usr/share/debconf/confmodule
. ./test
sayhello "sekon:config" "ohai"
./DEBIAN/preinst
#!/bin/bash
# Source debconf library.
. /usr/share/debconf/confmodule
. test
sayhello "sekon:preinst" "ohai"
Also, if i place the test script in $TEMPDIR/tmp/test and then build
and try to install the package i get
/var/lib/dpkg/tmp.ci/config: line 5: /tmp/test: No such file or directory
dpkg: error processing test_0.1_all.deb (--install):
subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
test_0.1_all.deb
Am i doing anything wrong here ?? searching for "debian control files
source scripts" is of very little utility.
thank you,
have a great day
Harish Badri Nath
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinn5dtrtbk_wqwwzqdhqwrrko2ous2ny5n4v...@mail.gmail.com
Re: HOWTO: Source a common shell script between DEBIAN/config and DEBIAN/preinst
Hi, your questions are probably better answered on debian-ment...@lists.debian.org. On Tue, 18 Jan 2011, harish badrinath wrote: > Given that i was told that you can deterministically determine which > file would run first DEBIAN/control _or_ DEBIAN/preinst, I have this > following query. You meant DEBIAN/config (and not control). This information is true but why do you care about the preinst ? The config script will be called before the "postinst" and that's all that usually matters. > I want to source a common file between these two scripts to ensure > that if the package cant automatically detect sane values, it prompt > the user for input as the last resort. The "DEBIAN" directory is for meta-information, it's definitely not a good place to store a shell library that shall be shared between a config script and a preinst script. > The values given itself are > trivial in nature, but if not done correctly would make the system > unusable by locking all the users out of the machine. When do you expect to use those values? Usually we use values to update a configuration file and we do that in the postinst. Without the configuration file the service/program is inactive and should definitely not lock all users out of the machine. > ./DEBIAN/preinst > #!/bin/bash > # Source debconf library. > . /usr/share/debconf/confmodule > . test > > sayhello "sekon:preinst" "ohai" You have no guaranty that debconf is available when the preinst is run. You should not use debconf as if it was there for sure. Note however that if you run debconf here, it will execute the config script if it has not yet been run. (Your log showed the config script being executed) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118075243.gb31...@rivendell.home.ouaza.com
Re: packages with hook interfaces and no documented hook policy
On 18/01/2011 07:53, Philipp Kern wrote: > | This script can install security upgrades automatically and > | unattended. However, it is not enabled by default. Most users > | enable it via the Software Sources programm (available in > | System/Administration), which has a simple radiobutton in the UI > | for enabling unattended upgrades. I do understand that and of course I know it does not work. I was merely suggesting that the conflict with pm-utils was not the answer. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d35482a.90...@free.fr
