Re: [gentoo-dev] Re: hardened glibc and gcc dependencies
On Fri, Oct 28, 2011 at 5:17 AM, Ryan Hill wrote: > On Thu, 27 Oct 2011 23:03:12 +0530 > Nirbheek Chauhan wrote: > >> So, I honestly see no reason why toolchain should not start using EAPI 2. > > I await your patch to toolchain.eclass. :P > Sure, whenever I'm feeling particularly masochistic and have devalued my sanity, I'll be sure to spend a few days on that... ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: RFC: sed script redundancy
On Fri, 20 May 2011 17:39:22 +0200 Jeroen Roovers wrote: > for a while now I've been wondering if all those sed scripts in all > those ebuilds are really effective. > > To find out, I've tried a couple of angles on a sed hook that basically > dissects the sed command line provided, divides everything up into sed > scripts, files being processed and other options, and runs everything > through diff to get some meaningful QA output as to the effective use > of the sed scripts invoked. > > Of course some of the time a sed script falsely seems to be ineffective, > but could be, when it uses some variable or output that varies depending > on the platform you run it on, like with the likes of $(get_libdir). > > I've looked into sed's internal solutions to no avail, but something > like -i[SUFFIX] might help, since it gives you a backup file to compare > with the file that's being streamed. > > The idea is to pass the result to > | diff -u $file $file[SUFFIX] > to figure out what was changed, and what sed script changed it. > > Any help? Sorry, old thread. :) You can use the 'w' flag to write a log file of lines changed. This includes lines changed where the replacement ended up the same as the text matched (eg. lib->$(get_libdir)). Which means you can do something like: dirtyepic@tundra ~ $ cat test foo foobar bar foobarfoo dirtyepic@tundra ~ $ sed -i -e 's:foo:foo:gw /dev/stdout' test | wc -l 3 I think only gnu sed can do the stdout thing. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: hardened glibc and gcc dependencies
On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote: > On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote: >> So, I honestly see no reason why toolchain should not start using EAPI 2. > > I await your patch to toolchain.eclass. :P i wouldn't bother as it's most likely not going to be accepted at this time (i haven't kept up-to-date with the hardened threads as i'm traveling atm) -mike
[gentoo-dev] Re: hardened glibc and gcc dependencies
On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote: > So, I honestly see no reason why toolchain should not start using EAPI 2. I await your patch to toolchain.eclass. :P -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] hardened glibc and gcc dependencies
On Thu, Oct 27, 2011 at 9:38 PM, "Paweł Hajdan, Jr." wrote: > On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote: >> In glibc: DEPEND="gcc[hardened?]" >> In gcc: PDEPEND="elibc_glibc? glibc[hardened?]" > > I even got an OK on #gentoo-hardened, but I just realized that EAPI-0 > (that both packages in question use) doesn't allow use deps like > [hardened?]. > > I guess bumping the EAPI on those packages is not an option (is it?), so > I'm going to do some more experiments to see if there are more possible > problems. > As per council approval in the last meeting, profiles/ is now EAPI 1. EAPI 2 usage in profiles was not a blocker due to portage version problems, but due to unresolved questions about cat/pkg[use] atoms in package.mask etc. Barring those, EAPI 2 would've been approved for profiles/ as well. So, I honestly see no reason why toolchain should not start using EAPI 2. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: hardened glibc and gcc dependencies
Paweł Hajdan, Jr. posted on Thu, 27 Oct 2011 18:08:36 +0200 as excerpted: > On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote: >> In glibc: DEPEND="gcc[hardened?]" >> In gcc: PDEPEND="elibc_glibc? glibc[hardened?]" > > I even got an OK on #gentoo-hardened, but I just realized that EAPI-0 > (that both packages in question use) doesn't allow use deps like > [hardened?]. > > I guess bumping the EAPI on those packages is not an option (is it?), so > I'm going to do some more experiments to see if there are more possible > problems. AFAIK, it's an option, but a tough one. But as with profiles, at some point it's worth considering whether holding back on toolchain EAPI bumps is worth it any longer. It'll need to happen eventually, and AFAIK, for a system without EAPI-1 or 2 or whatever, portage is already borked. Same with the tree in general, since a bash of that vintage isn't going to parse certain ebuilds due to the bash 4.1 thing. Actually, but for the patience of toolchain maintainers, that bump might have already happened. So I guess it's sort of up to them, tho getting the blessing of council on something that big is probably a reasonable idea. But that's probably a good idea for moving toward hardened by default anyway, so I don't see that as a huge block. I'm reminded of the move to cascading profiles... Plus the bash 4.1 thing. At some point, you just accept current reality and move on. But toolchain's say will matter a lot. If they don't believe it's time to leave EAPI-0 for gcc and glibc, I don't think it's worth pushing against them on their own packages. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] hardened glibc and gcc dependencies
On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote: > In glibc: DEPEND="gcc[hardened?]" > In gcc: PDEPEND="elibc_glibc? glibc[hardened?]" I even got an OK on #gentoo-hardened, but I just realized that EAPI-0 (that both packages in question use) doesn't allow use deps like [hardened?]. I guess bumping the EAPI on those packages is not an option (is it?), so I'm going to do some more experiments to see if there are more possible problems. signature.asc Description: OpenPGP digital signature
[gentoo-dev] hardened glibc and gcc dependencies
As a part of my earlier threads I tried to figure out the migration plan from not hardened glibc and not hardened gcc to both of them hardened. That of course raises questions like - what we compile first, and what are dependencies here? Here's what I have figured out - by _experimenting_ not speculation: 1. Building glibc with USE=hardened works, no matter whether the toolchain is hardened or not. 2. However, glibc won't apply one hardening-related patch if the used toolchain is not pie-enabled. 3. Interestingly, gcc with USE=hardened compiles fine even if glibc is -hardened. The vanilla spec works. I haven't tested the hardened spec. Based on that, I suggest the following dependency changes (conceptually): In glibc: DEPEND="gcc[hardened?]" In gcc: PDEPEND="elibc_glibc? glibc[hardened?]" Thoughts? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Council] ChangeLog generation within Gentoo
On 10/26/11 19:33, Bruno wrote: > In order to not bloat the tree I would like to see old entries purged > when there are more than 25-50 of them, especially if they refer to > ebuilds gone since more than 3-6 months. One thing to remember: Even if old ebuilds are gone in the tree already, they still may be installed on users systems. As a result, 'emerge --changelog' searches for their addition-entries in ChangeLog. So when purging ChangeLog's really becomes necessary, we might need to keep the addition-entries back to until a once-been-stable ebuild was superseded by another stable ebuild more than 1 year ago - or sth. similar. my 0.02 [€$?] /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] Re: [Council] ChangeLog generation within Gentoo
On 27-10-2011 03:28:33 +, Duncan wrote: > Fabian Groffen posted on Wed, 26 Oct 2011 23:00:22 +0200 as excerpted: > > On 26-10-2011 14:02:12 -0400, Rich Freeman wrote: > >> Well, if the desire to trim changelogs is generally agreed upon we > >> could always just count the lines and post a top-100 list or something > >> and let package maintainers go in and truncate things as seems bet to > >> them, with the guideline to keep the file intact up to a year before > >> the last commit. Eventually the files will be cleaned up. > > > > Don't you think it's much more sensical to remove all entries for > > ebuilds that are no longer in the tree then? > > 1) Given the irregularity of older entries, that could be difficult to > automate, tho it could be done going forward, once a log has been > manually trimmed once. a) take the set of available ebuilds b) forward scan through the ChangeLog for entries that affect any of the files c) copy those entries to a new ChangeLog Technically, you could do it on the machine that generates the rsync image, but that brings the problem that the Manifest file gets broken, hence an update + resign is necessary. E.g. all developer signs are replaced with a generic one. Same issue when generating the ChangeLogs from VCS with the current Manifests. Upside of doing it on rsync0 is that the full log is stored in sources.g.o, and the short/most relevant one is on rsync to the users. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
