| 03:59 |
|
pastebot joined #evergreen |
| 03:59 |
|
dbs joined #evergreen |
| 04:35 |
|
cherri_ joined #evergreen |
| 05:48 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:41 |
|
cherri_ joined #evergreen |
| 07:58 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
eeevil joined #evergreen |
| 13:18 |
bshum |
dbs: Well I looked up 100 on the site too |
| 13:19 |
bshum |
Okay, cool :) |
| 13:19 |
dbs |
yeah, sounds like our USMARC out-of-the-box defaults might not suit a non-USMARC situation |
| 13:19 |
bshum |
I would imagine that if they edit the misc_util.tt2 to ignore 7 as well during the get_graphic_880 dance, that might solve their display issue. |
| 13:20 |
* bshum |
supposes he *could* test it... |
| 13:20 |
bshum |
By making a weird fake record somewhere |
| 13:22 |
dbs |
where's that database-indexes == display-fields thing at |
| 13:22 |
berick |
bug 1251394 |
| 13:22 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1251394 - Assigned to Bill Erickson (erickson-esilibrary) |
| 13:23 |
|
snigdha26 joined #evergreen |
| 13:24 |
|
dMiller joined #evergreen |
| 13:28 |
bshum |
Yep, adding 7 to the list of subfields to ignore in misc_util for the get_graphic_880s function gets rid of it on my test server. |
| 13:28 |
bshum |
Guess I can write that back to them as a suggestion |
| 13:28 |
bshum |
And maybe it's something we can add to future Evergreen versions for them. |
| 13:30 |
dbs |
bshum++ |
| 13:30 |
* dbs |
tries to investigate the case of the short-lived z39.50 connections (incoming to Evergreen) |
| 13:34 |
bshum |
I'm trying to figure out how to figure out why queries are slow on our DB server. |
| 13:46 |
kmlussier |
snigdha26: yes, it took me by surprise the first time it started talking to me. |
| 13:47 |
kmlussier |
snigdha26: On that bug, you might want to change the "Assigned to" column to yourself so that others know you are working on it and don't try to fix it themselves. |
| 13:48 |
|
dkyle left #evergreen |
| 13:51 |
pastebot |
"berick" at 64.57.241.14 pasted "for phasefx, wheezy_installer -- only run live tests if $LIVETEST?" (19 lines) at http://paste.evergreen-ils.org/12 |
| 13:51 |
berick |
phasefx: ^-- if that looks sane, i'll push it to your branch |
| 13:52 |
snigdha26 |
kmlussier: Done that :) |
| 13:58 |
snigdha26 |
kmlussier: I was interested in a few others but it looks like some one is already working on them. I would like to work on this bug https://bugs.launchpad.net/evergreen/+bug/1369203. It looks like no one is working on it yet. |
| 14:20 |
phasefx |
berick++ looks good to me |
| 14:29 |
berick |
phasefx: cool, thanks for looking |
| 14:30 |
phasefx |
push it in soon and we'll see if it works one way or another :) |
| 14:30 |
berick |
testing by the seat of our pants! |
| 14:41 |
|
RoganH joined #evergreen |
| 14:42 |
|
ghost_name joined #evergreen |
| 14:42 |
* ghost_name |
hey |
| 16:16 |
collum |
Bmagic: It looks like the ptype_key column in mar21_physical_charateristic_subfield_map references the marc21_physical_characteristic_type_map |
| 16:16 |
collum |
Oops. jinx |
| 16:18 |
csharp |
bshum: I'm looking into that - I'll share whatever we find. |
| 16:18 |
bshum |
csharp: Tomorrow we're reformatting one of our Dells to use software RAID to deal with the TRIM problem. |
| 16:18 |
bshum |
We're going to try using 12.04 to see if that helps |
| 16:19 |
bshum |
Or maybe even go over to Debian :( |
| 16:22 |
bshum |
I do wonder if there's anything weird with the 3.13 kernel or something. But 12.04.5 uses that kernel on new installs, so it might not be a good test. |
| 17:11 |
|
nhilton joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
Bmagic |
dbwells: collum: Basically I am expierementing with what is possible. I would like to setup a new OPAC Icon definition which requires two 007 fields. One that starts with 'c' and one that starts with 's' |
| 00:54 |
|
snigdha26 joined #evergreen |
| 03:32 |
|
book` joined #evergreen |
| 03:43 |
|
remingtron_ joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:02 |
|
geoffsams joined #evergreen |
| 06:56 |
|
b_bonner joined #evergreen |
| 06:57 |
|
mnsri_ joined #evergreen |
| 09:37 |
|
mllewellyn joined #evergreen |
| 09:44 |
|
kbutler joined #evergreen |
| 09:45 |
|
kmlussier joined #evergreen |
| 09:46 |
berick |
phasefx: pushed to random/collab/phasefx/wheezy_installer -- however, to work, it needs the tip commit from this pulled into master: working/user/berick/lp1350042-grid-print-and-show-all-cols |
| 09:46 |
berick |
which fixes a bug in the JS test runner |
| 09:47 |
kmlussier |
Hi all. We're a little late in getting the DIG hack-a-way started, and yboston is stuck in traffic. |
| 09:47 |
kmlussier |
If anyone wants to come into the Google Hangout, can you send me your Google account e-mail via pm? Thanks! |
| 09:59 |
|
tspindler joined #evergreen |
| 11:28 |
kmlussier |
akilsdonk: OK, thanks! |
| 11:36 |
|
akilsdonk_ joined #evergreen |
| 11:37 |
|
phasefx_ joined #evergreen |
| 11:43 |
phasefx_ |
berick++ about to run a test |
| 11:46 |
|
krvmga joined #evergreen |
| 11:49 |
berick |
phasefx_: cool, for now, it's just reporting the return value, so the JS test suite will be all or none, but it's a start |
| 11:51 |
jeff |
osrf-gateway-v1 using duplicate param= param= parameter names sure can get annoying, depending on your client library. :P |
| 11:52 |
jeff |
one option is to jump to the translator instead. |
| 11:53 |
csharp |
@who will create an API for their API? |
| 12:02 |
dbwells |
Ah, so locations set that way /never/ capture at checkin, and you have to deliberately use the "capture holds" screen to get them to capture. Does that sound right? |
| 12:03 |
jeff |
nope, the workflow is a confirmation pop-up: This item could be captured but was not for policy reasons. Do you want to actually capture it?" (paraphrased) |
| 12:04 |
jeff |
what you described would probably be how we would have built/specified it if done today, and not 6 years ago. ;-) |
| 12:06 |
dbwells |
jeff: thanks for all the info. This actually might do what we need in a roundabout way. Time for actual field testing. |
| 12:06 |
jeff |
"This item could fulfill a hold request but capture has been delayed by policy." followed by "Capture" and "Do Not Capture" options. |
| 12:07 |
jeff |
strings begin with staff.circ.utils.hold_capture_delayed |
| 12:09 |
jeff |
by my read of xul/staff_client/server/circ/util.js, if you use the suppress popups feature in checkin, you'll get a sound but no pop-up, and there will be no capture. |
| 12:13 |
|
whargrove joined #evergreen |
| 12:14 |
whargrove |
Hi all - quick question: when creating the eg database and schema for a test server, how do I know what the database name should be? can I pass in any string I want to eg_db_config? |
| 12:15 |
csharp |
whargrove: yes |
| 12:15 |
csharp |
whargrove: "evergreen" is simplest |
| 12:15 |
csharp |
and will match many examples out there |
| 12:50 |
kmlussier |
snigdha26: Hold on...yboston and I are talking about it. |
| 12:57 |
kmlussier |
snigdha26: We're all about to break for lunch (sorry for the bad timing). But a lot of the features from http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:2.7_needs that aren't already being covered are probably difficult for a new person to the community to document. |
| 12:58 |
snigdha26 |
kmlussier: Oh! That's okay. But yboston needed to collaborate with a new volunteer ? Any thing I can do? |
| 12:59 |
kmlussier |
snigdha26: So yboston was thinking that you might want to look at replacing screenshots from some of our old circulation docs to the new web client that the community is currently testing. |
| 13:00 |
kmlussier |
I don't know what time it is there, but would you be around in an hour (maybe a little longer) to work with him on it? |
| 13:00 |
kmlussier |
Of course, there are always those biteisze docs that can be looked at if later doesn't work. :) |
| 13:01 |
snigdha26 |
kmlussier: It's 10:30 pm here, but I will definitely be around for a while, that's not a problem :) |
| 13:01 |
kmlussier |
snigdha26: OK, thanks! |
| 13:01 |
* kmlussier |
is usually too tired to do anything by 10:30 p.m. :) |
| 13:08 |
snigdha26 |
Sure :) Thanks |
| 13:15 |
|
chatley joined #evergreen |
| 13:15 |
|
RoganH joined #evergreen |
| 13:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 13:21 |
|
nhilton_ joined #evergreen |
| 13:34 |
pinesol_green |
[evergreen|Bill Erickson] LP#1350042 browser unit tests use repo fm_IDL2js.xsl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8f37922> |
| 13:39 |
|
nhilton joined #evergreen |
| 13:54 |
|
ktomita joined #evergreen |
| 14:10 |
csharp |
@quote random |
| 15:32 |
pinesol_green |
[evergreen|Kathy Lussier] Minor reparis to release notes and merge parts doscs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb0aed2> |
| 15:32 |
bshum |
The one for 8443 for hatch is "normal" I think when you don't have a printer stuff setup |
| 15:32 |
bshum |
But I would also expect to see errors for those other ports potentially |
| 15:39 |
whargrove |
I am troubleshooting my evergreen test server ... I keep on getting "no data received from server" when issuing the test commands |
| 15:39 |
whargrove |
ejabberd does not have an ssl_esock process |
| 15:40 |
whargrove |
Could that be causing the no data errors? |
| 15:40 |
kmlussier |
A general question about the web client then. If it can't be used when certain ports are blocked, is this going to present a problem for some of our libraries when they need to use it in production? |
| 15:41 |
bshum |
snigdha26: Yeah in my console from a server/client that can't talk I get something like: |
| 15:41 |
kmlussier |
I'm mostly concerned about schools and academics who may not be able to convince their IT departments to unblock the ports. |
| 16:43 |
mmorgan |
yup. Don't see openkiosk in appdata. Have been down many of these roads :) |
| 16:43 |
bshum |
Hmm |
| 16:43 |
* mmorgan |
agrees. Hmm... |
| 16:43 |
bshum |
Well |
| 16:43 |
bshum |
:) |
| 16:43 |
bshum |
That was the solution we used :D |
| 16:44 |
bshum |
Oh maybe it's under the parent folder |
| 16:44 |
bshum |
Like err |
| 16:44 |
bshum |
mozdevgroup? |
| 16:44 |
* bshum |
doesn't have access to his test system with it today |
| 16:44 |
* bshum |
quickly gives it an install to remember |
| 16:44 |
pinesol_green |
[evergreen|Kate Butler] Docs: Staff initials settings for patron notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82c76d0> |
| 16:47 |
mmorgan |
\me searches for possibly related directory names... |
| 16:48 |
bshum |
mmorgan: Local\MDG\OpenKiosk |
| 17:01 |
bshum |
mmorgan++ |
| 17:02 |
bshum |
gmcharlt: I imagine we could do something similar (new section) for the actual web client bits too. |
| 17:02 |
gmcharlt |
yeah |
| 17:02 |
bshum |
gmcharlt: Since there's some tweaks for apache 2.4 for websockets in OpenSRF |
| 17:02 |
bshum |
I wonder if we should include a copy of the modified apache.conf file |
| 17:02 |
bshum |
And make another directory / instruction step for it |
| 17:02 |
bshum |
Kind of like what we do for Evergreen |
| 17:02 |
bshum |
With 2.2 vs. 2.4 |
| 17:03 |
bshum |
Though I don't know if anybody's tested the 2.4 apache.conf with anything other than Debian for you guys, and Ubuntu 14.04 for us. |
| 17:03 |
bshum |
Thinking about Fedora :) |
| 17:03 |
* bshum |
stares off in dbs' direction |
| 17:03 |
bshum |
But we could start with that and see where it leads us |
| 17:03 |
gmcharlt |
bshum: say Fedora three times in a row... ;) |
| 17:04 |
|
gmcharlt joined #evergreen |
| 17:05 |
* dbs |
pops up |
| 17:24 |
jeff |
oops. |
| 17:24 |
jeff |
bshum++ |
| 17:28 |
whargrove |
jeff: sorry I didn't see your response. Thanks :) I wasn't making the connection between patron and user to create the staff user account |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:33 |
|
whargrove joined #evergreen |
| 17:33 |
bshum |
Race condition again? |
| 17:33 |
phasefx |
that one is probably from me mucking with it earlier |
| 17:33 |
phasefx |
I don't think the VM refreshed |
| 17:35 |
bshum |
Ah okay |
| 17:35 |
phasefx |
yeah, that's what happened |
| 17:36 |
phasefx |
Refresh happens at 11am, testing way later, and I jumped in between the two |
| 17:45 |
bshum |
Sigh |
| 17:45 |
bshum |
Reading the OpenSRF README closely for the first time to try mimicking the same style. |
| 17:45 |
bshum |
And now I want to edit the existing stuff |
| 03:00 |
pinesol_green |
bshum: The operation succeeded. |
| 03:01 |
bshum |
Inching ever so incrementally forward.... |
| 03:02 |
* bshum |
goes back to sleep. |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:28 |
|
kmlussier joined #evergreen |
| 06:13 |
|
kmlussier left #evergreen |
| 07:13 |
csharp |
alert to whoever may be using git, list, or lupin - we're going to pull them down for a minute to update mundungus - doing this early in hopes of little disruption |
| 09:29 |
rsoulliere |
tsbere: I was thinking that it has to relate to the data getting entered with faulty data, but if wee are entering in the staff client, the data should be pretty kosher unless there is a known bug in 2.5.5 |
| 09:31 |
tsbere |
rsoulliere: The text fields can end up with empty strings instead of nulls (circ modifier and the marc fields, though circ modifier may be prevented from being affected due to foreign key stuff) |
| 09:33 |
|
pmurray_away joined #evergreen |
| 09:33 |
rsoulliere |
tsbere: so an sql insert statement setting the blank fields to NULL where needed might be a good test? |
| 09:34 |
tsbere |
rsoulliere: SELECT whatever FROM config.circ_matrix_matchpoint WHERE <field> = '' |
| 09:34 |
tsbere |
rsoulliere: I figure you can flesh that out properly for testing ;) |
| 09:35 |
rsoulliere |
tsbere: yes, I'll try. ;-) |
| 09:36 |
|
mllewellyn joined #evergreen |
| 09:37 |
|
pmurray joined #evergreen |
| 10:32 |
pinesol_green |
Launchpad bug 1350350 in Evergreen "browser client build/install process improvements" (affected: 1, heat: 8) [Undecided,New] |
| 10:32 |
berick |
and i'm happy to help w/ that. |
| 10:39 |
pastebot |
"berick" at 64.57.241.14 pasted "browser client dependency building example for bshum" (19 lines) at http://paste.evergreen-ils.org/10 |
| 10:42 |
phasefx |
berick: do you have tuits to modify collab/phasefx/wheezy_installer for the web based client? for http://testing.evergreen-ils.org/~live/ |
| 10:46 |
phasefx |
I guess looking at the bug report, we'd still need to make some decisions regarding installing from git |
| 10:49 |
berick |
phasefx: yeah. remind me, does ~live do a build on a fresh OS each time? |
| 10:49 |
berick |
iow, it installs all prereqs each time? |
| 10:51 |
phasefx |
berick: correct, though it does have some uninstalled pre-fetched deb files available for apt |
| 10:52 |
phasefx |
or refresh now and look |
| 10:52 |
berick |
k, no rush |
| 10:53 |
berick |
just making the installer needs to build node.js |
| 11:03 |
phasefx |
berick: did you work up a way to do headless/browserless unit testing for the client? |
| 11:04 |
berick |
phasefx: yessir |
| 11:04 |
phasefx |
berick++ awesome |
| 11:04 |
phasefx |
we'll want the live page to run and expose that |
| 17:00 |
Bmagic |
I dont have a specific example, I was asking in general. Is there a setting for this in EG? |
| 17:00 |
mmorgan |
So is the context org for the "Lost Materials Processing Fee" library setting supposed to refer to the checkout library? |
| 17:00 |
mmorgan |
or the item's owning library? |
| 17:01 |
bshum |
mmorgan: I would have expected that to be for the library where the item was checked out. |
| 17:01 |
bshum |
But to be fair, I don't think we've tested it on a case-by-case. We always charge item price when an item goes lost. |
| 17:02 |
bshum |
And don't differentiate with our libs |
| 17:02 |
bshum |
So maybe this is a use case that Bmagic has that isn't expected behavior for the settings |
| 17:02 |
jihpringle |
Bmagic: we looked for such a setting back when we were on 2.4 and couldn't find one |
| 17:03 |
jihpringle |
and haven't seen anything that does this on 2.6 either |
| 17:03 |
Bmagic |
We are seeing that the owning library settings are getting applied to the circulation library patrons in the case of "Lost Materials Processing Fee". We would like that to stop |
| 17:09 |
bshum |
Trusty support is still being worked on |
| 17:09 |
whargrove |
OK, that's what I thought |
| 17:09 |
whargrove |
thanks! |
| 17:11 |
pinesol_green |
[evergreen|SnigdhaD] LP#1294269 Docs: Fixed small documentation formatting bugs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31f54c7> |
| 17:12 |
|
mmorgan left #evergreen |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:17 |
Bmagic |
bshum: A quick sql query and I come up with some circulations that meet my criteria. I lookup the patron from my sql query and find the xact id in the list of fines. I look at full details and the GUI says that the circulating library is the same as the owning library even though my sql says the contrary! |
| 17:19 |
bshum |
Bmagic: That sounds... mysterious. |
| 17:20 |
Bmagic |
bshum: im looking deeper, I might have spoke to soon.... |
| 00:37 |
|
chatley joined #evergreen |
| 00:39 |
|
b_bonner_ joined #evergreen |
| 01:03 |
|
StomproJ joined #evergreen |
| 05:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:57 |
|
rjackson-isl joined #evergreen |
| 07:57 |
|
Dyrcona joined #evergreen |
| 07:59 |
|
mrpeters joined #evergreen |
| 09:19 |
pastebot |
"csharp" at 64.57.241.14 pasted "\d authority.record_entry" (50 lines) at http://paste.evergreen-ils.org/24 |
| 09:19 |
csharp |
eeevil: ^^ |
| 09:26 |
|
Shae joined #evergreen |
| 09:26 |
eeevil |
csharp: as a quick test, you could try EXPLAINing the query after replacing "like" with ">=" |
| 09:27 |
csharp |
sure thing - just a sec |
| 09:28 |
csharp |
ERROR: argument of AND must be type boolean, not type tex |
| 09:29 |
pastebot |
"csharp" at 64.57.241.14 pasted "full explain output for eeevil" (3 lines) at http://paste.evergreen-ils.org/25 |
| 09:41 |
eeevil |
csharp: boo... well, I'd suggest adding a second text_pattern_ops index (create concurrently) to test |
| 09:41 |
eeevil |
and now I must run away |
| 09:41 |
csharp |
eeevil: thanks! |
| 09:54 |
|
yboston joined #evergreen |
| 10:00 |
dbwells |
csharp: I think what you are seeing is a side effect of the secondary changes on bug #1253163. |
| 10:45 |
dbwells |
eeevil: I did briefly try upping the cost, but didn't see any difference. I think I stopped at 100000. I don't have enough experience to know if that is "high", but it was at least higher than the default of (I think) 100. |
| 10:47 |
eeevil |
dbwells: yeah, I don't know if that's enough or not ... /me looks at the explain again |
| 10:47 |
jboyer_isl |
dwells, weevil: I’m just plain guessing, but is it possible that a vacuum analyze on the config tables may help the Qplanner realize they don’t change often? |
| 10:47 |
dbwells |
I've never posted to the PG lists, but I have a test case worked up which I think isolates the issue. We can see what they say over there. |
| 10:48 |
dbs |
dbwells: RhodiumToad is right over in #postgresql |
| 10:49 |
dbs |
RhodiumToad is like the collective wisdom of all PostgreSQL hackers combined |
| 10:49 |
eeevil |
dbwells: in csharp's example, it seems like it should be high enough... total cost is ~630000 |
| 10:49 |
dbs |
but a post to the mailing list carries more weight vs. the immediacy of IRC, and test cases are golden |
| 10:51 |
dbwells |
dbs: Thanks for the tip! I'll probably still start with the list if only due to general timidity. I still find it hard enough to speak up in #evergreen. :) |
| 10:53 |
* dbwells |
needs to re-steel himself daily |
| 10:53 |
dbs |
dbwells++ |
| 16:47 |
|
cherri joined #evergreen |
| 16:52 |
|
_bott_ joined #evergreen |
| 16:56 |
|
hbrennan joined #evergreen |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
hbrennan |
Patrons with max fines are being skipped in the holds queue. I'm looking in Standing Penalties and believe I just need to remove some items from the block_list.... |
| 17:01 |
hbrennan |
I would like patrons to be notified their hold is available (I'm guessing this is CAPTURE) and renew items they already have (RENEW) |
| 17:01 |
hbrennan |
But what is FULFILL? |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:02 |
|
wsmoak joined #evergreen |
| 07:29 |
|
Callender_ joined #evergreen |
| 07:40 |
|
mtate joined #evergreen |
| 11:35 |
kmlussier |
snigdha26: Depending on what you are documenting, you could use one of the community demos. |
| 11:35 |
yboston |
snigdha26: sorry, I had to take a phone call |
| 11:36 |
kmlussier |
snigdha26: http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers#community_demo_servers |
| 11:36 |
yboston |
snigdha26: let me first exlain that overall Evergreen has to sotware parts, the server part, and the client part |
| 11:37 |
yboston |
the client can be installed on windows very easily, and you can then connect your client to a community (test) server like Kathy mentioned |
| 11:38 |
yboston |
snigdha26: the server part of Evergreen has a lot more steps for installation and cannot be installed on windows. |
| 11:38 |
yboston |
usually to write docuemntation for this prject you only need the client |
| 11:39 |
snigdha26 |
kmlussier: I'll start with installing the client server then. |
| 11:40 |
snigdha26 |
yboston: What part of the documentation can I start working with after that? |
| 11:48 |
kmlussier |
snigdha26: We have some small doc needs at http://bit.ly/YqlB8y that might be good to start on. |
| 11:55 |
yboston |
snigdha26: I want to make it claer that the Evergreen "server" and the Evergreen "client" are two seprate peices fo software |
| 11:56 |
yboston |
snigdha26: The Evergreen cleint is easy to install on Windows. Once you install it you need to point your Evergreen client to one of the Commmunity servers that are already isntalled and running for anyone to use |
| 12:02 |
snigdha26 |
yboston: I've installed the Evergreen client |
| 12:06 |
yboston |
snigdha26: now you need to conenct your Evergreen client to one of the community servers that kmlussier mentioned earlier here http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers#community_demo_servers |
| 12:07 |
yboston |
snigdha26: when you run the Evergreen cleint, you will see a window that asks for information to connect to an Evergreen server |
| 12:08 |
yboston |
like "hostname" , where you would use the URL of one of the test servers listed in the community server link |
| 12:09 |
yboston |
though you should not use the "http://" part of the community server. So for the "hotname" value use "demo.evergreencatalog.com" instead of "http://demo.evergreencatalog.com/" |
| 12:11 |
snigdha26 |
yboston: I am encountering a network or server failure when I try to enter the workstation name, after logging in |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:11 |
|
sudshekhar02 joined #evergreen |
| 12:12 |
yboston |
there is an issue that always comes up the very ifrst time you connect the EG cleint to a EG server |
| 12:12 |
yboston |
it might be happening this time too |
| 12:12 |
yboston |
what does the client say right below the button called "re-test server" |
| 12:12 |
yboston |
does it say "200: Ok" |
| 12:12 |
yboston |
in greeen? |
| 12:13 |
snigdha26 |
yboston: status: 200 ok |
| 12:13 |
yboston |
it says 200 OK once or twice? |
| 12:13 |
snigdha26 |
yboston: twice. For status and version both |
| 12:26 |
|
wsmoak left #evergreen |
| 12:26 |
kmlussier |
snigdha26: OK, I can get that one back up and running for you. But it takes about 10 to 15 minutes. Sorry about that. |
| 12:27 |
snigdha26 |
kmlussier: Not a problem :) |
| 12:27 |
yboston |
snigdha26: this is good that you are helping us test our test community servers, thanks! |
| 12:28 |
snigdha26 |
yboston: haha, just trying to get started |
| 12:29 |
kmlussier |
yboston: Better to find the problems now than in the middle of Friday's DIG hackfest, right? :) |
| 12:29 |
yboston |
kmlussier: exactly |
| 12:42 |
snigdha26 |
yboston: I would have to work on asciidoc right? |
| 12:42 |
yboston |
snigdha26: no that is optional |
| 12:43 |
kmlussier |
snigdha26: The masslnc community demo server should be ready now. |
| 12:47 |
snigdha26 |
kmlussier: There's an error testing the hostname |
| 12:48 |
yboston |
snigdha26: any errors in the are below "re-test server"? |
| 12:48 |
yboston |
*area |
| 12:48 |
kmlussier |
snigdha26: you might need to add an SSL exception for that server. |
| 12:49 |
snigdha26 |
yboston, kmlussier: All good, I was able to register :D |
| 12:50 |
kmlussier |
snigdha26: Was it the SSL exception? If so, I should add that info to the wiki page. |
| 17:16 |
|
sarabee_ joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:27 |
|
geoffsams joined #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:41 |
|
Dyrcona joined #evergreen |
| 20:22 |
|
hbrennan joined #evergreen |
| 23:32 |
|
ktomita_ joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:26 |
|
wsmoak joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 07:47 |
|
mtate joined #evergreen |
| 09:30 |
jeff |
csharp: if you look at that file, it does most of its work inside a sub called "handler", which expects (among other things) an A/T-style $env hash with params. the actual elements of that hash that are used by that specific sub are few, but it's also going to do things like make log entries that claim to be trigger-related, and it's going to fire any A/T events that are defined for longoverdue.auto (which you may or may not have) |
| 09:31 |
eeevil |
csharp: a/t is meant to handle that stuff for you, so unless you're talking about a list on the order of several hundred thousand items (and even then, with judicious use of delay settings for the definition), you may just want to let a/t handle it. you'll notice that the the reactor is also potentially creating cascaded events (could be notifications, etc) after marking the item longoverdue |
| 09:32 |
eeevil |
jeff: jinx :) |
| 09:42 |
csharp |
eeevil: let me do a count of items that match our criteria |
| 09:42 |
|
yboston joined #evergreen |
| 09:44 |
csharp |
eeevil: looks like 309,524 at the moment that I would need to process |
| 09:44 |
csharp |
I'll look into processing with A/T (doing this all on a test server at the mo) |
| 09:46 |
eeevil |
if you used the min and max delay to do it in several-month chunks (change the def after each run) I bet that'll be less work in the long run |
| 09:46 |
csharp |
eeevil: excellent - I didn't know if that was a sane approach or not |
| 09:47 |
eeevil |
well, if you set it up as a special granularity for the time being, those could be processed in one go in parallel with the normal events. with --granularity-only |
| 14:10 |
kmlussier |
I was wondering if it would be wortwhile to have a separate DIG hack-a-way day just to focus on web client documentation. Of course, it couldn't be done in time for the 2.7 release. |
| 14:10 |
yboston |
I am open to a second event |
| 14:10 |
yboston |
or if there is time during the upcoming one |
| 14:11 |
kmlussier |
The nice thing about getting the documentation done early is that it also can serve as an opportunity to test functionality in the new web client. |
| 14:11 |
yboston |
kmlussier: good point |
| 14:11 |
jihpringle |
I'd be happy to work on it during the current hack-a-way or participate in a future specifc one |
| 14:11 |
kmlussier |
yboston: I think doing both in one day would be ambitious. |
| 15:30 |
remingtron |
Stompro: another thought, I've found that some client files have copies on the server, and that has confused me about which one to edit sometimes |
| 15:30 |
jeff |
but Windows vista and up will happy confuse things if you try to edit some files in some ways. :P |
| 15:31 |
phasefx |
Stompro: try creating a different profile with -profileManager |
| 15:31 |
jeff |
remingtron: good point, though in this case i think phasefx's test local edit confirmed that the file in question should be local and not server-sourced |
| 15:31 |
jeff |
Stompro: what is the full path to the file on disk that you are editing, and what's the local OS? |
| 15:32 |
Stompro |
phasefx: when you said "main.js" did you mean "menu.js" ? |
| 15:32 |
phasefx |
Stompro: no, I tried main.js so I wouldn't have to bother logging in |
| 15:32 |
jeff |
oh hey. |
| 17:06 |
|
wsmoak joined #evergreen |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 20:03 |
|
kmlussier joined #evergreen |
| 20:34 |
|
kmlussier joined #evergreen |
| 21:00 |
jeff |
phasefx: live test failure looks like another race condition -- what do you think? |
| 21:01 |
phasefx |
jeff: yeah, I think so, but no insight or tuits for fixing it |
| 21:03 |
jeff |
is there any way to allow for on-demand re-run of the tests by some folk, either via web or ssh? |
| 21:03 |
|
buzzy joined #evergreen |
| 21:07 |
phasefx |
jeff: not conceptually difficult, but some work is needed; my main concern is that we're using ganeti for it, and multiple folks can't do things concurrently with that. That said, virtualbox works fine with these tools :) |
| 21:09 |
phasefx |
maybe it's time to work in support for multiple drones, or fold it into buildbot somehow |
| 21:10 |
jeff |
i was just thinking "enable someone to trigger a sooner-than-in-12-hours re-run" |
| 21:10 |
jeff |
not "multiple concurrent test runs / testing different branches / etc" |
| 21:10 |
jeff |
that might have been unclear, or i might have misunderstood your answer. :-) |
| 21:11 |
phasefx |
we can cron it more frequently; my concern with concurrency is with us doing ganeti-stuff with other vm's at the same time |
| 21:11 |
phasefx |
I'm not a ganeti guru though |
| 21:12 |
jeff |
ah |
| 00:04 |
Guest6556 |
There is two types of policy the first is student policy who can borrowed atleast 25 books and Faculty which is 50 books. the problem is the number of books they can borrow is 10... |
| 00:04 |
Guest6556 |
Oh. well thanks for the answer and ideas I will try your suggestion. |
| 00:13 |
|
tsbere joined #evergreen |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:17 |
|
rangi joined #evergreen |
| 05:20 |
|
wsmoak joined #evergreen |
| 05:22 |
|
ldw joined #evergreen |
| 09:09 |
|
csharp joined #evergreen |
| 09:11 |
* csharp |
survived Adventures with PostgreSQL 9.3 last night |
| 09:12 |
csharp |
particularly bug 1253163 and bug 1277731 were fun to track down |
| 09:12 |
pinesol_green |
Launchpad bug 1253163 in Evergreen "authority indexes can fail on Postgres 9.3.0" (affected: 3, heat: 20) [Critical,Fix released] https://launchpad.net/bugs/1253163 |
| 09:12 |
pinesol_green |
Launchpad bug 1277731 in Evergreen "Hold tests failure" (affected: 1, heat: 6) [Critical,Fix released] https://launchpad.net/bugs/1277731 |
| 09:13 |
csharp |
eeevil++ dbwells++ # for fixes review on both so I wasn't up the creek ;-)( |
| 09:14 |
csharp |
s^fixes review^fixes/review^ |
| 09:25 |
|
yboston joined #evergreen |
| 11:01 |
dbs |
gmcharlt++ |
| 11:01 |
krvmga |
dbs: i just got your email. thx :) |
| 11:04 |
krvmga |
gmcharlt: it fetched the working branches |
| 11:05 |
gmcharlt |
krvmga: ok, another test for you: ssh git git.evergreen-ils.org (/me is watching /var/log/auth.log on the git server) |
| 11:06 |
krvmga |
gmcharlt: done |
| 11:08 |
gmcharlt |
krvmga: did you get back a list of repositories? |
| 11:08 |
krvmga |
gmcharlt: yes, down to working/random and then the connection closed |
| 11:20 |
eeevil |
it shouldn't have that (or, mine does not) |
| 11:21 |
gmcharlt |
eeevil: it doesn't make a difference whether or not ".git" is there |
| 11:21 |
eeevil |
gitgit.evergreen-ils.org:working/Evergreen vs gitgit.evergreen-ils.org:working/Evergreen.git |
| 11:21 |
gmcharlt |
(and I just tested that to besure) |
| 11:21 |
eeevil |
hrm... I thought it mattered before, but I'm using an older git, I think |
| 11:22 |
jcamins |
krvmga: just to confirm something I didn't see gmcharlt ask: you're looking at /your/repo/.git/config right? |
| 11:22 |
eeevil |
oh, no, I'm using a /newer/ git :) ... still 1.7, though |
| 16:32 |
kmlussier |
bshum++ |
| 16:32 |
bshum |
I'll be on the road next week, but will work with others to finish rounding out the docs and other things to get us ready for the 2.7 RC cut |
| 17:19 |
|
mmorgan left #evergreen |
| 17:32 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:45 |
|
gdunbar joined #evergreen |
| 17:46 |
|
jeff__ joined #evergreen |
| 17:46 |
|
Bmagic joined #evergreen |
| 04:38 |
|
Terence joined #evergreen |
| 04:39 |
Terence |
helo |
| 04:43 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 04:51 |
|
wsmoak joined #evergreen |
| 04:51 |
|
wsmoak joined #evergreen |
| 06:41 |
|
b_bonner joined #evergreen |
| 09:10 |
|
jwoodard joined #evergreen |
| 09:30 |
|
tsbere joined #evergreen |
| 09:32 |
|
tsbere joined #evergreen |
| 09:32 |
bshum |
phasefx: Hmm, looks like the live test build failed with the new DB pre-req makefile targets |
| 09:33 |
|
tsbere joined #evergreen |
| 09:36 |
dbs |
/home/opensrf/Evergreen/Open-ILS/src/extras//install/Makefile.debian-wheezy:8: *** commands commence before first target |
| 09:37 |
dbs |
crap. Missing \ at the end of line 8 |
| 09:37 |
bshum |
Whoops :( |
| 09:37 |
dbs |
live-tests++ |
| 09:38 |
dbs |
prepping a fix |
| 09:39 |
bshum |
dbs++ |
| 09:40 |
bshum |
The other ones look fine, fwiw. |
| 09:41 |
dbs |
Yep, lucky the live tester tests wheezy |
| 09:41 |
dbs |
I'm going to just push the fix in if you don't mind. Just two lines. |
| 09:42 |
bshum |
dbs: Sounds good to me. |
| 09:42 |
bshum |
Thanks! |
| 09:42 |
dbs |
user/dbs/fix_broken_Makefile_install if you want to double-check |
| 13:10 |
tsbere |
jeff: If you want to play with things something like this may be what we generally need: http://nsis.sourceforge.net/ShellExecAsUser_plug-in |
| 13:12 |
tsbere |
jeff: Or maybe this trick actually works too: http://mdb-blog.blogspot.com/2013/01/nsis-lunch-program-as-user-from-uac.html (with the benefit of not needing a plugin) |
| 13:20 |
|
akilsdonk joined #evergreen |
| 13:39 |
jboyer-isl |
jeff: I've seen software from some RFID vendors that tries to be smart about where it sends its data. You had to enter a list of window titles that can accept input. (Notepad would obviously be in the default set because of installer testing) |
| 13:39 |
jboyer-isl |
Oh hey, tsbere already said that. I hope it helped 20 mins ago. D: |
| 13:39 |
jboyer-isl |
:D |
| 13:40 |
jeff |
heh |
| 13:40 |
Bmagic |
Can anyone verify that there is no way to force the hold targeter to include newly catalogged items in the hold_copy_map sooner than every 24 hour laps from prev_check_time ? |
| 13:41 |
kmlussier |
Bmagic: Check-in modifier to retarget holds? |
| 16:56 |
|
kmlussier left #evergreen |
| 16:59 |
|
remingtron__ joined #evergreen |
| 17:00 |
* dbs |
can't remember if those are the good cholesterols or the bad ones. Heh. |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
eeevil |
jeff: sorry, query_int (for better googling). It may only be in 2.7? holdable_formats got ... more complex :) with MR holds coming back (via "the icon project") |
| 17:28 |
eeevil |
jeff: nope ... in 2.6. see: Open-ILS/src/sql/Pg/upgrade/0865.schema.convert-MR-holdable_formats.sql and Open-ILS/src/sql/Pg/upgrade/0864.MVF_CRA-upgrade.sql (the thing that can "compile" that) |
| 17:28 |
* eeevil |
runs away |
| 04:08 |
|
pmurray` joined #evergreen |
| 04:18 |
|
_bott_ joined #evergreen |
| 04:57 |
|
wsmoak joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:52 |
|
krvmga joined #evergreen |
| 08:12 |
|
akilsdonk_ joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 10:03 |
krvmga |
collum++ |
| 10:08 |
|
berick joined #evergreen |
| 10:16 |
|
mllewellyn joined #evergreen |
| 10:43 |
* tsbere |
runs one last set of tests before responding to questions on launchpad |
| 10:43 |
tsbere |
Just dawned on me that some of the things I am seeing issues with I didn't test without the code in question loaded. |
| 10:45 |
bshum |
berick: Fwiw, I had problems with the bookbags too when websockets weren't working right on my test server. What I saw was two things: |
| 10:45 |
bshum |
1) if websockets was not turned on, then I got internal server errors when trying to add bibs to bookbags |
| 10:46 |
bshum |
2) if websockets was not accessible (like if it was port blocked or not running properly), then I also found myself being taken to a page where it would stop/break eventually with some popup in XUL client about too many redirects or something |
| 10:48 |
berick |
bshum: interesting... OK |
| 10:48 |
berick |
thanks |
| 10:48 |
bshum |
It was not clear to me that the intent was for these existing parts of the XUL client to remain working without websockets installed and functional. Given this criteria, I'll curiously follow along and see what else we can find before we move forward. |
| 10:50 |
berick |
bshum: yeah, the hope was websockets would only be needed if you wanted to experiment w/ the browser client |
| 10:52 |
* tsbere |
apparently deleted one thing too many and has to do a much deeper clean install than he originally intended. Whoops. |
| 10:52 |
* dbs |
guesses he should probably open a bug for the Makefile install branch |
| 10:52 |
bshum |
dbs: Ack, I knew I forgot to merge something last night |
| 10:53 |
bshum |
dbs: It was on my list, I just got distracted with so many tasty "signedoff" bugs |
| 10:55 |
bshum |
dbs: If you have time to open an LP, that'd be swell, but if you have other matters to attend to, I can finish testing and push your commit later this afternoon. |
| 10:57 |
|
jboyer-isl left #evergreen |
| 10:57 |
|
jboyer-isl joined #evergreen |
| 10:59 |
jboyer-isl |
I know I missed this yesterday, but does anyone have time to look at lp 1241644 ? It's a pretty basic change that we've been running with just fine since October. |
| 11:18 |
mmorgan |
ok, so the claimed returned item with 0 fines has a xact_finish date? that's why it's not showing in items out? |
| 11:18 |
jboyer-isl |
mmorgan, yes. |
| 11:18 |
|
tsbere joined #evergreen |
| 11:19 |
mmorgan |
eeevil: gotcha |
| 11:19 |
mmorgan |
jboyer-isl: I'd be interested in testing this one. |
| 11:19 |
mmorgan |
I think I can get kmlussier to load a sandbox |
| 11:21 |
mmorgan |
but this problem have any relation to lp 793550 ? Should these claimed returned items have an xact_finish? |
| 11:21 |
pinesol_green |
Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550 |
| 11:22 |
jboyer-isl |
eeevil: sure, I don't mean the number associated with an actor.usr. |
| 11:22 |
|
DPearl1 joined #evergreen |
| 11:45 |
|
tsbere joined #evergreen |
| 11:46 |
eeevil |
berick_: unless you were depending on the "last lvalue gets returned" behavior of subs there? (but that seems a bit too magical to me) |
| 11:50 |
* bshum |
doesn't know what that commit references to, so will take eeevil's word for it :) |
| 11:51 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9e8a245ff181e3b837e1e60ef60c8eb3d8b0f190 |
| 12:05 |
|
berick joined #evergreen |
| 12:05 |
eeevil |
well, magic last lval does work in a simple test... but I'm still going to offer a branch bringing back the returns |
| 12:09 |
|
akilsdonk joined #evergreen |
| 12:13 |
|
jwoodard joined #evergreen |
| 12:14 |
eeevil |
hold pull list was only changed (AFAICT) in that commit above. The substantive change to the pre-websockets code was the lack of 'return's, so if you have a test env handy: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-staff-phase1-squash-with-returns |
| 12:15 |
eeevil |
note that http://paste.evergreen-ils.org/22 suggests it should work, but the sub is much more complicated than that test |
| 12:25 |
bshum |
eeevil: Hmm, what was the problem with the holds pull list in the client? Or is this a web client issue we're troubleshooting? |
| 12:28 |
eeevil |
bshum: I'm sorry ... I thought you were saying (up there) that the entry point for the current one broke until you set up (and un-firewalled) websockets. did I misunderstand? |
| 12:28 |
* bshum |
didn't notice any breakage in the XUL clients |
| 12:44 |
jeff |
I'm tempted to find out how much Nick Offerman would charge for some "custom Carl Kassell answering machine message" style audio or video of suitable variations on his Eggs and Bacon bit. |
| 12:45 |
jeff |
``Just give me all the ILS data you have. Wait, wait. I'm worried what you just heard was, "Give me a lot of data." What I said was, "Give me all the ILS data you have". Do you understand?'' |
| 12:46 |
eeevil |
tsbere: do you want to amend your comment on the ticket, WRT having to set up websockets to get the normal (xul staff client, normal tpac) stuff working? I think we've agree that that's not true, bshum? |
| 12:47 |
bshum |
eeevil: I have to test further as far as turning off my websockets. I got mine to work and didn't look back to see what wasn't working with them on. |
| 12:48 |
jeff |
the followup is a bit more of a mouthful, though: |
| 12:48 |
jeff |
``Just give me all the details on your authentication options. Wait, wait. I'm worried what you just heard was, "Give me a one page summary of your authentication options." What I said was, "Give all of the details on your authentication options" Do you understand?'' |
| 12:48 |
bshum |
eeevil: aka, my testing assumption was (get websockets working), find out if anything else was broken. Not so much, install it all, and see what's just plain broken. |
| 12:49 |
bshum |
But I'm getting there. Have to start a fresh VM. |
| 12:49 |
gmcharlt |
bshum: speaking of fresh VMs -- Debian testing no longer includes libemail-send-perl |
| 12:50 |
gmcharlt |
deprecated in favor of libemail-sender-perl |
| 12:50 |
gmcharlt |
wheee! |
| 12:51 |
bshum |
o.O |
| 12:53 |
|
geoffsams joined #evergreen |
| 12:53 |
eeevil |
bshum: gotcha. I think the low water mark for merging is "does this branch break anything if none if its new features are turned on" ... the high water mark is probably "its features work and so do the ones from outside this branch". in between those, it's a judgement call about the tradeoff between getting it out for user testing (and bug finding, of all varieties, of course!) vs pure bug-free code (regardless of whether it's in use or not) in a |
| 12:53 |
eeevil |
release. |
| 12:54 |
gmcharlt |
bug 1362260 |
| 12:54 |
pinesol_green |
Launchpad bug 1362260 in Evergreen "Email::Send is deprecated" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1362260 |
| 12:55 |
|
ericar joined #evergreen |
| 12:56 |
eeevil |
IOW, and IMHO, if simple inclusion (without websockets turned on) does not break existing functionality, I think it should go in. If turning them on breaks something in either xul or web staff client, then we should loudly explain that, and say "really, not for production yet!". if it does not break anything (that we can find) then it should go in and broad testing should be encouraged. my $0.02 |
| 12:57 |
eeevil |
(and IIUC the testing so far bookbags inside the web staff client, but not in the xul or tpac modes, are having issues ... but nothing else?) |
| 12:57 |
dbs |
Of course, determining if existing functionality is broken is tough without a comprehensive walkthrough of system features etc. |
| 12:57 |
dbs |
See historical effort to test big XUL staff client changes and we still didn't catch everything |
| 12:57 |
eeevil |
dbs: absolutely |
| 12:58 |
dbs |
Maybe we could at least reuse that list of manual tests as a starting point :) |
| 12:58 |
eeevil |
see also: acq "preview" |
| 12:59 |
eeevil |
(granted, this is 99.9% new front-end code only, with almost no backend logic that hasn't seen real use) |
| 13:05 |
|
jihpringle joined #evergreen |
| 16:49 |
csharp |
and it takes a long time, even on SSD |
| 16:51 |
|
buzzy joined #evergreen |
| 16:53 |
tsbere |
csharp: Well, I assume it takes a long time when the "merge from" user(s) have a lot of circs/holds. Probably faster when they don't. ;) |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:20 |
csharp |
yeah - we're going to be processing a large dupe file this weekend. I guess it's just going to take a while ;-) |
| 17:24 |
|
mmorgan left #evergreen |
| 18:18 |
bshum |
gmcharlt++ # pointing out to me what I've been doing wrong testing holds this whole week :( |
| 18:19 |
bshum |
I've updated bug 1350042 with my findings this afternoon. So far I'm not seeing any further problems with my test system running OpenSRF master + Evergreen web client branch. |
| 18:19 |
pinesol_green |
Launchpad bug 1350042 in Evergreen "Browser staff client / merge prep" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1350042 |
| 19:54 |
|
kmlussier joined #evergreen |
| 20:40 |
pinesol_green |
[evergreen|Dan Scott] LP#1362210: Install PostgreSQL packages where we can - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57f390e> |
