| Time |
Nick |
Message |
| 00:19 |
|
Bmagic joined #evergreen |
| 01:40 |
|
dteston joined #evergreen |
| 02:16 |
|
jihpringle joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:45 |
|
collum joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:09 |
gmcharlt |
I've made a couple config changes to the wiki that may be of interest |
| 09:09 |
gmcharlt |
first, there is now a top-level archive: namespace that is hidden by default (e.g., won't display in search results or sitemaps) |
| 09:09 |
gmcharlt |
second, I've installed the move plugin, which allows single-page and tree moves |
| 09:10 |
gmcharlt |
the upshot is that if there's a page that should not be kept, but we don't want it to completely disappear (e.g., for historical reasons), you can go to it and rename it to put in in the archive: namespace |
| 09:12 |
jeff |
then it's searchable by advanced search option? |
| 09:12 |
tsbere |
gmcharlt: So that it can be forgotten until someone questions "why did we keep this?" years later? ;) |
| 09:12 |
jeff |
what is the practical effect of attempting to visit the former URL of the now-moved page? |
| 09:14 |
gmcharlt |
jeff: it no longer exists at the former URL, and doesn't redirect; however, the act of moving a page does update backlinks |
| 09:19 |
|
kmlussier joined #evergreen |
| 09:20 |
jeff |
is there any way short of manually crafting a url to search or navigate to a page that has been archived? |
| 09:21 |
gmcharlt |
jeff: working on that now |
| 09:22 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
kmlussier joined #evergreen |
| 09:30 |
kmlussier |
rhamby: Should bug 1545115 have a pullrequest? |
| 09:30 |
pinesol_green |
Launchpad bug 1545115 in Evergreen "config.circ_matrix_matchpoint and config.hold_matrix_matchpoint need a description field" [Wishlist,New] https://launchpad.net/bugs/1545115 |
| 09:30 |
kmlussier |
gmcharlt++ |
| 09:30 |
|
mmorgan1 joined #evergreen |
| 09:31 |
rhamby |
kmlussier: I vaguely remember doing that once I read it so ... sure |
| 09:31 |
kmlussier |
rhamby: OK, thanks! |
| 09:31 |
rhamby |
kmlussier: I wouldn't think anything between now and then in the staff client would have broken it so test away |
| 09:33 |
kmlussier |
rhamby: I'll give jsandberg a chance to test it first, but will keep it on my radar if she doesn't have a chance to test it. |
| 09:33 |
gmcharlt |
jeff: https://wiki.evergreen-ils.org/doku.php?id=archive:start |
| 09:33 |
Dyrcona |
I wanted that at one point recently. |
| 09:34 |
gmcharlt |
tsbere: and yeah, you're probably right, but I'm hoping it will encourage people to get rid of outdated content, as a provides a way to ensure that it's not *forever* |
| 09:39 |
jeff |
gmcharlt++ i like the intent, and probably best we can do given the tools/time at hand. |
| 09:40 |
jeff |
i don't see a way to search the archive namespace, but that might be buried deeper in dokuwiki docs. |
| 09:40 |
jeff |
and the pages in the archive will likely make their way into google search results, so there's that as an option. |
| 09:41 |
jeff |
and of course there's always a quick journey to the files-on-disk on request/need. |
| 09:51 |
|
jvwoolf joined #evergreen |
| 09:54 |
|
dteston joined #evergreen |
| 10:10 |
Dyrcona |
csharp++ # Fixing my busted tests. |
| 10:11 |
Dyrcona |
Should that be backported to 2.11? |
| 10:12 |
dbs |
gmcharlt++ |
| 10:12 |
|
yboston joined #evergreen |
| 10:20 |
|
Christineb joined #evergreen |
| 10:28 |
kmlussier |
csharp++ Dyrcona++ |
| 10:28 |
pinesol_green |
[evergreen|Chris Sharp] Fix purge_user_activity.pg live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c62be18> |
| 10:28 |
pinesol_green |
[evergreen|Chris Sharp] LP#1640153 Fix abort-transit-copy-status.t perl test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2057458> |
| 10:29 |
csharp |
now once I can get testing.evergreen-ils.org credentials for the new builder servers on mundungus, we can resume testing on multiple OS platforms/releases |
| 10:30 |
Dyrcona |
Well, I figured tests would be easy to test. :) |
| 10:32 |
* kmlussier |
just noticed new acq menu on webby. Hooray! |
| 10:33 |
|
sandbergja joined #evergreen |
| 10:34 |
Bmagic |
You all are making Evergreen great.... again |
| 10:34 |
csharp |
MEGA |
| 10:35 |
Bmagic |
This release is going to be YUGE! |
| 10:58 |
jeff |
weird. tpac record detail page for a deleted bib with no content, not even with expand=marchtml |
| 10:59 |
jeff |
marc column in db is 4673 bytes and appears to be valid-seeming xml. |
| 11:06 |
|
mmorgan joined #evergreen |
| 11:08 |
dbs |
jeff: generally that's a sign that the MARC is either invalid in some way, or missing something that tpac assumes every marc record should have |
| 11:08 |
dbs |
(for the former) like a datafield without a subfield, or the like |
| 11:09 |
dbs |
this is why we have a "isValidMarc" function / trigger on on bre table |
| 11:12 |
kmlussier |
What do we do with bugs like bug 1467663, where the code is now incorporated in the sprint4 collab branch? Is it okay to merge berick's branch, in which case I assume it should be taken out of the collab branch? Or has past practice been that we wait until the full collab branch is merged? |
| 11:12 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Confirmed] https://launchpad.net/bugs/1467663 |
| 11:15 |
jeff |
kmlussier: i have similar questions also. |
| 11:21 |
kmlussier |
My inclination is to merge berick's branch sooner, because the original issue reported in the bug can be a big PITA for people testing/working on the web client if they use a test system where the database is constantly reloaded. |
| 11:22 |
berick |
kmlussier: i don't imagine there would be any opposition to merging to master. I find this bug to be a real PITA as well. |
| 11:26 |
gmcharlt |
kmlussier: and from the POV of the folks maintaining the collab branch, it doesn't cause any significant problems patches are picked from it sooner |
| 11:26 |
gmcharlt |
although it would be handy if any additions or changes to such patches existed as separate patches |
| 11:27 |
kmlussier |
berick / gmcharlt: Ok, thanks! I want to test it outside of webby before merging. I'll try to make time to do so today. |
| 11:40 |
|
brahmina joined #evergreen |
| 11:41 |
berick |
kmlussier++ gmcharlt++ |
| 11:59 |
|
jihpringle joined #evergreen |
| 12:06 |
csharp |
@praise [someone] |
| 12:06 |
* pinesol_green |
mmorgan is the very model of a modern major hacker |
| 12:07 |
mmorgan |
Heh. |
| 12:22 |
|
mmorgan1 joined #evergreen |
| 12:24 |
|
bmills joined #evergreen |
| 12:36 |
|
mmorgan1 joined #evergreen |
| 12:36 |
* tsbere |
has been given a pile of tickets that want to know which local statistical category entry to assign copies so they circulate with the correct rules today |
| 12:37 |
Dyrcona |
heh |
| 12:37 |
Dyrcona |
To be fair, they used to ask the same question on Horizon. |
| 12:38 |
tsbere |
AKA, "it hasn't mattered for the current OR previous ILS, and they are still asking". I don't think that is fair to the person getting asked the question. :P |
| 12:39 |
Dyrcona |
:) |
| 12:40 |
* tsbere |
is tempted to email the MVLC catalogers list with a "THIS HAS NOTHING TO DO WITH CIRC RULES!" rant, but will probably forget all about that when dealing with setting up actual circ rules after lunch |
| 12:47 |
|
kmlussier joined #evergreen |
| 13:03 |
|
dteston joined #evergreen |
| 13:24 |
berick |
gmcharlt: OK if I remove you as assignee of bug 1437103 or are you working on it? |
| 13:24 |
pinesol_green |
Launchpad bug 1437103 in Evergreen "unexpected popup dialogs appear at checkin" [Undecided,Confirmed] https://launchpad.net/bugs/1437103 - Assigned to Galen Charlton (gmc) |
| 13:25 |
gmcharlt |
berick: feel free to grab it |
| 13:26 |
berick |
gmcharlt: thanks |
| 13:47 |
jeff |
hrm. record buckets as a means of tagging bibs for reporting. |
| 13:47 |
jeff |
"shared" bucket with set prefix, report that lets you then report on (say) circ stats for those titles. |
| 13:48 |
jeff |
i'm not sure how (or if?) i'd want to design that to be less hack-y. |
| 13:57 |
tsbere |
jeff: Make the report on bucket ids, skip the prefix entirely, make them specify which buckets they care about! :P |
| 13:57 |
tsbere |
(then the same bucket could be included in two very different report sets, for that matter) |
| 14:03 |
jeff |
in this case, the idea is a self-service report. if you want to report on the circ stats for a handful of books you just found about ducks, create a new bucket with the right prefix, run the report, select the bucket from the drop-down. |
| 14:17 |
Bmagic |
Has anyone attempted to write software to systematically download LoC Authority records? |
| 14:18 |
tsbere |
Bmagic: I am going to assume "yes". If you mean "For Evergreen" I am going to assume "no". ;) |
| 14:18 |
Bmagic |
tsbere: yeah, for Evergreen. Is it against LoC policy to do such a thing? Rate limiting, etc? |
| 14:21 |
kmlussier |
tsbere++ # For good deeds performed in other channels. :) |
| 14:35 |
kmlussier |
miker: Re: your latest comment on bug 1467663. We talked about this a bit earlier at 11:12 in the scrollback. I was going to try to merge that code on its own soonish because we all agree that the original bug is a pain to deal with. |
| 14:35 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Fix committed] https://launchpad.net/bugs/1467663 |
| 14:36 |
miker |
jeff: interestingly, that intersects with upcoming dev I'll be working on (after first of the year), re "digital bookplates" ... in reality, will be "tag bibs, make those tags searchable" |
| 14:37 |
miker |
kmlussier: perhps we should just rebase the sprint4 branch and merge its contents sooner rather than later? IMO, there's no reason to wait until alpha or later to merge webclient work |
| 14:38 |
|
dteston_ joined #evergreen |
| 14:43 |
Dyrcona |
miker: I know you're not asking me, but I agree with rebasing sprint4 and merging sooner rather than later. |
| 14:47 |
kmlussier |
Yeah, I wouldn't have a problem with it if it only contained fixes, but there's also some acq stuff in there that I don't think anyone has looked at yet. |
| 14:47 |
kmlussier |
On the other hand, it's not like anyone is running master in production these days. |
| 14:48 |
* bshum |
plays the world's smallest violin |
| 14:49 |
tsbere |
MVLC comes close at upgrade times. I don't know if we will be upgrading again, though. <_< |
| 14:49 |
csharp |
@blame running from master |
| 14:49 |
pinesol_green |
csharp: Your failure is now complete, running from master. |
| 14:49 |
csharp |
:-D |
| 14:50 |
bshum |
Remove that comma and that sentence takes on a whole different meaning! |
| 14:51 |
kmlussier |
tsbere: If you do perform another upgrade, what are the odds of you running the web client? |
| 14:52 |
berick |
+1 to more aggressive browser client merging |
| 14:53 |
tsbere |
kmlussier: Probably zero. |
| 14:55 |
csharp |
I'm trying to factor in the suggestions from https://bugs.launchpad.net/evergreen/+bug/978095/comments/5 for my work on that and bug 1257915 - but how would I determine which is the "reason from the last-canceled copy" when there's not an edit date/time to pull from on the acq.lineitem_detail table? |
| 14:55 |
pinesol_green |
Launchpad bug 978095 in Evergreen master "Acq: lineitems display as "on order" even after all copies have been cancelled" [Medium,Confirmed] - Assigned to Chris Sharp (chrissharp123) |
| 14:55 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" [Medium,Confirmed] https://launchpad.net/bugs/1257915 - Assigned to Chris Sharp (chrissharp123) |
| 14:56 |
csharp |
I guess I could randomly pick a cancel reason from one of the canceled lids? |
| 14:56 |
csharp |
(as the comment says, they'd probably all be the same reason, but I'm trying to think of inevitable corner cases ;-)) |
| 14:57 |
kmlussier |
csharp: I actually prefer the 'multiple' or 'mixed' cancel reason when there is more than one. |
| 14:58 |
berick |
csharp: the assumption in that case was the lineitem cancel reason was getting set as the last copy was being canceled. |
| 14:58 |
berick |
not that it would be determined after the fact |
| 14:58 |
csharp |
berick: ah I see |
| 14:58 |
* berick |
would also be OK w/ 'multiple' |
| 14:58 |
kmlussier |
Also, csharp++ for looking at that. |
| 14:59 |
csharp |
not seeing a "multiple" reason, so that would be new, right? |
| 15:00 |
csharp |
berick++ Dyrcona++ # for providing guidance at the hackaway |
| 15:00 |
berick |
csharp: yes, it would be a new cancel_reason |
| 15:00 |
csharp |
ok cool |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:25 |
|
hbrennan joined #evergreen |
| 15:42 |
|
abowling joined #evergreen |
| 15:45 |
|
graced joined #evergreen |
| 15:45 |
|
miker joined #evergreen |
| 15:45 |
|
Shae joined #evergreen |
| 15:47 |
|
jyorio joined #evergreen |
| 15:51 |
miker |
kmlussier: fwiw, folks other than the devs are, indeed, looking at the acq stuff (and some fixes have come out of that looking already) :) |
| 15:51 |
|
rhamby joined #evergreen |
| 15:52 |
kmlussier |
miker: Thanks for the additional info. As it is, I'm coming around on the more aggressive merging for web client stuff. |
| 15:55 |
|
phasefx_ joined #evergreen |
| 15:55 |
|
abneiman joined #evergreen |
| 16:03 |
|
akilsdonk joined #evergreen |
| 16:18 |
|
mmorgan joined #evergreen |
| 16:19 |
Bmagic |
"Update Source" from MARC EDIT is giving me a pcrud error in gateway.log - Failed to cache key:value ...... 0_13835","service":"open-ils.pcrud"}] - CONNECTION FAILURE |
| 16:19 |
Bmagic |
any clues where to start looking? |
| 16:25 |
Dyrcona |
Bmagic: memcached run out of connections? I can't find "Failed to cache" in the Evergreen code. |
| 16:26 |
Bmagic |
I guess, but Im not sure how to query memcache to find out |
| 16:26 |
jeff |
miker: good to know (about "digital bookplates" feature)! |
| 16:26 |
Dyrcona |
Bmagic: Google it. There are some commands you can run on memcached. You telnet to the memcached port. |
| 16:27 |
Bmagic |
right, I'm digging |
| 16:27 |
Dyrcona |
I say Google it, 'cause I don't remember all of the commands. |
| 16:28 |
jeff |
the "Failed to cache" error is from OpenSRF, src/libopensrf/osrf_cache.c |
| 16:29 |
Dyrcona |
Ah, thanks, jeff. |
| 16:30 |
Dyrcona |
Yeah, it's definitely a memcached failure. |
| 16:30 |
Dyrcona |
jeff++ |
| 16:30 |
Bmagic |
it's trying to cache the IP address |
| 16:30 |
jeff |
thrown when the call to memcached_set doesn't return MEMCACHED_SUCCESS |
| 16:31 |
jeff |
Bmagic: usually something like "export MEMCACHED_SERVERS=10.0.0.1" followed by memcstat |
| 16:32 |
jeff |
Which may require you to apt-get install libmemcached-tools |
| 16:34 |
jeff |
Bmagic: are you experiencing this in the xul client or web? |
| 16:34 |
Bmagic |
xul |
| 16:35 |
Bmagic |
2.11 - but only one 2.11 machine. I tried another one and it worked |
| 16:36 |
Bmagic |
ok, so curr_connections: 26 |
| 16:36 |
Bmagic |
default max is 1024, so, should be good there |
| 16:40 |
jeff |
assuming configs are correct, you may have one or more pcrud drones that lack a valid memcached connection. restart open-ils.pcrud may fix it. |
| 16:41 |
jeff |
i think c apps don't retry if memcached fails once. |
| 16:43 |
Bmagic |
jeff: I have been restarting services a bunch |
| 16:43 |
|
abowling1 joined #evergreen |
| 16:43 |
jeff |
Bmagic: I'm not sure if you're saying "already tried, didn't fix" or "oh! that might explain it!" :-) |
| 16:44 |
Bmagic |
jeff: the issue recurs. It complains about CONNECTION FAILURE |
| 16:44 |
jeff |
Bmagic: something simple(ish) like memcached server IP/port not set properly in Apache config? |
| 16:44 |
Bmagic |
jeff: I am saying that I have been restarting opensrf and apache etc with no change |
| 16:45 |
Bmagic |
I didnt know that memcached configs were in apache. I'll take a look |
| 16:45 |
Bmagic |
I checked opensrf.xml |
| 16:45 |
|
abowling2 joined #evergreen |
| 16:45 |
jeff |
I could be wrong about which open-ils.pcrud uses. |
| 16:46 |
jeff |
rather, I don't know without looking which it uses. |
| 16:46 |
Bmagic |
OSRFTranslatorCacheServer ? is commented out |
| 16:46 |
jeff |
but you're going to run into issues sooner or later if your Apache config has the wrong value for OSRFTranslatorCacheServer |
| 16:47 |
Bmagic |
hmmm, is that new with 2.11? |
| 16:47 |
jeff |
Nope. |
| 16:47 |
jeff |
Commented out is going to default to 127.0.0.1:11211 |
| 16:47 |
Bmagic |
interesting |
| 16:47 |
|
abowling joined #evergreen |
| 16:50 |
Bmagic |
jeff: that was it |
| 16:51 |
Bmagic |
eg_vhost -> OSRFTranslatorCacheServer |
| 16:51 |
bshum |
That used to manifest pretty fast when using cataloging |
| 16:52 |
bshum |
With multiple app servers that is |
| 16:53 |
Bmagic |
which has always been commented out for us. LOL. Looking further, I find that each app server had memcached running, but not configed in opensrf.xml |
| 16:53 |
bshum |
If one sticks with the same app server long enough, that might not be a problem, per say. |
| 16:53 |
Bmagic |
crazy |
| 16:54 |
Bmagic |
It's showing it's face now because I have left memcached off on the app servers now |
| 16:57 |
Bmagic |
jeff++ Dyrcona++ |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:02 |
jeff |
okay, the "report on circ counts for copies attached to titles in a shared bucket with a specially prefixed name" report works well. |
| 17:04 |
|
mmorgan left #evergreen |
| 17:08 |
|
bmills joined #evergreen |
| 17:35 |
|
jvwoolf joined #evergreen |
| 17:48 |
|
jwoodard joined #evergreen |
| 18:11 |
|
bmills joined #evergreen |
