[gentoo-dev] PowerPC Resources at OSU

[R0b0t1]

Hello,

(This will be almost a duplicate on the PPC list, but now having more
information I am sending it to the BSD list as well.)

I apologize in advance if I did anything improper. I misunderstood
desultory when I asked him what to do earlier. Originally I was
unwilling to try to associate myself with Gentoo for the purpose of
this request but I wasn't referred to anyone who could fill out the
form "for" me.

Having requested OpenPOWER hosting from OSUOSL on Gentoo's behalf, I
was informed that hosting is already provided to the project.
Consequently I have two questions:

1) May I have access to a/the POWER server, or some other suitable
POWER resource? If not,
2) is anyone available to verify that I am associated with the project
or that I will use the resources for project related work?


For any comment to OSU, such as to request closure of the ticket or
that they go ahead with allocating the VM, please comment and I will
forward the support ticket to you.


My intent is to experiment with the PowerPC architecture, specifically
features found on newer POWER processors and servers. It is unlikely I
will ever get to do this on my own as the machines run $10k-$30k. I
requested services from OSU because GCC was not able to accommodate my
request for hypervisor access on their system.

However, having finally found the resources I've been looking for this
whole time, it looks like OSU's nodes are virtualized and won't be
able to do exactly what I want anyway (i.e. the GCC sysadmin was
misinformed), so I may have accidentally wasted people's time and
potentially tarnished Gentoo's reputation. I will make amends as best
I can.

IBM is willing to fund a node for my use and OSU is willing to deploy
it pending contact from Gentoo leadership. If there is a machine that
already exists that I would not disrupt, I would have no problems
working on existing resources instead if that seems reasonable. The
GCC server(s) are probably adequate, however I am having lots of
problems setting up a prefix on those systems because they use CentOS.
I am trying to fix bugs as best as I am able but it is starting to
look hopeless.

Excess resources on the donated OSU OpenPOWER machine could be offered
to other developers or used to run a Tinderbox. It may be a good idea
to do those things on the already existing machine(s).

Respectfully,
 R0b0t1

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Dean Stephens]

On 09/11/17 13:08, Michał Górny wrote:
> Any comments?
> 
Instead of spreading documentation back out across multiple sites and
changing workflow for a subset of it yet again, why not migrate the wiki
to e.g. gollum [1]? Given that it supports markdown, ReStructuredText,
and mediawiki markup and uses git for a backend.

[1] https://github.com/gollum/gollum

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[R0b0t1]

Hello friends,

On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny  wrote:
> W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael
> Orlitzky napisał:
>> On 09/11/2017 01:08 PM, Michał Górny wrote:
>> > Hi,
>> >
>> > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
>> > than Wiki, put in a nice git repo.
>> >
>>
>> I generally agree with you that wiki markup is terrible and that a text
>> editor and a git repo is The Right Way to do things (with Jekyll or
>> whatever to push it to the web). But in my experience, crappy and easy
>> is a better way to get people to contribute. When I've taken wiki
>> documents and moved them into git repos, more often than not I become
>> the sole contributor, and otherwise-technical people just start emailing
>> me their contributions (which decrease greatly in frequency).
>
> [...]
>
> Then, you can just take www.gentoo.org and run it locally. It takes
> a little more effort but jekyll is really trivial to set up and run
> locally. Then you see it exactly how it's gonna look on g.o.
>

I previously suggested Gollum and think I should suggest it again.
Gollum provides features relevant to a Wiki setting including web
editing. It would not require pages be rewritten and can render
MediaWiki that is maintained in a Git repository. It should be all of
the positives with no negatives.

Please refer to a statement by a project contributor and the original
author: https://github.com/gollum/gollum/issues/712.

Respectfully,
 R0b0t1

[gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Aaron Bauman]

