Re: [gentoo-dev] Re: GLEP XX: Fix the GLEP process
On Tuesday, 13. December 2005 03:42, Ciaran McCreesh wrote: > After that, I'll probably question replacing a single author with a > committee. We don't want to end up designing things like Ada, after > all... Hm, why not? It works, and wors well.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] bugs.g.o slowness
On Mon, 2005-12-12 at 18:45 -0500, Jeffrey Forman wrote: > I apologize for my mishap. Goes to show that testing on live hardware is > not the way to go ;) What is this "testing" thing you speak of? Should I buy one? Will santa give me one if i sit on his lap? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 13 Dec 2005 03:20:43 +: > Ok, new draft. Changes are as follows: [] > * Changed /var/lib/portage to /var/lib/gentoo OK, I must have missed the reason for that, and it isn't listed in one of your "a previous version" notes, unless I missed that too. Assuming the reason wasn't contrary to this (which it probably is, but...), why not /var/lib/portage/news/gentoo? If I read jstubbs' suggestion correctly, the "gentoo" would then serve as the repo name (in place of magic-chicken, altho as he proposed it, that would be part of the filename, not the directory the file is in) as well -- he said naming the current/default repo "gentoo" was sufficient. > * Added emerge --ask thingie > Checks for new news messages should be displayed: [] > * After an ``emerge --pretend`` [] > * Before an ``emerge --ask `` sequence Wouldn't it be less confusing if the news warning appeared in the same place, relative to the package listing, in both of these? Isn't an emerge --ask just the output of pretend, with a confirmation pinned to the end? Shouldn't it continue to be that, at least in concept? > * news.read is now mandatory for interactive clients, and ignored for > gateway clients > When a news item is read, its name should be removed from the > ``news-magic-chicken.unread`` file. If a news client acts as an > interactive reader rather than a gateway, it should then add the name to > a ``news-magic-chicken.read`` file in the same directory with the same > file format (again, ``magic-chicken`` should be a wildcard rather than > hardcoded). First, the change outline doesn't state what the result actually was, in the GLEP. Mandatory would require a MUST (or a similar statement that it's mandatory), while the GLEP words it as a SHOULD. Or is "should" not to be taken in the usual RFC meaning, but rather as an RFC "MUST"? Second but related, the first time I read thru it, I somehow missed the "rather than a gateway" part. Upon rereading, I saw it (obviously), but the effect of the present wording is to deemphasize the "gateway" clause, as well as the "read" file. If it's truly a MUST, then the "read" file deserves equal treatment with the "unread" file, probably by introducing the two as a pair, then treating them in parallel thru most of the other references. (IOW, the read file and its requirement for interactive clients currently appears to be the afterthought it in fact was, without that fact being recognized, which doesn't particularly positively impress, quality-wise.) Third, recall from the discussion of an earlier draft, someone mentioned the multiple meaning of read (as here) vs. "read" (as in README). The suggestion to avoid that ambiguity was "seen" and "unseen". Another might be (un)viewed. I'm not sure this is a big enough issue to matter much, particularly with "unread" there as well, to influence the context, but as I don't recall that point being addressed, I thought I'd mention it here. > Read the whole thing before commenting please. I did. FWIW & IMO... Your tenacity and attention to detail are both extremely good qualities to have in someone doing a GLEP. Few have the attention to detail and self-standards necessary, and I fear many that do would give up due to the barrage of criticism (hopefully all constructive ) these things get. Do keep up the good work! IMO, you are /far/ better at it than most would be, and the resulting GLEP will ultimately be the better for it! -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote: > Jason Stubbs wrote: > >On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: > >>On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> > >> > >>wrote: > >>| So what are you going to do? I asked already but you didn't answer. > >>| How are you going to find $PORTDIR/metadata/news? > >> > >>At present, by using portageq with a hardcoded suffix. If in the future > >>Portage introduces new functionality, then clients and the > >>specification can easily be updated to handle said functionality. > > > >And how can that be adapted to work with overlays, completely ignoring the > >possibility of distinct repositories. Overlays is something that exists > >already and news support for them is a request that will appear as soon as > >news support is added. > > Your Point is Moot ... Interesting use of capitals. > because an overlay (at present) is going to be exprimental software, or a repository from a non-English speaking community Gentoo site... > (unsupported offically anyways) and so you _should_ know what risks your > taking, except if your a new non-English-speaking user utilizing such a repository. > this GLEP is to warn you about supported updates/changes which you _need_ to > know about. This GLEP is about getting news regarding a set of ebuilds to the user. Making it only about the Gentoo supported tree serves no purpose. > Why should an overlay need to have news if the user has the consciensely > update and maintain it to begin it. Because they already support package.mask, thirdpartymirrors, eclasses and just about anything else that exists in the supported tree. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | And how can that be adapted to work with overlays, completely > | ignoring the possibility of distinct repositories. Overlays is > | something that exists already and news support for them is a request > | that will appear as soon as news support is added. > > Overlays don't contain metadata directories There's nothing preventing this. > and don't get synced, As Zac pointed out, esync exists. > so they don't contain news items. Neither of the points above prevent an overlay from containing news items. > Supporting news from multiple sources is something that's tied to supporting > packages from multiple sources, which overlay doesn't permit. Overlays are used for getting packages from multiple sources every day. The only thing preventing them from supporting getting news from multiple sources is your stubborness against adding a single level of indirection - a level of indirection that has absolutely no cost to readers. > Fixing that would require fixing portage to support multiple repositories > rather than using overlay, which is an issue for a different GLEP. I'll say it again. It wouldn't require a GLEP because the changes wouldn't go beyond portage. At least they wouldn't if you'd allow portage to keep its internals internal. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:58, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | > So... If, hypothetically speaking, someone were to write a GLEP > | > saying "move developer documentation into the QA group, restructure > | > said documentation to this new format etc etc", and the QA group > | > were in favour, and the developer community in general were in > | > favour, and the council were in favour, and the people proposed by > | > the GLEP to manage the new documentation were in favour, but the > | > existing owners of the developer documentation were not, you're > | > saying that it shouldn't be approved? > | > | Yes. > > Unworkable. Your proposal would allow a small group of obstinate > developers to hold back progress. The problem here is that the council > isn't acting as a decent last line of quality control when the GLEP > authors fail to do their jobs properly. Your GLEP is trying to solve > the wrong thing... Wrong. I'll expand on the "Yes" now that I've got a few minutes... Actually, I'll turn that into a "No". I misread "the people proposed by the GLEP to manage the new documentation" in my rush to leave for work this morning. The existing owners don't matter to the GLEP. They can continue to maintain the existing documentation if they wish. If you didn't have new people to maintain the new documentation however... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
On Tue, 13 Dec 2005 05:19:27 -0700 Duncan <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh posted <[EMAIL PROTECTED]>, | excerpted below, on Tue, 13 Dec 2005 03:20:43 +: | | > Ok, new draft. Changes are as follows: | [] | > * Changed /var/lib/portage to /var/lib/gentoo | | OK, I must have missed the reason for that, and it isn't listed in | one of your "a previous version" notes, unless I missed that too. It's getting ready for the glorious future when we won't be using Portage any more. I also changed most of the instances of "Portage" in the GLEP to "the package manager". | Wouldn't it be less confusing if the news warning appeared in the same | place, relative to the package listing, in both of these? Isn't an | emerge --ask just the output of pretend, with a confirmation pinned | to the end? Shouldn't it continue to be that, at least in concept? It's a question of visibility. | First, the change outline doesn't state what the result actually was, | in the GLEP. Mandatory would require a MUST (or a similar statement | that it's mandatory), while the GLEP words it as a SHOULD. Or is | "should" not to be taken in the usual RFC meaning, but rather as an | RFC "MUST"? I'm avoiding 'must', because there's probably a legitimate exception somewhere. | Third, recall from the discussion of an earlier draft, someone | mentioned the multiple meaning of read (as here) vs. "read" (as in | README). The suggestion to avoid that ambiguity was "seen" and | "unseen". Another might be (un)viewed. I'm not sure this is a big | enough issue to matter much, particularly with "unread" there as | well, to influence the context, but as I don't recall that point | being addressed, I thought I'd mention it here. Pfff. Email clients use it. Trying to avoid words with multiple definitions in English is pretty much futile. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
On Tue, Dec 13, 2005 at 03:20:43AM +, Ciaran McCreesh wrote: > ``Posted:`` > Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001) for > compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss +`` > format > may also be included. Mandatory. Proposed change: ``Posted:`` Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for compatibility with ISO-8601. UTC time in ``T19:53:46+`` format may also be included (`date --iso-8601=seconds`). Mandatory. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpPo0gHg4Etn.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
On Tue, 13 Dec 2005 20:55:23 +0100 Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: | On Tue, Dec 13, 2005 at 03:20:43AM +, Ciaran McCreesh wrote: | > ``Posted:`` | > Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001) | > for compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss | > +`` format may also be included. Mandatory. | | Proposed change: | | ``Posted:`` | Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for | compatibility with ISO-8601. UTC time in ``T19:53:46+`` | format may also be included (`date --iso-8601=seconds`). Mandatory. I'll accept that change if you get Grant to accept a mini-GLEP switching the GLEPs over to use that format too. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
On Tue, Dec 13, 2005 at 08:03:29PM +, Ciaran McCreesh wrote: > I'll accept that change if you get Grant to accept a mini-GLEP > switching the GLEPs over to use that format too. Fair enough. What do you mean by a mini-GLEP? Grant, what are your thoughts on this? Would you be willing to accept such a change? Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpZwu7jHaCT8.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
On Tue, 13 Dec 2005 21:13:29 +0100 Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: | On Tue, Dec 13, 2005 at 08:03:29PM +, Ciaran McCreesh wrote: | > I'll accept that change if you get Grant to accept a mini-GLEP | > switching the GLEPs over to use that format too. | | Fair enough. What do you mean by a mini-GLEP? Like GLEP 43. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh schrieb: | | Proposed change: | | | | ``Posted:`` | | Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for | | compatibility with ISO-8601. UTC time in ``T19:53:46+`` | | format may also be included (`date --iso-8601=seconds`). Mandatory. | | I'll accept that change if you get Grant to accept a mini-GLEP | switching the GLEPs over to use that format too. I don't think that we need a GLEP for it, no matter how 'mini' it would be.. Just asked Grant if I can convert dates in current GLEPs, and he's ok with, though he wanted to have input from -dev first, so: Anyone objecting to change those dates from "dd-mon-" format to "-mm-dd"? If not, i'll commit my diff in 24h... Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm vqe7CvpCLGklzdgsb3DUq54= =offW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Well, it would be changing Glep 1... which probably needs an ammendatory GLEP On 12/13/05, Danny van Dyk <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ciaran McCreesh schrieb: > | | Proposed change: > | | > | | ``Posted:`` > | | Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for > | | compatibility with ISO-8601. UTC time in ``T19:53:46+`` > | | format may also be included (`date --iso-8601=seconds`). Mandatory. > | > | I'll accept that change if you get Grant to accept a mini-GLEP > | switching the GLEPs over to use that format too. > > I don't think that we need a GLEP for it, no matter how 'mini' it > would be.. Just asked Grant if I can convert dates in current GLEPs, > and he's ok with, though he wanted to have input from -dev first, so: > > Anyone objecting to change those dates from "dd-mon-" format to > "-mm-dd"? > > If not, i'll commit my diff in 24h... > > Danny > - -- > Danny van Dyk <[EMAIL PROTECTED]> > Gentoo/AMD64 Project, Gentoo Scientific Project > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm > vqe7CvpCLGklzdgsb3DUq54= > =offW > -END PGP SIGNATURE- > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, 13 Dec 2005 21:35:44 +0100 Danny van Dyk <[EMAIL PROTECTED]> wrote: | I don't think that we need a GLEP for it, no matter how 'mini' it | would be.. Just asked Grant if I can convert dates in current GLEPs, | and he's ok with, though he wanted to have input from -dev first, so: | | Anyone objecting to change those dates from "dd-mon-" format to | "-mm-dd"? I object. You're changing the GLEP process, and the way that that's done is through another GLEP. Otherwise we'll end up with people writing GLEPs following GLEP 1, and not realising that GLEP 1 is no longer how things work. Doing things properly wouldn't be difficult here. GLEP 43 took less than half an hour. It's worth doing it for the sake of not confusing future GLEP authors. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, Dec 13, 2005 at 03:36:33PM -0500, Dan Meltzer wrote: > Well, it would be changing Glep 1... which probably needs an ammendatory GLEP or we avoid all the redtape bs and just do it, let anarchy rule the docs team already require dates to be in -MM-DD format and it makes sense to me -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Danny van Dyk wrote: [Tue Dec 13 2005, 02:35:44PM CST] > | I'll accept that change if you get Grant to accept a mini-GLEP > | switching the GLEPs over to use that format too. > > I don't think that we need a GLEP for it, no matter how 'mini' it > would be.. Just asked Grant if I can convert dates in current GLEPs, > and he's ok with, though he wanted to have input from -dev first, so: > > Anyone objecting to change those dates from "dd-mon-" format to > "-mm-dd"? Note that GLEP 1 would need to be amended, too, to reflect the new format. > If not, i'll commit my diff in 24h... I actually had in mind a couple of days, just to make sure that people had a reasonable chance to respond -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpxLb4157UcG.pgp Description: PGP signature
Re: [gentoo-dev] Re: Changes to date format of current GLEPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, Dan Meltzer schrieb: | Well, it would be changing Glep 1... which probably needs an ammendatory GLEP I would apply these changes to glep-0001.txt: [EMAIL PROTECTED] glep $ cvs diff glep-0001.txt Index: glep-0001.txt === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0001.txt,v retrieving revision 1.8 diff -u -b -B -r1.8 glep-0001.txt - --- glep-0001.txt 4 Apr 2004 23:05:35 - 1.8 +++ glep-0001.txt 13 Dec 2005 20:45:37 - @@ -6,8 +6,8 @@ ~ Status: Active ~ Type: Informational ~ Content-Type: text/x-rst - -Created: 31-May-2003 - -Post-History: 1-Jun-2003, 2-Jul-2003 +Created: 2003-05-31 +Post-History: 2003-06-01, 2003-07-02 Do you _really_ think this make a GLEP necessary? Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzUXaVNL8NrtU6IRAnruAJ4zXT5+gtyvKHi3BbD1EPvJYACCYwCgmG6z FW28Kz5W3N1nFz3ZJuPOEh8= =tVHu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RE: Changes to date format of current GLEPs
Whoops, sending to the list is a good idea -- Forwarded message -- From: Dan Meltzer <[EMAIL PROTECTED]> Date: Tue, 13 Dec 2005 15:51:16 -0500 Subject: Re: Changes to date format of current GLEPs To: Danny van Dyk <[EMAIL PROTECTED]> Nope, but the changes further on. > Created: > The Created header records the date that the GLEP was assigned a number, > while > Post-History is used to record the dates of when new versions of the > GLEP are > posted to gentoo-dev. Both headers should be in dd-mmm- format, e.g. > 14-Aug-2001. Should On 12/13/05, Danny van Dyk <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Dan, > > Dan Meltzer schrieb: > | Well, it would be changing Glep 1... which probably needs an > ammendatory GLEP > > I would apply these changes to glep-0001.txt: > [EMAIL PROTECTED] glep $ cvs diff glep-0001.txt > Index: glep-0001.txt > === > RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0001.txt,v > retrieving revision 1.8 > diff -u -b -B -r1.8 glep-0001.txt > - --- glep-0001.txt 4 Apr 2004 23:05:35 - 1.8 > +++ glep-0001.txt 13 Dec 2005 20:45:37 - > @@ -6,8 +6,8 @@ > ~ Status: Active > ~ Type: Informational > ~ Content-Type: text/x-rst > - -Created: 31-May-2003 > - -Post-History: 1-Jun-2003, 2-Jul-2003 > +Created: 2003-05-31 > +Post-History: 2003-06-01, 2003-07-02 > > Do you _really_ think this make a GLEP necessary? > > Danny > - -- > Danny van Dyk <[EMAIL PROTECTED]> > Gentoo/AMD64 Project, Gentoo Scientific Project > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDnzUXaVNL8NrtU6IRAnruAJ4zXT5+gtyvKHi3BbD1EPvJYACCYwCgmG6z > FW28Kz5W3N1nFz3ZJuPOEh8= > =tVHu > -END PGP SIGNATURE- > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, 13 Dec 2005 20:44:42 + Mike Frysinger <[EMAIL PROTECTED]> wrote: | On Tue, Dec 13, 2005 at 03:36:33PM -0500, Dan Meltzer wrote: | > Well, it would be changing Glep 1... which probably needs an | > ammendatory GLEP | | or we avoid all the redtape bs and just do it, let anarchy rule It's not a question of red tape. Red tape would be requiring that the GLEP be approved by twenty six different managers and team leads. It's a question of having the change documented properly so that future GLEP authors don't get bitten, and so that future GLEP authors understand the rationale so that they don't go and introduce something that has the same problems as the GLEP 1 date format. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, 2005-13-12 at 20:43 +, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 21:35:44 +0100 Danny van Dyk <[EMAIL PROTECTED]> > wrote: > | I don't think that we need a GLEP for it, no matter how 'mini' it > | would be.. Just asked Grant if I can convert dates in current GLEPs, > | and he's ok with, though he wanted to have input from -dev first, so: > | > | Anyone objecting to change those dates from "dd-mon-" format to > | "-mm-dd"? > > I object. You're changing the GLEP process, and the way that that's > done is through another GLEP. Otherwise we'll end up with people > writing GLEPs following GLEP 1, and not realising that GLEP 1 is no > longer how things work. Why not just modify GlEP 1 ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ciaran, Ciaran McCreesh schrieb: | | Anyone objecting to change those dates from "dd-mon-" format to | | "-mm-dd"? | | I object. You're changing the GLEP process, and the way that that's | done is through another GLEP. Otherwise we'll end up with people It wouldn't change the GLEP process. It changes how we document a date information. | writing GLEPs following GLEP 1, and not realising that GLEP 1 is no | longer how things work. No, they'd have to follow GLEP 2, the GLEP Template... | Doing things properly wouldn't be difficult here. GLEP 43 took less | than half an hour. It's worth doing it for the sake of not confusing | future GLEP authors. I just change all date strings in all glep-.txt ... Nobody will be confused if he has a look into the template GLEP first. Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzZVaVNL8NrtU6IRAnVWAJ9nGEEqRqv6D4CbGh1RLNPvVn8aygCgm1JE iqNotfEWrZQuqfVfSiBzGqI= =KyUu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Ciaran McCreesh wrote: [Tue Dec 13 2005, 02:43:42PM CST] > I object. You're changing the GLEP process, and the way that that's > done is through another GLEP. Otherwise we'll end up with people > writing GLEPs following GLEP 1, and not realising that GLEP 1 is no > longer how things work. > > Doing things properly wouldn't be difficult here. GLEP 43 took less > than half an hour. It's worth doing it for the sake of not confusing > future GLEP authors. Okay, I'll acquiesce to the call for a GLEP. It seems a tad extravagant, since I'll be the one approving it, but I can agree that having the change documented would be useful. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpwHiBPFT5Es.pgp Description: PGP signature
[gentoo-dev] Textrels in packages policy
Basically what I'm looking for here is an easy to understand explanation of what textrels are, why they are bad, and why they should hold back marking a package stable. The only information I've been able to find states that they could cause a performance hit, but this doesn't seem to warrant banning them completely in my eyes. Getting a clear cut policy on exactly what issues should hold a package back from being marked stable is what I'm looking for. Issues like textrels, executable stacks, etc is what I'm looking for to be defined and explained why we are to always avoid them. This should be added to existing documentation policy so it is somewhere for new devs to know about, and existing devs to have for a reference. Thanks -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpqTyAhTziGc.pgp Description: PGP signature
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <[EMAIL PROTECTED]> wrote: | Why not just modify GlEP 1 ? Going back and retroactively modifying standards is icky, and it *still* doesn't address the issue of documenting why the change was made. You know, a GLEP could have been written and posted by now :) -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 03:59:03PM -0500, Mark Loeser wrote: > Basically what I'm looking for here is an easy to understand explanation of > what textrels are, why they are bad, and why they should hold back marking a > package stable. The only information I've been able to find states that they > could cause a performance hit, but this doesn't seem to warrant banning them > completely in my eyes. erm, this e-mail comes a bit early ... i was hoping to have more stuff written before moving this info into gentoo-dev mailing list realm ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] > The purpose of GLEPs is to coordinate several teams into providing an > overall enhancement to Gentoo. However, the GLEP itself is written by > a single person rather than a cooperative effort between the teams. You know, there's no reason that GLEPs need to be written by a single person. It's often true, though, that it is a single person's idea, initially at least. > Specification > > Rather than coming to the ML with a completed GLEP and then asking for > feedback, a GLEP author should look at the teams involved and then > select a solicit a member from each team to be responsible for that > area of the GLEP. The GLEP author may represent any teams they belong > to. Throwing out the initial GLEP amounts to the same thing, in my opinion, since any interested parties are urged to provide feedback, and ideally the next revision will include that feedback, either to accept it or reject it. > Rationale > > Rather than doing lots of hard work and having it thrown away once it > is found to be unacceptable by the teams involved, the teams involved > share the hard work and come up with something acceptable to everybody > right from the outset. Yes, of course, GLEP authors should talk to the folks who are likely to be affected beforehand, but if they fail to do so then the GLEP process is likely to be rather protracted for that GLEP. I have to admit that I have no problem with people doing hard work for little gain, if that's what people want to do. *Shrug* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp0pldxoayh2.pgp Description: PGP signature
[gentoo-dev] GLEP XX - GLEP date and time format
GLEP: XX Title: GLEP date and time format Version: $Revision: $ Author: Henrik Brix Andersen <[EMAIL PROTECTED]> Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Dec-2005 Post-History: 13-Dec-2005 Abstract This GLEP proposes using an ISO-8601 compliant date format in GLEPs. Motivation == The current date format used in GLEPs is ``dd-mmm-`` format (e.g. 14-Aug-2001). This format is not internationalized and not easily machine parsable. This GLEP proposes switching to using an ISO-8601 compliant date format ``-dd-mm`` (e.g. 2001-08-14). This format is international and easily machine parseable. It also allows specifying the time of day (e.g. ``2001-08-14T19:53:46+``). Specification = An overview of the ISO-8601 specification is available online at http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html The date(1) utility also supports ISO-8601, making it easy for GLEP authors to get the format right. Backwards Compatibility === GLEP 1 should be updated to reflect this new date format, and all dates in existing GLEPs should be changed to ISO-8601. Copyright = This document has been placed in the public domain. -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpUArz26w68t.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: Changes to date format of current GLEPs
13.12.2005, 22:00:12, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 21:54:48 +0100 Danny van Dyk <[EMAIL PROTECTED]> > wrote: > | Do you _really_ think this make a GLEP necessary? > Yes. Otherwise, the next person who comes along and writes a GLEP that > does something to do with dates will have to rationalise the whole date > format decision all over again. > You're assuming that "GLEP == lots of work". This is the case for some > things, but it isn't true in all situations. Look at 43 for an example. Pardon my ignorance, but how's a GLEP amending a GLEP (amending a GLEP ...) less confusing than just changing the text of the original GLEP... Huh, goes beyond me... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp6OIKAOoK3K.pgp Description: PGP signature
Re: [gentoo-dev] GLEP XX - GLEP date and time format
On Tue, Dec 13, 2005 at 10:17:07PM +0100, Henrik Brix Andersen wrote: > This GLEP proposes switching to using an ISO-8601 compliant date > format ``-dd-mm`` (e.g. 2001-08-14). This format is international ^^ That should of course read ``-mm-dd``, sorry. > and easily machine parseable. It also allows specifying the time of > day (e.g. ``2001-08-14T19:53:46+``). ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpCwx8ICZDKs.pgp Description: PGP signature
Re: [gentoo-dev] Re: Changes to date format of current GLEPs
On Tue, 13 Dec 2005 21:54:48 +0100 Danny van Dyk <[EMAIL PROTECTED]> wrote: | Do you _really_ think this make a GLEP necessary? Yes. Otherwise, the next person who comes along and writes a GLEP that does something to do with dates will have to rationalise the whole date format decision all over again. You're assuming that "GLEP == lots of work". This is the case for some things, but it isn't true in all situations. Look at 43 for an example. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Changes to date format of current GLEPs
On Tue, 13 Dec 2005 22:18:36 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | Pardon my ignorance, but how's a GLEP amending a GLEP (amending a | GLEP ...) less confusing than just changing the text of the original | GLEP... Huh, goes beyond me... History. Look at RFCs for a good example. There's nothing wrong with extending or replacing parts of existing standards, especially if the existing standards are clearly marked as "extended by $blah" or "replaced by $blah". On the other hand, changing accepted GLEPs leads to confusion -- when someone says "GLEP 1", do they mean "GLEP 1 as it was when it was approved" or "GLEP 1 plus the modifications made three weeks ago" or "GLEP 1 plus the modifications made three weeks ago plus the modifications made last Tuesday"? Plus, of course, it helps to have a record of *why* changes were made... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP XX - GLEP date and time format
On Tue, Dec 13, 2005 at 10:17:07PM +0100, Henrik Brix Andersen wrote: > GLEP: XX > Title: GLEP date and time format After discussing this proposal on IRC with ciaranm and g2boojum, a few changes have been made: * Restrict the GLEP to deal with dates (not time) * Use proper GLEP format Since I have no idea on how to use docutils, I'd be grateful if someone familiar with the process (Grant?) could commit this to CVS. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd GLEP: 45 Title: GLEP date format Version: $Revision: $ Author: Henrik Brix Andersen <[EMAIL PROTECTED]> Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Dec-2005 Post-History: 13-Dec-2005 Abstract This GLEP proposes using an ISO-8601 compliant date format in GLEPs. Motivation == The current date format used in GLEPs is ``dd-mmm-`` (e.g. 14-Aug-2001). This format is not internationalized and not easily machine parseable. This GLEP proposes switching to using an ISO-8601 compliant date format ``-mm-dd`` (e.g. 2001-08-14). This format is international and easily machine parseable. Specification = An overview of the ISO-8601 specification is available online [#iso-8601]_. Note that only the ``-mm-dd`` subset of the ISO-8601 specification should be used in GLEPs. The date(1) utility supports ISO-8601, making it easy for GLEP authors to get the format right. Backwards Compatibility === GLEP 1 should be updated to reflect this new date format, and all dates in existing GLEPs should be changed to be ISO-8601 compliant. References == .. [#iso-8601] Numeric representation of Dates and Time, http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html Copyright = This document has been placed in the public domain. pgpO2lVmqLW4R.pgp Description: PGP signature
Re: [gentoo-dev] Re: Changes to date format of current GLEPs
On Tue, 2005-12-13 at 21:38 +, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 22:18:36 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | Pardon my ignorance, but how's a GLEP amending a GLEP (amending a > | GLEP ...) less confusing than just changing the text of the original > | GLEP... Huh, goes beyond me... > > History. Look at RFCs for a good example. There's nothing wrong with > extending or replacing parts of existing standards, especially if the > existing standards are clearly marked as "extended by $blah" or > "replaced by $blah". On the other hand, changing accepted GLEPs leads to > confusion -- when someone says "GLEP 1", do they mean "GLEP 1 as it was > when it was approved" or "GLEP 1 plus the modifications made three > weeks ago" or "GLEP 1 plus the modifications made three weeks ago plus > the modifications made last Tuesday"? > > Plus, of course, it helps to have a record of *why* changes were > made... > Or IEEE ish Original: GLEP 01 Ammended: GLEP 01.a -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] > > | There doesn't need to be a debate. This whole proposal doesn't care > > | about portage compatibility whatsoever and it's exactly this style of > > | thinking that slows down portage development (which everybody loves > > | to complain about so much). > > > > Sure it does. It cares about the way Portage is currently, and it cares > > about any reasonable future Portage changes. > > Bullshit. I'm not quite sure I understand the strong response. The GLEP was clearly designed to have a minimal impact on portage. Now I'm willing to listen to arguments that it does not, in fact, do that, but certainly the well-defined, minimal coupling between the news and emerge was not accidental. (Incidentally, I've never complained about the pace of portage development. I'm not developing it, so I don't complain about those who are.) Just as an aside, it would be nice if we could keep [EMAIL PROTECTED] vulgarity-free, since it's a list that's often read at work by a good number of people. > > > | As I said already, there will immediately be a bug asking for overlay > > | support. Portage already supports multiple in a form whether anybody > > | likes it or not. How they are supported and how they will change > > | should be of no concern to the glep. What should be of concern is > > | establishing a robust API between the readers and portage such that > > | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp9qHX6VO2Cp.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Tue, 13 Dec 2005, Mark Loeser wrote: > Basically what I'm looking for here is an easy to understand explanation of > what textrels are, why they are bad, and why they should hold back marking a > package stable. The only information I've been able to find states that they > could cause a performance hit, but this doesn't seem to warrant banning them > completely in my eyes. Given my limited knowledge on this, this is my understanding. TEXTRELS are basically text relocations. What this is, is relocation within the text segment of the process image. This brings up the question of what a relocation is. A relocation is simply the replacement of some text with a memory location. The big issue with this is that the text segment is usually suppose to be read only for security reasons. But because the text segment needs a relocation, it needs to be read-write since the relocation happens at runtime dynamically. The constant need to look up the address is what causes the performance degredation. The performance degredation however is of no worry to us. The issue is that since the text segment is now read-write, the image of the process is no longer guaranteed to remain the same as it can be overwritten (allowing code modifications at runtime which can happen other ways as well). Because of this, the application is far more vurnerable to arbitrary code execution as if an exploit manages to overwrite the text segment properly, it can execute code that it wants. I am not sure how correct this explanation is or it is even what you were looking for. > Getting a clear cut policy on exactly what issues should hold a package back > from being marked stable is what I'm looking for. Issues like textrels, > executable stacks, etc is what I'm looking for to be defined and explained > why > we are to always avoid them. This should be added to existing documentation > policy so it is somewhere for new devs to know about, and existing devs to > have for a reference. I agree, this would be very nice to have. It would make stabilization of packages a little bit easier. Thanks. Saleem Abdulrasool compnerd (at) gentoo (dot) org pgp64bkVZkTlP.pgp Description: PGP signature
Re: [gentoo-dev] GLEP XX - GLEP date and time format
Henrik Brix Andersen wrote: [Tue Dec 13 2005, 03:41:55PM CST] > Since I have no idea on how to use docutils, I'd be grateful if > someone familiar with the process (Grant?) could commit this to CVS. Committed to CVS. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpLxpJ2UeD24.pgp Description: PGP signature
Re: [gentoo-dev] GLEP XX - GLEP date and time format
On Tue, Dec 13, 2005 at 04:43:48PM -0600, Grant Goodyear wrote: > Committed to CVS. Thank you. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgp8rVH1WNvTP.pgp Description: PGP signature
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, 2005-13-12 at 21:09 +, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <[EMAIL PROTECTED]> > wrote: > | Why not just modify GlEP 1 ? > > Going back and retroactively modifying standards is icky, and it > *still* doesn't address the issue of documenting why the change was > made. And why not just adding a changelog to the glep explaining the changes? I really don't like to idea of having to read 8 gleps to find out how to write a glep ... and calling it glep 1.a is a good idea.. or 1.1 -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 13 Dec 2005 19:20:00 +: > Duncan wrote: > > | Ciaran McCreesh posted ... > | > | > * Changed /var/lib/portage to /var/lib/gentoo > | > | OK, I must have missed the reason for that > > It's getting ready for the glorious future when we won't be using > Portage any more. I also changed most of the instances of "Portage" in > the GLEP to "the package manager". I noticed the generic "package manager" stuff, but hadn't put two and two together. I have mixed feelings but see the point. > | Mandatory would require a MUST (or a similar statement > | that it's mandatory), while the GLEP words it as a SHOULD. > > I'm avoiding 'must', because there's probably a legitimate exception > somewhere. Makes sense. Just didn't agree with the change summary, and I wondered which was intended. > | Third, recall from the discussion of an earlier draft, someone > | mentioned the multiple meaning of read (as here) vs. "read" (as in > | README). > > Pfff. Email clients use it. Trying to avoid words with multiple > definitions in English is pretty much futile. Agreed. Just hadn't seen the point addressed, and recalled seeing it mentioned. Thanks! -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, Dec 13, 2005 at 06:05:03PM -0500, Olivier Crete wrote: > And why not just adding a changelog to the glep explaining the changes? > I really don't like to idea of having to read 8 gleps to find out how to > write a glep ... and calling it glep 1.a is a good idea.. or 1.1 GLEP 45, "GLEP date format", says that GLEP 1 should be modified to reflect this new date format, should it be accepted. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpzGjDsd0xv1.pgp Description: PGP signature
[gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
http://viewcvstest.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0001.html?rev=1.8&view=log meh, when it comes down to it... isn't this good enough of a change log? On 12/13/05, Olivier Crete <[EMAIL PROTECTED]> wrote: > On Tue, 2005-13-12 at 21:09 +, Ciaran McCreesh wrote: > > On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <[EMAIL PROTECTED]> > > wrote: > > | Why not just modify GlEP 1 ? > > > > Going back and retroactively modifying standards is icky, and it > > *still* doesn't address the issue of documenting why the change was > > made. > > And why not just adding a changelog to the glep explaining the changes? > I really don't like to idea of having to read 8 gleps to find out how to > write a glep ... and calling it glep 1.a is a good idea.. or 1.1 > > -- > Olivier Crête > [EMAIL PROTECTED] > Gentoo Developer > > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
14.12.2005, 0:05:03, Olivier Crete wrote: > And why not just adding a changelog to the glep explaining the changes? > I really don't like to idea of having to read 8 gleps to find out how to > write a glep ... and calling it glep 1.a is a good idea.. or 1.1 +1 -- jakub pgpLbeynqVjnu.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] > > > | As I said already, there will immediately be a bug asking for overlay > > > | support. Portage already supports multiple in a form whether anybody > > > | likes it or not. How they are supported and how they will change > > > | should be of no concern to the glep. What should be of concern is > > > | establishing a robust API between the readers and portage such that > > > | future changes won't cause breakage. > > Wouldn't it suffice for the GLEP to simply have a statement that it will > query portage for a list of repositories, once there's a way to do that, > but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | Modifications are required to portage anyway. Why postpone it until | after several readers are written and force all of them become broken? Because there isn't a specification saying what the future changes to Portage will be, so supporting said future changes straight off would require a massively over-generalised, over-indirected solution. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: > Basically what I'm looking for here is an easy to understand explanation of > what textrels are, why they are bad, and why they should hold back marking a > package stable. The only information I've been able to find states that they > could cause a performance hit, but this doesn't seem to warrant banning them > completely in my eyes. > > Getting a clear cut policy on exactly what issues should hold a package back > from being marked stable is what I'm looking for. Issues like textrels, > executable stacks, etc is what I'm looking for to be defined and explained > why > we are to always avoid them. This should be added to existing documentation > policy so it is somewhere for new devs to know about, and existing devs to > have for a reference. > > Thanks > Only problem I see with this is binary packages. We can not control upstream binaries as everyone is aware of. So when does it become safe to override stable packages that have texrel's and executable stacks? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDn2BVGDfjNg8unQIRAupGAKCiTPJseSVrklDjWXqwEdeHFDxnRQCcD0xQ mzjn2yXHiNSdBcnFkCTD+u0= =RYEw -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Olivier Crete wrote: > On Tue, 2005-13-12 at 21:09 +, Ciaran McCreesh wrote: >> On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <[EMAIL PROTECTED]> >> wrote: >> | Why not just modify GlEP 1 ? >> >> Going back and retroactively modifying standards is icky, and it >> *still* doesn't address the issue of documenting why the change was >> made. > > And why not just adding a changelog to the glep explaining the changes? > I really don't like to idea of having to read 8 gleps to find out how to > write a glep ... and calling it glep 1.a is a good idea.. or 1.1 > agree, have to dig multiple places to get the history of a document is annoying. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Tue Dec 13 2005, 05:44:39PM CST] > > Wouldn't it suffice for the GLEP to simply have a statement that it will > > query portage for a list of repositories, once there's a way to do that, > > but until then the default repo will be assumed? > > Modifications are required to portage anyway. Why postpone it until after > several readers are written and force all of them become broken? Okay, so what is the portage team proposing to use for a repo query API? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpKJpt3hG1A8.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Modifications are required to portage anyway. Why postpone it until > | after several readers are written and force all of them become broken? > > Because there isn't a specification saying what the future changes to > Portage will be, so supporting said future changes straight off would > require a massively over-generalised, over-indirected solution. newsdir="$(portageq envvar PORTDIR)/metadata/news" newsdir="$(portageq newsdir gentoo)" Both have one level of indirection. The first has two hard coded elements. The first has one. Where is the massive over-indirection? The second allows future changes. The first does not. Where does the specification come into it? All that would be needed is to allow a user a method to name overlays and it'd be useful straight off the bat. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 10:30:59PM +, Saleem A. wrote: > On Tue, 13 Dec 2005, Mark Loeser wrote: > > > Basically what I'm looking for here is an easy to understand explanation of > > what textrels are, why they are bad, and why they should hold back marking a > > package stable. The only information I've been able to find states that > > they > > could cause a performance hit, but this doesn't seem to warrant banning them > > completely in my eyes. > > The big issue with > this is that the text segment is usually suppose to be read only for > security reasons. But because the text segment needs a relocation, it > needs to be read-write since the relocation happens at runtime > dynamically. this is correct, a very good reason to fix TEXTRELs. another good reason is that since the segment cannot be mapped readonly, the memory cannot be shared across multiple processes ... each will need to have its own copy, thus wasting what could be significant memory resources. > The constant need to look up the address is what causes > the performance degredation. The performance degredation however is of > no worry to us. if by "constant" you mean "once everytime the code is loaded", then you are correct ... the relocations need to be rewritten everytime the image is loaded into memory by the dynamic loader (ldso), but after the first fixup, that's it, nothing else to be done. > > Getting a clear cut policy on exactly what issues should hold a package > > back > > from being marked stable is what I'm looking for. Issues like textrels, > > executable stacks, etc is what I'm looking for to be defined and explained > > why > > we are to always avoid them. This should be added to existing documentation > > policy so it is somewhere for new devs to know about, and existing devs to > > have for a reference. > > I agree, this would be very nice to have. It would make stabilization > of packages a little bit easier. working on it as i said ... i wish this e-mail could have been posted once i had more easier things to read :p -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 05:59:17PM -0600, Jory A. Pratt wrote: > Mark Loeser wrote: > > Basically what I'm looking for here is an easy to understand explanation of > > what textrels are, why they are bad, and why they should hold back marking a > > package stable. The only information I've been able to find states that > > they > > could cause a performance hit, but this doesn't seem to warrant banning them > > completely in my eyes. > > > > Getting a clear cut policy on exactly what issues should hold a package > > back > > from being marked stable is what I'm looking for. Issues like textrels, > > executable stacks, etc is what I'm looking for to be defined and explained > > why > > we are to always avoid them. This should be added to existing documentation > > policy so it is somewhere for new devs to know about, and existing devs to > > have for a reference. > > Only problem I see with this is binary packages. We can not control > upstream binaries as everyone is aware of. So when does it become safe > to override stable packages that have texrel's and executable stacks? no idea what you mean by "override", but here's a crazy idea ... ask upstream to fix the issues. for example, we just reported executable stacks with the ut2004 game and Ryan of epicgames was so kind as to fix it up for us. some upstream peeps dont even know about these sort of things until you point them out. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | newsdir="$(portageq envvar PORTDIR)/metadata/news" | newsdir="$(portageq newsdir gentoo)" | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
Mike Frysinger <[EMAIL PROTECTED]> said: > this is correct, a very good reason to fix TEXTRELs. another good > reason is that since the segment cannot be mapped readonly, the memory > cannot be shared across multiple processes ... each will need to have > its own copy, thus wasting what could be significant memory resources. Sounds like something nice to do, but not something that should be _required_ for a package to be deemed stable. > > The constant need to look up the address is what causes > > the performance degredation. The performance degredation however is of > > no worry to us. > > if by "constant" you mean "once everytime the code is loaded", then you > are correct ... the relocations need to be rewritten everytime the image > is loaded into memory by the dynamic loader (ldso), but after the first > fixup, that's it, nothing else to be done. Again, nice to fix, but does not seem necessary. > working on it as i said ... i wish this e-mail could have been posted > once i had more easier things to read :p You are working on a policy, or just docs to explain the issues? From what was listed above, I'm not sure why we should require that people fix these issues just to have a package deemed stable. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpqnl9LWsDn7.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Wed, 14 Dec 2005 00:22:36 + Mike Frysinger <[EMAIL PROTECTED]> wrote: | > The big issue with | > this is that the text segment is usually suppose to be read only for | > security reasons. But because the text segment needs a relocation, | > it needs to be read-write since the relocation happens at runtime | > dynamically. | | this is correct, a very good reason to fix TEXTRELs. This is only an issue if an application is already insecure. Thus, TEXTRELs shouldn't be considered sufficient reason to avoid marking something stable, any more than we avoid marking code that uses sprintf stable. | another good reason is that since the segment cannot be mapped | readonly, the memory cannot be shared across multiple processes ... | each will need to have its own copy, thus wasting what could be | significant memory resources. Again, that's a big "could be". We don't avoid marking stable code that, say, mallocs lots of space, then fills it with some calculated numbers (for example, the first million prime numbers), even though a better program would allow for that data to be shared. So yes, TEXTRELs when used accidentally are rather sucky. On the other hand, there are legitimate uses for them, and they aren't insecure, nor are they necessarily any worse performance-wise than code that uses other methods. Banning TEXTRELs outright makes no more sense than banning code that uses goto or sprintf -- if TEXTRELs are used accidentally and there's an easy fix, take it, but don't let them stop you from providing the most stable version of a package to your users. Oh, and don't accept reasons like "but they don't work if we enable $obscure_voodoo in the compiler" either. If $obscure_voodoo breaks on legitimate TEXTRELs then $obscure_voodoo is broken, not the code using TEXTRELs. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Tue, 13 Dec 2005 20:02:27 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: | You are working on a policy, or just docs to explain the issues? | From what was listed above, I'm not sure why we should require that | people fix these issues just to have a package deemed stable. Some people want no TEXTRELs to be a requirement because they're superstitious, or because they read somewhere that TEXTRELs are naughty and are repeating the conclusion without understanding the underlying reasons. It's approximately on par with trying to ban all code that uses 'goto' because it breaks certain security auditing tools that rely upon call graphs. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 08:02:27PM -0500, Mark Loeser wrote: > Mike Frysinger <[EMAIL PROTECTED]> said: > > working on it as i said ... i wish this e-mail could have been posted > > once i had more easier things to read :p > > You are working on a policy, or just docs to explain the issues? documentation on PIC/TEXTRELs/etc... the policy i consider a no-brainer, fix TEXTRELs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 01:07:53AM +, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 00:22:36 + Mike Frysinger <[EMAIL PROTECTED]> > | another good reason is that since the segment cannot be mapped > | readonly, the memory cannot be shared across multiple processes ... > | each will need to have its own copy, thus wasting what could be > | significant memory resources. > > Again, that's a big "could be". it's more often an "is be" considering the fact we're talking about shared library code here. > We don't avoid marking stable code > that, say, mallocs lots of space, then fills it with some calculated > numbers (for example, the first million prime numbers), even though a > better program would allow for that data to be shared. no one said that broken code with TEXTRELs cannot be marked stable they're something to be fixed down the road as time permits > Oh, and don't accept reasons like "but they don't work if we enable > $obscure_voodoo in the compiler" either. If $obscure_voodoo breaks on > legitimate TEXTRELs then $obscure_voodoo is broken, not the code using > TEXTRELs. majority of the time, if a build process is generating poor code with textrels, it wont work on most architectures. x86 just tends to be pretty lenient when it comes to poor code, so no one notices/cares. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
Mike Frysinger <[EMAIL PROTECTED]> said: > > We don't avoid marking stable code > > that, say, mallocs lots of space, then fills it with some calculated > > numbers (for example, the first million prime numbers), even though a > > better program would allow for that data to be shared. > > no one said that broken code with TEXTRELs cannot be marked stable > > they're something to be fixed down the road as time permits This I completely agree with, but was not what was being pushed as policy for the x86 arch team. If a package reintroduces textrels or such, I don't see the problem with marking it stable personally. The issues listed don't seem to warrant that. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpofdVS6jpvI.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Wed, 14 Dec 2005 01:20:29 + Mike Frysinger <[EMAIL PROTECTED]> wrote: | the policy i consider a no-brainer, fix TEXTRELs So... Say libfoo is a library that decodes files in the foo format. Say also that libfoo-2.1 is currently marked stable, and does not contain any TEXTRELs, but only supports foo files using the foo-1 format, which is rapidly becoming obsolete. Then, if libfoo-2.2 comes along, and introduces support for the rapidly becoming very widely used foo-2 format, should libfoo-2.2 be held back from being marked stable purely because of a TEXTREL? What about if, instead, libfoo-2.1 contains a security bug that is fixed by libfoo-2.2? What about if, instead, libfoo-2.1 has a nasty bug that will cause it to lose data under certain circumstances? See, any policy on TEXTRELs will have to be *very* carefully worded to avoid having people think that they're something important... Otherwise we'll end up with broken packages being left in stable simply because newer versions contain TEXTRELs. Don't overhype the problem -- make it clear that it's a "would be nice" issue, or else you'll encourage even more superstition than we have already... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
Mike Frysinger <[EMAIL PROTECTED]> said: > On Tue, Dec 13, 2005 at 08:02:27PM -0500, Mark Loeser wrote: > > You are working on a policy, or just docs to explain the issues? > > documentation on PIC/TEXTRELs/etc... > > the policy i consider a no-brainer, fix TEXTRELs By policy, I mean things to add to the ebuild policy stating, "These conditions must be met in order to consider a package stable:". I'll assume that is not what you are working on since nothing you have listed so far seems to imply this. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpRexJ34OhCQ.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 01:37:57AM +, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 01:20:29 + Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | the policy i consider a no-brainer, fix TEXTRELs > > So... Say libfoo is > blah blah blah i didnt read this e-mail, i imagine it's your normal stuff though, so i'm not missing much as i said, i'm pro-fixing TEXTRELs, not pro-preventing-packages-from-getting-into-stable-because-it-has-TEXTRELs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
For reference, I'm quoting this snippet from earlier in the thread: Jason Stubbs wrote: On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: .. Note:: Future changes to Portage involving support for multiple repositories may require one news list per repository. Assuming repositories have some kind of unique identifier, this file could be named ``news-repoid.unread``. Repositories will definitely have a unique identifier. Perhaps it would be better to use the repository-identifing format from the beginning so that readers are forced to be forwards-compatible? Assuming the readers would then output the repository name, labeling it "gentoo" should work well... [...] Ciaran McCreesh wrote: On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | newsdir="$(portageq envvar PORTDIR)/metadata/news" | newsdir="$(portageq newsdir gentoo)" | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. Apparently, 'gentoo' is meant to be the identifier for the official gentoo repository (portage tree). It corresponds to 'magic-chicken' below. Ciaran McCreesh wrote: Whenever relevant unread news items are found, the package manager will create a file named ``/var/lib/gentoo/news/news-magic-chicken.unread`` (if it does not already exist) and append the news item identifier (eg ``2005-11-01-yoursql-updates``) on a new line. Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, 14 Dec 2005 00:25:57 + Mike Frysinger <[EMAIL PROTECTED]> wrote: > no idea what you mean by "override", but here's a crazy idea ... ask > upstream to fix the issues. for example, we just reported executable > stacks with the ut2004 game and Ryan of epicgames was so kind as to > fix it up for us. some upstream peeps dont even know about these sort > of things until you point them out. Not to redirect the thread, but can someone point me to stuff on executable stacks (what they are and the background info on the warnings in portage)? If these are anywhere near critical, then I think a lot of us non-x86 arch monkeys have a lot of work on our hands. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
Jason Wever <[EMAIL PROTECTED]> said: > Not to redirect the thread, but can someone point me to stuff on > executable stacks (what they are and the background info on the > warnings in portage)? Not really redirecting the thread since this was another thing I wanted to find out about :) Basically, any of the things that "stricter" may complain about, which are "critical", in the sense that they can not be marked stable under any circumstances? Also, what exactly do they mean? :) > If these are anywhere near critical, then I think a lot of us non-x86 > arch monkeys have a lot of work on our hands. Yea, we need to know what is absolutely critical so we can add this to the ebuild policy if something should not go stable if the problem is present. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpn3AVUNG4Qp.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 07:59:02PM -0700, Jason Wever wrote: > On Wed, 14 Dec 2005 00:25:57 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > no idea what you mean by "override", but here's a crazy idea ... ask > > upstream to fix the issues. for example, we just reported executable > > stacks with the ut2004 game and Ryan of epicgames was so kind as to > > fix it up for us. some upstream peeps dont even know about these sort > > of things until you point them out. > > Not to redirect the thread, but can someone point me to stuff on > executable stacks (what they are and the background info on the > warnings in portage)? my gnu stack docs are actually complete: http://hardened.gentoo.org/gnu-stack.xml > If these are anywhere near critical, then I think a lot of us non-x86 > arch monkeys have a lot of work on our hands. gnu-stack tends to be broken for everyone, not just x86 or !x86 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Last rites for media-video/dvdrip
On Sunday 11 December 2005 09:32 pm, R Hill wrote: > Diego 'Flameeyes' Petten wrote: > > Oh well, media-video/dvdrip has many issues reported in bugzilla (some > > have patches, most haven't), and depends on a version of transcode with > > many issues, too (and force us to leave transcode 1 masked). > > Nobody in video herd is looking at it right now, last bump was done by > > morfic, and more would be needed. > > working on dvdrip is one of the things on my todo list, as soon as i finish > rebuilding my system. > > please reconsider dropping packages just because they don't currently have > a dedicated maintainer. if upstream is alive and people are using it, > leave it alone. especially if it's a popular package with just a handful > of bugs. also, it's a lot more likely you'll find a new maintainer for a > package when it's already in the tree for people to discover and use. > > isn't this what the maintainer-needed alias is for? > > --de. sorry there hasn't happened much yet wrt dvd::rip the system i worked on with dvdrip had a disk die, art of a md0, system is gone, so i too reinstall, some real life worries and usual lack of enough time for everything i started out keeping icewm maintained, and eventually took on other things short version is better i guess: we always appreciate user contributions, if i am slow, it does not represent any lack of interest between you and chandler dvd::rip s hould stay, one concern is that transcode 1 i had on the laptop, on the system dvd::rip worked on has 0.6.14, when i tried dvd::rip on here, it seems to have finished the plugin scan the hangs, scanning plugins was what i did on the XP, then the hdd died :) i too am frightened to see good working apps go, i still consider readding kcpuload which worked then was gone, works still well from an overlay ;) you get the idea i will add your email to the dvd::rip filter in kmail so i hopefully do not miss things wife's surgery is friday, so i don't expect to do much before then Thanks, Daniel Goller pgpzxz08W7VDT.pgp Description: PGP signature
Re: [gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. I am pleased to announce I've just finished porting my system to modular X. My system now does a clean emerge -Dp world with modular X installed and no virtual/x11. Now it would be great if some more of you could do the same with your systems. (Of course, remember to check before committing.) I've seen great effort going into this from other people in the past couple of weeks as well (and earlier!). The main mistake I've seen while going through packages other people have ported is redundant dependencies. For example, libXt RDEPENDs on libSM and libICE so we don't need to also include them. I use an emerge - -ep $foo | grep lib[SIX] to check for possibly redundant dependencies. Keep up the good work! Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn7fgXVaO67S1rtsRApOOAKCr4CHMPUczV9GoFopJGlK1EWjzbACffQ0D kuqlCBSqia3YnPn4KO4bcq4= =SPGl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 03:50:16AM +, Mike Frysinger wrote: > my gnu stack docs are actually complete: > http://hardened.gentoo.org/gnu-stack.xml A question about that: you discourage fixing this with --noexecstack because it's better to be able to submit a patch upstream. What's your take on patches that modify configure scripts or similar files to check for this flag, keeping it out of the ebuild? Is that good, acceptable, or bad, and why? pgpdHOunZ5i9m.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Dec 2005 15:59:03 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: > Basically what I'm looking for here is an easy to understand > explanation of what textrels are, why they are bad, and why they > should hold back marking a package stable. The only information I've > been able to find states that they could cause a performance hit, but > this doesn't seem to warrant banning them completely in my eyes. The seriousness of the textrel issue is different for Hardened Gentoo and normal Gentoo. For Hardened Gentoo they cause real problems and must to be fixed to avoid compromising the overall strategy. For non-hardened Gentoo it's not so serious. I'll focus on non-hardened Gentoo here. Textrels (short for "text relocations") are function or data pointers within the code of a shared library that need to be adjusted to take account of the address at which a shared library is loaded. Shared libraries can be loaded at varying addresses depending on how the loader brings shared libraries into a process' memory image. This can be affected by factors including the size of the main executable, which other shared libraries are loaded for the same process and in which order. When a shared library is loaded, any absolute address references within the code have to be changed to reflect the actual address according to the address at which the shared library is loaded, before that code is executed. Since the loader can't tell what will be executed and when, it has to resolve all such references before the process can be permitted to start execution (this is the performance overhead incurred at load time). It also means that the image of the shared library is specific to that process - other processes can only use the same image if they load the library at the same address which is unlikely under normal circumstances. Thus libraries that are truly shared between applications, consume separate memory for each application that is using them (which is therefore a resource overhead). One workaround for this is to use prelink. This examines your whole system, and marks all shared libraries with hints for their load addresses, which the loader follows if it can. The addresses are chosen to minimise the amount of collisions, If a shared library has no text relocations, it is properly Position Independent Code (PIC). Instead of absolute addresses, the code always uses relative addresses which work no matter at which address the code is loaded. Typically this is achieved via an indirection table (the Global Offset Table) which contains the offsets for each symbol. Thus such code can be mapped without write permissions on the code, and you only ever have one copy of the code in memory, no matter how many applications are using that code. The downside of position-independent code is that it does have a performance impact as currently implemented (i.e. it generates slower code) due to the indirection introduced. This is made worse by the bad use of shared libraries, and the fact that the visibility stuff in the GNU tools is so recent (shockingly) and so libraries have far too much stuff unnecessarily in their global offset tables. Shared libraries (.so's) are used for various things: 1) To share code between multiple applications, the original intention of shared libraries. Best example is libc which if it were to be duplicated for each running application would have a significant impact on memory usage. For such libraries, TEXTRELs are a problem; the seriousness of the problem depends on how many applications use them. 2) To modularise an application; good examples here are X and web-browser plugins. Here, code is loaded if it is used, but not otherwise. Loading all the device drivers into X would be wasteful, for example. This is a secondary use of shared libraries that arises from the way shared libraries are implemented, making them easy to use for this purpose. TEXTRELs here cause a penalty on load, but 3) To break an application up into bits. This is the worst reason to create a shared library, as it gains nothing but loses much. It means a developer abstraction has leaked unnecessarily into the implementation. These simply shouldn't be shared libraries, instead the code should have been linked into the executable. Textrels can be caused by: 1) asm code that isn't PIC 2) incorrect makefiles etc (if a build uses libtool properly, it'll create shared libraries with no textrels) Frequently these are easy to fix, and are simply oversights upstream. There's no reason not to fix these. Occasionally they're a pain to fix, especially non-PIC asm, and if upstream are non-PIC on purpose (usually because they want to extract every last cycle from the processor) we end up having to maintain large patches which amongst other things is risky. > Getting a clear cut policy on exactly what issues should hold a > package back from being marked stable is w
Re: [gentoo-dev] Textrels in packages policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Dec 2005 07:59:23 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: > On Wed, Dec 14, 2005 at 03:50:16AM +, Mike Frysinger wrote: > > my gnu stack docs are actually complete: > > http://hardened.gentoo.org/gnu-stack.xml > > A question about that: you discourage fixing this with --noexecstack > because it's better to be able to submit a patch upstream. What's your > take on patches that modify configure scripts or similar files to > check for this flag, keeping it out of the ebuild? Is that good, > acceptable, or bad, and why? Using '--noexecstack' overrides anything the compiler works out for itself, so applying it indiscriminately is a bad idea. For example, if an application contains asm code with no markings, but also contains code that creates trampolines, it should be marked for executable stack even if the asm code is fixed. Applying '--noexecstack' via LDFLAGS would break such an application. Regarding patches, it's usually much simpler to patch asm source code compared to patching an application's make process. Patching asm source code just means appending a few lines depending on the type of assembler used. As far as ebuilds are concerned, if you add it to LDFLAGS you will need to re-check the application every time you bump the ebuild, and it's difficult to find new occurrences of nested functions for example if you've applied '--noexecstack'. - -- Kevin F. Quinn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn88O9G2S8dekcG0RAsdDAJ9bhfqc44mtQgBsPu5OFjfNGG0GWQCg0eTA vU+j9b8nxMtodf5MSXgkfsE= =nVnR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
