[gentoo-dev] [PATCH] elisp.eclass: Drop support for EAPIs 0 to 3.

2019-07-15 Thread Ulrich Müller
Signed-off-by: Ulrich Müller 
---
 eclass/elisp.eclass | 36 +---
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index 55635398d54..c885345a7a8 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: elisp.eclass
@@ -9,7 +9,7 @@
 # Jeremy Maitin-Shepard 
 # Christian Faulhammer 
 # Ulrich Müller 
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 4 5 6 7
 # @BLURB: Eclass for Emacs Lisp packages
 # @DESCRIPTION:
 #
@@ -67,21 +67,17 @@
 
 inherit elisp-common
 case ${EAPI:-0} in
-   0|1|2|3|4|5) inherit epatch ;;
+   4|5) inherit epatch ;;
6|7) ;;
-   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-case ${EAPI:-0} in
-   0|1) EXPORT_FUNCTIONS src_{unpack,compile,install} \
-   pkg_{setup,postinst,postrm} ;;
-   *) EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
-   pkg_{setup,postinst,postrm} ;;
-esac
+EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
+   pkg_{setup,postinst,postrm}
 
 RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
-case ${EAPI:-0} in
-   0|1|2|3|4|5|6) DEPEND="${RDEPEND}" ;;
+case ${EAPI} in
+   4|5|6) DEPEND="${RDEPEND}" ;;
*) BDEPEND="${RDEPEND}" ;;
 esac
 
@@ -102,8 +98,7 @@ elisp_pkg_setup() {
 # @FUNCTION: elisp_src_unpack
 # @DESCRIPTION:
 # Unpack the sources; also handle the case of a single *.el file in
-# WORKDIR for packages distributed that way.  For EAPIs without
-# src_prepare, call elisp_src_prepare.
+# WORKDIR for packages distributed that way.
 
 elisp_src_unpack() {
[[ -n ${A} ]] && unpack ${A}
@@ -112,11 +107,6 @@ elisp_src_unpack() {
mv ${P}.el ${PN}.el || die
[[ -d ${S} ]] || S=${WORKDIR}
fi
-
-   case ${EAPI:-0} in
-   0|1) [[ -d ${S} ]] && cd "${S}"
-   elisp_src_prepare ;;
-   esac
 }
 
 # @FUNCTION: elisp_src_prepare
@@ -136,15 +126,15 @@ elisp_src_prepare() {
else
die "Cannot find ${patch}"
fi
-   case ${EAPI:-0} in
-   0|1|2|3|4|5) epatch "${file}" ;;
+   case ${EAPI} in
+   4|5) epatch "${file}" ;;
*) eapply "${file}" ;;
esac
done
 
# apply any user patches
-   case ${EAPI:-0} in
-   0|1|2|3|4|5) epatch_user ;;
+   case ${EAPI} in
+   4|5) epatch_user ;;
*) eapply_user ;;
esac
 
-- 
2.22.0


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

Hi,

Perhaps it's just me not being in the loop, but what exactly is the 
problem we're trying to solve here?



