Re: [gentoo-user] How to fully mask gnome-3.18 upgrade

[Stroller]

> On Wed, 2 March 2016, at 6:58 am, Nicol TAO  wrote:
> 
> I want to ask how to mask the upgrades of gnome-3.18. I really want to
> find gnome 3.16 profile as kde4 and kde5 case, but none.

• https://wiki.gentoo.org/wiki/Knowledge_Base:Masking_a_package
• https://wiki.gentoo.org/wiki//etc/portage/package.mask
* https://wiki.gentoo.org/wiki/Version_specifier

Please note the 3rd link.

If you want further help, I think you'll need to post the contents of your 
/etc/portage/package.mask and a list of the specific files which are giving you 
problems.

Stroller.

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Adam Carter]

FYI for anyone concerned about this latest issue "DROWN" - its only a
problem if SSLv2 is enabled. SSLv2 has been broken for a long time, so
should be disabled. However, if it is exposed then an attacker can retrieve
the private key, and in doing so will be able to also decrypt secure TLS
1.2+ sessions to any server using that private key.

https://www.openssl.org/news/secadv/20160301.txt

[gentoo-user] Re: [OT] Choice of graphics card

[James]

Peter Humphrey  prh.myzen.co.uk> writes:


> which as I said is scientific computing using GPUs as well as the CPU.


Here is another great site to look for opensource science codes to run
on your gpu(s).

http://gpuopen.com/professional-compute/

hth,
James

[gentoo-user] Re: [OT] Choice of graphics card

[James]

Peter Humphrey  prh.myzen.co.uk> writes:

>said is scientific computing using GPUs as well as the CPU.


Ah well take a look at this 'bad boy(gpu)' article::

http://finance.yahoo.com/news/amd-gpuopen-fuels-seismic-supercomputing-14049.html


hth,
James

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Rich Freeman]

On Wed, Mar 2, 2016 at 2:11 PM, James  wrote:
> Rich Freeman  gentoo.org> writes:
>
> Excuse me, but I did not criticize anyone.

I know.  It was really meant to temper my remarks, since email is easy
to misconstrue.  It wasn't really directed at you, and you did get at
your intent at the end of your previous post.

>
>> 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?

So far this package is only in testing.  Nobody would have run into
this issue if they weren't running ~arch.  While disruptions this
large are undesirable even in ~arch, the reality is that you're much
more likely to run into them since you are the guinea pigs.

This is actually a security issue as well, so there is going to be a
rush to get it stabilized somehow.  I'm not entirely sure how yet.
Security issues are exempt from the 30 day rule, and we don't always
backport them.

>
> So what commands do I run (git style) to see the history of the relevant
> build/release dates for openssl? The changelog seems incomplete

Are you talking about upstream, or within Gentoo?

Within gentoo online you can just browse:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl

Hit log next to any file you're interested in, or go up a directory
and hit log next to the openssl directory itself to see everything
including file deletions/etc.

Or with git you can run:
git clone git://anongit.gentoo.org/repo/gentoo.git
cd gentoo/dev-libs/openssl
git log .

>
>> 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.

There are pros and cons to it, but I wouldn't be here if I didn't
think that letting the users pick the winner between openssl/libressl
wasn't a good thing.  Initially I was pushing back on adding libressl
to the tree a bit just to see if we could come up with a better way to
do it in light of the mess we ran into with libav.  In the end we
couldn't come up with anything so it moved forward.

> Easy on being so critical, either for others or yourself.

I was just joking with that, hence the point about somebody bringing
it up when I inevitably make a mistake.


> Besides this is excellent evidence
> for CI (Jenkins + Gerrit) ?   Are you not a proponent of CI for Gentoo?

I'm definitely a proponent.  It can be a bit problematic resource-wise
and with latency.  However, I should really get into the habit of
trying to do commits via pull-requests that hit our CI system.

-- 
Rich

[gentoo-user] Re: [OT] Choice of graphics card

[Nikos Chantziaras]

On 02/03/16 13:50, Peter Humphrey wrote:

Hello list,

