| 12:14 |
dbwells |
no, you have to tell ezproxy to not bounce proxy requests to itself, but to allow a login->redirect |
| 12:14 |
dbwells |
sorry, ignore that |
| 12:15 |
dbwells |
When you say "same problem", you still get no login? Or you login and then get the 404? |
| 12:15 |
gsams |
I do not appear to be getting a login at all, it leads to the same address with a 404. |
| 12:15 |
gsams |
though I should probably reset or test at a different computer at this point |
| 12:16 |
gsams |
yeah, 404 no login option given |
| 12:17 |
hopkinsju |
jboyer-isl: Any update on those Ansible playbooks? I'm interested in working on that, but I'd like to have something to serve as a starting point. |
| 12:19 |
dbwells |
gsams: when I visit the URL I pasted above, I get the login prompt. It's possible you have cached redirect? |
| 12:21 |
gsams |
That is possible, I just attempted to request an item from a different computer instead to double check. I'm fixing that now on this computer with that link |
| 15:55 |
Stompro |
I haven't heard from Yamil for a while, Hopefully he is just on vacation. |
| 15:57 |
|
dMiller_ joined #evergreen |
| 16:54 |
Stompro |
Is there a guideline for when working git branches should be purged? I'm assuming that once something gets committed the working branch on git.evergreen-ils.org should be deleted? |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
dbs |
Stompro: that's a good assumption, but in practice very little ever gets purged |
| 17:12 |
Stompro |
dbs, I just thought of one reason not to purge, it would make it harder for someone that is looking at an old resolved bug, that wants to see details of a working branch. Rather than clicking on the link to the working branch they would have to track down the commit manually. |
| 17:18 |
|
bmills joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:14 |
csharp |
bshum: no biggie - I just got a pinesol_green alert and was checking if it was still up |
| 07:17 |
|
mrpeters joined #evergreen |
| 07:31 |
|
Newziky joined #evergreen |
| 10:38 |
csharp |
yep - it did |
| 10:38 |
csharp |
yay! |
| 10:40 |
mmorgan |
csharp++ |
| 10:44 |
csharp |
okay - so now that I know this process, I'm wondering how it could be improved... |
| 10:45 |
csharp |
the problem in my case was that the vendor didn't get the EDI message because we were testing with berick's testing edi_pusher script, which is configured to exit before actually sending anything |
| 10:45 |
csharp |
but there could be many reasons why that would fail, and there needs to be ways to recover from errors |
| 10:46 |
csharp |
e.g., a "Re-Send Order to Vendor" button somewher |
| 10:46 |
csharp |
e |
| 10:47 |
csharp |
I'm pretty sure I was creating new debits each time I re-activated the PO - that obviously shouldn't need to happen to fix a technical mistake |
| 10:55 |
Bmagic |
yeah, if that was on production, you might take a look at the debits for sure |
| 10:55 |
Bmagic |
csharp++ |
| 10:55 |
csharp |
fortunately we're still on a test server, but these are real orders |
| 11:03 |
Bmagic |
Anyone know where to find the logic that displays the columns in the web based staff client? (for grids) |
| 11:04 |
berick |
Bmagic: start w/ the tt2 for the UI |
| 11:04 |
berick |
it sets the behavior for each grid |
| 11:23 |
Bmagic |
right |
| 11:24 |
berick |
IOW, don't use the copy id as the field through which you access the hasholdscount class |
| 11:24 |
Bmagic |
yeah, I think that is my problem |
| 11:24 |
berick |
create a new holds_count (or whatever) field on the copy |
| 11:25 |
berick |
after you get it set up and restart services, I also suggest testing your IDL changes via srfsh queries first |
| 11:25 |
berick |
jumping straight to the web code creates a lot more opportunities for things to fail up front |
| 11:26 |
Bmagic |
right on |
| 11:27 |
Bmagic |
I tested it via srfsh against a new opensrf call I put into the perl, that is working |
| 11:28 |
berick |
e.g. retrieving a copy w/ fleshed call_number http://pastie.org/10221783 |
| 11:28 |
Bmagic |
ah, that helps |
| 11:28 |
Bmagic |
berick++ |
| 15:50 |
|
mrpeters1 joined #evergreen |
| 15:51 |
|
ericar_ joined #evergreen |
| 15:52 |
Dyrcona |
If it turns out to not work as is, we can always change it in the future. |
| 15:52 |
gmcharlt |
FWIW, I've started putting in test plans in my OpenSRF patches |
| 15:53 |
Dyrcona |
gmcharlt++ # I noticed and would have tried it out, but the meeting came up. |
| 15:54 |
gmcharlt |
in other news |
| 15:54 |
gmcharlt |
#action gmcharlt and eeevil to organize a webstaff client hacking day in July |
| 15:56 |
kmlussier |
terran: That's awesome! |
| 15:57 |
|
ericar_ joined #evergreen |
| 15:57 |
kmlussier |
If anyone needs a Sandbox, try to get the requests in by the end of the week so that we have a bit of time to get them ready. |
| 15:57 |
terran |
I'd really appreciate it if someone would test this fix I posted for bug squashing day: https://bugs.launchpad.net/evergreen/+bug/1454871 |
| 15:57 |
pinesol_green |
Launchpad bug 1454871 in Evergreen "KPAC Hold Notifications - SMS" (affected: 1, heat: 6) [Undecided,New] |
| 15:59 |
bshum |
terran: I'll keep my eye on that one, but probably not till next week. Maybe that'll be something we can test during bug day. |
| 15:59 |
bshum |
KPAC loves misery. |
| 15:59 |
bshum |
Err, misery loves company. |
| 15:59 |
terran |
bshum +1 |
| 16:00 |
bshum |
(also, regrets that I'm late and mostly missed the meeting) |
| 16:00 |
berick |
@who loves misery? |
| 16:53 |
gsams |
I'm pretty sure the config is all correct for this purpose, but I have no idea on the user, and further no idea why I'm getting 404 for requests. |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
dbwells |
gsams: what starting point URL are you trying to visit? |
| 17:26 |
jjk` |
I've upgraded a test system code+schema from 2.3.5 -> 2.7.4. I'm expecting to find instructions on how to rebuild indexes and whatnot in the documentaiton but don't see it. I've started the reingest_2.6_bib_recs.sql which I suspect should take quite some time. Should I be able to search & view any records in the opac at this point? |
| 17:35 |
jjk` |
Okay, I'm starting to see some results now. I guess I wasn't being patient enough. |
| 17:48 |
gsams |
dbwells: texasgroup.worldcat.org, if I understand your meaning |
| 17:49 |
gsams |
dbwells: They would go through the catalog to find an item, then request it. They'd then select their library (Roanoke, in my case) and be presented with the authentication, but it 404s instead. |
| 17:54 |
dbwells |
gsams: I don't completely understand your use case, but based on what I've seen in your configs and what you've said, your SPU should be something like: https://catalog.northtexaslibraries.org:2443/login?url=http://texasgroup.worldcat.org Does that allow you to proxy, or is that where you get the 404? |
| 03:27 |
|
jboyer-isl joined #evergreen |
| 03:29 |
|
jboyer_isl joined #evergreen |
| 03:42 |
|
jboyer-isl 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> |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:59 |
kmlussier |
Good morning #evergreen! |
| 07:59 |
kmlussier |
@weather 02771 |
| 11:36 |
hopkinsju |
We do that when all copies are under age based hold protection (and we changed that message to be more clear) but I'm feeling like we need to add something for on order records also |
| 11:39 |
Dyrcona |
Yeah, I think we just have the language when age hold protection comes into play. |
| 11:39 |
mmorgan |
Yes, that's true for us as well. No special language for on order items. |
| 11:39 |
Dyrcona |
berick++ # I have been testing the kill circ script branches this morning. |
| 11:40 |
berick |
Dyrcona: sweet |
| 11:40 |
jboyer-isl |
berick: I've specifically removed everything from our db servers over the years. They don't run anything now except the base system and postgres. We used to generate notices and payment reports directly on them, but that's been gone for some time. |
| 11:40 |
Dyrcona |
Basically, just doing circulations and placing holds. |
| 14:39 |
Dyrcona |
I just clicked on the big downloads graphic, didn't choose anything from a menu. |
| 14:42 |
Dyrcona |
I wonder if the two lines devoted to OpenSRF on the egdownloads matrix/table should be changed to one, with a link to the OpenSRF downloads page. |
| 14:42 |
dbs |
Windows failure was undoubtedly my fault for trying to just slide my VBox image over into virt-manager |
| 14:52 |
csharp |
yeah - I'm trying to convert my .vdi into a working .qcow2 with no success yet - the working instance was installed from scratch |
| 15:04 |
|
ericar joined #evergreen |
| 15:56 |
csharp |
@test |
| 15:56 |
pinesol_green |
csharp: What do you mean? An African or European swallow? |
| 16:00 |
bshum |
csharp: Am I spamming you with my experiments? |
| 16:10 |
bshum |
I was toying briefly with seeing how the Cast plugin operated. Freebase API is going away though end of this month, so meh |
| 17:01 |
kmlussier |
jboyer-isl++ |
| 17:01 |
kmlussier |
@quote random |
| 17:01 |
pinesol_green |
kmlussier: Quote #104: "<jeff> that's it. we're all switching to koha, right meow." (added by gmcharlt at 01:16 PM, January 02, 2015) |
| 17:07 |
ohiojoe |
so I *think* I'm ticklishly close to having an evergreen sandbox installed here.. |
| 17:08 |
ohiojoe |
however, when I do the srfsh test, I'm getting "Received no data from server" |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
ohiojoe |
wait a minute |
| 17:11 |
ohiojoe |
settings-tester is telling me that the libdbi PostgreSQL driver was not found in the shared library path |
| 17:30 |
dbs |
ohiojoe: that test in settings-tester should probably have been removed a long time ago |
| 18:16 |
|
wongon joined #evergreen |
| 19:15 |
|
buzzy joined #evergreen |
| 19:41 |
bshum |
@later tell Dyrcona I forgot, did we ever do anything with https://bugs.launchpad.net/evergreen/+bug/1413336 ? Maybe we should add that towards the next series. |
| 08:17 |
|
ericar joined #evergreen |
| 08:28 |
kmlussier |
devi_: You can't import records from a CSV files. You need to import MARC records. |
| 08:29 |
devi_ |
how to obtain MARC records? |
| 08:31 |
kmlussier |
devi_: If you're setting up a test system to see how it works, there is a test dataset called Concerto that can be used. |
| 08:31 |
devi_ |
I have other system with data and want to migrate to new server |
| 08:32 |
kmlussier |
devi_: OK, there is some info in this email thread here, but basically you would be looking to export the records out of your old system into a MARC format. http://markmail.org/message/ojwvigqpldn6wtsg |
| 08:33 |
kmlussier |
devi_: A lot of it depends on what system you were previously using and how easy it is to obtain the records. But most library systems will already have those records in the MARC format. |
| 12:47 |
Dyrcona |
It might have been in a private conversation. |
| 12:47 |
Dyrcona |
We have a few quotes that lack context in the logs. |
| 12:51 |
kmlussier |
I feel really sad that I haven't had a chance to experience the Armenian staff client yet if it is indeed that pretty. I was hoping I might find a link to a screenshot along with the quote. |
| 12:53 |
bshum |
I don't have a copy of all my IRC logs from that time on this laptop, but Dyrcona is probably right that it was a PM I sent or some other remark. |
| 12:54 |
bshum |
Looking at the log of the day it was added, it was during 2.1's development testing and I think I was testing all the languages for the staff client |
| 12:54 |
bshum |
Trying to figure out an i18n error. |
| 12:54 |
bshum |
That was preventing login or something |
| 12:54 |
bshum |
But I might have gotten my bugs and stories mixed up. |
| 12:57 |
* bshum |
grabs a stock 2.8 client to use to get a screenshot for kmlussier |
| 12:58 |
kmlussier |
bshum: Well, I'm not *that* sad. You don't need to go to the trouble. |
| 12:58 |
bshum |
Ouch |
| 12:58 |
bshum |
Yeah that won't work :) |
| 15:59 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
| 16:26 |
alynn26 |
Everybody have a good weekend. |
| 16:37 |
|
bmills joined #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 20:10 |
|
wongon joined #evergreen |
| 22:00 |
jeff_ |
Bad Friday for he.net / Linode |
| 22:02 |
|
akilsdonk joined #evergreen |
| 13:22 |
Dyrcona |
bshum++ |
| 13:22 |
|
jwoodard joined #evergreen |
| 13:23 |
Dyrcona |
Bmagic: I'm talking about open-ils.circ.actor.user.checked_out, which is in Circ.pm. I'm probably barking up the wrong tree. |
| 13:24 |
jeff |
Dyrcona: what kinds of tests (if any) do you want to see for selfcheck/jspac/craftsman/script-based removal? Just "release notes + live tests / manual testing as appropriate"? |
| 13:25 |
Dyrcona |
jeff: Yeah, I think release notes + live tests (if possible) plus manual testing should do it. |
| 13:25 |
jeff |
Good deal. |
| 13:25 |
Dyrcona |
If anyone can come up with live tests for these, they may make good models to follow in the future. |
| 13:27 |
jeff |
And I'll reply in-bug, but yes -- that jspac removal branch is intended to be sequential, remove legacy self checkout, remove old bbags interface, remove jspac. The bbags interface and/or dtree removal can be their own bugs. |
| 13:27 |
jeff |
I didn't want to get too bug-happy. |
| 13:27 |
jeff |
But I also didn't want it to be one massive "remove all this" commit either. |
| 13:28 |
bshum |
jeff just wants separate karma bumps for each job well done ;) |
| 13:28 |
bshum |
jeff++ # because he's awesome |
| 13:29 |
jeff |
The karma's nice, but having a cleaner codebase is nicer. :-) |
| 13:30 |
* bshum |
likes testing one thing at a time anyways. |
| 13:30 |
jeff |
*nod* |
| 13:31 |
Dyrcona |
heh |
| 13:31 |
berick |
jeff: i'm sure you saw, but I rebased and cleaned up a bunch in bug #1312308 |
| 13:36 |
berick |
ah, cool |
| 13:40 |
Bmagic |
Dyrcona++ |
| 13:40 |
|
ericar_ joined #evergreen |
| 13:44 |
kmlussier |
So test plans for bug fixes go in the commit message? Should they be put on the LP bug too? |
| 13:52 |
|
buzzy joined #evergreen |
| 14:37 |
gmcharlt |
kmlussier: good question, and I think it would be a good to do experiment informally |
| 14:37 |
gmcharlt |
I lean towards putting them in the LP too as a way of further explaining the bug |
| 14:37 |
* kmlussier |
is in the middle of writing her test plan in a commit message and hopes the experiment involves that particular step. |
| 14:38 |
kmlussier |
Yeah, that's where I was leaning. |
| 14:41 |
eeevil |
kmlussier: my thought is, since the author will have the commit message, they could just cut/paste the whole thing. I do that often (laziness being a virtue) |
| 14:45 |
|
Stompro_Home joined #evergreen |
| 15:45 |
|
akilsdonk_ joined #evergreen |
| 16:53 |
kmlussier |
Would there be any objection to my moving bug 1403966 from wishlist to bug? |
| 16:53 |
pinesol_green |
Launchpad bug 1403966 in Evergreen "Search results for metarecord search should exclude publication-specific information from the display" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1403966 |
| 16:55 |
jeff |
kmlussier: none here |
| 16:55 |
kmlussier |
My main goal at the moment is to get in the list of things that can be tested for Bug Squashing Day. If I keep it at wishlist, it's excluded. :) |
| 16:57 |
* kmlussier |
hears the thunder rumble in the distance and decides to leave before the storm arrives |
| 17:00 |
Dyrcona |
Too late. Storm's here. |
| 17:02 |
|
akilsdonk joined #evergreen |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 |
|
mnsri joined #evergreen |
| 17:09 |
|
bmills joined #evergreen |
| 17:43 |
gsams |
Dyrcona: What sort of items get that sort of protection? That seems really short. |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:23 |
|
mtj_ joined #evergreen |
| 07:27 |
|
Callender_ joined #evergreen |
| 07:35 |
|
jboyer-isl joined #evergreen |
| 09:23 |
|
montgoc1 joined #evergreen |
| 09:55 |
kmlussier |
One of our sites is planning to upgrade to 2.8 soon. I looked through the LP bugs and didn't see anything that warranted waiting for the next point release. But I thought I would check with everyone here in case I'm missing something. |
| 09:55 |
kmlussier |
I don know if anyone else is on 2.8 yet other than bshum. |
| 09:56 |
pgardella |
We've upgraded to 2.8.1 in our development environment and are going live with it next week in production. So far, we've not any any issues with 2.8. I was using it extensively at the conference, and we've had two of our libraries testing it. |
| 09:58 |
kmlussier |
pgardella: Thanks! That sounds promising. :) |
| 09:58 |
csharp |
RoganH: what version did you upgrade SCLENDS to? |
| 09:59 |
RoganH |
chsarp: 2.7.5 |
| 11:40 |
mrpeters |
nothing to my apache error logs today, other_vhosts_access.log just looks like normal activity, lots of 200 HTTP requests |
| 11:41 |
jeff |
mrpeters: browser console is where i'd look |
| 11:42 |
jboyer-isl |
mrpeters: This will make a difference, I'm just looking at webby, are you troubleshooting a local install? |
| 11:42 |
mrpeters |
a PINES test server |
| 11:42 |
mrpeters |
it is publicly accessible |
| 11:42 |
jboyer-isl |
ok, never mind me then; I haven't given this a shot yet to know what even can go wrong. |
| 11:42 |
mrpeters |
yeah thats what im trying to learn :P |
| 11:43 |
mrpeters |
interesting |
| 11:54 |
mrpeters |
yes, it is -- |
| 11:54 |
mrpeters |
sorry, was experimenting |
| 11:58 |
berick |
hm, i'm able to override websocket cert problems w/ chrome without using --ignore-certificate-errors |
| 11:58 |
jboyer-isl |
mrpeters: from the look of that section you might be better off using chrome for your testing so long as you have a self signed cert. I don't know if you can tell FF to ignore cert issues for that connection. (maybe if you tried to connect directly?) |
| 11:59 |
mrpeters |
i have certs, so we're all good |
| 11:59 |
mrpeters |
and i wasn't ignoring the docs jeff -- i just happened to do my experimenting before i read them :P |
| 11:59 |
mrpeters |
we are in the mix now! thanks jeff, jboyer-isl |
| 13:18 |
|
jihpringle joined #evergreen |
| 13:32 |
|
pgardella joined #evergreen |
| 13:42 |
Dyrcona |
Fun with git merge: Make a change on a custom branch, decide to cherry-pick that commit into your master branch, merge the custom branch with master, get the new feature commit showing up twice in git log. |
| 13:42 |
csharp |
yep, I've seen that |
| 13:45 |
|
graced joined #evergreen |
| 13:46 |
|
dbwells joined #evergreen |
| 13:46 |
|
buzzy joined #evergreen |
| 14:51 |
|
Newziky left #evergreen |
| 14:52 |
|
maryj_ joined #evergreen |
| 15:08 |
|
wongon joined #evergreen |
| 15:31 |
csharp |
we're reviewing bug 885270 and have applied jboyer-isl 's fix on a test server (about to apply to production)... what I'm not understanding is what is the use case for having the "Patron Registration: Cloned patrons get address copy" setting at all? Isn't the lack of that logic causing the bug in the first place? |
| 15:31 |
pinesol_green |
Launchpad bug 885270 in Evergreen "Delete User Aborts on Shared Address" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/885270 |
| 15:32 |
csharp |
in other words, shouldn't that setting be removed and jboyer-isl's script be added as an optional upgrade script? |
| 15:34 |
jboyer-isl |
jeff has made the point in the past that some users may perfer the old way which can be made to work, but requires more work in the purge user functions. We had no desire to keep the old functionality at all, so I didn't research that very much. |
| 15:12 |
bshum |
jboyer-isl: Ah alrighty. I'll give that a whirl. |
| 15:13 |
bshum |
jboyer-isl++ # thanks! :) |
| 15:13 |
bshum |
awitter++ # spam warrior |
| 15:14 |
jboyer-isl |
Also, oops about the scripts. We don't use them so I didn't test them properly, just copy pasta. |
| 15:16 |
berick |
jboyer-isl: tell me more about this pasta replicator |
| 15:16 |
bshum |
jboyer-isl: No worries, gives me stuff to poke at someday. |
| 15:18 |
Dyrcona |
"Our pasta who art in collander, draining be they noodles..." |
| 15:55 |
bshum |
jboyer-isl: That's what I was contemplating too. |
| 15:56 |
bshum |
Non-SSD storage, but with more than enough RAM to have to deal with major I/O issues. |
| 15:56 |
bshum |
As the tradeoff. |
| 15:56 |
jboyer-isl |
Then there are no concerns about TRIM support, etc. (also, how often do you really hit the disk? ;) ) |
| 16:00 |
|
graced joined #evergreen |
| 16:05 |
jboyer-isl |
I will say for the logs, there's a lot of Pg tuning that you need to do to really make the best use of that much ram. I don't think we're 100% there, but things are in pretty good shape for the most part. (there are still sorting temp files created very occasionally) |
| 16:06 |
jboyer-isl |
My hope is that I can get an identical model for testing, that would be huge. |
| 16:21 |
|
mrpeters joined #evergreen |
| 17:04 |
|
graced joined #evergreen |
| 17:04 |
|
dkyle1 joined #evergreen |
| 17:10 |
|
dkyle1 left #evergreen |
| 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:54 |
|
alynn26 left #evergreen |
| 18:01 |
* berick |
wonders if anyone has used http://sqitch.org/ for any projects. |
| 18:01 |
* berick |
says before disappearing |
| 04:24 |
|
pinesol_green joined #evergreen |
| 04:25 |
|
egbuilder joined #evergreen |
| 04:25 |
|
goood joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:52 |
|
collum joined #evergreen |
| 08:02 |
pgardella |
kmlussier++ for catching my typo |
| 10:33 |
Dyrcona |
Could be a bug with calculating/maintaing mbts.... |
| 10:34 |
Dyrcona |
maintaining, even. |
| 10:34 |
|
pgardella joined #evergreen |
| 10:34 |
berick |
Dyrcona: any chance you could paste/email your test JEDI? |
| 10:34 |
Dyrcona |
berick: Yes, if it fails again. |
| 10:35 |
Dyrcona |
I just built a fresh vm to make 100% sure. I just have to install OpenSRF and Evergreen, etc. |
| 10:35 |
mmorgan |
Hmm. Eyeballing these, looks like they are mostly all backdated checkins. |
| 11:16 |
kmlussier |
dbwells: You must be more human than me. :) |
| 11:17 |
* dbwells |
*more* human than someone? First time for everything :) |
| 11:17 |
kmlussier |
OK, it's me. Apparently, I have something that automatically logs me into that site, which worked fine until we added the math checks. I can disable that. |
| 11:19 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "JEDI I'm testing with" (1 line) at http://paste.evergreen-ils.org/57 |
| 11:19 |
Dyrcona |
berick ^^ |
| 11:20 |
|
dMiller_ joined #evergreen |
| 11:21 |
berick |
thanks Dyrcona |
| 13:08 |
jboyer-isl |
(apparently it is) |
| 13:09 |
bshum |
Heh |
| 13:12 |
Dyrcona |
:) |
| 13:30 |
bshum |
eeevil++ # I'll add your latest patch to our test server for the TT caching |
| 13:31 |
eeevil |
bshum: cool, thanks |
| 13:31 |
bshum |
eeevil: So far, so good anyways. I do feel like it's faster :) |
| 13:32 |
Dyrcona |
I should test that branch out, too. |
| 13:32 |
Dyrcona |
My dev system is pretty slow. |
| 13:32 |
eeevil |
you'll really want http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1452366_preinit_context_loaders plus my last commit on http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1449709-TT-caching-by-egweb |
| 13:33 |
bshum |
eeevil: Yeah I merged all of those, plus all the sprint2 so far published into the same test branch and rolled that out to our main test server. |
| 13:34 |
bshum |
Fun to try things out with a copy of our data :P |
| 13:34 |
eeevil |
rad. the former incorporates the latter, and one more that helps a bunch at apache worker startup |
| 13:43 |
bshum |
eeevil: Hmm, adding those changes breaks my system with an internal server error. |
| 13:44 |
bshum |
From ctx to r anyways |
| 15:00 |
kmlussier |
But during the OpenSRF configuration, I already copied those opensrf files and edited the opensrf_core.xml . |
| 15:05 |
jeff |
you copied different opensrf config files. |
| 15:05 |
Stompro |
kmlussier, the OpenSRF install is not specific to Evergreen, it just gets OpenSRF up and running. (even though it targest the /openils/ dir). When you install Evergreen you are installing new config files. |
| 15:06 |
jeff |
there are example opensrf config files in the opensrf archive which set up basic services designed just to test opensrf |
| 15:06 |
jeff |
there are example opensrf config files in the Evergreen archive which set up evergreen. |
| 15:06 |
kmlussier |
And the two are different? That makes sense. |
| 15:06 |
kmlussier |
jeff++ Stompro++ |
| 15:07 |
jeff |
if you don't install the opensrf config files that come with evergreen, then when you start "all opensrf services" you will get no evergreen opensrf services, you will only get the opensrf services that came with opensrf itself. |
| 15:09 |
dbs |
at one point the docs had a very emphatic "Yes, we know you just did this for OpenSRF. You really do have to do this again for Evergreen." |
| 15:09 |
dbs |
(or something like that |
| 15:10 |
kmlussier |
One of the things I'm doing while running through the install is noting down places where the instructions could be clearer. |
| 15:10 |
dbs |
kmlussier: you committed thoughtcrime |
| 15:10 |
dbs |
thoughtmistake :) |
| 15:10 |
dbs |
"Please refer back to the OpenSRF README and, as the opensrf Linux account, edit the Evergreen version of the opensrf_core.xml file using the same Jabber users and domains as you used while installing and testing OpenSRF.: |
| 15:10 |
dbs |
is the current version of that note |
| 15:11 |
* kmlussier |
probably commits thoughtmistake on an hourly basis |
| 15:12 |
* dbs |
goes into fullblown reallifemistake typically |
| 15:13 |
dbs |
Maybe rather than putting the stuff about "cp -b" in the note in that section of the docs, the "No, really. You have to do this for Evergreen now." should be the called-out note. |
| 10:02 |
pinesol_green |
jeff always wants pancakes. |
| 10:02 |
berick |
Dyrcona++ # RM hat in the ring |
| 10:03 |
jeff |
Dyrcona++ |
| 10:04 |
RoganH |
So, I'm trying to grok how detailed we want pg_tap tests in the non-concerto tests. Do we want tests that ultimately would test for all the tables, indexes, etc...? |
| 10:06 |
bshum |
Hmm, opinions on https://bugs.launchpad.net/evergreen/+bug/1454879 -- bug or new feature? (I'm leaning towards new, since it never displayed that information before, and if so, we should put in release note entry and add it towards 2.next, aka, 2.9) |
| 10:06 |
pinesol_green |
Launchpad bug 1454879 in Evergreen "Account Expiration Date in My Account" (affected: 2, heat: 10) [Undecided,New] |
| 10:08 |
berick |
bshum: i'd call it new as well |
| 10:37 |
pinesol_green |
jwoodard: The current temperature in Nipe Ranch, Krugerville, Texas is 56.5°F (9:36 AM CDT on May 21, 2015). Conditions: Light Rain. Humidity: 90%. Dew Point: 53.6°F. Pressure: 30.19 in 1022 hPa (Rising). |
| 10:38 |
jwoodard |
It was just 85°F and sunny yesterday... |
| 10:38 |
dbs |
timely article on release management stresses in PostgreSQL: http://lwn.net/SubscriberLink/645020/15f0367e0d5affff/ |
| 10:40 |
pgardella |
Hi, all. Trying to track down why many of our action triggers don't work. Namely overdue notices. Our hook=longoverdue.auto ones work. The hook=checkout.due ones do not, not even the example seed one. The action_trigger.event.state is "invalid" when I try to test the action trigger from the staff client. Nothing gets put into action_trigger.event_output, and the gateway.log only has osrf_http_translator 2015-05-21 14:37:42 [ACT:18040:./osrf_htt |
| 10:40 |
dbs |
we still use OpenSRF python for our custom LDAP-based auto-population of actor.usr & friends |
| 10:42 |
pgardella |
Any thoughts on how to debug it further? |
| 10:44 |
kmlussier |
Dyrcona++ # dusting off constrictor. |
| 11:15 |
jboyer-isl |
jonadab: provided you can properly excersize it. We (I!) have issues with that, and that's before you even get to things like race conditions / bugs that lie in wait until the load spikes. |
| 11:16 |
jonadab |
True. |
| 11:16 |
krvmga |
git++ |
| 11:16 |
jonadab |
Although a project like Postgres is widespread enough to have a lot of people testing even the bleeding-edge code. |
| 11:17 |
jboyer-isl |
git++ # in any case though. |
| 11:17 |
bshum |
jonadab: Well, a project like Evergreen occasionally has... bleeding code |
| 11:17 |
bshum |
And bleeding adopters |
| 11:17 |
bshum |
But that's besides the point. |
| 11:17 |
jonadab |
Yes, Evergreen would have more of a problem getting new stuff tested. |
| 11:17 |
bshum |
I forgot what I was trying to say. |
| 11:17 |
bshum |
I just see blood now. |
| 11:19 |
jboyer-isl |
I don't know if Pg is on the list of projects that huge companies are now throwing money at (OpenSSL is where that started) but they probably should be. |
| 13:38 |
bshum |
Or maybe the type of browser you've got |
| 13:38 |
bshum |
Or weird caching |
| 13:39 |
bmills |
bshum: all in https. in firefox now. |
| 13:42 |
bshum |
bmills: Hmm, that sounds suspicious. |
| 13:42 |
bshum |
Unfortunately we do not require passwords for our selfchecks |
| 13:42 |
bshum |
So I don't think I've tested it lately. |
| 13:43 |
bmills |
we only have one library interested in that aspect. otherwise.. |
| 13:52 |
bshum |
csharp: Every time I get a PGCon-announce email, I think to myself, (1) I wish I was going to hear the talks, and (2) I want poutine!!! :( :( |
| 13:52 |
bshum |
csharp: Just a little while to go, you'll have to share all the cool things you see and learn |
| 13:53 |
bshum |
bmills: I'm firing up one of our test servers to see if I can duplicate the problem you see. |
| 13:54 |
bshum |
Assuming of course, I can figure out which setting it is... whee! |
| 13:54 |
* bshum |
sets both settings to TRUE for giggles |
| 13:55 |
RoganH |
bshum: can we give karma to poutine? |
| 13:56 |
yboston |
heads up, the IRC practice time will start at 2 PM EST |
| 13:56 |
bshum |
RoganH: I would.... then I'd eat it. |
| 15:19 |
gsams |
well, one of those |
| 15:19 |
bshum |
bmills: That sounds like it might be a worthy goal... |
| 15:19 |
bshum |
bmills: I haven't encountered it personally, but I guess I don't check out that slowly :) |
| 15:19 |
tsbere |
gsams: I would call the iptables route more tested, though setcap kindof helps to ensure nothing else will use the port instead... |
| 15:20 |
bshum |
I'd say Launchpad that idea, and if you can mock up a quick proof of concept on code, that'd be cool. : P |
| 15:21 |
bmills |
bshum: thanks. mainly encountered the issue with the self check in kids. the piles can get big there |
| 15:21 |
bmills |
bshum++ |
| 15:23 |
gsams |
Now I just have to figure out what went wrong with ezproxy... |
| 15:24 |
* tsbere |
really needs to see about getting his "proxy straight in evergreen" stuff set up for testing somewhere... |
| 15:24 |
tsbere |
I mean, I know it works in theory. I haven't actually tested with real services, though. |
| 15:24 |
jboyer-isl |
gsams: I' |
| 15:26 |
jboyer-isl |
I'd recommend looking into what tsbere mentioned re: iptables and redirection. That way you don't have to run the server as root. We actually have our firewall doing that before requests hit our z39.50 server, so that's another option. (And much more appealing since I think IPtables looks like a social experiment in gaslighting sysadmins...) |
| 15:27 |
jboyer-isl |
Finally reading the rest of the scrollback, that's what he's doing anyway. Ah, well. |
| 15:47 |
tsbere |
Megakeen: I actually wrote a database function to fill "new materials" bookbags based on various criteria for our members. |
| 15:48 |
Megakeen |
I'm looking at a ppt about bookbag buckets now. I'll see what I can come up with. |
| 15:49 |
Megakeen |
My local director expects miracles when I don't have access to anything at the consortium level--nothing on the back end. D: |
| 15:51 |
makohund |
Megakeen: a test server with real data in it that you do have access to would be a nifty thing |
| 15:51 |
Megakeen |
Okay, from what I'm reading it looks like user lists created in-browser in the catalog can be viewed/edited as buckets in the client? |
| 15:52 |
Dyrcona |
Yes, that is true. |
| 15:52 |
Megakeen |
I think that solves my issue, then. The powers that be requested an easier way to add/remove items from the new lists 'cause doing so from the web interface is clunky. |
| 16:43 |
bshum |
And so they give you back junk |
| 16:43 |
bshum |
For us, I think they use specific hostnames to verify that we are who we are. |
| 16:43 |
bshum |
And that their content is allowed on our pages. |
| 16:44 |
gsams |
Yeah, they were planning to pull the eg_vhost file from another site and the award.tt2 file from another site to see if we could figure it out |
| 16:44 |
gsams |
I decided to take a shortcut |
| 16:44 |
gsams |
but I think I know what's wrong, gonna test it |
| 16:45 |
bshum |
Do you have multiple eg_vhost entries for your different virtualhosts? |
| 16:45 |
bshum |
Maybe the variables aren't getting up to the right level |
| 16:46 |
gsams |
The lines they sent me for those two variables had a colon in it that should have been a space |
| 17:04 |
pgardella |
tbere++ |
| 17:11 |
mmorgan |
Hey! NOBLE got karma and I missed it? |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:34 |
|
dkyle1 left #evergreen |
| 17:40 |
|
wongon joined #evergreen |
| 19:05 |
kmlussier |
tsbere++ #Making up for the typo above :) |
| 00:35 |
|
jihpringle joined #evergreen |
| 04:02 |
|
gsams 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:22 |
|
graced joined #evergreen |
| 07:27 |
|
jboyer-isl joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 10:37 |
bshum |
We get a network failure |
| 10:37 |
bshum |
Can't call method \"id\" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line 2536. |
| 10:38 |
bshum |
Looking at that line in Circulate.pm, I find that it's attempting something with the dont_change_lost_zero |
| 10:38 |
jeff |
can you reproduce on a test system and try with and without that setting enabled? |
| 10:39 |
Bmagic |
When we migrate lost items, we make the status "missing" |
| 10:39 |
bshum |
jeff: I'll see if I can find the same item in our test system. Not sure if it's synced enough |
| 10:40 |
Dyrcona |
bshum: I believe the key is in your 3rd line. |
| 10:40 |
Dyrcona |
I'd just change the copy status to missing and try checking it in again. |
| 10:41 |
Dyrcona |
Bmagic++ |
| 11:14 |
mmorgan |
bshum: kmlussier: We migrated "billed" items to a Lost status, but I think we migrated associated transactions for those. |
| 11:15 |
mmorgan |
We haven't run into bshum's issue that I'm aware of. |
| 11:15 |
kmlussier |
Even if it is a flaw in the data migration, I'm worried that there may be several sites that have that flaw. How hard would it be to do a fix so that those flawed migrated items are handled better? |
| 11:16 |
* bshum |
lets his test database churn on a query while he drives over to the office for the next round of meetings... |
| 11:19 |
Bmagic |
bshum: does this help identify the situation you are in? select * from asset.copy where status=3 and id not in(select target_copy from action.circulation) |
| 11:20 |
Dyrcona |
Bmagic: He's doing that one already. Thinks he's missing an index, 'cause it's taking forever. |
| 11:20 |
Bmagic |
I see |
| 11:21 |
mmorgan |
... and found 131 items :-( |
| 11:21 |
* kmlussier |
personally thinks a bug should be filed. |
| 11:21 |
Dyrcona |
I ran this: select acp.id from asset.copy acp where acp.status = 3 and not acp.deleted and acp.id not in (select target_copy from action.circulation) |
| 11:21 |
Dyrcona |
Took 9 seconds on my test database the first time. |
| 11:21 |
* mmorgan |
agrees with kmlussier |
| 11:22 |
jeff |
kmlussier: to answer your question, i don't know -- haven't looked. no objection to a bug being filed as a next step to getting an eye on it. |
| 11:22 |
Bmagic |
yeah, my test db returned 2100 rows in 10 seconds |
| 11:25 |
Dyrcona |
I get 807, and after pulling out dates and doing some sorting, looks like all but 6 come from migration. |
| 11:26 |
Dyrcona |
Most recent one is from July of 2013. |
| 11:27 |
|
bmills joined #evergreen |
| 16:15 |
bshum |
So yeah |
| 16:15 |
bshum |
A sequential scan on 27 million rows of action.circulation apparently takes awhile to work |
| 16:17 |
dbs |
hah |
| 16:18 |
bshum |
I left our test DB running with the query to try finding all the bad "lost" items and it was still running this afternoon when I went to check on it. Around 4+ hours later. |
| 16:18 |
bshum |
So.... I'll think about better ways of finding that faster. |
| 16:18 |
jeff |
what was your query, again? |
| 16:19 |
bshum |
jeff: Mine was a very generic SELECT COUNT(*) FROM asset.copy WHERE status = 3 AND deleted = FALSE AND id NOT IN (SELECT target_copy FROM action.circulation); |
| 16:19 |
bshum |
The scan on getting target_copy from action.circulation is what's slowing me down |
| 16:33 |
bshum |
jeff: Yes, that works, and invokes the index |
| 16:33 |
bshum |
And voila, magic fast |
| 16:34 |
bshum |
Just 35682 copies to deal with... huzzah |
| 16:34 |
collum |
yep. Just ran the same query on my test machine. It runs exponentially faster. |
| 16:34 |
Dyrcona |
Takes only about 1 second less on my data, but that's still an improvement. :) |
| 16:34 |
|
buzzy joined #evergreen |
| 16:34 |
jeff |
yeah. completes in 623ms for me on a very very underpowered test instance. |
| 16:34 |
bshum |
2244 ms. Vs. how 4+ hours and incomplete? Yeah seems like a win. |
| 16:35 |
jeff |
http://i.imgur.com/IW8simF.gif |
| 16:35 |
bshum |
jeff++ |
| 16:58 |
bshum |
And run them whatever |
| 16:58 |
bshum |
Well, edit and run them |
| 16:59 |
jeff |
i'd go with that, yes. |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
bshum |
I should add to the README |
| 17:07 |
bshum |
Little things |
| 17:08 |
bshum |
Like install libemail-sender-perl |
| 11:23 |
Bmagic |
I wonder if the order needs to specify the system in order for the query to identify the shelving ID |
| 11:24 |
tsbere |
Dunno. |
| 11:24 |
tsbere |
Can't even speculate at this point. ;) |
| 11:58 |
berick |
Bmagic: csharp: fyi, pushed more fixes to bug 1373690 (edi template). thanks again for all the testing |
| 11:58 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 12:01 |
kmlussier |
Webby is very slow this morning. Is work being done on it? |
| 12:02 |
phasefx |
kmlussier: don't think so |
| 12:16 |
phasefx |
seems to be okay to me; running to lunch :) |
| 12:18 |
csharp |
well, the biggest problem with branch level copy locations I've seen is that, when combined with system-level cataloging, the copies can end up belonging to another branch's location (when locations are named the same across branches) - but that's fixed in bug 778989 |
| 12:18 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/778989 |
| 12:27 |
csharp |
berick: I'm afraid I'm going to have to wait for Leslie to get back to test correctly - I don't want to risk placing actual orders and confusing people because I don't know what I'm doing :-/ |
| 12:27 |
csharp |
but that said, |
| 12:27 |
csharp |
berick++ |
| 12:28 |
|
sandbergja joined #evergreen |
| 12:31 |
kmlussier |
phasefx: Works now. Thanks! |
| 12:31 |
kmlussier |
phasefx++ |
| 14:52 |
csharp |
Bmagic++ |
| 14:54 |
Bmagic |
gotta stop giving me karma, it's gonna get destroyed, lol |
| 14:54 |
berick |
hah |
| 14:54 |
Bmagic |
let's do all this EDI testing after the karmapocolypse |
| 14:58 |
* berick |
promises to manually carry over Bmagic's EDI karma |
| 14:58 |
Bmagic |
haha, I'm just kidding, I dont care |
| 14:58 |
berick |
ok, down to the last (obvious) problem. fixing.. |
| 15:48 |
bshum |
https://bugs.launchpad.net/bugs/1456289 - if memory serves, Bmagic and I saw this on 2.7 too, and it's cause autogen.sh wasn't run on the system with apache restarted |
| 15:48 |
pinesol_green |
Launchpad bug 1456289 in Evergreen "Tpac "edit" link on record screen does not save changes" (affected: 1, heat: 6) [Undecided,New] |
| 15:49 |
kmlussier |
Ah! I recall that one. |
| 15:50 |
bshum |
I'll put a note on the bug to that effect I guess |
| 15:50 |
bshum |
And we can probably close it with invalid. |
| 16:01 |
bshum |
gmcharlt: eeevil: mllewynn tells me that the vandelay loader for web client works fine (we tested it on our test server). |
| 16:01 |
bshum |
She also says that the flat text editor doesn't stay as the default option when opening additional records (aka, remain checked) |
| 16:01 |
bshum |
But otherwise, the sprint2 stuff so far, so good |
| 16:06 |
Bmagic |
berick: 2.7.0 |
| 16:07 |
|
mrpeters left #evergreen |
| 16:08 |
berick |
Bmagic: thanks |
| 16:14 |
tsbere |
Basically a single-machine brick |
| 16:14 |
tsbere |
I can't even see an *attempt* at making the call in the server logs. |
| 16:16 |
berick |
seems like the CONNECT is failing / not returning, so the .begin is never attempted |
| 16:17 |
jeff |
tsbere: what specific pcrud-based interface(s) are you testing with? |
| 16:18 |
tsbere |
Parts creation. Apparently from any interface you can create parts. |
| 16:22 |
bshum |
Parts... sigh. |
| 16:33 |
* tsbere |
glares at the javascript console of the staff client and the lineless "Transaction begin error" that tells him nothing about which of the four possible points that is generated did so |
| 16:44 |
* tsbere |
glares even more as now everything is working |
| 16:44 |
tsbere |
and nobody changed anything. I have just been trying to find logs. |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
ldwhalen joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:26 |
|
ldwhalen joined #evergreen |
| 16:45 |
|
bmills1 joined #evergreen |
| 16:52 |
Stompro |
My wife just told me I just missed a call from "Microsoft" looking to update my computer, I love talking to those guys, I'm sad I missed it. |
| 16:59 |
mmorgan |
Oh, those "Microsoft" guys really annoy me. |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
buzzy |
soon ... https://twitter.com/EvergreenILS/status/596782856396869632 |
| 17:07 |
Stompro |
buzzy++, first use of the #evgils15 tag, I've been waiting for it to turn up. |
| 17:10 |
kmlussier |
I've opened up voting for which cookies I should make for the MassLNC development partners. More details here https://plus.google.com/+KathyLussier/posts/PCk6Ya3Zivs |
| 23:13 |
bshum |
Once we package new maintenance releases later this month, I expect that it'll be smoother sailing for installation on Debian Jessie. |
| 23:15 |
nuentoter |
ok |
| 23:15 |
nuentoter |
so for me to have a better installation experience right now would you recommend wheezy? |
| 23:16 |
bshum |
nuentoter: For Debian, yes, I believe Wheezy has been better tested by different folks who use Debian. |
| 23:16 |
bshum |
I personally use Ubuntu primarily. So I'll caveat that I've only lightly tested Debians. |
| 23:16 |
bshum |
Though I know others can speak for Debian |
| 23:17 |
nuentoter |
most of my linux experience up until now has only been for very basic things on someones computer running crunchbang which is slick but technical |
| 23:17 |
nuentoter |
i used ubuntu for a few years about 6-7 years ago for work |
| 23:25 |
nuentoter |
ok so tonight i shall download wheezy and resume working on installing of jessie after you folks update |
| 10:45 |
kmlussier |
Ah, I forgot about that bug. |
| 10:46 |
bshum |
kmlussier: These bugs haunt my dreams. |
| 10:46 |
jwoodard |
NTLC aka North Texas Library Consortium in case everyone cannot read my mind or auto guess acronyms ;) |
| 10:46 |
bshum |
jwoodard: I've had some passing familiarity with NTLC ;) |
| 10:55 |
|
akilsdonk joined #evergreen |
| 10:56 |
bshum |
jwoodard: So my recommendation is to mention the issue up your chain of support, and see if they can test your bib/item and see if there are problems with the reingest on that record. |
| 10:57 |
bshum |
Something like: SELECT COUNT(*) FROM biblio.record_entry WHERE deleted = FALSE AND id NOT IN (SELECT source FROM metabib.record_attr_vector_list); |
| 10:57 |
bshum |
Would tell you how many bibs (which are not deleted) do not have a proper corresponding metabib.record_attr_vector_list entry |
| 10:58 |
bshum |
I just ran that on our systems and came up with 13 bibs, which makes me a little sad. |
| 10:58 |
csharp |
yay! 0 in PINES |
| 10:59 |
* csharp |
fully expected to see more than 0 |
| 10:59 |
bshum |
csharp: Amazing! |
| 11:02 |
bshum |
In case you wanted the exact bib IDs for those missing entries |
| 11:02 |
mmorgan |
bshum++ |
| 11:03 |
bshum |
mmorgan: Yeah, if you follow rjackson_isl's steps in his comment on that bug for a post-2.6 system, you can repair those missing entries. |
| 11:03 |
berick |
csharp: have you done any additional testing on EDI since your last comments in bug #1342227 ? |
| 11:03 |
pinesol_green |
Launchpad bug 1342227 in Evergreen "Setting up EDI Fails with Ruby version > 1.8" (affected: 2, heat: 14) [Undecided,New] https://launchpad.net/bugs/1342227 |
| 11:04 |
jwoodard |
bshum: Already sent an email. Proper training and database access are one of the many thing on my list of things to accomplish. |
| 11:04 |
jwoodard |
bshum++ kmlussier++ |
| 11:15 |
jeff |
but i think it's pretty rare. we have two. |
| 11:16 |
* bshum |
thanksfully has 0 |
| 11:16 |
bshum |
And I'll go back to blissfully not thinking about billing weirdness. |
| 11:17 |
csharp |
berick: no - I didn't put together a good way to test on the stock EG master machine I was on |
| 11:17 |
csharp |
berick: I was able to see the daemon running, though |
| 11:18 |
mmorgan |
Whew! we have 0 for jeff's query :) |
| 11:19 |
|
sarabee joined #evergreen |
| 11:20 |
csharp |
0 for jeff's query here too |
