On 12/13/2014 09:56 PM, martin f krafft wrote:
Holger had the idea to add to molly-guard a check that would require
the sysadmin to manually ack a reboot if fsck would be expected to
run. I like it.
me too :D
Instead of parsing df -t output, invoking tune2fs -l and doing
a whole bunch of g
Ian Jackson writes:
> Guillem Jover writes ("Re: one package altering other package's postrm"):
>> As mentioned before, just add a versioned Breaks against the cron
>> package not supporting that, do not mangle its maintainer scripts.
> ...
>> If using current apt with APT::Get::Purge=true or --p
Guillem Jover writes ("Re: one package altering other package's postrm"):
> As mentioned before, just add a versioned Breaks against the cron
> package not supporting that, do not mangle its maintainer scripts.
...
> If using current apt with APT::Get::Purge=true or --purge, or the
> aptitude TUI a
On Sun, 2014-12-14 at 15:26:37 +, Philip Hands wrote:
> Alexandre Detiste writes:
> > I've sent a one-liner patch, as this put the least work on cron maintainers:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095
> >
> > I guess they can apply it right away, even during the free
On 2014-12-15 15:56, Alexandre Detiste wrote:
>> Having various cron daemon implementations follows from their differing
>> designs,
>> but there isn't much design to merely writing out a file to a specific
>> directory securely.
>
> I agree.
>
> bcrontab does special magic and talk to it's dea
Alexandre Detiste writes:
...
>> then rather than simply removing the postrm, you could edit it, thus:
>>
>> sed -e 's#rm .*/etc/cron.allow#: &#' /var/lib/dpkg/info/cron.postrm
>
> I would do that; that's the least intrusive.
Oh, I pasted the wrong version of that -- it should have been '-i' t
> Another solution proposed by jfs was to factor out the crontab command
> (which writes to /var/spool/cron/crontabs) from src:cron.
That may have trickled down from this mail :-) (should I had CCed you ?)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766053#30
I finally came up with a minim
(Alexandre, sorry for the double reply, I only now noticed that my
webmail client did not reply to the list)
On 2014-12-15 12:12, Alexandre Detiste wrote:
>> On the other hand, if the problem is that the upgrade causes a remove,
>> and then some time later the user is going to tidy up by purging c
> On the other hand, if the problem is that the upgrade causes a remove,
> and then some time later the user is going to tidy up by purging cron,
This is it; everything works fine when you switch packages back and forth;
It's only sometime later when you run a routine "aptitude purge ~c"
that this
9 matches
Mail list logo
