| 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 |
remingtron: is that what you meant? |
| 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 |
| 09:18 |
csharp |
bshum: what would be the most effective way to test the fix to the libdbi bug? |
| 09:19 |
csharp |
Dyrcona: weren't you only experiencing the issue under conditions of higher load? |
| 09:19 |
* csharp |
re-reads |
| 09:19 |
bshum |
csharp: I was going to try following what happened in the bug report as far as copy creation goes. And also figure out the perl test that was included. |
| 09:20 |
csharp |
ah - there's a test |
| 09:20 |
Dyrcona |
csharp: No, it had nothing to do with load. pcrud transactions simply failed. |
| 09:20 |
bshum |
berick++ |
| 09:20 |
csharp |
Dyrcona: okay - my quick read several months ago clearly led to inaccurate impressions of the issue :-) |
| 09:20 |
bshum |
csharp: If you have time to spare a look, extra eyes never hurt. |
| 09:20 |
Dyrcona |
The fix is very simple and seems to work, but a mass delete script I tested on precise after applying the change gave me several "unknown errors." |
| 09:21 |
csharp |
well, since we're an ubuntu shop, and this is a obvious impediment, I only think it fair that we participate ;-) |
| 09:36 |
|
RoganH joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 09:58 |
* csharp |
tests the fix for bug 1366964 without issues |
| 09:58 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 09:58 |
berick |
to be clear, the fix to 1366964 doesn't prevent "unknown errors" (from the DB), it just allows cstore to recognize them as transient instead of "OMG DB IS DOWN" |
| 09:58 |
csharp |
live test works fine |
| 10:01 |
Dyrcona |
berick: I suspected as much. I'll sign off on it. |
| 10:02 |
berick |
Dyrcona++ |
| 10:02 |
berick |
csharp++ # testing |
| 10:02 |
Dyrcona |
If csharp wants to sign off, too, that's cool. I can wait and sign his branch then push that. |
| 10:03 |
Dyrcona |
It's today we want to release the dot releases for 2.5, 2.6, and 2.7, right? |
| 10:05 |
bshum |
Dyrcona: That's certainly my goal for 2.7. |
| 10:06 |
bshum |
Dyrcona: Sounds right to me. |
| 10:07 |
Dyrcona |
Will do. |
| 10:07 |
|
RoganH joined #evergreen |
| 10:11 |
pinesol_green |
[evergreen|Bill Erickson] LP#1366964 Update libdbi connection test error parsing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca4e28a> |
| 10:12 |
Dyrcona |
Done and done. |
| 10:12 |
berick |
woot |
| 10:13 |
Bmagic |
csharp: thanks for the feedback. Glad it's not just my system |
| 11:16 |
|
kmlussier joined #evergreen |
| 11:23 |
kmlussier |
jboyer-isl: Is bug 1210541 ready for a pullrequest tag? |
| 11:23 |
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 - Assigned to Jason Boyer (jboyer) |
| 11:24 |
jboyer-isl |
I think so. I've tested it a bit but I haven't heard of anyone else trying it out. |
| 11:26 |
jboyer-isl |
kmlussier, It worked well enough for me the day of the hackaway, for what that's worth. |
| 11:26 |
kmlussier |
jboyer-isl: OK, I'll add one then. I think we have somebody here is interested in trying it out. |
| 11:27 |
jboyer-isl |
Good to hear. Hopefully there's nothing to find. :) |
| 11:36 |
|
dreuther joined #evergreen |
| 15:57 |
bshum |
Maybe it'll be helpful in my future |
| 15:58 |
berick |
yeah, the git stuff was necessary on wheezy |
| 15:58 |
bshum |
I'm still deciding if I want to upgrade my laptop to utopic unicorn... |
| 15:59 |
berick |
well, hmm, trusty install 0.10.25. earliest i tested was 0.10.28 -- |
| 16:00 |
berick |
not entirely sure what I just said is true, but likely true |
| 16:00 |
bshum |
Heh |
| 16:00 |
berick |
i'll give it a shot |
| 16:01 |
bshum |
I didn't get to finish up the written instructions for the README in Evergreen for webclient building. |
| 16:34 |
gmcharlt |
eeevil++ |
| 16:38 |
|
nhilton_ joined #evergreen |
| 16:42 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:51 |
|
mrpeters left #evergreen |
| 16:52 |
|
kmlussier left #evergreen |
| 16:54 |
phasefx |
that last failure includes one not related to DST: open-ils.cstore 2014-11-05 16:27:37 [ERR :21897:oils_sql.c:2483:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_active,restrict_copy_delete) VALUES (DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR: null value in column "name" violates not-null constraint |
| 16:55 |
bshum |
Hmm |
| 16:56 |
bshum |
That's the new test |
| 16:56 |
bshum |
For the libdbi thing? |
| 16:56 |
|
dMiller_ joined #evergreen |
| 16:57 |
bshum |
Yep |
| 16:57 |
phasefx |
the test itself didn't throw an error |
| 16:58 |
bshum |
Hmm |
| 16:58 |
phasefx |
live_t/08-lp1366964-libdbi-error.t ..... ok |
| 16:59 |
berick |
that's supposed to happen |
| 16:59 |
berick |
the point of the test is to see how it recovers from a DB error |
| 16:59 |
dbwells |
That's great :) |
| 17:00 |
phasefx |
k, then when we can tell the webifier thing to expect an error |
| 17:00 |
* phasefx |
will poke |
| 17:01 |
berick |
phasefx++ |
| 17:01 |
berick |
didn't realize it would bark at that |
| 17:03 |
berick |
bshum: btw, initial test of nodejs package on trust looks good. will document when i get some time |
| 17:03 |
bshum |
berick++ # cool! |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
phasefx |
for reference, http://git.evergreen-ils.org/?p=working/random.git;a=commitdiff;h=2983559ea27c6506f750a757e64d9bb4d5b43548 Haven't tested it yet |
| 17:09 |
phasefx |
so that makes two exeptions that are DBI related :) |
| 17:09 |
phasefx |
exceptions, even |
| 17:10 |
bshum |
phasefx++ # nifty |
| 17:39 |
|
nhilton joined #evergreen |
| 17:54 |
|
nhilton_ joined #evergreen |
