From: James <wireless@tampabay.rr.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds
Date: Wed, 2 Mar 2016 19:11:03 +0000 (UTC) [thread overview]
Message-ID: <loom.20160302T194023-945@post.gmane.org> (raw)
In-Reply-To: CAGfcS_k7ScKk30T8hqYGB6UBjDd_AiFtapM6DceszqkGVcFvXg@mail.gmail.com
Rich Freeman <rich0 <at> gentoo.org> writes:
> >> They changed ABI without changing SONAME, which is an absolutely
> >> braid-dead thing for upstream to do, because it causes exactly this
> >> kind of breakage.
> >
> > Hmmmm. I've been working on my ebuild and end-o-mentoring quizes:: so in
> > that vein, should not the gentoo dev have bumped the gentoo rev
> > numbers, or did I miss-read the gentoo docs?
> >
>
> So, first, this isn't really the forum to critique what the devs did,
> and I haven't spoken to them so I can't vouch for what their knowledge
> was at the time.
Excuse me, but I did not criticize anyone. I *appreciate* what the devs do;
in fact so much, I've started down that path myself. As one who has put
together dozens of ebuilds, but few published, I greatly appreciated their
work and the opportunity to learn from all mistakes, mine and the devs.
Besides, I'm not a dev, so what forum would be more appropriate to question
and learn about ebuilds and booboos? So please appreciated that thge focus
of my questions, *are to learn* with a robust discussion, as I do intend to
seek dev_status one day. Are 'users' discouraged from breaking down
package/ebuild issues in this forum? If so, which forum can I ask questions,
even the dumb ones?
> Revbumping wouldn't help, and I'm pretty sure they did revbump it.
> The real issue was upstream, and I'd have to think about whether
> trying to fix it with a Gentoo patch would make things better or worse
> (it would make Gentoo different from everybody else, causing havoc if
> you had a proprietary binary you wanted to run and so on).
One of the dev-quiz questions is about how long to leave a package in
testing, with 30 days being the minimum, unless there is critical need,
or have I not correctly understood the docs and devmanual? Again, I have no
idea how long this package was in 'testing' but, this does sound like an
excellent opportunity for fledgling devs to learn a bit deeper? My
intentions are only based on the good for this distro, but, close
examination, at least for me, is highly warranted.
So what commands do I run (git style) to see the history of the relevant
build/release dates for openssl? The changelog seems incomplete....
> Upstream really dropped the ball on this. When I'm updating packages
> I certainly don't carefully review all their ABIs and SONAMEs.
> Without some kind of automatic QA tool it would be a pretty big
> undertaking. I might go see if there is such a tool though, maybe
> that might be a good outcome if such a tool exists.
> >> Everybody should be on the lookout for this update and carefully
> >> follow the forum post instructions to get through it. Again, in
> >> light of the dev-quizes, should not the package maintainer have
> >> posted a news item prior/simultaneously to the new package release?
> Sure, if they had known about it. However, it sounds like they may
> have been as surprised as anybody else. I'd really like to see one
> right away though.
Thanks! Good answer and now I'll have to go an edited/update my dev quiz
responses to indicate that a late news items, for something critical or that
touches so many packages, is warranted. Excellent, concrete example. One of
the things I have been working on, is supplying more details examples to the
devmanual current editor, just like this one, to reinforce the key
principles of the devmanual. I think some kind of footnotes to lots of
practical examples, is *exactly what the dev manual is missing* imho.
> The way openssl handles their ABIs really makes me think that libressl
> may not be the lesser evil. Sloppy SONAME handling causes all kinds
> of issues though and seeing it in high-profile projects like these is
> pretty concerning.
Good to know. In fact gentoo supports such a wide variety of libs so all of
this information, in a practical example, is very valuable imho.
> > Not trying to stir things up, just scratching many itches here on the
> > dev-quizes. Surely we are all human(oid) and thus forgiving of our
> > comrades....even to the point of encouragement?
> Of course. To err is human. To stabilize errs carries the death
> penalty. :) (I'm sure somebody will file that away for the next
> stable package I break.)
Easy on being so critical, either for others or yourself. I've been hacking
on ebuilds for almost a year now, and there is good reason quite a few
of mine are still not published....... Besides this is excellent evidence
for CI (Jenkins + Gerrit) ? Are you not a proponent of CI for Gentoo?
That's a common and ordinary usage for clusters these days.....
I do appreciate the information and candor!
be at peace,
James
next prev parent reply other threads:[~2016-03-02 19:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 14:41 [gentoo-user] openssl upgrade may miss some needed rebuilds walt
2016-03-02 15:15 ` [gentoo-user] " Nikos Chantziaras
2016-03-02 15:25 ` Todd Goodman
2016-03-02 15:49 ` Rich Freeman
2016-03-02 15:54 ` Alan McKinnon
2016-03-02 16:02 ` Rich Freeman
2016-03-02 16:06 ` James
2016-03-02 17:54 ` Rich Freeman
2016-03-02 18:32 ` Jeremi Piotrowski
2016-03-02 19:11 ` James [this message]
2016-03-02 20:16 ` Rich Freeman
2016-03-03 5:10 ` Adam Carter
2016-03-02 18:19 ` »Q«
2016-03-03 8:15 ` Håkon Alstadheim
2016-03-03 11:26 ` Rich Freeman
2016-03-03 13:05 ` Håkon Alstadheim
2016-03-03 13:43 ` Rich Freeman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20160302T194023-945@post.gmane.org \
--to=wireless@tampabay.rr.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox