- Tei-council - lists.tei-c.org

Deb packages key signing broken?
by Martin Holmes 07 Mar '21

07 Mar '21

Hi all, My Jenkins server says: Err:9 https://packages.tei-c.org/deb/binary ./ Release.gpg The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> [...] W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.tei-c.org/deb/binary ./ Release: The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> W: Failed to fetch https://packages.tei-c.org/deb/binary/./Release.gpg The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> Did the packages get signed correctly, or has the key expired? Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

3 3

what we’re up to
by Bauman, Syd 05 Mar '21

05 Mar '21

Martin, Nick, and I are halfway through updating the repos to use Saxon 10. We have finished the Stylesheets repo, which was probably the easier one. It has been checked in as the “saxon10” branch. We expect to do the TEI repo soon (unless someone else jumps on this interminable task). We expect to issue a PR for each repo, assigned to the same person (any volunteers?), at roughly the same time. Probably a good idea that each of the repos be merged at roughly the same time, too. (I think there shouldn’t be any circularity problem from this change, but just in case, having them both get to Mr. Jenkins in the same cycle sounds like a good defense.) I just realized there are no tickets for this, so I plan to create issues now.

1 0

Stylesheets meeting Thu 04 Mar
by Bauman, Syd 04 Mar '21

04 Mar '21

We have a Stylesheets meeting scheduled for tomorrow (likely today by the time you read this), Thu 04 Mar, 19:00Z to 20:30Z. That is * 11:00 PST * 14:00 EST * 19:00 GMT * 20:00 CET for 1½ hours. Agenda: 1. Update to 7.51.1, i.e. issue #488, PR #489 (Syd & Martin) 2. Issues surrounding yesterday’s release of TEI framework for oXygen (Hugh & Martin) 3. Detailed review of PR #327 (Peter) 4. Review of PR #462 (Syd)

3 2

TEI release directory structure
by Peter Stadler 01 Mar '21

01 Mar '21

Hi all, apologies for sending to both groups, but this issue is kind of between Council and infrastructure group, so I thought I’d be better to include both. The issue I see is about the „release“ directory structure, i.e. the stuff at https://tei-c.org/release/ Currently, on the Huma-Num server, „release“ is just a symlink pointing at "Vault/P5/current“ – this caused frequent errors with the Stylesheets release missing due to missing CSS files for building ePubs. It was hacked around by copying Stylesheets to P5 or symlinking Stylesheets into P5. Since the structure under „release“ seems to mimic the "/usr/share/doc“ and „/usr/share/xml“ structure known from Debian systems – and this is the place where the TEI Debian packages are installed by default – I think the *original* setup might have looked like an apache Webserver simply serving its local „/usr/share“ directory under „release“ to the outside. At the latest with the ADHO server crash, this setup got lost and we have a semi-functioning release directory now. IMHO, with our current infrastructure, the proper setup would be to (hard) create the directory „release/doc“ and „release/xml/tei“ and create symlinks within these directories to the respective directories in the Vault: release/doc * tei-p5-doc —> ../../Vault/P5/current/doc/tei-p5-doc * tei-p5-exemplars —> ../../Vault/P5/current/doc/tei-p5-exemplars * tei-xsl —> ../../Vault/Stylesheets/current/doc/tei-xsl release/xml/tei: * Exemplars —> ../../../Vault/P5/current/xml/tei/Exemplars * Test —> ../../../Vault/P5/current/xml/tei/Test * custom —> ../../../Vault/P5/current/xml/tei/custom * odd —> ../../../Vault/P5/current/xml/tei/odd * schema —> ../../../Vault/P5/current/xml/tei/schema * stylesheet —> ../../../Vault/Stylesheets/current/xml/tei/stylesheet * xquery —> ../../../Vault/P5/current/xml/tei/xquery release/oxygen —> Vault/P5/current/oxygen Does that make sense? Anything I’m missing? And of course, I’m curious about some more history that Lou(?) or James(?) might be able to share? Best Peter

3 2

Stylesheets meeting is scheduled for this Thu 04 Mar 19:00Z
by Bauman, Syd 01 Mar '21

01 Mar '21

