December 2019 - Tei-council

Docker containers and user permissions
by Martin Holmes 19 Dec '19

19 Dec '19

Hi all, I've just been experimenting a bit further with the docker containers, and come across something that I've found in the past, which can cause problems on *NIX systems. By default, when you run a docker container, you end up as the root user in the container. That means that when you run a build process, if you save the output to a directory that's actually on your host filesystem, those files and folders may be owned by root, and you'll then have to use sudo to remove them. What I've done in the past is to use a run command like this: docker run --user $(id -u) --name tei -v /home/mholmes/WorkData/tei:/tei -it -e TZ=America/Vancouver teic/teidev-docker which runs the docker container and logs you in with the same user id that you have on your host system (in my case 1001); that means that when files are saved from a build process, they belong to you. In some cases, you'll end up logged in with a prompt like this: I have no name!@e08387ca074c:/tei/ which means that there is no user in the container with the same uuid as your user on the host system, but that doesn't matter; files will be saved under the correct user id, so on your host system they'll belong to you, not to root. (They may have group root, but that doesn't matter if you own them.) This just makes it easier to examine and clean up any products from the build process that remain on your host filesystem. You can actually create a parallel user with the same name and uid as your own in the docker container if you like, but that will get blown away every time you remove the container, of course. Incidentally, on the issue of vulnerable docker containers, I'm not alone in being worried: <https://www.techrepublic.com/article/docker-containers-are-filled-with-vuln…> The assumption that nothing malignant can get into your docker container, and that nothing can escape from it into your host system, is I think flawed: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14271> and in particular, if actions in the container are running as root, I believe you are running a risk. I think it's important that docker containers are regularly updated by their maintainers, but I also do run apt update and apt dist-upgrade or the equivalent as root in the container if it's one I'm keeping around. That does of course risk breaking the container's ability to do the build processes if some software the build is dependent on is updated in an unexpected way, but we want to know that anyway so we can fix it. And updating your container is no different from updating one of the live Jenkins servers, which is something I do with my server religiously every day. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

1 0

workshop "Building the TEI Guidelines locally"
by Peter Stadler 18 Dec '19

18 Dec '19

Dear all, tomorrow we’ll be having our little workshop on how to build the TEI Guidelines (and Stylesheets) locally and although I’m quite late, may I ask you to prepare your computers by installing Docker (Community Edition) [1] and download (aka ‚pull‘) the teic/jenkins image? That is, once you have Docker installed (and the Docker daemon is running; you can tell when the little Docker whale stops loading in your system tray) you simply hit `docker pull teic/jenkins` on the command line. This will take some minutes (depending on your connection) since the image is about 800 MB! Oh, and of course you will need to have a clone of the TEI [2] and the Stylesheets repo [3] on your machine. Best Peter [1] https://docs.docker.com/v17.09/engine/installation/ [2] https://github.com/TEIC/TEI [3] https://github.com/TEIC/Stylesheets

2 2

Stylesheets (and other) meeting time
by Syd Bauman 17 Dec '19

17 Dec '19

We agreed Stylesheets meetings should be 1st Tue of the month at 13:00Z. Two problems, the first with just Jan, the second more general. * I will be traveling on Tue 07 Jan; it is perhaps 50/50 I will be able to make the call, and if I do, I am likely to be a jet-lagged blithering idiot. (I am taking a red-eye from Boston to Leeds, UK overnight Mon 06 to Tue 07.) * The time is a bit of a problem for Martin. During daylight's saving time (Mar-Oct) it is 06:00, which is fine. But during standard time (Jan, Feb, Nov, Dec) 13:00Z is 05:00 PST. Thus we would not have Martin for the 1st hour of the Jan, Feb, Nov, or Dec meetings. Thoughts?

6 5

Council meeting times
by Scholger, Martina (martina.scholger＠uni-graz.at) 17 Dec '19

17 Dec '19

Dear Council, I've added our monthly Council meetings to the google calendar. We agreed that it should be the 2nd Tuesday of the month at: 9:00-10:30 (EST/EDT) / 14:00-15:30 (GMT/BST) / 15:00-16:30 (CET/CEST). Only the meeting on March 10 is affected by the switch to summer time, therefore the meeting will be at 9:00-10:30 (EDT) / 13:00-14:30 (GMT) / 14:00-15:30 (CET). Our next regular Council call is on Tuesday, January 14. Best, Martina

1 0

Is oxygen plugin message from tei-c.org incorrect?
by Elisa Beshero-Bondar 14 Dec '19

14 Dec '19

Dear TEI Councillors, Today I was showing Jessica Lu how to access the oXygen plugin from its supposedly canonical location tied to the latest release: https://www.tei-c.org/release/oxygen/updateSite.oxygen Or at least I *think* this is the correct site. Am I right about the URL? I'm writing up our documentation now for how the TEI community should install the oxygen plugin, having just walked Jessica through the process. The reason I'm suddenly uncertain about it is the message that pops up upon adding it, which warns the user, "Use this only if you are testing the plugin." Here's the message in full: DEVELOPMENT BUILD of the Oxygen TEI plugin based on the current trunk versions of TEI P5 and the TEI Stylesheets.Jenkins build number: 2019-07-18-143911. Use this only if you are testing the plugin. To avoid conflict with builtin framework, please ensure that you have gone to Preferences->Document Type Association in oXygen and deactivated all the TEI frameworks that have "External" in the storage columns. Is that the message that should be appearing with this plugin? It seems like the same message we see on the bleeding-edge plugin, and indeed it is: On installing the bleeding-edge plugin (from http://jenkins.tei-c.org/job/oxygen-tei-stable/lastSuccessfulBuild/artifact… ) the message is the same: "Use this only if you are testing the plugin. " I don't think we intend for those messages to be so much the same, do we? But I want to check with you all and make sure I have the right URLs for the plugins first. Should I open a ticket about this on the TEI oxygen plugin repo? On the verge of opening said ticket, Elisa -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> Development site: http://newtfire.org

2 3

Physical address for the TEI?
by Meaghan Brown 13 Dec '19

13 Dec '19

Does anyone happen to know the legal address for the TEI? I need it for bureaucratic reasons. Best, Meaghan -- Dr. Meaghan Brown

2 1

Doodle Poll Spring F2F
by Scholger, Martina (martina.scholger＠uni-graz.at) 12 Dec '19

12 Dec '19

Dear all, I apologize for this horrible doodle for planning our spring F2F meeting: https://doodle.com/poll/zaeh4k9kfu5wdhfp In our meeting on Tuesday we decided to do another doodle poll on times and decide for a place afterwards. The F2F meeting lasts 3 days (+ travel time). Please fill in the doodle as soon as possible. Best, Martina

1 0

standOff problem #1: content model of <teiCorpus>
by Syd Bauman 11 Dec '19

11 Dec '19

The current content model of <teiCorpus> is: teiHeader, ( ( model.resourceLike+, ( TEI | teiCorpus )* ) | ( TEI | teiCorpus )+ ) ) That is, you may *either* have a series of 1 or more <TEI> and <teiCorpus> elements, intermingled; OR you can have one or more of <facsimile>, <fsdDecl>, <sourceDoc>, and <text> elements intermingled followed by zero or more <TEI> and <teiCorpus> elements intermingled. This is exactly the same as saying teiHeader, model.resourceLike*, ( TEI | teiCorpus )* except that it requires at least one child <TEI>, <teiCorpus>, <facsimile>, <fsdDecl>, <sourceDoc>, or <text>. In the new <standOff> world, we have voted to make <TEI> a member of model.resourceLike. Thus we have to alter the content model of <teiCorpus> because as written it would be ambiguous (if a <TEI> is your first child after <teiHeader>, you don't know which branch of the content model you are in). It is not too difficult to solve the ambiguity problem: teiHeader, ( ( model.resourceLike+, ( teiCorpus, ( TEI | teiCorpus )* )? ) | ( teiCorpus, ( TEI | teiCorpus )* ) ) ) I am pretty confident this content model validates the same set of documents (and, perhaps as importantly, rejects the same set of documents) as the original content model (with <TEI> in model.resourceLike). I am not against using this content model. But it occurs to me that a) it is a bit cumbersome b) the set of documents permitted is already screwy c) it looks very different from the content model of <TEI>, which (in the new world order) <teiCorpus> is very similar to. One possible solution is to 1) add <teiCorpus> to model.resourceLike, too; and then 2) change content model of <teiCorpus> to match that of <TEI> (in the new standOff world): teiHeader, model.resourceLike+ This has the advantage of having a very clean, understandable content model for <teiCorpus> (and no ambiguity). It has the disadvantage that it allows for even more screwy things. E.g. <teiCorpus> <teiHeader> <standOff> <TEI> <facsimile> <TEI> <teiCorpus> <TEI> <facsimile> <TEI> <teiCorpus> <facsimile> </teiCorpus> It has the feature (which some will consider an advantage, others a disadvantage, I'm sure) that <TEI> and <teiCorpus> become the same thing. Just as an XSLT stylesheet can have an outermost element of <xsl:stylesheet> or <xsl:transform>, no difference, a TEI document will be able to have <TEI> or <teiCorpus> as an outermost element, no difference. Same goes at every level of nesting where one is allowed: so is the other, and it can have the same content. Personally, I still think putting <TEI> into model.resourceLike was probably a mistake, but once we've done that, I'm inclined to say throw <teiCorpus> in there, too.

