On Fri, Aug 17, 2012 at 11:38 PM, Mike Frysinger wrote:
people seem to be settling on x86_64-pc-linux-gnux32 as the default tuple, so
i'll be updating our profiles to use that by default. this shouldn't impact
anyone already running x32 as the existing tuple/ABI settings should continue
On Thu, Aug 30, 2012 at 3:41 AM, Michał Górny wrote:
On Wed, 29 Aug 2012 19:12:01 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
does it actually ? are DEPEND variables not allowed to be
expanded
On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
On Wed, 29 Aug
On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
In other words, pkg-config is only used when no other criteria allows
it to classify the particular .la file as suitable for removal or not.
Sadly, it's rather, ehm, unfriendly to ebuild developers who obviously
don't even read the relevant
On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
In other words, pkg-config is only used when no other criteria
allows it to classify the particular .la file as suitable
On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
In other words
On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
does it actually ? are DEPEND variables not allowed to be expanded in
pkg_* src_* funcs ?
Nope. We don't guarantee that the metadata variable gets exported back
to the ebuild
On Sunday 19 August 2012 04:41:17 Luca Barbato wrote:
On 8/18/12 5:31 AM, Mike Frysinger wrote:
i'll probably land it later this weekend/monday.
Would be nice having a list of bugs open so people might have a look and
see if there is something big left.
we've been making trackers
On Saturday 18 August 2012 02:01:12 Diego Elio Pettenò wrote:
On Fri, Aug 17, 2012 at 10:44 PM, Mike Frysinger vap...@gentoo.org wrote:
there's a trivial patch needed to make 1.49 work. forcing people to use
1.50 is purely the boost's maintainers choice.
[...]
there's a trivial patch
On Saturday 18 August 2012 03:21:20 Michał Górny wrote:
On Fri, 17 Aug 2012 23:25:10 -0400 Mike Frysinger wrote:
On Thursday 16 August 2012 16:19:44 Michał Górny wrote:
--- a/eutils.eclass
+++ b/eutils.eclass
+# Install all specified files into directory. This doesn't
modify
*yawn* such a drama queen.
i never said i am going to do this everyone else be damned. i did say i
will probably do this soon. but that is why i posted to gentoo-dev in the
first place -- to get feedback from others.
gnutls breakage: not relevant. you're causing that breakage by not adding
On Monday 06 August 2012 15:45:46 Kent Fredric wrote:
Looking at the source of eutils.eclass ' # Let people filter things
dynamically ' suggests to me that this field is for use by a end user
via package.env and friends.
no, it is meant for packagers to have a single patch tarball, setup
On Tuesday 14 August 2012 17:59:40 Zac Medico wrote:
That just means that somebody made a mistake. They should have put the
EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
about the correct place to put the EXPORT_FUNCTIONS call, and that
problem is solved.
sounds
On Tuesday 14 August 2012 16:39:57 Michał Górny wrote:
On Tue, 14 Aug 2012 12:46:30 -0700 Zac Medico wrote:
On 08/14/2012 02:44 AM, Michał Górny wrote:
As some of you may have noticed, lately introduced 'double include
preventions' have caused changes in effective phase functions in a
On Thursday 16 August 2012 16:19:44 Michał Górny wrote:
--- a/eutils.eclass
+++ b/eutils.eclass
+# Install all specified files into directory. This doesn't modify global
+# 'insinto' path. Alike doins, calls 'die' on failure in EAPI 4+; in earlier
+# EAPIs, returns false in that case.
i
with glibc-2.15 gone stable, it's time to get 2.16 in the pipe. the big
issues have been sorted out already. there's a few packages still known to
build fail, but they've had quite some time to sort their stuff out, so i don't
see delaying further making a difference there. if anything,
people seem to be settling on x86_64-pc-linux-gnux32 as the default tuple, so
i'll be updating our profiles to use that by default. this shouldn't impact
anyone already running x32 as the existing tuple/ABI settings should continue
to work just fine (no plans to ever change that).
-mike
On Tuesday 14 August 2012 13:37:25 Alexis Ballier wrote:
it breaks on _pie_ executables, which are not that common if you dont
run hardened.
every Gentoo system has PIEs on it. not many, but some.
file /*bin/* /usr/*bin/* | grep shared.object
(i wonder why cups is building itself as PIE
On Saturday 18 August 2012 01:16:29 Diego Elio Pettenò wrote:
- everything depending on boost (current 1.49 won't work, you need
1.50, and quite a few things break with 1.50);
there's a trivial patch needed to make 1.49 work. forcing people to use 1.50
is purely the boost's maintainers
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
bin/egencache |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/egencache b/bin/egencache
index a75a341..d0c073c 100755
--- a/bin/egencache
+++ b/bin/egencache
@@ -102,7 +102,7 @@ def parse_args(args
On Friday 27 July 2012 08:13:16 Chí-Thanh Christopher Nguyễn wrote:
Ulrich Mueller schrieb:
As I had pointed out before [1], changing from POSIX to an en_US
locale will have undesirable side effects, like commas as thousands
separators in numbers (because of LC_NUMERIC). Also the defaults
On Wednesday 18 July 2012 12:18:35 Andreas K. Huettel wrote:
On Wed, Jul 18, 2012 at 5:33 PM, hasufell hasuf...@gentoo.org wrote:
epatch is so widely used and basic that I wonder why it's still not
implemented as a real helper function.
Because then its harder to change, it must be in
On Wednesday 18 July 2012 13:29:41 Ciaran McCreesh wrote:
On Wed, 18 Jul 2012 18:18:35 +0200 Andreas K. Huettel wrote:
On Wed, Jul 18, 2012 at 5:33 PM, hasufell hasuf...@gentoo.org
wrote:
epatch is so widely used and basic that I wonder why it's still
not implemented as a real
On Thursday 19 July 2012 02:57:09 Ulrich Mueller wrote:
On Wed, 18 Jul 2012, Ciaran McCreesh wrote:
Many eclasses (eutils being the most prominent example) contain:
DESCRIPTION=Based on the ${ECLASS} eclass
Is this of any use?
The reason that sort of thing is there is because in
On Wednesday 18 July 2012 13:53:37 Ulrich Mueller wrote:
Our current policy [1] requires that ebuilds must assign the seven
variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, and
IUSE, even if their value is empty.
Could we drop this requirement? Repoman already enforces that
On Wednesday 25 July 2012 12:38:05 Ulrich Mueller wrote:
On Wed, 25 Jul 2012, Mike Frysinger wrote:
Our current policy [1] requires that ebuilds must assign the seven
variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS,
and IUSE, even if their value is empty.
Could we
On Friday 06 July 2012 11:32:22 Ulrich Mueller wrote:
However, I remember that there used to be some problems with SHA256
and DSA keys. Before we add --digest-algo SHA256 to the default
PORTAGE_GPG_SIGNING_COMMAND in make.globals, I'd like to ask for
feedback if it works without problems.
a
On Wednesday 04 July 2012 21:36:02 Albert W. Hopkins wrote:
Might it be better if you could tell portage to look for kernel builds
in another location than /usr/src/linux. Perhaps you can already and I'm
not aware.
export KBUILD_OUTPUT=...
-mike
signature.asc
Description: This is a digitally
On Monday 02 July 2012 13:37:53 Richard Yao wrote:
On 07/02/2012 10:54 AM, Alexis Ballier wrote:
hu? yes, as already pointed out, uname is not reliable when
cross-compiling. You should use CHOST, and then you get tc-arch-kernel.
See freebsd-lib ebuild for how it is handled.
In that case,
On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
On 06/30/2012 04:07 AM, Pacho Ramos wrote:
I would like to discuss a bit more issues like:
https://bugs.gentoo.org/show_bug.cgi?id=423087
Even if there are a lot of packages that can cause this breakage when
downgraded, I think it
On Friday 29 June 2012 01:59:37 Mike Gilbert wrote:
On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger vap...@gentoo.org wrote:
On Monday 25 June 2012 00:15:59 Mike Gilbert wrote:
An official release of grub-2.00 should be coming pretty soon. I would
like to keyword this for ~amd64 and ~x86
On Thursday 28 June 2012 04:22:22 Naohiro Aota wrote:
Diego Elio Pettenò flamee...@gentoo.org writes:
I'm going to give up maintainership of a few packages simply because I'm
not using it any longer and thus I can't care about them as much as I
should:
dev-util/perf
I take this one.
On Tuesday 26 June 2012 00:04:35 Duncan wrote:
Mike Gilbert posted on Mon, 25 Jun 2012 23:13:09 -0400 as excerpted:
Profiles do not set a default bootloader so I have no idea what you
are talking about.
I could have sworn there was a virtual/bootloader or some such, that was
a part of
On Monday 25 June 2012 00:15:59 Mike Gilbert wrote:
An official release of grub-2.00 should be coming pretty soon. I would
like to keyword this for ~amd64 and ~x86 shortly after it hits the tree.
I don't do much work on base system packages, so I would like some
advice on how to make this as
On Sunday 24 June 2012 04:18:07 Ben de Groot wrote:
On 24 June 2012 02:32, Mike Frysinger vap...@gentoo.org wrote:
On Saturday 23 June 2012 13:37:59 Michael Palimaka wrote:
+for x in ${LANGS}; do
+ IUSE+= linguas_${x}
+done
if you don't want to make it into an array:
IUSE
On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote:
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
Multilib (and/or multiarch) support
Sorry for a possibly ignorant question. Does multilib support include
the ability to build Busybox against uclibc (on a glibc system)?
i'm not
On Wednesday 20 June 2012 16:25:30 Richard Yao wrote:
Multilib (and/or multiarch) support
Thomas already has multilib documents put together for review. multiarch
doesn't make sense for us, and even if it did, there's no way it'd be spec-ed
out in a reasonable time frame for EAPI=5 (or even 6
On Thursday 21 June 2012 08:11:27 Homer Parker wrote:
On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
In case you're not aware, the first time Gentoo did multilib, it was
done as a series of random changes to Portage that no-one really
thought through or understood. As you can
On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote:
In case you're not aware, the first time Gentoo did multilib, it was
done as a series of random changes to Portage that no-one really
thought through or understood. As you can see, that didn't work...
yes yes, it's very easy to throw
On Tuesday 19 June 2012 23:27:06 Samuli Suominen wrote:
On 06/20/2012 06:19 AM, Mike Frysinger wrote:
On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:
On 06/15/2012 06:10 PM, Mike Frysinger wrote:
On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
On 06/13/2012 06:02 AM, Mike
On Tuesday 19 June 2012 23:59:02 Mike Gilbert wrote:
On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger vap...@gentoo.org wrote:
On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
i've noticed a growing trend where people put setup
On Saturday 23 June 2012 13:37:59 Michael Palimaka wrote:
+for x in ${LANGS}; do
+ IUSE+= linguas_${x}
+done
if you don't want to make it into an array:
IUSE+= $(printf 'linguas_%s ' ${LANGS})
-mike
signature.asc
Description: This is a digitally signed message part.
On Wednesday 20 June 2012 11:56:58 viv...@gmail.com wrote:
Meeting with bug: #409471 suggested that some ebuilds could benefit from
expanding -march=native to the actual flags the compiler use.
i can't really see how. if packages can't handle certain flags, then fix
those.
so NAK on adding
On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:
On 06/15/2012 06:10 PM, Mike Frysinger wrote:
On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
On 06/13/2012 06:02 AM, Mike Frysinger wrote:
i've noticed a growing trend where people put setup of variables into
pkg_setup
On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't
have to call the respective src_* func
On Saturday 16 June 2012 08:12:13 Ulrich Mueller wrote:
On Sat, 16 Jun 2012, Pacho Ramos wrote:
I would like to know if there is some place where things going to be
included (or proposed to be included) for eapi5 are listed (if such
place exists). Currently, looks like there is no eapi5
On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
On 06/13/2012 06:02 AM, Mike Frysinger wrote:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have
to call the respective src_* func from
On Friday 15 June 2012 09:32:18 Michał Górny wrote:
# Remove static libs we're not supposed to link against.
if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary ${archivefile#${D%/}}
- rm -f ${archivefile}
On Friday 15 June 2012 12:52:56 Michał Górny wrote:
On Fri, 15 Jun 2012 11:11:58 -0400 wrote:
On Friday 15 June 2012 09:32:18 Michał Górny wrote:
# Remove static libs we're not supposed to link
against. if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo
On Friday 15 June 2012 12:54:16 Michał Górny wrote:
On Fri, 15 Jun 2012 11:11:44 -0400 Michael Orlitzky wrote:
On 06/15/12 09:32, Michał Górny wrote:
It is a little confusing when the function reports .a removal when
no such file exists. Also, explain why the file is removed.
Why
On Thursday 14 June 2012 21:16:31 Samuli Suominen wrote:
So how about renaming USE=gs consumers to USE=ps and making USE=ps
global flag with the proposed description?
merging is a good idea. getting away from ghostscript is good. i might
suggest expanding ps to postscript though as ps is a
On Wednesday 13 June 2012 14:32:22 Ian Stakenvicius wrote:
On 13/06/12 02:09 PM, Fabian Groffen wrote:
On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
Hey all - I'd like to propose that enewuser forces updates to a
user's home dir and shell whenever it is called, so that if this
On Wednesday 13 June 2012 15:11:19 Ian Stakenvicius wrote:
On 13/06/12 03:04 PM, Mike Frysinger wrote:
we have egetshell and egethome already. thus it's fairly easy to
detect the transition case. if they installed the older version
which set values that you now want to change
On Wednesday 13 June 2012 15:35:40 Ian Stakenvicius wrote:
--- user.eclass [some timestamp]
+++ user.eclass.esethome [some other timestamp]
@@ -388,3 +388,63 @@
}
fi
+
+# @FUNCTION: esethome
has to be inside the giant if block. so put this above the fi.
+# @USAGE: user
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have to
call the respective src_* func from an inherited eclass. unfortunately this
adds pointless overhead to binpkgs. can we please move away from this
On Tuesday 12 June 2012 13:55:45 Justin wrote:
these days still FFLAGS and FCFLAGS are unset by default.
Any objections to to default to CFLAGS of the profile equally to CXXFLAGS?
sounds fine
-mike
signature.asc
Description: This is a digitally signed message part.
On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote:
Calling use in global scope isn't allowed so what are you suggesting
they do instead?
as implied in the body of my message, put it into the relevant src_* func. in
this case, src_prepare.
-mike
signature.asc
Description: This is a
On Tuesday 12 June 2012 23:54:45 Mike Frysinger wrote:
On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote:
Calling use in global scope isn't allowed so what are you suggesting
they do instead?
as implied in the body of my message, put it into the relevant src_* func.
in this case
Automatically strip trailing newlines from the ChangeLog, and be
better about not adding them in the first place (still not perfect,
but getting there).
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
pym/portage/tests/repoman/test_echangelog.py |9 +
pym/repoman/utilities.py
On Thursday 07 June 2012 02:13:16 Luca Barbato wrote:
On 07/06/12 05:17, Mike Frysinger wrote:
On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote:
Is there a wiki or forum thread somewhere where folks can gloat and/or
commiserate?
i haven't set up anything
Shall we start
On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote:
I think that would be interesting to try to not get grep build with pcre
support by default, specially after reading man grep and seeing that
its support is tagged as experimental:
-P, --perl-regexp
Interpret PATTERN
On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote:
The problem is that grep keeps linked against libpcre and it can cause
problems like pointed in referred bug report, and it's really risky as
people can have their portage completely broken for example when libpcre
is downgraded for some
On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote:
i'm pleased to announce the initial x32 release candidate:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
Also pleased to hear this! Thanks! Can't wait to find the time to play
with it. Did you do all that
On Tuesday 05 June 2012 02:14:36 Mike Frysinger wrote:
v4
committed with test cases
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday 31 May 2012 08:55:25 Michał Górny wrote:
+# Note: this function implicitly calls pkg-config. You should add it to
+# your DEPEND when using it.
should clarify: implicitly calls pkg-config when your package provides a .pc.
+ if [[ ! ${removing_all} ]]; then
+ local
On Sunday 03 June 2012 18:16:30 Zac Medico wrote:
On 06/02/2012 10:08 PM, Mike Frysinger wrote:
# @FUNCTION: _multijob_fork # @INTERNAL # @DESCRIPTION: # Do the
actual book keeping. _multijob_fork() { [[ $# -eq 1 ]] || die
incorrect number of arguments
local ret=0 [[ $1 == pre
v4
-mike
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multiprocessing.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @AUTHOR:
# Brian Harring ferri...@gentoo.org
# Mike Frysinger vap...@gentoo.org
# @BLURB
i'm pleased to announce the initial x32 release candidate:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
the x32 ABI is the default one, and includes x86/amd64 ABIs. it is not using
/lib32/ (and /lib is not a symlink) like our existing amd64 multilib as that
is being
compiler wise, you do not need to specify -mx32 yourself. the toolchain
defaults to the x32 ABI (and all programs in there are compiled as x32). you
only need -mx32 if you want to do something like distcc and execute with
toolchains that aren't targeting x32 by default.
as for what are valid
On Tuesday 05 June 2012 14:44:13 Mike Frysinger wrote:
i'm pleased to announce the initial x32 release candidate:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
to be kind to infra, i've put this on the mirrors:
http://distfiles.gentoo.org/experimental/amd64/x32/
this URL
On Saturday 02 June 2012 05:52:01 David Leverton wrote:
Mike Frysinger wrote:
exec {mj_control_fd}${mj_control_pipe}
I'll have to remember that feature, but unfortunately it's new in bash
4.1, so unless we're giving up 3.2 as the minimum for the tree
lame
: $(( ++mj_num_jobs
v2
-mike
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multiprocessing.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @AUTHOR:
# Brian Harring ferri...@gentoo.org
# Mike Frysinger vap...@gentoo.org
# @BLURB
On Saturday 02 June 2012 16:39:16 Zac Medico wrote:
On 06/02/2012 12:54 PM, Mike Frysinger wrote:
if [[ ! -L /dev/fd/${fd} ]] ; then
eval exec ${fd}${redir}'${file}' break
fi
I launched up a GhostBSD livedvd to see what
On Saturday 02 June 2012 19:29:29 Zac Medico wrote:
On 06/02/2012 02:12 PM, Mike Frysinger wrote:
On Saturday 02 June 2012 16:39:16 Zac Medico wrote:
On 06/02/2012 12:54 PM, Mike Frysinger wrote:
if [[ ! -L /dev/fd/${fd} ]] ; then
eval exec ${fd
On Saturday 02 June 2012 19:59:02 Brian Harring wrote:
On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
# @FUNCTION: multijob_post_fork
# @DESCRIPTION:
# You must call this in the parent process after forking a child process.
# If the parallel limit has been hit
v3
-mike
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multiprocessing.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @AUTHOR:
# Brian Harring ferri...@gentoo.org
# Mike Frysinger vap...@gentoo.org
# @BLURB
...@gentoo.org
# Mike Frysinger vap...@gentoo.org
# @BLURB: parallelization with bash (wtf?)
# @DESCRIPTION:
# The multiprocessing eclass contains a suite of functions that allow ebuilds
# to quickly run things in parallel using shell code.
if [[ ${___ECLASS_ONCE_MULTIPROCESSING} != recur
On Friday 01 June 2012 07:37:52 Dirkjan Ochtman wrote:
It looks to me (from looking at eshowkw for python packages quite a
bit) that a great many packages aren't being keyworded on m68k. Would
it perhaps make sense to drop it from the set of stable arches (for
example, in the bugzilla
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
mark it @INTERNAL
if [[ -z $size ]] ; then
${size}
if [[ $function == doicon ]] ; then
${function}
if [[
example conversion of eatureconf
-mike
--- autotools.eclass
+++ autotools.eclass
@@ -16,7 +16,7 @@
if [[ ${___ECLASS_ONCE_AUTOTOOLS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_AUTOTOOLS=recur -_+^+_- spank
-inherit libtool
+inherit libtool multiprocessing
# @ECLASS-VARIABLE:
On Tuesday 29 May 2012 15:00:15 Sergei Trofimovich wrote:
Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
we've already got:
https://bugs.gentoo.org/336626
please collaborate there
-mike
signature.asc
Description: This is a digitally signed message part.
On Friday 01 June 2012 22:50:10 hasufell wrote:
On 06/02/2012 12:49 AM, Mike Frysinger wrote:
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
mark it @INTERNAL
what i meant here was:
# @FUNCTION
On Saturday 02 June 2012 00:11:19 Brian Harring wrote:
On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
and put it into a new multiprocessing.eclass. this way people can
generically utilize this in their own eclasses/ebuilds.
it doesn't currently support nesting
On Thursday 31 May 2012 01:46:41 Michał Górny wrote:
On Wed, 30 May 2012 17:19:49 -0400 Mike Frysinger wrote:
On Monday 28 May 2012 03:58:56 Michał Górny wrote:
+# @USAGE: [all]
this is incorrect. the usage is:
all | files to remove
No, it's perfectly valid. Moreover, it even
On Monday 28 May 2012 03:58:56 Michał Górny wrote:
+# @FUNCTION: remove_libtool_files
preen_libtool_files might be better. after all, you aren't just removing
them all.
+# @USAGE: [all]
this is incorrect. the usage is:
all | files to remove
+ [[ ${#} -le 1 ]] || die Invalid
On Sunday 27 May 2012 14:12:46 Samuli Suominen wrote:
Fedora rawhide and ArchLinux switched to libusbx and followed suit in
our virtual/libusb:1.
sad that we can't get these things merged. maybe we need to convince dsd to
hand over the reigns ?
-mike
signature.asc
Description: This is a
On Wednesday 30 May 2012 13:01:24 Michał Górny wrote:
This issue was given my attention through bug 418217 [1]. Long story
short -- there are applications which call pager implicitly. Those are
git systemd. They don't actually require any pager being installed;
however, if $PAGER is set they
On Wednesday 30 May 2012 17:41:18 Peter Stuge wrote:
Mike Frysinger wrote:
Fedora rawhide and ArchLinux switched to libusbx and followed
suit in our virtual/libusb:1.
sad that we can't get these things merged. maybe we need to
convince dsd to hand over the reigns ?
It seems
On Wednesday 30 May 2012 17:57:43 Michael Orlitzky wrote:
On 05/30/2012 05:23 PM, Mike Frysinger wrote:
On Wednesday 30 May 2012 13:01:24 Michał Górny wrote:
This issue was given my attention through bug 418217 [1]. Long
story short -- there are applications which call pager
implicitly
On Wednesday 30 May 2012 20:18:11 Zac Medico wrote:
On 05/25/2012 09:20 AM, Mike Frysinger wrote:
On Thursday 24 May 2012 16:04:30 Zac Medico wrote:
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
Rather than copying pasting the same behavior for the
different eclass checks, add a common
On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
Is there any sane way to handle sub-eclasses? eg. foo-base inherits
foo-functions.
i was thinking of extending the metadata to handle this. did you have any
specific ideas in mind ? i can see inheriting say distutils should not require
On Friday 25 May 2012 12:06:49 Alexey Shvetsov wrote:
Mike Frysinger писал 2012-05-25 19:42:
On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
Is there any sane way to handle sub-eclasses? eg. foo-base inherits
foo-functions.
i was thinking of extending the metadata to handle
On Friday 25 May 2012 14:38:34 Steven J Long wrote:
Steven J Long wrote:
You could maybe tighten the false-negative side by scanning all
functions defined in an eclass, and warning if they're undocumented.
that happens now when you emerge eclass-manpages, but i suspect no one
cares.
preprocessor flags (e.g. -I and -D) should be added via `append-cppflags`, and
build systems should be respecting ${CPPFLAGS}. to enforce this a bit better,
i'll be adding a qawarning to append-flags when it encounters flags that should
be passed to append-cppflags.
-mike
signature.asc
On Friday 25 May 2012 18:33:43 Ciaran McCreesh wrote:
On Fri, 25 May 2012 15:02:32 -0500 Dan Douglas wrote:
If it were made a policy now that ebuilds and eclasses cannot depend
upon the subshell (for example, to set temporary positional
parameters or isolate temporary variables), then maybe
On Friday 25 May 2012 23:23:30 Ryan Hill wrote:
...
what Ryan said
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday 24 May 2012 16:04:30 Zac Medico wrote:
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
Rather than copying pasting the same behavior for the different eclass
checks, add a common class for them to extend. This makes adding more
eclass checks trivial, and keeps down bitrot
i implemented eclass checking for some of the most common ones in the tree,
but Zac didn't particularly care for the maintaining of lists of functions
used by eclasses directly in repoman (due to the concern of them getting out
of sync).
so the proposal is to utilize the existing eclass
On Thursday 24 May 2012 16:12:35 Kent Fredric wrote:
Were it me, I'd have a tool that scrapes the eclass files's
documentation and emits a .json file which repoman can then optionally
use for consistency checks.
python provides its own pickling system. no need to add yet another layer.
On Thursday 24 May 2012 18:16:23 Steven J Long wrote:
You could maybe tighten the false-negative side by scanning all functions
defined in an eclass, and warning if they're undocumented.
that happens now when you emerge eclass-manpages, but i suspect no one cares.
if you run the script by
501 - 600 of 3211 matches
Mail list logo
