[gentoo-dev] Packages up for grabs: app-text/gocr

2020-03-16 Thread Jonas Stein
Dear all

the following packages are up for grabs:

app-text/gocr

after removing the TeX Project from the maintainer list.
The package is no LaTeX package.
https://packages.gentoo.org/packages/app-text/gocr

There is an open bump request
https://bugs.gentoo.org/688656
and two very old tickets.

Upstream:
https://www-e.ovgu.de/jschulen/ocr/index.html

-- 
Best,
Jonas











































signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: kde5.eclass and kde5-functions.eclass

2020-03-16 Thread Andreas Sturmlechner
kde5.eclass: Mark @DEAD for removal
kde5-functions.eclass: Mark @DEAD for removal

No consumers left in Gentoo ebuild repository.






Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread James Le Cuirot
On Mon, 16 Mar 2020 22:15:32 +0100
"Andreas K. Huettel"  wrote:

> > > 
> > > https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track
> > > -keywords?expand=1  
> > That's kind of what ALLARCHES is for although IIRC the rules state that
> > packages should still be initially keyworded in the usual way. Other
> > distros do "noarch" though so the idea isn't without precedent.  
> 
> It was a long discussion to get ALLARCHES finalized and accepted, and now 
> barely anyone is using it. (Most arch teams never bothered to adapt their 
> workflow.) Maybe we should do that for a start? 

We did use it for Java while I was around. I even wrote a policy page
about it. It would probably still be used if there was anything much
happening with Java at the moment.

https://wiki.gentoo.org/wiki/Project:Java/Stabilization_Policy

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9wapE19Abm.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: python2-specific virtual/python-*

2020-03-16 Thread Michał Górny
Note that this goes to package.deprecated, rather than package.mask. 
These are virtuals, so they don't really impact users, and there's
really no point to make Portage complain about them being installed.

# Michał Górny  (2020-03-16)
# Virtuals for Python 2 backports.  Mostly obsolete, and some of them
# are really confusing.  Use $(python_gen_cond_dep ...) instead
# if your package still needs to support Python 2 (or remove it
# for Python 3 only packages).
virtual/python-backports_abc
virtual/python-enum34
virtual/python-funcsigs
virtual/python-futures
virtual/python-ipaddress
virtual/python-pathlib
virtual/python-singledispatch
virtual/python-typing
virtual/python-unittest-mock

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread Andreas K. Huettel
> Perhaps we could write a tool that
> looks up newer versions of installed ebuilds that have dropped keywords
> for a given arch and report which dependencies also need keywording. I
> guess we don't have something like that?

True, keeping track of long-running stable requests with complicated lists is 
a serious pain. Also true, additional automation could help here. 

In the end this boils down to the question, can we do something better than 
bugzilla for stabilization and keywording tracking? A dedicated webapp (which 
still needs to be integrated with bugzilla somehow to process blockers)?

Obviously this is work. I am tempted to suggest Google Summer of Code, except 
that experience tells me that's the fastest way to get a half-functional pile 
of code that never goes into production. Any better ideas?

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


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


Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread Andreas K. Huettel
> > 
> > https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track
> > -keywords?expand=1
> That's kind of what ALLARCHES is for although IIRC the rules state that
> packages should still be initially keyworded in the usual way. Other
> distros do "noarch" though so the idea isn't without precedent.

It was a long discussion to get ALLARCHES finalized and accepted, and now 
barely anyone is using it. (Most arch teams never bothered to adapt their 
workflow.) Maybe we should do that for a start? 

Anyway, ALLARCHES only affects stabilization, not keyword requests.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


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


Re: [gentoo-dev] [PATCH] toolchain.eclass: fix cygwinports patching

2020-03-16 Thread Sergei Trofimovich
On Mon, 16 Mar 2020 18:41:02 +0100
ha...@gentoo.org wrote:

