Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Donnie Berkholz wrote:
> Lance Albertson wrote:
> | What if instead of having proj/en we did herd/en on www? Of course, that
> | doesn't help the whole "GuideXML is hard" bit. I like the idea of using
> | RST, but it doesn't seem very scalable at this time. Maybe, instead of
> | that, we created some kind of development site for herds (maybe
> | herds.g.o). Could be a place where herds put up status updates, specific
> | docs, draft docs, etc. Once things get established on that site, docs
> | could get moved to GDP if it were logical to do.
> 
> Really every herd should be either part of a project or in the process
> of creating a new one for themselves by now. There's no excuse, since
> the block on creating new projects disappeared.

The question I ask is ... does every herd have a project it fits under?
I doubt it. And if it doesn't, is it really considered a project? Or is
that just a generic name given now? I guess a see a distinction between
herds and projects that our current documentation url layout doesn't
cover it well. To me, it should have its own herd/fooherd layout
(example being www.gentoo.org/herd/en/netmon). Otherwise you're going to
confuse our users into thinking that herds are projects when they're
really just herds. Granted, some herds may be just a project, but I'm
mainly after the herds that have no real project to fit under.

I understand the block was lifted for projects, but that doesn't mean
herds should all should fit underneath proj/. I think we should open up
a similar space just for herds.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lance Albertson wrote:
| What if instead of having proj/en we did herd/en on www? Of course, that
| doesn't help the whole "GuideXML is hard" bit. I like the idea of using
| RST, but it doesn't seem very scalable at this time. Maybe, instead of
| that, we created some kind of development site for herds (maybe
| herds.g.o). Could be a place where herds put up status updates, specific
| docs, draft docs, etc. Once things get established on that site, docs
| could get moved to GDP if it were logical to do.

Really every herd should be either part of a project or in the process
of creating a new one for themselves by now. There's no excuse, since
the block on creating new projects disappeared.

| Now that leaves us to unofficial docs from users. I'm not sure where to
| put that. A public wiki poses a whole slew of issues I don't think we
| have enough staff to manage. But relying on gentoo-wiki isn't exactly
| the best avenue either. Having a site like this is like having another
| 'team' similar to the forums trying to maintain order/facts. There needs
| to be another solution that doesn't require as much effort on our part.
| I sadly can't think of an answer. I guess the real question is, is this
| that much of a problem/issue?

Are there any wikis with the same kind of spam-protection that a lot of
blogging software has, such as the crazy-looking picture you have to
type the word from, and required registration with a valid email address?

The combination of those two would do a lot to deter automated spamming,
although a determined person could still do damage if they're sitting in
front of the computer.

