Re: [gentoo-dev] stripping out the DO NOT REPLY from bugzie emails
Robin H. Johnson wrote: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: Please consider lowercasing the first sentence, to stop the yelling, and removing the repetition from the second sentence, which seems to treat the addressee as retarded. Suggested replacement: Do not reply to this email, nor to the person whose email address is mentioned below. To comment on this bug, please visit: Benno -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
Juergen.Schinker wrote: Bryan Østergaard schrieb: It's with a bit of sadness but also a bit of relief that I'm finally retiring from Gentoo. Aj! kloeri! No! i want you to stay, you are important for Gentoo but what can I do Bribe him! Benno -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn wrote: I know I've seen many instances where the word INVALID has got peoples hackles up, [...] This is the same issue I have with NOTABUG - it's like saying, you're wrong, shouldn't have raised the report, just perhaps not as in-your-face as INVALID. Precisely. NOTABUG sounds less harsh than INVALID (for some just a little, for others a lot), it is less likely to irk people, and it is also used elsewhere, so why not use it instead? (But don't use NOCHANGE, that is too cryptic.) Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Thomas de Grenier de Latour wrote: I think that protection against harmfull new config files should be selective to be useful. It should only affect directories from which files are blindly sourced by some services you are already running. There, and only there¹, new config files are unexpected change of your existing configuration, and thus lead to unexpected behaviors. [...] The directories i'm thinking of are all this /etc/*.d/: acpi.d, logrotate.d, pam.d, etc. There, adding a new file is really just like appending a new chunk to an existing config file. Indeed. But not only those, also the cron.*ly directories. The specific example I was thinking of is slocate, that isntalls a script into /etc/cron.daily, which I don't want there. Implementation of a special anti-new-file-protection for this critical directories could be done in at least two ways: - a global NEW_CONFIG_PROTECT variable [...] - an ebuild-specific variable, [...] Or via the config file of etc-update. Let the package manager always create ._cfg* files in the protected areas, and let the updater tool figure out from its configuration which files can be automerged and which to show diffs for. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Daniel Gryniewicz wrote: On Wed, 2006-09-13 at 19:47 +0200, Benno Schulenberg wrote: Ideally the package manager would unconditionally respect the config protection area, and it should be up to tools like etc-update to (configurably) automerge new files and identical files, just like it can be configured to automerge trivial/comment changes. I disagree. If there is a sane default configuration for something (which is most things), I want it installed, so it works out of the box. I don't want to have to fiddle with config files to get sshd up and running. There's no need to fiddle: it will run out of the box right after running etc-update. That is, when this tool is extended to deal with new files and configured to automerge them. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. I would much prefer new files to be treated as if replacing an existing zero length file. When something is installed into /etc, etc-update should alert me to this, because logically speaking a new configuration file is a big configuration change. Ideally the package manager would unconditionally respect the config protection area, and it should be up to tools like etc-update to (configurably) automerge new files and identical files, just like it can be configured to automerge trivial/comment changes. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt wrote: * Steve Dibb [EMAIL PROTECTED] schrieb: See the little D? It's not big, it's not fat, but it's warning you. :) Not actually an eye-catching. To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? You don't have to look at it. Write your own little emerge wrapper script, let it amongst other things grep for UD, and let it howl when it finds it. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Overlays: Status Report
Stuart Herbert wrote: * Developers and Users Guides online [2], [3] [3] http://www.gentoo.org/proj/en/overlays/usersguide.xml Without the s: http://www.gentoo.org/proj/en/overlays/userguide.xml -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Comment
Klaus-J. Wolf wrote: http://www.seismic.de/gentoo/gentoo_mask_proposal.html * Manually keyword unmasking an ebuild, automatically means unmasking the last one in the line of masked versions. No. Use the = to unmask a specific version only. For example: =sys-apps/findutils-4.2.25 ~x86 Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
Curtis Napier wrote: I'm especially interested in feedback from anyone who uses accessibilty programs such as screen readers or if you are color blind or have any other accessibilty issues. Not being blind or otherwise visually handicapped, but I use rather large letters (18 pixels), do not use the entire screen width for the browser window, and like to keep the monitor at low brightness levels. This means that indeed the green in the top bars is too dark to read. And that this green line wraps. And the text in the blabla-bar (Portage: an easy to use...) flows out of its box (see the pngs). This is both in Konqueror and in Firefox. In Konqueror alone the Design by in the bottom line wraps, and the little green arrows in the menus at the bottom are missing, which makes it hard to see that Name/Logo Guideline is a single entry. What I dislike most is that the links are always underlined. I've got my browsers configured not to underline links, and now this new Gentoo style sheet forces these underlines. The blabla-bar is unneeded, in my opinion it takes up too much space, it makes it look too much like a commercial site, and it makes the overall page too dark. Better make the menus that now sit at the bottom of the front page sit at the left. The little pictures in those menus are not needed, especially since the one for Resources is incomprehensible. The infinity sign at the top doesn't look enough like two O-s, and what is it supposed to refer to? Better use two plain O-s, and make them bend just a little toward each other. Benno bar-not-wide-enough-fox.png Description: PNG image bar-not-wide-enough-konq.png Description: PNG image bar-too-small-fox.png Description: PNG image bottom-wrapped-konq.png Description: PNG image missing-arrows-konq.png Description: PNG image
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: Next draft will propose being able to append .read to a filename to mark it read without deleting it. But don't use .read, as it can be understood as both present tense (imperative) and past tense. Better use something like .seen. Benno -- gentoo-dev@gentoo.org mailing list
