https://bugzilla.wikimedia.org/show_bug.cgi?id=54311
Web browser: ---
Bug ID: 54311
Summary: Random api errors
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Wikidata
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: maarten(a)mdammers.nl
Classification: Unclassified
Mobile Platform: ---
I'm running several bots and every once in a while a bot crashes:
Adding new template claim to [[wikidata:Q6614219]]
Traceback (most recent call last):
File "C:\pywikibot\core\add_template.py", line 120, in <module>
main()
File "C:\pywikibot\core\add_template.py", line 117, in main
bot.run()
File "C:\pywikibot\core\add_template.py", line 52, in run
item.addClaim(newclaim)
File "C:\pywikibot\core\pywikibot\page.py", line 2676, in addClaim
self.repo.addClaim(self, claim, bot=bot, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 709, in callee
return fn(self, *args, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 3578, in addClaim
data = req.submit()
File "C:\pywikibot\core\pywikibot\data\api.py", line 394, in submit
raise APIError(code, info, **result["error"])
pywikibot.data.api.APIError: badtoken: * '''Sorry! We could not process your
edi
t due to a loss of session data.'''
Please try again.
If it still does not work, try [[Special:UserLogout|logging out]] and logging
ba
ck in.
* There seems to be a problem with your login session;
this action has been canceled as a precaution against session hijacking.
Go back to the previous page, reload that page and then try again.
This exception should be caught and the addClaim should be retried.
Maybe a Wikidata bug should be filed too to figure out why we seem to loose
session data every once in a while
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54547
Web browser: ---
Bug ID: 54547
Summary: sync.py, linkreports.py and phpfrontforpywikibot
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/patches/609/
Reported by: valhallasw
Created on: 2013-04-13 21:11:43
Subject: sync.py, linkreports.py and phpfrontforpywikibot
Original description:
See http://lists.wikimedia.org/pipermail/pywikipedia-l/2013-March/007776.html
and http://lists.wikimedia.org/pipermail/pywikipedia-l/2013-March/007785.html
\------------
I have been working on some additions to the pywikipediabot framework.
I'd be happy if my code could be useful to others.
sync.py helps synchronizing different wikis. It goes through a bunch
of namespaces and creates an overview of pages that are different,
this is already useful for Templates and MediaWiki but especially
useful when dealing with semantic mediawiki, where a lot of the
functionality lives in namespaces such as Property, Type and Form.
linkreports.py creates a page with a table of broken links, first
date, last date and error message.
I also wrote a little PHP frontend that lets people run a
pywikipediabot replace script \(it's for folks who can't or don't want
to use anything on a commandline\). This can probably live on its own
on github, but it might be a bit too custom at this point and I'd like
to have some comments on it.
This PHP frontend is available at https://github.com/guaka/phpfrontforpywikibot
It's pretty rough still but releasing it forces me to think about the
public release when adding more functionality.
I'm not sure how to proceed with getting sync.py and linkreports.py in
the official repo. Shall I just put them up on github so you can take
a look? I'm looking forward to your ideas.
Kasper
\----------------------
On Mon, Mar 11, 2013 at 11:10 AM, Kasper Souren <kasper.souren(a)gmail.com>
wrote:
> I'm not sure how to proceed with getting sync.py and linkreports.py in
> the official repo. Shall I just put them up on github so you can take
> a look? I'm looking forward to your ideas.
Didn't hear anything back in a week so I just put stuff up here:
https://github.com/guaka/pywikibot-extras
Still needs a bit of work to make it more generic but sync.py could
already be useful as is.
\-------------------
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54541
Web browser: ---
Bug ID: 54541
Summary: When loging in to a site, try the site-configured
username if any
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/patches/621/
Reported by: gallaecio
Created on: 2013-08-03 20:30:54.056000
Subject: When loging in to a site, try the site-configured username if any
Original description:
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54554
Web browser: ---
Bug ID: 54554
Summary: spellcheck.py — Remember words skipped in a page
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/patches/576/
Reported by: Anonymous user
Created on: 2012-11-15 11:49:53
Subject: spellcheck.py — Remember words skipped in a page
Original description:
When you use the spellcheck.py script and use the p switch for a word, it is
ignored for the whole page, indeed. However, when you run the script again on
the same page, you get the word yet again. I think the spellchecker should
remember you want to skip that word on that page.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54555
Web browser: ---
Bug ID: 54555
Summary: Force retrieval of last edit time
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/patches/571/
Reported by: strainu
Created on: 2012-10-27 15:35:07
Subject: Force retrieval of last edit time
Original description:
This patch changes the Page.editTime function in order to allow the user to
request a valid editTime even if the page has not yet been fetched. The API
call used is theoretically much lighter than retrieving the whole page. The
default behavior remains unchanged.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55170
Web browser: ---
Bug ID: 55170
Summary: trunk 10450 not py2.6 compatible
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/1519/
Reported by: drtrigon
Created on: 2012-10-09 15:08:56
Subject: trunk 10450 not py2.6 compatible
Original description:
Hello all\!
As Merlijn suggested at \[1\] I should also report this here too. I would solve
it myself but a quick shot does not seam appropriate.
\[1\] https://jira.toolserver.org/browse/TS-1466
Python code using:
>>> import re
>>> re.sub\(..., flags=...\)
does not work in python 2.6 because the optional parameter \'flags\' was
introduced in python 2.7. As Merlijn noted, this should be replaced by
>>> re.compile\(..., flags=...\).sub\(...\)
A fast \'grep \"flags\" \*\' in my pywikipedia directory of revision 10450,
yields at least following matches:
imagecopy\_self.py: match = re.search\(regex, text,
flags=re.IGNORECASE\)
imagecopy\_self.py: contents\[u\'permission\'\] = re.sub\(regex,
u\'\', contents\[u\'permission\'\], flags=re.IGNORECASE\)
imagecopy\_self.py: text = re.sub\(toRemove, u\'\', text,
flags=re.IGNORECASE\)
imagecopy\_self.py: text = re.sub\(regex, u\'\', text,
flags=re.IGNORECASE\)
imagecopy\_self.py: match = re.search\(regex, text,
flags=re.IGNORECASE\)
imagecopy\_self.py: result = re.sub\(regex, replacement,
match.group\(0\), flags=re.IGNORECASE\)
...so there are at least 4 problematic cases which should be changed. I am not
aware if a similar issues exists with \'re.search\'.
Thanks and greetings
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54998
Web browser: ---
Bug ID: 54998
Summary: move pagegenerators out of data.api
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/348/
Reported by: valhallasw
Created on: 2013-09-11 16:46:27.449000
Subject: move pagegenerators out of data.api
Original description:
Move data.api.{anything that returns Page objects} from data.api to
data.pagegenerators or pywikibot.pagegenerators.
See https://gerrit.wikimedia.org/r/#/c/80300/1,
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55197
Web browser: ---
Bug ID: 55197
Summary: PostData() datas are not gzip compressed
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: ASSIGNED
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/1447/
Reported by: Anonymous user
Created on: 2012-05-19 16:38:59
Subject: PostData() datas are not gzip compressed
Assigned to: xqt
Original description:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55088
Web browser: ---
Bug ID: 55088
Summary: allow batch mode uploads of images
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/189/
Reported by: janalynn
Created on: 2009-04-20 15:33:38
Subject: allow batch mode uploads of images
Original description:
I was searching for help and came across others with my concern. This request
might have already been made, but I didn't find it when I performed a search.
Thank you for your help\!
Batch Uploads?
Is there any way to "upload" a large batch of pictures to a local instance of
mediawiki? Is there a workaround? I know this sounds stupid \(just link to
them\) but I'd like them to have pages, thumbnails, etc...
http://pywikipediabot.sf.net/
A: There is no current way that I know \(as of v1.4.2\) .. I have the same
concern.. it would be nice to be able to batch upload. -- Sy / \(talk\)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55315
Web browser: ---
Bug ID: 55315
Summary: category.py breaks articles with includeonly and
noinclude
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/822/
Reported by: djbarrett
Created on: 2008-11-19 19:07:20
Subject: category.py breaks articles with includeonly and noinclude
Original description:
This is a DEADLY bug that wrecks wiki structure.
I ran "python category.py" to rename one category to another. For articles
containing <includeonly> and <noinclude> statements, pywikipedia
made incorrect changes. When renaming category B to category C, the text:
<includeonly>\[\[Category:A\]\]</includeonly><noinclude>\[\[Category:B\]\]</noinclude>
becomes:
<includeonly></includeonly><noinclude></noinclude>
\[\[Category:C\]\]
In other words, it completely removed category A, and when renaming category B,
placed the new category tag outside the noinclude tags.
This wrecked a complicated category structure.
$ python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r6088, Nov 12 2008, 11:19:15\)
Python 2.4.3 \(\#1, May 24 2008, 13:57:05\)
\[GCC 4.1.2 20070626 \(Red Hat 4.1.2-14\)\]
--
You are receiving this mail because:
You are the assignee for the bug.