It's approaching time to invest in a new system, and I'd like the panel's
views on which make of graphics card to choose: AMD, nVidia or Radeon. I
don't want to start a flame war, but which of those would give me the best
performance in GPU calculations? I have some BOINC projects in mind, which
apparently are greatly accelerated by using GPUs as well as CPUs.

The nouveau driver for nVidia can't do CUDA (GPU) calculations so I'd have
to use the nVidia driver; I don't know about the others which is why I'm
asking.

Does anyone here have an opinion to offer?


If you need 64-bit FP compute, AMD Radeon is your only choice. NVidia 
only supports 32-bit FP and cripples 64-bit FP on consumer cards, 
rendering them virtually useless; you'd have to buy a "professional" 
card (thousands of dollars).


So you might want to check whether your applications need 64-bit FP or 
32-bit.

[gentoo-user] Re: useflag hell.

[Kai Krakow]

Am Sun, 28 Feb 2016 21:01:48 +0200
schrieb Alan McKinnon :

> On 28/02/2016 20:14, Alan Grimes wrote:
> > I've been running number theory code for a few weeks, so haven't
> > been updating my machine too often...
> > 
> > I for the last day or so I'm in a run my "pretendupdate" script,
> > look at the results, decide whether to run ufed or bleep with
> > package.use run the pretendupdate script again, do something
> > while it computes, come back to it hours later, and repeat the
> > cycle... This is really getting silly and I'm starting to suspect
> > that I'm stuck in useflag hell and there isn't a solution to this.
> 
> 
> There's always a solution, and they are seldom hard to solve. However,
> portage doesn't exactly make it easy for you with the output. Mere
> information is often obfuscated and looks like stuff you must fix,
> whereas the real nuggets can be hidden in the noise.
> 
> Often running without -v can help considerably.
> 
> So, here goes, comments inline
> > 
> > 
> > 
> > 
> > tortoise ~ # ./pretendupdate
> > 
> > These are the packages that would be merged, in order:
> > 
> > Calculating dependencies... done!
> > 
> > !!! Multiple package instances within a single package slot have
> > been pulled !!! into the dependency graph, resulting in a slot
> > conflict:
> > 
> > dev-libs/icu:0
> > 
> >   (dev-libs/icu-56.1:0/56::gentoo, ebuild scheduled for merge)
> > pulled in by (no parents that aren't satisfied by other packages in
> > this slot)
> > 
> >   (dev-libs/icu-55.1:0/55::gentoo, installed) pulled in by
> > dev-libs/icu:0/55=[abi_x86_32(-),abi_x86_64(-)] required by
> > (dev-qt/qtcore-4.8.7-r1:4/4::gentoo, installed)
> >
> > ^^  
> 
> Despite what it looks like all this is mere information.
> Two separate things result in different version of Qt being pulled
> into the problem solution. And it's exactly the form you'd expect.
> 
> The first chunk is really saying that icu-56.1 is the most recent
> version and all other things being equal, that's the one portage would
> install. The second chunk is saying that qtcore-4.8.7-r1 requires
> icu-55.1 (not the most recent), so portage spews forth heaps of junk
> to helpfully let you not figure it out.
> 
> What portage really should say is more like:
> 
> Most recent version of icu (icu-56.1) not installed due to these
> requirements:
> qtcore-4.8.7-r1 requires icu-55.1
> 
> Ignore the multiple OMG! bangs before all of the above output
> 
> 
> > 
> > 
> > 
> > It may be possible to solve this problem by using package.mask to
> > prevent one of those packages from being selected. However, it is
> > also possible that conflicting dependencies exist such that they are
> > impossible to satisfy simultaneously.  If such a conflict exists in
> > the dependencies of two different packages, then those packages can
> > not be installed simultaneously.
> > 
> > For more information, see MASKED PACKAGES section in the emerge man
> > page or refer to the Gentoo Handbook.
> > 
> > 
> > !!! The ebuild selected to satisfy
> > ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has
> > unmet requirements.
> 
> This is the expression portage needs to install based on dependencies,
> most recent version, maskings, and your USE flags. It's informational.
> 
> > - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg fftw gtk kde kdenlive
> > lua melt opengl python qt5 sdl xine xml -compressed-lumas -debug
> > -frei0r -jack -libav -libsamplerate -qt4 -rtaudio (-ruby) -vdpau"
> > ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
> > 
> >   The following REQUIRED_USE flag constraints are unsatisfied:
> > kde? ( qt4 )
> 
> This is the actual problem, According to the ebuild, if you set
> USE="kde", then you also need USE="qt4". Your USE has qt5 enabled, and
> that's the problem.
> 
> Presumably, mtl does not yet support KDE with Qt5
> > 
> >   The above constraints are a subset of the following complete
> > expression: python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde?
> > ( qt4 )
> 
> And this is the helpful gigantic USE expression, all of which must be
> satisfied to install mlt. The bit above this shows just the part that
> is problematic, so this is also informational. Note
> > 
> > (dependency required by
> > "kde-apps/kdenlive-15.12.1::gentoo" [ebuild]) (dependency required
> > by "kde-apps/kdemultimedia-meta-15.12.1-r1::gentoo" [ebuild])
> > (dependency required by "kde-apps/kde-apps-meta-15.08.3-r3::gentoo"
> > [ebuild])
> > (dependency required by
> > "kde-apps/kde-meta-15.08.3::gentoo" [ebuild]) (dependency required
> > by "@selected" [set]) (dependency required by "@world" [argument])
> 
> And the is a part of the full dep tree that leads to mlt being
> included
> > tortoise ~ #
> > 
> > 
> > ##
> > 
> > 
> > The attached files are whatever is left after --- six years of
> > resolving similar issues on this same install...
> 
> 
> What you need to do 

[gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[James]

Rich Freeman  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.
> >
> > H. 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
> > comradeseven 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

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Jeremi Piotrowski]

On Wed, Mar 2, 2016 at 6:54 PM, Rich Freeman  wrote:
> 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.
>

I recall reading about such a tool:
http://ispras.linuxbase.org/index.php/ABI_compliance_checker
I haven't tried it out, but I would be curious to see whether it would have
caught this case.

[gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[»Q«]

On Wed, 2 Mar 2016 10:49:59 -0500
Rich Freeman  wrote:

> https://forums.gentoo.org/viewtopic-p-7886940.html
> https://bugs.gentoo.org/show_bug.cgi?id=576128

I had wget with USE="gnutls" already, so I took the plunge yesterday
and followed PolynomialC's instructions at the first link above.

When I used

revdep-rebuild.sh -i -L "libssl\.so.*" -- --exclude=openssl --keep-going

the only package that failed to rebuild was
www-client/w3mmee-0.3.2_p24-r7, and that failure is due to
, nothing to do with
openssl.

Re: [gentoo-user] Re: [OT] Choice of graphics card

[Rich Freeman]

On Wed, Mar 2, 2016 at 12:44 PM, Peter Humphrey  wrote:
>
> Not just the computing power, though: Gentoo support will be important over
> the life of the system. If the life of this current box is any guide, that
> could stretch to 10 years. Well, maybe.
>

So, I can't speak to computation in particular, so take all of this
with a grain of salt.

In general the sentiment I've seen expressed is that at least
presently the quality of drivers goes (best to worst):
NVidia proprietary
AMD open source
NVidia open source

So, right now if you want the best overall performance/etc and don't
care about tainted kernels nvidia is your best choice, and I believe
it isn't even close.

However, if you want the best overall performance WITH AN OPEN SOURCE
kernel/etc, then AMD is the better solution.

Now, as I understand it AMD has been talking about moving more towards
open source drivers so that they're much closer in quality to
NVidia's.  At that point there will be less need to compromise between
driver quality and open source.  Of course, either vendor's hardware
might be superior.  (From what I've heard at the high end NVidia tends
to be better, and of course stuff like games tends to support it more,
but at the lower end AMD is VERY competitive and doesn't tend to
cripple stuff as much to segment the markets - something that is true
of their CPUs as well.)

So, while NVidia is often the route people go, I'd say that you need
to understand your needs.

With AMD it is all open source and I think most of it is even
upstreamed into the kernel, so support is as good as it gets.  With
Nvidia you may find yourself limited to particular kernels, especially
once your card is no longer supported.  AMD overall has more
commitment to open source itself, though it doesn't port its
proprietary windows drivers over like NVidia does.

Again, all of this is more general and pertains to graphics, and the
situation for computation could be very different.  I also am hardly a
graphics card super-enthusiast, so if others have more knowledge I'm
all ears.

-- 
Rich

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Rich Freeman]