On Monday, September 11, 2017 3:43:13 AM EDT Sergei Trofimovich wrote:
> On Sun, 10 Sep 2017 22:18:08 +
> 
> bugzilla-dae...@gentoo.org wrote:
> > DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> > whose email is mentioned below. To comment on this bug, please visit:
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=621130
> > 
> > Aaron Bauman  changed:
> >What|Removed |Added
> > 
> > --
> > --> 
> >  CC|sp...@gentoo.org|
> > 
> > --- Comment #16 from Aaron Bauman  ---
> > sparc was dropped to exp.
> > 
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f1
> > 2313a2925fcadd177a9
> [ CCed gentoo-dev@ to raise general awareness ]
> 
> Why do you need to drop sparc@ from CC on all the bugs?
> 
> It takes away possibility from users using sparc@ to report
> test status easily. Even after the bug is closed.
> 
> sh@ and s390@ are also exp profiles and CC is one of mechanisms
> to ask arch teams to try keywording/stablereq.

You're right.  Fixed.



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

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Michael Orlitzky]

On 09/11/2017 05:06 PM, Michał Górny wrote:
> 
> Example of GitHub rendering:
> https://github.com/mgorny/glep-draft/blob/preamble-test/glep-0001.rst
> 
> IMO this beats the preview/editing capabilities MediaWiki gave us.
> 

If that's how we get an offline preview, I'm not sold =P

I can run MediaWiki locally too, and keep the source in a git repo. Your
other methods of getting a local preview don't sound significantly
easier than that -- at least, not enough so to justify throwing
everything out and starting all over again.

It looks like we're just treading water here, but I can live with it
either way.

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Michał Górny]

W dniu pon, 11.09.2017 o godzinie 22∶56 +0200, użytkownik Michał Górny
napisał:
> W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael
> Orlitzky napisał:
> > On 09/11/2017 01:08 PM, Michał Górny wrote:
> > > Hi,
> > > 
> > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
> > > than Wiki, put in a nice git repo.
> > > 
> > 
> > I generally agree with you that wiki markup is terrible and that a text
> > editor and a git repo is The Right Way to do things (with Jekyll or
> > whatever to push it to the web). But in my experience, crappy and easy
> > is a better way to get people to contribute. When I've taken wiki
> > documents and moved them into git repos, more often than not I become
> > the sole contributor, and otherwise-technical people just start emailing
> > me their contributions (which decrease greatly in frequency).
> 
> Rich already answered this in detail, so I'll skip it.
> 
> > Will it be possible to build the GLEP rst files locally, and view the
> > output exactly as it would appear on the website? I ask because, so long
> > as you don't want to be able to preview the result, you can already
> > write MediaWiki markup into a text file locally. The offline "live
> > preview" ability is the killer feature of RST as I see it.
> 
> Of course yes. However, the exactness of result depends on how much
> effort you put into it.
> 
> The 'easy way' is rst2html.py (dev-python/docutils). It will give you
> a rough rendering with a standard style, i.e. kinda ugly but enough to
> see if everything works as expected. You'll also see the preamble as big
> mumbo-jumbo on top.
> 
> Then, there's glep.py (dev-python/docutils-glep) which adds preamble
> parsing, table of contents and some styling. AFAICS it needs a bit
> handiwork (copying a stylesheet to a relative directory) but it gives
> nice old-school rendering.
> 
> Then, you can just take www.gentoo.org and run it locally. It takes
> a little more effort but jekyll is really trivial to set up and run
> locally. Then you see it exactly how it's gonna look on g.o.
> 
> As a side note, we may also rename GLEPs to .rst. Then, GitHub will also
> provide out-of-the-box rendering of them.
> 

Example of GitHub rendering:
https://github.com/mgorny/glep-draft/blob/preamble-test/glep-0001.rst

IMO this beats the preview/editing capabilities MediaWiki gave us.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Michał Górny]

