FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 05-10-2008, 04:22 PM
Joel Andres Granados
 
Default this is a pyparted patch for 429185

I'm posting the patch here because I don't know where pyparted discussion list lives

You can find the patch at https://bugzilla.redhat.com/attachment.cgi?id=305028

pyparted needs to search the valid partitions before it returns anything in the py_ped_disk_next_partition function. With this patch we can now save anaconda tracebacks to usb keys. I build pyparted but didn't test the patch extensively.
Comments are greatly appreciated.

PS: For the lazy ones, I'm attaching the patch also.
--
Joel Andres Granados
Red Hat / Brno, Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-12-2008, 02:03 PM
Jeremy Katz
 
Default this is a pyparted patch for 429185

On Sat, 2008-05-10 at 18:22 +0200, Joel Andres Granados wrote:
> I'm posting the patch here because I don't know where pyparted discussion list lives
>
> You can find the patch at https://bugzilla.redhat.com/attachment.cgi?id=305028
>
> pyparted needs to search the valid partitions before it returns anything in the py_ped_disk_next_partition function. With this patch we can now save anaconda tracebacks to usb keys. I build pyparted but didn't test the patch extensively.
> Comments are greatly appreciated.

This significantly changes the semantics of the next_partition() API
call. While there aren't a lot of cases where you care about the
non-active partitions, there are a few.

I think that actually the right fix for the bug is probably something
along the lines of (completely untested)
diff --git a/partedUtils.py b/partedUtils.py
index 573bf4c..22bccb6 100644
--- a/partedUtils.py
+++ b/partedUtils.py
@@ -1362,7 +1362,7 @@ class DiskSet:

drives = []
for d in isys.removableDriveDict().items():
- func = lambda p: not p.get_flag(parted.PARTITION_RAID) and
not p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2", "fat16", "fat32"]
+ func = lambda p: p.is_active and not
p.get_flag(parted.PARTITION_RAID) and not
p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3", "ext2",
"fat16", "fat32"]

disk = self.disks[d[0]]
parts = filter_partitions(disk, func)


You have to ensure that the partition is an active one before doing any
of get_flag or fs_type, etc. Yeah, it's a little ugly, but it's a part
of the API and until we completely replace it, I think we have to live
with it

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-12-2008, 05:51 PM
Joel Andres Granados
 
Default this is a pyparted patch for 429185

Jeremy Katz wrote:

On Sat, 2008-05-10 at 18:22 +0200, Joel Andres Granados wrote:

I'm posting the patch here because I don't know where pyparted discussion list lives

You can find the patch at https://bugzilla.redhat.com/attachment.cgi?id=305028

pyparted needs to search the valid partitions before it returns anything in the py_ped_disk_next_partition function. With this patch we can now save anaconda tracebacks to usb keys. I build pyparted but didn't test the patch extensively.
Comments are greatly appreciated.


This significantly changes the semantics of the next_partition() API
call. While there aren't a lot of cases where you care about the
non-active partitions, there are a few.


I think that actually the right fix for the bug is probably something
along the lines of (completely untested)
diff --git a/partedUtils.py b/partedUtils.py
index 573bf4c..22bccb6 100644
--- a/partedUtils.py
+++ b/partedUtils.py
@@ -1362,7 +1362,7 @@ class DiskSet:

drives = []

for d in isys.removableDriveDict().items():
- func = lambda p: not p.get_flag(parted.PARTITION_RAID) and
not p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2", "fat16", "fat32"]
+ func = lambda p: p.is_active and not
p.get_flag(parted.PARTITION_RAID) and not
p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3", "ext2",
"fat16", "fat32"]

disk = self.disks[d[0]]

parts = filter_partitions(disk, func)


You have to ensure that the partition is an active one before doing any
of get_flag or fs_type, etc. Yeah, it's a little ugly, but it's a part
of the API and until we completely replace it, I think we have to live
with it

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


