Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
> Now, on the topic of the tarballs. > > Give me one example of something that you can do with a stage1 or stage2 > tarball that you cannot with a stage3 tarball. Stage1: Changing CHOST= and run ./bootstrap.sh (well you can do it but it's dumb) Stage3: has full cxx/berkdb/ssl/pam/libwrap and all the cruft pulled in from having use flags enabled thats not easy to get rid of otherwise. I don't care what you do with the docs, but the stages 1, 3 need to stay. stage2 has always been a bonus stage more or less added into the mix cuz it's a byproduct of stage building (pre catalyst days). -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tue, 2005-11-22 at 10:58 -0500, Chris Gianelloni wrote: > On Tue, 2005-11-22 at 10:29 -0500, solar wrote: > > > Now, on the topic of the tarballs. > > > > > > Give me one example of something that you can do with a stage1 or stage2 > > > tarball that you cannot with a stage3 tarball. > > > > Stage1: Changing CHOST= and run ./bootstrap.sh > > (well you can do it but it's dumb) > > Right. You can do it. > > > Stage3: has full cxx/berkdb/ssl/pam/libwrap and all the cruft pulled in > > from having use flags enabled thats not easy to get rid of otherwise. > > You can accomplish this, too. Maybe we could even use that nice little > "scripts" directory in the portage tree to write a script to assist in > performing this. I'm sure it would be less error-prone than what we > have now with the broken QA procedures allowing things to go into > system, or system-depended packages, that pulls in all kinds of useless > crap. > > > I don't care what you do with the docs, but the stages 1, 3 need to > > stay. stage2 has always been a bonus stage more or less added into the > > mix cuz it's a byproduct of stage building (pre catalyst days). > > Removing the stage1 and stage2 instructions from the Handbook has > already reduced the number of errors being reported by new users to me. While I'm glad your getting less bugs/errors reported, I'm a little sad that you had stage1 install instructions removed. Starting from stage1 is the basic hardened way. Most of our users (which seem to be 10% of the userbase) start from that stage due to hardened only shipping it's stages as i386-pc-linux-gnu and honestly most users are i686-pc-linux-gnu so they end up changing this. We ship as i386 to ensure all x86 compatibility. I hope that you can arrange for either the stage1 install instructions to be put back in or split off into it's own stage1.xml doc. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, 2005-11-23 at 16:57 +0100, Henrik Brix Andersen wrote: > On Wed, Nov 23, 2005 at 08:19:40AM -0500, Ned Ludd wrote: > > ha ok new rule for me. drink coffee before sending first mail of the > > morn. > > What's this supposed to imply? That you didn't intend to repeat > yourself in the original mail - or that hardened will continue to ship > 2.4.x stages for 2006.0+? ;) That I did not intend to repeat myself. Before hitting send I usually take whatever mail copy and paste it into $EDITOR then wrap it at 72 chars wide and delete the unwrapped block. Clearly I forgot the last step. As for hardened and 2.4.x it seems most of our users are wanting 2.6.x now and unless users/devs show interest I can't really see us needing to produce a new set of 2.4.x based 2006.x stages. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 13:56 -0500, Mark Loeser wrote: > Mark Loeser <[EMAIL PROTECTED]> said: > > Only thing I see > > as lacking is we might want to get a doc together on how to properly upgrade > > your toolchain so we don't get an influx of bugs from users that have a > > system half compiled with 3.3 and the other half with 3.4 so they get > > linking > > errors. > > Seems people read this to mean that I was going to write a doc, which I have > no intentions on doing. I believe adding "It is recommended that you `emerge > -e system && emerge -e world` after merging gcc-3.4" to the einfo at the end > of the gcc-3.4.4 install should be good enough. I'm not sure how other archs > handled the migration, but I haven't been able to find any docs online. > > So, let me know if marking it stable in the next day or two is completely > stupid and I should wait to announce this via the GWN or something, or if its > an alright move and people aren't going to stab me for marking it stable. einfo "$stuff" and mark it stable later today wins my vote. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, 2005-12-19 at 18:37 +0100, Marius Mauch wrote: > On Thu, 15 Dec 2005 22:47:21 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > this months meeting wasnt too eventful, kind of quiet ... on the > > agenda: > > > > - Marius: decision on multi-hash for Manifest1 > > there was a bit of hearsay about why the council was asked to > > review/decide on this issue since we werent able to locate any > > portage devs at the time of the meeting ... > > Well, it would help if the actual meeting date would be announced and > not pushed back without notice ;) > > > so our decision comes with a slight caveat. assuming the reasons > > our input was asked for was summarized in the e-mail originally > > sent by Marius [1], then we're for what we dubbed option (2.5.1). > > that is, the portage team should go ahead with portage 2.0.54 and > > include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 > > should not be included as having both SHA256/SHA1 is pointless. > > Ok, not a problem. > > > it was also noted that we should probably omit ChangeLog and > > metadata.xml files from the current Manifest schema as digesting > > them serves no real purpose. > > You're all aware that this would break portage version older than 6 months)? Also while they don't affect the > build process they contain important information and are/will be parsed > by portage, so I'm not that comfortable with dropping also the option > of verifying them permanently. > > One thing solar has pointed out is that in countries with stupid laws > pycrypto violates some patents so currently we cannot ship it in stages > or binary packages (so I'm told, I'm neither a lawyer nor someone who > is affected by such laws). This is probably something releng and the > python herd have to deal with. It's easy enough to patch the two ciphers out when USE=bindist would be set. > So right now I'll go ahead and add the pycrypto code to portage, but > will not yet add the dep to any ebuild or change anything metadata.xml > or ChangeLog related (according to Jason 2.0.54 is still away one or > two weeks anyway). If you do that please set it as a blocker for the .54 release. Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired regression. Nothing in the portage as of <=.53 make direct use of those two files and there is no security value in bloating the digest format with them. Thats why they were removed 2.0.51.21 Making the argument for maybe portage in the future will use them is not valid as they are currently omited and we/I have been told before by the portage team (ferringb & jstubbs iirc??) that portage itself wont be doing any .xml parsing in it's core. IE So that means not today nor tomorrow will anything need to depend on those files in order to build. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, 2005-12-19 at 20:29 +0100, Marius Mauch wrote: > On Mon, 19 Dec 2005 13:45:04 -0500 > solar <[EMAIL PROTECTED]> wrote: > > > If you do that please set it as a blocker for the .54 release. > > Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired > > regression. Nothing in the portage as of <=.53 make direct use of > > those two files and there is no security value in bloating the digest > > format with them. Thats why they were removed 2.0.51.21 ... > Name a single portage version that does *not generate* manifest entries > for them (hint: there is none). They are only ignored right now during > verification. So it's in no way a regression. sigh I just checked and you are correct it does still create them, so I'll happily recant on the word regression. It however seems pointless to include them in creation. Currently the 2 unused lines are taking up about ~1.1M in the tree, when we have several additional hashes I can only imagine that it would use significantly more space than currently. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] checdeps.rb for getting deps out of elf files
On Wed, 2005-12-28 at 21:52 +0200, Petteri Räty wrote: > Paul de Vrieze wrote: > > On Wednesday 28 December 2005 17:26, Petteri Räty wrote: > > > >>I just picked some package as an example of the output with > >>openoffice-bin. My understanding here is that if you link against those > >>libraries, it will break break binary packages because dependencies > >>don't say to pull in required libraries. This just means that apr-util > >>should be fixed. > >> > > > > > > By the way, you might want to check the locations of libraries. > > Openoffice-bin > > does not satisfy the dependency for the db library. It namely is outside > > the > > library search path (and it should be). You might want to use ld.so.conf > > with > > the rpath attribute of the binary to determine which libraries to consider. > > > > Working on it with solar. I just put the || in there until I have > something better. Thinking about libstdc++-v3 having all the > alternatives is also useful. Developers should know that the one from > openoffice is not used. We just added -L to be used with -n in scanelf(pax-utils-0.1.6) to search the ld.so.cache. It works in uclibc and glibc environments and handles 32/64 bit dupes. We can't verify any of the *BSD's at this time however as we no access to one of it's caches. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SLOTs and libraries
On Wed, 2006-01-04 at 20:59 +0100, Patrick Lauer wrote: > On Wed, 2006-01-04 at 09:13 -0800, Robin H. Johnson wrote: > > On Wed, Jan 04, 2006 at 05:45:22PM +0100, Patrick Lauer wrote: > > > Now I'm wondering - is there a sane way of handling this that doesn't > > > forcefully remove python 2.4? > > > e.g. could python modules be installed to multiple python versions? How > > > do others (ruby, perl, ...) handle it? For the moment I've "solved" that > > > by package.masking python 2.4, unmerging it and rebuilding all Python > > > modules - less than optimal ... > > See dev-python/validation-1.2.3 for another solution. > > It installs itself for all versions of Python that are on the system. > I don't fully understand the magic how it finds all Python versions, but can > this be applied to other packages? > Are there reasons for not doing this (besides increasing build time)? > > Also - how does portage react to "multi-installing" packages? This question seems better suited for the portage mailing list. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: ca-certificates PDEPEND
On Mon, 2006-01-09 at 16:55 +0100, Andrea Barisani wrote: > Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief > exchange of emails already happened on -dev but since it's not so easy to > track it I'm lagging behind on this) I would like to express that I really > don't like the fact that we are "trusting" cacert.org certs (among others) > without providing it as a choice. > > Despite all the political views that we can throw in favour of a "cacert.org > are trying to make the SSL certs world less evil" argument this is some major > policy that we are supporting and it shouldn't be taken that lightly (I don't > remember such a major confrontation about this) and I really don't think this > should be a default policy but rather user's choice. Technically cacert.org > is not a recognized CA in the "proper" way (and don't point that a proper CA > is a lame concept and a snake oil thing..this is not the point). > [CCing [EMAIL PROTECTED] because this concerns the team as well imho.] > > Just my 2 eurocent. > > P.S. > I know that firefox doesn't trust /etc/ssl/certs by default, dunno about > konqueror. The point is still relevant though. Do you think the PDEPEND of the ca-certs should be tied to a USE= flag? If so should it be a 'no*certs' flag or a USE=cacerts ? -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo Council Meeting Summary (20060112)
Monthly Gentoo Council Meeting for Jan 2006. Present: Koon (Thierry Carrez) Swift (Sven Vermeulen) agriffis (Aron Griffis) seemant (Seemant Kulleen) solar (Ned Ludd) vapier (Mike Frysinger) Absent: azarah (Martin Schlemmer) Where abouts unknown for the last 30 days. Attendance by non council members appeared to be rather low. Agenda: * GLEP 45 - GLEP date format * Disallowing council members to act as proxies for other council members. * Global gentoo goals for 2006 Outcome: * GLEP 45: As stated on the mailing lists minor changes to GLEP's and the GLEP process is best left in the hands of the GLEP editors. Everybody supported g2boojum's ability to decide. Otherwise we would of voted yes. * Disallowing council members to act as proxies for other council members. Status = Approved. * Global gentoo goals for 2006 This was mostly a brainstorming session covering such topics as should the council even be setting global goals, enterprise support, GRP, ebuild/profile/eclass and binpkg signing. -- solar <[EMAIL PROTECTED]> Gentoo Linux -:- Topic (#gentoo-council): changed by vapier: Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month? 06:54PM where am I? 06:54PM :p 06:55PM batman anybody want to step up and chair this or open session today? 06:57PM i would but like i said, i'm prob gonna have to pop out early 06:59PM welp, by my clock, it's about that time eh 07:00PM i'm pretty sure az isnt going to show up -:- tove [EMAIL PROTECTED] has joined #gentoo-council 07:00PM Koon / seemant / solar / seemant / vapier 07:00PM who is awake ? check 07:01PM mate 07:01PM I am awake 07:02PM i'll assume Koon will wake shortly -:- kloeri_ [EMAIL PROTECTED]/developer/kloeri] has joined #gentoo-council * GLEP 45 - GLEP date format <-- ok this one. This is not even for us to decide on is it? The glep editors got that one covered right? 07:02PM yes, g2boojum is for it 07:02PM * SwifT/#gentoo-council doesn't mind at all 07:02PM and i'm pretty sure we'd all vote yes -:- NetSplit: irc.freenode.net split from zelazny.freenode.net [07:02pm] -:- BitchX: Press ^F to see who left ^E to change to [irc.freenode.net] 07:02PM it's not for us to decide, I should think 07:02PM stupid freenode -:- [Users(#gentoo-council:10)] [ kloeri_ ] [ tove ] [EMAIL PROTECTED] ] [EMAIL PROTECTED]] [ kallamej ] [vg2boojum ] [ FuzzyRay ] [EMAIL PROTECTED] ] [ spb ] [EMAIL PROTECTED] ] -:- Topic (#gentoo-council): Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month? -:- Topic (#gentoo-council): set by vapier at Thu Jan 12 18:54:06 2006 07:02PM regarding chairing, sorry, just saw the e-mail. Perhaps next meeting who did we lose on that split? 07:03PM I support g2boojum's ability to decide that :) 07:03PM Koon -:- Koon [EMAIL PROTECTED]/developer/Koon] has joined #gentoo-council -:- mode/#gentoo-council [+o Koon] by ChanServ 07:03PM here he is ok next item is. * disallow multiple votes per person (from ciaranm) http://marc.theaimsgroup.com/?t=11346783302&r=1&w=2 07:04PM WFM 07:04PM wfm? 07:04PM the reasoning in that email is sound 07:04PM yes too 07:04PM so yes, wfm2 07:04PM isn't it Windows Meta Format or something? 07:04PM SwifT: works for me 07:04PM emerge wtf && wtf wfm 07:04PM oh, that 07:04PM yes, wfmaw 07:04PM pfft that isnt real 07:05PM you're just making s**t up 07:05PM brb phone 07:05PM have we all voted for that? 07:05PM (or a majority anyway) 07:05PM solar hasnt I dont see the point personally and what brought it up was I'm guessing me trying to cover for az last month. but if the majority want to put into effect thats ok. so yes 07:06PM you're so accommodating 07:06PM !alindeman:*! Hi all .. Regional server looks to be having some trouble; we're working to resolve it now next item is * global gentoo goals for 2006 07:06PM whee 07:06PM that thread went to garbage fast eh that we talked about a short bit in mail and said that global goals is not something that the council should decide. anybody have any input towards that subject? 07:08PM i dont think that's it 07:08PM so my followup question is: who's role is that to play? explain please 07:09PM !lilo:*! Problem with a temporary main rotation server; however, we'd removed it from the main rotation as soon as we could manage, and about 800 users were affected 07:09PM we cant just defer it, if we do we're saying "what Gentoo is now is good enough" 07:10PM no, but some people would like to see us 7 give the global direction where Gentoo is heading at 07:10PM which, frankly, will probably upset at least 7 other people :p 07:10PM however, if the council could work on keeping track of Gentoo's shortcomings and possible interesting areas, we can give a boost to new proposals 07:10PM well, not really
Re: [gentoo-dev] pending dooooooom of use.defaults
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. The autouse itself is not a bad feature or idea if it were used properly. Problem is that it's not been used properly. If it were limited to simple things like just X and the things that actually make sense then it would even be fine to keep and would allow some of the more bloated (default-linux) profiles to be cleaned up. Shrug. I like the existing behavior and the power of deciding for myself when and where I want to take advantage of USE_ORDER= > 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 -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 2006-01-13 at 20:23 +, Ciaran McCreesh wrote: > On Fri, 13 Jan 2006 15:13:02 -0500 solar <[EMAIL PROTECTED]> wrote: > | The autouse itself is not a bad feature or idea if it were used properly. > | Problem is that it's not been used properly. > > No, it's bad. It's another thing that makes correct dependency > resolution impossible. If your going to contradict somebody why don't you give more detail and less opinion. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
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' -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Manifest2 decision delayed (was: Gentoo Council Meeting Summary (20060209))
On Thu, 2006-02-09 at 22:39 -0500, Mike Frysinger wrote: > 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 I hope that is is the case. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] static compilation and executable stacks
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 > -mike -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)
On Mon, 2006-02-20 at 14:13 +0100, Bjarke Istrup Pedersen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey. > > I was thinking, how about putting all log related packages into their > own category? > This should be logging daemons, log viewers, logrotate etc. > > Maybe creating a logging herd would be an idea to, to remove the load > from the base-system herd. > > What do you think? I think most pkgs are fine where they are at now. The main logging pkgs do not suffer from not being maintained. app-admin/ where most things are now seems the most fitting. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 2006-02-28 at 11:58 +0100, Patrick Lauer wrote: > Hi all, > > at FOSDEM we had a nice discussion about languages, translations etc. > Having people from the US (wolf31o2) who never have problems and people > from Japan (usata) who always have problems with encodings / > charsets / ... was quite interesting. > > 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. > > Enabling the unicode useflag in the profiles should help our > international users and should not cause any problems. Are there any > known bugs / problems this would trigger? Any reasons against that? > > If there are no objections this should be a small but helpful change. > > On a tangent I wonder if pulling in extra fonts as a dependency of X > makes sense (useflag controlled, enabled by default) - that way the > unicode capabilities are available without any configuration. I forget where I read it but I thought that unicode lead to overflows and was considered a general security risk. I wish I knew where I read that but I'm unable to find it. Any list readers know anything relating to that? -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 2006-02-28 at 20:18 +0100, Kevin F. Quinn (Gentoo) wrote: > On Tue, 28 Feb 2006 12:47:33 -0500 > solar <[EMAIL PROTECTED]> wrote: > > > I forget where I read it but I thought that unicode lead to overflows > > and was considered a general security risk. I wish I knew where I read > > that but I'm unable to find it. > > Well, stuff I could find includes: > > http://www.kde.org/info/security/advisory-20060119-1.txt > buggy UTF-8 decoder in KDE - this is an overflow error, which as > ciaranm says is a risk applicable to anything. It's a bug in KDE, not > in UTF-8 as such. Perhaps this is what was at the back of your mind. > > > http://www.izerv.net/idwg-public/archive/0181.html > risks of using UTF-8; in particular the use of separate validators > which won't process things exactly the same way the application does. > Also homograph risks associated with allowing more than one encoding for > a character. > > http://www.eeye.com/html/Research/Advisories/AD20010705.html > example of UTF-8(ish) used to fool IDSs by using alternative > non-standard encodings that IDSs aren't aware of. > This actually is another example of issues with secondary validators > described in the link above - they're not guaranteed to parse things > exactly the same way the application does. > > http://www.microsoft.com/mspress/books/sampchap/5612b.asp > describes a number of risks of accepting UTF-8, including the above. > > > So far I haven't found anything that could be considered a general > security risk, but that doesn't prove much :) Thanks Kevin. I think whatever I was thinking of had todo with widechar support. Maybe on phrack, vuln-dev, DD I forget. But the second link was a pretty good read and perhaps can give us some sort of reasonable checks that we can use before we opt to allow the use flag to be enabled in our hardened profiles. Think we can automate any checks using the UTF-8-test.txt ? -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wed, 2006-03-01 at 17: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. > > I also heard that gcc-4 contains a re-written stack protector > implementation with different semantics and that was why it didn't > recognise the flag anymore. > > > every gcc in portage by default supports -fno-stack-protector > > So that includes gcc 4 then. Well that makes life easier. :-) > > I presume it's a gentoo patch to gcc-4 to add back in > -fno-stack-protector? For the 4.0.x it should be just a dummy call. For 4.1 it is included. What does change and is really uncool with 4.1 is that -fno-stack-protector-all is missing and wont be added back without several somebodies making a case for it upstream. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] binary packages and striping
On Thu, 2006-03-09 at 11:28 +0100, Diego 'Flameeyes' Pettenò wrote: > On Thursday 09 March 2006 04:12, Mike Frysinger wrote: > > this is kind of a pita in terms of maintenance and imo a hack ... why not > > just have the splitelf code skip stripped binaries > Because of the number of `file` calls needed to identify stripped and > non-stripped binaries, I'd say... Come to think of it portage-2.1_NEXT will require >=pax-utils-0.1.10 (auto fixing evil rpaths) which has support for '*.a' files now (spanky rules). We can probably obsolete the need to call 'file' all together now in prepstrip. Heres a patch also which should help you track down offending programs as they occur. should catch all cases of 'install -s' also. http://tinderbox.x86.dev.gentoo.org/portage/local/patches/sys-devel/binutils/binutils-gentoo-strip-safe.patch -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
On Tue, 2006-04-04 at 12:53 -0700, Donnie Berkholz wrote: > Carsten Lohrke wrote: > > This is what I'd like to see clarified. To me, only a decision of the > > Council > > may lead to such a "suspension", as it is the relevant _elected_ entity. > > And > > I hereby request to add a paragraph at least, stating exactly this. ... > This is absurd. The council shouldn't need to make every decision in > Gentoo itself. It should be able to delegate power to any group it chooses. Thanks for pointing this out Donnie. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE="minimal" for kernel sources
On Mon, 2005-09-05 at 22:08 +0300, Petteri Räty wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have a couple of old machines I maintain and emerging and unmerging
> kernel sources take a while because there are so many files. Also one
> set of gentoo sources takes about 230MB of disk space. By removing stuff
> not belonging to x86 I was able to succesfully run make with 58MB/230MB
> removed. The stuff I removed:
> arch/* except i386 and x86_64
> include/asm-* expect asm-generic, asm-i386 and asm-x86_64
> So I propose we implement a minimal USE flag in the kernel-2 eclass that
> would make the cleaning I succested before the merging. One problem
> coming from the clean is that make clean does not work and at the moment
> it is run before unmerging, which is of course a good thing. If the
> kernel devs think this is a good idea, I can make an implementation for
> this.
Would something like an unpack.mask/UNPACK_MASK="paths/ wildcards.."
work for you? Perhaps you can simply just take advantage of tar's
--exclude=/-e options in the unpack() function of ebuild.sh when
USERLAND == GNU. Untested patch attached if you want to play
with/perfect the idea. By excluding it from tar you should be able to
save space/cpu/ram all the way around the board while getting the same
end result.
--- /usr/bin/ebuild.sh 2005-09-08 13:48:02.0 -0400
+++ ebuild.sh 2005-09-08 13:51:13.0 -0400
@@ -346,8 +346,9 @@
if [ "$USERLAND" == "BSD" ]; then
tarvars=""
else
- tarvars="--no-same-owner"
- fi
+ tarvars="--no-same-owner"
+ [[ "$UNPACK_MASK" != "" ]] && tarvars="${tarvars} -e \'${UNPACK_MASK}\'"
+ fi
[ -z "$*" ] && die "Nothing passed to the 'unpack' command"
Re: [gentoo-dev] Reminder on dependencies.
On Tue, 2005-10-25 at 17:39 +0100, Ciaran McCreesh wrote: > On Tue, 25 Oct 2005 07:09:03 -0700 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | I disagree. You shouldn't expect to be able to compile things against > | it unless all DEPENDs are installed. The whole point of DEPEND is to > | be able to do things like this; remove all things not necessary for > | your programs to run, not to compile. > > I'm glad to see you're volunteering to join in with Ned in going > through every single ebuild in the tree and fixing them up to list nth > level dependencies. It's going to be really fun watching you update > several hundred packages every time a library's compile dependencies > change between versions. Please do not put words in my mouth. I've already asserted to you several times that the definition of RDEPEND= is unclear and that we do infact need a new set of depend atoms. R=(runtime) not Buildtime for the NNth time. Till then please focus your efforts on something useful that does not break other peoples systems or projects. > See, if libfoo-1.0's headers don't need (say) boost, but libfoo-1.1's > headers do, with what you're proposing you'd have to go through and > update the dependencies of every single package using libfoo. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reminder on dependencies.
On Tue, 2005-10-25 at 20:16 +0100, Ciaran McCreesh wrote: > On Tue, 25 Oct 2005 13:55:36 -0400 solar <[EMAIL PROTECTED]> wrote: > | Please do not put words in my mouth. I've already asserted to you > | several times that the definition of RDEPEND= is unclear and that we > | do infact need a new set of depend atoms. R=(runtime) not Buildtime > | for the NNth time. Till then please focus your efforts on something > | useful that does not break other peoples systems or projects. > > Given the choice of possibly causing minor inconvenience to the embedded > people or outright breaking the tree for every single user, the sane > option is to keep the tree working. If embedded has a requirement for > better DEPEND specifications, why don't they start working on a GLEP? Embedded GLEP eh? You two are the ones trying to distort the meaning of RDEPEND= simply because the depclean is broken for the cases you make. Where is your GLEP for this? Where is a real like example? I'm sure you can dig back in the tree and show us something you had to fix in the tree if this is such a problem as you were asserting last night. While your at it please go ahead and show us the code that resolves the case for everybody so this silly thread can end. I've already busted by ass and fixed the vital broken packages and eclasses which INCORRECTLY included linux-headers etc in RDEPEND= we already worked with releng and other groups to ensure that things function properly, so heh no GLEP is needed from embedded as things are/were functioning correctly. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed changes to base profile for Gentoo/ALT
On Wed, 2005-11-02 at 14:38 +, Mike Frysinger wrote: > On Wed, Nov 02, 2005 at 01:11:24PM +0100, Diego 'Flameeyes' Petten? wrote: > > I would have some other changes for virtuals, but they are less important > > right now. > > it depends on the changes ... i'm more likely to tell you to just override > them in your own tree :P > > > Obviously if this is going to be applied the missing packages should be > > added > > to the packages of default-linux and other linux profiles that does inherit > > from base. > > linux-based profiles should inherit default-linux rather than base anyways ... Mike, Thats a lot easier said than done and I'd rather us not inherit from default-linux for the uclibc, hardened and it looks as if selinux, vserver profiles also inherit directly from base. I'd rather us keep it this way and or add another stop gap profile between default-linux and base such as profiles/linux-core as using default-linux as a parent is going to add alot more cruft that we may want. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed changes to base profile for Gentoo/ALT
On Wed, 2005-11-02 at 13:11 +0100, Diego 'Flameeyes' Pettenò wrote: > As I'd like to get sooner or later (better sooner) the profiles for > Gentoo/FreeBSD in main tree, I've synced the fake base profile in gentoo-alt > overlay with the one in the tree. Unfortunately there are things in base that > are linux-specific, so they, IMHO, should be moved in default-linux. > > The attached patch is the proposed changes, they are mainly linux-specific > userland that does not work outside of Linux-based systems, but there are > also some GNU-specific packages like which that we don't use. > > I would have some other changes for virtuals, but they are less important > right now. > > Obviously if this is going to be applied the missing packages should be added > to the packages of default-linux and other linux profiles that does inherit > from base. After reviewing the existing profiles effected by the proposed change I'd suggest you do something like this. cp -a base base-tmp cd base cat ~/base-alt-changes | patch cd .. diff -u base-tmp/packages base/packages | grep ^- | cut -c 2- > new.x mv new.x base-tmp/packages mv base core mv base-tmp base echo ../core > base/parent # And then bsd inherits from core vs base. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
