Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos pa...@gentoo.org wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I don't believe anyone is active in the mobile herd anymore. Probably the packages need to be moved to maintainer-needed@ so individual developers can take care of them. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
Seems most of apps maintained by indiviual maintainers (for example i'm maintaining wimax stack) I dont know overall state of this herd Markos Chandras писал 29-10-2012 13:50: On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos pa...@gentoo.org wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I don't believe anyone is active in the mobile herd anymore. Probably the packages need to be moved to maintainer-needed@ so individual developers can take care of them. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
On 28/10/12 14:26, Pacho Ramos wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I've been maintaining sys-power/acpid since nobody in mobile@ has been for ages now I've never seen anyone from mobile@ replying to any of the bugs, *any* of the bugs So yeah, +1 for m-needed@, the herd clearly doesn't work as random HW specific packages are assigned to it
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
On Mon, Oct 29, 2012 at 11:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 28/10/12 14:26, Pacho Ramos wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I've been maintaining sys-power/acpid since nobody in mobile@ has been for ages now I've never seen anyone from mobile@ replying to any of the bugs, *any* of the bugs So yeah, +1 for m-needed@, the herd clearly doesn't work as random HW specific packages are assigned to it Perfect. Lets remove the project+email+herd altogether with an immediate announcement of this action and which packages are not maintained anymore. Pacho can you take care of this like you did in the past for other dead teams? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Sun, Oct 28, 2012 at 10:35:01PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: 2012-10-28 22:14:15 Mike Gilbert napisa??(a): This library is used for processing Unicode text in several high-profile packages, including Chromium and other Webkit browsers, PHP, boost, and many more. Fair warning: ICU tends to break several packages with every major release, so thorough testing is needed when bumping it. This package is currently being maintained by proxy by a former Gentoo developer, Arfrever. Given this package's potential to cause problems, this situation is not ideal. It would be really great if an active Gentoo developer would step forward and take care of this one. I am actively maintaining ICU and test many reverse dependencies with new versions of ICU (using a not package.masked version of GCC). Members of proxy-maintainers team or others actively commit fixes/updates, so there is no need to change current situation. Yeah... I don't agree with that. Floppym wouldn't be looking for a new maintainer if that was accurate. The package has been cranky enough in parallel with revdeps breaking everytime it's bumped that this needs a dev watching it, rather than whichever random proxy-maintainer member snags that version. Anyone got the spare cycles for it? ~harring
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/27/2012 05:23 AM, Piotr Szymaniak wrote: On Wed, Sep 26, 2012 at 01:43:27PM -0700, Matt Turner wrote: On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol mike...@gmail.com wrote: A few months ago, I filed bug 423651 to ask that bzip2 on the install media be replaced with pbzip2. It was closed a short while later, telling me that it'd involve changing what's kept in @system, and that had to be discussed here, rather than in a bug report. If we're going to ship a parallel bzip2 implementation, it should be lbzip2 and not pbzip2. lbzip2 can decompress bz2 archives with multiple threads that haven't been compressed with lbzip2/pbzip2. Afair I'm using PORTAGE_BZIP2_COMMAND with lbzip2 and it works fine. Also some time ago I've changed a bit the (famous?) stage4 backup script from g-wiki to support parallel gz/bz2 implementations (simple check if there pbzip2/lbzip2/foobar installed and if yes, use it instead of normal gzip/bzip2). I've been testing PORTAGE_BZIP2_COMMAND=lbzip2 for the few weeks since this thread as well, and I have to say it's been great. Maybe portage should be like my stage4 mod? If it finds some parallel (de)compressor it should use it, if not fallback to standard gzip/bzip2? The releng team has begun using lbzip2 for decompressing things as much as possible for speeding up catalyst builds, and speaking only for myself I think it's been useful. I spoke to zmedico about replacing the default portage decompresser and he suggested far more use could be attained by simply creating an eselect-bzip2 (possibly defaulting to lbzip2 as this thread seemed to agree). I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Thanks, Zero_Chaos Piotr Szymaniak. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQjo79AAoJEKXdFCfdEflKQNQQAIur3Mx4eD6kVv3US6kDkKpn Z8aHyZqWIOws9VqcPCJUb1c1bn8aj2QTjL63obh//rJby1Qd1P3X3OA9hKfaiyiJ hbgWRu5RkMSNPIdXhaslD3h/kL78BPr9eVz9O3R/TMp01puz4su0j1JVOtAT5Ny2 qAVof+H6RC5aCP2pKjIkvDq9vma/jd9QT98rM3UIw3BorBpkl0vTTa+sLtGA+U6p mBkYZJFUUnkW3AtNC1ucPvQS9a7NwOxH5EDGEy4QeSJh9nvQZ8zCFivNtr4SUS6A SGV0j/PB0Uqf42y1NOBfFSEQoQGT3aIlZzkbGdJKf6/jIdGPHhxWt3npQ6U6gOg9 TA/8zCJkJk0GZKAIq+K/y8STczeuIJ2hgrHUup4/I6CYwI66eBRiqnayNEmah7Cy rpqR7xwqh+F2JrjljNYfE9qVQKwqhLU5MsOONlqRS+FPw+SuxxbJM6BiLCk4s0Qz GPs5PXTz92MzzQ18XUuMq53bi9IaEmJJa8E83IBm3PD4zq67KsiWd2YxQo/JYX4p ZTBayLabbY6PRwMVx0k9jKG7aOOKFZ5t2k5BmZDv6JBD2Sww9q6+xUPoTDwsZPgZ pVv2m3AwaOXbGpvMrpqmzOTxbovUALp9WhdyTxlR5NmbTeXIuaKW/lQTU0cl/LKP ACg4IADjv3hQz7gfsHAP =hCz9 -END PGP SIGNATURE-
[gentoo-dev] spotify license
It's looking hard to be able to add the spotify ebuild to tree because of licensing concerns. http://www.spotify.com/us/legal/end-user-agreement/ 10:02 prometheanfire do you have a plaintext version? I can copy the text, but just thought I'd ask :D 10:02 dan^spotify No, and copy+pasting it into a text file isn't something we really want you to to do, since it changes from time-to-time 10:04 prometheanfire ok, I'll see what the proper course of action is, I think you have us accept the license on first start right? 10:04 dan^spotify Correct 10:04 dan^spotify Well, first login 10:05 prometheanfire just as good probably 10:05 dan^spotify If you've already accepted the most up-to-date license on another machine, you won't be prompted again https://bugs.gentoo.org/show_bug.cgi?id=373093 They want it to be accepted through the app. Is there a way this is compatible with Gentoo? Any advice would be appreciated. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] spotify license
On Mon, Oct 29, 2012 at 10:17 AM, Matthew Thode prometheanf...@gentoo.org wrote: It's looking hard to be able to add the spotify ebuild to tree because of licensing concerns. http://www.spotify.com/us/legal/end-user-agreement/ That doesn't really look like a license to me. It seems to be more like the terms of use of their service. I don't really see much license to do anything, but they do point out they'll sue you if you do something they don't like. 10:02 prometheanfire do you have a plaintext version? I can copy the text, but just thought I'd ask :D 10:02 dan^spotify No, and copy+pasting it into a text file isn't something we really want you to to do, since it changes from time-to-time As long as we restrict mirroring, perhaps the license in portage should just say Spotify has an end-user license agreement governing their service and software that they change from time to time. Please refer to their website for details. It is not clear that redistribution of their software is permissible. They want it to be accepted through the app. Is there a way this is compatible with Gentoo? Any advice would be appreciated. So, my two cents are that any issues around license acceptance to USE spotify have nothing to do with Gentoo (I'd go a step further and state that there is no such thing as license acceptance in the first place - licenses are merely statements that you are permitted to do something under certain conditions and if you don't follow the conditions then you may or may not be permitted to do something). I wouldn't go removing any prompts/etc they put in their software, but we don't need to go adding them either. They are free to put conditions on the use of their service, and communicate them to their customers. We don't distribute their software (RESTRICT=mirror), so we aren't really a party to the matter. Rich
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), ++ but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. Rich
[gentoo-dev] [RFC] A news item covering PYTHON_TARGETS
Hello, Since some ebuilds are using that variable already and we still didn't inform most of our users if and how they should set it, I'd like to commit the following news item: Title: PYTHON_TARGETS deployment Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2012-10-29 Revision: 1 News-Item-Format: 1.0 Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. If you are running a modern system with Python 2.7 3.2, and you didn't set USE_PYTHON, then you don't have to do anything. The defaults will fit you. Otherwise, you will want to set PYTHON_TARGETS in your make.conf file. This is a regular USE_EXPAND variable listing requested Python implementations like: PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 The variable should list all requested Python implementations. A complete list of possible values can be obtained using a command like: emerge -1pv dev-python/python-exec -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: spotify license
On Mon, 29 Oct 2012, Matthew Thode wrote:
It's looking hard to be able to add the spotify ebuild to tree because
of licensing concerns.
http://www.spotify.com/us/legal/end-user-agreement/
This concerns not so much the client software, but their service and
the contents provided through it.
10:02 prometheanfire do you have a plaintext version? I can copy
the text, but just thought I'd ask :D
10:02 dan^spotify No, and copy+pasting it into a text file isn't
something we really want you to to do, since it changes from time-to-time
10:04 prometheanfire ok, I'll see what the proper course of action
is, I think you have us accept the license on first start right?
10:04 dan^spotify Correct
10:04 dan^spotify Well, first login
10:05 prometheanfire just as good probably
10:05 dan^spotify If you've already accepted the most up-to-date
license on another machine, you won't be prompted again
https://bugs.gentoo.org/show_bug.cgi?id=373093
They want it to be accepted through the app. Is there a way this is
compatible with Gentoo?
We need a plaintext license file for the client that we put in
${PORTDIR}licenses/, so users can look at it before they install the
package.
Any advice would be appreciated.
Maybe it would make more sense to add one of the free alternatives?
http://despotify.se/
https://gitorious.org/libopenspotify
media-sound/despotify is already in Sunrise, bug 307795.
Ulrich
Re: [gentoo-dev] [PATCH python-r1 5/8] Convert x11-misc/redshift to python-r1 (example).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/10/12 07:02 AM, Micha? Górny wrote:
This serves as an example how the new functions can be used. ---
gx86/x11-misc/redshift/redshift-1.7-r1.ebuild | 33
--- 1 file changed, 14 insertions(+), 19
deletions(-)
diff --git a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild index
f3bd210..589e571 100644 ---
a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild +++
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild @@ -24,7 +21,8 @@
COMMON_DEPEND==x11-libs/libX11-1.4 x11-libs/libxcb geoclue? (
app-misc/geoclue ) gnome? ( dev-libs/glib:2 - =gnome-base/gconf-2
) + =gnome-base/gconf-2 ) +gtk? ( ${PYTHON_DEPS} )
RDEPEND=${COMMON_DEPEND} gtk? ( =dev-python/pygtk-2
dev-python/pyxdg )
..should we not also ensure that the PYTHON_TARGETS for pygtk-2 and
pyxdg match (or at least include) the PYTHON_TARGETS being used for
this package? IE:
RDEPEND=${COMMON_DEPEND} - gtk? ( =dev-python/pygtk-2 -
dev-python/pyxdg ) + gtk? ( =dev-python/pygtk-2[$PYTHON_USEDEP]
+ dev-python/pyxdg[$PYTHON_USEDEP] )
I don't know if this is actually needed by the package but I would
assume so as it seems to be building and installing for multiple pythons..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlCOn+wACgkQ2ugaI38ACPBumgD9FDoSOvYTftLxQuo6Hix6ud9l
eZ0f5iLnD2SfzaaWcxwA/022wryA/f+f0ebg9WmS+C4AuzNvCQMQe7El3ERuAw23
=KDxM
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: spotify license
On 10/29/2012 09:52 AM, Ulrich Mueller wrote:
On Mon, 29 Oct 2012, Matthew Thode wrote:
It's looking hard to be able to add the spotify ebuild to tree because
of licensing concerns.
http://www.spotify.com/us/legal/end-user-agreement/
This concerns not so much the client software, but their service and
the contents provided through it.
10:02 prometheanfire do you have a plaintext version? I can copy
the text, but just thought I'd ask :D
10:02 dan^spotify No, and copy+pasting it into a text file isn't
something we really want you to to do, since it changes from time-to-time
10:04 prometheanfire ok, I'll see what the proper course of action
is, I think you have us accept the license on first start right?
10:04 dan^spotify Correct
10:04 dan^spotify Well, first login
10:05 prometheanfire just as good probably
10:05 dan^spotify If you've already accepted the most up-to-date
license on another machine, you won't be prompted again
https://bugs.gentoo.org/show_bug.cgi?id=373093
They want it to be accepted through the app. Is there a way this is
compatible with Gentoo?
We need a plaintext license file for the client that we put in
${PORTDIR}licenses/, so users can look at it before they install the
package.
Any advice would be appreciated.
Maybe it would make more sense to add one of the free alternatives?
http://despotify.se/
https://gitorious.org/libopenspotify
media-sound/despotify is already in Sunrise, bug 307795.
Ulrich
This makes me think that it covers the client as well. They did say
that if we tried to keep this up to date that would be good enough.
Third party software libraries included in the Spotify Service are
licensed to you either under these Terms, or under the relevant third
party software library’s licence terms as published in the help or
settings section of our desktop and mobile client and on our website.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH python-r1 5/8] Convert x11-misc/redshift to python-r1 (example).
On Mon, 29 Oct 2012 11:25:33 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/10/12 07:02 AM, Micha? Górny wrote:
This serves as an example how the new functions can be used. ---
gx86/x11-misc/redshift/redshift-1.7-r1.ebuild | 33
--- 1 file changed, 14 insertions(+), 19
deletions(-)
diff --git a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild index
f3bd210..589e571 100644 ---
a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild +++
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild @@ -24,7 +21,8 @@
COMMON_DEPEND==x11-libs/libX11-1.4 x11-libs/libxcb geoclue? (
app-misc/geoclue ) gnome? ( dev-libs/glib:2 -
=gnome-base/gconf-2
) +=gnome-base/gconf-2 ) +gtk? ( ${PYTHON_DEPS}
)
RDEPEND=${COMMON_DEPEND} gtk? ( =dev-python/pygtk-2
dev-python/pyxdg )
..should we not also ensure that the PYTHON_TARGETS for pygtk-2 and
pyxdg match (or at least include) the PYTHON_TARGETS being used for
this package? IE:
RDEPEND=${COMMON_DEPEND} - gtk? ( =dev-python/pygtk-2 -
dev-python/pyxdg ) + gtk? ( =dev-python/pygtk-2[$PYTHON_USEDEP]
+ dev-python/pyxdg[$PYTHON_USEDEP] )
I don't know if this is actually needed by the package but I would
assume so as it seems to be building and installing for multiple pythons..
Yes, of course that'd need to be done if and when pygtk and pyxdg start
using PYTHON_TARGETS ;).
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH python-r1 5/8] Convert x11-misc/redshift to python-r1 (example).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/10/12 11:42 AM, Michał Górny wrote:
On Mon, 29 Oct 2012 11:25:33 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 27/10/12 07:02 AM, Micha? Górny wrote:
This serves as an example how the new functions can be used.
--- gx86/x11-misc/redshift/redshift-1.7-r1.ebuild | 33
--- 1 file changed, 14 insertions(+),
19 deletions(-)
diff --git a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild index
f3bd210..589e571 100644 ---
a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild +++
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild @@ -24,7 +21,8
@@ COMMON_DEPEND==x11-libs/libX11-1.4 x11-libs/libxcb
geoclue? ( app-misc/geoclue ) gnome? ( dev-libs/glib:2 -
=gnome-base/gconf-2 ) + =gnome-base/gconf-2 ) +gtk? (
${PYTHON_DEPS} ) RDEPEND=${COMMON_DEPEND} gtk? (
=dev-python/pygtk-2 dev-python/pyxdg )
..should we not also ensure that the PYTHON_TARGETS for pygtk-2
and pyxdg match (or at least include) the PYTHON_TARGETS being
used for this package? IE:
RDEPEND=${COMMON_DEPEND} - gtk? ( =dev-python/pygtk-2 -
dev-python/pyxdg ) + gtk? (
=dev-python/pygtk-2[$PYTHON_USEDEP] +
dev-python/pyxdg[$PYTHON_USEDEP] )
I don't know if this is actually needed by the package but I
would assume so as it seems to be building and installing for
multiple pythons..
Yes, of course that'd need to be done if and when pygtk and pyxdg
start using PYTHON_TARGETS ;).
I guess it wouldn't work to make $PYTHON_USEDEP contain
python_target_whatever(+) strings so that the targets being missing
would still allow the use deps to exist, huh...
I'm thinking this wouldn't catch issues where the PYTHON_COMPAT of a
dep is not as complete as the PYTHON_COMPAT of the consumer (and i
assume we would want to error on that)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlCOpRgACgkQ2ugaI38ACPBsaAD/R6Sqq2VGcmmUg6hqyWsWUG4v
aiV1vKdLGj+rpayOX8MA/A5iNmR0DYQ/ebTiQ+lzXqjbEmoc9o6yUxPbJ2OgeR66
=wtJu
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH python-r1 5/8] Convert x11-misc/redshift to python-r1 (example).
On Mon, 29 Oct 2012 11:47:36 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/10/12 11:42 AM, Michał Górny wrote:
On Mon, 29 Oct 2012 11:25:33 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 27/10/12 07:02 AM, Micha? Górny wrote:
This serves as an example how the new functions can be used.
--- gx86/x11-misc/redshift/redshift-1.7-r1.ebuild | 33
--- 1 file changed, 14 insertions(+),
19 deletions(-)
diff --git a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild index
f3bd210..589e571 100644 ---
a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild +++
b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild @@ -24,7 +21,8
@@ COMMON_DEPEND==x11-libs/libX11-1.4 x11-libs/libxcb
geoclue? ( app-misc/geoclue ) gnome? ( dev-libs/glib:2 -
=gnome-base/gconf-2 ) + =gnome-base/gconf-2 ) +gtk? (
${PYTHON_DEPS} ) RDEPEND=${COMMON_DEPEND} gtk? (
=dev-python/pygtk-2 dev-python/pyxdg )
..should we not also ensure that the PYTHON_TARGETS for pygtk-2
and pyxdg match (or at least include) the PYTHON_TARGETS being
used for this package? IE:
RDEPEND=${COMMON_DEPEND} - gtk? ( =dev-python/pygtk-2 -
dev-python/pyxdg ) + gtk? (
=dev-python/pygtk-2[$PYTHON_USEDEP] +
dev-python/pyxdg[$PYTHON_USEDEP] )
I don't know if this is actually needed by the package but I
would assume so as it seems to be building and installing for
multiple pythons..
Yes, of course that'd need to be done if and when pygtk and pyxdg
start using PYTHON_TARGETS ;).
I guess it wouldn't work to make $PYTHON_USEDEP contain
python_target_whatever(+) strings so that the targets being missing
would still allow the use deps to exist, huh...
...that sounded like a good idea...
I'm thinking this wouldn't catch issues where the PYTHON_COMPAT of a
dep is not as complete as the PYTHON_COMPAT of the consumer (and i
assume we would want to error on that)
...before this part ;). So I guess it's safer to just keep it like it
is, and assume that when converting a package to p-r1, you are supposed
to check its revdeps to add $PYTHON_USEDEP whenever necessary.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS
On Mon, Oct 29, 2012 at 10:45 AM, Michał Górny mgo...@gentoo.org wrote: Hello, Since some ebuilds are using that variable already and we still didn't inform most of our users if and how they should set it, I'd like to commit the following news item: Title: PYTHON_TARGETS deployment Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2012-10-29 Revision: 1 News-Item-Format: 1.0 Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. If you are running a modern system with Python 2.7 3.2, and you didn't set USE_PYTHON, then you don't have to do anything. The defaults will fit you. Otherwise, you will want to set PYTHON_TARGETS in your make.conf file. This is a regular USE_EXPAND variable listing requested Python implementations like: PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 The variable should list all requested Python implementations. A complete list of possible values can be obtained using a command like: emerge -1pv dev-python/python-exec Good idea to inform users. Is there a way to have this news item go away, say after a year or so? Every time I do a fresh install, I get hit with a couple of perpetual news items, and it is a little annoying.
[gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS
Michał Górny posted on Mon, 29 Oct 2012 15:45:01 +0100 as excerpted: Title: PYTHON_TARGETS deployment [snip] Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. That paragraph needs help. Try this: Recently, new python eclasses were deployed. As ebuilds migrate, the way they support multiple python implementations will change. The previous method built support for all installed python implementations. The new method uses the PYTHON_TARGETS USE flags to explicitly name the implementations that support should be built for. If you are running a modern system with Python 2.7 3.2, and you didn't set USE_PYTHON, then you don't have to do anything. The defaults will fit you. Fewer changes in this paragraph. Try this: If you are running a modern system with Python 2.7 and 3.2 and you haven't set USE_PYTHON, you don't need to do anything. The defaults will continue to work just as they have. The rest of it looks good to me. Extra points for the specific examples, both of PYTHON_TARGETS and of a suitable command-line to get a list of all possibilities. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] A news item covering PYTHON_TARGETS
On Mon, 29 Oct 2012 15:45:01 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, Since some ebuilds are using that variable already and we still didn't inform most of our users if and how they should set it, I'd like to commit the following news item: Title: PYTHON_TARGETS deployment Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2012-10-29 Revision: 1 News-Item-Format: 1.0 Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. If you are running a modern system with Python 2.7 3.2, and you didn't set USE_PYTHON, then you don't have to do anything. The defaults will fit you. Otherwise, you will want to set PYTHON_TARGETS in your make.conf file. This is a regular USE_EXPAND variable listing requested Python implementations like: PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 The variable should list all requested Python implementations. A complete list of possible values can be obtained using a command like: emerge -1pv dev-python/python-exec this might be slghtly be reudundant, but how about set PYTHON_TARGETS in place of PYTHON_ABIS or USE_PYTHON in /etc/make.conf. Technically it's not essential. PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 is just right, a clear example of each. While before the implementations right and doesn't read quite right, either just delete before or While the implementations being installed were used by default by python.eclass deleting the word before. I think a simple comma might make the original valid; While before, the implementations being installed were used by default -- kind regards Ian Delaney -- kind regards Ian Delaney
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012/10/29 Brian Harring ferri...@gmail.com: On Sun, Oct 28, 2012 at 10:35:01PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: 2012-10-28 22:14:15 Mike Gilbert napisa??(a): This library is used for processing Unicode text in several high-profile packages, including Chromium and other Webkit browsers, PHP, boost, and many more. Fair warning: ICU tends to break several packages with every major release, so thorough testing is needed when bumping it. This package is currently being maintained by proxy by a former Gentoo developer, Arfrever. Given this package's potential to cause problems, this situation is not ideal. It would be really great if an active Gentoo developer would step forward and take care of this one. I am actively maintaining ICU and test many reverse dependencies with new versions of ICU (using a not package.masked version of GCC). Members of proxy-maintainers team or others actively commit fixes/updates, so there is no need to change current situation. Yeah... I don't agree with that. Floppym wouldn't be looking for a new maintainer if that was accurate. The package has been cranky enough in parallel with revdeps breaking everytime it's bumped that this needs a dev watching it, rather than whichever random proxy-maintainer member snags that version. Anyone got the spare cycles for it? If Arfrever keeps maintaining it for a while, I will take it. Christoph ~harring -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS
On Mon, Oct 29, 2012 at 1:01 PM, Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Mon, 29 Oct 2012 15:45:01 +0100 as excerpted: Title: PYTHON_TARGETS deployment [snip] Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. That paragraph needs help. Try this: Recently, new python eclasses were deployed. As ebuilds migrate, the way Recently, a new python eclass was deployed. or Recently, a few new python eclasses were deployed. or even Recently, a few python eclasses were deployed. And then capitalize Python. -- :wq
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 29/10/2012 10:37, Christoph Junghans wrote: If Arfrever keeps maintaining it for a while, I will take it. Do remember that whatever you commit, _You_ take responsibility for it. After a screwup, the answer I didn't do anything, I just committed what Arfrever gave me is not a good answer. In particular, if I hear such an answer from anybody (be it for icu or something else, be it for a minor inconsistency or a total fuckup), I'll be requesting devrel to re-evaluate their commit rights, as they are missing the understanding of you're responsible for whatever you commit. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, Oct 29, 2012 at 2:00 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: In particular, if I hear such an answer from anybody (be it for icu or something else, be it for a minor inconsistency or a total fuckup), I'll be requesting devrel to re-evaluate their commit rights, as they are missing the understanding of you're responsible for whatever you commit. While I do agree in principle, I think that talking about going to devrel over minor inconsistencies is over-the-top. Devs committing for proxies should be reviewing ebuilds, and also applying some kind of QA (make sure it works, get feedback from testers, etc). However, mistakes can and will happen, and that's OK. I'll take a package that has a mistake twice a year over a package that isn't in the tree at all any day. It seems like many of the ICU issues are upstream-related. If your library breaks on every release then somebody clearly doesn't understand the purpose of sonames. That puts anybody maintaining the package at a distro level in a really bad position. I think what is most needed here is a maintainer that can just coordinate with the various downstream projects. I don't care as much whether ICU is perfectly consistent as long as projects like chromium have a chance to test things out and catch issues before they hit the tree. That is actually part of the job of a proxy maintainer. Rich
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
Diego Elio Pettenò wrote: the understanding of you're responsible for whatever you commit. A load of bull IMO. Is this rooted in some stupid US law thing (via the foundation) or merely in some cowardly individual disconnected from the real world, phrasing stupid blanket rules? Or something else? Isn't it outrageous to claim that people who create and contribute to and around Gentoo without being developers are any less responsible for what they do than devs are? I have personal experience from several cases of the reverse, but that doesn't make me think that it's the norm for devs to behave irresponsibly. Diego, what you wrote does nothing other than make it seem like you have a personal agenda against Arfrever. If so, that situation is something you must obviously work on resolving elsewhere. I expect that anyone and everyone who contribute to any open source project will do their damndest to contribute only perfect work. I know that this is a pipe dream, but it does happen. I think the way to make it happen more often is education, but not everyone is able to educate and so, there is a gap.. Threats aren't an excellent way to try to close any gap IMO. WTF. //Peter
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 29/10/2012 11:10, Rich Freeman wrote: While I do agree in principle, I think that talking about going to devrel over minor inconsistencies is over-the-top. It's not about the inconsistencies, it's about the excuse. If the maintainer owns up to the mistake, that's fine by me, shit happens and so on. If the maintainer tries to cover behind I'm just proxying, then I'll be pissed. I'll take a package that has a mistake twice a year over a package that isn't in the tree at all any day. That's fine if it's a fringe package or one that wouldn't get to the tree otherwise — I agree with the spirit and methods. It's _not_ fine for a package that, yes, only has 50 dependencies, but every time it breaks everything goes KO. It seems like many of the ICU issues are upstream-related. If your library breaks on every release then somebody clearly doesn't understand the purpose of sonames. That puts anybody maintaining the package at a distro level in a really bad position. The problem with ICU is worse than you expect. For once, with version 50, it changes ABI (but not soname as far as I can tell) depending on which compiler you build it with. Yes, this is pretty much fucked up. I think what is most needed here is a maintainer that can just coordinate with the various downstream projects. I don't care as much whether ICU is perfectly consistent as long as projects like chromium have a chance to test things out and catch issues before they hit the tree. That is actually part of the job of a proxy maintainer. Agreed. At the same time, we should have learnt that Arfrever is unable to take up that job, given the repeated issues we've been having with almost everything he maintained. Which is why we need to find someone else. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 29/10/2012 11:30, Peter Stuge wrote: A load of bull IMO. Is this rooted in some stupid US law thing (via the foundation) or merely in some cowardly individual disconnected from the real world, phrasing stupid blanket rules? Or something else? You're free to disagree and not become a developer. But with commit _rights_ come commit _responsibility_. If you commit something for somebody else, you're still responsible if it breaks somebody else's package, it doesn't exempt you from not doing _your_ work. Isn't it outrageous to claim that people who create and contribute to and around Gentoo without being developers are any less responsible for what they do than devs are? No. It seems stupid to me to pretend that those that actually got through evaluation feel they can drop responsibility for what others give to them to commit. Especially, how do you expect people to keep up with a project's policies, if they can't be asked to own up to their own mistakes? Diego, what you wrote does nothing other than make it seem like you have a personal agenda against Arfrever. If so, that situation is something you must obviously work on resolving elsewhere. No. _I_ don't have a personal agenda against him. But _We_, as in Gentoo, have an history instead. A history that keeps repeating. A history that, if hiding behind the I'm just committing his stuff, will keep repeating. There is a reason why he's been kicked out, and I wasn't the only one taking that decision. Committing stuff for him, from him, without actually checking it, testing it, _owning_ it, is showing a lack of respect for the _whole_ project. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, Oct 29, 2012 at 2:30 PM, Peter Stuge pe...@stuge.se wrote: I expect that anyone and everyone who contribute to any open source project will do their damndest to contribute only perfect work. Setting aside issues of tone, I want to touch on the more direct issue of quality and perfection. I do think that most developers aim for high quality, but quality means something different to everybody. Quality could be: 1. Having a newer package in the tree, perhaps with resolved upstream issues. 2. Having more integration testing. 3. Having good documentation. 4. Having good communications to the end users about impending changes. 5. Being better integrated with other projects (such as chromium in this case). 6. Maintainability of the actual ebuild code. 7. Compliance with formal policies. All of those have a connotation of quality, and they are at odds with each other. The more time you spend on any of them the less time you have to spend on others. Complying with any of #2-7 takes time, and thus conflicts with #1. I think we should have a pool of developer proxies who are interested in supporting proxy maintenance. I don't think we get anywhere by punishing them when the inevitable mistake occurs. However, we also don't get anywhere by turning a blind eye to real issues that repeatedly come up. It sounds like there are some of those with ICU. I don't think we need drastic action. Maybe we just need a proxy dev who can be a little more closely associated with the package so they're aware of the issues that routinely come up and can help prevent them. Maybe Arfrever can work a little more closely with some of the other teams. I do think we need reasonable quality policies so that we're all on the same page. Testing packages should at least be confirmed as generally working and free of obvious problems. Stable packages should have been in testing for 30 days. Packages with highly impactful changes should have news items before being unmasked or stabilized. And so on. They don't have to be out-of-hand, and we don't have to shoot our wounded either. Rich
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, Oct 29, 2012 at 2:40 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: You're free to disagree and not become a developer. But with commit _rights_ come commit _responsibility_. If you commit something for somebody else, you're still responsible if it breaks somebody else's package, it doesn't exempt you from not doing _your_ work. ++ We do have a trust with our users. It doesn't mean that non-devs don't write good code. They do. However, the purpose of vetted developers is to be a gatekeeper to what runs on our user's systems. Devs also should be good at spotting problems with ebuilds that cause issues that might not be apparent from simply running emerge. That's the value Gentoo adds as a distro. Anybody can publish an overlay, but devs are required to get stuff in the tree. All that said, anything we can do to lower barriers to contribution while maintaining quality is a good thing. I don't want devs to be afraid of committing things, but they should be making an honest effort to catch issues. Rich
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, 29 Oct 2012 19:30:40 +0100 Peter Stuge pe...@stuge.se wrote: Diego Elio Pettenò wrote: the understanding of you're responsible for whatever you commit. Outrageours rant deleted Isn't it outrageous to claim that people who create and contribute to and around Gentoo without being developers are any less responsible for what they do than devs are? I guess Diego's response is rooted in seeing bug reports about or finding bugs in ebuilds that have been tagged with proxymaint. I've recently seen quite a few things with the same label that should not have been committed in the first place. I have personal experience from several cases of the reverse, but that doesn't make me think that it's the norm for devs to behave irresponsibly. That's good to hear, but it says nothing about the (arguably) fringe cases of bad commits. Diego, what you wrote does nothing other than make it seem like you have a personal agenda against Arfrever. I don't normally agree with anything Diego says, mind you. I expect that anyone and everyone who contribute to any open source project will do their damndest to contribute only perfect work. Yes. And everyone makes mistakes when they fail to spot the imperfections. That's just human. But no one should ever hide behind the lame excuse that it was somebody else's work when it obviously was not the contributor/proxy developer who did the commit. At the other end of the spectrum, recently some people like to tie red tape around everything, hold up progress for months, and call that QA. I know that this is a pipe dream, but it does happen. I think the way to make it happen more often is education, but not everyone is able to educate and so, there is a gap.. Threats aren't an excellent way to try to close any gap IMO. WTF. Since it is a pipe dream, you have to expect and deal with careless commits as and when they occur, and keeping people on their toes is one way to help prevent it, rather than fix the mess afterwards. jer
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012/10/29 Diego Elio Pettenò flamee...@flameeyes.eu: On 29/10/2012 10:37, Christoph Junghans wrote: If Arfrever keeps maintaining it for a while, I will take it. Do remember that whatever you commit, _You_ take responsibility for it. After a screwup, the answer I didn't do anything, I just committed what Arfrever gave me is not a good answer. Ok, I should have been more precise here. I will take it, but as I am new to the insides of icu, it will take me a bit to understand/fix/workaround it's issues and for that time having Arfrever will be more than useful. In particular, if I hear such an answer from anybody (be it for icu or something else, be it for a minor inconsistency or a total fuckup), I'll be requesting devrel to re-evaluate their commit rights, as they are missing the understanding of you're responsible for whatever you commit. Please, go ahead. I am happy with having less rights and less responsibilities. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, 2012-10-29 at 11:35 -0700, Diego Elio Pettenò wrote: The problem with ICU is worse than you expect. For once, with version 50, it changes ABI (but not soname as far as I can tell) depending on which compiler you build it with. Yes, this is pretty much fucked up. It's even worse than that: if you switch compilers, the declared API in icu-50 headers will not match the ABI of the icu binary. I've just filed https://bugs.gentoo.org/show_bug.cgi?id=440156 after hitting a linking failure when building libreoffice using gcc-4.7 against icu-50 which had been built with gcc-4.6.
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans ott...@gentoo.org wrote: 2012/10/29 Diego Elio Pettenò flamee...@flameeyes.eu: On 29/10/2012 10:37, Christoph Junghans wrote: If Arfrever keeps maintaining it for a while, I will take it. Do remember that whatever you commit, _You_ take responsibility for it. After a screwup, the answer I didn't do anything, I just committed what Arfrever gave me is not a good answer. Ok, I should have been more precise here. I will take it, but as I am new to the insides of icu, it will take me a bit to understand/fix/workaround it's issues and for that time having Arfrever will be more than useful. Arfrever will probably continue to send patches, but we need someone who can dig in deeper than I have been. Just make sure you verify and test everything he sends you, and have someone with a tinderbox test it on version bumps. I'm also happy to help in whatever way I can, other than having my name attached to it. :-)
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 10/29/2012 03:45 PM, Mike Gilbert wrote: On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghansott...@gentoo.org wrote: 2012/10/29 Diego Elio Pettenòflamee...@flameeyes.eu: On 29/10/2012 10:37, Christoph Junghans wrote: If Arfrever keeps maintaining it for a while, I will take it. Do remember that whatever you commit, _You_ take responsibility for it. After a screwup, the answer I didn't do anything, I just committed what Arfrever gave me is not a good answer. Ok, I should have been more precise here. I will take it, but as I am new to the insides of icu, it will take me a bit to understand/fix/workaround it's issues and for that time having Arfrever will be more than useful. Arfrever will probably continue to send patches, but we need someone who can dig in deeper than I have been. Just make sure you verify and test everything he sends you, and have someone with a tinderbox test it on version bumps. I'm also happy to help in whatever way I can, other than having my name attached to it. :-) I just generated the list of dependencies, 28 packages, see below. Compile tests against each are easy enough. Run tests against non-library packages are easy too. It would be harder to do an exhaustive test against, say, dev-libs/boost because then we are a couple of libraries levels deep. Not sure how deep is enough with this one. # Reverse dependencies for dev-libs/icu app-i18n/ibus-qt app-office/libreoffice # One of the following USE flag combinations is required: # icu x11-libs/qt-webkit # One of the following USE flag combinations is required: # icu dev-libs/boost # One of the following USE flag combinations is required: # icu app-text/sword # One of the following USE flag combinations is required: # icu dev-libs/xerces-c # One of the following USE flag combinations is required: # icu dev-db/sqlite app-text/calibre # One of the following USE flag combinations is required: # intl dev-lang/php # One of the following USE flag combinations is required: # calligra_features_kexi app-office/calligra net-libs/webkit-gtk # One of the following USE flag combinations is required: # unicode media-libs/raptor # One of the following USE flag combinations is required: # icu net-nds/openldap # One of the following USE flag combinations is required: # !dedicated,icu games-simulation/openttd # One of the following USE flag combinations is required: # icu x11-libs/qt-core dev-tex/bibtexu www-client/uzbl # One of the following USE flag combinations is required: # cxx dev-libs/beecrypt app-text/bibletime # One of the following USE flag combinations is required: # icu app-accessibility/brltty dev-db/firebird # One of the following USE flag combinations is required: # icu gnustep-base/gnustep-base # One of the following USE flag combinations is required: # cjk net-misc/suite3270 sys-apps/gptfdisk www-client/chromium # One of the following USE flag combinations is required: # icu dev-libs/libxml2 dev-db/couchdb # One of the following USE flag combinations is required: # icu dev-libs/yaz -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
[gentoo-dev] Re: spotify license
On 10/29/2012 03:32 PM, Matija Šuklje wrote:
On Ponedeljek 29. of October 2012 15.52.20 Ulrich Mueller wrote:
On Mon, 29 Oct 2012, Matthew Thode wrote:
It's looking hard to be able to add the spotify ebuild to tree because
of licensing concerns.
http://www.spotify.com/us/legal/end-user-agreement/
This concerns not so much the client software, but their service and
the contents provided through it.
Well, the “Spotify Software” is included at least it §4 and also in general
included in the “service” term. The license agreement is lacking though.
In any case Gentoo can’t be the 3rd party here and therefore not redistribute
it.
10:02 prometheanfire do you have a plaintext version? I can copy
the text, but just thought I'd ask :D
10:02 dan^spotify No, and copy+pasting it into a text file isn't
something we really want you to to do, since it changes from time-to-time
10:04 prometheanfire ok, I'll see what the proper course of action
is, I think you have us accept the license on first start right?
10:04 dan^spotify Correct
10:04 dan^spotify Well, first login
10:05 prometheanfire just as good probably
10:05 dan^spotify If you've already accepted the most up-to-date
license on another machine, you won't be prompted again
https://bugs.gentoo.org/show_bug.cgi?id=373093
They want it to be accepted through the app. Is there a way this is
compatible with Gentoo?
We need a plaintext license file for the client that we put in
${PORTDIR}licenses/, so users can look at it before they install the
package.
Yup.
They probably deem §§ 3 and 4 to be the license, but it’s quite lacking IMHO.
So since full copyright is default, this means that we’re not allowed to
redistribute it. RESTRICT=mirror we have to do here.
As a sub-optimal solution, Rich’s idea to create a Spotify license and point
the users to the actual EULA.
But unless they clarify the software license for their *client*, I’d rather
we
don’t include it. Too messy.
Maybe it would make more sense to add one of the free alternatives?
http://despotify.se/
https://gitorious.org/libopenspotify
media-sound/despotify is already in Sunrise, bug 307795.
Seems a better idea IMHO.
cheers,
Matija
P.S. As Rich mentioned, the difference between a (real) license and “license
agreement” is that a license grants you more rights then you get by law and
therefore you don’t have to agree to it, since your rights are not
diminished;
a so called license agreement (EULA, ToS, whatever_agreement) has nothing to
do with a (real) license apart from the falsely borrowed name and you have to
agree with it, since your statutory rights are diminished/voided.
Ya, I've asked for clarification there, unless we get something more
explicit it stays out of tree.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
El lun, 29-10-2012 a las 12:16 +, Markos Chandras escribió: On Mon, Oct 29, 2012 at 11:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 28/10/12 14:26, Pacho Ramos wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I've been maintaining sys-power/acpid since nobody in mobile@ has been for ages now I've never seen anyone from mobile@ replying to any of the bugs, *any* of the bugs So yeah, +1 for m-needed@, the herd clearly doesn't work as random HW specific packages are assigned to it Perfect. Lets remove the project+email+herd altogether with an immediate announcement of this action and which packages are not maintained anymore. Pacho can you take care of this like you did in the past for other dead teams? Yes, but probably won't have time for it until ~10 November or so (weekend of next week) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 29/10/2012 13:19, Anthony G. Basile wrote: I just generated the list of dependencies, 28 packages, see below. Compile tests against each are easy enough. Run tests against non-library packages are easy too. It would be harder to do an exhaustive test against, say, dev-libs/boost because then we are a couple of libraries levels deep. Not sure how deep is enough with this one. Are you sure about your numbers? My script shows 52, not 28 packages. Among others, your list does not show libreoffice-bin, which is what this time would have caused the most damage. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 10/29/2012 04:59 PM, Diego Elio Pettenò wrote: On 29/10/2012 13:19, Anthony G. Basile wrote: I just generated the list of dependencies, 28 packages, see below. Compile tests against each are easy enough. Run tests against non-library packages are easy too. It would be harder to do an exhaustive test against, say, dev-libs/boost because then we are a couple of libraries levels deep. Not sure how deep is enough with this one. Are you sure about your numbers? My script shows 52, not 28 packages. Among others, your list does not show libreoffice-bin, which is what this time would have caused the most damage. I used reverse-dependencies.py from the arch-tools repo. greping the tree shows the following 53 packages. (I'm either not using reverse-dependencies.py correctly or the tool is missing something. I'll try to figure that out later.) Anyhow, the question really remains, how to deeply test this package before adding it to the tree even ~arch? app-accessibility/brltty app-arch/unar app-emulation/vmware-workstation app-emulation/open-vm-tools app-emulation/vmware-view-open-client app-i18n/ibus-qt app-i18n/fcitx app-misc/tracker app-office/calligra app-office/libreoffice-bin app-office/libreoffice app-text/calibre app-text/sword app-text/bibletime dev-db/couchdb dev-db/firebird dev-db/sqlite dev-lang/php dev-lang/R dev-lang/parrot dev-libs/389-adminutil dev-libs/xerces-c dev-libs/beecrypt dev-libs/boost dev-libs/dee dev-libs/yaz dev-libs/xalan-c dev-libs/libxml2 dev-tex/bibtexu dev-util/dwdiff dev-vcs/veracity games-simulation/openttd games-strategy/megaglest gnustep-base/gnustep-base media-libs/harfbuzz media-libs/raptor media-sound/music-file-organizer media-sound/mpfc net-libs/qmf net-libs/webkit-gtk net-misc/suite3270 net-nds/389-admin net-nds/openldap net-nds/389-ds-base net-nntp/tin sci-geosciences/mapnik sys-apps/gptfdisk sys-apps/prefix-chain-utils www-apps/389-dsgw www-client/uzbl www-client/chromium x11-libs/qt-webkit x11-libs/qt-core -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] [RFC] A news item covering PYTHON_TARGETS
On Mon, 29 Oct 2012 15:45:01 +0100 Michał Górny mgo...@gentoo.org wrote: Since some ebuilds are using that variable already and we still didn't inform most of our users if and how they should set it, I'd like to commit the following news item: Thank you for all your suggestions, and especially Duncan for wording the hardest paragraph for me ;). I've also tried to make the remaining ones clearer. Title: PYTHON_TARGETS deployment Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2012-10-29 Revision: 1 News-Item-Format: 1.0 Recently, a few new Python eclasses were deployed. As ebuilds migrate, the way they support multiple Python implementations will change. The previous method built Python modules for all currently installed Python implementations. The new one uses the PYTHON_TARGETS USE flags to explicitly name the implementations the modules shall be built for. If you are running a modern system with Python 2.7 3.2 being the only installed Python implementations, then you don't have to do anything. The defaults will simply fit you, and let you keep your system up-to-date when new Python versions are deployed. However, if you'd like to use another set of Python implementations, you will want to set PYTHON_TARGETS in your make.conf file appropriately. This variable names the enabled implementations in the standard way common to all USE_EXPAND variables. For example, a setup enabling all major Python implementations would look like: PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 The variable should list all Python implementations which are going to be used on the system; missing a particular value there will result in missing Python modules. A complete list of all possible values can be obtained using a command equivalent to the following: emerge -1pv dev-python/python-exec -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 29/10/2012 14:37, Anthony G. Basile wrote:
Anyhow, the question really remains, how to deeply test this package
before adding it to the tree even ~arch?
a) check that there is nothing depending on =${oldver} — if there is,
notify maintainer;
b) check the documentation to see if there is something extremely
obvious that will break (with icu unfortunately that doesn't happen);
c) try to get betas and rcs in asap _but masked_;
d) call for a tinderbox run (I can do that with a quick email);
In this case all should have stopped at a) since libreoffice-bin has a
=49* dep, for obvious reasons.
Since there was no hurry of security issues to get icu-50 in, I don't
see why this was all forced through -50_rc without giving time to the
_one_ package that was using an older version to update.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS
Michał Górny posted on Mon, 29 Oct 2012 22:50:09 +0100 as excerpted: Thank you for all your suggestions, and especially Duncan for wording the hardest paragraph for me ;). I've also tried to make the remaining ones clearer. That's clear enough if it were water you could bottle and sell it! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS
On 29.10.2012 18:15, Mike Gilbert wrote: Good idea to inform users. Is there a way to have this news item go away, say after a year or so? Every time I do a fresh install, I get hit with a couple of perpetual news items, and it is a little annoying. News items were designed to be deleted when they are not deleted. Unfortunately Portage used to crash when that was first tried. I think it's been quite a long time since that was fixed so it could be safe to try again. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, 29 Oct 2012 15:07:15 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: [...] d) call for a tinderbox run (I can do that with a quick email); For that part, I think everyone would benefit from an official tinderbox, infra-hosted and with a documented interface; not everyone has the horsepower to build libreoffice or run boost's test suite. It is also probably not obvious to everyone that one should ask you for help, or even what is eligible for a tinderbox run (I remember you refused when I asked you to make a tinderbox run for ffmpeg). It would also save you the electricity bill and, being official, rants about how bugs are filled.
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, Oct 29, 2012 at 5:17 PM, Alexis Ballier aball...@gentoo.org wrote: On Mon, 29 Oct 2012 15:07:15 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: [...] d) call for a tinderbox run (I can do that with a quick email); For that part, I think everyone would benefit from an official tinderbox, infra-hosted and with a documented interface; not everyone has the horsepower to build libreoffice or run boost's test suite. It is also probably not obvious to everyone that one should ask you for help, or even what is eligible for a tinderbox run (I remember you refused when I asked you to make a tinderbox run for ffmpeg). It would also save you the electricity bill and, being official, rants about how bugs are filled. Luckily I'm not paying the electricity bill of the new tinderbox. As for the rest, yes I'd welcome an official one as well, the problem is that there really isn't an interface. Every time I spoke about building one, the answer has been $project will make it obsolete/useless (be it somebody else's personal project, or a GSoC one). The whole code is open, I'll try to find some more time to document it over the week as I discussed with Brian, maybe that can help. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