The argument of waiting for pyparted to be rewritten is a considerable one. If your going to do the whole thing from scratch, why bother adding new stuff to the current one. OTOH, checking for the validity of the partition so in the anaconda code make me feel dirty. The other thing is that fix to anaconda goes in and then might stays there even when the new pyparted is being used. It might be good to do the anaconda change and have a bug (if someone has a better idea of how to not let this fall through the cracks please tell me) that documents this issue.

btw, where does the new pyparted live? the patch is done against the latest version present in ssh://git.fedorahosted.org/git/pyparted.git maybe I can help speed things up and include a patch in the new pyparted. (something like an argument that will give you the "next partition" or the "next sane partition")

thx for the comments.


--
Joel Andres Granados
Red Hat / Brno, Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-12-2008, 07:00 PM
David Cantrell
 
Default this is a pyparted patch for 429185

On May 12, 2008, at 7:51 AM, Joel Andres Granados wrote:


Jeremy Katz wrote:

On Sat, 2008-05-10 at 18:22 +0200, Joel Andres Granados wrote:
I'm posting the patch here because I don't know where pyparted
discussion list lives


You can find the patch at https://bugzilla.redhat.com/attachment.cgi?id=305028

pyparted needs to search the valid partitions before it returns
anything in the py_ped_disk_next_partition function. With this
patch we can now save anaconda tracebacks to usb keys. I build
pyparted but didn't test the patch extensively.

Comments are greatly appreciated.

This significantly changes the semantics of the next_partition() API
call. While there aren't a lot of cases where you care about the
non-active partitions, there are a few. I think that actually the
right fix for the bug is probably something

along the lines of (completely untested)
diff --git a/partedUtils.py b/partedUtils.py
index 573bf4c..22bccb6 100644
--- a/partedUtils.py
+++ b/partedUtils.py
@@ -1362,7 +1362,7 @@ class DiskSet:
drives = []
for d in isys.removableDriveDict().items():
- func = lambda p: not p.get_flag(parted.PARTITION_RAID)
and

not p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2", "fat16", "fat32"]
+ func = lambda p: p.is_active and not
p.get_flag(parted.PARTITION_RAID) and not
p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2",

"fat16", "fat32"]
disk = self.disks[d[0]]
parts = filter_partitions(disk, func)
You have to ensure that the partition is an active one before doing
any
of get_flag or fs_type, etc. Yeah, it's a little ugly, but it's a
part
of the API and until we completely replace it, I think we have to
live

with it
Jeremy
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


The argument of waiting for pyparted to be rewritten is a
considerable one. If your going to do the whole thing from scratch,
why bother adding new stuff to the current one. OTOH, checking for
the validity of the partition so in the anaconda code make me feel
dirty. The other thing is that fix to anaconda goes in and then
might stays there even when the new pyparted is being used. It
might be good to do the anaconda change and have a bug (if someone
has a better idea of how to not let this fall through the cracks
please tell me) that documents this issue.


btw, where does the new pyparted live? the patch is done against
the latest version present in ssh://git.fedorahosted.org/git/pyparted.git
maybe I can help speed things up and include a patch in the new
pyparted. (something like an argument that will give you the "next
partition" or the "next sane partition")



We've been talking about the new pyparted in today's anaconda meeting,
so I wanted to point out what clumens and I had already completed:


1) Emulation of the existing pyparted API marked as deprecated.
2) New _ped module that gives full access to libparted.
3) New parted module full of classes and exciting fun functions that
may or may not do handy things.


At this point, we want to get the new pyparted done and in Fedora and
working. Anaconda will use the deprecated API until parts of it can
be rewritten to use the newer API.


Anyways, it got back-burnered last year because of too much other
stuff to do, but it's on the list for F-10 now.


--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-12-2008, 07:58 PM
Jeremy Katz
 
Default this is a pyparted patch for 429185

