I am trying to build a system that uses a unionfs as root. The init
script is based on the one used by gentoo and uses initramfs. The
problem is how to remount the unionfs constituents read only during
halt.
cat /proc/mounts displays /dev/hda1 (ext2) mounted rw in /memory. The
problem is that /mem
On 7/28/05, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> No. It isn't. We've added unionfs support for CD boots, not for normal
> installations.
>
> Rafael, please check http://bugs.gentoo.org/show_bug.cgi?id=99682 for
> the initial patch we came up with.
I have just tested it with baselayout-1
On 7/28/05, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> this is already added/being added for 2005.1
One problem that I have found: how to unmount /memory when using
initramfs? Since the /dev is not moved umount says that /dev/hda1 is
not mounted...
> join #gentoo-releng for more info
I don't hav
I am building a small system based on gentoo. The system is installed
in a squashfs and has a ext2 added via unionfs. The ext2 is in hda1
and the squashfs is in hda2.
I was very pleased to find out that very little tweaking was necessary
in the linuxrc and initrd.scripts of genkernel 3.3. In initr
On 5/18/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> How is it that you know those two greps will catch everything?
I don't. In fact I am sure they don't catch everything: given a Turing
machine one can replace all halts by a "do something with flex". So it
is undecidable if x11 rdepends on fle
On 5/18/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Let me know once you've tested removing each thing individually, then
> run every application in the X distribution in every configuration to
> show that there are no dependencies.
Thats a lot of work, but I can offer a smaller evidence that
I noticed that xorg-x11-6.8.2-r1.ebuild has a very big RDEPEND. For
example, is there really a need for flex after xorg has been compiled?
Thanks for comments,
Rafael
The RDEPEND:
>=sys-libs/zlib-1.1.3-r2
>=sys-devel/flex-2.5.4a-r5
>=dev-libs/expat-
Why does get_number_of_jobs reduces the number of parallel jobs to "to
ensure successful merge"? In my humble opinion if a package fails to
compile with a large -j then the ebuild should know the limit and
reduce it.
An example of the problem: My machine has one processor but there are
many icecc
I know that the libstdc++v3 is intended to help in the migration to
gcc 3.4. But I also find it usefull to build very small installations
without gcc.
For this reason I have ported the ebuild to gcc 3.4.3. Should I submit
a bug report with it?
Rafael Ávila de Espíndola
# Copyright 1999-2005 Gento
