Re: [gentoo-dev] unmounting a filesystem mounted by /init (initramfs)

2005-07-29 Thread Rafael Ávila de Espíndola
On Thursday 28 July 2005 23:50, Jeff Walter wrote:
 Rafael,

  I have no clue if this will work, but maybe try the -n option.  The
 man says that it won't write to /etc/mtab, but I'm hoping it will ignore it
 as well and just go for the mount.  Also, you'll be remounting / as
 read-only effectively, so you won't be able to write /etc/mtab anyways.
The halt.sh script copies /proc/mounts to /etc/mtab before trying to unmount, 
so I think that this is not the problem.

Thanks anyway,
Rafael


pgpDiW4SjDffk.pgp
Description: PGP signature


[gentoo-dev] Proposed change to base.eclass: patch || die

2005-07-29 Thread Dan Armak
Hi all,

base.eclass (which inherited by many other eclasses) has an src_unpack 
supporting patching from patchfiles listed in $PATCHES. However, today, if 
patching fails the process doesn't abort. So I propose:

==
--- base.eclass 11 Jul 2005 15:08:06 -  1.27
+++ base.eclass 29 Jul 2005 13:45:39 -
@@ -35,11 +35,11 @@ base_src_unpack() {
cd ${S}
for x in $PATCHES; do
debug-print $FUNCNAME: autopatch: patching 
from ${x}
-   patch -p0  ${x}
+   patch -p0  ${x} || die Patchfile $x failed 
to apply
done
for x in $PATCHES1; do
debug-print $FUNCNAME: autopatch: patching 
-p1 from ${x}
-   patch -p1  ${x}
+   patch -p1  ${x} || die Patchfile $x failed 
to apply
done
;;
all)


This will make some ebuilds fail which accidentally rely on non-applying 
patches, which is the correct thing to do IMHO. Objections? 

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951


pgp3JxWxcL9Pi.pgp
Description: PGP signature


Re: [gentoo-dev] Proposed change to base.eclass: patch || die

2005-07-29 Thread Diego 'Flameeyes' Pettenò
On Friday 29 July 2005 15:56, Dan Armak wrote:
 base.eclass (which inherited by many other eclasses) has an src_unpack
 supporting patching from patchfiles listed in $PATCHES. However, today, if
 patching fails the process doesn't abort.
Why can't we just use epatch?

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgp5kwlxwyvND.pgp
Description: PGP signature


Re: [gentoo-dev] Proposed change to base.eclass: patch || die

2005-07-29 Thread Diego 'Flameeyes' Pettenò
On Friday 29 July 2005 16:05, Dan Armak wrote:
 Anyway, the effective change would be to die if patching fails (and support
 patchlevels != 0), so my orig question stands.
epatch already takes care of failing, that's why I was thinking about that :)

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpfq6QOcvHaZ.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die

2005-07-29 Thread Diego 'Flameeyes' Pettenò
On Friday 29 July 2005 17:31, Mike Frysinger wrote:
 from a QA point of view, no package should apply a patch, have the patching
 fail, but continue to emerge ... who knows what kind of garbage you'll end
 up with
This can be read as it's good to use epatch ? :P

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgp80OuYzHa9r.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die

2005-07-29 Thread Carsten Lohrke
On Friday 29 July 2005 17:40, Diego 'Flameeyes' Pettenò wrote:
 This can be read as it's good to use epatch ? :P

It's just less text to write PATCHES=foo ..., if you don't have a src_unpack 
function in the particular ebuild.


Carsten


pgpVewopKrcSC.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die

2005-07-29 Thread Diego 'Flameeyes' Pettenò
On Friday 29 July 2005 19:02, Carsten Lohrke wrote:
 Don't get what you want to say... I read Diego's comment as an ironic one,
 that there's no need for the PATCHES variable, which is of course true, but
 you don't have to write src_unpack(){ foo_unpack ; epatch some_patch }
 just for a single patch. I'm a bit surprised by such a comment on this
 triviality.
No I wasn't saying that it's useless to use PATCHES.. actually, if this is 
going to be fixed (the failure stuff) I think I'll start using it more.
What I was saying was that Mike's comment could have been read as just move 
to epatch, if something breaks (like packages dying as the patch fails to 
apply) it was broken QA-wise before.

No irony, really.

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgp9VWpTyj6Nv.pgp
Description: PGP signature


Re: [gentoo-dev] News on PHP5 support on Gentoo

