Bugzilla Bug 61828

Just requesting an ebuild for gparted, the GNOME alternative to qtparted. If I
have time, I'll make one myself. ;)

well, afaik it's pretty alpha & we need an updated libparted (preferably with
the patch on the gparted homepage) before it can even be considered. Please
open a bug for parted-1.6.12 & make it block this one.

Alright, done.

gparted is now at version 0.0.4.

Created an attachment (id=39132) [edit]
simple gparted-0.0.4 ebuild

Here's a really simple ebuild for gparted 0.0.4 that depends on the parted
1.6.14 ebuild in the blocking bug listed above. It loads up and displays fine,
but I haven't had time to test any actual partition resizing / moving.

If people could help me with testing it, I would greatly appreciate it. :)

I tried the ebuild and worked flawlessly. Why should the KDE users have a
parted-based GUI and the Gnome users don't? LOL

Looking forward to using this instead of Partiton Magic :)

Marcos: I'm glad that my hack-job ebuilds have had some success. ;)

However, could you clarify if you actually used the emerged gparted to resize any partitions? If so, can you also let us know what filesystem type they were?  I just want to verify that someone has actually /used/ the app successfully, since I /still/ haven't had time to test it myself. :P

Just a personal reminder, gparted 0.0.5 is out, with bugfixes, speed increases,
and some sort of internationalization. I'll get around to posting an updated
ebuild sometime soon-ish. ;)

FYI: sys-apps/parted-1.6.15 was added to portage 25 Sep 2004.

I'd be happy to try your ebuild. But i was just wondering, do i have to create
the Manifest etc. myself? I don't want to sound lazy but i'd like to know what
the standard way of doing this is.

Ramon: No harm in asking questions. :)  The standard way (after you've copied
the ebuild to somewhere under /usr/local/portage, or wherever your local
portage tree resides) is to just run "ebuild foo.ebuild digest". That will
generate all the manifest and digest files for you, based on the source files
it has downloaded. If it hasn't downloaded any source files yet, it will
retrieve them, and then make a digest. :)

In any case, I plan to have a 0.0.5 ebuild out shortly, so you might want to
wait a couple of hours for that one. ;)

Created an attachment (id=41807) [edit]
gparted 0.0.5 ebuild

Seems to run alright. I made it depend on at least parted*.15 (as mentioned in
a previous comment), so it should have the latest and greatest parted features.
:)

Well, the 0.0.5 ebuild emerges just fine. I found out i actually had "bad"
partition table and i seem unable to delete a (ext2) partition even when it's
unmounted. Bug or feature? Resizing seems impossible for all partitions

The important thing is, it works and looks pretty slick already :)

Heh, I wouldn't call "no resizing" working. ;)

However, since all of that is supplied to gparted via libparted, that seems to me like it's libparted bugs, not gparted ones. It told me I had an invalid ext2 partition as well, even though the previous version had no problems with it, so I'm inclined to believe there are bugs at work here. ;)

libparted's ext2/3 code isn't really compatible with the newest e2fstools.
Please send mails about this to bug-parted@gnu.org to convince Andrew to fix
this. According to him it's a relative easy fix. But for us mere mortals it'd
take weeks only to understand that code (not even fix it) :P

New (0.0.6) version of GParted out. I'll have an updated ebuild shortly. This
version adds support for reiserfs stuff, but its via progreiserfs (namesys'
alternate reiserfs tools), and there doesn't seem to be an ebuild for that yet.
I'm going to make a bug requesting an ebuild for that, then have this bug be
blocked by that one. Once there's an ebuild for progreiserfs (ie, once I get
around to making one! ;) ), then I'll add a USE flag to gparted's ebuild to
enable optional use of it.

At least, that's my plan. Any comments on it would be appreciated. ;)

bleh, progsreiserfs is horribly broken apparently, so we'll just ignore that
functionality for now.

Graeme, can you be a bit more specific about the problems you encounter when
making an ebuild for progsreiserfs?

thnks!

My work on that is on bug 68854, which references bug 51773. What I discovered
is that at one point, there already were progsreiserfs ebuilds, and they were
discontinued due to instability and lack of maintainence ("But the last one
(0.3.1rc8) is from 12-Dec-2002 - seems to be a dead project.").

Until the Gentoo core developers decide that they wish to reintroduce this
piece of software, it's not really my place to try and force it to be
reintroduced.

I figure that if there's enough demand, then the Gentoo core devs will
reconsider the way its masked now. At that point, we can add it as a dep of
this package. In the mean time, we don't lose any functionality in gparted by
/not/ having it.

On another point, I've noticed that the current reiserfsprogs stable package (
3.6.18) on my system /includes/ a tool called resize_reiserfs, which apparently
does what you'd expect. Perhaps it would be more prudent for gparted to make
use of this, rather than the apparently discontinued progsreiserfs stuff?

i agree, if it was up to me i would've used the 'official' reisersfsprogs.
Hoewever, as you can see at http://www.gnu.org/software/parted/#features this
is not a gparted thingy, but a 'feature' from parted. Thus it seemed logical to
enable it in gparted.

Maybe (most likely) i'll change this in the future, right now i have other
matters  to attend to (like adding ntfs support).

