Re: [parted-devel] Call for organization
Hi All, So there seems to some consensus over things. Here's what I conclude: - We setup a Wiki (Trac, At Alioth hopefully!) and put in all this information about our plans for 2.0 there. - Assign a loose set of roles for all those interested in the project. As of now; it seems the most suitable assignments would be: * Leslie as Project Leader * Myself as Infrastructure Lead * David as Maintainer for the 1.x versions * Otavio as Maintainer for the 2.x versions, if he is willing As David mentioned before, all of us can of course wear multiple hats. If someone is unavailable for some task, feel free to take it up. Bringing too much of hierarchy and structure to such a project is counter-productive. As for the question of whether the Infrastructure lead will be applying reviewed patches; I don't mind doing it. There isn't much work for me once we have the infrastructure setup. Maintenance doesn't take a lot of time, and I would be happy to apply these patches and free the developers to work on more code :) All of us are keen to meetup on IRC. Tomorrow is a sunday, and I hope everyone should be able to make it around noon GMT? That seems to a timeslot where all of us are likely to be awake :) Another thing, there is an item I'd like to add to our TODO: support for OS X. This isn't likely to be possible by 2.0; but maybe by 2.5 we should be able to do it. I am in a very good position to work on this; but unfortunately am pressed for time. Anyway, this is something we should consider in the back of our heads; and is definitely not something of very high priority. I'll get in touch with Otavio as to how we can get Trac up and running on Alioth. Cheers, - Anant ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
David Cantrell [EMAIL PROTECTED] writes: I wonder if we really need this, and whether a shell-based interface wouldn't be easier _and_ appeal to a larger audience. pyparted is in use by every distribution that uses anaconda (that includes Fedora, RHEL, CentOS, Yellowdog, rPath, and the list goes on). Gentoo as uses pyparted for the installer project(s). I'm more interested in multiple language bindings to make libparted as usable by other projects as possible. Otavio mentioned this. C++, Perl, and so on (PHP? hahaha, that would be amusing!). Shell bindings, sure. My suggestion of pyparted is (1) it's already there and (2) it's in use in a lot of projects already. I agree that it's need. I'm just wondering if pyparted was _done right_. I'm woring if it need improvements but if it uses the a good way of building bindings that allow us to reuse most of code to build bindings for other languages as well. We do need to think about how to do that otherwise will be a hell to maintain it all on the future. Most of projects that I found doing bindings to other languages uses SWIG for it. What pyparted uses? Iff it doesn't use that kinda of framework I'm not favoured to merge it. 4) Unit testing framework. Otavio's working right on this, but I don't know who will code all the tests. It seems a lot of work. I originally planned to pay someone to do it via bounties, but as long as we haven't received the donation I have applied for, this obviously won't work out. This will be a lot of work. I don't think it's necessary to pay someone. I think once the bulk of the test suite is written, maintaining it will be less difficult. It's the initial getting-over-the-hurdle stage that's hard. So please review the patches sent here to the mailing list about it. I would like to merge it on a day or two. - Getting a rough schedule in place for some 1.9.x test releases Speaking of which, I would like to hand over the lead for 1.x entirely to you. This sort of already happend, but I'd like to assert this. You have done a very good job on this. Thanks. Yeah, it has sort of happened already. So I guess that means I'm the 1.x Maintainer (unless we're picking different terminology). David, I would like to get some description from you what kinda of changes you think are good for 1.x releases. Besides, how we should do to merge changes on the stable-1.8.x branch too. This is need otherwise will be difficult to others know what kinda of fix could be merged there and also how we should proceed to process the patch queue against the branch. What's your idea on that? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
rohit hooda [EMAIL PROTECTED] writes: Regarding the VFS layer...if we write it to where new filesystems can be easily added, we can then pick and choose which ones we want to use external libraries for and which ones we just keep our code for. I would like to work on this ... i.e. for getting the ext3 support in. I have had a few mail exchanges earlier with leslie regarding this ( a long time ago ) but nothing worked out :(. I guess I can may a fresh start now and get things moving on this front. Good. You can start work on it. Please, use a git repository that we can checkout from for it since it'll be a bunch of work. Besides, I'd suggest you to look at stgit for managing your patches since it'll make your life fair easily then using plain git to manage that kinda of branch. That would allow you to send patches for review and change them again without much hassle. So your patches will be resent again for review and so on until we get at merging quality of work. Any one has more comments on that? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
Debarshi Ray [EMAIL PROTECTED] writes: I was also thinking about having multiple language bindings to libparted. My thinking was triggered by the libparted++ project [1][2]. Since Python is a language I have started using from a few months back, I am also interested in the Python bindings part. However, I would like to read up a bit on language bindings before starting to code. Yes, that's good and very useful. I do think that we need it but it should be done right otherwise we'll end spending too much time for little volume of work. The unit-testing framework is also something I am interested in. I have a very elementary knowledge of unit-testing, but being a student I have a lot of time to spare, and I think I can help Otavio in this. Again I have to learn about unit-testing frameworks for C. Perfect. Please review the patches I've sent here and comment on that. I would like to merge them om Monday morning and will do if I don't receive any complains about it before. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] print all --list
On Sat, Dec 09, 2006 at 11:35:56AM -0200, Otavio Salvador wrote: Leslie, I hope I am correct. :-) I think you are correct here. Does someone see this differently? Everything's alright with that. -- gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 http://nic-nac-project.de/~skypher/ pgphurHn7GaPe.pgp Description: PGP signature ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
Anant Narayanan [EMAIL PROTECTED] writes: Iff it doesn't use that kinda of framework I'm not favoured to merge it. I differ on that opinion. libparted is a system-level library and does not deserve to use SWIG at all. The only real way to write python bindings for something like libparted is to write it by hand in plain old C. SWIG is great for some high-level libraries like SQLite or GStreamer, but not for something like libparted. Here's how I see it: we make the one-to-one bindings in plain C, like how it was meant to be done (the python handbook way). The OO bindings can then import that module and can be written in Python itself. Anant, I just don't see why is bad to use something to make our work easier? If it can't be SWIG, no problem, we can choose another tool for it or even write something that grab a description file and write the code for us or something like it. If it'll be one-to-one mapping it shouldn't be impossible to do. Looks very impressive to me the http://www.swig.org/tutorial.html and simple to maintain and extend. Why do you think that is too bad to have swig being used for it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
Hi Otavio, Anant, I just don't see why is bad to use something to make our work easier? I do agree SWIG makes our job easier, but its just too huge a dependency for something low-level like libparted. The bottomline is I am not comfortable with using a third-party tool to generate code for us. I may be a little selfish here; but at Gentoo we take python for granted; and it seems as an overkill to demand SWIG just to be able to generate bindings for libparted. If it can't be SWIG, no problem, we can choose another tool for it or even write something that grab a description file and write the code for us or something like it. If it'll be one-to-one mapping it shouldn't be impossible to do. Now this is something I would love to do. We can come up with a way of defining functions and data types and generating code out of it. But that must be written by us, and we should be in control of what's going on. The build process for the bindings must be transparent and ideally require no more dependencies than libparted does. Looks very impressive to me the http://www.swig.org/tutorial.html and simple to maintain and extend. Why do you think that is too bad to have swig being used for it? Well like I said, it's really not good to depend on SWIG for something this fundamental. Basically we hand over control to SWIG and if something goes wrong with SWIG, we're helpless. It's also a little difficult to debug: we get a segfault and we don't know how to find out whether its a bug in our interface or in SWIG itself. I'm all for making our own code generation system, so we have a definition file that can be uniformly used across all language bindings. It'll take us time, but should be worth it in the long run. Of course, just my 2 cents. I'm not ruling out SWIG; so if everyone feels that's the way to go; no problem. It's just that I've had not-so-good experiences with SWIG before ;) David, a link to pyparted sources would be helpful. How did you go about doing the one-to-one mapping? Cheers, - Anant ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Unavailable until Monday
An IRC meeting is the next big step. I saw tomorrow at noon being a candidate. No can do. I'm away for the next two days. Can we postpone the meeting until then? I'd like the first meeting to be all of us talking together. Sunday will be difficult for me too. Anyday next week will be good for me too. Cheers, Debarshi -- Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
[parted-devel] Deprecate ped[register|unregister]_disk_type
Here is a patch to deprecate ped_[register|unregister]_disk_type in
favour of ped_disk_type_[register|unregister]. I did this since almost
all the functions in libparted have ped_filename as a prefix, which
was not the case here.
The older functions are still there and they throw an exception of
type INFORMATION. We can keep them this way for some time and then
finally remove them in a 2.x release.
What do you think?
Happy hacking,
Debarshi
--
Universities are places of knowledge. The freshman each bring a
little in with them, and the seniors take none away, so knowledge
accumulates.
From e6618e0d7a330c982607a8829c15a35784893947 Mon Sep 17 00:00:00 2001
From: Debarshi Ray [EMAIL PROTECTED]
Date: Sun, 10 Dec 2006 05:42:07 +0530
Subject: Deprecate ped_[register|unregister]_disk_type in favour of
ped_disk_type_[register|unregister]. A simple renaming was done.
---
include/parted/disk.h | 10 --
libparted/disk.c | 32 +---
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/include/parted/disk.h b/include/parted/disk.h
index 286740b..6884020 100644
--- a/include/parted/disk.h
+++ b/include/parted/disk.h
@@ -222,8 +222,8 @@ struct _PedDiskArchOps {
int (*disk_commit) (PedDisk* disk);
};
-extern void ped_register_disk_type (PedDiskType* type);
-extern void ped_unregister_disk_type (PedDiskType* type);
+extern void ped_disk_type_register (PedDiskType* type);
+extern void ped_disk_type_unregister (PedDiskType* type);
extern PedDiskType* ped_disk_type_get_next (PedDiskType* type);
extern PedDiskType* ped_disk_type_get (const char* name);
extern int ped_disk_type_check_feature (const PedDiskType* disk_type,
@@ -248,6 +248,12 @@ extern int ped_disk_get_primary_partitio
extern int ped_disk_get_last_partition_num (PedDisk* disk);
extern int ped_disk_get_max_primary_partition_count (const PedDisk* disk);
+/**
+ * Deprecated functions.
+ */
+extern void ped_register_disk_type (PedDiskType* type);
+extern void ped_unregister_disk_type (PedDiskType* type);
+
/** @} */
/**
diff --git a/libparted/disk.c b/libparted/disk.c
index df6b4f1..8557874 100644
--- a/libparted/disk.c
+++ b/libparted/disk.c
@@ -65,7 +65,7 @@ static int _disk_raw_add (PedDisk* disk,
static PedDiskType*disk_types = NULL;
void
-ped_register_disk_type (PedDiskType* disk_type)
+ped_disk_type_register (PedDiskType* disk_type)
{
PED_ASSERT (disk_type != NULL, return);
PED_ASSERT (disk_type-ops != NULL, return);
@@ -76,7 +76,7 @@ ped_register_disk_type (PedDiskType* dis
disk_types = (struct _PedDiskType*) disk_type;
}
-void ped_unregister_disk_type (PedDiskType* disk_type)
+void ped_disk_type_unregister (PedDiskType* disk_type)
{
PedDiskType*walk;
PedDiskType*last = NULL;
@@ -2248,5 +2248,31 @@ ped_disk_print (PedDisk* disk)
ped_partition_print (part);
}
-/** @} */
+/**
+ * Deprecated function. Use ped_disk_type_register instead.
+ */
+void
+ped_register_disk_type (PedDiskType* disk_type)
+{
+ped_exception_throw (
+PED_EXCEPTION_INFORMATION,
+PED_EXCEPTION_OK,
+_(ped_register_disk_type is deprecated.
+ Use ped_disk_type_register instead.));
+ped_disk_type_register (disk_type);
+}
+
+/**
+ * Deprecated function. Use ped_disk_type_unregister instead.
+ */
+void ped_unregister_disk_type (PedDiskType* disk_type)
+{
+ped_exception_throw (
+PED_EXCEPTION_INFORMATION,
+PED_EXCEPTION_OK,
+_(ped_unregister_disk_type is deprecated.
+ Use ped_disk_type_unregister instead.));
+ped_disk_type_unregister (disk_type);
+}
+/** @} */
--
1.4.2.4
___
parted-devel mailing list
parted-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Deprecate ped[register|unregister]_disk_type
Debarshi Ray [EMAIL PROTECTED] writes: Here is a patch to deprecate ped_[register|unregister]_disk_type in favour of ped_disk_type_[register|unregister]. I did this since almost all the functions in libparted have ped_filename as a prefix, which was not the case here. The older functions are still there and they throw an exception of type INFORMATION. We can keep them this way for some time and then finally remove them in a 2.x release. I think it's right but I would suggest that we make a macro to make easier to warn user. I don't think that an exception is right but we can display a warning while compiling. Other's comments? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Call for organization
David, a link to pyparted sources would be helpful. How did you go about doing the one-to-one mapping? http://people.redhat.com/dcantrel/pyparted/ Regards, Debarshi -- Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
[parted-devel] GNU Parted Official Repository: Changes to '4005d75a05b7d043c285479f73fbb9cecfd92b70'
___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
[parted-devel] GNU Parted Official Repository: Changes to '4005d75a05b7d043c285479f73fbb9cecfd92b70'
___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
[parted-devel] GNU Parted Official Repository: Changes to 'stable-1.8.x'
New branch 'stable-1.8.x' available with the following commits: commit 4005d75a05b7d043c285479f73fbb9cecfd92b70 Author: Debarshi Ray [EMAIL PROTECTED] Date: Fri Dec 8 00:51:06 2006 +0530 Zero sized device is shown as 0.00B and not -0.00kB. commit 53195acd3d8ce1af9188a68a179955cf8e35a938 Author: Otavio Salvador [EMAIL PROTECTED] Date: Wed Dec 6 23:33:52 2006 -0200 libparted/exception.c: Dynamically allow space of exception message. commit 14ff7f8e10ea3034f35c96ec9050561697204f3a Author: Otavio Salvador [EMAIL PROTECTED] Date: Wed Dec 6 22:44:40 2006 -0200 Output a backtrace when catching SEGV_MAPERR or a general SIGSEGV signals. commit 38d2355c2d2550aa0e70a2c8d7df49e8286f7d49 Author: Debarshi Ray [EMAIL PROTECTED] Date: Thu Dec 7 07:31:39 2006 +0530 Implement 'print devices'. commit e4777a8008ef2689451c3e6cd07bd041e6f14f8c Author: Benno Schulenberg [EMAIL PROTECTED] Date: Wed Dec 6 00:00:04 2006 +0100 Add a missing space, and quotes for consistencey commit efe6c7cbe0a6bf397d8a71e38462d93b951b87f9 Author: Benno Schulenberg [EMAIL PROTECTED] Date: Wed Dec 6 00:00:03 2006 +0100 Translate the copyright message, and hard wrap it commit bba602738804241613ea21cd48899beab78d3ab8 Author: Otavio Salvador [EMAIL PROTECTED] Date: Tue Dec 5 14:12:24 2006 -0200 parted/parted.c: Remove useless line break commit b885ee06b10912c6bfa7e788050c5a2f7476150e Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 22:21:12 2006 -0500 Fix the upload script to correctly reference the sig files. commit 2f78207a075556057410ab0549e2d76c84c3f540 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 20:29:24 2006 -0500 Remove ChangeLog, doc/mdate-sh, and doc/texinfo.tex which are all unmanaged files now since they are automatically generated at release time. commit b129e24751b2aaf74e711391841981bdf8272881 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 20:28:34 2006 -0500 Generate a ChangeLog before running the autogen tools since we need a file called 'ChangeLog' to exist when running those tools. commit ae5858d4ea8a90578be9aca4bd2b11f32f467056 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 18:42:05 2006 -0500 Updated NEWS file for the 1.8.1 release. commit 475b9e4e6a26097c1b31aa04a5f66e49eed8e205 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 18:36:49 2006 -0500 Pass git changelog through 'fold -s' to wrap long lines. commit 3c2427a7c6441def3d1e779073e88b70dc3d16f0 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 18:22:44 2006 -0500 Added the --enable-selinux switch for the configure script. If set, it will add -lselinux and -lsepol to the list of libraries to link with. commit 1a3c4bd246942bd3bafe90c3d28409417fa34776 Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 18:18:14 2006 -0500 Rename all old ChangeLog files to ChangeLog.0 since we are using git to store changelog info now. commit 35a96a5c4ea86b3e6ec88ce097440ad351d716db Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 18:08:00 2006 -0500 Check for git before running. Generate a ChangeLog file when making the archive. commit de275c913158391667998f082b70e5c1eac75e7c Author: David Cantrell [EMAIL PROTECTED] Date: Sun Dec 3 17:55:18 2006 -0500 Disable ext2fs resizing, tell user to run resize2fs instead. commit 07712ab07a5beddf8b8c2e7fd7238d42cb174dd1 Author: Leslie P. Polzer [EMAIL PROTECTED] Date: Sat Dec 2 21:43:02 2006 +0100 Updated URL of static parted in docs. commit 7b4eca1969473423aa604d2b56705ac5fbc80e84 Author: Debarshi Ray [EMAIL PROTECTED] Date: Thu Nov 30 08:09:08 2006 +0530 Cleanup _partition_warn_busy, _disk_warn_busy, _partition_warn_loss and _disk_warn_loss. commit d6dda771b80bb99a88c636056393420202488a47 Author: Otavio Salvador [EMAIL PROTECTED] Date: Tue Nov 28 22:26:50 2006 -0200 Proper print when there're no extended partitions, but partition names (patch from Sven Luther) commit 1dc978b56644a2ac54bab87b29aee04f72c6bd65 Author: Otavio Salvador [EMAIL PROTECTED] Date: Tue Nov 28 17:36:03 2006 -0200 libparted/arch/linux.c: initialize task point to please GCC commit cc3d9b962e8a0746a483437f033c43851a49850e Author: Otavio Salvador [EMAIL PROTECTED] Date: Tue Nov 28 17:35:00 2006 -0200 Don't enforce libselinux and libsepol linking when using device-mapper support commit 9fe3e315603f469f86234602f65e2e397950e486 Author: Debarshi Ray [EMAIL PROTECTED] Date: Wed Nov 29 03:43:05 2006 +0530 Warn before mklabel and mkfs. commit fd2b4a0babaa3592911c521be8bf4432f075f3bf Author: Debarshi Ray [EMAIL PROTECTED] Date: Wed Nov 29 00:10:04 2006 +0530 Make mktable aliased to mklabel. commit 8399d4a3db801cfabe33baf55b040072dc365a51 Author: Otavio Salvador [EMAIL PROTECTED] Date: Mon Nov 27 22:06:20 2006 -0200 Fix 'print' command help 'print' command help was missing a new line at end and then breaking the help
[parted-devel] GNU Parted Official Repository: Changes to 'stable-1.8.x'
scripts/release/tarball_upload.sh |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) New commits: commit c6df442f83ceaeeddf0121a28a3c9bd3b91c666d Author: Leslie P. Polzer [EMAIL PROTECTED] Date: Sat Dec 9 10:51:43 2006 +0100 Release script: cannot call return from top level; replaced with exit. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
Re: [parted-devel] Deprecate ped[register|unregister]_disk_type
Distribution vendors then only have to add a -DDEPRECATED_20 to the build of the package to fix it for the time being, and the author of the package is woken up and incited to fix his stuff :) To wake up the programmer using libparted, do you still want to use ped_exception_throw to display an exception of type INFORMATION, or want to use something different? Happy hacking, Debarshi -- Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. ___ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