On Mon, 2008-05-12 at 19:51 +0200, Joel Andres Granados wrote:
> The argument of waiting for pyparted to be rewritten is a considerable one. If your
> going to do the whole thing from scratch, why bother adding new stuff to the current
> one. OTOH, checking for the validity of the partition so in the anaconda code make
> me feel dirty. The other thing is that fix to anaconda goes in and then might stays
> there even when the new pyparted is being used. It might be good to do the anaconda
> change and have a bug (if someone has a better idea of how to not let this fall
> through the cracks please tell me) that documents this issue.

The anaconda change won't remain if we change the pyparted API. There
are cases (including extendeds, iirc) where getting access to the
non-active partitions is important so you can't just go changing the
semantics of the API call. If you control all the code up and down and
there aren't any "public" APIs exposed, then sure, you can change
semantics whenever -- but that's not the case here.

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-13-2008, 08:04 AM
Joel Andres Granados
 
Default this is a pyparted patch for 429185

Jeremy Katz wrote:

On Mon, 2008-05-12 at 19:51 +0200, Joel Andres Granados wrote:
The argument of waiting for pyparted to be rewritten is a considerable one. If your
going to do the whole thing from scratch, why bother adding new stuff to the current
one. OTOH, checking for the validity of the partition so in the anaconda code make
me feel dirty. The other thing is that fix to anaconda goes in and then might stays
there even when the new pyparted is being used. It might be good to do the anaconda
change and have a bug (if someone has a better idea of how to not let this fall
through the cracks please tell me) that documents this issue.


The anaconda change won't remain if we change the pyparted API. There
are cases (including extendeds, iirc) where getting access to the
non-active partitions is important so you can't just go changing the
semantics of the API call. If you control all the code up and down and
there aren't any "public" APIs exposed, then sure, you can change
semantics whenever -- but that's not the case here.



I agree with you. What I propose is not a change to the old API but an change to the new one before it gets out the door. We can have a function that has an argument "validonly" (or something like that) which is false by default. This would mean that the call will have the argument only when the caller wants to ensure a valid "next partition". In other words:

nextvalidpartition = next_partition(validonly=true)
nextpartition = next_partition()

my point being that the check for the validity of the partition, IMO, is better put inside pyparted and not in a higher level. This does not change the semantics of the current calls. the next_partition() will still work and will still return the next partition, valid or invalid. So stuff that uses that function will not be invalid after the change. It does change the semantics of the calls where we want to ensure that the next partition is valid, it additionally does away with the couple of lines that check for the validity.

--
Joel Andres Granados
Red Hat / Brno, Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-13-2008, 10:54 AM
Jeremy Katz
 
Default this is a pyparted patch for 429185

On Tue, 2008-05-13 at 10:04 +0200, Joel Andres Granados wrote:
> I agree with you. What I propose is not a change to the old API but an change to the new one before it gets out the door. We can have a function that has an argument "validonly" (or something like that) which is false by default. This would mean that the call will have the argument only when the caller wants to ensure a valid "next partition". In other words:
>
> nextvalidpartition = next_partition(validonly=true)
> nextpartition = next_partition()
>
> my point being that the check for the validity of the partition, IMO, is better
> put inside pyparted and not in a higher level. This does not change the semantics
> of the current calls. the next_partition() will still work and will still return
> the next partition, valid or invalid. So stuff that uses that function will not
> be invalid after the change. It does change the semantics of the calls where we
> want to ensure that the next partition is valid, it additionally does away with
> the couple of lines that check for the validity.

For the new API, we should just get rid of the next_partition() stuff
altogether and do something iterator based --
for p in disk.partitions
would be oh so nice And at that point, we could make that just
return active partitions[1], leaving the special cases to use a special
case API. But, veering off the course now

Jeremy

[1] In fact, maybe it makes sense that it only returns active,
non-freespace partitions that are in use. Maybe not extendeds either.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-13-2008, 11:39 AM
Joel Andres Granados
 
