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 attachment 39132 [details] 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 attachment 41807 [details] 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 attachment 42587 [details] 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 attachment 45466 [details] 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 attachment 46619 [details] 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
