Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-18 Thread Joshua Saddler
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...

2013-01-18 Thread Joshua Saddler
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

2013-08-21 Thread joshua saddler
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

2009-10-02 Thread Joshua Saddler
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?

2009-10-03 Thread Joshua Saddler
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?

2009-10-03 Thread Joshua Saddler
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?

2009-10-03 Thread Joshua Saddler
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

2009-10-04 Thread Joshua Saddler
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

2009-10-09 Thread Joshua Saddler
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

2009-10-11 Thread Joshua Saddler
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

2009-10-13 Thread Joshua Saddler
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

2009-10-13 Thread Joshua Saddler
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

2009-10-26 Thread Joshua Saddler
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

2009-12-02 Thread Joshua Saddler
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

2009-12-08 Thread Joshua Saddler
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

2009-12-15 Thread Joshua Saddler
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

2009-12-25 Thread Joshua Saddler
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

2009-12-26 Thread Joshua Saddler
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

2010-02-16 Thread Joshua Saddler
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

2010-02-16 Thread Joshua Saddler
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?

2010-02-28 Thread Joshua Saddler
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

2010-03-03 Thread Joshua Saddler
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

2010-03-03 Thread Joshua Saddler

 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

2010-03-05 Thread Joshua Saddler
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

2010-03-05 Thread Joshua Saddler
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

2010-03-05 Thread Joshua Saddler
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

2010-03-05 Thread Joshua Saddler
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

2010-03-07 Thread Joshua Saddler
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?

2010-03-09 Thread Joshua Saddler
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

2010-03-24 Thread Joshua Saddler
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

2010-03-24 Thread Joshua Saddler
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

2010-03-24 Thread Joshua Saddler
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

2010-03-24 Thread Joshua Saddler
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

2010-03-28 Thread Joshua Saddler
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?

2010-04-03 Thread Joshua Saddler
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

2010-04-04 Thread Joshua Saddler
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?

2010-04-04 Thread Joshua Saddler
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

2010-04-04 Thread Joshua Saddler
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

2010-04-04 Thread Joshua Saddler
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?

2010-05-14 Thread Joshua Saddler
-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?

2010-05-29 Thread Joshua Saddler
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.

2010-07-11 Thread Joshua Saddler
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

2012-03-28 Thread Joshua Saddler
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

2010-07-18 Thread Joshua Saddler
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

2010-07-20 Thread Joshua Saddler
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

2010-07-20 Thread Joshua Saddler
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)

2010-07-26 Thread Joshua Saddler
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

2010-08-16 Thread Joshua Saddler
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

2010-08-16 Thread Joshua Saddler
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

2010-08-17 Thread Joshua Saddler
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

2010-08-24 Thread Joshua Saddler
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

2010-08-24 Thread Joshua Saddler
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

2010-08-24 Thread Joshua Saddler
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

2010-09-20 Thread Joshua Saddler
-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

2010-09-20 Thread Joshua Saddler
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

2010-09-26 Thread Joshua Saddler
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

2010-09-26 Thread Joshua Saddler
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

2010-12-01 Thread Joshua Saddler
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

2010-12-01 Thread Joshua Saddler
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)

2011-02-09 Thread Joshua Saddler
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

2011-02-28 Thread Joshua Saddler
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

2011-04-13 Thread Joshua Saddler
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

2011-06-22 Thread Joshua Saddler
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

2011-06-28 Thread Joshua Saddler
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

2011-07-15 Thread Joshua Saddler
-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

2011-07-15 Thread Joshua Saddler
-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

2011-08-26 Thread Joshua Saddler
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

2011-11-11 Thread Joshua Saddler
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