Name- rakesh rana s/o- jagdish rana vill- barkagaon(rana muhalla) Po+ps- barkagaon dist- hazaribag state- jharkhand pin code- 825311
11 Dec
2011
11 Dec
'11
8:19 a.m.
----------
Sent from my Nokia phone
------Original message------
From: <mediawiki-l-request(a)lists.wikimedia.org>
To: <mediawiki-l(a)lists.wikimedia.org>
Date: Saturday, December 10, 2011 11:27:43 PM GMT+0000
Subject: MediaWiki-l Digest, Vol 99, Issue 8
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
or, via email, send a message with subject or body 'help' to
mediawiki-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MediaWiki-l digest..."
Today's Topics:
1. Re: Problem updating mediawiki (Brion Vibber)
2. Re: runjobs.php question (Fred Bauder)
3. [MediaWiki-l] Skin-Synagonism (Kaseluris-Nikos-1959)
4. Re: [MediaWiki-l] Skin-Synagonism (K. Peachey)
5. Re: Login error,<nocookiesforlogin> (Platonides)
6. Re: Memory Leak Issue (Platonides)
7. Re: incorrect mime type detection (Platonides)
8. Re: Context weirdness (Platonides)
9. Re: incorrect mime type detection (Jens Wille)
----------------------------------------------------------------------
Message: 1
Date: Fri, 9 Dec 2011 10:49:09 -0800
From: Brion Vibber <brion(a)pobox.com>
Subject: Re: [Mediawiki-l] Problem updating mediawiki
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Message-ID:
<CAFnWYTm1QvbudBHdQXU6HsNdjk4O5WTBC3BJA=z-cpzwts=wZg(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Dec 9, 2011 at 10:34 AM, Marlen Caemmerer <caemmerer(a)monoro.de>wrote;wrote:
Yes. I just wanted to confirm if it was sending the cookies.
Unlike what you report, I do get a wikidb_session cookie (and it is
indeed marked as secure, $wgCookieSecure is defaulting to true from the
https access)
Still, filling a random user & password, I get the same error you reported.
Your setup _should_ work, these errors are usually related to php not
being able to write in the session_path, but if you didn't touch php and
it worked before... The rewrite rule shouldn't matter, either but I'd
ask you to remove it, and check if that makes a difference (you don't
even need to enter the right credentials, as nocookies has higher
priority than badpassword).
------------------------------
Message: 6
Date: Sat, 10 Dec 2011 23:14:49 +0100
From: Platonides <Platonides(a)gmail.com>
Subject: Re: [Mediawiki-l] Memory Leak Issue
To: mediawiki-l(a)lists.wikimedia.org
Message-ID: <jc0ld6$c89$1(a)dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
What's your configured memory_limit of php?
If a request surpassed it, it would be cancelled, but not the total
system memory shouldn't be surpassed (many concurrent requests?). I
assume "the server had completely maxed out its memory" refers to the
apache process?
Note that a php like MediaWiki cannot produce a memory leak in the
server, as php frees all the memory used by the request and the end of it.
Are you sure there were absulutely no requests that night? Perhaps it
was crawled by e.g Googlebot.
------------------------------
Message: 7
Date: Sat, 10 Dec 2011 23:56:31 +0100
From: Platonides <Platonides(a)gmail.com>
Subject: Re: [Mediawiki-l] incorrect mime type detection
To: mediawiki-l(a)lists.wikimedia.org
Message-ID: <jc0nrc$rl4$1(a)dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
Those images match the signature of a central directory.
unzip -t 01-0557-3.jpg
On Fri, 9 Dec 2011, Brion Vibber wrote:
Running on command-line that looks like you are indeed seeing the bug in
its original form. (I forgot the / comes through too.) The
htmlspecialchars() there escapes the < and > for HTML output, so that's why
they come through as < and >
-- brion
------------------------------
Message: 2
Date: Fri, 9 Dec 2011 11:58:50 -0700 (MST)
From: "Fred Bauder" <fredbaud(a)fairpoint.net>
Subject: Re: [Mediawiki-l] runjobs.php question
To: jfoster81747(a)verizon.net, "MediaWiki announcements and site admin
list" <mediawiki-l(a)lists.wikimedia.org>
Message-ID:
<40650.66.243.192.69.1323457130.squirrel(a)webmail.fairpoint.net>
Content-Type: text/plain;charset=iso-8859-1
>
> Your system has a combination of PHP and libxml2 versions which is buggy
> and can cause hidden data corruption in MediaWiki and other web apps.
> Upgrade to PHP 5.2.9 or later and libxml2 2.7.3 or later!
> ABORTING (see http://bugs.php.net/bug.php?id=45996).
>
Funny,
the result is:
<pre>
Got: bc/b
Expected: <b>c</b>
</pre>
Is there any issues with adding some lines of code to
let me know when
the script has finished processing. Currently when I run manually in a
terminal it just stops after a while. However I actually don't know that
it finished its job. Some of the other scripts actually do have a "I'm
done" line when finished. Or an error warning when it craps out.
Thanks!
frosty
do this:
php runJobs.php
php showJobs.php
When the showjobs runs it tells you its over.
I'm talking about command line commands.
Fred
------------------------------
Message: 3
Date: Sat, 10 Dec 2011 08:09:33 +0200
From: Kaseluris-Nikos-1959 <kaseluris.nikos(a)gmail.com>
Subject: [Mediawiki-l] [MediaWiki-l] Skin-Synagonism
To: MediaWiki-l(a)lists.wikimedia.org
Message-ID:
<CAN2wPPSEczRRiTs2sGV+zzemVoqEoBONVhAQ57892R_xxJed1w(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I have created the skin "synagonism" that greatly improvespage-READING
by moving the table-of-contents on the left and showingthe position
the reader is reading!
More specifically:1) The left sidebar now is a drop-down menu, always
visible.2) Thelogo, the portlets personal and search and the title of
the page arealways visible.3) The table-of-contents (toc) moved on the
left in asplittable-pane, always visible.4) The toc is an expandable
tree.5)There is two-way communication between the toc and the
articles.* Byclicking on the toc, goes to that heading and the user
can copy theaddress of any section of an article.* By clicking on a
section of anarticle, in the toc is highlited this section and its
parents are onlyexpanded, giving to the reader the big picture of the
position s|he isreading. Thus improves the readability of big
articles.6) If there isno toc in a page (eg less than 3 headings), the
toc automaticallycloses and leaves all the space for the article.7)
Splitbar has abutton that closes|opens the toc with one click.You can
find it at SourceForge: http://synagonism-mw.sourceforge.net/
I don't have much MediaWiki code experience and I am too old to bean
expert on it!!!
Please, If commiters are interesting in my skin's functionality,
docode review and commit my skin for me.
Reporting bugs to me, I'll do my best.
(my slogan at the end, shows why I call my skin "synagonism"!)
--
Kaseluris-Nikos-1959
Synagonism = ALL winners, Antagonism = ONE winner
------------------------------
Message: 4
Date: Sat, 10 Dec 2011 17:00:24 +1000
From: "K. Peachey" <p858snake(a)gmail.com>
Subject: Re: [Mediawiki-l] [MediaWiki-l] Skin-Synagonism
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Message-ID:
<CADnECnXdgKmUR1rVutjFSZBYO5wDafoLXG1Q-xQayWpt3PJiSA(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Dec 10, 2011 at 4:09 PM, Kaseluris-Nikos-1959
<kaseluris.nikos(a)gmail.com> wrote:
Please, If commiters are interesting in my skin's
functionality,
docode review and commit my skin for me.
Reporting bugs to me, I'll do my best.
Have you considered apply for commit
access[0] yourself? That way it
would be easier to any code review on the code plus any additional
commits within our CR interface. Dantman[1] is a fan/into the skinning
stuff so no doubt he will by and comment on this email, if not, You
can give him a shout on his talk page at MediaWiki wiki.
[0]. http://www.mediawiki.org/wiki/Commit_access
[1]. http://www.mediawiki.org/wiki/User:Dantman
------------------------------
Message: 5
Date: Sat, 10 Dec 2011 18:18:59 +0100
From: Platonides <Platonides(a)gmail.com>
Subject: Re: [Mediawiki-l] Login error,<nocookiesforlogin>
To: mediawiki-l(a)lists.wikimedia.org
Message-ID: <jc042g$3m3$1(a)dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
On 05/12/11 04:02, Jeffrey T. Darlington wrote:
On 12/4/2011 3:58 PM, Platonides wrote:
I was thinking that instead of the languages/messages/MessagesEn.php
shipped with MediaWiki 1.18 you could have there a copy of an older release.
You should have there on line 1074:
That's strange. Do you have the language
files up to date?
I have no idea. I'm starting from a clean yet slightly tweaked copy of
the 1.18.0 code (I have a custom skin derived from MonoBook), and I made
sure to run maintenance/update.php to update my database during the
upgrade. I've also run maintenance/rebuildLocalisationCache.php, which
was requested when someone else was trying to debug my prior upgrade
issues. Beyond these steps, I've never had to "update my language
files" before. 'nocookiesforlogin' =>
'{{int:nocookieslogin}}', # only translate this message to other languages if you
have to change it
and in line 1072 (you also seem to miss this):
'nocookiesfornew' => 'The
user account was not created, as we could not confirm its source.
Ensure you have cookies enabled, reload this page and try again.',
The md5 of the file is:
59498d33f47acb0a25cb1eec986fad1d
languages/messages/MessagesEn.php
Is your wiki
available somewhere?
It's publicly available in read-only mode; I'm the only one with admin
privileges, and nobody else has or can create a login. I've been
planning on taking on a few volunteer wiki-wranglers, but I haven't
started taking applications yet. You can take a look if you want, but
since you won't be able to log in anyway I don't know if that will help.
http://www.gpf-comics.com/wiki/ warning [01-0557-3.jpg]: zipfile claims to be last
disk of a multi-part archive;
attempting to process anyway, assuming all parts have been concatenated
together in order. Expect "errors" and warnings...true multi-part support
doesn't exist yet (coming soon).
error [01-0557-3.jpg]: missing 1852006951 bytes in zipfile
(attempting to process anyway)
error [01-0557-3.jpg]: attempt to seek before beginning of zipfile
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
unzip -t 05-0995-2.jpg
warning [05-0995-2.jpg]: zipfile claims to be last
disk of a multi-part archive;
attempting to process anyway, assuming all parts have been concatenated
together in order. Expect "errors" and warnings...true multi-part support
doesn't exist yet (coming soon).
error [05-0995-2.jpg]: missing 1689894850 bytes in zipfile
(attempting to process anyway)
error [05-0995-2.jpg]: attempt to seek before beginning of zipfile
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
Whereas with a normal file:
unzip -t 01-0557-2.jpg
Archive: 01-0557-2.jpg
End-of-central-directory signature not found. Either this file is not
a zipfile, (...)
01-0557-3.jpg contains "50 4B 05 06" at offset 0x4E24B and 05-0995-2.jpg
at 0x309DE. Since they're just 4 bytes at an arbitrary offset amongst
"random" data, it's apparently a statistical false positive.
In fact, the more throughly ZipDirectoryReader detects it as 'zip-bad',
'trailing bytes after the end of the file comment'.
Maybe we should strength the checks at MimeMagic.php
What were you changing in the db? I don't get that "magic change back"
that you report. Perhaps it was metadata update was triggering it.
Setting these values you should be safe:
img_name img_size img_width img_height img_metadata img_bits img_media_type img_major_mime img_minor_mime img_sha1
01-0557-3.jpg 377382 599 800 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg 1fyq01rqsw47yhvl4sqg66gr4d60j0f
05-0995-2.jpg 220187 800 565 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg ghuv3z91zq81vub5v8zj9tmjziojzrh
------------------------------
Message: 8
Date: Sun, 11 Dec 2011 00:05:31 +0100
From: Platonides <Platonides(a)gmail.com>
Subject: Re: [Mediawiki-l] Context weirdness
To: mediawiki-l(a)lists.wikimedia.org
Message-ID: <jc0oc8$ugu$1(a)dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
On 05/12/11 02:25, John W. Foster wrote:
On Sun, 2011-12-04 at 22:09 +0100, Platonides wrote:
It doesn't matter too much. As the default is to have the first letter
as capital, some templates you import may call them with different case,
but that's all.
If you want to switch back $wgCapitalLinks to true; you should then run
maintenance/cleanupTitles.php Otherwise, pages created with the first
letter lowercase will be unreachable.
------------------------------
Message: 9
Date: Sun, 11 Dec 2011 00:27:40 +0100
From: Jens Wille <jens.wille(a)gmx.org>
Subject: Re: [Mediawiki-l] incorrect mime type detection
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Message-ID: <4EE3EAEC.4060804(a)gmx.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Platonides [2011-12-10 23:56]:
On 01/12/11 00:51, John Foster wrote:
I did indeed, as per the instructions at the WorkingWiki site. I have
been advised by the author that it is actually not necessary, but for
now the damage is already done, so I will just leave it & clean up the
issues.
I would appreciate any advice as to which way is best...context
sensitive or not. It wont matter once I get finished using templates
built by others that I've borrowed from other sites. I intend to never
allow content that depends on shortcuts or acronyms and I like the
titles of everything to begin with caps. Just a personal thing LOL.
Thanks for the reply. My mediawiki 1.17 installation as gone nuts. It
is not correctly
identifying things where the first letter context has changed. example:
Template: tlx call does not find Template:Tlx In the past this has made
no difference.
Did you change $wgCapitalLinks to false? 01-0557-3.jpg contains "50 4B 05 06" at
offset 0x4E24B and
05-0995-2.jpg at 0x309DE. Since they're just 4 bytes at an
arbitrary offset amongst "random" data, it's apparently a
statistical false positive.
ok, thanks for your input!
What were you changing in the db? I don't get that
"magic change
back" that you report. Perhaps it was metadata update was
triggering it.
mysql> SELECT img_name FROM image WHERE img_media_type <>
'BITMAP';
+---------------+
| img_name |
+---------------+
| 01-0557-3.jpg |
| 05-0995-2.jpg |
+---------------+
2 rows in set (0.00 sec)
mysql> UPDATE image SET img_media_type = 'BITMAP', img_major_mime =
'image', img_minor_mime = 'jpeg' WHERE img_media_type <>
'BITMAP';
Query OK, 2 rows affected (0.04 sec)
Rows matched: 2 Changed: 2 Warnings: 0
mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP';
Empty set (0.01 sec)
[...access File:01-0557-3.jpg in browser...]
mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP';
+---------------+
| img_name |
+---------------+
| 01-0557-3.jpg |
+---------------+
1 row in set (0.00 sec)
[...access File:05-0995-2.jpg in browser...]
mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP';
+---------------+
| img_name |
+---------------+
| 01-0557-3.jpg |
| 05-0995-2.jpg |
+---------------+
2 rows in set (0.00 sec)
so that seems a bit weird to me.
Setting these values you should be safe:
well,
that didn't work either :(
but what did work, though, is a plain `convert` (without actually
changing anything) and uploading that instead. this way it must
have gotten rid of any "garbage" there might have been. so, thanks
again. for me the problem is solved :) as far as the database issue
is concerned i don't know... to be honest, as long as it doesn't
affect me, i don't really care. i just don't understand what it's
doing there.
cheers
jens
------------------------------
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
End of MediaWiki-l Digest, Vol 99, Issue 8
******************************************
4513
days inactive
4513
days old
mediawiki-l@lists.wikimedia.org
0 comments
1 participants
participants (1)
-
jitendrarana4＠gmail.com