[gentoo-dev] Package up for grabs

[Brendan Horan]

Hi,

I am currently the proxy maintainer for app-arch/snappy.
I no longer have the time/interest to proxy maintain this.
I wish to be removed from the metadata.xml.

It has one open bug :
https://bugs.gentoo.org/show_bug.cgi?id=551238

There are currently no other maintainers.
This would drop it back to "Maintainer Needed" if no one is interested.

Thanks

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Joakim Tjernlund]

On Fri, 2016-05-27 at 18:21 -0400, NP-Hardass wrote:
> On 05/27/2016 06:05 PM, Daniel Campbell wrote:
> > On 05/27/2016 02:45 PM, NP-Hardass wrote:
> > > Not on hand, but as the MATE maintainer, I can tell you that starting
> > > with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
> > > more are.
> > > 
> 
> > 
> > Aha, thanks for offering that info. Which ones if you don't mind?
> > 
> in 1.14 x11-misc/mozo and mate-extra/mate-system-monitor.  Don't have
> the 1.16 ones handy as I haven't been able to work on it the last week
> (more hw issues)
> 

NP, there are 2 patches floating on the MATE ml that move the dependency on 
sys-power/upower-pm-utils
consolekit(suspend/resume is handled by consolekit instead). Wold you be 
interested to
add those to gentoo MATE?

  Jocke