I'm personally using a separate /usr (On numerous systems) and other 
than one problem I've encountered this isn't actually currently an issue 
for me, and the reason this specific case was an issue was due to one 
single tool (which unfortunately I can't remember now) having been 
installed into /usr where I'd personally expect it to go into /.


Kind Regards,
Jaco

On 2019/07/15 01:50, Mike Gilbert wrote:


This series introduces the global USE flag 'split-usr' to control
whether binaries and libraries are split into separate / and /usr
directories, or if they are always installed in /usr. This is a step
toward making merged /usr workable on Gentoo for the average user.

This USE flag is already being used by some packages, including
sys-apps/baselayout and sys-apps/systemd.

This series also moves the gen_usr_ldscript function to a new eclass,
and makes it a noop on most systems when split-usr is enabled. Moving
it to a new eclass allows us to avoid adding IUSE="split-usr" to every
ebuild that uses toolchain-funcs.eclass.

Mike Gilbert (6):
   profiles: add global USE flag 'split-usr'
   profiles: enable USE="split-usr" in base
   usr-ldscript.eclass: copy gen_usr_ldscript from toolchain-funcs.eclass
   usr-ldscript.eclass: return early if USE=split-usr is disabled
   Convert ebuilds to inherit usr-ldscript
   toolchain-funcs.eclass: deprecate gen_usr_ldscript

  app-accessibility/brltty/brltty-5.2-r1.ebuild |   2 +-
  app-accessibility/brltty/brltty-6.0-r1.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.6-r11.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.7.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.8.ebuild |   2 +-
  app-arch/bzip2/bzip2-.ebuild  |   2 +-
  app-arch/xz-utils/xz-utils-5.2.4-r2.ebuild|   2 +-
  app-arch/xz-utils/xz-utils-5.2.4-r3.ebuild|   2 +-
  app-arch/xz-utils/xz-utils-.ebuild|   2 +-
  dev-libs/expat/expat-2.2.6.ebuild |   2 +-
  dev-libs/expat/expat-2.2.7.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.110.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.111.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.112.ebuild |   2 +-
  dev-libs/libaio/libaio-.ebuild|   2 +-
  dev-libs/libedit/libedit-20130712.3.1.ebuild  |   2 +-
  dev-libs/libedit/libedit-20170329.3.1.ebuild  |   2 +-
  dev-libs/libiconv/libiconv-1.14-r1.ebuild |   2 +-
  dev-libs/libiconv/libiconv-1.15.ebuild|   2 +-
  dev-libs/libintl/libintl-0.19.7.ebuild|   2 +-
  dev-libs/libintl/libintl-0.19.8.1.ebuild  |   2 +-
  dev-libs/libintl/libintl-0.20.1.ebuild|   2 +-
  dev-libs/libpcre/libpcre-8.41-r1.ebuild   |   2 +-
  dev-libs/libpcre/libpcre-8.42.ebuild  |   2 +-
  dev-libs/libpcre/libpcre-8.43.ebuild  |   2 +-
  dev-libs/libpcre2/libpcre2-10.32.ebuild   |   2 +-
  dev-libs/libpcre2/libpcre2-10.33.ebuild   |   2 +-
  .../libpwquality/libpwquality-1.4.0.ebuild|   2 +-
  .../libusb-compat-0.1.5-r2.ebuild |   2 +-
  .../libusb-compat-0.1.5-r3.ebuild |   2 +-
  dev-libs/libusb/libusb-1.0.19-r1.ebuild   |   2 +-
  dev-libs/libusb/libusb-1.0.21.ebuild  |   2 +-
  dev-libs/libusb/libusb-1.0.22.ebuild  |   2 +-
  dev-libs/lzo/lzo-2.10.ebuild  |   2 +-
  eclass/toolchain-funcs.eclass |  15 +-
  eclass/usr-ldscript.eclass| 160 ++
  .../iptables/iptables-1.6.1-r3.ebuild |   2 +-
  .../iptables/iptables-1.6.2-r2.ebuild |   2 +-
  .../iptables/iptables-1.8.2-r2.ebuild |   2 +-
  .../iptables/iptables-1.8.3-r1.ebuild |   2 +-
  net-libs/libmnl/libmnl-1.0.3-r1.ebuild|   2 +-
  net-libs/libmnl/libmnl-1.0.4.ebuild   |   2 +-
  net-libs/libnftnl/libnftnl-1.0.8-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.1-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.2-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.3.ebuild   |   2 +-
  net-libs/libtirpc/libtirpc-1.0.2-r1.ebuild|   2 +-
  net-libs/libtirpc/libtirpc-1.0.3.ebuild   |   2 +-
  net-libs/libtirpc/libtirpc-1.1.4.ebuild   |   2 +-
  profiles/base/make.defaults   |   4 +
  profiles/use.desc |   1 +
  sys-apps/acl/acl-2.2.52-r1.ebuild |   2 +-
  sys-apps/acl/acl-2.2.53.ebuild|   2 +-
  sys-apps/attr/attr-2.4.47-r2.ebuild   |   2 +-
  sys-apps/attr/attr-2.4.48-r2.ebuild   |   2 +-
  sys-apps/attr/attr-2.4.48-r3.ebuild   |   2 +-
  sys-apps/dmapi/dmapi-2.2.12-r1.ebuild |   2 +-
  sys-apps/keyutils/keyutils-1.5.11-r1.ebuild   |   2 +-
  sys-apps/keyutils/keyutils-1.5.9-r4.ebuild|   2 +-
  sys-apps/keyutils/keyutils-1.6.ebuild |   2 +-
  sys-apps/openrc/openrc-0.34.11.ebuild |   2 +-
  sys-a

[gentoo-dev] News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0

2019-07-15 Thread Marek Szuba
Hello,

Please find attached a news item warning the users of net-p2p/syncthing
that version 1.2.0 and newer do not interoperate with version 0.14.45
and older. I have included the same warning in the 1.2.0 ebuild, that
said I believe this deserves a news item because a) it could affect
mission-critical file-replication set-ups, and b) old versions panic and
shut down when fed incompatible data.

Thank you in advance for any and all feedback!


-- 
MS
Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older
Author: Marek Szuba 
Posted: 2019-07-18
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-p2p/syncthing

Starting with version 1.2.0, Syncthing always uses large, variable-sized,
blocks to index and transfer files larger than 256 MiB [1]. Syncthing
version 0.14.45 and older will initially appear to accept files scanned
with large blocks, but will later panic during some internal file
operations. Do NOT enable large blocks in clusters with devices still
on v0.14.45 or older, e.g. Debian Stretch servers using official packages.

