[gentoo-dev] Re: [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal
On 17 Jan 2022 11:09, Sam James wrote: > When -I${SYSROOT} is injected, it'll override the default of -Im4, which > results in trying to install macros to ${SYSROOT} (a sandbox violation) > when they can't be found. > > From aclocal(1): > ``` >-I DIR add directory to search list for .m4 files > >--install > copy third-party files to the first -I directory > ``` > > The first directry is normally -Im4 if anything, whereas when injected > (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so > we try to copy macros to somewhere outside of the build directory). we should define the semantics we want and bring it upstream to get into automake. although it seems like ACLOCAL_PATH might work well enough for us now to switch to that. as a stop gap, it seems like the use of --install is pretty low ? we're cross-compiling about ~2.5k packages in CrOS every day and never seen a failure here. so the few packages which are running into troubles can workaround it by setting AT_SYS_M4DIR right ? > In EAPI 7+, this is almost always the case! We don't generally expect > to find macros (particularly things like autoconf-archive) in ${SYSROOT} > because that's for DEPEND-class dependencies, then they end up being > copied in unnecessarily and wrongly. i think this optimism is misplaced. libraries often install m4 files which is precisely why this logic is in here. https://bugs.gentoo.org/677002#c10 deleting this check will break things. prob more than we're fixing. -mike signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/
On 28 Oct 2021 23:43, Andreas K. Huettel wrote: > > checking whether the C compiler works... * > > /var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83: > > failure (Function not implemented): > > * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x, > > 0x): Function not implemented > > configure: error: cannot run C compiled programs. > > (and yes this is in qemu-alpha user space emulation) > > > > Oops, sorry, this was the bump to sandbox-2.28 (?), not the stabilization. if you have a bug to report, please use bugs.gentoo.org so things can stay organized. -mike signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic
On 20 Mar 2017 20:35, Michał Górny wrote: > Remove the parallel econf logic that adds a lot of complexity for minor > gain. It results in the output from different configure scripts being > mixed in the build log, making it unreadable. It causes econf to be run > in a subshell which is a PMS violation and can cause issues with some of > package manager implementations. Furthermore, the multijob parallel > processes are interleaved with multilib-build logic which is unsupported > and a very bad idea. NAK. you still haven't backed up your claims wrt to PMS, and this slows things down significantly. -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On 16 Mar 2017 10:38, Michał Górny wrote: > Convert the usage of eblits in sys-devel/autoconf into an equivalent > eclass. This makes the ebuilds more readable, more predictable and fixes > compliance with stricter versions of the package manager (i.e. a future > release of Portage). obvious NAK until you sort out the open questions already raised about the backwards breaking change you're trying to land in PMS. the point of having EAPI's in the first place is that we don't break them, but change the behavior across new versions. your patches aren't fixing actual bugs, just things you "don't like". -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Package up for grab
On 03 Aug 2016 17:54, M wrote: please fix your client to not top post or use html -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers
On 24 Jun 2016 07:40, Michał Górny wrote: > On Thu, 23 Jun 2016 21:32:34 -0400 Mike Frysinger wrote: > > On 22 Jun 2016 22:06, Michał Górny wrote: > > > +# @FUNCTION: tc-is-gcc > > > +# @DESCRIPTION: > > > +# Return true if the current compiler is pure GCC. > > > > "pure" doesn't make much sense and is just confusing > > > > shouldn't this be a @RETURN instead of @DESCRIPTION ? same for clang below. > > I've followed suit with other functions in the eclass. They use @RETURN > for stuff that is echoed, and @DESCRIPTION for exit codes. right ... bash doesn't allow you to @RETURN a string -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH 2/4] toolchain-funcs.eclass: Assume CPP="$(tc-getCC) -E" when unset, #582822
OK -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH 1/4] toolchain-funcs.eclass: Fix _tc-getPROG with multi-parameter defaults
OK -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers
On 22 Jun 2016 22:06, Michał Górny wrote: > +# @FUNCTION: tc-is-gcc > +# @DESCRIPTION: > +# Return true if the current compiler is pure GCC. "pure" doesn't make much sense and is just confusing shouldn't this be a @RETURN instead of @DESCRIPTION ? same for clang below. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs
please avoid html e-mails -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 21 May 2016 17:08, Amadeusz Żołnowski wrote: > Mike Frysinger writes: > >> The same "sed -i" is used. I have some configs to edit in place in > >> src_prepare(). It's easier with awk rather than sed. > > > > again, provide an example. one or two uncommon use cases doesn't justify > > being added to eutils. > > See rebar.eclass review where it is used. Later ejabberd ebuild I'm > going to add uses it as well. neither of those are terribly compelling and can be written in sed. you want to do a match & replace in that just as easily. roughly: sed -i \ -e '/{[[:space:]]*deps[[:space:]]*,\/,\/}/{s:.*:{deps, []}:}' \ foo > This function is too generic to be in > rebar.eclass, so I have decided to move it to eutils. What is the > problem with adding it to eutils? because no one else is using it or cares about it. we've gotten by for more than 10 years at this point w/out someone asking for this. if you really want it in rebar, then just DEPEND on gawk and use the inplace flag in your code. then there's no need for eawk anywhere. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 20 May 2016 21:09, Amadeusz Żołnowski wrote: > Mike Frysinger writes: > > On 18 May 2016 22:25, aide...@gentoo.org wrote: > >> awk doesn't have the -i option like sed and if editing file in place is > >> desired, additional steps are required. eawk uses tmp file to make it > >> look to the caller editing happens in place. > > > > what's your real use case ? i've never once thought "man, i wish i could > > run an awk script and modify a file in place". and i write awk most days. > > The same "sed -i" is used. I have some configs to edit in place in > src_prepare(). It's easier with awk rather than sed. again, provide an example. one or two uncommon use cases doesn't justify being added to eutils. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()
On 16 May 2016 14:17, rindeal wrote: > So this is what it looks like now: still missing tests. see eclass/tests/flag-o-matic.sh. > - local f var findflag="$1" > - > - # this code looks a little flaky but seems to work for > - # everything we want ... > - # for example, if CFLAGS="-march=i686": > - # `get-flag -march` == "-march=i686" > - # `get-flag march` == "i686" > + local var pattern="${1}" drop the braces for builtin vars > for var in $(all-flag-vars) ; do > - for f in ${!var} ; do > - if [ "${f/${findflag}}" != "${f}" ] ; then > - printf "%s\n" "${f/-${findflag}=}" > + local i flags=( ${!var} ) > + for (( i=${#flags[@]}-1; i>=0; i-- )) ; do omitting spaces doesn't make code faster, it just makes it unreadable. for (( i = ${#flags[@]} - 1; i >= 0; --i )) ; do stick a comment above this for loop explaining why we walk backwards. > + local needle="-${pattern#-}" # force dash on avoid inline comments and make them complete sentences. # Make sure we anchor to the leading dash. local needle="-${pattern#-}" > + local haystack="${flags[i]%%=*}" # we're comparing flags, not > values it's a bit easier to read if you unpack the flag explicitly. local flag=${flags[i]} > + if [[ ${haystack##${needle}} == '' ]] ; then use a -z test instead of comparing to '' -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 18 May 2016 22:25, aide...@gentoo.org wrote: > awk doesn't have the -i option like sed and if editing file in place is > desired, additional steps are required. eawk uses tmp file to make it > look to the caller editing happens in place. what's your real use case ? i've never once thought "man, i wish i could run an awk script and modify a file in place". and i write awk most days. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 20 May 2016 02:16, Mart Raudsepp wrote: > I would like if such a function would explicitly document that calling > this function means the caller should DEPEND on an awk provider. > Similarly, I would like that all ebuild that call 'sed' actually DEPEND > on sed, not just half of them. > I would also like that no ebuild would assume packages in @system to be > present, beyond those dictated by PMS (unpackers and such). this is all a terrible terrible idea and has been hashed/explained a number of times on this list. have you ever tried looking at the tools configure scripts run ? -mike signature.asc Description: Digital signature
Re: [gentoo-dev][PATCH] dev-lang/go-1.6.2: enable go-bootstrap tarball for ppc64le #581278
On 28 Apr 2016 13:28, Leno Hou wrote: > --- a/dev-lang/go/go-1.6.2.ebuild > +++ b/dev-lang/go/go-1.6.2.ebuild > @@ -88,6 +88,16 @@ go_arch() > case "${portage_arch}" in > x86)echo 386;; > x64-*) echo amd64;; > + ppc64) > + case "$(tc-endian $@)" in the quote nesting is incorrect. you want: case $(tc-endian "$@") in > + little) > + echo ppc64le > + ;; > + big) > + echo ppc64 > + ;; > + esac > + ;; up to William, but seems like a one liner would be fine: [[ $(tc-endian "$@") == "big" ]] && echo ppc64 || echo ppc64le -mike signature.asc Description: Digital signature
Re: [gentoo-dev][PATCH v1 ] sys-fs/hfsplusutils with gcc-5: blockiter.c:148:8: error: redefinition of blockiter_curr #580620
On 23 Apr 2016 11:39, David Seifert wrote: please don't top post > I generally prefer using -std=gnu89 instead of -fgnu89-inline, as GCC might > change some C11 semantics later on. To me -std=gnu89 seems more robust. perhaps, but other than gnu-inline behavior, it seems to be fine. if we hit another build issue, we can re-evaluate then. -mike signature.asc Description: Digital signature
Re: [gentoo-dev][PATCH v1 ] sys-fs/hfsplusutils with gcc-5: blockiter.c:148:8: error: redefinition of blockiter_curr #580620
On 22 Apr 2016 03:57, Leno Hou wrote: > +-extern inline UInt32 blockiter_curr(blockiter *b) > +-{ > +-return b->e->start_block + b->block; > +-} > +- > +- > ++extern inline UInt32 blockiter_curr(blockiter *b); i don't think that's how you want to handle extern inline. it doesn't make sense when it's declared this way as there is no actual body for gcc to optimisitcally inline. instead, we should go with what Ubuntu/Debian have: use the -fgnu89-inline flag to build since those are the semantics this code expects. i've pushed that fix now. -mike signature.asc Description: Digital signature
Re: [gentoo-dev][PATCH v2 2/2] ERROR: sys-apps/attr: unable to read SONAME from libattr.so #580792
thanks, i've added elibtoolize calls to acl & attr now https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9e18bcb8f8bcaa6b3e5543caf16a684e7dacd21 -mike signature.asc Description: Digital signature
Re: [gentoo-dev][PATCH v2 1/2] eclass/libtool: fix unable read SONAME for ppc64le #580792
On 22 Apr 2016 03:44, Leno Hou wrote: > 2) The problem is due to the wrong $LD="ld -m elf64ppc" when link. > This patch sets $LD="ld -m elf64lppc" in m4/libtool.m4 on ppc64le. i'm looking at the upstream libtool project and i'm not seeing these changes in there. have you sent patches to them to update libtool ? otherwise, all packages will continue to be created with bad versions in them ... what upstream has right now is: if AC_TRY_EVAL(ac_compile); then case `/usr/bin/file conftest.o` in *32-bit*) case $host in ... powerpc64le-*linux*) LD="${LD-ld} -m elf32lppclinux" ;; powerpc64-*linux*) LD="${LD-ld} -m elf32ppclinux" ;; ... *64-bit*) case $host in ... powerpcle-*linux*) LD="${LD-ld} -m elf64lppc" ;; powerpc-*linux*) LD="${LD-ld} -m elf64ppc" ;; ... your 2.4.2 patch makes sense in that it had no LE support, so you need to add the tuple matching. however, the 2.4.4 & 2.4.6 patches are applying to libtool versions that know how to handle LE. keep in mind that the logic here is just for handling mismatch in the expected bitness and the tuple. i.e. when you're using a tuple like powerpc-linux-gnu (which is normally 32bit) but you're actually producing 64-bit code. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64
On 21 Apr 2016 13:16, Leno Hou wrote: > On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote: > > On 20 Apr 2016 13:52, Leno Hou wrote: > > > Authored-by: Linda Jiang > > > --- > > > eclass/toolchain-binutils.eclass | 1 + > > > 1 file changed, 1 insertion(+) > > > > when you submit a patch that is not extremely obvious, you must provide > > details/justification in the commit message. otherwise we're forced to > > try and guess what/why it is you want to do things, and ultimately we > > tend to start of just saying "no". > > > > Sorry, We describes details/justification in Gentoo Bugzilla#580614 > <https://bugs.gentoo.org/show_bug.cgi?id=580614>. Explain here again. that bug hadn't been reassigned yet to toolchain@ so i didn't see it. i'll follow up there. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
On 20 Apr 2016 21:01, Alon Bar-Lev wrote: > On 20 April 2016 at 18:52, Ian Stakenvicius wrote: > > After doing some experimentation with a mingw crossdev, I found that I > > needed to do a lot of EXTRA_ECONF settings in combination with > > USE="aqua" in order to get packages supporting a win32 API to be > > configured appropriately. In order to support this situation better, > > I propose adding a new global flag 'win32', modelled after the 'aqua' > > flag, that can be used instead to provide this configuration directly > > in ebuilds. > > > > Just like USE="aqua", the flag will be use.mask'ed in base/ so that > > users don't erroneously enable it. I didn't un-use.mask it anywhere > > yet since (A) I don't have a prefix/windows environment to test, and > > (B) the mingw-based crossdev environments use profiles/embedded by > > default, which doesn't inherit from profiles/base and so doesn't have > > the use.mask restriction. > > > > The attached patch lists the necessary changes to profile/ as well as > > the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo > > (the actual commit will include more versions). > > > > Comments? > > You should be able to achieve similar behavior by looking at libc > and/or CHOST without introducing new USE flag, just like we do for > aix/solaris/freebsd etc... agreed ... we have kernel_Winnt & elibc_Winnt already. i think those represent a mingw environment (vs a cygwin env). i don't think a parallel to aqua makes sense. aqua is a specific UI toolkit in OS X. it's more parallel to something like GTK+ or QT. further, nesting aqua/win32 doesn't make sense as there is no valid profile where both flags would be available. USE=aqua can only be turned on in an OS X profile where your proposed USE=win32 would be masked (and vice versa). -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64
On 20 Apr 2016 13:52, Leno Hou wrote: > Authored-by: Linda Jiang > --- > eclass/toolchain-binutils.eclass | 1 + > 1 file changed, 1 insertion(+) when you submit a patch that is not extremely obvious, you must provide details/justification in the commit message. otherwise we're forced to try and guess what/why it is you want to do things, and ultimately we tend to start of just saying "no". > --- a/eclass/toolchain-binutils.eclass > +++ b/eclass/toolchain-binutils.eclass > @@ -271,6 +271,7 @@ toolchain-binutils_src_configure() { > # We used to do it for everyone, but it's slow on 32bit arches. #438522 > case $(tc-arch) in > ppc|sparc|x86) myconf+=( --enable-64-bit-bfd ) ;; > + ppc64) myconf+=( --enable-targets="powerpc-linux-gnu" ) ;; > esac why ? we don't normally do this (as you can see in the file, there is no other arch-specific handling like this). instead, binutils itself handles things by selecting a default set of supported targets based on the active host. and when i glance in there, this seems to already be done for you. bfd/config.bfd: powerpc64-*-elf* | powerpc-*-elf64* | powerpc64-*-linux* | \ powerpc64-*-*bsd*) targ_defvec=powerpc_elf64_vec targ_selvecs="powerpc_elf64_le_vec powerpc_elf32_vec powerpc_elf32_le_vec rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec" want64=true ;; powerpc64le-*-elf* | powerpcle-*-elf64* | powerpc64le-*-linux* | \ powerpc64le-*-*bsd*) targ_defvec=powerpc_elf64_le_vec targ_selvecs="powerpc_elf64_vec powerpc_elf32_le_vec powerpc_elf32_vec rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec" want64=true ;; ld/configure.tgt: powerpc*-*-elf* | powerpc*-*-eabi* | powerpc*-*-sysv* \ | powerpc*-*-linux* | powerpc*-*-netbsd* | powerpc*-*-openbsd* \ | powerpc*-*-solaris* | powerpc*-*-kaos* | powerpc*-*-vxworks*) case "${targ}" in *64*) targ_emul=elf64ppc targ_extra_emuls="elf32ppc elf32ppclinux elf32ppcsim" targ_extra_libpath="elf32ppc elf32ppclinux" td=tdir_elf32ppc case "${targ}" in powerpc*le-*) td=tdir_elf32lppc;; esac eval ${td}=`echo "${targ_alias}" | sed -e 's/64//'` eval ${td}linux=\$${td} eval ${td}sim=\$${td} ;; and indeed, when i query a default ppc64 linker, it says it already supports both 32bit & 64bit targets: $ powerpc64-unknown-linux-gnu-ld --help | grep supported powerpc64-unknown-linux-gnu-ld: supported targets: elf64-powerpc elf64-powerpcle elf32-powerpc elf32-powerpcle aixcoff-rs6000 aixcoff64-rs6000 aix5coff64-rs6000 elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex powerpc64-unknown-linux-gnu-ld: supported emulations: elf64ppc elf32ppc elf32ppclinux elf32ppcsim it would have to of course in order for biarch support (which works) which is how we build 64-bit kernels in a 32-bit userland. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem
On 19 Apr 2016 22:12, Leno Hou wrote: > --- /dev/null > +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch > @@ -0,0 +1,26 @@ > +--- configure.orig 2016-04-09 16:24:17.507053635 + > configure2016-04-09 16:25:41.851918142 + > +@@ -4947,6 +4947,9 @@ > + ppc64-*linux*|powerpc64-*linux*) > + LD="${LD-ld} -m elf32ppclinux" > + ;; > ++ppc64le-*linux*|powerpc64le-*linux*) > ++ LD="${LD-ld} -m elf32lppclinux" > ++ ;; you appear to be patching libtool code. this should be in libtool itself. if it's a common issue, we'll want to leverage elibtoolize here. make a patch and stick it in eclass/ELT-patches/ppc64le/, and then update the libtool.eclass file to apply those. then update opensp to call the elibtoolize function in src_prepare. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff
On 19 Apr 2016 04:02, Anthony G. Basile wrote: > On 4/19/16 1:41 AM, Mike Frysinger wrote: > > i waited until the known bugs died down. i don't have access to a > > tinderbox system myself. > > you didn't notice that coreutils and systemd/udev/eudev broke? i had pushed the coreutils issue upstream, but i thought it was fixed already (via configure checks). i don't run those other packages. > but a heads up would have been useful certainly. i usually do it based on how much on an impat a change will have. i didn't think this would spawn as many bugs as it had (since the incoming rate had slowed/stopped), but i misjudged. > > not today, but as i said, we want to move multiple libraries (at least > > glibc, uClibc, musl, and bionic) in that direction. the current behavior > > violates the POSIX standard. > > i took a look at opengroup.org and it seems posix is silent on the > matter. POSIX does not permit sys/types.h inclusion to export things it doesn't define. since it doesn't define major/minor/makedev, including them in the export is a standards violation. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff
On 19 Apr 2016 08:15, Michał Górny wrote: > On Tue, 19 Apr 2016 01:41:06 -0400 Mike Frysinger wrote: > > On 19 Apr 2016 04:21, Mart Raudsepp wrote: > > > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger: > > > > On 16 Apr 2016 09:23, Patrick Lauer wrote: > > > > > So why on earth are we applying a random patch that upstream is not > > > > > using > > > > > > > > not everyone uses glibc, and glibc *is* moving in this > > > > direction. Gentoo > > > > is simply accelerating the change ... otherwise glibc will take > > > > longer to do the actual migration. > > > > > > You don't need to break everyone's ~arch for dubious glibc benefits, > > > which could be done by a p.masked version and a tinderbox run. > > > I am not your tinderbox dummy having to waste time on this to maintain > > > my own ~arch stuff. > > > > i waited until the known bugs died down. i don't have access to a > > tinderbox system myself. > > Cut the nonsense. You clearly didn't even test that glibc version > on a single system. If you did, you'd notice the core system packages > failing to build. i know it's asking a lot of you, but you should refrain from making claims that not only do you obviously have no idea about but can also be trivially refuted. i run glibc versions starting before i commit them to the tree and build/test packages against it constantly. this box has built hundreds of packages and if you look at the git tree, i fixed a number of packages before anyone even saw the breakage. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff
On 19 Apr 2016 04:21, Mart Raudsepp wrote: > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger: > > On 16 Apr 2016 09:23, Patrick Lauer wrote: > > > So why on earth are we applying a random patch that upstream is not > > > using > > > > not everyone uses glibc, and glibc *is* moving in this > > direction. Gentoo > > is simply accelerating the change ... otherwise glibc will take > > longer to do the actual migration. > > You don't need to break everyone's ~arch for dubious glibc benefits, > which could be done by a p.masked version and a tinderbox run. > I am not your tinderbox dummy having to waste time on this to maintain > my own ~arch stuff. i waited until the known bugs died down. i don't have access to a tinderbox system myself. > > packages failing to build under glibc already > > fail to build in other environments. > > That is simply not true except for the part where it is. highlighting one system where it's working for you doesn't mean all systems behave that way. there's even an autoconf macro specifically to deal with this and has been for years. they wouldn't have written & deployed it for fun. > at least not to the extent you make it sound. not today, but as i said, we want to move multiple libraries (at least glibc, uClibc, musl, and bionic) in that direction. the current behavior violates the POSIX standard. > Why are all the concerns raised at e.g > https://bugs.freedesktop.org/show_bug.cgi?id=94231 not resolved then? what exactly are you expecting here ? i'm not an X.org dev. i can't fix code in that project for them. all the questions posed have been answered in the bug. it's merely waiting for them to actually commit code. > Over there you even told you won't be including this patch in Gentoo, > but get it trickled in from upstream once they judge it as good to go. no idea where you're getting reading this. i never said that. > Instead you go ahead and unmask this without removing the gentoo > specific sysmacros header removal, knowing FULLY WELL that you break > ~arch for a lot of things again, no. read what i actually said, and read the actual bug open on the topic. most of the packages i was aware of were fixed, and there were only like 2 or 3 left assigned to projects/devs who are not me. once things moved into ~arch, we started getting more bug reports, not before. > Even todays git of man-pages tells that including sys/types.h is > sufficient and the correct thing to do to get makedev/major/minor. and we've already been discussing fixing that. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff
On 16 Apr 2016 09:23, Patrick Lauer wrote: > So why on earth are we applying a random patch that upstream is not > using not everyone uses glibc, and glibc *is* moving in this direction. Gentoo is simply accelerating the change ... otherwise glibc will take longer to do the actual migration. packages failing to build under glibc already fail to build in other environments. > *and* unleashing it on ~arch without any of the usual precautions > like masking the package until some of the issues have been smoked out? it was masked for a while, some bugs were fixed, but no new ones were really being found. so in the absence of data showing a problem, unmasking is normal. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 01 Apr 2016 20:00, Alexis Ballier wrote: > On Friday, April 1, 2016 3:58:18 AM CEST, Mike Frysinger wrote: > >>> ... > >> lemme look it up for you then: > >> https://wiki.gentoo.org/wiki/Council_decisions > >> > >> systems with separate /usr should be supported. However, users > >> shouldn't be > >> constrained from using software which doesn't support that. -- 04/2012 > >> meeting ... > > > > "being supported" != "enabled by default". so no, i still don't see any > > requirement in anything you've cited that this be turned on by default. > > you're right, but you know, before you claimed the contrary of what was > voted and then decided to argue whether a 4 years old council decision > applies or not here, my point was, and still is, that such council > decisions make me think you're confusing what *you* want and what *we* (as > a project) want for this case i see no significant number of people clamoring for this as the default. the bug that started this has everyone on board for changing the default. it's really no different either from the install process today: a stage3 cannot be unpacked & booted directly. a user must configure it before it can actually be used. if that means enabling USE=sep-usr, then so be it. there's no reason to force this legacy behavior on the majority of people when a split-/usr is uncommon. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 21:09, Alexis Ballier wrote: > On Thursday, March 31, 2016 8:19:52 PM CEST, Mike Frysinger wrote: > > On 31 Mar 2016 19:00, Alexis Ballier wrote: > >> On Thursday, March 31, 2016 6:07:28 PM CEST, Mike Frysinger wrote: > >>> On 31 Mar 2016 16:05, Alexis Ballier wrote: ... > >> > >> i dont think anybody expects you to post tree-wide conversion patches to > >> -dev ml :) > >> > >> but i also dont think it is a good idea to leave the toolchain-funcs > >> version around, and if you want to drop it, you'll have to > >> fill bugs to let > >> ppl know, which is probably more work than adding 8 chars to an inherit > >> line that can be automated > > > > sure -- backwards compat won't be dropped until we're confident everyone > > has migrated over > > ... which introduces a mess to track what has been converted and what not > while it can be done once and for good not really. a simple grep in the tree for the single func being dropped is fairly trivial. > >>> ... > >> not sure if this was phrased as such, but I seem to recall a council > >> decision stating that separate /usr should be made easy to users unless > >> this causes serious issues; thus, no, I don't think that is > >> the behavior we > >> want :) ... > > > > pretty sure the decision was that it's not required to be supported. > > lemme look it up for you then: > https://wiki.gentoo.org/wiki/Council_decisions > > systems with separate /usr should be supported. However, users shouldn't be > constrained from using software which doesn't support that. -- 04/2012 > meeting > > The council has voted in favour of a separate /usr being supported > (5 yes, 1 no vote). > > > and > > regardless of that, i don't see the default behavior of being off as being > > contra "easy to use". > > but you're right there, it doesn't make it hard to use, just not working > out of the box, which is already debatable; however, with eudev being the > default I don't think there is anything preventing it atm with a default > setup, but i might certainly stand corrected there "being supported" != "enabled by default". so no, i still don't see any requirement in anything you've cited that this be turned on by default. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 21:13, Alexis Ballier wrote: > On Thursday, March 31, 2016 8:20:45 PM CEST, Mike Frysinger wrote: > > On 31 Mar 2016 19:03, Alexis Ballier wrote: > >> On Thursday, March 31, 2016 6:08:52 PM CEST, Mike Frysinger wrote: > >>> On 31 Mar 2016 10:12, Mike Gilbert wrote: ... > >> > >> unless you symlink /bin to /usr/bin, moving binaries around has wider > >> implications than sep-usr > > > > no valid package will be affected. if you're hardcoding `/bin/foo`, then > > you're doing it wrong already and that's your fault. > > since when '#! /bin/sh' is invalid at the top of a shell script ? or even > execv deprecated ? there are exceptions for a few very well known programs, but a few shebangs does not mean supporting `/bin/cut` or `/bin/kmod` is required. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 19:03, Alexis Ballier wrote: > On Thursday, March 31, 2016 6:08:52 PM CEST, Mike Frysinger wrote: > > On 31 Mar 2016 10:12, Mike Gilbert wrote: > >> On Wed, Mar 30, 2016 at 7:58 PM, Mike Frysinger > >> wrote: ... > > > > i think we can scope it currently for libs (and any data files they need), > > but i don't see it being a bad thing to leverage it for /bin progs. > > unless you symlink /bin to /usr/bin, moving binaries around has wider > implications than sep-usr no valid package will be affected. if you're hardcoding `/bin/foo`, then you're doing it wrong already and that's your fault. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 19:00, Alexis Ballier wrote: > On Thursday, March 31, 2016 6:07:28 PM CEST, Mike Frysinger wrote: > > On 31 Mar 2016 16:05, Alexis Ballier wrote: > >> On Thursday, March 31, 2016 1:58:19 AM CEST, Mike Frysinger wrote: > >>> All ebuilds that call gen_usr_ldscript today will migrate to this and > >>> will allow people to move away from installing things into /. For the > >>> systems that want to have a split-/usr partition, they can turn on this > >>> USE flag across their system. > >> > >> Your patchset seems to be missing some ebuilds in that regard: expat and > >> sys-freebsd/* come to mind. > > > > i did not do a full migration as i got bored, but i did do enough to show > > it in action. the current method does not require all be converted at the > > same time though, so it can be left up to maintainers of relevant packages > > to do the change over themselves. > > i dont think anybody expects you to post tree-wide conversion patches to > -dev ml :) > > but i also dont think it is a good idea to leave the toolchain-funcs > version around, and if you want to drop it, you'll have to fill bugs to let > ppl know, which is probably more work than adding 8 chars to an inherit > line that can be automated sure -- backwards compat won't be dropped until we're confident everyone has migrated over > >>> This also allows us to mask the flag on many targets where it doesn't > >>> make sense (like most prefix setups) and where we don't want to support > >>> it at all. > >> > >> It should be noted that, unless I missed something, the default settings > >> will *not anymore* allow sep-usr after this patchset (sep-usr > >> useflag will > >> be disabled). This should be advertised more (a news item?) or simply > >> sep-usr added to make.defaults. The latter will also enable busybox's > >> sep-usr support. > > > > the patchset allows for some targets (notably Linux systems) to control > > whether the flag is enabled. it is turned off by default and i think > > that's the behavior we want. i have not forced enabled it for any target > > but maybe the prefix/darwin guys will want to do that. > > not sure if this was phrased as such, but I seem to recall a council > decision stating that separate /usr should be made easy to users unless > this causes serious issues; thus, no, I don't think that is the behavior we > want :) pretty sure the decision was that it's not required to be supported. and regardless of that, i don't see the default behavior of being off as being contra "easy to use". -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 10:12, Mike Gilbert wrote: > On Wed, Mar 30, 2016 at 7:58 PM, Mike Frysinger wrote: > > To make forward progress on bug 417451, introduce a new sep-usr eclass > > that will hold all logic related to having a separate /usr. For now, > > this is just the gen_usr_ldscript function and a new USE=sep-usr flag. > > Seems like a decent idea. > > Before this flag gets added, should we define some bounds? I just > don't want to see this flag get abused by using it to move other files > around randomly, like moving things from /bin to /usr/bin, etc. i think we can scope it currently for libs (and any data files they need), but i don't see it being a bad thing to leverage it for /bin progs. > > All ebuilds that call gen_usr_ldscript today will migrate to this and > > will allow people to move away from installing things into /. For the > > systems that want to have a split-/usr partition, they can turn on this > > USE flag across their system. > > So the sep-usr flag will be disabled by default? That's going to > trigger a change from the current state, and will definitely need to > be announced. correct. i can put together a news item. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
On 31 Mar 2016 16:05, Alexis Ballier wrote: > On Thursday, March 31, 2016 1:58:19 AM CEST, Mike Frysinger wrote: > > All ebuilds that call gen_usr_ldscript today will migrate to this and > > will allow people to move away from installing things into /. For the > > systems that want to have a split-/usr partition, they can turn on this > > USE flag across their system. > > Your patchset seems to be missing some ebuilds in that regard: expat and > sys-freebsd/* come to mind. i did not do a full migration as i got bored, but i did do enough to show it in action. the current method does not require all be converted at the same time though, so it can be left up to maintainers of relevant packages to do the change over themselves. > > This also allows us to mask the flag on many targets where it doesn't > > make sense (like most prefix setups) and where we don't want to support > > it at all. > > It should be noted that, unless I missed something, the default settings > will *not anymore* allow sep-usr after this patchset (sep-usr useflag will > be disabled). This should be advertised more (a news item?) or simply > sep-usr added to make.defaults. The latter will also enable busybox's > sep-usr support. the patchset allows for some targets (notably Linux systems) to control whether the flag is enabled. it is turned off by default and i think that's the behavior we want. i have not forced enabled it for any target but maybe the prefix/darwin guys will want to do that. -mike signature.asc Description: Digital signature
[gentoo-dev] [PATCH 15/21] sys-libs/libcap: switch to sep-usr eclass
--- sys-libs/libcap/libcap-2.24-r2.ebuild | 4 ++-- sys-libs/libcap/libcap-2.25.ebuild| 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-libs/libcap/libcap-2.24-r2.ebuild b/sys-libs/libcap/libcap-2.24-r2.ebuild index 1585662..6c8f163 100644 --- a/sys-libs/libcap/libcap-2.24-r2.ebuild +++ b/sys-libs/libcap/libcap-2.24-r2.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils multilib multilib-minimal toolchain-funcs pam +inherit eutils multilib multilib-minimal toolchain-funcs pam sep-usr DESCRIPTION="POSIX 1003.1e capabilities" HOMEPAGE="http://www.friedhoff.org/posixfilecaps.html"; @@ -16,7 +16,7 @@ SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux" IUSE="pam static-libs" -RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}] +RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?] pam? ( virtual/pam )" DEPEND="${RDEPEND} sys-kernel/linux-headers" diff --git a/sys-libs/libcap/libcap-2.25.ebuild b/sys-libs/libcap/libcap-2.25.ebuild index fc4a23b..2b7aa6e 100644 --- a/sys-libs/libcap/libcap-2.25.ebuild +++ b/sys-libs/libcap/libcap-2.25.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit eutils multilib multilib-minimal toolchain-funcs pam +inherit eutils multilib multilib-minimal toolchain-funcs pam sep-usr DESCRIPTION="POSIX 1003.1e capabilities" HOMEPAGE="http://www.friedhoff.org/posixfilecaps.html"; @@ -16,7 +16,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux" IUSE="pam static-libs" -RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}] +RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?] pam? ( virtual/pam )" DEPEND="${RDEPEND} sys-kernel/linux-headers" -- 2.7.4
[gentoo-dev] [PATCH 17/21] sys-libs/ncurses: switch to sep-usr eclass
--- sys-libs/ncurses/ncurses-5.9-r101.ebuild | 4 ++-- sys-libs/ncurses/ncurses-5.9-r3.ebuild | 4 ++-- sys-libs/ncurses/ncurses-5.9-r4.ebuild | 4 ++-- sys-libs/ncurses/ncurses-5.9-r5.ebuild | 4 ++-- sys-libs/ncurses/ncurses-5.9-r99.ebuild | 4 ++-- sys-libs/ncurses/ncurses-6.0-r1.ebuild | 4 ++-- sys-libs/ncurses/ncurses-6.0.ebuild | 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/sys-libs/ncurses/ncurses-5.9-r101.ebuild b/sys-libs/ncurses/ncurses-5.9-r101.ebuild index 541bb16..69de05f 100644 --- a/sys-libs/ncurses/ncurses-5.9-r101.ebuild +++ b/sys-libs/ncurses/ncurses-5.9-r101.ebuild @@ -6,7 +6,7 @@ EAPI="5" -inherit eutils toolchain-funcs multilib-minimal multiprocessing +inherit eutils toolchain-funcs multilib-minimal multiprocessing sep-usr MY_PV=${PV:0:3} MY_P=${PN}-${MY_PV} @@ -20,7 +20,7 @@ SLOT="5/5" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="gpm tinfo unicode" -DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP}] )" +DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP},sep-usr?] )" # Block the ncurses-5 that installs the same lib. #557472 RDEPEND="${DEPEND} !https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/"; LICENSE="metapackage" SLOT="5/5" KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" -IUSE="ada +cxx gpm static-libs tinfo unicode" +IUSE="ada +cxx gpm sep-usr static-libs tinfo unicode" -DEPEND="sys-libs/ncurses:0/5[ada?,cxx?,gpm?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]" +DEPEND="sys-libs/ncurses:0/5[ada?,cxx?,gpm?,sep-usr?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]" RDEPEND="${DEPEND}" diff --git a/sys-libs/ncurses/ncurses-6.0-r1.ebuild b/sys-libs/ncurses/ncurses-6.0-r1.ebuild index 029591b..ba51035 100644 --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild @@ -4,7 +4,7 @@ EAPI="5" -inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing +inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing sep-usr MY_PV=${PV:0:3} PV_SNAP=${PV:4} @@ -19,7 +19,7 @@ SLOT="0/6" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="ada +cxx debug doc gpm minimal profile static-libs test threads tinfo trace unicode" -DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP}] )" +DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP},sep-usr?] )" # berkdb? ( sys-libs/db )" # Block the older ncurses that installed all files w/SLOT=5. #557472 RDEPEND="${DEPEND} diff --git a/sys-libs/ncurses/ncurses-6.0.ebuild b/sys-libs/ncurses/ncurses-6.0.ebuild index 3b85135..fd9c94d 100644 --- a/sys-libs/ncurses/ncurses-6.0.ebuild +++ b/sys-libs/ncurses/ncurses-6.0.ebuild @@ -15,7 +15,7 @@ HOMEPAGE="https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/"; LICENSE="metapackage" SLOT="5/6" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" -IUSE="ada +cxx gpm static-libs tinfo unicode" +IUSE="ada +cxx gpm sep-usr static-libs tinfo unicode" -DEPEND="sys-libs/ncurses:0/6[ada?,cxx?,gpm?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]" +DEPEND="sys-libs/ncurses:0/6[ada?,cxx?,gpm?,sep-usr?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]" RDEPEND="${DEPEND}" -- 2.7.4
[gentoo-dev] [PATCH 19/21] dev-libs/libedit: switch to sep-usr eclass
--- dev-libs/libedit/libedit-20130712.3.1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dev-libs/libedit/libedit-20130712.3.1.ebuild b/dev-libs/libedit/libedit-20130712.3.1.ebuild index 50e38d6..4b1202f 100644 --- a/dev-libs/libedit/libedit-20130712.3.1.ebuild +++ b/dev-libs/libedit/libedit-20130712.3.1.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit eutils toolchain-funcs versionator base multilib-minimal +inherit eutils toolchain-funcs versionator base multilib-minimal sep-usr MY_PV=$(get_major_version)-$(get_after_major_version) MY_P=${PN}-${MY_PV} @@ -18,7 +18,7 @@ SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x86-freebsd ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos" IUSE="static-libs" -DEPEND=">=sys-libs/ncurses-5.9-r3[static-libs?,${MULTILIB_USEDEP}] +DEPEND=">=sys-libs/ncurses-5.9-r3[sep-usr?,static-libs?,${MULTILIB_USEDEP}] !<=sys-freebsd/freebsd-lib-6.2_rc1" RDEPEND=${DEPEND} -- 2.7.4
[gentoo-dev] [PATCH 16/21] sys-libs/cracklib: switch to sep-usr eclass
--- sys-libs/cracklib/cracklib-2.9.1-r1.ebuild | 4 ++-- sys-libs/cracklib/cracklib-2.9.4.ebuild| 4 ++-- sys-libs/cracklib/cracklib-2.9.5.ebuild| 4 ++-- sys-libs/cracklib/cracklib-2.9.6.ebuild| 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild b/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild index 792bb37..c7e36a4 100644 --- a/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild +++ b/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild @@ -6,7 +6,7 @@ EAPI="4" PYTHON_COMPAT=( python2_7 ) DISTUTILS_OPTIONAL=1 -inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs +inherit eutils distutils-r1 libtool multilib-minimal sep-usr MY_P=${P/_} DESCRIPTION="Password Checking Library" @@ -18,7 +18,7 @@ SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x86-macos ~m68k-mint" IUSE="nls python static-libs test zlib" -RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )" +RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )" DEPEND="${RDEPEND} python? ( dev-python/setuptools[${PYTHON_USEDEP}] diff --git a/sys-libs/cracklib/cracklib-2.9.4.ebuild b/sys-libs/cracklib/cracklib-2.9.4.ebuild index a826ef9..f2fa977 100644 --- a/sys-libs/cracklib/cracklib-2.9.4.ebuild +++ b/sys-libs/cracklib/cracklib-2.9.4.ebuild @@ -6,7 +6,7 @@ EAPI="5" PYTHON_COMPAT=( python2_7 ) DISTUTILS_OPTIONAL=1 -inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs +inherit eutils distutils-r1 libtool multilib-minimal sep-usr MY_P=${P/_} DESCRIPTION="Password Checking Library" @@ -18,7 +18,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x86-macos ~m68k-mint" IUSE="nls python static-libs test zlib" -RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )" +RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )" DEPEND="${RDEPEND} python? ( dev-python/setuptools[${PYTHON_USEDEP}] diff --git a/sys-libs/cracklib/cracklib-2.9.5.ebuild b/sys-libs/cracklib/cracklib-2.9.5.ebuild index a826ef9..f2fa977 100644 --- a/sys-libs/cracklib/cracklib-2.9.5.ebuild +++ b/sys-libs/cracklib/cracklib-2.9.5.ebuild @@ -6,7 +6,7 @@ EAPI="5" PYTHON_COMPAT=( python2_7 ) DISTUTILS_OPTIONAL=1 -inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs +inherit eutils distutils-r1 libtool multilib-minimal sep-usr MY_P=${P/_} DESCRIPTION="Password Checking Library" @@ -18,7 +18,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x86-macos ~m68k-mint" IUSE="nls python static-libs test zlib" -RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )" +RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )" DEPEND="${RDEPEND} python? ( dev-python/setuptools[${PYTHON_USEDEP}] diff --git a/sys-libs/cracklib/cracklib-2.9.6.ebuild b/sys-libs/cracklib/cracklib-2.9.6.ebuild index dda19c0..fa3143a 100644 --- a/sys-libs/cracklib/cracklib-2.9.6.ebuild +++ b/sys-libs/cracklib/cracklib-2.9.6.ebuild @@ -6,7 +6,7 @@ EAPI="5" PYTHON_COMPAT=( python2_7 ) DISTUTILS_OPTIONAL=1 -inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs +inherit eutils distutils-r1 libtool multilib-minimal sep-usr MY_P=${P/_} DESCRIPTION="Password Checking Library" @@ -18,7 +18,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x86-macos ~m68k-mint" IUSE="nls python static-libs test zlib" -RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )" +RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )" DEPEND="${RDEPEND} python? ( dev-python/setuptools[${PYTHON_USEDEP}] -- 2.7.4
[gentoo-dev] [PATCH 13/21] sys-apps/keyutils: switch to sep-usr eclass
--- sys-apps/keyutils/keyutils-1.5.9-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild b/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild index 7b8ddbf..7a813c0 100644 --- a/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild +++ b/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild @@ -4,7 +4,7 @@ EAPI="5" -inherit multilib eutils toolchain-funcs linux-info multilib-minimal +inherit multilib eutils toolchain-funcs linux-info multilib-minimal sep-usr DESCRIPTION="Linux Key Management Utilities" HOMEPAGE="https://people.redhat.com/dhowells/keyutils/"; -- 2.7.4
[gentoo-dev] [PATCH 12/21] sys-libs/readline: switch to sep-usr eclass
--- sys-libs/readline/readline-6.2_p5-r1.ebuild | 2 +- sys-libs/readline/readline-6.3_p8-r1.ebuild | 2 +- sys-libs/readline/readline-6.3_p8-r2.ebuild | 2 +- sys-libs/readline/readline-7.0_rc1.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-libs/readline/readline-6.2_p5-r1.ebuild b/sys-libs/readline/readline-6.2_p5-r1.ebuild index 36ffdf4..153fbdd 100644 --- a/sys-libs/readline/readline-6.2_p5-r1.ebuild +++ b/sys-libs/readline/readline-6.2_p5-r1.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal +inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr # Official patches # See ftp://ftp.cwru.edu/pub/bash/readline-6.2-patches/ diff --git a/sys-libs/readline/readline-6.3_p8-r1.ebuild b/sys-libs/readline/readline-6.3_p8-r1.ebuild index 98588d9..a51cb78c 100644 --- a/sys-libs/readline/readline-6.3_p8-r1.ebuild +++ b/sys-libs/readline/readline-6.3_p8-r1.ebuild @@ -4,7 +4,7 @@ EAPI=4 -inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal +inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr # Official patches # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/ diff --git a/sys-libs/readline/readline-6.3_p8-r2.ebuild b/sys-libs/readline/readline-6.3_p8-r2.ebuild index ad21882..eca2b24 100644 --- a/sys-libs/readline/readline-6.3_p8-r2.ebuild +++ b/sys-libs/readline/readline-6.3_p8-r2.ebuild @@ -4,7 +4,7 @@ EAPI=4 -inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal +inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr # Official patches # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/ diff --git a/sys-libs/readline/readline-7.0_rc1.ebuild b/sys-libs/readline/readline-7.0_rc1.ebuild index da06224..ccbe927 100644 --- a/sys-libs/readline/readline-7.0_rc1.ebuild +++ b/sys-libs/readline/readline-7.0_rc1.ebuild @@ -4,7 +4,7 @@ EAPI="5" -inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal +inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr # Official patches # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/ -- 2.7.4
[gentoo-dev] [PATCH 21/21] sys-apps/tcp-wrappers: switch to sep-usr eclass
--- sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild b/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild index 1496b09..4923e85 100644 --- a/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild +++ b/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils toolchain-funcs versionator flag-o-matic multilib-minimal +inherit eutils toolchain-funcs versionator flag-o-matic multilib-minimal sep-usr MY_PV=$(get_version_component_range 1-2) DEB_PV=$(get_version_component_range 3) -- 2.7.4
[gentoo-dev] [PATCH 20/21] dev-libs/libpcre: switch to sep-usr eclass
--- dev-libs/libpcre/libpcre-8.38.ebuild | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/dev-libs/libpcre/libpcre-8.38.ebuild b/dev-libs/libpcre/libpcre-8.38.ebuild index fcda8d2..f7c64aa 100644 --- a/dev-libs/libpcre/libpcre-8.38.ebuild +++ b/dev-libs/libpcre/libpcre-8.38.ebuild @@ -4,7 +4,7 @@ EAPI="5" -inherit eutils multilib libtool flag-o-matic toolchain-funcs multilib-minimal +inherit eutils multilib libtool flag-o-matic toolchain-funcs multilib-minimal sep-usr DESCRIPTION="Perl-compatible regular expression library" HOMEPAGE="http://www.pcre.org/"; @@ -24,10 +24,10 @@ IUSE="bzip2 +cxx +jit libedit pcre16 pcre32 +readline +recursion-limit static-li REQUIRED_USE="readline? ( !libedit ) libedit? ( !readline )" -RDEPEND="bzip2? ( app-arch/bzip2 ) - zlib? ( sys-libs/zlib ) - libedit? ( dev-libs/libedit ) - readline? ( sys-libs/readline:0= )" +RDEPEND="bzip2? ( app-arch/bzip2[sep-usr?] ) + zlib? ( sys-libs/zlib[sep-usr?] ) + libedit? ( dev-libs/libedit[sep-usr?] ) + readline? ( sys-libs/readline:0=[sep-usr?] )" DEPEND="${RDEPEND} virtual/pkgconfig" RDEPEND="${RDEPEND} -- 2.7.4
[gentoo-dev] [PATCH 18/21] dev-libs/libpwquality: switch to sep-usr eclass
--- dev-libs/libpwquality/libpwquality-1.3.0.ebuild | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/dev-libs/libpwquality/libpwquality-1.3.0.ebuild b/dev-libs/libpwquality/libpwquality-1.3.0.ebuild index e2597b0..8082188 100644 --- a/dev-libs/libpwquality/libpwquality-1.3.0.ebuild +++ b/dev-libs/libpwquality/libpwquality-1.3.0.ebuild @@ -5,7 +5,7 @@ EAPI="5" PYTHON_COMPAT=( python{2_7,3_3,3_4} ) -inherit eutils multilib pam python-r1 toolchain-funcs +inherit eutils multilib pam python-r1 sep-usr DESCRIPTION="Library for password quality checking and generating random passwords" HOMEPAGE="https://fedorahosted.org/libpwquality/"; @@ -17,7 +17,7 @@ KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~mips ppc ppc64 s390 sh sparc x86" IUSE="pam python static-libs" RDEPEND=" - >=sys-libs/cracklib-2.8:= + >=sys-libs/cracklib-2.8:=[sep-usr?] pam? ( virtual/pam ) python? ( ${PYTHON_DEPS} ) " @@ -38,7 +38,6 @@ src_configure() { configuring() { local sitedir econf \ - --libdir="${EPREFIX}/$(get_libdir)" \ $(use_enable pam) \ --with-securedir="${EPREFIX}/$(getpam_mod_dir)" \ $(use_enable python python-bindings) \ @@ -58,12 +57,7 @@ src_test() { src_install() { if_use_python_python_foreach_impl default - if use static-libs; then - # Do not install static libs in /lib - mkdir -p "${ED}usr/$(get_libdir)" - mv "${ED}$(get_libdir)/libpwquality.a" "${ED}/usr/$(get_libdir)/" || die - gen_usr_ldscript libpwquality.so - fi + gen_usr_ldscript -a pwquality prune_libtool_files --modules } -- 2.7.4
[gentoo-dev] [PATCH 14/21] dev-libs/libaio: switch to sep-usr eclass
--- dev-libs/libaio/libaio-0.3.110.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev-libs/libaio/libaio-0.3.110.ebuild b/dev-libs/libaio/libaio-0.3.110.ebuild index 0605dbe..f625ba7 100644 --- a/dev-libs/libaio/libaio-0.3.110.ebuild +++ b/dev-libs/libaio/libaio-0.3.110.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit eutils multilib-minimal toolchain-funcs flag-o-matic +inherit eutils multilib-minimal toolchain-funcs flag-o-matic sep-usr DESCRIPTION="Asynchronous input/output library that uses the kernels native interface" HOMEPAGE="https://git.fedorahosted.org/cgit/libaio.git/ http://lse.sourceforge.net/io/aio.html"; -- 2.7.4
[gentoo-dev] [PATCH 11/21] dev-libs/lzo: switch to sep-usr eclass
--- dev-libs/lzo/lzo-2.08-r1.ebuild | 2 +- dev-libs/lzo/lzo-2.09.ebuild| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev-libs/lzo/lzo-2.08-r1.ebuild b/dev-libs/lzo/lzo-2.08-r1.ebuild index f3cff4b..e988b96 100644 --- a/dev-libs/lzo/lzo-2.08-r1.ebuild +++ b/dev-libs/lzo/lzo-2.08-r1.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit eutils multilib-minimal toolchain-funcs +inherit eutils multilib-minimal sep-usr DESCRIPTION="An extremely fast compression and decompression library" HOMEPAGE="http://www.oberhumer.com/opensource/lzo/"; diff --git a/dev-libs/lzo/lzo-2.09.ebuild b/dev-libs/lzo/lzo-2.09.ebuild index f3cff4b..e988b96 100644 --- a/dev-libs/lzo/lzo-2.09.ebuild +++ b/dev-libs/lzo/lzo-2.09.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit eutils multilib-minimal toolchain-funcs +inherit eutils multilib-minimal sep-usr DESCRIPTION="An extremely fast compression and decompression library" HOMEPAGE="http://www.oberhumer.com/opensource/lzo/"; -- 2.7.4
[gentoo-dev] [PATCH 10/21] sys-libs/pam: switch to sep-usr eclass
--- sys-libs/pam/pam-1.2.1-r1.ebuild | 4 ++-- sys-libs/pam/pam-1.2.1.ebuild| 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-libs/pam/pam-1.2.1-r1.ebuild b/sys-libs/pam/pam-1.2.1-r1.ebuild index a3e541d..6cb59da 100644 --- a/sys-libs/pam/pam-1.2.1-r1.ebuild +++ b/sys-libs/pam/pam-1.2.1-r1.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit libtool multilib multilib-minimal eutils pam toolchain-funcs flag-o-matic db-use fcaps +inherit libtool multilib multilib-minimal eutils pam toolchain-funcs flag-o-matic db-use sep-usr fcaps MY_PN="Linux-PAM" MY_P="${MY_PN}-${PV}" @@ -138,7 +138,7 @@ multilib_src_install() { sepermitlockdir="${EPREFIX}/run/sepermit" local prefix - if multilib_is_native_abi; then + if use sep-usr; then prefix= gen_usr_ldscript -a pam pamc pam_misc else diff --git a/sys-libs/pam/pam-1.2.1.ebuild b/sys-libs/pam/pam-1.2.1.ebuild index 8309dda..5241086 100644 --- a/sys-libs/pam/pam-1.2.1.ebuild +++ b/sys-libs/pam/pam-1.2.1.ebuild @@ -4,7 +4,7 @@ EAPI=5 -inherit libtool multilib multilib-minimal eutils pam toolchain-funcs flag-o-matic db-use +inherit libtool multilib multilib-minimal eutils pam toolchain-funcs flag-o-matic db-use sep-usr MY_PN="Linux-PAM" MY_P="${MY_PN}-${PV}" @@ -136,7 +136,7 @@ multilib_src_install() { sepermitlockdir="${EPREFIX}/run/sepermit" local prefix - if multilib_is_native_abi; then + if use sep-usr; then prefix= gen_usr_ldscript -a pam pamc pam_misc else -- 2.7.4
[gentoo-dev] [PATCH 09/21] sys-apps/attr: switch to sep-usr eclass
--- sys-apps/attr/attr-2.4.47-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-apps/attr/attr-2.4.47-r2.ebuild b/sys-apps/attr/attr-2.4.47-r2.ebuild index 11a6bda..06bac92 100644 --- a/sys-apps/attr/attr-2.4.47-r2.ebuild +++ b/sys-apps/attr/attr-2.4.47-r2.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils toolchain-funcs multilib-minimal +inherit eutils multilib-minimal sep-usr DESCRIPTION="Extended attributes tools" HOMEPAGE="http://savannah.nongnu.org/projects/attr"; -- 2.7.4
[gentoo-dev] [PATCH 07/21] app-arch/xz-utils: switch to sep-usr eclass
--- app-arch/xz-utils/xz-utils-5.2.2.ebuild | 2 +- app-arch/xz-utils/xz-utils-.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/app-arch/xz-utils/xz-utils-5.2.2.ebuild b/app-arch/xz-utils/xz-utils-5.2.2.ebuild index 34283d5..b5e54d2 100644 --- a/app-arch/xz-utils/xz-utils-5.2.2.ebuild +++ b/app-arch/xz-utils/xz-utils-5.2.2.ebuild @@ -7,7 +7,7 @@ EAPI="4" -inherit eutils multilib toolchain-funcs libtool multilib-minimal +inherit eutils multilib libtool multilib-minimal sep-usr if [[ ${PV} == "" ]] ; then EGIT_REPO_URI="http://git.tukaani.org/xz.git"; diff --git a/app-arch/xz-utils/xz-utils-.ebuild b/app-arch/xz-utils/xz-utils-.ebuild index ac40bc4..784acf0 100644 --- a/app-arch/xz-utils/xz-utils-.ebuild +++ b/app-arch/xz-utils/xz-utils-.ebuild @@ -7,7 +7,7 @@ EAPI="4" -inherit eutils multilib toolchain-funcs libtool multilib-minimal +inherit eutils multilib libtool multilib-minimal sep-usr if [[ ${PV} == "" ]] ; then EGIT_REPO_URI="http://git.tukaani.org/xz.git"; -- 2.7.4
[gentoo-dev] [PATCH 08/21] sys-apps/acl: switch to sep-usr eclass
--- sys-apps/acl/acl-2.2.52-r1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sys-apps/acl/acl-2.2.52-r1.ebuild b/sys-apps/acl/acl-2.2.52-r1.ebuild index d1d2169..e645a73 100644 --- a/sys-apps/acl/acl-2.2.52-r1.ebuild +++ b/sys-apps/acl/acl-2.2.52-r1.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils toolchain-funcs multilib-minimal +inherit eutils multilib-minimal sep-usr DESCRIPTION="access control list utilities, libraries and headers" HOMEPAGE="http://savannah.nongnu.org/projects/acl"; @@ -15,7 +15,7 @@ SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux" IUSE="nls static-libs" -RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}] +RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?] abi_x86_32? ( !<=app-emulation/emul-linux-x86-baselibs-20140406-r2 !app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] -- 2.7.4
[gentoo-dev] [PATCH 06/21] app-arch/bzip2: switch to sep-usr eclass
--- app-arch/bzip2/bzip2-1.0.6-r6.ebuild | 2 +- app-arch/bzip2/bzip2-1.0.6-r7.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/app-arch/bzip2/bzip2-1.0.6-r6.ebuild b/app-arch/bzip2/bzip2-1.0.6-r6.ebuild index d7b2cdf..95ce04d 100644 --- a/app-arch/bzip2/bzip2-1.0.6-r6.ebuild +++ b/app-arch/bzip2/bzip2-1.0.6-r6.ebuild @@ -7,7 +7,7 @@ EAPI=4 -inherit eutils toolchain-funcs multilib multilib-minimal +inherit eutils toolchain-funcs multilib multilib-minimal sep-usr DESCRIPTION="A high-quality data compressor used extensively by Gentoo Linux" HOMEPAGE="http://www.bzip.org/"; diff --git a/app-arch/bzip2/bzip2-1.0.6-r7.ebuild b/app-arch/bzip2/bzip2-1.0.6-r7.ebuild index 60d0df3..4092978 100644 --- a/app-arch/bzip2/bzip2-1.0.6-r7.ebuild +++ b/app-arch/bzip2/bzip2-1.0.6-r7.ebuild @@ -7,7 +7,7 @@ EAPI=4 -inherit eutils toolchain-funcs multilib multilib-minimal +inherit eutils toolchain-funcs multilib multilib-minimal sep-usr DESCRIPTION="A high-quality data compressor used extensively by Gentoo Linux" HOMEPAGE="http://www.bzip.org/"; -- 2.7.4
[gentoo-dev] [PATCH 05/21] sys-libs/gpm: switch to sep-usr eclass
--- sys-libs/gpm/gpm-1.20.7-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-libs/gpm/gpm-1.20.7-r2.ebuild b/sys-libs/gpm/gpm-1.20.7-r2.ebuild index ee9f5a7..a29bf7e 100644 --- a/sys-libs/gpm/gpm-1.20.7-r2.ebuild +++ b/sys-libs/gpm/gpm-1.20.7-r2.ebuild @@ -6,7 +6,7 @@ EAPI="4" -inherit eutils systemd toolchain-funcs autotools multilib-minimal +inherit eutils systemd toolchain-funcs autotools multilib-minimal sep-usr DESCRIPTION="Console-based mouse driver" HOMEPAGE="http://www.nico.schottelius.org/software/gpm/"; -- 2.7.4
[gentoo-dev] [PATCH 04/21] sys-libs/pwdb: switch to sep-usr eclass
--- sys-libs/pwdb/pwdb-0.62.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-libs/pwdb/pwdb-0.62.ebuild b/sys-libs/pwdb/pwdb-0.62.ebuild index 920b19a..90f4a0e 100644 --- a/sys-libs/pwdb/pwdb-0.62.ebuild +++ b/sys-libs/pwdb/pwdb-0.62.ebuild @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils toolchain-funcs flag-o-matic +inherit eutils toolchain-funcs flag-o-matic sep-usr DESCRIPTION="Password database" HOMEPAGE="https://packages.gentoo.org/package/sys-libs/pwdb"; -- 2.7.4
[gentoo-dev] [PATCH 03/21] sys-libs/zlib: switch to sep-usr eclass
--- sys-libs/zlib/zlib-1.2.8-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-libs/zlib/zlib-1.2.8-r1.ebuild b/sys-libs/zlib/zlib-1.2.8-r1.ebuild index 43a555a..23161b0 100644 --- a/sys-libs/zlib/zlib-1.2.8-r1.ebuild +++ b/sys-libs/zlib/zlib-1.2.8-r1.ebuild @@ -5,7 +5,7 @@ EAPI=4 AUTOTOOLS_AUTO_DEPEND="no" -inherit autotools toolchain-funcs multilib multilib-minimal +inherit autotools toolchain-funcs multilib multilib-minimal sep-usr DESCRIPTION="Standard (de)compression library" HOMEPAGE="http://www.zlib.net/"; -- 2.7.4
[gentoo-dev] [PATCH 02/21] profiles: mask USE=sep-usr for most systems
--- profiles/base/use.mask | 3 +++ profiles/default/bsd/use.mask | 4 profiles/default/linux/use.mask | 4 profiles/prefix/darwin/use.mask | 4 4 files changed, 15 insertions(+) diff --git a/profiles/base/use.mask b/profiles/base/use.mask index 3127dad..8ef3e3a 100644 --- a/profiles/base/use.mask +++ b/profiles/base/use.mask @@ -396,3 +396,6 @@ openrc-force # sys-libs/libapparmor apparmor +# Mike Frysinger (30 Mar 2016) +# Most systems do not support a sep-/usr partition. +sep-usr diff --git a/profiles/default/bsd/use.mask b/profiles/default/bsd/use.mask index ba2cd7f..5776edd 100644 --- a/profiles/default/bsd/use.mask +++ b/profiles/default/bsd/use.mask @@ -77,3 +77,7 @@ sane_backends_qcam # Diego E. Pettenò (19 oct 2010) # unmasking flags that only apply to FreeBSD -kqueue + +# Mike Frysinger (30 Mar 2016) +# Allow people to opt-in to a sep-/usr partition. +-sep-usr diff --git a/profiles/default/linux/use.mask b/profiles/default/linux/use.mask index 647b635..db46d3b 100644 --- a/profiles/default/linux/use.mask +++ b/profiles/default/linux/use.mask @@ -17,3 +17,7 @@ x264 # Samuli Suominen (19 Apr 2013) # Linux specific module loading/unloading support -kmod + +# Mike Frysinger (30 Mar 2016) +# Allow people to opt-in to a sep-/usr partition. +-sep-usr diff --git a/profiles/prefix/darwin/use.mask b/profiles/prefix/darwin/use.mask index 3b7c8f9..5473e88 100644 --- a/profiles/prefix/darwin/use.mask +++ b/profiles/prefix/darwin/use.mask @@ -43,3 +43,7 @@ v4l # introspection is far from working on OSX introspection + +# Mike Frysinger (30 Mar 2016) +# Allow people to opt-in to a sep-/usr partition. +-sep-usr -- 2.7.4
[gentoo-dev] [PATCH 01/21] sep-usr.eclass: new eclass to hold gen_usr_ldscript and related logic #417451
This is mostly a copy of the func as it exists in the toolchain-funcs eclass, but with some of the initial logic shifted to USE=sep-usr. Once all ebuilds have switched over to this eclass, we can drop it from the toolchain-funcs eclass. In the meantime, make sure this is inherited last. --- eclass/sep-usr.eclass | 152 ++ profiles/use.desc | 1 + 2 files changed, 153 insertions(+) create mode 100644 eclass/sep-usr.eclass diff --git a/eclass/sep-usr.eclass b/eclass/sep-usr.eclass new file mode 100644 index 000..c6791e1 --- /dev/null +++ b/eclass/sep-usr.eclass @@ -0,0 +1,152 @@ +# Copyright 1999-2016 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: sep-usr.eclass +# @MAINTAINER: +# Toolchain Ninjas +# @BLURB: functions to support a split /usr partition +# @DESCRIPTION: +# Some core packages might install extra files into / instead of /usr when +# the expectation is that /usr is a separate mount point. This eclass holds +# various functions to simplify that process for ebuild writers. + +if [[ -z ${_SEP_USR_ECLASS} ]]; then +_SEP_USR_ECLASS=1 + +inherit multilib + +IUSE="sep-usr" + +# @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. +gen_usr_ldscript() { + local lib libdir=$(get_libdir) output_format="" auto=false suffix=$(get_libname) + [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/ + + # This code only matters when it's been enabled. #417451 + use sep-usr || return 0 + + # We only care about stuffing / for the native ABI. #479448 + if [[ $(type -t multilib_is_native_abi) == "function" ]] ; then + multilib_is_native_abi || return 0 + fi + + # Just make sure it exists + dodir /usr/${libdir} + + if [[ $1 == "-a" ]] ; then + auto=true + shift + dodir /${libdir} + fi + + # OUTPUT_FORMAT gives hints to the linker as to what binary format + # is referenced ... makes multilib saner + local flags=( ${CFLAGS} ${LDFLAGS} -Wl,--verbose ) + if $(tc-getLD) --version | grep -q 'GNU gold' ; then + # If they're using gold, manually invoke the old bfd. #487696 + local d="${T}/bfd-linker" + mkdir -p "${d}" + ln -sf $(which ${CHOST}-ld.bfd) "${d}"/ld + flags+=( -B"${d}" ) + fi + output_format=$($(tc-getCC) "${flags[@]}" 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p') + [[ -n ${output_format} ]] && output_format="OUTPUT_FORMAT ( ${output_format} )" + + for lib in "$@" ; do + local tlib + if ${auto} ; then + lib="lib${lib}${suffix}" + else + # 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 + #TODO: better die here? + fi + + case ${CTARGET:-${CHOST}} in + *-darwin*) + if ${auto} ; then + tlib=$(scanmacho -qF'%S#F' "${ED}"/usr/${libdir}/${lib}) + else + 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 + # 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 + fi + rm -f "${ED}"/${libdir}/${lib} + fi + + # Mach-O files have an id, which is like a soname, it tells how +
[gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default
To make forward progress on bug 417451, introduce a new sep-usr eclass that will hold all logic related to having a separate /usr. For now, this is just the gen_usr_ldscript function and a new USE=sep-usr flag. All ebuilds that call gen_usr_ldscript today will migrate to this and will allow people to move away from installing things into /. For the systems that want to have a split-/usr partition, they can turn on this USE flag across their system. This also allows us to mask the flag on many targets where it doesn't make sense (like most prefix setups) and where we don't want to support it at all. Mike Frysinger (21): sep-usr.eclass: new eclass to hold gen_usr_ldscript and related logic #417451 profiles: mask USE=sep-usr for most systems sys-libs/zlib: switch to sep-usr eclass sys-libs/pwdb: switch to sep-usr eclass sys-libs/gpm: switch to sep-usr eclass app-arch/bzip2: switch to sep-usr eclass app-arch/xz-utils: switch to sep-usr eclass sys-apps/acl: switch to sep-usr eclass sys-apps/attr: switch to sep-usr eclass sys-libs/pam: switch to sep-usr eclass dev-libs/lzo: switch to sep-usr eclass sys-libs/readline: switch to sep-usr eclass sys-apps/keyutils: switch to sep-usr eclass dev-libs/libaio: switch to sep-usr eclass sys-libs/libcap: switch to sep-usr eclass sys-libs/cracklib: switch to sep-usr eclass sys-libs/ncurses: switch to sep-usr eclass dev-libs/libpwquality: switch to sep-usr eclass dev-libs/libedit: switch to sep-usr eclass dev-libs/libpcre: switch to sep-usr eclass sys-apps/tcp-wrappers: switch to sep-usr eclass app-arch/bzip2/bzip2-1.0.6-r6.ebuild | 2 +- app-arch/bzip2/bzip2-1.0.6-r7.ebuild | 2 +- app-arch/xz-utils/xz-utils-5.2.2.ebuild| 2 +- app-arch/xz-utils/xz-utils-.ebuild | 2 +- dev-libs/libaio/libaio-0.3.110.ebuild | 2 +- dev-libs/libedit/libedit-20130712.3.1.ebuild | 4 +- dev-libs/libpcre/libpcre-8.38.ebuild | 10 +- dev-libs/libpwquality/libpwquality-1.3.0.ebuild| 12 +- dev-libs/lzo/lzo-2.08-r1.ebuild| 2 +- dev-libs/lzo/lzo-2.09.ebuild | 2 +- eclass/sep-usr.eclass | 152 + profiles/base/use.mask | 3 + profiles/default/bsd/use.mask | 4 + profiles/default/linux/use.mask| 4 + profiles/prefix/darwin/use.mask| 4 + profiles/use.desc | 1 + sys-apps/acl/acl-2.2.52-r1.ebuild | 4 +- sys-apps/attr/attr-2.4.47-r2.ebuild| 2 +- sys-apps/keyutils/keyutils-1.5.9-r1.ebuild | 2 +- .../tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild | 2 +- sys-libs/cracklib/cracklib-2.9.1-r1.ebuild | 4 +- sys-libs/cracklib/cracklib-2.9.4.ebuild| 4 +- sys-libs/cracklib/cracklib-2.9.5.ebuild| 4 +- sys-libs/cracklib/cracklib-2.9.6.ebuild| 4 +- sys-libs/gpm/gpm-1.20.7-r2.ebuild | 2 +- sys-libs/libcap/libcap-2.24-r2.ebuild | 4 +- sys-libs/libcap/libcap-2.25.ebuild | 4 +- sys-libs/ncurses/ncurses-5.9-r101.ebuild | 4 +- sys-libs/ncurses/ncurses-5.9-r3.ebuild | 4 +- sys-libs/ncurses/ncurses-5.9-r4.ebuild | 4 +- sys-libs/ncurses/ncurses-5.9-r5.ebuild | 4 +- sys-libs/ncurses/ncurses-5.9-r99.ebuild| 4 +- sys-libs/ncurses/ncurses-6.0-r1.ebuild | 4 +- sys-libs/ncurses/ncurses-6.0.ebuild| 4 +- sys-libs/pam/pam-1.2.1-r1.ebuild | 4 +- sys-libs/pam/pam-1.2.1.ebuild | 4 +- sys-libs/pwdb/pwdb-0.62.ebuild | 2 +- sys-libs/readline/readline-6.2_p5-r1.ebuild| 2 +- sys-libs/readline/readline-6.3_p8-r1.ebuild| 2 +- sys-libs/readline/readline-6.3_p8-r2.ebuild| 2 +- sys-libs/readline/readline-7.0_rc1.ebuild | 2 +- sys-libs/zlib/zlib-1.2.8-r1.ebuild | 2 +- 42 files changed, 227 insertions(+), 65 deletions(-) create mode 100644 eclass/sep-usr.eclass -- 2.7.4
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 15 Feb 2016 13:13, Francesco Riosa wrote: > Also, why, why people using systemd ARE interested in this thread? > You should not be interested at all. in case you're directing at me, i do not use systemd anywhere -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 15 Feb 2016 02:31, M. J. Everitt wrote: > I think people are confusing the fact that there IS no separate 'udev' i'm fully aware of this fact and have been since it happened. i don't think it changes my point. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 15:56, Anthony G. Basile wrote: > On 2/14/16 3:47 PM, Mike Frysinger wrote: > > On 14 Feb 2016 15:42, Anthony G. Basile wrote: > >> On 2/14/16 3:23 PM, Mike Frysinger wrote: > >>> eudev: no one of any relevance outside of Gentoo runs it. > >> > >> that's not true, nor is it the central criticism, imo. > > > > can you list the projects that utilize eudev ? the repo doesn't > > that i can see. it is the central criticism imo when correct > > interaction with other projects is key. people rely on rules being > > parsed & run correctly, as well as information provided by udev > > matching what they are running/testing everyday. > > until patrick brought up the list of distros, i was only aware of > alpine which is a musl based distro. then puppy and slack came > forward. they build their entire system using eudev as the libudev > provider. if there were issues, they would bring forward bug reports > like any other project. > > so when you say "people rely on rules being parsed ..." i don't know > why those user bases are dismissed. i'm not dismissing them per-se. i'm being practical here: i think you can agree that the combined developer base of alpine/puppy/slack(ware?) is significantly smaller as compared to the distros using udev. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 15:47, Anthony G. Basile wrote: > On 2/14/16 3:34 PM, Mike Frysinger wrote: > > the bring up of the daemon itself is not nearly as important as the > > runtime interaction of people using libudev or rules being executed. > > correct and i've been careful with libudev. > > anyhow, can we divert this away from udev/eudev. mike what do you > recommend as the future of openrc once systemd-udev can no longer be > extracted. if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead, and this whole thread is fairly moot. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 15:42, Anthony G. Basile wrote: > On 2/14/16 3:23 PM, Mike Frysinger wrote: > > eudev: no one of any relevance outside of Gentoo runs it. > > that's not true, nor is it the central criticism, imo. can you list the projects that utilize eudev ? the repo doesn't that i can see. it is the central criticism imo when correct interaction with other projects is key. people rely on rules being parsed & run correctly, as well as information provided by udev matching what they are running/testing everyday. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 21:31, Patrick Lauer wrote: > On 02/14/2016 09:23 PM, Mike Frysinger wrote: > > On 14 Feb 2016 11:41, Brian Dolbec wrote: > >> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote: > >>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote: > >>>> If, for any reason, eudev should be abandoned - we can just change > >>>> the virtual back. One-line change. > >>> Which is precisely the corresponding argument for not switching the > >>> default to eudev in the first place. > >> OH, my, this is looking more like you are being paid by systemd peeps... > > honestly ? cut the crap man. > > > >> You are just refusing to acknowledge these simple facts. > >> > >> systemd.: irrelevant to this decision > >> > >> standalone systemd-udev.: Vehemently unsupported, support for its > >>capability to exist is planned to be punted > >>in the future. > >> > >> eudev...: fully functional, actively developed, > >>and fully supported, mature project, been > >>around for years. > > udev: it's the default in every major distro that everyone tests and > > develops against. > Not the standalone config we're using, so if you remove all > systemd-using distros which are irrelevant to this discussion you end up > with gentoo, and ~15 distros that use eudev. And of course other > irrelevant weirdos that use mdev, vdev etc. > > > > eudev: no one of any relevance outside of Gentoo runs it. > No one runs udev either. So that's a non-argument > > > So given the context of this discussion, and your ignorant contribution > ... maybe you should cut the crap, man. Being a bit more polite wouldn't > be wrong either. yes, your e-mails in this thread are a shining example of how to collobarate and make cogent arguments. attacking people directly is definitely how you "win". it's too bad i haven't actually done any of what you're attempting to slander me with here. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 22:31, Alon Bar-Lev wrote: > On 14 February 2016 at 22:23, Mike Frysinger wrote: > > udev: it's the default in every major distro that everyone tests and > > develops against. > > > > eudev: no one of any relevance outside of Gentoo runs it. > > I honestly don't understand this argument that pops over and over. > > No "major distro" using udev without systemd, so OpenRC people are > already using udev in unsupported setup. > > Better to use a tool that is tested and supported in this setup. the bring up of the daemon itself is not nearly as important as the runtime interaction of people using libudev or rules being executed. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 Feb 2016 11:41, Brian Dolbec wrote: > On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote: > > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote: > > > If, for any reason, eudev should be abandoned - we can just change > > > the virtual back. One-line change. > > > > Which is precisely the corresponding argument for not switching the > > default to eudev in the first place. > > OH, my, this is looking more like you are being paid by systemd peeps... honestly ? cut the crap man. > You are just refusing to acknowledge these simple facts. > > systemd.: irrelevant to this decision > > standalone systemd-udev.: Vehemently unsupported, support for its >capability to exist is planned to be punted >in the future. > > eudev...: fully functional, actively developed, >and fully supported, mature project, been >around for years. udev: it's the default in every major distro that everyone tests and develops against. eudev: no one of any relevance outside of Gentoo runs it. > Oh and here is one final piece that should blow your reason away > > https://github.com/gentoo/eudev <== NOTICE that it's upstream is > within our gentoo domain. irrelevant. any Gentoo dev can create any repo in that namespace even when they shouldn't. the fact that eudev is in there does *not* mean the whole Gentoo project has signed on to it, or that it's some sort of "banner" project. it means at least one Gentoo dev decided to do X and our project system doesn't require project consensus before X can proceed. do not conflate these. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Changing order of default virtual/udev provider
On 09 Feb 2016 22:39, Duncan wrote: > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted: > > On 08 Feb 2016 13:46, Michał Górny wrote: > >> I'm strongly against this, because: > > > > agreed. i also don't see any reasons in Patrick's e-mail to suggest the > > current default is inadequate. "i don't like upstream" isn't relevant. > > I'd agree, except that the way we're running udev is strongly discouraged > and generally not supported by upstream, with a statement that it /will/ > break in the future, it's simply a matter of time. start a thread then when that actually happens -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]
On 03 Feb 2016 22:35, Andreas K. Huettel wrote: > Am Dienstag, 2. Februar 2016, 02:33:30 schrieb Mike Frysinger: > > > I took the liberty of doing (2) and reverted the commit. Not sure why > > > this needs so much discussion; after all a broken tree is always > > > suboptimal. > > > > unless things are on fire (which i don't think this was), i don't > > generally clamor for 0-day fixes. if we can find a better fix in > > a day or so, then i'm happy for that. i dislike repos with history > > that is just a constant stream of land, revert, land, revert, land. > > > > not that i'm saying your revert was wrong ... just airing my > > general personal preferences. > > You're right of course... but there's one thing we have to keep in mind. > > We're not running a project were releases are made from the vcs. The vcs *is* > the release... and whatever is out there gets pushed to users. > > This is why my personal preference is more to revert if I'm not sure that the > fix will happen soon. which is why you weigh the impact on users. how many people are actually affected and for how long ? in this case, fairly sure no actual user saw the failure on their system. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] abusive behaviour / communications from a user
On 02 Feb 2016 11:14, Ian Delaney wrote: > Members of comrel this is the gentoo-dev list. no idea why you're posting it here. if you want to rope in comrel, then do so on the bug, or file a new bug for them, or e-mail them directly. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 08 Feb 2016 13:46, Michał Górny wrote: > I'm strongly against this, because: agreed. i also don't see any reasons in Patrick's e-mail to suggest the current default is inadequate. "i don't like upstream" isn't relevant. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]
On 01 Feb 2016 22:16, Andreas K. Huettel wrote: > Am Montag, 1. Februar 2016, 21:30:41 schrieb Mike Frysinger: > > On 01 Feb 2016 19:55, Patrice Clement wrote: > > > > New issues: > > > > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl > > > > > > This commit is breaking the tree: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec > > > > > > I did try to work around the issue you've introduced when but the > > > enlightenment eclasses are a bit of mystery to me and I eventually gave > > > up. > > > > > > Could you revert this commit and fix this issue? > > > > the issue is that efl-1.15.2 is marked stable for alpha/ia64/sparc, and > > it depends on app-i18n/ibus, but commit 97a6aec deleted the only ibus > > ebuild that was marked stable for those arches. > > > > it can be fixed in a few ways (i'm listing in order of preference): > > (1) mark a newer ibus stable > > (2) revert that commit to re-add the old stable ebuilds > > (3) add USE=ibus to package.use.stable.mask for these arches > > (4) degrade all packages for these arches to unstable > > I took the liberty of doing (2) and reverted the commit. Not sure why this > needs so much discussion; after all a broken tree is always suboptimal. unless things are on fire (which i don't think this was), i don't generally clamor for 0-day fixes. if we can find a better fix in a day or so, then i'm happy for that. i dislike repos with history that is just a constant stream of land, revert, land, revert, land. not that i'm saying your revert was wrong ... just airing my general personal preferences. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]
On 01 Feb 2016 19:55, Patrice Clement wrote: > > New issues: > > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl > > This commit is breaking the tree: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec > > I did try to work around the issue you've introduced when but the > enlightenment > eclasses are a bit of mystery to me and I eventually gave up. > > Could you revert this commit and fix this issue? the issue is that efl-1.15.2 is marked stable for alpha/ia64/sparc, and it depends on app-i18n/ibus, but commit 97a6aec deleted the only ibus ebuild that was marked stable for those arches. it can be fixed in a few ways (i'm listing in order of preference): (1) mark a newer ibus stable (2) revert that commit to re-add the old stable ebuilds (3) add USE=ibus to package.use.stable.mask for these arches (4) degrade all packages for these arches to unstable -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: make_desktop_entry, remove unnecesssary extglob use
On 29 Jan 2016 09:24, Michał Górny wrote: > Remove an unnecessary extglob setting where a simpler ${foo%.*} is going > to suffice, considering that the stripping is done conditionally after > checking that one of the supported suffixes is used. looks obvious enough -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
On 22 Jan 2016 12:04, Alexis Ballier wrote: > On Thu, 21 Jan 2016 18:45:20 +0100 Michał Górny wrote: > > If I see a package that clearly doesn't build or otherwise simply > > doesn't work, could not have worked for past 3 years, are you forcing > > me to waste a time reporting a bug to no maintainer who could fix it? > > sure, don't waste your time and just delete it so that nobody can track > why it was removed or even attempt to fix it. > > > Because to me, the lack of any open bugs is a clear evidence that > > the package is not only unmaintained, but also unused. > > lack of open bug means there is no known bug; anything else is pure > supposition this. if anything, it sounds like i need to keep open a trivial bug for a package to keep people from wrongly proactively tree cleaning. the # of users of a package is irrelevant. if there are (real i.e. not "typo in message" bugs) open, then that's a diff story. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Herd likely up for grabs: kernel-misc
On 20 Jan 2016 19:48, Duncan wrote: > Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted: > > if base-system@ isn't going to maintain it, we'll punt it from the herd > > Umm, you mean project, right? Because the whole discussion here is part > of getting rid of herds. =:^) a distinction without a difference -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Herd likely up for grabs: kernel-misc
On 20 Jan 2016 12:39, Rich Freeman wrote: > On Wed, Jan 20, 2016 at 12:34 PM, Mike Frysinger wrote: > > On 18 Jan 2016 00:57, Joshua Kinard wrote: > >> On 01/17/2016 14:57, Michał Górny wrote: > >> > sys-apps/kexec-tools : > >> > >> Better suited for base-system, maybe? > >> > >> > sys-fs/jfsutils : > >> > >> Definitely base-system, as xfsprogs is already maintained by them. > > > > sounds fine for both. generally fs tools probably should live under > > base-system for consistency. > > Nothing wrong with consistency, but I'd prefer a package to be placed > under the base-system project because the base-system project members > intend to maintain it. I don't want to see packages placed into > projects simply because they're similar to other packages in those > projects if it means they'll just be neglected. > > I have no idea which is the case here. If the base-system maintainers > want to maintain these two packages, have at it! If not, leave it as > maintainer-needed. if base-system@ isn't going to maintain it, we'll punt it from the herd -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Herd likely up for grabs: kernel-misc
On 18 Jan 2016 00:57, Joshua Kinard wrote: > On 01/17/2016 14:57, Michał Górny wrote: > > Hello, everyone. > > > > The current maintainers of kernel-misc herd so far haven't replied to > > our queries. If we don't get any reply in a week, we will be disbanding > > it and looking for new maintainers for its packages. > > > > Is anyone interested in keeping the herd as a whole and maintaining all > > of its packages? If nobody replies till 2016-01-24, the herd will be > > automatically disbanded and I will be sending a complete list of > > packages needing maintainers. > > > > Packages currently in herd along with their other maintainers: > > > > [snip] > > > sys-apps/kexec-tools : > > Better suited for base-system, maybe? > > [snip] > > > sys-fs/jfsutils : > > Definitely base-system, as xfsprogs is already maintained by them. sounds fine for both. generally fs tools probably should live under base-system for consistency. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Herd up for grabs: xbox
On 18 Jan 2016 10:38, Alexis Ballier wrote: > On Sun, 17 Jan 2016 17:47:54 +0100 Michał Górny wrote: > > media-tv/kodi: > > media-tv/xbmc: > > you can add video herd for these two if vapier is ok with that i think sounds fine -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Herd up for grabs: net-dialup
On 17 Jan 2016 21:57, Lars Wendler wrote: > I am going to take the following packages: > > net-dialup/mingetty > net-dialup/ppp > net-dialup/rp-pppoe > > I think that I might not be the perfect maintainer for these packages > (especially for ppp) so if anyone else wants to maintain these, feel > free to add yourself as well. how about moving those to base-system@ ? for the low level serial ones, we can move them to embedded since they get way more use there nowadays than w/dialup modems. app-misc/ckermit net-dialup/lrzsz net-dialup/minicom net-dialup/picocom net-dialup/xc -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Herd likely up for grabs: net-fs
On 17 Jan 2016 21:03, Michał Górny wrote: > net-fs/autofs: dlan@ > net-fs/curlftpfs : slyfox@ > net-fs/davfs2: proxy-maintainers, gokt...@binghamton.edu > net-fs/libnfs: > net-fs/ncpfs : > net-fs/netatalk : > net-fs/nfs4-acl-tools: > net-fs/nfstest : prometheanfire@ > net-fs/nfs-utils : > net-fs/openafs : NP-Hardass@, bircoph@ > net-fs/openafs-kernel: NP-Hardass@, bircoph@ > net-fs/openafs-legacy: > net-libs/libgssglue : > net-libs/libnfsidmap : > net-libs/librpcsecgss: > net-libs/libtirpc: > net-libs/rpc2: > net-nds/portmap : base-system > net-nds/rpcbind : > sys-libs/lwp : > sys-libs/rvm : https://bugs.gentoo.org/569422#c3 nfs/rpc projects will move to base-system@. the rest are up for grabs. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 17 Dec 2015 11:57, Ulrich Mueller wrote: > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > On 15 Dec 2015 20:23, Anthony G. Basile wrote: > >> > short/mid term, i was thinking of writing a new package that > >> > holds the db and tools to query/manage it. user.eclass would > >> > DEPEND on it and ask it for details, perhaps even doing the > >> > actual fs updates (the bash code here is not pretty wrt locks and > >> > python would be much nicer). that tool could even search > >> > additional site paths (like /usr/local) to locate overrides. > >> > >> how do we get our own uid/gid's in there for our packages? just > >> open a bug against the new package? > > > i would open the git repo to all devs and just let anyone push > > directly and roll releases. maybe just push a tag and that's what > > the ebuild would hit. no need to be gate keepers here since we don't > > today w/ebuilds and calls to enew{user,group}. > > So if I want to add a new user or group, I would have to commit it to > the repo of that package, then roll a new release, create an ebuild > for that release, add that version to DEPEND of my own package's > ebuild, and only then my ebuild could refer to the new user? And > eventually, I'd have to take care of stabilising things, too? That > looks like a cumbersome procedure, even if it is only intended as a > stopgap solution until we can move things to a profile. yes, that's what you'd have to do. considering packages themselves have to go through stabilization, that particular aspect isn't a big deal. or we just auto-stable it. > Couldn't we add the user/group db to a subdir of the eclass dir > instead, so that user.eclass could access it there? people get whiny when we leverage eclass/ for storage. but we do it already, so it makes no difference to me. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: openrc c api (librc) usage
On 16 Dec 2015 06:44, Duncan wrote: > Mike Frysinger posted on Tue, 15 Dec 2015 00:00:51 -0500 as excerpted: > > On 10 Dec 2015 10:32, William Hubbs wrote: > >> I want to start a discussion about the usage of OpenRC's C api as > >> defined in rc.h. > > > > very few projects ever picked up the API/libraries. probably for the > > best. > > > >> I have no idea which projectss out there are using it, or which > >> functions they are using. > > > > look at the RDEPEND in ebuilds. if a package uses the libs, it should > > be listed there. > > Even with openrc still in @system? Doesn't look like that bug has been > fixed yet.[1] if you link against openrc, you need to RDEPEND on it -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 20:23, Anthony G. Basile wrote: > On 12/15/15 4:55 PM, Mike Frysinger wrote: > > On 15 Dec 2015 22:35, Ulrich Mueller wrote: > >> Whatever the format will be, the more important question is where this > >> would be implemented: > >> > >> - In the package manager, with user and group definition in profiles. > >> This seems to be what GLEP 27 suggests, and as far as I can see, it > >> would require an EAPI bump. Certainly doable, but last time we > >> bumped profiles to a new EAPI we had a rather long transition > >> period. > >> > >> - In user.eclass, which could be extended to use the EUSERS and > >> EGROUPS variables defined in ebuilds. The problem is, where would > >> one store the user and group definitions then? Profiles cannot be > >> accessed from an eclass. > > > > long term, i think profiles are better to hold the db as it provides for > > clean stacking and is trivial for site-specific extension/control, as well > > as image builders via something like catalyst. > > > > short/mid term, i was thinking of writing a new package that holds the db > > and tools to query/manage it. user.eclass would DEPEND on it and ask it > > for details, perhaps even doing the actual fs updates (the bash code here > > is not pretty wrt locks and python would be much nicer). that tool could > > even search additional site paths (like /usr/local) to locate overrides. > > how do we get our own uid/gid's in there for our packages? just open a > bug against the new package? i would open the git repo to all devs and just let anyone push directly and roll releases. maybe just push a tag and that's what the ebuild would hit. no need to be gate keepers here since we don't today w/ebuilds and calls to enew{user,group}. the question is how to handle the tools. i'm thinking we should have two distinct packages so the db could be completely overridden by overlays. the tools could be in the same repo or a sep one. i don't feel strongly either way as we'd just mark base-system@ as the maintaining herd. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 22:35, Ulrich Mueller wrote: > Whatever the format will be, the more important question is where this > would be implemented: > > - In the package manager, with user and group definition in profiles. > This seems to be what GLEP 27 suggests, and as far as I can see, it > would require an EAPI bump. Certainly doable, but last time we > bumped profiles to a new EAPI we had a rather long transition > period. > > - In user.eclass, which could be extended to use the EUSERS and > EGROUPS variables defined in ebuilds. The problem is, where would > one store the user and group definitions then? Profiles cannot be > accessed from an eclass. long term, i think profiles are better to hold the db as it provides for clean stacking and is trivial for site-specific extension/control, as well as image builders via something like catalyst. short/mid term, i was thinking of writing a new package that holds the db and tools to query/manage it. user.eclass would DEPEND on it and ask it for details, perhaps even doing the actual fs updates (the bash code here is not pretty wrt locks and python would be much nicer). that tool could even search additional site paths (like /usr/local) to locate overrides. the API to ebuilds/eclasses would be unchanged. in CrOS, we only look at the first argument (the user/group name) and load all other details from the db. we could seamlessly migrate over existing ebuilds by opting in to this simpler form. maybe the short/mid term solution is enough to not get into profile mess even if i think it's the correct data storage location. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: OpenRC public API definition
On 03 Dec 2015 11:36, William Hubbs wrote: > 1) All definitions in rc.h, even though they are not formally documented > in man pages. this. if it's not meant to be public, it should have been in librc.h or a similar internal header. > I'm bringing this up, because I am looking at redesigning one of the > undocumented functions soon, and the redesign will definitely break > things if people are using the function outside of OpenRC. bump the SONAME and forget about it. as mentioned in the other thread, there's not really any consumers today. plus, i'm pretty sure we've broken things a bit in the past but no one noticed/complained. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 15:56, Ulrich Mueller wrote: > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > a flat text file akin to /etc/passwd is not readable. xml is readable. > > ESR's case study about the password file format seems to disagree: > http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332 because you cited it, i read it anyways. that document is about how text formats should be preferred over binary formats because they do not require custom tools to modify/update, and because it's easier for binary formats to screw themselves over from a portability/extensible pov. it does not champion the passwd format all by itself, and even says that it's a bit rigid, and you should consider tagged formats if you want something more. which we do. see also the example i posted to Alec as why the format is hostile to devs whereas my simple RST proposal has none of these issues. we also know the format works because it's been in use by CrOS for two years now, including: (1) profile stacking/overrides (2) marking users as "dead" (3) tools to verify/check consistency at rest (4) parallel installs (5) correct handling of ROOT and SYSROOT although 4/5 were written only with Linux/flat files in mind, so they do not support other OS's or account formats (e.g. ldap/etc...). i imagine we'll need to merge with the existing user.eclass logic rather than drop in replace. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: converting copyright/license information in OpenRC
On 15 Dec 2015 13:37, William Hubbs wrote: > On Tue, Dec 15, 2015 at 02:24:22PM -0500, Mike Frysinger wrote: > > your description sounds like you want to run: > > s/Copyright .*/Copyright OpenRC Authors/ > > > > i'm saying you can't do that > > That's the first part, the second part is to have an Authors file at > the top level that lists all of the authors and refer to that in the > copyright statement, see the license branch of the main github repo and > let me know if this is legal. The site I linked seems to think so > because I'm not deleting copyright attributions, just moving them around. i don't think it's kosher. just reach out to Roy and see if he's OK with it and that'll avoid any ambiguity. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: converting copyright/license information in OpenRC
On 15 Dec 2015 09:31, William Hubbs wrote: > On Tue, Dec 15, 2015 at 12:05:07AM -0500, Mike Frysinger wrote: > > On 11 Dec 2015 14:16, Patrick McLean wrote: > > > On Fri, 11 Dec 2015 15:37:48 -0600 William Hubbs wrote: > > > > On Fri, Dec 11, 2015 at 09:04:47PM +0100, Ulrich Mueller wrote: > > > > > >>>>> On Fri, 11 Dec 2015, William Hubbs wrote: > > > > > > > > > Well, the OpenRC project is currently inconsistent about this, so the > > > > intention is to make it consistent. > > > > > > > > The .c/.h files have file-scope licenses, but that isn't true for > > > > everything in the project. > > > > > > > > I am willing to make the effort to do this, I was just wondering if > > > > there are any legal pitfalls I need to worry about. > > > > > > > > My theory is I can probably use git to find out who all of the authors > > > > are, and generate an Authors list from that information and from > > > > looking at copyright notices. > > > > > > One concern about this is the possibility of copied code. If OpenRC > > > ever copied code from other BSD licensed projects, then dropping the > > > notice from the top of the file would be a violation of the upstream > > > license. > > > > OpenRC isn't purely Gentoo copyright, so it's already a violation. > > the majority of entries belong to Roy. > > I have no idea what you mean by "it's already a violation", and I'm not > sure what Gentoo Copyright has to do with it. your description sounds like you want to run: s/Copyright .*/Copyright OpenRC Authors/ i'm saying you can't do that > Altering Copyright statements to try to claim Gentoo copyright would > definitely be a violation, but that's not what I'm wanting to do. adding multiple entries isn't a problem and in fact could/should be done in most openrc files at this time -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 10:35, Alec Warner wrote: > On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger wrote: > > a flat text file akin to /etc/passwd is not readable. xml is readable. > > u trollin' bro? in this domain, it's harder to screw up xml and not notice (either human or machine) whereas it's pretty easy to add/omit an extra : and not notice as the file will be valid from a parsing pov. quick, off the top of your head, which of these are correct ? and tell me which field exactly each one is supposed to go to ? and then reasonably expect new comers to read this and not choke ? lp:x:4:7::/var/spool/lpd:/bin/false lp:x:4:7:/var/spool/lpd:/bin/false lp:x:4:7:/var/spool/lpd::/bin/false lp:x:4:7::lpd:/bin/false lp:x:4:7:lpd:/bin/false lp:x:4:7:lpd::/bin/false i consider this format simply a different form of hazing except we all lose ;) -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 10:24, Anthony G. Basile wrote: > i looked through portage code and we do have xml parsing sprinkled > throughout, mostly in repoman for obvious reasons. why are we trying to > avoid xml? to be honest i don't have strong feelings about either the > flat file (a la /etc/passwd) or xml. > > i'm interested in this because the hardened-sources kernel does make use > of some special uid/gids. gengor pointed me to glep 27 and suggested > that i implement it but i wasn't that interested. still, it would clean > up the hardened. i don't think XML adds that much over RST, and are trivial to parse, both on an ad-hoc basis, as well as python has modules to enable it. i think most people would agree RST or flat text files are less verbose than XML w/out really losing that much (if anything). at the time i was thinking XML purely because we were much more of an XML shop at the time (we had guidexml and metadata.xml), but with the rise of wiki/github/glep and the fall of guidexml, the project has moved on. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 15:56, Ulrich Mueller wrote: > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > a flat text file akin to /etc/passwd is not readable. xml is readable. > > ESR's case study about the password file format seems to disagree: > http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332 i don't generally find anything ESR has to say useful, and his code even less so > I think the name:password:uid:gid:gecos:directory:shell format is > readable well enough for human eyes. having looked at way too many of these, i disagree. it's harder (imo) to scan due to the lack of alignment, it's more of a pita to deal with defaults, and it doesn't permit for additional metadata like i already quoted (the defunct field). > Certainly it is machine readable; > even with standard tools like fgetpwent(3) (or its equivalent in other > programming languages). again, not portable. the format proposed is also trivial to parse by python and awk. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 15:33, Michał Górny wrote: > On Tue, 15 Dec 2015 09:19:36 -0500 Mike Frysinger wrote: > > On 15 Dec 2015 07:28, Ulrich Mueller wrote: > > > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > > > > > On 14 Dec 2015 21:22, Ulrich Mueller wrote: > > > >> The spec seems incomplete. I cannot find a description of the user and > > > >> group files' format. (But in fact, there is a standard format which > > > >> suggests itself, namely that of the passwd(5) and group(5) files.) > > > > > > > i recall going with xml at the time, but i can't find reference to it. > > > > > > So the package manager would have to parse XML? We have tried to avoid > > > that, so far. > > > > not entirely accurate considering we have metadata.xml > > Not entirely accurate considering the contents of metadata.xml are not > necessary to build and install packages. read the context. your statement is fairly obvious. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 16:00, Michał Górny wrote: > On Tue, 15 Dec 2015 15:56:34 +0100 Ulrich Mueller wrote: > > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > > > a flat text file akin to /etc/passwd is not readable. xml is readable. > > > > ESR's case study about the password file format seems to disagree: > > http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332 > > > > I think the name:password:uid:gid:gecos:directory:shell format is > > readable well enough for human eyes. Certainly it is machine readable; > > even with standard tools like fgetpwent(3) (or its equivalent in other > > programming languages). > > Alternatively we could go for whitespace-separated, like fstab. Column > aligning even more. we cannot because whitespace is valid, and we use it already in fields -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 15 Dec 2015 07:28, Ulrich Mueller wrote: > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > On 14 Dec 2015 21:22, Ulrich Mueller wrote: > >> The spec seems incomplete. I cannot find a description of the user and > >> group files' format. (But in fact, there is a standard format which > >> suggests itself, namely that of the passwd(5) and group(5) files.) > > > i recall going with xml at the time, but i can't find reference to it. > > So the package manager would have to parse XML? We have tried to avoid > that, so far. not entirely accurate considering we have metadata.xml > >> Also having whole directory trees seems wasteful and doesn't fit so > >> well into the existing design of profiles. It might be simpler to put > >> "user" (or "passwd") and "group" files directly in the profile. > >> (If directories are really needed, we could use the scheme foreseen > >> in [1] for package.* and use.* files.) > > > we implemented this GLEP in Chromium OS and have been using it for a while: > > https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master > > > having a directory of files is way more user friendly imo and allows for > > a format that is easier to read. /etc/passwd and /etc/group format are > > not that easy to scan and aren't portable. > > As we most likely will introduce profile file directories in EAPI 7 > (see bug 282296), I'd rather use the same scheme for the user and > group files, but not something different. a flat text file akin to /etc/passwd is not readable. xml is readable. a markdown like format would work -- easy to parse by machines & humans and is a single stackable file. user:ntp uid:203 gid:203 user:man uid:13 gid:13 (using : as delimiter since that's what *NIX uses in /etc/passwd) the main one would grow probably to about 2000+ lines (~400 users in the tree and each entry takes ~4 lines assuming we enforce eliding of defaults) which isn't that terrible. CrOS has a python script already for validating the db consistency. > >> Also a mechanism how a subprofile could undefine a user or group > >> defined in its parent seems to be missing. > > > what exactly do you mean by that ? you want to make it so attempts to > > use the account yield an undefined error ? or you want to have it so > > a child can revert back to an earlier definition ? > > The former. we already handle this in CrOS by explicitly including a flag in the file: defunct:true thus the PM need not care about the status when locating files or otherwise include any special handling. if the last file you hit is marked as defunct, then enew{user,group} will throw an error when they're called. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)
On 02 Dec 2015 23:20, James Le Cuirot wrote: > On reflection, I'm now thinking that we should call it something less > generic. I also found that the Qt build uses SYSROOT for its own > purposes so you cannot rely on it in toolchain wrappers. ROOT is > probably just as unreliable. For that reason, I ended up using > CB_SYSROOT in cross-boss. it should be SYSROOT. we've been using it for years in Chromium OS w/out problems, it's in the base cross-compiling logic already, it's the obvious logical name, and it's used by a few ebuilds and upstream packages. no matter what name you pick you run the risk of colloding with upstream packages using it for something else. we've already seen that with the vars in the spec like ABI, ROOT, and D. > I forgot to mention earlier that if ROOT were used, PMS actually > forbids it from being referenced in the src_* phases so this > restriction would need to be lifted. Relying on the toolchain's > internal sysroot is not sufficient. sounds fine to forbid it > > > gcc and friends support a --sysroot argument. It used to be the case > > > that this didn't work on a toolchain configured without a sysroot, > > > possibly creating issues for #4, but I've tested and it now works > > > regardless. > > > > $ gcc --sysroot=/tmp/foo -I/usr/include foo.c > > /usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: > > this linker was not configured to use sysroots > > collect2: error: ld returned 1 exit status > > > > Two problems here: > > 1. link fails > > 2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's > > gcc do) > > Yeah, turns out my hello.c test was not sufficient. It seems gcc is > fine with it but binutils isn't. This seems silly to me so maybe this > could be patched out or perhaps building the native binutils with > --with-sysroot=/ would work? i vaguely recall older versions misbehaving, but should be fixed in the latest ones. which is why i haven't enabled it for all builds -- wanted to make sure things didn't break first w/native. > I know about -Wpoison-system-directories. We only enable it for > cross-compilers but I think it only triggers when cross-compiling > anyway. It's a shame they didn't make it dependent on --sysroot > instead. the eclass enables it only when creating cross-compilers. i could rework the code to be available all the time and work off of sysroot. i was going for conservative on the first pass. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Use GLEP27!
On 14 Dec 2015 21:22, Ulrich Mueller wrote: > The spec seems incomplete. I cannot find a description of the user and > group files' format. (But in fact, there is a standard format which > suggests itself, namely that of the passwd(5) and group(5) files.) i recall going with xml at the time, but i can't find reference to it. > Also having whole directory trees seems wasteful and doesn't fit so > well into the existing design of profiles. It might be simpler to put > "user" (or "passwd") and "group" files directly in the profile. > (If directories are really needed, we could use the scheme foreseen > in [1] for package.* and use.* files.) we implemented this GLEP in Chromium OS and have been using it for a while: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master having a directory of files is way more user friendly imo and allows for a format that is easier to read. /etc/passwd and /etc/group format are not that easy to scan and aren't portable. > Also a mechanism how a subprofile could undefine a user or group > defined in its parent seems to be missing. what exactly do you mean by that ? you want to make it so attempts to use the account yield an undefined error ? or you want to have it so a child can revert back to an earlier definition ? -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: converting copyright/license information in OpenRC
On 11 Dec 2015 14:16, Patrick McLean wrote: > On Fri, 11 Dec 2015 15:37:48 -0600 William Hubbs wrote: > > On Fri, Dec 11, 2015 at 09:04:47PM +0100, Ulrich Mueller wrote: > > > > On Fri, 11 Dec 2015, William Hubbs wrote: > > > > > Well, the OpenRC project is currently inconsistent about this, so the > > intention is to make it consistent. > > > > The .c/.h files have file-scope licenses, but that isn't true for > > everything in the project. > > > > I am willing to make the effort to do this, I was just wondering if > > there are any legal pitfalls I need to worry about. > > > > My theory is I can probably use git to find out who all of the authors > > are, and generate an Authors list from that information and from > > looking at copyright notices. > > One concern about this is the possibility of copied code. If OpenRC > ever copied code from other BSD licensed projects, then dropping the > notice from the top of the file would be a violation of the upstream > license. OpenRC isn't purely Gentoo copyright, so it's already a violation. the majority of entries belong to Roy. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: openrc c api (librc) usage
On 10 Dec 2015 10:32, William Hubbs wrote: > I want to start a discussion about the usage of OpenRC's C api as > defined in rc.h. very few projects ever picked up the API/libraries. probably for the best. > I have no idea which projectss out there are using it, or which > functions they are using. look at the RDEPEND in ebuilds. if a package uses the libs, it should be listed there. if you don't find any of those (few) packages actually using the API, then just make the change and wait for someone to complain. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] ncurses-5.9 -> ncurses-6.0 step-by-step?
On 14 Dec 2015 02:14, Joshua Kinard wrote: > I might've missed it, but do we have a step-by-step procedure to take a rootfs > that uses ncurses-5.9 and upgrade it to ncurses-6.0 WITHOUT breaking anything? > I, like others, ran into the problem of emerge yanking libncurses.so.5 libs > out when upgrading to ncurses-6.0, which broke bash and a few other packages. portage should preserve needed libraries. if it doesn't, file a bug. -mike signature.asc Description: Digital signature
[gentoo-dev] moving gcc-5.3 to unstable
all the blocking issues raised have been addressed w/gcc-5.3, so i'll be moving it into ~arch this weekend -mike signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7
On 01 Dec 2015 11:38, William Hubbs wrote: > I find the multilib eclasses and their separate multilib phase functions > to be confusing, so I was wondering if we could discuss making multilib > support native to portage in eapi 7 so that we can use the normal phase > functions again? we cannot hardcode the actual ABIs in PMS because adding/removing ones would require an EAPI update which is a terrible idea i don't see a benefit in adding the helper/phase functions either and wouldn't actually address your concern: you'd still need to know the API and how to use them. -mike signature.asc Description: Digital signature