Re: [gentoo-dev] Moving our/portage stuff to var
On Mon, 17 Dec 2012 11:19:20 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: Currently we put portage into /usr/portage and all related stuff is to be in the subfolders there (distfiles, binpkg). I've always myself override these defaults in make.conf to point for /var/portage/ (not /var/lib because I never bothered enough how to make world and config files to be put elsewhere :P). The only reason why we have this currently in usr is that bsd ports put their stuff in there and I suppose Daniel just did the same. With respect to reality how stuff is done in the linux land all the variable data should be in /var so we should adjust and move it in there too. What would you think? do it. stick it somewhere in /var. i have a small SLC SSD just for /var and /usr/portage partitions, since those consistently incur high writes. dropping to just one partition for all that i/o would be real nice. if this proposed change is made, please make sure to contact the GDP. while we don't update things like manpages or elog announcements, we would have a ton of stuff to fix in gentoo.org/doc/en/ . also, make sure stuff is sorted out on the catalyst/releng end well in advance, so users aren't stuck with bad stages. signature.asc Description: PGP signature
Re: [gentoo-dev] removing the server profiles...
On Wed, 16 Jan 2013 00:36:18 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Hi, several people have pointed out to me that the 10.0 - 13.0 transition would be a good moment to finally remove the (also in my opinion rather useless) server profiles. The easiest way to do this would be to * just not copy the server profiles from 10.0 to 13.0 and * have the deprecation warning for 10.0/server point to 13.0 (i.e. prompt users to upgrade from the 10.0 server profile to the 13.0 base profile). whenever the rest of the developers reach a consensus, please file a bug report to let the documentation team know what changes we need to make to the upgrade guide and other docs. thanks! signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: stabilization policies
On Aug 20, 2013, at 11:19 AM, William Hubbs willi...@gentoo.org wrote: My question is, how can we improve our stabilization procedures/policies so we can convince people not to run production servers on ~arch and keep the stable tree more up to date? do the Arch Linux thing…keep just one version of a package in the tree, as a general rule.
Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
On Fri, 02 Oct 2009 08:52:24 +0200 Rémi Cardona r...@gentoo.org wrote: Thanks for the wording, I've somewhat made it a bit stronger. @Dev, please ACK or NAK or whatever. Looks good to me. (Both as a dev and as a PR member.) signature.asc Description: PGP signature
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
On Sat, 03 Oct 2009 15:54:31 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: I have tried to bring up the issues on the docs team list but pretty much get shot down and told everything is fine and dandy. Going to have to call bullshit on this one. Who told you that on the lists? Have you *seen* *any* of the posts *I've* made? Take a look back at the list for the last, oh, year's worth of posts from me. We know there's stuff to do. There just aren't enough people. I do what I can, but I'm but one man. I personally would happily donate my time to working on the docs, if only it didn't involve a markup language nobody else uses. I suggested a closed wiki for official documentation, but was again shot down saying that the existing team (who seem to be doing nothing) would need to reskill and that the server admins dislike wikis. Who seem to be doing nothing. Thanks. Thanks for shitting all over my work for the last month/year/years. All the hours I spend each week (each day) even when I'm devaway maintaining docs in /doc/, /proj/, and our other www pages in /main/. Thanks for saying I do nothing. I know you're not aware of everything that's going on behind the scenes, but to make such a blanket statement is just uncalled for. I suggest you take a look at http://sources.gentoo.org/gentoo/xml/htdocs/ (doc/en/ and proj/en/) to see some commit history before making such an unkind statement. We're not totally dead. Not all of the team is inactive. I'm active. The translators are active. Our lead has been fielding the bugs as they come in. The problem with the English side of the docs is that I'm basically the only person doing anything. That means that while I can *sorta* keep up with the regular influx of non-handbook doc bugs, I can't do the entire handbook revamp on my own.* * Actually, I could, but some of the changes I have in mind are so far-reaching that I'd prefer not to go over the head of my team lead and instead stick to our existing policies rather than start breaking things left and right. signature.asc Description: PGP signature
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
On Sun, 04 Oct 2009 00:58:56 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: I have no intention of shitting all over anybodys work. My apologies if that was the interpretation. I'm simply escalating an issue I have raised before to somewhere I think it'll get more attention. I realize (now) it wasn't your intention. But that was how I took it. Just sayin'. Maybe you're not totally dead, but my criteria for activity has been the multiple bugs I've been sitting on and the number of times I'm having to tell new users the handbook is wrong, ignore it and follow my instructions in this case or oh dear! You seem to have installed a version of Portage so ancient that 99% of our package tree can't be installed (or words to that effect) - mostly to do with the lack of up-to-date handbooks, which as per my original post is now becoming a dire situation, in my opinion. It is pretty bad -- it's news to me that EAPI2 is causing installation issues. That's on top of the interesting outdated packages and blockers seen when updating from something as old as 2008. Problem is that there is no real quick fix for the handbooks, and there never was, even when the autobuilds were first introduced. It's not just a matter of changing version numbers. It's also the supporting text. It's also the variable infrastructure in our other handbooks that build the displayed text using a number of conditionals. Every file we have needs to be overhauled to match what should be a simple version change, because the autobuilds are very different. Give me two or three straight days that I devote 12 hours of work to the docs per day, and three GDP members who can work some or all of that time, and I can get the handbooks done in a weekend. It's doable, it just needs a large block of time, and more people besides me doing all the work. I've been doing solo handbook overhauls for the last several releases. It's not fun anymore. This is even more wide-reaching than that, since it involves core handbook design decisions that (I think) *require* getting my fellow team members and lead to review and consider. If the rest of the team is dead, why not escalate the issue to, say the -dev list. At least from what you've said in your most recent post you seem to think _something_ does need to be done about the current situation. This is an idea, but I don't know that it would accomplish much. I've chimed in on major package changes on the -dev list with a request for developers to talk with the GDP regarding related doc updates, but most of those kinds of requests go unanswered, or are answered very slowly. Usually I jump on IRC as it's more likely that I'll enlist help from my fellow developers there, in real time: two very recent examples are the Xfce and X11 teams helping me out with my questions regarding the guides for 'em, and some stuff on bugzilla. Something does need to be done about the number of active docs developers, and the number of non-GDP members contributing patches that I just need to commit with minimal review, thus acting as a commit proxy. But I can't *force* people to help out with the documentation -- that includes users and developers. Nor can I force our developers to have free time right when *I* need some answers WRT a doc. signature.asc Description: PGP signature
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
On Sat, 3 Oct 2009 20:45:21 +0300 Markos Chandras hwoar...@gentoo.org wrote: This is actually true. Maybe all devs should have access on docs since the docs teams are dead. I would suggest to let all developers contribute to documentation whether they belong to docs team or not No. Many (most?) devs do not write good documentation. Their native language may not be English. They don't know the coding style. They don't know how to write code that validates. They're not good at putting together step-by-step instructions with helpful, explanatory text. They don't know all the myriad documents that need editing to pick up the change made to one part of a different document. The GDP team is not dead, fer cryin' out loud. I just replied to Allen's message elsewhere in this same thread. As I said in that thread, you can't force people to write documentation, patches, or even a plain-text list of change foo to bar alterations. We still can't force developers to use repoman when they commit, or force developers to not break dependencies EVERY TIME they commit even with repoman. We can't force developers to contribute EVERY TIME they make a change to a package, or pick up upstream's changes. It'd be nice if we had a really integrated system for doing packages and docs at the same time, but it's not possible to make people do what you want them to do. signature.asc Description: PGP signature
[gentoo-dev] Updated handbooks for autobuilds
There. I did the x86 and amd64 handbooks (networked, anyway; who cares about networkless). They're now ready for the 10th anniversary. I'm pretty sure. I also did the x86 quickinstall handbooks. GDP, and interested devs who can contribute patches to Bugzilla: Please review all the files I touched and make those same kinds of changes to our other arch handbooks. Also, do review what I touched to make sure I didn't leave anything out, or that keyvals aren't showing empty space or wrong variables. Happy 10th anniversary. I'm off to celebrate Oktoberfest. Maybe I'll do some more work when I get back. * * * PS: Someone get that mother-$$#^^@#($-ing bugzilla back online and comment on the handbook autobuilds tracker bug with this status update. Bugzie is down for me, and I'm out of time and patience to deal with it. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Fri, 9 Oct 2009 19:57:07 +0200 Matthias Schwarzott z...@gentoo.org wrote: Hi there! As some of you have waited long for this to happen, sys-apps/openrc-0.5.1 is there. It has a default enabled (eapi-1) useflag oldnet to install the old-style network scripts called net.*. Regardless of this use-flag, the new init-script /etc/init.d/network is always installed. For transition to new-style network script there is something todo I think. Unordered list of todos: * hotplug? at least udev does explicitly call in net.* scripts * New systems should get old or new scripts? * does new scripts already can do all that was possible with net.* ? So far I hope the update does not break any system. In case this happens nevertheless open a bug as usual. Regards Matthias As long as this new version is ~arch (and not hardmasked), you also need to send some documentation updates for http://www.gentoo.org/doc/en/openrc-migration.xml; patches to bugs.gentoo.org, Documentation product. This way we in the GDP can take care of keeping the guide up-to-date. Thanks. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: package.use.stable.mask
On Sat, 10 Oct 2009 22:04:50 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Hi, lately I spoted that quite few packages have optional parts bit unstable (KDE parts, boinc [i wont stable it until the cuda is, i wont do the work explained bellow :)], kipi,...). I really don't like the shebang about doing -r1 and -r50 so we keep 2 revisions where one is stableable and second is not. So how about having this nice file (topic), it quite self-explainable by the name. Also syntax would be same as for package.use.mask and same goes for placement Don't take this too harshly, but doing it this way seems entirely bass-ackwards to me. Why not just do one of the following: 1. Stabilize the dependencies. Make 'em all the same level. I went through this the other from the other side when trying to get RedNotebook stabilized: I couldn't do so until pyyaml, one of its dependencies, had libyaml stabilized, since libyaml is an optional USE dependency for pyyaml. By forcing all three packages to be stable, *we prevented breakage to users' systems from the beginning.* No need to mess with complicated stable/unstable dependency relationships. 2. Don't mark the origin package stable in the first place! If its dependencies aren't stable, then you cannot in good conscience declare that the original package should be stable, and then let the dependencies sort themselves out . . . weeks or months down the line. Just let it *and* its deps remain in ~arch. What's so wrong with that? * * * Again, I really think it's bad QA and bad practice to mismatch stable packages with unstable dependencies. Please tell us why 1. and 2. don't work for you. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Wed, 14 Oct 2009 00:52:06 +0200 Dawid Węgliński c...@gentoo.org wrote: Upstream already provides such a documentation as you can see above. Gentoo provides migration guide. I believe doc team will update use flag description as soon as it's possible. In this case, As soon as it's possible means when someone sends a patch to bugzilla, because I don't know what the hell to do. And I'm the document maintainer. Take a look at the forums, folks -- there are a *lot* of threads on this major change. Things that should be simple and straightforward, are not really straightforward. Like the USE flag and reading its description in metadata.xml, or enabling it to get a working system. Right now, most of the reports are from users who for one reason or another don't have the flag enabled. And there are other regression reports from the .5 series in general, not specific to the USE flag. And lots of users just don't know what this change brings, or what they should expect, or what they need from the new version. Who'll help them out? Who holds the hands of these users, to tell 'em there's a migration guide with the fixes for these problems? Who writes the information in the guide so that it will be there when they need help? Not me. I don't write that stuff down. I'm just the guy who commits it. And I've got nothing to help our users. So if you know how OpenRC 0.5.x is supposed to behave, from the perspective of a stable user moving to ~arch OpenRC . . . then for the love of our users, go to bugs.gentoo.org and get me some patches. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Tue, 13 Oct 2009 22:54:31 +0200 Thomas Sachau to...@gentoo.org wrote: I disagree in this place. ~arch is called testing because it actually is about TESTING new versions and packages. You should expect problems and you should be able to recover from them and you should be able to use bugzilla. Else i suggest you move to a stable arch instead. Your arguments could make sense, if it would be about the stable tree, but forcing the testing tree to be a second stable tree, just with newer package versions isnt our goal nor does it help anyone. I'm going to pick on your email for this: you're not alone in your feelings, but yours is the most convenient email to reply to. :) You should expect problems and you should be able to recover from them. You're right! You're so right that I'm going to go and completely expunge the OpenRC Migration guide from CVS, because users don't need documentation on how to make the change! They should already know that there will be problems, so we don't need to tell them which *specific* problems those will be. Right? Right. And since they should already be able to recover from them, there's no need to list step-by-step instructions on making the change or dealing with complications, since they're supposed to already know that. I don't know how, but surely not by reading some silly guide! Guides are for n00bs! ~arch is for elite hax0rs who already know everything about OpenRC's internals. And if they don't know what they're doing, then they shouldn't be running ~arch packages, so let's presume to tell them what we think *their* needs are. We're right. And we certainly don't want them testing something if there's a GUIDE for it, I mean, sheesh! That's like asking them to help out. No, no, we want our users to come crawling to US, through the festering, fetid sekrit corridors of our labyrinthine bugzilla, to join us in our even more sekrit rituals around the Status whiteboard. * * * All that to say, Tommy (et al), is that the idea of expecting users to magically know everything and not to offer any documentation *in advance* . . . is a silly idea. Good lord, can you imagine the shitstorm the X11 team would have gone through if they'd tried *that* without first writing up xserver 1.5 and 1.6 migration guides?! signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Mon, 26 Oct 2009 13:11:38 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: AllenJB wrote: * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us? It's not only for Gentoo developers, but for /Software/ developers in general. IMHO. Uhh . . . no, it's not. A long time ago I talked with the folks who created the profile, and that's why I put the following into our profile documentation. This is seen in all handbooks: note The cdeveloper/c subprofile is specifically for Gentoo Linux development tasks. It is enot/e meant to help set up general development environments. /note . . . so no, it's not for general software development; it's to help out the hundreds of developers and users who are performing Gentoo development activities. Developing Gentoo is not like writing some random piece of software. This profile is for our special requirements, nothing else. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc stabilization todo
On Thu, 3 Dec 2009 02:44:47 + Sylvain Alain d2_rac...@hotmail.com wrote: Hi everyone, I think that the best should be to release a migration guide just before the official release and also a news on the first page of Gentoo.org You really should have checked our doc repo before sending your mail: http://www.gentoo.org/doc/en/openrc-migration.xml I, Cardoe, and Uberlord wrote it back in April 2008[1]. [1] http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/openrc-migration.xml signature.asc Description: PGP signature
Re: [gentoo-dev] irregular project metadata check
On Tue, 8 Dec 2009 10:20:36 +0100 Thilo Bangert bang...@gentoo.org wrote: Hi all, similarly to the metadata.xml check, the following is a list of small problems related to the project metadata as found in the gentoo CVS repository. Documentation: Only 1 developers signed up for project! Only one GDP member, eh? Your script is rather unreliable. Take, for example, our GDP page: http://www.gentoo.org/proj/en/gdp/index.xml It lists all our developers, as does: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/metadoc.xml?view=markup Yet your script only seems to be looking at devrel's roll-call/userinfo.xml file, which is autogenerated from the LDAP attributes each developer has. The problem with checking LDAP for roles is that there doesn't seem to be a standard way to label projects. For docs, you'll find the following roles: French Documentation Lead Documentation Documentation, Developer Relations, Infrastructure --- this one doesn't seem to be counted as Documentation, since it lists other roles. Documentation, Czech Translation Translator Follow-Up . . . etc. There are LOTS more different references to working with documentation or translation, some of them not even for the GDP. Normally Documentation refers to the GDP, but I see some devs in there who are not on the GDP team who list Documentation as a primary role. No standardization there whatsoever. Another problem with checking LDAP attributes is that they tend to be very out-of-date, even more so than project pages. People get their LDAP stuff set ONCE, when they first join, then tend to forget about them for the rest of their stay in Gentoo. Examples: all the Xfce (or XFCE) guys who are no longer there, or anyone who's added six different teams and package herds since their original responsibilities. I wish there was a standard way of labelling existing duties, and I wish there was an easier way to update the LDAP attributes. I think no one cares enough to login to dev.g.o to change their stuff, as the process is tedious. You may want to point your script at all our (sub)project index pages and check for the dev role tag to see who does what, though that may generate some false hits because not all of 'em will actually be Gentoo developers, as in the case of arch testers. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: QA last rites for x11-wm/ion
On Tue, 15 Dec 2009 08:09:20 +0100 Ulrich Mueller u...@gentoo.org wrote: Wasn't there some licence issue with this package, too? Ulrich There was with ion3, yes. It was removed for that reason about 2.5 years ago -- not just Gentoo, but basically all distros pulled it. Upstream went crazy. http://article.gmane.org/gmane.linux.gentoo.devel/49030 http://article.gmane.org/gmane.linux.gentoo.devel/49048/match=ion3 ion2 was only punted for QA reasons: http://bugs.gentoo.org/167468 signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites for net-dns/ldapdns
On Wed, 23 Dec 2009 10:40:06 -0600 Victor Ostorga vosto...@gentoo.org wrote: # Víctor Ostorga vosto...@gentoo.org (23 Dec 2009) # Last bump in 2005, does not build against current # stable net-nds/openldap-2.4.19-r1 bug #247956 # Removal in 30 days net-dns/ldapdns So what about http://www.gentoo.org/doc/en/ldapdns-guide.xml -- you want the GDP to just remove the doc? We can do that. Is there a compatible drop-in replacement that will allow us to s/ldapdns/foo throughout the guide? signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites for net-dns/ldapdns
On Fri, 25 Dec 2009 23:47:51 -0600 Victor Ostorga vosto...@gentoo.org wrote: Yes, it will be needed to remove the doc. Is there a compatible drop-in replacement that will allow us to s/ldapdns/foo throughout the guide? Unfortunately, I don't know an exact replacemente for ldapdns, at some point I heard about a LDAP sdb back-end for BIND 9 [1], but don't know if it is still functional. [1] http://bind9-ldap.bayour.com/ Well, without documentation on how to use it, we can't do anything, so I just removed the LDAP DNS guide entirely. RESO FIXED from the GDP. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: News item: MySQL 5.1 bump
On Tue, 16 Feb 2010 06:37:03 -0800 Petteri Räty betelge...@gentoo.org wrote: On 15.2.2010 22.26, Robin H. Johnson wrote: As soon as the 72 hours on this news announcement are done, I'm going to be unmasking it. I do expect most of the breakage to come from the client libraries, and NOT any actual data storage issues. If MySQL detects that it's not safe to access a table, it does give you a suitable error to repair the table. p...@gentoo.org has yet to be CCed to any mails as far as I can see. It's done now. I still don't know why we're always CCed . . . but anyway, the latest version that Robin posted looks okay. Including the upgrade procedure link was the most important add-on. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: News item: MySQL 5.1 bump
On Tue, 16 Feb 2010 19:20:06 + Robin H. Johnson robb...@gentoo.org wrote: Giving the staffing levels of PR vs. the eyes on the -dev ML, I don't see the point either. Yup. Besides, it's not like any of us have commit access to go back and fix something in a news announcement after the fact. Portage tree news items . . . what we do in PR really doesn't seem like it's suited to that aspect of Gentoo. The thing I care about most is that there's proper documentation released (or linked) along with the announcement. In this case, you did, so well done. signature.asc Description: PGP signature
Re: [gentoo-dev] Marking bugs for bugday?
On Sun, 28 Feb 2010 21:04:04 +0100 Sebastian Pipping sp...@gentoo.org wrote: On 02/28/10 20:54, Markos Chandras wrote: Do we still have bugdays? Who is taking care of this project and the respective webpage? I think we first need to answer these questions before we even consider resurrect this project welp - away He's not away, he's retired. It's just taken several months to close his bug. gurligebis - no reply yet I thought gurli was also retired. signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: games-fps/openarena
On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. It is not something that is necessary for running a desktop system. Your logic is very thin here. By that same line of reasoning, neither are the gtk or qt flags, since you don't need 'em if you're building, say, a *box desktop. Printing is something I'd argue is part of a desktop environment. It's very much a graphical activity, and that's what a desktop is. We've had the Printing Guide in our Desktop Documentation Resources section for years for that very reason. http://www.gentoo.org/doc/en/?catid=desktop signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Thu, 4 Mar 2010 19:22:41 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. So nothing uses it yet, and it's completely incompatible with 90% of the numerous python/pygtk apps already on my system, so it'll just sit there, SLOTted, doing nothing but taking up more space on my very limited SSD, while Python 2.6 is the version that's actually in use by every single app. Currently Python 3.1 should *NOT* be set as [the] main active version of Python. (emphasis and grammar fix mine) So . . . why the heck are you stabilizing it? Please don't spam me or the other users by sticking us with a useless new version. Leave it in ~arch -- it's not at all necessary to force the upgrade by stabilizing it. We're completely dependent on the hundreds of upstream Python-coded projects to switch on their timetable. Forcing a useless Python version to be the default in Gento doesn't force *them* to write 3.x-compatible code. signature.asc Description: PGP signature
Re: [gentoo-dev] Split desktop profile patches news item for review
On Thu, 4 Mar 2010 16:52:50 +0200 Theo Chatzimichos tampak...@gentoo.org wrote: I'll give three days max for the suggestions here etc, and then I'll proceed in creating the news item. So I guess it will be committed in a week max. Thanks Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 10:10:00 +0100 Dirkjan Ochtman d...@gentoo.org wrote: Because 'stable' denotes that it works as intended, that it can be installed easily, etc. All of these are true now for python3. There are applications being written for it. We want to package those too. I'm fine with people masking it, and maybe we should make that easier somehow, but 3.x should definitely be stable. It does *not* work as intended. Here, since your selective quoting missed every point I made, lemme make 'em again: Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. So nothing uses it yet, and it's completely incompatible with 90% of the numerous python/pygtk apps already on my system, so it'll just sit there, SLOTted, doing nothing but taking up more space on my very limited SSD, while Python 2.6 is the version that's actually in use by every single app. Like I said before, like it says *in the news item*, stuff does not work with it. How does that qualify as works as intended when it will not work with all my packages that use Python? If you believe stabilizing a package should be done in a vacuum, in an idealized world where no other package cares about another, then congrats, you're on the right track. Currently Python 3.1 should *NOT* be set as [the] main active version of Python. This is in the friggin' news item itself. If it should not be used, then don't force stable users to install it. It will *NOT* under this proposal be the default. Please formulate more carefully if you want to make an argument. If it's stable, then users get it by default, assuming they run the stable tree. They install a recent stage3, build their system, run emerge -uD world. Bam, a useless version of Python is now installed. Nothing on their systems will use it, so it's bloat. but 3.x should definitely be stable No one has said yet why this is. So . . . direct question, gimme a direct answer: why? signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 10:56:23 +0100 Dirkjan Ochtman d...@gentoo.org wrote: No one has said yet why this is. So . . . direct question, gimme a direct answer: why? Because in my opinion stable means that the people who package this are stating that hey, we did some testing with this, it works with all of the other packages you have installed that want to use it. Aaaand none of my packages that are installed want to use it. That's what I'm sayin'. Maybe if I ran ~arch they'd ask for Python 3.x, but I run stable, so *nothing* wants to use it. Every other stable user is in the same situation. You seem to be ignoring us, the stable users, in favor of rushing 3.x out of ~arch, like that makes some kind of perceived problem go away. It does not mean everyone should have it installed, which is what it appears you think it means. Yet that's the net effect -- everyone *will* have it installed. . . unless folks start getting crafty with pseudo version ranges, as Zac mentioned. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Sun, 07 Mar 2010 20:26:24 +0200 Petteri Räty betelge...@gentoo.org wrote: On 03/07/2010 07:32 PM, Samuli Suominen wrote: no need to stabilize experimental python, not even convinced it should be in ~arch yet (but package.masked for testing) I don't think upstream considers python 3 experimental so when it can be installed side by side with 2.6 so that ebuilds don't break it belongs in ~arch. Fine, then let's leave it in ~arch. Don't stabilize it yet. See below: Mark Loeser halc...@gentoo.org wrote: The stable tree should all Just Work together. That's why. signature.asc Description: PGP signature
Re: [gentoo-dev] How about a monthly bumpday?
On Tue, 09 Mar 2010 22:32:22 -0600 Nathan Zachary nathanzach...@gentoo.org wrote: On 09/03/10 22:08, Sebastian Pipping wrote: Hello! We have about 500 bump request open at the moment: https://bugs.gentoo.org/buglist.cgi?quicksearch=bump I assume that quite a few of them would be no big deal to their maintainers in Gentoo. Bugday is occupying the first Saturday of the month: how about bumpday on the third Saturday of the month? First bumpday could be March 20th, 10 days from now. What do you think? Sebastian Not sure that my opinion matters all that much as I'm not currently doing ebuild work, but I think this idea could really help out the status of the tree. Attached to it could be a stabilisation day as well. --Nathan Zachary The ones that I'm CCed on, either as proxy maintainer or because I have some other interest, I prolly would mind. They're not simple revbumps, but they have dependency changes and/or other complicated changes, which is the only reason why they're still open. My bugs can't be solved with a simple rename-and-commit. I'm prolly not the only one who feels this way, so you really need to pick your bugs carefully! Otherwise we'll end up with another screwed-up mess like the one we just went through with patrick. Bumpdays are otherwise a good idea, though I'm not sure why we need a separate day for that in addition to our standard bugdays. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Wed, 24 Mar 2010 17:43:56 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-23 20:28:38 Ben de Groot napisał(a): As mentioned in the other thread, this news item should mention that users who do not need python-3 should mask it locally to prevent it from being pulled into the dependency graph. Python maintainers do not recommend to mask Python 3. But everyone else in Gentoo does, so . . . signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Wed, 24 Mar 2010 18:14:44 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-24 17:57:35 Joshua Saddler napisał(a): On Wed, 24 Mar 2010 17:43:56 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Python maintainers do not recommend to mask Python 3. But everyone else in Gentoo does, so . . . Some Gentoo developers/users, who aren't Python maintainers, said that they didn't object to have Python 3 installed. They're in the minority, judging by the replies in this thread. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Wed, 24 Mar 2010 19:04:51 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: People, don't want Python 3, probably have already masked it. There is no reason to waste Council's time for decision on what sentence should be included in the news item. Not the folks running the stable tree, because they don't know about it. They're not following the discussion here on -dev. They're going to get unpleasantly surprised when it shows up in their next world update. Include instructions on how to mask it if desired in the news item. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Wed, 24 Mar 2010 16:12:55 -0500 William Hubbs willi...@gentoo.org wrote: On Wed, Mar 24, 2010 at 09:36:52PM +0100, Ben de Groot wrote: We agree that this is the minimum that should be done. But our Python lead stubbornly refuses to honor this reasonable request. On the other hand, I can see his point as well. The news item makes it very clear that python-3 cannot be the default python and that python-2 needs to be installed. Again, if it *cannot* be the default python, then it *should not* be installed by default, which is what will happen if it's marked stable and users aren't told to p.mask it. Even then, it'll likely get installed first, as users will probably learn about p.masking it only *after* they install it. signature.asc Description: PGP signature
Re: [gentoo-dev] List of User projects
On Sun, 28 Mar 2010 13:09:07 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Mar 28, 2010 at 10:07:52PM +0200, Rennn 'Necoro' Neumann wrote: Am 28.03.2010 21:04, schrieb Brian Harring: Instead, if the purpose is a thanks, why not every once in a while put up a news item discussing the tools in question? Such an approach allows folk to focus in on whatever is useful/interesting (regardless of origination) and give the same 'thanks' angle and public exposure for the author in question. Like the Gentoo Weekly/Monthly Newsletter (R.I.P.)? Pretty much the notion, although I'd avoid the monthly angle- that seems to be the downfall of GWN and kin. ~harring I still try to put up articles of interest whenever someone sends 'em to PR's way, or when I find out there's some interesting use of Gentoo out there. The Misa guitar comes to mind. But covering each and every little bit of software written for Gentoo is too much work for one guy, or even a folks. 'Specially since they so often go defunct after a very short time -- I'm thinking of all the Portage frontends in particular. signature.asc Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. Not everything has a bug tracker, but the end result is still a visible difference in the stuff you see on the website. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. We've added quite a bit, with the automated feeds and whatnot. And the sidebar stuff. And the revamping of our releases page, and lots of other areas. I've added lots of stuff; I guess you just haven't noticed. - Speaking of our website, PR ... guess there's nothing more to add. Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all the work I did to organize SCALE and go out and make a difference with our (potential) users by talking with them doesn't mean anything. All the word-of-mouth I've done with folks before and after SCALE, even my coworkers must not count for much. * * * I would have expected such this kind of negative, abrasive email from a user, but to see such a sensationalist letter coming from a developer is disappointing, to say the least. I expect better from you. Because whether you realize it or not, your email can only come across as denigrating my efforts, and everyone else who puts in hard work on (actually visible!) changes. Your email was inflammatory and offensive, but not in the way that motivates me to do more or do anything different. It came across as extremely demotivational. signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 03:20:53 +0200 Ben de Groot yng...@gentoo.org wrote: GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? No, he's definitely out to kill GuideXML. Just give him time. A wiki can fulfill several purposes for us: 1. Easy collaboration among devs, for brainstorming, developing new documentation, assembling upcoming meeting agendas, and so on [for which there currently is not really any obvious place] This is not *impossible* with our current setup; it can still be done in a few different ways: 1) project spaces in /proj/$LANG/foobar/ -- how hard is it to commit to CVS when going through document drafts? 2) devspaces -- it's easy enough to dump stuff in here for others to refer to However, a wiki *does* make it easier for everyone to jump right in and edit stuff as ideas are passed around, rather than waiting for someone to make changes to something in a devspace. 3. A place to host and maintain our existing documentation [which is currently in GuideXML] Entirely unnecessary duplication of effort. To quote the forum mods, don't cross-post . . . and especially don't do it if you'll be violating a doc license somewhere. It's one of the reasons why we don't use existing unofficial wiki content in our docs. I and the GDP have written about that ad nauseum over the years; just search the list archives. I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point . . . to say the least. Show me a wiki that has the flexibility of our handbook, which can be a huge printer-friendly all-in-one doc, or an as-you-need-it doc with one page per chapter. Show me a wiki that has built-in intradoc linking to every paragraph, chapter, subchapter, code sample, etc. Show me a wiki that produces such beautiful code samples (with titles). Show me a wiki that can produce the following formatting for ebuilds: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7 . . . or a wiki that makes it super-easy to add all sorts of additional in-line formatting to regular paragraphs, for example all the blue highlighting for code used throughout http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font used for filesystem paths. Show me a wiki that makes it easy to create tables, for example, compare RadeonProgram from the x.org wiki: http://www.x.org/wiki/RadeonProgram?action=edit ||-2 style=text-align: center; background-color: #66 '''Native''' ||style=text-align: center; background-color: #66 '''R100''' ||style=text-align: center; background-color: #66 '''R200''' ||style=text-align: center; background-color: #66 '''R300''' ||style=text-align: center; background-color: #66 '''R400''' ||style=text-align: center; background-color: #66 '''RS690''' ||style=text-align: center; background-color: #66 '''R500''' ||style=text-align: center; background-color: #66 '''R600''' ||style=text-align: center; background-color: #66 '''R700''' || . . . that's one line of cells. One. Ugly. Compare it to: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1 table tr thFoo/th thBar/th /tr tr tiThis is an example for indentation/ti timore stuff/ti /tr /table Which is easier to read and instantly comprehend? By moving to a wiki, you'll lose a huge percentage of what GuideXML can do, in exchange for quicker and easier editing and creation of docs, though neither of these have been qualified. As some others on this list have mentioned, wiki syntax is downright ugly and simply not as consistent or readable as plain ol' XML or HTML. From what I've seen, the biggest objection to GuideXML is folks don't want to take the time to learn a few tags. Well, you'll have to learn tags and syntax for either system, so pick your poison. I've yet to see a wiki that even has as much sense as HTML, which is pretty low on the totem pole of consistency. I ain't out to stop ya'll from using a wiki. I do agree that they have some advantages. However, I will point out how limited wikis are. They're not a magic bullet that will solve all our problems. signature.asc Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On Sun, 4 Apr 2010 10:22:06 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: 5 years ago [...] constantly added [...] You need to clarify your metric. How are you defining constant? How often does a new document need to appear? What mostly happens is steady refinement and expansion of our existing docs, occasionally splitting off long portions into their own document, or merging a few back together where appropriate. Stuff that's written fully from scratch is much rarer than you think, and it's been that way for a long time. I'm not saying that's a bad thing; that's just how it is. Two noteworthy exceptions: 2005 and 2006. Those were years when we had all the English speaking GDP members writing. I came on board in 2005 and immediately helped crank out docs and updates, and worked with folks to get new stuff into the tree. 2005 was a good year both for the GDP and for external contributors to help write stuff and add patches, which is why we saw much more diversity in our new docs. Since then, the list of active English writers in the GDP has declined to one and it's been that way for a few years now, so that partly explains the slowdown in docs. Another is that we just aren't getting as many new submissions since the days when (apparently) we had more willing developers to pitch in with the docs. Many of the 2005/2006 guides have had their primary authors/contributors disappear, leaving us without an easy way to keep them up-to-date. The GDP can't maintain a doc if we don't have someone, internal or external, who can devote time to keeping docs up-to-date. Lots of those 2005/2006 additions need serious overhaul, or I'll have to mark 'em deprecated/draft or even remove them entirely. Some of the guides written years ago have been removed from the tree. Part of maintaining documents is not just writing new ones, but treecleaning, if you will, our existing collection. It's not as attention-getting as a totally new guide. I can't promise attention-getting news releases for every doc or website change I make. * * * Here, I'll take 2 hours to go through our complete CVS history for our docs in /doc/en/ and create a list of what was added or removed in the last 5 years. This list doesn't *begin* to include total rewrites or near-total rewrites (such as the printing, gnome, X11 guides) or whether the rewrites were made in just one day or over time as packages and methods have evolved. It doesn't cover the handbooks, nor the handbooks I wrote entirely from scratch in 2006 to cover the new GLI installers (and their subsequent removal after 2008's releases). It also does not include documents that have since been marked draft or deprecated or some other maintainance status besides active. I expect some of the docs on this list to still be in draft or to have moved to it or deprecated, so whether they really count is up to you to decide. If you want to average docs on a monthly or yearly basis . . . you can tweak the numbers all you want. Note, also, that just because you don't see a doc on it in the last 5 years doesn't mean we don't already have a wealth of published info on a subject in our existing documentation. Something that was added in, say, 2002 or 2004 is prolly very complete, and covers lots of stuff you'd normally find in separate articles elsewhere, for example on wikis. I'm not putting much here besides the files added/removed. This is just stuff that's initially added to or removed from CVS. *2010* Nothing totally new added nor anything completely removed. Hey, the year is young. Lots of rewrites though. *2009* Same. Mostly extensive rewrites, most notably the handbooks to take into account the autobuilds. New: bind-guide.xml New: lxde-howto.xml New: openbox.xml Removed: ldapdns-guide.xml (added 2006) Removed: gentoo-sparc-quickinstall.xml (added 2004) *2008* New: multipath.xml New: nagios-guide.xml (draft) New: openrc-migration.xml Removed: apache-developer.xml (added 2005) Removed: apache-troubleshooting.xml (added 2005) Removed: apache-upgrading.xml (added 2005) Removed: kde-config.xml (added 2004) Removed: kde-split-ebuilds (added 2005) *2007* New: gcc-optimization.xml New: pda-guide.xml (draft) New: vpnc-howto.xml New: xen-guide.xml New: xfce-config.xml Removed: colinux-howto.xml (added 2004) Removed: mysql-upgrade-slotted (added 2006, but mysql team reverted SLOTting) Removed: nx-guide.xml (added 2004) Removed: openmosix-howto.xml (added 2003) *2006* New: change-chost.xml New: conky-howto.xml New: cross-compiling-distcc.xml New: gentoo-alpha-faq.xml New: gentoo-x86+raid+lvm2-quickinstall.xml New: info-guide.xml New: jffnms.xml New: kernel-config.xml New: ldapdns-guide.xml (removed 2009) New: liveusb.xml New: man-guide.xml New: portage-utils.xml New: postgres-howto.xml New: vdr-guide.xml New: zsh.xml Removed: java-old.xml (added 2006) Removed: vserver-howto.xml (added 2005) *2005* New: apache-developer.xml (removed 2008)
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 17:23:54 +0200 Ben de Groot yng...@gentoo.org wrote: As has been pointed out, your table example was unfair, as they don't do the same thing. I would frown on such inline styling (that's what stylesheets are for), and there are a number of ways you can markup tables in wikis. One is to allow HTML tags, so it would be very much like GuideXML. Another one, which I prefer personally, is to use reStructuredText, which is even clearer than HTML markup. Having to write a custom stylesheet just to get one wiki page to do what you want is pretty dumb. How is it unfair? Because tables really are so much simpler to write in GuideXML? Here's a more complicated table: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10 source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=1 By moving to a wiki, you'll lose a huge percentage of what GuideXML can do, I don't see that at all. Is there any essential feature of GuideXML that is missing in MediaWiki? (Let's take that wiki implementation as the most likely one we will adopt.) I haven't seen anything yet that is impossible or very difficult to do. Do you really think that GuideXML is so special and advanced that nobody else had the same needs and that major wiki engines do not provide in those needs? Mediawiki mostly involves memorizing how many quote or tick marks you use. This markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what each tag means. It's semantic. ul starts an unordered list. ol starts an ordered list. li is a list item. b for bold text. e for emphasized text, similar to XHTML's em tag. table to start a table. Mediawiki requires you to memorize numbers of marks to achieve the same effect: two ' ' for italic text, three ' ' ' for bold, five ' ' ' ' ' for bold AND italic. Now take a look at the section on Mediawiki lists: whitespace becomes part of your formatting. Lame. At least with GuideXML, you can use whatever whitespace or linebreaks you want to keep code human-readable, and know that it won't affect the rendered version. Oh, *and* you have to prefix Mediawiki list items with ; and : , which is completely nonsensical and arbitrary. The character doesn't explain what it's for, unlike semantic XML tags. Take a good look at the Mediawiki mixture of lists sample: (I'd provide a direct link, but there's no built-in way to snap to it) http://www.mediawiki.org/wiki/Help:Formatting That is just plain ugly. The eye has a hard time unjumbling the ##s and ;:* crammed together. Also, note another flaw of Mediawiki: At any time, you can throw in HTML and CSS to do stuff, because apparently Mediawiki isn't flexible enough on its own to generate your desired rendering. Having to mix HTML with a totally different wiki syntax is stupid. Having to learn CSS *on top* of learning wiki syntax (and HTML) just to write a document is retarded. You've tried to make the case that learning GuideXML is too hard, but in order to use Mediawiki you'd need to learn at least 3 languages. In my earlier email, I shared a code sample of GuideXML tabls. Mediawiki's idea of tables? {| to start. |+ for a caption. |- for a row. ! for headers, and | for data. Use more || symbols for more rows. Seriously, what part of this is easily understood to be table markup? *And* you can mash in XHTML attributes to style the text. Big no-no. Leave the styling to a separate stylesheet, and let the code just be code. Yeah, since Mediawiki tables can accept straight-up CSS (another skill you had all better learn if you're going to write valid code, apparently), you *can* do a bit more color formatting than with our existing XSL rules for GuideXML. I'll grant you that. But that's at the price of standardization: since arbitrary tags and markup is allowed, there's nothing to keep consistency between documents, or even within the same document. GuideXML at least has a clean, consistent visual representation. Once you start allowing arbitrary markup, there'll be a million and one ways of representing the same thing, and that's not good for someone trying to wade through documents. There *should* be a standard way of representing information. And if you really wanted to, you could easily write an extension to parse GuideXML, so it could be used as wiki markup. So again, the markup is not really an argument against using a wiki instead of our current GuideXML+gorg setup. Except I haven't seen Mediawiki offer anything like our textual color palette or other code syntax and block-level formatting flexibility. 2. It is a non-transferable skill. You can't use it anywhere else. And unless you are a regular GuideXML writer, you will have to look up its particular usage almost every time you do use it. It's just XML. That's all. If you can write HTML, then you can write XML. XML is *easier*. It's got far fewer tags, for starters. That means much, much less to learn. Oh, and guess what?
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Mon, 5 Apr 2010 02:08:06 +0200 Ben de Groot yng...@gentoo.org wrote: On 4 April 2010 21:33, Joshua Saddler nightmo...@gentoo.org wrote: Having to write a custom stylesheet just to get one wiki page to do what you want is pretty dumb. Yes it would be. The idea is that you design consistent styling from the get-go, so your stylesheets will be ready for those needs. Pretty much the same as the current documentation solution. How is it unfair? Because tables really are so much simpler to write in GuideXML? No, because they were displaying different things, using different features. Here's a more complicated table: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10 source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=1 And you think that's intuitive? Tables are a bitch, and I think both the GuideXML approach (copied from HTML) and the wiki syntax one are equally unintuitive. In my opinion reStructuredText is offering a better alternative: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables At least the GuideXML approach to tables is familiar to anyone who's worked with HTML. Oh wait, you shouldn't be comparing GuideXML with HTML. More on that later in this message. Also, don't get me started on rST's many failings. It's just like wiki syntax, in that anything you want to do besides line spaces and lists involves stupid nonsemantic code. Having to define URIs twice is retarded: External hyperlinks sample sentence, like Python_. .. _Python: http://www.python.org/ Tables: A big problem with rST and wiki markup is that they try to preserve the rendered format within the source code view. +++---+ | Header 1 | Header 2 | Header 3 | +++===+ | body row 1 | column 2 | column 3 | +++---+ That's rST source. This gets unwieldy very quickly for larger tables, as they'll overflow your editor window. Hey, that might not be a problem, but it's also a losing proposition to try to have that stuff rendered within the source view. Let the renderer take care of the final rendering, as really, tags and markup are all arbitrary. What should matter is how it appears in your webbrowser, since that'll vary from the source view anyways. . . . I hope you aren't seriously suggested rST as the wiki format. Mediawiki mostly involves memorizing how many quote or tick marks you use. The beauty is: you don't have to memorize it, as it is just a click of a button on the editor interface away. And not everyone will want to do that. I certainly don't like clicking around when it's easier and faster for me to just type the code myself. Really, you're mostly making a case for a graphical XML editor like Beacon, rather than making a case for a wiki. :) This markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what each tag means. No, I don't. The body and title tags are used quite differently from HTML, which is confusing. When do I use section and when do I use body? And what the frak is stmt? And why uri and figure instead of HTML's a and img tags? Except to a few dedicated people, GuideXML is confusing. That's your problem, then. Do you know what semantic means? Semantic doesn't mean just like HTML. So stop treating it that way. Let's look at semantic tags. It's not hard to see that var is a variable and that stmt is a statement, and comment is a comment. Semantic markup is markup that means what it says. Using punctuation marks like ' '' ; : is neither semantically useful nor easily readable, as I showed in the code samples you oh-so-casually skipped over. Nice try. ' and ' ' mean nothing in and of themselves. But you're not a web author, so I'll stop trying to beat you over the head with how things work. Next point: Having to mix HTML with a different dialect of XML is equally stupid, and moreover it is confusing. At least with MediaWiki, you don't have to use it, as there are other options. Why the hell do you keep bringing up HTML? Stop comparing GuideXML with HTML. Treat them as two separate languages, please. I only mentioned GuideXML in the context of it's easier to learn because it has fewer tags than HTML -- you operate under the mistaken assumption that GuideXML should be *like* HTML, and that HTML has too many tags. You assume that everyone comes from an HTML background and thus will be confused by GuideXML. What do you mean? You can predefine styles in your CSS to express your textual color palette (if I understand correctly what you meant by that). There is advanced code syntax highlighting available, for example using GeSHi. Okay, then you also need a way to get those styles into your document by coming up with new tags or wiki markup. var is a variable in GuideXML, and it'll be colored yellow. You mark this variable in a pre block with the var tag, which is created just
Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 May 2010 12:45:54 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Following Petteri's thread last month about RESOLVED LATER and given a issue that has been reported to User Relations about the abuse of the VERIFIED status in Bugzilla, I'd like to get some feedback from fellow developers. We have a user that has been marking resolved bugs as verified following his actions on other bugzilla(s) and he quotes the Bugzilla Docs[1] to explain his actions. Some developers have become upset because of the spam email that action causes. It seems to me the reason those developers got upset is that they don't value the VERIFIED status so I wonder if anyone uses that status or if we should just drop it. If possible and useful, would we like to restrict the VERIFIED status change to a specific group of people? Please share your thoughts on this so we can decide how to act on this case. Punt VERIFIED. It's useless for documentation and for everything else I do. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkvtc8wACgkQxPWMzpKk6kOD2wCgqr+brRXJljXR+wDk8+fOETUG sQQAn3gJVt3rclCmXyqHfwu/D4fBgFkG =7I70 -END PGP SIGNATURE-
Re: [gentoo-dev] gentoo embedded reference accounts?
On Fri, 28 May 2010 22:47:58 -0700 spinugio spinu...@gmail.com wrote: Hi everybody, can I please get some so-to-speak reference accounts of products that are using Gentoo as their embedded Linux distribution of choice? in other words, can you please let me know of any embedded appliance that is running gentoo linux? I am trying my best to convince my company that it would be a good choice :) I'd really appreciate any help in this direction from your side... We really have no way of knowing unless someone tells us. As far as what we do know . . . I usually run news items on these kinds of things, so check the Public Relations and GMN archives for articles on the various places Gentoo's used. D-Link routers, for example, run (or used to run) Gentoo. SRI's solar probe, RAISE, ran Gentoo. The Misa Digital Guitar, just entering mass production, runs Gentoo. There are many more places where Gentoo's been used in various devices and production environments, so the PR, GMN, and GWN archives are your friends, as well as searching Google for Gentoo success stories. signature.asc Description: PGP signature
Re: [gentoo-dev] 'State of Gentoo' BoF session, Linux Symposium 2010.
On Sun, 11 Jul 2010 01:30:08 -0400 Jacob Godserv jacobgods...@gmail.com wrote: On Fri, Jul 9, 2010 at 13:19, Robin H. Johnson robb...@gentoo.org wrote: I'm running a BoF session during the Linux Symposium 2010 in Ottawa next week, entitled 'State of Gentoo'. I've had my own uneducated ideas about this exact topic. I'd love to hear more about this. Will notes or a recording be posted anywhere? Ideally in the underused Presentation Listing in the PR projspace: http://www.gentoo.org/proj/en/pr/docs/presentation-listing.xml We can do the GuideXML for the list; just send us the file(s) and license(s) used so that we can host 'em on g.o. signature.asc Description: PGP signature
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Tue, 27 Mar 2012 19:49:00 +0200 Pacho Ramos pa...@gentoo.org wrote: Hello 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. Thanks for discussing this :) not gonna happen, for reasons that SwifT others already mentioned. this is the sort of non-simple, non-trivial text/info/instructions that would be better suited to an optimizing your FS layout article on the gentoo wiki, or similar. signature.asc Description: PGP signature
[gentoo-dev] ipv6 documentation: net-dns/totd substitutes
Hey folks, thought I'd ask here, since I can't find answers on what's maintained in our ipv6 packages. http://bugs.gentoo.org/show_bug.cgi?id=326771 asks for updates to our sadly neglected ipv6 guide (http://www.gentoo.org/doc/en/ipv6.xml). I removed the note that said to keyword net-dns/totd, now that it's been stabilized. totd is a DNS proxy used for 6to4 conversion. The problem, as I outlined in comment #6, is that we should not continue referencing totd in the guide. It's maintainer-wanted, no-herd, only available for two arches (x86 amd64), and only stable on x86. Do we have a more cross-platform alternative that's actually maintained? Who does ipv6 commits these days? Given the much-hyped death of ipv4 addresses sometime in the next several months, it's important that we find a suitable alternative and get it properly documented, with help from its maintainers, in the guide. Thanks for your help. -- GDP, PR, etc. signature.asc Description: PGP signature
Re: [gentoo-dev] Updated handbooks for autobuilds
On Sun, 4 Oct 2009 11:42:13 -0700 Joshua Saddler nightmo...@gentoo.org wrote: There. I did the x86 and amd64 handbooks (networked, anyway; who cares about networkless). They're now ready for the 10th anniversary. I'm pretty sure. I also did the x86 quickinstall handbooks. It's been several months, so it's time for a status update: This week I finally completed the alpha, arm, hppa, ia64, and sparc handbooks. Still have to do PPC/PPC64. There are just a few open tracker bugs; once these are fixed, that will free up all the ebuild and non-doc bugs that depend on our handbook bugs. While doing the handbooks, I discovered that some of our arches have been neglected, so this next part is a call for help with the weekly/monthly autobuilds. * * * What's up with the arches: x86 and AMD64 have not had new stages or LiveCDs in months. jmbsvicetto just started working on 'em, but we need LOTS of eyes and fixers for our two biggest arches. Right now there's no one else. Most of the breakages seem to come from toolchain and Python 3.x build failures (because *someone* wanted it stable), but it needs troubleshooting. HPPA could use some assistance in generating autobuilt LiveCDs: the most recent CDs are from the 2008.0 release. If you've got the hardware, please contact the HPPA team. IA64 hasn't had new media in a month, but I understand that armin76 is workin' on it. If you've got Itanium hardware, contact the ia64 team. PPC64 hasn't produced much in the way of stages or CDs since October 2009. PPC32 and PPC64 (32-bit userland) has stages from May, but no CDs since 10/2009. PowerPC is one of our bigger secondary platforms, right? We need folks with the hardware to diagnose the problems and come up with some build fixes, so that we can adjust the autobuild scripts. Based on the number of releases, ARM, Sparc, and Alpha seem to be doing okay. More folks willing to watch for build failures and help out are, of course always welcome. MIPS is is its own special arch; last releases are from 2007.0. However, r0bertz and redhatter are working on getting stuff to first compile before putting together autobuild releases. If you've got any kind of MIPS machine, especially something fairly recent, please get in touch with the MIPS folks to see about getting stuff to build. MIPS could use more recent stages. The installation instructions for MIPS are so different they have their own entirely nonconformant handbook. With working autobuilds, even on a monthly (or longer) basis, I could fix up the handbooks to make them much easier for folks to maintain. Nonstandard documentation is always extremely difficult to work with. Bottom line: the autobuilds idea is a sound one. However, it needs more maintenance than you might think. We need more people to watch it and help out. Thanks for your time, Josh signature.asc Description: PGP signature
Re: [gentoo-dev] Updated handbooks for autobuilds
On Tue, 20 Jul 2010 17:11:10 -0400 Richard Freeman ri...@gentoo.org wrote: Is the process for creating these documented somewhere? I did some googling and couldn't really find any documentation on how our stages and liveCDs are built in the first place. There are some generic catalyst docs, but no real docs on how to generate an official build - that is one that would be identical (not necessarily bitwise) to what you'd find on the mirrors if they were up to date. I haven't been able to find a clear step-by-step guide, either. Maybe there's something else in our project space, but I only ever handled the docs side of Releng. Also check the list archives? Supposedly some of the catalyst development is happening on non-Gentoo sites, so maybe there's a bugtracker/wiki/ML upstream. Where's agaffney to answer these questions when ya need him . . . signature.asc Description: PGP signature
Re: [gentoo-dev] News item announcing as-needed (glep 42 stuff)
On Mon, 26 Jul 2010 13:44:36 -0700 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This might be a bit unclear to less savvy users. How about just make sure your LDFLAGS in /etc/make.conf contains -Wl,--as-needed or is unset? Instead of saying overriding, I'd say something more similar to disabling --as-needed and add that it is not recommended. It should be unset; as you say, users should not be screwing with system-wide LDFLAGs, as we don't support anything but the defaults. I put an LDFLAGs FAQ in the optimization guide a long time ago: section titleWhat about LDFLAGS?/title body p The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so you don't need to change them. /p /body /section signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Cleanup of the Get Gentoo page
On Mon, 16 Aug 2010 16:34:08 +0300 Markos Chandras hwoar...@gentoo.org wrote: You should talk directly to the teams how are responsible for this part of the webpage like dosc or pr teams Common misconception. Neither the GDP, PR, or even Releng is directly responsible for those pages, though all three teams have provided input in the past. There's just me. I happen to be on all three teams, but none of those teams themselves are responsible for /main/ content. That said, I've been looking at the proposed changes, so I'll be implementing some or all of them soon, probably today, time permitting. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Cleanup of the Get Gentoo page
On Mon, 16 Aug 2010 11:43:06 -0700 Joshua Saddler nightmo...@gentoo.org wrote: That said, I've been looking at the proposed changes, so I'll be implementing some or all of them soon, probably today, time permitting. I'm not going to be able to get to this, so anyone else with commit access to /main/en/ can feel free to make the changes. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Cleanup of the Get Gentoo page
On Mon, 16 Aug 2010 22:24:45 -0700 Alec Warner anta...@gentoo.org wrote: I have access to main/en and I am willing to do website stuff; just nothing with a quick turnaround. I know guidexml and enough xsl to be dangerous. Excellent. I've been the defacto www@ team for as long as I can remember. More help would be appreciated. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 10:30:20 -0400 Richard Freeman ri...@gentoo.org wrote: Looking at the tracker bug, I see all of three issues blocking openrc from going stable. One is documentation, It seems like we should just make the next bugday OpenRC Cleanup Day or something like that. Everybody can take 15 minutes to contribute to a wiki on getting started with openrc, or blog about it, or whatever. the docs team can glean the best of that and get the docs in order. Oh heck no. We're not about to wade through a hundred blog entries/wiki articles in a desparate attempt to assemble a coherent guide. Besides, Doug, Roy, and I wrote a migration guide a few years ago that I've been constantly updating: http://www.gentoo.org/doc/en/openrc-migration.xml The big issue with the docs is that IF OpenRC/baselayout-2 are marked stable, it will require massive changes to hundreds of our other doc files. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 19:18:56 +0200 Christian Faulhammer fa...@gentoo.org wrote: Hi, Joshua Saddler nightmo...@gentoo.org: The big issue with the docs is that IF OpenRC/baselayout-2 are marked stable, it will require massive changes to hundreds of our other doc files. Is there a list of the needed changes? Read the OpenRC guide, then read all our other guides. That's the list. It will require a line-by-line code scan to figure all this stuff out. Creating such a list would probably take almost as long as actually fixing the docs. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 22:57:46 -0500 Nathan Zachary nathanzach...@gentoo.org wrote: I don't think that the documentation changes should be a determining factor in switching to OpenRC. If we are going to endorse using OpenRC, the more relevant issues are the ones regarding its future development. The documentation can be updated in due time. Of course, that's just my opinion. It's not really a determining factor in whether or not we adopt it as our default system. It's just one of the big tasks to complete if we do. I'm not arguing against using OpenRC just because the docs will require significant rewrites. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 20 Sep 2010 06:46:21 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Why can't we keep both? There are strong advantages/disadvantages either way and there are users invested in both new/oldnet. I know this is more work on doc writers, but I don't think that will equal the pain users will experience being forced one way or another. Wrong. It will. The GDP--that's effectively just me--will already have to rewrite every single one of hundreds of pages of documentation to allow for the new syntax and way of doing things present in the oldnet behavior of OpenRC. That's ~weeks to ~months of work, even if there's someone besides me doing it. I'll have to do all that effort and time commitment yet again if we have to rewrite everything once newnet becomes the default after everyone uses oldnet for a while. Worse yet, if BOTH are enabled, and we have to document both simultaneously. Then we'd have to fill up our docs with stupid conditionals: IF you're using oldnet, use THIS complicated config, but IF you're using newnet, then follow THIS complicated set of steps. Documenting both config styles, whether simultaneously or sequentially, is massively complex, unnecessary, and a complete waste of time. I'd probably quit if I had to redo everything more than once, and then there would be absolutely no one to work on any docs. That's not a threat by the way, just a statement of likely outcome. I simply wouldn't have enough spare time to adjust the suddenly broken mass of documentation for the new config style. Please. Just stick to *one* config. I strongly suggest that it be oldnet, given all the problems with newnet raised in this thread. But more importantly, because *the groundork has already been done* when I wrote the OpenRC Migration Guide. I can piggyback all my efforts off that guide, which will greatly shorten the amount of time needed for the rest of the documentation. Otherwise a completely new migration guide will have to be written, AND all the docs will need to be adjusted to THAT one. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyXnpYACgkQxPWMzpKk6kNdZwCgrVN6D12QzaHw5lXZl+h610PL /ccAni2xDC+CWwkTw9GKBCvjT/IDqcj9 =RxdN -END PGP SIGNATURE-
Re: [gentoo-dev] openrc: oldnet vs newnet
On Mon, 20 Sep 2010 11:16:08 -0500 William Hubbs willi...@gentoo.org wrote: All, I want to start a new thread since the discussion on openrc is centering on whether we should use oldnet, newnet, or keep both. Use oldnet. Why? 1. We already have a migration guide setup for it: http://www.gentoo.org/doc/en/openrc-migration.xml Keeping oldnet will greatly reduce the time needed to change all our other docs, since I can use it as a reference, without needing write a completely new migration guide for oldnet and *then* still have to change all our other docs. 2. Users are already accustomed to doing things via oldnet, since they've been using OpenRC and following this guide for two years now, since 2008. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
On Sun, 26 Sep 2010 08:37:35 -0400 Jacob Godserv jacobgods...@gmail.com wrote: On Mon, 20 Sep 2010 14:32:49 -0400 Mike Frysinger vap...@gentoo.org wrote: man, fix your line length. what a nub you are. Or adjust your mail client. Then you could save yourself the name calling, which changes the mood of the mailing list and causes issues for more people than just your target. It's okay. We go back some years. We've met in person. I can read Mike's text tone. We're just playin'. Besides, I learned something important, namely that despite my configs, Claws Mail wasn't behaving properly, so I had to make a few changes. S'all good. At no point was I hurt by the nub label. I think I replied NO U, which is of course how we handle things off-list. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
On Sun, 26 Sep 2010 13:32:49 -0700 Alec Warner anta...@gentoo.org wrote: On Sun, Sep 26, 2010 at 1:26 PM, Mike Frysinger vap...@gentoo.org wrote: because he's a stupid nub -mike NO U Is that pronounced 'nub' or 'noob' ? Man I should really go to SCALE next year :X We got the official invite from the organizers, as well as the CFP/talks. I'm interested in going yet again, especially since it's moved to a new venue. signature.asc Description: PGP signature
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On Wed, 1 Dec 2010 12:13:03 -0800 Alec Warner anta...@gentoo.org wrote: On Tue, Nov 30, 2010 at 8:02 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-11-2010 10:34, Sebastian Pipping wrote: On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote: There will probably be no active version of Python set. You had two weeks to come up with this. Please find my on IRC to team up on an agreed fix. As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I'd like to take this chance to recall this is the 2nd time on the last few months where stage generation was broken by python changes. Also, we've been unable to create hardened stages for over 8 weeks because of a sandbox issue. The weekly stages generation depends on the quality and stability of the stable tree. Therefore, the RelEng team kindly asks all maintainers to pay attention to the stable ebuilds in the system set and to please fix any failures asap as they may / can prevent stage generation. Be sure to think carefully about changes that can impact the stage generation, in particular when they involve python. Two issues: proj/en/releng is old as hell and doesn't even mention stage generation. How does a developer know when the stage generation is broken? Is there a dashboard? At work we have a guy who is basically a build cop and checks our build dashboard once a day or so and if it is broken he goes and finds the guy who broke it and punches him in the face until he fixes it. I imagine we do not have staff for this (and no one has invented punching over the internet.) Catalyst sends automated emails to rel...@gentoo.org from the various build boxes: dolphin, poseidon, other dev.g.o machines. I am curious how often stage builds fail (how long can they be broken until we actually care?) Fairly often, especially in the last couple of months or so. There were some arches that, last I checked, hadn't had any new media in several months. Python is the usual cause. Remember the last huge Python debacle that resulted in suspension? Yeah, that was one of the reasons for continually broken media. Python issues are pretty much the only reason why general stage builds fail (hardened is its own set of problems.) Here's part of a typical message from one of the boxes, minus a whole bunch of bad interpreter errors: - [[ (1/3) Configuring environment ]] /usr/portage/scripts/bootstrap.sh: line 307: python: command not found - [[ (2/3) Updating portage ]] env: emerge: No such file or directory !!! catalyst: run script failed. Traceback (most recent call last): File modules/generic_stage_target.py, line 1207, in run_local run script failed.,env=self.env) File /usr/lib64/catalyst/modules/catalyst_support.py, line 542, in cmd raise CatalystError,myexc CatalystError None I see messages like this pretty much every day. Releng is understaffed on a few arches, which is why no one has time to track down the errors, fix them, and get the builds completed. signature.asc Description: PGP signature
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On Wed, 01 Dec 2010 21:58:20 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: So we have some automatic reporting. Can we have a webpage for that, or a mailing list that people can subscribe to? Mailing list: http://bugs.gentoo.org/329165 I have no idea how to go about doing an automated webpage or other integration with other projects. Do we have some bugs or other actions towards fixing those problems? Not that I know of. AFAIK problems are dealt with on the basis of whoever sees the email AND has time to fix it. The Releng team members in charge of minor arches generally do a pretty good job of fixing stuff on a timely basis. Our major arches seem to break more frequently, but receive less TLC. Again, manpower and time issues. Is it possible to bisect the portage tree and identify a breaking commit? Beats me. Git would make that easier. From what I can see, anything that's ever been done to Python has resulted in breakage. signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Installer (text-based)
On Wed, 09 Feb 2011 22:42:52 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Can anaconda give the user a shell at any point of the installation? Is it possible to manually skip the automated steps? Last I checked, Anaconda was designed for binary installations, originally for RPM-based systems. Trying to shove source-based compilation into a binary installer seems like a lot of time, trouble, and hacking. Better to start from scratch. I hope you guys talk to releng about your CLI-based installer, if it gets off the ground. Since we'll need to figure out what's supported as an official install method. If you aren't worried about a canonical way of doing things with the existing media, then never mind. Either way, good luck. signature.asc Description: PGP signature
Re: [gentoo-dev] Wiki status
On Tue, 01 Mar 2011 01:17:18 +0100 Stefan Behte cr...@gentoo.org wrote: Hi list, seeing Donnie link to a GSOC page on en.gentoo-wiki.com, I was wondering about the status of our own, gentoo-hosted wiki. When gentoo-wiki.com had its major failure, I was very frustrated and thus have some concerns about planning GSOC or anything else there. There are 17 people listed on http://www.gentoo.org/proj/en/wiki/ and the last meeting seems to have been 10 months ago: so, what is the state of the project? What is the timeline for the wiki? Is the team still active at all? Could you be a bit more public about it or point me to an url if I missed something? Thanks! :) Why not email the wiki team, rather than everyone on the general -dev mailing list? signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites for sys-kernel-usermode-sources
On Wed, 13 Apr 2011 08:31:18 -0400 Daniel Gryniewicz d...@gentoo.org wrote: # Daniel Gryniewicz d...@gentoo.org (13 Apr 2011) # Masked for removal in 30 days. Functionality is merged into and maintained in # the upstream kernel. Use any kernel (e.g. gentoo-sources) instead. sys-kernel/usermode-sources Daniel Please read and advise the GDP on http://www.gentoo.org/doc/en/uml.xml http://www.gentoo.org/doc/en/gentoo-kernel.xml is easier to deal with; we'll just move usermode-sources to the previously provided section. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: split up media-sound/ category
On Tue, 21 Jun 2011 16:24:07 +0200 Michał Górny mgo...@gentoo.org wrote: Hello, As we discussed for a while, the media-sound/ category has grown very large and it may be a good idea to split it. Right now, it contains audio players, editing software, converters, sound systems and a lot of other utilities related to sound. Splitting that up would make looking up software easier for users (e.g. if I want to take a look at what audio players we have, I don't need to see all other programs). What do you think? What new category/-ies do you suggest? Whatever happened to implementing tags for the Portage tree? The idea behind tags was to avoid spamming users with more and more directories, especially for apps that are hard to categorize. Which, arguably, is most of them. We have tags for weblog content/topics; tags for ebuilds are also a good idea. Splitting up the media-* categories doesn't solve any problems for the packages that do many different things, whether encoding, playing, editing, wrapping, connecting, etc. Many media apps belong in 3 or 4 or more categories. Tags are the right solution for these, rather than being pigeonholed into just one category, which only reflects one use. signature.asc Description: PGP signature
Re: [gentoo-dev] The Python problem
On Mon, 27 Jun 2011 16:49:23 -0400 Mike Frysinger vap...@gentoo.org wrote: if you dont want multiple builds on your system, then dont install multiple versions of python. -mike This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-misc/dhcpv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 10 Jul 2011 19:05:42 +0300 Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (10 Jul 2011) # Dead upstream. Bugs #353788 and #348232 # Alternatives: # net-misc/dibbler # net-misc/dhcp[ipv6] # Masked for removal in 30 days net-misc/dhcpv6 Not cool. For a few reasons: 1. I had to delete significant sections of the ipv6 guide tonight, since there's no documentation for these alternatives. Now there's nothing on running an ipv6 dhcp server or client. 2. There are no more stable dhcp/ipv6 packages in the tree. This sucks, both for users that run stable, and for the documentation, since we're only supposed to cover stable packages. - - net-misc/dhcp doesn't get +ipv6 unless you emerge the ~arch version 4.x, and even then, there is NO documentation included on how to use it with ipv6. - - net-misc/dibbler only has ~arch and hardmasked versions available. Can anyone lend the GDP a hand and get us a couple of paragraphs on how to configure a dhcp/ipv6 server and client, similar to what we had in the guide? Ideally with a stable package, or maybe the maintainers could stabilize their ~arch alternatives. I hate to use Markos' Last Rites email as a jumping off point, but it's these kinds of removals, the kind that shaft our users and documentation maintainers, that make me throw up my hands in frustration and take another step toward retirement. Markos, I'm not singling you out; this has been going on for a long time now, with many, many current and former developers: package maintainers almost *never* look at the docs or contact the GDP when going through package removals. I would like this to change. :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4f1+gACgkQxPWMzpKk6kPmsgCgvix72X4GE0cSVoh10pUGERtk 0xQAn35U5d+2U9fni8FX75NlKIu4wZ10 =DmEh -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: net-misc/dhcpv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 15 Jul 2011 10:59:29 +0300 Markos Chandras hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (10 Jul 2011) # Dead upstream. Bugs #353788 and #348232 # Alternatives: # net-misc/dibbler # net-misc/dhcp[ipv6] # Masked for removal in 30 days net-misc/dhcpv6 Not cool. For a few reasons: 1. I had to delete significant sections of the ipv6 guide tonight, since there's no documentation for these alternatives. Now there's nothing on running an ipv6 dhcp server or client. Which documentation are you referring to? Sorry; meant to include the URI: http://www.gentoo.org/doc/en/ipv6.xml dhcpv6 has no stable keywords Really? I thought it did. Then that's something the GDP should have noticed when we initially added that section to the guide. True. I was to request stabilization as well. Thanks. I can keep this package in the tree long enough until there is an alternative documentation available. My point is not to frustrate users but to force them migrate to better alternatives. Moreover, remember that the dhcpv6 upstream is dead and dhcp[ipv6] is the official alternative. I don't quite see the point in supporting dhcpv6 anymore. I don't like the idea of keeping a dead package around, either. My main issue is that there's no documentation on using ipv6 configs with net-misc/dhcp, so I have nothing to add to the guide. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4g0A8ACgkQxPWMzpKk6kO19wCbBQBO9iJlWguLcysqTb5ULLv1 DK4AnjVRCrOWE3eHSuBnPtUOuWmZgCKR =UTmL -END PGP SIGNATURE-
[gentoo-dev] Re: mesa r600 gallium news item
On Thu, 25 Aug 2011 23:12:22 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Hello, Please see the attached news item for review. The news item should be published before mesa-7.11 goes stable. Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349 Best regards, Chí-Thanh Christopher Nguyễn what about updating the emul-linux-x86-* libraries to use gallium, too? they currently use the classic mesa, judging from the output of eselect mesa list. signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
On Fri, 11 Nov 2011 15:53:44 -0600 William Hubbs willi...@gentoo.org wrote: Hi all, http://bugs.gentoo.org/show_bug.cgi?id=389437 has prompted a discussion of whether or not we should use ifconfig in openrc to configure networking on linux systems. I'm not asking that we consider removing net-tools from systems, because there are tools there that we still need. In my view though, two of these tools (ifconfig and route), have been surpassed in functionality by iproute2's ip tool. So, what I am considering doing is dropping the ifconfig module from openrc and using iproute2 for all network configuration on linux systems. The other side of the discussion seems to be that openrc needs to work on minimal installations, so we need to continue supporting using ifconfig. I realize there would be a trade-off if I stop supporting linux's ifconfig and route in openrc, but how much of a trade-off? Would the benefits of iproute2 outweigh the down side of not supporting ifconfig and route on linux? What does everyone think? William i'm in favor of whatever doesn't force me and our users to install Yet Another Tool besides what's in the system set, and whatever doesn't result in a LOT of work for the GDP to update all of our documentation. there are dozens of places in all the docs that refer to ifconfig and the other utilities installed with sys-apps/net-tools. i'd really prefer it if i didn't have to learn a whole new set of tools syntax, and then had to rewrite all of our docs for them. ifconfig and net-tools work as-is; i've yet to see a compelling case for installing learning iproute. if net-tools isn't being dropped from the system set, don't force our users to install redundant utilities. signature.asc Description: PGP signature