Thanks Martin! This is all very encouraging. I am pretty sure tei-p5-database is long since past its sell-by date, though eXist folks might like to roll it, or something like it, into their demo material. Magda? On 01/12/16 01:02, Martin Holmes wrote:
I've investigated further, by actually trying to install some of the unsigned packages on my local system.
teu-p5-schema, tei-p5-doc, tei-p5-exemplars and tei-p5-test all install.
tei-p5-source depends on tei-xsl.
The tei-xsl package would not install because it had a dependency on "saxon". I assume that it's the saxon package that was originally distributed by Sebastian:
http://tei.oucs.ox.ac.uk/teideb/
After looking into this package, it seems to me that it does no more than install saxon9he.jar and set it up, so I figured that this dependency could be replaced with libsaxon-java. I tried this by changing the control file locally and building the package; I was able to install the result, and following that I was able to install tei-p5-source. Everything basically seems to work, although calling a transformation such as teitorng fails to find the local P5 source where it's been installed, and instead uses the Vault copy. Not sure if that's what should happen or not.
Anyway, I've changed the control file in the Stylesheets deb build to depend on libsaxon-java instead of "saxon".
tei-p5-database is supposed to install a bunch of XQuery and stuff into an existing eXist xmldb instance, but the included PERL scripts assume that eXist is running under Cocoon (nobody does that any more, and in fact I think it's impossible to build eXist to work that way). I didn't test it because I have various eXist instances locally that I don't want to risk. I'm not sure whether there's any point in keeping this package.
If anyone knows more than me about any of this stuff, please pipe up and correct me.
I've been looking into the possibility of creating a deb package repo on the Jenkins server itself, and doing the package signing there. That would make me the distributor of the packages (it has to be a person with an email address, and all the setup should be done when logged onto the hosting server itself, I think). It would be doable, but I do think it would be preferable to have the tei user on tei-c.org do this, with an email address that can be monitored by multiple people and the capability for anyone able to log on as tei to do a package release. It can be done:
http://troubleshootingrange.blogspot.ca/2012/09/hosting-simple-apt-repositor...
and contrary to what I believed before, I think a script could simply pull the latest built packages from Jenkins and sign them locally.
Cheers, Martin
On 2016-11-30 08:39 AM, Martin Holmes wrote:
I've looked into setting up an Ubuntu PPA, and it seems to require that the packages be built on the Launchpad server; that looks like more complication than we probably want, so my sense is that a locally-managed repo would be the best option.
I also remember a detailed discussion to decide which of the packages we wanted to keep. The outcome appears to be that we no longer build a whole set of packages that were originally being built -- compare this list:
http://tei.oucs.ox.ac.uk/teideb/
to this:
http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/
Cheers, Martin
On 2016-11-28 11:10 AM, Martin Holmes wrote:
Hi Lou,
Sorry you think I'm just making difficulties; I was just trying to remember the conversation that happened around this. It wasn't my ticket -- Stefan has it, and Peter's last comment reflects what I remember.
https://github.com/TEIC/TEI/issues/1441
Another option might be for a single individual who's enthusiastic about it to set up an Ubuntu PPA. That's less official and perhaps a good interim solution.
Cheers, Martin
On 2016-11-28 10:59 AM, Lou Burnard wrote:
OK, let me put this another way.
We are about to do another release, a major one. It won't be available as a debian package unless someone steps up able and willing to assume the weighty responsibility of being a debian release expert. Do we care? Debian users will, especially since we went to the trouble of asking their opinion last year. I care, because I want to be able to tell Ubuntu peeps that they can just grab the tei-stylesheet package (for example) and get moving, without having to explain how to install it from Github.
If I didn't know you better Martin, I'd think you were just making difficulties for the sake of it. Of course we need a good long term solution, and yes, it would be very nice if we could build all the components of the release on one machine which we (sort of) own. But we're not going to be there for a wee while yet. And this release is going to happen in a week or two. Is it going to be the first one with no debian support at all or (hopefully) the last one we have had to cobble together using the good will of one or two council members?
On 28/11/16 18:41, Martin Holmes wrote:
This is an overview of what would be required:
https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
The key bit, I think, is that "in general, you should run [gpg --gen-key] on the computer hosting the apt repository, as the user that will sign the packages". If I understand that correctly, then either a single individual with control over their own server would end up volunteering to be the long-term maintainer of the deb packages (which was the situation with Sebastian), or a generic user on a TEI server (presumably the "tei" user on tei-c.org) would do it, so that the update/release duties could be passed from person to person over time.
That's why we wanted to build/release on tei-c. If anyone remembers differently, please correct me.
Cheers, Martin
On 2016-11-28 09:53 AM, Lou Burnard wrote:
[apologies for the preceding aborted message]
Thanks for the quick response Martin.
It doesn't seem to me that "backburnering" is a very desirable state of affairs. At the very least http://tei.oucs.ox.ac.uk/teideb/ needs to be updated with a warning if it is not currently serving up current versions of the packages.
If Stefan was fingered as DPM, he will need replacing THIS MONTH, as he is no longer active on Council.
I don't see what the possibility or otherwise of building on tei-c.org has to do with it. We don't worry about that when building other TEI products: they get built where they get built. The issue here is where they are going to be served from. You don't need saxon to run a debian repo sfaik ! Someone suggested we could set up a PPA (whatever that is) on github quite easily, if I recall aright.
Or we should just say, sorry we don't do that anymore and stand by for some bad vibes.
On 28/11/16 17:38, Martin Holmes wrote: > As far as I recall, this is the situation: > > The debs were always released by Sebastian, and signed with his > personal key. IIRC James now has access to that key and could > conceivably sign packages, but I think everyone agreed that would > be a > bad idea. > > Therefore there was a plan for someone else to take over signing > and > releasing the packages, and Stefan was looking into this the last > time > I heard anything about it. > > This was also partly tied up with the question of whether we should > build things on tei-c.org, and that issue is tangled up with the > problem of the version of Saxon on tei-c being too old for building > purposes, but required IIRC for the existing CMS system; so the > discussion may have been back-burnered pending the replacement > of the > CMS with something more modern. > > Cheers, > Martin > > On 2016-11-28 09:33 AM, Lou Burnard wrote: >> About a year ago, Martin H did a Community Consultation thing >> about >> whether or not we should continue to distribute debian packaged >> versions >> of at least some parts of the TEI product line. >> >> The response was yes we should. (I simplify). But I can't find any >> evidence of what happened thereafter. Step 15 of TCW22 suggests we >> are >> probably still building packages as part of the release but I >> don't >> believe they are necessarily getting put anywhere people can >> get at >> them. >> >> (Step 15 reads "Inform the Debian Package Maintainer of the new >> release >> Note: This step may change as we review Debian Package >> Creation The >> Debian repository can only be updated by its maintainers, so >> let the >> Debian Package Maintainer know that your release is done, so they >> can >> grab the new packages and add them to the repository. ") >> >> I don't know who the DPM is, nor what state we are in as regards >> reviewing DPC. >> >> So who is the DPM? The notes at http://tei.oucs.ox.ac.uk/teideb/ >> though >> very precise and helpful surely need some updating. >> >>