W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael
Orlitzky napisał:
> On 09/11/2017 01:08 PM, Michał Górny wrote:
> > Hi,
> > 
> > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
> > than Wiki, put in a nice git repo.
> > 
> 
> I generally agree with you that wiki markup is terrible and that a text
> editor and a git repo is The Right Way to do things (with Jekyll or
> whatever to push it to the web). But in my experience, crappy and easy
> is a better way to get people to contribute. When I've taken wiki
> documents and moved them into git repos, more often than not I become
> the sole contributor, and otherwise-technical people just start emailing
> me their contributions (which decrease greatly in frequency).

Rich already answered this in detail, so I'll skip it.

> Will it be possible to build the GLEP rst files locally, and view the
> output exactly as it would appear on the website? I ask because, so long
> as you don't want to be able to preview the result, you can already
> write MediaWiki markup into a text file locally. The offline "live
> preview" ability is the killer feature of RST as I see it.

Of course yes. However, the exactness of result depends on how much
effort you put into it.

The 'easy way' is rst2html.py (dev-python/docutils). It will give you
a rough rendering with a standard style, i.e. kinda ugly but enough to
see if everything works as expected. You'll also see the preamble as big
mumbo-jumbo on top.

Then, there's glep.py (dev-python/docutils-glep) which adds preamble
parsing, table of contents and some styling. AFAICS it needs a bit
handiwork (copying a stylesheet to a relative directory) but it gives
nice old-school rendering.

Then, you can just take www.gentoo.org and run it locally. It takes
a little more effort but jekyll is really trivial to set up and run
locally. Then you see it exactly how it's gonna look on g.o.

As a side note, we may also rename GLEPs to .rst. Then, GitHub will also
provide out-of-the-box rendering of them.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Robin H. Johnson]

On Mon, Sep 11, 2017 at 01:29:38PM -0400, Michael Orlitzky wrote:
> Will it be possible to build the GLEP rst files locally, and view the
> output exactly as it would appear on the website? I ask because, so long
> as you don't want to be able to preview the result, you can already
> write MediaWiki markup into a text file locally. The offline "live
> preview" ability is the killer feature of RST as I see it.
Yes, this capability existed in the old CVS repo, along with the glep.py
tool that was part of dev-python/docutils.

'make' was sufficient to trigger the build. It would be nice to ensure
that the HTML build process was still easily accessible.

glep.py was a tiny wrapper for rst2html.py, which should be even easier
to get working now, since it can take arguments rather than needing
python overrides.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Rich Freeman]

On Mon, Sep 11, 2017 at 10:29 AM, Michael Orlitzky  wrote:
>
> But in my experience, crappy and easy
> is a better way to get people to contribute. When I've taken wiki
> documents and moved them into git repos, more often than not I become
> the sole contributor, and otherwise-technical people just start emailing
> me their contributions (which decrease greatly in frequency).
>

I'd tend to agree if people could actually edit stuff on the Wiki.
The problem is that there is really no way to do the equivalent of a
pull request or other review process on a Wiki.

Either we open pages up, in which case we have to watch them for
changes we don't want.  Or we don't open them up, in which case
suggesting patches is a royal pain.

I've wanted to propose more significant changes to the handbook and it
is hard to do because I can't just offer one big patch that people can
comment on.  I could start making little changes here and there but
until they're all done it will be inconsistent, and it makes it harder
to influence the overall direction.

-- 
Rich

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Kristian Fiskerstrand]

On 09/11/2017 07:29 PM, Michael Orlitzky wrote:
> I generally agree with you that wiki markup is terrible and that a text
> editor and a git repo is The Right Way to do things (with Jekyll or
> whatever to push it to the web). But in my experience, crappy and easy
> is a better way to get people to contribute. 

I generally agree with this as well, but I don't like that we're
shifting back and forth as much as we do, which is a further hindrance.
At some point we just need to decide on something and go with it,
whether that is Wiki, RST or LaTeX..

The accessibility issues of wiki review and editing is a reasonable
argument, but we probably don't want to rush a change again.

Maybe we should start by defining a set of criteria / RFP for how we
would like the GLEP process to be and the format required?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Michael Orlitzky]

On 09/11/2017 01:08 PM, Michał Górny wrote:
> Hi,
> 
> TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
> than Wiki, put in a nice git repo.
> 

