| 01:31 |
|
Jillianne joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:43 |
|
dwgreen joined #evergreen |
| 08:05 |
|
kmlussier joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:45 |
|
collum joined #evergreen |
| 09:50 |
csharp |
does webby respect the session timeout YAOUSes? |
| 09:52 |
mmorgan |
csharp: I don't believe I tested in webby explicitly, but see lp 1693035 |
| 09:52 |
pinesol_green |
Launchpad bug 1693035 in Evergreen "Logins not honoring all org unit timeout settings" [Medium,New] https://launchpad.net/bugs/1693035 |
| 09:55 |
csharp |
mmorgan: perfect - thanks! |
| 10:01 |
kmlussier |
csharp: I asked that question in here a few weeks ago. Initially, I was seeing that webby wasn't timing out at all, but the next day, it started to time out based on the YAOUS. |
| 10:02 |
kmlussier |
I didn't investigate further because other things came up. |
| 10:03 |
Dyrcona |
Webby is open. Maybe someone messed with the timeouts? |
| 10:04 |
kmlussier |
Yes, let me correct myself. Not in webby, but in the web client. I did the testing on my own VM, and it wasn't an issue with the settings changing. |
| 10:08 |
csharp |
sorry, yes I was using "webby" to mean "the web client" |
| 10:11 |
kmlussier |
csharp: Dyrcona was speculating that it could be a cache issue when I reported back my results here - http://irc.evergreen-ils.org/evergreen/2017-09-29#i_327518 |
| 10:12 |
kmlussier |
But a couple of days earlier when I first started testing, I believe berick said he noticed it doesn't always work for him. |
| 10:13 |
Dyrcona |
If there are errors rendering a template, where would they show up in the logs, if at all? |
| 10:14 |
berick |
i confirmed one scenario where it fails to log out. if the server is no longer responding, as in the case w/ a temp VM I set up yesterday, it get stuck in the middle of the log out dance. that's an atypical example, but maybe there's something to be learned there. worth looking for JS console errors around the time it should have logged out... |
| 10:15 |
Dyrcona |
Oh, wait! I see the problem. Never mind. |
| 10:40 |
|
mmorgan1 joined #evergreen |
| 10:41 |
csharp |
berick: not that I've seen |
| 10:44 |
csharp |
seeing lots of no_tz.open-ils.storage.actor.user.crazy_search: prepare_cached(SELECT evergreen.unaccent_and_squash(?)) statement handle DBIx::ContextualFetch::st=HASH(0xd55f878) still Active at /usr/local/share/perl/5.18.2/OpenILS/Application/Storage/Publisher/actor.pm line 627. in the osrfwarn log |
| 10:49 |
kmlussier |
berick: I didn't file any mainly because, once I got the timeout the work a couple of days after adding the setting, I didn't continue testing it to determine if my initial problem was indeed a cache issue or if there was a larger problem. |
| 10:51 |
berick |
kmlussier: gotcha. (again, not sure if we need one, just curious) |
| 10:51 |
* berick |
looks at the API issue |
| 10:53 |
jeff |
csharp: and did those insanely high values then cause problems with webby? |
| 11:16 |
|
sandbergja joined #evergreen |
| 11:31 |
Bmagic |
berick: select * from reporter.simple_record where tcn_value = '2468087' results in 4 rows. Perhaps too many rows is the issue? |
| 11:32 |
berick |
Bmagic: do where id = <whatever> |
| 11:32 |
Bmagic |
berick: that can't be right, because I tested one of the barcodes that showed the title in the email and it had 4 rows also |
| 11:33 |
Bmagic |
berick: using the id column to match the record from asset.call_number where call_number is asset.copy.call_number, I still get 4 rows |
| 11:34 |
berick |
ok, yeah, there should only ever be 1 reporter.simple_record entry per bib ID |
| 11:34 |
Bmagic |
strange that the example where the title appeared in the email also has 4 rows |
| 11:41 |
Bmagic |
funny you should ask, I did a presentation 2 years ago showing how we have been addressing duplicate records |
| 11:42 |
Bmagic |
and we have been deduping bre on a regular basis using this 2-step approach |
| 11:43 |
berick |
well i mean multiple occurences of the same bib ID in reporter.materialized_simple_record |
| 11:44 |
Bmagic |
berick: once I started querying rmsr - there is only 1 row per bib (of the two that I tested where one is showing the title and the other is not) |
| 11:45 |
berick |
ok, good. |
| 11:45 |
berick |
that's at leat as it should be |
| 11:45 |
Bmagic |
if there is a row there, then the email should have the title? |
| 15:03 |
miker |
it shouldn't, as the network should be autoflushed, and the send() def happens before the check for max_requests... but it's a lead I'm chasing down |
| 15:03 |
Dyrcona |
dbwells: Variation on the off-by-one error: Taking a count too soon and acting on it. |
| 15:07 |
dbwells |
miker: I am able to recreate the "hang" with enough persistence using open-ils.search.biblio.copy_counts.location.summary.retrieve but it doesn't look like the log message is related, unfortunately. |
| 15:07 |
miker |
:( |
| 15:07 |
miker |
thanks for testing |
| 15:10 |
miker |
dbwells: I was going to say, before, the stderr msg looks like a bug of omission, by not closing a helper statement handle that gets cached somewheres ... seems more likely now, after your test |
| 15:11 |
miker |
so, likely not a failure-causing bug, just noise |
| 15:11 |
dbwells |
yeah |
| 15:16 |
csharp |
this call: CALL: open-ils.search open-ils.search.serial.record.bib.retrieve 5621115, 1, 1 |
| 15:17 |
csharp |
which is made while a record loads, results in a "severe query error" (Empty IN list) |
| 16:13 |
mmorgan |
open-ils.cstore open-ils.cstore.direct.config.usr_setting_type.search.atomic {"name":[]} |
| 16:16 |
dbwells |
miker: Just caught up on reading bug #1704396. Not sure if my issue is even related to the other search hangs, but is sure seems that way. The "good" news is a simple srfsh script with 500 open-ils.search.biblio.copy_counts.location.summary.retrieve calls is enough to reliably trigger this behavior for us, unfortunately only on production. |
| 16:16 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,Confirmed] https://launchpad.net/bugs/1704396 |
| 16:16 |
dbwells |
miker: so, I should at least be in a somewhat reasonable position to test patches. |
| 16:19 |
dbwells |
miker: I also wonder (without much understanding yet) whether the bug might be in the ".atomic" wrapper. Logs look like storage responds, but search just keeps waiting for it to finish. I might try a quick non-atomic copy of open-ils.search.biblio.copy_counts.location.summary.retrieve just to see if it passes the srfsh test. |
| 16:30 |
|
b_bonner joined #evergreen |
| 16:35 |
|
rlefaive joined #evergreen |
| 16:43 |
dbwells |
Just anecdotal at this point, but "atomic" in the storage call does not seem to be a factor. |
| 17:05 |
miker |
dbwells: thanks! that's one less thing to check early on |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
|
Jillianne joined #evergreen |
| 17:12 |
|
jihpringle joined #evergreen |
| 17:50 |
|
b_bonner left #evergreen |
| 17:54 |
|
Dyrcona joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:23 |
|
phooks joined #evergreen |
| 19:26 |
|
phooka joined #evergreen |
| 19:30 |
phooka |
working on building out new production servers and autogen.sh is erroring out while Updating OrgTree |
| 00:13 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: adding backup information to cli manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ecad6e> |
| 02:27 |
|
kipd joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 08:15 |
|
collum joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 09:01 |
JBoyer |
Or, anyone else with some insider knowledge re: 3.0 search. |
| 09:01 |
JBoyer |
? |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:05 |
* csharp |
is curious about JBoyer's search concern since we're testing 3.0 right now |
| 09:06 |
JBoyer |
I've found a difference in the queries where staff can't accurately limit to a single location but patrons can. I was hoping to get some background on why. |
| 09:06 |
JBoyer |
Also, has your 3.0 testing turned up anything similar? (or, rather, have you checked?) |
| 09:12 |
csharp |
not that I know of - I can check |
| 09:14 |
mmorgan |
JBoyer: I just did a quick search logged in as a staff user on a 3.0 system, and am also seeing a problem with limiting. |
| 09:15 |
JBoyer |
Ok. So good news, I'm neither crazy* nor running a damaged system. (*At least not for this reason) |
| 11:13 |
miker |
hrm... well, I'm around now |
| 11:15 |
miker |
re the search stuff above, I looked at this last week with an upgraded system and didn't see the behavior. which obv doesn't mean it's not happening, just that something's different |
| 11:19 |
|
mmorgan joined #evergreen |
| 11:19 |
kmlussier |
I see it too on one of my test VMs. |
| 11:30 |
|
rlefaive joined #evergreen |
| 11:46 |
kmlussier |
Never mind. I don't see it on my VM. I was just seeing the standard gray bibs that always come up in a staff search. |
| 11:46 |
* kmlussier |
drinks more coffee. |
| 11:47 |
kmlussier |
This dataset shouldn't have any copy-less bibs, but I guess that's another problem to solve in my spare time on a later date. |
| 12:02 |
|
khuckins joined #evergreen |
| 12:58 |
|
yboston joined #evergreen |
| 12:59 |
|
khuckins joined #evergreen |
| 17:48 |
csharp |
maybe the wrong kind of join in the fieldmapper linkage? (but that probably would result in perl-level errors rather than blank data) |
| 17:54 |
berick |
Bmagic: you've confirmed the bibs in question have reporter.simple_record entries? |
| 17:54 |
berick |
... with titles |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:04 |
rhamby |
fyi, removing roles of some wordpress accounts for those that haven't been active in 8+ years |
| 19:12 |
csharp |
wow - that bot really was wreaking havoc for us - error/warn logs are very reasonable now |
| 19:12 |
csharp |
@band add Wreaking Havoc |
| 00:41 |
|
Jillianne joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_ joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:27 |
|
kmlussier joined #evergreen |
| 09:19 |
|
bos20k joined #evergreen |
| 09:48 |
miker |
jeff / bshum: yes, there's really nothing to maintain -- the introspection stuff is old as the hills and hasn't changed ... ever. there are some issues on the C side that should be cleaned up (the atomic/streaming bool is logically reversed from the perl, signature structure is a little different) however -- but that's opensrf, not docgen |
| 09:49 |
miker |
also, I find it very handy on a dev system on occasion, so I'd like to see it unbroken as well |
| 09:55 |
bshum |
Well, so far in my re-testing of the apache config |
| 09:55 |
bshum |
I think all that's really needed was to add "AddType application/xml .xsl" to the definition |
| 09:55 |
bshum |
I'm not sure if it's an apache 2.4 specific thing |
| 09:56 |
bshum |
I have to retest with a system that's got apache 2.2, but really those should be mostly dead by now :) |
| 09:56 |
miker |
bshum: that looks like it works. 2.2 isn't all the way dead, though |
| 09:56 |
* bshum |
goes back to the archives to try finding a wheezy ISO |
| 09:57 |
bshum |
miker: I know, I'm just living my life on the edge of new :) |
| 10:53 |
bshum |
So apache 2.2 config requires no adjustment and "just works" |
| 10:54 |
miker |
it correctly sees xsl as an xml application ... :) |
| 10:54 |
jeff |
bshum: on apache 2.4, you didn't need the SSI legacy directive? That doesn't mesh with my understanding. |
| 10:54 |
bshum |
jeff: Well I was just testing with the lines one by one, and found that I only needed the one line |
| 10:55 |
miker |
jeff: you do. you need the whole block that the commit removed, plus the line bshum is talking about |
| 10:55 |
miker |
or, that's what worked for me on 2.4 |
| 10:55 |
bshum |
So now I'm not sure why, cause I thought I needed everything too |
| 10:55 |
bshum |
Maybe something got cached... re-tests |
| 10:55 |
jeff |
heh. |
| 10:56 |
jeff |
miker: that's why i was surprised and trying to make sure i understood bshum's statements above. |
| 10:57 |
bshum |
jeff: miker: well.... odd as it seems, when I only add that one line to my eg_vhost.conf definition for the docgen.xsl, the page renders as expected... |
| 16:17 |
|
mmorgan joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:13 |
|
sandbergja joined #evergreen |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:18 |
|
jvwoolf joined #evergreen |
| 06:01 |
|
rlefaive joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
JBoyer joined #evergreen |
| 08:44 |
|
_adb joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:50 |
Dyrcona |
Based on this line "dumpost_cfg_t *) ap_get_module_config(r->per_dir_config, &dumpost_module)" I assume that mod_dumpost can be configured per directory, so I'll give that one a shot. It can also log headers. |
| 09:01 |
JBoyer |
Oh, yeah, dumpio was what I had used. I was using it on a test system so while it was crazy chatty it wasn't *All the things* I hope dumppost works, that sounds more generally useful. |
| 09:04 |
Dyrcona |
I'll give it a whirl. |
| 09:19 |
|
abowling1 joined #evergreen |
| 09:19 |
Dyrcona |
I have to use this on production to capture what Autographics sends us. I'd rather not have to take the time to set up a test with them. |
| 09:19 |
Dyrcona |
But, I'm gonna try it on a test vm, first. |
| 09:21 |
Dyrcona |
@decide stay or go |
| 09:21 |
pinesol_green |
Dyrcona: go with go |
| 09:22 |
Dyrcona |
pinesol_green: I knew you'd say that. ;) |
| 10:09 |
Dyrcona |
Ah, no. It looks like that line is deceiving and DumpPost configs have to be server wide. |
| 10:26 |
Dyrcona |
JBoyer: I've logged a few messages from Autographics, and I'm surprised. |
| 10:27 |
Dyrcona |
JBoyer: What I see blows up with the old version of HTTP::Body, too, so the change that causes the issue is elsewhere. |
| 10:27 |
Dyrcona |
But, now I have some real data to test with. |
| 10:34 |
JBoyer |
Dyrcona, did you manage to pull any POST info with them or just the XML? If it's not too much trouble to anonymize I could poke at it on occasional too |
| 10:34 |
Dyrcona |
I'm grabbing the content-type head and the POST body. |
| 10:34 |
Dyrcona |
s/(head)/\1er/ |
| 10:35 |
Dyrcona |
Since this is server-wide. |
| 10:36 |
Dyrcona |
I've got at least 5 more messages from autographics, now. |
| 10:37 |
Dyrcona |
I may shut it down before an hour. The file grows a few hundred KB per minute. :) |
| 10:39 |
Dyrcona |
They're using Content-type: application/xml, and my testing shows that blows with Dancer 1.3202 with the old and the new version of HTTP::Body. |
| 10:39 |
JBoyer |
Not as bad as dumpio but still a but chatty, yeah |
| 10:40 |
Dyrcona |
In fact, the xml handler for HTTP::Body is the same, other than the version number. |
| 10:40 |
JBoyer |
Huh. So something about the older version of HTTP::Body on 14.04 is why it doesn't blow up here? |
| 13:36 |
JBoyer |
And 2, when customizing receipt templates, (checkout specifically) I |
| 13:36 |
Dyrcona |
OK. It shouldn't be hard to recreate. Just set content-type to application/xml for one. |
| 13:37 |
JBoyer |
ve heard from staff that they can't add patron name and barcode. Meaning that {{patron.first_given_name}} and so on works in the preview, but not on paper. Is that a regression or is the preview just ahead of the backend? |
| 13:37 |
Dyrcona |
JBoyer might also be interested to know that after 2-1/2 hours of logging, I have 127 actual messages from autographics to test with. |
| 13:37 |
dbwells |
Dyrcona: yes :) In my opinion, the bug is in HTTP::Body::XForms. It just lazily sets body to the buffer contents, which isn't going to be a handle. |
| 13:38 |
Dyrcona |
dbwells: What's odd is that hasn't changed since 2010, and that older version "worked." |
| 13:38 |
Dyrcona |
Unless autographics changed their content-type to coincide with our upgrade... |
| 13:54 |
Dyrcona |
That may be easier. I'll try that first. |
| 13:54 |
Dyrcona |
dbwells++ # again for the suggestions. |
| 13:59 |
dbwells |
Dyrcona: trying to familiarize myself a bit with NCIPServer, figure we'll probably move in that direction sooner or later :) |
| 14:00 |
kmlussier |
JBoyer: You might want to check in with Terran on the receipt issue. I know she did a lot of testing to see which fields worked and which didn't. |
| 14:02 |
kmlussier |
JBoyer: When I tested the new search code, I did a lot of side-by-side testing on two different servers to try to verify the code was retrieving the same set of search results, except in cases where it was retrieving more because of the higher cap. |
| 14:02 |
kmlussier |
I didn't see anything strange at that time, but I don't know if I limited by library from advanced search in my testing. |
| 14:03 |
* kmlussier |
returns to trying to figure out why badges don't always show when they should. |
| 14:19 |
miker |
JBoyer: not seeing that on demo.evergreencatalog.com ... and I can't remember you're catalog's URL |
| 14:20 |
JBoyer |
evergreen.lib.in.us |
| 14:21 |
JBoyer |
berick, re: bug 1656036, If I have time tomorrow to through something together I'd appreciate some thoughts, but if I can't get things together go with your plan. Like you said, it's better to get something going than continually bikeshedding this thing. |
| 14:22 |
JBoyer |
Yeah, that metarecord search bug was driving me nuts, but I didn't see any point in letting people see it. |
| 14:22 |
JBoyer |
I mean, as far as I know it still is, I haven't had time to track anything down. :/ |
| 14:23 |
JBoyer |
miker, a simple search that shows what I mean: search Indiana state library for title Bag of Bones (we mainly collect large print for users with poor sight) there are several results that have nothing to do with us. |
| 14:26 |
miker |
so, I may not be testing what you're testing, but I just searched for 'harry potter' globally (773 results), went to advance search and restricted to Andrews and got what I expected (77 results) and added added a cache killer, and got the same 77 results. all hav copies at andrews AFAICT |
| 14:26 |
kmlussier |
JBoyer: They're all ebooks? |
| 14:26 |
miker |
or are ebooks |
| 14:26 |
|
khuckins_ joined #evergreen |
| 14:37 |
miker |
:) |
| 14:40 |
|
tspindler joined #evergreen |
| 14:42 |
JBoyer |
I'm currently rebuilding all of the app servers to hide the timings, but since it's only staff I guess it's less dire, though staff are more likely to notice anyway. |
| 14:42 |
JBoyer |
So I'll keep looking, and that's a way to test webby to make sure it's just us. |
| 14:48 |
Dyrcona |
dbwells++ # One more time, because hacking HTTP::Body::XForms seems to have fixed it for me. Changing NCIP::Dancing didn't work. :( |
| 14:50 |
miker |
JBoyer: I'm not seeing this in a (quick) test at demo.evergreencatalog.com, fwiw |
| 14:51 |
miker |
logged in as staff, obv |
| 14:51 |
JBoyer |
miker, thanks for checking; moar data, moar help. I'll continue to poke. |
| 14:52 |
JBoyer |
Just because I'm curious, does the new asset.copy_vis_cache stuff get used in searches like this, or is that used elsewhere? (record details or something else) |
| 14:52 |
miker |
it's used in searches |
| 17:14 |
jeff |
i'd still recommend not installing it by default, and perhaps even recommend restricting it, and give it a look-over, but part of why it has lasted as long as it has is that it doesn't require much in the way of upkeep -- it uses opensrf system calls to get methods and their signatures from the running system. |
| 17:26 |
|
Jillianne joined #evergreen |
| 17:59 |
|
yboston joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:01 |
|
Christineb joined #evergreen |
| 19:22 |
* csharp |
cranks up Bmagic's docker image |
| 20:09 |
csharp |
btw, my suggestion to use Fedora server/cockpit makes downloading/installing/running the docker image super easy |
| 01:35 |
|
rlefaive joined #evergreen |
| 04:02 |
|
Jillianne joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:32 |
|
book` joined #evergreen |
| 07:01 |
|
jvwoolf joined #evergreen |
| 07:04 |
|
sard joined #evergreen |
| 11:13 |
_adb |
O_o |
| 11:14 |
_adb |
idk 'bout that, but i got cats https://i.imgur.com/g27CrKb.gifv |
| 11:15 |
kmlussier |
:) |
| 11:31 |
Dyrcona |
Eh, bummer. That patch hasn't fixed the problem in production. It worked on my test VM though. |
| 11:32 |
|
jvwoolf joined #evergreen |
| 11:36 |
Dyrcona |
Maybe it did, and it didn't kick in until the second apache2 reload? |
| 11:40 |
|
collum joined #evergreen |
| 15:22 |
Bmagic |
kernal/kernel |
| 15:24 |
csharp |
sandbergja: also, make sure the laptop's processor is set to use virtualization (BIOS setting), otherwise vbox will not run well |
| 15:25 |
csharp |
(might be the case with Hyper-V too, but I'd be surprised if it runs at all without that setting set already) |
| 15:25 |
Bmagic |
sandbergja: If I am understanding that you are using docker for Windows, you can test a basic Ubuntu image without using the Evergreen container. "docker run ubuntu -it" |
| 15:27 |
Bmagic |
Something tells me that it's not going to work due to some of the system calls being incompatible. the videos: https://vimeo.com/230985351 and https://vimeo.com/231611654 |
| 15:27 |
csharp |
Bmagic++ |
| 15:27 |
* csharp |
still needs to make time to watch the third installment |
| 17:43 |
cesardv |
lol |
| 17:43 |
* cesardv |
really likes halloween >< |
| 17:44 |
* berick |
will not be trickrtreating at cesardv's house |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:46 |
|
jvwoolf joined #evergreen |
| 18:59 |
|
stephengwills left #evergreen |
| 19:29 |
|
rlefaive joined #evergreen |
| 00:06 |
|
sallyf joined #evergreen |
| 00:06 |
|
lbarry joined #evergreen |
| 02:33 |
|
Jillianne joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
JBoyer joined #evergreen |
| 07:51 |
|
agoben joined #evergreen |
| 13:40 |
Dyrcona |
I noticed it when looking at the latest version of the Enlightenment window manager. They apparently use it. |
| 13:41 |
Dyrcona |
Right now, I'm trying to figure out why Plack::Handler::Apache2 and Dancer::Request are not playing nice together. |
| 13:55 |
Dyrcona |
So, I'm trying Plack from CPAN. |
| 14:02 |
Dyrcona |
No one can answer me about running NCIPServer on Ubuntu 16.04? It is broken for me, but I swear I tested is once before and it worked. |
| 14:21 |
Dyrcona |
Oh, lovely. |
| 14:21 |
Dyrcona |
It's broken in production, but it just works on a test vm. |
| 14:41 |
Dyrcona |
And, it just works for me in production when I run my test script using LWP against it. |
| 14:41 |
jeff |
problem with the data production is receiving? |
| 14:42 |
|
stephengwills joined #evergreen |
| 14:51 |
Dyrcona |
Nope. Not the data. |
| 15:29 |
jeff |
on git.evergreen-ils.org or elsewhere? |
| 15:30 |
Dyrcona |
git.evergreen-ils.org |
| 15:30 |
Dyrcona |
I've been chatting with some folks in #dancer on irc.perl.org. |
| 15:30 |
Dyrcona |
The consensus there was some weird interaction of Plack::Handler::Apache2 and Dancer, but that was before I had done my own tests. |
| 15:31 |
Dyrcona |
I even removed the packaged plack and installed it from CPAN. |
| 15:32 |
jeff |
did it break suddenly, or is this after a known change was made? |
| 15:32 |
Dyrcona |
Now, it think it's something "weird" in their POST requests that Apache 2.4 or the Plack handler doesn't like. |
| 17:12 |
jeff |
stephengwills: are you trying to step through a trigger function, or do something else? |
| 17:12 |
stephengwills |
stepping through trigger function |
| 17:13 |
stephengwills |
still working on that 001/003 thing from this morning. everytime I try to get out…it pulls me back in! |
| 17:13 |
Bmagic |
stephengwills: I have been known to replace a function with one that puts more in the output using things like NOTICE along the way. On a test machine of course. |
| 17:14 |
stephengwills |
I was thinking of doing that. just lots of watchdog lines |
| 17:14 |
Bmagic |
in some cases, adding columns to tables to write the debug output during execution. Maybe jeff has something better |
| 17:17 |
|
Jillianne2 joined #evergreen |
| 17:24 |
jeff |
if they don't, then they will fall back to org unit id 1, and use either that org unit's setting for cat.marc_control_number_identifier or they will use the shortname if org unit 1 does not have a value set for that setting. |
| 17:25 |
stephengwills |
so what i really want to do is run the bre and update the owner? on save the 003 will get fixed? |
| 17:25 |
jeff |
where "they will fall back to org unit id 1" is better written as "then the control number identifier handling for those records will fall back to org unit id 1" |
| 17:25 |
stephengwills |
that’s easy enough to test |
| 17:26 |
jeff |
the global flag cat.maintain_control_numbers also needs to be enabled, but i suspect you have that set already. |
| 17:27 |
stephengwills |
yup that’s good |
| 17:27 |
stephengwills |
almost all of our records have a null owner |
| 17:27 |
stephengwills |
:/ |
| 17:28 |
stephengwills |
you understand I only come here to embarress myself in from of my better, right? |
| 17:29 |
stephengwills |
thanks |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:11 |
|
stephengwills left #evergreen |
| 21:18 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating copy buckets docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ec21eb8> |
| 23:14 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: documentation for Record Buckets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=55edc1f> |
| 00:56 |
|
bwicksall_ joined #evergreen |
| 01:34 |
|
bwicksall joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:37 |
|
Dyrcona joined #evergreen |
| 07:53 |
|
kmlussier joined #evergreen |
| 08:11 |
Dyrcona |
Noodle [from Gorillaz] gets a holiday? Cool! |
| 08:11 |
jonadab |
Only thing is, if you have a Happy Puppy Day, you're probably going to have to have a Cute Kitten Day too, or the cat lovers will riot. |
| 08:12 |
rjackson_isl |
True |
| 08:12 |
kmlussier |
Dyrcona++ #Excellent test plan for placing multiple holds |
| 08:12 |
Dyrcona |
kmlussier: Thanks. There are also PgTap and perl tests for the backend changes. |
| 08:13 |
* Dyrcona |
has decided that tests are good. |
| 08:16 |
* csharp |
had an idea to develop baseline schema pgtap tests so sites know if they have everything expected by the stock install |
| 08:16 |
csharp |
but seems like that would be a massive project |
| 08:16 |
csharp |
actually a lot of the scripting could probably be automated |
| 08:16 |
Dyrcona |
Some of that is there already, I think. |
| 08:16 |
Dyrcona |
And, yes, it could be automated. |
| 08:17 |
Dyrcona |
Query pg_catalog and related tables on a known good installation and write out the tests. |
| 08:18 |
Dyrcona |
I still wouldn't call it trivial. |
| 08:18 |
Dyrcona |
Might take a day or so to get it all just right. |
| 08:18 |
* csharp |
keeps thinking of things like this, thinks, "oh, that would be great for the hackaway", then realizes how many other things exactly like that have already been mentioned :-) |
| 08:36 |
|
collum joined #evergreen |
| 08:52 |
|
kmlussier joined #evergreen |
| 09:00 |
|
bos20k joined #evergreen |
| 09:16 |
* Dyrcona |
shut down his gitlab test vm, but it may only be temporary. |
| 09:16 |
Dyrcona |
I might rebuild it or move it to another server. |
| 09:17 |
csharp |
gitlab is the front runner imho |
| 09:17 |
Dyrcona |
I really need to make the time to look at it seriously. I think I'd like to switch to gitlab from gitolite for our local repositories, but other projects are more important. |
| 09:26 |
|
kmlussier joined #evergreen |
| 09:27 |
csharp |
Dyrcona: I have another server earmarked for community VMs that has more resources than current mundungus |
| 09:27 |
Dyrcona |
csharp++ |
| 09:30 |
Dyrcona |
My gitlab test vm is set to use up to 60GB of space and is actually 18GB in size, and it's hardly being used. |
| 09:31 |
Dyrcona |
It uses 4GB of RAM, but could probably use more. |
| 09:31 |
Dyrcona |
Just for a reference. |
| 09:31 |
csharp |
/dev/mapper/mundungus-root 481G 257G 200G 57% / |
| 16:52 |
Dyrcona |
Not related (directly) to Evergreen but this looks neat: http://resume.github.io/ |
| 16:53 |
Dyrcona |
You have to opt-in by starring the resume/resume.github.com project. |
| 17:21 |
|
roycroft joined #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 07:32 |
|
Dyrcona joined #evergreen |
| 07:50 |
csharp |
Bmagic: I'm interested in the results of your test as well - that's a long-standing source of confusion for our libraries |
| 08:03 |
|
collum joined #evergreen |
| 08:27 |
Dyrcona |
So, no one uses retarget local holds when checking in new copies? |
| 08:28 |
* Dyrcona |
just got caught up with the logs. |
| 09:24 |
Dyrcona |
There are things about syrup that I do not understand. |
| 09:24 |
Dyrcona |
i.e. most of it. |
| 09:25 |
Dyrcona |
It appears to need an Evergreen installation to talk to via the gateway, yet doesn't work unless services are also running locally. |
| 09:27 |
* Dyrcona |
is going to install stock 3.0 on a test server with production data. |
| 09:27 |
kmlussier |
No, I don't think that's true. NOBLE doesn't have Syrup running with an Evergreen installation. I'm pretty sure artunit told me it wasn't needed way back when. |
| 09:27 |
Dyrcona |
All I can say is what I see in our installation which I did not set up and have had little to do with except upgrading the OpenSRF and Evergreen packages when we upgrade production. |
| 09:28 |
Dyrcona |
Ours has configuration to use bark.cwmars.org and it wont' work unless I run services locally. |
| 09:29 |
Dyrcona |
That's all I can say for certain at this time. |
| 09:29 |
Dyrcona |
I did set up a test vm that uses itself, and the same appears to be true there. |
| 09:29 |
Dyrcona |
Hopefully, we will soon abandon Syrup. |
| 09:36 |
|
mdriscoll joined #evergreen |
| 09:47 |
kmlussier |
I'm curious. Why is the new Overdrive functionality not recommended for production use without careful testing? |
| 09:48 |
csharp |
hmm - 2017-10-05 09:15:42 utility03 open-ils.trigger: [WARN:25782:Client.pm:122:] Sending large message of 2544937 bytes to router private.utility03.gapines.org/open-ils.trigger |
| 09:48 |
Dyrcona |
'Cause it hasn't been thoroughly tested, or at least not beyond Sitka. |
| 09:48 |
csharp |
immediately after that, the client is gone from the jabber network |
| 09:48 |
* Dyrcona |
is supposed to setup a test with Overdrive, but time. |
| 09:50 |
csharp |
that's a PO JEDI a/t event, btw |
| 09:51 |
Dyrcona |
csharp: Did the event complete with success and was it properly handled? |
| 09:55 |
mdriscoll |
Regarding Syrup, NOBLE has opensrf 2.4.1 installed on our syrup server. We are not even running opensrf services. Syrup utilizes the opensrf libraries to talk to whatever evergreen server you point it at. According to a comment in the code "It [Python OpenSRF library] isn't needed for our read-only ILS operations, only for updates." So if you are not having Syrup make changes to Evergreen copies like copy location, I |
| 15:06 |
Dyrcona |
And, git confirms it. |
| 15:06 |
|
Stompro joined #evergreen |
| 15:06 |
* Dyrcona |
wanted to make a slashdot joke, about offline being dead, but it didn't seem to fit. |
| 15:25 |
kmlussier |
Speaking of offline, I asked this question late Friday afternoon, which is a bad time to ask a question. |
| 15:26 |
kmlussier |
All of my offline testing was done when my computer was offline or when I was in offline mode. |
| 15:26 |
kmlussier |
I've noticed when rebuilding my VMs that offline doesn't seem to work if the Evergreen server is down. |
| 15:27 |
kmlussier |
How will we be handling those situations where the Evergreen server is down? |
| 15:35 |
Dyrcona |
I thought that was the point of offline, though granted you may have to make a connection first to get the required data. |
| 15:36 |
kmlussier |
Dyrcona: Yes, you do have to make that connection first and load the patron edit screen. |
| 15:38 |
Dyrcona |
So, you're saying that after that, it still doesn't work if the server is down? |
| 15:52 |
kmlussier |
berick: That's what I did before when I said I went directly to the offline page. |
| 15:52 |
berick |
ah, missed that part of the comment |
| 15:52 |
berick |
so it fails to render |
| 15:53 |
kmlussier |
berick: yes |
| 15:54 |
kmlussier |
miker: So have you gotten offline to work in your own testing where the Evergreen server is no longer available? |
| 15:55 |
miker |
kmlussier: it's working for me right now on webby |
| 15:55 |
miker |
(apache is off) |
| 15:56 |
miker |
well, back on now |
| 15:58 |
kmlussier |
miker: OK, I visited the patron reg page. |
| 16:00 |
miker |
kmlussier: apache's down |
| 16:00 |
miker |
hey webby, I'm in your interface offlinin' books ;) |
| 16:02 |
kmlussier |
miker: hmmm, so it worked at first, but then after I cleared my browser cache (not app cache), I got the 503. |
| 16:07 |
kmlussier |
On my own test server, if I simply stop Evergreen services, offline works. |
| 16:08 |
miker |
ah, that's because of ngnix |
| 16:09 |
miker |
or... wait... |
| 16:10 |
miker |
haproxy on webby, rather |
| 16:20 |
kmlussier |
bug 1721636 |
| 16:20 |
pinesol_green |
Launchpad bug 1721636 in Evergreen "upup needs to learn about i18n.js" [Undecided,New] https://launchpad.net/bugs/1721636 |
| 16:20 |
kmlussier |
miker++ |
| 16:20 |
miker |
kmlussier: thanks |
| 16:20 |
* miker |
makes a note at the top of base_js.tt2 |
| 16:29 |
miker |
kmlussier: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1721636-i18n_js-for-upup |
| 16:29 |
miker |
kmlussier: you'll need to clear the service worker cache to test, obvs |
| 16:31 |
* kmlussier |
prefers WARNING WARNING WARNING over ATTENTION ATTENTION ATTENTION because it reminds her of the Lost in Space robot. |
| 16:31 |
miker |
kmlussier: ha! I started with WARNING, but changed it ... sorry :) |
| 16:39 |
|
khuckins_ joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:05 |
|
khuckins__ joined #evergreen |
| 17:37 |
|
berick joined #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
BobW__ joined #evergreen |
| 19:47 |
|
yar joined #evergreen |
| 22:09 |
|
wsmoak_ joined #evergreen |
| 02:37 |
|
jihpringle joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 08:07 |
|
collum joined #evergreen |
| 10:20 |
Dyrcona |
Are you talking about 2.12 or 3.0? |
| 10:20 |
csharp |
2.12/OpenSRF 2.5 |
| 10:20 |
Dyrcona |
OK. Just makin' sure. :) |
| 10:20 |
csharp |
we're going to 3.0 in January - just trying to get it going on all test servers I can get my hands on ;-) |
| 10:21 |
Dyrcona |
OK. Thought you were upgrading this weekend, too. |
| 10:21 |
csharp |
nah - we moved to 2.12 over Labor Day weekend - I'm a glutton for punishment, but not that much! :-) |
| 10:21 |
Dyrcona |
We're looking at maybe next June for 3.0, but that's because there are a ton of other things we want to do in the mean time. |
| 14:38 |
Dyrcona |
:) |
| 14:38 |
Bmagic |
All FYI - The Evergreen 3.0 docker container is now avaialble for cloning. docker pull mobiusoffice/evergreen-ils:3.0.0 |
| 14:43 |
|
DPearl joined #evergreen |
| 14:47 |
jeff |
Bmagic: only intended for testing use, not production -- per the repository description? |
| 14:48 |
Bmagic |
jeff: I don't think there is a problem using it for production, provided you handle the database and configs for your environment |
| 14:48 |
Bmagic |
we are using containers for our application bricks |
| 14:48 |
Bmagic |
works perfectly fine, the database is separate |
| 16:47 |
Bmagic |
blongwell - I always have to use the SQL query to see which one it's deciding |
| 16:48 |
Bmagic |
the first part of the routine is to get the ID numbers of the circ staff, patron, item, circ library |
| 16:49 |
Bmagic |
then plug those values into action.find_circ_matrix_matchpoint(context_ou integer, item_object asset.copy, user_object actor.usr, renewal boolean) |
| 16:50 |
berick |
think you can also grep for 'circulator: circ policy test found matchpoint' (at INFO) in the logs |
| 16:50 |
Bmagic |
or rather this one action.find_circ_matrix_matchpoint( context_ou integer, match_item bigint, match_user integer, renewal boolean) |
| 16:50 |
Dyrcona |
I was about to say I think it is logged at a different than normal log level setting. |
| 16:51 |
Dyrcona |
But, I'm taking off, so good luck! |
| 17:26 |
Bmagic |
it's not a "real" solution I don't think |
| 17:26 |
Bmagic |
if it makes it a little better though, might as well |
| 17:27 |
berick |
right, it's a back-stop |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:54 |
|
khuckins__ joined #evergreen |
| 22:01 |
|
roycroft joined #evergreen |
| 22:03 |
|
Bmagic joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 08:01 |
|
kmlussier joined #evergreen |
| 08:07 |
|
rlefaive_ joined #evergreen |
| 08:20 |
csharp |
in this case it's the entire directory - when working from the 3.0.rc tarball it was the single file |
| 08:21 |
csharp |
@monologue |
| 08:21 |
pinesol_green |
csharp: Your current monologue is at least 9 lines long. |
| 08:25 |
csharp |
so manually copying build, then manually creating /openils/var/web/js/ui/default/common/build/js (common didn't exist either) and copying jquery.min.js over got everything working |
| 08:26 |
csharp |
either I'm reading wrong or something is borked |
| 08:33 |
|
bos20k joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:39 |
csharp |
same behavior with another xenial test server\ |
| 08:44 |
* csharp |
files bug 1721015 |
| 08:44 |
pinesol_green |
Launchpad bug 1721015 in Evergreen ""grunt all" step not installing angular/dependencies" [Undecided,New] https://launchpad.net/bugs/1721015 |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
yboston joined #evergreen |
| 09:57 |
Dyrcona |
And, if you install from a tarball, as csharp points out, you can skip those steps as they should be done as part of the process in making the tarball. |
| 09:57 |
Dyrcona |
Just for the sake of clarity in the logs. ;) |
| 10:00 |
|
dbwells joined #evergreen |
| 10:34 |
csharp |
Dyrcona: thanks for the confirmation |
| 10:35 |
csharp |
I was confused because the karma tests shouldn't work at that point, right? |
| 10:35 |
Dyrcona |
I think they would still work since they only look at what you have locally. |
| 10:35 |
csharp |
ah - ok |
| 10:35 |
Dyrcona |
The things just wouldn't be installed unless you ran make install again. |
| 17:35 |
gmcharlt |
demo.evergreencatalog.com is now running 3.0.0 |
| 17:46 |
bshum |
gmcharlt++ |
| 17:59 |
|
jonadab joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
|
remingtron joined #evergreen |
| 19:04 |
|
b_bonner left #evergreen |
| 20:05 |
|
rlefaive joined #evergreen |
| 01:08 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Juvenile-to-adult script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=717bb89> |
| 01:24 |
|
abowling joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
JBoyer joined #evergreen |
| 09:57 |
csharp |
gonna try on a stock machine, manually building via instructions |
| 09:57 |
csharp |
but our debs/config scripts don't touch JS at this point |
| 09:59 |
gmcharlt |
csharp: yeah - and they shouldn't have to, at least in the case of using a release tarball |
| 10:00 |
csharp |
yeah, this is built from the tarball |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:09 |
csharp |
leaving that alone for now - manually copying the angular-sanitize.min.* files solved the immediate problem - I'll test and report back later this afternoon |
| 10:26 |
|
mmorgan joined #evergreen |
| 10:33 |
|
collum joined #evergreen |
| 10:44 |
Dyrcona |
csharp: I build a fresh master vm yesterday and had no problems. |
| 11:22 |
gmcharlt |
hmm, I've gone ahead and expanded the tarball |
| 11:22 |
gmcharlt |
and yeah, no angular-sanitze* in Evergreen-ILS-3.0.rc/Open-ILS/web/js/ui/default/staff/build/js |
| 11:23 |
gmcharlt |
dbwells: out of curiosity, what platform did you build on? |
| 11:24 |
dbwells |
gmcharlt: our main dev box is still on wheezy |
| 11:25 |
|
mdriscoll joined #evergreen |
| 12:08 |
dbwells |
csharp++ # testing the RC and finding a problem I caused |
| 12:09 |
|
sandbergja joined #evergreen |
| 12:09 |
dbwells |
csharp: It appears that I have a too-old npm version which led to this bad build. |
| 12:11 |
dbwells |
Should be simple to correct, but also hoping to find time to actually understand the issue (I've been coasting with my understanding of some of this). |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:23 |
|
khuckins__ joined #evergreen |
| 12:45 |
csharp |
dbwells: oh - cool |
| 16:25 |
kmlussier |
I won't be here long. :) |
| 16:32 |
|
khuckins joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:37 |
|
Dyrcona joined #evergreen |
| 19:50 |
|
jonadab joined #evergreen |
| 21:14 |
gmcharlt |
https://evergreen-ils.org/evergreen-development-update-16-on-the-eve-of-release/ |
| 03:59 |
|
acautley joined #evergreen |
| 04:59 |
|
acautley joined #evergreen |
| 05:59 |
|
acautley joined #evergreen |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
acautley joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
Dyrcona joined #evergreen |
| 07:52 |
Dyrcona |
heh |
| 08:00 |
|
acautley joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 08:20 |
kmlussier |
lol - a follow-up to my question about the staff client library timeout setting. It appears that this setting is consulted for web client timeouts. |
| 08:21 |
kmlussier |
I had set it to 10 seconds the other day when I was testing it, and was just cursing at the web client this morning because it kept logging me out. |
| 08:22 |
kmlussier |
I'm not sure why it didn't work in my earlier testing, though. Could it be a browser issue? I tested it in Firefox, but was using Chrome this morning when it started working. |
| 08:23 |
kmlussier |
No, it's working in Firefox now too. |
| 08:34 |
Dyrcona |
Could be a cache issue. |
| 08:45 |
kmlussier |
@marc 130 |
| 08:45 |
pinesol_green |
kmlussier: A uniform title used as a main entry in a bibliographic record. [a,d,f,g,h,k,l,m,n,o,p,r,s,t,6,8] |
| 09:20 |
pinesol_green |
Launchpad bug 1720345 in Evergreen "Cannot create copy tags" [Medium,Confirmed] https://launchpad.net/bugs/1720345 |
| 09:20 |
kmlussier |
gmcharlt: Thanks! If it looks good, is it something that can be merged or do I need to wait until after .0 is out? |
| 09:21 |
gmcharlt |
it's enough of a regression that I've targetted it for 3.0.0 |
| 09:21 |
kmlussier |
gmcharlt: OK, I'll test it now. |
| 09:35 |
|
kmlussier joined #evergreen |
| 09:46 |
pinesol_green |
[evergreen|Galen Charlton] LP#1720345: ensure egEditFmRecord's customFieldTemplates is optional - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f23400> |
| 09:51 |
kmlussier |
gmcharlt++ |
| 16:34 |
kmlussier |
@hate inconsistent bugs |
| 16:34 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates inconsistent bugs. |
| 16:42 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Adding some use cases to MARC Batch Edit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=24c896d> |
| 16:57 |
kmlussier |
Before I leave for the day, I'm going to leave a question about offline circ. When I tested offline circ, I always tested it in an environment where I lost Internet. |
| 16:58 |
kmlussier |
But I never tested the scenario where people need to use offline because the system is down. |
| 16:58 |
kmlussier |
I've noticed that when I bring my VMs down, the staff login page shows the menu bar, but, otherwise, is white. How will staff get to offline circ in those cases when the system is down? |
| 16:59 |
* kmlussier |
now needs to run but wanted to post the question before forgetting about it again. |
| 17:00 |
|
acautley joined #evergreen |
| 17:57 |
|
abowling left #evergreen |
| 18:00 |
|
acautley joined #evergreen |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:00 |
|
acautley joined #evergreen |
| 20:00 |
|
acautley joined #evergreen |
| 21:00 |
|
acautley joined #evergreen |
| 02:25 |
|
gsams joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:04 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:06 |
|
collum joined #evergreen |
| 15:20 |
berick |
csharp: can you paste a few context lines? |
| 15:20 |
berick |
from the source file |
| 15:20 |
berick |
not seeing what I would expect to see at that line in master |
| 15:20 |
Dyrcona |
csharp: PhantomJS is used by the karma unit tests. |
| 15:21 |
csharp |
berick: which is the source file? sorry - I'm truly at a loss :-/ |
| 15:21 |
* csharp |
is also sick, so brain is not 100% |
| 15:21 |
berick |
/home/opensrf/pines/Open-ILS/web/js/ui/default/staff/circ/patron/app.js |
| 15:47 |
kmlussier |
@hates |
| 15:47 |
pinesol_green |
kmlussier hates Launchpad search; Internet Explorer; snow; scheduling meetings; Starbucks; negative balances; undrinkable coffee; winter; blizzards; spam; dojo interfaces; Windows line endings; peanut M&Ms; bad technology days; authorities; pollen; comcast; and comcast even more |
| 15:53 |
csharp |
@hates |
| 15:53 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (2 more messages) |
| 15:53 |
csharp |
@more |
| 15:53 |
pinesol_green |
csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; and (1 more message) |
| 15:53 |
csharp |
@more |
| 17:33 |
|
b_bonner left #evergreen |
| 17:43 |
|
Jillianne joined #evergreen |
| 17:59 |
|
acautley joined #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
acautley joined #evergreen |
| 19:59 |
|
acautley joined #evergreen |
| 21:00 |
|
acautley joined #evergreen |
