On 12/30/18 9:51 PM, Pratyush Das wrote:
> For oracle-jdk - https://pastebin.com/iT1XsfUv
> In this case the log tells you to download jdk-8u192-linux-x64.tar.gz
> from
> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
> and place it in your distfiles
For oracle-jdk - https://pastebin.com/iT1XsfUv
In this case the log tells you to download jdk-8u192-linux-x64.tar.gz from
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
and place it in your distfiles directory. But it does not tell you where
your distfiles
20181229-19:33 zlogene ee981eb0125
dev-libs/libexplain20181229-12:33 zlogene e2dcf9bb504
dev-util/fhist 20181229-12:34 zlogene f41b5f7aaa3
games-server/ut2003-ded20181229-12:27 zlogene b53c88d5238
Additions:
app-crypt/tpm2-tools 20181230-20:51 alonbl3cd3fa3e139
On 30/12/18 19:58, Pratyush Das wrote:
> Hi,
>
> In reference to this forum post
> - https://forums.gentoo.org/viewtopic-t-1091144-highlight-.html , I was
> told that several users found wrong information in the portage error logs
> pointing them to the wrong directory for distfiles to be
Hi,
In reference to this forum post -
https://forums.gentoo.org/viewtopic-t-1091144-highlight-.html , I was told
that several users found wrong information in the portage error logs
pointing them to the wrong directory for distfiles to be downloaded and
placed in for the emerge to work when the
Upstream is dead.
Package does not support openssl-1.1, significant change to package.
Removal in 30 days.
On 12/30/18 1:06 AM, Zac Medico wrote:
> On 12/30/18 12:44 AM, Michał Górny wrote:
>> On Sat, 2018-12-29 at 04:49 -0800, Zac Medico wrote:
>>> In order to prevent failed unshare calls from corrupting the state
>>> of an essential process, validate the relevant unshare call in a
>>> short-lived
On 12/30/18 12:44 AM, Michał Górny wrote:
> On Sat, 2018-12-29 at 04:49 -0800, Zac Medico wrote:
>> In order to prevent failed unshare calls from corrupting the state
>> of an essential process, validate the relevant unshare call in a
>> short-lived subprocess. An unshare call is considered valid
On Sat, 2018-12-29 at 04:49 -0800, Zac Medico wrote:
> In order to prevent failed unshare calls from corrupting the state
> of an essential process, validate the relevant unshare call in a
> short-lived subprocess. An unshare call is considered valid if it
> successfully executes in a short-lived