I generally agree with you that wiki markup is terrible and that a text
editor and a git repo is The Right Way to do things (with Jekyll or
whatever to push it to the web). But in my experience, crappy and easy
is a better way to get people to contribute. When I've taken wiki
documents and moved them into git repos, more often than not I become
the sole contributor, and otherwise-technical people just start emailing
me their contributions (which decrease greatly in frequency).

Will it be possible to build the GLEP rst files locally, and view the
output exactly as it would appear on the website? I ask because, so long
as you don't want to be able to preview the result, you can already
write MediaWiki markup into a text file locally. The offline "live
preview" ability is the killer feature of RST as I see it.

[gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[Michał Górny]

Hi,

TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
than Wiki, put in a nice git repo.

Bug: https://bugs.gentoo.org/628098


A short bit of history
==

A long time ago, in a gal... oh wait. Back in the old good days GLEPs
were reStructuredText files stored in our CVS repo (along with the GLEP
project page). The idea closely resembles the one used for PEPs
in Python. Similarly to the Python project, we had a docutils plugin to
convert GLEPs into 'nice' HTML, and so on, and so on.

Then there was the wiki boom, and GLEPs were wikified as part of that.
This brings us to where we are now.


Problems with wiki
==

I've already listed them in detail [1]. The most relevant points, copied
from the bug [2]:

> 1. Lack of proper review platform and merge capability. We end up
> reinventing the wheel poorly by copying articles and requesting review
> of that. Then GLEP editors move them back eating history and sometimes
> resulting in even worse failures like including a temporary subpage in
> GLEP namespace [a]. Getting a GLEP in place sometimes takes GLEP
> editors over *a month* during which time there is not even a clear
> indication that a GLEP has update pending.
> 
> 2. The wiki form does not really fit GLEPs. Note that RFCs are plain
> text files. PEPs use reStructuredText which is also pretty close to
> plain text. MediaWiki GLEPs are only mildly readable as plain text,
> and sometimes end up referring to external templates or other
> materials. They are not stand-alone, and they are hard to copy to use
> outside the wiki.
> 
> 3. MediaWiki is not very good at accessibility. It's not convenient
> for anything more complex than quick article edits, and it ends up
> being real PITA for people with disabilities [b].
>
> [...]
> [a]:https://wiki.gentoo.org/wiki/GLEP:73/VerificationAlgo
> [b]:https://archives.gentoo.org/gentoo-project/message/01fc23841c98670b2419a8638f97ec0b


The target layout
=

What I'd like to do is to restore the 'old school' file-based layout,
albeit in a bit more modern form. The idea is that GLEPs will be stored
as reStructuredText files in a dedicated git repository. The rendered
HTML versions will be available from our main site.

This simple solution will introduce a number of advantages:

a. the original source text of GLEPs will be once more readable,
and useful without the HTML rendering or external templates; for reviews
we wouldn't have to resort to a web browser,

b. everyone will be able to clone the GLEP repo and work on their
branches locally, then GLEP editors will be able to merge/cherry-pick
the changes to master without discarding history,

c. it will be possible to work on GLEPs without using a web browser or
having Internet access.


The masterplan
==

The plan on introducing the changes follows:

1. Convert the old GLEP repository from CVS to git (done [3]),

2. Prepare www.g.o to render GLEPs (done [4]),

3. Convert the one GLEP that was written in GuideXML to reST,

4. Update GLEPs from wiki,

5. Update GLEP-1/2 for the new-old workflow,

6. Profit!

For steps 3 onwards I'd gladly accept some help. If someone wants to
help, please contact me and I'll help you get started. Otherwise, I will
just update them at my own pace, as time permits.


Any comments?

[1]:https://archives.gentoo.org/gentoo-project/message/bf6cdaeb6c9c689b32e1f0c55447ca5d
[2]:https://bugs.gentoo.org/628098
[3]:https://github.com/mgorny/glep-draft
[4]:https://github.com/mgorny/www-gentoo-org (gleps branch)

-- 
Best regards,
Michał Górny

[gentoo-dev] [PATCH 2/2] multiprocessing.eclass: add tests for float values

[Mike Gilbert]

Also fix the test function to output the correct var for failures.

Bug: https://bugs.gentoo.org/630626
---
 eclass/tests/multiprocessing_makeopts_loadavg.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/tests/multiprocessing_makeopts_loadavg.sh 
b/eclass/tests/multiprocessing_makeopts_loadavg.sh
index a03bf0ca8799..d17d7734b9f2 100755
--- a/eclass/tests/multiprocessing_makeopts_loadavg.sh
+++ b/eclass/tests/multiprocessing_makeopts_loadavg.sh
@@ -15,7 +15,7 @@ test-makeopts_loadavg() {
tend 1 "Mismatch between MAKEOPTS/cli: '${indirect}' != 
'${direct}'"
else
[[ ${direct} == "${exp}" ]]
-   tend $? "Got back: ${act}"
+   tend $? "Got back: ${direct}"
fi
 }
 
@@ -35,6 +35,8 @@ tests=(
999 "-kl"
4 "-kl4"
5 "-kl 5"
+   2.3 "-l 2.3"
+   999 "-l 2.3.4"
 )
 for (( i = 0; i < ${#tests[@]}; i += 2 )) ; do
test-makeopts_loadavg "${tests[i]}" "${tests[i+1]}"
-- 
2.14.1

[gentoo-dev] [PATCH 1/2] multiprocessing.eclass: make loadavg regex work for float values

[Mike Gilbert]

Bug: https://bugs.gentoo.org/630626
---
v2: Reject "-l 2.3.4"

 eclass/multiprocessing.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 50368e35ea93..b6e92976f73e 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -120,7 +120,7 @@ makeopts_loadavg() {
# This assumes the first .* will be more greedy than the second .*
# since POSIX doesn't specify a non-greedy match (i.e. ".*?").
local lavg=$(echo " $* " | sed -r -n \
-   -e 
's:.*[[:space:]](-[a-z]*l|--(load-average|max-load)[=[:space:]])[[:space:]]*([0-9]+|[0-9]+\.[0-9]+).*:\3:p'
 \
+   -e 
's:.*[[:space:]](-[a-z]*l|--(load-average|max-load)[=[:space:]])[[:space:]]*([0-9]+(\.[0-9]+)?)[[:space:]].*:\3:p'
 \
-e 
"s:.*[[:space:]](-[a-z]*l|--(load-average|max-load))[[:space:]].*:${2:-999}:p")
# Default to ${inf} since the default is to not use a load limit.
echo ${lavg:-${2:-999}}
-- 
2.14.1

[gentoo-dev] Last rites: app-editors/qwriter, dev-util/kscope, dev-util/monkeystudio, dev-util/universalindentgui

[Michael Palimaka]

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628224.
app-editors/qwriter

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628228.
dev-util/kscope

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628230.
dev-util/monkeystudio

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628234.
dev-util/universalindentgui

[gentoo-dev] On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

On Sun, 10 Sep 2017 22:18:08 +
bugzilla-dae...@gentoo.org wrote:

> DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> whose email is mentioned below. To comment on this bug, please visit:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=621130
> 
> Aaron Bauman  changed:
> 
>What|Removed |Added
> 
>  CC|sp...@gentoo.org|
> 
> --- Comment #16 from Aaron Bauman  ---
> sparc was dropped to exp.
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f12313a2925fcadd177a9

[ CCed gentoo-dev@ to raise general awareness ]

Why do you need to drop sparc@ from CC on all the bugs?

It takes away possibility from users using sparc@ to report
test status easily. Even after the bug is closed.

sh@ and s390@ are also exp profiles and CC is one of mechanisms
to ask arch teams to try keywording/stablereq.

-- 

  Sergei


pgpyTAG6aMsvb.pgp
Description: Цифровая подпись OpenPGP