| Time |
Nick |
Message |
| 01:42 |
|
Mark__T joined #evergreen |
| 02:16 |
|
_bott_ joined #evergreen |
| 02:16 |
|
dbwells joined #evergreen |
| 08:21 |
|
finnx joined #evergreen |
| 08:28 |
|
Dyrcona joined #evergreen |
| 08:34 |
|
akilsdonk_ joined #evergreen |
| 08:35 |
|
kivilahtio joined #evergreen |
| 08:39 |
|
kbeswick joined #evergreen |
| 08:46 |
kivilahtio |
everybody: berick: eeevil: I managed to get the debugger working. It was more simpler than I thought. I wrote a small tutorial about debugging and I would appreciate some feedback before I publish it under dokuwiki->"Project OpenSRF, the framework underlying Evergreen". https://docs.google.com/document/d/1CGMPWG2Pb5_mhnnEzXywfkQTnp8OeCdMivjd9Pap_ow/edit?usp=sharing |
| 08:47 |
Dyrcona |
kivilahtio++ #whether this works or not. |
| 08:47 |
kivilahtio |
It works for me |
| 08:48 |
kivilahtio |
but might not work for all services, tested with open-ils.serial |
| 08:49 |
Dyrcona |
kivilahtio: I'll gladly test it with other services today. If this works or only needs slight modifications to work everywhere, then it is a god-send. |
| 08:49 |
|
finnx joined #evergreen |
| 08:50 |
|
Rogan_ joined #evergreen |
| 08:50 |
kivilahtio |
Dyrcona: Happy to hear that. |
| 08:53 |
berick |
kivilahtio++ |
| 08:54 |
|
ericar joined #evergreen |
| 08:54 |
berick |
one comment.. raising the /opensrf/default/apps/open-ils.<service>/keepalive value will have negative consequences in some cases and probably won't help w/ debugging |
| 08:54 |
kivilahtio |
berick, what does it do anyway? |
| 08:56 |
berick |
when you open a connected session to a drone (e.g. for database transactions), that value determines how long the drone will wait between new requests before it assumes the caller has gone away |
| 08:56 |
|
mmorgan joined #evergreen |
| 08:56 |
berick |
very similar to apache keepalive |
| 08:56 |
kivilahtio |
berick, ok, I'll remove that |
| 08:56 |
berick |
the value has no bearing when the drone is actively working, though |
| 09:10 |
Dyrcona |
kivilahtio: Does one make the configuration file changes on the workstation or on the server? |
| 09:11 |
Dyrcona |
kivilahtio: Ah, wait, I think reading further answers my question. The change is made on the workstation, since you'll start services there. |
| 09:13 |
paxed |
kivilahtio: niistä 100a:n normalisoinneista - se mun phpskripti pelittää kenellä tahansa, se kun lukee nimet tekstitiedostosta. |
| 09:17 |
Dyrcona |
Syntax a mockery Google Translate makes of. |
| 09:17 |
Dyrcona |
At least for Finnish to English and Finnish to French. |
| 09:17 |
paxed |
machine translation of finnish is mostly a failure |
| 09:17 |
kivilahtio |
Dyrcona, what paxed said has nothing to do with the debugger :) I think what you mentioned is already written in the "environment limitations" |
| 09:18 |
|
kmlussier joined #evergreen |
| 09:18 |
Dyrcona |
kivilahtio paxed Yes, something about PHP scripts reading text files and normalization. |
| 09:18 |
Dyrcona |
kivilahtio: Yes, found it. |
| 09:18 |
kivilahtio |
but to sum it up we are talking about normalizing capitalized author names |
| 09:20 |
Dyrcona |
kivilahtio: You specify running as the opensrf user, but I've already installed OpenSRF and Evergreen on my workstation as my own user account, so that should be the same as running as opensrf user, right? (Just making sure.) |
| 09:20 |
kivilahtio |
Dyrcona, right |
| 09:20 |
kivilahtio |
that is the "advanced" part |
| 09:20 |
kivilahtio |
well I havent tested it but that is what I would have done had I known this |
| 09:29 |
pinesol_green |
[evergreen|Bill Erickson] LP 1177388 'Add to Po' Honors default copy count - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aae36ea> |
| 09:30 |
berick |
@quote add <Bender> An infinite loop? I don't have time for that! |
| 09:30 |
pinesol_green |
berick: The operation succeeded. Quote #59 added. |
| 09:33 |
paxed |
Dyrcona: we've got lots of 100a fields where the author name is in all-caps. it doesn't look pretty. and the national service that should provice normalized author names isn't yet in use. |
| 09:33 |
kivilahtio |
so paxed went and did a nice prettifier script! |
| 09:36 |
|
finnx joined #evergreen |
| 09:37 |
|
finnx2 joined #evergreen |
| 09:37 |
|
finnx joined #evergreen |
| 09:52 |
|
bkuhn joined #evergreen |
| 09:55 |
|
DPearl joined #evergreen |
| 10:00 |
|
yboston joined #evergreen |
| 10:05 |
eeevil |
kivilahtio: also re users, ISTM that xhost and DISPLAY should be plenty to allow the perl debugger to open windows, no? seems simpler to me, but I'm rather old school with the NIXen, perhaps |
| 10:09 |
kivilahtio |
eeevil, I have no idea what you are talking about, but I'll google and get back at this |
| 10:10 |
* tsbere |
uses x forwarding over ssh to open GUI windows on the servers |
| 10:30 |
|
Ruth joined #evergreen |
| 10:32 |
* Dyrcona |
hasn't installed any X applications on his development VM, but just might in order to try running the debugger remotely. |
| 10:33 |
Dyrcona |
However, I've been pulled off onto another project today, so I don't know if I'll get to play with debugging for a while. |
| 10:34 |
kivilahtio |
Dyrcona, Good luck with that! |
| 10:39 |
jcamins |
rfrasur: apparently California does not have any state-wide barcode registry. So I am up to four states that I know for sure about (MA, CA, CT, GA). |
| 10:40 |
jcamins |
jeff: hey, any idea how barcode prefixes get assigned in Michigan? |
| 10:41 |
|
zerick joined #evergreen |
| 10:44 |
rfrasur |
jcamins: not ignoring. will think about that in a sec |
| 10:45 |
jcamins |
rfrasur: at that rate, it'd only take another three weeks to find out what every state does. |
| 10:45 |
rfrasur |
jcamins: distribution of labor? |
| 10:46 |
rfrasur |
hmm, sorry...read that wrong |
| 10:46 |
rfrasur |
just a sec...budget conversation |
| 10:46 |
jcamins |
No problem. |
| 10:48 |
csharp |
@whocares marc |
| 10:48 |
pinesol_green |
bshum, jcamins and rfrasur hate marc |
| 10:48 |
csharp |
@whocares MARC |
| 10:48 |
pinesol_green |
bshum, jcamins and rfrasur hate MARC |
| 10:50 |
* rfrasur |
just found out that we, a tax funded institution, has to pay to be audited by the State Board of Accounts, a tax funded state office. |
| 10:50 |
* rfrasur |
is NOT impressed |
| 10:51 |
gmcharlt |
ah, the joy of chargebacks |
| 10:55 |
rfrasur |
okay, jcamins: that's very good. Is there something that you need help with on that? |
| 10:55 |
* rfrasur |
might not be able to do much other than find people that can...if needed. |
| 10:56 |
jcamins |
rfrasur: I don't think so. I'm just contacting people during down moments. |
| 10:56 |
jcamins |
(because I spend so much time with nothing to do! wait...) |
| 11:00 |
rfrasur |
jcamins++ |
| 11:00 |
|
dboyle joined #evergreen |
| 11:01 |
rfrasur |
program planning fail |
| 11:01 |
rfrasur |
rfrasur-- |
| 11:01 |
Dyrcona |
Is [off] working? |
| 11:01 |
jcamins |
Five. Kansas does not have statewide barcode prefix assignments. |
| 11:02 |
rfrasur |
um, I hope so. it was. |
| 11:02 |
csharp |
Dyrcona: yep: http://evergreen-ils.org/irc_logs/evergreen/2013-06/%23evergreen.19-Wed-2013.log#line92 |
| 11:02 |
rfrasur |
csharp++ |
| 11:02 |
* rfrasur |
breathes a sigh of relief |
| 11:03 |
bshum |
It's a beautiful day for another drive to Massachusetts. More power woes for our servers :( |
| 11:03 |
* csharp |
wasn't looking forward to saying "-= THIS MESSAGE NOT LOGGED =-" in place of his actual snark |
| 11:03 |
rfrasur |
lol |
| 11:03 |
rfrasur |
bshum++ |
| 11:03 |
rfrasur |
mazda++ |
| 11:03 |
bshum |
Shiny mazda driving though, yes :D |
| 11:03 |
rfrasur |
power_outages-- |
| 11:03 |
csharp |
bshum: nice car! |
| 11:03 |
bshum |
csharp: I have an HP ILO question for you... |
| 11:03 |
Dyrcona |
bshum: The data center is in Springfield, right? |
| 11:04 |
bshum |
So, I can get to the ILO, but it's stuck at power off. Momentary press does nothing. |
| 11:04 |
csharp |
@eightball did bshum invent the "problem" just to drive his new car on work time? |
| 11:04 |
pinesol_green |
csharp: Maybe... |
| 11:04 |
bshum |
I'm thinking it's not getting the power it needs. |
| 11:04 |
csharp |
bshum: or it could be stuck enough to need a "long" press |
| 11:04 |
csharp |
oh - power's off - sorry |
| 11:05 |
csharp |
most situations in which I've used iLO have resulted in my visiting the server cage anyway :-/ |
| 11:05 |
rfrasur |
okay...y'all are relegated to a hidden window for a few. It's much more interesting to chat in here than pay bills. |
| 11:06 |
bshum |
Though it makes me wonder how the ILO keeps functioning with power off. |
| 11:06 |
bshum |
We were surprised to be able to even reach it. |
| 11:07 |
* csharp |
is asking awitter |
| 11:13 |
bradl |
bshum: I could be misunderstanding what you're saying, but I think that's precisely a use for ilo :) |
| 11:13 |
bshum |
bradl: Yeah I'm thinking there's some backup battery or such that lets me talk to ILO, but power isn't getting to the actual servers. |
| 11:13 |
csharp |
looks like the ilo is wrong about the power state (says it's on, but bshum is seeing that it's off) |
| 11:14 |
bshum |
Well, no I think the command to power on is going through, it says it processes it. But the state is still off. |
| 11:14 |
csharp |
oh I see |
| 11:14 |
|
mcooper joined #evergreen |
| 11:14 |
bshum |
So definitely looks like a nice drive up to Springfield. |
| 11:14 |
csharp |
crank up the tunes and go ;-) |
| 11:15 |
csharp |
sunglasses required |
| 11:15 |
bshum |
Zoom, zoom. Thanks csharp and everybody else :D |
| 11:15 |
csharp |
bshum++ |
| 11:15 |
|
dbs joined #evergreen |
| 11:16 |
bradl |
ah, I see. nevermind me. :) |
| 11:26 |
kivilahtio |
eeevil, Sometimes oldskool is way better than newskool. Too bad I never enjoyed the possibility to completely halt system execution at ANY time and step backwards!! OMG. I figured out that xhost thingy. It is a smart way to do this debugging and I have included it in the tutorial. Thanks yous! |
| 11:28 |
eeevil |
np ... just be careful with xhost if you have any /other/ oldschoolers on your network ... you could end up with thousands of xeyes instances staring at you |
| 11:30 |
* gmcharlt |
shivers |
| 11:30 |
csharp |
heh |
| 11:31 |
gmcharlt |
http://www.youtube.com/watch?v=K-m8_cM_SFI |
| 11:31 |
kivilahtio |
eeevil, Better disable remote login for opensrf... |
| 11:32 |
kivilahtio |
* to opensrf |
| 11:33 |
eeevil |
gmcharlt: of course that video blows up for me :( |
| 11:33 |
Rogan_ |
Sometimes I shouldn't just click on the IRC window when I come back to my desk after being gone a bit. |
| 11:33 |
eeevil |
Rogan_: false. you should always do that. |
| 11:35 |
kivilahtio |
very nice video |
| 11:35 |
kivilahtio |
maybe share it a bit? |
| 11:35 |
jcamins |
rfrasur++ # got a response from the Indiana State Library. |
| 11:35 |
jcamins |
No registry. |
| 11:56 |
|
acoomes joined #evergreen |
| 12:01 |
kivilahtio |
does anyone have any idea how to extend the timeout in the OpenSRF shell srfsh? |
| 12:04 |
kmlussier |
@marc 024 |
| 12:04 |
pinesol_green |
kmlussier: A standard number or code published on an item which cannot be accommodated in another field (e.g., field 020 (International Standard Book Number), 022 (International Standard Serial Number) , and 027 (Standard Technical Report Number)). The type of standard number or code is identified in the first indicator position or in subfield $2 (Source of number or code). (Repeatable) (1 more message) |
| 12:11 |
Dyrcona |
kivilahtio: Last time I looked into changing time outs with OpenSRF and serices, I discovered that there were more than I wanted to deal with at more levels than I wanted to deal with. |
| 12:13 |
csharp |
we're getting several messages of this type when running marc_export: Record length of 104715 is larger than the MARC spec allows (99999 bytes). at /usr/share/perl5/MARC/File/USMARC.pm line 313 |
| 12:14 |
csharp |
does that mean that the record is actually too large, or that something in the leader is screwy? |
| 12:14 |
eeevil |
csharp: the record is actually too large. are you including items? |
| 12:14 |
csharp |
yes |
| 12:14 |
csharp |
that's probably why, then, right? |
| 12:14 |
eeevil |
indeed |
| 12:14 |
csharp |
ok - thanks |
| 12:14 |
Dyrcona |
@hate MARC |
| 12:14 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates MARC. |
| 12:14 |
eeevil |
can you do without them? |
| 12:14 |
csharp |
yeah, probably |
| 12:15 |
csharp |
it's only 5 so far of like 60K |
| 12:15 |
* Dyrcona |
wonders off mumbling about antiquated garbage..... |
| 12:15 |
eeevil |
oh, I meant the items :) |
| 12:15 |
csharp |
oh - heh - probably not - you know how PINES is ;-) |
| 12:15 |
eeevil |
oclc dump? |
| 12:15 |
eeevil |
or some such? |
| 12:15 |
csharp |
some such |
| 12:16 |
csharp |
a library is going to use this export of their holdings in a third party inventory program |
| 12:17 |
* rfrasur_paying_b |
catches up |
| 12:17 |
dbs |
csharp: do you have the option of using MARCXML as an output format? |
| 12:17 |
eeevil |
you may still get the error, but if you can use marcxml formatted records then the length doesn't actually matter. only ISO2701 records are length limited |
| 12:18 |
eeevil |
dbs: beat me to it! |
| 12:18 |
* eeevil |
heads to lunch |
| 12:18 |
rfrasur |
jcamins: are they interested in starting one there? if not, I'll just send out emails to everyone and ask and put together a list |
| 12:18 |
rfrasur |
@hates |
| 12:18 |
pinesol_green |
rfrasur hates MARC; mouthy teens; and eightball |
| 12:19 |
rfrasur |
hmm, how do I unhate something? |
| 12:19 |
* dbs |
just switched to metabib.reingest_metabib_field_entries() instead of updating biblio.record_entry marc = marc to speed up reingest & cut down on WAL churn |
| 12:19 |
dbs |
@dontcare rfrasur |
| 12:19 |
pinesol_green |
dbs: I have no record of dbs's loving or hating rfrasur |
| 12:20 |
rfrasur |
(well, that's good) |
| 12:20 |
|
frank joined #evergreen |
| 12:20 |
rfrasur |
@donthate eightball |
| 12:20 |
pinesol_green |
rfrasur: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 12:20 |
dbs |
rfrasur: @dontcare |
| 12:20 |
rfrasur |
@dontcare eightball |
| 12:20 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur no longer hates eightball. |
| 12:20 |
rfrasur |
dbs++ |
| 12:22 |
kivilahtio |
Dyrcona, I modified the srfsh source. Timeout was a static variable and i changed it from 120 to 6000 and recompiled. Looks like it did the trick. No side effects yet. |
| 12:24 |
Dyrcona |
@hates |
| 12:24 |
pinesol_green |
Dyrcona hates balons; the staff client; javascript; shitty data; Apple Computer; his dev vm; intermittent errors; perl; SIP; printing; DST; parts; NCIP; LaunchPad; IRC; dates and calendar math; and MARC |
| 12:24 |
Dyrcona |
@dontcare his dev vm |
| 12:24 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona no longer hates his dev vm. |
| 12:24 |
kivilahtio |
Dyrcona, why are you working here then? |
| 12:24 |
rfrasur |
lol....you hate many thing |
| 12:24 |
rfrasur |
hehe |
| 12:24 |
frank |
Does someone know if there is a bug when the user check in the item one day after the due date, this because the system does not generate the default bill ($5.00), but if the user check in the item 2 or more days after the due date, the system generates correctly the accumulated bills |
| 12:25 |
rfrasur |
there's an automatic grace period |
| 12:25 |
Dyrcona |
I find I can only hate things that I care about. Love and hate are really the same thing. |
| 12:25 |
rfrasur |
that probably needs to be turned off in your case |
| 12:25 |
|
jdouma joined #evergreen |
| 12:25 |
rfrasur |
frank: sorry...there's an automatic grace period of a day |
| 12:26 |
rfrasur |
a default grace period is probably a better way to say that...anyway. |
| 12:26 |
Dyrcona |
@loves |
| 12:26 |
pinesol_green |
Dyrcona loves git; Tina Dico; MacOS X Leopard; you anyway; scripted sign off; sed; Monique Ortiz; and OpenBSD |
| 12:26 |
kivilahtio |
Dyrcona, so true. You can hardly hate anyone so badly unless you loved him/her first. |
| 12:26 |
dbs |
jeffdavis: Saw another 2.1-era staff client that applied the 2.4 update but got "message":"robj is null" TypeError trying to connect. We found during the 2.3 upgrade that clients didn't seem to get the new xulrunner; wondering if that might be the issue. |
| 12:26 |
frank |
rfrasur: so Do I have to change that field to?, |
| 12:26 |
kivilahtio |
@hates |
| 12:26 |
pinesol_green |
kivilahtio: kivilahtio doesn't seem to hate anything. |
| 12:26 |
kivilahtio |
heard that? ;) |
| 12:27 |
Dyrcona |
@dontcare MacOS X Leopard |
| 12:27 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona no longer loves MacOS X Leopard. |
| 12:27 |
rfrasur |
frank: I'm honestly not sure. I just understand the behavior. One of this lovely ladies or gentlemen will be more help on the how. |
| 12:27 |
rfrasur |
this/these |
| 12:27 |
Dyrcona |
Grace periods can be configured in a number of ways, depending on your Evergreen version. |
| 12:30 |
frank |
Dyrcona: 2.3.7 |
| 12:30 |
Dyrcona |
frank: Are you using in-db circ rules or scripts? |
| 12:31 |
Dyrcona |
And, do you run the fine_generator script on a regular basis? |
| 12:32 |
|
ericar joined #evergreen |
| 12:32 |
dbs |
Yeah, default grace period = 1 fine period, doesn't it? |
| 12:32 |
rfrasur |
dbs: yeah |
| 12:32 |
Dyrcona |
dbs: In 2.3.7, I think it has to be passed in as 1 otherwise it is zero..... |
| 12:32 |
|
acoomes joined #evergreen |
| 12:33 |
frank |
Dyrcona: I changed the default value from 1 to 0 and I tested it, I looks well, The system generated the bill |
| 12:33 |
Dyrcona |
I would have to checkout a 2.3 branch, but master ignores the grace period. |
| 12:34 |
Dyrcona |
frank: Grace period can also be set from config.circ_matrix_matchpoint and config.rule_recurring_fine. |
| 12:35 |
Dyrcona |
These would affect fine generation at checkin if using in-db circ rules. |
| 12:35 |
rfrasur |
frank: are you system admin? librarian? |
| 12:36 |
frank |
system admin from Evergreen IPICYT, Mexico |
| 12:36 |
rfrasur |
k |
| 12:36 |
rfrasur |
(oooo...Mexico! didn't know there were implementations there) |
| 12:37 |
rfrasur |
@love Evergreen |
| 12:37 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves Evergreen. |
| 12:38 |
frank |
yes, here is our catalog http://biblioteca.ipicyt.edu.mx/eg/opac/home, we are trying to convince other institutions to use evergreen as ILS |
| 12:38 |
dbs |
frank++ |
| 12:38 |
rfrasur |
frank++ |
| 12:39 |
frank |
we hope in 2 months have a new one implementation of evergreen in Mexico, we are helping to comimsa to migrate to SIABUC to evergreen, we hope they could adopt it well |
| 12:40 |
rfrasur |
Is your campus primarily English speaking? |
| 12:40 |
frank |
no, :P, spanish, we try to speak english, sorry if I have some mistakes |
| 12:41 |
rfrasur |
frank: not at all. Your English is fine :-). I was just interested in how using the OPAC will be. |
| 12:42 |
dbs |
https://translations.launchpad.net/evergreen/master/+lang/es says the TPAC is untranslated :/ |
| 12:42 |
rfrasur |
frank: Will it be translated to Spanish? |
| 12:42 |
rfrasur |
dbs: that was my next question. Hmm...seems like that might want to become a priority. |
| 12:42 |
kivilahtio |
dbwells, senator: Do you have any idea what happens to Issuances that are double-volumes. Like some special magazines can be published to contain two volumes. Does the Serials-module in anyway support these? |
| 12:43 |
frank |
We are using it in english because the institution is a research center, but we hope to start translating it to MX spanish |
| 12:44 |
kivilahtio |
dbwells, senator: so we have issuances like "1,2,3,4,5-6,7,8,9,10,11-12" |
| 12:44 |
senator |
kivilahtio: yes |
| 12:44 |
rfrasur |
frank: very good on both accounts |
| 12:44 |
kivilahtio |
senator, what if there is no way to predict them? |
| 12:45 |
kivilahtio |
senator, Do I have to include them in the caption_And_pattern? |
| 12:45 |
rfrasur |
dbs: here's a scenario - What if they wanted to have both an English and Spanish version of the OPAC? |
| 12:45 |
rfrasur |
is it the same OPAC and a toggle between languages? or how might that function? |
| 12:45 |
senator |
if the combined issuances cannot be predicted, you don't have to include them in the caption and pattern. i believe the workaround that most sites use is to delete the second issuance of the combined set, and to relabel the first |
| 12:46 |
dbs |
rfrasur: kind of like http://laurentian.concat.ca ? |
| 12:47 |
rfrasur |
dbs: exactly. |
| 12:47 |
rfrasur |
so the functionality already exists...there's just a need for the translation |
| 12:47 |
dbs |
rfrasur: that's supported out of the box, you just define as many languages as you want to support in the apache config |
| 12:47 |
rfrasur |
dbs++ |
| 12:48 |
kivilahtio |
senator, yes that was our solutions as well. But there is a problem with the basic_summary. It excludes these double-volumes from te summary pattern. Like my previous example would look like this "1-5,7-11" even if we wanted it to look like "1-12" |
| 12:48 |
senator |
kivilahtio: to solve that, you may be able to edit the holding_code of the combined issuance you have manipulated |
| 12:48 |
senator |
if subfield $b holds the month |
| 12:48 |
|
stevenyvr2 joined #evergreen |
| 12:49 |
senator |
setting that to 05-06 *may* cause the basic_summary to say the right thing |
| 12:49 |
senator |
but i'm not certain, and would need to experiment |
| 12:49 |
kivilahtio |
senator, I was hoping to edit the Serial::summarize_contents() with the help of my newlywed debugger. Because rebuilding the summaries would destroy any manual changes |
| 12:49 |
dbwells |
kivilahtio: yes, I was just about to say the same. Except I think the syntax you want would be 05/06. |
| 12:50 |
senator |
dbwells is no doubt correct |
| 12:50 |
kivilahtio |
senator, dbwells: I think I already have a kind of solution, but I ned to get deeper into the function to present the algorithm |
| 12:51 |
kivilahtio |
senator, dbwells : just asking about your opinion |
| 12:52 |
kivilahtio |
senator, dbwells : I was thinking of using the label to detect multivolume issues. like label containing String "4-6" could be targeted as a multivolume. |
| 12:52 |
|
jihpringle joined #evergreen |
| 12:52 |
dbwells |
kivilahtio: I would also say that the current summarization code is easily frustrated by any holding_code which is outside the prediction pattern. You can try the branch here for something a little more forgiving: https://bugs.launchpad.net/evergreen/+bug/1180039 |
| 12:52 |
pinesol_green |
Launchpad bug 1180039 in Evergreen 2.4 "Serial summarization should be more flexible" (affected: 1, heat: 6) [Low,Confirmed] |
| 12:54 |
kivilahtio |
dbwells, this reminds me of one thing. Where should I push some bugfixes i made to the regenerate_summaries? |
| 12:55 |
|
acoomes joined #evergreen |
| 12:55 |
dbwells |
kivilahtio: I don't think we ever opened a bug, but I think there is a collab branch for that. One second... |
| 12:55 |
rfrasur |
@note remember spanish translation https://translations.launchpad.net/evergreen/master/+lang/es |
| 12:55 |
pinesol_green |
rfrasur: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 12:55 |
rfrasur |
hmm, I'm registered and identified |
| 12:55 |
bshum |
With the bot. |
| 12:56 |
bshum |
vs. with Freenode |
| 12:56 |
dbwells |
kivilahtio: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/regen_serial_summaries |
| 12:56 |
dbwells |
kivilahtio: is that the code you are talking about? |
| 12:56 |
bshum |
@hate server power failures |
| 12:56 |
kivilahtio |
dbwells, yeah thats what I cloned, so I just push my modifications there? |
| 12:56 |
pinesol_green |
bshum: The operation succeeded. bshum hates server power failures. |
| 12:57 |
dbwells |
kivilahtio: yes, it is collab, go for it! |
| 12:57 |
rfrasur |
bshum++ #thanks |
| 12:57 |
kivilahtio |
dbwells, I got a nice hint from senator to check that out |
| 12:57 |
kivilahtio |
dbwells, ok dokey |
| 12:58 |
dbwells |
kivilahtio: Looking at it right now, I think the 'return' in the middle should probably be a 'next', so maybe that is in your group of fixes :) |
| 12:58 |
kivilahtio |
bshum, Have you encountered system freezing when using Evergreen? |
| 12:58 |
kivilahtio |
dbwells, indeed :D but I think that was the only one |
| 12:59 |
kivilahtio |
bshum, sometimes we can't shut our virtualized Evergreen down, I think apache2 fails to close down nicely |
| 12:59 |
kivilahtio |
bshum, same happens when not virtualized, but then we can just power down. |
| 12:59 |
bshum |
kivilahtio: I haven't noticed anything like that in my environment. The worst that happens is if I'm using NFS and I turn on/off servers in the wrong order causing lockups while it waits for shares that don't exist. |
| 13:02 |
bshum |
kivilahtio: We're using KVM though, not Xen, for our environment. |
| 13:02 |
bshum |
And I might have added some overkill hardware to the mix as far as how much RAM I dedicated to our virtual instances :D |
| 13:03 |
kivilahtio |
bshum, how come? |
| 13:03 |
bshum |
Because it was there. |
| 13:03 |
bshum |
Mostly. |
| 13:03 |
|
Polo joined #evergreen |
| 13:03 |
kivilahtio |
bshum, what do you mean with "overkill" :D W are looking forward to 128GB RAM for our province and little more to grow |
| 13:04 |
kivilahtio |
I never thought Evergreen could be so memory hungry |
| 13:04 |
bshum |
kivilahtio: Most of our hardware is in the database server of course. Our app servers are virtualized, so I think I gave them like 48 GB of RAM out of the 128 GB that was available. To play with. |
| 13:04 |
bshum |
But we're barely scratching 12 GB of RAM on the app servers now. |
| 13:04 |
Polo |
Hello, Why can't I delete a user from the actor.usr table. We have some users that are floating in there that really shouldn't be that aren't linked to any cards. but when I try to delete them from CLI they get added right back |
| 13:05 |
kivilahtio |
bshum, I shudder at the thought that I should have to build and configure our servers and Evergreen clustered on top of them |
| 13:05 |
Dyrcona |
Polo: Evergreen doesn't delete users. The database trigger sets a field in actor.usr, deleted, to true. |
| 13:05 |
csharp |
kivilahtio: if you cluster out apache and opensrf services, you can have more machines with lower resources |
| 13:05 |
kivilahtio |
csharp, but afaik the biggest resource hog is the search and biblio |
| 13:05 |
csharp |
kivilahtio: we have a script that does the clustering (as per our setup, but could be adapted) |
| 13:06 |
kivilahtio |
btw |
| 13:06 |
kivilahtio |
I wrote a small plan for our Evergreen cluster |
| 13:06 |
csharp |
kivilahtio: http://git.evergreen-ils.org/?p=contrib/pines/genasys.git;a=summary if you're interested |
| 13:06 |
kivilahtio |
I could link it here if you are interested. But I have a gut feeling its pretty crappy |
| 13:06 |
Polo |
Dyrcona, I understand that but I have some stray users that have no card value no name no real information in there that I want to clean out of the table. DELETE FROM actor.usr WHERE id = 'whatever' fails to actually delete the row |
| 13:06 |
|
RBecker joined #evergreen |
| 13:07 |
Polo |
So what i'm asking is there a way to remove them from the table with out removing everything? |
| 13:07 |
bshum |
kivilahtio: I enjoy seeing server plans. Feel free to share :D |
| 13:07 |
kivilahtio |
https://docs.google.com/document/d/1jJhdNtnxEvYVG15nyH8dHhKypm6W5vPli4POg6OZpdI/edit?usp=sharing |
| 13:07 |
Dyrcona |
Polo: Then let me restate, there is a DELETE TRIGGER on actor.usr in the database that sets the deleted field. You will need to disable that trigger to actually delete the rows. |
| 13:08 |
kivilahtio |
feel free to comment |
| 13:08 |
Polo |
Gotcha |
| 13:08 |
csharp |
kivilahtio: nice |
| 13:08 |
kivilahtio |
bshum, csharp : if you have some plans of your own I would love to read them and try to learn something |
| 13:08 |
Polo |
Dyrcona: do you know the name of the trigger or how I can find the name? |
| 13:09 |
kivilahtio |
csharp, I am happy you like it, because I got a rather negative reaction from our municipal IT monopoly/service provider |
| 13:09 |
Dyrcona |
\dt actor.usr in psql should tell you. |
| 13:09 |
kivilahtio |
csharp, but they are pissed off about me stepping on their toes |
| 13:10 |
csharp |
kivilahtio: I would consider the utility server of a bit higher priority (holds, fine generation, notices) |
| 13:10 |
kivilahtio |
csharp, undercutting them at every opportunity |
| 13:10 |
csharp |
kivilahtio: you should have a convo with bradl about the early days of EG in PINES ;-) |
| 13:11 |
kivilahtio |
csharp, yeah, well the states has always been few steps ahead when it comes to Open Source, than Finland I think |
| 13:11 |
Polo |
\dt actor.usr on returns the table name etc |
| 13:11 |
Polo |
\dft actor.usr returns blank |
| 13:11 |
Dyrcona |
\d |
| 13:11 |
Polo |
kk ty |
| 13:12 |
Dyrcona |
Polo: You might want to look at this: http://www.postgresql.org/docs/9.2/interactive/index.html |
| 13:13 |
csharp |
kivilahtio: looks like a sound plan to me |
| 13:13 |
|
akilsdonk_ joined #evergreen |
| 13:15 |
kivilahtio |
csharp, thanks. Do you have any documents like these I could take a look at? |
| 13:16 |
csharp |
kivilahtio: lemme look around |
| 13:18 |
rfrasur |
kivilahtio: that's pretty cool |
| 13:19 |
csharp |
kivilahtio: not polished at all, but similar content: http://pastebin.com/WRpijm8G |
| 13:19 |
bradl |
csharp: the stories about tables being flipped over and shots being fired? |
| 13:20 |
csharp |
bradl: exactly ;-) |
| 13:20 |
bradl |
hah! |
| 13:21 |
bradl |
kivilahtio: so it seems the reaction for "those in power" is the same, no matter the side of the Atlantic |
| 13:22 |
rfrasur |
oooo...just read back about kivilahtio stepping on toes |
| 13:22 |
rfrasur |
kivilahtio++ |
| 13:23 |
kivilahtio |
bradl, The thing is that the contract between our municipal IT (PTTK) forbids any "competetive" business. They find it competetive that I want to buy hardware that doesn't come with a Windows preinstalled costing 800€ less |
| 13:23 |
bradl |
Oh, I had to battle to NOT use Oracle |
| 13:24 |
* rfrasur |
is mesmerized by the ridiculous logic. |
| 13:24 |
kivilahtio |
bradl, Or if I happened to have been offered some second hand servers in bulk for few hundreds of €, it was no way possible to buy those even if they would have been of tremendous value to us and rid us of the PTTK's crappy virtual environment |
| 13:25 |
|
collum joined #evergreen |
| 13:26 |
kivilahtio |
bradl, also we are recruiting now. And actually got a applications from a pretty talented "Open Source" revolutionary. Well we can't hire him because we need to make sure PTTK doesn't have anyone to replace him. It's all fine and games as long as we hire the best man, but I am not certain that is about to happen. |
| 13:26 |
dbs |
If only Evergreen had used Oracle from the start... that would have helped the open source story nicely. |
| 13:27 |
kivilahtio |
bradl, so let's see what comes out of it. I actually was warned about the city bureaucracy... and quite frankly sometimes I think how nice it would be to not actually work under such barriers. Well lately it has been getting easier. |
| 13:27 |
kivilahtio |
venting out... |
| 13:27 |
kivilahtio |
dbs, a hint of sarcasm I presume? |
| 13:28 |
bradl |
We're still battling (especially in US federal govt) the perception that their IT would "never allow them to run open source" |
| 13:28 |
dbs |
Heh, a "hint" :) |
| 13:29 |
|
RBecker joined #evergreen |
| 13:29 |
kivilahtio |
can you imagine, I have been buying computer parts and building pc's because that can be thought of as a "upgrade" and not a new pc acquisitons, just because of this dumb contract |
| 13:30 |
rfrasur |
do they not factor in your time, I presume? |
| 13:30 |
rfrasur |
(obviously) |
| 13:32 |
kivilahtio |
rfrasur, even with my time involved i got a cheaper bargain |
| 13:33 |
kivilahtio |
+some debugging time in a hardware shop for AMD selling processors that don't work with said motherboards |
| 13:33 |
bradl |
csharp: btw, I am still coming for Tux! ;) |
| 13:33 |
rfrasur |
hmm, gotcha |
| 13:36 |
kivilahtio |
I think the issue is with big money having their foot so deep in our governments a$$. But luckily things are changing fast! Russia is making huge savings by adopting OS. And other as well. |
| 13:37 |
kivilahtio |
It is a huge advantage for us, that we can point out to you guys and say, "These guys did it, and they are 10 times bigger than us" |
| 13:38 |
rfrasur |
lol, no pressure :D |
| 13:38 |
kivilahtio |
yeah |
| 13:42 |
Dyrcona |
kivilahtio: http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/dyrcona/debug |
| 13:42 |
paxed |
rfrasur: you wondered earlier about OPAC in multiple languages... like dbs said, it's supported, but has some minor bugs (eg. bug 1156545) |
| 13:42 |
pinesol_green |
Launchpad bug 1156545 in Evergreen "Currency symbol and format should not be in po-file translatable texts" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1156545 |
| 13:42 |
rfrasur |
I'll say this...of course, I can't speak to anything but what I know and that is...here...in Indiana (not the broader U.S.), the government is full of people who have a million different motivations, but most of them are change adverse because it's scary and can be expensive. But, when they get on whatever kick they get on, the expensive isn't so bad if they can get a guarantee. Of course, we know that a written |
| 13:42 |
rfrasur |
guarantee means less than the paper it's printed on. Even so, they have a tendency to think that brand name (Windows, Xerox, blah blah blah) implies better quality and that guarantee. They'd rather trust the name than their people. |
| 13:43 |
* Dyrcona |
bites his anarchist tongue. |
| 13:43 |
rfrasur |
paxed: I've been taking a look through it. It doesn't look like it'd be awful to at least do a little translation work on it and then let bug fixers fix bugs. |
| 13:43 |
rfrasur |
Dyrcona: anarchist or revolutionist? |
| 13:44 |
paxed |
rfrasur: ours is at http://193.65.112.188/ |
| 13:44 |
* rfrasur |
is more for controlled disassembly and reconfiguration |
| 13:44 |
Dyrcona |
rfrasur: voluntarist |
| 13:44 |
bradl |
rfrasur: you mean "no one ever got fired for buying IBM"? |
| 13:44 |
rfrasur |
Dyrcona++ |
| 13:45 |
rfrasur |
bradl: lol...not in my knowledge...but you know. It fluctuates. Also depends on how much IBM is contributing to who, what and where. |
| 13:45 |
Dyrcona |
bradl++ |
| 13:45 |
paxed |
rfrasur: and it could be considered usable in finnish |
| 13:45 |
Dyrcona |
Although, I have heard of someone who was fired for buying IBM, but it may be an urban legend. |
| 13:46 |
bradl |
rfrasur: it's an old marketing phrase :) |
| 13:46 |
rfrasur |
paxed: excellent on the OPAC |
| 13:46 |
dbs |
That's high praise coming from paxed! |
| 13:46 |
rfrasur |
bradl: I figured...after I came up with a response (autoresponder) |
| 13:47 |
paxed |
we just need to get our translations back into master :P |
| 13:47 |
paxed |
s/translations/updated translations/ |
| 13:48 |
bradl |
Dyrcona: musta been an Apple employee ;) |
| 13:48 |
Dyrcona |
heh |
| 13:48 |
rfrasur |
bradl++ |
| 13:48 |
dbs |
Apple bought IBM in the PowerPC days |
| 13:49 |
rfrasur |
(stupid monstrosity) |
| 13:50 |
csharp |
@blame add $who musta been an Apple employee. |
| 13:50 |
pinesol_green |
csharp: The operation succeeded. Blame #11 added. |
| 13:51 |
bradl |
wow, PowerPC. I'd forgotten about that. Along with thing like Cyrix and math coprocessors :) |
| 13:52 |
|
akilsdonk__ joined #evergreen |
| 13:52 |
dbs |
486 _DX_ I said. DX! |
| 13:53 |
paxed |
Turbo button! |
| 13:53 |
kivilahtio |
I remember math coprocesors |
| 13:53 |
Dyrcona |
MMU |
| 13:53 |
kivilahtio |
they "supposedly" gave the pc a kickass advantage in Worms |
| 13:53 |
bradl |
wow, turbo button |
| 13:53 |
bradl |
paxed++ |
| 13:53 |
* eeevil |
had fun in 96 building a cyrix 6x86-based monster with ... wait for it! ... 128MB RAM from Tiger Direct |
| 13:53 |
dbs |
hmm. we should add a turbo button the to staff client |
| 13:53 |
kivilahtio |
dbs, I second that |
| 13:54 |
rfrasur |
dbs++ #add a bug report |
| 13:54 |
bradl |
eeevil: 128MB? holy cow. I think my main desktop had 8 mb. |
| 13:54 |
Dyrcona |
If we're waxing nostalgic, I miss 680x0 assembly..... |
| 13:56 |
rfrasur |
and cassette input |
| 13:56 |
* Dyrcona |
has a VIC-20 with a cassette drive that still might work. |
| 13:56 |
bradl |
eeevil: no, I had 16 MB. I had 16 crappy 1 mb 30-pin SIMMS in an adapter to plug into the... 72(?) pin slots on my mobo |
| 13:56 |
rfrasur |
lol, GSoC...a light v. of EG to run on Commodore 64 |
| 13:57 |
Dyrcona |
640K is enough for anyone! |
| 13:57 |
berick |
heh, the staff client turbo button just prints out a bus ticket to your data center |
| 13:57 |
Dyrcona |
berick++ |
| 13:57 |
bradl |
berick++ |
| 13:58 |
rfrasur |
sigh - no local public transportation = no turbo button functionality |
| 14:00 |
kivilahtio |
Ok, gentlemen, and ladies, time for me to go bunk myself. (whatever that means) Good night. Nice chatting with you Open Source Fredom Fighters! |
| 14:01 |
rfrasur |
g'nite, kivilahtio: keep up the good fight. |
| 14:01 |
Dyrcona |
kmlussier: Are you using my development vm at this time? |
| 14:01 |
kmlussier |
I'm logged in, but I'm not really using it. Want me to log out? |
| 14:02 |
Dyrcona |
I am thinking of loading a new branch to pickup kivilahtio's debug tricks plus the round3 version of that acq branch. |
| 14:03 |
kmlussier |
Dyrcona++ Sounds good to me. |
| 14:03 |
Dyrcona |
Ok, then, I still have to merge everything, but I'll go ahead. |
| 14:05 |
kmlussier |
Dyrcona: Will you be re-adding all of the dev branches? I just noticed that berick updated working/user/berick/acq-order-ident-apply-inline too. |
| 14:05 |
jeff_ |
neat. i have many rows in asset.opac_visible_copies with a null copy_id; |
| 14:07 |
|
RBecker joined #evergreen |
| 14:08 |
dbs |
jeff_: we have 0 such rows, if that makes you feel any better |
| 14:11 |
csharp |
kivilahtio++ # sharing experiences |
| 14:12 |
csharp |
0 rows here too |
| 14:13 |
dbs |
berick: fwiw, i think bug 1187433 is a must-merge for 2.4.1 - thorny as the upgrade side of things might be |
| 14:13 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:15 |
eeevil |
dbs: I've asked for a third set of eyes as well, on that bug in particular, and won't be cutting 2.4.1 until that goes in |
| 14:16 |
csharp |
Dyrcona: yes 'ForwardX11 yes' in .ssh/config works |
| 14:16 |
Dyrcona |
csharp: Thought so. Wonder if that should be added to the documentation? |
| 14:17 |
* Dyrcona |
thinks maybe we should write a beginner's guide to hacking evergreen. |
| 14:17 |
csharp |
I was thinking the same thing last week |
| 14:17 |
csharp |
I don't have the skills yet, but I am familiar with the environment |
| 14:17 |
paxed |
it's a huge subject |
| 14:17 |
* rfrasur |
was just thinking that there's no reason more non-developers are helping to translate. |
| 14:18 |
rfrasur |
are...aren't |
| 14:18 |
csharp |
just time and motivation |
| 14:18 |
csharp |
but mostly motivation, I think |
| 14:18 |
rfrasur |
I dunno. Actually, I think they don't understand that they CAN. |
| 14:19 |
paxed |
also: Launchpad. |
| 14:19 |
eeevil |
csharp: I wonder if that would be something like a Carl Sagan's "apple pie from scratch" recipe... |
| 14:19 |
rfrasur |
eeevil++ |
| 14:19 |
paxed |
eeevil: i don't know that, but i bet it starts something like "First, create a universe ..." |
| 14:19 |
jeff_ |
dbs: makes me feel only a little better. i've no idea where these nulls came from. checking vs a previous snapshot to see if they've grown/shrunk at all. |
| 14:20 |
eeevil |
paxed: indeed :) |
| 14:20 |
|
RBecker joined #evergreen |
| 14:21 |
|
moodaepo joined #evergreen |
| 14:22 |
|
gdunbar joined #evergreen |
| 14:23 |
|
kbeswick joined #evergreen |
| 14:23 |
* berick |
backs away slowly from bug 1187433 |
| 14:23 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:23 |
berick |
thanks for the summary dbs |
| 14:23 |
* berick |
just wanted to kick it in the gut and merge it |
| 14:23 |
berick |
but that seems premature |
| 14:37 |
Dyrcona |
kmlussier: My dev vm should be running OpenSRF again. |
| 14:37 |
kmlussier |
Dyrcona: Thanks! |
| 14:47 |
|
ldwhalen joined #evergreen |
| 15:00 |
jeffdavis |
So I'm reading 1187433 and thinking about the implications for our 2.4 upgrade in a few days... |
| 15:00 |
eeevil |
jeffdavis: what are you at currently? |
| 15:00 |
jeffdavis |
2.2 |
| 15:04 |
eeevil |
it looks like simply delaying the execution of Open-ILS/src/sql/Pg/version-upgrade/2.3-2.4-supplemental.sh until after you run 2.4.0-2.4.1-upgrade-db.sql should be enough |
| 15:07 |
dbs |
eeevil: agreed, but probably worthwhile munging the 2.3-2.4 upgrade to include the good metabib function bodies, just in case |
| 15:08 |
eeevil |
dbs: well, the 2.3-2.4 is 2.4.0 specific, so you'd run the 2.4.0-2.4.1 script anyway, right? |
| 15:09 |
jeffdavis |
I had been planning to go live on 2.4.0 since we don't have time to test 2.4.1, but I dunno how much of a consideration that sort of situation should be here |
| 15:10 |
dbs |
eeevil: you might, if the 2.3-2.4 script didn't say "Now run supplemental.sh" right at the end of it? |
| 15:10 |
eeevil |
jeffdavis: there are significant bug fixes that will exist in 2.4.0, fwiw. the apostrophe stuff is just one of them |
| 15:10 |
* dbs |
was about to recommend to jeffdavis to skip 2.4.0 :) |
| 15:10 |
eeevil |
dbs: oh, that should be changed, yes. sorry |
| 15:11 |
eeevil |
er, will exist in 2.4./1/ |
| 15:11 |
eeevil |
not 2.4.0 |
| 15:11 |
berick |
could we just replace the 2.3->2.4 upgrade with a 2.3 -> 2.4.1? |
| 15:12 |
jeffdavis |
eeevil: is there a working branch for 2.4.1? |
| 15:13 |
dbs |
origin/rel_2_4 is the working branch, + some bug fixes yet to be merged :) |
| 15:13 |
jeffdavis |
ok, I've got most of the stuff in there (except the latest 2 commits I think) - that helps |
| 15:14 |
dbs |
jeffdavis: you're not using script-based circ anymore, right? bug 1192019 is pretty important for those that still are (us, UPEI, ... ?) |
| 15:14 |
pinesol_green |
Launchpad bug 1192019 in Evergreen "Renewals fail with script-based circulation" (affected: 1, heat: 8) [High,New] https://launchpad.net/bugs/1192019 |
| 15:14 |
eeevil |
jeffdavis: https://bugs.launchpad.net/evergreen/+bug/1187433 and https://bugs.launchpad.net/evergreen/+bug/1192019 (which I'm about to merge) are all that are left, I think |
| 15:14 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 18) [High,Confirmed] |
| 15:14 |
eeevil |
dbs beat me to it again! ;) |
| 15:14 |
dbs |
hah |
| 15:14 |
* dbs |
hopes we can cut over to in-db real soon now |
| 15:16 |
jeffdavis |
we have one or two sites using circ scripts but they were just waiting for 2.4 to switch to in-db, so we're good |
| 15:16 |
jeffdavis |
thanks for pointing me at those bugs, i'll have a look |
| 15:20 |
eeevil |
master has 1192019 now |
| 15:20 |
eeevil |
as does 2.4 |
| 15:21 |
|
dboyle joined #evergreen |
| 15:22 |
pinesol_green |
[evergreen|Dan Scott] Support script-based circ in nearest_hold() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d273da4> |
| 15:40 |
|
dboyle_ joined #evergreen |
| 15:50 |
ldwhalen |
How do I assign the 2.4 tag to a Ticket? It is not in the drop down list of tags when creating a new ticket. |
| 15:51 |
paxed |
you mean milestones? |
| 15:51 |
paxed |
there's 2.4.1 |
| 15:51 |
ldwhalen |
Sorry, wrong IRC. |
| 15:52 |
|
ElliotFriend joined #evergreen |
| 15:54 |
ElliotFriend |
Can anyone help me figure out why some of the "General" macros don't seem to work for me when I print a checkin receipt? |
| 15:54 |
pinesol_green |
[evergreen|Bill Erickson] 2.3.8 stub upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0136b8a> |
| 15:56 |
ElliotFriend |
From what I can gather %PATRON_FIRSTNAME% %PATRON_LASTNAME% and %PATRON_BARCODE% don't seem to work on checkin receipts, but do seem to work fine on checkout receipts. They show up as %PATRON_FIRSTNAME%, etc. |
| 15:57 |
ElliotFriend |
%patron_barcode% (lowercase) shows up as "undefined" in both places. |
| 16:06 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Add (noop) upgrade script for 2.2.10 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0ad5370> |
| 16:07 |
|
ldwhalen joined #evergreen |
| 16:12 |
|
jlj1290 joined #evergreen |
| 16:13 |
jlj1290 |
I can't get the live demos to work. This one I can get to recognize the server demo.ils.edoceo.com but the user name or password is incorrect. Has it been changed? |
| 16:14 |
kmlussier |
jlj1290: I would recommend e-mailing edoceo about that. I know it has been reset in the psat. |
| 16:14 |
kmlussier |
s/psat/past |
| 16:14 |
* gmcharlt |
just had a violent flashback to middle school |
| 16:15 |
jlj1290 |
Ok thank you I will try doing that. |
| 16:15 |
kmlussier |
jlj1290: There's a link to his web site on the downloads page. You should be able to find his contact info t here. |
| 16:15 |
|
_bott_ joined #evergreen |
| 16:16 |
senator |
gmcharlt++ |
| 16:17 |
phasefx |
ElliotFriend: I think in general EG advertises certain macros (and list columns) even when the data isn't really there in a given context to display. It's worthy of a bug report, but I'm not sure there's a quick fix |
| 16:19 |
phasefx |
ElliotFriend: with check-in for example, you can check in multiple items from different patrons, and the %PATRON_FIRSTNAME% macro is associated with the whole slip, not specific lineitems, so it wouldn't know which patron to display |
| 16:20 |
ElliotFriend |
phasefx: That makes sense! And, that makes it less confusing to me :-D |
| 16:22 |
ElliotFriend |
As a sidenote, do you know if it's possible to print %PATRON_BARCODE% (on a check-out receipt, for example) as a barcode, rather than numbers? |
| 16:22 |
phasefx |
yes, it is. I may still have an example somewhere <looks> |
| 16:22 |
phasefx |
you'll need a barcode font to do it |
| 16:23 |
ElliotFriend |
On the workstation? I already do, not sure how to tell the staff client (or printer driver?) to use it... |
| 16:23 |
kmlussier |
ElliotFriend: Try this http://masslnc.cwmars.org/node/2817#comment-848 |
| 16:24 |
kmlussier |
ElliotFriend: I haven't tried it, but it was a nice tip that was just posted on our site a couple days ago. |
| 16:25 |
ElliotFriend |
kmlussier: I'll definitely take a look at that. Thanks! |
| 16:25 |
phasefx |
ElliotFriend: that's the strategy I used, a font tag. I thought I had wrote up a nice example somewhere |
| 16:31 |
ElliotFriend |
Here's the bug report: https://bugs.launchpad.net/evergreen/+bug/1192699 |
| 16:31 |
pinesol_green |
Launchpad bug 1192699 in Evergreen "Various Patron-centric Macros Don't Work with Checkin Receipt Template" (affected: 1, heat: 6) [Undecided,New] |
| 16:37 |
ElliotFriend |
phasefx: kmlussier: that did the trick with the barcode on the receipt. Thanks! |
| 16:42 |
pastebot |
"dbs" at 204.193.129.146 pasted "Current highest offenders on the osrfwarn log hit list" (6 lines) at http://paste.evergreen-ils.org/18 |
| 16:44 |
jeff |
dbs++ |
| 16:47 |
dbs |
the INNER problem is a one-liner |
| 16:48 |
* dbs |
gets to work |
| 16:53 |
paxed |
@hate perl |
| 16:53 |
pinesol_green |
paxed: The operation succeeded. paxed hates perl. |
| 16:58 |
phasefx |
ElliotFriend: kmlussier: just for reference and IRC logs: http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:barcode_font |
| 16:59 |
jeffdavis |
@wholoves perl |
| 16:59 |
pinesol_green |
jeffdavis: I can't find anyone who loves perl. |
| 16:59 |
csharp |
@whocares perl |
| 16:59 |
pinesol_green |
Dyrcona and paxed hate perl |
| 16:59 |
kmlussier |
phasefx: Ah, nice! Maybe we can incorporate that in the official docs too. |
| 16:59 |
phasefx |
please do |
| 17:00 |
* dbs |
files bug 1192710 with a pullrequest accordingly |
| 17:00 |
pinesol_green |
Launchpad bug 1192710 in Evergreen "QP uses numeric cmp operator for comparing strings, fills logs with warnings" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1192710 |
| 17:00 |
kmlussier |
phasefx: Will do. After I'm done with acq docs. :P |
| 17:00 |
phasefx |
kmlussier: those are probably much more important :D |
| 17:01 |
dbs |
kmlussier++ # acq docs |
| 17:02 |
ElliotFriend |
On another subject, where can I adjust SMTP settings for Evergreen? All evergreen services are installed on a single server. I can easily direct to another server for outbound SMTP, if need be. |
| 17:02 |
gmcharlt |
ElliotFriend: smtp_server in /openils/conf/opensrf.xml |
| 17:03 |
gmcharlt |
it's pretty common to run exim4 or postfix on an Evergreen server if no external MTA is available |
| 17:04 |
gmcharlt |
(or if you don't trust the external MTA's uptime) |
| 17:05 |
ElliotFriend |
gmcharlt: Thanks! Restart needed after changing those? What's the difference between "global email notification settings" and "global mail server settings"? Change both? |
| 17:06 |
gmcharlt |
ElliotFriend: change both, and yes, restart services |
| 17:06 |
ElliotFriend |
Also, I see a bunch of SIP settings below that, I've known there is a SIP server involved with evergreen, but don't really understand it's purpose? Can anybody explain it? |
| 17:06 |
dbs |
berick: would that "more extensive refactoring to avoid the next out of an eval" amount to wrapping the remaining logic in the eval in an "else { .. }" block? |
| 17:06 |
ElliotFriend |
gmcharlt: Thanks! |
| 17:07 |
dbs |
ElliotFriend: SIP is a protocol usually used by self-check machines, automated material handlers, or authentication systems |
| 17:08 |
dbs |
(an example of the latter being PC reservation systems) |
| 17:08 |
ElliotFriend |
dbs: So, it's not intended to work with our on-premise Asterisk server to make calls, or anything? |
| 17:08 |
gmcharlt |
yep, different SIP protocol |
| 17:08 |
gmcharlt |
wait |
| 17:08 |
bshum |
In opensrf.xml I think it's phone stuff. |
| 17:08 |
gmcharlt |
correct |
| 17:08 |
dbs |
heh |
| 17:09 |
gmcharlt |
oils_sip.xml is the *other* SIP that dbs was talking about |
| 17:09 |
dbs |
sorry, for once SIP is SIP-as-in-VOIP in this context |
| 17:09 |
bshum |
other_sip-- |
| 17:09 |
ElliotFriend |
Dangit! Just when I get my head around one SIP protocol, I find out *another* one exists! :-D |
| 17:10 |
gmcharlt |
it's a conspiracy! |
| 17:10 |
berick |
dbs: i could be wrong, but I recall it being worse than that. IIRC, i set out to fix it before realizing it would require shuffling some stuff around... |
| 17:10 |
* berick |
looks again |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
dbs |
berick: yeah, there are a few cases where next is invoked |
| 17:12 |
dbs |
it just so happens that all 22,000 of them in our logs today are from line 1135 |
| 17:12 |
csharp |
"protocols"-- |
| 17:12 |
berick |
yeah, i was wondering when piping WARN to the syslog files would result in some unexpected OMGs... |
| 17:14 |
berick |
dbs: but anyway, yes, your solution sounds sane |
| 17:15 |
* berick |
wonders if it complains about 'return' from an eval |
| 17:17 |
berick |
apparently not |
| 17:17 |
dbs |
kind of hating the whitespace fix only being in master :/ |
| 17:17 |
berick |
maybe we should move the guts of the loop to a sub and replace the 'next' calls with 'return' calls |
| 17:17 |
berick |
kill 'em all in one swoop |
| 17:18 |
dbs |
that's the initial bigger refactoring I had considered |
| 17:18 |
berick |
dbs: or.. wrap the all to next in a 'no warnings' .. 'use warnings' /me ducks |
| 17:18 |
berick |
to get over the hump |
| 17:18 |
berick |
s/all/call/ |
| 17:19 |
dbs |
yeah, don't like that much |
| 17:28 |
* dbs |
throws user/dbs/silence_fine_generator_eval_next into working quickly |
| 17:35 |
* berick |
will give that a hearty poke on the morrow |
| 17:52 |
|
b_bonner left #evergreen |
| 17:53 |
|
b_bonner joined #evergreen |
| 18:11 |
|
misilot joined #evergreen |
| 18:44 |
|
dbwells_ joined #evergreen |
| 18:47 |
|
zxiiro joined #evergreen |
| 19:56 |
|
dboyle joined #evergreen |
| 20:50 |
|
stevenyvr2 left #evergreen |
| 21:11 |
|
misilot joined #evergreen |
| 21:14 |
|
_bott_ joined #evergreen |
| 21:29 |
|
kmlussier joined #evergreen |
| 21:35 |
|
finnapz joined #evergreen |
| 21:37 |
|
finnapz joined #evergreen |
| 21:43 |
|
finnx2 joined #evergreen |
| 21:46 |
|
finnx2 joined #evergreen |
| 21:51 |
|
finnx1 joined #evergreen |
| 22:00 |
|
finnx1 left #evergreen |
| 22:01 |
|
finnx1 joined #evergreen |
| 22:43 |
|
finnx1 left #evergreen |
| 22:43 |
|
finnx1 joined #evergreen |
| 23:03 |
|
ldwhalen joined #evergreen |
| 23:58 |
|
_bott_ joined #evergreen |
