1 |
On Wed, Mar 2, 2016 at 2:11 PM, James <wireless@×××××××××××.com> wrote: |
2 |
> Rich Freeman <rich0 <at> gentoo.org> writes: |
3 |
> |
4 |
> Excuse me, but I did not criticize anyone. |
5 |
|
6 |
I know. It was really meant to temper my remarks, since email is easy |
7 |
to misconstrue. It wasn't really directed at you, and you did get at |
8 |
your intent at the end of your previous post. |
9 |
|
10 |
> |
11 |
>> Revbumping wouldn't help, and I'm pretty sure they did revbump it. |
12 |
>> The real issue was upstream, and I'd have to think about whether |
13 |
>> trying to fix it with a Gentoo patch would make things better or worse |
14 |
>> (it would make Gentoo different from everybody else, causing havoc if |
15 |
>> you had a proprietary binary you wanted to run and so on). |
16 |
> |
17 |
> One of the dev-quiz questions is about how long to leave a package in |
18 |
> testing, with 30 days being the minimum, unless there is critical need, |
19 |
> or have I not correctly understood the docs and devmanual? Again, I have no |
20 |
> idea how long this package was in 'testing' but, this does sound like an |
21 |
> excellent opportunity for fledgling devs to learn a bit deeper? |
22 |
|
23 |
So far this package is only in testing. Nobody would have run into |
24 |
this issue if they weren't running ~arch. While disruptions this |
25 |
large are undesirable even in ~arch, the reality is that you're much |
26 |
more likely to run into them since you are the guinea pigs. |
27 |
|
28 |
This is actually a security issue as well, so there is going to be a |
29 |
rush to get it stabilized somehow. I'm not entirely sure how yet. |
30 |
Security issues are exempt from the 30 day rule, and we don't always |
31 |
backport them. |
32 |
|
33 |
> |
34 |
> So what commands do I run (git style) to see the history of the relevant |
35 |
> build/release dates for openssl? The changelog seems incomplete.... |
36 |
|
37 |
Are you talking about upstream, or within Gentoo? |
38 |
|
39 |
Within gentoo online you can just browse: |
40 |
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl |
41 |
|
42 |
Hit log next to any file you're interested in, or go up a directory |
43 |
and hit log next to the openssl directory itself to see everything |
44 |
including file deletions/etc. |
45 |
|
46 |
Or with git you can run: |
47 |
git clone git://anongit.gentoo.org/repo/gentoo.git |
48 |
cd gentoo/dev-libs/openssl |
49 |
git log . |
50 |
|
51 |
> |
52 |
>> The way openssl handles their ABIs really makes me think that libressl |
53 |
>> may not be the lesser evil. Sloppy SONAME handling causes all kinds |
54 |
>> of issues though and seeing it in high-profile projects like these is |
55 |
>> pretty concerning. |
56 |
> |
57 |
> Good to know. In fact gentoo supports such a wide variety of libs so all of |
58 |
> this information, in a practical example, is very valuable imho. |
59 |
|
60 |
There are pros and cons to it, but I wouldn't be here if I didn't |
61 |
think that letting the users pick the winner between openssl/libressl |
62 |
wasn't a good thing. Initially I was pushing back on adding libressl |
63 |
to the tree a bit just to see if we could come up with a better way to |
64 |
do it in light of the mess we ran into with libav. In the end we |
65 |
couldn't come up with anything so it moved forward. |
66 |
|
67 |
> Easy on being so critical, either for others or yourself. |
68 |
|
69 |
I was just joking with that, hence the point about somebody bringing |
70 |
it up when I inevitably make a mistake. |
71 |
|
72 |
|
73 |
> Besides this is excellent evidence |
74 |
> for CI (Jenkins + Gerrit) ? Are you not a proponent of CI for Gentoo? |
75 |
|
76 |
I'm definitely a proponent. It can be a bit problematic resource-wise |
77 |
and with latency. However, I should really get into the habit of |
78 |
trying to do commits via pull-requests that hit our CI system. |
79 |
|
80 |
-- |
81 |
Rich |