Diego 'Flameeyes' Pettenò wrote:
skype, blackdown-jdk, rar, opera, openoffice-bin, they are all stripped by
upstream, but passes through portage's prepstrip, so they get stripped
again and the missing debug info is tried to be copied in /usr/lib/debug.
Might want to skip stripping
Mike Frysinger wrote:
Heh heh, same place as FEATURES=noinfo noman nodoc ;)
not really ... those are documented in make.conf
-mike
I have a nasty habit of always looking at make.conf.example instead of the
man page. Plus, er, uh, I used FEATURES=noman ;) Yeah, thats my story
and I'm
Ferris McCormick wrote:
I hesitate to raise my head again, but why not use
FEATURES='-noman' emerge ...
(FEATURES='-noman -noinfo -nodoc' USE='doc' emerge ...
for that matter.)?
I use that sort of thing for, say,
FEATURES='-distcc ccache' MAKEOPTS='-j2'emerge ...
on some specific
Stuart Herbert wrote:
Another point of view are servers, where there's simply no need to
have docs installed on each and every box in a rack. There's no need
to install what a user doesn't need, and having doc and example USE
flags more widely supported means that Gentoo does a better job of
Ciaran McCreesh wrote:
On Sat, 04 Mar 2006 12:04:11 -0600 MIkey [EMAIL PROTECTED] wrote:
| At my job we aim to eventually rid ourselves completely of MS
| products on several thousand (local and remote) desktops and replace
| them with some sort of thin linux client running the citrix
I am contemplating the migration of all of my source code management from a
hacked up in-house system to subversion. I currently use overlays to house
ebuilds and install the actual packages on my target systems.
Instead of re-inventing the wheel, I would like to implement as much as
possible
Paul de Vrieze wrote:
Using this flags on a freshly compiled stage3 (from a stage1, just running
emerge system without setting useflags) I get no blockers at all, when
setting the useflags at the point that system has been recompiled.
Are you suggesting that on fresh installs, after editing
On Saturday 28 January 2006 12:39, Stephen P. Becker wrote:
On second thought, never mind :) I am not sure what you are trying to
point out here in the first place.
He is trying (quite successfully) to show that you are full of shit.
In this particular case, I might have to agree with you
Paul de Vrieze wrote:
The ebuilds are not done in that way, the problem is portage's inability
to handle this. There is no way ebuilds could solve this problem except
not having the dependency. What is needed to solve it is merge perl
without ssl support, merge openssl, merge perl with ssl
Paul de Vrieze wrote:
Would you mind sharing the useflags you mean, and which packages you want
to build? It might be bugs in the packages involved.
My standard USE flags for building a lamp server. No X, no cruft.
USE=-X -alsa -apm -arts -avi -cups -doc -eds -emboss -gnome -gpm -gstreamer
On Thursday 26 January 2006 00:14, Homer Parker spammed:
On Wed, 2006-01-25 at 21:06 -0600, Mikey wrote:
Solutions?
And how many have you tested and submitted patches for? Instead of just
complaining, be proactive and help with the problem you perceive is
there. If it's a viable
On Thursday 26 January 2006 08:02, Chris Gianelloni spammed:
RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml
Except that is for an *already installed* system.
Again, you didn't take into account the simple thing called common
sense. If you're already going to be doing an emerge -e
On Thursday 26 January 2006 08:06, Chris Gianelloni spammed:
The difference in doing from stage1 instead of stage3 is you don't have
to go through a gcc migration to prevent your build from being
unusable. You also go through 1 gcc upgrade (gcc 3.3.5 - gcc 3.4.4),
not 3 (3.3.5 - 3.3.6 -
On Thursday 26 January 2006 08:12, Chris Gianelloni spammed:
Something else that *everybody* seems to be missing is that the *first*
method in the GCC upgrading guide, which is the one that would apply
from a fresh-installed system, seems to be completely overlooked by all
the naysayers.
Mike Frysinger wrote:
Why should system packages (determined by your profile) be present in the
official stage1/3 tarballs?
do you even realize what you're asking ?
-mike
Duh, let me clarify that:
Why should system packages (determined by your profile) be present in the
world file on
Wernfried Haas wrote:
You already complained about that on the forums [1] in a rather
similar thread and yet you still haven't filed a bug report about
Why I explained a couple of posts further down. I could not duplicate the
problem either, I think it went away in 3.4.4-r1. I don't like
Dale wrote:
I thought that if you chose to do a stage 1 install you were on your
own. That was my understanding. If that is true, he is getting support
for something that is not supported, right?
I'm not asking for support, I'm giving it.
--
gentoo-dev@gentoo.org mailing list
Jan Kundrát wrote:
As the person who did the fixes for most of the bugs reported against
the GCC Upgrading Guide, I'd say that I'd remember about that bug
reports on upgrading gcc... Could you please refresh my memory by
providing bug numbers in Gentoo Bugzilla? Were such issues reported to
Wernfried Haas wrote:
If compiling gcc once more is really such a waste of time, you should
consider switching to a binary distribution. ;-)
It is not me claiming that using an installation method that compiles gcc
three times makes sense.
--
gentoo-dev@gentoo.org mailing list
Alec Warner wrote:
Maybe you think fixing a circular dep is easy, I know I do. But when
Joe Shmoe think it's OMG U63r 1337 to install gentoo using a stage1
because it makes his system so awesomely fast ( hence, The Conrad
install on the forums, heh ;) ) and he has no ing clue how any of
Wernfried Haas wrote:
So you complain about a problem that is already fixed as if it still
exists? I really don't get it.
That particular bug was fixed. Using a stage1/bootstrap approach for a
fresh install is a _method_ of installing gentoo that is immune to that
particular bug because it is
Jan Kundrát wrote:
Have you noticed that I'm the reporter of this bug? Just FYI, bug
*wasn't* in the guide but in the underlying eclass/gcc-config causing
automatic switch to newly installed GCC during pkg_postinst. Just by a
coincidence the eclass was updated shortly after gcc/3.4
Jan Kundrát wrote:
MIkey wrote:
A bug, again, that the stage1 installation method was immune to,
How come? (I'm not familiar with toolchain.eclass at all.)
Because the first pass of the bootstrap, that prepares a working gcc/glibc,
uses the bootstrap USE flag and disables all but a few
Mike Frysinger wrote:
On Thursday 26 January 2006 11:06, MIkey wrote:
Why should system packages (determined by your profile) be present in the
world file on official stage1/3 tarballs?
whether they are in the world file itself doesnt really matter
the world target includes all
Stephen P. Becker wrote:
Which is precisely your problem. You are blindly eating your food
without contemplating the contents.
Perhaps I am just contemplating a little deeper than you are.
pre-existing install != installing from a fresh stage. First, running
bootstrap.sh with the new
Jan Kundrát wrote:
MIkey wrote:
A bug, again, that the stage1 installation method was immune to,
How come? (I'm not familiar with toolchain.eclass at all.)
Because the stage1 method bootstraps gcc/glibc and performs the minimum
steps needed to complete the subsequent emerge -e system
Jan Kundrát wrote:
Great, there was a bug. Yeah, there was. Please notice the word was.
It means that it has been fixed and it isn't there anymore. So the
problem got fixed. It's over. Finito. Period. Why are you still talking
about it?
Because Becker needed to be informed about it. I know
On Wednesday 25 January 2006 10:38, Marius Mauch spammed:
that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
would have rebuilt it, not the 3.3 version (unless there is a dep on
3.4 in system).
Does this have something to do with it?
gcc-3.4.4-r1.ebuild:
PDEPEND=|| (
Chris Gianelloni wrote:
Which you won't have to deal with for long, 2006.0 is being worked on as
we speak. The basic jist of this is that what you are seeing is pretty
much expected behavior for bootstrapping using a stage with an older
GCC.
The way I read it, the gcc-3.4.4-r1.ebuild
Jan Kundrát wrote:
Seems like a bit ranting to me. Why do you use unsupported installation
method if you want it simple?
I don't know about Sven, but the reasons I prefer the unsupported
installation method is all outlined here:
http://badpenguins.com/gentoo-build-test/
--
Chris Gianelloni wrote:
You're reading it wrong. The bootstrap USE flag is set during
bootstrap, not the build USE flag. This means libstdc++-v3 (or gcc 3.3)
is required at the bootstrap level. The reason that libstdc++-v3
My mistake, it is just portage that gets that build flag during
Jan Kundrát wrote:
What is most interesting to me about this discussion is the fact than
no one has bothered to offer any facts to back up these assertions. --
author should read any of the wolf31o2's mails about this subject.
I _have_ read his mails about it, had several exchanges with him
On Wednesday 25 January 2006 18:27, Chris Gianelloni wrote:
You didn't follow the Handbook. Your comments about compiling GCC 3
times are completely unbased, since you ran not only an emerge -e
system (which is recommended) but then immediately, and needlessly,
followed it up with an emerge
On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote:
Ahh, so you were the idiot that ran those tests. Congratulations...you
needlessly did a --emptytree world after you had already done
--emptrytree system in order to bloat your results.
RTFM -
On Wednesday 25 January 2006 19:49, Stephen P. Becker wrote:
You aren't serious, are you? Did *you* read the fucking manual *and*
comprehend it? Methinks not...upgrading from 3.3 to 3.4 in a
I didn't write the manual, so save your hubris for whoever did. I just
followed its instructions, I
Mike Frysinger wrote:
note: for those who think they can argue for support of these features to
be kept in Gentoo, you're barking up the wrong tree so dont waste your
time -mike
So, um, when can we expect all hell to break loose? Just a quick check on
my laptop:
On Monday 23 January 2006 04:56, Patrick Börjesson spammed:
The problem with your reasoning is that portage only reports the
highest upgrade (from it's point of view). So if you have package
A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then
portage will chose the highest
On Monday 23 January 2006 12:46, Marius Mauch spammed:
That is _exactly_ how it is intended to work. Normal users will
get A-1.1 when they run emerge -u. Users with a need for stability
will only see A-1.0-s1, and only if it is available for A-1.0.
And for that you have to hack the
On Saturday 21 January 2006 22:39, Marius Mauch wrote:
Check the archives for gentoo-dev and gentoo-server, several
implementation plans have been presented in the not-so-distant past.
However everyone seems to have a slightly different goal he wants to
achieve, so maybe the best would be for
On Sunday 22 January 2006 13:02, Marius Mauch wrote:
Well, posting YAIP (yet another implementation plan) won't really help
either.
Correct, plans never seem to go anywhere in regards to this...
Don't see the goal here, just the constraints. Are you after a
non-moving tree, a tree with just
On Sunday 22 January 2006 16:56, Marius Mauch wrote:
That's not really what you want.
-s updates might (will) be overlaid with version or revision bumps
from time to time, for this to be of any use it has to happen at the
resolver level (visiblity filter).
Normal emerges would
Oops, wrong patch. Here is the correct one...
--- emerge.orig 2006-01-22 18:31:34.0 -0600
+++ emerge 2006-01-22 18:30:01.0 -0600
@@ -162,6 +162,7 @@
params=[selective, deep, self, recurse, empty]
actions=[
clean, config, depclean,
+glsa-only,
info, inject, metadata,
Attached is a patch that adds a new option when syncing, emerge --sync
--no-sync-delete. It simply removes the --force --delete --delete-after
rsync arguments. This will enable users to only add/update their local
portage trees, which is not really possible using excludes... More
importantly if
I have been emailing the published addresses for GLEP 19 for 2 months now
with no success. I am very interested in any ideas or projects that might
help gentoo be more server friendly, in an enterprise environment, for
lack of a better term.
I have an idea towards stabilizing portage for
I recently posted a question in the Portage Programming forum and was told
that this mailing list might be the place to go. Any help would be greatly
appreciated.
I have a custom in-house web based source code/packaging repository system
that I need to integrate into ebuilds. It is kind of
On Sunday 09 October 2005 19:36, John Myers wrote:
Is the id-name mapping 1:1? Since this is an in-house app, can you write
a script which has nice names, perhaps using $_SERVER['PATH_INFO'], i.e.
http://codeserver.wherever.net/pman/package_dl.php/mypackage.tar.gz ? In
Actually this is my
On Sunday 09 October 2005 19:32, Marius Mauch wrote:
Well, ebuilds (and therefore eclasses) can't override anything related
to the fetch process (other than setting RESTRICT and/or SRC_URI). Your
problem has to be fixed server side (assuming you want a proper
solution), as portage *needs* the
47 matches
Mail list logo