If I understand correctly, we are scheduled to hold a Stylesheets meeting this coming Thursday, 04 March at 19:00Z to 20:30Z. That is * 11:00 PST * 14:00 EST * 19:00 GMT * 20:00 CET for 1½ hours. I am expecting we will spend a little time reviewing the fix for the 4.2.1 release, and intend to post here an actual agenda with a ticket or two to work on by at least 24 hours before the meeting. I am hoping Martina will also post the details of how to get to the meeting here at least a few hours before the meeting. Looking forward!

1 0

Slight borkitude in moduleRef content model display
by Martin Holmes 25 Feb '21

25 Feb '21

Hi all, Just clicking around in the various types of Guidelines outputs, and I noticed this: <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-moduleRef.html> Take a look at the content model. It's the same in the ebook; it's slightly different but I think also borked in the PDF (p. 1402). I don't think it's urgent, because it was the same in 4.1.0. I'll raise a ticket and start investigating. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

2 3

Version 4.2.0 released
by Nicholas Cole 25 Feb '21

25 Feb '21

Dear Council, The Release team is happy to report that with the exception of the Oxygen Plugin, the build and release of P5 4.2.0 and Stylesheets 7.51.0 has been done. The release notes need some moderately extensive updating, and I will be making some suggested changes and a pull request later today / tomorrow. Very best wishes, Nicholas, Meaghan, and Peter.

3 3

GPG Key
by Nicholas Cole 23 Feb '21

23 Feb '21

Dear Council, Just to note that the current expiration date for the TEI GPG key is the second of next month. This can be extended, of course, without problem, but I’m not sure whose task that is. Best wishes, Nicholas

2 3

release notes
by Scholger, Martina (martina.scholger＠uni-graz.at) 22 Feb '21

22 Feb '21

Dear all, I've added a first draft of the release notes to the release branch (release-4.2.0): https://github.com/TEIC/TEI/commit/06af7ce77dae7d133c39da68cf0a179a579bca0a Please feel free to modify and please correct my spelling errors. Best, Martina

5 8

Release Number?
by Nicholas Cole 20 Feb '21

20 Feb '21

Dear Council, There is a lot in this release. Have we all agreed what the version number is? ;-) If there are any last pleas not to ‘freeze’ yet, make them now. As far as I can see, the Jenkins servers are reporting builds correctly. I’m going to ‘freeze’ at 15:00pm UK time, for Release 4.2.0, unless we think this is a ‘major’ version. (I actually think there’s quite a lot in this release, actually). Best wishes, N.

6 6

Freeze?
by Nicholas Cole 20 Feb '21

20 Feb '21

Dear Council, I suppose the Freeze starts at the end of today. Is that right? N

3 6

broken persPronouns
by Bauman, Syd 18 Feb '21

18 Feb '21

~10 hours ago PR 2014 was merged into dev. This broke the build because we (Meaghan and I) had examples that used <persPronouns> in running-prose-like places (inside <closer> and <docAuthor>, to be precise); but, because <persPronouns> was (as per the original FR) only a member of model.personPart, it was only allowed inside <person>, <personGrp>, and <persona>. We put our heads together on a brief telephone consultation, and concluded that we believe that the new <persPronouns> element is going to be desired for the encoding of signature blocks in email or blog posts as much or more than in personographies. Therefore we think the solution is to permit <persPronouns> in those sorts of places, not to remove the examples. Thus I have made <persPronouns> a member of model.persNamePart (in addition to model.personPart). This allows <persPronouns> in <closer> and <docAuthor>, and thus should fix the build. It also allows <persPronouns> in quite a few desirable places like inside an <s>, a <p>, or an <item>. It also allows it inside lots of somewhat screwy places like <tagUsage> and <unti>. However, <roleName> (for example) is allowed in precisely the same set of places, so even if screwy, at least it is consistently screwy. If anyone wants to object, please do so quickly (by Fri latest, preferably earlier). The commit that would need to be reverted is 1f874af07. Sorry everyone. The reason this got past me, BTW, is because oNVDL does not run on my system. (Martin is saying “I told you so” right now. :-)

4 3

semantic version conversation
by Bauman, Syd 15 Feb '21

15 Feb '21