7 10

CI for standOff
by Syd Bauman 11 Dec '19

11 Dec '19

Dear CI server maintainers -- Would it be possible to add the the "sydb-standOff" branch to one or more of the contiuous integration server lists of branches-to- build? I can build it locally, but am soon to send out mail asking that people look at the changes and play with the result. Having a CI copy would make that easier on folks. If not I can certainly put the build I generate up on the web somewhere.

3 2

Unihan etc.
by Martin Holmes 10 Dec '19

10 Dec '19

Hi all, Following today's discussion, I posted a brief summary on the pull request: <https://github.com/TEIC/TEI/pull/1901> Please read and feel free to edit/expand where necessary. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

1 0

Triangle SCI and possible Mellon grant
by Hugh Cayless 10 Dec '19

10 Dec '19

Hi all, I was supposed to send this a couple of weeks ago. My apologies. In October, Martina and I, along with several other folks, were at the Scholarly Communications Institute here in NC. Our group was focused on doing something about better internationalizing the TEI, including improving the translation process, introductory materials, etc. At the end, we were approached by Patricia Hswe, who’s a program officer at Mellon about possibly putting together a proposal to do some of this work. The following document is a kind of summary of our conclusions plus some ideas for how extra funding might help: https://docs.google.com/document/d/1TPuMHN4ZxklX5JlLo7HEFmEgTiUvuRD0cxDFE65… Patricia would like us to submit a prospectus, which would lead to a grant proposal if it is accepted. Your thoughts are, of course, welcome. So, interesting times! Hugh Sent from my phone.

