02:55 |
|
Jillianne joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
04:52 |
|
gsams_ joined #evergreen |
04:54 |
|
BigRig joined #evergreen |
07:12 |
|
agoben joined #evergreen |
08:28 |
csharp |
also Bmagic ^^ |
08:28 |
csharp |
Bmagic: that could explain your crazy cstore issue |
08:29 |
|
jvwoolf1 joined #evergreen |
08:31 |
Dyrcona |
csharp: Looks good to me. I'll let Bmagic test it, since he's run into it. |
08:31 |
Dyrcona |
Anyway, I think my upgrade script issue is gonna set my testing back a day. I'll have to do a new restore, and that takes about 6 hours on this server. |
08:32 |
Dyrcona |
Yeah. The query returns only 1 row on a non-botched database. |
08:38 |
|
mmorgan joined #evergreen |
08:38 |
Dyrcona |
bleh. |
08:42 |
jeff |
but wait, it doesn't fail when you're using pg_restore to create the db instead of creating it first? |
08:43 |
Dyrcona |
jeff: When I restore -c -C -d postgres so that the db is restored with the name evergreen, it works. |
08:43 |
Dyrcona |
When I create an empty database and restore with just -d dbname it fails. |
08:43 |
jeff |
okay. what version of evergreen is the database at restore time? |
08:44 |
jeff |
i'm curious to do some more testing myself later. |
08:44 |
Dyrcona |
Pg 9.2 restored to a Pg 9.5 db server. |
08:44 |
Dyrcona |
Oh sorry, Evergreen: 2.10.7 |
08:44 |
jeff |
using pg_dump 9.2 and pg_restore 9.5? |
08:48 |
Dyrcona |
The database name is evergreen. |
08:48 |
jeff |
(relevant when using -c -C) |
08:49 |
Dyrcona |
And, I'm set back a day..... |
08:50 |
Dyrcona |
I also specifically want my data from last week for testing purposes. I'm going to test URI deletes with the branch on Lp 1482757, but that's not particularly relevant. :) |
08:50 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
08:50 |
jeff |
bug 1671150 -- looks like i need to make a working branch. |
08:50 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 - Assigned to Jeff Godin (jgodin) |
09:50 |
JBoyer |
Unless we make un-deletion more involved (a full reingest, possibly more) or make it impossible without poking around in the database manually they should probably stick around. |
09:50 |
mmorgan |
Dyrcona: In my experience, once added, asset.uri entries don't go away. Part of lp 1482757 is meant to address that bit. |
09:50 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
09:50 |
Dyrcona |
Right. I was going to test some of that, but I have a delay because of pg_restore issues. |
09:51 |
Dyrcona |
I'm just trying to do some cleanup in production. |
09:52 |
jeff |
in terms of pgcrypto, it looks like we use crypt() in actor.set_passwd / actor.verify_passwd and gen_salt() in actor.create_salt |
09:53 |
mmorgan |
Oh, I get it. So the deleted records still have the 856, imo, the asset.uri should probably remain. |
10:14 |
Dyrcona |
I'm going through the list anyway in case some are not deleted. |
10:14 |
Dyrcona |
Mostly romance novels from Freading. |
10:16 |
Dyrcona |
and mysteries. |
10:20 |
Bmagic |
csharp: I'll test it and get back to you. I'm not positive that we had that exact problem. |
10:32 |
|
kmlussier joined #evergreen |
10:37 |
csharp |
Bmagic: I'm not sure it's our *only* problem :-/ |
10:38 |
csharp |
but it happened last night and I could very easily track the cause in the logs |
14:04 |
|
khuckins_ joined #evergreen |
14:09 |
jeffdavis |
jeff: you mentioned in the past that you have a PatronAPI shim - is that something you'd be willing to share? |
14:11 |
|
jihpringle_ joined #evergreen |
14:14 |
jeff |
yes. |
14:15 |
jeff |
many of the local patron tests for eligibility are expressed in perl code, but i expect that i can make them commented examples and throw it up on github. |
14:17 |
jeff |
we use it as a true/false test -- we are not returning patron data such as name or expiration date or birth date, or even money owed. |
14:18 |
jeff |
this doesn't mean that it can't do those things, just that we intentionally didn't. |
14:18 |
jeffdavis |
I'm hoping to get some time this summer to make that an option with EG's SIP server too. |
14:19 |
jeff |
i'm looking now to see if we're testing password or just using the library card. |
14:24 |
jeff |
not checking password (because we did not want patrons to enter their library password into a vendor app / site) |
14:25 |
jeff |
it could be added, but i'm okay with it not being there. :-) |
14:34 |
jeffdavis |
That would likely be good for Sitka's immediate use case (we've had a patron auth request from another vendor and I'm trying to steer away from SIP for that). |
14:38 |
gsams |
https://www.humblebundle.com/books/linux-book-bundle |
15:10 |
pinesol_green |
[evergreen|Galen Charlton] LP#1694497: fix record links on 2nd+ page of grouped results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc9b7ea> |
15:38 |
|
remingtron joined #evergreen |
15:38 |
|
dbwells joined #evergreen |
16:20 |
|
Jillianne joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:33 |
kmlussier |
Do we know what needs to be done to fix the tests? |
16:36 |
jeff |
did they start breaking on the 28th? |
16:36 |
* jeff |
looks |
16:36 |
jeff |
29th |
16:36 |
Dyrcona |
Looks like apt-get update/upgrade needs to be run or someone broke packages on the Debian side. |
16:40 |
jeff |
on May 28, the libdbd-pg-perl package in the postgresql PGDG apt repository was updated: https://www.postgresql.org/message-id/E1dEuUN-0000Q0-Gy%40atalia.postgresql.org |
16:41 |
jeff |
for Wheezy, it requires the latest perl package, which is not present on the test system. |
16:41 |
jeff |
so yeah, either someone needs to manually apt-get update && apt-get dist-upgrade, or fix whatever automated process is expected to do that which isn't. :-) |
16:42 |
Dyrcona |
I don't think I have access. If I do, I never used it. |
16:42 |
jeff |
i may. checking. |
16:49 |
jeff |
checked. |
17:04 |
jeff |
oh wow, and we woke phasefx from a 6+day slumber, to boot. |
17:06 |
|
mmorgan left #evergreen |
17:06 |
phasefx |
it doesn't |
17:10 |
jeff |
current output of http://testing.evergreen-ils.org/~live/test.4.html shows it does... |
17:10 |
jeff |
but that the version of perl it installed is still one revision down. |
17:10 |
jeff |
hrm. |
17:11 |
phasefx |
in build_essentials it's doing apt-get update && apt-get -yq dist-upgrade ... skips the upgrade; would that make a difference? |
17:12 |
jeff |
i'm missing the "skips the upgrade" part of your statement. |
17:12 |
Dyrcona |
dist-upgrade does an upgrade. |
17:21 |
jeff |
phasefx_: in this case, it may simply be a case of the VM not having the security repo enabled as an apt source. |
17:21 |
Dyrcona |
ok |
17:21 |
jeff |
phasefx_: i don't see security.debian.org in the output of apt-get update |
17:21 |
phasefx |
yeah, it simply has: http://testing.evergreen-ils.org/~live/test.4.html |
17:21 |
phasefx |
cut/paste across desktops, bleh :) |
17:22 |
phasefx |
wheezy main contrib |
17:22 |
jeff |
yeah. that's the issue. |
17:22 |
phasefx |
jeff++ |
17:23 |
jeff |
it broke after the new PGDG package update started requiring the latest perl package for wheezy, which is only available from security.debian.org |
19:28 |
Freddy_Enrique |
but how do I Lad the sample data? |
19:29 |
Freddy_Enrique |
Load* |
19:29 |
Freddy_Enrique |
Its in the instructions, but I wasn't able to figure it out |
19:30 |
csharp |
Freddy_Enrique: two ways: 1) add --load-all-sample during the eg_db_config.pl step 2) run psql on Open-ILS/tests/datasets/sql/load_all.sql |
19:34 |
Freddy_Enrique |
Let see.... there were 4 step in the eg_db_config. this could be a 5 step. Should it look like this? |
19:34 |
Freddy_Enrique |
https://snag.gy/dqlPTv.jpg |
19:35 |
csharp |
Freddy_Enrique: that works, yeah |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
05:49 |
|
b_bonner joined #evergreen |
05:49 |
|
mnsri_away joined #evergreen |
05:50 |
|
ericar joined #evergreen |
10:00 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312824: follow-up to fix whitespace - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7d2ca7> |
10:03 |
|
rlefaive_ joined #evergreen |
10:03 |
Freddy_Enrique |
Now to evergreen itself. Yesterday I finally entered the database via client and there are too many things to watch. Any tips where I should begin? |
10:05 |
kmlussier |
Freddy_Enrique: Did you load the Concerto test dataset into the database? |
10:07 |
kmlussier |
Freddy_Enrique: If not, you should probably start by cataloging records. It's difficult to do anything without some bibliographic records in the system. |
10:07 |
Freddy_Enrique |
Concerto test dataset? Not so sure what you mean. |
10:07 |
Freddy_Enrique |
So, first I should catalog some records |
10:08 |
csharp |
Bmagic: any further issues for A/T stuff? our utility server choked (apparently on "too many events") over the weekend killing pretty much everything else |
10:10 |
kmlussier |
Freddy_Enrique: It's a set of sample bibliographic and patron records that can be loaded on to a test system. http://evergreen-ils.org/documentation/install/README_2_12.html#_loading_sample_data |
10:11 |
Freddy_Enrique |
OMG |
10:12 |
Freddy_Enrique |
can I do this step after I started Evergreen? |
10:13 |
csharp |
(doesn't appear to have been cstore process proliferation causing our issue, btw) |
10:13 |
Bmagic |
csharp: Thanks for reminding me, I am going to run some queries and find out! |
10:15 |
Bmagic |
csharp: no more issues! |
10:15 |
csharp |
Bmagic: awesome |
10:15 |
berick |
Freddy_Enrique: yes, you should be able to add the concerto data while EG is running. |
10:16 |
berick |
Freddy_Enrique: something like: cd Open-ILS/tests/datasets/sql && psql -U evergreen -f load_all.sql |
10:16 |
Dyrcona |
Freddy_Enrique: I'd still shut it down, load the data, and then start Evergreen again. |
10:16 |
Bmagic |
Breaking them up helped, but I also disabled two "long running" offenders. Custom triggers that I have been playing with LP1496522 |
10:17 |
Freddy_Enrique |
Terrific! Thanks Berick and D. |
12:41 |
kmlussier |
I'm not having any trouble with the grouped ones. |
12:43 |
|
rlefaive joined #evergreen |
12:45 |
* mmorgan |
is not seeing a problem with the grouped records either, just the ungrouped ones. |
12:45 |
kmlussier |
mmorgan and I are probably testing on the same server. :) |
12:45 |
mmorgan |
maybe! Or two very similar servers :) |
12:49 |
jeffdavis |
I can't replicate on 2.12.1. |
12:57 |
mmorgan |
I am seeing the problem on a 2.12.0 server with concerto. The grouped records work, the ungrouped ones take me to the my account login page. |
13:21 |
kmlussier |
Bmagic: Not that I know of. dbwells just mentioned it at 12:28:01 |
13:23 |
* kmlussier |
needs to disappear for a while. |
13:23 |
|
jwoodard joined #evergreen |
13:32 |
dbwells |
kmlussier, mmorgan, JBoyer, Bmagic: thanks for testing and confirming. For the record, we are also seeing that metarecord/grouped results do link correctly, as a few of you noted. |
13:33 |
Bmagic |
dbwells: bug 1694497 |
13:33 |
pinesol_green |
Launchpad bug 1694497 in Evergreen "Grouped formats page 2+ results omit the record number in hyperlink" [Undecided,New] https://launchpad.net/bugs/1694497 |
13:34 |
JBoyer |
Yeah, that's my mistake. groups do work because they're links to new searches basically. When I saw the URL point to /results/?query... I assumed they were broken, just like records. |
13:34 |
JBoyer |
Assumptions and so on... |
13:35 |
dbwells |
jeffdavis: you mentioned it was working for you on 2.12.1. Do you have a link to the catalog where you are testing that? |
13:38 |
dbwells |
Bmagic++ # thanks for the LP bug |
13:40 |
JBoyer |
Oh, another wrinkle. I have a result on page 1 that has a busted /record/?blahblah URL. Maybe that record will show us something. |
13:41 |
jeffdavis |
dbwells: https://bna.bc.catalogue.libraries.coop/eg/opac/results?query=charles%20dickens;qtype=keyword;locg=24;detail_record_view=1;modifier=metabib;page=1 |
13:42 |
jeffdavis |
we have lots of TPAC customizations there which may be why we're not seeing it |
13:47 |
gmcharlt |
yep |
13:47 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "potential fix" (16 lines) at http://paste.evergreen-ils.org/165 |
13:51 |
Bmagic |
gmcharlt++ |
13:58 |
dbwells |
gmcharlt++ # that fixed it |
14:00 |
dbwells |
In testing, noticed another "page 2" bug. The "Return to Grouped Search Results" always takes you back to page one of your search, even if the result you clicked on was on a later page. This isn't what I would expect. I tested with and without gmcharlt's patch, and this doesn't appear related either way. |
14:03 |
Bmagic |
dbwells: I believe that is a pre-existing bug, reported a long time ago |
14:05 |
dbwells |
Bmagic: Thanks, good to know. It is certainly not as serious as the other. |
14:05 |
Bmagic |
I'm hunting for it now |
16:20 |
Dyrcona |
I know there's nothing in it, but a config.upgrade_log update, but it looks like the 2.12.1 to 2.12.2 upgrade script did not make it into origin/rel_2_12. |
16:22 |
Dyrcona |
Or, wait. Maybe there should be something in it. |
16:25 |
Dyrcona |
Yeah. There should be something in it and it is missing from the rel_2_12 branch. |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:44 |
gmcharlt |
Dyrcona: thanks for catching that; I've corrected this |
16:45 |
Dyrcona |
gmcharlt++ |
16:45 |
Dyrcona |
I was going to open a Lp bug later. |
16:45 |
Dyrcona |
I noticed because I have a test branch based on rel_2_12 and I was looking for the upgrade script to run. :) |
16:46 |
gmcharlt |
indeed |
16:46 |
gmcharlt |
also, that one's not a no-op |
16:47 |
|
Jillianne joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
09:48 |
|
littlet joined #evergreen |
13:53 |
|
FreddyEnrique joined #evergreen |
13:54 |
FreddyEnrique |
Hi everyone |
14:05 |
jonadab |
It's built on jabber. |
14:06 |
jonadab |
So yeah, I think you can continue to proceed for now. |
14:06 |
FreddyEnrique |
Ok, I'm proceeding |
14:06 |
jonadab |
If you can get to the point where the srfsh math test passes (you send an add request and get back the answer), then OpenSRF is installed. |
14:06 |
jonadab |
At that point you can go on to installing OpenILS itself. |
14:07 |
jonadab |
and/or other dependencies like Postgres, depending what order you're doing things in. |
16:10 |
|
rlefaive joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
18:30 |
FreddyEnrique |
guys |
18:30 |
FreddyEnrique |
I was able to do the Testing the default OpenSRF services |
18:30 |
FreddyEnrique |
I suppose evething is alright |
18:31 |
FreddyEnrique |
still....the web dir doesnt appear... |
18:32 |
FreddyEnrique |
Or does it mean I hace to continue the evergreen installation? |
19:28 |
jonadab |
I believe the web dir stuff comes from OpenILS itself, _not_ from OpenSRF. |
19:32 |
FreddyEnrique |
btw |
19:32 |
FreddyEnrique |
the apache installation is before of after the the opensrf installation? |
19:41 |
jonadab |
Either, I think. |
19:41 |
jonadab |
But probably best install Apache before OpenILS. |
19:42 |
jonadab |
Although, the prerequisites step probably does automatically, come to think. |
19:42 |
jonadab |
Not sure if the prerequisites also picks up Postgres. |
19:42 |
jonadab |
It might. |
19:46 |
jonadab |
If you follow the instructions in the order in which they're written, it should all work. That isn't the only possible order or even necessarily the fastest order, but it's an order that works. |
19:47 |
jonadab |
Some of the guys at the conference were saying that they like to change the order in some ways, e.g., I remember they said they create the opensrf user first and download everything _as_ that user, so then they don't have to recursively chown it all, which saves maybe a minute or so. |
19:48 |
jonadab |
That sort of optimization is probably more relevant if you're installing a lot of times (e.g., for testing changes) and are familiar with the process and can move through the steps quickly. |
19:49 |
jonadab |
BTW, this channel tends to be pretty dead on the weekends; I think a lot of the Evergreen folks don't irc at home. |
19:49 |
jonadab |
Which is weird to me, I have IRC up _more_ of the time at home than at work, I think. |
19:49 |
jonadab |
But that may be partly because it was the NetHack community that pulled me into IRC, and then I found #evergreen later. |
19:53 |
FreddyEnrique |
I see.... i really appreciate your help, even though its family time |
19:53 |
FreddyEnrique |
but since I'm still struggling in the university |
19:53 |
jonadab |
Not a problem for me. |
21:21 |
FreddyEnrique |
chown -R opensrf:opensrf /openils |
21:22 |
FreddyEnrique |
nano /etc/hosts |
21:22 |
FreddyEnrique |
after editing that file |
21:22 |
bshum |
So were you able to get to the end of the OpenSRF instructions where you do the math test? |
21:22 |
bshum |
And that was successful? |
21:22 |
FreddyEnrique |
well...actually yes |
21:23 |
bshum |
Okay |
21:23 |
FreddyEnrique |
the errors comes when I`m in the server installation |
21:29 |
FreddyEnrique |
make: *** [all-recursive] Error 1 |
21:30 |
bshum |
And seems to explain why nothing seems to be getting installed for Evergreen |
21:31 |
FreddyEnrique |
maybe is the instructions? |
21:31 |
bshum |
You ran make -f Open-ILS/src/extras/Makefile.install ubuntu-trusty command as root right? |
21:31 |
bshum |
While inside the Evergreen-ILS-2.12.2 directory? |
21:31 |
bshum |
In what seems to be your home folder |
21:32 |
bshum |
I don't think it's the instructions; they're pretty well-tested these days. |
21:32 |
FreddyEnrique |
I wish I could uppload a screenshot to describe it. But yeah. |
21:33 |
FreddyEnrique |
I change to root |
21:33 |
bshum |
I find https://snag.gy/ pretty useful for sharing screenshots |
04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
rjackson_isl joined #evergreen |
07:40 |
|
rlefaive joined #evergreen |
07:59 |
|
kmlussier joined #evergreen |
09:59 |
kmlussier |
JBoyer++ # Sleuthing for bug 1693560 |
09:59 |
pinesol_green |
Launchpad bug 1693560 in Evergreen "UPDATE_MARC Permission Error in Search Catalog" [Undecided,New] https://launchpad.net/bugs/1693560 |
10:00 |
kmlussier |
JBoyer: You can delete those local storage values by highlighting it, then clicking the X that appears to the left of the Filter box. |
10:01 |
JBoyer |
As soon as someone said "it always happens on this testing account" and it didn't happen on my browser it was really easy. |
10:01 |
* kmlussier |
can't help with the actual bug, but has had plenty of experience deleting those local storage keys. |
10:01 |
JBoyer |
Oh, hey, that's much simpler, heh. |
10:01 |
Dyrcona |
Sure, just as I connect to the training the server, the VPN closes on me. |
10:06 |
csharp |
heh - I haven't tried that |
10:06 |
Dyrcona |
Building your own ssh tunnels on the command line and configuring those as servers is more reliable. |
10:06 |
csharp |
we have a vpn |
10:06 |
* kmlussier |
tests bshum's tip with lp 922128 |
10:06 |
pinesol_green |
Launchpad bug 922128 in Evergreen "Scrollbars non sunt multiplicanda praeter necessitatem" [Undecided,Triaged] https://launchpad.net/bugs/922128 - Assigned to Ben Shum (bshum) |
10:06 |
Dyrcona |
I have a vpn, but still need to tunnel the production servers. |
10:06 |
csharp |
sylvar++ |
10:21 |
JBoyer |
berick++ |
10:22 |
Dyrcona |
dbwells++ |
10:22 |
csharp |
debug must be on? or no process to automate truncating/deletion? |
10:22 |
Dyrcona |
I left a test vm running over the weekend with everything being logged. Came in on Monday to find the 60GB space for it full, and no one had touched it. |
10:23 |
Dyrcona |
/home and /var are pretty close to full, too. |
10:24 |
* kmlussier |
just realized that we no longer have holds, transit, or other images on slips in the web client. :( |
10:25 |
csharp |
frog time! |
10:32 |
Dyrcona |
I think I should adjust my postgresql logging settings downwards and stop sending them to syslog on training. NOTE: I did not set this up originally. |
10:32 |
JBoyer |
Dyrcona, it's great so long as you're also using the recommended syslog config, but yes, it should not be dumped in messages. |
10:34 |
Dyrcona |
JBoyer: The default configs now send everything to syslogs, IIRC. I think we should set the defaults back to /openils/var/log and /var/log/apache2 with notes on setting up a syslog server for bigger sites. |
10:34 |
Dyrcona |
The defaults are not ideal for standalone installations and/or test vms. |
10:34 |
Dyrcona |
I know... I know... I should LP it. |
10:35 |
JBoyer |
Dyrcona, I know, but we also include some rsyslog configs that pull everything out of messages and puts them in /var/log/evergreen/* which is pretty handy. |
10:35 |
Dyrcona |
In the stock configs or you do that in Indiana? |
11:21 |
|
_bott_ joined #evergreen |
11:21 |
Dyrcona |
I have Pg 9.5 on Debian, installed from apt.postgresql.org, so I guess the man pages are just out of date. |
11:26 |
csharp |
so who is running 9.5+ in production? any issues of note? |
11:27 |
Dyrcona |
Not in production, yet, but training and all of my test dbs are on 9.5. |
11:28 |
Dyrcona |
If you install 0979 and 0982, then everything seems hunky dory. |
11:28 |
csharp |
we're upgrading over Labor Day and current plan is to stay on 9.4 - we're shy of being pioneers atm :-) |
11:28 |
Dyrcona |
We plan to upgrade to 9.5 when we get a new db server this summer, probably in July. |
11:29 |
Dyrcona |
I still have to actually spec. out the hardware. |
11:29 |
Dyrcona |
I've been hitting 9.5 pretty hard, running the tests, cron jobs, all kinds of stuff. |
11:29 |
csharp |
cool |
11:32 |
berick |
been running 9.6 on test vm's for a bit now. (also with 0979 and 0982). |
11:34 |
Dyrcona |
Going well, I take it? |
11:34 |
berick |
yeah, so far so good. |
11:34 |
bshum |
http://irc.evergreen-ils.org/evergreen/2017-01-26 |
11:35 |
csharp |
bshum: yeah just on concerto-sized vms :-) |
11:36 |
bshum |
csharp: Eh, Labor Day is still awhile from now... You've got plenty of time to acquire that adventurous spirit :) |
11:37 |
csharp |
true dat |
11:38 |
Dyrcona |
I've been testing with copies of production data and with concerto. |
11:38 |
Dyrcona |
FWIW. |
11:39 |
Dyrcona |
Maybe I'll upgrade my test db server, dumbo, to 9.6. |
11:41 |
Bmagic |
anyone struggle to keep enough cstore drones for action triggers in the middle of the night? |
11:41 |
bshum |
How many did you set up with? |
11:41 |
Bmagic |
I'm at 85 |
12:10 |
Dyrcona |
hmm. trying to get the id from actor.org_unit_descendants for a bunch of ous at once and not having much luck. I swear that I've done this before, though. |
12:10 |
Dyrcona |
After lunch.... |
12:15 |
|
maryj joined #evergreen |
12:16 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
12:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1672775 Action/Trigger purge PGTAP tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71817cb> |
12:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1672775 Action/Trigger CRON-able purge script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea536c7> |
12:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1672775 Action/Trigger retention interval release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36567bb> |
12:16 |
pinesol_green |
[evergreen|Galen Charlton] LP#1672775: add purge_at_events.srfsh to example crontab - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ded4c3> |
12:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1672775 Stamping A/T purge SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=510d4fe> |
12:18 |
gmcharlt |
berick++ |
12:22 |
JBoyer |
berick++ |
12:23 |
JBoyer |
Oh, and I have a question that berick or gmcharlt may have a quick answer to. I want to base the destination of a link on the tt2 splash page on the workstation's system level ou ancestor. what in broad strokes do you think is the best way to find that? |
13:57 |
berick |
heh |
13:58 |
Dyrcona |
I notice we're not doing shutdown on the sockets, but close. I wonder if there is any real difference? (Probably not, but I'll look.) |
13:59 |
Dyrcona |
shutdown in a signal handler might help.... |
14:05 |
Dyrcona |
Well, I don't see any SIGPIPE errors on my 2.12 development/test vm. |
14:06 |
Dyrcona |
I just truncated the logs on training or I'd look there, too. |
14:06 |
Dyrcona |
I haven't updated to 2.12.2, yet. It is still about 2.12.1. |
14:07 |
|
Jillianne joined #evergreen |
16:22 |
Bmagic |
Dyrcona: We were able to accomplish this for circulate=false, but that is different |
16:25 |
Bmagic |
Dyrcona: The Everything permission will make it work though |
16:26 |
|
jvwoolf joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:31 |
berick |
hear ye, hear ye, the afternoon test bell rings |
16:35 |
kmlussier |
:) |
16:37 |
Dyrcona |
Bmagic: If Everything works, but adding HIGH_LEVEL.....override doesn't, I'd consider that a bug of some kind. |
16:37 |
Bmagic |
yeah, there is something wrong in here somewhere, hard to say what exactly |
18:01 |
csharp |
@who is the spy |
18:01 |
pinesol_green |
StomproJosh is the spy. |
18:23 |
Bmagic |
gnight all |
18:23 |
bshum |
Oooo Stretch got a release date! |
18:25 |
bshum |
June 17. |
18:26 |
bshum |
Guess we'll have some time to test it out before 3.0 |
20:13 |
|
jvwoolf joined #evergreen |
22:20 |
|
genpaku joined #evergreen |
00:33 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fb27b3> |
00:33 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4f578be> |
00:50 |
|
StomproJ joined #evergreen |
04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:06 |
|
StomproJosh joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
07:40 |
|
rlefaive joined #evergreen |
08:40 |
|
jvwoolf joined #evergreen |
08:43 |
|
mmorgan joined #evergreen |
08:59 |
|
_adb joined #evergreen |
09:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1691801 Webstaff grid column move controls - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58579e8> |
09:09 |
pinesol_green |
[evergreen|Josh Stompro] LP1574141 - Allow invalidate for all patrons with the same contact. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c1ac484> |
09:09 |
pinesol_green |
[evergreen|Galen Charlton] LP1574141: minor code tweaks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c6b0d4> |
09:09 |
pinesol_green |
[evergreen|Galen Charlton] LP1574141: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=52b09a6> |
09:11 |
* gmcharlt |
claims 1041 in the name of apple cake recipes everywhere! |
09:17 |
* JBoyer |
is suddenly more interested in whatever 1041 fixes if apple cake is involved. |
09:17 |
gmcharlt |
dbs: if you've got a second, I'd appreciate an eye on my follow-up for bug 1411699 before I merge it |
10:28 |
jeff |
JBoyer: we thankfully don't have that issue, but i do remember KCLS was experimenting a while back with some changes with regard to that interface. |
10:30 |
|
mmorgan1 joined #evergreen |
10:31 |
berick |
JBoyer: just curious, have you loaded the same title in webby? |
10:31 |
jeff |
perhaps we should have some bibs (or serials, though I think in JBoyer's case they're not serial.record_entries) in sample data with many copies for easier testing of such things. |
10:32 |
jeff |
because yes, webby. |
10:32 |
jeff |
i skipped a few thoughts there. |
10:32 |
JBoyer |
berick, yeah, it's fine there because paging is the issue. |
10:32 |
berick |
JBoyer: just the answer i was hoping for |
10:32 |
JBoyer |
And jeff's right, they' |
10:32 |
JBoyer |
re not "serials," just regular old acp. |
10:33 |
JBoyer |
I'd like to be able to tell people "this works, stop using the old thing" but we don't have anything in the way of an intro or training or etc. It's coming, but it's not here yet. |
10:35 |
JBoyer |
jeff, and I'm not sure it makes much difference to include them in the sample data because it's always going to be fast to pull hundreds of items out of a database with under 1000 records total. |
10:38 |
jeff |
well, it wouldn't take the place of testing with real life datasets, but it's potentially useful for getting a feel for interfaces where the number of items is going to make an impact (not just on speed, but potentially other things as well) |
10:38 |
berick |
yeah, i doubt DB speed is the issue there |
10:52 |
dbs |
gmcharlt: I'm focused on a workshop but at one point I had pushed http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/nodojo_acjs (as a WIP) |
11:06 |
|
Jillianne joined #evergreen |
16:29 |
bshum |
oracle-- microsoft-- # just 'cause |
16:30 |
Dyrcona |
sybase-- # for completeness-sake |
16:30 |
Dyrcona |
:P |
16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:31 |
Dyrcona |
Succes! |
16:31 |
Dyrcona |
Or for the English speakers in the audience, "Success!" |
16:31 |
Dyrcona |
:) |
00:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11.5 maintenance release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82dee7d> |
00:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.2 Maintenance release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a8e1007> |
01:16 |
|
Christineb joined #evergreen |
04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:38 |
|
Stone joined #evergreen |
05:39 |
Stone |
Good day. I am new on here. I am here to make enquiries about setting up a library |
05:39 |
Stone |
I need guidlines, sort of |
09:35 |
bos20k |
Dyrcona: good, that's what I was planning to do. |
09:35 |
Dyrcona |
You'll sometimes find multiple upgrades doing more or less the same ingest and its more efficient to do the ingests all at once at the end. |
09:36 |
bshum |
nom, nom, nom |
09:36 |
Dyrcona |
So, on my acq thing: I looked at the event output and nothing jumps out at me. Is there some way I can test this to see where it is blowing up? |
09:37 |
bshum |
Dyrcona: The event that's failing is the push right? But was there anything odd in the POJEDI move? From PO to EDI I mean. That would be a related trigger event. |
09:38 |
bos20k |
Thanks! |
09:38 |
miker |
bos20k: you can either use Dyrcona's script, or generate SQL along the lines of: 1) \o /tmp/reingest.sql 2) select 'select metabib.reingest_record_attributes('||id||'),'||id||';' from biblio.record_entry where not deleted; 3) \i /tmp/reingest.sql |
09:49 |
miker |
Dyrcona: I was talking about a full update with the 'ingest.skip_browse_indexing' enabled, followed by a browse-only reingest |
09:49 |
Dyrcona |
OK, then, that will pick it up. |
09:49 |
miker |
so that the first can be parallelized safely (deadlocks possible on parallel with browse enabled) |
09:50 |
bos20k |
dbwells: Maybe. At the moment we're not running a normal 2.9. We're running what bshum left. I figured it might be a good way to do it, do them individually. I have just started testing them and have already had to modify them a bit due to nonstandard stuff in our database. |
09:50 |
Dyrcona |
dbwells: If you're past the version where the 2.9 to 2.10 upgrade script was made it can be difficult to use the packaged upgrade scripts. |
09:50 |
Dyrcona |
I make my own, but I know how. |
09:51 |
bshum |
Right, it'd be master as of around when rel_2_9 got branched, but not specifically. |
10:08 |
dbwells |
bshum: well, you are always good company :) |
10:08 |
berick |
Dyrcona: i can rebase bug 1373690 if it'll help |
10:08 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Wishlist,New] https://launchpad.net/bugs/1373690 - Assigned to Jason Stephenson (jstephenson) |
10:08 |
Dyrcona |
berick: It might. If you scroll up you'll see why I want to test it. |
10:09 |
Dyrcona |
I'm stuck with an edi pusher error and so far haven't figured out the exact cause. |
10:13 |
berick |
yeah, that can be a real pain. one thing to verify: select is_json(jedi) from acq.edi_message where id = .. |
10:13 |
* dbs |
waves |
10:13 |
jeff |
dbs: greetings! |
10:16 |
berick |
haha, I finally found where I fixed an egPcrud error in a working branch. and I of course fixed it a different way (mixed w/ other fixes). Dyrcona, gimme a minute to fix the branch before you test anything, plz. |
10:16 |
Dyrcona |
Too many blue icons... I often end up in a different application from the one that I wanted. |
10:16 |
Dyrcona |
berick: NP. I don't think I'm getting to it today at this rate. |
10:19 |
Dyrcona |
berick: No acq.edi_message is generated for this purchase order. I think that is the step that's blowing up. |
10:22 |
berick |
Dyrcona: ah |
10:24 |
berick |
Dyrcona: the is_json test should be done on the event_output.data in that case |
10:26 |
Dyrcona |
It says 'f' but just eyeballing it earlier, I didn't see the problem. Would perl2json report the exact issue, do you think? |
10:26 |
Dyrcona |
Err, json2perl rather.... |
10:28 |
Dyrcona |
All right, I'll dump the output data and try parsing it with a small script. |
11:49 |
JBoyer |
Hah, though you could use them sort of like the reverse of a custom ringtone based on the job you were about to perform. Simple admin tasks = :D, catalog cleanup = :/, and working a public desk = D: |
11:51 |
Dyrcona |
jeff: apropos one-off scripts, I wrote one to check validity of json that might prove useful later. |
11:52 |
Dyrcona |
It has 5 use statements and 3 lines of actual code. :) |
11:52 |
JBoyer |
jeff, there's a fun test of our unicode handling; can you successfully use a location name of 🔥🆕📚 and have everything appear correctly |
11:55 |
csharp |
JBoyer++ |
11:56 |
JBoyer |
Bummer, acpl editor says no. :/ |
11:56 |
JBoyer |
To the database! |
14:01 |
|
khuckins__ joined #evergreen |
14:07 |
Dyrcona |
Looks like it is finally fixed. |
15:00 |
Dyrcona |
Ah, he just left. |
15:06 |
Dyrcona |
Anyway, a full ingest as I described earlier had been running for 16 days on a test vm before I just stopped it. |
15:06 |
Dyrcona |
I'm updating the test db server software. |
15:06 |
Stompro |
cesardv++, thanks for working on bug 1098685. |
15:06 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Undecided,Confirmed] https://launchpad.net/bugs/1098685 - Assigned to Cesar V (cesardv) |
15:08 |
cesardv |
Stompro: hi! sure np |
16:16 |
pinesol_green |
[evergreen|Galen Charlton] forward-port 2.12.1-2.12.2 schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02b95ed> |
16:21 |
gmcharlt |
Evergreen-ILS-2.12.2a.tar.gz is now in place and the downlaods page update |
16:21 |
gmcharlt |
d |
16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:31 |
dbs |
re: input type=date, for some stupid reason Firefox on the desktop still falls back to plain text input (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date) |
16:31 |
dbs |
yay releases! |
16:33 |
dbs |
https://bugzilla.mozilla.org/show_bug.cgi?id=825294#c93 summarizes the unfortunate Firefox situation |
03:32 |
|
Anna_ joined #evergreen |
03:33 |
|
Anna_ joined #evergreen |
03:38 |
|
Anna_ joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:03 |
|
rlefaive joined #evergreen |
06:51 |
|
rlefaive joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
14:30 |
Dyrcona |
That's good news. |
14:30 |
kmlussier |
Dyrcona: It will give a useful message and bounce you to the workstation registration page. |
14:31 |
Dyrcona |
OK. I haven't done that for a while, 'cause I've not been using a client on the vm that gets reinstalled the most. |
14:31 |
* phasefx |
is going to have start testing his assumptions more |
14:33 |
Dyrcona |
Yes, always good to retest assumptions from time to time. |
14:33 |
kmlussier |
I would send a reply to the email, but my lost email to the general list was a reply to the same thread. Not that there was anything insightful in that email. Mainly confirming what mmorgan found and asking for more detail. |
14:36 |
Dyrcona |
I have been using the webstaff client for most of my recent testing, though. |
14:49 |
mmorgan |
Dyrcona: What do you use your new uri table and view for? |
14:51 |
Dyrcona |
Removing 856s from bib records. |
14:52 |
Dyrcona |
The table is for vendors and holds some data about them, including two regexes: one to identify their URLs, and the second to get the vendor's record id from the URL. |
15:46 |
|
mmorgan joined #evergreen |
15:48 |
jeff |
we did similar when we were running 2.7 on Jessie. Ansible checked out one branch to do the pre-req install, then checked out a different branch to install Evergreen. :-) |
15:59 |
Bmagic |
2.11 is going away soon enough..... |
16:23 |
berick |
jeff: fyi at the top 2 commits https://github.com/berick/pysip2/commits/master |
16:24 |
berick |
using it to test stunnel->sip connections |
16:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:33 |
jeff |
handy! |
16:33 |
jeff |
and yeah, why not support it in the client instead of needing to use stunnel on both ends. |
16:33 |
jeff |
berick++ |
16:33 |
berick |
exactly, one less step there |
16:33 |
* mmorgan |
always feels like it's time to go home when the afternoon test results are reported. Especially when they're successful. |
16:34 |
jeff |
"quick, leave before something breaks!" |
16:34 |
mmorgan |
Exactly! |
16:36 |
csharp |
berick++ jeff++ |
01:04 |
|
Jillianne joined #evergreen |
01:08 |
|
rlefaive joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:26 |
|
kmlussier joined #evergreen |
07:27 |
kmlussier |
gmcharlt: I made it about half-way through testing bug 1312824 on Wednesday. Do you mind if I assign myself to it again or have you already made progress testing it? |
07:28 |
pinesol_green |
Launchpad bug 1312824 in Evergreen "open-ils.circ.hold.change_title(.specific_holds) APIs cancel previously captured holds at other locations, confusing staff and patrons" [Medium,Confirmed] https://launchpad.net/bugs/1312824 |
07:28 |
|
rlefaive joined #evergreen |
08:02 |
* kmlussier |
just noticed that the Reserves copy status is not set to "is available" by default. Should it be? |
09:25 |
kmlussier |
If I do an Oliver Twist search with metarecord searching turned off, I get pages and pages of results for the Charles Dickens work before I see any other work by that name. When I turn metarecord searching on, the relevance for the Charles Dickens title sinks. |
09:25 |
kmlussier |
I wouldn't expect metarecord searching to have that effect on relevance ranking. |
09:31 |
jeff |
is relevance ranking on metarecord searches done based on the lead/master record in the metarecord set, and is that record of low rank in the non-metarecord search results? |
09:32 |
kmlussier |
jeff: I don't know. I test it to see if it gets a low rank. |
09:33 |
kmlussier |
I'm finding that it happens consistently with all those classic novels where there are lots of critical or other derivative works that share the same title. |
09:36 |
|
maryj joined #evergreen |
09:36 |
* kmlussier |
has wandered far off from what she started working on. |
09:47 |
csharp |
hmm, so my bug from yesterday (bug 1691784) was working off the wrong premise - it's batch volume transfer that rips the bib out from under the acq lineitem |
09:47 |
pinesol_green |
Launchpad bug 1691784 in Evergreen "batch volume transfers need to take acq into account" [Medium,New] https://launchpad.net/bugs/1691784 |
09:47 |
csharp |
(original report assumed that it was a bib merge) |
16:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1678638: technical documentation for qstore - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f87c94c> |
16:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1678638: add text versions the qstore and query_schema docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2d338c3> |
16:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1678638: use new preferred extension for AsciiDoc files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=391d7ed> |
16:13 |
kmlussier |
While testing bug 1690468, I noticed some odd behavior with the exclude electronic resources limiter that is unrelated to the code I'm testing. |
16:13 |
pinesol_green |
Launchpad bug 1690468 in Evergreen 3.0 "Exclude Electronic Resources cannot be un-selected with advanced search filters applied" [Undecided,Confirmed] https://launchpad.net/bugs/1690468 |
16:13 |
kmlussier |
If I go to https://mlnc2.noblenet.org/eg/opac/results?bool=and&qtype=keyword&contains=contains&query=two&bool=and&qtype=title&contains=contains&query=&bool=and&qtype=author&contains=contains&query=&_adv=1&detail_record_view=0&fi%3Aitem_type=m&fi%3Aitem_type=a&fi%3Aitem_lang=eng&locg=2&pubdate=after&date1=1980&date2=&fi%3A-search_format=electronic&sort= |
16:13 |
kmlussier |
I get 2 results |
16:18 |
kmlussier |
You know, I noticed some strange behavior with the pub date filter earlier, but I never nailed it down. I'll follow up on that and file a bug in LP |
16:18 |
kmlussier |
dbwells++ |
16:22 |
|
Jillianne joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:33 |
Dyrcona |
kmlussier: The weirdness with the pub date filter is it uses fixed fields and not what displays in the OPAC. I've seen it before and may or may not have opened a bug. |
16:33 |
* Dyrcona |
disappears in a puff of smoke. |
16:34 |
kmlussier |
hmmm...I don't know that we're talking about the same weirdness. |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:18 |
|
rlefaive joined #evergreen |
06:29 |
|
Callender joined #evergreen |
07:33 |
|
agoben joined #evergreen |
13:01 |
|
hbrennan joined #evergreen |
13:02 |
|
jihpringle joined #evergreen |
13:02 |
miker |
berick: egPromptDialog.open returns an object containing a "result" which is a promise, correct? Just like any other uibModal ... |
13:14 |
jeffdavis |
What would "Forking Error" normally indicate (beyond OpenSRF failing to create a child process)? Just saw that on a test server experiencing an outage, memory seemed adequate and drone counts weren't too high when I checked. |
13:17 |
Dyrcona |
jeffdavis: The user may have exceeded the process limit set by the O/S. This can be configured per user, but the O/S also has an absolute limit that cannot be exceeded. |
13:17 |
Dyrcona |
jeffdavis: Could mean other things, too. |
13:19 |
jeffdavis |
Hmm, total processes seemed ok but maybe I missed something transient. |
13:19 |
* jeffdavis |
travels back in time, sets up monitoring for this test server |
13:19 |
Dyrcona |
:) |
13:20 |
jeffdavis |
unusual_outages_on_test_server_2_days_before_upgrade-- |
13:20 |
Dyrcona |
Modern Linux runs a whole pile of stuff. |
13:27 |
Dyrcona |
I love those. Some day, I plan to learn what all of the numbers in those log entries mean. :) |
13:32 |
csharp |
jeff: I just wanted to have control over who has access to our bibs via z39.50 |
13:32 |
|
yboston joined #evergreen |
13:36 |
Dyrcona |
Anyone else want to test drive hold targeter v2 repairs and additions? I'm sold. |
13:42 |
kmlussier |
Dyrcona: If you think somebody else should test it before it goes in, I can put it on my to-do list for tomorrow. But I'm also comfortable with your ok if you think it's ready to merge. |
13:43 |
Dyrcona |
I think it's OK. I like the soft retarget interval. It does what I expected based on the description. |
13:44 |
Dyrcona |
There was one thing I wanted to look at, but it was a "bug" in the old targeter. |
13:44 |
|
yboston joined #evergreen |
15:04 |
tspindler |
Thanks all, made it just over an hour |
15:04 |
kmlussier |
tspindler++ |
15:05 |
hbrennan |
tspindler: not bad at all! |
15:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1677661 Hold Targeter V2 Repairs & Improvements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3073bcb> |
15:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1677661 Targeter V2 extras release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54dc1aa> |
15:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1677661 Targeter V2 remove unused batch API - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1c2d9c> |
15:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1677661 Hold targeter live test use API, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=238dba9> |
15:10 |
terran_ |
kmlussier: are you going to update the outreach committee page with the text changes? |
15:10 |
kmlussier |
terran_: Yes, I will. |
15:10 |
kmlussier |
But probably not until tomorrow. |
15:43 |
|
rlefaive joined #evergreen |
15:53 |
|
rlefaive joined #evergreen |
16:06 |
|
tspindler left #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:37 |
|
rlefaive joined #evergreen |
16:49 |
|
mmorgan joined #evergreen |
16:56 |
|
khuckins_ joined #evergreen |