Some wiki's also support ACLs, which could help in this respect. For
example, xorg.freedesktop.org has some pages that are "immutable" and
can only be edited by a few people.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDw1qBXVaO67S1rtsRAsGhAJ4yjLfL7pk5hqCQgkKeoB7KQ1bd/QCggRx/
u4bFgzcQEHAZKYcOac3+3d4=
=F9Jt
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sven Vermeulen wrote:
| We have already received many bugs for documentation in /proj/* which is
| not GDPs. I had no issue with this as I hoped this would be a transient
| state where the documentation is eventually handed over to the GDP so that
| both the project /and/ GDP can further maintain the documents.

Seems like what would be useful is a metadata.xml-type thing for guides,
so they're assigned properly.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDw1oVXVaO67S1rtsRAi0EAJ0YOQHsMazZb0fxWfU6uvQNQ6Dk9gCgtKr3
SlWUS940a1n4/YPr1Tfq0hw=
=S+yA
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A New Linux Way

[Mike Frysinger]

On Monday 09 January 2006 22:40, Mark Stewart wrote:
> Please contact me if you are interested.

thank you captain douche

please unsubscribe yourself from our lists and never stop by again
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Sven Vermeulen wrote:
> On Sun, Jan 08, 2006 at 06:45:01PM +, Luis Medinas wrote:
> 
>>We could start a public wiki displaying all herds and projects. It would
>>be great to add some low level docs, herds/project goals, ideas and so.
>>Even the users could be allowed to edit and share information.
> 
> 
> I would personally welcome additional documentation, but if we're going to
> add an official Wiki for Gentoo, we're basically splitting the documentation
> development on many sides. 

So, maybe we should list the different type of documentation issues
we're facing today. It seems that there are several areas where Gentoo
could improve and speed up documentation on a few things.

 * The GDP docs
 * Herd specific docs/updates
 * Unofficial/draft docs from users/devs

Perhaps we should consider re-evaluating how we deal with documentation
for Gentoo to try and deal with the hodge-podge of documentation
scattered everywhere from numerous self-run trac installs, to self run
wikis of other kinds. Its really starting to hurt Gentoo in some aspect
because of the disjointness of those docs.

What if instead of having proj/en we did herd/en on www? Of course, that
doesn't help the whole "GuideXML is hard" bit. I like the idea of using
RST, but it doesn't seem very scalable at this time. Maybe, instead of
that, we created some kind of development site for herds (maybe
herds.g.o). Could be a place where herds put up status updates, specific
docs, draft docs, etc. Once things get established on that site, docs
could get moved to GDP if it were logical to do.

Now that leaves us to unofficial docs from users. I'm not sure where to
put that. A public wiki poses a whole slew of issues I don't think we
have enough staff to manage. But relying on gentoo-wiki isn't exactly
the best avenue either. Having a site like this is like having another
'team' similar to the forums trying to maintain order/facts. There needs
to be another solution that doesn't require as much effort on our part.
I sadly can't think of an answer. I guess the real question is, is this
that much of a problem/issue?

Who knows, its getting late in the night for me and I'm just starting to
think up crazy ideas :-)

In short: Do we need to re-evaluate Gentoo's documentation structure to
better fit the needs of of our users and developers?

Cheers-

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Sven Vermeulen]

On Sun, Jan 08, 2006 at 06:45:01PM +, Luis Medinas wrote:
> We could start a public wiki displaying all herds and projects. It would
> be great to add some low level docs, herds/project goals, ideas and so.
> Even the users could be allowed to edit and share information.

I would personally welcome additional documentation, but if we're going to
add an official Wiki for Gentoo, we're basically splitting the documentation
development on many sides. 

What used to be a (forced) monopoly for GuideXML becomes a set of GuideXML,
RST and Wiki. Although I have indeed read that the goal of the documents
differ, we are placing a boundary on what GDP should do and shouldn't.

We have already received many bugs for documentation in /proj/* which is
not GDPs. I had no issue with this as I hoped this would be a transient
state where the documentation is eventually handed over to the GDP so that
both the project /and/ GDP can further maintain the documents.

A wiki is nice, but don't forget that it only allows for online
documentation editing. I am one of those devs who develops his
documentation mostly off-line. There is also no quality assurance over a
wiki and not that many wikis have decent versioning tools (or they have them
but they're really awkward to use).

The Java team already uses the gentoo-wiki.com infrastructure, indeed an
unofficial wiki for official documentation. 

Wkr,
  Sven Vermeulen

-- 
  Gentoo Foundation Trustee  |  http://foundation.gentoo.org
  Gentoo Council Member  

  The Gentoo Project   <<< http://www.gentoo.org >>>


pgp9i29yzFCoL.pgp
Description: PGP signature

Re: [gentoo-dev] A New Linux Way

[Dale]

Dan Meltzer wrote:




Please don't spam other distrobutions mailing lists with your trash.  Thank you!
 






Personally, I would rather donate money to the one I am using and like 
than to $BUY$ and have to learn another distro.  I also went to the site 
and can't even figure out how to get the stupid thing.  Of course, I 
wouldn't any way.  I like Gentoo.  :D  What is this "subscription" you 
have to get to use it? 


Dale
:-)



--
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 
80GB hard drives.  Named Smoker
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.  
Named Swifty
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 224MBs of ram and a 2.5GB 
drive.  Named Pokey
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB 
SCSI drive.  Named Putput

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A New Linux Way

[Dan Meltzer]

On 1/9/06, Mark Stewart <[EMAIL PROTECTED]> wrote:
> Subject line:
>   A New Linux Way

Learn to send emails correctly?

>
> Text as follows:
>
> Hello fellow Linux Users!
>
> We here at SaviourLinux.com desire to create a united universal way.
> Please visit the website for more information, but here is the purpose:
>
>
> Saviour Linux is an easy and universal Linux distribution that pays
> community programmers.
>
> Saviour Linux is not just another distribution. Saviour Linux will be
> unified and run by the community. We will bring in a new business that
> gives out completely free software instead of closed source. All of our
> profit will come from services and it will pay volunteer programmers.
> Only a little of the profit will go towards overhead.
>
>
> Saviour Linux is Linux united. Every distribution can still be
> independent, but we wanted to help the community in a new way.
>
> Please contact me if you are interested.

Please don't spam other distrobutions mailing lists with your trash.  Thank you!
>
> Sincerely,
> Mark Stewart
>
>
>
> SaviourLinux.com
> Coordinator and Website Maintainer
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] A New Linux Way

[Mark Stewart]

Subject line:
  A New Linux Way

Text as follows:

Hello fellow Linux Users!

We here at SaviourLinux.com desire to create a united universal way. 
Please visit the website for more information, but here is the purpose:


Saviour Linux is an easy and universal Linux distribution that pays
community programmers.

Saviour Linux is not just another distribution. Saviour Linux will be
unified and run by the community. We will bring in a new business that
gives out completely free software instead of closed source. All of our
profit will come from services and it will pay volunteer programmers.
Only a little of the profit will go towards overhead.


Saviour Linux is Linux united. Every distribution can still be
independent, but we wanted to help the community in a new way.

Please contact me if you are interested.

Sincerely,
Mark Stewart



SaviourLinux.com
Coordinator and Website Maintainer

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New global USE flag - gs

[Drake Wyrm]

Lares Moreau <[EMAIL PROTECTED]> wrote:
> media-gfx/graphicsmagick:gs - enable ghostscript support
> media-gfx/imagemagick:gs - enable ghostscript support
> media-libs/urt:gs - Add support for postscript
> 
> Looking in these ebuilds, all:
> gs? ( virtual/ghostscript )

For how many of these might it make sense to use "ps - enable postscript
support" rather than "gs - enable ghostscript support"? If I understand
correctly, the consensus is that use flags should reflect the capability
enabled rather than the name of the library or package which provides
that capability.

-- 
That is not dead which can eternal lie,
And with strange eons even death may die.
  -- The Call of Cthulu, II. The Tale of Inspector Legrasse


pgpW27yZjvvk1.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Mike Frysinger]

On Monday 09 January 2006 11:56, Brian Harring wrote:
>Curl won't honor/use the cacerts package for example

it does actually, re-emerge it after ca-certificates
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Diego 'Flameeyes' Pettenò]

On Monday 09 January 2006 21:04, Tom Martin wrote:
> The devmanual has an an enormous number of links, citations and cross
> references. I'd imagine that's what really takes time to generate. For
> things like this, it would be very fast.
Might be good to test moinmoin's RST support then.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpVQ19lNU7hY.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Tom Martin]

On Mon, 9 Jan 2006 18:11:42 +0100
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:

> And IIRC ciaranm said it took quite a while to render the devmanual
> from RST to HTML, would be difficult to sync hourly then.

The devmanual has an an enormous number of links, citations and cross
references. I'd imagine that's what really takes time to generate. For
things like this, it would be very fast.


-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


signature.asc
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Grant Goodyear wrote:
> Diego 'Flameeyes' Pettenò wrote: [Sun Jan 08 2006, 11:59:40AM CST]
> 
>>I originally thought of putting it on my devspace, but using GuideXML
>>there is a bit tricky, at least for me (as xsltproc seems to refuse
>>working on the pure xml directly).
> 
> 
> I actually prefer devspace for these sorts of docs.  Every dev has their
> own space for that sort of thing, and they can use whatever
> easy-to-manage doc producing system that they want (within reason).
> Instead of "fixing" that problem, I think it would be better to fix the
> xsltproc issues you're having instead.  If you'll post what's happening
> to your doc, perhaps one of our trusty doc folks can help you out.

If there is something I can do on toucan to make things better, let me
know. I haven't heard much from anyone that something is broke about it.
I could setup gorg on toucan or something to make things better for such
things. Just create a bug so I can put it on my todo list.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Jan Kundrát]

Grant Goodyear wrote:
> Again, I like devspace for these things.  Of course, particularly useful
> docs would likely be adopted by the GDP (with the permission of the
> author, of course).

Thinking about legal issues (and about tracking all contributors among
developers) - please use CC-BY-SA [1] for your docs.

[1] http://creativecommons.org/licenses/by-sa/2.5

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Grant Goodyear]

Diego 'Flameeyes' Pettenò wrote: [Sun Jan 08 2006, 11:59:40AM CST]
> I originally thought of putting it on my devspace, but using GuideXML
> there is a bit tricky, at least for me (as xsltproc seems to refuse
> working on the pure xml directly).

I actually prefer devspace for these sorts of docs.  Every dev has their
own space for that sort of thing, and they can use whatever
easy-to-manage doc producing system that they want (within reason).
Instead of "fixing" that problem, I think it would be better to fix the
xsltproc issues you're having instead.  If you'll post what's happening
to your doc, perhaps one of our trusty doc folks can help you out.

> So I was thinking if we had a way to put some "how to fix" guides
> somewhere, on the lines of the ones written by soalr and vapier for
> hardened. A part the --as-needed thing, it might also be useful to put
> something about "how to solve parallel make issues" and similar things
> that are tricky but usually just requires little knowledge of tricks.

Again, I like devspace for these things.  Of course, particularly useful
docs would likely be adopted by the GDP (with the permission of the
author, of course).

-g2boojum-
--
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgppVuia9qUyz.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Diego 'Flameeyes' Pettenò]

On Monday 09 January 2006 18:11, Andrea Barisani wrote:
> Yeah it could be treated as a bug, I'd rather fix that by patching wget
> (--dont-be-a-pain-with-self-signed-certs yes) or anyway at *that* layer and
> not by adding ca-certificates as a DEPEND since it has other implications
> that we already discussed.
wgetrc can be changed to not bitch about it, or a switch can be added to the 
FETCHCOMMAND command (but it requires a newer version of wget as older don't 
understand it and bails out, the first is the ideal, IMHO, as people can 
still change that in their ~/.wgetrc).

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpQWUvvcmtdr.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Tom Martin]

On Mon, 9 Jan 2006 16:47:57 +
Tom Martin <[EMAIL PROTECTED]> wrote:

> On Mon, 9 Jan 2006 09:34:22 -0500
> Aron Griffis <[EMAIL PROTECTED]> wrote:
> 
> > Brian Harring wrote:[Sun Jan 08 2006, 09:16:36PM EST]
> > > Regardless, (imo) it's already been laid out why guideXML'ifying 
> > > everything doesn't totally work.  Three reasons...
> > > 
> > > A) bit of work required just to jot down a quick list of "this is 
> > > broke, fix it" that's going to be thrown out 2 weeks down the
> > > line.
> > 
> > I noticed Ciaran has been using RST for GLEP 42.  I wonder if it
> > would be a good alternative to guideXML in general.
> > 
> > http://docutils.sourceforge.net/rst.html
> > 
> > I realize this doesn't address the *rest* of what you said,
> > though...
> 
> I agree.
> 
> These little 'howtos' are potentially very short, and guideXML would
> be overkill. RST is absolutely perfect for this kind of thing: quick
> and easy to write, powerful, and legible in raw form. It's also easily
> converted to any number of other formats.
> 
> A new CVS repository containing these little howtos that is accessible
> with viewcvs would be perfect, if you ask me.
> 
> (big snip)

... And then Flameeyes showed me MoinMoin. It understands RST and can
also do XMLRPC. Best of all worlds.

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


signature.asc
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Brian Harring]

Sending this to the ml, tom already has heard the reasons but throwing 
them out for others to comment on...

On Mon, Jan 09, 2006 at 04:47:57PM +, Tom Martin wrote:
> > I realize this doesn't address the *rest* of what you said, though...



> These little 'howtos' are potentially very short, and guideXML would be
> overkill. RST is absolutely perfect for this kind of thing: quick and
> easy to write, powerful, and legible in raw form. It's also easily
> converted to any number of other formats.
Agreed.

> A new CVS repository containing these little howtos that is accessible
> with viewcvs would be perfect, if you ask me. There would be proper
> version control on the files and they would be read/write for
> developers and read-only for users (otherwise the potential of
> vandalism etc. is too high). This is, in my opinion, how things should
> be for these simple developer guides.
disagree. :)

Note my comments about allowing non gentoo personnel to modify the 
docs.  I'm not minting half devs just so they can do some doc work, 
nor is it efficient for trusted devs to be passing patches through me 
just because they haven't yet been around long enough where we mint 
'em.


> The whole wiki-for-everything idea really annoys me. It forces
> a web browser on me, and this is particularly naff when it comes to
> editing. It's also really bland and boring, and completely unoriginal.

Note that what's being pushed here is the desire for a faster model of 
doc developing;

GDP/guidexml docs are good for long term stable docs.

They suck royally however, if we're talking about developmental docs 
for portage where things move quickly.  Less work required to maintain 
the documentation, higher chance the docs will actually be up to 
date/maintained.  Note that's my opinion, I don't dislike guidexml, I 
just prefer to not dink around with it for docs that are going to be 
rapidly changing.


> I still haven't fixed the other two points Brian mentioned, but I don't
> really think they're all that serious. If a user sees an omission, he
> can drop a mail to the guy who wrote the guide. There's really no
> reason to file bugs for anything like this.

We're not talking about a guide here- two scenarios.

flameeyes rapid development of docs, improving the quality- area to 
hash out the doc before slapping it up in official docs (and no, 
labelling it unofficial doesn't fly when we're talking about 
initial hammering out of the doc).

Essentially, a chalkboard/whiteboard for projects- communal scratchpad 
of what the current issues are (and I mean *current*, that day), 
proposals for apis, use scenarios, rough design documents.

We could (and do) do this via devspace, but that suffers the exact 
issue I'm after addressing- not everyone involved can modify it (for 
devspace, only one person can modify it).

> Allowing universal r/w is
> asking for vandalism. As for the third point -- concurrency -- this is
> exactly what any VCS is supposed to fix. We live with it with the
> tree's CVS, I'm sure we can live with it for this.

Where exactly did I ask for universal r/w?  I've seen a lot of args 
against this based upon "joe idiot will screw up the page".  What I'm 
after is non gentoo personnel capable of handling the docs- does that 
mean everyone?  No.  It means people not minting people just so we can 
have them do a bit of doc work, essentially, nuking the overhead.

Again, vcs is worthless if you don't have access to it.  Non gentoo 
folks do not have access to the vcs, thus we're right back to my point 
for why a wiki is useful- we don't have to mint a couple dozen part 
time contributors as devs just so they can do their work.

Proposals/alternatives thus far are basically reinventing wiki's, just 
slower.  That's kind of a sign that people dislike wiki software 
they've seen- I've yet to see anyone level arguement against the model 
of doc development I'm after however.

So... if the core need isn't an issue, wth should we reinvent the 
wheel and create our own wiki analog?

~harring


pgpAknTOSAknI.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Diego 'Flameeyes' Pettenò]

On Sunday 08 January 2006 18:59, Diego 'Flameeyes' Pettenò wrote:
>   Okay let's forget the flames and talk about something related to
> practical development today :)
Sigh ok no practical development at this come out as a discussion/flame again.

What I was thinking of is _not_:
- a wiki writable by users;
- a CVS writable by non-devs;
- a replacement for GuideXML (I like it);
- a way to replace GDP (I was thinking of dev-level documentation);

What I was thinking was instead:
- a place where things can be drafted up before GDP submission if they want to 
handle dev docs, too;
- a place where devs can put their own dev guides, without changing the style 
of the site from the one in main Gentoo site;
- a place that does not require the strict belonging to a project to put 
guides into.

I like GuideXML, so I have no problem with writing small-to-medium guides with 
it, RST would be fine, too, but I don't want it to be plain text or ViewCVS 
only, GuideXML is in style with the rest of the site and it has printable 
version available, and it's Googlable. ViewCVS is too "raw" for user viewing, 
and there might be users interested in those guides. And IIRC ciaranm said it 
took quite a while to render the devmanual from RST to HTML, would be 
difficult to sync hourly then.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpW6yk0OucLA.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Andrea Barisani]

On Mon, Jan 09, 2006 at 06:03:03PM +0100, Jakub Moc wrote:
> 
> 9.1.2006, 17:28:04, Andrea Barisani wrote:
> 
> > On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
> >> 
> >> 9.1.2006, 17:12:31, Andrea Barisani wrote:
> >> 
> >> > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> >> 
> >> >> 
> >> >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
> >> >> If so should it be a 'no*certs' flag or a USE=cacerts ?
> >> 
> >> > USE=cacerts sounds the proper course of action to me.
> >> 
> >> NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
> >> realplayer thing again.
> 
> > It's the realplayer thing that should be fixed. Can't believe that
> > ca-certificates got relatively quiet as a PDEPEND because of that ;).
> 
> No, it's not, it's FETCHCOMMAND/wget thing. Would like to hear about
> alternatives besides those discussed ad nauseam in Bug 101457.
>

I know I read the bug. My remark wasn't a "strict" one.

> Realplayer does *not* depend on ca-certificates in ANY way, it's

That's kinda obvious.

> FETCHCOMMAND that's broken w/ unknown CA and self-signed certificates. Since
> not honoring self-signed certificates by default can be hardly considered as
> a bug, hence the depenency on ca-certificates in wget.
> 

Yeah it could be treated as a bug, I'd rather fix that by patching wget
(--dont-be-a-pain-with-self-signed-certs yes) or anyway at *that* layer and not 
by adding ca-certificates as a DEPEND since it has other implications that we 
already discussed.

-- 
Andrea Barisani <[EMAIL PROTECTED]>.*.
Gentoo Linux Infrastructure Developer  V
 (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^
  "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Kalin KOZHUHAROV]

Francesco Riosa wrote:
>> Kalin KOZHUHAROV wrote:
>> 
[...]
>> "{{{ A hypothetical example:
>> 
>> I used mysql-4.1.16-r30 and I have a locally encoded (say Shift_JIS)
>> database. I have DBD-mysql compiled against that and a package FOO using
>> that works as expected.
>> 
>> Some package wants >=mysql-5.0.0 and DBD-mysql, and because mysql is
>> SLOTed, portage says ok, emerges mysql-5.0.18-r30 and rebuilds
>> DBD-mysql against it.
> 
> 
> Oops *you* need to tell portage to rebuild DBD-mysql. Difficult that a
> package will want mysql >= something, but take this is an example, so
> it's ok.

Yup, /me bad. The usual way for a package using a language binding is to
depend on that bindig (dev-perl/DBD-mysql-VVV).

All my worries were for the case when the latest stable dev-perl/DBD-mysql
is compiled against the latest SLOTed mysql-5.1.x and is being used to
access data on an old (SLOTed or not; localhost or some remote host) server.
But I guess then the problem will be entirely in dev-perl/DBD-mysql being
unable to connect to older servers :-)

At this moment I should say "Sorry for the wasted bandwidth/time" :-|

[...]

> Better ?

Times better! Hypothetical problem is solved, thank you for your time!

Kalin.

-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:56:30, Luca Barbato wrote:

> Jakub Moc wrote:
>> 9.1.2006, 17:12:31, Andrea Barisani wrote:
>> 
>> 
>>>On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:

> Just add it as DEPEND and everybody would be fine, isn't it?

Not a realplayer issue (see the other mail).


-- 

jakub

pgpCrhzxTI4Gt.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:28:04, Andrea Barisani wrote:

> On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
>> 
>> 9.1.2006, 17:12:31, Andrea Barisani wrote:
>> 
>> > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
>> 
>> >> 
>> >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
>> >> If so should it be a 'no*certs' flag or a USE=cacerts ?
>> 
>> > USE=cacerts sounds the proper course of action to me.
>> 
>> NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
>> realplayer thing again.

> It's the realplayer thing that should be fixed. Can't believe that
> ca-certificates got relatively quiet as a PDEPEND because of that ;).

No, it's not, it's FETCHCOMMAND/wget thing. Would like to hear about
alternatives besides those discussed ad nauseam in Bug 101457.

Realplayer does *not* depend on ca-certificates in ANY way, it's
FETCHCOMMAND that's broken w/ unknown CA and self-signed certificates. Since
not honoring self-signed certificates by default can be hardly considered as
a bug, hence the depenency on ca-certificates in wget.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpcX6wvYqpUZ.pgp
Description: PGP signature

Re: [gentoo-dev] init scripts and custom signals

[Henrik Brix Andersen]

On Mon, Jan 09, 2006 at 04:32:28PM +, Roy Marples wrote:
> hostapd

I've just updated hostapd ~ARCH to use kill.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpysdQP3Z21L.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Luca Barbato]

Jakub Moc wrote:

9.1.2006, 17:12:31, Andrea Barisani wrote:



On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:




Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
If so should it be a 'no*certs' flag or a USE=cacerts ?




USE=cacerts sounds the proper course of action to me.



NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
realplayer thing again.



Just add it as DEPEND and everybody would be fine, isn't it?

lu

--

Luca Barbato

Gentoo/linux Developer  Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Brian Harring]

On Mon, Jan 09, 2006 at 05:28:04PM +0100, Andrea Barisani wrote:
> On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
> > 
> > 9.1.2006, 17:12:31, Andrea Barisani wrote:
> > 
> > > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> > 
> > >> 
> > >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
> > >> If so should it be a 'no*certs' flag or a USE=cacerts ?
> > 
> > > USE=cacerts sounds the proper course of action to me.
> > 
> > NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
> > realplayer thing again.
> 
> It's the realplayer thing that should be fixed. Can't believe that
> ca-certificates got relatively quiet as a PDEPEND because of that ;).

I bitched for exactly that; we can't mirror their files, and having 
the package non fetch restricted is questionable from a license 
standpoint anyways.

Either way, one thing that *should* be noted here is that this still 
doesn't totally fix the issue for realplayer.  Curl won't honor/use 
the cacerts package for example, so we still have the same bug, just 
different fetcher.

Adding cacerts to the pdepend effectively is expansion of allowed 
SRC_URI targets- right now we require all uri to be on standards ports 
(443, 80) for restricted networks.  Now, via this change, we require 
FETCHCOMMAND to be a binary that supports cacerts.

We also require any https proxy to support/allow cacerts also, if my 
understanding of https proxying is correct.

Finally, this also requires infra to now run with cacerts on for the 
master mirroring box.

Basically... I'm still against this change.  We require fetchers that 
support http, and support the standard chain of trust for https.  I 
don't like changing the restrictions just for a (bluntly) stupid 
upstream that forces downloads through https.

~harring


pgpgvMkDOSk3W.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Tom Martin]

On Mon, 9 Jan 2006 09:34:22 -0500
Aron Griffis <[EMAIL PROTECTED]> wrote:

> Brian Harring wrote:  [Sun Jan 08 2006, 09:16:36PM EST]
> > Regardless, (imo) it's already been laid out why guideXML'ifying 
> > everything doesn't totally work.  Three reasons...
> > 
> > A) bit of work required just to jot down a quick list of "this is 
> > broke, fix it" that's going to be thrown out 2 weeks down the line.
> 
> I noticed Ciaran has been using RST for GLEP 42.  I wonder if it would
> be a good alternative to guideXML in general.
> 
> http://docutils.sourceforge.net/rst.html
> 
> I realize this doesn't address the *rest* of what you said, though...

I agree.

These little 'howtos' are potentially very short, and guideXML would be
overkill. RST is absolutely perfect for this kind of thing: quick and
easy to write, powerful, and legible in raw form. It's also easily
converted to any number of other formats.

A new CVS repository containing these little howtos that is accessible
with viewcvs would be perfect, if you ask me. There would be proper
version control on the files and they would be read/write for
developers and read-only for users (otherwise the potential of
vandalism etc. is too high). This is, in my opinion, how things should
be for these simple developer guides.

I'd also propose that these things are listed in a flat directory
hierarchy, more or less. I'd rather the names of the files were
prefixed with the project/herd name and then dumped in the same
directory.It would encourage 'reading around' a bit (you know,
like when you look up a word in a dictionary and end up learning
another few words by accident). This can only be a good thing (I'll
admit that, say, a documentation developer stumbling across the
Gentoo/MIPS stabilisation criteria is not in reality that useful
useful, but in the majority of cases this rule holds true).

The whole wiki-for-everything idea really annoys me. It forces
a web browser on me, and this is particularly naff when it comes to
editing. It's also really bland and boring, and completely unoriginal.
They're also hard to navigate. If I was going to write one of these
guides I'd rather put a .txt on my devspace than bother with the
devwiki.

I still haven't fixed the other two points Brian mentioned, but I don't
really think they're all that serious. If a user sees an omission, he
can drop a mail to the guy who wrote the guide. There's really no
reason to file bugs for anything like this. Allowing universal r/w is
asking for vandalism. As for the third point -- concurrency -- this is
exactly what any VCS is supposed to fix. We live with it with the
tree's CVS, I'm sure we can live with it for this.

I guess it's also important to distinguish what constitutes a little
development 'howto' for some common task, rather than a full-on GDP
guide.

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


signature.asc
Description: PGP signature

Re: [gentoo-dev] init scripts and custom signals

[Roy Marples]

On Monday 09 January 2006 14:22, Mike Frysinger wrote:
> On Monday 09 January 2006 07:32, Roy Marples wrote:
> > It's been brought to my attention that dnsmasq and acpid use
> > start-stop-daemon to send custom signals such as HUP. While this works
> > with baselayout-1.11, it does not work with baselayout-1.12
>
> is this due to changes we are making in Gentoo ?  i.e. we've just been
> importing ssd from Debian for the most part and i dont really think we
> should be diverging in behavior ...
> -mike

If so then it's undocumented behaviour - s-s-d's manpage expects --stop to 
stop the daemon. In the same way that s-s-d expects the daemon to actually be 
a daemon instead of a shell script that launches daemons.

This change was made months ago, has been in ~ARCH for months and only now 
just appears? This has been in a released baselayout since March 2005. lol

A quick grep through the tree shows the following packages using 
start-stop-daemon to send a HUP signal

capisuite
dnsmasq (has been changed to kill, but not rev bumped)
freeradius
netkit-timed
proxyper
hostapd
acpid (has been changed to kill in its ~ARCH version)

Whereas all other init scripts that send a HUP use kill or killall - examples 
are spamassassin and syslog-ng

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo Linux Developer


pgpam2kox5mw6.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Andrea Barisani]

On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
> 
> 9.1.2006, 17:12:31, Andrea Barisani wrote:
> 
> > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> 
> >> 
> >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
> >> If so should it be a 'no*certs' flag or a USE=cacerts ?
> 
> > USE=cacerts sounds the proper course of action to me.
> 
> NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
> realplayer thing again.

It's the realplayer thing that should be fixed. Can't believe that
ca-certificates got relatively quiet as a PDEPEND because of that ;).

-- 
Andrea Barisani <[EMAIL PROTECTED]>.*.
Gentoo Linux Infrastructure Developer  V
 (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^
  "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Kalin KOZHUHAROV]

Andrea Barisani wrote:
> On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> 
>>On Mon, 2006-01-09 at 16:55 +0100, Andrea Barisani wrote:
>>
>>>Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief
>>>exchange of emails already happened on -dev but since it's not so easy to
>>>track it I'm lagging behind on this) I would like to express that I really
>>>don't like the fact that we are "trusting" cacert.org certs (among others)
>>>without providing it as a choice.
>>>
>>>Despite all the political views that we can throw in favour of a "cacert.org
>>>are trying to make the SSL certs world less evil" argument this is some major
>>>policy that we are supporting and it shouldn't be taken that lightly (I don't
>>>remember such a major confrontation about this) and I really don't think this
>>>should be a default policy but rather user's choice. Technically cacert.org
>>>is not a recognized CA in the "proper" way (and don't point that a proper CA
>>>is a lame concept and a snake oil thing..this is not the point).
>>
>>>[CCing [EMAIL PROTECTED] because this concerns the team as well imho.]
>>>
>>>Just my 2 eurocent.
>>>
>>>P.S.
>>>I know that firefox doesn't trust /etc/ssl/certs by default, dunno about 
>>>konqueror. The point is still relevant though.
>>
>>
>>Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
>>If so should it be a 'no*certs' flag or a USE=cacerts ?
> 
> 
> USE=cacerts sounds the proper course of action to me.

I was just `emerge world -vDatu --newuse` on some ~x86 boxen and I saw the new 
(at least to me)
cacert ebuild getting pulled. Although, I support cacert.org and use it 
occasionally, I also think
making it the default is a bit too quick for now. Making it a useflag might be 
better.

Are there any other packages like cacert now? Didn't see any, but time will 
tell.
Might be a better solution to have a more general ebuild that installs CA certs 
and it will have
different (local) useflags.

Just my 2 non-dev Japanese yen :-)

Kalin.
-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init scripts and custom signals

[Henrik Brix Andersen]

On Mon, Jan 09, 2006 at 09:22:59AM -0500, Mike Frysinger wrote:
> is this due to changes we are making in Gentoo ?  i.e. we've just been 
> importing ssd from Debian for the most part and i dont really think we should 
> be diverging in behavior ...

Both dnsmasq and acpid have been fixed to use `kill` instead - but I
wonder how many other ebuilds are "abusing" s-s-d this way...

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpthXq9FZkx9.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:12:31, Andrea Barisani wrote:

> On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:

>> 
>> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
>> If so should it be a 'no*certs' flag or a USE=cacerts ?

> USE=cacerts sounds the proper course of action to me.

NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
realplayer thing again.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpsEZgc6Hws7.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Henrik Brix Andersen]

On Mon, Jan 09, 2006 at 05:12:31PM +0100, Andrea Barisani wrote:
> USE=cacerts sounds the proper course of action to me.

If this is implemented, please make it USE=cacert, not USE=cacerts.

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpdOkpI8qd8n.pgp
Description: PGP signature

[gentoo-dev] Re: ca-certificates PDEPEND

[Andrea Barisani]

On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> On Mon, 2006-01-09 at 16:55 +0100, Andrea Barisani wrote:
> > Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief
> > exchange of emails already happened on -dev but since it's not so easy to
> > track it I'm lagging behind on this) I would like to express that I really
> > don't like the fact that we are "trusting" cacert.org certs (among others)
> > without providing it as a choice.
> > 
> > Despite all the political views that we can throw in favour of a "cacert.org
> > are trying to make the SSL certs world less evil" argument this is some 
> > major
> > policy that we are supporting and it shouldn't be taken that lightly (I 
> > don't
> > remember such a major confrontation about this) and I really don't think 
> > this
> > should be a default policy but rather user's choice. Technically cacert.org
> > is not a recognized CA in the "proper" way (and don't point that a proper CA
> > is a lame concept and a snake oil thing..this is not the point).
> 
> > [CCing [EMAIL PROTECTED] because this concerns the team as well imho.]
> > 
> > Just my 2 eurocent.
> > 
> > P.S.
> > I know that firefox doesn't trust /etc/ssl/certs by default, dunno about 
> > konqueror. The point is still relevant though.
> 
> 
> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
> If so should it be a 'no*certs' flag or a USE=cacerts ?

USE=cacerts sounds the proper course of action to me.

-- 
Andrea Barisani <[EMAIL PROTECTED]>.*.
Gentoo Linux Infrastructure Developer  V
 (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^
  "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: ca-certificates PDEPEND

[solar]

On Mon, 2006-01-09 at 16:55 +0100, Andrea Barisani wrote:
> Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief
> exchange of emails already happened on -dev but since it's not so easy to
> track it I'm lagging behind on this) I would like to express that I really
> don't like the fact that we are "trusting" cacert.org certs (among others)
> without providing it as a choice.
> 
> Despite all the political views that we can throw in favour of a "cacert.org
> are trying to make the SSL certs world less evil" argument this is some major
> policy that we are supporting and it shouldn't be taken that lightly (I don't
> remember such a major confrontation about this) and I really don't think this
> should be a default policy but rather user's choice. Technically cacert.org
> is not a recognized CA in the "proper" way (and don't point that a proper CA
> is a lame concept and a snake oil thing..this is not the point).

> [CCing [EMAIL PROTECTED] because this concerns the team as well imho.]
> 
> Just my 2 eurocent.
> 
> P.S.
> I know that firefox doesn't trust /etc/ssl/certs by default, dunno about 
> konqueror. The point is still relevant though.


Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
If so should it be a 'no*certs' flag or a USE=cacerts ?
-- 
solar <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] ca-certificates PDEPEND

[Andrea Barisani]

Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief
exchange of emails already happened on -dev but since it's not so easy to
track it I'm lagging behind on this) I would like to express that I really
don't like the fact that we are "trusting" cacert.org certs (among others)
without providing it as a choice.

Despite all the political views that we can throw in favour of a "cacert.org
are trying to make the SSL certs world less evil" argument this is some major
policy that we are supporting and it shouldn't be taken that lightly (I don't
remember such a major confrontation about this) and I really don't think this
should be a default policy but rather user's choice. Technically cacert.org
is not a recognized CA in the "proper" way (and don't point that a proper CA
is a lame concept and a snake oil thing..this is not the point).

[CCing [EMAIL PROTECTED] because this concerns the team as well imho.]

Just my 2 eurocent.

P.S.
I know that firefox doesn't trust /etc/ssl/certs by default, dunno about 
konqueror. The point is still relevant though.

-- 
Andrea Barisani <[EMAIL PROTECTED]>.*.
Gentoo Linux Infrastructure Developer  V
 (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^
  "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Aron Griffis]

Brian Harring wrote:[Sun Jan 08 2006, 09:16:36PM EST]
> Regardless, (imo) it's already been laid out why guideXML'ifying 
> everything doesn't totally work.  Three reasons...
> 
> A) bit of work required just to jot down a quick list of "this is 
> broke, fix it" that's going to be thrown out 2 weeks down the line.

I noticed Ciaran has been using RST for GLEP 42.  I wonder if it would
be a good alternative to guideXML in general.

http://docutils.sourceforge.net/rst.html

I realize this doesn't address the *rest* of what you said, though...

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgpz1VyIiCw8i.pgp
Description: PGP signature

Re: [gentoo-dev] init scripts and custom signals

[Mike Frysinger]

On Monday 09 January 2006 07:32, Roy Marples wrote:
> It's been brought to my attention that dnsmasq and acpid use
> start-stop-daemon to send custom signals such as HUP. While this works with
> baselayout-1.11, it does not work with baselayout-1.12

is this due to changes we are making in Gentoo ?  i.e. we've just been 
importing ssd from Debian for the most part and i dont really think we should 
be diverging in behavior ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Kalin KOZHUHAROV wrote:
> Francesco Riosa wrote:
>> Kalin KOZHUHAROV wrote:
[...]
>
> Now this is in my mind, a mind that looks for bugs and troubles before
they come out.

That's exactly what I'm looking for ;-)

>
> If mysql is slotted (and you said it it will be soon), what will
happen to software that use mysql
> bindings, for example dev-perl/DBD-mysql?

will happen that the bindings need to be fixed at first,
fex see bug #114925 "dev-perl/DBD-mysql-3.0002_p4 fails to compile"
where Malcolm Lashley give a patch to add backward compatibility.

TODO: threat include files like libraries, also mind about "mysql_config"

>
> "{{{ A hypothetical example:
>
> I used mysql-4.1.16-r30 and I have a locally encoded (say Shift_JIS)
database. I have DBD-mysql
> compiled against that and a package FOO using that works as expected.
>
> Some package wants >=mysql-5.0.0 and DBD-mysql, and because mysql is
SLOTed, portage says ok,
> emerges mysql-5.0.18-r30 and rebuilds DBD-mysql against it.

Oops *you* need to tell portage to rebuild DBD-mysql.
Difficult that a package will want mysql >= something, but take this is
an example, so it's ok.

>
> The probable result is that package FOO will be silently broken
because of incompatible changes
> between mysql-4.1 and mysql-5.0 ...
>
> "}}}

Not so probable, or at least at a lesser degree than what you think.
The major part of incompatibilityes are absorbed from the additional
layer offered by DBD-mysql.
The client app will still work with DBD-mysql, not directly with the server.
Ah and by the way remember that the server running will continue to be
4.1, and that default datadir will be different for 4.1 and 5.0 (it's
insane to make two different versions work with the same data)

Charset side there is additional support in MySQL 5.0 to support UTF-16,
but the big jump has been done between 4.0 and 4.1, now it should be
just more easy.

>
> Actually reading on
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html there are
quite
> many incompatible changes.

Take a look at the changes:

Server Changes:
- The indexing order for end-space in TEXT  columns ...
  Unlikely to affect many apps.
- For BINARY columns, the pad value and how ...
  Unlikely to affect many apps.
- MyISAM and InnoDB  tables created with DECIMAL ...
  Database only change, not visible outside (well not exatly but with a
good approx.)
- Incompatible change: As of MySQL 5.0.3, the server by default no
longer loads user-defined functions...
  Unlikely to affect many apps.
- Incompatible change: The update log was removed in MySQL 5.0 ...
  Don't affect apps, learn to use "mysqlbinlog"
- Support for the ISAM storage engine has been removed ...
  Well it's real time to switch to myisam
- Support for RAID options in MyISAM tables has been removed ...
  Don't affect apps.

SQL Changes:
- Previously, a lock wait timeout caused InnoDB to roll ...
  Look like a bug fixed
- The namespace for triggers has changed in MySQL 5.0.10. ...
  Don't affect 4.1
- As of MySQL 5.0.15, the CHAR() function returns a binary string rather
than ...
  Filtered from DBD-mysql layer
- Beginning with MySQL 5.0.12, natural joins and joins with USING,
including outer join variants, are processed according to the SQL:2003
standard. The changes include elimination of redundant output columns
for NATURAL joins and joins specified with a USING clause and proper
ordering of output columns. The precedence of the comma operator also
now is lower compared to JOIN.
  LIKELY TO AFFECT MANY APPS THAT USE SQL, however the fixes are cheap
as this nonsense
  1 + 2 - 3 ==> ( 1 + 2 ) * 3
  there is an operator that changed precedence.

>
> Although this may be a problem for DBD-mysql, it will be exposed after
mysql is SLOTed...
> Or shall we SLOT dev-perl/DBD-mysql as well?
> And what about ruby, python (any other language bindings?)?

No at all, every one of these must be able to compile on whatever
version of mysql,
examples of how this could be done are at bugs 85783, 85810, 85829,
85843, 85844, 114925.

Better ?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init scripts and custom signals

[Roy Marples]

On Monday 09 January 2006 12:40, Henrik Brix Andersen wrote:
> On Mon, Jan 09, 2006 at 12:32:32PM +, Roy Marples wrote:
> > So, the question now must be, do we allow start-stop-daemon to defy
> > calling logic and NOT stop a daemon? How do we know we're not supposed to
> > stop the daemon based on a custom signal? The answer is we can't. So
> > instead of
> >
> > start-stop-daemon --stop -s HUP -p /var/run/dnsmasq.pid
> >
> > we need to write
> >
> > kill -s HUP $(< /var/run/dnsmasq.pid)
>
> ... or implement a stand-alone --signal (or -s) in start-stop-daemon,
> allowing it to be called like this:
>
> start-stop-daemon --signal HUP -p /var/run/dnsmasq.pid

Which would only work in baselayout-1.12 as the start-stop-daemon binary 
demands either a --start or --stop flag.

I've not tried it, but using --start --signal HUP should work with 
baselayout-1.12 as we don't muck around with --start. It also makes more 
sense in my eyes.

I dunno, call me old fashioned but you use the kill command to send signals to 
daemons.

Either way, the init scripts have to change.

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo Linux Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init scripts and custom signals

[Henrik Brix Andersen]

On Mon, Jan 09, 2006 at 12:32:32PM +, Roy Marples wrote:
> So, the question now must be, do we allow start-stop-daemon to defy calling 
> logic and NOT stop a daemon? How do we know we're not supposed to stop the 
> daemon based on a custom signal? The answer is we can't. So instead of
> 
> start-stop-daemon --stop -s HUP -p /var/run/dnsmasq.pid
> 
> we need to write
> 
> kill -s HUP $(< /var/run/dnsmasq.pid)

... or implement a stand-alone --signal (or -s) in start-stop-daemon,
allowing it to be called like this:

start-stop-daemon --signal HUP -p /var/run/dnsmasq.pid

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgp3PdrvUTohS.pgp
Description: PGP signature

[gentoo-dev] init scripts and custom signals

[Roy Marples]

Hi

It's been brought to my attention that dnsmasq and acpid use start-stop-daemon 
to send custom signals such as HUP. While this works with baselayout-1.11, it 
does not work with baselayout-1.12

The start-stop-daemon-binary has to have either a --start or --stop option. 
Now I read this as two simple statements.
1) I want to start daemon foo
2) I want to stop daemon foo

The aforementioned init scripts want option 3
3) I want to stop daemon foo with signal HUP
Which is perfectly valid. However, HUP is not a stop signal and they expect it 
to process the signal and not stop.

baelayout-1.12 is a bit more strict about things. If you ask something to 
--stop it stops regardless.

So, the question now must be, do we allow start-stop-daemon to defy calling 
logic and NOT stop a daemon? How do we know we're not supposed to stop the 
daemon based on a custom signal? The answer is we can't. So instead of

start-stop-daemon --stop -s HUP -p /var/run/dnsmasq.pid

we need to write

kill -s HUP $(< /var/run/dnsmasq.pid)

Thanks

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo Linux Developer
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] OpenPGP keyservers

[Paweł Madej]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

In portage there is only one keyserver named Onak. It is quite unusable
for me, so I've looked for other keyservers. I've found three quite
common on the internet:

CKS - http://www.cryptnet.net/fsp/cks/
SKS - http://www.nongnu.org/sks/
PKS - http://www.mit.edu/people/marc/pks/

My question is if some of you had any experience with those apps? I plan
to make ebuild for them all to give a choice for users, but if you think
that it is wrong idea, all comments welcome.

I wrote emails to all authors of above apps with questions if they are
developed/ if they agree to place them into portage tree, and now
waiting for answers.


- --
Paweł Madej aka Nysander
http://quanteam.info  | http://forum-farmaceutyczne.org
http://nysander.quanteam.info | http://wiki.quanteam.info
GPG key: 5861680B | keyserver: http://pgp.mit.edu
key fingerprint: 34A9 B8BB DFA2 4F0B EFB5  CE50 82F4 8C82 5861 680B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDwk/BgvSMglhhaAsRAsG2AKCSR9rGW2fPyilW+u5A3i6S9p7gKwCeJjQe
ORKoOrVQD0JnLWfD2XwCsQ4=
=WLLq
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Diego 'Flameeyes' Pettenò]

On Monday 09 January 2006 03:14, Marius Mauch wrote:
> Find a nice place in www.gentoo.org/proj/
Okay that's what I try to do most of the time, in this specific case, I'm 
probably going to ask for space to qa project (as fixing --as-needed problems 
or parallel make issues and such is imho QA-related). This still does not 
resolve issues for other things like the quilt guide I tried to start writing 
(but then I'm not so good at explain the user/dev part of it).

But at least I'll probably have time to spend on the other stuff for a while 
if Sven allows me :)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpxkXHgVjPB5.pgp
Description: PGP signature

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Kalin KOZHUHAROV]

Francesco Riosa wrote:
> Kalin KOZHUHAROV wrote:
> [...]
> 
>>>An eselect-mysql module has been prepared to create simlinks for the
>>>desired version of mysql making easy to switch between them (hopefully)
>>>
>>>The libraries (libmysqlclient & co) don't follow this logic and the
>>>higher version is always the default (similarly to sys-libs/db).
>>
>>So how does this affect packages that use say dev-perl/DBD-mysql ?
>>
>>If they can only use mysql-5, then the will be broken if they connect to a 
>>mysql-4 server using non
>>UTF-8 encoding. (bad wording, but generally speaking, there is an 
>>inconsistence in character
>>encoding betweet mysql-4 and mysql-5 that DOES break things on non ISO-8859-1 
>>encoded databases)
>>
> 
> [...]
> 
> At the moment 4.0 is not slotted, only >= 4.1 are.
> 
> The fact that is effectively possible to use a non slotted 4.0 together
>  with 4.1 and 5.0 does not mean that it should be used that way.
> 
> Does this answer your question ?
Well, not exactly :-)
Let me try to make it clearer.

Now this is in my mind, a mind that looks for bugs and troubles before they 
come out.

If mysql is slotted (and you said it it will be soon), what will happen to 
software that use mysql
bindings, for example dev-perl/DBD-mysql?

"{{{ A hypothetical example:

I used mysql-4.1.16-r30 and I have a locally encoded (say Shift_JIS) database. 
I have DBD-mysql
compiled against that and a package FOO using that works as expected.

Some package wants >=mysql-5.0.0 and DBD-mysql, and because mysql is SLOTed, 
portage says ok,
emerges mysql-5.0.18-r30 and rebuilds DBD-mysql against it.

The probable result is that package FOO will be silently broken because of 
incompatible changes
between mysql-4.1 and mysql-5.0 ...

"}}}

Actually reading on 
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html there are quite
many incompatible changes.

Although this may be a problem for DBD-mysql, it will be exposed after mysql is 
SLOTed...
Or shall we SLOT dev-perl/DBD-mysql as well?
And what about ruby, python (any other language bindings?)?

Kalin.
-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support

[Luca Barbato]

Stuart Herbert wrote:



Which packages do you want to add the srvdir global USE flag for?



fenice has support for it in at configure level, gentoo-webroot-default 
could enjoy it as well as apache may provide an alternate default too.


lu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Kalin KOZHUHAROV wrote:
[...]
>>
>> An eselect-mysql module has been prepared to create simlinks for the
>> desired version of mysql making easy to switch between them (hopefully)
>>
>> The libraries (libmysqlclient & co) don't follow this logic and the
>> higher version is always the default (similarly to sys-libs/db).
> 
> So how does this affect packages that use say dev-perl/DBD-mysql ?
> 
> If they can only use mysql-5, then the will be broken if they connect to a 
> mysql-4 server using non
> UTF-8 encoding. (bad wording, but generally speaking, there is an 
> inconsistence in character
> encoding betweet mysql-4 and mysql-5 that DOES break things on non ISO-8859-1 
> encoded databases)
> 
[...]

At the moment 4.0 is not slotted, only >= 4.1 are.

The fact that is effectively possible to use a non slotted 4.0 together
 with 4.1 and 5.0 does not mean that it should be used that way.

Does this answer your question ?

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New global USE flag - gs

[Lares Moreau]

media-gfx/graphicsmagick:gs - enable ghostscript support
media-gfx/imagemagick:gs - enable ghostscript support
media-libs/urt:gs - Add support for postscript

Looking in these ebuilds, all:
gs? ( virtual/ghostscript )

Please make global.
-- 
Lares Moreau <[EMAIL PROTECTED]>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net |
Gentoo x86 Arch Tester |   ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |  Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support

[Stuart Herbert]

Hi Luca,

On 1/9/06, Luca Barbato <[EMAIL PROTECTED]> wrote:
> that's an useflag you may use it or not, webapps use webapp-config that
> already handles /srv w/out any problem, having the base webroot using
> srvdir would be nice so you spare a couple of mv but that's all...
>
> lu

I haven't read GLEP 20 for some time now, so my apologies if this is
clear in my original draft.

My original intention for the srvdir USE flag was to cope with these
two situations:

a) Apps that have compile-time paths that can't be overridden w/
runtime configuration
b) Apps that have runtime configuration, which we could setup to work
with /srv out of the box.

I don't believe that it's practical to specify a layout for /srv that
fits everyone.  I use /srv// on some of the boxes I
look after, but some of them run /srv///
instead.

Which packages do you want to add the srvdir global USE flag for?

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list