Re: [gentoo-dev] Themes for Webapplication
I am writing an ebuild for pmwiki. Its not in the portage tree yet. I think I will put the themes in /usr/share/pmwiki/Skins Hope that is OK. Stuart Herbert wrote: Hi, On Fri, 2005-11-04 at 07:41 +0100, Rene Zbinden wrote: I am writing an eubild for an webapplication (wiki) and there are a lot of themes available. I write an ebuild for these themes. Now my question is where do I install these themes so that webapp-config handles them correctly. We need a little more information to help answer that question. Which wiki are you writing an ebuild for? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: Motivation == There are currently several ways of getting news out to our users, none of them particularly effective: This assumes the following ways are really ineffective, something which you don't prove or give any reason for. Hence it's eligable for another big discussion. To avoid that, I would suggest to add a number of reasons, or whatever to make this assumption sound (more) valid. It is important, I think, that the reader can understand your grounds for saying this. (I personally disagree on this statement now, but it makes no use discussing it since you haven't given any ground as on why. Maybe if you would give a definition, I could adjust my own definition and agree.) A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. Perhaps you want to add a small footnote here, to give a small example of such debacle, and using that example point out what is the problem you think is important, and hence will address in this paper... eh GLEP. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. This is a minor side issue, but I think that GLEP 2 states that you should use ' instead of `. No discussion on it please, I might be wrong or you just didn't know. Preemptive Users should be told of changes *before* they break the user's system, after the damage has already been done. style suggestion for unambigous interpretation: perhaps a because if applied afterwards instead of after No user subscription required It has already been demonstrated [#forums-whining]_ 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. You implicitly state that many users do not read the gentoo-announce list and RSS-feeds because they are subscription based. This sounds like a too quick assumption to me. At least it is not founded in any way. Consider that for RSS-feeds one typically doesn't have to subscribe, but just add it to his/her reader. Make clear why you think the subscription model stops users from reading, and why a push-based alternative (as you suggest here) will work. Remember that it is easy to say here that users don't read what's on their consoles as well, as in post emerge messages etc. So make sure you deal with it upfront, why you think now it *will* work. No user monitoring required It has already been demonstrated [#forums-whining]_ 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. Apart from that this point seems to repeat much of the previous one, it introduces a new unfounded claim (users do read, but now too late) which somehow contradicts previous statements. Beware that you clearly deal with this, or just introduce it earlier so it doesn't look you're contradicting yourself. 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. Direct question that follows from this: what *do* we expect a user/system to have available? I think it's good to state that as well, since you're excluding a lot here in once sentence. 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository. From here, it is merged with the rsync tree. This is described in `News Item Distribution`_. 4. The news item is merged with the rsync tree. Implementation details of this point are beyond the scope of this GLEP; existing solutions are in place for merging GLSAs to the tree. Where does point 4 differ from the second part of point 3? Also, point 3 implies that the merging into the rsync tree is being described further on, while point 4 states the oposite of not discussing it (out of scope). Maybe split point 3 and merge with 4? 5. Users fetch the news item when they sync. This ensures that the news items in question are pushed to the user before the user accidentally makes an unwanted change. No changes to the existing rsync process are required by this GLEP. I would suggest a reference to a place where you will explain this 'pushing' to the user in detail. Especially the time and the way how are important. Or maybe I was just confused by pushed and is the only thing this point wants to say that all news items are just synced together with the rest of the portage tree upon a emerge --sync. The latter sounds logical considering the last sentence quoted above. 6. Portage filters the news item and, if it is relevant, installs it in a special location to be read by a news item reader. Messages are also displayed to
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, Nov 05, 2005 at 11:28:33AM +0100, Grobian wrote: Ciaran McCreesh wrote: Motivation == There are currently several ways of getting news out to our users, none of them particularly effective: This assumes the following ways are really ineffective, something which you don't prove or give any reason for. Hence it's eligable for another big discussion. To avoid that, I would suggest to add a number of reasons, or whatever to make this assumption sound (more) valid. It is important, I think, that the reader can understand your grounds for saying this. (I personally disagree on this statement now, but it makes no use discussing it since you haven't given any ground as on why. Maybe if you would give a definition, I could adjust my own definition and agree.) You must not have read the [#forums-whining]_ reference as that makes it quite clear that existing methods isn't adequate. Even if you think the apache maintainers made lots of mistakes you can't really fault us for not trying to get the news of config changes out to all users. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Jan Kundrát wrote: On Saturday 05 of November 2005 11:28 Grobian wrote: Remember that it is easy to say here that users don't read what's on their consoles as well, as in post emerge messages etc. So make sure you deal with it upfront, why you think now it *will* work. Emerge messages are usually hidden by compilation output, so this argument doesn't apply here, IMHO. Or am I missing your point here? You give an example here of why console messages aren't read. But if that is your rationale here, I would like to see it stated in the GLEP why it *will* work there. On the previous discussion there was an example of a console message not being read fully/properly. This will happen to more people. What I was asking for is that such situation is either outlawed (ie. People should just read, if they don't then it's not my problem) or recognised (ie. It is known that people do not read, hence we propose to use a text-to-speech module and play the produced audio file, so the user can listen to the imporant message -- idiotic example of course). Just to make things clear and properly defined. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
[EMAIL PROTECTED] wrote: You must not have read the [#forums-whining]_ reference as that makes it quite clear that existing methods isn't adequate. Even if you think the apache maintainers made lots of mistakes you can't really fault us for not trying to get the news of config changes out to all users. I haven't, that's correct. However, a reference should be a source for additional information. A small exerpt or recap of that thread is not in the GLEP. Also, [#forums-whining]_ was not referenced in the quoted part, the reference only follows later on. Going into answering your question, the thread suggests for instance an RSS-feed with this info. Also the GLEP mentions 5 distinct sources, of which I personally think at least two will be effective for a certain group of people. That last thing was what I was aiming at. For some it might work quite well if the apache2 upgrade stuff (as sent out on gentoo-dev) was communicated through gentoo-announce. Hence my doubts on whether [they are not] particularly effective is a general statement that applies to any situation. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 2005-11-05 at 00:58 +, Ciaran McCreesh wrote: Feedback from people who have something useful to say would be very much welcomed, assuming of course that they've read the GLEP. It is written in the GLEP (Requirements): No user monitoring required It has already been demonstrated [#forums-whining]_ 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. And later in Specification-Overview: 5. Users fetch the news item when they sync. This ensures that the news items in question are pushed to the user before the user accidentally makes an unwanted change. No changes to the existing rsync process are required by this GLEP. My concerns are twofold: The first is the method of delivery: Through 'emerge sync', which requires that users run this on a regular basis to receive relevant news. Further, this process can take a very long time and transfers a relatively large amount of data along with the news. My second concern is the frequency that users sync. A stated concern is getting news to users before it is too late. Is there any way to gauge the number of unique users which sync on a regular basis? When is too late? Is there an acceptable window for delivering news? It is not uncommon for me to refrain from running emerge sync (or even cvs up on the entire gentoo-x86 tree) for weeks or months on machines I wish to keep somewhat static. -- Regards, Lisa Seelye GPG: 09CF5 2D6B8 2B72B 997A7 601BC B46B5 561E4 96FC5 http://www.thedoh.com/~lisa/site signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Additional issue/question... On Sat, Nov 05, 2005 at 12:58:14AM +, Ciaran McCreesh wrote: 6. Portage filters the news item and, if it is relevant, installs it in a special location to be read by a news item reader. Messages are also displayed to inform the user that news is available. 7. The news item is handled by the user's choice of news item reader. See `News Item Clients`_. snip Client Side ''' Notification that new relevant news items will be displayed via the ``emerge`` tool in a similar way to the existing configuration files need updating messages: :: * Important: 3 config files in /etc need updating. * Type emerge --help config to learn how to update config files. * Important: there are 5 unread news items. * Type emerge --help news to learn how to read news files. The unread news message will also be displayed immediately after an ``emerge sync``. Your example readers delete from the news directory, yet I'd expect that's not going to be desirable for all setups- nor is leaving the news item in the news directory, and having it flagged every sync by emerge as unread. Might want to consider some way to mark an item as read without waxing it from the directory, if against it, clarify in the glep why. ~harring pgpKWldQPcsrp.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, Nov 05, 2005 at 12:29:28PM +0100, Grobian wrote: [EMAIL PROTECTED] wrote: You must not have read the [#forums-whining]_ reference as that makes it quite clear that existing methods isn't adequate. Even if you think the apache maintainers made lots of mistakes you can't really fault us for not trying to get the news of config changes out to all users. I haven't, that's correct. However, a reference should be a source for additional information. A small exerpt or recap of that thread is not in the GLEP. Also, [#forums-whining]_ was not referenced in the quoted part, the reference only follows later on. Going into answering your question, the thread suggests for instance an RSS-feed with this info. Also the GLEP mentions 5 distinct sources, of which I personally think at least two will be effective for a certain group of people. That last thing was what I was aiming at. For some it might work quite well if the apache2 upgrade stuff (as sent out on gentoo-dev) was communicated through gentoo-announce. Hence my doubts on whether [they are not] particularly effective is a general statement that applies to any situation. If we were only aiming at a certain group of people there would be no need to change anything. The apache announcements reached lots of users but still left a large chunk of users in the dark. Moving the news to -announce or some RSS feed wouldn't change anything as the basic problem with these methods is that people have to actively search out important news instead of news getting pushed to them. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Saturday 05 of November 2005 12:34 Lisa Seelye wrote: The first is the method of delivery: Through 'emerge sync', which requires that users run this on a regular basis to receive relevant news. Further, this process can take a very long time and transfers a relatively large amount of data along with the news. My second concern is the frequency that users sync. A stated concern is getting news to users before it is too late. Is there any way to gauge the number of unique users which sync on a regular basis? When is too late? Is there an acceptable window for delivering news? It is not uncommon for me to refrain from running emerge sync (or even cvs up on the entire gentoo-x86 tree) for weeks or months on machines I wish to keep somewhat static. How can users who don't run `emerge --sync` or any other syncing methods perform possibly dangerous upgrades of packages? Cheers, -jkt -- cd /local/pub more beer /dev/mouth pgplWNR3MV0al.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Saturday 05 November 2005 06:08, Jason Stubbs wrote: Why does `emerge --changelog` not suffice for package-specific news? From a user/sys.admin point of view let me give you an example; I maintain quite a lot Gentoo-systems. For me it's impossible to read _every_ changelog for minor release changes. For example not so long ago Apache was upgraded from 2.0.54-r15 to 2.0.54-r31. For me as a user/sys.admin based on versionnumbers this is a minor change. However the changes were rather extensive (e.g. reorganization of conf.files). When these changes occur I want to be informed _before_ I start emerge and I think that this information should be _pushed_ to users/sys.admins instead of _pulled_ from external sources (forums, website, mailinglist, etc. or changelogs). If changelogs could be extended with a priority flag and emerge would notify me when a high priority changelog is applicable to my system then this would be just fine for me. Basically all I want is; Notification that new relevant news items will be displayed via the ``emerge`` tool in a similar way to the existing configuration files need updating messages: :: * Important: 3 config files in /etc need updating. * Type emerge --help config to learn how to update config files. * Important: there are 2 security advisories released for installed packages. * Type emerge --security to see the details. * Important: there are 5 unread news items. * Type emerge --help news to learn how to read news files. If this is possible by extending the changelog I'm a happy users/sys.admin. I don't care if I need to type emerge --news or emerge --changelog as long the information is pushed. Disclaimer; I'm not 100% sure that the versionnumbers from Apache mentioned above are exact the real world examples, but you get the idea. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
[EMAIL PROTECTED] wrote: If we were only aiming at a certain group of people there would be no need to change anything. The apache announcements reached lots of users but still left a large chunk of users in the dark. Moving the news to -announce or some RSS feed wouldn't change anything as the basic problem with these methods is that people have to actively search out important news instead of news getting pushed to them. I disagree. A lot Gentoo users I know read gentoo-announce and the GWN. For me it works quite well if I see a message with a warning on something. I can quickly find it back if I am in need for it. I would typically disable the whole news feature of portage and just watch the announce ML with all the news announcements. Works fine for me. The GLEP *is* targetted at a certain group of people, since it is there mainly to help those that complained in [forum_whining] and those -- I think -- mostly desktop end-users to prevent them from breaking their system and complain with us. I broke my webserver too after the apache update. Too bad I was stupid enough to 'just do it' on a webserver that should *not* have been offline for a while. I just ignored the message the init.d script gave when it refused to stop my apache. To cut a long story shory, I have solved the problem myself, knowing I was stupid for ignoring the message on gentoo-dev. I never blamed the apache herd or anyone else but myself and just fixed it myself. Sys-admins are supposed to try updates on a toy box first. A warning is nice, documentation on how to solve it the best is even nicer. Think of knowledge books of many commercial systems. What the GLEP does is twofold: 1. Suggest special (**important**) news items to be accepted within Gentoo, and them being stored somewhere 2. Desparately push this news to users, because it seems that they don't read information which is not available (yet! see 1). So thank you for letting me realise that this GLEP should be splitted in two. One for just realising and standardising a way to publish news items on normal and known media: mailing lists, RSS feeds and WWW pages. It should include topics regarding what information (like solutions or workarounds) should be there. Then an additional GLEP which suggests the pushing of information to the user -- like this current GLEP -- can be written when it becomes clear after a reasonable amount of time after realising the GLEP mentioned above doesn't work sufficiently. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. Examples of the recent upgrade debacles aren't needed, but you should at least state some of the outcomes that occurred, whether it be unscheduled downtime, data corruption or whatever. Preemptive Users should be told of changes *before* they break the user's system, after the damage has already been done. s/after/when/ perhaps? This sentence takes a couple of reads... No user subscription required It has already been demonstrated [#forums-whining]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. Could you use complaints instead of whining or whatever will represent what the users are doing from an unbiased point of view please? Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers, those whose English language skills are below par or morons. morons is not needed either. The following headers are used for filtering. If none of these headers are specified, the news item is displayed for all users. Otherwise, the news item is displayed if *at least one* header matches. It would seem more useful if the headers were sorted into the three classes first. A news item would then only be displayed if a header from the class matches or the class is empty. This would allow for rules such as net-www/apache is installed and the keyword is either mips or sparc. ``Display-If-Installed:`` A dependency atom or simple package name (for example, ``dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the package specified installed, the news item should be displayed. ``Display-If-Keyword:`` A keyword [#glep-22]_ name, for example ``mips``. If the user is on the arch in question, the news item should be displayed. ``Display-If-Profile:`` A profile path, for example ``default-linux/sparc/sparc64/server``. If the user is using the exact profile in question, the news item should be displayed. This header may be used to replace ``deprecated`` files in the future. Isn't keyword just a generalization of profile? Why have both? Thus, all proposed news items must be posted to the ``gentoo-dev`` or ``gentoo-core`` mailing list, and ``Cc:``\ed to [EMAIL PROTECTED] at least 72 hours before being committed (exceptions may be made in exceptional circumstances). Any complaints regarding wording or clarity **must** be addressed before the news item goes live. Why gentoo-core? It's a news item; it's purpose is to be made public. Client Side ''' Whenever relevant unread news items are found, ``emerge`` will copy or symlink the news file into ``/var/lib/gentoo/news/``. Notification that new relevant news items will be displayed via the ``emerge`` tool in a similar way to the existing configuration files need updating messages: :: * Important: 3 config files in /etc need updating. * Type emerge --help config to learn how to update config files. * Important: there are 5 unread news items. * Type emerge --help news to learn how to read news files. The unread news message will also be displayed immediately after an ``emerge sync``. Portage may also warn of unread news items using, for example, a red flashy before actions such as merging a package. Portage must keep track of news items which have already been installed to avoid repeatedly reinstalling a deleted news item. Why put this in portage at all? Post sync hooks will likely be available in 2.0.54. If adding hooks were as easy as adding a file to a portage config directory, would adding the package that does the above to the system package set be enough to force this new information dispersal method on users? Once a news item is 'installed', third party tools (or a traditional Unix pager and ``rm``) can be used to display and view the news files. An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display tool; other display tools (for example, a news to email forwarder, which would be ideal for users who sync on a cron) are left as options for those who desire them -- the simple file format make this relatively simple. This is just more reasoning that nothing should be added to portage at all... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, Nov 05, 2005 at 01:58:00PM +0100, Grobian wrote: [EMAIL PROTECTED] wrote: snip I disagree. A lot Gentoo users I know read gentoo-announce and the GWN. For me it works quite well if I see a message with a warning on something. I can quickly find it back if I am in need for it. I would typically disable the whole news feature of portage and just watch the announce ML with all the news announcements. Works fine for me. The GLEP *is* targetted at a certain group of people, since it is there mainly to help those that complained in [forum_whining] and those -- I think -- mostly desktop end-users to prevent them from breaking their system and complain with us. I broke my webserver too after the apache update. Too bad I was stupid enough to 'just do it' on a webserver that should *not* have been offline for a while. I just ignored the message the init.d script gave when it refused to stop my apache. To cut a long story shory, I have solved the problem myself, knowing I was stupid for ignoring the message on gentoo-dev. I never blamed the apache herd or anyone else but myself and just fixed it myself. Sys-admins are supposed to try updates on a toy box first. A warning is nice, documentation on how to solve it the best is even nicer. Think of knowledge books of many commercial systems. snip Even if you don't realise that this will be a big help for many users or you just don't think those users deserver any help (not sure which one it is tbh) - you might at least consider the fact that only having to push news about major / critical changes in one place is going to make things a lot easier for devs. Frankly, I don't see any reason not to follow through with this GLEP as it's going to be very useful for many people and the current system has shown itself to be inadequate lots of times already. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote: ``Display-If-Installed:`` ?? ?? A dependency atom or simple package name (for example, ?? ?? ``dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the ?? ?? package specified installed, the news item should be displayed. ``Display-If-Keyword:`` ?? ?? A keyword [#glep-22]_ name, for example ``mips``. If the user is on the ?? ?? arch in question, the news item should be displayed. ``Display-If-Profile:`` ?? ?? A profile path, for example ``default-linux/sparc/sparc64/server``. If ?? ?? the user is using the exact profile in question, the news item should be ?? ?? displayed. This header may be used to replace ``deprecated`` files in ?? ?? the future. Isn't keyword just a generalization of profile? Why have both? You would have to specify a common subprofile, and have the code know to dig through the ancestors of a profile. Breaks down when dealing with profiles that lack a common base (conversion from flat profiles to cascaded for example). ~harring pgp7ES8WE2LRE.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Saturday 05 November 2005 22:24, Brian Harring wrote: On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote: ``Display-If-Installed:``   A dependency atom or simple package name (for example,   ``dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the   package specified installed, the news item should be displayed. ``Display-If-Keyword:``   A keyword [#glep-22]_ name, for example ``mips``. If the user is on the   arch in question, the news item should be displayed. ``Display-If-Profile:``   A profile path, for example ``default-linux/sparc/sparc64/server``. If   the user is using the exact profile in question, the news item should be   displayed. This header may be used to replace ``deprecated`` files in   the future. Where'd those funny As come from? Isn't keyword just a generalization of profile? Why have both? You would have to specify a common subprofile, and have the code know to dig through the ancestors of a profile. If a user is using the exact profile in question... Common subprofiles seem to be irrelevant. I was going to bring up that point as well, but then I recalled that some utilized profiles have children also (such as amd64/2005.1 and amd64/2005.1/no-multilib). If subprofiles were also picked up, there would be no way to specify a news item that only pertained to multilib amd64 systems. Breaks down when dealing with profiles that lack a common base (conversion from flat profiles to cascaded for example). My understanding is that each class of header can appear multiple times. As far as I can tell Display-If-Keyword would just prevent having to specify Display-If-Profile for each profile of the keyword specified. I'd just like to clarify that it has no purpose beyond that. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Bryan ��� wrote: Even if you don't realise that this will be a big help for many users or you just don't think those users deserver any help (not sure which one it is tbh) - you might at least consider the fact that only having to push news about major / critical changes in one place is going to make things a lot easier for devs. Any help that you can give is great. I am not against the ideas in this GLEP. It's are good ideas. However, you cannot push something that is not there, and you cannot say you *have* to push it because other ways don't work -- ways which aren't yet explored. News items as described have never been published before, IMHO, and hence the effect of un-filtered, un-personalised publishing of these news items is *not* known. I would priorise on getting them published somehow, and in the meanwhile continue on this GLEP from another perspective: personalising news messages based on the user's portage. Such GLEP can elaborate much more on support for mailing automatically to root or another user, pushing forcibly on the screen or reading via 'news-update', just to suit every installation/user scenario that we can dream up. It also is in the two separate issues that you snipped from my previous mail. I think we're not going to agree here, so to prevent any more lengthy discussions over gentoo-dev on this topic, you can contact me off-list. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] useful profiles.desc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Continuing a subject I've brought up several times in the past... Are we any closer to having a profiles.desc that lists all valid profiles? IIRC the current stable portage should be ok with it. Are there any other issues preventing this from becoming a reality? - -- You have no real enemies. Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbMBMC3poscuANHARAl10AJ9twxEaDuXBpiZBMB1OtOlhJJgV9wCffjgM jxo8Kz9t5g9V1cP3A6tL1H4= =x4YW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 05 Nov 2005 11:28:33 +0100 Grobian [EMAIL PROTECTED] wrote:
| Preemptive
| Users should be told of changes *before* they break the user's
| system, after the damage has already been done.
|
| style suggestion for unambigous interpretation:
| perhaps a because if applied afterwards instead of after
Ugh. Wonder how many comments I'm going to get on that one... There
should be a not before system, which I accidentally killed by
pressing the wrong key in Vim.
| Apart from that this point seems to repeat much of the previous one,
| it introduces a new unfounded claim (users do read, but now too late)
Read the linked forums thread and all will become clear.
| 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.
|
| Direct question that follows from this: what *do* we expect a
| user/system to have available? I think it's good to state that as
| well, since you're excluding a lot here in once sentence.
Anything that's in the system target, and as little as is reasonably
possible extra.
| Where does point 4 differ from the second part of point 3?
Oops.
| 6. Portage filters the news item and, if it is relevant, installs
| it in a special location to be read by a news item reader. Messages
| are also displayed to inform the user that news is available.
|
| So, same as for point 5, the exact details on how this works and what
| a 'news item reader' is (since you previously defined a requirement
| of having almost nothing available on the system) should be refered
| to here. I want to be sure that you will elaborate on it lateron, so
| I can stack up my many questions for now.
A news item reader is something which reads news items.
| The news item will be named in the form
| ``-mm-dd-item-name.en.txt``, where ``item-name`` is a very
| short name (e.g. ``apache-updates``) and ``en`` is the two letter
| ISO 639 [#iso-639]_ language code for the news item. The short name
| must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-``
| (hyphen).
|
| Consider replacing hyphen with an underscore to ease parsing.
Mixing hyphens and underscores? That's just going to start confusing
things...
| (Maybe: An English (''en'') version must be available for all news
| items as per GLEP 34 [#glep-34]_. Other languages ...)
GLEP 34 doesn't say anything about news items...
| ``Author:``
| Author's name and email address, in the form ``Real Name
| [EMAIL PROTECTED]``. Mandatory, multiple author fields may be
| specified if appropriate.
|
| Separated how? Using commas, semicolons, spaces or whatever?
Multiple fields. Maybe that'd be clearer were it to say Mandatory;
multiple author headers may
| ``Version:``
| Initially 1. Incremented every time a non-trivial change is
| made. Changes which require a re-read of the news item should
| instead use a new news item file.
|
| Perhaps you want to track trivial changes as well in the minor, in
| order to be able to quickly see a change was made, and prevent people
| from considering a non-trivial change as trivial.
Well, if you want to see that it was made, it's not trivial.
| Maybe you should explicitly state this field is optional and why. I
| could think of some reasons why this header should be mandatory, but
| perhaps you add a completely different value to the header than I do
| now.
Maybe I should just mark it as mandatory instead.
| From a completeness perspective, it would perhaps be a option to
| include a special header that contains a boolean expression that
| resolves to true if the message is relevant to the user, and false
| otherwise. This would allow AND and NOT to be included instead of
| only OR semantics.
|
| In any case, elaborate on why supporting only OR was chosen and why
| other (probably investigated) options were discarded (and hence make
| my statement above unnecessary).
The previous draft had an option for and or none-of modes. I took it
out because I don't think it's going to be anywhere near as useful as
one might initially think.
| The text body should be wrapped at 72 characters. No fancy
| formatting or tab characters should be used -- the news item may be
| being displayed directly to a terminal. Paragraphs should be
| separated by two blank lines.
|
| Elaborate some more on No fancy formatting or tab characters.
| People might want/like to include a bulleted/numbered list or insert
| a small (shell) code example. Also make some note on the average
| length (number of paragraphs) and perhaps a predefined structure
| (ie.: introduction/abstract, impact, solutions/actions,
| links/more-information)
These're things to be decided when news items are sent for review. Once
we have some real material there'll be a more useful way of judging
what is acceptable and what has gone too far.
| Thus, all proposed news items must be posted to the
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 05:24:51 -0600 Brian Harring [EMAIL PROTECTED] wrote: | Drop the lightweight bit and merge it into multiple delivery. You're | after lightweight _default_, which is fine, but the phrasing is a bit | screwed. Hrm, I don't see those as contradictory. There's a requirement that the solution does not require anything fancy, and a requirement that the solution does not force one particular reading method upon the user. There's no requirement that the solution must not be usable with anything which is not lightweight. | News items are published and delivered to users as follows: | snip | 6. Portage filters the news item and, if it is relevant, installs | it in a special location to be read by a news item reader. Messages | are also displayed to inform the user that news is available. | | Out of curiousity, how are you planning on having 101 general notices | reigned down on a users head during an initial install? Yes, you | have the atom filter, but what about general notices? People who've just done an initial install won't have lots of packages installed. As for general notices, if there're lots of them we have serious issues... | Further, how are notices going to apply to users who don't have the | package installed, then go and merge it? Your statement above | implies the irrevalent (at the time of sync) notices are ignored, | which breaks down under the scenario where a news item is pushed out | that apache configuration is going to change, I merge old style | apache after sync'ing the news, portage (due to your news id cache) | considers it deleted, and doesn't display it. Wording perhaps could be clearer... News items are added to the don't copy again list when they're copied, not when they're checked. | News items may be signed using GPG. If this is done, a detached | signature should be used. | | I'd argue for must be, personally. A bogus news item claiming to be | from portage devs, telling users to change their SYNC setting could | cause massive mayhem. Signing elsewhere isn't mandatory yet. | Still haven't address my point about | A) package moves combined with news entries Gotta handle those manually / with epkgmove. Someone could write a server-side handler for automatic updates if they want, but given that package moves are already a case of do all the things on a big list, it's not much added complexity... | B) N packages | | Assume you mean that the bit above is a full DepSet, not a single | atom (if that's the case, clarify that N atoms are allowed). A single atom is probably sanest... | Should clarify USE conditionals are a no go- might be worth | considering the full atom syntax (despite the fact portage doesn't | currently support it for depends), use flags, slot, etc. I'd rather not try to guess what Portage may or may not support in the future. There's nothing precluding using :slot and [use] atoms if portage ever supports them. | ``Display-If-Keyword:`` | A keyword [#glep-22]_ name, for example ``mips``. If the user | is on the arch in question, the news item should be displayed. | | N keywords == N Header entries? Yup. | No go on -core imo; it's a community/dev issue, should be visible to | the general public rather then hidden away in the ml we do our | flaming in. There *might* be legit security reasons for using -core, for example for nasty upgrade required security bugs that we can't disclose before a given date. Hopefully this will never happen. | Already pointed out that this won't fly looking forward, it | implicitly assumes a single repository. Again, we can deal with that if Portage ever gets multiple repo support. Until it does, I'm not trying to guess how it's going to end up being implemented. | Nuke flashy (any phrasing that allows for blinking crap sliding into | portage I instinctively dislike). Is there a technical name for the big red ! messages? | Portage must keep track of news items which have already been | installed to avoid repeatedly reinstalling a deleted news item. | | Track it how, via the directory, or a secondary list? The GLEP doesn't require any particular implementation. | News items can be removed (by removing the news file from the main | tree) when they are no longer relevant, if they are made obsolete | by a future news item or after a long period of time. This is the | same as the method used for ``updates`` entries. | | Might want to consider a maximum period of time for news entries to | linger by default; perhaps a header for controlling deletion (this is | would require commit access for whatever does the scans obviously). We don't do this with updates or ebuilds or anything else, so I don't really see the point. | Stop using trivial (no it's not in reference to above, just hit the | right word count where I'm whinging about it). But it's such a nice word! | Points above regarding working sanely for N repos need be addressed, Which I'll do right before
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 05 Nov 2005 11:34:23 + Lisa Seelye [EMAIL PROTECTED] wrote: | The first is the method of delivery: Through 'emerge sync', which | requires that users run this on a regular basis to receive relevant | news. Further, this process can take a very long time and transfers a | relatively large amount of data along with the news. | | My second concern is the frequency that users sync. A stated concern | is getting news to users before it is too late. Is there any way to | gauge the number of unique users which sync on a regular basis? When | is too late? Is there an acceptable window for delivering news? | It is not uncommon for me to refrain from running emerge sync (or | even cvs up on the entire gentoo-x86 tree) for weeks or months on | machines I wish to keep somewhat static. Well... If a user doesn't sync, they're not going to get hit by upgrade problems. So so long as news items are kept around for a sufficiently long period of time, there aren't going to be issues. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp14Bx456luU.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 5 Nov 2005, Ciaran McCreesh wrote: On Sat, 05 Nov 2005 11:28:33 +0100 Grobian [EMAIL PROTECTED] wrote: | Preemptive | Users should be told of changes *before* they break the user's | system, after the damage has already been done. | | style suggestion for unambigous interpretation: | perhaps a because if applied afterwards instead of after Ugh. Wonder how many comments I'm going to get on that one... There should be a not before system, which I accidentally killed by pressing the wrong key in Vim. I can't resist. I think you mean 'not after system,': ...*before* they break the user's system, not after Regards, - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (sparc, devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDbPLTQa6M3+I///cRAsAhAKDgotmZ+E9TMdLAgzUbVj8s3++mVwCfeVoj 9TSuRiLKvIofQFPp/RRrC4I= =1MKl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 17:58:40 + (UTC) Ferris McCormick [EMAIL PROTECTED] wrote: | I can't resist. I think you mean 'not after system,': | ...*before* they break the user's system, not after Uh oh, I think I finally cracked. Now I'm crazzyyy!!! -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpO75IR47G0Q.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 2005-11-05 at 17:53 +, Ciaran McCreesh wrote: On Sat, 5 Nov 2005 05:43:12 -0600 Brian Harring [EMAIL PROTECTED] wrote: | Your example readers delete from the news directory, yet I'd expect | that's not going to be desirable for all setups- nor is leaving the | news item in the news directory, and having it flagged every sync by | emerge as unread. | | Might want to consider some way to mark an item as read without | waxing it from the directory, if against it, clarify in the glep why. Hrm. Append '.read' to the filename? chmod -r filename -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 14:24:01 -0500 Philip Webb [EMAIL PROTECTED] wrote: | 051105 Ciaran McCreesh wrote: | News Item File Format | ... | The news item will be named in the form | ``-mm-dd-item-name.en.txt`` | ... | News Item Headers | ... | Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001). | | /spectate | Why the change in date format ? Let's use the proper international | style, ie ``-mm-dd``, in both places, which has the added | advantage of not creating problems for non-Anglophones with different | month names. spectate Consistency with GLEPs. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp8Bb3BIObeL.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, Nov 05, 2005 at 05:45:35PM +, Ciaran McCreesh wrote: | News items may be signed using GPG. If this is done, a detached | signature should be used. | | I'd argue for must be, personally. A bogus news item claiming to be | from portage devs, telling users to change their SYNC setting could | cause massive mayhem. Signing elsewhere isn't mandatory yet. Deal with it ;) New additions to the tree that don't require signing just shove more load onto anyone who is trying to make the entire tree signed- you're already placing it in the tree so it doesn't make screw with future portage plans (news directory), this isn't much different. Note also I'm not stating your example clients must handly signing- it'll ugly up the trivial exmples a bit, but the messages delivered *must* be signed from where I'm sitting. It's easy to state that well others don't have to sign; the problem here is that you must start somewhere. If the whole effort of signing is abandoned, the restriction that all news items be signed is easily dropped- going in reverse (retroactively getting authors to sign their old news) is a bit of work that could be avoided. | Still haven't address my point about | A) package moves combined with news entries Gotta handle those manually / with epkgmove. Someone could write a server-side handler for automatic updates if they want, but given that package moves are already a case of do all the things on a big list, it's not much added complexity... Note it please; it's a concern. | No go on -core imo; it's a community/dev issue, should be visible to | the general public rather then hidden away in the ml we do our | flaming in. There *might* be legit security reasons for using -core, for example for nasty upgrade required security bugs that we can't disclose before a given date. Hopefully this will never happen. Valid point, which will hopefully be noted in v3 of the glep? :) | Already pointed out that this won't fly looking forward, it | implicitly assumes a single repository. Again, we can deal with that if Portage ever gets multiple repo support. Until it does, I'm not trying to guess how it's going to end up being implemented. *cough* PORTDIR_OVERLAY *cough* Already have multiple repo support. Assumed you meant standalone, in which case I still think you're dodging support that must be there. Changing it after the fact because it wasn't design with an extra bit of forward thinking isn't something I'm incredibly game for. Yes it's extra work for you, but you're proposing the change ;) You're going for forward compatibility... this is just that. | Nuke flashy (any phrasing that allows for blinking crap sliding into | portage I instinctively dislike). Is there a technical name for the big red ! messages? Freaking annoying, is the technical term I use. ~harring pgpgXMPcJoSn7.pgp Description: PGP signature
Re: [gentoo-dev] useful profiles.desc
On Sat, Nov 05, 2005 at 01:34:55PM -0500, Chris Gianelloni wrote: On Sat, 2005-11-05 at 09:23 -0500, Aaron Walker wrote: Continuing a subject I've brought up several times in the past... Are we any closer to having a profiles.desc that lists all valid profiles? IIRC the current stable portage should be ok with it. Are there any other issues preventing this from becoming a reality? Also, what are the valid status entries? Is it just dev and stable? well, repoman only cares about dev, but yes, those are the only two status values we are using atm -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
051105 Ciaran McCreesh wrote: 5 Nov 2005 14:24:01 -0500 Philip Webb [EMAIL PROTECTED] wrote: 051105 Ciaran McCreesh wrote: News Item File Format ... The news item will be named in the form ``-mm-dd-item-name.en.txt`` ... News Item Headers ... Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001). /spectate Why the change in date format ? Let's use the proper international style, ie ``-mm-dd``, in both places, which has the added advantage of not creating problems for non-Anglophones with different month names. spectate Consistency with GLEPs. Sorry, that doesn't mean anything: could you offer something which makes more sense ? (I do realise you have put a lot of effort into this appreciate it) -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: | Apart from that this point seems to repeat much of the previous one, | it introduces a new unfounded claim (users do read, but now too late) Read the linked forums thread and all will become clear. the forums thread advocates against the new unfounded claim, IMHO. | The news item will be named in the form | ``-mm-dd-item-name.en.txt``, where ``item-name`` is a very | short name (e.g. ``apache-updates``) and ``en`` is the two letter | ISO 639 [#iso-639]_ language code for the news item. The short name | must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-`` | (hyphen). | | Consider replacing hyphen with an underscore to ease parsing. Mixing hyphens and underscores? That's just going to start confusing things... I was referring to the item-name. It is defined to allow -, whild the fields are also separated with -. Hence I suggested to allow _ in the item-name instead of - to avoid (possible) problems when parsing the field. | In any case, elaborate on why supporting only OR was chosen and why | other (probably investigated) options were discarded (and hence make | my statement above unnecessary). The previous draft had an option for and or none-of modes. I took it out because I don't think it's going to be anywhere near as useful as one might initially think. I'd appreciate it if that would be documented and grounded. | Elaborate some more on No fancy formatting or tab characters. | People might want/like to include a bulleted/numbered list or insert | a small (shell) code example. Also make some note on the average | length (number of paragraphs) and perhaps a predefined structure | (ie.: introduction/abstract, impact, solutions/actions, | links/more-information) These're things to be decided when news items are sent for review. Once we have some real material there'll be a more useful way of judging what is acceptable and what has gone too far. I guess then it's better to state that, and make no assumptions or partial decisions on it. If it is out of scope of the GLEP, make it like that. | - what if noone feels like commenting on the submission? Then it's assumed correct. | - how do you know a certain dev is a competent English speaker? *shrug* If we ever get onto linguistics arguments, there're enough of us with copies of Fowler and the OUP Style Guide to settle things. Then what is the point in requiring it is correct English? (Not even considering the big difference between UK/US English) You can and will not enforce it. Everyone writing such news item will do her/his best to make it sound like real English, and perhaps ask for help, but that's it. Hence my suggestion to put the doc writers in the loop somehow. | Does portage only 'warn' and still continue, or does it completely | stop when an unread news item is found for a package that is to be | upgraded? In the first case, the 'preemptive' requirement is being | violated, in the latter, the option for a '--force' or something must | be discussed. (Users with multiple systems might already know the | message, or users might not be interested in it since they don't run | the application in production.) Portage only *warns* you if you try to unmerge glibc... Which means you won't be able to satisfy your preemptive requirement. | Yes, and make it a requirement that all news messages get posted | somewhere on public channels. I don't see any particular need to *require* that all news items are posted to a specific place. You might be right, as the how, when and why of news items should be a completely separate thing, as I see it right now. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 17:24:14 -0500 Philip Webb [EMAIL PROTECTED] wrote: | Consistency with GLEPs. | | Sorry, that doesn't mean anything: | could you offer something which makes more sense ? GLEP 1 mandates date headers in that format. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpwbAlJapBpa.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 05 Nov 2005 23:32:19 +0100 Grobian [EMAIL PROTECTED] wrote: | I was referring to the item-name. It is defined to allow -, whild | the fields are also separated with -. Hence I suggested to allow | _ in the item-name instead of - to avoid (possible) problems when | parsing the field. The fields are separated with .s. Underscores for the name don't make parsing any more or less difficult. | | In any case, elaborate on why supporting only OR was chosen and | | why other (probably investigated) options were discarded (and | | hence make my statement above unnecessary). | | The previous draft had an option for and or none-of modes. I took it | out because I don't think it's going to be anywhere near as useful | as one might initially think. | | I'd appreciate it if that would be documented and grounded. Actually, I'm starting to think Jason's idea works best. | Then what is the point in requiring it is correct English? (Not even | considering the big difference between UK/US English) You can and | will not enforce it. Everyone writing such news item will do her/his | best to make it sound like real English, and perhaps ask for help, | but that's it. Hence my suggestion to put the doc writers in the | loop somehow. What makes you suppose that the doc writers are the most qualified English language speakers? | | Does portage only 'warn' and still continue, or does it completely | | stop when an unread news item is found for a package that is to be | | upgraded? In the first case, the 'preemptive' requirement is being | | violated, in the latter, the option for a '--force' or something | | must be discussed. (Users with multiple systems might already | | know the message, or users might not be interested in it since | | they don't run the application in production.) | | Portage only *warns* you if you try to unmerge glibc... | | Which means you won't be able to satisfy your preemptive | requirement. Not at all. You can warn users repeatedly, but there comes a point when trying to warn them any further becomes futile. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpW2Hb1pkuCA.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 14:29:31 -0600 Brian Harring [EMAIL PROTECTED] wrote: | Signing elsewhere isn't mandatory yet. | | Deal with it ;) In order to deal with it, I'd also have to come up with a solution to distributing keys for Gentoo developers. That's a separate issue which must be addressed separately. A wording change from may to should be is fine by me, but must be is not, at least until we have a real signing system in place. | | Already pointed out that this won't fly looking forward, it | | implicitly assumes a single repository. | | Again, we can deal with that if Portage ever gets multiple repo | support. Until it does, I'm not trying to guess how it's going to | end up being implemented. | | *cough* PORTDIR_OVERLAY *cough* | | Already have multiple repo support. Assumed you meant standalone, in | which case I still think you're dodging support that must be there. Overlays override on conflicts, they don't run in parallel. | Changing it after the fact because it wasn't design with an extra bit | of forward thinking isn't something I'm incredibly game for. Yes | it's extra work for you, but you're proposing the change ;) | | You're going for forward compatibility... this is just that. I'm going for not making any design decisions which will preclude reasonable future changes. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp9b6dSx8JbE.pgp Description: PGP signature
[gentoo-dev] Becoming Mirror
Hi! I am member of LUG, and we are interested in becoming a Gentoo Mirror! We are wanting to know info about system requirements and configuration. Cumps Armindo Silva -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Becoming Mirror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Armindo Silva wrote: Hi! I am member of LUG, and we are interested in becoming a Gentoo Mirror! We are wanting to know info about system requirements and configuration. Cumps Armindo Silva -- The following docs are available: Gentoo Linux rsync Mirrors Policy -- http://www.gentoo.org/doc/en/rsync.xml Gentoo Linux Source Mirrors Policy -- http://www.gentoo.org/doc/en/source_mirrors.xml those should cover most questions you'll have, and get you in touch with the right people. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDbVA+ZwjIiODIZ4oRAgnbAJ42RjVCwkxCwBLo4DQ+N67YeY6dxQCfdxst N14x4MlIiopmym54tfgRJ3Y= =hd17 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Becoming Mirror
this can be found in the docs at http://www.gentoo.org/doc/ On 11/5/05, Armindo Silva [EMAIL PROTECTED] wrote: Hi! I am member of LUG, and we are interested in becoming a Gentoo Mirror! We are wanting to know info about system requirements and configuration. Cumps Armindo Silva -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Becoming Mirror
Hi! You're right!! Just found it! I never entered on Other Documentation Section.. Thanx!! On 11/6/05, Dan Meltzer [EMAIL PROTECTED] wrote: this can be found in the docs at http://www.gentoo.org/doc/ On 11/5/05, Armindo Silva [EMAIL PROTECTED] wrote: Hi! I am member of LUG, and we are interested in becoming a Gentoo Mirror! We are wanting to know info about system requirements and configuration. Cumps Armindo Silva -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Becoming Mirror
On Sat, 2005-11-05 at 19:37 -0500, Robert Paskowitz wrote: The following docs are available: Gentoo Linux rsync Mirrors Policy -- http://www.gentoo.org/doc/en/rsync.xml Gentoo Linux Source Mirrors Policy -- http://www.gentoo.org/doc/en/source_mirrors.xml those should cover most questions you'll have, and get you in touch with the right people. /me hides, being the right person. But thanks guys for answering all the questions before I could even get to them. -- --- 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] GLEP 42 Critical News Reporting Round Two
On Sunday 06 November 2005 02:57, Ciaran McCreesh wrote: On Sat, 5 Nov 2005 22:18:14 +0900 Jason Stubbs [EMAIL PROTECTED] | The following headers are used for filtering. If none of these | headers are specified, the news item is displayed for all users. | Otherwise, the news item is displayed if *at least one* header | matches. | | It would seem more useful if the headers were sorted into the three | classes first. A news item would then only be displayed if a header | from the class matches or the class is empty. This would allow for | rules such as net-www/apache is installed and the keyword is either | mips or sparc. Hrm. I'll need to think about that. But it's starting to sound nicer than the and/or/none voodoo I'd removed previously. My sentences aren't making much sense either, even if you got my intention anyway. ;) A news item would then only be displayed if a header from the class matches or the class is empty *for each class*. | Isn't keyword just a generalization of profile? Why have both? Simplicity. Ok. Just confirming. | Thus, all proposed news items must be posted to the ``gentoo-dev`` | or ``gentoo-core`` mailing list, and ``Cc:``\ed to | [EMAIL PROTECTED] at least 72 hours before being committed | (exceptions may be made in exceptional circumstances). Any | complaints regarding wording or clarity **must** be addressed | before the news item goes live. | | Why gentoo-core? It's a news item; it's purpose is to be made public. Possible security concerns. Hopefully this will never happen. Ok. | Why put this in portage at all? Post sync hooks will likely be | available in 2.0.54. If adding hooks were as easy as adding a file to | a portage config directory, would adding the package that does the | above to the system package set be enough to force this new | information dispersal method on users? Performance. I have a bash script which does the installs that could easily be called by a hook, but it has to call portageq quite a bit. Otherwise a hook would be fine... Possibly it's fine anyway? The script could be converted to Python. Or we can have a go at speeding up portageq a bit. (Or both ;). It's just that there's only a small part of integrated into portage as far as the current GLEP goes, which then partially locks people out of working with the news items in alternative ways... Could you send over the bash version of the post-sync script? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] useful profiles.desc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Sat, 2005-11-05 at 09:23 -0500, Aaron Walker wrote: Continuing a subject I've brought up several times in the past... Are we any closer to having a profiles.desc that lists all valid profiles? IIRC the current stable portage should be ok with it. Are there any other issues preventing this from becoming a reality? There should be no issues anymore. I was planning on doing this myself at some point. Are you wanting to do this, or should I? Doesn't matter one way or the other to me :) If you were planning on doing it soon then go for it. I probably won't have the time to do it myself until I get done moving in a week or two. I vaguely remember someone (might've even been you) having all archs report a list of valid profiles. That'd be a good starting point. Cheers - -- How many weeks are there in a light year? Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbXAxC3poscuANHARAqhDAJ9P20MkYu+8HlhS59k9BYTtHC+HOACgilSe 25436aidq0JMwoy/vRkJPKA= =bnh4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
