| Time |
Nick |
Message |
| 00:07 |
|
zerick joined #evergreen |
| 00:29 |
|
artunit joined #evergreen |
| 00:45 |
|
atlas__ joined #evergreen |
| 01:13 |
|
ldwhalen joined #evergreen |
| 01:14 |
|
shadowspar joined #evergreen |
| 01:25 |
|
bwicksall joined #evergreen |
| 03:25 |
|
ldwhalen joined #evergreen |
| 03:51 |
|
atlas__ joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:47 |
csharp |
@later tell jeff yeah - it was to update openssl, etc. |
| 07:47 |
pinesol_green |
csharp: The operation succeeded. |
| 08:06 |
|
kmlussier joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:49 |
|
kbeswick joined #evergreen |
| 08:51 |
|
tspindler joined #evergreen |
| 08:54 |
|
Shae joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 08:59 |
|
timlaptop joined #evergreen |
| 09:00 |
|
ericar joined #evergreen |
| 09:05 |
|
mrpeters joined #evergreen |
| 09:08 |
|
rjackson-isl joined #evergreen |
| 09:08 |
csharp |
hmm http://tech.slashdot.org/story/14/04/09/2047205/yahoo-dmarc-implementation-breaks-most-mailing-lists |
| 09:09 |
csharp |
that may be something for us to be aware of^^ |
| 09:09 |
csharp |
@who still uses Yahoo!? |
| 09:09 |
pinesol_green |
Callender still uses Yahoo. |
| 09:16 |
bshum |
Silly question maybe, but how would we inform yahoo users of breakage if the lists may already be borked in reaching them? |
| 09:18 |
|
dluch joined #evergreen |
| 09:19 |
csharp |
not a silly question - that occurred to me too |
| 09:20 |
csharp |
I guess we could identify users on the lists with yahoo.com addresses and BCC them all a message |
| 09:20 |
|
lcathenry joined #evergreen |
| 09:23 |
jeff |
csharp: there shouldn't have been an openssl update on lupin... weird. |
| 09:24 |
jboyer-isl |
openssl and libssl are different packages. libssl is the Big Deal at the moment. |
| 09:25 |
|
geoffsams joined #evergreen |
| 09:27 |
csharp |
jeff: yeah - it was there |
| 09:27 |
csharp |
I haven't rebooted or manually restarted any services, though - don't know if that's required after the update |
| 09:29 |
bshum |
I wouldn't have expected lupin to be affected as a squeeze box. |
| 09:29 |
jboyer-isl |
csharp: apache is the most important one to restart if you haven't. |
| 09:29 |
* jeff |
looks |
| 09:29 |
bshum |
Maybe they were unrelated updates. |
| 09:29 |
|
RoganH joined #evergreen |
| 09:30 |
bshum |
Also I don't think we employ SSL on lupin for apache stuff. |
| 09:31 |
bshum |
dbwells: Maybe there's a typo in eeevil's patches. I didn't get to dig too deep on them. |
| 09:34 |
jeff |
jboyer-isl: correct in that libssl is the most important component of the update, but since both openssl and libssl are part of the same source package, i was calling it all "openssl". sorry, almost as confusing as having a package named libssl1.0.0 which is version 1.0.1-mumble. :-) |
| 09:35 |
jeff |
csharp: i'm showing no signs of any openssl update on lupin. you sure it wasn't another box, or openssh and not openssl? |
| 09:35 |
jeff |
(sorry, i should just drop it -- nevermind! :-) |
| 09:35 |
jeff |
my brain sees "weird" and latches on. :P |
| 09:37 |
jboyer-isl |
jeff: I only point it out because I think it's possible that there could be an update to openssl but not libssl. (update to a tool but not the library, etc.) I saw one of the distro sites put up a big UPDATE: DO THIS INSTEAD kind of notice because they didn't specify the proper package. |
| 09:37 |
|
yboston joined #evergreen |
| 09:40 |
jeff |
which distro site, out of curiosity? |
| 09:42 |
csharp |
jeff: sorry - looking at dpkg.log and it appears I read "openssh" as "openssl" |
| 09:45 |
jeff |
csharp++ mischief managed! |
| 09:54 |
jboyer-isl |
jeff: my memory appears to have failed me. I know I saw it somewhere, but it's possible it was on a forum or something not quite official. (I'd imagine the official advice is always "update everything unless you have a good reason not to") |
| 09:55 |
csharp |
gmcharlt: following up on my testing the 14.04 install scripts for OpenSRF/Evergreen... you probably saw that I stalled on libdbi location issues - I haven't had a chance to get back to it, FYI |
| 09:55 |
|
denishpatel joined #evergreen |
| 09:56 |
* csharp |
is busy today and tomorrow putting in hardware orders, troubleshooting something that has broken multiple PINES reports templates, and other paperwork-y things |
| 10:04 |
|
atlas__ joined #evergreen |
| 10:07 |
|
kmlussier joined #evergreen |
| 10:13 |
|
jwoodard joined #evergreen |
| 10:14 |
|
kbutler joined #evergreen |
| 10:22 |
|
Dyrcona1 joined #evergreen |
| 10:23 |
gmcharlt |
csharp++ # thanks for the update |
| 10:27 |
|
RoganH joined #evergreen |
| 10:36 |
|
CleverNameHere joined #evergreen |
| 10:50 |
CleverNameHere |
So after changing the opensrf.xml file to give the reporter a valid email address to send when a report is run, it still gives me the wrong address. Does evergreen itself need to be restarted and not just the reporter or have I missed something else? |
| 10:51 |
csharp |
CleverNameHere: yes, you need to restart opensrf |
| 10:51 |
eeevil |
or opensrf.settings, in the least |
| 10:52 |
|
kmlussier joined #evergreen |
| 11:04 |
dbs |
berick: your accessibility expertise would be of value in bug 1305958 |
| 11:05 |
pinesol_green |
Launchpad bug 1305958 in Evergreen "Copy table header is wrong - and questionable practice" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1305958 |
| 11:05 |
|
kayals_ joined #evergreen |
| 11:09 |
|
lisek joined #evergreen |
| 11:17 |
CleverNameHere |
can you restart just .settings or just .reporter? they aren't in the list if you run osrf_ctl.sh -h |
| 11:19 |
CleverNameHere |
or would those all be covered under start stop and restart osrf? |
| 11:27 |
* dbs |
suspects mailing lists automatically prepend "tl;dr" to his posts |
| 11:29 |
kmlussier |
@marc 240 |
| 11:29 |
pinesol_green |
kmlussier: The uniform title for an item when the bibliographic description is entered under a main entry field that contains a personal (field 100), corporate (110), or meeting (111) name. [a,d,f,g,h,k,l,m,n,o,p,r,s,6,8] |
| 11:40 |
dkyle |
In 2.6, anyone else see marc expert search queries take way too long, resulting in nothing found? |
| 11:41 |
yboston |
Dyrcona: I loaded up your RDA changes to my EG 2.5.x test server. Waiting for cataloger feedback |
| 11:42 |
Dyrcona |
yboston: OK. |
| 11:42 |
* dbs |
adds "Add schema.org to RDA branch" to his actual to-do list, not just his mental overload list |
| 11:45 |
gmcharlt |
heads up -- I will be running apt-get upgrade on the Git server shortly |
| 11:46 |
kmlussier |
dkyle: I've always found that expert search take way too long. |
| 11:46 |
|
atlas__ joined #evergreen |
| 11:48 |
dkyle |
kmlussier: but do you get results? I'm always getting no entries found because the query takes forever. |
| 11:49 |
kmlussier |
dkyle: I'm trying one now. However, I don't think it has been unusual for me in the past to get no results on the first try, but I ultimately was able to get results. |
| 11:49 |
gmcharlt |
update of git server complete |
| 11:53 |
bshum |
dkyle: kmlussier: there are bug tickets for that. About slow and not retrieving expert search. |
| 11:53 |
kmlussier |
Bleh. I just tried MARC expert searches on two 2.4 catalogs and one 2.5ish catalog. I got no results in any of them. The 2.4 catalogs gave me internal server errors. The 2.5ish one didn't retrieve any results. |
| 11:53 |
kmlussier |
Overall, I would say MARC expert search needs some love if it's continued. I seem to recall some other issues with it too. |
| 11:54 |
bshum |
I would look them up but I'm on site at a library. Playing with RFID sorter machine! |
| 11:54 |
bshum |
:P |
| 11:54 |
dkyle |
kmlussier: sounds different, I never get results in the browser. query times are crazy long |
| 11:55 |
kmlussier |
dkyle: I think it's probably similar to what I saw in the 2.5ish catalog I was using. |
| 11:55 |
dkyle |
bshum: really? I looked right before asking here... not very well I guess |
| 11:55 |
kmlussier |
I don't see it either. I see some other MARC expert search bugs. |
| 11:59 |
kmlussier |
dkyle: Are you including a subfield when you do your MARC expert search? |
| 11:59 |
dkyle |
kmlussier: I am. |
| 12:01 |
pastebot |
"dkyle" at 64.57.241.14 pasted "long running query from marc expert search" (37 lines) at http://paste.evergreen-ils.org/55 |
| 12:02 |
bshum |
rec_descriptor, bleh |
| 12:02 |
dbs |
More MVF/CRA refactoring to be done? |
| 12:03 |
bshum |
Sounds like it. |
| 12:03 |
dbs |
@google when will it stop? |
| 12:03 |
pinesol_green |
dbs: What do you mean? An African or European swallow? |
| 12:06 |
kmlussier |
@coin |
| 12:06 |
pinesol_green |
kmlussier: tails |
| 12:08 |
dkyle |
so maybe its not just our db then. i'm still not finding an existing bug on this.. |
| 12:09 |
kmlussier |
dkyle: No, I don't think there is an existing bug, especially if it was caused by MVF/CRA. I would recommend filing one. |
| 12:10 |
yboston |
Dyrcona: early feedback is good on the RDA change. They mentioned they were going to look at how the publisher info looks on the search results page, but your code did not touch that part anyway. |
| 12:11 |
kmlussier |
yboston: Would you be able to put your intern's AsciiDoc into the working repository so that more eyes could look at it? |
| 12:12 |
kmlussier |
yboston: Or if you wanted to send me what you have, I would be happy to take some time to put it into the working repo. |
| 12:12 |
yboston |
I have a shared dropbox folder |
| 12:12 |
yboston |
that I can share with you, need an email address frfom you |
| 12:12 |
kmlussier |
OK, I'll send it in a pm. |
| 12:13 |
dkyle |
kmlussier: hmm the inner workings of mvf/cra are beyond me at this point. I can file. |
| 12:14 |
yboston |
quick question about the "mvf/cra" features, will they allow me to filter results so I only get ebooks or streaming audio records? |
| 12:15 |
kmlussier |
yboston: Yes. |
| 12:15 |
kmlussier |
You actually can do that now with search filter groups. But with MVF, we configured many of those filters to be the default on the basic search screen. |
| 12:15 |
yboston |
kmlussier: gracias, that is what I thought, but forgot to ask anyone at the conference |
| 12:16 |
dbwells |
dkyle: If you're up for trying something, please see if this view def helps your query times at all: http://pastebin.com/zPLXgF07 |
| 12:16 |
yboston |
kmlussier: did not know I could do that already, not familiar with "search filter groups" |
| 12:16 |
eeevil |
CleverNameHere: sorry, ran off to a meeting. a full opensrf restart will work fine. you can restart just one service, but I don't remember the commandline switches OTTOMH |
| 12:16 |
dkyle |
dbwells: thanks. will give it a try |
| 12:20 |
eeevil |
bshum: I think we can kill metabib.rec_descriptor entirely in that case. but a full rewrite is in order, really. related: pg 9.4's jsonb and json_hash_ops may give us the chance to kill metabib.full_rec FOR EVAR ... down the road |
| 12:20 |
CleverNameHere |
eeevil: Thanks for the knowledge. I'll wait till the end of the day when no one is using evergreen to restart things. |
| 12:21 |
bshum |
Mmm, the idea of PG 9.4 makes my spirits soar! |
| 12:21 |
dbwells |
Makes my spirits sore ;) |
| 12:22 |
eeevil |
bshum: and fts is getting much faster for common cases |
| 12:23 |
|
fparks joined #evergreen |
| 12:26 |
* dbs |
pours another shot of GIN |
| 12:28 |
jeff |
eeevil: when you say "common cases" are you including common cases in evergreen, or is all of evergreen fts usage outside the scope of what you/postgres would call "common cases"? :-) |
| 12:30 |
dkyle |
dbwells: no meaningful difference 527175ms to 522228ms |
| 12:31 |
dbwells |
dkyle: ok, thanks. Not unexpected, but was worth a shot |
| 12:31 |
dkyle |
dbwells: thanks for taking the shot |
| 12:32 |
eeevil |
jeff: including evergreen cases. short strings, rare+common query types |
| 12:32 |
jeff |
eeevil: sounds good! :-) |
| 12:32 |
eeevil |
and GIN is getting better generally |
| 12:33 |
eeevil |
and trigram indexing improvements over the 9.3 improvements (which we don't use right now, but HELLO SIMILARITY RELEVANCE BUMPS!) |
| 12:37 |
eeevil |
dbwells: SERIALS! (just something we found here trying to create a pattern) ... so, the pattern code does not recognize pwXXmo in $y (that's XX=week-of-year, on monday). dunno if we care, or if we should, but wanted to alert the current HolderOfSerialsPatternsKnowledge ;) |
| 12:45 |
eeevil |
bshum / dkyle: back to expert search for a sec, in the tpac there's no way to apply filters that require metabib.rec_descriptor, so I can get rid of that where it's not used (query-by-query). branch forthcoming |
| 12:46 |
|
mllewellyn joined #evergreen |
| 12:50 |
dkyle |
eeevil++ so i should hold off on another bug report? |
| 12:50 |
eeevil |
dkyle: no, go ahead and I'll use your bug number |
| 12:52 |
* dbwells |
kinda wishes he had a big, broken DB to play with |
| 12:52 |
|
jihpringle joined #evergreen |
| 12:53 |
dbs |
dbwells: don't we all? |
| 12:54 |
dbwells |
:) |
| 12:56 |
eeevil |
the other uses of mrd in metabib.pm are at the end of dead code paths, so I'm going to leave them alone |
| 12:58 |
dkyle |
dbwells: would you like dump file? :) |
| 13:02 |
csharp |
dbwells: come on down to Georgia! we sell 'em by the dozen ;-) |
| 13:09 |
eeevil |
see: 1306133 |
| 13:10 |
eeevil |
bug 1306133 |
| 13:10 |
pinesol_green |
Launchpad bug 1306133 in Evergreen "marc expert search long running queries" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1306133 |
| 13:10 |
|
kbeswick_ joined #evergreen |
| 13:10 |
eeevil |
there we go |
| 13:13 |
|
rfrasur joined #evergreen |
| 13:15 |
gmcharlt |
I've just discovered an annoying little dependency glitch |
| 13:15 |
|
hbrennan joined #evergreen |
| 13:17 |
gmcharlt |
Business::Stripe has POD test cases that are broken, so if Test::Pod is installed (which it would be on Debian and Ubuntu if you follow the OpenSRF install instructions), cpan Business::Stripe fails |
| 13:18 |
gmcharlt |
so I think that for the moment Business:Stripe will need to be moved to CPAN_MODULES_FORCE |
| 13:18 |
eeevil |
gmcharlt: do we have a "force" list? |
| 13:18 |
gmcharlt |
just curious whether anybody else had run into this |
| 13:18 |
eeevil |
heh ... so, yeah |
| 13:18 |
gmcharlt |
gmcharlt: yes |
| 13:18 |
berick |
heh, just hit that myself |
| 13:18 |
gmcharlt |
er, eeevil: yes |
| 13:19 |
gmcharlt |
OK, I'll work up a bug report and patch now |
| 13:23 |
csharp |
okay, for those following at home/who care, I can confirm that the INNER join patch in 80e3f6f has no bearing on our borked reports templates issue |
| 13:23 |
pinesol_green |
[evergreen|Mike Rylander] Correctly mark nested INNER joins as such - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=80e3f6f> |
| 13:23 |
* csharp |
runs off to inspect the IDL |
| 13:25 |
|
tonyb_ohionet joined #evergreen |
| 13:25 |
tonyb_ohionet |
hello anyone here? |
| 13:25 |
rfrasur |
lol, yes |
| 13:26 |
dkyle |
eeevil++ that did the trick |
| 13:26 |
tonyb_ohionet |
Thanks rfrasur! Just making sure everything works before DIG |
| 13:27 |
rfrasur |
tonyb_ohionet++ |
| 13:27 |
|
CarrieC joined #evergreen |
| 13:29 |
tonyb_ohionet |
Does anyone use Vandelay that might be online now? |
| 13:29 |
eeevil |
dkyle: great! |
| 13:30 |
csharp |
tonyb_ohionet: go ahead and ask your question and people will answer as they can ;-) |
| 13:31 |
tonyb_ohionet |
OK...this is going to sound crazy....but not being a cataloger :) |
| 13:31 |
tonyb_ohionet |
When using the Match Set Editor, let's say I wanted to overlay on the 001 control field.... |
| 13:31 |
tonyb_ohionet |
There's really no subfield for that...but Vandelay won't let me create a Match Set without it.... |
| 13:32 |
tonyb_ohionet |
"...and the subfield must be one non-whitespace, non-control character." |
| 13:32 |
tonyb_ohionet |
Am reading documentation now, but see nothing to explain a case like this.... |
| 13:32 |
berick |
@isitdown bugs.launchpad.net |
| 13:32 |
pinesol_green |
berick: What do you mean? An African or European swallow? |
| 13:33 |
csharp |
that would be a handy plugin to load ;-) |
| 13:33 |
bshum |
tonyb_ohionet: I think mllewellyn did some custom index for 001 in our system. For OCLC tag matching because we don't change it to Evergreen IDs. |
| 13:33 |
bshum |
She may know more. |
| 13:35 |
tonyb_ohionet |
Thanks everyone...but not sure I understand the responses... |
| 13:35 |
tonyb_ohionet |
???? |
| 13:35 |
tonyb_ohionet |
I could report it as a bug, but it's not really....wishlist then? |
| 13:35 |
|
rsoulliere joined #evergreen |
| 13:37 |
remingtron |
tonyb_ohionet: don't mind berick and csharp, they were talking about something else. |
| 13:37 |
tonyb_ohionet |
aha...got it...thanks! :) |
| 13:38 |
tonyb_ohionet |
bshum...who is mllewellyn? |
| 13:38 |
tonyb_ohionet |
Is asking that allowed? |
| 13:38 |
bshum |
She's one of my coworkers. |
| 13:38 |
tonyb_ohionet |
If not, I can email you... |
| 13:38 |
bshum |
Probably not watching her screen at the moment. |
| 13:39 |
bshum |
IRC isn't always up for everyone. And I'm offsite at the moment. |
| 13:39 |
bshum |
I'd suggest writing your question to the list. |
| 13:40 |
bshum |
If we have something to contribute, I'll make sure mllewellyn sees it. |
| 13:42 |
tonyb_ohionet |
will do...thanks! |
| 13:43 |
bshum |
If it's on the list, maybe others can chime in too. |
| 13:50 |
remingtron |
FYI everyone, there's a DIG meeting in 10 mins. |
| 13:51 |
remingtron |
(Documentation Interest Group, for any casual observers) |
| 13:51 |
rfrasur |
remingtron++ |
| 13:52 |
berick |
yay, my first jessie install |
| 13:52 |
|
kmlussier joined #evergreen |
| 13:53 |
kmlussier |
Phew! Made it back in time for the DIG meeting. |
| 13:54 |
rfrasur |
wb :) |
| 13:54 |
gmcharlt |
berick: bug 1306176 |
| 13:54 |
pinesol_green |
Launchpad bug 1306176 in Evergreen "Business::Stripe can fail to be installed" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1306176 |
| 13:54 |
berick |
gmcharlt++ |
| 13:55 |
gmcharlt |
https://bugs.launchpad.net/evergreen/+bug/1306176/comments/1 == ask me how I know this thing |
| 13:55 |
pinesol_green |
Launchpad bug 1306176 in Evergreen "Business::Stripe can fail to be installed" (affected: 1, heat: 6) [Undecided,New] |
| 13:55 |
berick |
heh |
| 13:55 |
* berick |
can picture the scene |
| 13:59 |
|
terranm joined #evergreen |
| 13:59 |
eeevil |
dkyle: would you mind signing off on my branch attached to https://bugs.launchpad.net/evergreen/+bug/1306133 ? then we can get it into 2.6.0 |
| 13:59 |
pinesol_green |
Launchpad bug 1306133 in Evergreen "marc expert search long running queries" (affected: 1, heat: 6) [Undecided,New] |
| 13:59 |
eeevil |
assuming dbwells is agreeable to that |
| 14:00 |
yboston |
#startmeeting 2014-04-10 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 14:00 |
pinesol_green |
Meeting started Thu Apr 10 14:00:24 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:00 |
pinesol_green |
The meeting name has been set to '2014_04_10___dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
| 14:00 |
|
kbeswick joined #evergreen |
| 14:00 |
yboston |
#topic Introductions |
| 14:00 |
dbwells |
eeevil: dkyle: sounds fine to me |
| 14:00 |
yboston |
welcome everyone, please start introducing yourselves |
| 14:01 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 14:01 |
* rsoulliere |
is Robert Soulliere, Mohawk College |
| 14:01 |
* yboston |
is Yamil Suarez @ Berklee college of Music - DIG meeting facilitator |
| 14:02 |
jihpringle |
#info jihpringle is Jennifer Pringle, Sitka (BC Libraries Cooperative) |
| 14:02 |
yboston |
BTW, The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda |
| 14:02 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:02 |
akilsdonk |
#info akilsdonk is Angela Kilsdonk, Equinox Software |
| 14:02 |
rfrasur |
#info rfrasur is Ruth Frasur, Hagerstown Library, Evergreen Indiana |
| 14:02 |
kbutler |
#info kbutler is Kate Butler, Rodgers Library |
| 14:02 |
ericar |
#info ericar is Erica Rohlfs, Equinox Software |
| 14:02 |
terranm |
#info terranm is Terran McCanna, PINES |
| 14:03 |
CarrieC |
#info CarrieC is Carrie Curie, PALS |
| 14:03 |
dluch |
#info dluch is Debbie Luchenbill, MOBIUS |
| 14:03 |
kmlussier |
Wow! Nice turnout today. :) |
| 14:04 |
yboston |
lets wait anothre minute, before we start |
| 14:04 |
remingtron |
welcome everybody :) |
| 14:04 |
yboston |
Here is the agenda again: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda |
| 14:04 |
dbs |
#info denials is Dan Scott, Laurentian University |
| 14:04 |
dbs |
(mostly lurking) |
| 14:04 |
* rfrasur |
is mostly lurking as well. Sorry. |
| 14:05 |
yboston |
I think we can start, remingtron do you want to start off with your proposal? (BTW< do you know the meetbot syntax?) |
| 14:05 |
yboston |
(I can take care of it if you want) |
| 14:05 |
remingtron |
hmm, I can try |
| 14:05 |
yboston |
just type #topic _name_ |
| 14:06 |
yboston |
or tell me what topic name to sue |
| 14:06 |
yboston |
*use |
| 14:06 |
remingtron |
#topic Proposed goal: Document all new 2.6 features by July 1, and all new future version features by the time the version is released. |
| 14:06 |
kmlussier |
remingtron: http://evergreen-ils.org/dokuwiki/doku.php?id=community:using-meetbot is helpful. |
| 14:07 |
remingtron |
#info I mostly explain this on the agenda, so in summary, I think DIG should adopt a more formal workflow to ensure that all new features get documented by the time each new version is released. |
| 14:07 |
remingtron |
kmlussier++ #thanks for the link |
| 14:08 |
yboston |
I like the proposal |
| 14:08 |
kbutler |
I think a more formal workflow would be useful. |
| 14:08 |
kmlussier |
remingtron: +1 to 2.6 documentation by July 1. |
| 14:08 |
dluch |
I like it, too. |
| 14:09 |
jihpringle |
+1 |
| 14:09 |
kmlussier |
For future versions, I like the goal of getting the documentation done by release time and think we should work toward it. And if we continue to get this much participation in DIG, I think we can reach it. |
| 14:09 |
yboston |
kmlussier: I agree |
| 14:09 |
kmlussier |
But if we go back to 3 or 4 active participants, it's not as likely. |
| 14:10 |
yboston |
if we had 3 remingtron we would :) |
| 14:10 |
dluch |
And in relation to agenda item II.d., I suppose depending on how many active DIG participants we have, maybe there could be a group working on older feature updates, in addition to making sure the new versions are ready for release date. |
| 14:10 |
remingtron |
yboston: how kind :) |
| 14:10 |
kmlussier |
That's true. So, remingtron, can you clone yourself? |
| 14:10 |
remingtron |
hmm... |
| 14:10 |
remingtron |
@clone remingtron |
| 14:10 |
pinesol_green |
remingtron: Try restarting apache. |
| 14:10 |
remingtron |
nope, sorry |
| 14:11 |
yboston |
I have doen some work on older versiosn, I could keep a focus on that |
| 14:11 |
yboston |
while others focus on new features |
| 14:11 |
kmlussier |
I think remingtron's approach to focus on new features at alpha time makes a lot of sense. |
| 14:11 |
kbutler |
dluch: do you mean features not previously documented, or updating now out-of-date documentation for new versions? |
| 14:12 |
kmlussier |
Once the .0 release is out, there shouldn't be many new features to document, As long as we stick to the schedule. |
| 14:12 |
yboston |
kmlussier +1 |
| 14:12 |
jihpringle |
+1 |
| 14:12 |
dluch |
Hmm...both, I suppose, but I was especially thinking of features that exist already but haven't been documented |
| 14:12 |
yboston |
kbutler: I keep focusing on older features that need updates, I keep forgetting about features that have never been docuemtned |
| 14:13 |
yboston |
(need to remeber those too) |
| 14:13 |
tonyb_ohionet |
would be nice to have something like "...if you encounter this..." |
| 14:14 |
yboston |
tonyb_ohionet: do mean like a tip of what to do if you encounter errors? |
| 14:14 |
tonyb_ohionet |
Yes...that would be great...pointers for new users.... |
| 14:15 |
rfrasur |
I think there are definitely things that could be added, but it seems that documenting both new features and never documented features should be priority...at least in my mind. |
| 14:15 |
remingtron |
yeah, it can feel like DIG has a mountain of work to do, which is why I think focusing on the upcoming features first will help us gain traction and then work on the backlog of undocumented stuff as we can |
| 14:15 |
kmlussier |
Who here can commit to documenting 1-3 features a month? I can. |
| 14:15 |
jihpringle |
I can too |
| 14:15 |
remingtron |
I can |
| 14:15 |
tonyb_ohionet |
I can try...just still lost figuring out how to get started... |
| 14:15 |
tonyb_ohionet |
sorry guys.... |
| 14:15 |
kmlussier |
remingtron: I think the 1 to 3 features a month makes it feel more manageable too. You aren't looking at the entire mass of docs that need to be done; just focusing on your bit. |
| 14:15 |
yboston |
i can, now that the conferece is over :) |
| 14:15 |
rfrasur |
I can commit to documenting one...if someone tells me which one to do. |
| 14:15 |
dluch |
I can, with the caveat that I'm off for the entire month of May for surgery recovery. |
| 14:16 |
yboston |
also, Galen's Git tutorial helped me get better at Git |
| 14:16 |
kbutler |
I think the focus on new features are good, but it's also just as important to keep the existing documentation up to date. |
| 14:16 |
yboston |
(also the lynda.com Git tuttorial) |
| 14:16 |
rfrasur |
(and it's in my skill set...which is not particularly good at anything) |
| 14:16 |
rfrasur |
kbutler: that's true |
| 14:17 |
kmlussier |
tonyb_ohionet: What would help you get started? Identifying features to document? |
| 14:17 |
|
denishpatel joined #evergreen |
| 14:18 |
kmlussier |
The Update Expire Date button one should be a nice bitesize feature to document for somebody just getting started. |
| 14:18 |
tonyb_ohionet |
Well...yboston and I have been working on the basics...(he's awesome) |
| 14:18 |
kmlussier |
I concur. yboston is awesome! :) |
| 14:18 |
tonyb_ohionet |
and I have some 2.6 stuff bit size to try but we're still at 2.4 |
| 14:18 |
kbutler |
yboston++ |
| 14:18 |
* yboston |
blushes |
| 14:19 |
yboston |
ESI has a 2.5 server that can be used for updating docs |
| 14:19 |
yboston |
Eventually they can provide a 2.6 test server |
| 14:19 |
dkyle |
eeevil: will sign off... trying to figure out how, i haven't used git much lately |
| 14:19 |
jihpringle |
yboston: the Sitka 2.6beta server can still be used at the moment |
| 14:19 |
tonyb_ohionet |
gotcha...I could start with that then... |
| 14:19 |
akilsdonk |
yes, the ESI test server will be upgraded for 2.6 |
| 14:19 |
yboston |
akilsdonk: cool |
| 14:20 |
yboston |
so should those that can commit to the July 1st deadline add ourselves to one of the wiki pages, then we can start assigning stuff to ooursleves or each other? |
| 14:21 |
kmlussier |
Let's start with the 2.6 wiki page to make sure those features are done. |
| 14:21 |
yboston |
I can focus on old stuff with abother volunteer |
| 14:21 |
yboston |
*another |
| 14:21 |
dluch |
yboston: I can help you |
| 14:21 |
remingtron |
I think people should claim features to document by either adding their name next to the feature on the TODO page or emailing the DIG list (if they don't have a wiki account) |
| 14:21 |
yboston |
dluch: thanks |
| 14:22 |
remingtron |
here's the current TODO page: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs |
| 14:22 |
kbutler |
yboston, dluch: I can help too. Maybe one of us can be revising and one can be looking for missing stuff? |
| 14:22 |
yboston |
BTW, I can provide wiki accoutns for anyone that wants one |
| 14:22 |
rfrasur |
when is the 2.6 server going to be available? |
| 14:22 |
kmlussier |
I'm curious about documentation for WCAG compliance. Is that something that needs to be documenated or is it something that should just work? |
| 14:22 |
* rfrasur |
reads up to make sure she didn't miss it. |
| 14:22 |
remingtron |
sounds like we have a "Focus on older docs needs" team forming |
| 14:23 |
|
denishpatel joined #evergreen |
| 14:23 |
yboston |
so far I have dluch , kbutler , yboston for older stuff |
| 14:23 |
yboston |
which should be fine |
| 14:23 |
tonyb_ohionet |
yboston, I can still work on this: https://bugs.launchpad.net/evergreen/+bug/1294269 |
| 14:23 |
pinesol_green |
Launchpad bug 1294269 in Evergreen "Small documentation formatting bugs" (affected: 1, heat: 6) [Low,New] |
| 14:24 |
tonyb_ohionet |
and this: https://bugs.launchpad.net/evergreen/+bug/1294299 |
| 14:24 |
pinesol_green |
Launchpad bug 1294299 in Evergreen "Small documentation punctuation bugs" (affected: 1, heat: 6) [Undecided,New] |
| 14:24 |
yboston |
tonyb_ohionet: yes, continue with that, then maybe when you are done you can choose to switch to newer stuff, or do older stuff |
| 14:24 |
remingtron |
kmlussier: I'd say we should mention WCAG compliance somewhere, but I don't think it needs any configuration |
| 14:24 |
tonyb_ohionet |
OK.....thanks! |
| 14:25 |
akilsdonk |
kmlussier: for WCAG compliance, there is nothing to document for end users. I'm not sure if there is information about the code that might be helpful to include in the technical docs though. |
| 14:25 |
remingtron |
so before next meeting, all who are willing should assign themselves to a feature or two on the TODO list |
| 14:25 |
kmlussier |
It might be useful to add a sentence to the tpac documentation that it meets WCAG guidelines. One we have end-user tpac documentation, that is. |
| 14:26 |
yboston |
so for new features I see remingtron , kmlussier , and I think one mroe person that I am missing |
| 14:26 |
remingtron |
if you get stuck or find it's harder than you expected, just email the DIG list and ask for help |
| 14:26 |
* jl- |
Benjamin Wiens, Keystone Library Network -- sorry was in a meeting |
| 14:26 |
jihpringle |
jihpringle for new features |
| 14:26 |
jl- |
reading backlog |
| 14:26 |
rfrasur |
remingtron, are we only focusing on 2.6 ...or 2.5 needs as well? |
| 14:26 |
remingtron |
Welcome jl- ! |
| 14:26 |
yboston |
perhaps, we want to temporarily ignore old stuff and attack the 2.6 stuff to destroy our July first deadlien? |
| 14:26 |
kmlussier |
+1 |
| 14:26 |
remingtron |
yboston: yes, +1 |
| 14:26 |
kbutler |
+1 |
| 14:27 |
jihpringle |
+1 |
| 14:27 |
yboston |
jl-: welcome, here is the agenda http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda |
| 14:27 |
yboston |
jl-: we are talking about Remington's proposal |
| 14:28 |
remingtron |
sounds like we agree to the July 1 deadline for documenting all new 2.6 features |
| 14:28 |
yboston |
though tonyb_ohionet is already looking at some older stuff that will server to give him expereince, so perhaps he can continue that |
| 14:28 |
|
dreuther joined #evergreen |
| 14:28 |
yboston |
or not |
| 14:28 |
yboston |
remingtron: yes, I think we agree |
| 14:28 |
tonyb_ohionet |
I will be glad to help in anyway....I'll tackle the two bugs that yboston and I were working with... |
| 14:28 |
jl- |
yboston, remingtron thanks |
| 14:29 |
dbs |
kmlussier: +1 to a quick sentence about WCAG, that will help answer questions from sites evaluating Evergreen for compliance purposes |
| 14:29 |
* yboston |
needs to look up meetbot syntax |
| 14:29 |
kmlussier |
dbs: Good point. |
| 14:29 |
jeff |
yboston: http://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot for many of the basics |
| 14:29 |
yboston |
#agreed DIG will document all new 2.6 features by July 1, and all new future version features by the time the version is released. |
| 14:30 |
yboston |
sorry I meant in my own meetbot cheat sheet |
| 14:30 |
jeff |
ah :-) |
| 14:31 |
yboston |
#action DIG members will sign up for what features the will work on for July 1st on the DIG EG 2.6 to do page |
| 14:31 |
yboston |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs |
| 14:32 |
yboston |
jeff: gracias |
| 14:33 |
yboston |
should we set up some milestones for our next meeting or some time in the fututre? |
| 14:33 |
kbutler |
will someone (with git access) be collecting the docs? |
| 14:33 |
kmlussier |
remingtron++ #For helping us focus. |
| 14:33 |
yboston |
I would submit new docs to the mailing list |
| 14:33 |
yboston |
then one of us that has git access can then add them |
| 14:33 |
kmlussier |
kbutler: A number of us have git access and can put them in a working branch if you send them to the mailing list. |
| 14:34 |
yboston |
that is only my suggestion, other may think otherwise |
| 14:34 |
yboston |
*others |
| 14:34 |
kbutler |
That's fine. Just wanted to confirm. :) |
| 14:34 |
remingtron |
yboston: +1 |
| 14:34 |
yboston |
kbutler: no problem |
| 14:34 |
remingtron |
yboston: what kind of milestones did you have in mind? |
| 14:35 |
yboston |
I meant something like... |
| 14:35 |
yboston |
by next week DIG memebres should pick what new feature |
| 14:35 |
yboston |
they want to work on |
| 14:35 |
rfrasur |
I think that's a good idea. |
| 14:35 |
rfrasur |
+1 to picking a feature |
| 14:36 |
kbutler |
+1 |
| 14:36 |
remingtron |
+1, maybe with an email reminder in a few days |
| 14:36 |
remingtron |
and only pick as many as you can finish before next meeting (in 1 month) |
| 14:37 |
remingtron |
(so next meeting is also a milestone) |
| 14:38 |
tonyb_ohionet |
+1 to everyone thank you1 |
| 14:38 |
tonyb_ohionet |
you! |
| 14:38 |
yboston |
we can also try pairing up the first month, so two people collaborate to get a few features done after oen month |
| 14:38 |
yboston |
so we get used to the process |
| 14:38 |
yboston |
For example, at the conference I was looking at the "striped" payments feature with Alexey, and we did not know in what section to add the docuemntation. we wanted to reach out the the developer but ran out of time |
| 14:38 |
remingtron |
sounds great, I'm happy to help someone |
| 14:39 |
remingtron |
and asking the developers is a great idea too. they can explain more about their features. |
| 14:39 |
kmlussier |
I'm happy to pair up with someone too. |
| 14:40 |
remingtron |
who wants a DIG partner for this round of features? |
| 14:40 |
jl- |
I'm currently in the process of migrating 18 libraries (for test purposes) from voyager -> eg, so I'm hoping I can add something about migration or voyager specific migration at some point. migration seems to be rather undocumented (because ILS.* are unfortunately so different) |
| 14:40 |
yboston |
I always want to ask developers where they envisioned the documentation living, in case they had thought about it. it can be tricky deciding in a vacuum if it should be in admin settigns or in OPAC settings, etc |
| 14:40 |
yboston |
hence why I suggest teaming up for the first month |
| 14:41 |
dbs |
yboston: devs might not be the best people to ask about where docs should live; different mindsets |
| 14:41 |
remingtron |
yeah, broader structure of the docs is an ongoing question, but I'm happy to work on that |
| 14:41 |
yboston |
dbs: absolutely, but I would always like to ask them in case they had thought about it. if not that is fine |
| 14:42 |
dbs |
fair enough! just keep in mind what we/they think might be wrong :) |
| 14:42 |
yboston |
jl-: I had talk about having a multi ILS "rosetta stone" wiki pages for that type of thing |
| 14:42 |
remingtron |
jl-: yes, migration docs could be handy, take good notes! |
| 14:43 |
remingtron |
alright, should we keep moving in the agenda? |
| 14:43 |
kmlussier |
+1 |
| 14:43 |
yboston |
before we do do we want to agree to a simle milestone about signing up AND/or signing up in pairs the first month? |
| 14:43 |
kmlussier |
I need to leave in about 10 minutes. |
| 14:43 |
remingtron |
related reminder, anyone writing asciidoc should look at our style guide (and offer edits!) |
| 14:43 |
yboston |
kmlussier: OK |
| 14:43 |
remingtron |
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_style_guide |
| 14:44 |
rfrasur |
would it be easier to just sign up, and if you see only one person is on a feature, add yourself and contact them? |
| 14:45 |
yboston |
rfrasur: that sounds fine to me |
| 14:45 |
dluch |
yboston: Sorry, I'm confused. The milestone will be to sign up/team up in the first month or to sign up, team up, and then have that done in the first month? |
| 14:45 |
remingtron |
dluch: I think sign up in the next week, then have first assignments done in a month |
| 14:46 |
kmlussier |
Done by the next meeting. |
| 14:46 |
yboston |
I was leaving open ended for the group to decide |
| 14:46 |
rfrasur |
There don't honestly seem to be that many features needed for 2.6...unless I'm completely misunderstanding. |
| 14:46 |
kmlussier |
rfrasur: So that should make it that much easier to have all of them documented. :) |
| 14:46 |
jihpringle |
should we count 2.5 new features that haven't been documented as well? |
| 14:46 |
rfrasur |
okay...so I'm not misunderstanding? |
| 14:47 |
rfrasur |
kmlussier++ |
| 14:47 |
yboston |
this is a release with few features, which makes it perfect to tryt his approach out |
| 14:47 |
kbutler |
let's do 2.6 first and if we get done early, worry about 2.5? |
| 14:47 |
yboston |
kbutler: +1 |
| 14:47 |
remingtron |
rfrasur: more might appear, and some might be harder to document than expected |
| 14:47 |
rfrasur |
+1 to that |
| 14:47 |
kmlussier |
I would prefer to get the 2.6 ones done first before we tackle 2.5. To keep us focused and hit that deadline. |
| 14:47 |
rfrasur |
remingtron: that's my concern. Certain features require individuals with specific knowledge sets to work with them. |
| 14:47 |
yboston |
remingtron++ #some of those few ones could be doozies |
| 14:48 |
kmlussier |
FWIW, I haven't done my usual scan of the Change Log to see if there are any new features missing from the release notes. I know yboston was looking at it, but I don't know how far he got. |
| 14:48 |
yboston |
kmlussier: not far at all |
| 14:48 |
yboston |
but I started docuemnting your process at least |
| 14:48 |
remingtron |
kmlussier: I started with things already in RELEASE_NOTES_NEXT and have been scanning launchpad committed bugs for 2.6 |
| 14:48 |
rfrasur |
And I'm curious if it'd be a good idea to seek out those people that know how to use the features...or at least get started...and have them participate in the documentation, if they're willing, even if they don't traditionally participate in DIG |
| 14:48 |
kmlussier |
yboston: OK, then. I will commit to doing that within the next week too. Sorry, I was distracted for a few months, but I have time to focus on DIG again. |
| 14:49 |
yboston |
so it sounds we want to start with the 2.6 list as it is |
| 14:49 |
remingtron |
rfrasur: yes, users and developers are welcome in the conversation, good ideas |
| 14:49 |
yboston |
lets sign ourselves up for a few of them, while working in pairs |
| 14:50 |
remingtron |
kmlussier: you've had a lot on your plate! |
| 14:50 |
kmlussier |
That's one of the reasons why I threw out the "Update Expire Date" button as a possible option for someone new. It should be one that doesn't require specialized knowledge. |
| 14:50 |
yboston |
and shoot for completing in one month |
| 14:50 |
yboston |
kmlussier++ |
| 14:50 |
rfrasur |
My personal concern is that no matter how much I WANT to help, if I don't have any clue how to use a feature, I sure can't document it. |
| 14:50 |
kmlussier |
I've seen it, and once you click the button, you know what it does. |
| 14:50 |
remingtron |
and if anyone gets stuck, just email the list or ask on IRC for help |
| 14:50 |
yboston |
yes, and perhpas when kathy does her releaso notes review, we might end up with newer features |
| 14:51 |
kmlussier |
rfrasur: Also, if you can find the LP bug where the feature was originally posted, there often is a lot of information on how it works. |
| 14:51 |
remingtron |
kmlussier: good idea, let's add links to the TODO page as appropriate |
| 14:51 |
rfrasur |
kmlussier++ #yeah |
| 14:51 |
yboston |
btw, we are almost at the 1 hour mark. |
| 14:51 |
rfrasur |
remingtron++ #that'd be very helpful. |
| 14:52 |
dluch |
remingtron ++ |
| 14:52 |
yboston |
lets shoot to sign up for features by Esrly next week? I will pick one tht has someone already signed up |
| 14:53 |
rfrasur |
yboston: will you also send out an email reminder tomorrow or Monday? |
| 14:53 |
yboston |
BTW, we might want to ignore the ones with ESI lsited, since they might already have direct access tot he specs and the developers, so they might not need to pair up??? |
| 14:53 |
yboston |
I can send out the reminder |
| 14:53 |
rfrasur |
ty, and +1 on the ESI features. |
| 14:53 |
remingtron |
yboston: I agree, ESI does a fine job with their docs |
| 14:54 |
yboston |
#agreed If DIG finisshes all of the 2.6 todos, we will shift to the 2.5 missing features |
| 14:55 |
* kmlussier |
needs to run. |
| 14:55 |
kmlussier |
Bye all! |
| 14:55 |
yboston |
I also wanted to have a quick chat about release ntoes, but I will do that in the mialing list. |
| 14:55 |
remingtron |
kmlussier: bye, thanks! |
| 14:55 |
dluch |
kmlussier: bye! |
| 14:55 |
yboston |
any final comments or questions as we approach the 1 hour mark? |
| 14:55 |
remingtron |
yboston: one question |
| 14:55 |
remingtron |
will the "work on old stuff" team be working in the background, or also focusing on 2.6 first? |
| 14:55 |
yboston |
(btw, I can keep going longer) |
| 14:56 |
yboston |
I would want to try focusing on 2.6 just so that we all get experience |
| 14:56 |
yboston |
on DIG practices, AsciiDoc, etc |
| 14:56 |
remingtron |
sounds good to me |
| 14:56 |
yboston |
but we can choose to work in parallel |
| 14:57 |
|
shart290 joined #evergreen |
| 14:57 |
shart290 |
Good day everyone, I have a conundrum that I could use some input on. |
| 14:57 |
* rfrasur |
listens |
| 14:58 |
remingtron |
shart290: if you are willing to wait a moment, we are just finishing a meeting |
| 14:58 |
kbutler |
I think 2.6 first is fine with me. |
| 14:58 |
|
kbeswick joined #evergreen |
| 14:58 |
shart290 |
absolutely. thank you |
| 14:58 |
yboston |
shart290: give us a couple of minutes |
| 14:59 |
yboston |
so lets start signing up in pairs (or more) and lets tlak on the mailing list if you have questions, of just email me directly and I will point the way |
| 14:59 |
rfrasur |
+1 |
| 14:59 |
yboston |
including helping phrase questiosn for the develoeprs |
| 14:59 |
remingtron |
+1 |
| 14:59 |
dluch |
+1 |
| 14:59 |
remingtron |
yboston: and you will email the list about your Release Notes topic? |
| 14:59 |
yboston |
yes |
| 14:59 |
yboston |
jsut added it to my calendar |
| 15:00 |
yboston |
any final questiosn or comments? |
| 15:00 |
remingtron |
great, thanks |
| 15:01 |
yboston |
also, remeber, let me know if you need me to "sign" you up for features ont he wiki or ask me directly for wiki access |
| 15:01 |
yboston |
anything else? |
| 15:01 |
yboston |
next meeting should be (if we keep same schedule) May 1st |
| 15:01 |
yboston |
(and we can change schedule if we want) |
| 15:02 |
yboston |
OK, if there is nothing lese, I will stop the meeting |
| 15:03 |
yboston |
#endmeeting |
| 15:03 |
pinesol_green |
Meeting ended Thu Apr 10 15:03:05 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:03 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-10-14.00.html |
| 15:03 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-10-14.00.txt |
| 15:03 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-10-14.00.log.html |
| 15:03 |
remingtron |
yboston++ |
| 15:03 |
rfrasur |
yboston++ |
| 15:03 |
yboston |
remingtron++++++++ |
| 15:03 |
akilsdonk |
yboston++ |
| 15:03 |
kbutler |
yboston++ |
| 15:03 |
rfrasur |
remingtron++ |
| 15:03 |
ericar |
yboston++ remingtron++ |
| 15:03 |
dluch |
yboston++ |
| 15:03 |
shart290 |
As soon as you are ready, I believe I may be a tad in over my head on something and I do need to pick a few brains |
| 15:04 |
yboston |
shart290: go ahead |
| 15:04 |
jl- |
thanks everyone, hopefully I'll be of more use soon |
| 15:05 |
shart290 |
I am working on repairing a computer that was running evergreen ils on Debian squeeze |
| 15:06 |
yboston |
jl-: that work we did on Git and docuentation was great to help me cofirm I was doing the right workflows |
| 15:06 |
yboston |
jl-: thanks |
| 15:06 |
jl- |
yboston: my pleasure |
| 15:06 |
shart290 |
it suddenly dropped to login shell without a window manager, nothing I did other than upgrading the distribution got it anywhere. So ia m running Wheezy now but I am having problems getting openils and evergreen running again. |
| 15:07 |
shart290 |
presently there's a version issue with xulrunner, as the version that was being used was 1.9.1 and it's got 24.4 now? |
| 15:07 |
shart290 |
and apache2 is throwing errors with Perl lines in the conf files for the vhost. |
| 15:08 |
jeff |
shart290: first question -- was the machine in question running just the staff client, or was it running the server components of Evergreen as well? |
| 15:08 |
jeff |
ah, sounds like it was running server components as well. |
| 15:08 |
shart290 |
it was running everything. It was the server. |
| 15:09 |
jeff |
Was this a testing/development instance of Evergreen, or something that was being used in production for real work? |
| 15:09 |
|
Dyrcona1 joined #evergreen |
| 15:09 |
shart290 |
it was production, something happened to the machine a couple of months ago and nobody said anything til last week. I got in yesterday, never having laid a finger on it before. |
| 15:10 |
shart290 |
I am familiar and comfortable with Linux, but I have hit a dead end in my expertise |
| 15:11 |
jeff |
Do you know what version of Evergreen you're running? |
| 15:12 |
shart290 |
lemme check.. |
| 15:13 |
shart290 |
2.1.1 is what is on the machine presently |
| 15:13 |
jl- |
shart290: well, what errors are you getting ? |
| 15:13 |
jl- |
http://docs.evergreen-ils.org/2.3/_starting_evergreen.html |
| 15:13 |
jl- |
this should start it |
| 15:14 |
jl- |
wheezy works fine |
| 15:14 |
shart290 |
One of them, when running osrf_control is that there are processes running without PID files. |
| 15:15 |
shart290 |
let me try whats on that link really quick |
| 15:15 |
jeff |
jl-: if you've never had your hands on this before, one basic thing to know is this -- there are three major components of an evergreen install: the database server (postgresql), the OpenSRF services, and Apache. they'll need to be brought up in that order. |
| 15:15 |
jl- |
jeff: thanks, I've installed it a few times |
| 15:16 |
jeff |
as stated in that document, ejabberd and memcached are also important, but usually are already running and are pretty stateless and don't need manual restarting in Most Cases |
| 15:16 |
shart290 |
right, I gathered that much yesterday. |
| 15:16 |
jeff |
jl-: completely misdirected my message -- that was intended for shart290 -- sorry. :-) |
| 15:16 |
jl- |
=) |
| 15:16 |
|
CarrieC left #evergreen |
| 15:16 |
jl- |
shart290: try starting it as described in the documentation above |
| 15:17 |
shart290 |
I made sure to backup the postgresql database files yesterday in the event that i'd have to wipe the computer but aside from having problems with dependencies it's all the same system still. |
| 15:17 |
jeff |
shart290: as the root user, i'd stop apache, then as the opensrf user i'd start opensrf services as directed in the documentation above. watch CPU utilization using top/htop/similar, and once things have gotten quiet start apache. from there, logs with error messages would be helpful. |
| 15:18 |
jeff |
if you've upgraded the OS, you might need to re-install some dependencies or even re-compile OpenSRF and/or Evergreen. I'm not sure I've upgraded Debian out from under an existing Evergreen instance myself. |
| 15:18 |
jeff |
and yes, good to know that you have backups. :-) |
| 15:19 |
jeff |
probably wouldn't hurt to back up /etc/apache2 and /openils/conf or even all of /openils also. |
| 15:19 |
|
floadam joined #evergreen |
| 15:19 |
jeff |
shart290: so has this been down for weeks, or did it only go down when you started looking into a report of problems? |
| 15:20 |
shart290 |
it went down like 4 months ago, and since I am not the regular tech for this machine/library I wasnt able to get in and see why. it was running an xserver instance up until it went down. then it was all command line. again I don't know why. |
| 15:22 |
shart290 |
ok, so at autogen.sh it gives me an error that no bootstrap config exists |
| 15:23 |
shart290 |
http://pastebin.com/Syf18Lbz |
| 15:24 |
shart290 |
And the same error I got last time I tried restarting apache2 |
| 15:24 |
shart290 |
http://pastebin.com/Smvp66Rs |
| 15:27 |
shart290 |
which opensrf_core.xml returns no results |
| 15:28 |
shart290 |
is it possible to remove opensrf and evergreen without affecting the database? |
| 15:28 |
shart290 |
if so I may get most current for both, remove both and reinstall. |
| 15:31 |
rfrasur |
shart290: I'm not sure who all is at their desk right now, but you might ping eeevil or gmcharlt with that question...or csharp. |
| 15:31 |
* rfrasur |
pinged them...if they're around. |
| 15:31 |
shart290 |
ok, I think I know what might be going on. the reference to ${path} may be incorrect. |
| 15:32 |
shart290 |
the opensrf_core.xml appears to be in /opensrf/conf not in ${prefix}/etc/ |
| 15:38 |
shart290 |
I just need to figure out where that reference is set. |
| 15:42 |
csharp |
shart290: if you/whoever installed this followed the install instructions as written, those files should live in /openils/conf |
| 15:42 |
shart290 |
right, and it is there but the it appears as if it is being looked for elsewhere |
| 15:45 |
shart290 |
the other very confusing error is this one: |
| 15:45 |
shart290 |
apache2ctl stop |
| 15:45 |
shart290 |
Syntax error on line 17 of /etc/apache2/sites-enabled/eg.conf: |
| 15:45 |
shart290 |
Invalid command 'PerlRequire', perhaps misspelled or defined by a module not included in the server configuration |
| 15:45 |
csharp |
shart290: first off, 2.1.1 is EOL at this point, so if you can back up the database with pg_dump (sounds like you may have already done that) and reinstall via the instructions, then do a pg_restore after walking through the install instructions for a more recent version, then run through the upgrade scripts from 2.1.1 to 2.5.X (or 2.6.X)... |
| 15:45 |
csharp |
that's what I'd recommend rather than trying to fix the borked box as is |
| 15:45 |
shart290 |
yeah, I just didn |
| 15:45 |
shart290 |
didn't want to have to reinstall linux and everything. |
| 15:46 |
csharp |
shart290: maybe apache mod-perl isn't loaded? |
| 15:46 |
csharp |
(in which case, that points to multiple problems) |
| 15:46 |
|
alynn26 joined #evergreen |
| 15:47 |
shart290 |
I didn't even see it in the available modules folder. and it also didn't show up in synaptic package manager as an available package. |
| 15:47 |
csharp |
e.g., the installation instructions were not followed correctly and who knows *what* is on there |
| 15:47 |
shart290 |
exactly |
| 15:47 |
shart290 |
so I will have to dump the DB and start from the beginning. |
| 15:48 |
csharp |
shart290: that's what I'd do - maybe back up OS directories (/home, /root, /openils, maybe /var) |
| 15:48 |
csharp |
as well |
| 15:48 |
csharp |
oh, and /etc |
| 15:49 |
csharp |
shart290: how much RAM does that box have? |
| 15:50 |
shart290 |
I'm not sure, it |
| 15:50 |
shart290 |
it's running an i3 so maybe 2-4gb |
| 15:50 |
csharp |
'free -g' should tell you, or 'top' |
| 15:50 |
|
kbeswick joined #evergreen |
| 15:51 |
shart290 |
about 6gb |
| 15:51 |
csharp |
shart290: and this is meant to be the client *and* the server? |
| 15:51 |
shart290 |
it's a small library |
| 15:52 |
shart290 |
4-5 people using the card catalog and not all at the same time. |
| 15:52 |
csharp |
okay - then I would recommend running everything on something super light, like LXDE |
| 15:52 |
jeff |
if apache is throwing syntax errors about PerlRequire being an invalid command, you'll want to install libapache2-mod-perl2 at a minimum. |
| 15:53 |
jeff |
if you've upgraded the OS, you might consider running the Makefile.install pre-req installer for OpenSRF and Evergreen and supply the debian-wheezy argument. I've not run through that upgrade path myself, so again -- have backups first. |
| 15:53 |
shart290 |
right |
| 15:54 |
csharp |
yeah, Debian upgrades can bork Evergreen something fierce ;-) |
| 15:54 |
jeff |
And if you're considering backing up the database then re-installing OpenSRF and Evergreen, keep in mind that you'll want to install the exact same version of Evergreen, otherwise you'll need to upgrade the database as well. |
| 15:55 |
csharp |
yeah, I was thinking shart290 should restore on a newly installed EG machine and run through the DB upgrade scripts |
| 15:55 |
csharp |
if the DB is as small as I think it would be, that shouldn't take long |
| 15:56 |
|
mtcarlson joined #evergreen |
| 15:59 |
shart290 |
one sec, I'm going over what I've gotten so far. Thank you for your help so far also. |
| 15:59 |
shart290 |
csharp++ jeff++ jl-++ |
| 16:00 |
csharp |
shart290: good luck |
| 16:00 |
* csharp |
speeds away into the sunset |
| 16:03 |
berick |
bah, apache / libgdbm segfaults in jessie. /me saves that for another day |
| 16:04 |
|
atlas__ joined #evergreen |
| 16:21 |
|
kbeswick joined #evergreen |
| 16:40 |
|
tspindler left #evergreen |
| 17:03 |
jeff |
@who is The Data Analyst |
| 17:03 |
pinesol_green |
_bott_ is The Data Analyst. |
| 17:07 |
bshum |
"I do not think it means what you think it means." |
| 17:11 |
|
mmorgan left #evergreen |
| 17:18 |
gmcharlt |
FYI - https://bugs.launchpad.net/evergreen/+bug/1306258 |
| 17:18 |
pinesol_green |
Launchpad bug 1306258 in Evergreen "more seed data for MARC21 fixed field values would be nice" (affected: 1, heat: 6) [Undecided,New] |
| 17:20 |
pastebot |
"yboston" at 64.57.241.14 pasted "RDA 264 issue in search results- distributor data showing up and labeled publisher" (37 lines) at http://paste.evergreen-ils.org/56 |
| 17:21 |
|
dac joined #evergreen |
| 17:23 |
bshum |
yboston: And you're sure that bib doesn't have any other publisher information in it? Legacy 260 perhaps? |
| 17:23 |
bshum |
Because looking at the misc_util.tt2 for 2.5.1 (and master), I can definitely see that it checks for ind2="1" for given 264 lines |
| 17:24 |
bshum |
Which should eliminate that 264 you're seeing which has an ind2 of 2? |
| 17:24 |
yboston |
there is no 260 tag. I had also searched for the name of the distributor (culver city) and it only appears in the 264 |
| 17:25 |
bshum |
in Dyrcona's code, there doesn't seem to be any crossover between the new 264 variables he used and pubinfo which is what gets passed to the results display. |
| 17:25 |
yboston |
can you remind me of the file I should be looking at to see the TT2 code, besides misc_util? |
| 17:25 |
yboston |
(the one for search resutls) |
| 17:25 |
bshum |
Search results should be... parts/results/table.tt2 |
| 17:26 |
pinesol_green |
[evergreen|Mike Rylander] LP#1306133: Avoid metabib.rec_descriptor where possible - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e953ba1> |
| 17:26 |
yboston |
this might be the confusion, I don't mean that dyrcona's code cause this change, it is just a request for additional functionality |
| 17:26 |
bshum |
yboston: Well, it shouldn't display that 264 at all in the results |
| 17:27 |
bshum |
Even on an unmodified system |
| 17:27 |
yboston |
I need to pul up the file, but I don;t doubt you, but "culver city, etc" is showing up as "publisher" |
| 17:27 |
bshum |
That's why I'm concerned as to why the misc_util.tt2 seems to be lying to us |
| 17:27 |
yboston |
in the reults |
| 17:27 |
yboston |
*resutls |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
bshum |
Grr, finding a bib with actual holdings is such a chore sometimes |
| 17:31 |
* bshum |
is looking for a sample from my system |
| 17:32 |
bshum |
Interesting... |
| 17:32 |
bshum |
yboston: I think you've found yourself a bug |
| 17:33 |
|
Christineb joined #evergreen |
| 17:33 |
yboston |
bshum: OK, thanks for looking into it. I can submit it tomorrow |
| 17:33 |
bshum |
Yeah I'm able to replicate that on our production system |
| 17:33 |
bshum |
So somehow it's not paying attention to the ind2 flag |
| 17:34 |
pinesol_green |
[evergreen|Dan Scott] LP#1305958 Fix copy table header ID error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12319bb> |
| 17:34 |
yboston |
We are slowly putting more eyebles into RDA stuff so it makes sense |
| 17:34 |
yboston |
*eyeballs |
| 17:35 |
dbwells |
Well, we've been teetering on the edge of a 2.6.0 release for a while now. Anyone wishing to push us over, please do: https://launchpad.net/evergreen/+milestone/2.6.0 |
| 17:37 |
yboston |
bshum: also, movie bib records also tend to be slighly different than books, often they don't have 1xx fields and I guess in this case they have a distributor and not a publisher> |
| 17:37 |
yboston |
? |
| 17:37 |
dbwells |
I wish I could recreate the acq bug, so I could have a bit more confidence that we've solved it, but I just don't have a test server big enough right now. |
| 17:38 |
bshum |
yboston: I could see that. I'm trying to trace back where in the code this might have gone off the rails. |
| 17:38 |
bshum |
I have an idea. |
| 17:38 |
bshum |
dbwells: I wish we could have tested it more fully too. Other than the limited, "seems to work" that we quickly did |
| 17:38 |
dbwells |
The acq bug is the only true blocker, at the moment at least :) |
| 17:39 |
bshum |
dbwells: I have nothing new to add to it at this time though :\ |
| 17:40 |
yboston |
bshum: feel free to post the bug if you want, but if not I will do it tomorrow morining (need to finsish somehting else tonight) |
| 17:40 |
dbwells |
bshum: I certainly appreciate what you've been able to do. If you are confident my code at least doesn't break anything, it is there and ready for signoff. |
| 17:41 |
bshum |
yboston: I have to dig deeper, but I think it's something with the way that graphic_880 touches on tag 264 |
| 17:41 |
yboston |
bshum: interesting |
| 17:41 |
bshum |
Which I'd like to poke dbs to help take a look at more closely. |
| 17:42 |
bshum |
I'm not 100% sure on it because I have to keep looking through it |
| 17:43 |
bshum |
dbwells: Eh, good enough that I think we can push it along and see what happens next ;) |
| 17:43 |
dbwells |
bshum: Once that gets in, and provided nothing else suddenly pops up, I think I'd like to do the release with a "Known Issue" added to the release notes to explain that this problem might still exist, and how to get help if it does. |
| 17:45 |
dbwells |
bshum: I'll be out of the office tomorrow, but I expect to have time over the weekend to do release rolling if things settle down tomorrow. |
| 17:45 |
bshum |
dbwells: I'm pushing it momentarily once I find out what number is next |
| 17:45 |
bshum |
But cool, that'll give us a little more time to poke and see what else shakes loose. |
| 17:46 |
dbwells |
bshum: sweet, thanks again |
| 17:46 |
bshum |
Calling 0879 |
| 17:46 |
dbwells |
I'm out, have a good evening, all |
| 17:50 |
pinesol_green |
[evergreen|Dan Wells] LP#1304559 Fix slow Vandelay-based imports - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d42fbec> |
| 17:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1304559 - stamping upgrade script for vandelay_record_attr_to_flat - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1fa38c> |
| 18:02 |
|
jboyer-isl joined #evergreen |
| 18:05 |
bshum |
Huh |
| 18:05 |
bshum |
args.pubinfo = "$args.pubplace $args.publisher $args.pubdate"; |
| 18:05 |
bshum |
But then later on, it also sets |
| 18:05 |
bshum |
args.pubinfo = (args.pubinfos.size) ? args.pubinfos.0 : ''; |
| 18:06 |
bshum |
So wouldn't that mean that it'll replace pubinfo with the results from the graphic_880s hunt for tags 260 and 264 |
| 18:06 |
bshum |
Which is probably why it doesn't narrow it to only 264 with ind2=1 |
| 18:07 |
|
csharp joined #evergreen |
| 18:09 |
* bshum |
ponders this more. |
| 18:17 |
bshum |
Yep, I think that's the problem |
| 18:20 |
bshum |
Maybe we should just explicitly name all the different parts pubplace, publisher, pubdate in the results, same as we do for record. |
| 18:20 |
bshum |
And skip this combined pubinfo, and reserve that for the 880s dance |
| 18:21 |
|
Dyrcona joined #evergreen |
| 18:23 |
bshum |
At that point, if we desired, we could add Dyrcona's additional RDA 264 definition types as other things to be displayed in the more details instead of publisher, etc. but with the right designations. Distributor instead of publisher, and so forth. |
| 18:24 |
bshum |
Hmm |
| 18:25 |
|
Dyrcona joined #evergreen |
| 18:43 |
bshum |
And boo, dbs is right, there are no 264 samples in the test data. |
| 18:43 |
bshum |
Guess we really ought to make several to test all the variations out. |
| 18:45 |
bshum |
Maybe after dinner. |
| 18:45 |
bshum |
@monologue |
| 18:45 |
pinesol_green |
bshum: Your current monologue is at least 16 lines long. |
| 18:57 |
bshum |
Hmm, maybe an IF publisher, ELSIF distributor, and down the list of potential 264 types for results... |
| 19:24 |
|
csharp joined #evergreen |
| 20:27 |
|
mtj_ joined #evergreen |
| 21:19 |
dbs |
jsc-- # how is http://www.rdatoolkit.org/examples/MARC helpful? "The links below will download PDF files of RDA cataloging examples of authority records and and bibliographic records." |
| 21:20 |
* gmcharlt |
has no desire to write MARC::File::PDF |
| 21:20 |
gmcharlt |
;) |
| 21:21 |
dbs |
As helpful as MARC::File::DOCX would be for LoC's equivalent: http://www.loc.gov/catworkshop/RDA%20training%20materials/SCT%20RDA%20Records%20TG/index.html |
| 21:22 |
dbs |
To quote GOB: "COME ON!!!" |
| 21:22 |
dbs |
And there's http://www.loc.gov/catdir/cpso/RDAtest/rdatestrecords.html from 2011: "no attempt has been made to confirm that the records actually conform to RDA or that the MARC structure is valid" |
| 21:23 |
dbs |
It's like they don't _want_ software to actually implement RDA support. |
| 21:29 |
bshum |
:( |
| 21:29 |
gmcharlt |
backdoor way to encourage work on LD? |
| 21:30 |
* gmcharlt |
is a cynical optimist |
| 21:44 |
dbs |
gmcharlt: yeah, yeah, except the JSC people are responsible for RDA-as-LD and related BIBFRAME stuff that is _not_ encouraging |
| 21:45 |
dbs |
"Oh, we know it's impossible for humans to work with this directly like they would any other vocabulary; just use the RDA Toolkit(TM) for the low, low price of..." |
| 21:45 |
* dbs |
notes "We are publicly logged." Yes, yes we are. |
| 21:46 |
Guest40233 |
dbs++ |
| 22:18 |
|
mrpeters left #evergreen |
| 22:37 |
bshum |
Hmm |
| 22:48 |
dbs |
Uh oh. bshum is musing. |
| 22:48 |
bshum |
dbs: Oh no, I was just looking at the links you posted. |
| 22:50 |
bshum |
They are pretty terrible. |
| 22:51 |
* dbs |
thinks he knows somebody who has a fair bit of RDA experience (as in, training people) and is hoping they'll come through for us |
| 22:51 |
dbs |
But yeah, it shouldn't be this hard to get your hands on a canonical set of reference examples. |
| 22:52 |
* dbs |
goes away to soothe self with ice cream |
| 22:57 |
bshum |
dbs++ |
| 22:57 |
bshum |
@dessert dbs |
| 22:57 |
* pinesol_green |
grabs a scoop of Cookies and Cream and sends it sliding down the dessert bar to dbs |
| 22:57 |
bshum |
(now that was just lucky) |
