[gentoo-dev] Packaging changes in LLVM 10
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
Re: [gentoo-dev] Packaging changes in LLVM 10
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.
Re: [gentoo-dev] Packaging changes in LLVM 10
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
[gentoo-dev] Re: Packaging changes in LLVM 10
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.
[gentoo-dev] [PATCH] toolchain.eclass: fix cygwinports patching
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
Re: [gentoo-dev] [PATCH] toolchain.eclass: fix cygwinports patching
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
Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches
> > > > 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] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches
> 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.
[gentoo-dev] Last rites: python2-specific virtual/python-*
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
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: kde5.eclass and kde5-functions.eclass
kde5.eclass: Mark @DEAD for removal kde5-functions.eclass: Mark @DEAD for removal No consumers left in Gentoo ebuild repository.
[gentoo-dev] Packages up for grabs: app-text/gocr
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