Thanks for the quick response Martin! debian users will co 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.

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.

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.

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. > >

On 2016-11-30 06:11 PM, Hugh Cayless wrote:

That all sounds pretty reasonable. Loading the remote source is the default behavior of the Stylesheets, so unless the packaged version is configured differently, I'd expect it to do the same thing.

I've thunk about this, and it seems like a bug to me. If you install P5 packages on your machine, presumably you expect the Stylesheets to use them, don't you? My feeling would be that if you don't specify a source, it should look where the stuff should be (/usr/share/xml/tei/odd/p5subset.xml, presumably, since I think that's what it's looking for) and use that; only if that's not available should it go to the Web. The presumption would be that whatever version of the Stylesheets you have installed, you also want to use the matching version of P5, not whatever happens to be the current Vault version. The p5subsetDoctored.xml file was not in the deb package, because nobody thought of that, so we'll have to figure out how to make that happen. I'm not (yet) familiar with how deb building works -- it seems to be based on Make, but it's less than transparent on first examination -- but that should be doable. Unless anyone objects, I'll have a go at that when I have a chance. Cheers, Martin

Iirc tei-p5-database sounds like how we used to roll about a decade ago. :-)

Agreed on general procedure. It would be really nice if the release technician could take care of it, or, failing that, if at least a few of us could deal with it.

On Wed, Nov 30, 2016 at 8:02 PM, Martin Holmes mailto:mholmes@uvic.ca> 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/ 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 http://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... 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/ http://tei.oucs.ox.ac.uk/teideb/>

to this:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/ 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 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 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 http://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/ 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 http://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 http://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/ http://tei.oucs.ox.ac.uk/teideb/ though very precise and helpful surely need some updating.

-- tei-council mailing list tei-council@lists.tei-c.org mailto:tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Hi all, I've put a note on that page at http://tei.it.ox.ac.uk/teideb/ noting that the packages are significantly out of date and no longer maintained. I had thought that Stefan was looking at setting up a package repository. This is definitely something that they'd not want me to continue doing here. A bunch of the packages Sebastian had given up on packaging and didn't really update any more. (I think -teaching, -emacs, -database and potentially others fall into that category.) We (Council) did a spreadsheet analysing these all somewhere at some point, didn't we? I seem to recall that if we did provide them again that we'd only do the bare minimum. I'm convinced there are better things to do than maintain debian packages of this material. -James On 01/12/16 12:11, Lou Burnard wrote:

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. >>> >>> >

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

The frustrating thing is that we have been and still are happily building the deb packages (see https://github.com/TEIC/TEI/issues/1441) as part of our release process, but not actually signing them or putting them anywhere people can get at them! We could at least stick them in the github repo. On 28/11/16 19:10, Hugh Cayless wrote:

I agree with Lou that the lack of Debian support is a Bad Thing. It's not a new thing though. We haven't had any Debian support at all for a couple of years, have we?

What do we need in order to start doing this again, if we can't do it on tei-c.org? Should we rent a VM until we can fix tei-c? Nobody has been jumping up and down to become the maintainer, so I think if we're going to do this, it needs to be Council's responsibility, and we should set it up so that any release tech can do the package release as well. Is that feasible?

On Mon, Nov 28, 2016 at 1:59 PM, 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.

-- 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