[gentoo-dev] PowerPC Resources at OSU
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
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
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
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
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
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
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
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
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
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
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
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
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
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 (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
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
