[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh posted [EMAIL PROTECTED], excerpted below, on Sun, 11 Dec 2005 21:19:08 +: Does anyone really use emerge --ask? Oh, /my/ yes! The following should speak for itself. (I have a similar set of ep* commands, those in /usr/local/bin, so I can --pretend as my normal user. Yes, I do have autocompletion setup for them all, too, tho it was basically a matter of ensuring the gentoo autocompletion ran first, then using the same autocomplete functions emerge did, since these are almost all just special cases of the emerge command.) ~#cd /usr/local/sbin /usr/local/sbin#for eascript in ea* ;do echo $eascript;cat $eascript;done ea #!/bin/bash exec emerge -av --oneshot $* ea2 #!/bin/bash exec emerge -av $* eafetch #!/bin/bash exec emerge -avuDf $* eafetchworld #!/bin/bash exec emerge -avuDf world eapaK #!/bin/bash exec emerge -avk --oneshot $* eapaK2 #!/bin/bash exec emerge -avk $* eapak #!/bin/bash exec emerge -avK --oneshot $* eapak2 #!/bin/bash exec emerge -avK $* easync #!/bin/bash emerge sync eupdatedb emerge -avuDf world eatree #!/bin/bash exec emerge -avuDt --oneshot $* eatree2 #!/bin/bash exec emerge -avuDt $* eatreeworld #!/bin/bash exec emerge -avuDt world eaworld #!/bin/bash exec emerge -avuD world -- 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] 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've finished roughly half today -- I'm 13,400 lines into the 26,300 lines of my original emerge -Dpd world output. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDnUF3XVaO67S1rtsRAmFtAJ9vJkj0qZWdW9Smjjri1uDyY3dhdACgjS9t dI3wQT6FYNXWG9uBAR0LSFE= =9JGB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs posted [EMAIL PROTECTED], excerpted below, on Mon, 12 Dec 2005 09:11:53 +0900: On Monday 12 December 2005 09:01, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Repositories will be user-labelled. However, all that readers need be | concerned with is how to extract the repository name from the | news.unread file and how to then resolve that to a directory name, | regardless of how repositories are implemented. See, this is exactly why I'm not wanting to care about multiple repo details at this point. There's no specification of how they work and what exactly they're supposed to do, and to make matters worse the way you seem to think they'll be handled is a really really bad way of doing it. Regardless of what you think about the current plans for multiple repository support, the details that readers will need to know wont change. Ciaran hasn't stated, but it appears to me if I'm reading correctly between the lines, the reason he doesn't want to mess with specifying multiple repo details right now is that it's getting the cart before the horse in terms of nailing down certain areas of the multiple repo spec. For example, if repository-id forms a part of the path and we define path parsing now, then we are effectively defining legal characters for repository-id now. That's an entirely different glep, far out of scope and reaching into other people's territory, limiting how that might be implemented by defining a portion of the id-scope in an entirely unrelated glep. Given how heated I've seen GLEP discussion get (and I'm not saying that's /bad/, just a fact), I really can't blame Ciaran for attempting to keep the scope of the proposal, and therefore the debate, down to exactly what he's aiming to accomplish, without ending up getting into an entirely /different/ debate about how he's limiting the future flexibility of the multiple repo implementation. Once there's a concrete proposal there to work with, then and only then, he's saying (from my viewpoint), is it appropriate for consideration in relation to the news proposal. Don't unnecessarily tie the two together, complicating life for both. Let each be argued on its merits separately, and when/if multiple repo is actually close enough to deployment that there's some actual rules to work with, /then/ worry about fixing this to match. If I'm incorrect, just tell me to go back in my corner and lurk some more g, but that's what I'm getting out of this subthread so far. -- 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
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13568 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 529 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
Of course, all of these points would have made it into the GLEP *if* it had been posted with plenty of time for people to comment on it instead of one day. harping on this old point solves nothing. we've already established quite clearly that this will not happen again in the future. Technically, no. It does, however, point out that the council basically screwed infra up the rear without using lube, and then told infra, we don't care, we won't discuss changing it, and we would approve it again! -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:20, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Regardless of what you think about the current plans for multiple | repository support, the details that readers will need to know wont | change. Incorrect. Right now, readers should ignore news-blah.unread and only pay attention to news.unread. Readers will have to be updated to deal with multiple repositories whenever the multiple repositories GLEP is approved. Incorrect. There needs to be no GLEP regarding multiple repository support in portage. There may need to be a GLEP regarding splitting up the portage tree into separate repositories, but that is nothing to do with the issue I'm talking about. | | Even before multiple respositories are properly supported, I | | guarantee bugs about support for this in portage overlays. With | | the above, we would be able to add that support. Without it, all | | we can do is put a big CANTFIX. | | Overlay is not the same as multiple repository support. | | There's no difference as far as readers go. Sure there is. there's no metadata/ directory in overlays. Again, why I really don't like this design. You're asking portage to do crap to support external tools without looking to provide compatibilty with future portages. How are you planning to find the metadata directory in the first place? | Nope, which is why news.read shouldn't be specified. news.read is specified because there was demand for it the last time around. It's staying specified because the reasons given were based upon convincing use cases rather than random speculation. Can you show a use case that crosses several readers? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Mon, 12 Dec 2005 15:06:04 + Mike Frysinger [EMAIL PROTECTED] wrote: | it's really more up to the GLEP author(s) and infra to find the middle | ground as to what's feasible. if none can be found, then yes, i would | whip out my virtual wang and take it to infra again with the subdomain | idea (i would however offer lube; more for myself though). You're assuming that the GLEP authors are competent and willing to listen to feedback. When this isn't the case, it's the council's job to stand there and say go away and don't come back until you do this properly. -- 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) updates
On Mon, 12 Dec 2005 23:29:00 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Incorrect. There needs to be no GLEP regarding multiple repository | support in portage. There may need to be a GLEP regarding splitting | up the portage tree into separate repositories, but that is nothing | to do with the issue I'm talking about. Sure. You could go ahead and implement it without a GLEP in the really really bad way you're proposing currently. Or you could take the GLEP route and let other developers help you come up with a design that doesn't royally suck. | Again, why I really don't like this design. You're asking portage to | do crap to support external tools without looking to provide | compatibilty with future portages. How are you planning to find the | metadata directory in the first place? Not at all. There's an it will probably be handled like this note in the GLEP. I can't get any more detailed than that until there's a proper specification for what Portage is going to do in the future. | | Nope, which is why news.read shouldn't be specified. | | news.read is specified because there was demand for it the last time | around. It's staying specified because the reasons given were based | upon convincing use cases rather than random speculation. | | Can you show a use case that crosses several readers? Look back to the original thread. -- 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: GLEP 42 (Critical news reporting) updates
On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. | 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. | 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. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. -- 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] Heads up - Savannah CVS changes
For your information, the anonymous CVS setup for savannah has changed from using SSH to using pserver: http://savannah.gnu.org/forum/forum.php?forum_id=4168 This affects the following ebuilds in portage, for which I have opened a bug: https://bugs.gentoo.org/115327 sci-mathematics/axiom- app-emacs/emms-cvs-0 app-i18n/scim-cvs-1.1.0 gnustep-base/gnustep-back-art-0.9.5_pre20050312 gnustep-base/gnustep-base-1.10.2_pre20050312 gnustep-base/gnustep-make-1.10.1_pre20050312-r1 gnustep-base/gnustep-back-xlib-0.9.5_pre20050312 gnustep-base/gnustep-gui-0.9.5_pre20050312-r1 gnustep-apps/projectcenter-0.4.3_pre20050312 gnustep-apps/terminal-0.9.5_pre20050110 gnustep-apps/terminal-0.9.5_pre20050315 gnustep-apps/preferences-1.3.0_pre20050315 gnustep-apps/preferences-1.3.0_pre20050110 gnustep-apps/textedit-0.95_pre20050315 gnustep-apps/textedit-0.95_pre20050110 gnustep-apps/stshell-0.8.3_pre20050312 gnustep-apps/stshell-0.8.3_pre20050106 gnustep-apps/easydiff-0.3.1_pre20050312 gnustep-apps/easydiff-0.3.1_pre20050106 gnustep-apps/easydiff-0.3.1_pre20041203 gnustep-libs/gdl2-0.9.2_pre20050106 gnustep-libs/gdl2-0.9.2_pre20050312 gnustep-libs/gsweb-1.1.1_pre20050312 gnustep-libs/renaissance-0.8.1_pre20041203 gnustep-libs/renaissance-0.8.1_pre20050312 gnustep-libs/prefsmodule-1.1.1_pre20050315 gnustep-libs/prefsmodule-1.1.1_pre20050110 gnustep-libs/smbkit-0.0.1_pre20050106 gnustep-libs/steptalk-0.8.3_pre20050312 gnustep-libs/steptalk-0.8.3_pre20050106 sys-cluster/gomd-cvs-0.2_beta1 dev-lisp/cl-ansi-tests-cvs-0 dev-lisp/gcl-cvs-2.7.0 app-editors/nano-1.3.9 app-editors/emacs-cvs-22.0.50 app-editors/emacs-cvs-23.0.0 Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp4bRB8VoKxy.pgp Description: PGP signature
Re: [gentoo-dev] Creating a Sketeton System
On 12/12/05, Andrew Muraco [EMAIL PROTECTED] wrote: George Prowse wrote: After some talk in the forums a point came up that we need a way to reduce the long used gentoo system to a bare point before X but after any baselayout upgrade had been applied. Isn't that what the stages are, Barebone systems?yes but if you extracted a stage on to an already built system you would not only have the the mess there that you wanted to get rid of but also all your config files would revert back to older versions and you'd lose any changes made. This script would enable two things: a person to rebuild his system after a library malfunction and also if a person wanted to switch from 100% gtk to 100% qt or vice-versa. At present we have depclean to reduce anything past xorg-x11 but that doesn't get as far as anything that doesn't rely on a package being able to depend on an GUI, libraries need to be brought in and all but baselayout needs to be cleaned out so a bare bone is left.Why not just move world out of the way and then emerge what you want tokeep/install then emerge depclean the rest (although this could easily fubar a system if they do it blindly removing important system packages)because i'd rather not use depclean but also depclean doesn't get rid of the configs left by any packages, for instance: if i had xfce on my system before and i did emerge -C xorg-x11 emerge depclean xfce would be wiped off but if i emerged xfce again there would still be modified parts that would use the options i selected on the previous version. George
Re: [gentoo-dev] Creating a Sketeton System
George Prowse wrote: yes but if you extracted a stage on to an already built system you would not only have the the mess there that you wanted to get rid of but also all your config files would revert back to older versions and you'd lose any changes made. ... because i'd rather not use depclean but also depclean doesn't get rid of the configs left by any packages, for instance: if i had xfce on my system before and i did emerge -C xorg-x11 emerge depclean xfce would be wiped off but if i emerged xfce again there would still be modified parts that would use the options i selected on the previous version. It really sounds like you're contradicting yourself here. You don't want your config files overwritten, but you don't want your config files used when you remerge the packages? Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: Repositories will be user-labelled. However, all that readers need be concerned with is how to extract the repository name from the news.unread file and how to then resolve that to a directory name, regardless of how repositories are implemented. Expanding on this a little further then, we would have a file in a standard location such as /var/lib/portage-news/repos.desc that maps repository identifiers to the absolute paths of news directories (no hard coding of metadata/news/). This will provide a layer of indirection so that the portage news add-on will be able to direct news readers to the proper locations, regardless of repository implementation details. Even before multiple respositories are properly supported, I guarantee bugs about support for this in portage overlays. With the above, we would be able to add that support. Without it, all we can do is put a big CANTFIX. [...] the data should probably not be in /var/lib/portage I would also prefer that /var/lib/portage/ be reserved for core portage functionality (package management) and that non-essential add-ons store their data elsewhere. Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] bugs.g.o slowness
To all, I know bugs.g.o is slow for some of you. I am working on it as expeditiously as I can. We are having a problem with tables locking for some reason. I have set myself up in #gentoo-bgo on irc.gentoo.org if you wish to help debug in the effort. I apologize about the inconvenience. -Jeffrey -- --- Jeffrey Forman Gentoo Infrastructure Gentoo Release Engineering Bugs.Gentoo.org Administrator [EMAIL PROTECTED] --- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] bugs.g.o slowness
On Mon, 2005-12-12 at 18:19 -0500, Jeffrey Forman wrote: To all, I know bugs.g.o is slow for some of you. I am working on it as expeditiously as I can. We are having a problem with tables locking for some reason. I have set myself up in #gentoo-bgo on irc.gentoo.org if you wish to help debug in the effort. I apologize about the inconvenience. -Jeffrey Problems solved. It looks like a query I ran on the database behind bugs.gentoo.org from the MySQL command line took a bit longer than usual. After killing the process, it got hung on the backend and took bugs with it. I apologize for my mishap. Goes to show that testing on live hardware is not the way to go ;) I want to thank Mike Marineau from the OSL [1] for looking into the database and killing my query. He saved the day. Please direct all donations, well wishes and other expensive gifts to him. -Jeffrey [1] http://www.osuosl.org -- --- Jeffrey Forman Gentoo Infrastructure Gentoo Release Engineering Bugs.Gentoo.org Administrator [EMAIL PROTECTED] --- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. Blah, blah, blah. | 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. | 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. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. Without a list of future features, you think the best way to go must be the least agile? As Zac said, all that matters to keep full compatibility on the side of the readers is to add a level of indirection. All your reasoning above falls apart in the face of that simple *logical* request. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP XX: Fix the GLEP process
Abstract 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. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. 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. 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. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. -- 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: Fix the GLEP process
On Tuesday 13 December 2005 11:06, Jason Stubbs wrote: Abstract 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. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. 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. A GLEP should list whom has been solicited and provide evidence that each has given their explicit approval of the GLEP. A GLEP without explicit approval of all teams involved cannot receive managerial approval. 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. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. So what are you going to do? I asked already but you didn't answer. How are you going to find $PORTDIR/metadata/news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
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. -- 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: Fix the GLEP process
On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. 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? -- 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] Re: GLEP XX: Fix the GLEP process
If everyone but infra was in favor of glep 41, are you saying it should be approved? /devils advocate On 12/12/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. 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? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
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. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:24, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. 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. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP XX: Fix the GLEP process
On Mon, 12 Dec 2005 21:35:40 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | If everyone but infra was in favor of glep 41, are you saying it | should be approved? Nope. I'm questioning the use of the word involved. 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... -- 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: GLEP 42 (Critical news reporting) updates
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. -- Jason Stubbs Your Point is Moot because an overlay (at present) is going to be exprimental software, (unsupported offically anyways) and so you _should_ know what risks your taking, this GLEP is to warn you about supported updates/changes which you _need_ to know about. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
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... -- 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: GLEP 42 (Critical news reporting) updates
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 and don't get synced, so they don't contain news items. Supporting news from multiple sources is something that's tied to supporting packages from multiple sources, which overlay doesn't permit. Fixing that would require fixing portage to support multiple repositories rather than using overlay, which is an issue for a different GLEP. You can use gensync (included with gentoolkit). $ gensync --help Usage: gensync options repo-id-1 repo-id-2 ... where options is one of -a, --all-sources - sync all know sources -l, --list-sources - list known rsync sources -C, --no-color - turn off colours -h, --help - this help screen -V, --version - display version info Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 42 (Critical News Reporting) round five
Ok, new draft. Changes are as follows: * mysql-4.1, not -5. * Added einfo, ewarn to the list of methods currently used * Added + and : to the allowed news item IDs, to match package name policy (Kugelfang thought we might need, say, a libstdc++ news item at some point) * Changed /var/lib/portage to /var/lib/gentoo * The news file is now named 'news-magic-chicken.*'. News clients are to use a wildcard rather than hardcoding magic-chicken. * Added emerge --ask thingie * news.read is now mandatory for interactive clients, and ignored for gateway clients Read the whole thing before commenting please. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm GLEP: 42 Title: Critical News Reporting Version: $Revision: $ Author: Ciaran McCreesh [EMAIL PROTECTED] Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005 Abstract This GLEP proposes a new way of informing users about important updates and news regarding tree-related items. Motivation == Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention during the upgrade process. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst`` A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Requirements An adequate solution must meet all of the following requirements: Preemptive Users should be told of changes *before* they break a system, not after the damage has already been done. Ideally, the system administrator would be given ample warning to plan difficult upgrades and changes, rather than only being told just before action is necessary. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be able to read news items. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal and some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers or those whose English language skills are below par. Simple for developers Posting news items should be as simple as is reasonably possible. Simple for users Reading relevant news items should be as simple as is reasonably possible. Compatibility with existing and future news sources A news system would ideally be able to be integrated with existing news sources (for example, Forums, GWN,
Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Internationalisable |Being able to provide messages in multiple languages may be | beneficial. | | Not quite sure, is it required for GLEP's to be in american English or | is UK English fine? | | Pointing at Internationalizable The standard for Gentoo documentation is to use whichever variant the original author prefers. -- 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] Re: GLEP 42 (Critical News Reporting) round five
Alrighty then, good enough for me :) One other thing .. Note:: A previous draft of this GLEP allowed news items to be sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation may arise where this will be necessary (for example, a security update which must break backwards compatibility and which cannot be revealed to the public before a given date). The seems like a half complete thought, I realize you want to discourage it from happening, but maybe change it to read It is possible that a situation and in only this case may it be sent to -core instead On 12/12/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Internationalisable |Being able to provide messages in multiple languages may be | beneficial. | | Not quite sure, is it required for GLEP's to be in american English or | is UK English fine? | | Pointing at Internationalizable The standard for Gentoo documentation is to use whichever variant the original author prefers. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh wrote: Ok, new draft. Changes are as follows: I Think That You've tweaked this GLEP to death ;-) Anyways, I can't wait until everybody is happy with it and it gets moving, because I know that gcc 4 and qt4 and glibc 2.3.6 are right around the corner, and those would be great chances to use this new news dohicker and see how it goes. Thanks for the continuous hard work on this, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
On Mon, 12 Dec 2005 23:25:29 -0500 Andrew Muraco [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | Ok, new draft. Changes are as follows: | | I Think That You've tweaked this GLEP to death ;-) Sadly not. It still needs work. It's going to take at least a couple more drafts before I'd be happy sticking it up for voting... Complex changes need thorough planning. Otherwise we just end up wasting lots of time implementing something that doesn't work, and then lots more time trying to fix bugs in something that's broken by design, and then even more time supporting the legacy brokenness whenever it finally is done properly. I'd much rather throw away a design than throw away code. -- 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