Ahhh, I see how these all fit together now. Parted just gets this feature if
libreiserfs is present on the system when it's being built...

Ok, well, I can't do much about getting progsreiserfs into Gentoo, so this
feature will have to stay off for a while in the Gentoo package. :(

OTOH, if you get a system in place to do ntfs stuff using the commandline
tools, perhaps we could organize doing the same with the reiserfs tools?
Obviously, this'd be quite a bit farther down the road, but still, it might be
a good option. :)

Re: comment 14. I've talked with one of the parted guys, and the synopsis is
that "yes, libparted doesn't support the newest ext2/3 features, no, we don't
have time to fix it at the moment". The other little tidbit of advice I got
about it was this:

"One might convert ext3 to ext2 and disable all features (man tune2fs) then
use parted then convert it back to ext3, features enabled. Running e2fsck
during these shouldn't be forgotten and makeing full backup before doing
these."

So, that'd be yet another commandline-tool hack, which I imagine gparted's
auther isn't really interested in doing, at least at the moment. ;)

Created an attachment (id=42587) [edit]
gparted-0.0.6.ebuild

This is Graeme's 0.0.5 ebuild with a src_unpack function.  The file I
downloaded unpacks to a directory called gparted, not gparted-0.0.6.

Re: <a href="http://bugs.gentoo.org/show_bug.cgi?id=61828#c20">comment 20</a>
It's not strictly necessary to have progsreiserfs on your system when building
parted/gparted. If you install it later, it'll be detected at runtime and used
properly.

Finally a bit of good news =)

Re: comment 22. Ha! Yes, I actually made one myself yesterday, and then I got
caught up in sorting out this reiserfs/parted stuff, and forgot to actually
attach it! My bad! ;)

Re: comment 23: That's excellent news. That means that there doesn't need to be
any specific reference in the Gentoo package... people are free to make a
simple ebuild and install progsreiserfs if they really want that functionality,
and it should Just Work(tm) with their existing (g)parted install.

Now, to get NTFS stuff working. ;)  I may have time to actually help with that,
so I'll see you on IRC.

0.0.6 compiles on amd64. keywords ~amd64 could be added. I did my own ebuild
(saw this one only after). Almost same except you don't need to move directory,
just use :

S="${WORKDIR}/${PN}"

then a regular :
src_compile() {
        econf --prefix=/usr || die "configuration failed"
        emake || die "emake failed"
}

I did not include my ebuild as with mine gparted failed to show in menu. Not
sure why...

New version of gparted available (see: http://gparted.sourceforge.net/news.php)
Lots of improvements (ext2/3, NTFS, reisefs...)

Could anyone of you please make an ebuild?? I just can not of yet ;-)
(I promise i will learn;-))

Thanx in advance

i think copying the 0.0.6 ebuild to gparted-0.0.7.ebuild will work.

That may work, but we'll probably want to massage the dependancies a bit, so
that it will default to install all the necessary commandline tools to get
maximum functionality.

ok, but maybe it's best to add some useflags. Wether they are disabled by
default or not isn't that important as long as the user is able to control
stuff.

Are you on this one Graeme or should i volunteer? ;) 

Heh, I'll do it, if you have a list of all the external programs that gparted
depends on these days. :)

no have plors do it, as an exercise.

Haha, you heard the man, Bart! Get on it! ;)

Created an attachment (id=45466) [edit]
gparted-0.0.7.ebuild

hmm, i guess some explanation would be in place :)
No useflags since that would introduce 3 (and later on even more) useflags to gentoo.
No hard deps on the different progs like ntfsprogs etc.. because that would cause a lot of unnecessary bloat.

If people need support for a specific filesystem they have to merge the proper tool and GParted will detect and use it.

I know it's not perfect, but i think it's the best we can do atm...

Introduction of useflags should not be a problem as they would be local
useflags, specific to given packages. While I'd generally assume someone
wanting a partitioning tool will like lots of functionality, I can imagine
someone not wanting support for stuff they will never touch.

I think local use flags would be the way to go.

Created an attachment (id=46619) [edit]
gparted-0.0.8.ebuild

simple copy of gparted-0.0.7.ebuild.

@Robert:
Personally i don't care that much whether we use useflags or not, but some
people like to limit the amount of useflags gentoo already has.

In this case they're not necessary either since gparted treats the tools like
plugins. If they are installed, gparted uses them. if not, some options will be
unavailable. 
See also http://gparted.sourceforge.net/features.php

why is gparted not officially included in portage?

Good question, Gad! :)

thx!
what about the answer ? :)

Hahahaha, well, I'm not an official Gentoo developer, so I really wouldn't
know. Foser'd probably be the one to ask, but the usual answer (ie, that the
Gentoo developers really busy all the time) is probably the correct one. ;)

Well, i asked foser about it and it seems noone has time to maintain it.

plors is going to maintain it, so you have to poke him about becoming a dev
faster.

plors' devrel-bug is RESOLVED LATER :/ foser, would you mind if i step up as
maintainer till plors is a dev? i like this tool, and it seems that many others
want it in portage too. i was quite astonished when emerge said it can't find
gparted :)

fine with me, plors can be found in IRC if you need him.

I overheard there's an interesting bounty addition not yet in the source ;)

finally in portage: sys-block/gparted