Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Daniel Campbell]

On 10/04/2016 10:25 AM, Ian Stakenvicius wrote:
> On 20/08/16 08:30 PM, Daniel Campbell wrote:
>> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
>>> wrote:
 1) Stabilization is a simpler and much more formalized process compared to
 normal bug resolution.
 * There is one version to be stabilized.
 * One precise package version
>>>
>>> Can you clarify what this means?  Do you mean that at any time only
>>> one version of any particular package/slot is marked stable?
>>>
>>> That seems like it would be problematic for ranged deps.  Granted,
>>> those are problematic in and of themselves since they can create
>>> conflicts that are hard to resolve.  However, this extends conflicts
>>> between package you might not want to install at the same time to
>>> situations where you don't even need both of the conflicting packages.
>>>
>> I believe he's just talking about a per-bug or per-stablereq basis. So
>> each version gets its own opportunity to have bugs surface or
>> stabilization issues instead of attempting to stabilize a bunch of
>> versions at once.
>>
>> (Correct me if I'm wrong; I don't see the value of a single stable
>> version for each package and it would create a lot of noise in git log)
>>
> 
> Even though some projects (mozilla, for instance) do request
> stabilizations of multiple packages and/or versions in a single go,
> that doesn't mean we should and I have no issues changing our process
> to something more atomic.
> 
> What should be noted here is that if we work towards adopting new
> tools or methods here, we absolutely need to do so in a way that is
> beneficial to the workflow of our AT's, especially those that perform
> large numbers of stabilizations like ago.  If this new process doesn't
> make things at least incrementally easier for them, it needs to be
> re-thought.
> 
> 
What sort of things would fit best into AT workflow? Different bug
states make it easier to filter bugs for ourselves. Is there another
mechanic you'd rather see?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [warning] the bug queue has 95 bugs

[Alex Alexander]

Our bug queue has 95 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-portage-dev] [PATCH v2] setup.py: enable libc bindings optionally (bug 594744)

[Alexander Berntsen]

LGTM.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2] setup.py: enable libc bindings optionally (bug 594744)

[Zac Medico]

The libc bindings are optional, since ctypes is used as a fallback when
they are not available. The libc bindings do not support cross-
compilation, therefore it is useful to be able to build them
conditionally. This patch adds an option to enable them conditionally,
which the ebuild can use by adding the following code to the
python_prepare_all function:

if use native-extensions; then
printf "[build_ext]\nportage-ext-modules=true" >> \
setup.cfg || die
fi

X-Gentoo-Bug: 594744
X-Gentoo-Bug-URL: https://bugs.gentoo.org/594744
---
[PATCH v2] adds a "Native Extensions" section to the README file, and
updates the commit message to note that the libc bindings are optional
because ctypes is used as a fallback.

 .travis.yml |  1 +
 README  | 19 +++
 setup.py| 21 +
 3 files changed, 41 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index c098c4d..ded5893 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -10,6 +10,7 @@ python:
 install: "pip install lxml"
 
 script:
+- printf "[build_ext]\nportage-ext-modules=true" >> setup.cfg
 - ./setup.py test
 - ./setup.py install --root=/tmp/install-root
 # prevent repoman tests from trying to fetch metadata.xsd
diff --git a/README b/README
index 5e78842..311d036 100644
--- a/README
+++ b/README
@@ -13,6 +13,25 @@ Dependencies
 Python and Bash should be the only hard dependencies. Python 2.7 is the
 minimum supported version.
 
+Native Extensions
+=
+
+Portage includes some optional native extensions which can be built
+in the source tree by running the following command:
+
+python setup.py build_ext --inplace --portage-ext-modules
+
+The following setup.cfg settings can be used to enable building of
+native extensions for all invocations of the build_ext command (the
+build_ext command is invoked automatically by other build commands):
+
+   [build_ext]
+   portage-ext-modules=true
+
+Currently, the native extensions only include libc bindings which are
+used to validate LC_CTYPE and LC_COLLATE behavior for EAPI 6. If the
+native extensions have not been built, then portage will use ctypes
+instead.
 
 Licensing and Legalese
 ===
diff --git a/setup.py b/setup.py
index e900aaa..e2c6b6e 100755
--- a/setup.py
+++ b/setup.py
@@ -6,6 +6,7 @@ from __future__ import print_function
 
 from distutils.core import setup, Command, Extension
 from distutils.command.build import build
+from distutils.command.build_ext import build_ext as _build_ext
 from distutils.command.build_scripts import build_scripts
 from distutils.command.clean import clean
 from distutils.command.install import install
@@ -624,6 +625,25 @@ def get_manpages():
yield [os.path.join('$mandir', topdir, 'man%s' 
% g), mans]
 
 
+class build_ext(_build_ext):
+   user_options = _build_ext.user_options + [
+   ('portage-ext-modules', None,
+"enable portage's C/C++ extensions (cross-compling is not 
supported)"),
+   ]
+
+   boolean_options = _build_ext.boolean_options + [
+   'portage-ext-modules',
+   ]
+
+   def initialize_options(self):
+   _build_ext.initialize_options(self)
+   self.portage_ext_modules = None
+
+   def run(self):
+   if self.portage_ext_modules:
+   _build_ext.run(self)
+
+
 setup(
name = 'portage',
version = '2.3.1',
@@ -651,6 +671,7 @@ setup(
 
cmdclass = {
'build': x_build,
+   'build_ext': build_ext,
'build_man': build_man,
'build_scripts': x_build_scripts,
'build_scripts_bin': x_build_scripts_bin,
-- 
2.7.4