[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Gregory M. Turner posted on Mon, 10 Sep 2012 20:29:53 -0700 as excerpted: > However, IIRC, /etc/make.conf is just ignored by portage if > /etc/portage/make.conf is present, so symlinking, or even better, if > possible, hardlinking those files would probably "do the right thing" > for legacy tools that don't know about the new location... unless I'm > mistaken, which is always plausible :) Thanks. Reasonable approach and good to know. (I actually just did a sync. I should go adjust the location before I try to build anything, and start my own tests instead of debating what /could/ happen. Excuse me... =:^) -- 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: News item 1: changes to stages (make.conf and make.profile)
On 9/9/2012 6:34 PM, Zac Medico wrote:
On 09/09/2012 05:59 PM, Duncan wrote:
To your knowlege (IOW have you tested) having /etc/make.conf either a
symlink to /etc/portage/make.conf or a simple one-line
"source /etc/portage/make.conf"?
I've tested them both just now, and they work for me. Why wouldn't they?
If both /etc/portage/make.conf and /etc/make.conf were evaluated, stuff like
FOO="${FOO} bar"
could cause, i.e., duplications... not sure what all the rules are
limiting what one can and can't put in make.conf, but one could imagine
all kinds of wacky stuff.
However, IIRC, /etc/make.conf is just ignored by portage if
/etc/portage/make.conf is present, so symlinking, or even better, if
possible, hardlinking those files would probably "do the right thing"
for legacy tools that don't know about the new location... unless I'm
mistaken, which is always plausible :)
-gmt
Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote: > Is there anything in particular in the spec/proposal for DEPENDENCIES > that would exclude the addition of individual "build: app-cat/myatom" > "run: app-cat/myatom" deps by an eclass or eclasses? I know the > "goal" here is to make things atom-centric, but I can't see an > implementation ever working of this that wouldn't permit the "pile-on" > of additional entries of different (or even the same) roles on > identical or near-identical atoms. They could be piled on; it would require each eclass to reset the label for safety reasons though; same goes for ebuilds frankly (or the PM would have to reset the context to build+run: each time through). Pardon if addressed elsewhere; this thread is a fucking mess... ~harring
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, Sep 10, 2012 at 02:47:48PM -0700, Christopher Head wrote: > As a user… yes? I use a laptop, so I don’t much care which one is > maintained but I’d be quite annoyed if both went away (unless there’s > some other dæmon that does the same job that I’ve never heard of). I am thinking that we will probably stop supporting netplugd if we stop supporting one. ifplugd seems to have much more functionality. William pgpjItdziXbcc.pgp Description: PGP signature
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, 10 Sep 2012 09:48:32 -0500 William Hubbs wrote: > Does anyone have any thoughts about whether we should keep OpenRC > support for one or both of these? As a user… yes? I use a laptop, so I don’t much care which one is maintained but I’d be quite annoyed if both went away (unless there’s some other dæmon that does the same job that I’ve never heard of). Side note… we’re talking about a pretty tiny program here. Is “upstream unmaintained” actually really a big deal? I mean, if ifplugd has worked without bugs for the last seven years then it doesn’t really matter that it’s unmaintained, does it? All the bugs on ifplugd in BGO appear to be mostly a pile of stuff related to the scripts around it, plus #214842 which appears to have been the kernel’s fault and #171415 which was a minor QA issue. Chris
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: > On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > > In researching this program, I have found that it and ifplugd, which is > > the alternative, have been unmaintained for years. Also Debian has > > declared netplugd to be obsolete in favor of ifplugd. > > > > Does anyone have any thoughts about whether we should keep OpenRC > > support for one or both of these? > > The ifplugd author recommends you use NetworkManager for dynamic > networking scenarios. NM seems bloated though unless you are using a desktop environment. It wants to install 29 dependencies on my box. Williiam pgp4HY3UhYSDZ.pgp Description: PGP signature
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > In researching this program, I have found that it and ifplugd, which is > the alternative, have been unmaintained for years. Also Debian has > declared netplugd to be obsolete in favor of ifplugd. > > Does anyone have any thoughts about whether we should keep OpenRC > support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On 10 September 2012 15:48, William Hubbs wrote: > All, > > I have a regression in OpenRc wrt netplugd [1]. > > In researching this program, I have found that it and ifplugd, which is > the alternative, have been unmaintained for years. Also Debian has > declared netplugd to be obsolete in favor of ifplugd. The page referenced on the bug that says so appears to be talking about a different package than the one we have in the tree - they have different authors stated, and also, for the one we have the package is called netplug, with the executable called netplugd, whereas for the one declared obsolete the package itself is called netplugd. > Does anyone have any thoughts about whether we should keep OpenRC > support for one or both of these? There are a few options for this functionality (that I'm aware of): 1) netplug: never used it so no particular comments. 2) ifplugd: what I'm using now. I can't remember if there's a particularly good reason why I chose it, but I suspect it might have been for the audio feedback it provides when it detects a connection or disconnection. This probably isn't compelling enough by itself to keep the package if we'd otherwise want to remove it, but it is quite nice. 3) wpa_supplicant: supposed to be able to do this even for wired interfaces, but I just did some experimenting and it seems broken - it thinks the cable is plugged in even when it isn't. 4) dhcpcd: not sure when it was introduced, but current dhcpcd can detect when the link goes up and down, and request/renew its lease when it comes up. The only wrinkle that I can see here is that, if no ifplugd/netplug/wpa_supplicant is configured, OpenRC waits for it to receive a lease when starting the interface, rather than allowing it to background itself. So for dhcpcd, it might be enough to just make OpenRC aware that it doesn't need to wait for a lease when starting the interface. Keeping at least one of the other options working would still be required for other DHCP clients if they don't have similar functionality, or non-DHCP situations where it's necessary to do some sort of reconfiguration when the network is (dis)connected (such as OpenRC's arping module), assuming anyone cares about those of course. > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=427088
[gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
All, I have a regression in OpenRc wrt netplugd [1]. In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? Thanks, William [1] https://bugs.gentoo.org/show_bug.cgi?id=427088 pgp9BGzMX2zPI.pgp Description: PGP signature
Re: [gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
On 09/10/2012 03:55 AM, Doug Goldstein wrote: > Hey all, > > Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to > app-emulation/qemu at some point this week. The app-emulation/qemu > ebuilds will effectively die and be replaced by the > app-emulation/qemu-kvm ebuilds. I've brought this up before and there > was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The > fact of the matter is that the app-emulation/qemu just isn't getting > the same maintenance care that app-emulation/qemu-kvm is. I've really > only got the bandwidth to handle one at a time. Additionally this will > bring us inline with a few other distros use of qemu as they're really > building their binaries from qemu-kvm. I mostly care for the qemu-user variant (and lately I had been otherwise busy). I like the idea of keeping a single ebuild for the system emulation though. lu
Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)
On 10-09-2012 10:28:26 +0100, Ciaran McCreesh wrote: > On Mon, 10 Sep 2012 11:25:05 +0200 > Fabian Groffen wrote: > > On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote: > > > So really we should just not support prefix at all in any EAPI > > > before 5, and not have the whole "but define those prefix variables > > > anyway" hack in eclasses. But apparently people are preferring to > > > go to great lengths not to have to use newer EAPIs... > > > > I think the problem is that this vision doesn't really give a > > migration path, even when people are willing to move on to EAPI 5. > > It gives you a marvellous opportunity to get the tree using newer EAPIs > as you prefixify things. You ignore the current state of affairs, IMO. > > Personally, this vision doesn't really encourage me to push any > > changes for this, since Portage seems to handle it well. > > No, it really doesn't. Portage's error checking just isn't good enough > yet that you notice the breakage. "Appears to work for some subset > of inputs if you don't look too closely" is not "works". This really deviates from getting us to a solution. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)
On Mon, 10 Sep 2012 11:25:05 +0200 Fabian Groffen wrote: > On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote: > > So really we should just not support prefix at all in any EAPI > > before 5, and not have the whole "but define those prefix variables > > anyway" hack in eclasses. But apparently people are preferring to > > go to great lengths not to have to use newer EAPIs... > > I think the problem is that this vision doesn't really give a > migration path, even when people are willing to move on to EAPI 5. It gives you a marvellous opportunity to get the tree using newer EAPIs as you prefixify things. > Personally, this vision doesn't really encourage me to push any > changes for this, since Portage seems to handle it well. No, it really doesn't. Portage's error checking just isn't good enough yet that you notice the breakage. "Appears to work for some subset of inputs if you don't look too closely" is not "works". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)
On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote: > So really we should just not support prefix at all in any EAPI before > 5, and not have the whole "but define those prefix variables anyway" > hack in eclasses. But apparently people are preferring to go to great > lengths not to have to use newer EAPIs... I think the problem is that this vision doesn't really give a migration path, even when people are willing to move on to EAPI 5. Personally, this vision doesn't really encourage me to push any changes for this, since Portage seems to handle it well. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)
On Mon, 10 Sep 2012 10:18:56 +0200 Fabian Groffen wrote: > Normally, if you use a USE-flag, you add them to IUSE of the ebuild. > However, some USE-flags have been considered too general to put them > in there in the past. That's not exactly why. Historically (as in, way before EAPI days) IUSE was purely a visual thing: it was used for emerge -pv output, but not anything affecting behaviour. Thus, people didn't list things that weren't worth showing to the user. That all went out of the window when we got package.use, new-use support, etc. At that point, IUSE had to be fairly accurate. It became even more important when we introduced use dependencies and use dependency defaults. Not having an accurate IUSE means that dependencies like cat/pkg[prefix(-)] can't work. This is why the original EAPI 3 tidied all this up properly. Unfortunately, due to EAPI 3 becoming EAPI 4 and having some features removed, use dependency defaults ended up being "supported" without having the necessary information to make them work correctly in all cases, and prefix ended up being supported but without the "prefix" use flag being special. So really we should just not support prefix at all in any EAPI before 5, and not have the whole "but define those prefix variables anyway" hack in eclasses. But apparently people are preferring to go to great lengths not to have to use newer EAPIs... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)
On 07-09-2012 16:38:15 -0700, Gregory M. Turner wrote: > On 9/7/2012 10:32 AM, Fabian Groffen wrote: > > With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase > > has been added to PMS, that finally makes a statement on what's supposed > > to be in IUSE, and what not[2]. To me, this patch means that things like > > userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an > > ebuild/eclass (and hence should be removed). 'prefix', on the other > > hand, should be added to IUSE of those ebuilds/eclasses that use them. > > What, exactly, is the difference -- the principle behind the "should"s > above? USE_EXPAND? Probably more a problem of me being lazy than > anything being wrong with it, but [2] reads like Greek to me. USE_EXPAND - yes. > > For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be > > enriched with IMPLICIT_IUSE="prefix". > > > > For all currently Council approved EAPIs this means 'prefix' has to be > > added to IUSE. > > I haven't looked into IMPLICIT_IUSE too carefully, but ... shouldn't > this be... implicit? Sorry, I'm being super lazy and not reading > anything here. The idea here is that the package manager knows in advance which USE-flags are valid for the ebuild. I called that 'defined' lateron in this mail. Normally, if you use a USE-flag, you add them to IUSE of the ebuild. However, some USE-flags have been considered too general to put them in there in the past. Most of those are arch-related, keyword, userland_*, etc. IMPLICIT_IUSE is meant to accomodate this case for ordinary USE-flags, like 'prefix'. That is, a USE-flag added to IMPLICIT_IUSE is always there, and hence no need to add it to IUSE of the ebuild. This only works for EAPI 5 (assuming it gets accepted), though. > > In case you wonder why this is a problem now, Portage/repoman has a rule > > that USE-flags that are masked in the profiles implicitly are defined. > > Probably making a total ass of myself at this point but... could you > define "defined"? I'm guessing I'd understand how to get flags masked > implicitly if I read the IMPLICIT_IUSE stuff? Or do you mean "are > defined implicitly" (in which case, again, I don't see why we'd need to > make them explicit). There is probably different wording for this, but what I meant was that ebuilds can only use USE-flags that are defined to be used by the ebuild. The latter is done through listing it in IUSE in the ebuild. > > [2] > > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d053bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e12c2f906 > > Apologies for these questions -- in my defense, being both lazy and > ignorant puts me at a real disadvantage here :) The real question here is if the dev community agrees on adding 'prefix' conditionally to IUSE in many eclasses and ebuilds. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
On Sun, 9 Sep 2012 20:55:58 -0500 Doug Goldstein wrote: > Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to > app-emulation/qemu at some point this week. Package moves shouldn't be used to move a package over something that already exists. You should just package.mask and later remove. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
Doug Goldstein schrieb: > Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to > app-emulation/qemu at some point this week. The app-emulation/qemu > ebuilds will effectively die and be replaced by the > app-emulation/qemu-kvm ebuilds. I've brought this up before and there > was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The > fact of the matter is that the app-emulation/qemu just isn't getting > the same maintenance care that app-emulation/qemu-kvm is. I've really > only got the bandwidth to handle one at a time. Additionally this will > bring us inline with a few other distros use of qemu as they're really > building their binaries from qemu-kvm. Is such a takeover really necessary? If there is no maintainer for app-emulation/qemu and it is broken, lastrite it. That other distros pretend to install qemu while actually installing qemu-kvm doesn't make it the Right Thing™. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] RFC: intel-sdp.eclass (new eclass to handle intels compiler suites and libraries)
Hi all,
please give comments on the attached eclass.
The purpose of the eclass is
* handle the suite bundle and its single rpms
* simplify ebuilds
* a clean and easy way to unpack what is needs to be install
Thanks,
justin
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: intel-sdp.eclass
# @MAINTAINER:
# Sébastien Fabbro
# Justin Lecher
# Sci Team
# @BLURB: Handling of Intel's Software Development Products package management
# @ECLASS-VARIABLE: INTEL_DID
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download ID from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2504
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPN
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package name to download from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. parallel_studio_xe
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPV
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download version from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2011_sp1_update2
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_SUBDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package sub-directory where it will end-up in /opt/intel
# To find out its value, you have to do a raw install from the Intel tar ball
# @ECLASS-VARIABLE: INTEL_RPMS_DIRS
# @DESCRIPTION:
# List of subdirectories in the main archive which contains the
# rpms to extract.
: ${INTEL_RPMS_DIRS:=rpm}
# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
# 32bit arch in rpm names
#
# e.g. i484
: ${INTEL_X86:=i486}
# @ECLASS-VARIABLE: INTEL_BIN_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm without any version/arch tag
#
# e.g. compilerprof
# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm of common data which are arch free
# without any version tag
#
# e.g. openmp
inherit check-reqs multilib versionator
_INTEL_PV1=$(get_version_component_range 1)
_INTEL_PV2=$(get_version_component_range 2)
_INTEL_PV3=$(get_version_component_range 3)
_INTEL_PV4=$(get_version_component_range 4)
_INTEL_URI="http://registrationcenter-download.intel.com/irc_nas/${INTEL_DID}/${INTEL_DPN}";
SRC_URI="
amd64? ( multilib? ( ${_INTEL_URI}_${INTEL_DPV}.tgz ) )
amd64? ( !multilib? ( ${_INTEL_URI}_${INTEL_DPV}_intel64.tgz ) )
x86? ( ${_INTEL_URI}_${INTEL_DPV}_ia32.tgz )"
LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"
IUSE="multilib"
KEYWORDS="-* ~amd64 ~x86"
RESTRICT="mirror"
RDEPEND=""
DEPEND=">=app-arch/rpm2targz-9.0.0.3g"
_INTEL_SDP_YEAR=${INTEL_DPV%_update*}
_INTEL_SDP_YEAR=${INTEL_DPV%_sp*}
# @ECLASS-VARIABLE: INTEL_SDP_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rootless path to installation dir
INTEL_SDP_DIR="opt/intel/${INTEL_SUBDIR}-${_INTEL_SDP_YEAR:-${_INTEL_PV1}}.${_INTEL_PV3}.${_INTEL_PV4}"
# @ECLASS-VARIABLE: INTEL_SDP_EDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rooted path to installation dir
INTEL_SDP_EDIR="${EROOT%/}/${INTEL_SDP_DIR}"
S="${WORKDIR}"
QA_PREBUILT="${INTEL_SDP_DIR}/*"
intel-sdp_pkg_pretend() {
: ${CHECKREQS_DISK_BUILD:=256M}
check-reqs_pkg_pretend
}
# @ECLASS-VARIABLE: INTEL_ARCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# Intels internal names of the arches; will be set at runtime accordingly
#
# e.g. amd64-multilib -> INTEL_ARCH="intel64 ia32"
intel-sdp_pkg_setup() {
local arch a p
if use x86; then
arch=${INTEL_X86}
INTEL_ARCH="ia32"
elif use amd64; then
arch=x86_64
INTEL_ARCH="intel64"
if has_multilib_profile; then
arch="x86_64 ${INTEL_X86}"
INTEL_ARCH="intel64 ia32"
fi
fi
INTEL_RPMS=""
for p in ${INTEL_BIN_RPMS}; do
for a in ${arch}; do
INTEL_RPMS="${INTEL_RPMS}
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.${a}.rpm"
done
done
for p in ${INTEL_DAT_RPMS}; do
INTEL_RPMS="${INTEL_RPMS}
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.noarch.rpm"
done
case "${EAPI:-0}" in
0|1|2|3) intel-sdp_pkg_pretend ;;
esac
}
intel-sdp_src_unpack() {
local l r t rpmdir
for t in ${A}; do
for r in ${INTEL_RPMS}; do
# Find which subdirectory of the archive the rpm is in
rpm_found="false"
for subdir in ${INTEL_RPMS_DIRS}; do
[[ "${rpm_found}" ==
Re: [gentoo-dev] Perl: please don't delete packlists
On Mon, 10 Sep 2012 17:22:14 +1200 Kent Fredric wrote: > On 9 September 2012 15:53, Matthias Bethke > wrote: > > I think Gentoo of all distributions should aim to provide software > > as "original" as possible. If there are any reasons that I have > > ignored so far why people would want the current behavior, how > > about I make this patch conditional on a new use flag? > > I'd suggest not a USE flag, at least, not at present, it would > needlessly require all ebuilds to have that useflag, which would be a > significant noise to users. > > I'd rather a documented( in the eclass ) ENV variable that could > toggle this behaviour that was /not/ a use-flag, so only people who > cared about that sort of behaviour could adjust it. > > Then the question is only really as to what a "Sane default" is. Seems > the sane default is to install packlists, but have it being > disable-able by ENV change for the people who have the tuits to know > "I'll never need those, and if I do, I can handle the need to rebuild > everything with them". I think the relevant env variable is called INSTALL_MASK then ;). -- Best regards, Michał Górny signature.asc Description: PGP signature