At the VF2F we apparently discussed PR 1996 (which implements one point of the discussion on issue 1993). Does anyone remember what, if anything, I said about it? My suspicion is I was making tweaks for 2032 at the time, and did not realize y’all were accepting the idea that TEI/@version (et al.) is a “version number following the Semantic Versioning Specification”. Because it is not. This would have serious (albeit extremely rare) side-effects in processing, because it means we would be obligated to drop anything from a ‘+’ on (i.e., the build metadata) when ascertaining order of precedence. Much more importantly, it means that we would be obligated to change our system of changing the MAJOR and MINOR portions of the version number. (The PATCH bit would still be updated only for backwards-compatible bug fixes.) We currently update MINOR every new release (roughly every 6 months), and only update MAJOR if and when there is a significant change in functionality (e.g., switching to PureODD). If we adopt SemVer, we would be obligated to change MAJOR whenever any backwards-incompatible change occurred, no matter how small. Furthermore, we would have to define backwards-incompatible. Obviously a change (even a bug fix) that changes the schema such that a document that was valid before the change is invalid after it is a change that requires a bump in the MAJOR portion in the SemVer system. But what about the reverse, a change that allows a document that had been invalid to be considered valid? (E.g., adding "PostScript" to the value list of @scheme in att.styleDef.) Seems to me that is backwards-incompatible too, just in a different way. (The schema no longer catches the same “error” it used to.) Conversely, of course, we could use the idea that SemVer refers to the incompatibility of the API, not of the schema, to decide not to bump MAJOR for incompatible schema changes. But if the version number is about the API, what API is it about, and what does it have to do with our release system and schemas? I think all of this can be avoided by just saying “based on” rather than “following” the Semantic Versioning specification. (Note that in either case it should be capitalized and have a reference in the bibliography to the spec<https://semver.org/> that we don’t follow but maybe will say that we do.) If y’all really think we really should say we are following it, I will accept the majority opinion. That said, you should not vote in favor of “following” until you have actually read the SemVer<https://semver.org/> spec.

5 9

keep Subversion version # capability? On stupidity
by Bauman, Syd 13 Feb '21

13 Feb '21

Hey all. Two things. First just wanted to clarify that when I said “because it’s stupid” in reference to <text> as a direct child of <teiCorpus>, I was trying to express that it was inappropriate and careless of us to ever let <text> slip into the content model of <teiCorpus> in that position (which happened in 2016-02). I am (as y’all can probably tell) somewhat annoyed with myself for not noticing this as a problem when it came up then. I was not calling users (like Martin and Janelle, among others) who make use of this perfectly valid facility stupid. My current annoyance, though, is some horrible code. Thus I want input on what to do with P5/repodate.xml. This is an untracked file generated by the Makefile during the P5 build process and read by the P5/Utilities/expand.xsl program. That program changes the <?insert date?> PI found in P5/Source/guidelines-en.xml (and in P5/Source/guidelines-fr.xml) and thus in p5.xml into the date the GLs were built, and changes the <?insert revision?> PIs into the git commit number, etc. This whole system is made quite a bit more complicated by the fact that the code is designed to work whether the version control system we use is Subversion or git. My instinct is that it is no longer useful to maintain the code that worries we might be using Subversion rather than git. We have not been using Subversion for roughly 5 years,[1] and I do not see us ever going back to it. Sure, GitHub the service is a company and may fold, but git the command is not going away. Something better may come along, and we may switch in the future, but that means re-working all this code, anyway. The only reasonable concern that floats through my tiny brain is that maybe we need this code in case someone uses the current build system to try to generate a very old copy of the Guidelines that dates back to the pre-git days. But I do not have any reason to believe that either anyone would use the modern Makefile to build an ancient copy of the Guidelines (you would use the build system that came with that revision), or that there would be any hope of success even if this code for handling Subversion revision numbers was left in place. So does anyone think we should leave the Subversion code in there? Going once … P.S. Given that we are in the refrigeration period, I will be doing this in a separate branch and leave it to others whether to merge it before or after release. It should have absolutely no effect on the output at all. (And if anything goes wrong, would be very easy to spot by just checking the output of PIs.) Notes [1] My vague recollection is that the changeover from Subversion in Sourceforge to git in GitHub was masterfully handled by Peter Stadler in 2015 or 2016.

3 4

Next VF2F: May 7 and 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 12 Feb '21

12 Feb '21

Dear all, Our next virtual F2F meeting is on May 7 and 8. As last time, the North American Group starts on Friday at 12am PST / 3pm EST (3 hours); the Europeans continue on Saturday morning at 9am BST/10am CET (3 hours); the full Council meets on Saturday 6am PST / 9am EST / 2pm BST / 3pm CET (4 hours). Please have a look at the google calendar to check the meeting times. Best, Martina

1 0

Council call in 40 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Feb '21

11 Feb '21

Dear all, Our call starts in 40 minutes. Agenda: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

1 0

Re: [Tei-council] Mr. Jenkins is ignoring me
by Bauman, Syd 10 Feb '21

10 Feb '21

Thank you, Peter! (Why did I not see it in the dashboard? Why did I miss the build failure locally? Hmmm...) ________________________________ seems it’s there at https://jenkins.tei-c.org/job/TEIP5-Test-dev/680/ The build has been kicked off due to your commit but failed, hence the subsequent jobs have not been started at all.

1 0

Mr. Jenkins is ignoring me
by Bauman, Syd 10 Feb '21

10 Feb '21

Attn: Peter & Martin I committed to dev branch at 20:50:00 localtime (± 6 sec), commit #9d8122417ee2ec8d05f979bf920f98069586817a. That was over 2 hours ago, and yet neither Jenkins[1] seems to have noticed. Worse, one of them seems to have kicked off a build at roughly halfway between then and now, but it does not list my commit as its reason for existing. Snif! What is going on? — Syd “I’ve been ghosted by a CI server!” Bauman [1] https://jenkins.tei-c.org/view/TEI%20dev/ https://jenkins2.tei-c.org/view/Dev%20branch%20jobs/

2 1

Re: [Tei-council] Next Stylesheets meeting
by BERMUDEZ SABEL Helena 09 Feb '21

09 Feb '21

Hello! No issues with the proposed date. Best, H. Helena Bermúdez Sabel Chercheuse FNS senior Institut des sciences du langage Université de Neuchâtel ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 08 February 2021 18:08:07 To: tei-council(a)lists.tei-c.org; Martin Holmes; Nicholas Cole Subject: [Tei-council] Next Stylesheets meeting Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

6 5

PDF build with Japanese
by Martin Holmes 08 Feb '21

08 Feb '21

Hi all, The ruby stuff is now merged into the repo, and I've spent a good few hours now trying to get the PDF to build properly. It dies with this error: ! LaTeX3 Error: The key 'fontspec-opentype/...' is unknown and is being (LaTeX3) ignored. which is something to do with xml:lang='ja' appearing in the source. At one point I got it to build, but without the Japanese language attributes, the characters just come out as square boxes. Can anyone who knows more about LaTeX than me suggest anything? I don't really want to go round removing xml:lang attributes just to get past the PDF problem, but I don't know what else to do at this point. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

4 8

Next Council call: Feb 11
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, This is the preliminary agenda for our next Council call on February 11 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

2 1

Next Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

1 0

Refrigeration
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, We are close to refrigeration, starting on Friday, February 12. After this date we should not commit major changes to the schema. Minor changes like improvements in wording, correction of typos etc. are fine. Please have a look at the open milestone 4.2.0 Guidelines issues (https://github.com/TEIC/TEI/issues?q=is%3Aissue+milestone%3A%22Guidelines+4…) and 7.51.0 Stylesheets issues https://github.com/TEIC/Stylesheets/issues?q=is%3Aopen+is%3Aissue+milestone…. Please remove issues that you will not tackle before the next release. Best, Martina

1 0

positioning of examples vis-a-vis prose
by Bauman, Syd 08 Feb '21

08 Feb '21

Working on ruby glosses, I think it is quite useful to say in the prose of CO things like “the following example” or “the example above”. I note that the “Examples” subsection of the “Style Notes” section of TCW 20<https://teic.github.io/TCW/tcw20.html> (why don’t these <div>s have IDs?) says in the very first paragraph not to do that. However, it is clear to me that the rest of that paragraph is about examples in tagdocs, not examples in the prose of the Guidelines. Furthermore, I think the logic (someone might come along later and add an example) at best does not really apply here in the prose (where being able to differentiate examples is useful), and at worst is basically silly. (I very vaguely remember the argument in favor of this restriction, and begrudgingly agreeing to it; but I cannot find the reasoning that led me to that agreement now, nor can I recall if it was intended for only tagdocs or for examples in the prose, too :-) That said, why don’t we have a mechanism for referring to specific examples?

4 3

Re: [Tei-council] More NVDL issues: Spec files not validating
by Bauman, Syd 05 Feb '21

05 Feb '21

Trying to validate which schema file against which schema? ________________________________ Just trying to validate the schema itself in oXygen.

3 10