[1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Marek Szuba
On 2019-07-15 12:38, Jaco Kroon wrote:

> I'm personally using a separate /usr (On numerous systems) and other
> than one problem I've encountered this isn't actually currently an issue
> for me, and the reason this specific case was an issue was due to one
> single tool (which unfortunately I can't remember now) having been
> installed into /usr where I'd personally expect it to go into /.

The issue is not with *split* /usr, it's with the scenario currently
being adopted by many Linux distros (e.g. Fedora or Debian) in which
/bin, /sbin, /lib and /lib64 are symlinks to respective subdirectories
of /usr. The purpose of the changes at hand is, as described by floppym
in his initial post, to pave the way towards making merged /usr workable
on Gentoo for the average user.

-- 
MS



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [PATCH] eclass/cmake-utils.eclass: restrict rpath hack to Prefix/rpath

2019-07-15 Thread Michael Palimaka

On 7/12/19 3:14 AM, hero...@gentoo.org wrote:

From: Benda Xu 

   Prefix/standalone does not need it.
---
  eclass/cmake-utils.eclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ea1858e9735f..109b584afb39 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -612,7 +612,7 @@ cmake-utils_src_configure() {
fi
fi
  
-	if [[ ${EPREFIX} ]]; then

+   if use prefix-guest; then
cat >> "${build_rules}" <<- _EOF_ || die
# in Prefix we need rpath and must ensure cmake gets 
our default linker path
# right ... except for Darwin hosts



This seems to break non-prefix builds, as the prefix-guest USE flag will 
not exist.




[gentoo-dev] [PATCH] subversion.eclass: Support EAPI 7, drop EAPIs 0 to 3.

2019-07-15 Thread Ulrich Müller
Closes: https://bugs.gentoo.org/678344
Signed-off-by: Ulrich Müller 
---
 eclass/subversion.eclass | 44 
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/eclass/subversion.eclass b/eclass/subversion.eclass
index d9f9daf7eb6e..ab707027a502 100644
--- a/eclass/subversion.eclass
+++ b/eclass/subversion.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: subversion.eclass
@@ -6,35 +6,39 @@
 # Akinori Hattori 
 # @AUTHOR:
 # Original Author: Akinori Hattori 
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
-# @BLURB: The subversion eclass is written to fetch software sources from 
subversion repositories
+# @SUPPORTED_EAPIS: 4 5 6 7
+# @BLURB: Fetch software sources from subversion repositories
 # @DESCRIPTION:
 # The subversion eclass provides functions to fetch, patch and bootstrap
 # software sources from subversion repositories.
 
-inherit eutils
-
 ESVN="${ECLASS}"
 
-case "${EAPI:-0}" in
-   0|1)
-   EXPORT_FUNCTIONS src_unpack pkg_preinst
-   DEPEND="dev-vcs/subversion"
-   ;;
-   2|3|4|5)
+case ${EAPI:-0} in
+   4|5)
+   inherit eutils
EXPORT_FUNCTIONS src_unpack src_prepare pkg_preinst
-   DEPEND="|| ( dev-vcs/subversion[http] 
dev-vcs/subversion[webdav-neon] dev-vcs/subversion[webdav-serf] )"
;;
-   6)
+   6|7)
+   inherit estack
EXPORT_FUNCTIONS src_unpack pkg_preinst
-   DEPEND="|| ( dev-vcs/subversion[http] 
dev-vcs/subversion[webdav-neon] dev-vcs/subversion[webdav-serf] )"
;;
*)
-   die "EAPI ${EAPI} is not supported in subversion.eclass"
+   die "${ESVN}: EAPI ${EAPI:-0} is not supported"
;;
 esac
 
-DEPEND+=" net-misc/rsync"
+DEPEND="|| (
+   dev-vcs/subversion[http]
+   dev-vcs/subversion[webdav-neon]
+   dev-vcs/subversion[webdav-serf]
+   )
+   net-misc/rsync"
+
+case ${EAPI} in
+   4|5|6) ;;
+   *) BDEPEND="${DEPEND}"; DEPEND="" ;;
+esac
 
 # @ECLASS-VARIABLE: ESVN_STORE_DIR
 # @DESCRIPTION:
