Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Friday 21 September 2007, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 12:34:41 -0400: we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons, generally broken gcc or (on amd64) switching back to multilib from 64-bit only profiles, so it /cannot/ be rightly assumed that there's not an existing configuration in /root/. (Whether that's the right way to accomplish such recovery isn't the point; the point is, it's done, by people desperate to get a working system once again who know no other way to do it.) there's a ton of other files that'd get blown away (like everything in /etc) ... anyone who blindly unpacks a stage3 onto their system gets what they deserve in my eyes Chris's idea of testing both USE=build *AND* that there's no existing file there that's going to get blown away, sounds reasonable, regardless of the debate over where the code is eventually placed. except that doesnt address the issue you raised above at all ... the files are going into /root/ ... how they get there is the subject of the debate -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] I've added you as a friend on StumbleUpon
I'm sorry. I visit site and uncarefully click submit. On 9/21/07, Seemant Kulleen [EMAIL PROTECTED] wrote: Can we just unsubscribe this person from this list? This is absolutely ludicrous. I'm really sorry. -- Best regards, Sincerely yours, Yuriy Rusinov
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On 9/20/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: On Thursday 20 September 2007 19:54:16 Donnie Berkholz wrote: econf has default econf failed die message. The following would be sufficient: econf \ --localstatedir=/var \ --sysconfdir=/etc/csync2 Is that so ... when did that appear? Does it happen for all of the package managers? Which functions do this? Where is it documented? The currect PMS draft documents it (for econf only). All three package managers conform to it. As you seem to know, PMS is still a draft and as such can't be considered a valid reference document yet. The econf function is indeed the only one that is officially documented as aborting automatically via die(). You can find this in our Gentoo Development Guide available at devmanual.gentoo.org. In any case it is considered good practice to always add '|| die(message)' after all helper functions. The reason is you can't (or shouldn't) rely on any of them dying properly now or in the future. Plus adding a specific message helps debugging. And about the existence of other package managers, yes, I've heard that rumor too. I've even heard that they may work, but I can't confirm. Denis. ���^����(� ��X��X�
[gentoo-dev] Unmasking udev-115-r5
Hi there! If nobody objects, I will unmask udev-115-r5 (or later if needed) today or tomorrow. There are some rules that got removed between udev-115-r1 and newer version. If you miss anything please contact us. Either these need to be added back, or installed by other relevant packages. One package I know that needs this is aoetools (Bug #193315). Please, if you use or maintain any unusual hardware/driver, please test if there are no regressions in udev-115-r5. One still open regression is this: As we no longer use a wrapper around modprobe blacklisting will not work in all cases, until module-init-tools is patched (Bug #192201). Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: gentoo-x86 commit in net-irc/epic4: ChangeLog epic4-2.8.ebuild
* Raul Porcel (armin76) [EMAIL PROTECTED]: armin76 07/09/20 19:10:45 Modified: ChangeLog Added:epic4-2.8.ebuild Log: Version bump (Portage version: 2.1.3.9) 1.1 net-irc/epic4/epic4-2.8.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild?rev=1.1content-type=text/plain Index: epic4-2.8.ebuild === # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild,v 1.1 2007/09/20 19:10:44 armin76 Exp $ inherit flag-o-matic eutils HELP_V=20050315 DESCRIPTION=Epic4 IRC Client HOMEPAGE=http://epicsol.org/; SRC_URI=ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/${P}.tar.bz2 ftp://prbh.org/pub/epic/EPIC4-PRODUCTION/epic4-help-${HELP_V}.tar.gz mirror://gentoo/epic4-local.bz2 [...] pkg_postinst() { if [ ! -f ${ROOT}/usr/share/epic/script/local ] then elog /usr/share/epic/script/local does not exist, I will now elog create it. If you do not like the look/feel of this file, or elog if you'd prefer to use your own script, simply remove this elog file. If you want to prevent this file from being installed elog in the future, simply create an empty file with this name. cp ${WORKDIR}/epic4-local ${ROOT}/usr/share/epic/script/local ^^ This probably does not exist. Installing a default file and testing in pkg_preinst() might be better. src_install() { [...] newins ${WORKDIR}/epic4-local local.gentoodefault [...] } pkg_preinst() { if [ ! -f ${ROOT}/usr/share/epic/script/local ] \ [ ! -f ${D}/usr/share/epic/script/local ] then elog ... cp ${D}/usr/share/epic/script/local{.gentoodefault,} fi } -- .: Regards Torsten | :. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 21 Sep 2007 03:16:49 -0400: On Friday 21 September 2007, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 12:34:41 -0400: we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons[.] (Whether that's the right way to accomplish such recovery isn't the point[.] anyone who blindly unpacks a stage3 onto their system gets what they deserve in my eyes Agreed, but I was trying to stay strictly on target and not go there (thus the whole whether that's the right way to do it is beside the point thing). I was/am just pointing out that the base assumption isn't always correct. If the policy is to be the you do it, you get to keep the pieces concept, great, but that's rather different than pretending it won't happen. I'd still rather not see anything going into /root based on principle, but the only at stage-build time, and if there's something there, don't overwrite it is IMO a reasonable compromise. (That's quite apart from the question of what package gets the privilege of dealing with it; I've no dog in that fight to have an opinion on.) -- 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 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Gentoo vmware/virtualbox/qemu images
Hi there, At the OpenExpo here in Zurich I got many requests for a vmware image of Gentoo. What do you think of providing a live image in addition to the minimal- and live-cd's? Cheers, Tiziano -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Is anyone from infra around?
maillog: 20/09/2007-13:47:17(-0700): Mike Doty types Georgi Georgiev wrote: The IP for rsync1.jp.gentoo.org changed not too long ago. I notified gentoo-mirrors two weeks ago, but even today, neither the DNS nor the ACL has been updated. Could someone poke the relevant parties and refer them to the message below? http://archives.gentoo.org/gentoo-mirrors/msg_01262.xml infra was aware of the change, but dropped the ball. we've updated our DNS and acls. In the future, would you please either file a bug or send a email to [EMAIL PROTECTED] instead? This list isn't the appropriate place. Ah, yes, I forgot all about it but I did open a bug on 9/11. https://bugs.gentoo.org/show_bug.cgi?id=192064 -- (* Georgi Georgiev (* Dull women have immaculate homes. (* *)[EMAIL PROTECTED]*)*) (* http://www.gg3.net/ (*(* -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 04:23 +, Duncan wrote: Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons, generally broken gcc or (on amd64) switching back to multilib from 64-bit only profiles, so it /cannot/ be rightly assumed that there's not an existing configuration in /root/. (Whether that's the right way to accomplish such recovery isn't the point; the point is, it's done, by people desperate to get a working system once again who know no other way to do it.) Anyone doing anything like this deserves all the suck that comes with it. If some file gets overwritten on their system, so be it. It's not our job to hand hold when people are doing things that are pretty stupid to begin with when anyone with sense would be sure to --exclude things they know they won't want (like /root)... ;] Chris's idea of testing both USE=build *AND* that there's no existing file there that's going to get blown away, sounds reasonable, regardless of the debate over where the code is eventually placed. Thanks, but if the maintainers don't want to do it, there's not much we can do about it. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote: On Thursday 20 September 2007, Chris Gianelloni wrote: Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? no, bash is not a special case why not add an `emerge --config baselayout` to the end of stage3 and i'll do the /root/ default setup in the baselayout ebuild I'd rather not do anything that isn't accomplished automatically by the ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo vmware/virtualbox/qemu images
On Fri, 2007-09-21 at 19:01 +0200, Tiziano Müller wrote: Hi there, At the OpenExpo here in Zurich I got many requests for a vmware image of Gentoo. What do you think of providing a live image in addition to the minimal- and live-cd's? Bug #115902 If you can answer the questions in that bug sufficiently, feel free to revisit this. Also, please contact the team that would likely be doing all of the work to get this sort of thing done prior to bringing up such a proposal, especially when there's already a bug report open for it. ;] We now have a wonderful x86 Release Coordinator, which was one of the blockers in doing a VMware image before. Of course, there's always the what is Gentoo question to determine what we would put in a VM. I don't get this obsession with a live image when someone can boot the LiveCD/LiveDVD on real hardware *or* in VMware. They can even boot the ISO directly and not even have to burn to disk, so people without a DVD burner can still use the LiveDVD. So exactly what problem are we trying to solve with creating an image that cannot be solved with our current media? Where do you plan on storing such a large image? What other media are you planning on us removing to support it? (By the way, I am planning on adding support for creating VMware images to catalyst, so this will eventually be something much easier for us in Release Engineering...) -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 11:37 -0700, Chris Gianelloni wrote: ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. +1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Friday 21 September 2007, Chris Gianelloni wrote: On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote: On Thursday 20 September 2007, Chris Gianelloni wrote: Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? no, bash is not a special case why not add an `emerge --config baselayout` to the end of stage3 and i'll do the /root/ default setup in the baselayout ebuild I'd rather not do anything that isn't accomplished automatically by the ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. as outlined already, it's objectionable in the sense that once a user has entered the system, nothing can be assumed in the automatic case. by the user running `emerge --config baselayout`, we can assume that the behavior it exhibits (for example, setting up files in /root that dont exist from /etc/skel/) is expected. as also explained, tying into USE=bootstrap and USE=build is not correct as that does not represent everything in stage3 and there is no way to detect the stage2-stage3 state vs a normal emerge. the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote: the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. I've already stated my preference for not doing *anything* outside of merging packages in the stages. Were this stage3, I wouldn't care. Anyway, I'd much rather leave everything as it is now than add the emerge --config stuff. You're free to add it to the ebuilds, of course, which would satisfy the people that want it, but I would prefer not add it to the stages, even if it is documented in the Handbook, as it isn't required. Basically, I'd rather we either throw it into the earlier stages, or not do it at all. You've given good reason on why, while technically feasible since we're only caring about bash at this time, it is still a bad idea as it opens us up to yet another slippery slope. I completely see your point, which is why I'm taking the stance that things are best left as they are now. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo vmware/virtualbox/qemu images
Chris Gianelloni wrote: On Fri, 2007-09-21 at 19:01 +0200, Tiziano Müller wrote: Hi there, At the OpenExpo here in Zurich I got many requests for a vmware image of Gentoo. What do you think of providing a live image in addition to the minimal- and live-cd's? Bug #115902 If you can answer the questions in that bug sufficiently, feel free to revisit this. Also, please contact the team that would likely be doing all of the work to get this sort of thing done prior to bringing up such a proposal, especially when there's already a bug report open for it. ;] We now have a wonderful x86 Release Coordinator, which was one of the blockers in doing a VMware image before. Of course, there's always the what is Gentoo question to determine what we would put in a VM. I don't get this obsession with a live image when someone can boot the LiveCD/LiveDVD on real hardware *or* in VMware. They can even boot the ISO directly and not even have to burn to disk, so people without a DVD burner can still use the LiveDVD. So exactly what problem are we trying to solve with creating an image that cannot be solved with our current media? Where do you plan on storing such a large image? What other media are you planning on us removing to support it? (By the way, I am planning on adding support for creating VMware images to catalyst, so this will eventually be something much easier for us in Release Engineering...) The only advantage I see is less than technical people(read windows/osx users) who don't know/are afraid of ISOs and such, yet know how to operate vmware-player. Were we to consider Enterprise Gentoo we'd certainly want to offer it to people interested in gentoo. Think of it more as a marketing tool. As for what to put on it, liveDVD is the only sane choice. That said; It would be awsome if when catalyst can build vmware images, to make a minimal one as well, so groups(maybe xfce4, kde, ) can make their own demos based on that. -- === Mike Doty kingtaco -at- gentoo.org Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- [EMAIL PROTECTED] mailing list