1 |
On Fri, Apr 27, 2012 at 17:13, Mike Gilbert <floppym@g.o> wrote: |
2 |
> To be honest, I did not look into each patch in great detail. I really |
3 |
> just tested the resulting builds to make sure they did not break |
4 |
> anything obvious. |
5 |
|
6 |
I can imagine, I just think it's probably good if we do look at |
7 |
patches in detail. |
8 |
|
9 |
>> 3. Added 61_all_process_data.patch, for which the goal seems somewhat unclear. |
10 |
> This is some logic for python-wrapper that was in the 2.7.2 patchset as |
11 |
> well. If you want to drop it, I'm sure that will require some |
12 |
> re-engineering of python-wrapper. |
13 |
|
14 |
Right. Do you know what this fixes, and how/why it will be |
15 |
re-engineered? As long as we don't know these things, I'd prefer to |
16 |
leave the patch out rather than include it. |
17 |
|
18 |
>> You also removed the mention of the upstream bug from |
19 |
>> 04_all_libdir.patch, probably just by mistake? |
20 |
> |
21 |
> I don't see any mention of a bug in the 2.7.2, 2.7.3 or 2.7.3-0 version |
22 |
> of the patch, so I'm not sure what you are referring to here. |
23 |
|
24 |
Are you sure? The 04* patch I just unpacked from my 2.7.3 patch set |
25 |
does have a bug in it (maybe it wasn't in 2.7.2, though). |
26 |
|
27 |
>> Including |
28 |
>> 26_all_gdbm-1.9.patch in 3.1.5 is probably a good idea. For 3.1.5's |
29 |
>> 09_all_sys.platform_linux2.patch, I'd prefer if we just reuse |
30 |
>> ${FILESDIR}/linux2.patch, unless that doesn't apply for some reason. |
31 |
> |
32 |
> I don't really see a difference either way. I guess it is more visible |
33 |
> in the ebuild. |
34 |
|
35 |
I like the fact that it's a single patch for all the versions, and |
36 |
that we don't have to manage it separately in the patch sets. |
37 |
|
38 |
>> Now, we can certainly discuss adding these patches on this list, but I |
39 |
>> think we should try to maintain some balance on the upside of having |
40 |
>> extra fixes in our ebuilds and the amount of maintenance we're willing |
41 |
>> to do on carrying those patches forward (e.g. the distutils patch is a |
42 |
>> pretty big pain, and it seems like more of a feature than a bug). |
43 |
> |
44 |
> Well, that does seem to be Arfrever's baby, so as long as he keeps |
45 |
> rebase it, we should be ok. |
46 |
|
47 |
Yeah, I'd really prefer to have us not depend on Arfrever for our |
48 |
dev-lang/python updates. IMO we should drop this from 3.3 pending |
49 |
upstream movement. |
50 |
|
51 |
> That makes sense. I will keep it in mind. |
52 |
> |
53 |
> Would you like me to cut a new set of tarballs without 08, 22, and 23? |
54 |
|
55 |
That would be perfect. I'd also still like to drop 61 unless we have a |
56 |
clear picture of what/why it helps (and can document that in the |
57 |
patch). |
58 |
|
59 |
Cheers, |
60 |
|
61 |
Dirkjan |