Bug#986709: rsnapshot is stable, not dead

2021-05-28 Thread David Cantrell
Of the 11 open PRs, several are marked as "needs tests", and all but 
three look like new features, not bugfixes. Two of the three bug fixes 
are for rsnapreport, a tool that to be blunt I don't think is very 
important. One is for LVM- and BTRFS- specific issues so is hard for 
people without a very specific configuration to test.


There are three broad themes in the open tickets.

1. help requests, which ought to be on the mailing list.

2. feature requests

3. minor problems with argument parsingin some unusual situations,
   especially when args contain whitespace.

The only one of those themes that is even slightly important is the 
third, and they are mostly unfixable without breaking existing working 
configurations.


Finally, the most recent release is almost completely up-to-date with 
the master branch:


https://github.com/rsnapshot/rsnapshot/compare/HEAD..1.4.3

So what, exactly, is unmaintained about it? Looks to me like it has 
exactly the amount of maintenance that is required for mature software.


--
David Cantrell



Bug#840581: vim-conque: ConqueTerm doesn't appear to load into vim

2016-10-12 Thread David Cantrell
Package: vim-conque
Version: 2.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Having installed the vim-conque package, I start vim:

  $ vim

and then try to start bash within it:

  :ConqueTerm bash

and just get this error:

  E492: Not an editor command: ConqueTerm bash

It looks like a bunch of files got installed in /usr/share/vim-conque,
but they don't seem to get loaded when vim starts.

If having access to the machine would help with debugging then I can
arrange that, I'll just need an ssh public key from you.

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim-conque depends on:
ii  python2.7.9-1
ii  vim-nox [vim-python]  2:7.4.488-7

Versions of packages vim-conque recommends:
ii  vim-addon-manager  0.5.3

vim-conque suggests no packages.

-- no debconf information



Bug#688790: Fixed

2013-07-01 Thread David Cantrell

Thanks, fixed upstream:
  https://github.com/DrHyde/rsnapshot/commit/d15488

--
David Cantrell


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#380226: libparted does not resize NTFS

2007-01-22 Thread David Cantrell
libparted does not resize NTFS at the moment, so it's not the cause of
the problem.  But I'm not sure what you are using libparted with.  What
software are you using that invokes libparted?  Where can I find the
source for it?

-- 
David Cantrell [EMAIL PROTECTED]
Red Hat / Westford, MA



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#380226: libparted does not resize NTFS

2007-01-22 Thread David Cantrell
On Mon, 2007-01-22 at 22:51 +0100, Frans Pop wrote:
 Hello David,
 
 First of all, thank you for your interest in helping solve this.

Apologies for it taking so long.  The GNU parted team has shifted around
a bit in the past year or so.

 On Monday 22 January 2007 22:01, David Cantrell wrote:
  libparted does not resize NTFS at the moment, so it's not the cause of
  the problem.  But I'm not sure what you are using libparted with.  What
  software are you using that invokes libparted?  Where can I find the
  source for it?
 
 Correct. We use ntfsresize to resize the file system. The only thing we 
 need libparted for is to resize the physical partition the NTFS file 
 system is on.
 
 The actual resize operation is done in the following steps:
 - run ntfsresize to determine if the NTFS partition is clean and what the
   range is it can be resized to
 - ask user for new partition/file system size
 - if smaller than current, resize NTFS file system using ntfsresize
 - resize physical partition using libparted
 - resize NTFS file system up to new size of physical partition
 
 This procedure works fine for pre-Vista NTFS partitions.
 With Vista partitions the issue we currently have is that Windows for some 
 reason no longer creates the partition starting on the second sector of 
 the disk and that libparted, because of the current constraints, changes 
 the starting sector of the physical partition which, of course, makes the 
 file system inaccessible.

That's right.  On DOS disk labels, the starting primary partition was
always aligned to sector 0x3F (or 63), but Vista has changed that to
accomodate large disks.  Vista now aligns to sector 0x800 by default
(2048), but it's actually configurable by the administrator.
Unfortunately, it will only present more problems for people like you
and me down the road.  The best we can do is accomodate other operating
systems as much as possible.  See this for more information:

http://support.microsoft.com/kb/923332

 The software we use for this in the installer is a fairly complex beast 
 called partman, which consists of various components. Most of it is 
 scripted, but the interaction with libparted is done through a program 
 called parted_server.

The parted(8) interactive program that comes with GNU parted can do what
you are describing in the above steps.  But you cannot do a partition
resize since resize via parted(8) is intended to resize the filesystem
and partition in one step.  Since libparted lacks NTFS support, we
prevent the user from doing that.

But you can remove the partition and recreate it with a higher end
boundary, which effectively resizes the physical partition for you and
then you can run ntfsresize on that.

When resizing a Vista NTFS partition, be sure to start at sector 2048.
In the parted(8) interactive program, this can be done by specifying
1049kB as the starting location.  See command_line_get_sector() in
parted/ui.c to see how 1049kB is translated to the correct starting
sector.  See do_mkpart() in parted/parted.c to see how to add a
partition using libparted.

I think you could modify you parted_server program to work with these
limitations in mind.

Now, I have made a patch for parted-1.8.2 that will preserve the
starting sector of 2048 on Vista partitions when you are creating the
DOS disklabel.  That should be added to the parted package in Debian for
this to work.

Does any of that help?

 P.S. If you would like to discuss this, feel free to look for me on IRC. I 
 am fjp on #debian-boot on OFTC.

I am dcantrell on FreeNode in #parted and various other places.  Or
kg6cii on AIM.  Email here.

-- 
David Cantrell [EMAIL PROTECTED]
Red Hat / Westford, MA



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]