| # | Time | Nick | Message |
|---|
| # | 01:39:26 | pmplett_ has quit IRC |
| # | 01:39:59 | pmplett has joined #evergreen |
| # | 01:43:07 | pmplett has quit IRC |
| # | 01:44:06 | pmplett has joined #evergreen |
| # | 08:20:21 | pmplett has joined #evergreen |
| # | 10:10:33 | rsinger has quit IRC |
| # | 11:06:11 | jhaig has joined #evergreen |
| # | 11:10:27 | jhaig | Hi. I'm playing around with Evergreen to try it out (I was here asking about it a few weeks ago but I put it on the side and have just come back to it). I have found the Evergreen 1.6 documentation pdf (which I think must have been created since I last looked) and in the section on "Installation of Evergreen Staff Client Software" it mentions a pre-built binary for LInux. I remember seeing that there was no pre-built bi |
| # | 11:13:34 | phasefx | jhaig: part of your message was truncated, after "I remember seeing that there was no pre-built bi" |
| # | 11:14:13 | jhaig | Thanks. I thought the IRC servers dealt with that sort of thing. |
| # | 11:14:15 | jhaig | I remember seeing that there was no pre-built binary for Linux for 1.6 but now I see there is one for early testing for 2.0. Firstly, is this likely to work with a 1.6 server (I guess not)? Secondly, is there a pre-built binary for Linux for 1.6, or is this a mistake in the documentation? |
| # | 11:14:19 | jhaig | Thirdly, as I have not yet got to the stage of creating a live system, would it be more worth my while to use the 2.0 server, even though it is in alpha, instead of 1.6? Thanks |
| # | 11:15:35 | phasefx | there's not really a linux executable being offered on the downloads page, but a set of files you can point xulrunner or firefox at to run |
| # | 11:15:58 | phasefx | though the build system in trunk now has an option for building xulrunner+application bundles for linux |
| # | 11:16:47 | jhaig | I thought the pre-built binaries were just something for xulrunner to run. Or are the Windows and Mac versions stand-alone clients? |
| # | 11:18:42 | phasefx | the client "application" is just a bunch of javascript, xml, css, etc. spread through a certain directory structure. There's a file called application.ini at the root of all of this, that you can invoke like so: xulrunner application.ini or firefox -app application.ini The windows installer on the download site installs a windows version of xulrunner, application.ini and |
| # | 11:18:48 | phasefx | friends, and creates a shortcut for xulrunner application.ini |
| # | 11:19:31 | phasefx | the application.ini and related files also exists on any given Evergreen server, so if you need those files for a linux client, you can copy them from your server |
| # | 11:20:00 | phasefx | Open-ILS/xul/staff_client/build/ |
| # | 11:20:27 | phasefx | is this making sense? |
| # | 11:20:35 | jhaig | Yes it is. |
| # | 11:21:42 | phasefx | once the new build features in trunk get ported to the 2.x, we'll be offering more types of client bundles for download, since it'd be less work to put together than in the past |
| # | 11:22:14 | jhaig | I did find the application.ini when I first built it a couple of weeks ago and it worked OK, except that it seemed to make the window not quite big enough. I thought that this might be a problem due to me building the server on Debian and then running the client on Ubuntu, so I thought that getting a pre-built binary might work better. |
| # | 11:22:16 | phasefx | a firefox extension is also possible in trunk today |
| # | 11:23:14 | phasefx | there are differences between different xulrunner versions, and different xulrunner executables in different operating systems, though they're usually just cosmetic |
| # | 11:23:51 | phasefx | I don't like the linux xulrunner all that much since it doesn't draw borders around <groupbox> elements, and some other style issues |
| # | 11:24:19 | phasefx | ironically, wine+windows xulrunner on linux works well and looks nice :) |
| # | 11:24:29 | jhaig | I might try that. |
| # | 11:24:39 | jhaig | Is it possible to get the same functionality through the web interface? |
| # | 11:24:41 | phasefx | firefox as the executable is also worth trying |
| # | 11:25:23 | phasefx | a lot of the newer staff interfaces are written such that they could be used outside of the staff client and directly in a browser, but there's no comprehensive set of links or a launchpoint for that |
| # | 11:26:07 | phasefx | in the long run, it may be that we move completely to the web. There are librarians who want to go to either extreme |
| # | 11:27:02 | phasefx | in the short long term, the xulrunner client will probably move away from remotely-served xul and just be a fat self-updating local application |
| # | 11:27:21 | jeff | hopefully without relying on the xulrunner update mechanism. |
| # | 11:27:57 | phasefx | jeff: well, you could always manually install a newer version, is that what you mean? |
| # | 11:28:13 | eby was looking at http://www.amplesdk.com/ for a bit |
| # | 11:28:23 | jeff | as long as there is an option that doesn't involve the xulrunner auto-update mechanism, i think we'll be good. |
| # | 11:29:06 | jeff | eby: interesting. even uses XUL in some way. |
| # | 11:29:32 | eby | yeah it can interpret part of xul |
| # | 11:29:38 | phasefx | jeff: of course, the non-xul bits will still be served remotely (dojo interfaces) |
| # | 11:29:50 | jeff | phasefx: of course :) |
| # | 11:30:22 | phasefx | jeff: what's the concern with auto-update, is that something that gives grief with Firefox now? |
| # | 11:31:12 | phasefx | with what tsbere did, you have to explicitly create updates on the server for the client to want to update itself |
| # | 11:31:13 | jeff | phasefx: doesn't work for environments where the user doesn't have rights to update the application files, and can be unpredictable as to when updates actually happen. |
| # | 11:31:27 | phasefx nods |
| # | 11:32:25 | phasefx | jeff: something else I want to do (and atz would love), is have a version compatibility check happen through API |
| # | 11:33:03 | jeff | something more than the current "does the server have a directory named after my build stamp?" |
| # | 11:33:23 | phasefx | right, I haven't completely thought it through, but I keep having moments of insight that I later forget |
| # | 11:33:57 | jeff | as you think about it and write down your notes ;) -- a local version increment could be handy for some. |
| # | 11:34:05 | phasefx | if we do an all local-xul client we'll need a different mechanism |
| # | 11:34:15 | jeff | if you're ending up with a "you need a client update before you can use this server" |
| # | 11:35:07 | jeff | then a local increment on top of whatever evergreen version support matrix could be useful. |
| # | 11:35:46 | jhaig | Anyway, my last question, which I think got lost in the discussion on the staff client - I am currently at the stage of playing around with a freshly installed system before deploying a live system. Would it be more worthwhile for me to go straight to 2.0, even though it is in alpha, than trying out 1.6? |
| # | 11:35:56 | phasefx | may be as simple as maintaining a table with a text column, and if the "version/build/stamp string" submitted through the API can be found in that table, success |
| # | 11:37:54 | phasefx | jhaig: it may depend on what you're wanting to do with it, whether 2.0 has features you want, and how much churn you're willing to accept with bug fix updates, etc. |
| # | 11:38:17 | eby | and going live date |
| # | 11:41:11 | phasefx | jhaig: also, beta has been cut for 2.0, though I haven't packaged a client for it, and it's not advertised on the download site yet |
| # | 11:42:22 | jhaig | I know 2.0 is still in alpha, and I understand what that means for stability and updates. |
| # | 11:43:52 | phasefx | hey, that amplesdk, it just rendered (translated) some xul in Google Chrome for me :D |
| # | 11:44:12 | phasefx | <script type="application/ample+xml" |
| # | 11:44:21 | phasefx | xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> |
| # | 11:46:36 | phasefx | so like dojo, it's going to look for its own special script tags to do stuff with |
| # | 11:48:02 | phasefx | jhaig: well, soon to be in beta. It'd be worth it to "us" if you went with 2.0 just for the additional eyes on it, etc :) |
| # | 11:48:49 | jhaig | I'm going to have a go with the alpha 5 that is currently available. |
| # | 12:03:46 | gmcharlt has quit IRC |
| # | 12:03:46 | gmcharlt has joined #evergreen |
| # | 12:15:04 | dbs wondered whether the official documentation is referring to the VMs when they mention "pre-built binary", but http://docs.evergreen-ils.org/1.6/draft/html/staffclientinstallation.html is pretty clear it's staff client on "windows, mac, or linux" |
| # | 12:15:27 | dbs | docs need reviewers and testers just like the code does, i guess |
| # | 12:21:14 | jhaig | phasefx: Would this be the beta you are talking about? http://libmail.georgialibraries.org/pipermail/open-ils-general/2010-November/003613.html |
| # | 12:23:23 | phasefx | jhaig: yeap |
| # | 12:30:22 | dbs | no virtual machine available yet, I've been slacking (err, parenting) |
| # | 12:56:56 | jhaig | In the 2.0 beta, the makefile Open-ILS/src/extras/Makefile.install is missing the target install_pgsql_server_debs_83. Is this deliberate? According to the 1.6 documentation, this is what I need for Debian Lenny. |
| # | 12:58:50 | jhaig | Because as it stands, I don't think it can install postgres on Lenny - 8.4 isn't available. |
| # | 13:04:34 | phasefx | jhaig: I'm using deb http://www.backports.org/debian lenny-backports main contrib non-free for 8.4 on lenny |
| # | 13:26:32 | rsinger has joined #evergreen |
| # | 13:31:09 | jhaig | Is that the recommended route? I've just edited the makefile to allow me to install 8.3 |
| # | 13:38:18 | phasefx | I don't know if anyone should do that in production; it may just be time to discontinue using lenny |
| # | 14:46:22 | jeff | lenny is the current stable debian release. |
| # | 14:47:18 | phasefx | ah, is it? nevermind that then |
| # | 14:47:28 | jeff | of course, squeeze may be out by the time evergreen 2.0 is out of beta. i haven't followed, but i think squeeze is getting close. |
| # | 14:47:42 | phasefx forgot how slow debian is :) |
| # | 14:48:49 | jeff | memory and http://evergreen-ils.org/dokuwiki/doku.php?id=versioning indicate that eg 2.0 requires pg 8.4, so your options for evergreen 2.0 on lenny include: |
| # | 14:48:57 | jeff | 1) installing a backport of pg 8.4 |
| # | 14:49:31 | jeff | 2) installing from source with or without the assistance of that tool i can't remember that's suggested in the 1.6 install docs |
| # | 14:49:42 | phasefx | stow or something |
| # | 14:49:57 | jeff | 3) installing the database on its own non-lenny host :) |
| # | 14:50:02 | jeff | stow sounds right. |
| # | 14:50:26 | jeff | but knowing what the official recommendation of evergreen is for 2.0 on lenny (or not) would be good to nail down. |
| # | 14:51:17 | jeff | i don't think we have anything other than Makefile.install and maybe some release notes that states what distros are supported. |
| # | 14:51:31 | jeff | but now i'm just talking from memory and not bothering to look things up, so i'll stop :) |
| # | 15:18:39 | bshum has joined #evergreen |
| # | 15:32:08 | finnapz1 has joined #evergreen |
| # | 15:33:41 | finnapz has quit IRC |
| # | 15:34:28 | finnapz has joined #evergreen |
| # | 15:43:43 | bshum has quit IRC |
| # | 15:44:09 | bshum has joined #evergreen |
| # | 15:54:09 | dbs | squeeze or lucid for Evergreen 2.0; let us speak no more of lenny |
| # | 15:57:07 | dbs | rhel 5 and centos 5 too, I suppose, but I wouldn't go there personally. rhel 6 / centos 6, maybe, once somebody pulls together the prereqs, etc |
| # | 15:57:13 | bshum | dbs: I'm working through the beta install steps using the old alpha ones as a guide. Would it be helpful if I modified the instructions for that? |
| # | 15:58:11 | bshum | Actually should probably wait for staff clients, nvm my eagerness :) |
| # | 15:59:35 | dbs | http://lists.debian.org/debian-devel-announce/2010/10/msg00002.html suggests squeeze may make it by christmas |
| # | 15:59:57 | dbs | bshum: yeah, that's why I've held off on the wiki / downloads page |
| # | 16:02:28 | bshum | dbs: Upside didn't encounter any oddities so far with b1 installing over a4. Will give a fresh install a whirl sometime later. |
| # | 16:02:35 | dbs | fedora 13 / 14 for testing and development purposes, but would never recommend fedora for production; shelf life is too short (like non-LTS ubuntu releases) |
| # | 16:03:16 | dbs | bshum: cool, it would be surprising but not unprecedented if something bad did turn up :) |
| # | 16:08:12 | bshum | dbs: I've finished a draft of the meeting minutes along with the action items I could discern from the discussions. Please feel free to make corrections or add new things I missed: http://www.open-ils.org/dokuwiki/doku.php?id=dev:meetings:2010-11-16 |
| # | 16:09:03 | bshum | I'll send an email out tomorrow to start discussing the meeting time. Maybe we'll get more feedback this time, though I think 12 sounds better for west-coasters |
| # | 16:09:20 | bshum | In the meantime, time to kick the tires on b1. |
| # | 16:12:41 | dbs | bshum++ |
| # | 17:06:36 | jhaig | Sorry for disappearing for a bit. Reading back, I see that postgres 8.4 is required for Evergreen 2.0, so backports would be required. I noticed, however, that in the Makefile.install file there is a target 'install_pgsql_client_debs_83'. Surely this shouldn't be there. |
| # | 17:09:58 | jhaig | Also, before I go for the evening, I checked and centos 5 does have a postgres84 package available as well the postgres package, which is version 8.1. I may go for using centos, which is what I would have used but it seemed that Evergreen was very much geared towards Debian from what I read about version 1.6. |
| # | 17:10:44 | jhaig has quit IRC |
| # | 17:18:59 | bshum has quit IRC |
| # | 17:41:26 | dbs | @later tell jhaig there's no one I know who actively tests and develops Evergreen on centos / rhel, it's very much a second-class citizen |
| # | 17:41:26 | pinesol` | dbs: The operation succeeded. |
| # | 20:45:08 | mrpeters-isl_ has joined #evergreen |
| # | 20:46:02 | mrpeters-isl_ | hey all, not sure if anyone is around tonight but if so i'm curious about an efficent query i could run to take care of some biblio.record_entry records that arent linked to any call number records... |
| # | 20:46:26 | mrpeters-isl_ | UPDATE biblio.record_entry SET deleted='t' WHERE id NOT IN (SELECT record FROM asset.call_number WHERE deleted='f'); would probably eventually work but its terribly inefficent |
| # | 20:55:50 | mrpeters-isl_ has quit IRC |
| # | 20:57:04 | _dkyle_ has quit IRC |
| # | 20:59:12 | _dkyle_ has joined #evergreen |
| # | 21:08:40 | pmplett has quit IRC |
| # | 21:10:03 | pmplett has joined #evergreen |
| # | 21:19:45 | pmplett has quit IRC |
| # | 21:57:55 | pmplett has joined #evergreen |
| # | 22:00:00 | dbs | mrpeters-isl: create an index on asset.call_number on the deleted column |
| # | 22:00:41 | dbs | without that index, it has to sequentially scan every row of asset.call_number to figure out which call numbers are deleted |
| # | 22:03:14 | dbs | although... it'll probably seq scan the table anyway, unless you have a ton of deleted call nums |
| # | 23:15:05 | dbs | @later tell eeevil I think the Dojo shipped with beta1 might need some love, like "cd /openils/var/web/js/dojo/dijit/themes; ln -sf tundra/images images" to avoid 404s and other damage |
| # | 23:15:05 | pinesol` | dbs: The operation succeeded. |
| # | 23:17:21 | dbs | @later tell eeevil nuisance becomes a problem in the config -> global flags interface, for example |
| # | 23:17:21 | pinesol` | dbs: The operation succeeded. |
| # | 23:41:16 | dbs has quit IRC |
April 10-13