2005-07-29 Thread Alexander Simonov
цитата от=Stuart Herbert
 We're working to provide support for both PHP4 and PHP5 running on the
 same box.  At the moment, this work is available in a tarball overlay
 [1], along with a number of supporting eselect modules [2],[3],[4].  The
 overlay contains new dev-lang/php packages, and PHP extensions under
 dev-php4/ and dev-php5 categories.

 The new dev-lang/php package in the overlay replaces dev-php/php,
 dev-php/php-cgi, and dev-php/mod_php.  The overlay uses a single package
 to deliver all three SAPIs.  The package is SLOTed, allowing PHP4 and
 PHP5 to be installed on the same box at the same time.

 The new dev-lang/php package provides two virtuals:

 * virtual/php - means that the php CLI SAPI is installed
 * virtual/httpd-php - means that php-cgi or mod_php is installed

 There are packages in Portage which currently (R)DEPEND on dev-php/php
 or dev-php/mod_php.  When this overlay has been added to Portage, we'll
 need to fix all of these packages to (R)DEPEND on the virtuals instead.

 In the overlay, PHP extensions move from dev-php into dev-php4/ and
 dev-php5 categories.  Install packages from dev-php4/ if you want to use
 them for PHP4, and from dev-php5/ if you want to use them for PHP5.  The
 category names are provisional; we may go with php4-ext and php5-ext
 when we add all of this stuff into the Portage tree.

 We're part-way through adding all the extensions to the overlay.

 The dev-lang/php package installs into /usr/lib/php[45]/, and does not
 install the php or php-cgi binaries into /usr/bin.  We've written three
 modules for eselect, which you can use to make /usr/bin/php et al
 symlink either to PHP4 or PHP5 as you wish.  The symlinks are not needed
 by any of the packages in the overlay.

 PEAR support is next on the list.  We will make the overlay work with
 the existing dev-php/PEAR-* packages in Portage.  dev-php/PEAR-PEAR will
 install the 'pear' command; it won't be installed by dev-lang/php (we'll
 make dev-lang/php RDEPEND on dev-php/PEAR-PEAR so that pear continues to
 be installed by default).

 After that, we have a lot of testing to do, some documentation to write,
 and we need to decide on the best way to add these packages into Portage
 to replace the existing PHP packages.  Nothing has been decided yet, but
 it would make sense for the dev-php/php-4* packages and the new
 dev-lang/php package to both exist as stable packages for a transitional
 period, whilst the masked dev-php/php-5* packages would be dropped in
 favour of the dev-lang/php package.

 Once the packages are in the Portage tree, it will take a bit of time to
 mark them stable.  We hope to have x86 and ppc stable a month or so
 after the release of php-5.1.0, but that is an aspiration, not a
 commitment.

 To keep up to date with the latest news on this work, follow my blog
 postings [5].  The best way to provide feedback is to pop into
 #gentoo-apache on irc.freenode.org.

Yes!
You are greate man
Thanks!!!

-- 
WBR, Alexander Simonov
Ukrainian Gentoo Community Coordinator

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] LWE Exhibit badges courtesy of Gentoo

2005-07-29 Thread Corey Shields

If you happen to be registering for an Exhibit Hall badge for the upcoming 
LinuxWorld Expo in San Francisco, use priority code N0339 to let them know 
that you're coming to support Gentoo!

The badges are free if registering in advance, and $35 at the door.  However, 
if you use this code the door fee is waived. (or hunt me down during that 
week for an exhibit hall pass)

We should have a nice booth this year.  Thanks to dostrow, we will have 
Powered by Gentoo Linux stickers to hand out, along with a couple of demos 
(an x86 and a pegasosppc demo).

Looking forward to meeting many of you there!

Cheers!

-- 
Corey Shields
Gentoo Linux Infrastructure Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields


pgpEB6ALeNopL.pgp
Description: PGP signature


Re: [gentoo-dev] unmounting a filesystem mounted by /init (initramfs)

2005-07-29 Thread Ned Ludd
On Fri, 2005-07-29 at 08:48 -0300, Rafael Ávila de Espíndola wrote:
 On Thursday 28 July 2005 23:50, Jeff Walter wrote:
  Rafael,
 
   I have no clue if this will work, but maybe try the -n option.  The
  man says that it won't write to /etc/mtab, but I'm hoping it will ignore it
  as well and just go for the mount.  Also, you'll be remounting / as
  read-only effectively, so you won't be able to write /etc/mtab anyways.
 The halt.sh script copies /proc/mounts to /etc/mtab before trying to unmount, 
 so I think that this is not the problem.

In the embedded world /etc/mtab is often a symlink to ../proc/mounts and
everything works well.

-- 
Ned Ludd [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list