Upgrade procedures for, e.g. librsvg and other rendering dependencies

Just wondering if we've got an established procedure or schedule for
upgrading the various rendering and rasterizing dependencies, such as
librsvg, ImageMagick, etc. on a regular basis?

I ask because http://bugzilla.wikimedia.org/show_bug.cgi?id=10207
("Upgrade librsvg to version 2.18.0", which was also a request for
2.16.0) doesn't strike me as something we should need to repeat each
time a new version comes out.

librsvg upgrades, in particular, are useful, because they often fix
various upstream SVG rasterization bugs.

Rob Church

MediaWiki automated test run failure 2007-09-01

An automated run of parserTests.php showed the following failures:

This is MediaWiki version 1.11alpha (r25385).

Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...

   1 previously failing test(s) now PASSING! :)
      * <references> after <gallery> (bug 6164)  [Fixed between 31-Aug-2007 07:15:36, 1.11alpha (r25338) and
01-Sep-2007 07:15:33, 1.11alpha (r25385)]

  17 still FAILING test(s) :(
      * URL-encoding in URL functions (single parameter)  [Has never passed]
      * URL-encoding in URL functions (multiple parameters)  [Has never passed]
      * Table security: embedded pipes
(http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html)  [Has never passed]
      * Link containing double-single-quotes '' (bug 4598)  [Has never passed]
      * message transform: <noinclude> in transcluded template (bug 4926)  [Has never passed]
      * message transform: <onlyinclude> in transcluded template (bug 4926)  [Has never passed]
      * BUG 1887, part 2: A <math> with a thumbnail- math enabled  [Has never passed]
      * HTML bullet list, unclosed tags (bug 5497)  [Has never passed]
      * HTML ordered list, unclosed tags (bug 5497)  [Has never passed]
      * HTML nested bullet list, open tags (bug 5497)  [Has never passed]
      * HTML nested ordered list, open tags (bug 5497)  [Has never passed]
      * Inline HTML vs wiki block nesting  [Has never passed]
      * Mixing markup for italics and bold  [Has never passed]
      * dt/dd/dl test  [Has never passed]
      * Images with the "|" character in the comment  [Has never passed]

Re: Upgrade procedures for, e.g. librsvg and other rendering dependencies

Rob Church wrote:
> Just wondering if we've got an established procedure or schedule for
> upgrading the various rendering and rasterizing dependencies, such as
> librsvg, ImageMagick, etc. on a regular basis?

Not really, at the moment. :P :)

> I ask because http://bugzilla.wikimedia.org/show_bug.cgi?id=10207
> ("Upgrade librsvg to version 2.18.0", which was also a request for
> 2.16.0) doesn't strike me as something we should need to repeat each
> time a new version comes out.
> 
> librsvg upgrades, in particular, are useful, because they often fix
> various upstream SVG rasterization bugs.

We'll have to make sure it doesn't interfere with other packages on the
new Ubuntu setup, but hopefully it shouldn't be too hard to keep up that
way.

-- brion vibber (brion @ wikimedia.org)

Re: Upgrade procedures for, e.g. librsvg and other rendering dependencies

On 9/1/07, Brion Vibber <brion@...> wrote:
> Rob Church wrote:
> > Just wondering if we've got an established procedure or schedule for
> > upgrading the various rendering and rasterizing dependencies, such as
> > librsvg, ImageMagick, etc. on a regular basis?
>
> Not really, at the moment. :P :)
[snip]
> We'll have to make sure it doesn't interfere with other packages on the
> new Ubuntu setup, but hopefully it shouldn't be too hard to keep up that
> way.

I made a rasterization regression test a while back while I was doing
some playing with using Inkscape or Batik rather than SVG.  Basically
it rendered a large number of SVGs with the target renderer and
measured the difference of the rasterized output with a stored copy
done by rsvg.

If I spruce it up some will we use it?

Re: [MediaWiki-CVS] SVN: [25083] trunk/phase3/languages/messages/MessagesEn.php

On 8/31/07, Platonides <Platonides@...> wrote:
> This breaks typing characters with Alt+numeric code, as you end up at
> Special:Preferences. Please reassign a non-numeric character.
>
> Follow-up: ',' was added on the previous revision (r25082), it didn't
> have an accesskey before, which is bug 5206.

Yeah, Firefox screws up with numeric codes.  They shouldn't be used.

Re: [MediaWiki-CVS] SVN: [25083] trunk/phase3/languages/messages/MessagesEn.php

On 9/1/07, Simetrical <Simetrical+wikilist@...> wrote:
> Yeah, Firefox screws up with numeric codes.  They shouldn't be used.

