On Sat, Sep 24, 2011 at 14:18, Rich Freeman wrote:
On Sat, Sep 24, 2011 at 3:10 AM, Mike Frysinger wrote:
On Sat, Sep 24, 2011 at 02:49, Duncan wrote:
Unfortunately, locking a bug to kill the whining is likely to have rather
more negative effects than one might have anticipated. One would
On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote:
On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote:
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
On Sunday, September 25, 2011 08:53:08 Rich Freeman wrote:
However, I can't seem to find a chromeos-meta package in portage, and
the fact that my chromeos laptop has some feature does me little good
in getting my Gentoo desktop to do the same. At best ChromeOS is a
fork of Gentoo, and the
On Sunday, September 25, 2011 21:57:27 Nirbheek Chauhan wrote:
But neither portage, nor the portage tree, nor any of our branding are
shipped with ChromeOS. Hence it's as much a Gentoo install as $company
that uses portage to build $image for their embedded device, but
doesn't leave any trace
On Sat, Sep 24, 2011 at 02:43, Nikos Chantziaras wrote:
On 09/24/2011 08:24 AM, Mike Frysinger wrote:
the defines in question are internal to zlib. packages relying on them
are broken, plain and simple.
Then fix *them*, not zlib.
they are being fixed already
Then why did you fix zlib
On Sat, Sep 24, 2011 at 02:49, Duncan wrote:
Mike Frysinger posted on Sat, 24 Sep 2011 01:10:43 -0400 as excerpted:
it was purely to keep people from continuing to whine with circular
logic. if bugzilla had a way to temporarily lock comments, i would
have used that.
In theory, that'd
On Friday, September 23, 2011 19:30:15 Alec Warner wrote:
On Fri, Sep 23, 2011 at 3:28 PM, Nirbheek Chauhan wrote:
On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him
after setting the
On Friday, September 23, 2011 18:02:50 Andreas K. Huettel wrote:
It's a mess right now and it just doesn't look right. The bug that
deals with it was locked from public view:
https://bugs.gentoo.org/show_bug.cgi?id=383179
Is there any good reason why this bug is dev-only? Going
On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote:
I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
packages currently in the tree. The maintainer of zlib pushed those
revisions with a patch that alters macro identifiers, making Gentoo's
zlib incompatible
On Thursday, September 22, 2011 14:23:55 Tim Harder wrote:
On 2011-09-22 Thu 01:53, Ulrich Mueller wrote:
In the course of the old-style to new-style transition of virtuals,
I had taken maintainership of several new-style virtual packages.
After several months have passed without any
On Wednesday, September 21, 2011 12:36:57 Thomas Kahle wrote:
On 09:10 Mon 19 Sep 2011, Michał Górny wrote:
On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote:
On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote:
On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote
since there's been no new feedback in a while, i'll add this to eutils.eclass
in a while:
usex() { use $1 echo ${2-yes}$4 || echo ${3-no}$5 ; }
then once it hits the PMS, i'll put EAPI wrapping around it.
-mike
signature.asc
Description: This is a digitally signed message part.
On Monday, September 19, 2011 03:10:45 Michał Górny wrote:
On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote:
On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote:
On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote:
'$(use_enable static-libs static)' themselves. While
On Monday, September 19, 2011 10:57:30 Michał Górny wrote:
On Mon, 19 Sep 2011 10:43:04 -0400 Mike Frysinger wrote:
On Monday, September 19, 2011 03:10:45 Michał Górny wrote:
On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote:
On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan
On Monday, September 19, 2011 11:35:09 Michał Górny wrote:
On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote:
by that token, i'll go ahead and remove glibc's static libraries
since upstream doesn't even support static linking
I'm probably ignorant so you'd have to elaborate
On Monday, September 19, 2011 18:25:36 Duncan wrote:
Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted:
On Monday, September 19, 2011 11:35:09 Michał Górny wrote:
On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote:
by that token, i'll go ahead and remove glibc's
On Monday, September 19, 2011 20:58:41 Mike Frysinger wrote:
On Monday, September 19, 2011 18:25:36 Duncan wrote:
By default? That's begging the question (logic sense) and consequently
does not properly support your blanket your system is using static
binaries right now statement
On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote:
On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote:
'$(use_enable static-libs static)' themselves. While at it, it may be
better to just drop the flag if no other package relies on it and no
user has ever requested the static
'bout that time again. if you peeps know of anything blocking glibc-2.13 from
going stable, mark the relevant bug as blocking the tracker.
tracker: https://bugs.gentoo.org/354107
stabilization: https://bugs.gentoo.org/382377
-mike
signature.asc
Description: This is a digitally signed message
On Friday, September 16, 2011 11:14:28 Michał Górny wrote:
On Fri, 16 Sep 2011 08:39:48 -0500 Donnie Berkholz wrote:
I don't want this in my repo.
By *your* repo you mean dev overlay? Noone forces you to declare
additional paths.
i think he meant maintaining masks for pkgs in his repo for
On Friday, September 16, 2011 09:36:32 Donnie Berkholz wrote:
understanding is that it probably makes sense to switch to x32 no matter
what you're using now (x86 or amd64).
x32 needs a 64bit processor, so x86 cant go away as it's the only ABI that can
run on 32bit processors
but for 64bit
On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
But doesn't switching mean we're going to hit LFS PITA once again?
LFS hasnt really been a pain in a long while. but it's something worth
raising on the x32 lists (which i'll do) since x32 has native 64bit support
(uint64_t == %rax).
On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
Is a x86/amd64/x32 multilib profile just going to provide toolchain
support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
do we want a 'full' x32 profile, where every package is built by default
as x32 code?
On Friday, September 16, 2011 12:01:43 Mike Frysinger wrote:
On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
But doesn't switching mean we're going to hit LFS PITA once again?
LFS hasnt really been a pain in a long while. but it's something worth
raising on the x32 lists (which
On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
On 09/16/11 10:58, Stratos Psomadakis wrote:
On 09/16/2011 10:48 AM, Michał Górny wrote:
On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote:
PS why not merge all x86 abis into one keyword? because
x86_32 x86_64 x86_x32
On Friday, September 16, 2011 01:46:49 Duncan wrote:
Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted:
On Thursday, September 15, 2011 17:03:07 Michał Górny wrote:
On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote:
On Thursday, September 15, 2011 16:12:00 Michał
On Friday, September 16, 2011 15:09:52 Thomas Sachau wrote:
Mike Frysinger schrieb:
On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
Is a x86/amd64/x32 multilib profile just going to provide toolchain
support for x32 binaries (like x86 in a x86/amd64 multilib profile
ive converted my system over to x86/amd64/x32 multilib for funs. but i can
see how some people wont want all three all the time. so the question is how
we want to make this available to users at the release/profile level.
background: x32 is a new ABI that runs on 64bit x86_64 processors. see
On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
KEYWORDS wise, i'd like to avoid having to add x32 everywhere.
instead, reusing amd64. only downside is the existing USE=amd64
behavior, but we can address that by making
On Thursday, September 15, 2011 16:14:20 Michał Górny wrote:
On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld wrote:
I'm trying to think of how best to avoid users who are not aware to
get caught with non-booting systems.
Guess we could try to detect a few common cases and die in
On Thursday, September 15, 2011 17:03:07 Michał Górny wrote:
On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote:
On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
KEYWORDS wise, i'd like to avoid having to add x32
On Wed, Sep 14, 2011 at 02:02, Ulrich Mueller wrote:
On Tue, 13 Sep 2011, Mike Frysinger wrote:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
You should omit the colons though. ${2-yes} and ${3-no} will allow for
an explicit empty string as argument, whereas the :- variants won't
On Wed, Sep 14, 2011 at 01:18, Ciaran McCreesh wrote:
On Tue, 13 Sep 2011 10:29:48 -0400 Mike Frysinger wrote:
You don't do it by checking IUSE. You do it by having the ebuild
define a variable like WANT_MONKEY_SUPPORT.
it's a crap shoot. as long as Michał's proposed func doesnt attempt
On Wed, Sep 14, 2011 at 06:38, Michał Górny wrote:
As the 'has_iuse' thread worked out, right now PMS doesn't allow us to
grep IUSE for random values during runtime. Thus, all eclasses using
that to enable features per ebuild-defined IUSE are broken.
this statement isnt exactly clear. no,
On Wed, Sep 14, 2011 at 16:03, Michał Górny wrote:
Well, the other thing is IUSE=static-libs. I don't like it either but
this is probably a bigger case than the other.
The main resolution as I see it, is to simply drop IUSE=static-libs
from a lot of ebuilds where static libs aren't actually
On Tuesday, September 13, 2011 06:24:51 Ciaran McCreesh wrote:
On Tue, 13 Sep 2011 11:53:28 +0200 Diego Elio Pettenò wrote:
Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto:
In that case blocking just old versions is wrong, since if your
installed version is broken
On Tuesday, September 13, 2011 05:53:28 Diego Elio Pettenò wrote:
Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto:
(Incidentally, there's a bug in libtool that causes it to randomly link
to stuff on / if you try to create an executable that links to both a
built
On Tuesday, September 13, 2011 06:46:33 Ciaran McCreesh wrote:
On Tue, 13 Sep 2011 12:50:30 +0200 Michał Górny wrote:
Are you sure this is defined behaviour? IUSE is a fancy merged
variable for eclasses, and I don't think we guarantee that the value
visible to the ebuild at any
i keep writing little helpers like this in ebuilds:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
or if i want something a little different, i can do:
export some_var=$(usex some_flag true
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
i dont
On Tuesday, September 13, 2011 22:02:28 Donnie Berkholz wrote:
On 17:56 Tue 13 Sep , Mike Frysinger wrote:
useful enough for EAPI ? or should i just stick it into eutils.eclass
? OR BOTH !?
I prefer to avoid EAPI whenever possible, as it just makes things slower
and more complex
On Monday, September 12, 2011 15:19:29 Nathan Phillip Brink wrote:
On Sun, Sep 11, 2011 at 03:55:49PM -0400, Mike Frysinger wrote:
as for no-multilib systems, lib64 will be the same, and lib will be
symlinked to lib64. this will be easier i think to share files between
multilib and non
On Friday, September 09, 2011 14:47:56 Mike Frysinger wrote:
anyone have a good reason for keeping cpio around in the system profile ?
moved to the bug:
https://bugs.gentoo.org/382633
any other issues should get posted to the bug
-mike
signature.asc
Description: This is a digitally signed
i dont care what the FHS has to say on the topic, so i havent bothered
looking. below is documentation on the current system, and where i plan on
taking things in the future.
note that this only applies to amd64, ppc64, sparc64, and s390x systems where
people think in terms of 32bit and 64bit
On Sunday, September 11, 2011 19:10:26 Duncan wrote:
But somehow, it never happened, and over time, as 64-bit became common
and pretty much everything (at least everything freedomware) was ported
and the existing setup worked better and better, the pressure to leave
what was now working
anyone have a good reason for keeping cpio around in the system profile ?
-mike
signature.asc
Description: This is a digitally signed message part.
On Wednesday, September 07, 2011 03:20:01 Tomáš Chvátal wrote:
please stop committing packages that is not possible to fetch right away.
You can pick from three options:
a) stop using mirrors://gentoo/ and put it on dev.gentoo.org to your
public_html like most of us do
b) mask the package
On Wednesday, September 07, 2011 05:27:05 Michał Górny wrote:
On Wed, 07 Sep 2011 12:17:21 +0300 Alexey Shvetsov wrote:
Moving things as openrc to /usr/libexec will effectevely barake old
systems with separtae / and /usr. So it isnt good idea
Old systems should migrate to initramfs, like
On Thursday, September 08, 2011 18:15:21 Joshua Kinard wrote:
On 09/08/2011 16:02, Eray Aslan wrote:
Seperate /usr without initramfs used to work. Now it doesn't. What you
are proposing is going to make it well neigh impossible to correct later
on. We could have done a proper fix instead
On Thursday, September 08, 2011 14:10:23 Arfrever Frehtes Taifersar Arahesis
wrote:
2011-09-08 19:03:56 Thomas Sachau napisał(a):
Tomáš Chvátal schrieb:
Start collecting ideas for EAPI5.
2) USE-flag based support to install for different slots (e.g. python,
ruby or php)
The
On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
we just got the following bug report for openrc today [1].
On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
causes breakage in openrc.
that specific report sounds like using /run would fix things ?
as for the
On Tuesday, September 06, 2011 17:58:12 Olivier Crête wrote:
On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote:
On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
The simplest fix for this would be for us
On Tuesday, September 06, 2011 17:53:37 William Hubbs wrote:
On Tue, Sep 06, 2011 at 04:45:43PM -0500, William Hubbs wrote:
On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
we just got the following bug report
On Saturday, June 11, 2011 16:11:35 Mike Frysinger wrote:
historically, glibc provided all the ugly rpc support (while not nearly as
relevant today, it still is used by way of nfs support). the glibc
maintainers have opted to stop supporting this. at first they declined to
accept new
On Wednesday, August 31, 2011 16:22:28 Michał Górny wrote:
On Wed, 31 Aug 2011 22:14:08 +0200 Tomáš Chvátal wrote:
what is the purpose of this fancy useflag, it controlls install of at
best one or more small sh scripts.
As we do not bother with the logrotate useflag this thing should fall
On Wednesday, August 31, 2011 18:16:29 Ulrich Mueller wrote:
On Wed, 31 Aug 2011, Mike Frysinger wrote:
installing the files unconditionally does fall into the
logrotate/xinetd category, so it should get punted. but people
should not end up with the depends installed all the time
On Sunday, August 28, 2011 14:38:31 Michael wrote:
Mike Frysinger wrote:
like Nathan said, only if the package directly uses/links against the X11
API/libs in question. if the package only uses gtk+ funcs, then it
should not be declaring a dependency on the X11 libs.
Just to confirm
On Monday, August 22, 2011 15:21:23 Michael wrote:
I wrote a script to search for discrepancies between linked libraries and
what's defined in (R)DEPEND, with the intention of improving QA for minimal
package installs.
The devmanual seems to suggest that it's a bad thing for packages to
On Tuesday, August 23, 2011 13:53:26 Michael wrote:
Mike Frysinger wrote:
On Monday, August 22, 2011 15:21:23 Michael wrote:
I wrote a script to search for discrepancies between linked libraries
and what's defined in (R)DEPEND, with the intention of improving QA for
minimal package
with many people cramming this info into the eclass in many different (and
broken ... i guess no one actually looks at the man page output to verify
correctness) ways, i codified it with a new @AUTHORS block which is just like
the @MAINTAINERS block. start using it :P.
-mike
signature.asc
we added the cld workaround to gcc-4.3.0+ in early 2008 until packages sorted
themselves out. i think they have at this point. in terms of kernels, we're
talking about ones around 2.6.25 and earlier.
i'll be dropping it from our gcc builds, so now is the time to make noise if
this affects
On Saturday, August 20, 2011 14:08:00 Andreas K. Huettel wrote:
so... is this something where I should suddenly in a moment of clarity
shout ah, that cld workaround ?!
if you dont know immediately what i was referring to, then chances are you
dont care :)
otherwise, Matt provided good info
On Thursday, August 18, 2011 04:50:23 Diego Elio Pettenò wrote:
Unfortunately, as long as the mirror://gentoo/ option is still
maintained, we'll end up with situations like today's gnuconfig that
couldn't be fetched, causing all ~arch users to see the same failure,
because the distfile wasn't
On Thursday, August 18, 2011 11:02:55 Diego Elio Pettenò wrote:
Il giorno gio, 18/08/2011 alle 10.54 -0400, Mike Frysinger ha scritto:
you're understanding of this particular bug is completely off. i
forgot to
upload the pkg -- the only place it existed was on my desktop. it had
nothing
On Thursday, August 18, 2011 12:13:44 Diego Elio Pettenò wrote:
Il giorno gio, 18/08/2011 alle 11.55 -0400, Mike Frysinger ha scritto:
i think you've inverted this statement from what you meant. ~arch
failing to
fetch for more than a couple of hours was because i went to sleep.
SRC_URI
On Monday, August 15, 2011 17:33:24 Nirbheek Chauhan wrote:
I don't see a pressing need to split virtual/ yet :)
+1
-mike
signature.asc
Description: This is a digitally signed message part.
On Saturday, August 13, 2011 01:41:54 Arun Raghavan wrote:
On 7 August 2011 17:20, Raúl Porcel wrote:
With subprofiles we could keyword such packages, mask them globally on
arm and unmask it on the subprofile of the subarchitecture that supports
it.
I think this makes sense. What would
On Sunday, August 07, 2011 07:50:42 Raúl Porcel wrote:
The problem is that during the history of the ARM architecture(according
to the wikipedia, the architecture was introduced back in 1981) there
has been some subarchitectures(the most available are armv4, armv4t,
armv5t, armv6j and armv7-a)
On Wednesday, August 10, 2011 05:55:19 Michał Górny wrote:
I'm attaching a net-dns/resolvconf-symlink ebuild which
replaces /etc/resolv.conf with a symlink to a runtime-writable location
when installed. That package could be added to PDEPEND of packages like
net-misc/networkmanager or
On Sunday, August 07, 2011 19:21:15 Mike Frysinger wrote:
now that yacc is no longer part of system, and we have multiple providers
of yacc, we need a virtual. so unless there are any complaints, i'll be
adding virtual/yacc which has || ( sys-devel/bison dev-util/yacc ).
implemented and added
On Sunday, August 07, 2011 23:32:09 Matt Turner wrote:
On Sun, Aug 7, 2011 at 11:21 PM, Mike Frysinger vap...@gentoo.org wrote:
now that yacc is no longer part of system, and we have multiple providers
of yacc, we need a virtual. so unless there are any complaints, i'll be
adding virtual
now that yacc is no longer part of system, and we have multiple providers of
yacc, we need a virtual. so unless there are any complaints, i'll be adding
virtual/yacc which has || ( sys-devel/bison dev-util/yacc ).
once that settles, i'll probably relocate bison to dev-util.
-mike
On Wed, Aug 3, 2011 at 07:43, Michał Górny wrote:
A good moderation would be to require PGP signatures as well but I
guess many devs still don't do that.
while ideal, but would be an annoyingly high barrier for less
up-to-speed peeps, or for people using webmail
-mike
On Wed, Jul 20, 2011 at 11:29, Michał Górny wrote:
On Wed, 20 Jul 2011 19:05:54 +0400 Maxim Koltsov wrote:
and 2) ask Gentoo developers and users: is it worth to be in tree? If
there are 5 votes for Leechcraft and no unfixable complaints from
other devs, i will start adding Leechcraft to tree.
On Wed, Jul 20, 2011 at 12:10, Georg Rudoy wrote:
Seems like the only issue that needs clarification now is the number
of packages and the need in separate eclass. Actually, there are 32
ebuilds for now (and new will be added as new modules are written),
and the eclass contains some common
On Sun, Jul 17, 2011 at 04:45, Kfir Lavi wrote:
-e '/^CFLAGS/{s|[[:space:]]=| +=|g;s|-O2||g;s|-Werror||g}' \
no need for the [[:space:]] since the first = will get matched, and
presumably it reads something like CFLAGS = ..
the others could be done with the -r flag and:
s|-(O2|Werror)||
On Tue, Jul 19, 2011 at 14:32, Kacper Kowalik wrote:
W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
I guess I'm
On Tue, Jul 19, 2011 at 15:51, Kacper Kowalik wrote:
W dniu 19.07.2011 20:40, Mike Frysinger pisze:
On Tue, Jul 19, 2011 at 14:32, Kacper Kowalik wrote:
W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze
if you specify a patch to `epatch` which does not exist based on the name
alone, epatch will now search for it in EPATCH_SOURCE. this makes it useful
to apply a set of patches which have a specific order but cannot use the
existing lexicographical search.
quick example is a debian patchset
On Friday, July 15, 2011 02:44:45 Michał Górny wrote:
On Thu, 14 Jul 2011 19:19:11 -0400 Mike Frysinger wrote:
3) Since a hardened kernel can be configure with various flavors of
pax or grsec or selinux, there should be useflags to reflect
userland needs to conform. There already
On Friday, July 15, 2011 06:51:42 Anthony G. Basile wrote:
ewarn We are disabling MPROTECT on the mono binary.
sed '/exec/ i\paxctl -mr $r/@mono_runtime@' -i
${S}/runtime/mono-wrapper.in
use:
sed -i \
'/exec/ itype -p paxctl /dev/null paxctl -mr
On Thursday, July 14, 2011 18:52:04 Anthony G. Basile wrote:
2) The choice of a hardened kernel is made by emergeing
hardened-sources, configuring, compiling, booting. There is no use flag
for this choice per se. That means that virtual/linux-sources would
remove the condition RDEPEND:
On Wednesday, July 13, 2011 13:36:29 Ed W wrote:
On 12/07/2011 16:54, Mike Frysinger wrote:
baselayout-1 vs openrc isnt the issue. it's bash array support vs
flat strings. the former is supported in baselayout-1, and should be
supported in openrc. William is talking about dropping
On Tue, Jul 12, 2011 at 07:12, Rich Freeman wrote:
On Tue, Jul 12, 2011 at 1:09 AM, Mike Frysinger wrote:
it would be nice to come up with some level of automated conversion. no
matter how much we say read the docs, there will always be people who do
not. i think the reason the openrc
On Monday, July 11, 2011 14:06:47 Samuli Suominen wrote:
I've never used eclass/tests/ or are familiar with where it's used
it doesnt get used directly anywhere. it's a handy dir for people to put
testsuites of their eclasses and then run manually when they're changing the
eclasses to make
On Monday, July 11, 2011 20:38:49 William Hubbs wrote:
this bug was filed against OpenRc today [1]. The issue was that the user
was attempting to use bash arrays, which, as far as I knew are not
supported in OpenRc.
they've been supported to ease migration from existing configs.
bash arrays
On Tuesday, July 12, 2011 00:54:02 William Hubbs wrote:
On Mon, Jul 11, 2011 at 11:27:59PM -0400, Mike Frysinger wrote:
i dont think we've had openrc in stable long enough to force people to
migrate. so i'd keep the code putting along for now, and add a note to
the feature removal schedule
On Monday, July 04, 2011 13:56:25 Fabian Groffen wrote:
Just one little note, which is that Prefix is stuck with a modified
version of baselayout-1.
why ?
-mike
signature.asc
Description: This is a digitally signed message part.
On Sunday, July 03, 2011 18:49:52 Paul Arthur wrote:
On 2011-07-03, Jonathan Callen a...@gentoo.org wrote:
Peter Volkov wrote:
rm -rf ${D}/usr/share/doc/aria2
|| die
`rm -f` never fails -- if the target does not exist, then rm simply
returns true. (The only reason it would fail
On Tuesday, July 05, 2011 19:05:23 Francesco R wrote:
rm -f chuck norris
rm: cannot remove `Chuck Norris': Operation not contemplated
chuck norris != Chuck Norris
-mike
signature.asc
Description: This is a digitally signed message part.
On Fri, Jul 1, 2011 at 10:44, William Hubbs wrote:
this is a followup thread to the one about openrc being mandatory on all
gentoo systems.
I started a new thread, because I want to figure out which
functions located in /etc/init.d/functions.sh need to be available
regardless of the init
On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote:
Why can't we just split up functions.sh into /lib/output.sh
we're not changing the file name
containing the init script independent (but often gentoo specific)
output stuff, and have functions.sh source this. Output.sh would be
provided by
On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
Also i'm going to add USE_EXPAND for infiniband userspace drivers:
libmlx4
libmthca
libehca
libcxgb3
should it be based on the hardware family rather than the lib name ?
Any objections about moving this stuff to tree?
i object to it
On Thu, Jun 30, 2011 at 15:13, Alexey Shvetsov wrote:
On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote:
On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
Also i'm going to add USE_EXPAND for infiniband userspace drivers:
libmlx4
libmthca
libehca
libcxgb3
use
On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
Ok, the option that I'm looking at now is to set up openrc so
On Thu, Jun 30, 2011 at 17:30, Michał Górny wrote:
On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger wrote:
On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
On Wed, 29 Jun
On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
Honestly, I think a better solution would be to provide a convenience
function library, independent of OpenRC
On Wed, Jun 29, 2011 at 02:12, Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote
On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and was
long ago decided as the canonical public entry point for scripts
external to baselayout (as opposed to a path
2011/6/28 Olivier Crête:
As long as we have Gentoo-style init scripts in the tree, we will need
these functions to be available. So yes, they should probably be in a
separate package from openrc itself to ease the transition to the bright
systemd future.
systemd is limited (acknowledged by
901 - 1000 of 3211 matches
Mail list logo