On Wed, Mar 2, 2016 at 11:06 AM, James  wrote:
> Rich Freeman  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.
>
> H. 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.

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).

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.

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.

>
> Not trying to stir things up, just scratching many itches here on the
> dev-quizes. Surely we are all human(oid) and thus forginving of our
> comradeseven 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.)

-- 
Rich

Re: [gentoo-user] Re: [OT] Choice of graphics card

[Peter Humphrey]

On Wednesday 02 March 2016 15:33:27 James wrote:
> Peter Humphrey  prh.myzen.co.uk> writes:
> > It's approaching time to invest in a new system, and I'd like the
> > panel's views on which make of graphics card to choose: AMD, nVidia or
> > Radeon. Does anyone here have an opinion to offer?
> 
> Perhaps you can define some more parameters as to your budget constraints,
> power limitations on the main power supply and exactly
> what is your target use of the video (gpu+memory) resources?

Budget seems unlikely to influence choice of graphics card maker. The three I 
mentioned are all offered by my preferred system builder, Armari. I don't 
know what you mean about limits to power. You snipped the application area, 
which as I said is scientific computing using GPUs as well as the CPU.

> Noise (dB) restrictions? Air or water cooled? hardware (slot)
> availability?

I'm just interested in the comparative performance of the three makes of GPU 
at this stage. I can fill in the rest of the spec once I know which to go for 
- unless one make is ruled out by excessively noisy coolers or something.

Not just the computing power, though: Gentoo support will be important over 
the life of the system. If the life of this current box is any guide, that 
could stretch to 10 years. Well, maybe.

> New mobo or an upgrade to an existing mobo?

It'll be a new system, as I said.

> Dual windows booting for windows gaming? etc etc.

I'm not interested in Windows or gaming. Certainly not the kind of rapid-fire 
games that spotty youths seem to go for.

-- 
Rgds
Peter

[gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[James]

Rich Freeman  gentoo.org> writes:


> >> Today's upgrade of openssl to 1.0.2g-r1 may cause some necessary
> >> rebuilds to fail due to missing symbol errors.

> https://forums.gentoo.org/viewtopic-p-7886940.html
> https://bugs.gentoo.org/show_bug.cgi?id=576128

> 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.

H. 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?




> 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?


Not trying to stir things up, just scratching many itches here on the
dev-quizes. Surely we are all human(oid) and thus forginving of our
comradeseven to the point of encouragement?



quizfully,
James

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Rich Freeman]

On Wed, Mar 2, 2016 at 10:54 AM, Alan McKinnon  wrote:
> On 02/03/2016 17:49, Rich Freeman wrote:
>> https://forums.gentoo.org/viewtopic-p-7886940.html
>> https://bugs.gentoo.org/show_bug.cgi?id=576128
>>
>> 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.
>
> brain dead is being kind to folks with non-functioning brains...
>
> I'm now seriously considering the libressl folks might have a point.
>

You mean the project that forked openssl, changed the APIs and ABIs,
and also kept the same SONAMEs for "compatibility?"  We can see how
well that worked with libav...

-- 
Rich

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Alan McKinnon]

On 02/03/2016 17:49, Rich Freeman wrote:
> https://forums.gentoo.org/viewtopic-p-7886940.html
> https://bugs.gentoo.org/show_bug.cgi?id=576128
> 
> 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.


brain dead is being kind to folks with non-functioning brains...

I'm now seriously considering the libressl folks might have a point.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Rich Freeman]