Default this is a pyparted patch for 429185

Jeremy Katz wrote:

On Tue, 2008-05-13 at 10:04 +0200, Joel Andres Granados wrote:

I agree with you. What I propose is not a change to the old API but an change to the new one before it gets out the door. We can have a function that has an argument "validonly" (or something like that) which is false by default. This would mean that the call will have the argument only when the caller wants to ensure a valid "next partition". In other words:

nextvalidpartition = next_partition(validonly=true)
nextpartition = next_partition()

my point being that the check for the validity of the partition, IMO, is better
put inside pyparted and not in a higher level. This does not change the semantics
of the current calls. the next_partition() will still work and will still return
the next partition, valid or invalid. So stuff that uses that function will not
be invalid after the change. It does change the semantics of the calls where we
want to ensure that the next partition is valid, it additionally does away with
the couple of lines that check for the validity.


For the new API, we should just get rid of the next_partition() stuff
altogether and do something iterator based --
for p in disk.partitions
would be oh so nice And at that point, we could make that just
return active partitions[1], leaving the special cases to use a special
case API. But, veering off the course now

Jeremy

[1] In fact, maybe it makes sense that it only returns active,
non-freespace partitions that are in use. Maybe not extendeds either.



The iterator idea is a very good one!!!! Something to think about before releasing the new pyparted bits.
Going to patch up anaconda for now and see if I can come up with something for the iterator thing. Haven't played with iterator and python bindings so don't really know how complex the whole thin is. But its worth a look.




--
Joel Andres Granados
Red Hat / Brno, Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Tue May 13 15:30:01 2008
Return-path: <launchpad-users-bounces@lists.canonical.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 13 May 2008 14:45:56 +0300
Received: from chlorine.canonical.com ([91.189.94.204])
by s2.java-tips.org with esmtp (Exim 4.68)
(envelope-from <launchpad-users-bounces@lists.canonical.com>)
id 1JvsxA-0002PS-5U
for tom@linux-archive.org; Tue, 13 May 2008 14:45:56 +0300
Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com)
by chlorine.canonical.com with esmtp (Exim 4.60)
(envelope-from <launchpad-users-bounces@lists.canonical.com>)
id 1Jvswp-000599-Lx; Tue, 13 May 2008 12:45:35 +0100
Received: from ug-out-1314.google.com ([66.249.92.170])
by chlorine.canonical.com with esmtp (Exim 4.60)
(envelope-from <ubuntu@bugabundo.net>) id 1Jvswn-00058f-No
for launchpad-users@lists.canonical.com; Tue, 13 May 2008 12:45:33 +0100
Received: by ug-out-1314.google.com with SMTP id l31so959927ugc.48
for <launchpad-users@lists.canonical.com>;
Tue, 13 May 2008 04:45:33 -0700 (PDT)
Received: by 10.67.105.19 with SMTP id h19mr7022586ugm.64.1210679133088;
Tue, 13 May 2008 04:45:33 -0700 (PDT)
Received: from blubug.router.matir.pt ( [194.79.72.220])
by mx.google.com with ESMTPS id g9sm17781150gvc.0.2008.05.13.04.45.27
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Tue, 13 May 2008 04:45:32 -0700 (PDT)
Organization: http://BUGabundo.net
To: launchpad-users@lists.canonical.com
Subject: Re: Show status changes in bug mail subject
Date: Tue, 13 May 2008 12:45:15 +0100
User-Agent: KMail/1.9.9
References: <20080513103010.GF6433@piware.de>
In-Reply-To: <20080513103010.GF6433@piware.de>
MIME-Version: 1.0
Message-Id: <200805131245.24443.Ubuntu@bugabundo.net>
From: "(=?utf-8?q?=60=60-=5F-=C2=B4=C2=B4?=) -- Fernando"
<ubuntu@bugabundo.net>
X-BeenThere: launchpad-users@lists.canonical.com
X-Mailman-Version: 2.1.8
Precedence: list
Reply-To: Ubuntu-reply@bugabundo.net, launchpad-users@lists.canonical.com
List-Id: Discussion for Launchpad users <launchpad-users.lists.canonical.com>
List-Unsubscribe: <https://lists.ubuntu.com/mailman/listinfo/launchpad-users>,
<mailto:launchpad-users-request@lists.canonical.com?subject=unsubscribe>

