Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/03/2015 12:47 AM, Brian Dolbec wrote: On Mon, 3 Aug 2015 00:22:42 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: I'm having a hard time understanding why we need daemons to handle our filesystems. Can you give me a use case that /etc/fstab is insufficient for solving? - -- Daniel Campbell - Gentoo Developer It is about defining proper dependencies and not blindly returning a success result when there were actual failures to start some files systems. So in some ways it is a bugfix. But it is actually a re-design which will overcome shortcomings/limitations in the fstab, netmount, localmount designs. Net result should be better configurability, proper error reporting, proper service order startup,... Downside, it will likely mean a little migration/transistion. I'm in favour of the change. Good work William. I'm okay with a change as long as it's relatively manageable and offers some real benefits. If I understand correctly, this new mounting will allow us to declare mounting dependencies the same way we declare service/daemon dependencies, correct? So say I want to have an ownCloud instance that provides a single /usr or /etc for any Gentoo system that wants it on my local network. Is that a use case that would benefit from this new mounting? I'm just trying to understand which use cases benefit and why, and what it is that fstab isn't good enough for right now. As a developer, I want to be able to support users on this if/when it hits mainline OpenRC. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVv/uOAAoJEAEkDpRQOeFwcYUP+wcyl4leWeX8lYrsIXc1Ukzs /uU33M1zcFM8Sya7ywO3cjGvS/3d1P9qkVeDy1S/Cfb8SGGGECsNbVpN0Dht9un7 UxOejDuTXdqD5+XWVBsoXYcWbvVFtOPGnSJtQSd8nU0RQ9jOxQqKjk05Of/e0mKT yT91GFvbBpTFyzM+cnXPN/OKHBOEg0Aq51JmtQ2jn8fjrUml87C7MrqwmX1PnQPN mvxhtTAvmj4LMIIRnUsPZOl/6NfeHgWeepkYcKEJiAlBasr4eMawhR+cbQmvLDeg skmvptRU42GQ3Ah/IDXvBN1dZGwXv1lYb+r5NqxxNK8RqsaWHMQ25278Fr1HVgj9 julvufmP8mrhe/Q939qW+Z7efhT2Mn+VFaX4woqSSNw8iqy/zgwtWlVHInpd3Q7B xpIRkpeJxNBLfYAh61RvBqbQuf9jsNoy8fabyx3LaHKwif7sjKEfx++lGc4Eq9b4 vEB+HdMXGJsP2AeFg/QDa8ioaYpIwCPDtTliQBjGs7KW/4gzJdg1A/iLux0J9dAQ snhRP4QYmBEU1V8XiCRYk68QBdsOFkN5sPoad1/ZIN+jQMSn3uXcEeflWoj+z+GZ K7p6xSdPkowBmrJrn1SkgpIlqyqUSNUB6haT1SKPPUBAye3JHZATpwgaF3teuPOG Kw8VULdYOad9ynaMO8g1 =sGaS -END PGP SIGNATURE-
Re: [gentoo-dev] new eclass: golang-vcs-snapshot.eclass for golang vcs snapshots
On Mon, Aug 03, 2015 at 07:20:20PM -0500, William Hubbs wrote: *snip* # Copyright 1999-2013 Gentoo Foundation I'll fix the year before I commit. William signature.asc Description: Digital signature
Re: [gentoo-dev] useflag policies
On 03/08/2015 22:20, Rich Freeman wrote: On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski reave...@gmail.com wrote: On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... Obviously there are many reasons people use Gentoo, but here is my perspective on this. The value of Gentoo is that it gives you a LOT of power to tweak individual package configurations, without the requirement to do this for everything. There are packages that I carefully configure USE flags for, CFLAGS for, epatch_user, and so on. Heck, some packages I run in containers where I can carefully control almost all aspects of their environment. Then on the same host I'll have screen and bash and a million other packages installed where exact configuration is not critical, and so I want it to just work. If I wanted to micromanage everything I might as well run Linux From Scratch. Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. +1 One of the most powerful aspects of ebuilds is the ability to not have to control something the user does not want to. I use Gentoo because I can control what I wish and like Rich the bits I want to control are a small fraction of the whole. When a dev says I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo, there is a place for that but it is by no means the general case. We DO accommodate the control freaks, we let them USE=-* and let them keep all the tiny shards. But the truth is far more subtle than a care-all/care-none scenario. I say stick with reasonable defaults, and for better or worse, that includes use highest version in ACCEPT_KEYWORDS unless user says otherwise -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
On Mon, Aug 03, 2015 at 04:38:59PM -0700, Daniel Campbell (zlg) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/03/2015 12:47 AM, Brian Dolbec wrote: On Mon, 3 Aug 2015 00:22:42 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: I'm having a hard time understanding why we need daemons to handle our filesystems. Can you give me a use case that /etc/fstab is insufficient for solving? - -- Daniel Campbell - Gentoo Developer It is about defining proper dependencies and not blindly returning a success result when there were actual failures to start some files systems. So in some ways it is a bugfix. But it is actually a re-design which will overcome shortcomings/limitations in the fstab, netmount, localmount designs. Net result should be better configurability, proper error reporting, proper service order startup,... Downside, it will likely mean a little migration/transistion. I'm in favour of the change. Good work William. I'm okay with a change as long as it's relatively manageable and offers some real benefits. If I understand correctly, this new mounting will allow us to declare mounting dependencies the same way we declare service/daemon dependencies, correct? So say I want to have an ownCloud instance that provides a single /usr or /etc for any Gentoo system that wants it on my local network. Is that a use case that would benefit from this new mounting? I'm just trying to understand which use cases benefit and why, and what it is that fstab isn't good enough for right now. As a developer, I want to be able to support users on this if/when it hits mainline OpenRC. fstab is *not* going anywhere. The difference right now is that you just have two services that control all file system mounts and imo do a bad job of it. ;-) netmount and localmount always succeed, regardless of whether anything they mount fails. Under the new system, you will have services like mount.home, mount.usr, mount.var etc, which will actually be able to report failure if they do not mount their file systems. localmount and netmount will be kept, for now, but you will have to configure them to have dependencies like rc_need=mount.foo mount.bar mount.bas etc, depending on which file systems are local or network. These versions of localmount and netmount will also change behaviours, because they will be able to fail if a filesystem they need fails to mount. Does that make sense? William signature.asc Description: Digital signature
[gentoo-dev] new eclass: golang-vcs-snapshot.eclass for golang vcs snapshots
This eclass is meant to handle vcs snapshots of golang packages coming
from services like github.
Let me know what you think.
William
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: golang-vcs-snapshot.eclass
# @MAINTAINER:
# William Hubbs willi...@gentoo.org
# @BLURB: support eclass for unpacking VCS snapshot tarballs for
# software written in the Go programming language
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which unpacks the
# first tarball mentioned in SRC_URI to its appropriate location in
# ${S}, treating ${S} as a go workspace.
#
# The location where the tarball is extracted is defined as
# ${S}/src/${EGO_PN}.
#
# The typical use case is VCS snapshots coming from github, bitbucket
# and similar services. They have a commit hash appended to the directory name
# which makes extracting them a painful experience. But if you use a
# SRC_URI arrow to rename it (which you're likely have to do anyway),
# vcs-snapshot will just extract it into a matching directory.
#
# Please note that this eclass currently handles only tarballs
# (.tar.gz), but support for more formats may be added in the future.
#
# @EXAMPLE:
#
# @CODE
# EGO_PN=github.com/user/package
# inherit golang-vcs-snapshot
#
# SRC_URI=http://github.com/example/${PN}/tarball/v${PV} - ${P}.tar.gz
# @CODE
inherit golang-base
case ${EAPI:-0} in
5) ;;
*) die ${ECLASS} API in EAPI ${EAPI} not yet established.
esac
EXPORT_FUNCTIONS src_unpack
# @FUNCTION: golang-vcs-snapshot_src_unpack
# @DESCRIPTION:
# Extract the first archive from ${A} to the appropriate location for GOPATH.
golang-vcs-snapshot_src_unpack() {
local f destdir=${WORKDIR}/${P} x
ego_pn_check
set -- ${A}
x=$1
mkdir -p ${destdir}/src/${EGO_PN%/*}
tar -C ${destdir}/src/${EGO_PN%/*} -x --strip-components 1 \
-f ${DISTDIR}/${x} || die
}
signature.asc
Description: Digital signature
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
On Mon, Aug 3, 2015 at 7:38 PM, Daniel Campbell (zlg) z...@gentoo.org wrote: So say I want to have an ownCloud instance that provides a single /usr or /etc for any Gentoo system that wants it on my local network. Is that a use case that would benefit from this new mounting? I suppose daemons that provide mountpoints (FUSE/etc) might be one use case, but the more common one would be daemons that require mountpoints (especially ones that might not be quickly available at boot). Maybe my 500TB mythtv recording directory takes 2min to fsck and mount so I'd like to delay startup of mythtv. Hosts that run lots of containers or such with iSCSI mounts might be another use case - they could be mounted in parallel and their containers could start as they become available. -- Rich
Re: [gentoo-dev] useflag policies
On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote: [...] Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. Of course some users will proceed to enable both qt4 and qt5 globally in their make.conf, but I don't think it is unreasonable to expect them to then deal with adding exceptions to package.use for those packages where exactly-one-of is required. In my opinion, this is the way Gentoo has always worked, and we should simply recommend users to only set one of the qt* useflags as globally enabled, if they want to prevent such micro-management. Hiding the qt4 option is in my opinion the wrong solution around people complaining after they have consciously enabled both flags. If this is not acceptable (or absolutely unusable as one dev put it), then we need a proper solution, which a) will not hide the qt4 option, and b) will prevent triggering required_use blockage by choosing qt5 over qt4 in case both are enabled, while c) informing the user about this. This probably requires new eclass or even EAPI functionality. In the meantime, we should stick with the policies adopted at the qt3 to qt4 transition (explicit versioned useflags) and let the user deal with per-package management if they enable both flags. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote: On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote: [...] Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. That is not correct. The desktop profile enables qt4, because it is a reasonable default (for qt-only packages, USE=-qt4 means don't build any gui, but desktop users always expect some kind of a gui by default, whether it's gtk or qt*.) The result is that qt4 is enabled in child profiles of desktop - gnome and kde and plasma. Since plasma enables qt5 and does nothing with qt4, you have all qt versions enabled there. And when popular qt5-only, gui-optional packages appear in the tree, we will need to enable qt5 in desktop profile too. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 3 Aug 2015 00:47:24 -0700 Brian Dolbec dol...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 3 Aug 2015 00:22:42 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: I'm having a hard time understanding why we need daemons to handle our filesystems. Can you give me a use case that /etc/fstab is insufficient for solving? - -- Daniel Campbell - Gentoo Developer It is about defining proper dependencies and not blindly returning a success result when there were actual failures to start some files systems. So in some ways it is a bugfix. But it is actually a re-design which will overcome shortcomings/limitations in the fstab, netmount, localmount designs. Net result should be better configurability, proper error reporting, proper service order startup,... Downside, it will likely mean a little migration/transistion. I'm in favour of the change. Good work William. - -- Brian Dolbec dolsen I forgot to say: For the average joe user that only has a few fstab entries, /boot, /root,/home. swap... It won't mean much if anything other than an un-needed change. Since it works for them. But for a systems administrator configuring servers with virtual machines, services depending on certain or multiple filesystems being up, etc... It can mean a BIG difference. It is the more complicated systems that are hitting the limitations of the current fstab system. not the simple user with a standard/basic handbook install. - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVvx9LXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YkEMP/jCQVHLzBirLl3O752jXxc98 VB7yXuq1JTgAtC02ZZ6rTtSDcGHuNTfYSDV85A0qxIGHveK9GF1p3M2dueDIVF90 IBNuP1f2M+IAHm7htatA4a0OG8GFl1ldPKExFRWxwtjs1l4jK1PKZNPXKMztdNOA V221ugPBoGBsjHNkgG04NaBPLHRu+JCGnW3SIDU5ATCFu+KpEmlFXK+vKs3/Eqln XRz1pxcomgrAiV1lY7hV0dnianUBy2p2i8fkHaILLtcicJmsnOhzDqX94k5BomUb C4fJoQw/Q/bIOLQTrT1jwQ6cOSnq/h40VyyYMnem1nEaFQ/4ePBq+Ie298Xtu5Bg rS4xu0QOmtZyqwDpoqusAH+Zljf3Wa5joi7wUse1PyXWcVZCRUfeujGEWp/mBEIy FB5rwBUV/dLhh2CXO/V4h5BwXKJ1slc/v5c56RO3qZib/3nG2yqlN+48daIARGAC MnnjfUt/83fArwC5bBSN6TibfLPV+O/yjT0BXsh5Oqx7cKQPnSXq3EBtal3WdNcT Q5jX9fdoW4wnFn8OGn1g6tse1w2PtaQuDa9jOt+2WixMky399Zmqnfrzx6eFV4EN 4JfYsJMEL/3iZfP2BH9N3CBItHgJf296Wj8UP0dy0Li0bJU12yPcYTcRAyT2LvEz TNs2g32DnhUeoW5aN/2H =CCBF -END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2015 10:33 AM, Andrew Savchenko wrote: On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: Recently some team members of the Qt project have adopted these ebuild policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies I have an issue with the policy adopted under Requires one of two Qt versions. In my opinion, in the case where a package offers a choice between qt4 or qt5, we should express this in explicit useflags This is what the policy does: Implement both qt4 and qt5 USE flags and a REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice. This will create insane amount of blockers if users have both flags in make.conf (and this is a common scenario). Other developers state that users are not interested in such implementation details, or that forced choice through REQUIRED_USE is too much of a hassle. This results in current ebuilds such as quassel to not make it clear that qt4 is an option. This goes against the principle of least surprise, as well as against QA recommendations. I would like to hear specifically from QA about how we should proceed, but comments from the wider developer community are also welcome. As far as I understand this is done to simplify user's experiense: usually people set both USE=qt4 qt5 in global make.conf, because they want qt in the first place. This policy will allow to USE both qt versions whichever is available preferring newer one. Quite reasonable approach. Alternatives (^^() and ??()) will require micromanagement (e.g. pagkage.use.conf) for dozens if not hundreds of packages for no good reason. If someone still needs to override such policy (e.g. to use qt4 when both are available), this can be done by per-package configuration. My idea is that packages should be fully controllable, but choises of default behaviour should be done so, that in most cases micromanagement will not be necessary. I like this qt policy and I'm not sure if it violates any current rule. But even in such case this rule should be fixed. Moreover, this problem is not limited for qt: we have exactly the same issue with gtk2 vs gtk3 and probably some other technologies. Of course in theory it is possible to build package with two sets of binaries supporting both qt4 and qt5, but I see little practical need for that. So I propose to add somewhere to devmanual/policies the following recommendation: If package supports several versions of the same technology (e.g. qt4 and qt5) and more than one is enabled by USE flags, ebuild should prefer the later one (in terms of technology generation).. Best regards, Andrew Savchenko +1 - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVvxlqAAoJEAEkDpRQOeFwRqAP/jLkyzsJ0lPind06f8YvQ4aF Nog8g2pJHJUYXryJwCZpedj4Ju8QWnlE9qOLFO/PvKjNq1AddI7PB/BpUAK1HBuq 9T319lQttGyZAFqEeYm3j1c7IcQInNSXaGLJnLVw19UWgUg1ZuTxiec7XJ7Qovmy D1BdZrMSVhxzSfCKN0kGM3IDxgInVWnEhPCiqDzDMT/U9j1K1sOFA/77/M+HbEvp LP26R/ICdznLNTRqAQxBn6TnZ0D6LMp+ngWCvSa07XCyn3O2K1cQA012l3hQ4/Jb +GP3mk6UM3rhn5saZ+2nJM5axFNylTFcJnqJFjU6//Q7q3C0Xh4sEuu8n3ywgiG4 8Mmta0i9TgGcIjfnCcDpMO6Yvs1g79Hgg3A87tCzJEaYRXWlHjGY+YsoYVIvPS6d qNdhG8+/8hhQUQy4gcmT7M5HZVkMj/hmju+X9bCPbDrJY6Xii90ZbvCZGiPBAJbm VebTPg5CAzybhqtYAOiygLKMqh1Sw8LrFlBSAMJpLr89CHN0ODuzQp+Rho6rYcp0 t2J8AWJHW2XJ8TePvDpCDkEog83c1sSxKPqsu8AHTPcw+Bvol4vpmUsv0BQlp9aa F4ZXxccqTzbZtwJ9x7jBGjlBl6H4Bu0OE/y7nUPG9aTldxMfnEgJeEktUtpAlWCu fYSYVLjlNUl9OtL/ElnI =fRV1 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] circular_dependency_handler: limit USE combination search (bug 555698)
On Sun, 2 Aug 2015 23:21:36 -0700 Zac Medico zmed...@gentoo.org wrote: Limit the number of USE combinations search to 1024, in order to avoid consuming unreasonable abouts of time. First, discard ** typo^^ amounts irrelevent flags that are not enabled. Since extract_affecting_use doesn't distinguish between positive and negative effects (flag? vs. !flag?), assume a positive relationship. If there are still too many combinations, then don't bother to explore any of them. X-Gentoo-Bug: 555698 X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=555698 --- pym/_emerge/resolver/circular_dependency.py | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/pym/_emerge/resolver/circular_dependency.py b/pym/_emerge/resolver/circular_dependency.py index b710671..5c11956 100644 --- a/pym/_emerge/resolver/circular_dependency.py +++ b/pym/_emerge/resolver/circular_dependency.py @@ -14,7 +14,9 @@ from _emerge.DepPrioritySatisfiedRange import DepPrioritySatisfiedRange from _emerge.Package import Package class circular_dependency_handler(object): - + + MAX_AFFECTING_USE = 10 + * in the commit message you talk about the limit being set to to 1024 but here it is set 10? Clarify please. def __init__(self, depgraph, graph): self.depgraph = depgraph self.graph = graph @@ -156,7 +158,7 @@ class circular_dependency_handler(object): total_flags = set() total_flags.update(affecting_use, required_use_flags) total_flags.difference_update(untouchable_flags) - if len(total_flags) = 10: + if len(total_flags) = self.MAX_AFFECTING_USE: affecting_use = total_flags affecting_use = tuple(affecting_use) @@ -164,6 +166,21 @@ class circular_dependency_handler(object): if not affecting_use: continue = + if len(affecting_use) self.MAX_AFFECTING_USE: + # Limit the number of combinations explored (bug #555698). + # First, discard irrelevent flags that are not enabled. + # Since extract_affecting_use doesn't distinguish between + # positive and negative effects (flag? vs. !flag?), assume + # a positive relationship. + current_use = self.depgraph._pkg_use_enabled(parent) + affecting_use = tuple(flag for flag in affecting_use + if flag in current_use) + + if len(affecting_use) self.MAX_AFFECTING_USE: + # There are too many USE combinations to explore in + # a reasonable amount of time. + continue + Damn, that _find_suggestions() is already 150+ LOC, up to 9 indent levels deep, before you add this :/ Is there a way you can do this in a separate test/function? At least it wouldn't be adding directly to something that already could use a little refactoring. /me cringes at what repoman is... #We iterate over all possible settings of these use flags and gather #a set of possible changes #TODO: Use the information encoded in REQUIRED_USE -- Brian Dolbec dolsen
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 3 Aug 2015 00:22:42 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: I'm having a hard time understanding why we need daemons to handle our filesystems. Can you give me a use case that /etc/fstab is insufficient for solving? - -- Daniel Campbell - Gentoo Developer It is about defining proper dependencies and not blindly returning a success result when there were actual failures to start some files systems. So in some ways it is a bugfix. But it is actually a re-design which will overcome shortcomings/limitations in the fstab, netmount, localmount designs. Net result should be better configurability, proper error reporting, proper service order startup,... Downside, it will likely mean a little migration/transistion. I'm in favour of the change. Good work William. - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVvxyMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7Yor0P/0ezM3i0k0vs2cBoklFx/RCk Tr89aQkF4HTv54gDSbwpU/bD1dSRJqWvzcJ04zqLoQeo/NnCyWxLRuKeYGba8Oh/ 0A56uuZBz1xfAgu9CCW2UDPbmFezqzLhMPddPH6N8rzmY5pJMDYpMsf4YuMZhRkI znfNBXuhEJjv91cxZD8RHasdkjzhXkzWnlL4p+9Xn4oALyiebA25OBGis9mtMuCQ /I3QXBqbuSMJ1OgzrfulU1wuWW7ELDDpSGL+4knKNzyqwyWIyeEK/dLoT78m0lvG Jbk3ehR5MY3Wm2usXHcS/fSKWf0dnhtjPHw3VUBr7aiOaIaSNDZ7CZcFqOq+jpcs /rionyEkzGo94s7dBJ11vYW5r5HfTNoY+7eLNqLTiTKPeeYtkLdxCaVAu3PjFMlM IsAlSXZ3nfS1/ti4Rnky2s9f/UXO0CZXPFpetqMHrTxv7HAerCiUkWKEPWozCfat pg4A7ycrl/1D7Eyw/XFI8/eo+4sxBn2hbAhopQZ+IOJ6398/EaQH8coaNbjU6AoN pBvbkscK38tllpSOf69CwlwUyIBylpE9rxDGzAiaUFIUqTZFLBkUebSj8LgUhO2M mAX2MxDqJV+BbtzN4pc27mWeXHJoQTEPe4VDgssKQvju0tu9mk/egfdqqXs5NL/g Z3YHhn1wynCD3C0pee5a =LpWf -END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2015 12:12 PM, Rich Freeman wrote: On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko birc...@gentoo.org wrote: This is a clean solution for developers and maintainers, but not for ordinary users — they will confused by qt qt4 qt5: what is 'qt', how is it different from 'qt4' and 'qt5'. What you are really doing is implementing second-level USE flags, while they were supposed to be linear. No argument that it isn't intuitive, but setting USE=qt and forgetting about it certainly seems more user-friendly than setting qt4/qt5 on individual packages and worrying about which is better where. To some extent the current qt policy accomplishes this, but it sacrifices control when users actually do want it. I'm a bit torn on the issue myself, but just telling users to set USE=qt and forget about it unless you really care seems pretty simple to me. The documentation for USE=qt4/qt5 could say this is an advanced setting for users who want to prefer the qt4 implementation over others - set USE=qt if all you care about is qt support. I like this idea. USE=qt for all apps that optionally support or need it, qt4/qt5 for apps that support both. We can default to qt5 and users can still choose qt4 if they prefer it. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVvxjcAAoJEAEkDpRQOeFwbIsQAJeCSW9NHUFyXirEhh/pL7cP Vc5F6bgxZhJ1svHiCxMAQuFz5POG/yxjq6iAwjtCaDaWBDj/HbSDe69Pu0HBcCkK ezb2AJTtacvkWDxlJhH4H9m7QB3M9/XWlKlfMAhKnDEaSFS/yieR578LE1sNd2aF A9JditTliVqmRr3DYNvT4JlqGIBJyU43gR75gW2gHyWE0FTZ4Rv8k6DQHJuseFb6 OvWWrDCKZQZqLmLIvpvz1ksyXuFis8qqCPLws37awo56kjT8jDJ+kdulwFGdvxui zrau+MtufhDwehVsVKKe1j/6dhVnmOqlIZd3H7Pule9jFsH6AGRN4s2dL2bp9vqi WdmQI8B6eDvdUK0Il1+zd7V1Uq8DXIYpTlOYrUHtnAlyaT8ln7FqojSKODASZ/10 LkJQ9SLv7ej6nQLnkYe4F1FQqssPqGe4v2tAZcFVu2pYda3KCP7PJKT70oFtzwrQ 76jVgp5Ryp/cbZrM2tOEcvb/3kTXDHDW2Wavh+VV7XwBmTvXoXqZas+eHMMtbyDJ 1cofAFRvu6HWnITTg3ZPoiQbm5Sq4rjG7aUvkyUxIoC8YzhXdHOTBpaYaFe6nZ/f 45e7lHq4iDsArmBn2BiF4kBKZh8I5xMY1/K10mC8/4emBS3NHbafOUKqujCCqLMj dhh/jF4gLzALPIDGXBRp =j7X5 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/30/2015 09:55 AM, Alon Bar-Lev wrote:
On 30 July 2015 at 19:15, Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 30/07/15 01:55 AM, Duncan wrote:
Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
excerpted:
On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
alo...@gentoo.org wrote:
On 29 July 2015 at 23:20, William Hubbs
willi...@gentoo.org wrote:
so that there is a better idea out there of what I'm
talking about, the OpenRC github repository now has a
mount-service branch.
But I still trying to figure out why do we need to keep
fstab around. It is pure legacy.
On what planet is fstab pure legacy? Many utilities use it
and expect it to exist. For example the ability to do mount
/foo requires a properly configured fstab file (also mount
-a).
I think there are two meanings of the word legacy here.
#1, /etc/fstab on linux is not legacy, and I don't think anyone
here (except possibly for WilliamH as I can't actually tell from
his statements) has been calling it 'legacy' in this context.
/etc/fstab is legacy in the sense it did not evolve since early
days of UNIX. Imagine /etc/crontab was left the same single file,
but it at least evolved to usr /etc/cron.*/ to ease management of
multiple sources and ease packaging/maintenance without need to
parse and rewrite single file when provisioning.
Nobody ignores /etc/fstab existence, I provided solutions of how
/etc/fstab can be read in flexible method as netifrc does (which
was actually the core idea of this move), doing so will make the
service much simpler as it can use external helper scripts to
provide the data out of whatever source, please re-read my
message.
However, having the option *NOT* to use /etc/fstab has many
advantages in security (storing credentials in own files),
provisioning (no need to race parse/rewrite), dynamic (define the
location of nfs server based on logic) and many more.
I do not understand why people are so sensitive for a change that
does not effect the outcome of their need, all that I recommended
to add is driver:
mount_driver_\${NAME}=fstab mount_mountpoint_\${NAME}=/mnt/auto
driver will be executed by the service, in this case:
openrc-mount-helper-${openrc_mount_driver_\${NAME}}
${mount_mountpoint_\${NAME}}
the output will be evaluated. This simple solution will enable the
service to be generic and provide flexible pure configuration
(whatever we choose), while support any source of information that
is capable of constructing this configuration.
Loose nothing gain some, simpler service and constraint fstab
within driver.
Another drive I can think of is UPnP.
Regards, Alon
I'm having a hard time understanding why we need daemons to handle our
filesystems. Can you give me a use case that /etc/fstab is
insufficient for solving?
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJVvxa+AAoJEAEkDpRQOeFwGWUQAKCnuRLHYmUikYu+u0+1Tkck
eFmzW7C/G+Tbm5vqkRwk0F781gIPbpV36QOdIoTfBB65HJ9155VnsISXmQskf1+7
HN2guLTBrtOttZXOyF4KU7klGwElYTmD6tjMmH7aTxy6ID3lMKNtWDlktNgxPcH8
lfYsmB2DJ3+pxdMpPLCg0tGcR+s2RjNKJUnbXNGXO3vzO7PH/gPG9KkqtlVI/78I
Xf1m1e/MCEpRU8c2GCRzDuUkznUp3OMoXysMo3a/1c7NYx+KZ9CIlFZXiOX8CKJ5
hVf1xE0g8spRnH5Bq/EXO0mMhdWLB82ax4mD+jXdMR7H1i8SHjHGqQwQlKRFGIyg
UFfFcgz1GswGGar/AjkKz02FuiMYgJ7kU2nRHBlNsfjnjsdc8iIxPGhcCMWYZjuD
kLE/c6487ymQTMMYlIZ/qG7/90k57/TXZq0AuBPCB4/HD2vHMJBcYQkoWlnQSGEC
oYrVEvb9N1eKYe7/IpxnKVGKTZY1OP+xtDGvpPwp1MtE0GZ9VQbhS1+aJy6nVrs1
Uxx6/H7RTFwD5Af4V6mNe20ucz5mkEJxX9qTsNMrDAu+DHFUC3CTtYmeRN9Fsbve
ibHsIh1N0mI0bOvN16VK2s/ToahnsP09WvkJpnMIyJSfs4qWfpOhTWN8JEMWEdo2
j7V+HGJZ2GNYm3K0hFJI
=YuTA
-END PGP SIGNATURE-
[gentoo-dev] Last rites: sys-apps/systemd-ui
Resending due to broken Reply-To. # Mike Gilbert flop...@gentoo.org (03 Aug 2015) # Unmaintained upstream. Fails to build. Removal in 30 days. # Bugs: 478174, 546192, 556200. sys-apps/systemd-ui
[gentoo-portage-dev] [PATCH] circular_dependency_handler: limit USE combination search (bug 555698)
Limit the number of USE combinations searched to 1024 = 2 ** 10, where 10 is a constant named MAX_AFFECTING_USE, in order to avoid consuming unreasonable amounts of time. First, discard irrelevent flags that are not enabled. Since extract_affecting_use doesn't distinguish between positive and negative effects (flag? vs. combinations, then don't bother to explore any of them. X-Gentoo-Bug: 555698 X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=555698 --- pym/_emerge/resolver/circular_dependency.py | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/pym/_emerge/resolver/circular_dependency.py b/pym/_emerge/resolver/circular_dependency.py index b710671..5c11956 100644 --- a/pym/_emerge/resolver/circular_dependency.py +++ b/pym/_emerge/resolver/circular_dependency.py @@ -14,7 +14,9 @@ from _emerge.DepPrioritySatisfiedRange import DepPrioritySatisfiedRange from _emerge.Package import Package class circular_dependency_handler(object): - + + MAX_AFFECTING_USE = 10 + def __init__(self, depgraph, graph): self.depgraph = depgraph self.graph = graph @@ -156,7 +158,7 @@ class circular_dependency_handler(object): total_flags = set() total_flags.update(affecting_use, required_use_flags) total_flags.difference_update(untouchable_flags) - if len(total_flags) = 10: + if len(total_flags) = self.MAX_AFFECTING_USE: affecting_use = total_flags affecting_use = tuple(affecting_use) @@ -164,6 +166,21 @@ class circular_dependency_handler(object): if not affecting_use: continue + if len(affecting_use) self.MAX_AFFECTING_USE: + # Limit the number of combinations explored (bug #555698). + # First, discard irrelevent flags that are not enabled. + # Since extract_affecting_use doesn't distinguish between + # positive and negative effects (flag? vs. !flag?), assume + # a positive relationship. + current_use = self.depgraph._pkg_use_enabled(parent) + affecting_use = tuple(flag for flag in affecting_use + if flag in current_use) + + if len(affecting_use) self.MAX_AFFECTING_USE: + # There are too many USE combinations to explore in + # a reasonable amount of time. + continue + #We iterate over all possible settings of these use flags and gather #a set of possible changes #TODO: Use the information encoded in REQUIRED_USE -- 2.3.6
[gentoo-dev] Re: rfc: openrc mount service prototype
Brian Dolbec posted on Mon, 03 Aug 2015 00:59:07 -0700 as excerpted: On Mon, 3 Aug 2015 00:47:24 -0700 Brian Dolbec dol...@gentoo.org wrote: On Mon, 3 Aug 2015 00:22:42 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: I'm having a hard time understanding why we need daemons to handle our filesystems. Can you give me a use case that /etc/fstab is insufficient for solving? It is about defining proper dependencies and not blindly returning a success result when there were actual failures to start some files systems. So in some ways it is a bugfix. But it is actually a re-design which will overcome shortcomings/limitations in the fstab, netmount, localmount designs. For the average joe user that only has a few fstab entries, /boot, /root,/home. swap... It won't mean much if anything other than an un-needed change. Since it works for them. But for a systems administrator configuring servers with virtual machines, services depending on certain or multiple filesystems being up, etc... It can mean a BIG difference. It is the more complicated systems that are hitting the limitations of the current fstab system. not the simple user with a standard/basic handbook install. [TL;DR folks, skip to last paragraph.] Any time there's nested mounts, say /var/log on /var, on /, or /usr/local on /usr, on /, there's dependency issues that the current openrc localmount and netmount services don't deal with explicitly. If it happens to work, great, but sometimes it doesn't. Back on openrc, I used to have this problem with some custom bindmounts I did for a chrooted service. They were nested mounts, bind-mounting something that itself was on a separate filesystem, and openrc's localmount just doesn't deal well with that sort of thing, so I had to roll my own latelocalmount service, with the mounts marked noauto so localmount didn't try to mount them before their source filesystems were mounted, then explicitly mounted by name, in the latemount service. If I'd have had multiple layers of nesting, I would have needed multiple layers of mounting services. That gets to be a nightmare pretty quickly, all because openrc's existing mount services handle things en-mass, there's no way to explicitly specify dependencies of one mount on others, either at the mount level, or with the service, since individual mount services don't exist, only the en-mass localmount and netmount services. It was and remains a mess. To my very pleasant surprise, when I switched to systemd, most of those mounts just worked, because systemd uses an internally multiplexed individual mount approach instead of the en-mass approach openrc currently uses, and systemd automatically calculates dependencies. The one that systemd did NOT handle correctly by default was because it was a symlink, and apparently systemd's automated dependency handling doesn't deal with symlinks. (Not that I can blame it, symlinks can go circular or dangling, and the calculations get complex pretty quickly. But it handles the non-symlink cases _surprisingly_ well!) And that one had a simple fix, adding a single line to the service unit depending on that mount (it was an early-boot service so had the default deps of all mounts done turned off, but still would have detected the need for the mount based on path, if it was a straight path, not symlinked), making explicit the mount dependency so systemd could follow the dependency logic and would ensure that mount was completed before trying to start the service that depended on it. Long story short, systemd has upped the expectancy by handling these things automatically in most cases and making it very simple to add explicit mount deps where systemd's automatic handling fails, so other init systems must either match that expectancy now too, or fall further behind. The expectations have changed, and forcing the admin to jump thru a series of complex hack hoops to get nested mounts, etc, working, simply doesn't cut it any more. -- 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] useflag policies
On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... regards MM
Re: [gentoo-portage-dev] [PATCH] circular_dependency_handler: limit USE combination search (bug 555698)
On Mon, 3 Aug 2015 10:45:24 -0700 Zac Medico zmed...@gentoo.org wrote: Limit the number of USE combinations searched to 1024 = 2 ** 10, where 10 is a constant named MAX_AFFECTING_USE, in order to avoid consuming unreasonable amounts of time. First, discard irrelevent flags that are not enabled. Since extract_affecting_use doesn't distinguish between positive and negative effects (flag? vs. combinations, then don't bother to explore any of them. X-Gentoo-Bug: 555698 X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=555698 --- That's better, thanks looks good -- Brian Dolbec dolsen
[gentoo-dev] Last rites: sys-apps/systemd-ui
# Mike Gilbert flop...@gentoo.org (03 Aug 2015) # Unmaintained upstream. Fails to build. Removal in 30 days. # Bugs: 478174, 546192, 556200. sys-apps/systemd-ui
Re: [gentoo-dev] Re: useflag policies
On Mon, 3 Aug 2015 21:23:37 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 03/08/15 07:14, NP-Hardass wrote: ^^ has the pleasant side effect of being easier to read, as a user. The user receives a message saying at-most-one-of instead of some convoluted other expression that they don't understand. I am all for the use of ^^ add the default for this reason. This introduces a usability nightmare for anyone with both qt4 and qt5 in their global USE flags (a common configuration). What if we had something like this? REQUIRED_IUSE=^^qt ( qt5 qt4 ) Users who don't care would set just qt rather than qt4 or qt5 and this mechanism would automatically enable whichever one appears first in the brackets. If qt4 or qt5 (or both) are set then the behaviour would remain as it is now. Or perhaps some variation on this? I'm not declaring this to be a great idea, just throwing it out there for consideration. :) -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: useflag policies
Michael Palimaka wrote: On 03/08/15 07:14, NP-Hardass wrote: ^^ has the pleasant side effect of being easier to read, as a user. The user receives a message saying at-most-one-of instead of some convoluted other expression that they don't understand. I am all for the use of ^^ add the default for this reason. This introduces a usability nightmare for anyone with both qt4 and qt5 in their global USE flags (a common configuration). As a Gentoo user. This is what I have set and what I hope to get because of the settings. I have both qt4 and qt5 set in make.conf for my USE flags. I expect qt5 for whatever packages can work with qt5 and qt4 for whatever isn't ready for qt5 but requires qt. If for some reason a package isn't quite ready for qt5 and won't function correctly for me, I can always set that in package.use until it is. My current entries for this: media-libs/phonon-vlc qt5 media-video/mkvtoolnix -qt5 I don't have notes on that so not sure what was ran into to require those. I may comment those out and give them another try. Point of this post, provide a little user info about expectations and settings. Y'all sort out the best way forward and let us know if we need to change something. :-) Dale :-) :-)
Re: [gentoo-dev] Re: useflag policies
On 03/08/2015 15:07, Dale wrote: Michael Palimaka wrote: On 03/08/15 07:14, NP-Hardass wrote: ^^ has the pleasant side effect of being easier to read, as a user. The user receives a message saying at-most-one-of instead of some convoluted other expression that they don't understand. I am all for the use of ^^ add the default for this reason. This introduces a usability nightmare for anyone with both qt4 and qt5 in their global USE flags (a common configuration). As a Gentoo user. This is what I have set and what I hope to get because of the settings. I have both qt4 and qt5 set in make.conf for my USE flags. I expect qt5 for whatever packages can work with qt5 and qt4 for whatever isn't ready for qt5 but requires qt. If for some reason a package isn't quite ready for qt5 and won't function correctly for me, I can always set that in package.use until it is. My current entries for this: media-libs/phonon-vlc qt5 media-video/mkvtoolnix -qt5 I don't have notes on that so not sure what was ran into to require those. I may comment those out and give them another try. Point of this post, provide a little user info about expectations and settings. Y'all sort out the best way forward and let us know if we need to change something. :-) Dale and I think alike. I also have Qt4 and Qt5 installed, and I expect packages that use them to link to the version that works better (understanding that better is usually the opinion of upstream and the devs). If I decide I care about which one works better for a given package, then I'm happy to package.use but mostly I like that file to be as empty as I can get it. What I don't want is for the machinery to give the impression that I can't just go with whatever the dev put in the ebuild for the general case. I also don't want to have to keep going back to use.desc because it's not obvious what the flag probably does. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] useflag policies
Maciej Mrozowski wrote: On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... regards MM You may lose that one if I'm seeing your point correctly. See Alan and my earlier replies. I have both qt4 and qt5 set and I leave which is best to use to the devs to control in the ebuild. If for example qt5 does not work well for a package, let the ebuild pick qt4 for that package. If qt5 works reliably, then build with qt5. If I have a problem with it, then I can set it in package.use if needed, doesn't build or function correctly or I want qt5 even if it isn't stable. As things switch to qt5 more, I don't have to do anything except let the updates roll out as they become stable and the dev sets that in the ebuild. Keep in mind, devs already do a LOT of the selection process. Otherwise, we could set any and every USE flag and package combination there is without any restrictions. In other words, we could have USE flag soup even if it is known that two or more USE flags clash. As it is, if a dev knows two flags clash, we get a nifty error message and then we get to figure out how to get it to work right, sometimes portage's error message is cryptic to say the least. If I took your point wrong, my apologies. Lowly user. Dale :-) :-)
Re: [gentoo-dev] useflag policies
On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski reave...@gmail.com wrote: On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... Obviously there are many reasons people use Gentoo, but here is my perspective on this. The value of Gentoo is that it gives you a LOT of power to tweak individual package configurations, without the requirement to do this for everything. There are packages that I carefully configure USE flags for, CFLAGS for, epatch_user, and so on. Heck, some packages I run in containers where I can carefully control almost all aspects of their environment. Then on the same host I'll have screen and bash and a million other packages installed where exact configuration is not critical, and so I want it to just work. If I wanted to micromanage everything I might as well run Linux From Scratch. Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. -- Rich