On Wed, Mar 2, 2016 at 10:15 AM, Nikos Chantziaras  wrote:
> On 02/03/16 16:41, walt wrote:
>>
>> Today's upgrade of openssl to 1.0.2g-r1 may cause some necessary
>> rebuilds to fail due to missing symbol errors.
>>
>> Example:  libcurl was broken and caused the rebuilds of virtualbox and
>> git to fail until I forced a rebuild of curl.  Any installed package
>> that is actually linked against openssl will be affected by this,
>> notably curl or wget, which may prevent portage from fetching source
>> files.
>
> Does that mean that the library name is the same and the "preserve-libs"
> FEATURE doesn't kick in in this case?
>

https://forums.gentoo.org/viewtopic-p-7886940.html
https://bugs.gentoo.org/show_bug.cgi?id=576128

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.

revdep-rebuild is incapable of detecting this kind of breakage.  Your
linking will appear intact, but things will crash because the ABI
changed.

Everybody should be on the lookout for this update and carefully
follow the forum post instructions to get through it.

-- 
Rich

[gentoo-user] Re: [OT] Choice of graphics card

[James]

Peter Humphrey  prh.myzen.co.uk> writes:

> 
> Hello list,
> 
> It's approaching time to invest in a new system, and I'd like the panel's 
> views on which make of graphics card to choose: AMD, nVidia or Radeon. 
> Does anyone here have an opinion to offer?




Perhaps you can define some more parameters as to your budget constraints,
power limitations on the main power supply and exactly
what is your target use of the video (gpu+memory) resources?

Noise (dB) restrictions? Air or water cooled? hardware (slot) availability?
New mobo or an upgrade to an existing mobo?
Dual windows booting for windows gaming? etc etc.


hth,
James

Re: [gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Todd Goodman]

* Nikos Chantziaras  [160302 10:16]:
> On 02/03/16 16:41, walt wrote:
> > Today's upgrade of openssl to 1.0.2g-r1 may cause some necessary
> > rebuilds to fail due to missing symbol errors.
> >
> > Example:  libcurl was broken and caused the rebuilds of virtualbox and
> > git to fail until I forced a rebuild of curl.  Any installed package
> > that is actually linked against openssl will be affected by this,
> > notably curl or wget, which may prevent portage from fetching source
> > files.
> 
> Does that mean that the library name is the same and the "preserve-libs" 
> FEATURE doesn't kick in in this case?

It's not working for me either and I've had to manually rebuild curl and
w3m.

Todd

[gentoo-user] Re: openssl upgrade may miss some needed rebuilds

[Nikos Chantziaras]

On 02/03/16 16:41, walt wrote:

Today's upgrade of openssl to 1.0.2g-r1 may cause some necessary
rebuilds to fail due to missing symbol errors.

Example:  libcurl was broken and caused the rebuilds of virtualbox and
git to fail until I forced a rebuild of curl.  Any installed package
that is actually linked against openssl will be affected by this,
notably curl or wget, which may prevent portage from fetching source
files.


Does that mean that the library name is the same and the "preserve-libs" 
FEATURE doesn't kick in in this case?

[gentoo-user] openssl upgrade may miss some needed rebuilds

[walt]

Today's upgrade of openssl to 1.0.2g-r1 may cause some necessary
rebuilds to fail due to missing symbol errors.

Example:  libcurl was broken and caused the rebuilds of virtualbox and
git to fail until I forced a rebuild of curl.  Any installed package
that is actually linked against openssl will be affected by this,
notably curl or wget, which may prevent portage from fetching source
files.

I suggest using quickpkg to back up openssl before the upgrade in case
you need to recover urgently in the middle of the update.

[gentoo-user] [OT] Choice of graphics card

[Peter Humphrey]

Hello list,

It's approaching time to invest in a new system, and I'd like the panel's 
views on which make of graphics card to choose: AMD, nVidia or Radeon. I 
don't want to start a flame war, but which of those would give me the best 
performance in GPU calculations? I have some BOINC projects in mind, which 
apparently are greatly accelerated by using GPUs as well as CPUs.

The nouveau driver for nVidia can't do CUDA (GPU) calculations so I'd have 
to use the nVidia driver; I don't know about the others which is why I'm 
asking.

Does anyone here have an opinion to offer?

-- 
Rgds
Peter