Re: [gentoo-dev] Guidelines for dangerous USE flags
On Tue, Aug 22, 2017 at 01:22:51PM -0400, Michael Orlitzky wrote: > The net-analyzer/nrpe package has a ./configure flag: > > --enable-command-args allows clients to specify command arguments. *** > THIS IS A SECURITY RISK! *** Read the SECURITY > file before using this option! > > Back in nrpe-2.x, it was available via USE=command-args, but I dropped > it from nrpe-3.x, and a user just asked about it (bug 628596). There are > at least two things we could do with a dangerous flag like that: > > 1) require EXTRA_ECONF to enable it. > 2) hide it behind a masked USE flag. > > Both options require about the same amount of work from the user, namely > editing something under /etc/portage. What do y'all think is the best > way to proceed? Are there other examples in the tree I could follow? I like the masked USE flag approach. Using EXTRA_ECONF requires a bit more work from the user (not much though) but is less visible afterwards in my opinion. Perhaps a name that implies that there is a security risk could be interesting, but that's a minor suggestion. Is there a way we could somehow ensure that a USE flag is never set globally, but only on a per-package basis? Wkr, Sven Vermeulen
Re: [gentoo-dev] rfc: /etc/hostname on gentoo
On Mon, Aug 22, 2016 at 01:28:50PM -0400, Michael Orlitzky wrote: > On 08/22/2016 11:58 AM, William Hubbs wrote: > > All, > > > > it looks like app-emulation/docker expects /etc/hostname to exist. > > > > Isn't there some kind of portable operating system standard that says > how to do these things? Yes, wouldn't the Docker project be happy to take on a patch that uses gethostname() or so? Wkr, Sven Vermeulen
Re: [gentoo-dev] Dev retirement - Farewell message
On Sun, May 01, 2016 at 04:57:09PM +0200, José Fournier wrote: > I have been a bit far from Gentoo for a rather long time now. I joined > Gentoo in 2013 and I used to be a translator for the French language. At > this time, I had to become a developer in order to be able to submit my > work in the previous documentation system – but in reality I am not a > developer at all. Nowadays, with the new wiki – which I can see grow > and improve day after day – it is no longer necessary for people like me > become a developer. > > At the beginning I could get a friendly and patient help from Sven > Vermeulen who introduced me and was my mentor for a while. I am very > grateful to him because it is not something obvious for someone who is > not a computer scientist to enter a world like the Gentoo Community and > Sven contributed a lot to make me feel at home. > > Recently, I decided to join the Fedora community to help as a translator > again. It a very different distribution and community but my previous > experience at Gentoo is very valuable. Arriving in this new home, I told > them all the good I think of the Gentoo distribution and of its people. > If there is one distribution which made me progress substantially in my > understanding of the Linux system, it is Gentoo, with no doubt. > > Before leaving your community, I want to wish you all the best and thank > you very much for your constant effort to make free and open source > software available to everyone. > Hi José, Although it's sad to see you leave, I feel it's more like a mutation than a farewell. I'm glad you continue to contribute to the open source/free software community, and wish you all the best within the Fedora community. With kind regards, Sven Vermeulen aka SwifT
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Sat, Oct 10, 2015 at 10:09:11AM +0200, Michał Górny wrote: > I have the pleasure to announce that we have formed a new Reviewers > team [1] for Gentoo. The team is going to assemble developers willing > to perform ebuild reviews and help contributors improve their ebuild > skills. > > The main goal of the team is to handle GitHub pull requests. We are > going to review incoming PRs, communicate with maintainers and merge > them as appropriate. In particular, we're going to help willing > contributors get high-quality, PGP-signed commits into Gentoo, > therefore helping them prepare to become Gentoo developers. > > The side goal is to review current Gentoo commits for major QA > violations and other issues, aiming at improving the quality of ebuilds > in Gentoo and helping other developers using bash, ebuilds and git > effectively. > > [1]:https://wiki.gentoo.org/wiki/Project:Reviewers This is good news. There are quite a few developers that manage a small subset of packages while doing tremendous work for Gentoo within that community. For instance, they focus on particular deliverables in repositories which eventually get packaged, or on integration of certain components which have a strong, broader community coverage. These developers will certainly welcome any helping hand (even post-commit) in keeping packages of high quality. I hope you will also focus on the documentation side. Certain processes that we follow within Gentoo (for commits, for instance the Git workflow) would benefit from a good document *set* (yes, set, as you'll definitely want such processes to have both a single-screen version as well as an elaborate version). I've also found myself often looking for similar ebuilds in which a certain problem would already have been implemented. For instance, ebuilds with an optional python part using the python-r1 eclass. Do you think it is worthwhile to have a number of packages assigned as good examples? Wkr, Sven Vermeulen
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman wrote: I think X-Gentoo-Bug: 557022 also makes the job easier for tools that parse commit messages. I don't. Just the bug prefix should be fine for almost all purposes, even for tools. I'm pretty sure the majority of developers don't care that one developer uses X-Gentoo-Bug and another just adds it to the commit title. I like /guidelines/ in the sense that, if I don't know something, I can look it up. But don't make it mandatory until we start depending on it (for instance, when we would automate stuff based on the content of the commit message). Wkr, Sven Vermeulen
Re: [gentoo-dev] what's the correct format for bugs containing package name and version?
On Fri, Mar 06, 2015 at 06:55:13AM -0500, Rich Freeman wrote: Out of curiousity, what makes the changes necessary in the first place? It seems like an incredible amount of effort is going into standardizing the format of textual summary lines and perhaps the simplest solution is to just not standardize them at all. It doesn't hurt to have a recommendation, and personally I really appreciate when people (yes, that includes developers and wranglers ;-) update the line to be more informative. There already is a recommendation on the wiki, part of the Bug Wranglers project [1]. [1] https://wiki.gentoo.org/wiki/Project:Bug-wranglers The difference between the segregation character (be it ': ', ' - ', ' : ' or what not) is for me less of a concern than the fact that it starts with the category/package name+version (and with in front if it has been fixed with that version or higher). That is a real plus as I can easily see how many fixes are in to a package, which ones to mark as FIXED when stabilizing (I tend to use TEST-REQUEST as long as the package is still in ~arch), etc. There are other resources on the wiki as well which might best be aligned with whatever recommendation is used. See Beautiful bug reports [2] and Bugzilla HOWTO [3] as examples. [2] https://wiki.gentoo.org/wiki/Beautiful_bug_reports [3] https://wiki.gentoo.org/wiki/Bugzilla_HOWTO Wkr, Sven Vermeulen
Re: [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
On Mon, Sep 01, 2014 at 11:26:49PM +0200, Tom Wijsman wrote: [...] With this change, we implement the same end result (correctly labeled files after installation) while removing the need for the DEPEND dependency. After all, this was not a build-time dependency but a merge-time one, which we abused a bit to make things work. With this change in place, we can now update the tree (at least, for those packages that do not have other SELinux related dependency requirements - those that link with libselinux still need it in DEPEND of course) to remove the USE=selinux conditional dependency from DEPEND. Given the discussion on dynamic dependencies and so, I am thinking about doing this as follows: 1. Create a tracker with separate bugs for every package where this change can be made 2. Give developers time to apply this (simple) change together with whatever other changes they were planning. 3. After 6 months or so, do the change myself (with revbump) [...] Is this a good approach to take? [...] LGTM; we should avoid unnecessary bumps rebuilds for trivial changes, especially when a USE flag based dependency line is removed from DEPEND. Michał Górny told me on IRC that I might be approaching this incorrectly (or at least, inefficiently). I was working on the massive bug-spree (right now stopped around 22% of the packages to investigate) so I'm temporarily holding off until I'm certain. The only change I want to instill on packages is to remove the USE=selinux specific dependency to a sec-policy/selinux-* package from the DEPEND variable. So something like: DEPEND= foo - bar - selinux? ( sec-policy/selinux-bez ) + bar If I am allowed to do this change without revbumping, I can just stop making massive bug reports and do the change(s) myself... Someone? Pretty-please? Wkr, Sven Vermeulen
Re: [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
On Sat, Nov 01, 2014 at 01:52:57PM +0100, Michał Górny wrote: Michał Górny told me on IRC that I might be approaching this incorrectly (or at least, inefficiently). I was working on the massive bug-spree (right now stopped around 22% of the packages to investigate) so I'm temporarily holding off until I'm certain. The only change I want to instill on packages is to remove the USE=selinux specific dependency to a sec-policy/selinux-* package from the DEPEND variable. So something like: DEPEND= foo - bar - selinux? ( sec-policy/selinux-bez ) + bar If I am allowed to do this change without revbumping, I can just stop making massive bug reports and do the change(s) myself... You should have emphasized that the dependency will still be in RDEPEND. As I said with QA hat on, such a change is fine since it affects build-time dependencies only. People who installed the package already are not affected. Thanks. I'll do the necessary updates tomorrow then (without revbump) and invalidate the bug reports I already made. Wkr, Sven Vermeulen
[gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
tldr; I want to remove USE=selinux deps from DEPEND in non-libselinux-linking packages in a sane manner and use a bug tracker with 6 months timeframe. Hi all In the past, to enable proper SELinux support in our tree, we had to have the appropriate SELinux policy modules installed and loaded before the package/application for which the policy was designed is merged to the system. The reason is that otherwise the files installed on the system will have the wrong labels assigned, making the applications unable to function properly. We implemented this by having the USE=selinux triggered dependency in both DEPEND (needed before merge) and RDEPEND (policy needs to be available during runtime), like so: DEPEND=selinux? ( sec-policy/selinux-somepolicy ) RDEPEND=selinux? ( sec-policy/selinux-somepolicy ) Recently, we updated the SELinux eclass so that after installation of a policy package, the reverse dependencies of that package are looked up and those reverse dependencies are relabeled (i.e. proper SELinux labels are assigned to the files of that package). With this change, we implement the same end result (correctly labeled files after installation) while removing the need for the DEPEND dependency. After all, this was not a build-time dependency but a merge-time one, which we abused a bit to make things work. With this change in place, we can now update the tree (at least, for those packages that do not have other SELinux related dependency requirements - those that link with libselinux still need it in DEPEND of course) to remove the USE=selinux conditional dependency from DEPEND. Given the discussion on dynamic dependencies and so, I am thinking about doing this as follows: 1. Create a tracker with separate bugs for every package where this change can be made 2. Give developers time to apply this (simple) change together with whatever other changes they were planning. 3. After 6 months or so, do the change myself (with revbump) I don't think it is useful for end users that I do the change immediately as this creates package bumps (and rebuilds) with no real benefit, and not bumping is also not a good idea given the discussion on dynamic dependencies in the past. By providing a 6-months period, developers can put in this change when they are bumping the package themselves (for functional and other reasons) and the bugs (with tracker) allow developers to not forget this. Is this a good approach to take? Happy to hear your thoughts on this, Sven Vermeulen
Re: [gentoo-dev] Re: don't rely on dynamic deps
On July 22, 2014 11:25:05 AM CEST, Pacho Ramos pa...@gentoo.org wrote: El mar, 22-07-2014 a las 10:32 +0200, Kristian Fiskerstrand escribió: [...] I find it somewhat curious that the difference between ~arch and stable hasn't been brought up in this discussion yet. IMHO a user on ~arch should expect a higher number of rebuilds, it _is_ after all testing, whereby at the point it reaches stable, the deps are hopefully more likely to be correct to begin with. Does anyone have any insight into where these changes most often occur? Well, I have seen multiple times of this kind of fixes being noticed by people running really old stable boxes. They notice them when they update to latest stable and, then, we need to fix depends raising the versions usually :/ Maybe this discussion should be focused on trying to think about how to standardize a way for distinguish between revision bumps needing full rebuild or only VDB updates :| As someone who regularly adds in dependencies without bumping (adding USE=selinux dependencies to the proper SELinux policy) because that would trigger lots of totally unnecessary rebuilds: +1 Wkr, Sven -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Multilib dependencies need to have = on least version having EAPI=5 or multilib support
On Thu, Jun 19, 2014 at 12:13:12AM +0200, Michał Górny wrote: Hi, developers and users. [...] Thank you for your cooperation. If you have any questions, please do not hesitate to ask. Hi Michał Thank you for your endless effort to get Gentoo to this stage (and further). Wkr, Sven Vermeulen PS I'm in a positive mood
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, May 30, 2014 at 04:34:09PM +, hasufell wrote: Tom Wijsman: Please no p.mask for a single line being wrong... That's nonsense. The amount of wrong lines doesn't matter. A single wrong line in the kernel can break your whole system as well. Please p.mask (or patch) immediately. There is no point in waiting. I'd appreciate any patch on the Gentoo Handbook to use another tool for initramfs. I have some experience with dracut, but the last dracut generated initramfs failed on my system, whereas genkernel's still goes well. The last Dracut generated initramfs also failed on SELinux systems, but that isn't something that cannot be worked around... Wkr, Sven Vermeulen
Re: [gentoo-dev] RFC: Namespace for users created for packages
On Wed, Mar 26, 2014 at 02:32:58PM +0100, Michal Hrusecky wrote: Hi all, interesting discussion started in openSUSE mailing list[1][2] and I would like to open up the same question on this mailing list. Basically it is about the following problem. Citing parts of proposal: Many packages need to add user and group names for their unprivileged daemons. Many names are short for convenience, e.g. 'pop', 'vdr', 'tor' or 'znc'. Since there is no separate name space for system users those names may collide with names of real persons. Sharing a user name between a system user and a normal user leads to surprising or even security relevant misbehavior as the daemon user may write to files in the real user's home or vice versa. Conclusion, in short, is to prefix system users (with some exceptions like root or nobody) with underscore '_'. So you would get users like '_pop', '_vdr', '_tor' or '_znc'. OpenBSD already does that[3]. openSUSE proposal with more details can be seen on GitHub[4]. So the question is, what would you think about such a policy in Gentoo? I'm in favor. It shouldn't be used as *the* check to make sure that an account is a functional (non-interactive/daemon) account (for that there is also the user id range and so on) but for visibility it's definitely worth persuing. Wkr, Sven Vermeulen
[gentoo-dev] New package eid-viewer, is app-misc ok?
Hi all I'm going to add eid-viewer, which is software to view the contents of a Belgian eID card (such as the person's picture, address details or certificte information), to the Portage tree. I think the most proper category is app-misc, but considering this is already a quite full category I'm open to suggestions what a better one would be (if any). There is a related package, called app-crypt/eid-mw, already in the tree under the app-crypt category as it is middleware for interacting with the card. However, unlike the middleware, the viewer doesn't seem to perform anything cryptographic-related. So - is app-misc ok? Wkr, Sven Vermeulen
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Tue, Dec 10, 2013 at 09:55:05PM +0100, Pacho Ramos wrote: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I'm ok with it. At least cronie's main website is quick to find, and I remember a bug I sent in to the cronie maintainers and got a fast reply, so positive experience as well. Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Sat, Aug 03, 2013 at 04:44:52PM +, Duncan wrote: I run openrc- because I guess my configuration's unusual enough to trigger bugs once in awhile, and from experience once I do, it's a lot easier to track 'em down if I've only a couple commits to check since my last update. Plus the fact that I can (and religiously do) run the unpack to trigger a git pull, then run git whatchanged, BEFORE doing the actual update. So if there's a problem, I either spot it right away before I actually build and install the update, or at minimum, I have a very good idea where it is once I hit it, because I have a good idea what changed and why. Care to elaborate a small bit on this? Is this a hook through bashrc that you use? I'm running a few - myself (not openrc though) and am interested in doing something similar... Wkr, Sven Vermeulen
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
Alex Legler a...@gentoo.org wrote: - Developer list: Moves to the sidebar. Not sure how to render that. Maybe in a comment and people remove that once they have added all the members? Oh so the developer list and subproject list will be generated by mediawiki? Cool. I can just drop that (at the time of conversion the project sites themselves are still available to consult). I'll update the stylesheet with the suggested style improvements this evening. Wkr, Sven Vermeulen -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
On Wed, Jun 26, 2013 at 03:54:47PM +0200, Alex Legler wrote: I've committed my draft XSL to the gentoo/xml/htdocs/xsl location, named guidexml2wiki.xsl. It still requires some updates that I'll work on soon (such as handling internal links) as I'll be using it more and more for the guides on gentoo.org/doc/en to move to the wiki as well. ProjectXML generates towards GuideXML, so should be usable chained. It would be nice to move the foundation/ content to the Wiki as well I think. I did some additional work on the style (as well as making a small wrapper script to simplify handling it). There are still some issues that I need to sort out, but I hope I can do that the coming days. I keep track of the stuff at [1], an example output can already be found at [2]. [1] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki [2] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki/test It would appreciate some feedback - things that do not need to be covered anymore or so (I know our wiki supports some stuff that shouldn't be rendered anymore). No promises, but everything I know can help ;) btw, the tool actually converts GuideXML, so I'll be updating it later on to support better moves of our documentation as well. Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: Gentoo Hangouts
On Mon, Jun 24, 2013 at 12:04:04PM +0100, Markos Chandras wrote: I like the idea. It might help bring developers and users closer. Me too, if I can ever contribute to it, or help users with their Gentoo (Hardened/SELinux/IMA/EVM/...) through it, I'll be happy to work with it. Wkr, Sven Vermeulen
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On Tue, Jun 11, 2013 at 02:15:29PM +0200, Alex Legler wrote: On 11.06.2013 13:05, Theo Chatzimichos wrote: On Tuesday, June 11, 2013 12:20:20 Sven Vermeulen wrote: Jason A. Donenfeld zx...@gentoo.org wrote: On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler a...@gentoo.org wrote: - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document What is the current status of such a tool? It is a script (xslt) that can be used with xsltproc to convert large chunks into wiki style. It isn't perfect though thus still requires manual review, but it is doable. I *think* I committed one to the repo a while ago. If not, I'll do so soon (I have one in my own repo just for this purpose). How about an ebuild please? Optional. I intend to expose this as a web site/service. I've committed my draft XSL to the gentoo/xml/htdocs/xsl location, named guidexml2wiki.xsl. It still requires some updates that I'll work on soon (such as handling internal links) as I'll be using it more and more for the guides on gentoo.org/doc/en to move to the wiki as well. ProjectXML generates towards GuideXML, so should be usable chained. But as mentioned, it's a draft, and if you don't like it I don't mind at all ;-) Wkr, Sven Vermeulen PS An ebuild for a single stylesheet seems like overkill to me, but i've been proven incorrect in the past...
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
Jason A. Donenfeld zx...@gentoo.org wrote: On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler a...@gentoo.org wrote: - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document What is the current status of such a tool? It is a script (xslt) that can be used with xsltproc to convert large chunks into wiki style. It isn't perfect though thus still requires manual review, but it is doable. I *think* I committed one to the repo a while ago. If not, I'll do so soon (I have one in my own repo just for this purpose). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] extending metadata.xml to support CPE information
On Wed, May 08, 2013 at 09:06:00PM -0400, Mike Frysinger wrote: On Wednesday 08 May 2013 21:01:19 Mike Frysinger wrote: On Tuesday 07 May 2013 23:59:18 Mike Frysinger wrote: we've already got a database for maintaining this sort of thing on a per- package basis: metadata.xml. so let's extend the DTD to cover this. the existing remote-id field looks like a pretty good fit, so the proposal is simple: add a new cpe type. committed: or not. someone on cc want to commit that change for me ? :) just add cpe between cpan-module and cran in the remote-id field. Done Wkr, Sven Vermeulen
Re: [gentoo-dev] extending metadata.xml to support CPE information
On Tue, May 07, 2013 at 11:59:18PM -0400, Mike Frysinger wrote: the guys who maintain the security CVE project [1] [2] (designed to be the authority when it comes to indexing security related vulnerabilities in projects) have a CPE specification [3] to make tracking CVEs back to a canonical source in a machine parseable format. the ChromiumOS project wants to be able to tie CPEs to a specific package. this would probably also be a good thing for our own security team to tie into the GLSA process. the Debian project too is extending their database to include CPE information [4]. we've already got a database for maintaining this sort of thing on a per- package basis: metadata.xml. so let's extend the DTD to cover this. the existing remote-id field looks like a pretty good fit, so the proposal is simple: add a new cpe type. the entries for net-misc/curl would be: upstream remote-id type=cpecpe:/a:curl:curl/remote-id remote-id type=cpecpe:/a:curl:libcurl/remote-id /upstream or the gzip package: upstream remote-id type=cpecpe:/a:gnu:gzip/remote-id /upstream for most packages, there will probably be only one cpe entry, but as you can see here, sometimes more than one can track back to a single package. we have some scripts running on the CrOS side to try and do an initial seed (at least, for all the packages we're using), so i'll probably take care of merging that into the main tree. i'm not proposing this be required or anything (since not all packages will have one). I'm all for it. We can then easily map CVEs against packages, especially if the version structure we use in the ebuilds is the same one as used upstream (so the remainder of the CPE with version can be easily obtained). http://blog.siphos.be/2013/04/matching-packages-with-cves/ Wkr, Sven Vermeulen
Re: [gentoo-dev] alsaconf removal?
On Thu, Apr 11, 2013 at 10:10:45AM +0300, Samuli Suominen wrote: alsaconf should die as it's useful only for ISA/PCMCIA and currently broken see, http://bugs.gentoo.org/456214 does anyone have problems with dropping alsaconf and patching the gentoo's alsa-guide.xml to tell users to edit /etc/modprobe.d/alsa directly if they need? udev will autoload the modules just fine even without touching the whole file for PCI, USB, ... devices Fine by me.
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
On Sun, Jan 06, 2013 at 10:01:00PM -0600, Doug Goldstein wrote: On Sun, Jan 6, 2013 at 7:31 PM, Robin H. Johnson robb...@gentoo.org wrote: Just a heads up, DNSSEC is now live on *.dev.gentoo.org hosts. So for those that had to look up some or all of what Robin mentioned, I'll summarize below. Feels like I'm on reddit now... Upvote for you for the explanation, and an upvote to Robin for implementing it for us! Wkr, Sven Vermeulen
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Sat, Dec 08, 2012 at 08:10:32PM -0500, Rich Freeman wrote: Uh, does emerge-webrsync have some kind of automagical detection of the fact that you're building a chroot? I would think that it would sync /usr/portage, and not /mnt/gentoo/usr/portage. Perhaps you should move that down into the chroot section, and mkdir /usr/portage if that is needed? Crap. Indeed, section moved towards the place where we optionally recommend emerge --sync, and put in an mkdir /usr/portage. Wkr, Sven Vermeulen
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 10:44:31AM -0500, Richard Yao wrote: On 11/30/2012 06:46 AM, Sven Vermeulen wrote: On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Seems a good improvement to me. I'm ok with it as well. I'll draft up something. I suspect emerge-webrsync is available on all platforms? It is part of sys-apps/portage. Okay, I've updated the instructions. First, I removed the references to the stage3 snapshots on the Universal CD as I don't think we have a (recent enough) Universal CD, and we would recommend the stage3 files from our mirrors anyway. Second, the Portage tree snapshots are now installed through emerge-webrsync (which means the entire section on downloading the tarballs, checking integrity, extracting is now a single paragraph). Finally, the section on updating the Portage tree (using emerge --sync) is now marked as optional, with the remark that if you're behind a firewall you can safely ignore this section as the user will already have a quite up-to-date tree installed. I don't know if we should remove the section altogether (about emerge --sync) or not. It is a small step and users *will* create bug reports about it if they don't notice it in the documentation anymore. Marking it optional seems to be a good approach here. Wkr, Sven Vermeulen PS Commit was made a few minutes ago, so please give it an hour before it shows up on the site.
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Seems a good improvement to me. I'm ok with it as well. I'll draft up something. I suspect emerge-webrsync is available on all platforms?
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, Jul 24, 2012 at 01:15:43PM -0400, Michael Orlitzky wrote: I think a news item is reasonable here (in addition to the above). Most users don't know about the move from /etc/make.conf to /etc/portage/make.conf. After this change, there will be a gradually-increasing need to know that a switch took place. 1) To a first approximation, nobody reads the documentation. There sure are a lot of nobody's then... Wkr, Sven Vermeulen
[gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, Jul 24, 2012 at 12:07:59AM +, Jorge Manuel B. S. Vicetto wrote: I've talked with both the PR and Docs team before about this change. I'll try to help the docs team updating the handbook. Speaking of which, will this also start the use of the SHA512 WHIRLPOOL checksums? We've had a bug open for it for a while (bug #386475) but the digests still don't show this. If it is simultaneously, we'll need to fix that as well. Can current users also already use the /etc/portage location? If so, I can already update the docs now (since I'll need to describe both of the locations for a while anyhow). Wkr, Sven Vermeulen
Re: [gentoo-dev] Looking for a (temporary) proxy docdev for french documentation
On Thu, Jul 12, 2012 at 06:22:31PM +0200, Xavier Miller wrote: The french documentation is quite outdated, and this is not a good vitrine to Gentoo for the French-speaking users. By this outdated documentation, we get, in the french subforum and #gentoofr IRC channel, many outdated questions about HAL, baselayout 1, or CHOST changes... I had contact with cam, who said there is nobody now in the FR doc team. In the other side, there are some volunteers who can help to update the official documentation. We need thus an /ad interim/ proxy docdev to help us to merge the patches for the documentation. Meanwhile, I could follow the procedure to become a docdev. Hi Xavier, You might want to take this to the gentoo-doc mailinglist. That being said, I don't mind proxying commits for you guys. I'll contact you offlist for the details. Wkr, Sven Vermeulen
[gentoo-dev] Last rites: some sec-policy/selinux-* packages
In the past, some SELinux policy packages provided SELinux modules whose name didn't reflect the package name. For instance, selinux-gnupg provided the gpg SELinux module. A year or so ago, our SELinux module packages got a standard naming convention so that selinux-module provides the module SELinux module. Or, in the example above, selinux-gpg provides gpg. The ebuilds that had a wrong name got updated to DEPEND on the new package (so they act as some sort of wrapper) so that we didn't have to introduce package renaming. I've now also removed all dependencies on these wrapper packages and will remove them from the tree in about 30 days. The packages are: selinux-acpi selinux-audio-entropyd selinux-bluez selinux-cyrus-sasl selinux-desktop selinux-ftpd selinux-ipsec-tools selinux-jabber-server selinux-nfs selinux-oidentd selinux-snmpd selinux-tftpd selinux-ucspi-tcp selinux-courier-imap selinux-gnupg selinux-haveged selinux-openldap Wkr, Sven Vermeulen
[gentoo-dev] Cleanup of @link attribute in guides
Hi guys, Unless I'm notified why I shouldn't, I'll be removing the @link attributes from all guides under gentoo/xml/htdocs from the guide... tags. This attribute was used in the past for improving linking across documents, but the underlying functions have all been removed for quite some time now and I rather clean up the DTD a bit. I'm aiming for Tuesday April 10th (or later) to give the smarter guys and girls here ample time to tell me to stop touching their files and do some real work instead. Once the link has been removed from the documents, I'll also remove it from the DTD so that new commits won't bring it in again. Yours faithfully, your local doc monkey Sven Vermeulen PS Sending to gentoo-dev because it also includes changes on the xml/htdocs/proj/* documents.
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote: Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? I don't like the cons approach, as it gives the impression that users are pushed into a negative solution, whereas the current situation works just fine for almost all users. The approach for a different partition is for performance reasons (which most users don't have any negative feelings about) and as such might be read as a ricer approach. But perhaps it would be more lean to just start with a wiki page (or document) for alternative / better partitioning layouts, and when that has stabilized then we can talk about Handbook integration, not? Wkr, Sven Vermeulen
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Sat, Mar 31, 2012 at 08:56:22AM +0100, Ciaran McCreesh wrote: Do you really want to be advertising an awful hack that doesn't really work, is conceptually unsound and that breaks all kinds of things in subtle ways? Isn't that something all major distributions do? ;-) Sven
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. Wkr, Sven Vermeulen
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Tue, Mar 27, 2012 at 02:47:15PM -0400, Rich Freeman wrote: On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev tetrom...@gentoo.org 1. ext4, not ext3, needs to be recommended as the default filesystem. We have kernel 3.2 marked stable, there is no need to keep talking about ext4 as if it's something experimental. I tend to agree here. Not sure we need the full discussion of filesystems either. Ext4 is probably good enough for everybody, and mention ext3/2 as more established alternatives. I see no issue putting ext4 as the suggested file system. However, it must be checked on a per-architecture basis (I can only test x86 and amd64 myself - I know, I'm missing all the fun) and preferably brought on by the responsible teams of those architectures. Dropping the (elaborate) explanation on file systems won't win us much. It's not like it is that long - a paragraph per file system type. Even the online help in recent distribution installations provide more information. I tend to feel the same way about stuff like LILO. I would *really* like to drop LILO and while we are at it, get grub2 working on all systems/architectures and stable ;-) But I'm not going to drop LILO without group consent. Then again, Gentoo is about choice. It just seems like we're presenting users with more choices than makes sense for a newbie. If there is a choice between something that 99.99% of users will want, and some ancient piece of cruft that still works and is better for 0.01% of the userbase, does that really have to be in the handbook? Welcome to documentation development. The Gentoo Handbook has always been a difficult source for such discussions. If we truely want to provide information towards our users on all possible choices, you'll need a totally different approach. I once started (before I left Gentoo, rejoined, left again) on a complete gentoo handbook that covered much more in greater detail (you'll find the last version at http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml) but I've since moved away from that. Perhaps I should work again on it... Wkr, Sven Vermeulen
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Tue, Mar 27, 2012 at 02:29:34PM -0500, William Hubbs wrote: Why not just the separate quick install guide like we have that lists steps and the handbook if yu want more details? We came from that. It means we need to start managing just the commands for each architecture. After a while, people start asking more information for just the necessary bits, making the guides longer and longer, after which they'll eventually need to be made multi-page. Wkr, Sven Vermeulen
Re: [gentoo-dev] www-servers herd is empty
On Wed, Mar 21, 2012 at 09:22:19AM +0100, Dirkjan Ochtman wrote: Then, the way to go would be to move them to maintainer-needed and let people pick whatever they want. I agree and can do it myself just now if you let me do Seems sensible. I also dont mind helping out here, I use nginx, privoxy, squid and apache on a daily basis (albeit not to their full potential). Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote: We should really have some documentation on how to create a minimal initramfs that mounts /usr (if we don't already, I haven't looked). I've never needed one until now and don't have the foggiest idea how it's done. I can't be the only one. I just started the tracker [1] for the documentation changes and sent info to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed updates trickle into the documents. [1] https://bugs.gentoo.org/show_bug.cgi?id=407959 Also, the handbook still endorses having a separate partition for /usr and includes it in the example setup. This should be changed now, not when stabilization time comes. It's an example, and we still endorse it. Only will we now tell users to use an initramfs with it. Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 03:00:41PM -0500, Mike Gilbert wrote: I'm asking how does one enable PIE/ASLR, not how to check if it is enabled already. Look at http://hardened.gentoo.org, the default toolchain used includes PIE, and it also includes various other measures (like additional grSecurity restrictions or even SELinux) that makes Gentoo Hardened systems less vulnerable to this specific vulnerability. Wkr, Sven Vermeulen
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 05, 2012 at 08:08:44PM +, Ciaran McCreesh wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. They've thought of that, and will make - kexec mandatory so that reboots are not needed for those times you need to switch kernels - make hibernation mandatory for the other times
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote: I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. dracut fully supports SELinux (it's used in Fedora which has this SELinux horror on by default). Yes... but no. Fedora uses SELinux but using a policy where most domains run unconfined (meaning they're allowed to do almost anything) and mostly the network-facing services are confined. I just got dracut working on a SELinux system here (took me a few hours to compile a SELinux domain for dracut, because the application doesn't work with the standard privileges of an administrator) and it boots up (up to and including dracut: Switching root) until SELinux is activated. From that point onwards, it's dead since its using wrong labels and wrong context. It is SELinux-aware (it mounts the selinuxfs and such) but I think I'll need to edit the /usr/lib/dracut/* stuff to get it to boot up properly on a SELinux system that doesn't use unconfined domains... I'll try to get it working the next few days. Once (or when) it does, I'll submit the necessary patches to wherever is necessary. Wkr, Sven Vermeulen
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I don't like this one bit. Things used to be simple with the split between /bin and /usr/bin (and its related directories), this isn't going to make it more simple. 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. 3) Try to maintain things the way they are as long as possible. I'm all for this one. But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Wkr, Sven Vermeulen
Re: [gentoo-dev] We need *you* for a USE=selinux dependency
On Mon, Dec 05, 2011 at 08:54:13AM +0100, Paweł Hajdan, Jr. wrote: In Gentoo, unlike some other distributions, we try to keep the number of loaded/installed modules to a minimum so that policy rebuilds as well as the system overhead is limited. This results in a base policy (provided by selinux-base-policy) and modules (provided by sec-policy/selinux-modulename). To make sure that installations of a package pull in the right SELinux module, the proper dependencies must be defined. Are you sure this is right choice? It seems to me that it'd be better to focus no making things work, and increasing the complexity of the deps makes this harder (and increasing the number of packages you maintain too). Unless you have _abundant_ resources to deal with that, I'd like to discourage you from handling policies that way. For end users, this is much more enjoyable. If we load up all policies, then any interaction with the SELinux policies will take some time. Also, all policies in memory do take up some space. Finally, for development purposes, this is very much enjoyable as well, since it allows for much faster policy development (rebuild policies in seconds to minutes rather than dozen of minutes). Maintenance is actually pretty easy. The eclass we use provides us with a very easy interface to add modules, and because it is a module per ebuild, we can push changes on individual modules without pushing full policy builds again. Furthermore, imagine I'm adding a new package foo that is covered by the SELinux policy. Most developers don't use SELinux (hey, I suspect most of them don't even use developer profile; bad, bad!). How do I know whether it's sec-policy/selinux-foo that's not yet added or sec-policy/selinux-games or something else... If the complete policy is in one package, this should be obvious, and we don't even need deps for that. I know. This is one major hurdle that we need to take on. Using dependencies is the easiest approach, albeit the most resource intensive one (initially, that is). I don't mind having the dependencies added as we go. For our end users, we already documented that missing modules are to be expected and how to resolve it. As said by other devs here, I also think it'd be more effective if you just do the change yourself. USE=selinux doesn't affect anything else so it's safe. Ok, no problem. I'll check on IRC regardless, if not just to give a heads up on changes. Also, my apologies for not sorting the list. Careful readers will notice it is sorted, but by the package name, not category :/ Thanks you all for the feedback! Wkr, Sven Vermeulen
[gentoo-dev] We need *you* for a USE=selinux dependency
Hi guys 'n gals obligatory tl;dr: Please check your package below this list and see if it (the package) has a proper DEPEND and RDEPEND on the listed sec-policy/selinux-module package(s) Within the Gentoo Hardened project, we are working on getting the SELinux support into shape. Recent evolutions are the stabilization of latest upstream userspace utilities and policies as well as documentation improvements and even some human resource improvements (read: fresh blood in our ranks). Within SELinux, specific modules are used (called SELinux modules, because we are not that creative in our naming) that contain the SELinux policy (what is allowed) as well as labeling information for files (which we call file context information). This labeling is very important in order for the policies to work well - wrong labels will lead to applications running with wrong permissions (which usually means Application No Workie). In Gentoo, unlike some other distributions, we try to keep the number of loaded/installed modules to a minimum so that policy rebuilds as well as the system overhead is limited. This results in a base policy (provided by selinux-base-policy) and modules (provided by sec-policy/selinux-modulename). To make sure that installations of a package pull in the right SELinux module, the proper dependencies must be defined. In the list below you will find package dependency information. This means that the given package should have both DEPEND and RDEPEND on the dependency (which is always of the form sec-policy/selinux-modulename since dependencies on sec-policy/selinux-base-policy are always satisfied the moment a user has SELinux enabled on his Gentoo system). The dependency should be USE=selinux-triggered (the selinux USE flag is masked for non-SELinux profiles and mandatory on SELinux systems), like so: IUSE=selinux DEPEND=selinux? ( sec-policy/selinux-modulename ) RDEPEND=selinux? ( sec-policy/selinux-modulename ) The dependency must be on both levels, because the SELinux module must be installed before the package is installed (and in theory, RDEPEND could trigger an installation afterwards): during the installation phase, Portage labels the files on the system (which would get wrong labels if the module isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package support requirements. Since there are quite a few packages that would need updates, I thought about first mailing gentoo-dev for feedback and perhaps a first chunk of work done. I also wouldn't mind creating bugreports for each of them, but that would still be best done after having mailed gentoo-dev ;-) Wkr, Sven Vermeulen [1] I am aware that Portage currently installs RDEPEND before the package itself, but that might change in the future and other package managers might exhibit different behavior. games-board/aisleriot sec-policy/selinux-games sys-apps/apmd sec-policy/selinux-apm net-dns/bind sec-policy/selinux-bind net-wireless/bluez sec-policy/selinux-bluetooth app-i18n/canna sec-policy/selinux-canna app-cdr/cdrkit sec-policy/selinux-cdrecord app-cdr/cdrtools sec-policy/selinux-cdrecord app-antivirus/clamav sec-policy/selinux-clamav net-im/climm sec-policy/selinux-games mail-mta/courier sec-policy/selinux-courier net-print/cups sec-policy/selinux-lpd dev-vcs/cvs sec-policy/selinux-cvs sys-process/daemontools sec-policy/selinux-daemontools sys-process/daemontools-encore sec-policy/selinux-daemontools mail-filter/dcc sec-policy/selinux-dcc app-admin/denyhosts sec-policy/selinux-denyhosts sys-devel/distcc sec-policy/selinux-distcc net-dns/djbdns sec-policy/selinux-djbdns app-arch/dpkg sec-policy/selinux-dpkg app-cdr/dvd+rw-tools sec-policy/selinux-cdrecord www-client/epiphany sec-policy/selinux-mozilla x11-misc/expocity sec-policy/selinux-wm net-analyzer/fail2ban sec-policy/selinux-fail2ban app-arch/fastjar sec-policy/selinux-java net-mail/fetchmail sec-policy/selinux-fetchmail www-client/firefox-bin sec-policy/selinux-mozilla dev-java/gcj-jdk sec-policy/selinux-java dev-vcs/gitolite sec-policy/selinux-gitosis dev-vcs/gitolite-gentoo sec-policy/selinux-gitosis dev-vcs/gitosis sec-policy/selinux-gitosis dev-vcs/gitosis-gentoo sec-policy/selinux-gitosis virtual/gnat sec-policy/selinux-ada gnome-base/gnome-applets sec-policy/selinux-cpufreqselector gnome-extra/gnome-games sec-policy/selinux-games gnome-base/gnome-shell sec-policy/selinux-wm app-crypt/gnupg sec-policy/selinux-gpg www-servers/gorg sec-policy/selinux-gorg gpe-base/gpe-dm sec-policy/selinux-xserver net-print/hplip sec-policy/selinux-cups x11-apps/iceauth sec-policy/selinux-xserver net-misc/icecast sec-policy/selinux-icecast net-nntp/inn sec-policy/selinux-inn kde-base/katomic sec-policy/selinux-games kde-base/kbattleship sec-policy/selinux-games sys-apps/kbd sec-policy/selinux-loadkeys kde-base/kblackbox sec-policy/selinux-games kde-base/kbounce sec-policy/selinux-games kde-base/kgoldrunner sec-policy
Re: [gentoo-dev] supporting /usr on separate partition
On Mon, Oct 17, 2011 at 01:50:04PM -0400, Ian Stakenvicius wrote: If someone wants to take on the burden of maintaining an init wrapper like that, then I guess that's fine. However, I wouldn't consider it to be an absolute requirement. I think it would be fine (maybe preferable) to simply provide a doc that describes how to mount /usr via an initramfs or linuxrc init wrapper. Such a doc would only be needed by those users who require that /usr be on a separate partition. This makes sense. So the Handbook could be updated with a caveat after the large partition example to say something like /usr on it's own partition needs special consideration, please see X ... this$ works. (Ian, it's a general reply, not specific to your e-mail) I've updated the Gentoo Handbook just a few moments ago to mention something like this in the introduction of the partition section How Many and How Big: --Snippet from the commit result: p However, multiple partitions have disadvantages as well. If not configured properly, you will have a system with lots of free space on one partition and none on another. Another nuisance is that separate partitions - especially for important mountpoints like path/usr/path or path/var/path - often require the administrator to boot with an initramfs to mount the partition before other boot scripts start. This isn't always the case though, so YMMV. /p p There is also a 15-partition limit for SCSI and SATA unless you use GPT labels. /p --End Snippet Now, I must say I find it strange that people think that the Gentoo Handbook suggests users to use a separate /usr partition. It does not. The default partitioning that we use is a separate /boot (yes, this can and has been debated in the past, I'm not going to change this) and / with a separate swap partition. Nothing more, nothing less. There are a few code listings where an example output is given which holds a separate /usr but I hope all those listings are clear that they are examples. It also states that this is an example we use in the Gentoo Handbook and that it depends on the user how he wants his partition scheme layed out. I'm hoping that the above update clarifies this sufficiently so that huge threads like this one don't need to reappear again ;-) If you think it is still unclear or needs improvements left or right, don't hesitate to mail me or, even better, file a bugreport (I act better on bug reports than on e-mails). Oh, and I use a separate /usr with no initramfs (yet), with software raid and lvm2. /me quickly hides Wkr, Sven Vermeulen
[gentoo-dev] GCC upgrades, FUD and gentoo documentation
Hi guys There is some FUD regarding GCC upgrades and I don't have the proper knowledge to write a correct document on GCC upgrades. As you are currently aware, we have a GCC upgrade guide [1], but it has seen its last update in 2008. Since then, things have undoubtedly changed. What I can find on GCC upgrades and their apparent need (or no-need) for rebuilding stuff: - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds from that version onwards should not be needed - The fix_libtool_files.sh command is now part of the toolchain eclass, so doesn't need to be ran by users anymore The only thing I fail to find out is why libtool needs to be rebuild (if it still needs to be). There are some sources telling it always needs to be rebuild (RedHat seems to fix the two togather at all times: gcc and libtool), others state that this is similar towards the C++ ABI, so not needed anymore since 3.4.0/4.1.0. I revamped the GCC Upgrade guide [2] with what I think is correct nowadays, but this is, to be honest, a bit out of my league. That's why I'm asking you, development community at large, to give some feedback on this, allowing the GDP to get rid of the FUD once and for all ;-) Wkr, Sven Vermeulen [1] http://www.gentoo.org/doc/en/gcc-upgrading.xml [2] http://dev.gentoo.org/~swift/docs/previews/gcc-upgrading.xml
[gentoo-dev] Last rites: sec-policy/selinux-mta (SELinux profiles)
Hi all, For those using one of the SELinux profiles, sec-policy/selinux-mta will be masked/removed as its policy is already part of selinux-base-policy (and as such gives conflicts, cfr bug #384851). Other people won't notice this as the package is already masked by default. Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Tue, Aug 16, 2011 at 09:22:30AM -0500, Dale wrote: Thanks for the reply. I also agree that the docs should be ready first then the change. I have a friend that may be switching from Gentoo because he can not get good docs on how to get his network working after the OpenRC update. It appears the docs he needs aren't ready yet. What's the point of having a nice Gentoo install if you can't set up your network stuff? I know, major apologies... The documents (more specific, the Gentoo Handbook and a few other high-profile ones) have been updated recently (last few days) so they should be okay now. However, some good reviews never hurt. If you do still find issues, don't hesitate to create a bugreport for it. Wkr, Sven Vermeulen
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. It looks like the situation where we will have to have one is if /usr and /var are not on the same file system as /, because of how udev has evolved. This isn't always true. I have /usr and /var on separate logical volumes (and as such, separate file systems) yet I don't use DEVTMPFS nor an initrd/initramfs, so I'm sure that the answer is a bit more specific. Wkr, Sven Vermeulen
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 08:25:19AM -0500, Matthew Summers wrote: This, at least to me, seems like an excellent opportunity to nicely document what can be done with an initramfs (in basic and advanced forms, as there are some really fancy things one can do with initramfs's), and how Gentoo is recommending their usage in the cases outlined by Robin and others. I'm all in favor of documenting what an initramfs does (or at least what it is supposed to do), how it works, how to create one, how to debug issues while booting with one, etc. That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? Also, how well does this play with all our profiles (so not only the popular architectures)? What about SELinux and/or grSecurity's RBAC model? Are these supported throughout the initramfs? Wkr, Sven Vermeulen
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Thu, Aug 04, 2011 at 09:31:07AM -0500, William Hubbs wrote: Add another to the list of folks who disagree with this and with the approach being taken. I don't blame gentoo devs per se, but I do feel like this is being forced down everyone's throats without any regard to the *nix philosophy of having separate /usr which has worked for years, and if people would fix their bugs correctly would continue to work. Same here. I do consider the situation to be a bug and, even if the damage is already done, it doesn't mean we should help with debolishing what is left. If anything, we should make it clear to users when and why an initramfs is needed. Saying because you have a /usr on a separate file system is not only a lie, it also covers the truth beneath it. Rather, why not identify in which situation(s) you will need an initramfs and work from there? I personally have /usr on a separate partition too (using LVM) without an initramfs or initrd. Works just fine. And I'd like to keep it that way, since it is simple and very manageable. Wkr, Sven Vermeulen
Re: [gentoo-dev] License Interpretation
On Wed, Aug 20, 2008 at 9:10 PM, Jim Ramsay [EMAIL PROTECTED] wrote: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software except to the extent you may be expressly permitted to decompile under applicable law, it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. I *think* I would be okay using this binary patch since: 1) This is specifically to make it operable with libcurl.so.4 2) I have (and others have) asked Adobe to recompile it with support for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or responded to any of these requests, as far as I am aware). Actually (and I'm no lawyer either), I think a binary patch isn't allowed: You may not modify, adapt, translate or create derivative works based upon the Software. The rest of the paragraph is about obtaining (or trying to obtain) its source code or application behavior, i.e. learn the program, not modify it. Wkr, Sven Vermeulen
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 27, 2007 11:40 PM, Doug Klima [EMAIL PROTECTED] wrote: [... EAPI is stuff PM supports/exports to the ebuild ...] Logical and proper to me. Actually, when I'm asked what EAPI is, I just say EAPI is a standard definition for the ebuild structure, implying supporting features from the package manager. Most of the time, the user is happy with the answer ;-) Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Good-bye
On Nov 24, 2007 6:39 PM, Seemant Kulleen [EMAIL PROTECTED] wrote: The time has finally come for me to resign from Gentoo. I've been meaning to do it for many months now, but the logistics took a little bit of time. Seemant Good luck with your future endeavors. If you ever come over to Belgium, be sure to contact me so I can guide you around a bit and we can have a nice talk with some good beers ;-) It seems like Gentoo is undergoing a generation switch - many of the elderly are taking on less responsibilities (or even retire) to give place to the energetic new developers ;-) Anyway, have fun and we'll sure see you around! Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] jmbsvicetto is now Sparc AT Subproject Lead
On 10/18/07, Ferris McCormick [EMAIL PROTECTED] wrote: I'm pleased to announce that Jorge Manual B S Vicetto [EMAIL PROTECTED] has taken the lead of the Sparc AT (Architecture Testers) subproject. As you know, Jorge has been a member of the Sparc AT subproject from its beginning, and he was willing to become its lead when I begged him to do so. Please give him the usual Gentoo words of encouragement for which we are so well known. My condolences to Jorge... Or isn't that the encouragement you were looking for? *g* Hit the bug(ger)s! Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Staff Developer: Maarten Bressers (mbres)
On 8/28/07, Hans de Graaff [EMAIL PROTECTED] wrote: I can confirm that Boxtel is in the Netherlands. And it's next to one of my favorite nature reserves in the Netherlands: De Kampina. Recommended for some hiking. Mo milk (Sais larry who doesn't distinguish between K and C). Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New (old) Developer: Dimitry Brad (diox)
On 7/29/07, Christian Heim [EMAIL PROTECTED] wrote: It's my pleasure to (re)-introduce to you Dimitry Brad (also known as diox on IRC), our latest addition joining the x86 arch monkeys. Dimitry has been a Gentoo Developer for quite some time (it has been nearly a year now), and he finally sent in his ebuild quiz and thus becoming a full-fledged Ebuild developer. So please welcome Dimitry as a new (old) fellow developer among us ! Even though diox is short, I'd like to propose a nickchange to O2 to save some expensive bytes. But for the rest: always welcome Dimitry ! ;-) Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Linking to Gentoo-wiki from www.gentoo.org
Andrew Ross said: http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=1chap=6#doc_chap2 (Yes, it's only a draft, but it still meets your criteria) It is in a section describing where to find information, more particularly about Massive collaboration guides and states There is an unofficial Gentoo Wiki filled with guides written by several hundreds of users. I'm sure this can't be wrong... Wkr, Sven Vermeulen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] The Gentoo Project proudly presents *drums* anigel *applaud*
Yes indeed my best audience, Gentoo now has a new developer in town. His name? Not important. His function? Not important either. His looks? Ugly as hell... why we want him? Because I am fond of french wifes, and he has one. Yes indeed my best audience, anigel is a Frenchie, a Limougeaud to be exact (which is an inhabitant of Limoges, the préfecture of the Haute-Vienne département). Stupefied? I know I am. And not only does he have a wife, he also has dinner for vapier - a beautiful young cat. Yes indeed my best audience, he is an animal lover. Fits right in. Jforman has another goatsitter and this one wont drive to jforman's house. No, he'll ride his bike to it. Yes indeed, my best audience, anigel seems to have a good condition. While most of us have long saluted their bike before they turned 26, anigel still loves to cycle through the woods, or just walking, looking for mushrooms. Err, wait a minute! Mushrooms !?! Aaarghh, what kind of freak did I introduce here? Another one for the pile of nuts in which we can find seemant, g2boojum and dsd. So now the nut pile has been extended with Hubert Mercier, a French Forum Administrator who in real life administers Unix systems. At least there's one sane property on this guy - he doesn't like the Perl language. And for that alone I disregard his mushroom incident... as long as he doesn't think he sees Larry fly. Sven Vermeulen -- The Gentoo Projecthttp://www.gentoo.org pgpsWIpsgWCL1.pgp Description: PGP signature
Re: [gentoo-dev] The Gentoo Project proudly presents *drums* anigel *applaud*
On Mon, Sep 04, 2006 at 09:43:23AM -0400, Michael Cummings wrote: Sven Vermeulen wrote: At least there's one sane property on this guy - he doesn't like the Perl language. And for that alone I disregard his mushroom incident... as long as he doesn't think he sees Larry fly. Bah. Can't believe I read through all that to get insulted. So you consider yourself sane huh? -- The Gentoo Projecthttp://www.gentoo.org pgpPsrYOI7Qlj.pgp Description: PGP signature
[gentoo-dev] I'm frilled to present to you, a new Gentoo developer
... which brings the German Conspiracy at 38. His nick is frilled, but in real life you'll call him Giesen, Wolf Giesen. Shaken, not stirred. And you'll call him that in the IT department of Aschendorff Medien, publisher of the Westfälische Nachrichten, whatever that is. You're probably all wondering what he's good at. He likes animals, so might make a good nanny for jforman's goats. And if klieber trained them well during the holidays, frilled will not need a dog to shepHerd them. Which is good, actually, 'cause he isn't all that fond of dogs anyway. Sorry beandog, no cookies for you. He's good in languages too. German and English are two of them, C is another good one. More evil languages he speaks are C++, Perl, PHP and ba(sh) not to speak of the Sum of All Fears, Java. But programming isn't really his thing. No, he's better in speaking in public if I may interprete Public Relations as such. Another journalist - we will all watch more security related articles in the GWN. If not, we'll drop Larry on him. Another animal he likes. Makes me wonder if the feeling is mutual. Oh, in Gentoo, he's going to work in the Security Team, so jaervosz has finally found himself another pet slave. Sorry Koon, you'll have to share Sune now. Will he show some tricks from the Ruhrgebiet, or rather from his current location - Münster? As you all might have guessed, he mentioned his first computer (TRS-80) in his introduction, but I wasn't impressed. The older their computer, the older their mind. Look paps, no hands! Anyway, he loves books and movies too - as well as a good beer. If you ever find the time, come over to Belgium and I'll show you what *real* beers are like. You get a good 'old welcome from me, Wolf. Welcome. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org The Gentoo Projecthttp://www.gentoo.org pgpP9qLCpUS0l.pgp Description: PGP signature
[gentoo-dev] GLEP ?? - Gentoo Knowledge Base
Hi folks I've just sent the GLEP to the GLEP editors so they can give it a nice number, but you'll find the text at http://dev.gentoo.org/~swift/tmp/kbase-glep.html as well. The GLEP covers the requirements I'd like to put on the Knowledge Base (KB). I didn't get much response on it on the gentoo-kbase mailinglist though, hopefully because everybody agrees (instead of laughing at it behind my back ;-) so I now present it to a larger community. I've also mailed the gentoo-kbase mailinglist with the next steps to complete: define an XML format for the KB topics (which is an *intermediate* format - definitely not the final one) and after that start creating lots of topics in that format. This is necessary because, if we want a good KB, we need to be able to test it well, so we need content. At the same time, we should start looking for possible existing technologies that we can use for the KB (we're all lazy). Each time a good candidate is found, we can put the topics in it and test it. For more discussion on this, please use the gentoo-kbase mailinglist. Wkr, Sven Vermeulen PS I've tried to get it on the gmane lists but apparently failed. I'll retry. -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpoiRKiWc1oW.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo Knowledge Base
On Wed, May 17, 2006 at 03:17:33PM +0200, Kristian Gavran wrote: Why reinvent the wheel?!? Gentoo has a really nice wiki: http://gentoo-wiki.com/Main_Page A wiki is more of a documentation system than a knowledge base. I think some KBs could very well employ a wiki as back-technology for writing the articles. But a KB is more strict in its writing: it can have a fixed layout (like title, synopsis, environment, analysis, solution [1]), allows for additional metadata (keywords, references to other articles, point-system per query, ...) and focuses more on its search technology than on the writing. Wkr, Sven Vermeulen [1] This is actually what I had in mind for the Gentoo KB -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpWF5fj80AZY.pgp Description: PGP signature
[gentoo-dev] RFC - Gentoo Knowledge Base
Hi all, For some time now, the idea of a Gentoo Knowledge Base, like RedHat [1] and Microsoft [2] do, has been brewing in Andrés Pereira and my minds. Not only that, but a feature request was also filed some time ago [3] and just recently a forum thread was started for it [4]. So, what is this about? A Knowledge Base provides answers to specific questions and problems that users (or developers) might encounter. It is easily searchable and maintained by developers who are knowledgeable in the topic. The knowledge base entries (topics as I like to call them) are not documentation guides, but very specific to a particular environment and question. They should leave absolutely *no* room for different interpretations. I have started a project site for this at http://www.gentoo.org/proj/en/kbase. A mailinglist has been created and will hopefully start a nice discussion about this topic. The mailinglist is [EMAIL PROTECTED] afaik. Once we have a nice idea about where we want to go (sic), a GLEP will probably follow for those who don't want to follow the mailinglist but do want to know what we will be/are doing. Wkr, Sven Vermeulen [1] http://kb.redhat.com [2] http://support.microsoft.com [3] https://bugs.gentoo.org/show_bug.cgi?id=102200 [4] http://forums.gentoo.org/viewtopic-t-462377.html -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpjNisgV7ilQ.pgp Description: PGP signature
[gentoo-dev] Council meeting logs for 2006-05-11
The meeting logs and summary for today's meeting have been committed to the Council Project page (http://www.gentoo.org/proj/en/council) and are readily available. Summary: In today's meeting, the QA-team GLEP (48) was brought into the field. The GLEP discusses the role of the QA team and its powers and was accepted by the gentoo-dev participants with little to no objections. The council therefore had only a few questions (can a single QA member act - yes, does it only work on the tree or on documentation too - tree currently) and accepted the GLEP for execution by 5 votes and 1 abstained. Like I said on the meeting, I need coffee, so please forgive any spelling and grammar mistakes made. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpiVV1us0T96.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Chris Gianelloni said: Really, I think that the number of bugs the GDP gets is probably fairly minimal for project-based documentation. Perhaps we could have something added to the project dtd that adds a little blurb at the bottom to file bugs for project documentation against the project itself? I really don't know if that would help or not, but it is an idea. The amount of bugs isn't the problem, but it does serve as a warning event to show the user how fragmented a project goal can be. In this case, not even all documentation is handled by the documentation team. Wkr, Sven Vermeulen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
On Sun, Jan 08, 2006 at 06:45:01PM +, Luis Medinas wrote: We could start a public wiki displaying all herds and projects. It would be great to add some low level docs, herds/project goals, ideas and so. Even the users could be allowed to edit and share information. I would personally welcome additional documentation, but if we're going to add an official Wiki for Gentoo, we're basically splitting the documentation development on many sides. What used to be a (forced) monopoly for GuideXML becomes a set of GuideXML, RST and Wiki. Although I have indeed read that the goal of the documents differ, we are placing a boundary on what GDP should do and shouldn't. We have already received many bugs for documentation in /proj/* which is not GDPs. I had no issue with this as I hoped this would be a transient state where the documentation is eventually handed over to the GDP so that both the project /and/ GDP can further maintain the documents. A wiki is nice, but don't forget that it only allows for online documentation editing. I am one of those devs who develops his documentation mostly off-line. There is also no quality assurance over a wiki and not that many wikis have decent versioning tools (or they have them but they're really awkward to use). The Java team already uses the gentoo-wiki.com infrastructure, indeed an unofficial wiki for official documentation. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgp9i29yzFCoL.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Mon, Jan 02, 2006 at 12:14:05PM -0600, Lance Albertson wrote: Since the council is the closest representation to a leader we have, I'd like to ask if they can come up with some kind of global goals for 2006 and beyond. I couldn't agree more, yet I'm afraid Gentoo has grown too large to do this efficiently. Many ideas are easily marked as WONTFIX (due to resource restrictions), CANTFIX (since it would mean a rewrite of Portage) or WORKSFORME (when /your/ way works). And when a proposal makes it to the mailinglist, only a small number of developers is interested in participating. The majority doesn't care, and a vocal minority tries everything in its power to prevent the project from succeeding. What could Gentoo bring out as a global goal for 2006 which isn't part of a single Gentoo project? Things like Have an automated installer (Installer Project), Document enterprise usage of Gentoo (Documentation Team), Port Gentoo to ReactOS (Gentoo/ALT), Introduce signing of all Portage Tree files (Portage Team), ... are all great accomplishments if they succeed (note: some of the above are hypothetical, in case you are wondering :) but only span one project. In my opinion, all projects should bring out global goals for themselves. The Gentoo Global Goals for 2006 would then be an overview of those goals. Yet the Gentoo Council doesn't bring any input here. There are some interesting ideas on the Gentoo Forums that aren't situated in any of the current projects, such as Top-100 Feature Requests [1], Gentoo Binary profile [2], Gentoo Knowledge Base [3], USE-flag triggered software installation [4], etc. Wkr, Sven Vermeulen [1] A site where the community can vote (one vote per bugzilla account?) on feature requests (or bugs), could be integrated in bugzilla if that's possible, but can also be a separate site where the feature request is formed dynamically (wiki?) or by discussion (forum). [2] A profile that freezes CFLAGS/CXXFLAGS/CHOST/USE/... and uses a build server to build binary packages for that binary-package profile. The project should not focus on the end result itself but rather on how all this is accomplished using Gentoo and how companies and organisations can easily implement a similar environment [3] Something like Microsoft's KB where common issues are well explained, resolutions documented and where a good search mechanism is in place to help find the right solution. Would require moderation so that solutions are correct. Could provide dual solutions: one community-written (open wiki), one developers accepted (moderated wiki). [4] Setting a USE flag triggers the installation of some recommended software so that novices don't need to search for the right software. Fex: USE=kde cdr - kde-meta + k3b -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgp1ZnN3wBD2G.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Tue, Jan 03, 2006 at 06:21:39PM +0100, Sven Vermeulen wrote: There are some interesting ideas on the Gentoo Forums that aren't situated in any of the current projects, such as Top-100 Feature Requests [1], Gentoo Binary profile [2], Gentoo Knowledge Base [3], USE-flag triggered software installation [4], etc. [...] (Sorry, pressed send too soon). However, having such proposals is great, but they need to be worked out by one or more users and formed into a GLEP. Such GLEPs can then be discussed on the mailinglist and sent for approval to the Gentoo Council. Now this is where the Gentoo Council comes in: its role is to /advise/ Gentoo's development, not regulate. If GLEPs come occasionally, there is barely any reason not to positively advise to implement GLEP. After all, if there are issues with it they would either be broken down during the mailinglist discussions, or they are broken down when the teams themselves refuse to implement them. When several GLEPs require (immediate) attention, the Council will try to advise where the priorities should be placed (which GLEP goes first). When several GLEPs interfere with each other, the Council will try to advise which GLEP is most beneficial for Gentoo and its community. Some people hope to see the Council as a regulating body. Forget it, developers are the brains that lead Gentoo's evolution, voluntary work is the blood that keeps Gentoo rolling, the community is the heart for which we all work. As such, there is no single regulating body. And as much as I hope to see a select few bring bright ideas, coördinate projects and make everyone's work easier, I have seen too many attempts that kill bright ideas to know far from everyone would be happy with such a situation. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpcsHpspmPGL.pgp Description: PGP signature
Re: [gentoo-dev] December Council Meeting
On Thu, Dec 08, 2005 at 01:56:37AM +0100, Marius Mauch wrote: current agenda: decision on multi-hash for Manifest1 You mean the Manifest2 GLEP, or did I miss something? Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpe2leFpMc62.pgp Description: PGP signature
Re: [gentoo-dev] New Dev: Marien Zwart (marienz)
On Wed, Nov 23, 2005 at 09:51:25AM -0600, Brian Harring wrote: Please welcome Marien Zwart, aka marienz to the crew. He's joining up as a python monkey, working on twisted (2.x stable ebuilds anyone? ^.^), portage 3 hacking, and pretty much anything python wise. Finally, he's been helping out in #gentoo for quite some time. [...] Hey I know that lurker from #gentoo... Welcome aboard! -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpYhfsy1lxIh.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 06:05:53PM +, Ciaran McCreesh wrote: Afaicr, the infinity sign will be kept, but I know a huge discussion will be held on this. It's not important in this stage of the development though... And now we're told that it *was* important at that stage and it's too late to change things? Riiight. I said that in that stage of the redesign development the logo discussion shouldn't be held as it is part of the design the infinity sign will be kept but that we leave it open for discussion if enough shoulders are put under it (huge discussion). The primary concern at that stage of the development was to continue to develop the design/XSL so that we have something workable when we offer the design to the public... which is now. Like I said before, I rather like the infinity sign. The trustees have had a discussion on this part too. Their decision was that we need a strong, compelling case for not using it since it is something the community has voted on. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgphvGhgBwF9d.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, Nov 23, 2005 at 10:24:55AM +0100, Paul de Vrieze wrote: Most people that complain are probably misinformed about the usefulness of stages 1 and 2. They are really only useful if you know what you're doing and don't really need the handbook that much. Those users should be able to find the alternative installation docs. I do agree however that there should be some link to the relevant documentation from the handbook. Actually the migration process did all that in one step: - Update the Handbook . Remove stage1/2 instructions . Add a /couple/ of references to the Gentoo FAQ - Update the Gentoo FAQ - Update the Gentoo Handbook FAQ Perhaps I should use the blink.../blink tags more often. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpQD9X7xowdh.pgp Description: PGP signature
Re: [gentoo-dev] opinion on how to improve the website redesign
On Tue, Nov 22, 2005 at 03:53:22AM +0100, Thomas de Grenier de Latour wrote: A good start could be to do that the quick and ugly way, thanks to Google (with some site:www.gentoo.org/some/thing/ and other black magic in the query terms). [...] Two major obstacles are - Google bases its search functionality on cached pages. I would assume that most people use the search functionality to find documentation which gets updated quite a lot. Google might offer outdated links or forget to point to a valuable resource - We would depend on Google a bit Now Google might be a reliable web site/service, I'd rather have the search functionality of our web site implemented on the Gentoo infrastructure. I would even hope that we can have some tweaking possibilities in our search functionality, such as: - Restricting pages to /doc (documentation), /main (Gentoo information), /news (News items+GWN), /proj (project stuff) - Restricting languages (en, fr, ... and any combination) - Have the search points assigned so that hits are calculated with certain weights: * title's get most of the points, unless many titles are selected * abstract's get the second most points, yada yada * content get third most points Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpI9eelB4DCs.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
On Sat, Nov 19, 2005 at 05:06:15PM +, Kurt Lieber wrote: Now, the same question for email -- how do we manage aliases, especially for inactive, retired and semi-retired arch testers? We could track usage in logs, but between mailing list subscriptions, bugzilla notifications and all sorts of other automated emails, that's not an accurate representation of whether an email alias is actively used or not. Isn't this an issue that also exists for the Gentoo developers in general? Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpJHv7uUeo5P.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Fri, Nov 18, 2005 at 09:09:29PM -0400, Luis F. Araujo wrote: What is the problem of giving them @g.o addresses? Why exactly do we need the distinction? (sorry, i can't see any benefit but more confusion). The GLEP was originally created to help the architecture testers with a specific privilege: read-only CVS access. This would allow them to improve the quality of the ebuilds sooner, help the architecture teams identify working (and perhaps even more important, not-working) tools and perform tests on the global system to make sure the distribution is in top-notch shape. The e-mail address was not that important, but was decided to bring it in the package because it would be some sort of appreciation to those users. One general idea was that arch testers wouldn't be developers because they have no formal obligation to the Gentoo project: we don't expect them to put in x hours a week in Gentoo, read the gentoo-core and -dev mailinglists or even catch up with most of the events that happen in Gentoo (like GLEPs and such). This is also a request from the arch testers, because many of them *can't* devote much time to Gentoo anyway. That sentiment is reflected in using a subdomain address, and from what we heard no tester had any problems with this (the e-mail addy is far less important than the rest of the GLEP). There was never an idea of marking one type of developer different from another (this was in fact specifically rejected in the first meeting) but rather giving non-developers some appreciation. Perhaps the proposed appreciation is misplaced - fine, if that is the sentiment, we'll try to get a better one. One (important) part of the GLEP is the request that the arch tester has passed the Staff Quiz and that a probation period should be passed before read-only CVS access is given. I'm personally wondering how close this comes to becoming a real developer (which, iirc, is something the trustees should be called upon as the Foundation should keep track of what defines a Gentoo Developer, as developers have voting rights on the Foundation board). As I said before, the arch testers themselves aren't asking for being a developer but rather for additional tools to help them do their work. I've said it in the first meeting and I'll reiterate: what is the sentiment of the arch testers in this case (if they are still reading this thread)? Wkr, Sven Vermeulen PS I would be quite surprised if there is *one* arch tester who feels good with this entire thread; it doesn't show of much appreciation between people. There is a huge difference between saying that a group has made an unfortunate decision or did not grasp the essence of the proposal and situation needed to make a good decision, and abuse of powers. PPS http://www.amazon.com/gp/product/0670883395/002-5294388-6434402?v=glancen=283155s=booksv=glance -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpNhQkaIMAU5.pgp Description: PGP signature
[gentoo-dev] Departure of Broeman and Aaby
With a sad heart I must announce that Jesper broeman Brodersen and Arne aaby Mejholm are leaving the Gentoo Documentation Team as the Danish translation lead/follow-up. They have made the Danish translations quite active (the /doc/da/ counts 109 translated documents) and I thank them for that. Time is no-one's friend, you'll always find that you can't find any spare hours in your back pocket. I wish them the best and they're of course always welcome for a quick chat. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpFExXRrgmv4.pgp Description: PGP signature
Re: [gentoo-dev] Getting Important Updates To Users
On Sun, Oct 30, 2005 at 04:52:39PM +0100, Thierry Carrez wrote: The reason why the front page and the gentoo-announce ML (the two official media for Gentoo - users information) are under-used is that approximately 5% of the developers know how to post to them. We should probably make them more open (with a moderation system to check message), then they will be used more. But there is no such system available yet. It is a single commit that gets transferred to the web site, no moderation possible. Doesn't mean that it shouldn't be done though. Wkr, Sven Vermeulen PS. If you want something posted in the current system, ping infra or mail [EMAIL PROTECTED] or [EMAIL PROTECTED] with the news item and it should get posted. I know, not the best track, but that's the current system. -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpMgLUTtoZx7.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting Thursday October 13th
On Tue, Oct 11, 2005 at 05:10:28PM -0400, Chris Gianelloni wrote: If the latter: hump the baselayout team. What does baselayout have to do with this? They're to blame for about everything. Nah, my bad. Of course I meant those responsible for the profiles. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpSqE4uNuFJ5.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting Thursday October 13th
On Mon, Oct 10, 2005 at 09:00:57AM -0400, Chris Gianelloni wrote: I'd like to see the council fight it out over^W^W^W^Wdiscuss which logger should be the default. *lol* That gave me a good laugh. Oh well, anyway. What's default? As in recommended by the documentation? Or installed as dependency of virtual/logger? If the former: hump the GDP. If the latter: hump the baselayout team. If both, try humping one of them at a time. Doing both just makes funny pictures, but doesn't give much results. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgporuI011pZB.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Classes, a possible new method of spreading information
On Sat, Oct 08, 2005 at 11:36:45AM -0600, Tres Melton wrote: I think that the best thing to do would be to put up a web page with some documentation or a topic outline and then schedule a QA on IRC and maybe in the forums too. There are a lot of topics that aren't documented that well. What we really need is to find what topics people are interested in learning more about. ... and document those. Welcome to the Gentoo Documentation Project. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpvEaTdYGnoi.pgp Description: PGP signature
Re: [gentoo-dev] Application server deployment eclass?
On Sun, Oct 02, 2005 at 03:07:23AM -0400, Dave Nebinger wrote: So how do I get my war file deployed? Am I left to external tools such as ant to manage that for me? How does such an entity fit within the portage world? Each J2EE server has its own method for deploying j2ee archives. I don't think it is easy to create one that supports them all (WebSphere, WebLogic, Oracle's, TomCat/JBoss, ...). And anyway, the idea behind such archives is that the deployment itself is tweaked to the environment itself - there is no way for a default works for all deployment method afaik. I personally use a Java tool that uses the JMX possibilities of the J2EE server (if it supports it) to deploy tools, but this is targetted on a personal environment and mainly used to 1. provide a sort-of default method for deploying archives on the environment (which uses a single brand of J2EE servers anyway) 2. automate the upgrading of archives to a new version Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgp3zvrS6Ghx5.pgp Description: PGP signature
Re: [gentoo-dev] default logger
On Tue, Sep 27, 2005 at 11:57:26AM -0500, Brian Harring wrote: Agreed. It should be syslog-ng. If nobody objects, I'll change it in base/virtuals. Objecting, obviously ;) [...] I'd rather see reasons listed as to why syslog-ng is a superior default for users who (most likely) don't care, then we lack /var/log/messages :) We've had metalog as the example log daemon in the Gentoo Handbook in the past. Every time it was added, we got a nice bug about why metalog was a bad default and syslog-ng should be used. I'm not on the I'net right now, but if you annotate the [gentoo]/xml/htdocs/doc/en/handbook/hb-install-tools.xml file you'll see a bunch of reasons over the past few changes. Afaik, most architectures prefer syslog-ng. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpm2AImqwnmg.pgp Description: PGP signature
Re: [gentoo-dev] FAQs for maintainer-wanted ebuilds
On Mon, Sep 12, 2005 at 05:55:42PM +0100, Ciaran McCreesh wrote: No. GuideXML URLs utterly suck. They're impossible to memorise and the second I changed anything every link would become invalid. But at least the layout is consistent, the location is official, concurrent development is possible and the resource is shared on multiple web nodes. Not to mention that GuideXML URLs don't suck and are a lot easier to remember. You just need to know the name of the document: http://www.gentoo.org/doc/en/document whereas with dev.g.o URLs, you have http://dev.gentoo.org/~user/path/document Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpnYiyWs4wJm.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Lukasz Damentko
On Fri, Sep 09, 2005 at 12:21:30AM +0200, Jan Kundrát wrote: internal GDP joke Is staking, poking out of the eyes and burning of hands considered a warm welcome? :-) /internal GDP joke Must have missed a few memo's. I thought only YoswinK was allowed to do this. Welcome on board, rane. Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpYDTsaaTFgO.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote: At the moment, the only way for a package maintainer to mark a package stable is to mark it stable on a real arch. Creating the maintainer arch solves this very problem. Yes, but please don't call it the maintainer arch. This will confuse our users and it'll be quite difficult to document. I would rather vote for a MAINTENANCE keyword, like the following example: MAINTENANCE=~x86 # Maintainer uses x86, package not deemed stable This provides two (wanted) inputs: stability and maintenance architecture. And it keeps backwards compatibility. Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpT9m5nSrswk.pgp Description: PGP signature
Re: [gentoo-dev] Devconference archives
On Mon, Aug 15, 2005 at 11:16:10AM +0200, Wernfried Haas wrote: That's very nice from IU for sure and especially if there are not many (read: one) options to choose from the outcome is pretty obvious. However, i'm not sure what our Social Contract says about it. It seems to deal with the operating system itself, but there seem to be no implications about anything else. So in theory we could host the whole www.gentoo.org stuff on IIS servers? Sure. The contract tells our users that we will never depend on non-free stuff, so the continuance of the distribution is guaranteed. But Gentoo can surely use propriatary products. Whether or not we want to is a different question. Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgp5Ev8262LeA.pgp Description: PGP signature
Re: [gentoo-dev] Food For Thought: Bugzilla Localization?
On Wed, Aug 03, 2005 at 04:17:38PM +0900, Chris White wrote:
1) Are there official gentoo i18n groups, and if so, do they have their own
bugzilla. If so, maybe we can link to them from the non-bugzilla site, and
the people their can transition non-english bugs over to standard bugzilla.
Nope (to your first question). We don't have a real i18n crew yet. It might
be a good idea for form one; we do have good support for i18n generally
(package maintainers are using the LINGUAS and the documentation has
references to locales and such) but an expertise group can probably improve
the distribution (for instance by adding the necessary man-pages-${LANG}
ebuilds, etc.).
2) Can people be brought on board to localize bugzilla, as well as provide
translation of non-english bugs.
I'm not in favor of having a non-English official bugzilla. To much
resources to put in it; I'd rather use translation teams to continuously
keep translating interesting stuff, like documentation but also help with
the localisation of Portage if that ever comes this far.
Translating bugs is such a waist of resources...
Wkr,
Sven Vermeulen
--
Documentation project leader - Gentoo Foundation Trustee
The Gentoo Projecthttp://www.gentoo.org
pgptTXX1bxyTO.pgp
Description: PGP signature
[gentoo-dev] New Developer: Michael Curtis Napier
After a long marathon of requests and quizzes, runner 972 has just crossed the finish. We had an exclusive interview with Michael Curtis Napier who likes to call himself curtis119 because his first 118 egos all failed miserably. Michael is an old rot in the ICT business (yo! guys! we have a nerd at the finish!), being born in the good 'old days in 1970. We would like to call him Sid Dabster but Illiad didn't want that. He has more than 10 years of experience in both UNIX (yaaay) and Windows (ny). To prove his nerdyness, he said he likes SciFi, Linux and Cisco. And there I thought Sisko was a character in Star Trek. Apparently, it is also a brand of coffee [1]. So far for the myth that Toledo inhabitants only drink Ice-Tea with milk. Curtis is one of the Forum Moderators and will be helping out Gentoo with the website redesign project and, hopefully in the not so far future, with documentation as well :) Please all give curtis119 some good Gentoo lovin' (except beejay, he can massage curtis119's feet instead). [1] http://www.ciscoscoffeeroasters.com.au/front_page.htm -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpQrO1SYviKh.pgp Description: PGP signature
Re: [gentoo-dev] KDE 3.4.1 keyworded stable on x86, amd64
On Fri, Jul 01, 2005 at 12:07:19AM +0300, Dan Armak wrote: If you're using monolithic ebuilds (this include all 3.3.x ebuilds) consider moving to the split ones: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml Don't forget to read the KDE Configuration HOWTO which also helps you a bit on choosing interesting KDE ebuilds: http://www.gentoo.org/doc/en/kde-config.xml Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpk6vONkXn81.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38 round two
On Wed, Jun 29, 2005 at 12:27:31AM +0100, Ricardo Loureiro wrote: Just a question, will there be a different group for moderators that belong to staff and moderators which doesn't belong? I'm asking this because users may relate different groups meaning official gentoo replies from gentoo staff and not official from other moderators, giving the idea of valid technical support from the gentoo staff moderators. There is no such thing as an official Gentoo reply. You can have replies from Gentoo developers, but no Gentoo reply. Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpsarpQ1BEwJ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Mon, Jun 27, 2005 at 02:22:09PM -0700, Michael Curtis Napier wrote: I have already taken the quiz in conjunction with another non-forum project. You are correct, it was easy. /me checks his archives ... after a couple of tries. =) -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpchVcrdssPb.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Matthias Schwarzott (zzam)
On Sat, Jun 18, 2005 at 09:03:09PM +0200, Benjamin Judas wrote: I'd like to welcome another potential member of the German Conspiracy, especially since he shares the same general taste for music as me. We're doomed -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpzgIzhrdbXl.pgp Description: PGP signature
Re: [gentoo-dev] Re: Removal of articles.xml from website
On Fri, Jun 10, 2005 at 08:54:49AM +0530, Shyam Mani wrote: That said, amybe we can can contact DW and ask for a permalink of sorts? Or if we could mirrior the article on our site? Any other solutions? I know from Daniel that DW takes the exclusive rights to publish the articles for the first X months (I believe it was 6 months, but don't take my word on it). We are allowed to republish those articles later (as we've done with for instance an article about CVS), even in the form of a GuideXML document. Perhaps we can add all articles to our own repository? If we put a note on top stating note This article was originally published at the IBM DeveloperWorks website. /note and we get the agreement of the authors we should be all right. Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpaxNzNn2bHW.pgp Description: PGP signature
[gentoo-dev] Re: Re: Removal of articles.xml from website
On Fri, Jun 10, 2005 at 11:39:57AM +0200, Sven Vermeulen wrote: I know from Daniel that DW takes the exclusive rights to publish the articles for the first X months (I believe it was 6 months, but don't take my word on it). We are allowed to republish those articles later (as we've done with for instance an article about CVS), even in the form of a GuideXML document. [...] Okay, just to be certain I dug up an old mail from Daniel explaining the IBM work. Apparently, they are: - written as work for hire - property of Tenco Media Corporation or Westtech Information Services - Daniel is however allowed to republish them as he sees fit after 6-9 months with no restrictions except clearly mentioning that the articles are property of beforementioned. In the mail he states that we can republish his articles on Gentoo as long as we put the following note in each document: The original version of this article was first published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux documentation team. So for Daniel's articles, this is no issue. However, we do need explicit approval for the other articles by the authors. I propose to start GuideXML'ifying Daniel's articles. I'll leave the details on the gentoo-doc mailinglist. If anyone sees his or her name on the articles page as being one of the other authors, mind contacting me with the approval (or disapproval) of republishing the articles (with or without modifications)? Wkr, Sven Vermeulen -- Documentation project leader - Gentoo Foundation Trustee The Gentoo Projecthttp://www.gentoo.org pgpl4hBUfg3gt.pgp Description: PGP signature
[gentoo-dev] GDP: Mid-year status update
Hi all, In the beginning of the year, I have posted the New Year Goals for the Gentoo Documentation Project [1], listing a few bigger topics we would like to address in this year. Now that we are half-way, I would like to inform you about the progress the GDP has made since then. For your reference, you can find the New Year Goals in the GDP Status Update, dated March 7th [2], but I will relist them here with information on their advancements. ** Pull in developers/contributors Before randomly starting to pull in users who want to join the GDP, we have crafted a guideline on how we recruit developers [3]. This guideline includes numbers on how we (Xavier and I) look at contributors before we deem them active enough to be part of the project. It also includes a Quiz that each contributor has to fill in succesfully. With this guideline in place, we have already invited a few contributors to join the GDP crew. Some of them are lead translators, non-x86 architectural documentation developers (MIPS, AMD64, PPC) and others are English Documentation Editors and reviewers. Others are in the pipeline for joining. We are however still looking for internal developers who want to join the GDP team to help their project deliver quality documentation. Internal, because they need to have a good knowledge of the project in their hands. This is however no hard-written rule: if you are known to the project but no Gentoo developer, that is of course good as well, but we do want the acknowledgement from the project. ** Reintroduce Status Updates Until this day I have not reintroduced status updates (the request on all documentation editors to submit personal status updates) since the team is currently working well (we have a good bug squashing rithm) and there is no direct need to duplicate what we already know of each other on the mailinglist. However, when the project would become too large to handle directly, indirect status updates will be introduced. But again, for the time being, this has not been found necessary. ** Improve documentation on GuideXML The idea here was to document the use of the various tags better (/why/ do we have an abstract tag, where is it used, etc.). With the Quiz in mind, this has been put back a bit as the Quiz directly asks each contributor for all this information. Putting it all in a single document would defeat the idea of the quiz a bit (since every body would be able to copy/paste everything). ** Writing Style documentation The entire Gentoo Documentation Repository is written by various individuals. This gives a cluttered idea on the writing style involved in the documents. We have not received any (negative) feedback about this, but we do feel that some common writing styles should be introduced. There is no proposal on a writing style yet, though, so see this as still being Planned. ** Define Location of Documentation Most projects put project-specific documentation on their project page. For the GDP, as long as this documentation does not affect the broad user base, this is just fine. Projects should know however that this documentation is less likely to be reviewed by the GDP or translated. Whenever a document can be of interest for a larger population, we feel that the document must reside under http://www.gentoo.org/doc/en, which is the GDPs play ground. Not only does this improve the quality of the documentation, but it also improves the visibility of the document to the wider audience. ** Audit the Existing Documentation Auditing is of course a work that's always in progress. We have recently decided to rewrite the ALSA Guide [4] as it was getting too cluttered with patches here and there to fix things that are obsoleted or renewed. Other documentation is being audited or worked on. If you find anything outdated or in need of an update, bug [5] us. ** More USE-case Documentation With USE-case documentation we mean documents that cover multiple subjects simultaneously. Documents such as the LDAP Howto [6], the UTF-8 Guide [7], Mailfilter Guide [8] and others are good examples. Such documents contain information that is more difficult to find elsewhere. However, we have seen that the community appreciates the configuration guides (Xorg, KDE, GNOME, fluxbox, ...) a lot as they are frequently referenced in #gentoo, on the mailinglists and on the Gentoo Forums, so the urge to go for USE-case documentation has decreased a bit in favor of the latter. If you have questions about other activities within the Gentoo Documentation Project, proposals or feedback, do not hesitate to reply or contact me personally at [EMAIL PROTECTED] or SwifT on irc.freenode.net. Wkr, Sven Vermeulen [1] http://www.gentoo.org/proj/en/gdp [2] http://www.gentoo.org/proj/en/gdp/status/status_20050307.xml [3] http://www.gentoo.org/proj/en/gdp/doc/doc