1 0

delete git branch?
by Syd Bauman 10 Dec '19

10 Dec '19

I re-named the "nest_TEI_deprecate_teiCorpus" branch to "sydb_standOff". That really means, of course, that I copied it. If we delete the old one, is the history still kept in the new one? (Looking at [1] it looks like the history would be kept, and we can just delete the old one.) Notes ----- [1] https://github.com/TEIC/TEI/commits/sydb_standOff/P5/Source/Specs/TEI.xml

2 1

Next call: Tuesday, December 10
by Scholger, Martina (martina.scholger＠uni-graz.at) 10 Dec '19

10 Dec '19

Dear all, this is a reminder for our next call on Tuesday, December 10 (PST 6:00-7:30, EDT 9:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30) We will start with the discussion on uniHan and standoff since Martin will kindly be joining us and has to head off to work at 7. Please have a look at the agenda and add your topics: https://docs.google.com/document/d/10zJFdN-p2WxGFTiRC8dMySCKe8QQ043lam1WFxz… Best, Martina

3 3

Spring F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 10 Dec '19

10 Dec '19

Dear all, yet again we have a number of great locations to choose from for our next spring F2F meeting. To get an idea about our preferences I ask you to fill in the doodle before our call tomorrow: https://doodle.com/poll/xaf3f4exhy6geyqf Best, Martina

4 3

oxygen-tei framework fix
by Martin Holmes 05 Dec '19

05 Dec '19

Hi all, Those of you on the Stylesheets call on Tuesday will remember that we discovered in the course of it that Syd's TEI for TEI Customizations template/ODD was available in the TEI P5 framework in Oxygen but not in the TEI ODD framework. I raised a ticket for that at the time, and I just figured it out and fixed it: <https://github.com/TEIC/oxygen-tei/issues/39> I put an explanation of the problem on the ticket, because we're sure to stumble over this again. If you're using the bleeding-edge version of the plugin, you should now be able to update and see Syd's thing in the TEI ODD framework options. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

2 1

Re: [Tei-council] release dates, some findings
by James Cummings 05 Dec '19

05 Dec '19

No objections to that. For the record some of these may have been instances where we had done a full release, realised that there was some corrigible error (in the build/release process), and then manually or otherwise did a re-release without changing the actual date of release. That is, we did the release, announced it, noticed an important error (like the non-English pages having not generated properly) and then silently fixed it without mentioning it publicly. ;-) There were also instances where stumbling blocks in the release meant that it went over midnight in the timezone where the build was happening. Not saying we shouldn't update the webpages to match the XML reality, just explaining. (Now off strike, but working to contract.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Peter Stadler <stadler(a)edirom.de> Sent: 29 November 2019 06:39 To: TEI Council <tei-council(a)lists.tei-c.org> Subject: [Tei-council] release dates, some findings for the record: While working through the Guidelines releases for the Zenodo ingest I discovered and fixed some inconsistencies regarding release dates at [1]. A few dates differed from what is mentioned in the respective release notes, so I fixed it to match the release notes. Lastly, one release note has the wrong date [2] which I already fixed in the xml [3]. I propose to adjust the date in the html version in the vault, as well, which I’ll do as soon as I get access to the vault. Best Peter [1] https://tei-c.org/guidelines/P5/ (table: „Version Date of Release (& Release Notes)“) [2] https://tei-c.org/Vault/P5/current/doc/tei-p5-doc/readme-3.2.0.html [3] https://github.com/TEIC/TEI/commit/9150346745c0057d74a20d0a36bcbbb09260d865

