Re: [gentoo-dev] unmounting a filesystem mounted by /init (initramfs)
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
[gentoo-dev] LWE Exhibit badges courtesy of Gentoo
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] Re: Proposed change to base.eclass: patch || die
On Friday 29 July 2005 19:09, Donnie Berkholz wrote: > I just don't see how his comment had anything to do with PATCHES. Gasp - communication is not error free. News to you!? I mistook him, that's all. > Thus, your comment doesn't make any sense to me, either. In my context it does, unfortunately it neither matches yours nor Diego's. Carsten pgpKszUBfJXax.pgp Description: PGP signature
Re: [gentoo-dev] News on PHP5 support on Gentoo
<цитата от="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
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
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] Re: Proposed change to base.eclass: patch || die
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: | On Friday 29 July 2005 18:39, Donnie Berkholz wrote: | |>That doesn't really make any sense. You could just as easily use PATCHES |>if you ran s/patch -p0
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
On Friday 29 July 2005 18:39, Donnie Berkholz wrote: > That doesn't really make any sense. You could just as easily use PATCHES > if you ran s/patch -p0 pgpG7wF0z1ROa.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: | 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. That doesn't really make any sense. You could just as easily use PATCHES if you ran s/patch -p0
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
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
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
On Friday 29 July 2005 11:14 am, Dan Armak wrote: > On Friday 29 July 2005 17:58, Duncan wrote: > > Diego 'Flameeyes' Pettenò posted > > <[EMAIL PROTECTED]>, excerpted below, > > > > on Fri, 29 Jul 2005 16:11:46 +0200: > > > 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 > > > > > > :) > > > > More on the point... what about replacing the current base.eclass code > > with appropriate calls to epatch? This would mean changes/fixes to > > epatch would automatically propagate, while continuing to maintain > > compatibility by keeping the base.eclass functionality around. > > Well as I wrote in my previous reply, I see no objection. I wanted to make > sure this is OK with all base.eclass users, beyond kde.eclass. 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 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
On Friday 29 July 2005 17:58, Duncan wrote: > Diego 'Flameeyes' Pettenò posted > <[EMAIL PROTECTED]>, excerpted below, > > on Fri, 29 Jul 2005 16:11:46 +0200: > > 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 > > > > :) > > More on the point... what about replacing the current base.eclass code > with appropriate calls to epatch? This would mean changes/fixes to epatch > would automatically propagate, while continuing to maintain compatibility > by keeping the base.eclass functionality around. Well as I wrote in my previous reply, I see no objection. I wanted to make sure this is OK with all base.eclass users, beyond kde.eclass. -- 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 pgpa2Zp1GeNXy.pgp Description: PGP signature
[gentoo-dev] Re: Proposed change to base.eclass: patch || die
Diego 'Flameeyes' Pettenò posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 29 Jul 2005 16:11:46 +0200: > 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 > :) More on the point... what about replacing the current base.eclass code with appropriate calls to epatch? This would mean changes/fixes to epatch would automatically propagate, while continuing to maintain compatibility by keeping the base.eclass functionality around. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed change to base.eclass: patch || die
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] Proposed change to base.eclass: patch || die
On Friday 29 July 2005 16:57, Diego 'Flameeyes' Pettenò wrote: > 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? We can. It's just that base.eclass existed long before epatch, so it doesn't use it :-) Anyway, the effective change would be to die if patching fails (and support patchlevels != 0), so my orig question stands. -- 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 pgp1TSvWrd5Iy.pgp Description: PGP signature
Re: [gentoo-dev] Proposed change to base.eclass: patch || die
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
[gentoo-dev] Proposed change to base.eclass: patch || die
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
[gentoo-dev] Re: unmounting a filesystem mounted by /init (initramfs)
On Friday 29 July 2005 02:34, Denis Vlasenko wrote: > "A chroot"? Better provide exact sequence of mounts, chroots which you > execute. Otherwise people need to guess. The relevant commands are: mount -t ext2 /dev/hda1 /memory mount -t unionfs -o dirs=/memory /union mount -t squashfs /dev/hda2 /newroot unionctl /union --add --after 0 --mode ro /newroot chroot /union /sbin/init The most promissing Idea I had till now is to move the ext2 mount and the unionctl past the point were /sbin/rc runs udevstart. I will try it as soon as possible. > Use lazy umount (umount -l) while fs is still visible The busybox umount doesn't support lazy unmount :( Anyway, I don't think that this would work since the unionfs will be using the ext2 partition to the very end and there won't be a chance to unmount it. > vda Thank you very much, Rafael pgp63YPcJNiAz.pgp Description: PGP signature
Re: [gentoo-dev] unmounting a filesystem mounted by /init (initramfs)
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
