Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

2013-06-11 Thread Alex Legler
On 11.06.2013 13:05, Theo Chatzimichos wrote:
> On Tuesday, June 11, 2013 12:20:20 Sven Vermeulen wrote:
>> "Jason A. Donenfeld"  wrote:
>>> On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler  wrote:
 - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an

   initial wiki version of the document
>>>
>>> What is the current status of such a tool?
>>
>> It is a script (xslt) that can be used with xsltproc to convert large chunks
>> into wiki style. It isn't perfect though thus still requires manual review,
>> but it is doable.
>>
>> I *think* I committed one to the repo a while ago. If not, I'll do so soon
>> (I have one in my own repo just for this purpose).
> 
> How about an ebuild please?
> 

Optional. I intend to expose this as a web site/service.

-- 
Alex Legler 
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

2013-06-11 Thread Theo Chatzimichos
On Tuesday, June 11, 2013 12:20:20 Sven Vermeulen wrote:
> "Jason A. Donenfeld"  wrote:
> >On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler  wrote:
> >> - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an
> >> 
> >>   initial wiki version of the document
> >
> >What is the current status of such a tool?
> 
> It is a script (xslt) that can be used with xsltproc to convert large chunks
> into wiki style. It isn't perfect though thus still requires manual review,
> but it is doable.
> 
> I *think* I committed one to the repo a while ago. If not, I'll do so soon
> (I have one in my own repo just for this purpose).

How about an ebuild please?

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


Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

2013-06-11 Thread Sergey Popov
10.06.2013 19:15, Alex Legler пишет:
> On 10.06.2013 14:36, Sergey Popov wrote:
>> 09.06.2013 18:22, Alex Legler пишет:
>>> I'd appreciate some input on below plan to move project pages to the Wiki:
>>>
>>> Motivation
>>> --
>>>
>>> The main motivation is to reduce the contents on the main website,
>>> allowing for an easier makeover. Also, the Wiki exposes the contents and
>>> an editing capability to more people, allowing for better collaboration.
>>> Finally, this is an opportunity for projects to go through the contents
>>> in their project spaces and update/remove outdated contents as well
>>> Gentoo as a whole to remove orphaned projects.
>>
>> Err, i do not want to say that wiki is not suite for this purpose, but
>> what's wrong with current situation? Is there something wrong with gorg?
> 
> The software is unmaintained, and the website template is next to
> unmaintainable. I could go on a bit more about this, but I think these
> two points *alone* justify moving away from it.
> 
>> Well, it is not always clear how to use some of it's features, but apart
>> of that, why we should migrate to wiki?
>>
>> Just to clear orphaned project pages?
> 
> No, I described multiple points. Again:
>  - Less contents on www.g.o -> we can much more easily relaunch it
>  - Users can more easily contribute to project documentation
>  - Update/purge project documentation
>  - Remove orphaned projects
> 

I did not know that gorg is not maintained. So yeah, in that case, i
understand your decision.

>>
>> Why we can not just have official project pages, maintained as usual
>> through gorg and additional info in wiki(if it is needed, for example,
>> like we do on Gentoo Qt project page?
>>
> 
> In case it wasn't clear enough yet: This is step 1 of n to get rid of
> gorg and GuideXML for the website (read: not main docs) aspects of Gentoo.
> Running two project page venues increases maintenance instead of
> lowering it. I intend to have less work after this change, not more.
> 
> Do you have any concerns beyond 'never change a running system'?
> 

For now - no, i am not. Thanks for clearing things for me.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

2013-06-11 Thread Sven Vermeulen


"Jason A. Donenfeld"  wrote:

>On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler  wrote:
>> - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an
>>   initial wiki version of the document
>
>
>What is the current status of such a tool?

It is a script (xslt) that can be used with xsltproc to convert large chunks 
into wiki style. It isn't perfect though thus still requires manual review, but 
it is doable.

I *think* I committed one to the repo a while ago. If not, I'll do so soon (I 
have one in my own repo just for this purpose).

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.



[gentoo-dev] How to spread intltool fixes to all packages

2013-06-11 Thread Pacho Ramos
Hello

Because of:
https://bugs.gentoo.org/show_bug.cgi?id=432848

We discovered an old bug affecting intltool that causes prefix of
localedir to be always hardcoded to the same location instead of
respecting configure flags. 

The patch is fixed by intltool upstream in their master branch but still
no new version was released including it. Anyway, we now have
dev-util/intltool-0.50.2-r1 with the bug fixed.

The problem of this issue (and most involving intltool) is that we need
to run:
intltoolize --copy --automake --force
(it doesn't seem to trigger maintainer mode in all ebuilds I have tried,
then, doesn't look to require eautoreconf to be run)

for all packages to get new and fixed ${S}/po/Makefile.in.in copied to
the sources, otherwise bundled file is used and, then, the one unfixed.
As it's unreliable to ping all upstreams involving intltool (they are a
ton) and this kind of problem will likely re-appear again in the future
(since the Makefile.in.in will be fixed in intltool upstream tarball but
will take a lot of time to reach all affected packages) we were
considering to run above command always at eclass level -> that way we
would stop using bundled ${S}/po/Makefile.in.in and, then, we would
always use the one provided by our intltool package (that should get
fixed and updated more often).

Other possible solution would be to use ELT-PATCHES to achieve that, but
I am still unsure about how would it work.

What are your thoughts?