Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
On Tue, 09 Jul 2013 20:45:16 -0400 Alex Xu alex_y...@yahoo.ca wrote: On second thought, I agree. Maybe dev can be changed to show an Email column with mailto: links? Please no, this is going to be more effective as a bait to spam than that we would receive any useful mails on it; there is a better way: https://wiki.gentoo.org/wiki/Special:EmailUser/a3li Which you can turn off if you want to (I'll probably turn it on later): https://wiki.gentoo.org/wiki/Special:EmailUser/TomWij The form still seems to miss a CAPTCHA though. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
Alex Legler a...@gentoo.org wrote: - Developer list: Moves to the sidebar. Not sure how to render that. Maybe in a comment and people remove that once they have added all the members? Oh so the developer list and subproject list will be generated by mediawiki? Cool. I can just drop that (at the time of conversion the project sites themselves are still available to consult). I'll update the stylesheet with the suggested style improvements this evening. Wkr, Sven Vermeulen -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/10/2013 08:58 AM, Tom Wijsman wrote: On Tue, 09 Jul 2013 20:45:16 -0400 Alex Xu alex_y...@yahoo.ca wrote: On second thought, I agree. Maybe dev can be changed to show an Email column with mailto: links? Please no, this is going to be more effective as a bait to spam than that we would receive any useful mails on it; there is a better way: https://wiki.gentoo.org/wiki/Special:EmailUser/a3li This replaces the old dev lists which mentioned a way to contact the devs via mail. We should stick with this offer. I don't want to see most of the devs unreachable to the public because a) the forgot to activate this form, b) users don't get the uid@gentoo.org schema. And this stu^H^Himple form has no gpg-signing, (B)CC or other stuff. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHdJR8ACgkQknrdDGLu8JB3pgD+Mtm0mOCfTeqJv2lKC6UzWMQL RmHP4HUed4+17ULj2N8A/1L6XeQcQVAIOvalAcIBS794KXln1HOrXmeijKTA8aj1 =9rCE -END PGP SIGNATURE-
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 10 Jul 2013 11:10:55 +0200 Michael Weber x...@gentoo.org wrote: On second thought, I agree. Maybe dev can be changed to show an Email column with mailto: links? Please no, this is going to be more effective as a bait to spam than that we would receive any useful mails on it; there is a better way: https://wiki.gentoo.org/wiki/Special:EmailUser/a3li This replaces the old dev lists which mentioned a way to contact the devs via mail. We should stick with this offer. I don't want to see most of the devs unreachable to the public because a) the forgot to activate this form, b) users don't get the uid@gentoo.org schema. And this stu^H^Himple form has no gpg-signing, (B)CC or other stuff. Makes sense, I have read context now; I'd vote to keep the old way, unless some sane way is implemented to not double the amount of spam. Example a href=#109;#97;#105;#108;#116;#111;#58;%74%65 %73%74%40%65%78%61%6D%70%6C%65%2E%63%6F%6DContact/a links to mailto:t...@example.com. This works an any standard browser and keeps most crawlers at bay; to be even more effective, mix # and % syntax. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR3Si4AAoJEJWyH81tNOV9FxUH/RYbkHb3VrMQM6CzpVmWEISE RrtoPg4dXtHonNJt97cVISDlF8/p0iaCOSEm+Qy5nuIzf5RVJBo5kqgot2gGX6Ls mghdrM/yqLLNNSnS/QM9KR1KFFCTzk8Al0OqgkeVBXYPg8G9g0dL5yebJqw0F7KM qGXsxZhvlnNqj6SYEMc14858vRGmt5lkG/JFHgr7VUfrcgkjC2QEImLti/1L5JcK 1ch7PtJhnMEMTe6zQGZdumiT6CIPLmeUVR6OFyZ6+Zyou/SbH0Ry5yaS3u85e3Jl m9ORmsCDAOJqqAigXLPjLGrlGp6NHNr0eUnMECp6LHyCDbc98XIeIf2+lqkidcc= =az9Y -END PGP SIGNATURE-
[gentoo-dev] New eclass - twisted-r1
Hello everypony In order to bump dev-python/twisted packages to EAPI=5 we also need to bump the twisted eclass to use distutils-r1. I have made this bump (to the eclass and dev-python/twisted*) packages in my yac overlay [1] You can view the actuall changes at [2]. It's merely the existing twisted eclass adapted to distutils-r1. I have tested the packages (merge, module import in python and tests) on python2_7 at amd64. I don't know when I'll get around to testing other pythons and x86. Certainly I'm currently unable to test pypy and eprefix. Besides reviewing the changes, could somepony test these arches? [1] https://github.com/yaccz/gentoo-overlay/tree/twisted-r1 [2] https://github.com/yaccz/gentoo-overlay/compare/5421996...020b0c2 signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass - twisted-r1
First of all: please wrap lines at 72 or 80 chars (even if the original
eclass didn't do that).
if [[ ${CATEGORY}/${PN} == dev-python/twisted* ]]; then
I know you're not responsible for this but it seems wrong to have two
different behaviors depending on PN. Is this used somewhere actually?
MY_PV=${MY_PV:-${PV}}
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
#SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
SRC_URI=http://twistedmatrix.com/Releases/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
TWISTED_PLUGINS=${TWISTED_PLUGINS:-twisted.plugins}
fi
# @ECLASS-VARIABLE: TWISTED_PLUGINS
# @DESCRIPTION:
# Twisted plugins, whose cache is regenerated in pkg_postinst() and
pkg_postrm() phases.
python_test() {
# TODO: this seems to be used only in dev-python/twisted-* packages as
# dev-python/twisted-13.0.0 have it's own src_test
if [[ ${CATEGORY}/${PN} != dev-python/twisted* ]]; then
die ${FUNCNAME}() can be used only in dev-python/twisted*
packages
fi
local sitedir=${EPREFIX}$(python_get_sitedir)
# Copy modules of other Twisted packages from site-packages directory
to temporary directory.
mkdir -p ${T}/${sitedir}
cp -R ${ROOT}${sitedir}/twisted ${T}/${sitedir} || die Copying of
modules of other Twisted packages failed with $(python_get_implementation)
$(python_get_version)
rm -fr ${T}/${sitedir}/${PN/-//}
Awful and ugly. Try to find a way to run the tests without this hackery.
# Install modules of current package to temporary directory.
${PYTHON} setup.py build -b build-${EPYTHON} install --force
--no-compile --root=${T} || die Installation into temporary directory
failed with $(python_get_implementation) $(python_get_version)
This is likely a candidate for 'distutils_install_for_testing'.
Or 'esetup.py' at least. Inlining build-dir is simply wrong.
pushd ${T}/${sitedir} /dev/null || return 1
PATH=${T}${EPREFIX}/usr/bin:${PATH} PYTHONPATH=${T}/${sitedir}
trial ${PN/-/.} || return 1
popd /dev/null || return 1
rm -fr ${T}/${sitedir}
}
twisted-r1_src_install() {
distutils-r1_src_install
if [[ -d doc/man ]]; then
doman doc/man/*.[[:digit:]]
fi
if [[ -d doc ]]; then
insinto /usr/share/doc/${PF}
doins -r $(find doc -mindepth 1 -maxdepth 1 -not -name man)
fi
}
_twisted-r1_update_plugin_cache() {
local dir exit_status=0 module
for module in ${TWISTED_PLUGINS}; do
if [[ -d ${EROOT}$(python_get_sitedir)/${module//.//} ]]; then
find ${EROOT}$(python_get_sitedir)/${module//.//}
-name dropin.cache -print0 | xargs -0 rm -f
fi
done
for module in ${TWISTED_PLUGINS}; do
#
http://twistedmatrix.com/documents/current/core/howto/plugin.html
${PYTHON} -c \
import sys
sys.path.insert(0, '${EROOT}$(python_get_sitedir)')
try:
import twisted.plugin
import ${module}
except ImportError:
if '${EBUILD_PHASE}' == 'postinst':
raise
else:
# Twisted, zope.interface or given plugins might have been
uninstalled.
sys.exit(0)
list(twisted.plugin.getPlugins(twisted.plugin.IPlugin, ${module})) ||
exit_status=1
done
for module in ${TWISTED_PLUGINS}; do
# Delete empty parent directories.
local dir=${EROOT}$(python_get_sitedir)/${module//.//}
while [[ ${dir} != ${EROOT%/} ]]; do
rmdir ${dir} 2 /dev/null || break
dir=${dir%/*}
done
done
return ${exit_status}
}
twisted-r1_pkg_postinst() {
_distutils-r1_run_foreach_impl _twisted-r1_update_plugin_cache
}
twisted-r1_pkg_postrm() {
_distutils-r1_run_foreach_impl _twisted-r1_update_plugin_cache
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass - twisted-r1
On Wed, 10 Jul 2013 22:25:50 +0200
Michał Górny mgo...@gentoo.org wrote:
First of all: please wrap lines at 72 or 80 chars (even if the
original eclass didn't do that).
if [[ ${CATEGORY}/${PN} == dev-python/twisted* ]]; then
I know you're not responsible for this but it seems wrong to have two
different behaviors depending on PN. Is this used somewhere actually?
MY_PV=${MY_PV:-${PV}}
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
#SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
SRC_URI=http://twistedmatrix.com/Releases/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
TWISTED_PLUGINS=${TWISTED_PLUGINS:-twisted.plugins}
fi
That's what I thought when I saw that but I found that all the
dev-python/twisted-* packages are depending on this, so I went with it.
Now I'm thinking I could instead provide functions
twisted-r1_twisted_src_uri and twisted-r1_twisted_build_dir used as
SRC_URI=$(twisted-r1_twisted_src_uri)
S=$(twisted-r1_twisted_build_dir)
in the depender ebuilds.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2013 10:03 PM, Robin H. Johnson wrote: On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? Please be more specific, this is currently implemented... - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR3ihMAAoJEKXdFCfdEflKH4sP/1dswIQytHVOXtI6mqzntqjy 9rBl2tkBft2gdQp7Vru3d4s0HiicpeLImSyvIM8H2FVmbEVutMwOOUWp2tllOUNh bb98BnrAoSMz4GEPtcS2d0vmZ3HdDj99mrnkOOWcqvHRPMn/J0KogAyrCVRa0+Pb bNEo2dU5g4Jegs8gl4l1ilH0hIyb7uqurwjd5G8NayJIs0U5gIpTHZzPvRJo0B98 tnzEsoSTY0JekgSGC+8xgR4ijmR0AicF5nCciKUjFf7OjEDitK6sF6g3m92zM8hU fjPLTW0vjR63KbtOJNgw992DpQoUfRj2jYn4ErjDB1jKz5+xvLy0+rpwZPYA4hgf QNck4OnLRqK6rMy45Tzu58gfUsH1GIdmdH0JJ0x2rBLu89GHB4HSR+UlE5ugxmvj uzs2ZJ8MPIT7mYnrqJ8XbiMzDmkvspkixbi6YpbiNCi76R08ljNXFjT0Ju5nI29u W+6p/we4FMPLo47W5zSAS4Csa0reIayaIpJTbeyfHVe88DcS6jO+JAs416mod9ec 1SYogk+SFrmFC0PyW9uQeP0gE12U20bw0NCI0R5+PmXIs54jrowIJgjB8hPH8Cpz df7+ZNGuDaOqQnJT5j1EwzfAPEGVHmHtIaMu3bRMv0EJZj3WMa1rABtFFX+65S1x dz87xG1hys5ZZmz8IzOQ =+Lzs -END PGP SIGNATURE-
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Wed, Jul 10, 2013 at 8:36 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 07/10/2013 10:03 PM, Robin H. Johnson wrote: On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? Please be more specific, this is currently implemented... He's talking about portage, not catalyst.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Wed, Jul 10, 2013 at 11:36:44PM -0400, Rick Zero_Chaos Farina wrote: On 07/10/2013 10:03 PM, Robin H. Johnson wrote: On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? Please be more specific, this is currently implemented... I was partially responding to dolsen's comment that it wasn't capable, as well as a discussion I had with somebody on the ChromeOS team a few months ago. In the ChromeOS case, if a library was removed off the system, but Portage still thought it was there, and you went to install a binpkg that had an ELF dependency on the removed library, you'd have broken binaries on the system. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On 07/10/2013 08:43 PM, Robin H. Johnson wrote: On Wed, Jul 10, 2013 at 11:36:44PM -0400, Rick Zero_Chaos Farina wrote: On 07/10/2013 10:03 PM, Robin H. Johnson wrote: On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? Please be more specific, this is currently implemented... I was partially responding to dolsen's comment that it wasn't capable, as well as a discussion I had with somebody on the ChromeOS team a few months ago. In the ChromeOS case, if a library was removed off the system, but Portage still thought it was there, and you went to install a binpkg that had an ELF dependency on the removed library, you'd have broken binaries on the system. Ideally, this would be handled entirely by EAPI 5 slot-operator dependencies. However, it seems like we'll need some form of sub-slot pass-through [1] and/or sub-slot dictionaries [2] before we'll be able to achieve complete adoption of slot-operators. Meanwhile, adding a preinst sanity check seems like a good idea. The LinkageMap class that's used for preserve-libs already has all of the info that we need about installed libraries, so it's just a matter of checking the binary package's NEEDED.ELF.2 entries against that. [1] https://bugs.gentoo.org/show_bug.cgi?id=449094 [2] https://bugs.gentoo.org/show_bug.cgi?id=462138 -- Thanks, Zac
