| 08:51 |
|
jwoodard joined #evergreen |
| 08:52 |
mrpeters |
dbwells++ thank you for the great info last night. so, we have retrieve_all, search_, are there others? any documentation on this I can read? |
| 09:11 |
dbwells |
mrpeters: I'm not sure if there is any thorough documentation for that. A few bits and pieces exist in various tutorials, mostly the work of dbs. |
| 09:12 |
mrpeters |
10-4 yeah, he has lots of great stuff for opensrf |
| 09:12 |
mrpeters |
i think i have this working, about to fire up and test |
| 09:12 |
mrpeters |
i was missing declaring my $auth along with $ident_type |
| 09:13 |
dbwells |
mrpeters: The usual CRUD (create/retrieve/update/delete) commands are all available, as well as search, batch_retrieve, and retrieve_all. |
| 09:13 |
mrpeters |
ok, very cool |
| 09:13 |
mrpeters |
well crap, no dice on the alpha sort |
| 09:57 |
tsbere |
csharp: That sounds about right, but I am not looking at that part of the system right now ;) |
| 09:58 |
mrpeters |
is your concern that it would sort the group headings too, because of the way the tree gets built? |
| 09:58 |
csharp |
tsbere: understood - thanks! |
| 10:00 |
tsbere |
mrpeters: Gimme a sec to test something quick. |
| 10:01 |
tsbere |
mrpeters: Yea, a standard sort kindof ignores the "tree" part of things... |
| 10:02 |
mrpeters |
ok, i think phasefx mentioned that in the bug as a possible side effect |
| 10:03 |
mrpeters |
your sort_ident_type branch works perfect, signoff forthcoming |
| 10:03 |
* bshum |
just realized that once alpha sort for ident_type goes in, he will no longer have "Yes" (id 1) before "No" (id 2) in his patron registration. |
| 12:22 |
mrpeters |
so the error message is even less helpful in current master |
| 12:23 |
mrpeters |
im at http://pastie.org/9732735 now -- which is good, i know my window.alert will work, i just need to move it to a proper location since it shows up on a valid, and invalid au.id right now |
| 12:30 |
tsbere |
mrpeters: What interface are we aiming to return to? |
| 12:30 |
Stompro |
mrpeters: Bug 1124498 - I have this almost tested after adding in the repeat delay bit. An event is generated but stays in collected state, just need to figure out how to get it to move on from there. |
| 12:30 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] https://launchpad.net/bugs/1124498 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 12:31 |
tsbere |
mrpeters: I will point out that the "interface" you seem to want (prompt for another ID) isn't actually an "interface" at all... |
| 12:31 |
mrpeters |
tsbere: it is the "Search" > "Retreieve patron by Database ID" |
| 12:36 |
mrpeters |
so wouldnt it be acceptable to bounce you to a window.alert and the portal page for the entry point? |
| 12:36 |
mrpeters |
if invalid |
| 12:36 |
tsbere |
mrpeters: I could argue "send them to patron search instead" but the amount of work to re-make the prompt isn't worth it. :P |
| 12:37 |
mrpeters |
yeah, that would be a fair redirect too. from the way the code looks, i think this might have just been a quick add for someone who was testing something |
| 12:37 |
tsbere |
mrpeters: Basically, "send them to something else, with that something else being uniform across the board" would be fairly easy. Making it know how you got there and sending you back, including to a prompt that isn't even a page, not so much. |
| 12:38 |
tsbere |
mrpeters: Note that the functionality exists (beyond the menu item) for things like "load patron from the hold/circ/whatever" type menus. So whatever is changed needs to take those into account as well, so you can't just make it always prompt for a new ID (or barcode). |
| 12:39 |
tsbere |
Which is why it goes to the main barcode entry box, I think. >_> The menu item causing it to do that is just pre-existing functionality triggering on bad inputs. |
| 13:00 |
Stompro |
kmlussier++ for pointing out the google doc that mmorgan++ created on getting the 30 day pre expire notice working. The Processing Group Context Field needs to be blank, not set to usr. |
| 13:02 |
mrpeters |
oh, nice you guys were able to create that? |
| 13:03 |
mrpeters |
and keep it recurring? |
| 13:07 |
mmorgan |
Stompro: Glad the notes helped! |
| 13:07 |
mmorgan |
we have not yet implemented it, but it worked in testing |
| 13:08 |
mmorgan |
assuming the recurrence will work based upon the interval that now be set in the action trigger. |
| 13:10 |
kmlussier |
mmorgan: What did you set the interval at? I know Stompro asked a question back on what a good interval would be, and I suggested 30 days. |
| 13:10 |
kmlussier |
s/back/a while back |
| 13:13 |
mmorgan |
so I guess that's actually "Event Repeatabilty Delay"? |
| 15:37 |
dbwells |
mrpeters: Thanks for letting me know. I figured you were trying to learn, so I was avoiding looking too deeply into the code. Glad it got worked out. |
| 15:37 |
mrpeters |
i indeed was, i wish i could have figured it out but tsbere saw a faster way and went on and fixed it |
| 15:38 |
mrpeters |
was a good lesson all the way down through the code clear to CDBI perl stuff though |
| 15:38 |
tsbere |
Had I not stumbled on the easy, quick, and correct solution and basically put the right code in place to test if the solution would even work I would have left it more to mrpeters ;) |
| 15:38 |
dbwells |
jboyer-isl: sitem to sunit is one-to-many |
| 15:38 |
mrpeters |
i think your suggestion would have worked for, say a srfsh request of the values |
| 15:38 |
mrpeters |
but i guess that tree unsorts things |
| 01:38 |
|
letsgofightdrag1 joined #evergreen |
| 01:54 |
|
letsgofightdrag1 joined #evergreen |
| 02:21 |
|
letsgofightdrag2 joined #evergreen |
| 05:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:35 |
|
eeevil joined #evergreen |
| 11:06 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 11:23 |
tsbere |
mrpeters: So, I can stop all but the commonStrings ones (usually), but I at least know what causes them! |
| 11:25 |
tsbere |
mrpeters: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/stop_before_remove stops most of the popups. The last of them appears to be caused by the onunload handlers in the pages or subpages due to them trying to run before the page actually finished loading. |
| 11:46 |
mrpeters |
oh man, nice |
| 11:47 |
mrpeters |
ill test and sign-off then, thanks |
| 11:52 |
mrpeters |
was also looking at 506689 -- but should probably see if the behavior exists in the web client too -- would anyone be willing to insert a non-stock config.ident_type value to one of the web client test servers (Bill - Utility Company), perhaps to test the sort order outside of License, SSN, and Other? |
| 11:52 |
mrpeters |
bug 506689 that is |
| 11:52 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] https://launchpad.net/bugs/506689 |
| 12:00 |
|
sandbergja joined #evergreen |
| 12:13 |
* tsbere |
is amazed at finding patrons with a "last circ month" in 1992 in the system |
| 13:00 |
dbwells |
Seems like I've been on a bad run lately, so nice to get something working :) |
| 13:33 |
kmlussier |
dbwells: A bad run? I just figured that was the nature of coding. |
| 13:35 |
RoganH |
The fickle finger of fate foretells fortune foul and fair for all. |
| 13:41 |
jboyer-isl |
mmorgan, are you about? I've got a couple questions about your test results re: bug 1210541 |
| 13:41 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 13:43 |
jboyer-isl |
Alas. I'll look into them when I have time to put a good test together. :) |
| 13:43 |
kmlussier |
jboyer-isl: She's around, but away from her desk at the moment. |
| 13:45 |
jboyer-isl |
ok. |
| 13:46 |
mmorgan |
jboyer-isl: be back in a few minutes ... |
| 14:02 |
gsams |
jboyer-isl: In the system I'm seeing max_delay (evergreen staff client call it Max Event Validity Delay. |
| 14:03 |
gsams |
I'm not seeing a minimum, but if it acts as a minimum wait time that would be an appropriate change in my mind. |
| 14:03 |
mmorgan |
jboyer-isl: The deleted locations still appeared in the interfaces where groups and order could be configured. |
| 14:04 |
jboyer-isl |
mmorgan, Ah, ok. Bummer. Back to my testing then. |
| 14:04 |
jboyer-isl |
Thanks! |
| 14:04 |
jboyer-isl |
mmorgan++ |
| 14:04 |
tsbere |
gsams: I would pick something like 12 hours or so. Or 1 hour more than however long from midnight your a/t runners pick up on the events to go out. |
| 14:04 |
mmorgan |
No, thank YOU! |
| 14:04 |
tsbere |
er, 1 hour less |
| 14:46 |
|
_bott_1 joined #evergreen |
| 14:48 |
|
_bott_1 joined #evergreen |
| 15:25 |
mrpeters |
in register_table.tt2 I'm seeing lots of references to fmclass and fmfield -- I'm taking a leap, and assuming those refer to the fm_IDL.xml, correct? |
| 15:34 |
kmlussier |
Doh. I suppose using an LC classification scheme would make it easier to test this LC Call number fix. |
| 15:38 |
|
vlewis_ joined #evergreen |
| 15:47 |
jeff |
mrpeters: *nod* |
| 15:47 |
jeff |
mrpeters: what brings you into the user editor? |
| 16:10 |
mrpeters |
i think, from retrieve_all_config_identification_type, which i beleive is loaded into memory when you login to the staff client |
| 16:12 |
mrpeters |
and now i'm looking at Storage/CDBI/ stuff which is scaring me :P i think i'm going to dig a hole to china! |
| 16:14 |
mrpeters |
http://pastie.org/9730906 feels like the end of the line... |
| 16:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:55 |
|
akilsdonk joined #evergreen |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:59 |
|
nhilton joined #evergreen |
| 09:21 |
pinesol_green |
csharp: The operation succeeded. Quote #98 added. |
| 09:22 |
jboyer-isl |
mmorgan, just wanted to let you know I haven't been ignoring your update to bug 1210541, but I've not had time to investigate/reply. |
| 09:22 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 09:23 |
jboyer-isl |
mmorgan++ # for testing it |
| 09:23 |
mmorgan |
jboyer-isl: no problem! I am thrilled to see progress on it! |
| 09:24 |
kmlussier |
jboyer-isl++ mmorgan++ |
| 09:24 |
Dyrcona |
If you search the logs you'll find some brief discussion of how we at MVLC solved some of our issues by increasing the limit on the number of files that our opensrf user can have. |
| 09:39 |
jeff |
> Donna appears to say that she is aware of this problem but has found a dishwasher in the White House kitchen that speaks Botok. Mr. Minaldi speaks Portuguese and so does the dishwasher. So Josh and Toby will be able to converse with Mr. Bambang via English-Portuguese-Botok-Portuguese-English. |
| 09:40 |
bshum |
jeff: That was a good episode. :P |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:40 |
jeff |
This is the scene from The West Wing that went through my mind this morning as I was describing to a co-worker how I was successful last night in initial testing with getting an outside vendor to verify patrons in our Evergreen system by emulating the III Patron API. |
| 09:42 |
bshum |
Yeah, that sounds about right. |
| 09:48 |
jeff |
There was a moment the other day where I thought the "Why don't we just speak in English" would have been more appropriate, but no. |
| 09:51 |
csharp |
The_West_Wing++ |
| 10:36 |
jeff |
But I think the long term goal would still be to use technologies that are better with regard to being 1) less niche, 2) better experience for patrons and 3) not gaping privacy/security holes |
| 10:37 |
kmlussier |
Dyrcona: Do you still have the fine generator running overnight on your dev server? |
| 10:37 |
Dyrcona |
It should be. |
| 10:37 |
kmlussier |
Dyrcona: OK, I just wanted to check before I got to far in my testing. Thanks! :) |
| 10:37 |
jeff |
the "other things" for the current reality would include divorcing SIP2 credentials from ILS credentials, giving the ability to filter or limit SIP messages and their responses -- essentially a field-level fine-grained control over what a given SIP client can see and do. |
| 10:37 |
kmlussier |
s/to/too |
| 10:38 |
jeff |
that second bit could either be in SIPServer (with or without need for driver support -- probably depending on where you wanted to do your config) or via a SIP proxy, which would be a bit more complex but have wider benefit to those not running SIPServer |
| 11:07 |
Bmagic |
mmorgan: yes..... |
| 11:08 |
bshum |
Bmagic: The thing that bothers me right now is that when I install a fresh Evergreen master / OpenSRF master, I don't see this bug. So it seems sporadic somehow. |
| 11:08 |
bshum |
Meaning not production data, using concerto or whatnot |
| 11:08 |
mmorgan |
we were testing some code and had made changes to the fm_idl. |
| 11:08 |
kmlussier |
Odd, I just tried the Fast Item Add from the MARC editor and had no problems. |
| 11:08 |
mmorgan |
then we could not save changes to items. We reverted the idl and it fixed the problem. |
| 11:08 |
Bmagic |
kmlussier: are you on 2.7+ ? and OpenSRF 2.4+ ? |
| 11:22 |
jeff |
bshum: wait until it's likely everyone's restarted their staff clients. :-) |
| 11:22 |
bshum |
mllewellyn will definitely be happier ;) |
| 11:22 |
bshum |
jeff: Gah, you're right |
| 11:23 |
* kmlussier |
returns to negative balance testing but thanks Bmagic for the distraction. :) |
| 11:23 |
Bmagic |
The stock js files have the path to the server with the generic /server/ and autogen replaces that with whatever you compled with right? |
| 11:23 |
* bshum |
will wait for the weekend then. |
| 11:23 |
mllewellyn |
mllewellyn will be much happier |
| 09:03 |
csharp |
btw, I'm one who would volunteer to help new devs get things up and running, for the record |
| 09:03 |
wsmoak |
I don’t even know how much it would cost (or how it works) but what about some sort of image that runs on Amazon or Google’s things? |
| 09:04 |
wsmoak |
I’d be willing to pay for the server time (vs. running my own server here, which is probably what it would take…) |
| 09:04 |
csharp |
you could definitely run a test server in the cloud, sure |
| 09:04 |
wsmoak |
but I need my very own instance to break and then press a button and re-make |
| 09:05 |
RoganH |
There are a couple of tools floating around for making VMs that you could do development on. |
| 09:05 |
csharp |
you would need maybe 8 - 16 GB of storage, minimum 4 GB RAM, and 2 - 4 processor cords |
| 09:05 |
mrpeters |
VM's and snapshots are the easy reset button :P |
| 09:05 |
RoganH |
csharp: I thought you were going to break out into 80s power cords there for a minute. :) |
| 09:06 |
RoganH |
berick's scripts pop to mind which I've used |
| 09:06 |
RoganH |
tsbere also has a method that I've heard good things about though I haven't tried it myself. I know kmlussier uses it for building VMs for bug testing. |
| 09:06 |
Stompro |
I really liked the Evergreen VM that used to be available.. but I realize that it takes a bit of work to keep it up to date. |
| 09:07 |
wsmoak |
it needs to not be a separate thing that only new devs ever use … or it won’t get maintained |
| 09:07 |
mrpeters |
yeah the vm thing never worked well |
| 09:12 |
|
maryj joined #evergreen |
| 09:12 |
wsmoak |
basically, I do not want to be a sysadmin. I *can* do those things, I have done, but it’s not what I want to spend my time on these days. |
| 09:12 |
RoganH |
Installing Evergreen really isn't that hard, it's just very time consuming and methodical, hence the tools to speed it up. |
| 09:12 |
RoganH |
Note that these are for doing bug testing and development, not building a production environment. |
| 09:12 |
mrpeters |
i'll give you time consuming for sure |
| 09:13 |
mrpeters |
but, to fix bugs, you should be capable of installing OpenSRF/Evergreen |
| 09:13 |
RoganH |
I agree. |
| 09:13 |
mrpeters |
how are you going to fix something you break if you aren't able to do a scratch install, you know? |
| 09:13 |
Stompro |
I hate editing the xml files... the fact that sometimes it's <password> and sometimes its <passwd>. And dealing with all the ejabberd accounts. |
| 09:14 |
mrpeters |
for me, personally, the solution to the time consuming bit is using VMWare (though Virtualbox would work fine too) and using snapshots |
| 09:14 |
RoganH |
I was trying to point out tools that can help with blasting and rebuilding a test build of Evergreen, not saying that they void the need to have the underlying skills. |
| 09:14 |
wsmoak |
:::shrug::: I don’t really want to fix bugs. I want to play with it and write against the api and see how it all works and *then* maybe get more involved. |
| 09:15 |
mrpeters |
no, I agree with you RoganH. Once you can perform the install once, no need to repeat it over and over again (though, it does become like muscle memory to install Evergreen eventually haha) |
| 09:15 |
RoganH |
using Virtual Box snapshots can work most of the time as well though I'd argue sometimes it's good to just be able to do a quick new build from git |
| 09:21 |
wsmoak |
… but that leans a lot on Java’s built-in stuff I know, with the ability to swap out data sources easily |
| 09:21 |
RoganH |
If you're running OSX virtual box is your friend. |
| 09:21 |
mrpeters |
heck yeah it is |
| 09:21 |
csharp |
wsmoak: we do have a test dataset (not automatically installed by the .deb package, fwiw) |
| 09:21 |
RoganH |
You can pay for VMWare (I used to) but Virtual Box has gotten so good in the last few years. |
| 09:22 |
mrpeters |
when i was at ISL my "master" server for submitting new patches, development, etc. was just a virtualbox VM on their OS X server |
| 09:22 |
mrpeters |
csharp: we could make the test data load SO easy. There is a flag now for eg_db_config to load all of that |
| 09:22 |
mrpeters |
i discovered it monday |
| 09:23 |
mrpeters |
--load_all_test or something |
| 09:23 |
mrpeters |
we could add that to our debs pretty easily i think |
| 09:23 |
csharp |
yep |
| 09:24 |
mrpeters |
maybe have it set up so you can do an apt-get install evergreen-ils and apt-get install evergreen-ils-populateddb |
| 09:24 |
csharp |
I wonder if it should be a separate deb, though |
| 10:00 |
jboyer-isl |
mrpeters, Probably a URI if you want to be picky, I can never remember the difference |
| 10:00 |
mrpeters |
heh yeah |
| 10:03 |
Stompro |
Does anyone have a "New Patron Welcome Email" notice that they use? We currently try to email a new customer right away, so that if their email is bad the staff have a chance to fix it while the customer might still be in the building. I just need to figure out if that is possible with action triggers. |
| 10:04 |
mrpeters |
so, if gpls were to host a deb of the current "stable" release with and without test data would the community advertise that as a "quick start" or would that still meet resistance because it doesn't account for installing the software, and could **potentially** cause someone to accidentally upgrade the package when they didn't intend to |
| 10:06 |
Stompro |
mrpeters: I'm pretty new, but I would support that and I would help add it to the community install docs. |
| 10:06 |
kmlussier |
berick++ |
| 10:07 |
Stompro |
mrpeters: would it be Ubuntu only or could Wheezy and Jessie users make use of it? |
| 10:08 |
mrpeters |
we would have to build seperate debs for those, i think |
| 10:08 |
mrpeters |
debian has some slightly different install steps |
| 10:08 |
bshum |
mrpeters: I think that's an interesting offer. Though I'm always curious to see the deb building process you guys have come up with in action. |
| 10:08 |
mrpeters |
I could make a demo video |
| 10:09 |
mrpeters |
i just hate hearing my own voice narrate it....and today is NOT the day to do that....60 degrees to 22 degrees in 12 hours did not help my throat |
| 10:11 |
mrpeters |
there is a little work done (Andy Witter usually handles it) to build any new debs for things that would normally get installed from source (spidermonkey, etc.) but if those don't change much from version to version, its really just grab the tarball and put it in a certain location and then run a script |
| 10:11 |
mrpeters |
you can pick "cluster" or "single server" |
| 10:11 |
mrpeters |
for the repo, its single server |
| 10:12 |
mrpeters |
only half of that I don't have a lot of knowledge on yet is the actual apt archive |
| 10:12 |
mrpeters |
not sure where Andy sticks the built debs up to update the repo |
| 10:13 |
mrpeters |
i just tell him hey, i built the 2.7.1a debs can you update the repo and link him my deb |
| 10:14 |
mrpeters |
one thing that would be cool, and im not sure if it could be done, is to have ALL of the old debs still there too, so you could do say, apt-get install evergreen-ils-2.0.4 and get the 2.0.4 build installed |
| 10:14 |
mrpeters |
wouldn't see many reasons to do that, other than nostalgia or testing "did this act differently before?" but could be handy |
| 10:17 |
bshum |
With deb files, wouldn't the version be part of the package name though? |
| 10:17 |
bshum |
Usually |
| 10:18 |
mrpeters |
yeah, i think traditionally it is |
| 12:43 |
tsbere |
kmlussier: I would argue then that the setting is horribly mis-named, then, because it isn't acting like a copy. |
| 12:44 |
* kmlussier |
notes that all of the examples in the docs at http://docs.evergreen-ils.org/2.7/_cataloging_electronic_resources_8201_8212_8201_finding_them_in_catalog_searches.html#_adding_a_located_uri_to_the_record were working as described back in the summer. |
| 12:44 |
jeff |
are they no longer working as described? |
| 12:44 |
kmlussier |
tsbere: If the subfield 9 is set to the consortium without the setting enabled, then it will show up in searches all the way down the org tree. But if it's set at a system or branch level, it only travels down, not up. |
| 12:45 |
kmlussier |
jeff: I believe they are. I haven't tested it since then. |
| 12:45 |
kmlussier |
tsbere: If you enable the setting, then the resource shows up both up and down the org tree. So if it's owned by a system and you search the consortium, it still shows up. Like copies do. |
| 12:45 |
tsbere |
kmlussier: As far as I know, copies only travel "up", not "down", so if the setting makes them travel *both* ways then URIs aren't acting as copies. |
| 12:46 |
tsbere |
kmlussier: Which would make the setting's name horribly wrong. :P |
| 12:46 |
kmlussier |
tsbere: If your search is scoped to the consortium, you don't see copies owned by a branch? |
| 12:52 |
tsbere |
jeff: I seem to recall it only shows up when scoped to the top of the tree. |
| 12:52 |
* tsbere |
has done stuff like that before |
| 12:54 |
kmlussier |
I guess the specific name of the settings was used to show how enabling it differs from default behavior. The default behavior is what makes the electronic resource show up in searches higher up the org tree. Enabling the settings is what allows it to travel down, as copies do. |
| 12:56 |
tsbere |
kmlussier: My (current) point being that the name and description *don't match what it does* - Copies by default travel "up" the tree, URIs by default travel "down" the tree, that option tells URIs to travel "up AND down" the tree. That is not acting like copies. That is acting like a combination of copies and URIs at the same time. |
| 12:58 |
* tsbere |
is assuming that kmlussier's assertion about things is true, BTW, and has not tested or dug the actual code up at this point |
| 13:00 |
dbwells |
I agree with tsbere that the setting doesn't really do what it claims. Anyone interested in all the various cans of worms should check out ldw's bug #1353643. I suspect the fallout from that will clarify the original setting as well. |
| 13:00 |
pinesol_green |
Launchpad bug 1353643 in Evergreen "URI $9 displayes too many links in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1353643 |
| 13:05 |
* eeevil |
is running to a doctor's appointment (already late) but the setting is to make URIs act like copies /in that/ they scope "down". it doesn't remove the "up" scoping, though. electronic resource limiting is about modeling access rights, where the uri owner (and it's subordinates) should have access |
| 14:24 |
kmlussier |
bug 1171984 |
| 14:24 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 - Assigned to Liam Whalen (whalen-ld) |
| 14:24 |
kakes |
kmlussier: who do you think is working on the overlay? |
| 14:25 |
kmlussier |
Are there still issues for the LC Call number group once dbwells's code is tested and merged? |
| 14:25 |
Stompro |
gmcharlt: Thanks for reviewing and committing the KPAC setup docs. gmcharlt++ |
| 14:25 |
kmlussier |
Sorry, that's the next agenda item. I withdraw the question. |
| 14:25 |
dbs |
#info dbs = Dan Scott, Laurentian University (with coffee in hand, finally) |
| 14:32 |
yboston |
yes |
| 14:32 |
yboston |
I finally put in a bug for issues searching LC calnumbers in OPAC numeric searches; bug 1389403 |
| 14:32 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:32 |
yboston |
I then added a link inside the bug to some test code that Dan Wells wrote to address the issue. I saw that Kathy tried testing that code during the EG bug squashing day. |
| 14:32 |
yboston |
I still need to query the community to see what other LC call number issues need to be addressed |
| 14:33 |
kmlussier |
I still owe a response to dbwells regarding what we're seeing in the logs. |
| 14:33 |
yboston |
and I made a basic wiki page for this group too |
| 14:33 |
kmlussier |
I think I sent out a query to the Evergreen community. |
| 14:36 |
pinesol_green |
Launchpad bug 1352542 in Evergreen "Printing: LC Call number formatting (2.5.2)" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1352542 |
| 14:37 |
dbs |
dbwells: are we normalizing the incoming call number label? /me isn't seeing that immediately in supercat |
| 14:38 |
remingtron |
dbwells is in a meeting at the moment |
| 14:38 |
yboston |
since we have one definite open bug, and one bug that has a fix awaiting more testing, we can keep the group open for now |
| 14:38 |
kmlussier |
DonB: Since you semi-volunteered up above, is this something you want to work through. At this time, I'm thinking it's primarily about identifying specific issues that are still out there. |
| 14:39 |
yboston |
I am sure there are other bugs I could report if I talk to the cataloger here, though she is on maternity leave right now |
| 14:39 |
* dbs |
sees that that's what the patch from dbwells is trying to do; seems reasonable |
| 14:42 |
pinesol_green |
[evergreen|alzr] LP#1207529: Add /openils assumption note - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e38ec30> |
| 14:42 |
yboston |
you being Kathy |
| 14:42 |
yboston |
we were all new like you once |
| 14:43 |
kmlussier |
#action kmlussier to post testing feedback for dbwells on bug 1389403 |
| 14:43 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:43 |
kmlussier |
Got it. |
| 14:43 |
kmlussier |
Those are all the sub-groups then. |
| 16:01 |
dbs |
jihpringle: cool, thanks -- that's a pretty impressive set |
| 16:06 |
|
jwoodard joined #evergreen |
| 16:33 |
|
mdriscoll left #evergreen |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:20 |
|
buzzy joined #evergreen |
| 18:01 |
|
kmlussier joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:36 |
|
wsmoak joined #evergreen |
| 06:37 |
|
eeevil joined #evergreen |
| 06:37 |
|
mtate joined #evergreen |
| 08:28 |
|
mdriscoll1 joined #evergreen |
| 08:30 |
|
graced joined #evergreen |
| 08:35 |
|
Stompro joined #evergreen |
| 08:37 |
bshum |
Stompro: I'm generally +1 to using the PostgreSQL apt repo and suggesting others to use newer PostgreSQL versions as long as the community users have had enough time to check things are working well. |
| 08:37 |
bshum |
The trick is just getting enough testing done for all the combinations. |
| 08:39 |
bshum |
That said, adding an extra repo might be more work than needed for some folks if the main repository for a given distribution already contains a reasonably new enough version of PostgreSQL. |
| 08:39 |
* bshum |
is of many minds on much of this. |
| 08:42 |
bshum |
Might be a good question to ask during the developer meeting this afternoon... |
| 08:44 |
Stompro |
bshum: Thanks, I'll work on something for the upgrade/install docs. |
| 08:44 |
|
artunit joined #evergreen |
| 08:45 |
|
mmorgan1 left #evergreen |
| 11:34 |
bshum |
Aha, okay |
| 11:34 |
bshum |
So that's why we haven't noticed that issue yet. |
| 11:34 |
bshum |
We're still doing it the old way |
| 11:34 |
mrpeters |
yeah, they both work well, im just more comfortable with this method |
| 11:35 |
mrpeters |
you can get some MONSTER xsl sheets when you're doing test's all throughout them |
| 11:35 |
jboyer-isl |
Ah. mrpeters just wrap that circ.target_copy.call_number.label in helpers.escape_xml() and it will be fine. (but the old notices will stay busted.) |
| 11:35 |
jboyer-isl |
In the A/T template, that is. |
| 11:35 |
mrpeters |
jboyer-isl: oh, sweet...i can do that |
| 14:09 |
bshum |
I know I need more time to digest things on that |
| 14:09 |
* dbs |
disappears to do some hardware stuff, grr |
| 14:10 |
bshum |
Let's defer on that subject till we get some more time to read through and respond to the latest? |
| 14:10 |
kmlussier |
I plan to test it soon, but I haven't had a chance look closely enough to come up with any questions yet. |
| 14:10 |
bshum |
Though I think for the action item, it's settled since it looks like dbwells did update the bug with new details. |
| 14:10 |
bshum |
Next past item |
| 14:10 |
bshum |
#info gmcharlt to release OpenSRF 2.4 when ready |
| 14:44 |
Dyrcona |
It points at something of mine that no longer exists. |
| 14:44 |
kmlussier |
The OPW wiki isn't an ideal place to share these scripts. If we think they might be useful to people, then maybe adding them to the install docs or the readme, as dbs previously suggested, is a good idea. |
| 14:45 |
* Dyrcona |
puts curmudgeon hat on. |
| 14:45 |
Dyrcona |
I think the current installation procedure is a good test for potential developers. |
| 14:46 |
Dyrcona |
If you can't follow a README, do a manuals installation, and troubleshoot issues, you're going to have a very hard time later figuring out why your code broke something. |
| 14:46 |
kmlussier |
Dyrcona: The curmudgeon hat suits you. :) |
| 14:47 |
Stompro |
Dyrcona: I understand your view, but if people give up during the install phase, then there is never the possibility of them contributing at all. |
| 15:10 |
|
Christineb left #evergreen |
| 15:15 |
kmlussier |
krvmga: When I look at http://bark.cwmars.org/eg/opac/record/3254422?query=frozen%20-kjklfjdkaljfd;qtype=title;fg%3Aformat_filters=10;locg=1;expand=marchtml#marchtml, I still see a 246 with Disney Frozen |
| 15:16 |
krvmga |
kmlussier: yes, jschrader added other 246 fields without "Disney" in them |
| 15:17 |
kmlussier |
I would leave one 246 there that just says Frozen as a better test. |
| 15:18 |
bshum |
parts++ |
| 15:18 |
kmlussier |
Heh...I was going to wait until you were on the road to do that. |
| 15:18 |
krvmga |
kmlussier: she's not in the office today. when i see her next, we'll try and see. |
| 16:04 |
|
nhilton joined #evergreen |
| 16:34 |
|
nhilton_ joined #evergreen |
| 16:50 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
|
mdriscoll1 left #evergreen |
| 17:02 |
|
mtcarlson joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 00:39 |
|
artunit_ joined #evergreen |
| 02:15 |
|
eby_ joined #evergreen |
| 02:38 |
|
rangi` joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:35 |
|
eeevil joined #evergreen |
| 06:48 |
|
wsmoak joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 08:55 |
csharp |
yes |
| 08:56 |
csharp |
oops - "yes" was meant for another window ;-) |
| 09:02 |
|
ericar_ joined #evergreen |
| 09:13 |
remingtron |
super old bug 921142 (heat 44!) ready for testing/pushing |
| 09:13 |
pinesol_green |
Launchpad bug 921142 in Evergreen 2.4 "Fixed fields are required to have all positions entered. " (affected: 6, heat: 44) [Medium,Confirmed] https://launchpad.net/bugs/921142 |
| 09:22 |
|
mrpeters joined #evergreen |
| 09:23 |
jeff |
next time, on "this old bug" |
| 11:02 |
|
maryj joined #evergreen |
| 12:41 |
|
nhilton joined #evergreen |
| 12:43 |
|
mrpeters joined #evergreen |
| 13:13 |
csharp |
did anyone ever mirror the old SVN repo site? I'm wondering if some old PINES development is still recoverable |
| 13:15 |
csharp |
specifically, I'm looking for the bad debt interface that was briefly alive on our test server c. 2009 |
| 13:28 |
bshum |
csharp: Yeah I think MVLC has a mirror of the SVN |
| 13:28 |
bshum |
Or a converted git copy anyways |
| 13:28 |
bshum |
But I'm not sure |
| 13:45 |
csharp |
I'm sure I just have a simple config option wrong |
| 13:45 |
csharp |
and I'm doing copy paste coding right now without really knowing the knobs and switches for apache/mod_perl |
| 13:52 |
eeevil |
csharp: that looks fine |
| 13:52 |
csharp |
ok thanks |
| 13:56 |
|
Stompro_home joined #evergreen |
| 14:13 |
csharp |
ah - that's interesting - no interface loads, but if I add anything to the url (e.g. https://test-brick01-head/baddebt/test), I get a downloaded CSV file that says Upload Failure |
| 14:14 |
csharp |
I don't understand enough about perl/CGI to know how to get the show_template subroutine to work |
| 14:21 |
csharp |
okay, so I can see that it at least is running the handler subroutine, but I don't see where show_template is invoked in that |
| 14:23 |
eeevil |
csharp: it seems it's not. http://pastie.org/9712488 should do it. I'll look at the git history right quick |
| 14:25 |
csharp |
eeevil++ # that did it |
| 14:25 |
eeevil |
cool. if you bug it I'll toss up a branch, eh? |
| 14:27 |
csharp |
sure thing |
| 14:28 |
csharp |
well, after I figure out why my test.csv file resulted in "Upload Failure" ;-) |
| 14:28 |
csharp |
ah - yeah, we're suffering bitrot here: Method [open-ils.cstore.direct.money.billable_xact.retrieve] not found for service open-ils.cstore |
| 14:29 |
csharp |
I'll look into it, now that I've got the scent ;-) |
| 14:31 |
jeff |
downtrodden and bitrotten |
| 14:32 |
eeevil |
ah, well, that'd be ungood to continue using in any case. it needs to be moved to pcrud re "no more private services in mod_perl" (but that's a broader project which will likely include IDL changes) |
| 14:32 |
csharp |
oh - ok |
| 15:21 |
hopkinsju |
Pssh. More like Google Earth |
| 15:21 |
bshum |
If my client is any indication |
| 15:21 |
dbs |
csharp: mebbe! |
| 15:22 |
csharp |
I have a crazy ticket in from one of our libraries where the production client is auto-updating itself to the test client version |
| 15:22 |
bshum |
I think there are some fun color/font addons you can use from Firefox to make your staff client more interesting looking :) |
| 15:23 |
csharp |
they swear that they aren't caching anything, but it's happening now when the test server is completely down |
| 15:23 |
dbs |
"evergreen -ProfileManager" to create a new profile maybe |
| 15:23 |
bshum |
It could be a bad upgrade path |
| 15:23 |
bshum |
Or cross-shared hostname/versions between your test and production environments. |
| 15:23 |
csharp |
I've tried to recreate the issue with no success |
| 15:23 |
bshum |
Like go to the test server to get your updates |
| 15:23 |
hopkinsju |
Do you have the test client build on the production server by mistake? |
| 15:23 |
csharp |
autoupdate host on the production clients is next.gapines.org... oh |
| 15:23 |
bshum |
Or like the test server client was installed with the same path as production |
| 15:24 |
csharp |
s/production clients/test clients/g |
| 15:24 |
csharp |
I wonder if they've been using test clients from last year's upgrade with the next.gapines.org path this whole time |
| 15:25 |
bshum |
Could be |
| 15:25 |
csharp |
huh - that's a distinct possibility |
| 15:25 |
csharp |
I only have random screenshots |
| 15:25 |
* bshum |
loves the time that a library was using the test server hostname as production for a few days before we noticed things seemed... wrong. |
| 15:26 |
csharp |
OMG, that's happened to us too |
| 15:26 |
bshum |
That's why I have completely different stamping now for our test group and production groups. |
| 15:26 |
csharp |
I thought about that, but I didn't want to create a stumbling block for testing |
| 15:26 |
* bshum |
wants more Evergreen staff client logo colors. |
| 15:26 |
bshum |
Red and orange/yellow aren't enough! |
| 15:27 |
bshum |
But yeah |
| 15:27 |
bshum |
I use rigbeta for my test server clients |
| 15:27 |
bshum |
And rigrelease for my regular production ones |
| 15:28 |
bshum |
So any red icon'd staff client for us is a test one |
| 15:28 |
bshum |
And orange/yellow = production |
| 15:28 |
bshum |
But as you say, we don't have nearly as much end-user library testing as we'd perhaps wish for. |
| 15:29 |
csharp |
we use the red icon for testing too |
| 15:30 |
jeff |
one of our "test before upgrade" setups had a garish yellow background in many staff (especially circ-related) interfaces to avoid the "oops, did production work in test env" situation. |
| 15:30 |
jeff |
but it would be nice to have support for that baked in, maybe as a new feature in the web client. |
| 15:31 |
jeff |
pre-login/post-login message / banner / popup, banner across the entire top of the page, or some combination of those things. |
| 15:33 |
bshum |
Hmm |
| 15:33 |
bshum |
I don't see why not |
| 15:35 |
csharp |
we used to use the "reddish" opac theme on our test server, but that didn't help from the client |
| 15:35 |
bshum |
Oh that's a throwback to the old days :) |
| 15:35 |
bshum |
I guess those files still exist. We need to finish ripping all that out sometime... |
| 15:36 |
csharp |
so theoretically, if the client has next.gapines.org in its autoupdate.js file, it might grab those update files even if it's logging into gapines.org? |
| 15:37 |
csharp |
well, the next server hasn't been updated since last year |
| 15:37 |
bshum |
Since that's where it'd check towards |
| 15:37 |
bshum |
Not the hostname you enter |
| 15:37 |
csharp |
right |
| 15:37 |
csharp |
okay - this is making more sense now |
| 15:39 |
csharp |
it never occurred to me that staff would be using test clients in production without realizing it |
| 15:39 |
csharp |
but we've never disallowed them in production either (via symlink) |
| 15:40 |
bshum |
Indeed. |
| 16:33 |
* jeff |
laughs at himself |
| 16:37 |
|
kmlussier joined #evergreen |
| 16:38 |
kmlussier |
dbwells++ |
| 16:39 |
kmlussier |
I'll try to fit in testing the new Negative Balance branch as soon as I can. |
| 16:39 |
* kmlussier |
disappears again. |
| 16:43 |
jeff |
mumble mumble billing mumble mumble |
| 16:43 |
jeff |
mous and mus can differ when there are closed xacts with non-zero balance_owed. |
| 16:44 |
jeff |
and the number of users where SUM(mmbxs.balance_owed) <> mous.balance_owed is different from the number of distinct users where mmbxs.xact_finish IS NOT NULL AND mmbxs.balance_owed <> 0 |
| 08:24 |
bshum |
Fair enough, just checking. |
| 08:25 |
* bshum |
is always antsy when it comes to backporting SQL upgrades to older versions. |
| 08:28 |
|
mdriscoll joined #evergreen |
| 08:28 |
csharp |
bshum: fwiw, I tested in master and 2.5.1 when I signed off |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:30 |
bshum |
csharp: For your addition, putting the DROP TRIGGER IF EXISTS in the base schema, do we need that in the base schema? I figure we don't need it when creating fresh DBs |
| 08:30 |
bshum |
Definitely handy for the upgrade script though |
| 10:00 |
kmlussier |
mmorgan++ #Thanks! |
| 10:01 |
kmlussier |
yboston: You're assigned to bug 1287791. Are you still looking at that one? |
| 10:01 |
pinesol_green |
Launchpad bug 1287791 in Evergreen "More right-click authority cleanup" (affected: 1, heat: 8) [Medium,Confirmed] https://launchpad.net/bugs/1287791 - Assigned to Yamil (ysuarez) |
| 10:01 |
* kmlussier |
can load it on a Sandbox if you want to test it. |
| 10:01 |
yboston |
no, I would need the help of one of the catalogers here, but they are not available |
| 10:02 |
kmlussier |
yboston: OK, should I remove you for now in case somebody else wants to test it? |
| 10:02 |
yboston |
yes |
| 10:04 |
kmlussier |
Hmmm...I might be able to test that one if there were more info in the bug report on what I should be looking for. |
| 10:13 |
csharp |
looks like bug 1175308 is relevant |
| 10:13 |
pinesol_green |
Launchpad bug 1175308 in Evergreen "MARC editor right-click authority search is confusing" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/1175308 |
| 10:18 |
kmlussier |
csharp: Thanks, that helps a little bit, but still doesn't tell me the problem bug 1287791 is trying to solve. I'll post a comment on the bug to see if I can get more details. |
| 10:45 |
* tsbere |
probably doesn't have time to obtain said understanding at the moment either |
| 10:46 |
csharp |
tsbere: understood |
| 10:54 |
eeevil |
kmlussier: the pre-patch bug is that we were searching on all subfields, not just controlled ones, with the right-click. so, extraneous (from the authority POV) breaks the search |
| 10:54 |
kmlussier |
eeevil: OK, thanks. If I have a moment, I'll see if I can replicate it then test the fix. |
| 11:08 |
jeff |
nice thing about trying to use gmail keyboard shortcuts in irc, since most don't involve an Enter, you have a chance to catch your mistake before sharing it with the world. |
| 11:09 |
mrpeters |
lol jeff |
| 11:09 |
mrpeters |
i always liked the gmail labs app to solve a math problem before you send |
| 11:26 |
kmlussier |
eeevil++ #Helping to rescue paxed's patch |
| 11:26 |
* mrpeters |
tries to install Evergreen without OpenSRF -- fail! |
| 11:27 |
mrpeters |
im spoiled not installing by hand anymore heh |
| 11:37 |
eeevil |
kmlussier++ # testing patches! |
| 11:37 |
|
sandbergja joined #evergreen |
| 11:40 |
kmlussier |
eeevil: Heh, I'm actually doing very little testing today, but maybe I can get some done this afternoon. |
| 11:43 |
mrpeters |
hrmmm |
| 11:43 |
mrpeters |
14.04 not liking OpenSRF master |
| 11:43 |
mrpeters |
checking for apache2... no |
| 12:29 |
pinesol_green |
Launchpad bug 1208915 in Evergreen "Apache 2.4.6 warns about eg.conf" (affected: 2, heat: 10) [Undecided,New] |
| 12:29 |
bshum |
Actually yeah nevermind |
| 12:29 |
bshum |
I got it |
| 12:30 |
berick |
i have a jessie vm i can test on if needed |
| 12:30 |
bshum |
We already fixed it in another bug |
| 12:30 |
bshum |
Looks like a dupe remnant |
| 12:31 |
berick |
cool |
| 12:50 |
mrpeters |
anyone else using opensrf/evergreen master (as of today) on 14.04? getting nothing relevant in logs about this 500 error |
| 12:50 |
mrpeters |
apache 2.4.7, fwiw |
| 12:51 |
* csharp |
learns that "propagation" of authority records is limited to linking with bibs |
| 12:51 |
bshum |
mrpeters: My test VM is 14.04 with master as of a few days ago and have no errors. |
| 12:51 |
mrpeters |
opensrf master too? |
| 12:51 |
bshum |
Yes |
| 12:51 |
mrpeters |
damn, i hate wasting half a day i could have been looking at bugs trying to get this running |
| 13:33 |
dbs |
could be that the servers are overloaded because of the Firefox Dev release today :? |
| 13:37 |
Dyrcona |
Could be.... |
| 13:38 |
kmlussier |
jihpringle: Do you use the Load Catalog Record IDS interface in acq at all? |
| 13:38 |
jihpringle |
we've testes it but don't really use it |
| 13:38 |
jihpringle |
testes = tested |
| 13:38 |
csharp |
hmm - that setting is not stopping authority propogation - looks like if the reingest on same marc setting is enabled, it just powers through |
| 13:39 |
* csharp |
consider re-adding the old setting |
| 13:39 |
kmlussier |
Ah, ok. We don't use it much either, but I'm noticing that it has a "Load more terms" button. The label doesn't make sense to me. |
| 14:50 |
eeevil |
the mines, they are ready |
| 14:50 |
csharp |
thanks |
| 14:50 |
csharp |
;-) |
| 14:53 |
* mmorgan |
resurfaces from testing lp 1210541 if anyone wants to have a look. |
| 14:53 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 14:53 |
mmorgan |
jboyer-isl++ |
| 14:55 |
jboyer-isl |
Stompro++ for finding the seed data damage I left in there. |
| 16:41 |
bshum |
Looks reasonable to me. |
| 16:42 |
mmorgan |
Invalid it is! |
| 16:42 |
|
kbutler joined #evergreen |
| 17:12 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:13 |
|
mmorgan left #evergreen |
| 17:21 |
|
nhilton_ joined #evergreen |
| 18:09 |
|
artunit joined #evergreen |
| 20:53 |
|
mmorgan1 joined #evergreen |
| 20:58 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1012308: Teach the staff client to use titlesort - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b343d1c> |
| 20:59 |
bshum |
Calling 0897 |
| 21:06 |
pinesol_green |
[evergreen|Chris Sharp] LP#1391290: Respect setting to disable authority propagation on reingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b72d5f6> |
| 21:06 |
pinesol_green |
[evergreen|Ben Shum] LP#1391290: Stamping upgrade script for authority reingest setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=afe883f> |
| 21:06 |
|
geoffsams joined #evergreen |
| 21:11 |
|
sarabee joined #evergreen |
| 21:22 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1386260: DST bugs in perl live tests (03-overdue_circ.t) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af46860> |
| 21:22 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1386260: DST bugs in perl live tests (04-overdue_with_closed_dates.t) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=600b508> |
| 21:22 |
bshum |
Maybe now we'll have a happy live test again :) |
| 21:22 |
bshum |
phasefx++ |
| 21:24 |
|
kmlussier joined #evergreen |
| 21:37 |
|
artunit joined #evergreen |
| 21:40 |
pinesol_green |
[evergreen|Josh Stompro] LP#1133158 - Fix typos in action_trigger_runner.pl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ff79901> |
| 09:32 |
mmorgan |
looks like a lot of those for the same threadtrace. |
| 09:35 |
csharp |
yeah - there's a duration for each individual opensrf message |
| 09:36 |
mmorgan |
ok, so the actual time of the transaction is the difference between the first and last timestamp for the threadtrace? |
| 09:36 |
csharp |
also, it depends on your loglevel (set in opensrf_core.xml) as to whether you get duration for full "transactions" (for lack of a better term to describe something like a checkin) |
| 09:36 |
csharp |
yes |
| 09:37 |
csharp |
if you up one of the loglevel values to debug (4), you get more information |
| 09:37 |
csharp |
but also far larger log files, so it's a tradeoff |
| 09:39 |
csharp |
I think it's the private opensrf loglevel that you'd need to increase - we do that on test servers, but not production |
| 09:40 |
|
yboston joined #evergreen |
| 09:41 |
mmorgan |
ok thanks. This is all really helpful. I spend a fair amount of time poking through logs, nice to understand them a little better. |
| 09:41 |
mmorgan |
csharp++ |
| 10:39 |
jeff |
bshum: nagios checks for ntp are handy there. |
| 10:43 |
bshum |
jeff: I'll add it to my list of things to build into my monitoring server |
| 10:43 |
bshum |
When I build it later :) |
| 10:44 |
csharp |
jeff: great idea |
| 10:45 |
csharp |
Dyrcona: awesome! I'm using yesterday's version on a test server now |
| 10:46 |
|
RoganH joined #evergreen |
| 10:48 |
|
kmlussier joined #evergreen |
| 10:51 |
Dyrcona |
csharp: cool. I'm testing the command line options to skip browse, search and facet reingest and just do the record attributes, now. |
| 10:51 |
* csharp |
signs off on the fix for bug 1390225 |
| 10:51 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225 |
| 10:51 |
csharp |
Dyrcona: rock on |
| 12:06 |
Dyrcona |
Ah, so looks like it is time to upgrade, then. :) |
| 12:07 |
jeff |
well past. |
| 12:14 |
|
nhilton joined #evergreen |
| 12:20 |
Stompro |
Dyrcona: auto-updates - I think it is more complex than that, at lease for my testing system. Looks like the auto-update requires a valid SSL cert, and some options that are set at configure time. And it doesn't look like the auto-update works if I used the staff client listed on the egdownloads page, you have to have already installed a custom built staff client. |
| 12:21 |
tsbere |
Stompro: Auto-updates don't work with community staff clients, but you don't have to use configure-time options. Staff-client build time options work as well, though the configure time options speed that up. As for the valid SSL cert, if your update host starts with http:// you can bypass that (though I wouldn't do that for production systems) |
| 12:22 |
* tsbere |
will also admit to not having *tested* http:// updates in quite a while, though |
| 12:23 |
Stompro |
tsbere: Thanks for the tips. |
| 12:24 |
tsbere |
Stompro: Oh, and while it is certaintly *easier* when it is, your updates host doesn't have to be the same server as your evergreen install. |
| 12:26 |
Dyrcona |
Heh. You'd think I would have rememberd updates_host. I just did an update with updates-client this morning. :p |
| 12:48 |
Dyrcona |
I'll leave that up to you and dbwells to decide. :) |
| 13:04 |
* phasefx_ |
has a fix for lp1386260 if someone wants to poke at it |
| 13:06 |
bshum |
bug 1386260 |
| 13:06 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:08 |
phasefx_ |
you can do perl live_t/03-overdue_circ.t to test on a stock install with concerto |
| 13:09 |
* phasefx_ |
will add that to the bug |
| 13:10 |
Dyrcona |
csharp: I pushed the changes I mentioned to my evergreen_utilities repo. I also made a change to db_upgrade.pl, but you probably don't use that one. |
| 13:10 |
|
akilsdonk_ joined #evergreen |
| 13:14 |
Dyrcona |
csharp: might want to wait. I just noticed a serious thinko/bug in my pingest changes. It won't work right as is if you try to do attribute and search or facet ingest at the same time. |
| 13:19 |
phasefx |
oy, I just fixed one test.. not all of them, doh |
| 13:39 |
csharp |
Dyrcona: no problem - I haven't pulled in today's changes yet |
| 13:39 |
|
kmlussier joined #evergreen |
| 13:40 |
phasefx |
alright, fix re-pushed for bug 1386260 :-) |
| 13:40 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:41 |
Dyrcona |
csharp: I'm having some "fun" with a little hidden global variable voodo.... I was wondering why it worked at all until I noticed a little $lists++; tucked away in the browse_ingest subroutine. |
| 13:42 |
jeff |
blargh. character encoding issues. |
| 13:44 |
Dyrcona |
Anyway, the bug I noticed is that I had doubled the number of child processes without also adjusting the number of lists, so the program could exit prematurely. |
| 13:49 |
Dyrcona |
Often makes those "vendor records" easier for MARC::Record to digest. Just ignore the comments in the output. :) |
| 13:50 |
jeff |
no, if yaz-marcdump can't parse without errors/warnings, you reject the file ;-) |
| 13:51 |
Dyrcona |
Then, I'd almost never load anything. ;) |
| 13:51 |
jeff |
last if $outcount >= 50; |
| 13:51 |
* jeff |
frowns |
| 13:52 |
jeff |
i need to develop better habits with regard to "# XXX: remove after testing" or somesuch. |
| 13:52 |
jeff |
though part of me wants hard limits (just not that low) in place for some automated things. |
| 13:52 |
Dyrcona |
jeff: command line option to limit, by default set to zero, which means do the whole thing. |
| 13:54 |
Dyrcona |
Well, perl -c says syntax OK. Guess that means I can commit. :) |
| 13:54 |
tsbere |
jeff: I tend to use TODO for things I intend to change/remove before pushing, and XXX for things I see as longer-term warning notes |
| 13:55 |
* jeff |
wonders what the larger convention is |
| 13:55 |
jeff |
i suppose what matters most is the local / codebase convention |
| 13:55 |
tsbere |
jeff: Oh, and "To whomever works on this code next:" for "we should do this later, because I am being lazy and don't feel like doing it now" (but I avoid doing that if I know what should be changed/done anyway) |
| 13:59 |
Dyrcona |
jeff: I've sometimes added --dry-run or similar options to my own stuff for testing purposes. |
| 13:59 |
* jeff |
nods |
| 13:59 |
jeff |
lots of this kind of thing is solved by good habits early: config file, command line arguments, etc. |
| 13:59 |
Dyrcona |
Or in a case where I was deleting files, a --delete option to actually do the delete, otherwise it just printed out what would be deleted without deleting. |
| 14:49 |
yboston |
I was not aware of that |
| 14:50 |
remingtron |
hm, let me check his email... |
| 14:50 |
yboston |
also, we could have the second server be used to test re-organizations |
| 14:50 |
kmlussier |
It's not just the multiple builds. If we want to make changes to the docs site, it's good to have a place to test them out ahead of time before putting them into production. |
| 14:50 |
yboston |
though in theory we can set up Robert's server to do that, though I beleive his servers are pretty taxed already |
| 14:50 |
remingtron |
on 10/3/2014 Robert emailed me and yboston, saying he added a 1pm build time to his docs server |
| 14:50 |
* kmlussier |
is thinking of some of the ideas snigdha26 raised at the last DIG meeting. |
| 14:51 |
yboston |
I need to learn how to read better |
| 14:51 |
remingtron |
yboston: no prob, you're a busy guy |
| 14:52 |
remingtron |
yboston: did we have a potential host for our new test docs VM? |
| 14:52 |
yboston |
PINES provides VMs for the EG community |
| 14:52 |
yboston |
and Galen started the discussion on provisioning a server for us |
| 14:53 |
remingtron |
anything we need to do to keep that moving forward? |
| 14:58 |
yboston |
my apologies that we have hit the hour mark already, I can stay on longer |
| 14:58 |
kmlussier |
But is this a leftover agenda item from last month? |
| 14:59 |
yboston |
I thought ti was leftover, but I could be wrong |
| 14:59 |
remingtron |
I don't recall discussing it much, or at least not deciding to try anything |
| 14:59 |
remingtron |
maybe we got sidetracked with needing a test server |
| 14:59 |
remingtron |
but I think we can decide to try things before the server is ready |
| 15:00 |
kmlussier |
remingtron: I think we're in an awkward period at the moment because snigdha26 has incorporated a lot of these ideas in her proposal, but the application review period isn't over yet. |
| 15:00 |
remingtron |
kmlussier: right, you mean that if accepted, she would do these things herself? |
| 15:00 |
kmlussier |
remingtron: Yes, exactly. |
| 16:09 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 6) [Undecided,New] |
| 16:11 |
|
sandbergja joined #evergreen |
| 16:11 |
|
RoganH joined #evergreen |
| 16:11 |
jeff |
commit c2c720d is what i had way-back-when |
| 16:11 |
jeff |
and the bot doesn't do working branches. |
| 16:11 |
jeff |
c2c720d |
| 16:11 |
jeff |
er, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=c2c720de6fb83aa1acc678de78a1695cf8201eb5 |
| 16:17 |
jeff |
eeevil: heh. specific to the issue in bug 1390225, i remembered that earlier this morning i had minimized a browser window to test that very thing. just un-minimized it, and guess what? error. :-) |
| 16:17 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1390225 |
| 16:17 |
jeff |
eeevil: sorry for not thinking of that specific case in our conversation earlier. :-) |
| 16:17 |
* jeff |
returns to looking oddly at this bib that is j in the leader but i in the mra |
| 16:50 |
|
mrpeters joined #evergreen |
| 17:00 |
|
mdriscoll left #evergreen |
| 17:04 |
gsams |
The system should be able to process the transactions pretty quickly, at least I would expect it to. It's a source of confusion for me anyway |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:25 |
|
kmlussier joined #evergreen |
| 17:26 |
gsams |
I'm thinking it might be exageration by circulation employees at the moment |
| 17:26 |
gsams |
ran a test of 50 items in less than 50 seconds |
| 17:27 |
gsams |
I might need to run that during different hours to test peak times |
| 17:28 |
gsams |
of course, this library has some people that circulate 100-200 items at a time |
| 17:46 |
gsams |
well, testing aside, how does this function in other systems? Does anyone handle renewals concurrently? |
| 17:47 |
|
kmlussier joined #evergreen |
| 19:34 |
|
nhilton joined #evergreen |
| 19:55 |
|
remingtron joined #evergreen |
