progress update:
- binutils-2.22 in ~arch should work fine
- glibc-2.14.1-r1 in ~arch includes support when x32 is in MULTILIB_ABIS
- linux-headers-3.1 includes support when x32 is in MULTILIB_ABIS
- you'll still need gcc-4.7 from the toolchain overlay
- a 3.1 kernel can be obtained here:
On Friday 02 December 2011 16:25:15 Samuli Suominen wrote:
On 12/02/2011 10:54 PM, Mike Frysinger wrote:
progress update:
- linux-headers-3.1 includes support when x32 is in MULTILIB_ABIS
so 3.1 will hit portage soon?
as soon as the bugs in the eclass keeping the ebuild out of the tree
i'd like to think Gentoo has grown up now to the point where we don't bother
with trivial ricer behavior. to that end, i'd like to EOL `filter-mfpmath`.
my main beef with filtering -mfpmath is that we use this only when someone
actually notices and reports misbehavior with the package in
On Wednesday 30 November 2011 11:34:05 Zac Medico wrote:
On 11/30/2011 08:09 AM, Mike Frysinger wrote:
On Wednesday 30 November 2011 01:23:59 Zac Medico wrote:
If it wasn't for implicit system dependencies, the system set and its
dependencies wouldn't need this kind of special treatment
On Wednesday 30 November 2011 13:23:53 Michał Górny wrote:
+# @ECLASS-VARIABLE: DOCS
+# @DESCRIPTION:
+# Array containing documents passed to dodoc command.
+#
+# DOCS=( NEWS README )
+
+# @ECLASS-VARIABLE: HTML_DOCS
+# @DESCRIPTION:
+# Array containing documents passed to dohtml command.
On Sunday 27 November 2011 17:28:12 Arfrever Frehtes Taifersar Arahesis wrote:
2011-11-26 11:58:22 Fabian Groffen napisał(a):
On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis wrote:
commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0
T Org
AuthorDate: Sat Nov 26
sys-libs/readline is no longer part of system:
http://sources.gentoo.org/profiles/base/packages?r1=1.55r2=1.56
http://sources.gentoo.org/profiles/prefix/windows/winnt/packages?r1=1.5r2=1.6
http://sources.gentoo.org/profiles/uclibc/packages?r1=1.34r2=1.35
-mike
signature.asc
Description: This is
On Tuesday 29 November 2011 21:14:49 Matt Turner wrote:
On Tue, Nov 29, 2011 at 3:09 PM, Mike Frysinger vap...@gentoo.org wrote:
we have USE=zlib already which should cover automatically pulling in zlib
when necessary, and we have that by default in make.conf. so there's no
need
On Tuesday 29 November 2011 21:14:49 Matt Turner wrote:
On Tue, Nov 29, 2011 at 3:09 PM, Mike Frysinger vap...@gentoo.org wrote:
we have USE=zlib already which should cover automatically pulling in zlib
when necessary, and we have that by default in make.conf. so there's no
need
On Saturday 26 November 2011 07:50:27 Nirbheek Chauhan wrote:
On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen wrote:
On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote:
[...] Besides, sorting even 30,000
entries (if you're merging every ebuild in portage) should not take
more than a few
On Wednesday 23 November 2011 19:31:11 Mike Frysinger wrote:
currently we blacklist certain phases (which is largely based on EAPI=0 and
blocking src_*) for enew{user,group}. moving forward, ferringb suggested
we invert this into a whitelist of allowed phases.
afaict, the blacklisting + dev
On Wednesday 23 November 2011 18:19:40 Maciej Mrozowski wrote:
On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:
if (patch -p${count} ${EPATCH_OPTS} --dry-run -f
${PATCH_TARGET})
${STDERR_TARGET} 21 ; then
There seems to be a little 'problem
currently we blacklist certain phases (which is largely based on EAPI=0 and
blocking src_*) for enew{user,group}. moving forward, ferringb suggested we
invert this into a whitelist of allowed phases.
afaict, the blacklisting + dev documentation has done a good job of
restricting calls to
On Monday 07 November 2011 15:03:12 Mike Frysinger wrote:
now that glibc-2.14 no longer breaks all rpc packages, i'll be adding
2.14.1 in a bit and then moving it to ~arch later this week. a package or
two is broken by this, but i think we're in a good state to see wider
testing.
as semi
the latest net-tools includes an USE=old-output flag so people can depend on
the old style if need be. we know openswan is broken in this regard.
if other people notice problems with their packages and the new ifconfig
output, you should migrate to iproute2 :P
-mike
signature.asc
we've got pretty good USE=readline coverage now, and there's nothing this
provides in terms of utility programs that means we need this to be explicitly
listed in the profile as a system package. so time to drop it.
-mike
signature.asc
Description: This is a digitally signed message part.
On Monday 14 November 2011 04:39:50 Patrick Lauer wrote:
Why do y'all want to make it harder for me to figure out
you've already told you how to put it into verbose mode (it's all of one line
in your make.conf). you do it once, and then you're done.
-mike
signature.asc
Description: This is a
On Sunday 13 November 2011 12:26:25 Mike Frysinger wrote:
i noticed that we have net-tools listed in base/packages. considering this
is a Linux-only tool, this doesn't make sense anymore. so i'll be
relocating it to default/linux/packages.
relocated
-mike
signature.asc
Description
On Sunday 13 November 2011 13:42:43 Mike Frysinger wrote:
now that we have USE=cxx, and base/make.defaults has USE=cxx, i'd like to
migrate gcc away from USE=nocxx.
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.478r2=1.479
-mike
signature.asc
Description: This is a digitally signed
On Monday 14 November 2011 14:00:01 Mike Gilbert wrote:
On 11/13/2011 11:37 PM, Mike Frysinger wrote:
On Sunday 13 November 2011 16:42:39 Mike Gilbert wrote:
If I understand you correctly, you are just going to add a cxx use
flag to gcc for some transitional period? If so, I can simply
On Sunday 13 November 2011 05:48:40 Paweł Hajdan, Jr. wrote:
On 11/12/11 11:24 PM, Patrick Lauer wrote:
Most devs will be unhappy as it makes it harder to view the log while
building.
We can have a different default in the developer profile.
the original reason for not doing this via
On Sunday 13 November 2011 10:16:31 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
for basic setups, it is completely redundant. which is the only case
we're talking about here.
[...]
you keep saying net-tools when you actually mean ifconfig. the
net-tools package provides
i noticed that we have net-tools listed in base/packages. considering this is
a Linux-only tool, this doesn't make sense anymore. so i'll be relocating it
to default/linux/packages.
-mike
signature.asc
Description: This is a digitally signed message part.
it seems we have some cases where eclasses/ebuilds interact poorly. for
example, if an eclass runs eautoreconf or elibtoolize, and then the ebuild
does some stuff where it ends up running eautoreconf, subsequent elibtoolize
calls are skipped.
this means that the work done by the earlier
On Sunday 13 November 2011 12:45:50 Samuli Suominen wrote:
On 11/13/2011 07:37 PM, Mike Frysinger wrote:
but i've hit this since with cross-compiling Linux targets:
- pygobject ebuild inherits gnome2 eclass
- pygobject's src_prepare first calls gnome2_src_prepare
On Sunday 13 November 2011 13:04:57 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
until we have replacement for all of its tools, it's always going to be
there.
After net-tools is no longer needed for basic setups (which I understand
will be still the case after the proposed
now that we have USE=cxx, and base/make.defaults has USE=cxx, i'd like to
migrate gcc away from USE=nocxx.
since this can be a pickle, i'd propose toolchain.eclass grow the checks:
- use cxx use nocxx die
- use !cxx use !nocxx die
this way when i do cut over from USE=nocxx
On Sunday 13 November 2011 13:50:25 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
On Sunday 13 November 2011 13:04:57 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
until we have replacement for all of its tools, it's always going to be
there.
After net
On Sunday 13 November 2011 16:42:39 Mike Gilbert wrote:
If I understand you correctly, you are just going to add a cxx use
flag to gcc for some transitional period? If so, I can simply switch it
at some point after you add the new flag?
transition period:
On Sunday 13 November 2011 19:57:05 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
until we have replacement for all of its tools, it's always going to
be there.
After net-tools is no longer needed for basic setups (which I
understand will be still the case after
On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
On 11/11/11 16:44, Zac Medico wrote:
good point. we don't want to punish old portage users. let's enable it
by default in portage itself then. just add `elog` output to the
portage ebuild to inform users of the change ? or do we
On Saturday 12 November 2011 20:26:54 Chí-Thanh Christopher Nguyễn wrote:
Joshua Saddler schrieb:
if net-tools isn't being dropped from the system set, don't force our
users to install redundant utilities.
ip is not redundant. You need it for e.g. GRE tunnels.
for basic setups, it is
On Friday 11 November 2011 16:53:44 William Hubbs wrote:
has prompted a discussion of whether or not we should use ifconfig in
openrc to configure networking on linux systems.
no, the discussion is whether we should continue to have ifconfig be an option
at all, not always use ifconfig. as
On Friday 11 November 2011 17:01:43 Chí-Thanh Christopher Nguyễn wrote:
Do you need iproute2 at all? I think you could fall back to busybox if
iproute2 is not installed.
that introduces an unnecessary level of instability for us to worry about imo.
if we want iproute, we should execute `ip`
On Friday 11 November 2011 06:38:00 Tomáš Chvátal wrote:
sys-devel/autoconf-archive
i'd been updating this for years ... didn't realize someone else had taken it
over ;). i'll move it to base-system herd.
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday 10 November 2011 22:23:57 Zac Medico wrote:
On 11/10/2011 07:17 PM, Zac Medico wrote:
On 11/10/2011 06:59 PM, Mike Frysinger wrote:
On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
On 11/10/2011 05:56 PM, Mike Frysinger wrote:
On Thursday 10 November 2011 20:39:11 Mike
On Friday 11 November 2011 10:05:56 Nathan Phillip Brink wrote:
On Fri, Nov 11, 2011 at 09:38:24AM -0500, Ian Stakenvicius wrote:
On 11/11/11 06:38 AM, Tomáš Chvátal wrote:
sys-devel/autoconf-archive - binki
I'll take autoconf-archive, unless if someone else wants it.
i was going to set
On Friday 11 November 2011 10:50:47 Zac Medico wrote:
On 11/10/2011 10:59 PM, Duncan wrote:
But please do at least einfo the change, and what to do to get back to
non-quiet by default if desired. Someone mentioned a news item. I'm not
sure it warrants that, but certainly an einfo, and if
On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
On 11/5/11 1:58 AM, Kacper Kowalik wrote:
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy there, but there's a
lot of packages that support things like make V=1 or
On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
On 11/5/11 1:58 AM, Kacper Kowalik wrote:
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy
On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
On 11/10/2011 05:56 PM, Mike Frysinger wrote:
On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
if you want quiet portage output, use something like --quiet when
running emerge. the verbosity of the build output isn't really
now that glibc-2.14 no longer breaks all rpc packages, i'll be adding 2.14.1
in a bit and then moving it to ~arch later this week. a package or two is
broken by this, but i think we're in a good state to see wider testing.
-mike
signature.asc
Description: This is a digitally signed message
On Sunday 06 November 2011 13:33:48 Petteri Räty wrote:
On 03.11.2011 17:30, Mike Frysinger wrote:
http://sources.gentoo.org/eclass/user.eclass?r1=1.8r2=1.9
Less than a day is quite a short time for people to comment. Also it
would be better to include the diff in the original email.
4
http://sources.gentoo.org/eclass/user.eclass?r1=1.8r2=1.9
-mike
signature.asc
Description: This is a digitally signed message part.
when i first wrote enew{user,group} oh-so-long-ago, the reason for the [extra]
arguments was the assumption that i am short sighted. i figured someone would
come up with some creative need for passing additional flags that i couldn't
possibly think of.
however, in the ~9 years since, all i
On Wednesday 26 October 2011 19:40:24 Mike Frysinger wrote:
i can't see any ebuild/eclass using egethome, egetshell,
is-login-disabled from portability.eclass. anyone have a reason for
keeping these before i punt them ?
hmm, seems a few packages in the tree want this functionality
On Wednesday 26 October 2011 19:40:24 Mike Frysinger wrote:
i can't see any ebuild/eclass using egethome, egetshell,
is-login-disabled from portability.eclass. anyone have a reason for
keeping these before i punt them ?
http://sources.gentoo.org/eclass/user.eclass?r1=1.3r2=1.4
http
On Sunday 30 October 2011 18:33:51 Petteri Räty wrote:
On 27.10.2011 2.40, Mike Frysinger wrote:
i can't see any ebuild/eclass using egethome, egetshell,
is-login-disabled from portability.eclass. anyone have a reason for
keeping these before i punt them ?
Breaking overlays. Isn't
On Wednesday 26 October 2011 10:20:54 Paweł Hajdan, Jr. wrote:
The second IUSE+= nossp seems redundant and could be removed, right?
looks like a fix was committed:
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.473r2=1.474
-mike
signature.asc
Description: This is a digitally
On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote:
On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote:
So, I honestly see no reason why toolchain should not start using EAPI 2.
I await your patch to toolchain.eclass. :P
i wouldn't bother as it's most likely not going to be accepted at
i'm indifferent to the newnet status
-mike
hopefully i didn't break anything before i go to sleep ;D
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.474r2=1.475
http://sources.gentoo.org/eclass/eutils.eclass?r1=1.366r2=1.367
-mike
i can't see any ebuild/eclass using egethome, egetshell,
is-login-disabled from portability.eclass. anyone have a reason for
keeping these before i punt them ?
-mike
On Mon, Oct 24, 2011 at 03:46, Michał Górny wrote:
On Mon, 24 Oct 2011 03:42:24 + Nathan Phillip Brink wrote:
On Sun, Oct 23, 2011 at 08:20:37PM +0200, Micha?? G??rny wrote:
---
scons-utils.eclass | 33 +
1 files changed, 25 insertions(+), 8
On Thursday 20 October 2011 23:20:35 Duncan wrote:
Magnus G suggests possibly adding PIE to amd64, which is already PIC,
this isn't quite right. amd64 shared objects (i.e. libraries) are PIC. the
applications are not.
Still, speaking as an ~amd64 user myself, that's certainly an acceptable
On Thursday 20 October 2011 07:46:57 Diego Elio Pettenò wrote:
Il giorno gio, 20/10/2011 alle 06.40 -0400, Anthony G. Basile ha scritto:
It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
and ssp into mainstream though. Packages which break because of
either
of those
On Thursday 20 October 2011 04:47:14 Paweł Hajdan, Jr. wrote:
I've noticed
http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e.
Debian is starting to make more and more hardening features default, at
least for most packages.
seems a bit light on what actually is being used
On Thursday 20 October 2011 08:41:55 Rich Freeman wrote:
2011/10/20 Tomáš Chvátal:
I would say that most hardened features should be merged to to main
profile as soon as they won't cause major PITA for the regular users.
I agree - especially for stuff that doesn't require active setup
On Thursday 20 October 2011 11:58:44 Donnie Berkholz wrote:
On 01:26 Thu 20 Oct , Mike Frysinger wrote:
On Wednesday 19 October 2011 15:40:50 Brian Harring wrote:
Name's a bit off though considering if the host was amd64, `huse amd64`
would return 1 since it's not in IUSE.
good
On Thursday 20 October 2011 12:47:27 Rich Freeman wrote:
I was trying to draw a contrast between passive things like
stack-protection and things that really get in your face like MAC.
the trouble was in the context quoting then ... it sounded like you were
proposing PaX by default
i am a fan
On Thursday 20 October 2011 16:01:01 Paweł Hajdan, Jr. wrote:
On 10/20/11 9:22 PM, Donnie Berkholz wrote:
alright, use_if_iuse. That's my last bikeshed for today.
I think this is the best one. I didn't really like any of the previously
proposed names, but this one is good.
yeah, this works
with the previously proposed/accepted GLEP 27 stalled, i'm looking into
mitigating the current suckiness of enew{user,group}/egetent. the first step
is simple: let's split these funcs out of eutils.eclass and into a dedicated
eclass. this makes it trivial for people externally to override the
i wrote a new func for toolchain.eclass: huse. this is because the
toolchain.eclass supports multiple versions in parallel, and the IUSE value
can vary greatly between them. so doing `use foo` without checking IUSE first
doesn't work. since i got a request to use this in other eclasses (for
On Wednesday 19 October 2011 14:05:50 Mike Frysinger wrote:
now that we have in_iuse in eutils.eclass (with all the caveats), i'll be
adding huse:
huse() {
in_iuse $1 || return 1
use $1
}
actually, after posting this, iuse is probably a better name
On Wednesday 19 October 2011 14:53:07 Brian Harring wrote:
On Wed, Oct 19, 2011 at 02:05:50PM -0400, Mike Frysinger wrote:
i wrote a new func for toolchain.eclass: huse. this is because the
toolchain.eclass supports multiple versions in parallel, and the IUSE
value can vary greatly between
On Wednesday 19 October 2011 15:40:50 Brian Harring wrote:
Name's a bit off though considering if the host was amd64, `huse amd64`
would return 1 since it's not in IUSE.
good point. how about iuse_use ? or use_iuse ?
-mike
signature.asc
Description: This is a digitally signed message part.
On Saturday 15 October 2011 03:29:54 Michał Górny wrote:
On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes wrote:
On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
We're imposing our deep integration because it's the only way to
make a compelling platform that just works, forcing
On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
WARNING: One or more updates have been skipped due to a dependency
conflict:
dev-python/numpy:0
(dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
with ~dev-python/numpy-1.5.1 required by
On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
On 10/14/11 01:48, Mike Frysinger wrote:
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS=${BUILD_CPPFLAGS
On Thursday 13 October 2011 11:17:07 Olivier Crête wrote:
That said, we, the GNOME upstream, think that having a separate /usr is
a completely stupid idea.
considering GNOME's track record wrt what they think is a good idea in the
UI land, i'm not sure this statement is terribly compelling
On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
While I've seen a lot of whining about this whole issue, I certainly
haven't been seen any effort to actually solve the problem within the
existing framework. For example, if someone cares enough, why not
write a wrapper script to track
On Thursday 13 October 2011 14:55:45 Canek Peláez Valdés wrote:
On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote:
On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
While I've seen a lot of whining about this whole issue, I certainly
haven't been seen any effort to actually
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS=${BUILD_LDFLAGS} \
CC=$(tc-getBUILD_CC) \
LD=$(tc-getBUILD_LD) \
On Thursday 13 October 2011 21:41:02 Alec Warner wrote:
On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger wrote:
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS
On Friday 30 September 2011 11:27:18 Diego Elio Pettenò wrote:
Il giorno ven, 30/09/2011 alle 11.06 -0400, Mike Frysinger ha scritto:
and azarah ;)
Right, by the way have you (or anyone else) got any news of him?
want to do a brain dump into the @DESCRIPTION part of libtool.eclass
On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote:
Another example from the X.org packages, installing the proprietary
ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
systems. Nobody in his right mind is proposing to treeclean them because
of this.
yes,
On Wednesday 12 October 2011 09:26:12 Rich Freeman wrote:
On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote:
Forking udev is probably not an option. The udev lead developer is a
Redhat employee, and his direction seems to be to drag everybody in
Redhat's direction. Our community
On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote:
Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto:
- The fix_libtool_files.sh command is now part of the toolchain
eclass, so
doesn't need to be ran by users anymore
Moreover, that should only be
On Saturday 08 October 2011 18:57:23 James Cloos wrote:
SV == Sven Vermeulen sw...@gentoo.org writes:
SV - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
SV from that version onwards should not be needed
That is not generally true.
I use gcc-4.5 as my system gcc, but
On Wednesday 12 October 2011 15:19:25 Samuli Suominen wrote:
On 10/12/2011 06:30 AM, Steven J Long wrote:
Michał Górny wrote:
I don't think that passing multiple files to epatch actually improves
readability. Simple example:
# bug #123456, foo, bar
epatch ${FILESDIR}/${P}-foo.patch
On Wednesday 12 October 2011 15:38:47 Matt Turner wrote:
On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger wrote:
On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote:
Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto:
- The fix_libtool_files.sh command is now
On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
If I want to add a patch to the list I might forget to to add the \
admittedly, i hit this every once in a while, and with all the || die being
implicit, it doesn't get caught right away. fortunately latest portage will
issue a QA
On Wednesday 12 October 2011 15:57:45 Tomáš Chvátal wrote:
2011/10/12 Mike Frysinger:
On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
If I want to add a patch to the list I might forget to to add the \
admittedly, i hit this every once in a while, and with all the || die
being
On Wednesday 12 October 2011 17:42:47 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
otherwise, Rich summed up things nicely in his later post.
If you mean that common sense thing: if there is disagreement about it,
then it is obviously not common.
you're mixing common
On Wednesday 12 October 2011 19:27:41 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
The removed qutecom ebuild was not broken at any time.
by splitting my reply, you changed the meaning. having qutecom in the
tree with a depend on versions that i'm now removing breaks
On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote:
On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
The removed qutecom ebuild was not broken at any time.
by splitting my reply, you changed the meaning. having qutecom in the
tree
On Wednesday 12 October 2011 11:09:56 Zac Medico wrote:
How about if we add a `emerge --upgrade` target that is analogous to
`apt-get upgrade`?
isn't that already done with @installed ? `emerge --upgrade @installed`
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday 13 October 2011 01:33:07 Michał Górny wrote:
On Wed, 12 Oct 2011 23:20:23 -0400 Mike Frysinger wrote:
On Wednesday 12 October 2011 11:09:56 Zac Medico wrote:
How about if we add a `emerge --upgrade` target that is analogous to
`apt-get upgrade`?
isn't that already done
On Tuesday 11 October 2011 03:11:03 Fabian Groffen wrote:
On 11-10-2011 00:50:54 -0400, Mike Frysinger wrote:
If people use strip from the elfutils package, take advantage of some of
its neat features (like splitting + stripping in one step).
+# See if we're using GNU binutils
The readelf utility is much more common than debugedit.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
bin/ebuild-helpers/prepstrip | 32 +++-
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/bin/ebuild-helpers/prepstrip b/bin/ebuild-helpers
This avoids a little duplication between the getTestFromCommandLine and
getTests funcs, and they'll get utilized even more in follow up patches.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
pym/portage/tests/__init__.py | 37 +
1 files changed, 17
The code assumes we're in the top of the tree (when it tries to run with
the full path pym/portage/tests/runTests), so try to make sure we are
in the right place to allow things like `../runtests.sh` to just work.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
runtests.sh |3 +++
1
On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
Samuli Suominen schrieb:
Please point to existing authoritative documentation which says that
downgrades are unacceptable.
It is NOT gentoo-x86 compatible package in it's current form.
It sets correct
On Sunday, October 02, 2011 16:00:30 Chí-Thanh Christopher Nguyễn wrote:
I agree that a downgrade is a bit inconvenient for users. But if another
package is built later with DEPEND on newer linux-headers or emerge
--deep option, then it will get upgraded again. As no package runtime
depends on
On Thursday, September 29, 2011 21:27:39 Robin H. Johnson wrote:
Provide public-domain implementation of the Whirlpool hash algorithm to
be used as new Manifest2 hash.
Signed-off-by: Robin H. Johnson robb...@gentoo.org
---
pym/portage/checksum.py |4 +
cleaned up ELT_try_and_apply_patch a bit, and added support for
@GENTOO_LIBDIR@ in patches
-mike
--- libtool.eclass
+++ libtool.eclass
@@ -16,7 +16,7 @@
DESCRIPTION=Based on the ${ECLASS} eclass
-inherit toolchain-funcs
+inherit multilib toolchain-funcs
once i double check the tree, i'll be changing `edos2unix` to die
automatically when the sed calls (since edos2unix is really just a single call
to sed).
-mike
signature.asc
Description: This is a digitally signed message part.
On Thursday, September 29, 2011 17:57:27 Donnie Berkholz wrote:
On 13:28 Thu 29 Sep , Mike Frysinger wrote:
cleaned up ELT_try_and_apply_patch a bit, and added support for
@GENTOO_LIBDIR@ in patches
Is this documented anywhere besides the comment immediately above the
implementation
sounds like a lot of hub bub over nothing
-mike
signature.asc
Description: This is a digitally signed message part.
On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote:
I'm a bit concerned that the future of linux on the desktop is going to be
one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS,
or a KDE OS. Each one would have its own package managers, repositories,
distros, APIs,
801 - 900 of 3211 matches
Mail list logo
