On Fri, Jan 21, 2011 at 5:39 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: packages with hook interfaces and no
> documented hook policy"):
>> On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
>> > If you have better suggestions how to solve this
Olaf van der Spek writes ("Re: packages with hook interfaces and no documented
hook policy"):
> On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
> > If you have better suggestions how to solve this problem, I'm happy to
> > hear (and implement) them. Until then
On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
> If you have better suggestions how to solve this problem, I'm happy to
> hear (and implement) them. Until then I would recomment that you run
> the upgrade manually so that you have control over when exactly it
> happens.
An alternative would
On Mon, Jan 17, 2011 at 08:54:12PM +0100, Bjørn Mork wrote:
> Neil Williams writes:
> > On Mon, 17 Jan 2011 18:43:23 +0100
> > Bjørn Mork wrote:
[..]
> 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
On Tue, Jan 18, 2011 at 01:08:36AM -0400, Joey Hess wrote:
> 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 unt
On Tue, Jan 18, 2011 at 10:41 AM, Michael Biebl wrote:
> On 18.01.2011 06:08, Joey Hess wrote:
>> 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 upgra
On 18.01.2011 06:08, Joey Hess wrote:
> 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
>> fi
James Vega writes:
> 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
Yes, its an ugly bug
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
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
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%
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
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
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
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 p
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.
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
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 unus
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, ev
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 i
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 pack
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
22 matches
Mail list logo
