Seems that it wants something from openrc. #!/bin/bash # # Based upon Debian's locale-gen, fetched from glibc_2.3.6-7.diff.gz # unset POSIXLY_CORRECT IFS umask 0022 argv0=${0##*/} source /etc/init.d/functions.sh || { echo "${argv0}: Could not source /etc/init.d/functions.sh!" 1>&2 exit 1 } Reproducible: Always
/etc/init.d/functions.sh is part of the core Gentoo system
No, OpenRC it's not necessarily part of the core Gentoo system. Not anymore since the inclusion of virtual/service-manager, which systemd satisfies, and therefore OpenRC may be removed when --depclean'ing if you use systemd.
A dep needs to be added until bug 373219, otherwise openrc can be depcleaned by portage (not sure if openrc team will know a better way of ensuring functions.sh is not depcleaned with openrc before getting bug 373219 solved)
(In reply to Canek Peláez Valdés from comment #2) i didn't say openrc was part of the core Gentoo system. read what i said. (In reply to Pacho Ramos from comment #3) this has nothing to do with bug 478252, nor do i see the need to add a dep. the status quo is nothing new here, and since only bug 373219 is going to be addressed, having these other various bugs open gains nothing.
(In reply to SpanKY from comment #4) > (In reply to Canek Peláez Valdés from comment #2) > > i didn't say openrc was part of the core Gentoo system. read what i said. > > (In reply to Pacho Ramos from comment #3) > > this has nothing to do with bug 478252, The problem is that it will get more people installing systemd in their systems and, then, this problem being more noticeable >nor do i see the need to add a dep. > the status quo is nothing new here, and since only bug 373219 is going to be > addressed, having these other various bugs open gains nothing. Nothing new regarding status quo, but status quo is that this bug is valid as a dep is missing causing openrc to be able to be depcleaned and that causing problems for packages like this
https://bugs.gentoo.org/show_bug.cgi?id=281523#c6 (Will discuss it here to try to know how to handle this and prevent people from shooting themselves in their foots)
(In reply to Pacho Ramos from comment #5) it isn't a new issue -> it's not a blocker. that's how it's always been.
(In reply to SpanKY from comment #7) > (In reply to Pacho Ramos from comment #5) > > it isn't a new issue -> it's not a blocker. that's how it's always been. My point was to try to keep more people from hitting this problem (specially since it can be solved adding a missing DEPEND)
<QA-hat> I'm a bit surprised that users are still exposed to this problem. There are more packages that need functions.sh, for example eselect. As a stopgap solution, openrc could be added to the system set, until bug 373219 is resolved. </QA-hat>
That is other option (anyway, I think most of packages with a missing DEPEND on openrc due functions.sh were reported already), who is taking care of maintaining system set?
(In reply to Pacho Ramos from comment #10) > who is taking care of maintaining system set? + 27 Aug 2013; Ulrich Müller <ulm@gentoo.org> packages: + Temporarily add sys-apps/openrc to the system set, until bug 373219 is + resolved. +
(In reply to SpanKY from comment #4) > (In reply to Canek Peláez Valdés from comment #2) > > i didn't say openrc was part of the core Gentoo system. read what i said. > > (In reply to Pacho Ramos from comment #3) > > this has nothing to do with bug 478252, nor do i see the need to add a dep. > the status quo is nothing new here, and since only bug 373219 is going to be > addressed, having these other various bugs open gains nothing. Can you please clarify why do you resolve this bug report as invalid? I am a systemd user and it is not clear to me!
All I needed was something quick and easy to cross compile, a few things, and overall quite simple. Less is more. For me the resolution is simple: I am forking off.
(In reply to Ulrich Müller from comment #11) > (In reply to Pacho Ramos from comment #10) > > who is taking care of maintaining system set? > > + 27 Aug 2013; Ulrich Müller <ulm@gentoo.org> packages: > + Temporarily add sys-apps/openrc to the system set, until bug 373219 is > + resolved. > + Can use something like virtual/efunctions.ebuild as I posted on bug #373219 instead now? This would change discussions to providing a suitable efunctions replacement, other packages could correctly depend on this virtual. And if a correct efunctions replacement can be emerged we update this virtual ebuidl to include it. And this bug may get closed without any more objections as we have a gento like solution!
Please see the tracker bug this bug blocks for info on how to fix this. The functions.sh that is part of the gentoo core will be in /lib/gentoo/functions.sh, and it should be sourced conditionally based on whether it exists or not, see how gentoolkit handled it. Thanks, William
*** Bug 504126 has been marked as a duplicate of this bug. ***
Created attachment 373030 [details, diff] glibc-locale-gen-dont_source_functions_sh_from_etc_initd.patch Possible fix...
Why not using $EPREFIX anymore?
<QA hat> This is a trivial fix that doesn't come with any real backwards compatibility dangers. In fact, it improves safety of packages through replacing implicit dependency on private API of a medium-sized package by explicit dependency on small, dedicated package. That said, 9 months (1.5yr in case of glibc) to apply the fix is definitely too long. Therefore, I'm setting a deadline on fixing the remaining bugs to 2014-12-27. If the bugs aren't fixed till that point, I will be committing simple 'sed' statements to replace the inherits. </QA hat>
(In reply to Michał Górny from comment #19) > <QA hat> > > Therefore, I'm setting a deadline on fixing the remaining bugs to > 2014-12-27. If the bugs aren't fixed till that point, I will be committing > simple 'sed' statements to replace the inherits. > > </QA hat> What are the "remaining bugs"?
(In reply to Anthony Basile from comment #20) > (In reply to Michał Górny from comment #19) > > <QA hat> > > > > Therefore, I'm setting a deadline on fixing the remaining bugs to > > 2014-12-27. If the bugs aren't fixed till that point, I will be committing > > simple 'sed' statements to replace the inherits. > > > > </QA hat> > > What are the "remaining bugs"? Presumably this bug and all other blockers to 504116. All that is required is to possibly add a dependency, and fix some paths. I believe the functions are identical so the risk of issues is very small.
(In reply to Michał Górny from comment #19) > <QA hat> > > This is a trivial fix that doesn't come with any real backwards > compatibility dangers. In fact, it improves safety of packages through > replacing implicit dependency on private API of a medium-sized package by > explicit dependency on small, dedicated package. > > That said, 9 months (1.5yr in case of glibc) to apply the fix is definitely > too long. Therefore, I'm setting a deadline on fixing the remaining bugs to > 2014-12-27. If the bugs aren't fixed till that point, I will be committing > simple 'sed' statements to replace the inherits. > > </QA hat> Okay I'm going to take care of this. Since the change is in vapier's dev space in glibc-2.20-patches-1.tar.bz2, I could either sed it or, more properly, reroll the tarball and put it in my dev space. I'll do the later because it seems the more correct approach. The fix will be in at least 2.20-r1 and maybe -9999 too. The other change will be that glibc will depend on sys-apps/gentoo-functions. @vapier. Sorry dude. It was either me or QA.
(In reply to Anthony Basile from comment #22) > @vapier. Sorry dude. It was either me or QA. Here are the only changes I made: yellow sys-libs # pwd /var/tmp/portage/sys-libs yellow sys-libs # diff -Naur glibc-2.20/work/extra/ glibc-2.20-r1/work/extra/ diff -Naur glibc-2.20/work/extra/locale/locale-gen glibc-2.20-r1/work/extra/locale/locale-gen --- glibc-2.20/work/extra/locale/locale-gen 2014-09-09 17:46:28.000000000 -0400 +++ glibc-2.20-r1/work/extra/locale/locale-gen 2014-12-28 11:37:13.000000000 -0500 @@ -14,8 +14,9 @@ EPREFIX="" fi -source "${EPREFIX}"/etc/init.d/functions.sh || { - echo "${argv0}: Could not source /etc/init.d/functions.sh!" 1>&2 +FUNCTIONS_SH="/lib/gentoo/functions.sh" +source "${EPREFIX}"${FUNCTIONS_SH} || { + echo "${argv0}: Could not source ${FUNCTIONS_SH}!" 1>&2 exit 1 } and yellow glibc # pwd /var/cvsroot/gentoo-x86/sys-libs/glibc yellow glibc # diff -Naur glibc-2.20.ebuild glibc-2.20-r1.ebuild --- glibc-2.20.ebuild 2014-11-17 20:54:54.692481643 -0500 +++ glibc-2.20-r1.ebuild 2014-12-28 12:09:09.000000000 -0500 @@ -1,6 +1,6 @@ # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/glibc-2.20.ebuild,v 1.6 2014/11/11 02:08:50 vapier Exp $ +# $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/glibc-2.20-r1.ebuild,v 1.1 2014/12/28 17:09:09 blueness Exp $ EAPI="4" @@ -27,7 +27,7 @@ ;; esac GCC_BOOTSTRAP_VER="4.7.3-r1" -PATCH_VER="1" # Gentoo patchset +PATCH_VER="2" # Gentoo patchset : ${NPTL_KERN_VER:="2.6.32"} # min kernel version nptl requires IUSE="debug gd hardened multilib nscd selinux systemtap profile suid vanilla crosscompile_opts_headers-only" @@ -69,6 +69,7 @@ !<sys-apps/portage-2.1.2 selinux? ( sys-libs/libselinux )" RDEPEND="!sys-kernel/ps3-sources + sys-apps/gentoo-functions selinux? ( sys-libs/libselinux ) !sys-libs/nss-db" @@ -91,7 +92,7 @@ echo mirror://gnu/glibc/$1 ftp://sourceware.org/pub/glibc/{releases,snapshots}/$1 mirror://gentoo/$1 } gentoo_uris() { - local devspace="HTTP~vapier/dist/URI HTTP~azarah/glibc/URI" + local devspace="HTTP~vapier/dist/URI HTTP~azarah/glibc/URI HTTP~blueness/glibc/URI" devspace=${devspace//HTTP/http://dev.gentoo.org/} echo mirror://gentoo/$1 ${devspace//URI/$1} }
I've added this to the glibc patchset: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/glibc/extra/locale/locale-gen?r1=1.35&r2=1.36
Okay no complaints. This is fixed in 2.20-r1 and above.
please don't commit revbumps like this. glibc is not cheap to build.
(In reply to SpanKY from comment #26) > please don't commit revbumps like this. glibc is not cheap to build. The next time something like this comes up, what approach would you recommend instead to ensure that a patch is included in the next regular update?
(In reply to Richard Freeman from comment #27) > (In reply to SpanKY from comment #26) > > please don't commit revbumps like this. glibc is not cheap to build. > > The next time something like this comes up, what approach would you > recommend instead to ensure that a patch is included in the next regular > update? The practice is to just bump PATCH_VER in place. Since many fixes are not needed by many users, you don't want to force a rebuild on everyone eg. a patch to glibc to fix a cross compile problem isn't needed by "regular" users, so we shouldn't force an expensive rebuild. Its a judgment call on when you can get away without a revbump. Here however, you need to add a RDEPEND on sys-apps/gentoo-functions, so I rev bumped. It needs to be added to -9999 as well which I did not do. I'll wait a bit and add that if Mike doesn't object or do it first. The commit would be: @@ -69,6 +69,7 @@ !<sys-apps/portage-2.1.2 selinux? ( sys-libs/libselinux )" RDEPEND="!sys-kernel/ps3-sources + sys-apps/gentoo-functions selinux? ( sys-libs/libselinux ) !sys-libs/nss-db"
(In reply to Richard Freeman from comment #27) you let the extra changes roll out with normal patch updates (In reply to Anthony Basile from comment #28) no, gentoo-functions should not be listed in any depend. it is part of the system.
> (In reply to Anthony Basile from comment #28) > > no, gentoo-functions should not be listed in any depend. it is part of the > system. Mike, this has been discussed and decided long ago, and many packages have already been fixed. If you don't participate, then at some point it's not yours to decide anymore.
(In reply to Andreas K. Hüttel from comment #30) > > (In reply to Anthony Basile from comment #28) > > > > no, gentoo-functions should not be listed in any depend. it is part of the > > system. > > Mike, > > this has been discussed and decided long ago, and many packages have already > been fixed. > > If you don't participate, then at some point it's not yours to decide > anymore. My apologies, seems I was misinformed. The definitive answer is in bug 504116.
(In reply to SpanKY from comment #29) > (In reply to Richard Freeman from comment #27) > > you let the extra changes roll out with normal patch updates > > (In reply to Anthony Basile from comment #28) > > no, gentoo-functions should not be listed in any depend. it is part of the > system. sys-apps/gentoo-functions is not listed in profiles/base/packages and grepping the tree for *DEPENDs, it doesn't look like anything in the @system set pulls it in. Here are the only packages depending on it: app-portage/gentoolkit x11-libs/libxcb app-admin/webapp-config app-admin/python-updater app-arch/makeself sys-devel/binutils-config sys-cluster/util-vserver games-emulation/virtualjaguar net-irc/eggdrop dev-util/ccache sys-libs/glibc And glibc and binutils-config only depend on it now that I've made those commits. I did think about this before adding the dependancy. Perhaps you're thinking of sys-apps/openrc?
(In reply to Andreas K. Hüttel from comment #31) > The definitive answer is in bug 504116. More specifically, bug 504116 comment 1.
(In reply to Mike Gilbert from comment #33) > (In reply to Andreas K. Hüttel from comment #31) > > The definitive answer is in bug 504116. > > More specifically, bug 504116 comment 1. Oh! I missed this point: "When yu make the fix, please do not add a hard dependency to sys-apps/gentoo-functions. The plan is to add this package to @system as soon as it goes stable." Darn, the rev bump wasn't necessary after all.
(In reply to Anthony Basile from comment #34) Since it seems people are not reading the entire bug report, bug 504116 comment 1 is quoted below. > After some discussion on the list, it was determined that if you add hard dependencies to your package for sys-apps/Gentoo-functions, we do not need to add it to @system at all, so go ahead and do that.
(In reply to Anthony Basile from comment #32) > > Perhaps you're thinking of sys-apps/openrc? One of the goals of this change is to virtualize openrc in @system. For that matter, containers don't necessarily need any init implementation, so I could forsee profiles in the future that don't have any in @system, but I doubt we'll see that until we clean up profiles so that having more of them doesn't entail a lot of overhead.
