Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander:
> On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote:
> > On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wrote:
> > > If people are really interested in keeping a tight, self contained
> > > root, we need to:
> > >
> > > - esta
On 01/07/2012 07:58 AM, Zac Medico wrote:
> That seems like an awfully large initramfs to load into memory for every
> boot, just to have it wiped from memory after switching to the real
> root. It's fine as long as you're not trying to shave every last
> microsecond off of your boot time though.
T
* Walter Dnes schrieb:
> On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote
>
> > This is just our donation, I'm hoping others will join in.
> > For the actual development, half of the resources should be
> > fine, but testing dozens of uncommon scenarios will eat up
> > a multiple of
Hi,
seems more and more software starts to use this:
dev-db/drizzle:tcmalloc
dev-db/haildb:tcmalloc
dev-db/redis:tcmalloc
dev-lang/ruby-enterprise:tcmalloc
dev-libs/libmemcached:tcmalloc
sys-cluster/gearmand:tcmalloc
- Use the dev-util/google-perftools libraries to replace the malloc()
implement
On Fri, Jan 6, 2012 at 4:39 PM, Michael Weber wrote:
> On 01/04/2012 04:42 AM, Arun Raghavan wrote:
>> We've just made it optional in upstream git as well, so unless someone
>> screams murder, I'm going to make esd support an off-by-default USE
>> flag for media-sound/pulseaudio as well.
>>
>
> MU
On 1/7/12 12:42 PM, Ulrich Mueller wrote:
> Some functions in eutils.eclass address very special tasks, so I
> wonder if they shouldn't be split out to dedicated eclasses:
>
> - CDROM functions (cdrom_get_cds, cdrom_load_next_cd).
> These are used by some 40 ebuilds only, most of them in games-*
Some functions in eutils.eclass address very special tasks, so I
wonder if they shouldn't be split out to dedicated eclasses:
- CDROM functions (cdrom_get_cds, cdrom_load_next_cd).
These are used by some 40 ebuilds only, most of them in games-*.
Maybe they could be moved to a dedicated cdrom.e
> On Sat, 7 Jan 2012, Michał Górny wrote:
> On Sat, 7 Jan 2012 11:05:09 +0100
> Ulrich Mueller wrote:
>> Yes, unfortunately some eclasses support DOCS only as an array,
>> others only as a space-separated list.
>>
>> IMHO, when such code is touched, it should be changed in a way that
>> both
On Sat, 7 Jan 2012 11:05:09 +0100
Ulrich Mueller wrote:
> > On Sat, 7 Jan 2012, Michał Górny wrote:
>
> >> Why only "similarly to EAPI 4" and not identical with it? The
> >> latter would follow the principle of least surprise.
>
> > Well, the defaults are identical. And DOCS as non-array wa
> On Sat, 7 Jan 2012, Michał Górny wrote:
>> Why only "similarly to EAPI 4" and not identical with it? The
>> latter would follow the principle of least surprise.
> Well, the defaults are identical. And DOCS as non-array was never
> supported.
Yes, unfortunately some eclasses support DOCS on
On Sat, 7 Jan 2012 00:15:50 +0100
Ulrich Mueller wrote:
> > On Fri, 6 Jan 2012, Michał Górny wrote:
>
> > if [[ ${DOCS} ]]; then
> > dodoc "${DOCS[@]}" || die "dodoc failed"
> > + else
> > + local f
> > + # same list as in PMS
> > + for f in RE
On Fri, 6 Jan 2012 19:41:39 -0500
"Walter Dnes" wrote:
> In my 3 gig /usr directory, over 2 gigs are devoted to
> Gentoo-specific stuff that a binary distro like Redhat does not
> require. What do we do if /usr is read-only? Symlink or bindmount
> onto it?
Remount read/write whenever necessa
On Fri, 06 Jan 2012 22:58:58 -0800
Zac Medico wrote:
> An alternative approach to a having a bulky initramfs "recovery
> partition" like yours would be to put the content of a livecd/usb
> recovery disk onto a spare partition, and configure your lean busybox
> initramfs to mount that as the root
13 matches
Mail list logo
