It seems to be the ePub building is broken. This seems to be something to do with broken fragment identifiers in the ePub pointing to BIB and ref files for a variety of things. See Error list at http://jenkins.tei-c.org/job/TEIP5-Documentation-dev/2669/parsed_console/ Thought I'd mention it in case it helped toward diagnosing the problem... -- Dr James Cummings, James.Cummings@newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: tei-council-bounces@lists.tei-c.org <tei-council-bounces@lists.tei-c.org> on behalf of Hugh Cayless <philomousos@gmail.com> Sent: 18 January 2018 14:56:34 To: TEI Council Subject: Re: [tei-council] Jenkins build process Maybe because the Documentation build is broken? http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation-dev/ I'm taking a look at it now. On Thu, Jan 18, 2018 at 7:14 AM, Mylonas, Elli <elli_mylonas@brown.edu> wrote:
I asked Syd the same question last night. Thought it was me.
Elli Mylonas
[Sent from my phone, please excuse typos or autocorrect]
On Jan 18, 2018 3:43 AM, "Scholger, Martina (martina.scholger@uni-graz.at) " <martina.scholger@uni-graz.at> wrote:
Dear all,
I'm a bit confused about the Jenkins build process. The last build is from 5 days ago but a lot of commits were made yesterday.
Best, Martina
Mag. Martina Scholger Zentrum für Informationsmodellierung Austrian Centre for Digital Humanities Universität Graz A-8010 Graz | Elisabethstraße 59/III Tel: +43 316 380 2291 eMail: martina.scholger@uni-graz.at<mailto:martina.semlak@uni-graz.at> Web: http://informationsmodellierung.uni-graz.at<http:// informationsmodellierung.uni-graz.at/> | http://gams.uni-graz.at<http:/ /gams.uni-graz.at/>
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived
Syd suggested that his efforts to fix #1476 may have caused the problem. Said he was going to look at it again. --elli [Elli Mylonas Senior Digital Humanities Librarian and Center for Digital Scholarship University Library Brown University library.brown.edu/cds] On Thu, Jan 18, 2018 at 11:57 AM, James Cummings < James.Cummings@newcastle.ac.uk> wrote:
It seems to be the ePub building is broken. This seems to be something to do with broken fragment identifiers in the ePub pointing to BIB and ref files for a variety of things. See Error list at http://jenkins.tei-c.org/job/TEIP5-Documentation-dev/2669/parsed_console/
Thought I'd mention it in case it helped toward diagnosing the problem...
--
Dr James Cummings, James.Cummings@newcastle.ac.uk
School of English Literature, Language, and Linguistics, Newcastle University
________________________________ From: tei-council-bounces@lists.tei-c.org <tei-council-bounces@lists. tei-c.org> on behalf of Hugh Cayless <philomousos@gmail.com> Sent: 18 January 2018 14:56:34 To: TEI Council Subject: Re: [tei-council] Jenkins build process
Maybe because the Documentation build is broken? http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation-dev/
I'm taking a look at it now.
On Thu, Jan 18, 2018 at 7:14 AM, Mylonas, Elli <elli_mylonas@brown.edu> wrote:
I asked Syd the same question last night. Thought it was me.
Elli Mylonas
[Sent from my phone, please excuse typos or autocorrect]
On Jan 18, 2018 3:43 AM, "Scholger, Martina ( martina.scholger@uni-graz.at) " <martina.scholger@uni-graz.at> wrote:
Dear all,
I'm a bit confused about the Jenkins build process. The last build is from 5 days ago but a lot of commits were made yesterday.
Best, Martina
Mag. Martina Scholger Zentrum für Informationsmodellierung Austrian Centre for Digital Humanities Universität Graz A-8010 Graz | Elisabethstraße 59/III Tel: +43 316 380 2291 eMail: martina.scholger@uni-graz.at<mailto:martina.semlak@uni-graz.at> Web: http://informationsmodellierung.uni-graz.at<http:// informationsmodellierung.uni-graz.at/> | http://gams.uni-graz.at <http:/ /gams.uni-graz.at/>
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I've dug into this a bit now, and I'm finding a bunch of corner cases. There's not a single unifying cause, just cases where the ID generated for the correct source location don't match the ones generated for the bibliography, for different reasons. I'll look at it a bit more, but we may be better off just removing @source='UND' from the cases where it causes an error for now. We're seeing this in the epub because it actually attempts to validate all of its links. Hugh On Thu, Jan 18, 2018 at 12:17 PM, Syd Bauman <s.bauman@northeastern.edu> wrote:
Yes, I did look at it again, but still have gotten (almost) nowhere. Anyone else who wants to look into this, speak up.
Syd suggested that his efforts to fix #1476 may have caused the problem. Said he was going to look at it again. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I concur with most of this: * does not seem to have anything to do with UND itself - may come up w/ UND because there are so many of 'em * probably occurs elsewhere, just not getting caught I am in the middle of ascertaining the paths to all of the <egXML>s in BACKLIST, in the hopes that if I locate the 8 problematic ones in there, something will jump out. Maybe we should talk tomorrow?
I've dug into this a bit now, and I'm finding a bunch of corner cases. There's not a single unifying cause, just cases where the ID generated for the correct source location don't match the ones generated for the bibliography, for different reasons. I'll look at it a bit more, but we may be better off just removing @source='UND' from the cases where it causes an error for now. We're seeing this in the epub because it actually attempts to validate all of its links.
Have discovered lots of things about guidelines.xsl, but no closer to solving this problem. I should mention the one bit where I am not sure I agree w/ you on this, though, Hugh:
we may be better off just removing @source='UND' from the cases where it causes an error for now
I'm wondering if we have to make a temporary kludge fix, it might be better to remove the test from the epub build, since we don't test for it anywhere else. (Yes, we may end up w/ bad links in the HTML, but we may already, the links aren't helpful in this case anyway, and at least the HTML and the ePub would be more likely to match.) Of course, that said, I don't know *how* to remove the test in the epub build, as it is in java. Do you (Hugh) have time tomorrow to Skype (or GH or whatever) on this?
I concur with most of this: * does not seem to have anything to do with UND itself - may come up w/ UND because there are so many of 'em * probably occurs elsewhere, just not getting caught
I am in the middle of ascertaining the paths to all of the <egXML>s in BACKLIST, in the hopes that if I locate the 8 problematic ones in there, something will jump out. Maybe we should talk tomorrow?
I’m afraid it’s not that simple. As far as I know, the epub check is just a single validation pass, and link resolution is one of the things it does. I don’t think we can just not validate the epub. Yeah, I can chat tomorrow. Sent from my phone.
On Jan 18, 2018, at 20:04, Syd Bauman <s.bauman@northeastern.edu> wrote:
Have discovered lots of things about guidelines.xsl, but no closer to solving this problem.
I should mention the one bit where I am not sure I agree w/ you on this, though, Hugh:
we may be better off just removing @source='UND' from the cases where it causes an error for now
I'm wondering if we have to make a temporary kludge fix, it might be better to remove the test from the epub build, since we don't test for it anywhere else. (Yes, we may end up w/ bad links in the HTML, but we may already, the links aren't helpful in this case anyway, and at least the HTML and the ePub would be more likely to match.)
Of course, that said, I don't know *how* to remove the test in the epub build, as it is in java.
Do you (Hugh) have time tomorrow to Skype (or GH or whatever) on this?
I concur with most of this: * does not seem to have anything to do with UND itself - may come up w/ UND because there are so many of 'em * probably occurs elsewhere, just not getting caught
I am in the middle of ascertaining the paths to all of the <egXML>s in BACKLIST, in the hopes that if I locate the 8 problematic ones in there, something will jump out. Maybe we should talk tomorrow? -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Heh-heh. I don't think it's that simple either, but I didn't mean end the entire validation pass, I meant go into its little Java innards and turn off the link check pass for the file BIB.html. (That's even harder for me, as I don't speak Java.)
I’m afraid it’s not that simple. As far as I know, the epub check is just a single validation pass, and link resolution is one of the things it does. I don’t think we can just not validate the epub. Yeah, I can chat tomorrow.
I've got two objections to trying this (well, maybe three). There is no check for BIB.html, so we'd have to add a condition that bypasses link checking for files with that name. This is someone else's software, so we'd have to fork it and produce our own ePub validator. And I *really* don't think we can say what constitutes validity for an ePub file. On Thu, Jan 18, 2018 at 11:32 PM, Syd Bauman <s.bauman@northeastern.edu> wrote:
Heh-heh. I don't think it's that simple either, but I didn't mean end the entire validation pass, I meant go into its little Java innards and turn off the link check pass for the file BIB.html. (That's even harder for me, as I don't speak Java.)
I’m afraid it’s not that simple. As far as I know, the epub check is just a single validation pass, and link resolution is one of the things it does. I don’t think we can just not validate the epub. Yeah, I can chat tomorrow. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I only see one objection in there, but I think it's sufficient: if it's someone else's program, that's not where we should be mucking.
I've got two objections to trying this (well, maybe three). There is no check for BIB.html, so we'd have to add a condition that bypasses link checking for files with that name. This is someone else's software, so we'd have to fork it and produce our own ePub validator. And I *really* don't think we can say what constitutes validity for an ePub file.
participants (4)
-
Hugh Cayless -
James Cummings -
Mylonas, Elli -
Syd Bauman