Hi Mark,
On Tue, Jun 20, 2017 at 9:11 AM, Mark Evenson evenson@panix.com wrote:
On 6/18/17 15:38, Erik Huelsmann wrote: […]
I've removed quite a few packages indeed (from the current production system, that is): all packages related to the X11 (server) have been removed. So have most LaTeX and LuaTeX packages. The idea behind this
step
is that the access provided by Common-Lisp.net is merely provided to support uploading and maintaining the static html pages -- my assumption
is
that that has little relationship to being able to start a desktop environment or graphics environment.
If you miss packages that you depend on, don't hesitate to speak up.
Please
explain what you need them for and I'll make them available again.
[…]
I appreciate the effort to get to Debian Stretch, but common-lisp.net also functions as a shell host
Indeed I have noticed some very-long running sessions on your account in the past. Looking at the page which lists services to our projects ( https://common-lisp.net/project-intro/), I think your use of the host is unsupported (as in: I can't find it as a listed service). We currently use shell sessions to run lisppaste and cliki, but I think that with the introduction of `systemd`, we can probably move those to be run as "user services" instead. Based on that, I was expecting the system not to have long-running shell sessions anymore.
and therefore needs more than uploading and maintaining the static html pages. To that end, I have reinstalled system-wide screen and gcc to continue with my use of the host.
Can I ask in what way the shell sessions you use need to be a generic service to support the common lisp community (and what role does GCC play in it)?
As for the 'screen' program specifically: it's my plan to replace it with tmux (which *is* installed).
In the future, we should probably have a explicit whitelist of who is
using what package. Is there somewhere that I can record the list of Debian packages on common-lisp.net that I am "actively" depending upon to prevent their removal in the future?
A question: do you intend to retain 'file://common-lisp.net/srv/' hierarchy, or will that be absorbed into the redoing of the 'https://gitlab.common-lisp.net/clo/server-config/' hierarchy.
The /srv hierarchy should remain as it is: it stores the data for the services that the host provides. The sever config you're pointing to (note: you've just published a URL for a project that's marked *private* for obvious reasons...) is only versioning the config of /etc. Some (most) config stored there is actually mostly there because it has been edited from the standard Debian config. In a number of cases, the Wheezy branch contains the edited version, but the Jessie and Stretch branches contain the Debian standard version, adding new configuration files ("the Debian way") to extend/enable/disable the standard Debian config.
It would be nice to update documentation on what systems we are using, and how. We have started to document things in the Trac wiki https://trac.common-lisp.net/clo/wiki/TitleIndex. Are we going to maintain this or migrate it to something else?
I wasn't aware of those pages (anymore?). However, given that there's one based on Debian 3.1(?!?), I think the pages need a serious overhaul ( https://trac.common-lisp.net/clo/wiki/InstalledPackages) Also, I think that specific page doesn't add much over the current listing of installed packages queried through Debian. If we want a page with installed packages, we probably want to map them to the services the host is supporting (if there's an explicit relationship). So that when upgrading, we can verify that those services are correctly installed again.
I don't feel an immediate need to move those pages elsewhere, although Trac's idea of generating a pre-seeded wiki with a lot of pages about its syntax isn't really resulting in a pleasantly structured wiki IMO. If we throw out the "standard" pages, I think we could extend it there. The clo/server-config project is private, so we'd be documenting for the current maintainers only. On the Trac wiki, it's all public (thus potentially documenting for our users as well), which I have no problem with, as long as the actual configuration isn't published.