(Well, at least before the combination key changed from Alt- to
Alt-Shift-.  IE not unlikely gets this wrong too.)

MediaWiki automated test run failure 2007-09-02

An automated run of parserTests.php showed the following failures:

This is MediaWiki version 1.11alpha (r25400).

Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...

  17 still FAILING test(s) :(
      * URL-encoding in URL functions (single parameter)  [Has never passed]
      * URL-encoding in URL functions (multiple parameters)  [Has never passed]
      * Table security: embedded pipes
(http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html)  [Has never passed]
      * Link containing double-single-quotes '' (bug 4598)  [Has never passed]
      * message transform: <noinclude> in transcluded template (bug 4926)  [Has never passed]
      * message transform: <onlyinclude> in transcluded template (bug 4926)  [Has never passed]
      * BUG 1887, part 2: A <math> with a thumbnail- math enabled  [Has never passed]
      * HTML bullet list, unclosed tags (bug 5497)  [Has never passed]
      * HTML ordered list, unclosed tags (bug 5497)  [Has never passed]
      * HTML nested bullet list, open tags (bug 5497)  [Has never passed]
      * HTML nested ordered list, open tags (bug 5497)  [Has never passed]
      * Inline HTML vs wiki block nesting  [Has never passed]
      * Mixing markup for italics and bold  [Has never passed]
      * dt/dd/dl test  [Has never passed]
      * Images with the "|" character in the comment  [Has never passed]
      * Parents of subpages, two levels up, without trailing slash or name.  [Has never passed]
      * Parents of subpages, two levels up, with lots of extra trailing slashes.  [Has never passed]

Passed 527 of 544 tests (96.88%)... 17 tests failed!

Re: [MediaWiki-CVS] SVN: [25083] trunk/phase3/languages/messages/MessagesEn.php

Platonides schrieb:
>> Revision: 25083
> 
> This breaks typing characters with Alt+numeric code, as you end up at 
> Special:Preferences. Please reassign a non-numeric character.
> 
> Follow-up: ',' was added on the previous revision (r25082), it didn't 
> have an accesskey before, which is bug 5206.

Sorry, I am not aware about problems with numeric codes. I have used 9
because it's optically similar to 'P' for preferences but P is already
used for preview in edit mode.

Any suggestion for another key?

My first thought (r25082) was ',' but this access key is hard coded for
the edit form field (BTW: why is it hard coded?).

Another issue I have found is the access key '=' for protecting a page.
At least with Firefox2/WinXp, which uses crtl-shift as access key
combination, the '=' access key is not longer reachable.

Any suggestions for a change/reassign?

Raymond.

_______________________________________________
Wikitech-l mailing list

Re: SVN: [25394] trunk/phase3

robchurch@... schrieb:
> Revision: 25394
> Author:   robchurch
> Date:     2007-09-01 17:57:55 +0000 (Sat, 01 Sep 2007)
> 
> Log Message:
> -----------
> Revert r25349 and offspring; the watchlist editor shows titles, not users - a contributions link is not
appropriate here, nor is it useful
> 

Sorry, I disagree with this revert. A link to the user contributions is
very helpful for all users who have a lot of user pages on its
watchlists (Wikipedians who welcome newbies or follow up users with
copyvios etc.).

To reduce the watchlist from older user pages it's helpful to edit the
watchlist in normal mode, see the contributions to decide if the user
page can be de-watchlisted.

The addition of this link was a request of the German OTRS team who
handles a lot of copyvios.

Hopefully I could have explained the reasons and ask for re-revert 
Thanks.

Raymond.

Re: SVN: [25394] trunk/phase3

On 02/09/07, Raimond Spekking <raimond.spekking@...> wrote:
> robchurch@... schrieb:
> > Revision: 25394
> > Author:   robchurch
> > Date:     2007-09-01 17:57:55 +0000 (Sat, 01 Sep 2007)
> >
> > Log Message:
> > -----------
> > Revert r25349 and offspring; the watchlist editor shows titles, not users - a contributions link is not
appropriate here, nor is it useful
> >
>
> Sorry, I disagree with this revert. A link to the user contributions is
> very helpful for all users who have a lot of user pages on its
> watchlists (Wikipedians who welcome newbies or follow up users with
> copyvios etc.).

I wouldn't have reverted had the link appeared on any page dealing
with the user in the context of a user, but the watchlist editor is
explicitly referring to the page, not the user. Ergo, it seems
completely inappropriate to me to arbitrarily change the semantics of
the context in which the title is being displayed for a single
namespace.

Rob Church