Re: [gentoo-dev] What to do with GCC 4 related bugs?
On Tuesday 03 January 2006 01:43, Dirk Heinrichs wrote: Am Montag, 2. Januar 2006 21:45 schrieb ext Mark Loeser: Chris White [EMAIL PROTECTED] said: The policy is pretty much if it doesn't compile, you get to fix it. If you have a patch then report it to bugzilla. Actually, since I plan on moving this to ~arch soon, please report all bugs to us, even if you don't have a patch. I'd like to know of everything that is broken. OK, expect the reports within the next few hours. Bye... just make sure you search to see if one hasnt already been filed ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ChangeLogs and rsync time
On Tuesday 03 January 2006 09:29, Paweł Madej wrote: Chris Gianelloni wrote: On Mon, 2006-01-02 at 13:20 -0600, Lance Albertson wrote: I'm sorry, but I still think the idea of simply RSYNC_EXCLUDEing the ChangeLog by default would be a much better solution. I didn't know before that it is possible, but after some reading man rsync I've added */*/ChangeLog line to my RSYNC_EXCLUDEs file you could just do 'ChangeLog' -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] invalid virtual/use flag
On Tuesday 03 January 2006 19:13, Ricardo Loureiro wrote: If I encounter such situations should I create a bug or report them here? either works ive removed the entries -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Tuesday 03 January 2006 11:05, Grant Goodyear wrote: Henrik Brix Andersen wrote: [Sun Jan 01 2006, 05:35:26PM CST] On Sun, Jan 01, 2006 at 05:30:01AM +, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I would like GLEP 45 [1] - GLEP date format - to be discussed and voted on. I doubt that GLEP 45 really needs a vote by the full council. The lead GLEP editor's decision should probably suffice for something this trivial. (Recall that the GLEP process is that the GLEP author let's the GLEP editors know when a GLEP is ready to go up for approval, and that it is generally the editors who work out precisely who needs to approve the thing.) that's fine by me ... although i doubt anyone on the council would be against it and it'd be voted in with little to no discussion ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Anyone still maintaining dev-libs/dietlibc ?
On Friday 06 January 2006 16:13, Christian Heim wrote: devs who contributed/touched the ebuilds: - Ned Ludd [EMAIL PROTECTED] - Mike Frysinger [EMAIL PROTECTED] i regret ever touching this package ... and i'm pretty sure Ned feels the same way ... i'm 100% uClibc now ;) If no one complains, I'll take this package. check with hansmi/dragonheart, but i know i dont care -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips
On Friday 06 January 2006 08:07, Alin Nastac wrote: Given the lack of interest manifested by mips team regarding net-proxy/squid and its security bumps, I propose to remove the last mips-stable version of this package - 2.5.10-r2 - marked as such by hardave on September the 4th 2005. Objections anyone? any reason you felt the need to e-mail gentoo-dev ? this is a pure security/mips issue, the rest of gentoo dev could care less -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need help fixing executable stack
On Friday 06 January 2006 12:30, Thomas Cort wrote: When emerging wxGTK-2.4.2-r4 on alpha I get a QA message about executable stacks ( http://bugs.gentoo.org/113119#c10 ). I read the GNU Stack Quickstart ( http://gentoo.org/proj/en/hardened/gnu-stack.xml ). well you didnt read far enough down :) http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap7 we are not able to qa check all arches at the moment for executable stacks due to toolchain limitations, alpha included ... that means dont waste your time trying to fix it i've already updated portage to only warn about exec stacks on fully supported architectures, that version just has yet to be released -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A New Linux Way
On Monday 09 January 2006 22:40, Mark Stewart wrote: Please contact me if you are interested. thank you captain douche please unsubscribe yourself from our lists and never stop by again -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Jan/2006 council agenda
for this month: * GLEP 45 - GLEP date format * disallow multiple votes per person (from ciaranm) http://marc.theaimsgroup.com/?t=11346783302r=1w=2 * global gentoo goals for 2006 for next month: * periodically freezing the tree for new packages (from carlo) i miss anything ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 13:42, Greg KH wrote: On Thu, Jan 05, 2006 at 07:56:30AM -0500, Chris Gianelloni wrote: You guys are more than welcome to go apply at Red Hat or Novell. Some of us already work for companies that produce other Linux distributions or support the companies that do. :) i know i would if i could get hired ;) -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] pending dooooooom of use.defaults
as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support existing stable users wont be affected as the 2.0.x versions will continue to carry support for this, but some of you stable users may notice some USE flags suddenly disappearing to recap, use.defaults inserts USE flags for you based upon what packages you have installed when you havent declared a preference. for example, if you have neither '-cups' or 'cups' in your USE (either in your make.conf, profile, env, whatever), but you do have the net-print/cups package installed, portage will add 'cups' to your USE -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 11:15, Kalin KOZHUHAROV wrote:
Or is it because I always had:
USE=-* ${MY_USE}
in /etc/make.conf?
yes
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 15:13, solar wrote: On Fri, 2006-01-13 at 06:57 -0500, Mike Frysinger wrote: as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support I see this as a good and bad thing. Good in one hand that less autojunk would be enabled like python/perl bindings not being added to every program on your system that supports it. Bad in the other hand I see the state of profiles getting worse=more bloated. i dont really see the profiles getting any more USE flags than they already have ... as for bloated, i see it as being a more-than-worth-it trade off when it comes to stability a profile-based USE will always stay the same while a autouse-based USE may fluctuate greatly based upon what the user emerges from day to day The autouse itself is not a bad feature or idea if it were used properly. there is no used properly or improperly when it comes to use.defaults -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Initng in vserver guests
On Saturday 14 January 2006 10:26, Bruno wrote: What are your thoughts about this? take it upstream, they have a bugzilla make it a configure option and we'll add a use flag `use_enable vserver` or some such junk otherwise, the answer is no ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Sunday 15 January 2006 01:19, Joshua Baergen wrote: Mike Frysinger wrote: - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS=-O -g and DEBUG_LDFLAGS=) Nothing huge, but won't this fry certain systems (SPARC iirc, among others) that need the -march information for the code to even run? If so, the solution would have to grab march/mcpu/mtune values and add them to the debug cflags. then we could set default DEBUG_CFLAGS in the profiles -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Sunday 15 January 2006 13:25, Dan Meltzer wrote: What would happen on subsequent merges or upgrades if --debug-build was omitted? Would there be a way (/etc/portage file perhaps?) to enable debug builds on a permanent basis? i didnt think anyone would want this but it'd be trivial to add a new feature (say debug-build) which you could then use with per-package-env -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pdf use flags
On Monday 16 January 2006 16:54, Marius Mauch wrote: So unless there are any objections to this I'll make the change this weekend. dooo it -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Initng in vserver guests
On Monday 16 January 2006 16:36, Bruno wrote: Will not need any special behavior on ebuild side (as distro is detected automatically; works also when building system in chroot) WFM, thanks -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Tuesday 17 January 2006 10:11, Richard Fish wrote: On 1/15/06, Olivier Crête [EMAIL PROTECTED] wrote: Why not use the splitdebug instead of nostrip? And make building with -g the default, then tell small HD users how to disable it in the docs. And it needs to disable -fomit-frame-pointer at least on x86. I've been building my whole system with splitdebug and yes it does take a lot of space, but its really useful. a good idea ... No argument against splitdebug, but my guess is that it would be useless for 99.97% of users, and would lead to complaints on -user about how much disk space gentoo consumes compared to insert least favorite distribution here, so it should not be the default. ... and we just make it dynamic to get best of both worlds if user has splitdebug in FEATURES, then we skip adding nostrip to FEATURES, but if user has -splitdebug in FEATURES, we add nostrip to FEATURES -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test depends
On Tuesday 17 January 2006 13:53, Doug Goldstein wrote: Basically some packages have additional depends to be able to run the tests. So if a user has FEATURES=test, then they need additional depends. For example, gstreamer http://bugs.gentoo.org/show_bug.cgi?id=115448 and expat (ghetto fix by me in tree) have depends on dev-libs/check to be able to run FEATURES=test. Is there anyway to properly do these depends or is the ghetto fix in expat the best solution thus far? Or go the way of other packages and have DEPEND=dev-libs/check. atm the fix is to use the test USE flag -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Does anyone want|need a static (lib)perl still?
On Wednesday 18 January 2006 09:27, Drake Wyrm wrote: Michael Cummings [EMAIL PROTECTED] wrote: On Tue, 2006-01-17 at 20:18 -0800, Drake Wyrm wrote: Portage is not the only important system tool. Some of us actually use Perl. Please do not be with the breaking. Is this to say there is a valid need for both libperl.a and libperl.so on your box? Personally, no, but others do. I should have been less ambiguous (and obnoxious) in my initial response. Please don't assume that just because _you_ don't need a static Perl, that _nobody_ needs a static Perl. in other words, you have no idea whether you use libperl, you just saw a perl thread and paniced because you thought perl was going to break -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Sunday 15 January 2006 01:11, Mike Frysinger wrote: this topic has come up before too many times and has yet to be solved, and we have too many hacks in place ok, so after sitting on the list for a while and accumulating feedback, how about this: - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* enables additional runtime code (such as assert()'s or helpful debug output) ... if you're confused by what i mean, run `USE=debug emerge nano` and then run `nano` - we add an emerge flag (say '--debug-build') which adds debug-build to FEATURES - if debug-build is in FEATURES, then the following happens: * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to DEBUG_CXXFLAGS (and in the future, we can add more variables as the need comes up) * if user already has FEATURES=splitdebug, then do not add nostrip * if user does not have FEATURES=splitdebug, then add nostrip to FEATURES - we will set sane debug defaults in the base profile: * DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g * DEBUG_LDFLAGS= - subprofiles can tweak these values as they see fit (or as required) i'll go ahead and start implementing framework for this in the meantime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:52, Mark Loeser wrote: Please lets avoid this assumption. I'd love to make it so we never make this assumption anywhere in the tree so that we could actually build GCC without pie or ssp, instead of generating all of the GCC profiles for every user. pie is in upstream gcc so your argument here is INVALID please move along, kthx -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:33, solar wrote: On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g Mike, how about DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g -fno-stack-protector -fno-pie All Gentoo properly supported toolchains support the last two flags and it ensures that debugging almost works for hardened users too. I'd say I could just run with the extra flags in the hardened/* profiles but it seems a good portion of the users these days seem to be vanilla users using 'gcc-config 1' to please the whiners, we can use: -O -g -fno-pie and keep the -fno-ssp in hardened profiles -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:17, Olivier Crete wrote:
On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
- if debug-build is in FEATURES, then the following happens:
* auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS
to DEBUG_CXXFLAGS (and in the future, we can add more variables as the
need comes up)
What about: CFLAGS=${CFLAGS} ${DEBUG_CFLAGS} .. otherwise bugs that
only appear after certain GCC optmisations may go away...
then we'll deal with that ... we're trying to debug bad code, not bad code
generation
- we will set sane debug defaults in the base profile:
* DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g
I'd propose -fno-omit-frame-pointer -ggdb for x86/amd64 and -g for
default...
why ? -fomit-frame-pointer is only used with -O whenever it doesnt interfere
with debugging ... in other words, -O on x86 will not imply
-fomit-framer-pointer
and as noted, x86_64 doesnt suck like x86, so this isnt an issue for amd64 :)
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Friday 20 January 2006 01:25, Harald van Dijk wrote: On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* enables additional runtime code (such as assert()'s or helpful debug output) ... I'd like to see cases such as use debug append-flags -DDEBUG explicitly mentioned, please. I'm sure you meant that this is okay, but to avoid confusion, could you actually say so? (Or, if I'm completely misunderstanding, tell me it's not okay. :) that depends, does your code actually have things like #ifdef DEBUG debug stuff #endif -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-libs/xpm
On Sunday 22 January 2006 12:31, Marcelo Góes wrote: On 1/22/06, Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 22 January 2006 09:48, Marcelo Góes wrote: media-libs/xpm is currently just a dummy ebuild that depends on virtual/x11. All ebuilds in the tree have already been adapted to depend directly on virtual/x11 and/or modular X equivalents. Thus I'm scheduling it for removal within a week or so if nobody complains. you cant remove the package until you update the things depending on it xpm is no longer a dummy package, it's x11-libs/libXpm now in modular X terms Like I said, this has already been taken care of. sorry, i'm a tool There are no more packages that still depend on media-libs/xpm. Instead, they depend either on virtual/x11 or x11-libs/libXpm and whatever else your scripts show... i have no scripts -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Saturday 21 January 2006 23:12, Marius Mauch wrote: Mike Frysinger wrote: On Sunday 15 January 2006 01:11, Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds debug-build to FEATURES IMO this is pointless and redundant. its purpose is to handle cases where user wants to always have a package built in this manner (ferringb mentioned it as a possibility and someone else mentioned they would like it) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuilds and USE flags
On Tuesday 24 January 2006 11:27, Rene Zbinden wrote: I am writing an ebuild for a program written in perl. This program has the dependency of gnuplot but with the png flag enabled. What is the gentoo way to enable this USE Flag for gnuplot when I emerge my program. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 18:14, Diego 'Flameeyes' Pettenò wrote: What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then the answer is no from my pov -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 19:13, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 00:32, Mike Frysinger wrote: if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then the answer is no from my pov Can you at least read all my mails till the end before replying next time? it wouldnt matter in this case -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 19:17, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 00:48, Stephen Bennett wrote: We've discussed this several times in the past, and every time the answer has been that in the ebuild environment `sed` is gnu sed-4. It's the only sane way to do things, since certain other platforms ship retarded versions of sed. And as there's no current way to fix the invokation of sed from within xargs or find yes there is add a 'sed' wrapper to the portage bin dir which simply does: exec gsed $@ , I'm not going to ask to change _all_ the calls of sed, but just the ones done through those two or other scripts and things that won't honour aliases in bashrc. that's a pita -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Tuesday 24 January 2006 17:56, Donnie Berkholz wrote: Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds nostrip to FEATURES and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS=-O -g and DEBUG_LDFLAGS=) I'm having a tough time finding this in the thread -- how can I ensure a certain group of packages are always built with debugging, if I don't want my whole box built that way? that would require per-package env: http://bugs.gentoo.org/show_bug.cgi?id=44796 at which point you would just add 'FEATURES=debug-build' to whatever packages you want -mike -- gentoo-dev@gentoo.org mailing list
Re: Environement categories (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tuesday 24 January 2006 01:44, Brian Harring wrote: Might I suggest this one just get shelved for a while? everything that gets shelved portage way stays that way for *quite* a while i would be ok with implementing the back end (i.e. FEATURES=debug-build) but putting off the front end (i.e. emerge --debug-build) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:16, Georgi Georgiev wrote: maillog: 25/01/2006-00:14:13(+0100): Diego 'Flameeyes' Pettenò types What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). Am I stupid or did I miss something? well, i cant really verify you arent stupid, but ... [ebuild R ] sys-apps/sed-4.1.4 [EMAIL PROTECTED] ~ $ gsed bash: gsed: command not found Diego was mistaken here ... probably my fault because i lied to him at some point on irc, who knows for sure ... at any rate, the sed ebuild does not install 'gsed' on GNU systems -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
On Wednesday 25 January 2006 07:30, Sven Köhler wrote:
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
so that a clean system is built with gcc 3.4 only!
it wouldnt anyways as the version of gcc isnt changed unless the user does so
so unless you ran `gcc-config 3.4.4`, your gcc version would still be 3.3.x
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 03:21, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 02:23, Ciaran McCreesh wrote: If there are any hardcoded calls to /usr/bin/sed, it is reasonable for you to ask for them to be fixed. For any others, use a wrapper script. I think the wrapper script idea was turned down by someone from portage IIRC. Anyway it's not exactly the cleanest solution: while it would have an immediate effect with no work required, it will increas, and not decrease) the number of assumption portage does. I think this is one of the worse things that can be done at this point. what kind of assumptions ? the kind where we, as ebuild writers, assume the system tools have a lot of features ? assuming `sed` in Gentoo is a GNU/sed is just fine by me -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: coreutils: deprecated behavior not so deprecated
On Wednesday 25 January 2006 01:54, MIkey wrote: 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? i added the version last nite so all unstable users will be seeing this now Just a quick check on my laptop: so file a bug -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
On Wednesday 25 January 2006 11:38, Marius Mauch wrote:
On Wed, 25 Jan 2006 17:23:20 +0100
Sven Köhler [EMAIL PROTECTED] wrote:
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
But doesn't bootstrap.sh rebuild gcc? I have to take a look again,
but i think bootstrap.sh rebuilt gcc 3.4 only - not 3.3.
gcc 3.3 was only rebuilt during emerge -e system.
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).
the -e system step probably rebuilt both
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
On Wednesday 25 January 2006 15:44, Sven Köhler wrote:
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
So i understand what you're trying to tell me, but bootstrap.sh makes
the choice already:
bootstrap.sh only rebuilds gcc 3.4
(i looked that up in my emerge.log)
you're looking at bootstrap wrong ... it forces a few native packages to the
newest version available
in this case, bootstrap emerges gcc and portage picks the best one ...
gcc-3.4.4
so that a clean system is built with gcc 3.4 only!
it wouldnt anyways as the version of gcc isnt changed unless the user
does so
so unless you ran `gcc-config 3.4.4`, your gcc version would still be
3.3.x
Right, and it will be the gcc 3.3 included in the stage1 tarball - even
if a new gcc 3.3 version is available. So if the user wants to use gcc
3.3, he has to manually update gcc (for example to have features not
included in the gcc from the stage1 tarball).
if a user wants gcc-3.3 but not gcc-3.4, then it's their responsibility to
mask it accordingly via /etc/portage
So no matter if the user wants gcc 3.3 or gcc 3.4, the user has to do
something manually to get a proper gentoo.
i dont know what you mean by proper
at any rate, this will all fix itself when 2006.0 is released
If i may suggest something, then i would recomm that the user is abled
to specify the gcc installed by bootstrap.sh like this:
bootstrap.sh --gccspec =sys-devel/gcc-3.3*
no, use /etc/portage
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Wednesday 25 January 2006 15:47, Stuart Herbert wrote: The csh package currently has a maintainer who is an active Gentoo developer; have you spoken to taviso first to find out whether he wants to remove csh from the tree? last we talked with taviso he had no problem punting csh -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Wednesday 25 January 2006 21:40, Sven Köhler wrote: I expected the result of these steps to be a clean system. What do i mean with a clean system? Actually i thought, that i mean the result of a emerge -e system - but i know now, that this is not what i mean. For example emerge -e system sometimes choses to install gcc-3.3 instead of the default libstdc++-v3. what you want to happen just isnt feasible at this point in time (if it ever will be) portage does not automatically change the version of gcc across major versions ... this is done on purpose as there is no way of knowing whether the user wants the new version of gcc to be the default system one or whether they are just installing a new one for fun you want bootstrap.sh to basically automatically run `emerge gcc emerge prune gcc` ... this is not doable as packages may be tied to the older version of gcc ... and in fact, python itself currently links against libstdc++, so if bootstrap followed the automated steps listed above, you'd end up with a broken python (and thus a broken emerge) thus, in order to get a clean system you're so keen on, you need to run bootstrap.sh to get a 3.4 compiler, switch your default compiler to 3.4, rebuild anything that is linked against 3.3 with 3.4, prune 3.3 from your system, and then continue on with the `emerge -e system` -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 08:54, Sven Köhler wrote: Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Thursday 26 January 2006 05:43, Paul de Vrieze wrote: Another candidate would be the strip binary which might be called by certain makefiles instead of being portage controlled. packages should never strip, only portage should -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 10:42, Mikey wrote: On Thursday 26 January 2006 08:16, Mike Frysinger spammed: On Wednesday 25 January 2006 22:07, Mikey wrote: On Wednesday 25 January 2006 20:53, Donnie Berkholz wrote: Name one of those that isn't in 'system'. [EMAIL PROTECTED] ~ $ emvp -e system | grep -e gzip -e linux-headers -e nano -e gettext -e glibc [ebuild N] sys-kernel/linux-headers-2.6.11-r3 0 kB Your point? My point was that they don't belong there. actually, they should 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 13:23, Sven Köhler wrote: Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 So let me summarize that again: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. currently, yes, that is the intended behavior -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 11:16, Paul de Vrieze wrote: On Thursday 26 January 2006 16:34, Mikey wrote: And those instructions have nothing whatsoever to do with common sense from a new, or even experienced users perspective. Knowing that a gcc upgrade will break libtool is not common sense, nor is it commonly known. It will not break libtool. it does and it doesnt /usr/bin/libtool hardcodes the paths to internal gcc files normally this isnt an issue as most packages now generate and use their own copy of libtool so that they always have the current toolchain information a few older packages however (jpeg comes to mind) use the system libtool instead of bundling their own -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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 the packages listed in the world file plus everything that is part of the system target ... portage adds them together automatically -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 14:00, MIkey wrote: 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 the packages listed in the world file plus everything that is part of the system target ... portage adds them together automatically /var/lib/portage/world should only contain the names of packages you explicitly emerge (without --oneshot). As far as I know an official stage3 tarball should only contain packages installed as a result of a system emerge, which should never enter them into the world file. they're probably recorded since tools like bootstrap.sh do not utilize --oneshot either way, the whole issue is moot as i already pointed out, as portage will add all 'system' packages to the 'world' target automatically (and i dont mean they are recorded in the world file) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Thursday 26 January 2006 11:06, Paul de Vrieze wrote: On Thursday 26 January 2006 14:51, Mike Frysinger wrote: On Thursday 26 January 2006 05:43, Paul de Vrieze wrote: Another candidate would be the strip binary which might be called by certain makefiles instead of being portage controlled. packages should never strip, only portage should ebuilds don't, some makefiles do. exactly, thus i said packages and not ebuilds Sometimes when calling the strip option of install. A strip wrapper prevents this broken behaviour once and for all. It could even be written to show a big fat warning. i know ... it isnt uncommon to see like `install -s` or `$(STRIP)` in packages and those need to be removed while this is a neat idea (catching those people who do `install -s`), i'm not sure it'd work as there isnt a clean way to detect whether it's the package calling `strip` or the ebuild/portage ... you could try passing info via an env var, but that's no fun :) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 14:08, Mike Frysinger wrote: On Thursday 26 January 2006 14:00, MIkey wrote: /var/lib/portage/world should only contain the names of packages you explicitly emerge (without --oneshot). As far as I know an official stage3 tarball should only contain packages installed as a result of a system emerge, which should never enter them into the world file. they're probably recorded since tools like bootstrap.sh do not utilize --oneshot we've tweaked bootstrap.sh to use --oneshot now -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 13:23, Sven Köhler wrote: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. ok, i looked into this some more and ran some tests ... long and short of it is that the behavior i discussed before applies only in a stage3 and beyond ... the gcc-config logic is specifically tweaked during bootstrap and build (i.e. stage1 and stage2), thus everything i said wrt to automatic switching of gcc has no bearing on this discussion ive chatted with wolf and the real fix here is to change the 'emerge clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way when you emerge a new SLOT-ed version of gcc, the old stripped down version in stage1 is automatically pruned -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Friday 27 January 2006 03:17, Paul de Vrieze wrote: On Thursday 26 January 2006 19:53, Mike Frysinger wrote: On Thursday 26 January 2006 11:06, Paul de Vrieze wrote: Sometimes when calling the strip option of install. A strip wrapper prevents this broken behaviour once and for all. It could even be written to show a big fat warning. i know ... it isnt uncommon to see like `install -s` or `$(STRIP)` in packages and those need to be removed while this is a neat idea (catching those people who do `install -s`), i'm not sure it'd work as there isnt a clean way to detect whether it's the package calling `strip` or the ebuild/portage ... you could try passing info via an env var, but that's no fun :) Well, portage uses prepstrip to do stripping. As such this prepstrip script could take care not to use the wrong strip binary. Shouldn't be hard to do even without hardcoding the path to the strip binary. it does ... but in case it cant find a fully qualified strip binary (CHOST-strip), it will fall back to plain old `strip` For ebuilds calling strip, I see no reason why they would. If at some point it is found necessary, it would be easy to have an estrip command to do this. even ebuilds shouldnt be calling strip they can call `prepstrip files or dirs` -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated
On Monday 23 January 2006 23:04, Mike Frysinger wrote: for those who dont know what i'm talking about, consider: tail -1 head -1 some other stuff i cant remember it would seem i lied about this (at least the first two still work) the source code was refactored and i assumed this to mean they cut out the backwards compat code without looking deeper into the source in case they had actually moved it, my bad -mike -- gentoo-dev@gentoo.org mailing list
Re: Environement categories (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Wednesday 25 January 2006 02:26, Brian Harring wrote: On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote: i would be ok with implementing the back end (i.e. FEATURES=debug-build) but putting off the front end (i.e. emerge --debug-build) Front-end doesn't matter, it's the back-end that's the concern. Clean up the backend in stable, and it's fine- hence the shelve it; fix the backend instead of tagging it half way in. what exactly is half way about the attached patch ? -mike Index: pym/portage.py === --- pym/portage.py (revision 2604) +++ pym/portage.py (working copy) @@ -1263,6 +1263,23 @@ if usersandbox in self.features: self.features.remove(usersandbox) + if debug-build in self.features: + # the profile should be setting these, but just in case ... + if not len(self[DEBUG_CFLAGS]): +self[DEBUG_CFLAGS] = -g -O +self.backup_changes(DEBUG_CFLAGS) + if not len(self[DEBUG_CXXFLAGS]): +self[DEBUG_CXXFLAGS] = self[DEBUG_CFLAGS] +self.backup_changes(DEBUG_CXXFLAGS) + # replace user vars with debug version + for var in [CFLAGS,CXXFLAGS,LDFLAGS]: +self[var]=self[DEBUG_+var] +self.backup_changes(var) + # if user has splitdebug, the debug info will be auto saved for + # gdb, otherwise we want to keep the binaries from being stripped + if not splitdebug in self.features: +self.features.append(nostrip) + self.features.sort() self[FEATURES] = .join([-*]+self.features) self.backup_changes(FEATURES) Index: pym/portage_const.py === --- pym/portage_const.py (revision 2604) +++ pym/portage_const.py (working copy) @@ -40,7 +40,7 @@ CONFIG_MEMORY_FILE = PRIVATE_PATH + /config INCREMENTALS=[USE,USE_EXPAND,USE_EXPAND_HIDDEN,FEATURES,ACCEPT_KEYWORDS,ACCEPT_LICENSE,CONFIG_PROTECT_MASK,CONFIG_PROTECT,PRELINK_PATH,PRELINK_PATH_MASK] -STICKIES=[KEYWORDS_ACCEPT,USE,CFLAGS,CXXFLAGS,MAKEOPTS,EXTRA_ECONF,EXTRA_EINSTALL,EXTRA_EMAKE] +STICKIES=[KEYWORDS_ACCEPT,USE,CFLAGS,CXXFLAGS,LDFLAGS,DEBUG_CFLAGS,DEBUG_CXXFLAGS,DEBUG_LDFLAGS,MAKEOPTS,EXTRA_ECONF,EXTRA_EINSTALL,EXTRA_EMAKE] EBUILD_PHASES = [setup,unpack,compile,test,install,preinst,postinst,prerm,postrm] EAPI = 0
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:37, Sven Köhler wrote: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. ive chatted with wolf and the real fix here is to change the 'emerge clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way when you emerge a new SLOT-ed version of gcc, the old stripped down version in stage1 is automatically pruned I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:50, Sven Köhler wrote: I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? ??? I just wanted to say Thank you for both fixes. sorry i forgot the /joke -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 11:15, Diego 'Flameeyes' Pettenò wrote: On Monday 30 January 2006 06:17, Diego 'Flameeyes' Pettenò wrote: Defining LINGUAS variable would be useful to allow people to know whether they are going to have special support for their language in a package, but it would also clutter the output quite a bit. Okay then.. I'm still looking locally how it appears, and I'm thinking it's really useful to have LINGUAS told in emerge -pv and -av. it makes a the -pv output unreadable and thus useless ... although if you do something like -pvv, then the user can expect to get a lot of output ... of course this still doesnt address the pita maintenance issue If somebody has a list of those variables, I would add them, it seems to me the most sensible way to do that, it would add documentation allowing people to know what they are going to do. Also, as use.desc is alphabetically sorted, all the linguas_* variables will stay together. no, we have lang.desc already, dont clutter use.desc with this crap -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 11:48, Diego 'Flameeyes' Pettenò wrote: On Monday 30 January 2006 17:38, Mike Frysinger wrote: it makes a the -pv output unreadable and thus useless ... although if you do something like -pvv, then the user can expect to get a lot of output ... emerge -p is now less useless than before so it make sense for -pv to show lot of stuff.. not really ... you're going from basic info (-p) to a crap ton of info (-pv) rather than offering a middle step incremental verbose is trivial and i'm pretty sure emerge already does it of course this still doesnt address the pita maintenance issue Adds an extra check to do before a bump. One would expect people to look at what they bump.. it's a big pita, you cant make it sound trivial so stop trying -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Tuesday 31 January 2006 06:31, Jason Stubbs wrote: On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: 1. Because for things like LINGUAS, there are arbitrarily many legal values, and documenting them all and keeping the list up to date would be extremely difficult. More precisely, how should they be documented if not via use.desc? considering there's a ton more LINGUAS values than we have USE flags (just run `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings benefits *noone* we have lang.desc, it is quite populated, what's wrong with having portage read that -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Monthly Gentoo Council Reminder for February
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] env pollution
On Sunday 05 February 2006 12:17, Chris PeBenito wrote: I have two bugs [1][2] with installs failing due to some environmental variables being set, which end up overriding the settings in the packages' makefiles, causing sandbox violations. While this is a simple enough to work around with some unsets, how much do we really want to work to fix polluted environments? I can't help but think that is not my bug, but instead (apparently) kth-krb's fault for polluting the env (the vars are seemingly worthless man and info pages paths). how is kth-krb polluting the env ? via env.d ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 09:51, Diego 'Flameeyes' Pettenò wrote: On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: [EMAIL PROTECTED] wrote: | Yeah that would help. But in the mean time what should we do? What you should always do. Do the right thing, even if repoman disagrees. Seems like repoman is actually our boss in this case, so I was forced to put the linguas_* to use.local.desc. that's retarded, please remove all such linguas_* crap from use.desc files -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 15:43, Diego 'Flameeyes' Pettenò wrote: On Sunday 05 February 2006 21:34, Mike Frysinger wrote: that's retarded, please remove all such linguas_* crap from use.desc files I can, but then Mr_Bones_ will come back to me again and we're stuck in this loop. Mr_Bones_ should be aware that this is a repoman limitation, not a bug in the ebuild itself ... fix repoman, not hack other crap You can remove them, but then it's your turn with Mr_Bones_ about them. done -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] env pollution
On Sunday 05 February 2006 15:49, Christopher J. PeBenito wrote: But looking at 02kth-krb in its files directory we have: PATH=/usr/athena/bin ROOTPATH=/usr/athena/sbin LDPATH=/usr/athena/lib MANDIR=/usr/athena/man INFODIR=/usr/athena/info then, as Donnie said, kth-krb is wrong it should be using MANPATH and INFOPATH -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Depend syntax
On Sunday 05 February 2006 16:46, Ciaran McCreesh wrote: Just a reminder that all of the following are either illegal or strongly deprecated, so please don't use them even if Portage currently lets you get away with it: DEPEND=blah You should always use the full foo-bar/blah spec inside ebuilds. repoman should be detecting this now http://bugs.gentoo.org/42299 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Self-circular dependencies
On Sunday 05 February 2006 17:11, Ciaran McCreesh wrote: Another not-so-uncommon issue that crops up: packages DEPENDing upon themselves. Sometimes this is legit -- one of the Ada compilers, for example, DEPENDs upon || ( itself another-compiler ). Sometimes, however, it's the result of eclass screwups. your script doesnt take into consideration SLOT's ... the linux-gazette and gcc stuff in your log for example is a false positive -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Fwd: Re: official branding ( gentoo )]
On Monday 06 February 2006 20:09, Georgi Georgiev wrote: Make that official-branding option depend on a single local USE flag (there was a discussion about branding use flags, but this one has to be *disabled* by default), and forget about it :-D. may i suggest USE=retarded-policies -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] heads up on funky build errors with -O0/nls
in case anyone else comes across this (ive seen a few packages lately) ... * symptom: build fails with -O0 but not with -O1 when nls support is enabled * error: LC_MESSAGES/LC_CTYPE/LC_ALL/LC_something is undefined and/or functions like setlocale()/textdomain()/etc... are implicitly defined * short answer: broken build system doesnt properly include locale.h * long answer: the reason -O1 and better works is because glibc will include locale.h automagically via some headers (like libintl.h) whenever optimization is enabled so as to get inline/optimized versions of some functions. when optimization is disabled, glibc will not include locale.h for you and the build fails. so make sure the configure script checks for locale.h and has a bit of code like: #ifdef HAVE_LOCALE_H # include locale.h #endif for example: http://bugs.gentoo.org/121920 -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] last thoughts for xml/xml2 unification
any last issues people wish to cover before we start finishing this up ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages
On Wednesday 08 February 2006 19:24, Jason Stubbs wrote: On Thursday 09 February 2006 08:19, Mark Loeser wrote: Anyone that is maintaining a binary package in the tree, and requires libstdc++-v3, please put a rdepend in your package on =virtual/libstdc++-3.3. I'd like to drop the dependency from gcc-3.4 and higher so that we do not needlessly force the libstdc++ package on people that do not need it. It was my understanding that it is needed for the 3.3 - 3.4 upgrade. Various packages that will build fine against either are broken until being recompiled after the upgrade and there is currently no way to express this with dependencies. gcc-3.3 wont be removed automatically, so the system wont break until the user tells it so :) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Manifest2 decision delayed (was: Gentoo Council Meeting Summary (20060209))
On Thursday 09 February 2006 22:05, Ned Ludd wrote: I would like to see it drop the tab handling for indicating newlines and just use a real newlines when we want a newline. While having the tabs makes it easier for people to read it increases the byte size and adds some undesired complexity for admins, scripts programs which want to utilize the file. A basic grep or sort would probably be more than a one liner when having to deal with the newline+tabs. umm, i'm 99% sure you read it wrong ... the lines were wrapped in the GLEP to help you read it, the actual file format will not be like that Current ~arch portage-2.1_preX Manifest files are using MD5, RMD160 and SHA256; Will Manifest2 drop SHA1 and use SHA256 also? Is a max of 3 ciphers a self imposed hard limit? If not can we set that to be so we don't get carried away? i think this is just a matter of the example being outdated -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Eclass for prime numbers
On Sunday 12 February 2006 12:22, Michael Hanselmann wrote: For an ebuild I'm working on, I need a function to test wether a number is a prime number. For that, I wrote an Eclass you find attached to this e-mail. Can this be commited? i cant really see how this would be useful to anything, but i guess you found something :p also, your eclass has bugs, remove these three lines completely: ECLASS=prime INHERITED=$INHERITED $ECLASS EXPORT_FUNCTIONS primes is_prime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/rc.conf
On Sunday 12 February 2006 14:16, Forrest Voight wrote: I believe that rc.conf contains many values that could be put into conf.d. sounds like your system is outdated For example, DISPLAYMANAGER Donnie already covered this and KEYMAP. this was moved to /etc/conf.d/keymaps a while ago, you should think about updating -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 19:01, Alec Warner wrote: Forrest Voight wrote: What happens if two env.d files set the same variable? You write an eselect module to choose between them :) brr wrong -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 20:07, Forrest Voight wrote: How is that wrong? If it isn't, eselect would be a great way to switch EDITOR and XSESSION. jesus, talk about over engineering using eselect to manage some default variables instead of simply editing your ~/.bashrc file is like using a backhoe to dig a hole for a bonsai tree ... sure it'll work, but who the hell wants a goddamn bonsai tree -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] static compilation and executable stacks
On Tuesday 14 February 2006 17:02, Tristan Hill wrote: I'm updating the rpm ebuild[1]. Without any modifications the executables are statically compiled and I get the QA message about executable stacks. However, removal of -static from the compilation flags in ./configure also stops generation of an executable stack. The information about executable stacks, e.g. [2] and [3] dont indicate anything special about static compilation. Wondered if anyone has any suggestions on this behaviour. re-emerge popt and see if that fixes it -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] static compilation and executable stacks
On Wednesday 15 February 2006 10:35, solar wrote: On Tue, 2006-02-14 at 18:09 -0500, Mike Frysinger wrote: On Tuesday 14 February 2006 17:02, Tristan Hill wrote: I'm updating the rpm ebuild[1]. Without any modifications the executables are statically compiled and I get the QA message about executable stacks. However, removal of -static from the compilation flags in ./configure also stops generation of an executable stack. The information about executable stacks, e.g. [2] and [3] dont indicate anything special about static compilation. Wondered if anyone has any suggestions on this behaviour. re-emerge popt and see if that fixes it It should be beecrypt that is the cause of it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132149#c9 i mentioned popt because i came across one user who had an old popt and when he built rsync statically, rsync had exec stacks -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Friday 17 February 2006 07:38, Simon Stelling wrote: Jakub Moc wrote: OMG, stop this crap and don't waste our time. Taken from http://dev.gentoo.org/~chriswhite/docs/flame.html: | One thing is to frequently refer to us or our. Pretend like people | are with you on this, so the uncertain ones will flock to your side! | | Code listing 1.6: Usage of plurality | | email: Stop wasting our time! Apparently somebody did his homework ;) pwnt ! -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RESTRICT and no*
On Tuesday 21 February 2006 17:59, Ciaran McCreesh wrote: What's the deal with no* values in RESTRICT? Is it RESTRICT=strip or RESTRICT=nostrip? fetch or nofetch? the no* stuff is slowly being cut out Which values work with all Portage versions, which work with only recent ones and which work with none? all versions in portage tree should support the keywords w/out leading no The documentation and the code are both inconsistent on this... not really ... all references to the no versions have been cut ... as for the code, the references still exist until we've removed them -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] time to unify xml/xml2
ive update the xml use.desc entry to be generic and marked the xml2 entry as deprecated ... can people start fixing their packages themselves ? i'll give some lead time so as to cut down on the # of bugs that need to be filed to get this finished up ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] time to unify xml/xml2
On Wednesday 22 February 2006 23:46, Mike Frysinger wrote: ive update the xml use.desc entry to be generic and marked the xml2 entry as deprecated ... can people start fixing their packages themselves ? i'll give some lead time so as to cut down on the # of bugs that need to be filed to get this finished up ... also, i dont do PR stuff, so could someone handle GWN and such ? (iirc, someone wanted a note on the gentoo.org frontpage, but that isnt for me to decide) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SRC_URI component naming collision
On Sunday 26 February 2006 14:45, Stuart Herbert wrote: Also, I cannot find this SRC_URI rule (as being applied by the QA team) in any official Gentoo policy document. that's because it's common sense ... filename collisions just dont work -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 12:08, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 09:00:15 + Stuart Herbert [EMAIL PROTECTED] wrote: | Again, then we are going to get into the argument of the definition | of an emergency and never be able to get anything done. We really | hope problems never come down to this, which is why we left it | worded this way. | | Me too. But it will, sooner or later, and when something isn't an | emergency, there's no reason why a change cannot wait until the | dispute has been resolved. And, when such a case occurs, there's nothing *requiring* QA to commit before the dispute is resolved. It's extremely likely that QA will work hard to ensure that everyone is happy before something gets changed. However, there are situations where waiting for a month would lead to considerable damage, and in those situations QA must be free to act. if something is going to lead to considerable damage and the maintainer is unwilling to resolve the issue, then i'm pretty sure there's more to be resolved here than fixing a package not sure leaving this power open ended is really needed -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 16:12, Stuart Herbert wrote: On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: Whilst that one's still alive, I'm not going to go around filing more similar breaks non-interactively bugs because the discussion will just get repeated over and over. This point is another example of an attempt to enforce an undocumented QA policy the non-interactive rule has never been stated, just hinted at for example, the dev handbook mentions offhand: * Testing the package Please keep in mind the general requirements of an ebuild here. The src_test routine must not be interactive. if you like i can rectify this situation in the Ebuild policy guide -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tuesday 28 February 2006 06:47, Patrick Lauer wrote: On Tue, 2006-02-28 at 12:32 +0100, Diego 'Flameeyes' Pettenò wrote: On Tuesday 28 February 2006 11:58, Patrick Lauer wrote: During that discussion we realized that having utf-8 not enabled by default and no utf8 fonts available by default causes lots of recompilation and reconfiguration. At the same time, you'll probably hear people bitching about UTF-8 being enabled because it's not needed for me, should be the rest of the world to change It is still optional, just enabled by default :-) All the people with non-ASCII charsets will have less work, only that we switch the load from, say, 75% of the users fixing their environment to 25% of users having to switch. hopefully people will fix their packages to respect USE=unicode as to whether they link against libncurses or libncursesw -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 04:49, Jakub Moc wrote: No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable; part=3chap=1 so what, you want us to duplicate everything in one document and place it in the other just because one has the title Policy ? that's retarded the dev handbook documents proper ebuild development regardless of the title on a particular page -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 11:47, Lance Albertson wrote: Ciaran McCreesh wrote: On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | The maintainer should be the absolute authority over his/her packages, | and only the council should be able to overrule maintainer decisions | in the case of disagreement between the maintainer and anybody else. So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global scope and refuses to move it, QA will have to get council approval to fix it? Use some common sense when showing an example please. We all know that something that stupid needs to be delt with quickly. we've had at least one ebuild do stuff in /tmp in global scope ... of course that was a mistake the dev felt really bad about and it was fixed once noticed, so not sure this is an appropriate example ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 10:08, Jakub Moc wrote: 28.2.2006, 15:39:40, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printabl epart=3chap=1 No, the whole thing is policy. No, it isn't. yes, it is ... that's the point of the handbook -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)
On Tuesday 28 February 2006 11:39, Jakub Moc wrote: 28.2.2006, 17:24:21, Danny van Dyk wrote: If you don't agree with the contents, why didn't you raise your opposition earlier? I don't feel any need to raise opposition against some unofficial manual, what would be the point in that? I'm raising my hand against silently incorporating parts of it (that affect a lot of stuff in the tree) into official docs without a proper discussion, even more so that they are being claimed as an official QA policy now. Documents located in private devspace of some devs are non-official and noone checks their contents for correctness, they are private activity of those devs. input was solicited from the developer community before about ciaranm's unofficial manual with notes that the plan was to incorporate it piece by piece into the official dev handbook -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. why do you need to be a mindreader ? the user requested they control the package, thus it isnt a bug, so dont issue a warning -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:10, Jakub Moc wrote: 28.2.2006, 20:59:42, Mike Frysinger wrote: On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. why do you need to be a mindreader ? the user requested they control the package, thus it isnt a bug, so dont issue a warning Sure, and when *ebuild* requested it instead, then portage will be automagically informed. So yeah, we can implement yet another variable into the eclass, and we can do tons of other magic voodoo about three lines of eclass that noone has ever noticed until today, and the whole thing can be a lot more complex for sure. Sorry, I call this a complete waste of time. whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 16:02, Jakub Moc wrote: 28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 16:58, Alec Warner wrote: Mike Frysinger wrote: On Tuesday 28 February 2006 16:02, Jakub Moc wrote: 28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see bugs filed in almost all circumstances. If QA and the maintainer can fix stuff without bugs, thats cool, especially for trivial matters. If QA and the developer aren't getting along on a specific issue then there is no reason NOT to have a bug open. Otherwise you get circumstances that were also discussed, such as I told the maintainer in person over a year ago... which may in fact be true, but people forget things and make mistakes and now you have nothing to point at for proof of inactivity except a vague statement. Better to cover your rear and be able to point to a year old bug with a solution attached, and be like look there is a bug and a fix and no one did jack squat. Essentially you have a case for any sane developer to agree with. dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was addressing the incorrect idea that it isnt a valid QA issue unless a user experiences it and complains via bugzilla -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | I should note that if are a Gentoo Developer and have | problems/concerns/issues with Ciaran's attitude/actions, please | comment on bug #114944. (this bug is only open to Gentoo developers). | Its better if you say it yourself in this bug rather than letting | other people quoting what you say. I should note that if you are a Gentoo developer who has found my advice helpful, you should comment on bug #114944 since certain people are trying to turn Gentoo development into a popularity contest. there's a lot more to the issue, but it's sad if that's all you see in the bug -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Monthly Gentoo Council Reminder for March
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does every gcc in portage by default supports -fno-stack-protector -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Wednesday 01 March 2006 02:37, Jakub Moc wrote: 28.2.2006, 16:29:10, Ciaran McCreesh wrote: The whole devrel handbook is policy, except where otherwise noted. See Mike's reply. Then any significant change there requires a sane procedure. which does not change the fact that the devrel handbook is policy unless otherwise noted as suggestion or guideline -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 12:17, Duncan Coutts wrote: On Wed, 2006-03-01 at 11:39 -0500, Mike Frysinger wrote: On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does Oh. I had reports from ppc devs who said that gcc-4 didn't recognise that flag. it does and it doesnt ... official gcc-4.0.x lacks ssp support, but official gcc-4.1.x has it I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? yes -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 0042 (news) final draft
On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. may push council meeting back to 3rd tuesday if people wish -mike -- gentoo-dev@gentoo.org mailing list
