Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger wrote: > well if we're going to do arbitrary lists ;) > (1) your options aren't mutually exclusive > (2) implementing both are desirable good to know your longterm plan :) however, even if both can be done, i still don't see the point of going through patching if we end up changing the default anyway. > (3) considering the glibc effort has been stalled for over a year, > (1) is something we can help accomplish and make reasonable progress > on (4) glibc isn't the only one that implements LFS in a transparent > backwards compatible manner maybe the fact that some file operations are broken with glibc's default settings on a somewhat popular fs would be a good argument to un-stall it ? > which leads me to the next part ... my first suggestion in the > tracker is for autotool based projects to use AC_SYS_LARGEFILE > because: (a) it supports a variety of systems > (b) as new systems come up or bugs are found or whatever, the > autoconf macro will improve and people eventually get those fixes for > free (c) it does it all transparently for you -- add the macro and > you're done (d) it fixes the package for all users, new & old > > the reason i listed only the raw CPPFLAGS and autoconf macros are > because those are the two i'm familiar with. i don't know how other > build systems (e.g. cmake) support this (assuming they do at all). > if people have other recipes on hand, then it would be great to > collect more there. -mike yes, but that is not what i am discussing: unless i missed something, they'll all end up one way or another adding the relevant defines; whether it is done with an m4 macro, append-lfs-flags, a cmake function or what else is an implementation detail of little interest to me trying to understand why we don't simply change the default :) Alexis.
[gentoo-dev] udev-init-scripts update
All, I have not released udev-init-scripts-28 yet. However, the latest version is set up the way I think we should go forward; it automatically adds the services to the sysinit runlevel. Take a look and let me know what you think. William signature.asc Description: Digital signature
Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On May 31, 2015 7:33:28 AM PDT, Alexis Ballier wrote: > >I'm not sure what's best for every one: >1. Push hundreds of patches upstream to add lfs flags; >2. Apply your patch to our glibc ebuilds, fix the corner cases, and go > back to glibc upstream with these data. > If the changes are made to glibc, would these be under a new symbol version for ABI compatibility, or just be changes to headers to make _FILE_OFFSET_BITS=64 the default? If not, what about binary software? Not saying you haven’t considered the relevant issues; I just haven’t seen binary software brought up on this list yet. -- Christopher Head
[gentoo-dev] s6.eclass: new eclass for installing s6 services
All,
we are starting to add support for s6 service supervision to Gentoo, so
I would like to add an eclass to facilitate the installation of s6
services.
Please take a look and let me know what you think.
If no one objects, I will commit this to the tree on 3 Jun.
Thanks,
William
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: s6.eclass
# @MAINTAINER:
# William Hubbs
# @BLURB: helper functions to install s6 services
# @DESCRIPTION:
# This eclass provides a helper to install s6 services.
# @EXAMPLE:
#
# @CODE
# inherit s6
#
# src_install() {
# ...
# s6_doservice myservice "${FILESDIR}"/run-s6 "${FILESDIR}"/finish-s6
# s6_doservice myservice/log "${FILESDIR}"/log-run-s6 \
# "${FILESDIR}"/log-finish-s6
# ...
# }
# @CODE
case ${EAPI:-0} in
0|1|2|3|4|5) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
# @FUNCTION: _s6_get_servicedir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed servicedir.
_s6_get_servicedir() {
echo /var/svc.d
}
# @FUNCTION: s6_get_servicedir
# @DESCRIPTION:
# Output the path for the s6 service directory (not including ${D}).
s6_get_servicedir() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
debug-print-function ${FUNCNAME} "${@}"
echo "${EPREFIX}$(_s6_get_servicedir)"
}
# @FUNCTION: s6_doservice
# @USAGE: servicename run finish
# @DESCRIPTION:
# Install an s6 service.
# servicename is the name of the service.
# run is the run script for the service.
# finish is the optional finish script for the service.
# This function is fatal in eapis newer than 4 and non-fatal otherwise.
s6_doservice() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
local run="$2"
local finish="$3"
[[ $name ]] ||
die "${ECLASS}.eclassYou must specify the s6 service name."
[[ $run ]] ||
die "${ECLASS}.eclass: You must specify the s6 service run
script."
(
local servicepath="$(_s6_get_servicedir)/$name"
exeinto "$servicepath"
newexe "$run" run
[[ $finish ]] && newexe "$finish" finish
)
}
signature.asc
Description: Digital signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
Dnia 2015-06-01, o godz. 12:13:52
William Hubbs napisał(a):
> # @FUNCTION: s6_get_servicedir
> # @DESCRIPTION:
> # Output the path for the s6 service directory (not including ${D}).
> s6_get_servicedir() {
> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
How about killing some support for ancient EAPIs? The less people can
use them, the better for ebuild migration.
> debug-print-function ${FUNCNAME} "${@}"
>
> echo "${EPREFIX}$(_s6_get_servicedir)"
> }
>
> # @FUNCTION: s6_doservice
> # @USAGE: servicename run finish
Please don't name it 'do*' if it doesn't match the usual do-function
usage, i.e. 'dofoo file1 file2...'. That's why I created
'systemd_install_serviced' and not 'doserviced'.
--
Best regards,
Michał Górny
pgpFdxZ3sVnNL.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
On Mon, Jun 01, 2015 at 07:24:26PM +0200, Michał Górny wrote:
> Dnia 2015-06-01, o godz. 12:13:52
> William Hubbs napisał(a):
>
> > # @FUNCTION: s6_get_servicedir
> > # @DESCRIPTION:
> > # Output the path for the s6 service directory (not including ${D}).
> > s6_get_servicedir() {
> > has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
>
> How about killing some support for ancient EAPIs? The less people can
> use them, the better for ebuild migration.
That's easy enough. In that case I would start support at eapi 5.
>
> > debug-print-function ${FUNCNAME} "${@}"
> >
> > echo "${EPREFIX}$(_s6_get_servicedir)"
> > }
> >
> > # @FUNCTION: s6_doservice
> > # @USAGE: servicename run finish
>
> Please don't name it 'do*' if it doesn't match the usual do-function
> usage, i.e. 'dofoo file1 file2...'. That's why I created
> 'systemd_install_serviced' and not 'doserviced'.
Ok, it would be easy enough to name it s6_install_service. There can't
be a do* in this case then because an s6 service is not just a simple
file.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/1/2015 1:13 PM, William Hubbs wrote: > All, > > we are starting to add support for s6 service supervision to > Gentoo, so I would like to add an eclass to facilitate the > installation of s6 services. > > Please take a look and let me know what you think. > > If no one objects, I will commit this to the tree on 3 Jun. > Can support be added for a run/finish log script? Should be no big deal to add what amounts to doexe $(s6_get_servicedir)/$name/log newexe run-s6 run Otherwise i may just cheat and use $name/log as the name on a second call since the eclass does not do any $name validation. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJVbJi1AAoJENH3ge/59KO2MZQP/2fc8nVlFkjXJGGFVchTKhwK XvUAB9PmF2oRz5xOPAbhfQc1YgQaVLDqFV/PrNHfN/gmcUnfvRv2JnSFEqw6Qv7O aCOQenVF6WhQjfxxfolZjBMX7M0rM2XgXQ8aHEov1JkQyV/1JXUr4MsLAyZwLE9v Di8MLcxZv/diJI3cqqiPucoehi/sPxQdc37mPbw3uGN+oWOzTMmwmUaPUEcvq2Pu gmtX6YA/A+1O/4pDXO7zJedHHFsluAlaUcuHJSp0LJ7RnfyFy0ZXqS4TjXs+N8q/ dPr51cKrL3bU1vLrOWQLHXvWHZIm3Uc3Po3P2x2AvqZpebltSFVZzaEq/e/DXrSK bgRpOzwTXMENHPM6cUr/GiebbAD+m3WG9TkS+wcd1C25NSsq+ocZQDJjaLf+VfpK hwZ1uIUy0Ux0LmdyGnnDNl8pWORldbtlC/tWjL3ZYf7OWVkRckxAoQ6lLSdf9qa/ pU2qO68bE3iDLL5r48QVmy4Xc1A1/zqge3vxvxG6DyerXJYRWF4OF23fSbCpdrQi BBRNE2p6g9jgJIps96iCL89DOdRAg6zopcMwZEO+e4cOHmAewxGFunsnCQAYsMIV 9EMUQH2l1vDwoKNglIgB6o/knGpjapJGgeU4IGlIjKjnuSucSaIYtquIqU5HagOR N+70MyEB9VVn0fgUneSa =OciI -END PGP SIGNATURE-
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
On Mon, Jun 01, 2015 at 01:39:01PM -0400, Brian Evans wrote:
> Can support be added for a run/finish log script?
> Should be no big deal to add what amounts to
>
> doexe $(s6_get_servicedir)/$name/log
> newexe run-s6 run
>
> Otherwise i may just cheat and use $name/log as the name on a second
> call since the eclass does not do any $name validation.
I'm open to it, I'm just not sure how I would make it happen since the
finish script for the service itself is optional. For example:
s6_install_service service script-1 script-2
In the above, script-2 is optional and could either be the finish script
for ${service} or the run script for ${service}/log, which is a service
itself.
The only way I can think of to allow service and log service
installation at the same time would be to use a reserved value such as
"none" to indicate that a script should be skipped. If I did that, to
install a run script and a log run script might look like:
s6_install_service service run-script none log-run-script
If you have a finish script, the call would be:
s6_install_service service run-script finish-script log-run-script
For either of these calls, there would also be an optional final
argument which would be the log-finish-script.
The tradeoff here would be that whatever I choose to indicate that a
script is skipped can't be used as a file name.
What do you think?
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
All,
here is an updated version of the eclass after receiving feedback on
IRC.
Let me know what you think.
Thanks,
William
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: s6.eclass
# @MAINTAINER:
# William Hubbs
# @BLURB: helper functions to install s6 services
# @DESCRIPTION:
# This eclass provides helpers to install s6 services.
# @EXAMPLE:
#
# @CODE
# inherit s6
#
# src_install() {
# ...
# s6_install_service myservice "${FILESDIR}"/run-s6
"${FILESDIR}"/finish-s6
...
# If you want a service to be logged, install the log service as
# shown here.
# s6_install_service myservice/log "${FILESDIR}"/log-run-s6 \
# "${FILESDIR}"/log-finish-s6
# ...
# }
# @CODE
case ${EAPI:-0} in
5) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
# @FUNCTION: _s6_get_servicedir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed servicedir.
_s6_get_servicedir() {
echo /var/svc.d
}
# @FUNCTION: s6_get_servicedir
# @DESCRIPTION:
# Output the path for the s6 service directory (not including ${D}).
s6_get_servicedir() {
debug-print-function ${FUNCNAME} "${@}"
echo "${EPREFIX}$(_s6_get_servicedir)"
}
# @FUNCTION: s6_install_service
# @USAGE: servicename run finish
# @DESCRIPTION:
# Install an s6 service.
# servicename is the name of the service.
# run is the run script for the service.
# finish is the optional finish script for the service.
s6_install_service() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
local run="$2"
local finish="$3"
[[ $name ]] ||
die "${ECLASS}.eclassYou must specify the s6 service name."
[[ $run ]] ||
die "${ECLASS}.eclass: You must specify the s6 service run
script."
(
local servicepath="$(_s6_get_servicedir)/$name"
exeinto "$servicepath"
newexe "$run" run
[[ $finish ]] && newexe "$finish" finish
)
}
# @FUNCTION: s6_service_down
# @USAGE: servicename
# @DESCRIPTION:
# Install the "down" flag so this service will not be started by
# default.
# servicename is the name of the service.
s6_service_down() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
[[ $name ]] ||
die "${ECLASS}.eclassYou must specify the s6 service name."
(
touch "$T"/down || die
local servicepath="$(_s6_get_servicedir)/$name"
insinto "$servicepath"
doins "$T"/down
)
}
# @FUNCTION: s6_service_nosetsid
# @USAGE: servicename
# @DESCRIPTION:
# Install the "nosetsid" flag so this service will not be made a session
# leader.
# servicename is the name of the service.
s6_service_nosetsid() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
[[ $name ]] ||
die "${ECLASS}.eclassYou must specify the s6 service name."
(
touch "$T"/nosetsid || die
local servicepath="$(_s6_get_servicedir)/$name"
insinto "$servicepath"
doins "$T"/nosetsid
)
}
signature.asc
Description: Digital signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
On 2015-06-01 17:08, William Hubbs wrote:
> [[ $name ]] ||
> die "${ECLASS}.eclassYou must specify the s6 service name."
This looks like it's missing a colon and space after ${ECLASS}.eclass,
note that this typo appears to be copied to a few other places.
Tim
signature.asc
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: linux-info.eclass
Dnia 2015-06-02, o godz. 04:27:35
"Mike Frysinger (vapier)" napisał(a):
> vapier 15/06/02 04:27:35
>
> Modified: linux-info.eclass
> Log:
> fix looking up output dir when cross-compiling (fix by Nam Nguyen from
> Chromium OS)
>
> Revision ChangesPath
> 1.106eclass/linux-info.eclass
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-info.eclass?rev=1.106&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-info.eclass?rev=1.106&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-info.eclass?r1=1.105&r2=1.106
>
> Index: linux-info.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/linux-info.eclass,v
> retrieving revision 1.105
> retrieving revision 1.106
> diff -u -r1.105 -r1.106
> --- linux-info.eclass 9 May 2015 08:03:40 - 1.105
> +++ linux-info.eclass 2 Jun 2015 04:27:35 - 1.106
> @@ -1,6 +1,6 @@
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/eclass/linux-info.eclass,v 1.105
> 2015/05/09 08:03:40 ulm Exp $
> +# $Header: /var/cvsroot/gentoo-x86/eclass/linux-info.eclass,v 1.106
> 2015/06/02 04:27:35 vapier Exp $
>
> # @ECLASS: linux-info.eclass
> # @MAINTAINER:
> @@ -529,7 +529,15 @@
> # but before we do this, we need to find if we use a different object
> directory.
> # This *WILL* break if the user is using localversions, but we assume
> it was
> # caught before this if they are.
> -
> OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"
> + if [[ -z ${OUTPUT_DIR} ]] ; then
> + # Try to locate a kernel that is most relevant for us.
> + for OUTPUT_DIR in "${SYROOT}" "${ROOT}" "" ; do
What's SYROOT? Did you mean SYSROOT?
> +
> OUTPUT_DIR+="/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build"
> + if [[ -e ${OUTPUT_DIR} ]] ; then
> + break
> + fi
> + done
> + fi
>
> [ -h "${OUTPUT_DIR}" ] && KV_OUT_DIR="$(readlink -f ${OUTPUT_DIR})"
> [ -d "${OUTPUT_DIR}" ] && KV_OUT_DIR="${OUTPUT_DIR}"
Also, how about you send your eclass changes for review like everyone
else is supposed to? That's how we usually fix bugs like the above.
Especially that you *aren't* listed as maintainer of the eclass, so
likely you won't even be CC-ed on bugs you created.
--
Best regards,
Michał Górny
pgpFHabew13yc.pgp
Description: OpenPGP digital signature
