Re: Check whether fsck would run

also sprach h...@shaw.ca [2014-12-14 05:07 +0100]: > There's an option for that: > > fsck -N -T > > (don't show Title at startup) This shows the fsck calls for all devices, not only those that would need a routine check. -T makes no difference, other than omitting the first line (version). --

Re: Check whether fsck would run

There's an option for that: fsck -N -T (don't show Title at startup) On 13/12/14 07:27 AM, Scott Schaefer wrote: On 12/13/2014 08:56 AM, 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

Re: one package altering other package's postrm

Hi! On Sat, 2014-12-13 at 23:09:08 +0100, Alexandre Detiste wrote: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? This would be just wrong and unnecessary. This is not the prerm case in

Re: one package altering other package's postrm

Alexandre Detiste writes: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? > This is needed to avoid that /etc/cron.allow & /etc/cron.deny disapears > when cron is purged but systemd-cron still needs those. (from v1.5.1) > In

Re: one package altering other package's postrm

On Dec 13, Alexandre Detiste wrote: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? Ugly, but sometimes there is no other option. I am quite sure that I had to do this once or twice in my packages and no adverse effects have

one package altering other package's postrm

Hi, Would it be OK / ugly / forbiden to do a "rm -f /var/lib/dpkg/info/cron.postrm" in systemd-cron preinst script ? This is needed to avoid that /etc/cron.allow & /etc/cron.deny disapears when cron is purged but systemd-cron still needs those. (from v1.5.1) In http://anonscm.debian.org/cgit/pkg

Re: Can/should we have an efi/efi-any platform architecture?

Quoting Joachim Breitner (2014-12-12 13:55:24) > Am Freitag, den 12.12.2014, 12:07 + schrieb Wookey: >> +++ Sebastian Reichel [2014-12-11 21:25 +0100]: >>> How about building for "arch: any" and adding a build dependency on >>> a new "efi-support" package, that is only available for >>> archi

Bug#773049: ITP: libsoldout -- libsoldout is a library implementing a parser for the markdown language

Package: wnpp Severity: wishlist Owner: Massimo Manghi * Package name: libsoldout Version : 1.3 Upstream Author : Natacha Porté * URL : http://fossil.instinctive.eu/libsoldout/home * License : BSD Programming Lang: C Description : libsoldout is a libra

Re: Check whether fsck would run

also sprach Scott Schaefer [2014-12-13 16:27 +0100]: > ... but then lists the fs-specific fscks that it would run .. > > [/sbin/fsck.xfs (1) -- /] fsck.xfs /dev/md0 > [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 /dev/sda1 Yeah, for all filesystems. It leaves it up to fsck.xfs and fsck.ext3 to decid

Re: Check whether fsck would run

On 12/13/2014 10:27 AM, Scott Schaefer wrote: On 12/13/2014 08:56 AM, 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. Instead of parsing df -t output, invoking tune2fs

Re: Check whether fsck would run

On 12/13/2014 08:56 AM, 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. Instead of parsing df -t output, invoking tune2fs -l and doing a whole bunch of grep magic, I won

Check whether fsck would run

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. Instead of parsing df -t output, invoking tune2fs -l and doing a whole bunch of grep magic, I wonder if there's a smarter way to find out if fsck