sysutils/gpart: deprecated port, anyone interested?

J. Hellenthal jhell at
Thu Mar 17 14:38:05 UTC 2011

On Thu, 17 Mar 2011 05:33, mandree@ wrote:
> Am 17.03.2011 07:49, schrieb Rainer Hurling:
>> Hey Matthias,
>> thanks for taking this up.
>> Am 17.03.2011 01:09 (UTC+1) schrieb Matthias Andree:
>>> On Wed, Mar 16, 2011 at 08:00:17PM +0100, Rainer Hurling wrote:
>>>> gpart in sysutils/gpart stands for 'guess partitions'. Its an old, but
>>>> very useful tool for repairing partitions. Unfortunately it does not
>>>> work on amd64.
>>> I've added two patches to make it work on amd64, bumped the expiration
>>> date and port revision (to 2), but I'm not sure if it can detect all
>>> relevant partition types yet. It detects my BSD UFS partitions, but not
>>> my Windows 7 NTFS partitions, and it would probably also need ZFS
>>> detection.
>> I can confirm that it builds and install on amd64 again.
> Sure enough - I'd tested that on my amd64 Tinderbox. :)
>> Newer partition types are not known to sysutils/gpart. For me it is a
>> useful tools to repair (older) servers with Win2000 or something like
>> that. In some cases it was the only tool, which was able to reconstruct
>> destroyed partition tables.
> Sounds reasonable.  Could you test the amd64 version on some of the disks and 
> see if it guesses reasonable partition tables, and finds existing partitions, 
> too?  I don't trust it yet, as there has been quite a bit of C integer data 
> type abuse in the source code when, even ten years ago, 
> /usr/include/inttypes.h existed... although the source code isn't all bad.
> I've fixed more than one "unsigned long" instance to uint32_t but didn't have 
> time yet to look deeper to see, for instance, if all the block structures are 
> 2^N (for N typically 9) bytes tall.
> An alternative appears to be <> 
> (GPL'd), but I haven't looked closer, but the list of supported file systems 
> is longer and comprises newer NTFS and exFAT, but not zfs/zpool either.
>>>> If someone is willing to update the port: I have an original tarball
>>>> 'gpart-0.1h.tar.gz'. It would need a new home ;-)
>>> Is that tarball different from what's on sunsite and currently fetched
>>> by the port?
>> I compared it against my old distfile and all seems fine:
>> ls -l old/gpart-0.1h.tar.gz new/gpart-0.1h.tar.gz
>> 52357 15 Feb 19:24:06 2001 old/gpart-0.1h.tar.gz
>> 52357 15 Feb 19:24:06 2001 new/gpart-0.1h.tar.gz
>> SHA256 (old/gpart-0.1h.tar.gz) =
>> b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3
>> SHA256 (new/gpart-0.1h.tar.gz) =
>> b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3
>> The updated port is still marked as deprecated. Do you plan to change
>> this back?
> Thanks for the comparison.
> What I'd like to see happen for an un-deprecation is a united effort to 
> contact the former maintainer about his plans and situation, and else a 
> coordination of the changes that other distributors may have added, too, so 
> as to create a unified effort.
> Basically we'd need a maintainer for the port and possibly for the upstream 
> code, too, but I don't plan to sign up for yet another maintainership.
> However, I don't have strong feelings about this either way.
> Original author Bcc'd.

Just for reference I did a distfile search for this and it came up in 
quite a few interesting places including fc14 that isn't really that old.

Attached is the result for the search.



  J. Hellenthal
-------------- next part --------------,com_ionfiles/fileid,58/func,download/

More information about the freebsd-ports mailing list