1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA512 |
3 |
|
4 |
On 05/21/2012 05:10 PM, Volker Armin Hemmann wrote: |
5 |
> Am Montag, 21. Mai 2012, 08:55:25 schrieb Mark Knecht: |
6 |
>> On Mon, May 21, 2012 at 8:04 AM, Markos Chandras |
7 |
>> <hwoarang@g.o> |
8 |
> wrote: |
9 |
>>> On Mon, May 21, 2012 at 3:46 PM, Mark Knecht |
10 |
>>> <markknecht@×××××.com> wrote: |
11 |
>>>> I love my Gentoo-devs, but what is the train of thought |
12 |
>>>> here? skype-2.2.0.35-r1 was ~amd64 yesterday. It's installed |
13 |
>>>> and working fine. Today 2.2.0.35-r99 is ~amd64, which is |
14 |
>>>> perfectly fine, but they've completely removed -r1 and now |
15 |
>>>> I'm required to unmask emulation packages that only came out |
16 |
>>>> today? That doesn't seem quite right... |
17 |
>>>> |
18 |
>>>> Why did they completely get rid of -r1? That should stick |
19 |
>>>> around for a little while after -r99 becomes ~amd64, |
20 |
>>>> shouldn't it? |
21 |
>>>> |
22 |
>>>> - Mark |
23 |
>> |
24 |
>> <SNIP> |
25 |
>> |
26 |
>>> -r1 had a security problem. You should unmask the emulation |
27 |
>>> packages and continue the update process. Look at the ChangeLog |
28 |
>>> so see what changed. Both versions are ~amd64 so I don't |
29 |
>>> understand your complain about keeping -r1 in the tree for a |
30 |
>>> while. |
31 |
>>> |
32 |
>>> Markos |
33 |
>> |
34 |
>> Thanks Markos. That's likely what I'll do, although the |
35 |
>> alternative I'm looking at for now is possibly getting -r1 from |
36 |
>> an overlay. |
37 |
>> |
38 |
>> I didn't think I was _complaining_. I was just asking what the |
39 |
>> train of thought was that leads them to do this sort of thing. |
40 |
>> Everything in the world has a security problem. |
41 |
> |
42 |
> well, apart from this being not true at all. It is just stupid to |
43 |
> keep a known BAD version in a TESTING tree. |
44 |
> |
45 |
>> We know they are either found or not found. Unmasking 8 emulation |
46 |
>> libraries that have _yesterdays_ date in their names, and |
47 |
>> therefore makes them quite new, may: |
48 |
> |
49 |
> new for their compilation. Not the code inside. |
50 |
>> |
51 |
>> 1) Create more security problems |
52 |
> |
53 |
> may, but it fixes a KNOWN problem. |
54 |
> |
55 |
>> |
56 |
>> 2) Create issues with other programs that use the libraries. |
57 |
> |
58 |
> which are.. none? |
59 |
> |
60 |
>> |
61 |
>> Anyway, thanks for the response. I'll either unmask or use an |
62 |
>> overlay. |
63 |
> |
64 |
> if you use testing, you have to deal with such kind of situations. |
65 |
> Using a known broken version is just stupid. There isn't a choice |
66 |
> between those two. There is only a choice between: use unstable or |
67 |
> stable. And if you use unstable, don't complain about things being |
68 |
> fluid. |
69 |
> |
70 |
- From what I can tell, he is not using ~amd64 (testing). He uses a |
71 |
mixed system (stable with a few packages in package.keywords) which |
72 |
sometimes is even worse :) |
73 |
|
74 |
The best way to deal with your problem (and avoid seeing your |
75 |
package.keywords getting bigger and bigger) is to grab -r1, mark it |
76 |
stable, put it in your local overlay and keep using that indefinitely. |
77 |
|
78 |
- -- |
79 |
Regards, |
80 |
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 |
81 |
-----BEGIN PGP SIGNATURE----- |
82 |
Version: GnuPG v2.0.19 (GNU/Linux) |
83 |
|
84 |
iQIcBAEBCgAGBQJPuneqAAoJEPqDWhW0r/LC538QAJNaPIa0BSCh67//wIXgXYbX |
85 |
pi231wBAhc0yGxfIcfXiNJBvTD5D08AAFhswoHHMer6/H1+NHKaeF8MnNmpt+41W |
86 |
FHRj5bG/30uhgD0thb6tmZ78GEWMOkRxPtv0jPQk0Y2YIkI9RYk3eYkgqD2MVbJz |
87 |
XJfI5HWpOB5Eh3fiNJkzc5mW2bdPLm0dFS5dmkKtVclM7bI4DJ42Gwk9pOgJ+T+H |
88 |
ciGPQt4NvqqXf94pV5LVXej9+93pTlNA4QvtSE1Io1T2srHrO5/3KE5t1QF6eht1 |
89 |
odSJMID+hZ7ViOIRxK1a453sAzO8rK1SZJhoKzYFhPonQq/VFymU/sGcap2gU3Y1 |
90 |
FQKVeb10nZdAT3v2dw8DaqGnxJHdWcbwRaJOy6M28vdDnOvFBwZYzFn5zTugwHr7 |
91 |
Gcd/buQ6yCtWvUUO/QtgkIgGVewxE5QdQ7Pn3ytt+j3wIQV9QVs46dEUy/rOc5FU |
92 |
deibghpnTYy1vn3uT5sLsDHlvWtE2XIonowPeBRcQmQJeo9snqIf2WBCn3ExiWym |
93 |
7Bj0iHVbnEQcdWnIuRiK5sR5eSi+lJv/1Z+xwH98lFXGyX8jM6501W9ZZRBxwMoA |
94 |
mbCv+RmHfMKUwHhVrdk4qmI/McgDN6DFkS1I/fHaa/mQ0ImDh5U9CahxvvsVz9s+ |
95 |
iV17+9hETK1TAMP9G2yb |
96 |
=+5ZX |
97 |
-----END PGP SIGNATURE----- |