| Time |
Nick |
Message |
| 03:00 |
|
Jillianne joined #evergreen |
| 04:23 |
|
hawahaniz_ left #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:08 |
|
rjackson_isl_ joined #evergreen |
| 07:10 |
|
Dyrcona joined #evergreen |
| 07:28 |
|
rjackson_isl joined #evergreen |
| 07:34 |
graced |
good morning #evergreen... see you in a week! |
| 08:06 |
|
collum joined #evergreen |
| 08:12 |
|
kmlussier joined #evergreen |
| 08:15 |
kmlussier |
Good morning #evergreen! |
| 08:15 |
JBoyer |
🎉 |
| 08:30 |
|
_bott_ joined #evergreen |
| 08:31 |
gmcharlt |
a little game for folks, arising from prep for one of my presentations next week |
| 08:31 |
gmcharlt |
guess the name, or at least nature, of the file that has been in the Evergreen source code the longest without any modification |
| 08:32 |
kmlussier |
No modification? |
| 08:32 |
gmcharlt |
more like file that hasn't been modified the longest time |
| 08:33 |
gmcharlt |
modifications before it "froze" don't count |
| 08:34 |
gmcharlt |
@coffee me |
| 08:34 |
* pinesol_green |
brews and pours a cup of Nicaragua Maragogipe Organic, and sends it sliding down the bar to me |
| 08:37 |
kmlussier |
I'm up against gmcharlt's program. I'm always scheduled against programs I want to go to. |
| 08:38 |
kmlussier |
Is there a schedule on the web site that has the program descriptions? |
| 08:38 |
gmcharlt |
hmm, just titles, as far as I know, although I assume that the link to the propsal spreadhseet may still be floating aroudn |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
|
bos20k joined #evergreen |
| 08:55 |
JBoyer |
terran++ # our first round of SMS courtesy notices is currently running. |
| 08:55 |
JBoyer |
11K texts, glad we're not charged on this end. D: |
| 08:56 |
JBoyer |
gmcharlt, I don't suppose LICENSE.txt is near the oldest? |
| 08:56 |
gmcharlt |
JBoyer: bzzzzzzzt! |
| 08:57 |
JBoyer |
Ah, so we're talking real back catalog here, heh. |
| 08:57 |
gmcharlt |
JBoyer: yeah, there was a textual update to the GPL2 that we applied back in 2010 |
| 08:59 |
JBoyer |
Ah, I'm out of the loop on licenses. |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:14 |
kmlussier |
gmcharlt: Is it an image file? |
| 09:14 |
gmcharlt |
kmlussier: close, but there are two files that whose last modification time predates the oldest image file |
| 09:15 |
* kmlussier |
considers this to be a game of 20 questions rather than a guessing game. |
| 09:15 |
gmcharlt |
fair enough |
| 09:16 |
kmlussier |
Is it bigger than a breadbox? |
| 09:17 |
gmcharlt |
it's fairly large as files of its type go |
| 09:19 |
JBoyer |
Animal, vegetable, mineral, or the model of a modern major general? |
| 09:19 |
JBoyer |
;) |
| 09:19 |
* gmcharlt |
checks the Evergreen source code base for cats |
| 09:20 |
gmcharlt |
*nothing meows back* |
| 09:20 |
|
yboston joined #evergreen |
| 09:28 |
|
jvwoolf joined #evergreen |
| 09:35 |
|
bos20k joined #evergreen |
| 09:40 |
|
collum joined #evergreen |
| 09:47 |
collum |
kmlussier: The proposals are here: https://docs.google.com/spreadsheets/d/1-n2-_ypSvQbxHilv5SmkUaYcjl-a3yFhpmrIeqxVTJg/edit#gid=0 |
| 09:48 |
collum |
The schedule with the descriptions has not yet been uploaded to the web site. |
| 09:48 |
kmlussier |
collum: Are you planning to upload the descriptions to the web site at some point? |
| 09:49 |
kmlussier |
collum: Also, I'm looking forward to the conference next week. It looks like you all have put together a great program! |
| 09:49 |
collum |
There's a pdf that was sent to the printer. I'll try to get it on the website. |
| 09:50 |
kmlussier |
Great, thanks! collum++ |
| 09:50 |
* kmlussier |
always loses her printed program part way through the conference, so it's always nice to have a backup on the web. |
| 10:02 |
|
terran joined #evergreen |
| 10:03 |
collum |
kmlussier: Well that was easy, I thought I would run into a file size restriction. It's the first link on this page under the conference logo. https://evergreen-ils.org/conference/2017-evergreen-international-conference/2017-conference-programs-and-schedule/ |
| 10:04 |
kmlussier |
Yay! collum++ |
| 10:04 |
kmlussier |
I can confirm there is a file size restriction, because I've run into it before with the annual report, but I don't know what it is. |
| 10:06 |
jeff |
Have I imagined a config / policy setting that doesn't exist? I was fairly certain that someone was doing "don't allow holds to be placed on items that are on the shelf". |
| 10:07 |
kmlussier |
I think it's a YAOUS |
| 10:09 |
* mmorgan |
agrees with kmlussier |
| 10:09 |
kmlussier |
jeff: Has local copy block |
| 10:09 |
jeff |
hah |
| 10:09 |
jeff |
i found that one with a search on "block", but skimmed over it. |
| 10:09 |
jeff |
thanks! |
| 10:09 |
jeff |
kmlussier++ mmorgan++ |
| 10:22 |
mmorgan |
jeff: We have one library that uses that org setting. A problem they've run into is that there's no way to override the behavior. |
| 10:24 |
dbwells |
gmcharlt: MARC21slim2MODS.xsl? |
| 10:24 |
gmcharlt |
dbwells: ding-ding-ding we have a winner! |
| 10:25 |
kmlussier |
gmcharlt: Is there a prize? |
| 10:28 |
dbwells |
Well, several of us have been wanting to update that thing for at least the last 7 years. |
| 10:28 |
* dbwells |
blushes |
| 10:30 |
gmcharlt |
there is! |
| 10:30 |
gmcharlt |
and here it is: https://librarypolice.com/winning_cat.jpg |
| 10:31 |
JBoyer |
Ah, nuts. I was thinking that but was afraid it would come across as snark because of the aforementioned "let's update it." :) |
| 10:31 |
JBoyer |
dbwells++ |
| 10:31 |
gmcharlt |
by the way, the oldest file that didn't ultimately originate from another project is Open-ILS/src/templates/marc/book.xml |
| 10:33 |
* dbwells |
sends a job to the campus poster printer |
| 10:37 |
bshum |
collum++ # pretty, thanks for sharing! |
| 10:44 |
rhamby |
bshum++ : for helping out with wordpress |
| 10:45 |
kmlussier |
bshum++ |
| 10:45 |
collum |
terran gets the credit for the program. terran++ |
| 10:45 |
* collum |
can make a link. :-) |
| 10:50 |
* kmlussier |
is also in the "can make a link" camp. |
| 10:50 |
terran |
collum++ thanks for posting! I kept thinking about it while I was away from my desk and then getting sidetracked by the time I got back |
| 10:51 |
terran |
I can't take credit for the pretty cover - that was done by Samantha Tribble |
| 10:53 |
kmlussier |
The cover is very pretty, isn't it? |
| 10:53 |
kmlussier |
And I like the theme: Open and Unbridled |
| 10:54 |
abneiman |
terran++ : program looks great! |
| 10:57 |
kmlussier |
I'm also very happy that I'm presenting on Thursday this year. It looks like I'll be able to relax for most of the conference this year! |
| 11:04 |
terran |
Thanks! |
| 11:07 |
|
jvwoolf joined #evergreen |
| 11:14 |
|
rlefaive joined #evergreen |
| 11:21 |
Bmagic |
Anyone else struggle with the staff client freezing up when replacing cards? I know it has to do with autogen but even after I run autogen, we have this issue. We identified an issue a year ago with the hash result being different on each app server |
| 11:21 |
Bmagic |
but concluded that the app servers would show a different hash because of the order of JSON strings getting parsed is not always the same. |
| 11:22 |
Bmagic |
Right now I wonder if it matters which app server the client is assigned vs. which app server the client is assigned when replacing the card? Just a theory, how does that sit with you? |
| 11:36 |
csharp |
Bmagic: yes, we've seen that - pretty sure it's related to https://bugs.launchpad.net/evergreen/+bug/1007380 |
| 11:36 |
pinesol_green |
Launchpad bug 1007380 in Evergreen "XACT_COLLISION Error in Patron Edit" [Medium,Confirmed] |
| 11:37 |
Bmagic |
Not sure if this is our issue. We don't get an error |
| 11:37 |
Bmagic |
The staff client just locks up, and you have to force kill the process |
| 11:41 |
mmorgan |
Bmagic: We have not had reports of this issue from our libraries. |
| 11:41 |
Bmagic |
mmorgan: Do you get differing autogen hashes? |
| 11:43 |
terran |
Bmagic: We've seen that too, but I don't think we've gotten the complaint since our January upgrade. (Of course, they might have just stopped telling us about it.) |
| 11:48 |
mmorgan |
Bmagic: is this in /openils/var/web/eg_cache_hash? |
| 11:48 |
Bmagic |
mmorgan: Yep |
| 11:49 |
mmorgan |
ok, it's different on our four bricks, but we no longer have app servers. |
| 11:58 |
csharp |
Bmagic: we don't get an error either, and I don't remember how I tracked it to that bug, but I did at some point |
| 12:05 |
csharp |
Bmagic: what our libraries reported was that they open the edit screen to see the cards, then go to the bills screen to create a billing/accept payment for the replacement card, then the hang happens when they try to replace and save |
| 12:07 |
|
khuckins joined #evergreen |
| 12:09 |
Bmagic |
csharp: roger that |
| 12:19 |
|
Christineb joined #evergreen |
| 12:24 |
|
jihpringle joined #evergreen |
| 12:25 |
kmlussier |
@coffee |
| 12:25 |
* pinesol_green |
brews and pours a cup of Decaf Organic Caffe Volcan, and sends it sliding down the bar to kmlussier |
| 12:25 |
kmlussier |
Decaf!!! |
| 12:25 |
kmlussier |
@blame pinesol_green |
| 12:25 |
pinesol_green |
kmlussier: It really IS itself's fault! |
| 12:25 |
JBoyer |
Bmagic, We get that when new libs migrate in and they're replacing cards non-stop for a few days. Evergreen.exe pegs a processor core and deadlocks on something until you kill it. I always assumed it was related to the memory leak issues of old. |
| 12:26 |
JBoyer |
It's one reason we're jumping on 2.12, we want the web client at circ asap. |
| 12:26 |
Bmagic |
JBoyer: I bet it's autogen for you especially since you mention new migrations |
| 12:27 |
JBoyer |
Our hashes never match since all 10 are generated independently. It's more the frequency of user updates and possibly the process used. |
| 12:28 |
Bmagic |
Yeah, there has to be something lurking in there somewhere |
| 12:28 |
Bmagic |
I just reran autogen, and we shall see |
| 12:28 |
JBoyer |
Better debugging on windows would be helpful, but since you can't really trigger it on demand (and I don't know if debugging symbols are still available for that vintage xulrunner...) we've just ridden it out. |
| 12:30 |
kmlussier |
JBoyer: When are you planning to upgrade to 2.12? |
| 12:30 |
JBoyer |
Easter weekend. |
| 12:31 |
JBoyer |
Hoping to squeeze in a vacuum full analyze too, takes 8 hours. :/ |
| 12:31 |
kmlussier |
Wow! Just a few weeks away. Awesome! |
| 12:31 |
* JBoyer |
remembers that he needs to actually tell people in Indiana this... |
| 12:31 |
kmlussier |
Be sure to file lots of bugs so that we can make the web client even better for 3.0 |
| 12:31 |
JBoyer |
Thats the hope! |
| 12:32 |
kmlussier |
Or, even, 2.12.2. No reason to wait for 3.0. :) |
| 12:32 |
JBoyer |
Well, the hope is that there aren't that many to *be* filed, but you know. |
| 12:32 |
kmlussier |
JBoyer: I always feel very confident that my thorough testing revealed everything there is to find. And then people start using it in production, and I find out I'm wrong. |
| 12:33 |
JBoyer |
"But WHY would anyone do THAT?! That's not how any of this works!" |
| 12:33 |
berick |
JBoyer: vacuum full analyze the whole db? nice |
| 12:35 |
* berick |
has a few vacuum-full's lined up, expects to recover several hundred GB of disk space |
| 12:35 |
berick |
after cleaning up copy auditor and anonymizing holds |
| 12:35 |
JBoyer |
berick, Yeah, that's where all the time will go. I think the db upgrade scripts (minus reingest, of course) only takes a few minutes. I was about to do another test run on our dev server to double check. |
| 12:36 |
JBoyer |
we keep all of our auditors trimmed (we delete 2 hogsheads a fortnight), and we run circ/hold purges daily. I'm hoping it all goes smoothly. |
| 12:36 |
berick |
heh |
| 12:37 |
JBoyer |
I'm reminded though that slony will be the hassle here. Perhaps for the next large upgrade we move to Pg 9.5 and back to the built in sync. |
| 14:05 |
|
kmlussier joined #evergreen |
| 14:12 |
|
jvwoolf joined #evergreen |
| 14:21 |
|
kaffenkj joined #evergreen |
| 15:03 |
Dyrcona |
So, if I configure the hold targeter to run in parallel, should I see more than 1 running with ps? |
| 15:03 |
Dyrcona |
I basically see the bash -c that started it and 1 hold targeter. |
| 15:05 |
berick |
Dyrcona: there will be multiple storage (old-style) or open-ils.targeter (new-style) processes actively working. |
| 15:05 |
berick |
still just one hold_targeter*pl process |
| 15:06 |
Dyrcona |
berick: Thanks! That makes it tougher to figure out, so I'll assume it is working. :) |
| 15:06 |
Dyrcona |
I'm using old style. I don't recall new style making it into master, yet. |
| 15:07 |
berick |
it's in 2.12 |
| 15:07 |
Dyrcona |
OK. |
| 15:08 |
Dyrcona |
So, another question: has anyone noticed the same copy being targeted at different holds with parallel targeting? |
| 15:08 |
Dyrcona |
I had an example sent to me and the prev_check_time for the two holds is more or less identical. |
| 15:10 |
Dyrcona |
Different users, different pickup locations, etc. Same bib, same current copy. |
| 15:11 |
berick |
parallel targeting segregates holds by metarecord to prevent that exact scenario. |
| 15:11 |
berick |
i can't say I've ever seen it happen |
| 15:11 |
Dyrcona |
The holds were placed about six minutes apart and the previous checck times are 30 seconds apart. |
| 15:11 |
Dyrcona |
Mabye this is more memcached "weirdness." |
| 15:12 |
berick |
are the holds old enough that they have not yet been re-targeted by the batch targeter? |
| 15:12 |
berick |
or young enough, rather |
| 15:12 |
Dyrcona |
I don't thinks the request time is on 3/13/17 and the previous check time was yesterday afternoon in this example. |
| 15:13 |
Dyrcona |
They would be retargeting about now, actually. |
| 15:13 |
Dyrcona |
ugh.. "I don't think so..." |
| 15:14 |
Dyrcona |
Think I'll check them in the database. |
| 15:16 |
Dyrcona |
Prev check time is still yesterday at 15:02. Probably need to wait another hour or so. |
| 15:16 |
berick |
still have same current_copy ? |
| 15:16 |
Dyrcona |
I'll see how many copies there are on this bib. |
| 15:16 |
Dyrcona |
Yes, they do. |
| 15:17 |
Dyrcona |
Wait a minute, the database disagrees with the spreadsheet on prev_check_time or I read the spreadsheet wrong. |
| 15:17 |
Dyrcona |
The prev_check_time is only 9ms apart. |
| 15:19 |
|
jvwoolf joined #evergreen |
| 15:19 |
Dyrcona |
Neither hold is frozen. |
| 15:20 |
Dyrcona |
Wonder if only 1 copy is currently eligible to fill the holds? |
| 15:21 |
Dyrcona |
That's more difficult to figure out. |
| 15:21 |
Dyrcona |
I read the spreadsheet wrong, of course. |
| 15:21 |
Dyrcona |
It doesn't have nanosecond resolution, though. |
| 15:22 |
berick |
i would still only expect the copy to be targeted once. |
| 15:33 |
Dyrcona |
Yes, that what we expect, but that is not what is happening. |
| 15:33 |
Dyrcona |
If only I could type..... ;) |
| 15:33 |
Dyrcona |
I think it is related to a hardware crash on 2/20/17. |
| 15:34 |
Dyrcona |
We were doing some o/s package updates and the util2 server that runs the hold targeter did not reboot because of a bad drive. |
| 15:34 |
Dyrcona |
I built a vm to serve as a replacement. |
| 15:35 |
Dyrcona |
Then, we got the a replacement hard drive and put the original hardware back in service, but with a freshly installed o/s because the system would not automatically recover with the new drive in place like it was supposed to. |
| 15:35 |
Dyrcona |
I believe that had to do with a failure to load the RAID driver. |
| 15:36 |
Dyrcona |
So, anyway, it is now basically a brand new machine and no guarantees that the configuration was the same. |
| 15:36 |
Dyrcona |
This is also the machine I suspect of being better off running its own memcached. |
| 15:37 |
Dyrcona |
So, we'll restart services, etc., tomorrow morning to get it to use localhost for memcached. |
| 15:37 |
Dyrcona |
And the reports of this started after the replacement VM went into service. |
| 15:38 |
* Dyrcona |
mumbles something about moving parts. |
| 15:41 |
Dyrcona |
In the meantime, the holds retargeted about 13ms apart and neither has a current copy. |
| 15:47 |
* berick |
launches VM on laptop, sees a snapshot of where things ended at the Fall hackfest |
| 15:48 |
* Dyrcona |
doesn't have enough available RAM to start a VM, but wouldn't have on that old still hanging around anyway. :) |
| 15:58 |
Dyrcona |
Did the open-ils.targeter service make it into the opensrf.xml.example file? |
| 15:58 |
Dyrcona |
I just compared my custom config with master, and I don't see it in the diff. |
| 16:00 |
berick |
yep |
| 16:00 |
Dyrcona |
I don't see it in a checkout of master or rel_2_12. Is it called open-ils.targeter? |
| 16:01 |
Dyrcona |
Oh. its' hold-targeter |
| 16:01 |
Dyrcona |
it's... I can apostrophe, I can. |
| 16:03 |
Dyrcona |
Heh. I've been installing config with open-ils.hold-targeter in it on my 2.10 servers.... ;) |
| 16:04 |
Dyrcona |
Or, actually, no. The cherry-picking has done what it should. |
| 16:05 |
Dyrcona |
There's also a new ebook_api service! |
| 16:05 |
Dyrcona |
Cool stuff. |
| 16:06 |
Dyrcona |
I've been too bogged down in the day to day to keep up with everything. |
| 16:28 |
|
mmorgan joined #evergreen |
| 16:33 |
|
khuckins_ joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:38 |
|
khuckins joined #evergreen |
| 18:56 |
|
kenstir joined #evergreen |
| 19:00 |
kenstir |
Is there anybody that hangs out here in the evenings, or is this a 9-to-5 crew? |
| 19:03 |
jihpringle |
kenstir: the channel tends to be active 9-5 Eastern Time |
| 19:03 |
jihpringle |
there are usually a few of us from the west coast around until at least 5pm Pacific |
| 19:05 |
kenstir |
Sadly I have a day job, so I have most of my OSRF questions in the evening. Maybe with a TARDIS IRC client I could send my questions back to when folks are around. |
| 19:06 |
jihpringle |
kenstir: you may want to try the mailing lists - https://evergreen-ils.org/communicate/mailing-lists/ |
| 19:06 |
kenstir |
That's a very good idea |
| 19:07 |
jihpringle |
depending on your questions the general or the dev (technical) lists are probably the best ones |
| 19:08 |
kenstir |
Definitely the dev list. I totally forgot about the list! Thanks for snapping me out of it. |
| 19:08 |
jihpringle |
no problem, glad I could help :) |
| 19:14 |
|
frank_guel joined #evergreen |
| 19:17 |
frank_guel |
Hi all, Is there any kind of bug or how can I fix it? When I create a new marc record into the 2.12v using a marc template used in 2.8.4, it created it but looks like it is encoded with other format, I mean If for example I have an © in the template, when I load it in staff client it looks well, but when I save it ir shows weird symbols, and if I open and replace the record with a © manually, save it, and it looks well |
| 19:22 |
jihpringle |
frank_guel: that sounds like a bug to me, I checked our templates which came from 2.10 to 2.12 and we don't have any symbols in our templates so I can't replicate |
| 19:23 |
frank_guel |
could be an accent or a symbol. |
| 19:25 |
jihpringle |
our templates are pretty much just lists of blank fields per item type |
| 19:27 |
frank_guel |
ah ok ok, I did another test, I open the k_book.xml default template, add a word with an accent, and it save it as a weird character, if I open it again and replace the character with the correct word, save the changes and it looks well |
| 19:28 |
jihpringle |
frank_guel: I'll ask one of our techs to add some accents/symbols to one of our templates and see if we can replicate |
| 19:30 |
frank_guel |
that sounds great, thanks |
| 19:30 |
jihpringle |
I'll let you know whether or not we can replicate |
| 19:37 |
frank_guel |
ok, that's good thanks |
| 22:11 |
|
khuckins joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