> From: Michael Haubenwallner 
> 
> Introduction of tc_apply_patches dropped patch dir, per
> commit bd758f25a82460f6e7011314f9fb7923864e9e1e
> 
> Signed-off-by: Michael Haubenwallner 
> ---
>  eclass/toolchain.eclass | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 9f435921922..7135af0817d 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -646,7 +646,13 @@ do_gcc_CYGWINPORTS_patches() {
>  
>   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
>   # readarray -t is available since bash-4.4 only, #690686
> - local patches=( $(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
> "${d}"/gcc.cygport) )
> + local patches=( $(
> + for p in $(
> + sed -e '1,/PATCH_URI="/d;/"/,$d' < "${d}"/gcc.cygport
> + ); do
> + echo "${d}/${p}"
> + done
> + ) )
>   tc_apply_patches "Applying cygwin port patches ..." ${patches[*]}
>  }

Looks good. Please push it.


-- 

  Sergei



[gentoo-dev] [PATCH] toolchain.eclass: fix cygwinports patching

2020-03-16 Thread haubi
From: Michael Haubenwallner 

Introduction of tc_apply_patches dropped patch dir, per
commit bd758f25a82460f6e7011314f9fb7923864e9e1e

Signed-off-by: Michael Haubenwallner 
---
 eclass/toolchain.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 9f435921922..7135af0817d 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -646,7 +646,13 @@ do_gcc_CYGWINPORTS_patches() {
 
local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
# readarray -t is available since bash-4.4 only, #690686
-   local patches=( $(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
"${d}"/gcc.cygport) )
+   local patches=( $(
+   for p in $(
+   sed -e '1,/PATCH_URI="/d;/"/,$d' < "${d}"/gcc.cygport
+   ); do
+   echo "${d}/${p}"
+   done
+   ) )
tc_apply_patches "Applying cygwin port patches ..." ${patches[*]}
 }
 
-- 
2.24.1




[gentoo-dev] Re: Packaging changes in LLVM 10

2020-03-16 Thread Nikos Chantziaras

On 16/03/2020 14:37, Gerion Entrup wrote:

when I compile LLVM for myself, I also always choose SHARED_LIBS simply
because of RAM usage when linking the libraries. In the past, I was not
able to link the single library on my 16 GB machine (I have not tested
it now and this could be dependent on other circumstances). What is the
current expected RAM usage for LLVM 10?


Sounds something else was wrong perhaps. I'm on 16GB RAM, 10GB of which 
are for the tmpfs I use for portage, and even with that it builds fine 
with -j4.





Re: [gentoo-dev] Packaging changes in LLVM 10

2020-03-16 Thread Michał Górny
On Mon, 2020-03-16 at 13:37 +0100, Gerion Entrup wrote:
> Am Montag, 16. März 2020, 09:23:49 CET schrieb Michał Górny:
> > Hi,
> > 
> > Since 10.0.0 final is around the corner, I'd like to take a minute to
> > inform developers of packaging changes in Gentoo that affect its
> > revdeps.  Following frequently repeated requests from Gentoo developers
> > and users, LLVM 10 is stopping to use BUILD_SHARED_LIBS=ON, i.e. split
> > shared libraries.  Instead, we'll be using the 'dylib' model recommended
> > upstream.
> > 
> > This means that sys-devel/{llvm,clang} no longer install those small
> > libLLVM*.so and libclang*.so files.  Instead, one big libLLVM-${ver}.so
> > and libclang-cpp.so.${sover} are installed (yes, I know this historical
> > inconsistency sucks).  Also note that Clang continues installing
> > libclang.so which is a *C* (not C++) library.
> > 
> > Most of LLVM revdeps should not have problem with LLVM dylib, as it was
> > the de-facto standard on other distros.  llvm-config handles it
> > transparently.  If you're dealing with a custom build system that
> > doesn't handle it, it's as simple as trying '-lLLVM' first (note that
> > you will '-L' due to slotting).
> > 
> > Clang revdeps may have trouble with clang-cpp library since it's
> > a fairly recent addition.  Again, the solution is simple: '-lclang-cpp'
> > (repeating: do not confuse it with -lclang which is a different library
> > for historical reasons).
> > 
> > sys-devel/lld does not install any libraries anymore.  If you ever need
> > them, please ping me and we'll try to come up with something upstream.
> > 
> > dev-util/lldb installs liblldb.so.  However, I'm not familiar with that
> > library and I don't know if it has any consumers.
> > 
> > If you need any help, please don't hesitate to ping me.
> 
> Hi,
> 
> when I compile LLVM for myself, I also always choose SHARED_LIBS simply
> because of RAM usage when linking the libraries. In the past, I was not
> able to link the single library on my 16 GB machine (I have not tested
> it now and this could be dependent on other circumstances). What is the
> current expected RAM usage for LLVM 10?
> 

