| Time |
Nick |
Message |
| 02:54 |
|
StomproJ joined #evergreen |
| 03:31 |
|
Stompro joined #evergreen |
| 03:59 |
|
StomproJ joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:02 |
|
Stompro joined #evergreen |
| 07:07 |
|
StomproJ joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
agoben joined #evergreen |
| 08:17 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
collum joined #evergreen |
| 08:44 |
csharp |
9d1d36d3 |
| 08:44 |
pinesol_green |
csharp: [evergreen|Galen Charlton] LP#1356477: teach OPAC patron registration form about staged user (opt-in) settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d1d36d> |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:51 |
JBoyer |
Yay translations! If anyone has time for a quick explanation of how exactly values get from config.i18n_core to the opac I'd appreciate it. I'm currently seeing what appear to be essentially random strings chosen for the item_lang filter in the advanced search at dev.evergreen.lib.in.us when using es-ES. |
| 08:51 |
JBoyer |
For instance, Malay is translated to 8 mm. |
| 08:52 |
JBoyer |
The ccvm ids are correct though, it's not as if the ccvm id for Maylay is translated to 8 mm., it's just using the wrong translations. :( |
| 08:53 |
Dyrcona |
And, I think I found a bug in Pg::DBD... :( |
| 08:54 |
|
bos20k joined #evergreen |
| 08:54 |
JBoyer |
There are also some fixed field values in there too, such as Adolescente for Gothic. |
| 08:55 |
Dyrcona |
JBoyer: That last one maybe hard to argue with. :) |
| 08:55 |
JBoyer |
(Adolescent being an Audience fixed field value, if you don't play around with that much) |
| 08:55 |
JBoyer |
Hah! |
| 08:55 |
JBoyer |
Dyrcona++ |
| 08:55 |
Dyrcona |
My sitch: I have a query with numbered placeholders: $1...$6. |
| 08:56 |
Dyrcona |
I double checked that $4 is indeed in the query, doesn't appear twice, etc. |
| 08:56 |
Dyrcona |
When I try to bind param 4, it tells that is an invalid parameter. |
| 08:57 |
JBoyer |
Is the type ambiguous? |
| 08:57 |
Dyrcona |
um, no. |
| 08:57 |
Dyrcona |
I found it..... It's a bug in my query. |
| 08:58 |
Dyrcona |
missing a closing single quote. |
| 08:58 |
Dyrcona |
See, that's usually the case with things like that. :) |
| 08:58 |
JBoyer |
3 cheers for the rubber duck! |
| 08:59 |
Dyrcona |
Hip! Hip! Hooray! |
| 08:59 |
Dyrcona |
And, this version of my query is even slower than the one with 2 left joins! |
| 08:59 |
Dyrcona |
I thought this would be the fastest of the 3 versions.... |
| 09:00 |
tsbere |
Dyrcona: So the bug is "it doesn't read your mind and correct your query on the fly"? ;) |
| 09:00 |
csharp |
@who is today's rubber duck? |
| 09:00 |
pinesol_green |
genpaku is today's rubber duck. |
| 09:04 |
Dyrcona |
tsbere: :) I'm still waiting for that patch! |
| 09:07 |
Dyrcona |
Pro-tip: two with queries on mrfr that are left joined to a base query is faster than the same base query with two left joins on mrfr is faster than the base query joined to a with query that has two unions of mrfr (i.e. mrfr joined 3 times). |
| 09:08 |
Dyrcona |
Now, to git reset --hard HEAD, git stash pop, git stash clear, and then revert a bunch of revert commits.... :) |
| 09:08 |
Dyrcona |
git is your friend! |
| 09:10 |
JBoyer |
I keep my git cheat sheet in a file marked git_howto-20130610_v2_draft_final_for_realz_this_time |
| 09:11 |
Dyrcona |
Heh |
| 09:13 |
Dyrcona |
anyway, I got my query time down to about 2 seconds from 17-18 seconds on average. |
| 09:14 |
Dyrcona |
That includes the time to passs through DBI and marshal the results in Perl. |
| 09:15 |
Dyrcona |
This is the same query where I was asking about tsquery yesterday. ;) |
| 09:15 |
Dyrcona |
tsquery made things worse in the original form. |
| 09:16 |
Dyrcona |
But I only ever got it to work with a hand-rolled query. |
| 09:16 |
Dyrcona |
So, anyway. |
| 09:17 |
JBoyer |
Well, never mind me and my "random strings" comment. I wasn't looking in the right place. It looks like either the ids in 950.seed-values.sql have changed over time or our tables are just a mess. the seed values for es-ES match up with the current 950, but not our db. |
| 09:17 |
JBoyer |
Now to asses the damage... :/ |
| 09:18 |
Dyrcona |
JBoyer: Could be vagaries of upgrades or patches applied before upgrades? |
| 09:18 |
Dyrcona |
Dunno if you do the latter. |
| 09:20 |
JBoyer |
I need to see how old they are, it's possible. And I have occasionally applied things pre-upgrade (I have to comment out large chunks of the upgrade scripts I'll be using next) these should be so old as to not be that. |
| 09:23 |
JBoyer |
It's tempting to delete everything from ccvm and reinsert, but that's a pain. |
| 09:25 |
Dyrcona |
Yes, and would take production down for a bit. |
| 09:25 |
Dyrcona |
Man, this branch has a really messy log! |
| 09:26 |
Dyrcona |
Including this commit: Revert "Revert "Change order by in match search per Janet."" |
| 09:26 |
Dyrcona |
Revert the Revert! |
| 09:29 |
|
yboston joined #evergreen |
| 09:30 |
Dyrcona |
Did I mention that someone once asked me why one would use branches in a repo where you are the sole developer? |
| 09:30 |
Dyrcona |
This branch is why. :) |
| 09:35 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Why we use branches, mmkay?" (251 lines) at http://paste.evergreen-ils.org/34 |
| 09:36 |
|
kmlussier joined #evergreen |
| 09:50 |
kmlussier |
Looks like we have a dev meeting scheduled for tomorrow. |
| 09:52 |
kmlussier |
yboston: Would you be able to add tomorrow's DIG meeting to the DIG calendar? It's at 1 p.m. Eastern. |
| 09:52 |
* kmlussier |
doesn't have the keys to that calendar yet. |
| 10:00 |
JBoyer |
Looks like our ids just went wherever whenever during the 2011 transition to SVF values. After some dev testing I'm going to experiment with dropping all of the ccvm values with id < 10000 and reload them. A full reingest is only around 14 hours, it's worth a shot and I don't plan to keep playing musical chairs with values for the rest of my career. |
| 10:02 |
miker |
JBoyer: Open-ILS/src/sql/Pg/version-upgrade/2.0-2.1-upgrade-db.sql:1447 may be useful to you as a starting point to fix the translations. won't work directly, though |
| 10:05 |
yboston |
kmlussier: I just added it. PM the email I shoudl use to give you DIG calednar access |
| 10:10 |
JBoyer |
miker, I found that earlier. I wouldn't have thought that unions would have allowed multiple tables to mix, but that's how it looks now. |
| 10:11 |
Dyrcona |
JBoyer: Unions work as along as the columns have the same data types. |
| 10:11 |
|
mmorgan1 joined #evergreen |
| 10:12 |
JBoyer |
Yeah, but what I'm wondering is if you can union 2 tables and have their rows interspersed. I would have expected all of table 1, then all of table 2, etc. |
| 10:13 |
Dyrcona |
Depends on how it's used. |
| 10:14 |
Dyrcona |
You could have an outer select with its own order by over a union query. |
| 10:19 |
miker |
JBoyer: oh, I was actually talking about rewriting the translations with the updates below the union ... I'd avoid changing ccvm if I could |
| 10:21 |
JBoyer |
Ah, I see. Yeah, messing with ccvm isn't a good time, but I'll try a few things. |
| 10:21 |
miker |
something like: UPDATE config.i18n_core SET identity_value = ccvm.id FROM config.coded_value_map AS ccvm WHERE fq_field = 'ccvm.value' AND ccvm.ctype = 'item_lang' AND identity_value = ccvm.code; |
| 10:23 |
miker |
hrm... well, that won't work ... but I think it can be made to |
| 10:46 |
|
mmorgan joined #evergreen |
| 10:51 |
|
Christineb joined #evergreen |
| 10:58 |
csharp |
so is it recommended/a good idea to upgrade users to the new password encryption after upgrading to 2.11? |
| 10:58 |
* csharp |
assumes yes, but wanted others' opinions/experiences |
| 10:59 |
Dyrcona |
csharp: It happens automatically the first time that they login, so in my opinion, "No." |
| 11:00 |
berick |
i am planning to auto-update the passwords (slowly, after hours) to force all accounts to the improved encryption |
| 11:01 |
berick |
well, when we get to that code |
| 11:01 |
|
DPearl joined #evergreen |
| 11:14 |
DPearl |
I'm attempting to install 2.11.1 with web client on debian-wheezy. Failing at the bower install step. Any hints? http://pastebin.com/k5Lf1w9F |
| 11:15 |
bshum |
You running it as the right user? |
| 11:15 |
csharp |
D |
| 11:15 |
Dyrcona |
DPearl: You're doing it as the wrong user. |
| 11:15 |
csharp |
Dyrcona: berick: thanks |
| 11:16 |
Dyrcona |
csharp: berick did the work, so put more weight on his opinion than mine. :) |
| 11:16 |
Dyrcona |
DPearl: Did you install Node.js from source code? (I'm guessing yes.) |
| 11:17 |
csharp |
I think I'll incorporate that into our upgrade downtime |
| 11:21 |
Dyrcona |
Hmm... Looks more like the wrong user owns the directories, maybe..... |
| 11:21 |
Dyrcona |
DPearl: What does "ls -ld ." show from the staff directory? |
| 11:21 |
Dyrcona |
Also, did you download a tarball? If so, you shouldn't have to do those steps. They should have been done by the packager. |
| 11:22 |
|
sandbergja joined #evergreen |
| 11:23 |
berick |
csharp: beware password migrations are (intentionally) slow. i would not suggest trying to update them all during an outage window. I forget the exact timeing (plus it depends on hardware), but a ~half-second password migration per user would result in a very long outage window. |
| 11:23 |
berick |
you could parallelize some... |
| 11:24 |
berick |
csharp: my plan is to deploy the code, let it run for a while, allowing a large percentage of passoword migrations to happen naturally, then go back and manually force the rest in batches after hours |
| 11:26 |
* Dyrcona |
is letting them happen "naturally." |
| 11:28 |
berick |
Dyrcona: yeah, my concern is that last 20% who don't log in for a year |
| 11:29 |
* berick |
hopes to one day deprecate the actor.usr.passwd column |
| 11:29 |
JBoyer |
berick, is there any reason to be careful about how they're parallelized? i.e. anything that needs to be taken into account beyond don't process the same account multiple times simultaneously. |
| 11:30 |
berick |
JBoyer: no I don't think so. should be able to just batch them up and go. |
| 11:32 |
JBoyer |
Cool. I didn't think it would matter, but I've been caught off guard before with bib records. |
| 11:34 |
DPearl |
It works *much* better as opensrf. Install instructions should specify this for better results. |
| 11:38 |
bshum |
DPearl: I'm pretty sure the instructions do say stuff to that effect |
| 11:40 |
bshum |
But I guess it needs some revision |
| 11:40 |
bshum |
It kind of depends on whether you're using the "user" to install or if opensrf is your user |
| 11:40 |
bshum |
Which the instructions diverged about awhile ago |
| 11:41 |
Dyrcona |
There are differences if you install Node.js from source versus using packages that are not mentioned in the README, I think. |
| 11:41 |
Dyrcona |
Like some Node config directory ending up owned by root. |
| 11:42 |
* bshum |
doesn't know why anyone would want to do the extra work by not just doing a -developer make install target :) |
| 11:42 |
Dyrcona |
But, it does say to skip all of those steps if you're installing from an official tarball. |
| 11:42 |
Dyrcona |
Well, on squeeze there was no package or it was too old. |
| 11:42 |
bshum |
Well... sure |
| 11:43 |
* Dyrcona |
is less sure about Wheezy. |
| 11:43 |
bshum |
But also squeeze was unsupported by the time we added those make targets no |
| 11:43 |
bshum |
I would expect the make target for -developer to work for any build requirements |
| 11:43 |
* Dyrcona |
isn't sure if it was unsupported when the instructions were first written. |
| 11:43 |
|
maryj joined #evergreen |
| 11:44 |
csharp |
berick: sounds good - thanks for the advice |
| 11:45 |
Dyrcona |
DPearl: This illustrates your problem: dpearl sapling:/home/opensrf/Evergreen-ILS-2.11.1/Open-ILS/web/js/ui/default/staff$ |
| 11:45 |
|
mmorgan joined #evergreen |
| 11:46 |
Dyrcona |
It's not an Evergreen-specific thing, but a UNIX permissions issue. |
| 11:46 |
Dyrcona |
That prompt indicates you're logged in as dpearl and trying to manipulate files in opensrf's home directory. |
| 11:46 |
Dyrcona |
Without very permissive settings on umask, that won't work. |
| 11:47 |
Dyrcona |
There's only so much UNIX we can teach in the README, I'm afraid. |
| 11:47 |
* Dyrcona |
does not mean that to beat up on DPearl, but to hopefully illustrate the situation for the logs and those who may come later. |
| 11:48 |
* bshum |
loves "sapling" :) |
| 11:48 |
Dyrcona |
Yeah, that's a good name for a test server/vm. |
| 11:48 |
bshum |
My trees never made it past "acorn" stage I guess. |
| 11:49 |
Dyrcona |
I name mine for the Linux distro of the vm. |
| 11:50 |
bshum |
That's what I do now. "ubuntu16" I hate you so.... |
| 11:50 |
Dyrcona |
I'm using the names: xenial, trusty, wheezy, jessie. |
| 11:52 |
|
bmills joined #evergreen |
| 11:54 |
|
Shae joined #evergreen |
| 11:54 |
|
miker joined #evergreen |
| 11:54 |
|
graced joined #evergreen |
| 11:55 |
|
drigney joined #evergreen |
| 11:56 |
|
brahmina joined #evergreen |
| 11:56 |
|
akilsdonk joined #evergreen |
| 11:56 |
|
jyorio joined #evergreen |
| 11:57 |
DPearl |
Go ahead! Beat me up! Thing is that the install instructions are otherwise careful to specify which user to execute the step, but not in this case. |
| 12:00 |
Dyrcona |
DPearl: Fair point, but I think the assumption is to run everything as "opensrf" unless otherwise specified. |
| 12:01 |
Dyrcona |
Where "opensrf" is the user who started the installation and owns the directory where the files are checked out/extracted. |
| 12:03 |
Dyrcona |
That said, any specific improvements to the README are most welcome as a git branch with a Launchpad bug. |
| 12:09 |
|
DPearl left #evergreen |
| 12:09 |
|
sarabee joined #evergreen |
| 12:20 |
* Dyrcona |
thinks I was a bit unfair with DPearl. |
| 12:33 |
* Dyrcona |
didn't mean to be.... |
| 12:34 |
Dyrcona |
Anyway, I've communicated with DPearl by email and he's just about got it working. |
| 12:37 |
Dyrcona |
@dessert 49 |
| 12:37 |
* pinesol_green |
grabs some Walker's Pure Butter Shortbread for Dyrcona |
| 12:38 |
|
jvwoolf joined #evergreen |
| 12:47 |
csharp |
berick: I've run the hold targeter v2 script several times now and all looks normal from this end of things (action.hold_copy_map looks as normal as I expect it to look - no errors when running the script against all our holds) - anything specific to try/look out for? |
| 12:51 |
|
jihpringle joined #evergreen |
| 12:56 |
berick |
csharp: great! nothing specific. the hope is it behaves the same as before when no new options are used. |
| 12:57 |
berick |
csharp: i am curious if you compared timing, though, to the current targeter |
| 12:57 |
berick |
or if you'd be willing to do so |
| 12:58 |
berick |
reset all active holds prev_check_time, run current targeter, then repeate with new targeter (or with --target-all) |
| 12:58 |
berick |
csharp: also, I pushed a small speed-up fix yesterday as you were testing. pulling that in would be good |
| 12:59 |
berick |
csharp++ |
| 13:00 |
csharp |
berick: I pulled in the fix before running it today - I'll run the other for a comparison, sure |
| 13:10 |
Dyrcona |
csharp++ # I never got around to looking at those changes. |
| 13:13 |
|
rhamby joined #evergreen |
| 13:19 |
|
kmlussier joined #evergreen |
| 13:23 |
* kmlussier |
encountered the same problems that DPearl encountered when installing the web client. |
| 13:24 |
|
abneiman joined #evergreen |
| 13:24 |
kmlussier |
I have notes for updating the install instructions. I think I even have a branch ready for the opensrf side of the instructions. |
| 13:27 |
jeffdavis |
We've had a request about using Evergreen to manage payments (debits/credits) for an external print management system. Is anyone doing anything like this? |
| 13:30 |
Dyrcona |
jeffdavis: SIP2 can be used to apply payments, but it doesn't have a way to bill a patron. |
| 13:34 |
Dyrcona |
jeffdavis: NCIP could do both with the "Create User Fiscal Transaction Service." |
| 13:34 |
Dyrcona |
But no code exists for NCIPServer for that service, and I doubt iNICPit has it, either. |
| 13:35 |
jeff |
jeffdavis: we've looked into it, but had trouble finding an external print management system that we didn't hate. |
| 13:38 |
Dyrcona |
jeff: Did you find any that could apply bills and payments in Evergreen? |
| 13:38 |
* Dyrcona |
is curious.... |
| 13:40 |
jeff |
i've never seen any explicitly claim that. a few that claim that they have an api, which we'd then make use of. |
| 13:40 |
jeff |
where a few is "at least one, i think" |
| 13:43 |
Dyrcona |
jeff: More or less what I thought. ;) |
| 13:45 |
jeff |
oftentimes it comes down to "keep the software and coinboixes we have, consider adopting some form of free print model, and revisit the available options again in 6-12 months" |
| 13:53 |
jeffdavis |
Dyrcona++ |
| 13:53 |
jeffdavis |
jeff++ |
| 13:53 |
jeffdavis |
thanks |
| 13:59 |
|
bmills joined #evergreen |
| 14:01 |
|
mmorgan1 joined #evergreen |
| 16:00 |
miker |
every time I see bug #1312699 I read "edible checkout history" |
| 16:00 |
pinesol_green |
Launchpad bug 1312699 in Evergreen "Editable Checkout History" [Wishlist,Fix released] https://launchpad.net/bugs/1312699 |
| 16:01 |
JBoyer |
Eating your way through the stacks |
| 16:06 |
bshum |
At least we have our priorities well established then :) |
| 16:06 |
* bshum |
needs to hunt down some snacks now |
| 16:17 |
|
mmorgan joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:41 |
|
bmills joined #evergreen |
| 17:45 |
gmcharlt |
@hate iframes |
| 17:45 |
pinesol_green |
gmcharlt: The operation succeeded. gmcharlt hates iframes. |
| 17:49 |
gmcharlt |
@hate dojo |
| 17:49 |
pinesol_green |
gmcharlt: The operation succeeded. gmcharlt hates dojo. |
| 17:53 |
jeffdavis |
@karma computers |
| 17:53 |
pinesol_green |
jeffdavis: computers has neutral karma. |
| 17:54 |
|
Christineb joined #evergreen |
| 20:36 |
|
kmlussier joined #evergreen |
| 21:25 |
|
bmills joined #evergreen |
| 21:26 |
|
bmills left #evergreen |