2 1

missing council reports
by Lou Burnard 04 Dec '19

04 Dec '19

To be exact: reports for the following years are missing: 2003, 2004, 2005, 2006, 2007, 2014 I have the first three.

1 0

vault.tei-c.org
by Peter Stadler 04 Dec '19

04 Dec '19

Dear all (Council and infrastructure group), here’s yet another update on the move to humanum: In our strive to separate out concerns and services we added another subdomain vault.tei-c.org where you can find – drumroll!" – the Vault. The data stems from a mounted volume which also feeds the ’traditional’ host at https://tei-c.org/Vault/. So, at present this is purely an additional service for us to test and sort things out. The vault.tei-c.org is run by an nginx docker container and the service description can be found in the infrastructure repo [1]. I already added CORS and some mime types for XML files – if anything is missing, drop me a line! Looking at the vault I found that the last three releases of the Stylesheets were missing at [2]. I just added them (as you can see from the timestamp) and updated the symlinks to „current“ and „current-old“. Second, I fixed the release date for 3.2.0 in the respective readme files (as I promised in my last mail). Looking at the P5 releases in the vault [3] I see „current-broken“, "current.03.04.2019“, and „X.X.X“. Is this in use by anyone? I suspect these are just leftovers from the migration which I’d like to delete. And there’s is a hidden „.svn“ folder which looks like it could be deleted as well. If no-one objects, I’ll do so. Best Peter [1] https://github.com/TEIC/infrastructure/tree/master/humanum [2] https://tei-c.org/Vault/Stylesheets/ or https://vault.tei-c.org/Stylesheets/ [3] https://vault.tei-c.org/P5/

3 6

Stylesheets meeting tomorrow, Tue 03 Dec 14:00Z
by Syd Bauman 03 Dec '19

03 Dec '19

Sorry I'm late on this. (I try to post these 24 to 72 hours in advance.) We have a Stylesheets Group meeting scheduled for this coming Tue 2019-12-03 14:00Z. timing ------ It will be: * 06:00 PST (Victoria) * 09:00 EST (New York) * 14:00 GMT (London) * 15:00 CET (Berlin) place ----- I am expecting we will use Google Hangouts. (I *think* I have my Google Hangouts life working. :-) topics ------ Main topics are the carry-over from last month: 1) Ticket 393.[1] 2) Ticket 399.[2] Martin has posted where he thinks the problem is on the ticket. If he's right (and I have no reason to believe he isn't), I'm not sure I like his proposed solution. So this may require some discussion. notes ----- [1] https://github.com/TEIC/Stylesheets/issues/393 [2] https://github.com/TEIC/Stylesheets/issues/399

5 5

Re: [Tei-council] Stylesheets meeting tomorrow, Tue 03 Dec 14:00Z
by James Cummings 02 Dec '19

02 Dec '19

I might be late to this. (I'm not counting TEI things as 'work' for the purposes of the UCU strike in HE here in the UK -- protesting the ongoing theft if our pensions, precarious contacts, absolutely gender pay gap. However I'll have to commute back home from the picket line rather than go to my office.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Raffaele Viglianti <raffaeleviglianti(a)gmail.com> Sent: Monday, December 2, 2019 4:30:13 PM To: Bauman, Syd <s.bauman(a)northeastern.edu> Cc: TEI Council <tei-council(a)lists.tei-c.org> Subject: Re: [Tei-council] Stylesheets meeting tomorrow, Tue 03 Dec 14:00Z Hi all, Unfortunately I will have to miss this again. My dept scheduled an all-hands meeting for tomorrow at 10am. Raff On Mon, Dec 2, 2019 at 11:28 AM Syd Bauman <s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>> wrote: Sorry I'm late on this. (I try to post these 24 to 72 hours in advance.) We have a Stylesheets Group meeting scheduled for this coming Tue 2019-12-03 14:00Z. timing ------ It will be: * 06:00 PST (Victoria) * 09:00 EST (New York) * 14:00 GMT (London) * 15:00 CET (Berlin) place ----- I am expecting we will use Google Hangouts. (I *think* I have my Google Hangouts life working. :-) topics ------ Main topics are the carry-over from last month: 1) Ticket 393.[1] 2) Ticket 399.[2] Martin has posted where he thinks the problem is on the ticket. If he's right (and I have no reason to believe he isn't), I'm not sure I like his proposed solution. So this may require some discussion. notes ----- [1] https://github.com/TEIC/Stylesheets/issues/393 [2] https://github.com/TEIC/Stylesheets/issues/399 _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0