@@ -434,12 +438,9 @@ subversion_wc_info() {
 
 # @FUNCTION: subversion_src_unpack
 # @DESCRIPTION:
-# Default src_unpack. Fetch and, in older EAPIs, bootstrap.
+# Default src_unpack. Fetch.
 subversion_src_unpack() {
subversion_fetch || die "${ESVN}: unknown problem occurred in 
subversion_fetch."
-   if has "${EAPI:-0}" 0 1; then
-   subversion_bootstrap || die "${ESVN}: unknown problem occurred 
in subversion_bootstrap."
-   fi
 }
 
 # @FUNCTION: subversion_src_prepare
@@ -458,10 +459,9 @@ subversion_src_prepare() {
 # want the logs to stick around if packages are uninstalled without messing 
with
 # config protection.
 subversion_pkg_preinst() {
-   has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
local pkgdate=$(date "+%Y%m%d %H:%M:%S")
if [[ -n ${ESCM_LOGDIR} ]]; then
-   local dir="${EROOT}/${ESCM_LOGDIR}/${CATEGORY}"
+   local dir="${EROOT%/}${ESCM_LOGDIR}/${CATEGORY}"
if [[ ! -d ${dir} ]]; then
mkdir -p "${dir}" || eerror "Failed to create '${dir}' 
for logging svn revision"
fi
-- 
2.22.0


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

Hi Marek,

Perhaps I need to re-ask the question this way:

What's the motivation for "merging" / and /usr?

I've seen arguments that it's a historic split, and to an extent this is 
true, however, having critical system recovery (and basic boot) stuff in 
/, on as small as possible a partition, with the bulk of the system on 
/usr makes a lot of sense for me.


Kind Regards,
Jaco


On 2019/07/15 14:28, Marek Szuba wrote:

On 2019-07-15 12:38, Jaco Kroon wrote:


I'm personally using a separate /usr (On numerous systems) and other
than one problem I've encountered this isn't actually currently an issue
for me, and the reason this specific case was an issue was due to one
single tool (which unfortunately I can't remember now) having been
installed into /usr where I'd personally expect it to go into /.

The issue is not with *split* /usr, it's with the scenario currently
being adopted by many Linux distros (e.g. Fedora or Debian) in which
/bin, /sbin, /lib and /lib64 are symlinks to respective subdirectories
of /usr. The purpose of the changes at hand is, as described by floppym
in his initial post, to pave the way towards making merged /usr workable
on Gentoo for the average user.



Re: [gentoo-dev] [PATCH 1/6] profiles: add global USE flag 'split-usr'

2019-07-15 Thread William Hubbs
On Mon, Jul 15, 2019 at 05:29:28AM +0200, Michał Górny wrote:
> On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
> > Signed-off-by: Mike Gilbert 
> > ---
> >  profiles/use.desc | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/profiles/use.desc b/profiles/use.desc
> > index fc19bbd0bbaa..ec5d4d6bc594 100644
> > --- a/profiles/use.desc
> > +++ b/profiles/use.desc
> > @@ -299,6 +299,7 @@ source - Zip the sources and install them
> >  sox - Add support for Sound eXchange (SoX)
> >  speex - Add support for the speex audio codec (used for speech)
> >  spell - Add dictionary support
> > +split-usr - Splits /bin and /lib from /usr/bin and /usr/lib
> >  sqlite - Add support for sqlite - embedded sql database
> >  ssl - Add support for SSL/TLS connections (Secure Socket Layer / Transport 
> > Layer Security)
> >  startup-notification - Enable application startup event feedback mechanism
> 
> I have no explicit suggestions right now but this description sounds
> like it's going to magically take care of splitting or merging
> the directories, and AFAIK it doesn't do that.

Mgorny,

you are correct, so the more I think about this, the more I am wondering
about its value as a use flag.

On baselayout you need it, because when the stages are built it sets up
the directories, but after that it does nothing on baselayout. Once we
have 19.0 profiles in the tree and support for older profiles goes away,
you won't need the use flag because this is how all linux builds will be
done.

This should not be taken as a quick way to migrate live systems, we do
not have that yet. I have a script that I am working on for that purpose.

The gen_usr_ldscript function should do nothing on a system which has
the usr merge. Mike told me that you shouldn't check the live filesystem
inside gen_usr_ldscript, so do you know of a better way to check
temporarily than a use flag?

If there is a better way, I would argue that we don't need the use flag
on packages besides baselayout.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Marek Szuba
On 2019-07-15 14:59, Jaco Kroon wrote:

> I've seen arguments that it's a historic split, and to an extent this is
> true, however, having critical system recovery (and basic boot) stuff in
> /, on as small as possible a partition, with the bulk of the system on
> /usr makes a lot of sense for me.

That's one of the reasons, yes. For a more in-depth discussion, see

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

as well as the Fedora feature the above mentions.

-- 
MS



Re: [gentoo-dev] [PATCH 1/6] profiles: add global USE flag 'split-usr'

2019-07-15 Thread Mike Gilbert
On Sun, Jul 14, 2019 at 11:29 PM Michał Górny  wrote:
>
> On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
> > Signed-off-by: Mike Gilbert 
> > ---
> >  profiles/use.desc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/profiles/use.desc b/profiles/use.desc
> > index fc19bbd0bbaa..ec5d4d6bc594 100644
> > --- a/profiles/use.desc
> > +++ b/profiles/use.desc
> > @@ -299,6 +299,7 @@ source - Zip the sources and install them
> >  sox - Add support for Sound eXchange (SoX)
> >  speex - Add support for the speex audio codec (used for speech)
> >  spell - Add dictionary support
> > +split-usr - Splits /bin and /lib from /usr/bin and /usr/lib
> >  sqlite - Add support for sqlite - embedded sql database
> >  ssl - Add support for SSL/TLS connections (Secure Socket Layer / Transport 
> > Layer Security)
> >  startup-notification - Enable application startup event feedback mechanism
>
> I have no explicit suggestions right now but this description sounds
> like it's going to magically take care of splitting or merging
> the directories, and AFAIK it doesn't do that.

Yeah, the wording sucks, and I am open to suggestions. How about
something like this:

Enable behavior to support maintaining /bin and /lib separately from
/usr/bin and /usr/lib.



Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base

2019-07-15 Thread Michael Orlitzky
On 7/14/19 9:56 PM, William Hubbs wrote:
> 
> The ultimate goal is to turn this flag off in the 19.0 profiles, we are
> just preserving the current status in the earlier ones.
> 

So, to be clear: the plan is to force a /usr merge after all?



Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

I have no idea who wrote this:

"The historical justification for a /bin, /sbin and /lib separate from 
/usr no longer applies today." but I strongly disagree.


Again, if /usr goes belly up (which with recent ext4/io bug(s) we've had 
probably about 10 systems already that needed repairing, and at least 5 
more that's pending), this fault would require me to head out to site to 
go and repair where currently due to fsck et al living on / and not on 
/usr I could recover without issues.


We've been unable to track an exact issue, but all of the affected 
systems was running 4.14.X kernels, we've not seen the same corruption 
from 5.0.2 onwards.  So we never filed a bug and simply upgraded kernels.


Further, none of the arguments for merging / and /usr makes any sense 
other than "others have already done this and if we don't follow suite 
we'll get cut off".  Not even the statement about network share of /usr 
makes any sense.  We run completely diskless systems with even / over 
nfs ... so seriously.


Even most of the myths and facts arguments are plainly uneducated.

Essentially what happens now is that an initrd needs to be built to 
contain ALL recovery tools that could possibly be required. Where 
previously, with / being mostly read-only this was still a risk worth 
taking.


Anyway, from the looks of this, this is just another comply or die 
situation, so I'm not seeing that there is much choice or say in this 
matter.  We'll just have to bloat our initrd's even further.  
Fortunately they do get freed post post ... just hoping they'll fit into 
the existing /boot partitions we have on our systems.



Kind Regards,
Jaco Kroon
C.E.O.

*T:* +27 (0)12 021  | *F:* +27 86 648 8561 | *E:* j...@iewc.co.za
*W:* iewc.co.za  | *A:* Unit 201, Building 2B, 
Sunwood Park, Queen's Crescent Lynnwood, Pretoria





Facebook  Twitter 
 Google+ 
 LinkedIn 



 

This email and all contents are subject to the following disclaimer: 
View Disclaimer 


On 2019/07/15 16:22, Marek Szuba wrote:

On 2019-07-15 14:59, Jaco Kroon wrote:


I've seen arguments that it's a historic split, and to an extent this is
true, however, having critical system recovery (and basic boot) stuff in
/, on as small as possible a partition, with the bulk of the system on
/usr makes a lot of sense for me.

That's one of the reasons, yes. For a more in-depth discussion, see

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

as well as the Fedora feature the above mentions.

))/io


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Michael Orlitzky
On 7/15/19 10:45 AM, Jaco Kroon wrote:
> I have no idea who wrote this:
> 
> "The historical justification for a /bin, /sbin and /lib separate from
> /usr no longer applies today." but I strongly disagree.

All of that stuff is written from the perspective of "I feel like doing
it this way in systemd, so I need to post-hoc justify making everyone
else go along with it."


> Again, if /usr goes belly up (which with recent ext4/io bug(s) we've had
> probably about 10 systems already that needed repairing, and at least 5
> more that's pending), this fault would require me to head out to site to
> go and repair where currently due to fsck et al living on / and not on
> /usr I could recover without issues.
> 
> We've been unable to track an exact issue, but all of the affected
> systems was running 4.14.X kernels, we've not seen the same corruption
> from 5.0.2 onwards.  So we never filed a bug and simply upgraded kernels.

Likely https://bugzilla.kernel.org/show_bug.cgi?id=201685



Re: [gentoo-dev] [PATCH 3/6] usr-ldscript.eclass: copy gen_usr_ldscript from toolchain-funcs.eclass

2019-07-15 Thread Mike Gilbert
On Mon, Jul 15, 2019 at 1:41 AM Ulrich Mueller  wrote:
>
> > On Mon, 15 Jul 2019, Mike Gilbert wrote:
>
> > + [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
>
> Wouldn't this be a good time to drop such historical baggage, and
> instead only support EAPIs where ED is defined? (I see the occasional
> EAPI=4 in your list of ebuilds, but nothing older.)

Yes, I suppose that makes sense. I'll send a patch when I have time.



Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base

2019-07-15 Thread Mike Gilbert
On Mon, Jul 15, 2019 at 10:33 AM Michael Orlitzky  wrote:
>
> On 7/14/19 9:56 PM, William Hubbs wrote:
> >
> > The ultimate goal is to turn this flag off in the 19.0 profiles, we are
> > just preserving the current status in the earlier ones.
> >
>
> So, to be clear: the plan is to force a /usr merge after all?
>

I don't anticipate that happening within 2019, so I doubt it would be
turned off in a "19.0" profile.

I think Gentoo developers are rather split on the /usr merge, and I
suspect a council ruling will be necessary if the pro-usr-merge camp
wants to push it through.



Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base

2019-07-15 Thread Mike Gilbert
On Sun, Jul 14, 2019 at 9:49 PM Michael Orlitzky  wrote:
>
> On 7/14/19 7:50 PM, Mike Gilbert wrote:
> >
> > +# Mike Gilbert  (2019-07-14)
> > +# Enable split-usr by default to keep systems working.
> > +USE="${USE} split-usr"
>
> A mandatory USE="keep-working" raises some philosophical red flags for
> me.

Yeah, that wording is bad. Maybe something like:

# Maintain split /usr for existing installs.

> Wouldn't it be better to name the flag "merge-usr" and leave the
> profile alone?

The "split-usr" flag is already being used by a few packages, so I
would like to keep it.

Another way to think about it: in the merged /usr case, ebuilds
generally do not need to do anything special: they can just copy their
files to $prefix (/usr). In the split /usr case, ebuilds need to do
special stuff like passing extra configure flags (--bindir, --libdir),
or calling gen_usr_ldscript to move libraries around.

The "split-usr" USE flag enables this special stuff. Having a
"merged-usr" USE flag would invert the meaning: disable the special
stuff if the flag is enabled. We generally try to avoid inverted flags
like this (a notable exception being the "vanilla" USE flag).

>  (This will be especially bad for the people who start with USE="-*")

As has been previously mentioned, we don't generally recommend this
for people who don't know what they are doing. In any case, I think
they would have already run into problems given that baselayout has
had IUSE="+split-usr" for at least several months.

A possible solution would be to add split-usr to use.force in the base
profile, and un-force it in some new profile we create at a later
date. Do people think this is warranted?



[gentoo-dev] Re: [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Mike Gilbert
On Sun, Jul 14, 2019 at 7:50 PM Mike Gilbert  wrote:
>
> This series introduces the global USE flag 'split-usr' to control
> whether binaries and libraries are split into separate / and /usr
> directories, or if they are always installed in /usr. This is a step
> toward making merged /usr workable on Gentoo for the average user.
>
> This USE flag is already being used by some packages, including
> sys-apps/baselayout and sys-apps/systemd.
>
> This series also moves the gen_usr_ldscript function to a new eclass,
> and makes it a noop on most systems when split-usr is enabled. Moving
> it to a new eclass allows us to avoid adding IUSE="split-usr" to every
> ebuild that uses toolchain-funcs.eclass.

Correction: gen_usr_ldscript becomes a noop when split-usr is
*disabled*. Hopefully that didn't confuse too many people. :)



Re: [gentoo-dev] Re: [PATCH 6/6] toolchain-funcs.eclass: deprecate gen_usr_ldscript

2019-07-15 Thread Mike Gilbert
On Mon, Jul 15, 2019 at 12:18 AM Jonathan Callen  wrote:
>
> On 7/14/19 11:31 PM, Michał Górny wrote:
> > On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
> >> Signed-off-by: Mike Gilbert 
> >> ---
> >>  eclass/toolchain-funcs.eclass | 15 ---
> >>  1 file changed, 4 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> >> index 2e027015c684..7bd90bb4e4a0 100644
> >> --- a/eclass/toolchain-funcs.eclass
> >> +++ b/eclass/toolchain-funcs.eclass
> >> @@ -950,18 +950,11 @@ tc-enables-ssp-all() {
> >>  # @FUNCTION: gen_usr_ldscript
> >>  # @USAGE: [-a] 
> >>  # @DESCRIPTION:
> >> -# This function generate linker scripts in /usr/lib for dynamic
> >> -# libs in /lib.  This is to fix linking problems when you have
> >> -# the .so in /lib, and the .a in /usr/lib.  What happens is that
> >> -# in some cases when linking dynamic, the .a in /usr/lib is used
> >> -# instead of the .so in /lib due to gcc/libtool tweaking ld's
> >> -# library search path.  This causes many builds to fail.
> >> -# See bug #4411 for more info.
> >> -#
> >> -# Note that you should in general use the unversioned name of
> >> -# the library (libfoo.so), as ldconfig should usually update it
> >> -# correctly to point to the latest version of the library present.
> >> +# This function is deprecated. Use the version from
> >> +# usr-ldscript.eclass instead.
> >>  gen_usr_ldscript() {
> >> +ewarn "${FUNCNAME}: Please migrate to usr-ldscript.eclass"
> >> +
> >>  local lib libdir=$(get_libdir) output_format="" auto=false 
> >> suffix=$(get_libname)
> >>  [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
> >>
> >
> > Wouldn't this trigger when both toolchain-funcs and usr-ldscript are
> > inherited, in reverse order?
> >
>
> I thought the same at first, but it looks like it will work because
> usr-ldscript inherits toolchain-funcs and both eclasses have include
> guards, so the toolchain-funcs version will always be overridden by
> usr-ldscript, if the later is inherited at all.

Exactly this. I put some thought into this before writing the patch,
and this is the conclusion I came to.

>  I'm not sure how fragile this construct is, though.

I think a PMS-level change would be necessary for this to break.



Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread William Hubbs
On Mon, Jul 15, 2019 at 10:51:46AM -0400, Michael Orlitzky wrote:
> On 7/15/19 10:45 AM, Jaco Kroon wrote:
> > I have no idea who wrote this:
> > 
> > "The historical justification for a /bin, /sbin and /lib separate from
> > /usr no longer applies today." but I strongly disagree.
> 
> All of that stuff is written from the perspective of "I feel like doing
> it this way in systemd, so I need to post-hoc justify making everyone
> else go along with it."

Also add this:

https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/

In particular, note Rob Landley's response linked in that story.

So, this has nothing to do with systemd at all, please stop conflating
it.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base

2019-07-15 Thread Michael Orlitzky
On 7/15/19 11:22 AM, Mike Gilbert wrote:
> 
> The "split-usr" flag is already being used by a few packages, so I
> would like to keep it.

The merits of the usr-merge notwithstanding, this does make more sense
if the plan is to eventually drop the flag entirely.


>>  (This will be especially bad for the people who start with USE="-*")
> 
> As has been previously mentioned, we don't generally recommend this
> for people who don't know what they are doing. In any case, I think
> they would have already run into problems given that baselayout has
> had IUSE="+split-usr" for at least several months.
> 
> A possible solution would be to add split-usr to use.force in the base
> profile, and un-force it in some new profile we create at a later
> date. Do people think this is warranted?
> 

I understand saying "you're on your own" to people who set USE="-*", but
in practice it's the best-supported way to turn off the
constantly-changing set of maintainers' pet IUSE defaults. I suppose we
can at least agree that some people do it. If there's a way to proceed
that doesn't break their systems by surprise one morning, it'd be the
polite thing to do.



Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Michael Orlitzky
On 7/15/19 11:37 AM, William Hubbs wrote:
> 
> https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/
> 
> In particular, note Rob Landley's response linked in that story.
> 
> So, this has nothing to do with systemd at all, please stop conflating
> it.
> 

That wiki page was copied verbatim from the systemd section, written by
the author of systemd, after he decided to leverage systemd to force the
merge on people.

I'm not even saying it's a bad idea. I'm saying that one dude made the
decision, and then came up with a bunch of obviously-bullshit reasons
why we've been doing it wrong all along and should do it his way
instead. Maybe he's right, but come on: we should be merging /usr for
compatibility with Oracle Solaris 11? Give me a break. Nonsense like
that weakens the overall argument.

I'm just letting Jaco know that his BS detector isn't broken. The
"predictable network interface names" article and others like it follow
the same pattern.



[gentoo-dev] [PATCH 1/2] usr-ldscript.eclass: add EAPI check and drop legacy code

2019-07-15 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/usr-ldscript.eclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eclass/usr-ldscript.eclass b/eclass/usr-ldscript.eclass
index a0fbd7d42ec4..1e631b5a34b7 100644
--- a/eclass/usr-ldscript.eclass
+++ b/eclass/usr-ldscript.eclass
@@ -11,6 +11,11 @@
 if [[ -z ${_USR_LDSCRIPT_ECLASS} ]]; then
 _USR_LDSCRIPT_ECLASS=1
 
+case ${EAPI:-0} in
+   4|5|6|7) ;;
+   *) die "EAPI=${EAPI} is not supported" ;;
+esac
+
 inherit multilib toolchain-funcs
 
 IUSE="split-usr"
@@ -31,7 +36,6 @@ IUSE="split-usr"
 # correctly to point to the latest version of the library present.
 gen_usr_ldscript() {
local lib libdir=$(get_libdir) output_format="" auto=false 
suffix=$(get_libname)
-   [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
 
tc-is-static-only && return
 
-- 
2.22.0




[gentoo-dev] [PATCH 2/2] usr-ldscript.eclass: avoid duplicate slashes in file paths

2019-07-15 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/usr-ldscript.eclass | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/eclass/usr-ldscript.eclass b/eclass/usr-ldscript.eclass
index 1e631b5a34b7..d6ad2173ebc4 100644
--- a/eclass/usr-ldscript.eclass
+++ b/eclass/usr-ldscript.eclass
@@ -85,27 +85,27 @@ gen_usr_ldscript() {
# Ensure /lib/${lib} exists to avoid dangling 
scripts/symlinks.
# This especially is for AIX where $(get_libname) can 
return ".a",
# so /lib/${lib} might be moved to /usr/lib/${lib} (by 
accident).
-   [[ -r ${ED}/${libdir}/${lib} ]] || continue
+   [[ -r ${ED%/}/${libdir}/${lib} ]] || continue
#TODO: better die here?
fi
 
case ${CTARGET:-${CHOST}} in
*-darwin*)
if ${auto} ; then
-   tlib=$(scanmacho -qF'%S#F' 
"${ED}"/usr/${libdir}/${lib})
+   tlib=$(scanmacho -qF'%S#F' 
"${ED%/}"/usr/${libdir}/${lib})
else
-   tlib=$(scanmacho -qF'%S#F' 
"${ED}"/${libdir}/${lib})
+   tlib=$(scanmacho -qF'%S#F' 
"${ED%/}"/${libdir}/${lib})
fi
[[ -z ${tlib} ]] && die "unable to read install_name 
from ${lib}"
tlib=${tlib##*/}
 
if ${auto} ; then
-   mv 
"${ED}"/usr/${libdir}/${lib%${suffix}}.*${suffix#.} "${ED}"/${libdir}/ || die
+   mv 
"${ED%/}"/usr/${libdir}/${lib%${suffix}}.*${suffix#.} "${ED%/}"/${libdir}/ || 
die
# some install_names are funky: they encode a 
version
if [[ ${tlib} != ${lib%${suffix}}.*${suffix#.} 
]] ; then
-   mv 
"${ED}"/usr/${libdir}/${tlib%${suffix}}.*${suffix#.} "${ED}"/${libdir}/ || die
+   mv 
"${ED%/}"/usr/${libdir}/${tlib%${suffix}}.*${suffix#.} "${ED%/}"/${libdir}/ || 
die
fi
-   rm -f "${ED}"/${libdir}/${lib}
+   rm -f "${ED%/}"/${libdir}/${lib}
fi
 
# Mach-O files have an id, which is like a soname, it 
tells how
@@ -115,34 +115,34 @@ gen_usr_ldscript() {
# libdir=/lib because that messes up libtool files.
# Make sure we don't lose the specific version, so just 
modify the
# existing install_name
-   if [[ ! -w "${ED}/${libdir}/${tlib}" ]] ; then
-   chmod u+w "${ED}${libdir}/${tlib}" # needed to 
write to it
+   if [[ ! -w "${ED%/}/${libdir}/${tlib}" ]] ; then
+   chmod u+w "${ED%/}/${libdir}/${tlib}" # needed 
to write to it
local nowrite=yes
fi
install_name_tool \
-id "${EPREFIX}"/${libdir}/${tlib} \
-   "${ED}"/${libdir}/${tlib} || die 
"install_name_tool failed"
-   [[ -n ${nowrite} ]] && chmod u-w 
"${ED}${libdir}/${tlib}"
+   "${ED%/}"/${libdir}/${tlib} || die 
"install_name_tool failed"
+   [[ -n ${nowrite} ]] && chmod u-w 
"${ED%/}/${libdir}/${tlib}"
# Now as we don't use GNU binutils and our linker 
doesn't
# understand linker scripts, just create a symlink.
-   pushd "${ED}/usr/${libdir}" > /dev/null
+   pushd "${ED%/}/usr/${libdir}" > /dev/null
ln -snf "../../${libdir}/${tlib}" "${lib}"
popd > /dev/null
;;
*)
if ${auto} ; then
-   tlib=$(scanelf -qF'%S#F' 
"${ED}"/usr/${libdir}/${lib})
+   tlib=$(scanelf -qF'%S#F' 
"${ED%/}"/usr/${libdir}/${lib})
[[ -z ${tlib} ]] && die "unable to read SONAME 
from ${lib}"
-   mv "${ED}"/usr/${libdir}/${lib}* 
"${ED}"/${libdir}/ || die
+   mv "${ED%/}"/usr/${libdir}/${lib}* 
"${ED%/}"/${libdir}/ || die
# some SONAMEs are funky: they encode a version 
before the .so
if [[ ${tlib} != ${lib}* ]] ; then
-   mv "${ED}"/usr/${libdir}/${tlib}* 
"${ED}"/${libdir}/ || die
+   mv "${ED%/}"/usr/${libdir}/${tlib}* 
"${ED%/}"/${libdir}/ || die
fi
-   

Re: [gentoo-dev] [PATCH] elisp.eclass: Drop support for EAPIs 0 to 3.

2019-07-15 Thread Hans de Graaff
On Mon, 2019-07-15 at 10:00 +0200, Ulrich Müller wrote:
> @@ -9,7 +9,7 @@
>  # Jeremy Maitin-Shepard 
>  # Christian Faulhammer 
>  # Ulrich Müller 
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> +# @SUPPORTED_EAPIS: 4 5 6 7
>  # @BLURB: Eclass for Emacs Lisp packages
>  # @DESCRIPTION:
>  #

Looks good to me.

Hans


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