https://bugzilla.wikimedia.org/show_bug.cgi?id=55190
Web browser: ---
Bug ID: 55190
Summary: *-login.data can have case discrepency on Linux host
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1475/
Reported by: jaclayiii
Created on: 2012-06-26 04:52:22
Subject: *-login.data can have case discrepency on Linux host
Original description:
Pywikipedia \[http\] trunk/pywikipedia \(r10401, 2012/06/21, 06:18:43\)
Python 2.7.2+ \(default, Oct 4 2011, 20:06:09\)
\[GCC 4.6.1\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok
Summary: the \*-login.data file maybe saved with an uppercase username but when
load cookies tries to find it on a Linux host, the case of the username maybe
lower. This has the unintended consequence of not allowing bots to login on
private wikis that have anonymous read api rights disabled.
If a user connects to a wiki that has LDAP or some other form of "add-on"
authentication, the user name returned may vary in case from what is in the
user-config.py file. The reason this matters is that the
<wikifamily>-<language>-<username>-login.data file may be
saved with an upper case letter in the username. Thus if the user-config.py
file contained:
users\["mywiki"\]\["en"\]="james"
but the LDAP authenticator returned back "James" as the username, then the
\*-login.data file would be mywiki-en-James-login.data, but when \_loadcookies
goes to look for such a file on line 5572:
if os.path.exists\(localPA\)
localPA is /~some/path/to/mywiki-en-james-login.data
Notice that the James is now lower case in the file above.
As Linux is case sensitive, it cannot find the login data and thus prevents
access to wikis the do not allow anonymous access to api's. A temporary work
around requires setting user name to the appropriate case \(even if the
username is case insensitive in the LDAP authentication scheme\), for example:
users\["mywiki"\]\["en"\]="James"
keywords: SSL, Login failure, https login failure, https linux login, https
pywikipedia, https pywikipedia linux
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55156
Web browser: ---
Bug ID: 55156
Summary: Windows implicite interpreter call
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1568/
Reported by: Anonymous user
Created on: 2013-01-23 15:15:20
Subject: Windows implicite interpreter call
Original description:
When I call a pwb script over the command line \(Windows 7\), without an
explicite call of the interpreter, I only get the documentation of the module
or a "no generator specified" error. Any ideas?
Pywikipedia \[http\] trunk/pywikipedia \(r10875, 2013/01/05, 22:45:20\)
Python 2.7.3 \(default, Apr 10 2012, 23:31:26\) \[MSC v.1500 32 bit \(Intel\)\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55137
Web browser: ---
Bug ID: 55137
Summary: Exception in Python 2.7.5
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1635/
Reported by: hazard-sj
Created on: 2013-06-02 01:31:50
Subject: Exception in Python 2.7.5
Original description:
I just upgraded from Python 2.7.3 to Python 2.7.5 and now I get \(this was
tested from wikipedia.py\):
exception UnsupportedOperation\('fileno',\) while fixing up sys.stdout and
sys.stderr
Versions:
Pywikipediabot trunk/pywikipedia/ \(r11604, 2013/06/01, 21:02:13, ok\)
Python 2.7.5 \(default, May 15 2013, 22:44:16\) \[MSC v.1500 64 bit \(AMD64\)\]
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55119
Web browser: ---
Bug ID: 55119
Summary: weblinkchecker: url incorrect parsed when using a
multiline template
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: weblinkchecker.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1671/
Reported by: harmenhuizinga
Created on: 2013-09-11 12:50:00.328000
Subject: weblinkchecker: url incorrect parsed when using a multiline template
Original description:
Today I discovered a problem parsing urls within multiline templates on
https://nl.wikipedia.org/w/index.php?title=Rie_Timmer
In this article there are a few urls used within templates, but the urls used
in multiline templates are parsed incorrect (including the }} at the end): e.g.
http://www.vsgermelo.nl/vsg_bulletin/82/20010982.htm}}
Template:
{{cite journal
| author=R. Boterenbrood, S. Westra, L. Korterink
| journal=VSG-bulletin
| title=Rie Timmer, dameskampioen van Nederland in 1971
| volume=35
| issue=82
| date=september 2001
| url=http://www.vsgermelo.nl/vsg_bulletin/82/20010982.htm}}
However, another url within a template, but not multiline works fine:
* {{Link chessgames.com|url=http://www.chessgames.com/player/rie_timmer.html}}
Version information:
$ python version.py
Pywikipedia [https] r/pywikibot/compat (r10277, ea68647, 2013/09/11, 14:28:43,
ok)
Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
config-settings:
use_api = True
use_api_login = True
unicode test: ok
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55112
Web browser: ---
Bug ID: 55112
Summary: Followlive: allow adding an optional reason for
deletion
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/77/
Reported by: Anonymous user
Created on: 2007-02-01 19:59:42
Subject: Followlive: allow adding an optional reason for deletion
Original description:
When using followlive.py, one often wants to add a speedy template to
particularly loathsome or crappy articles. But practice on the English
Wikipedia \(and probably others\) has since moved from the all-purpose
\{\{speedy\}\} or \{\{delete\}\} template to using \{\{db-reason|reason\}\}
templates in which the particular reason can adumbrated and elaborated upon at
length. followlive.py should allow inserting of arbitrary user-supplied text in
the reason field of \{\{db-reason\}\}.
When using the actual delete functionality through an admin account, I believe
followlive.py asks for text to put in the deletion log summary, so most of the
functionality is there. It just needs to ask the user for the text of the
reason, concatenate \{\{db-reason|, reason, and \}\}, and then insert in the
page as usual.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55106
Web browser: ---
Bug ID: 55106
Summary: Blockpageschecker's default value of -move option
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/130/
Reported by: nightshadow28
Created on: 2008-02-12 13:08:22
Subject: Blockpageschecker's default value of -move option
Original description:
A project using "moving protection", always use -move option. That is, if bot
operator forgets to use the option, it will be miss operation with false
editing. Therefore, would you change default value of the option by site?
For example, by code as below:
\---- \(1\)
\# Check list to block the users that haven't set their preferences
project\_inserted = \['en', 'fr', 'it', 'ja', 'pt', 'zh'\]
\# \(patch\) Check list to change default value of -move -----------------
Start
project\_moving\_prot = \[u'wikipedia:ja'\]
\# \(patch\) ------------------------------------------------------------- End
\---- \(2\)
\# Load the right site
site = wikipedia.getSite\(\)
\# \(patch\) default option value of -move ----------------------------------
Start
if unicode\(site\) in project\_moving\_prot:
wikipedia.output\('The site needs to check for protection of moving, so bot
will check it anyway.'\)
moveBlockCheck = True
\# \(patch\) --------------------------------------------------------- End
Sincerely yours, Nightshadow28.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55089
Web browser: ---
Bug ID: 55089
Summary: regexp functionality for -hint option
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: interwiki.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/187/
Reported by: Anonymous user
Created on: 2009-03-25 22:01:02
Subject: regexp functionality for -hint option
Original description:
it would be great if -hint option in interwiki.py bot could accept regular
expressions. this can be helpful, e.g. if in one wiki the article is entitled
"XXX, YYY" and the corresponding article in another wiki is "XXX \(YYY\)", or
if titles differ in some letters and these differences are regular between
languages.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55082
Web browser: ---
Bug ID: 55082
Summary: Warning for cross-namespace interwiki links
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: interwiki.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/207/
Reported by: tx1k1
Created on: 2009-06-23 07:27:23
Subject: Warning for cross-namespace interwiki links
Original description:
When working with interwiki.py, a warning is given if a page links to a
different namespace. E.g.:
WARNING: \[\[gl:Categoría:Música irlandesa\]\] is in namespace 14, but
\[\[en:Music of Ireland\]\] is in namespace 0. Follow it anyway? \(\[y\]es,
\[n\]o, \[a\]dd an alternative, \[g\]ive up\)
In these cases, an additional option should be added, something like: "\[t\]ry
for the same title in source's namespace".
In consequence, interwiki.py would continue working with the correct links with
\[\[en:Category:Music of Ireland\]\], without retyping it again.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55076
Web browser: ---
Bug ID: 55076
Summary: Suggestions regarding -addcat option in replace.py
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/221/
Reported by: Anonymous user
Created on: 2009-08-28 17:02:21
Subject: Suggestions regarding -addcat option in replace.py
Original description:
The initial problem: I wanted to replace text in categories AND simultaneously
add another category, but the addcat function undid the textual replacement. I
got it to work, here's the replacement.py diff \(the first change is a syntax
correction, the second change is from
http://osdir.com/ml/pywikipedia-bugs/2009-07/msg00067.html \):
304c304
< cat\_ns + ':' + addedCat\)
\---
> cat\_ns + addedCat\)
390c390
< cats = page.categories\(nofollow\_redirects=True\)
\---
> cats = page.categories\(\)
392d391
< cats.append\(self.addedCat\)
394c393
< cats\)
\---
>
\[self.addedCat\],addOnly = True\)
--
You are receiving this mail because:
You are the assignee for the bug.