Languages: en-N, fr-N, eo-1, zh-1
Programming languages: None proficiently
However, I try, and am an active contributor in MediaWiki projects. I am the maintainer of the MediaWiki-extensions-Score extension and have push access for Lilypond.
Languages: en-N, fr-N, eo-1, zh-1
Programming languages: None proficiently
However, I try, and am an active contributor in MediaWiki projects. I am the maintainer of the MediaWiki-extensions-Score extension and have push access for Lilypond.
Didn't see this until now, but I'd support as they have shown their work and interest in contributing further.
Where's the consensus for creating this new wiki?
Yes, the Score extension was re-enabled with LilyPond's safe mode activated. Even in a container, it's better safe than sorry.
@kamholz : A "New Wiki Importer" will import the data to the new site very soon.
Yes, looks like it!
@Hsarrazin: I don't really know other properties that use categories instead or as well. The special page is better suited as it is standardized for the use needed by the extension and avoids some pitfalls such as categories not existing or with different names. Your comment could be used to suggest that the special page be improved, which would help more than just the Score extension!
Our projects are open for anyone to edit, no matter if they're just students. If you have an idea of a project or initiative to encourage more students to participate, I suggest bringing it up on their wiki or on Meta. This Phabricator site is for technical requests, and I don't see what is to be done here. Therefore, I'll close this ticket, but don't hesitate to bring up this topic where it's relevant!
No, there are still vulnerabilities in safe mode.
@Miszczyk, the solution to the CVE would be to activate safe mode in Score, as is the default (with $wgScoreSafeMode). Disabling the extension completely is appropriate with the problems in safe mode, but is drastic for the vulnerability presented, already having a better alternative built-in.
@Miszczyk: Yes, it's the official repository. They've just moved.
@MoritzMuehlenhoff: That was a big discussion in LilyPond on upgrading Guile, and is in progress. The concern with upgrading was of performance, like with strings between both versions of Guile. Five years between the previous and current version though isn't encouraging.
Yes, arbitrary SVG can be included in LilyPond code, including scripts. We don't use SVG though as there are some output bugs.
Yes, I do believe such features would be expected to work through the Score extension, and a list of tasks disabling safe mode is in the description of T174413: Set $wgScoreSafeMode to false. An example is with paper sizes, which get changed for Wikisource and such (the example from T161293: Paper format with Score extension in Wikipedia is A4 only is https://de.wikipedia.org/w/index.php?title=Benutzer:Reiner_Stoppok/Tanzlied_aus_Poniky ). Also just generally, I'd expect it to work on snippets like LY's official examples: http://lilypond.org/examples.html (which may include colours). As these blocked interfaces are expressly for the requested features, it would be hard/impossible to function without.
Yes, safe code means that the shell execution syntax is disabled on LilyPond's end. The problem is that it also disables a lot of important features as well (full list at https://gitlab.com/lilypond/lilypond/-/blob/master/scm/safe-lily.scm), so instead dangerous executions are prevented through firejail that is less restrictive. Safe mode is thus on LilyPond, and if disabled, we'd expect a sandbox to be used.
@Miszczyk: Made https://gerrit.wikimedia.org/r/609467 to clarify the docs
To be more precise, the error is:
Could not execute LilyPond: /dev/null is not an executable file. Make sure $wgScoreLilyPond is set correctly.
Sounds interesting! Currently working on the extension to make it easier to add these new notations. Should get to this in a few weeks (after exams :) )
Yes. It isn't the Wikinews community, but the Wikipedia community consensus. As such, the argument on a distinction between voluntary and involuntary closure falls, and discussion on closing tr.wikinews should be on meta with proper notification to trwikinews, which seems to have not been done.
@Verdy_p, the fix is not yet accepted; it still needs a "+2" from someone allowed to while I've just given a "+1" as I don't have that access. Once the patch is truly accepted, it will take a few weeks for the change to go to all the Wikimedia wikis.
There isn't a script to perform this, so removing the project.
The way exporting from the Wikimedia Incubator works is a bit more complicated than just copy-pasting the XML, as the titles have to be modified, and attention given to keeping the history. There wouldn't be a timeout on the import, but it should be left to @MF-Warburg to perform the import if he's interested/given import on the wiki.
Should we put this on hold for the discussion happening on sitereq-l on this subject?
Might come back to it at some point; thought it was a trivial change...
The GCI trip is cancelled.
The org admins have got an email from Google for the mentor to go on the 2nd trip with both (!) GP winners. I've replied with the decision here. See you soon!
The problem is resolved as a user syntax error, so not a problem in the extension.
Yeah, didn't notice.
They'll (GCI) will send an email to the org admins next week with the dates etc.
There was no org admin form to fill (other than the Payoneer stuff). I've sent a message to ask about how to proceed (@Aklapper: needs mod approval for the Wikimedia mailing list)
I'd be interested; I'd love to meet our winners and visit Google! I'd be available for either date ranges and have the proper documentation.
I wouldn't know how to change the visibility of this task, but this task when drafted seems to be more about creating "criteria" or a process to decide which mentor to ship off to SF, and create a new open task for candidatures. We should open the task when we get told the cohort of our winners, in the case both winners are in the same one.
We should select the mentor only after the winners have been decided and they've settled on a date, so that the mentors can check whether they would be available to go.
The "pass": "Password": [{"LDAP_OPT_DEREF": 1}] lines are invalid as you're assigning a key to a key.
I'd be happy to be co-admin this year
Note that even though no error is shown, the image is not of Richmond City but of Richmond County, so this bug has not been resolved. See https://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Map_of_Virginia_highlighting_Richmond_City.svg/256px-Map_of_Virginia_highlighting_Richmond_City.svg.png (256px)
@Peteforsyth, no, the MIDI file was not generated, as it is linked to the same command as the image. The LY syntax is valid, but it seems at first glance to be too complex to be run all at once. Try splitting it?
The error message is (hidden by the error beautifier):
/vagrant/mediawiki/includes/shell/limit.sh: line 101: 2815 Segmentation fault /usr/bin/timeout $MW_WALL_CLOCK_LIMIT /bin/bash -c "$1" 3>&-
@jhsoby, @SPQRobin or @MF-Warburg normally handles imports. If you do, remember to import all revisions! :)
Not really any updates on this; but the whole functionality will be deprecated as TMH can convert MIDI files without need from Score.
Sorry, cannot attend. Hope whoever does enjoys it!
I don't see how separating a new FileRepo implementation could help, as FileRepo is already for interacting with filesystem files with or without database entries.
Goes with T135501: Formalize how TMH provides a player for Score-generated ogg/vorbis files. A consideration for TMH with local filesystem files (or whatever the term should be for files that do not have a File: namespace info-page)
The way it is supposed to work right now is when the cache version constant changes, the hash associated with all the files from previous versions change. As a result, the backend cannot get the old directory thus recreating it. Something here isn't working...
Sorry, I have been looking as to why the cache bumping does not work, as it should be part of the hash. I have not determined why it fails. For Q11980, I added a useless character to re-generate the image, although that shouldn't be necessary.
@Johan: I wouldn't have much of a timeline for this... I'll try adding tests and making sure mp3 transcoding works well (as it differs from MediaWiki-extensions-Score 's way)
Also, ImageMagick will still be needed until Ieb13455825053cb187e6240b238fa7b6bd5c18c1.
Gonna be resolved through T135597
ImageMagick isn't needed for one-page partitions, but doesn't seem to crop multi-paged docs nor hold them as one page.
Correct.