Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

"Walter Dnes" writes: > And what happens when 128-bit cpus debut? /lib128? In this case CHOST makes more sense. From my understanding, the Exherbo approach is the cleanest. Benda

Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

On Wed, Aug 02, 2017 at 03:25:01PM -0400, Mike Gilbert wrote > On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth wrote: > > Mike Gilbert wrote: > >> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote: > >>> If this already was discussed then

Re: [gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0

On 8/2/17 5:00 PM, Mike Gilbert wrote: > On Wed, Aug 2, 2017 at 4:52 PM, Anthony G. Basile wrote: >> Hi everyone, >> >> Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for >> gcc's source code. With gcc-6.4.0 however, they only provide .gz and >> .xz. Our

Re: [gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0

On Wed, Aug 2, 2017 at 4:52 PM, Anthony G. Basile wrote: > Hi everyone, > > Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for > gcc's source code. With gcc-6.4.0 however, they only provide .gz and > .xz. Our toolchain.eclass is written only for .bz2.

[gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0

Hi everyone, Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for gcc's source code. With gcc-6.4.0 however, they only provide .gz and .xz. Our toolchain.eclass is written only for .bz2. I'd like to commit the attached patch to deal with this change. A better fix would

Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

On śro, 2017-08-02 at 19:07 +, Martin Vaeth wrote: > Mike Gilbert wrote: > > On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote: > > > If this already was discussed then sorry for the noise: > > > > > > What is the rationale for merging lib32 with lib? >

Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth wrote: > Mike Gilbert wrote: >> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote: >>> If this already was discussed then sorry for the noise: >>> >>> What is the rationale for merging lib32 with

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Mike Gilbert wrote: > On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote: >> If this already was discussed then sorry for the noise: >> >> What is the rationale for merging lib32 with lib? >> Wouldn't it be somewhat cleaner to have a completely >> split

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

On Wed, 02 Aug 2017 17:51:43 +, Martin Vaeth wrote: > Michał Górny wrote: >> >> What are your thoughts? > > If this already was discussed then sorry for the noise: > > What is the rationale for merging lib32 with lib? > Wouldn't it be somewhat cleaner to have a

Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote: > Michał Górny wrote: >> >> What are your thoughts? > > If this already was discussed then sorry for the noise: > > What is the rationale for merging lib32 with lib? > Wouldn't it be somewhat cleaner to have

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Michał Górny wrote: > > What are your thoughts? If this already was discussed then sorry for the noise: What is the rationale for merging lib32 with lib? Wouldn't it be somewhat cleaner to have a completely split structure lib64 lib32 libx32 (possibly) lib

Re: [gentoo-dev] libressl blocker

On 08/02/2017 05:55 PM, James Cloos wrote: > Bug 626298 should block 561854 (the LibreSSL tracker). > > Could someone with the required perms mark it so? > > Thanks, > > -JimC Done, next time just ask the bug reporter (hint:: it's me ;) ) -- Toralf PGP 23217DA7 9B888F45 signature.asc

[gentoo-dev] New SYMLINK_LIB=no migration tool for review

Hi, everyone. I've finally gotten around to writing a new tool for migrating amd64 systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib- migration [2] repository along with a README. Please review it and give it more testing. The tool has a few advantages over the one attached to the

[gentoo-dev] libressl blocker

Bug 626298 should block 561854 (the LibreSSL tracker). Could someone with the required perms mark it so? Thanks, -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6

Re: [gentoo-dev] New eclass: opam.eclass

> > > > > "${pkg}.install" || die > > > done > > > } > > > > > > opam_src_install() { > > > opam-install "${PN}" > > > # Handle opam putting doc in a subdir > > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then > > > > Is PN always the correct subdirectory

Re: [gentoo-dev] New eclass: opam.eclass

On Tue, 25 Jul 2017 16:18:10 +0200 Michał Górny wrote: > On pon, 2017-07-24 at 17:20 +0200, Alexis Ballier wrote: > > # Copyright 1999-2017 Gentoo Foundation > > # Distributed under the terms of the GNU General Public License v2 > > > > # @ECLASS: opam.eclass > > #

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On śro, 2017-08-02 at 00:30 -0700, Zac Medico wrote: > On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: > > Enable the multilib-strict feature necessary for Portage to detect > > ebuilds not respecting libdir for libraries. Since those issues were > > reliably fixed over

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: > Enable the multilib-strict feature necessary for Portage to detect > ebuilds not respecting libdir for libraries. Since those issues were > reliably fixed over the years and we're nearing the removal of 'lib' > symlink, I