Re: [gentoo-dev] Unmasking =dev-libs/openssl-1.1*

2018-12-03 Thread Craig Andrews

On 06.11.2018 12:53, Craig Andrews wrote:

=dev-libs/openssl-1.1* has been masked since 26 Aug 2016 - that's over
2 years ago. I think it's time to talk about dropping the mask.

The tracker issue https://bugs.gentoo.org/592438 currently has 12 open
issues. Some will be closed by tree cleaning.

package.mask also shows a number of packages being masked because
their latest versions require >=dev-libs/openssl-1.1

What's the plan for removing this mask?

Thanks,
~Craig


I think we should make a plan for removing this mask. I'm not saying we 
do it today or tomorrow - but we should do it someday.


Should we set a date for removing the mask? Should the tracker have 0 
issues blocking it? Something else?


Thanks,
~Craig


signature.asc
Description: OpenPGP digital signature


[gentoo-dev] dev-lisp/clozurtecl and the 17.0 profile, was: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

2018-12-03 Thread grozin

(Moving to gentoo-dev)

On Sun, 2 Dec 2018, Michał Górny wrote:

I think that if there's one package that doesn't work with profiles
(compared to the very large number of packages which just work fine),
it's not the profiles but the package being broken (read: doing silly
assumptions).  Therefore, it's not 17.0 profiles being the problem but
the package in question.

Claiming that people doing any change to Gentoo are required to fix all
the problematic packages is just silly.  This is basically saying that
it's fine to add bad quality packages and then demand others to fix them
for you.  People who worked on the profile can fix bugs in the profile.
Don't expect them to pursue whatever broken packages you like just
because they happened to change the fragile conditions under which they
worked.

See bug #672454.

clozurecl compiles and works fine with the upstream-provided compilation 
flags. So, we cannot ask the upstream to solve our problems for us.


clozurecl compiles and works fine (for me this means that it can compile 
maxima and fricas, and they work) in the 13.0 profile. In the 17.0 one, 
its compilation loops forever on ~x86; on ~amd64 it compiles, but does not 
work properly (cannot compile maxima, bug #665364). So, the reason is in 
the new compilation or linking flags introduced in 17.0.


Is it possible to compile one specific package with compilation/linking 
flags closely following the 13.0 ones? How?



That said, if you insist I'll fix this package.  But I'm pretty sure you
won't like my fix.
If after this fix it will be able to compile maxima and fricas, and they 
will work, that would be sufficient for me.


Andrey

Re: [gentoo-dev] dev-lisp/clozurtecl and the 17.0 profile, was: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

2018-12-03 Thread Michał Górny
On Mon, 2018-12-03 at 22:02 +0700, gro...@gentoo.org wrote:
> (Moving to gentoo-dev)
> 
> On Sun, 2 Dec 2018, Michał Górny wrote:
> > I think that if there's one package that doesn't work with profiles
> > (compared to the very large number of packages which just work fine),
> > it's not the profiles but the package being broken (read: doing silly
> > assumptions).  Therefore, it's not 17.0 profiles being the problem but
> > the package in question.
> > 
> > Claiming that people doing any change to Gentoo are required to fix all
> > the problematic packages is just silly.  This is basically saying that
> > it's fine to add bad quality packages and then demand others to fix them
> > for you.  People who worked on the profile can fix bugs in the profile.
> > Don't expect them to pursue whatever broken packages you like just
> > because they happened to change the fragile conditions under which they
> > worked.
> 
> See bug #672454.
> 
> clozurecl compiles and works fine with the upstream-provided compilation 
> flags. So, we cannot ask the upstream to solve our problems for us.
> 
> clozurecl compiles and works fine (for me this means that it can compile 
> maxima and fricas, and they work) in the 13.0 profile. In the 17.0 one, 
> its compilation loops forever on ~x86; on ~amd64 it compiles, but does not 
> work properly (cannot compile maxima, bug #665364). So, the reason is in 
> the new compilation or linking flags introduced in 17.0.
> 
> Is it possible to compile one specific package with compilation/linking 
> flags closely following the 13.0 ones? How?

-fno-PIE, -fno-PIC are two potentially useful options.  Possibly more. 
Once you figure out which of them is necessary, you should tell upstream
to append it instead of relying on unsafe compiler defaults.

> 
> > That said, if you insist I'll fix this package.  But I'm pretty sure you
> > won't like my fix.
> 
> If after this fix it will be able to compile maxima and fricas, and they 
> will work, that would be sufficient for me.
> 

No.  After this fix it will be gone, and people will be able to compile
maxima and fricas using a working clisp compiler.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-mathematics/reduce

2018-12-03 Thread grozin

# Andrey Grozin  (03 Dec 2018)
# Masked since 2016.
# Removal in 30 days. Bug #671242.
=sci-mathematics/reduce-20110414-r1




Re: [gentoo-dev] up for grabs: www-misc/zoneminder

2018-12-03 Thread Victor Kustov


On Sun, 02 Dec 2018 23:47:48 +0100
"Andreas K. Huettel"  wrote:

> www-misc/zoneminder is up for grabs since I dont use it anymore and
> have no time for maintaining it...
> 

I will take it.

-- 
  С уважением,|  Best regards,
  Виктор Кустов   |  Victor Kustov
  XMPP: ktr...@jabber.ru
  I use FREE operation system: 4.14.67-calculate GNU/Linux
  up 9 weeks, 3 days, 4 hours, 19 minutes


pgpZBcdg1GlFR.pgp
Description: Цифровая подпись OpenPGP