To be honest, I don't know.  I have 8G here, and it's entirely
sufficient for -j3 build.  I don't experience major linking problems
as I used to, so things might have improved on binutils end.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Packaging changes in LLVM 10

2020-03-16 Thread Gerion Entrup
Am Montag, 16. März 2020, 09:23:49 CET schrieb Michał Górny:
> Hi,
> 
> Since 10.0.0 final is around the corner, I'd like to take a minute to
> inform developers of packaging changes in Gentoo that affect its
> revdeps.  Following frequently repeated requests from Gentoo developers
> and users, LLVM 10 is stopping to use BUILD_SHARED_LIBS=ON, i.e. split
> shared libraries.  Instead, we'll be using the 'dylib' model recommended
> upstream.
> 
> This means that sys-devel/{llvm,clang} no longer install those small
> libLLVM*.so and libclang*.so files.  Instead, one big libLLVM-${ver}.so
> and libclang-cpp.so.${sover} are installed (yes, I know this historical
> inconsistency sucks).  Also note that Clang continues installing
> libclang.so which is a *C* (not C++) library.
> 
> Most of LLVM revdeps should not have problem with LLVM dylib, as it was
> the de-facto standard on other distros.  llvm-config handles it
> transparently.  If you're dealing with a custom build system that
> doesn't handle it, it's as simple as trying '-lLLVM' first (note that
> you will '-L' due to slotting).
> 
> Clang revdeps may have trouble with clang-cpp library since it's
> a fairly recent addition.  Again, the solution is simple: '-lclang-cpp'
> (repeating: do not confuse it with -lclang which is a different library
> for historical reasons).
> 
> sys-devel/lld does not install any libraries anymore.  If you ever need
> them, please ping me and we'll try to come up with something upstream.
> 
> dev-util/lldb installs liblldb.so.  However, I'm not familiar with that
> library and I don't know if it has any consumers.
> 
> If you need any help, please don't hesitate to ping me.

Hi,

when I compile LLVM for myself, I also always choose SHARED_LIBS simply
because of RAM usage when linking the libraries. In the past, I was not
able to link the single library on my 16 GB machine (I have not tested
it now and this could be dependent on other circumstances). What is the
current expected RAM usage for LLVM 10?

Best,
Gerion


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


[gentoo-dev] Packaging changes in LLVM 10

2020-03-16 Thread Michał Górny
Hi,

Since 10.0.0 final is around the corner, I'd like to take a minute to
inform developers of packaging changes in Gentoo that affect its
revdeps.  Following frequently repeated requests from Gentoo developers
and users, LLVM 10 is stopping to use BUILD_SHARED_LIBS=ON, i.e. split
shared libraries.  Instead, we'll be using the 'dylib' model recommended
upstream.

This means that sys-devel/{llvm,clang} no longer install those small
libLLVM*.so and libclang*.so files.  Instead, one big libLLVM-${ver}.so
and libclang-cpp.so.${sover} are installed (yes, I know this historical
inconsistency sucks).  Also note that Clang continues installing
libclang.so which is a *C* (not C++) library.

Most of LLVM revdeps should not have problem with LLVM dylib, as it was
the de-facto standard on other distros.  llvm-config handles it
transparently.  If you're dealing with a custom build system that
doesn't handle it, it's as simple as trying '-lLLVM' first (note that
you will '-L' due to slotting).

Clang revdeps may have trouble with clang-cpp library since it's
a fairly recent addition.  Again, the solution is simple: '-lclang-cpp'
(repeating: do not confuse it with -lclang which is a different library
for historical reasons).

sys-devel/lld does not install any libraries anymore.  If you ever need
them, please ping me and we'll try to come up with something upstream.

dev-util/lldb installs liblldb.so.  However, I'm not familiar with that
library and I don't know if it has any consumers.

If you need any help, please don't hesitate to ping me.

-- 
Best regards,
Michał Górny



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