List-Archive: <https://lists.ubuntu.com/archives/launchpad-users>
List-Post: <mailto:launchpad-users@lists.canonical.com>
List-Help: <mailto:launchpad-users-request@lists.canonical.com?subject=help>
List-Subscribe: <https://lists.ubuntu.com/mailman/listinfo/launchpad-users>,
<mailto:launchpad-users-request@lists.canonical.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6961336588288651709=="
Mime-version: 1.0
Sender: launchpad-users-bounces@lists.canonical.com
Errors-To: launchpad-users-bounces@lists.canonical.com

--===============6961336588288651709==
Content-Type: multipart/signed;
boundary="nextPart10103218.eKfxuEijNW";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart10103218.eKfxuEijNW
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ol=C3=A1 Martin e a todos.

On Tuesday 13 May 2008 11:30:10 Martin Pitt wrote:

Hi all,
=20
for long bug mail threads it would be very helpful at times if the bug
mail subject would contain status changes. This makes it easier to see
if a bug was already fixed, marked as a duplicate, or closed as
invalid, without needing to read the entire thread.

<snip>

Thanks,
Martin=20


=46or a moment I though you were asking for the extra detailed info that is=
on the bottom of LP emails, if you activate that option.
But it seems that even that, doesn't carry enough info as you requested.
I wouldnt mind having that extra data on the subtitle, but remember bug #20=
2645 and others alike, where email is not properly threaded by the email cl=
ient, because of the subject change.

Even now, my KMail is not able to thread the comments sent via the LP web i=
nterface, and only those sent by email.
LP/malone should really set in-reply-to headers on emails.

https://bugs.edge.launchpad.net/malone/+bug/202645

=2D-=20
BUGabundo )
(``-_-=C2=B4=C2=B4) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance.=
I'll try to be more assertive as time goes by...

--nextPart10103218.eKfxuEijNW
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIKX9UcV4wzCrhCcoRAs0EAJ44DB2oSXyq1FgikgqS9e 9AvOqMSgCfQMKx
fofvr6XnfeQHnSkVDcTtN8o=
=Bv8u
-----END PGP SIGNATURE-----

--nextPart10103218.eKfxuEijNW--


--===============6961336588288651709==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users

--===============6961336588288651709==--
 
Old 05-13-2008, 05:27 PM
Patrick Devine
 
Default this is a pyparted patch for 429185

On Tue, 13 May 2008, Jeremy Katz wrote:


On Tue, 2008-05-13 at 10:04 +0200, Joel Andres Granados wrote:

nextvalidpartition = next_partition(validonly=true)
nextpartition = next_partition()

my point being that the check for the validity of the partition, IMO, is better
put inside pyparted and not in a higher level. This does not change the semantics
of the current calls. the next_partition() will still work and will still return
the next partition, valid or invalid. So stuff that uses that function will not
be invalid after the change. It does change the semantics of the calls where we
want to ensure that the next partition is valid, it additionally does away with
the couple of lines that check for the validity.


For the new API, we should just get rid of the next_partition() stuff
altogether and do something iterator based --
for p in disk.partitions
would be oh so nice And at that point, we could make that just
return active partitions[1], leaving the special cases to use a special
case API. But, veering off the course now


Yes, please don't reimplement the crufty old next_partition() stuff. The
partitions should be in a container class that implements __len__(),
__getitem__(), etc.


I ended up having to wrap this in my own container class in the past and
I'd love to get the 200 lines of code back.


--Patrick.


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 10:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org