https://meta.wikimedia.org/wiki/Participation:Support
If you want to speak or volunteer at a conference, and you need some
help with costs, check out our Participation Support program. It offers
participation support to Wikimedia community members, i.e. volunteers
contributing to Wikimedia projects such as MediaWiki, for non-Wikimedia
events.
Participation support is reimbursement covering travel, accommodation
and incidental expenses as necessary, in relation with participating in
(as distinct from merely attending) an event or activity.
So, for example, you could apply for Participation Support if you wanted to:
* help staff the open source booth[0] at the Grace Hopper conference,
October 3-6 [1]
* present a poster at Grace Hopper India in December (call closes
September 15th [2])
* speak at the Strata Conference in February (call for talks closes
Sept 30 [3])
If you need ideas for talks, check out the Presentations archive on
wikitech.wikimedia.org[4], and to see what conferences are coming up, I
like the LWN calendar[5].
[0] http://systers.org/systers-dev/doku.php/ghc12fossbooth
[1] http://gracehopper.org/2012/
[2]
http://gracehopper.org.in/2012/participate/call-for-participation-poster-se…
[3] http://strataconf.com/strata2013/
[4] https://wikitech.wikimedia.org/view/Presentations
[5] https://lwn.net/Calendar/
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Seems it's the only host currently using ECDSA, and the corresponding RR
is missing in the DNS. Hence:
jimmy@vangogh:~$ ssh ortelius.toolserver.org
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
1a:02:b1:fb:19:61:63:ec:29:69:e1:46:fd:fa:21:12.
Please contact your system administrator.
Update the SSHFP RR in DNS with the new host key to get rid of this message.
Last login: Thu Sep 6 12:55:43 2012 from vangogh.jimmyxu
Rules: https://wiki.toolserver.org/view/Rules
Documentation: https://wiki.toolserver.org/view/Getting_started
This system is a web server, not a login server. You may log into this
system for web-related tasks, but tools must not be run here.
Next general maintenance window: Wed, 14.03, 19:00-23-59 UTC.
Your account will expire on Saturday, 10 November 2012.
jimmy@ortelius:~$
--
Jimmy Xu
multichill@willow:~$ screen -rd
There is no screen to be detached.
multichill@willow:~$ uptime
12:09pm up 3:42, 15 users, load average: 1.79, 2.82, 2.86
multichill@willow:~$ last | grep reboot | head -2
reboot system boot Thu Sep 6 08:27
reboot system down Thu Sep 6 08:24
Why was willow rebooted? I can't find an announcement of any maintenance
or incident.
Maarten
Forwarding from wikitech-l.
-------- Original Message --------
Subject: [Wikitech-l] HTML5, it's a coming (again)!
Date: Wed, 5 Sep 2012 23:06:15 +0100
From: Sam Reed <reedy(a)wikimedia.org>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
To: <wikitech-l(a)lists.wikimedia.org>
It's been a long time coming (for the nth time..), but we're scheduling a
deployment of HTML5 across the Wikimedia cluster [1]. This is set for Monday
17th September at 18:00-20:00 UTC [2].
The intention is to set $wgHtml5 [3] to true everywhere. It's been running
on MediaWiki.org and our 2 test wikis for quite a while, and other sites
like translatewiki.net with no issues.
The intention is to leave it enabled unless it causes major problems. If
you're running an application that screen scrapes, shame on you; you've had
enough notice to get it fixed! ;)
Now is the time to fix up your scripts and programs (where necessary), tell
your friends!
Sam
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
[2] http://wikitech.wikimedia.org/view/Software_deployments#Week_of_Sept_17
[3] https://www.mediawiki.org/wiki/Manual:$wgHtml5
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello all,
if you never heard of puppet before, you can stop reading now :-).
From time to time I get asked how normal users can help with the
administration of the toolserver.
One way to do that now is to help us with puppet. The toolserver used puppet
for the solaris-servers for some time already and I spent several weeks to use
it also for linux. Because I had never used puppet before I had to learn it
from scratch and I'm sure I made some mistakes and broke a few things – but it
works now more or less.
Three weeks ago I have put our puppet-configuration into svn, to make the
progress more comprehensible; you can find it at [1] and a fisheye-view at [2].
You can help in the following ways:
*If you see a bug in jira asking for a change that will be make by puppet
(like installing a program, fixing a script or changing a config-file): attach a
diff.
*Help clean-up the puppet-config.
*Improve the puppet-config.
*Document about it in the wiki.
At the moment only the roots can submit to the repository, but I can imaging
to give write-access to regulars in future.
Last notice: If you find something like a password or a key or anything else
that you believe should not be public in the svn-repository: Please send me a
PRIVATE mail (not to this mailinglist!) – thank you very much.
Sincerely,
DaB.
[1] https://svn.toolserver.org/svnroot/puppet/
[2] https://fisheye.toolserver.org/browse/Puppet
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
I'm getting a 502 Bad Gateway error when trying to access any of the
toolserver websites, except for the wiki which appears to simply time
out. status.toolserver.org says it's up, could someone check into this?
--
----
User:Hersfold
hersfoldwiki(a)gmail.com
Just something odd I noticed while reviewing the SGE job success emails
for MIMEStatBot: When the script runs on a Solaris host, the "Max vmem"
value is consistently between 20 and 25 M, but on Linux it jumps up to
over 160 M.
Furthermore, the same effect can be reproduced with a much simpler test
script. Compare:
vyznev@willow:~$ perl -e 'system "uname -a; ps -o comm,vsz -p $$"'
SunOS willow 5.10 Generic_147441-19 i86pc i386 i86pc Solaris
COMMAND VSZ
perl 6632
vyznev@nightshade:~$ perl -e 'system "uname -a; ps -o comm,vsz -p $$"'
Linux nightshade 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012
x86_64 GNU/Linux
COMMAND VSZ
perl 104364
What's going on here? It it just an accounting difference, or does a
Perl process on Linux really consume over 100 megabytes more memory than
on Solaris?
--
Ilmari Karonen
Hello everyone,
I would like to try and update an apache module (mod_tile for serving
map tiles [1]) on Ptolemy, which still operates on Solaris. After fixing
a bunch of standard portability issues with the source code, I have run
into a problem that I am not sure about.
With the standard compile options, the build fails with:
Undefined first referenced
symbol in file
__stack_chk_fail_local ./.libs/dir_utils.o (symbol scope
specifies local binding)
ld: fatal: Symbol referencing errors. No output written to
./.libs/mod_tile.so
The suggested fix for this issue seems to be to add -fno-stack-protector
to the CFLAGS. After figuring out how to pass that to the apache build
system it does now seem to compile fine. (if one tries to do that during
the ./configure stage, ./configure fails by complaining that the
C-compiler can't produce an executable. Possibly because ./configure
uses the sun compiler rather than gcc which doesn't support
-fno-stack-protector?)
However, the apache build system (apxs) claims that apache on ptolemy
was built with stack protection. Does it matter if a module is built
without stack protection while apache is? Is there a way to test out if
the built module works correctly with the installed apache? Is there a
better way to fix this compile issue?
Currently I just compiled it from source in the project home directory.
Would it have to be "ported" to ts-spec to install it on ptolemy?
Thanks,
Kai
[1] http://svn.openstreetmap.org/applications/utils/mod_tile/