[gentoo-portage-dev] [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check locale

[Anthony G. Basile]

From: "Anthony G. Basile" 

The current method to check for a sane system locale is to use python's
ctypes.util.find_library() to construct a full library path to the
system libc.so and pass that path to ctypes.CDLL() so we can call
toupper() and tolower() directly.  However, this gets bogged down in
implementation details and fails with musl.

We work around this design flaw in ctypes with a small python module
written in C which provides thin wrappers to toupper() and tolower(),
and only fall back on the current ctypes-based check when this module
is not available.

This has been tested on glibc, uClibc and musl systems.

X-Gentoo-bug: 571444
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444

Signed-off-by: Anthony G. Basile 
---
 pym/portage/util/locale.py | 16 ++-
 setup.py   |  6 +++-
 src/portage_util_libc.c| 68 ++
 3 files changed, 82 insertions(+), 8 deletions(-)
 create mode 100644 src/portage_util_libc.c

diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
index 093eb86..5b09945 100644
--- a/pym/portage/util/locale.py
+++ b/pym/portage/util/locale.py
@@ -34,13 +34,15 @@ def _check_locale(silent):
"""
The inner locale check function.
"""
-
-   libc_fn = find_library("c")
-   if libc_fn is None:
-   return None
-   libc = LoadLibrary(libc_fn)
-   if libc is None:
-   return None
+   try:
+   from portage.util import libc
+   except ImportError:
+   libc_fn = find_library("c")
+   if libc_fn is None:
+   return None
+   libc = LoadLibrary(libc_fn)
+   if libc is None:
+   return None
 
lc = list(range(ord('a'), ord('z')+1))
uc = list(range(ord('A'), ord('Z')+1))
diff --git a/setup.py b/setup.py
index 25429bc..5ca8156 100755
--- a/setup.py
+++ b/setup.py
@@ -47,7 +47,11 @@ x_scripts = {
 # Dictionary custom modules written in C/C++ here.  The structure is
 #   key   = module name
 #   value = list of C/C++ source code, path relative to top source directory
-x_c_helpers = {}
+x_c_helpers = {
+   'portage.util.libc' : [
+   'src/portage_util_libc.c',
+   ],
+}
 
 class x_build(build):
""" Build command with extra build_man call. """
diff --git a/src/portage_util_libc.c b/src/portage_util_libc.c
new file mode 100644
index 000..977b954
--- /dev/null
+++ b/src/portage_util_libc.c
@@ -0,0 +1,68 @@
+/* Copyright 2005-2016 Gentoo Foundation
+ * Distributed under the terms of the GNU General Public License v2
+ */
+
+#include 
+#include 
+#include 
+
+static PyObject * _libc_tolower(PyObject *, PyObject *);
+static PyObject * _libc_toupper(PyObject *, PyObject *);
+
+static PyMethodDef LibcMethods[] = {
+   {"tolower", _libc_tolower, METH_VARARGS, "Convert to lower case using 
system locale."},
+   {"toupper", _libc_toupper, METH_VARARGS, "Convert to upper case using 
system locale."},
+   {NULL, NULL, 0, NULL}
+};
+
+#if PY_MAJOR_VERSION >= 3
+static struct PyModuleDef moduledef = {
+   PyModuleDef_HEAD_INIT,
+   "libc", /* 
m_name */
+   "Module for converting case using the system locale",   /* 
m_doc */
+   -1, /* 
m_size */
+   LibcMethods,/* 
m_methods */
+   NULL,   /* 
m_reload */
+   NULL,   /* 
m_traverse */
+   NULL,   /* 
m_clear */
+   NULL,   /* 
m_free */
+};
+
+PyMODINIT_FUNC
+PyInit_libc(void)
+{
+   PyObject *m;
+   m = PyModule_Create();
+   return m;
+}
+#else
+PyMODINIT_FUNC
+initlibc(void)
+{
+   Py_InitModule("libc", LibcMethods);
+}
+#endif
+
+
+static PyObject *
+_libc_tolower(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", tolower(c));
+}
+
+
+static PyObject *
+_libc_toupper(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", toupper(c));
+}
-- 
2.7.3

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 13:14, kirjutas Anthony G.
Basile:
> On 5/27/16 12:59 PM, rindeal wrote:
> > On 27 May 2016 at 18:54, landis blackwell  > m> wrote:
> > > I stopped reading after you reminded me it was 2016
> > 
> > Good to know, thanks for stopping by.
> > 
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk
> and
> gtk3, where gtk really means gtk2.  i'm not going to change that
> because
> it fits QA's specs.  but i could remove it altogether and just drop
> gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm
> asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.

Instead you should have 3 packages here.

avahi that ships the non-gtk linking bits.
avahi-gtk2 that ships the gtk2 library.
avahi-gtk3 that ships the gtk3 library.

This wasn't done originally as we lacked the manpower there and hoped
that gtk2 consumers will go away soon anyway. If that isn't the case,
the work should be done long ago. I hear there have been various
dependency issues already anyways due to the splitting not having been
done.

If there are no more avahi-gtk2 consumers, you could drop the gtk2
support altogether and maybe not need the splitting.
Then the question is if you name it USE="gtk" or USE="gtk3" to build
the gtk3 component.
Either way, consumers would USE depend correctly on which they need - I
don't think it's magical, so consumers would always actually link to it
and a clear USE depend can be in place.

So in an ideal world, you wouldn't have any USE=gtk* whatsoever here
anyways.


Mart

Re: [gentoo-portage-dev] [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check locale

[Brian Dolbec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 30 May 2016 11:08:03 +0200
Alexander Berntsen  wrote:

> On 27/05/16 16:26, Anthony G. Basile wrote:
> > However, this gets bogged down in implementation details and fails 
> > with musl.  
> Is it possible to elucidate this a bit more in a paragraph? Right now
> it reads a bit like "but this fails because reasons -_o_-", but in the
> future it might be nice to know said reasons.
> 
> Patch 1 and 2 look great. Patch 3 looks good to me, but obviously
> Michał knows more about this so I'll let him be the judge.
> - -- 
> Alexander
> berna...@gentoo.org

I agree that all 3 look good,  But I would say that the other changes
Michal proposed should be their own commit(s).  This being the first,
the others each adding to it.

- -- 
Brian Dolbec 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXTDXCXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YBWYP/2iFd7DsDKDwZJtTjUJfWAdJ
o4EqXmRtPOom0EIf5etfuiTRIKVAnALo9SeFJtp8nkBkRTcv5sa9IfB8ZKucslgW
VwlZCNBbXQIWm/d7zFYWSWw6rm0JM6Yq5hIrQ9R4eaKXZTZfNZUZla1u9LnGYmcs
VgNXd7EZ1R5zIxugWlLca5FhoEuNHiSrBQn5Vi9mfkngNAeqd5sl+dHBpfrFJlPs
2a7ia1YXXMe6ZVYWD0QW0Z2NcuZ16/7wkI7GH6qqglXkitP31g4tLlQZsVD9MU9k
VggQCcA2wdzyaEmLMBn+qE0Uu0yZ+uhIvFLkkbRVbb33WG9u/P5HC6Eio8m7YGb4
2qywJUiJkmdpOlcpfKdvjUpGa8TKF1UqjlsZWYVB65jmx3g4pCorwd2y3nOJktG3
Qodzm4/b3vaK+qLTmJWXqcQr2nvlj9vaibbrhX6RUhsHtlZJPrujiLv6g7m0wL+W
0rLhWL0J1+rmI+uUjzW62YmE3b6Yc7oAL7PEXLU+/R7vLSMA/Brfy5x/wMgwoMCW
MAq53aagDXKO2jWVtHiZ2Dj4AAcl5CmA4Gw5gtEezVnIQNTj/Lcui/p+li2q8N9O
RN0uG7xffmSqwbivJCwPUesxKBRDsQMRHk0R2L4VI5CQSrEq8d8vZRNUlf8EGisX
ODRF7zi9Uvu7WwjRCk1L
=9G6+
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Andrew Savchenko]

On Sun, 29 May 2016 14:58:03 +0200 Michał Górny wrote:
> On Sat, 21 May 2016 11:19:07 -0400
> waltd...@waltdnes.org wrote:
> 
> > On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote
> > 
> > > I see the following possibilities:
> > > 
> > > 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> > > tiny they are. Maintainers are required to keep IUSE up-to-date
> > > and users are forced to rebuild a lot. This is also a QA violation
> > > in terms of invalid use of USE flags.
> > > 
> > > 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
> > > miss and probably would need to repeated for every single phase anyway
> > > due to how global variables are handled in PMS. Additionally, it may
> > > break at some point since those variables are likely expected to be
> > > read-only anyway.
> > > 
> > > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> > > a good reason to use flags for localization, we introduce a new,
> > > non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> > > with the new flag in their make.conf files. LINGUAS gets the original
> > > upstream behavior back, and we eventually discourage it in favor of new
> > > INSTALL_MASK features (WiP) [2].
> > > 
> > > 4. We fix build systems not to do magic depending on whether LINGUAS
> > > is unset or set-to-empty. Instead, we could some special special value
> > > like '-' to signify not installing localizations at all. But that's
> > > upstream thing to do, and breaks backwards compatibility with existing
> > > systems disabling localizations.
> > > 
> > > 
> > > Your thoughts?  
> > 
> > 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
> > LOCALE_ALLOW="foo bar fubar"
> > 
> > which would block installing files in /usr/share/locale/* and
> > /usr/share/man/* EXCEPT for...
> > 
> > /usr/share/locale/foo
> > /usr/share/locale/bar
> > /usr/share/locale/fubar
> > /usr/share/man/foo
> > /usr/share/man/bar
> > /usr/share/man/fubar
> 
> This can be accomplished using inclusion/exclusion logic included in
> the patches I've recently sent for Portage.
> 
>   INSTALL_MASK="/usr/share/locale -/usr/share/locale/foo"
 
A proper way will be to fix ebuilds to respect LINGUAS properly.
l10n.eclass makes this quite easy. Build and install files just to
remove them later before/after merge to a live system is ridiculous,
especially considering that LINGUAS covers not only manuals, but
also html docs and other files.

Why users should care about additional INSTALL_MASK ordeal if they
already set up LINGUAS properly? This is PM and ebuild maintainers
job.

The same states for cron, systemd, logrotate and other potentially
unneeded files. Install mask is dangerous, very dangerous, because
locations may move, mandatory files may have accidentally removed
by an oversight. INSTALL_MASK is indeed useful, essential tool and
it is nice that it is being extended, but it should be a last
resort way to fix stuff, not a recommended technique.

The real problem is that "small files" control creates much burden
for package maintainers. It should be fixed by versatile and easy
to use eclasses, ideally the most popular helpers should go to PMS,
e.g. to default src_install().

Moving all burden of "small files" control and optional cleanup
from developers to users is not nice.

Best regards,
Andrew Savchenko


pgp2r1pGjRyz2.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check locale

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 27/05/16 16:26, Anthony G. Basile wrote:
> However, this gets bogged down in implementation details and fails 
> with musl.
Is it possible to elucidate this a bit more in a paragraph? Right now
it reads a bit like "but this fails because reasons -_o_-", but in the
future it might be nice to know said reasons.

Patch 1 and 2 look great. Patch 3 looks good to me, but obviously
Michał knows more about this so I'll let him be the judge.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXTALyAAoJENQqWdRUGk8BN6IP/0QqY6JdhzBGbNxdE3HCSDBt
kih75Hmjck6VQGlKNl+GLeML/ilTqitsVnkpbxeL3j00P69ZrW7OkZiLxGUQn+5P
9N0ljVR/FhHD5wJE3deS1IzNSERhuhSllIGKeweMIYXO3IT9tx4vDVNMB7v9zi+i
gduaxZr7byu3NSt//y+NJqHBUfxs2iWHA6+/KPDpKvs+E0hg2lycQVfsfCKFhQ/v
W+Jg5uw7Fo+6bTyUe5+b+12KlotFuHOko0unq9pt+PdT9GMek617kiMqDbXvazYf
/cgHiL1jIhSgRGbCmMVxAAo+BMp2AWrG4CyOdMHcS4shSw97jk/2NCI+1sUuuaNo
9go6ZCbLEx3LvL1kdCeR1lOk1kE6tC/lkiH1ZGMWuuYmF85qsCWgPHy1UZ+jXq1R
SkmwDXdJbbjVEzT8uVTm+hD8GyARXw7iP/1ZMLVgSRZfFGD48USIo/sVmyYdLOd5
xb90fupwpQiq49Rh+haeCN0uzSAPyAp4asrr9p409t8hH4i1sfDW/ed3jw+a/Pna
DyvPi/dY0ER9F1FnUxz4LYogm4Qa0IeFsQJUZZOlG8ekx5pBGxGqHOPH/Jx+iRLz
Pt9IvPKRInuU6LZ4gfkDvC5JfrX4DG8+PldsqItLP6GtPZSsp46f8Gdg2HUskmaD
8ESZIFkuxfL5wiKlK8Wi
=UDnS
-END PGP SIGNATURE-