[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest commit with
key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog 25 Sep 2012 14:08:40 - 1.23
+++ ChangeLog 11 Feb 2014 09:42:47 - 1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the GPL v2
+# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v 1.1
2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
On Tue, Feb 11, 2014 at 1:56 AM, Michael Palimaka kensing...@gentoo.org wrote: Looks interesting. It reminds me somewhat of autodep[1]. Interesting - does this work? I don't see it in portage. One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... Rich
[gentoo-dev] Re: mbox -- looks sort of interesting
On 02/11/2014 11:34 PM, Rich Freeman wrote: On Tue, Feb 11, 2014 at 1:56 AM, Michael Palimaka kensing...@gentoo.org wrote: Looks interesting. It reminds me somewhat of autodep[1]. Interesting - does this work? I don't see it in portage. It used to work pretty well, but the bundled portage version doesn't support EAPI 5. I previously made an attempt to merge a newer version of portage in, but I was not successful. One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does.
Re: [gentoo-dev] mbox -- looks sort of interesting
On 11/02/14 01:36, Jason A. Donenfeld wrote: Hey folks, Late night clicking-while-drooling, I came across something a few minutes ago that mildly piqued my interest -- mbox http://pdos.csail.mit.edu/mbox/. It's a sandbox that uses a combination of ptrace and seccomp bpf; neither ours nor exherbo's uses both of these together. The killer feature, for us, that's motivating me to write to this list, is that it creates a shadow file system, and then has the option to commit the changes of that file system to the real file system, piece by piece, when the process is done. It made me think of some discussions we had at FOSDEM about Portage evolution and whatnot. I haven't looked at this tool past an initial glance, but it does look like interesting food for thought. Jason At FOSDEM I have seen this interesting talk[1,2] on a similar subject. PRoot[3] would be similar to mbox. But CARE[4] might be great to reproduce build problems on user machines. justin 1 https://fosdem.org/2014/schedule/event/syscall/ 2 http://ftp.belnet.be/FOSDEM/2014/H2215_Ferrer/Saturday/Software_engineering_tools_based_on_syscall_instrumentation.webm 3 http://proot.me/ 4 http://reproducible.io/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org wrote: On 02/11/2014 11:34 PM, Rich Freeman wrote: One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does. What is emerge_strict? The Google is failing me here... Rich
[gentoo-dev] Re: mbox -- looks sort of interesting
On 02/12/2014 01:03 AM, Rich Freeman wrote: On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org wrote: On 02/11/2014 11:34 PM, Rich Freeman wrote: One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does. What is emerge_strict? The Google is failing me here... Rich Sorry, I should have clarified. It's provided by autodep, extending the dependency analysis by denying access to any files not part of the specified dependencies and @system.
Re: [gentoo-dev] mbox -- looks sort of interesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jason, On 11.02.2014 01:36, Jason A. Donenfeld wrote: It's a sandbox that uses a combination of ptrace and seccomp bpf; neither ours nor exherbo's uses both of these together. Actually, sydbox, Exherbo's sandbox *does* use both together. - -- Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL6mKUACgkQnuVXRcSi+5olDwCfRDoP9f2zfM1GndKcG1rkNWZR I9YAn2Rwdb40m0vnL0FIdyN3v/J3Ka7I =ZbOm -END PGP SIGNATURE-
[gentoo-dev] Last rites: www-client/htmlview
# Dion Moult mo...@gentoo.org (12 Feb 2014) # Masked for removal in 30 days. Removed as this was a compatibility hack # package, with equivalent functionality already implemented elsewhere (xdg- open # and co). (bug #480522) www-client/htmlview -- Dion Moult
[gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is trying to change
this into the most recent gtk version (it is a work in progress).
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that
may support either or both the toolkits. To handle this, a few developers have
introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit
versions are supported. At this point, the Gnome team highly recommends
prefering gtk3 if possible, skipping the useflag altogether. [1]
Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.
During our discussion, it was pointed out that keeping a generic USE=gtk is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.
A few of our members recommended a move away from the unversioned USE=gtk to
versioned-only USE flags. Qt managed to do this quite successfully when they
transitioned from the unversioned USE=qt (that actually meant qt3) to
USE=qt4. The benefits can be seen now that qt5 is around the corner.
USE=qt5 is straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too much - other
than adding a new use flag where appropriate. There is also no need for
USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At
some point in the future, when gtk2 consumers reach zero, we will retire gtk
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE=gtk4, without having to
re-structure half the tree.
We are reaching out to the developer community to hear your thoughts and ideas
on the matter. We would like to reach a decision that could possibly affect and
direct the state of whole tree. This decision could then be turned into a
policy, improving Gentoo's consistency across the tree.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
--
Alex Alexander | wired@gentoo
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 12/02/14 00:39, Alex Alexander wrote:
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is trying to change
this into the most recent gtk version (it is a work in progress).
No, it has always meant the latest version, it dates back to when gnome1
was still in tree
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages
that
may support either or both the toolkits. To handle this, a few developers have
introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit
versions are supported. At this point, the Gnome team highly recommends
prefering gtk3 if possible, skipping the useflag altogether. [1]
USE=gtk3 is valid only for libraries when it's not easy to split/slot
as a temporary flag.
Applications should simply pick one, the latest one that works, since
anything else is
obviously redudant.
Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.
It's sad that people don't follow common sense (which happens to be the
GNOME highlights)
and that everything must be turned into a policy of somesort so people
get it.
During our discussion, it was pointed out that keeping a generic USE=gtk is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.
I don't understand how unversioned flag could make things worse when
it's as straightforward
it can get -- gtk3 is a version bump over gtk2, if application supports
gtk3, it's
the one that should be used. The temporary USE=gtk3 used in some
packages due to
difficulties of splitting/slotting the packages, goes away soon enough.
What's important that the disease doesn't spread across the tree, making
it's life unnecessarily longer.
A few of our members recommended a move away from the unversioned USE=gtk to
versioned-only USE flags. Qt managed to do this quite successfully when they
transitioned from the unversioned USE=qt (that actually meant qt3) to
USE=qt4. The benefits can be seen now that qt5 is around the corner.
USE=qt5 is straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too much - other
than adding a new use flag where appropriate. There is also no need for
USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At
some point in the future, when gtk2 consumers reach zero, we will retire gtk
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE=gtk4, without having to
re-structure half the tree.
We are reaching out to the developer community to hear your thoughts and ideas
on the matter. We would like to reach a decision that could possibly affect
and
direct the state of whole tree. This decision could then be turned into a
policy, improving Gentoo's consistency across the tree.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
Just make the gnome gtk3 policy the guideline if you must. It's just
documenting common sense.
Re: [gentoo-dev] mbox -- looks sort of interesting
On Tue, Feb 11, 2014 at 10:39 PM, Wulf C. Krueger w...@mailstation.de wrote: On 11.02.2014 01:36, Jason A. Donenfeld wrote: It's a sandbox that uses a combination of ptrace and seccomp bpf; neither ours nor exherbo's uses both of these together. Actually, sydbox, Exherbo's sandbox *does* use both together. I didn't know sydbox made use of bpf. That's really cool. I'll have to take another look.
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Thanks for attaching link to team's policy which tries to lift any kind
of ambiguities people may have for what concerns gnome team's packages,
I hope it proved useful in your discussions.
Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit :
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is trying to change
this into the most recent gtk version (it is a work in progress).
Wrong, gtk USE flag means enable gtk support, whether this is gtk 1, 2
or 3 depends on what the package (presumably library) supports and
whether is can be slotted or not and whether current gentoo maintainer
decides what can be reasonably supported.
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages
that
may support either or both the toolkits. To handle this, a few developers have
introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit
versions are supported. At this point, the Gnome team highly recommends
prefering gtk3 if possible, skipping the useflag altogether. [1]
Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the
maintainer of the package. We point people to the fact that upstream
says gtk2 is a dead end and support will stop (if not in fact already
stopped) in the near future.
We also recommend to have maintainers support slots for their libs where
possible considering man-power and to only choose one toolkit for
applications considering where upstream development is going and
maturity of the port, and again, this is up to package maintainers.
Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.
During our discussion, it was pointed out that keeping a generic USE=gtk is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.
A few of our members recommended a move away from the unversioned USE=gtk to
versioned-only USE flags. Qt managed to do this quite successfully when they
transitioned from the unversioned USE=qt (that actually meant qt3) to
USE=qt4. The benefits can be seen now that qt5 is around the corner.
USE=qt5 is straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too much - other
than adding a new use flag where appropriate. There is also no need for
USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At
some point in the future, when gtk2 consumers reach zero, we will retire gtk
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE=gtk4, without having to
re-structure half the tree.
We are reaching out to the developer community to hear your thoughts and ideas
on the matter. We would like to reach a decision that could possibly affect
and
direct the state of whole tree. This decision could then be turned into a
policy, improving Gentoo's consistency across the tree.
Imho the whole discussion stems for packages maintainers which, as you
have written, did not follow our recommendation and tried to provided
application with both gtk2 and gtk3 support.
I agree that Gentoo is about choice... however as a maintainer of a
lot of packages, it is unreasonable to try to support two configuration
where one is dying slowly due to upstream (gtk) maintainer focus being
elsewhere, hence why we wanted maintainers to choose. Instead, it occurs
that some decided not to choose or to stop users from annoying them with
100 of duplicate bugs about not providing the alternative.
Looking at the situation from a gnome team member perspective when Gnome
3 was introduced to the tree, only three packages (providing libs)
needed exception to the rule to avoid unreasonable maintenance overhead:
spice, gtk-vnc and avahi. All of them had proper USE-dependencies in
relevant ebuilds so no confusion would be possible.
Right now, I don't really get the point of this discussion given all the
precedent threads about this, be it 2 years ago and 8-10 years ago.
Anyway, if QA would provide with a list of offenders (this could have
been done on bugzilla btw), we could walk-through the list and verify
what/if/how packages would need extra USE flags or not and not just for
our self-written policy's sake that is.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
Le Tue, 11 Feb 2014 12:09:14 +0200
Samuli Suominen ssuomi...@gentoo.org a écrit:
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest commit with
key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog 25 Sep 2012 14:08:40 - 1.23
+++ ChangeLog 11 Feb 2014 09:42:47 - 1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the GPL v2
+# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v 1.1
2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Nice catch, also present in the previous bump! 2.40 used EAPI 3 so it
had the implicit RDEPEND=${DEPEND}... Fixed in both 2.41 and 2.42
ebuilds
For upower this new version directly uses upower-glib, so it's a build
dependency
--
Bernard
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Wed, 12 Feb 2014, Samuli Suominen wrote: USE=gtk3 is valid only for libraries when it's not easy to split/slot as a temporary flag. Applications should simply pick one, the latest one that works, since anything else is obviously redudant. I don't see why applications should be treated differently from libraries. If a program supports more than one toolkit, then the choice should be left to the user. Nothing redundant there. Ulrich pgp_1aJRKdmQW.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 12/02/14 01:51, Ulrich Mueller wrote: On Wed, 12 Feb 2014, Samuli Suominen wrote: USE=gtk3 is valid only for libraries when it's not easy to split/slot as a temporary flag. Applications should simply pick one, the latest one that works, since anything else is obviously redudant. I don't see why applications should be treated differently from libraries. If a program supports more than one toolkit, then the choice should be left to the user. Nothing redundant there. Ulrich For libraries it's forced, like eg. libcanberra's gtk3 version for GNOME and gtk2 version for Xfce due to direct use of NEEDED, headers, pkg-config etc. But applications is whole different story... The maintainer makes the decision which toolkit is used and best supported. If some application has initial port to gtk3, but still lacks some features the gtk2 version still had, then maintainer makes the smart choice of using the version that has all the features, if the maintainer deems those features important. There is no point in having them in parallel, it only increases the workload, making maintainer do double-testing of the application, not to mention the work it causes later when gtk2 is slated obsolete as gtk1 is now Sometimes I think people have already forgotten the mess we had during the gnome1 removal times with USE=gtk2 :-( - Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
On 12/02/14 01:20, Bernard Cafarelli wrote:
Le Tue, 11 Feb 2014 12:09:14 +0200
Samuli Suominen ssuomi...@gentoo.org a écrit:
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest commit with
key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog 25 Sep 2012 14:08:40 - 1.23
+++ ChangeLog 11 Feb 2014 09:42:47 - 1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the GPL v2
+# $Header: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v 1.1
2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Nice catch, also present in the previous bump! 2.40 used EAPI 3 so it
had the implicit RDEPEND=${DEPEND}... Fixed in both 2.41 and 2.42
ebuilds
For upower this new version directly uses upower-glib, so it's a build
dependency
I don't think it's legit to use the upower-glib library without
pkg-config. So I'm pretty sure you are missing build-time-only
dependency of virtual/pkgconfig then too.
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Wed, 12 Feb 2014, Samuli Suominen wrote: But applications is whole different story... The maintainer makes the decision which toolkit is used and best supported. If some application has initial port to gtk3, but still lacks some features the gtk2 version still had, then maintainer makes the smart choice of using the version that has all the features, if the maintainer deems those features important. There is no point in having them in parallel, it only increases the workload, making maintainer do double-testing of the application, not to mention the work it causes later when gtk2 is slated obsolete as gtk1 is now Let's take Emacs as an example. The upstream package supports Athena widgets (both in Xaw and Xaw3d variants), Motif, GTK2, and GTK3. Currently there are five USE flags to control this, and I'm convinced that the right solution is to leave this choice to the user. (And if I was forced to decide on the toolkit for Emacs, then I wouldn't even pick GTK, for stability reasons ...) Ulrich pgpcFcdux7kOH.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote:
Thanks for attaching link to team's policy which tries to lift any
kind of ambiguities people may have for what concerns gnome team's
packages, I hope it proved useful in your discussions.
Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit
:
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state
of the gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is
trying to change this into the most recent gtk version (it is a
work in progress).
Wrong, gtk USE flag means enable gtk support, whether this is gtk
1, 2 or 3 depends on what the package (presumably library) supports
and whether is can be slotted or not and whether current gentoo
maintainer decides what can be reasonably supported.
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in
packages that may support either or both the toolkits. To handle
this, a few developers have introduced the gtk3 useflag, that
prefers gtk3 over gtk2 when both toolkit versions are supported.
At this point, the Gnome team highly recommends prefering gtk3 if
possible, skipping the useflag altogether. [1]
Wrong, as is written in policy whether to prefer gtk2 or 3 is up to
the maintainer of the package. We point people to the fact that
upstream says gtk2 is a dead end and support will stop (if not in
fact already stopped) in the near future.
We also recommend to have maintainers support slots for their libs
where possible considering man-power and to only choose one toolkit
for applications considering where upstream development is going
and maturity of the port, and again, this is up to package
maintainers.
This doesn't make sense to me at all. I can't see why slotted
libraries can't just use USE flags to specify what toolkit they're
built against, just like any other package in the tree (so, for
example, a package that needs webkit-gtk built against gtk3 would
depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware
that there could be limitations I'm unaware of (maybe the package only
can build one at a time?), but this is how it looks to me. By
switching to versioned gtk flags, this kills two birds with one stone:
it makes it obvious to the end user which version they're trying to
build their package against, and it gets rid of the need for (ab)using
revision numbers to implement slots like that.
Some developers choose to follow the Gnome team's highlights,
while others choose to go their own way. The QA team would like
to establish a guideline that solves this problem in the best way
possible.
During our discussion, it was pointed out that keeping a generic
USE=gtk is sub-optimal. The non-straightforward nature of new
toolkit versions makes transitioning from one to the other a
slow, tedius process and we think that a non-versioned USE flag
makes things even worse.
A few of our members recommended a move away from the unversioned
USE=gtk to versioned-only USE flags. Qt managed to do this
quite successfully when they transitioned from the unversioned
USE=qt (that actually meant qt3) to USE=qt4. The benefits can
be seen now that qt5 is around the corner. USE=qt5 is
straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too
much - other than adding a new use flag where appropriate. There
is also no need for USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by
USE=gtk3. At some point in the future, when gtk2 consumers
reach zero, we will retire gtk for good. Then, if some day gtk4
comes around, we will be able to introduce support for it in the
tree by simply adding USE=gtk4, without having to re-structure
half the tree.
We are reaching out to the developer community to hear your
thoughts and ideas on the matter. We would like to reach a
decision that could possibly affect and direct the state of whole
tree. This decision could then be turned into a policy, improving
Gentoo's consistency across the tree.
Imho the whole discussion stems for packages maintainers which, as
you have written, did not follow our recommendation and tried to
provided application with both gtk2 and gtk3 support.
I agree that Gentoo is about choice... however as a maintainer of
a lot of packages, it is unreasonable to try to support two
configuration where one is dying slowly due to upstream (gtk)
maintainer focus being elsewhere, hence why we wanted maintainers
to choose. Instead, it occurs that some decided not to choose or to
stop users from annoying them with 100 of duplicate bugs about not
providing the alternative.
Looking at the situation from a gnome team member perspective when
Gnome 3 was introduced to the tree, only three packages (providing
libs) needed exception to the rule to avoid
[gentoo-dev] Re: [RFC] Tightening EAPI rules
On Mon, 10 Feb 2014 20:43:41 +0800 Patrick Lauer patr...@gentoo.org wrote: At the time EAPI 0 was in limbo as toolchain required it (What's the current status of toolchain on that?) GCC is now EAPI 2 except for gcc-apple and kgcc64. I'm going to deprecate EAPI 0 and 1 soon but need to give people time to update overlays afterwards. It won't be hard to move to 4 after that but it'll need another deprecation cycle. You'll have to ask Mike about glibc and binutils. Personally I think we should always keep the latest three EAPIs around, so 4, 5, and 6 (and 0). -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
On Wed, 12 Feb 2014 01:36:01 +1100 Michael Palimaka kensing...@gentoo.org wrote: On 02/12/2014 01:03 AM, Rich Freeman wrote: On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org wrote: On 02/11/2014 11:34 PM, Rich Freeman wrote: One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does. What is emerge_strict? The Google is failing me here... Rich Sorry, I should have clarified. It's provided by autodep, extending the dependency analysis by denying access to any files not part of the specified dependencies and @system. There was a gentoo gsoc project a few years ago that did exactly this for doing dep checks on ebuilds. There was also one for determining deps automatically. Is this the project mentioned? ^^^ -- Brian Dolbec dolsen
[gentoo-dev] Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Tue, 11 Feb 2014 19:33:06 -0500 Chris Reffett creff...@gentoo.org wrote: This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Exactly. For wxGTK my options are using a gtk3 USE flag, adding a whole new wxGTK-gtk3 ebuild, or using a 3.0-gtk3 SLOT and some clumsy -r300 thing. The second option brings along a nightmare of file collisions (we have enough trouble supporting multiple installed versions, never mind multiple toolkits within those versions), and the last option isn't actually feasible because everything in the eclass/eselect is tied directly into the SLOT. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
El mar, 11-02-2014 a las 19:33 -0500, Chris Reffett escribió: [...] This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. At least for webkit-gtk, we would still need to have slots as, otherwise, people wanting gtk2 support wouldn't be able to have webkit2 support at the same time (that is needed by, for example, epiphany and other recent webkitgtk consumers), not sure about other slotted packages for gtk2/3 support (I don't have much time just now to recheck all :S)
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Hi,
On Wed, 12 Feb 2014 00:39:14 +0200 Alex Alexander wrote:
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is trying
to change this into the most recent gtk version (it is a work in
progress).
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in
packages that may support either or both the toolkits. To handle this,
a few developers have introduced the gtk3 useflag, that prefers gtk3
over gtk2 when both toolkit versions are supported. At this point, the
Gnome team highly recommends prefering gtk3 if possible, skipping the
useflag altogether. [1]
Some developers choose to follow the Gnome team's highlights, while
others choose to go their own way. The QA team would like to establish
a guideline that solves this problem in the best way possible.
During our discussion, it was pointed out that keeping a generic
USE=gtk is sub-optimal. The non-straightforward nature of new
toolkit versions makes transitioning from one to the other a slow,
tedius process and we think that a non-versioned USE flag makes things
even worse.
A few of our members recommended a move away from the unversioned
USE=gtk to versioned-only USE flags. Qt managed to do this quite
successfully when they transitioned from the unversioned
USE=qt (that actually meant qt3) to USE=qt4. The benefits can be
seen now that qt5 is around the corner. USE=qt5 is straightforward,
does not mess with qt4 packages and was introduced to the tree without
messing with current packages too much - other than adding a new use
flag where appropriate. There is also no need for USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by
USE=gtk3. At some point in the future, when gtk2 consumers reach
zero, we will retire gtk for good. Then, if some day gtk4 comes
around, we will be able to introduce support for it in the tree by
simply adding USE=gtk4, without having to re-structure half the tree.
We are reaching out to the developer community to hear your thoughts
and ideas on the matter. We would like to reach a decision that could
possibly affect and direct the state of whole tree. This decision
could then be turned into a policy, improving Gentoo's consistency
across the tree.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
This is a really good idea and I am all in favor of it.
gtk+:3 still isn't adopted widely and there are still not many good
looking skins available for it. (sorry but I don't want to have all gtk+
apps I am using looking totally ugly again)
I doubt gtk+:2 will be deprecated that soon as some of our devs try
to imply.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
