| Time |
Nick |
Message |
| 00:04 |
|
dreuther joined #evergreen |
| 01:23 |
|
b_bonner_ joined #evergreen |
| 01:46 |
|
b_bonner joined #evergreen |
| 01:46 |
|
phasefx joined #evergreen |
| 01:46 |
|
Callender joined #evergreen |
| 01:46 |
|
RBecker joined #evergreen |
| 01:46 |
|
jcamins joined #evergreen |
| 03:29 |
|
AliceR joined #evergreen |
| 03:49 |
|
AliceR joined #evergreen |
| 05:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
mtate joined #evergreen |
| 06:40 |
|
eeevil joined #evergreen |
| 07:10 |
|
Callender joined #evergreen |
| 07:11 |
|
sarabee joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:51 |
* csharp |
bans the spammer from Open-ILS lists |
| 07:56 |
|
kmlussier joined #evergreen |
| 07:59 |
|
collum joined #evergreen |
| 08:06 |
|
ericar joined #evergreen |
| 08:13 |
|
wjr joined #evergreen |
| 08:16 |
|
mrpeters joined #evergreen |
| 08:22 |
|
mtate joined #evergreen |
| 08:22 |
|
eeevil joined #evergreen |
| 08:27 |
|
tspindler joined #evergreen |
| 08:33 |
|
Shae joined #evergreen |
| 08:44 |
|
akilsdonk joined #evergreen |
| 08:45 |
|
jwoodard joined #evergreen |
| 08:49 |
|
eeevil joined #evergreen |
| 08:49 |
|
mtate joined #evergreen |
| 08:50 |
|
phasefx joined #evergreen |
| 08:50 |
|
graced joined #evergreen |
| 08:51 |
|
Callender_ joined #evergreen |
| 09:00 |
|
aashita joined #evergreen |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
aashita joined #evergreen |
| 09:05 |
aashita |
Hi Berick! |
| 09:05 |
aashita |
i Just want to know only Julia Lima has done editing of UI style guide |
| 09:24 |
|
RoganH joined #evergreen |
| 09:36 |
mrpeters |
trying to load the concerto, etc. data in 2.7 -- error that "env_create.sql" is missing. Is this a part of the test dataset that maybe got left out, or a missing dependency |
| 09:39 |
tsbere |
mrpeters: I see env_create.sql in what I believe to be the correct location |
| 09:40 |
mrpeters |
is that not /home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql ? |
| 09:40 |
* tsbere |
is also looking at master |
| 09:41 |
Dyrcona |
mrpeters: Is this from git or a tarball? |
| 09:41 |
mrpeters |
tarball |
| 09:42 |
Dyrcona |
It's in git. Maybe it is missing from the tarball. |
| 09:42 |
mrpeters |
yeah, i think it may be, no worries, ill clone the repo and use that but someone might want to take a look |
| 09:43 |
Dyrcona |
"Someone" being bshum. ;) |
| 09:44 |
Dyrcona |
I checked rel_2_7 and tags/rel_2_7_0, and the file is in both branches where it should be. |
| 09:44 |
Dyrcona |
Just for the record. |
| 09:45 |
mrpeters |
/home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql is correct location, no? |
| 09:45 |
Dyrcona |
Yes, it is. |
| 09:45 |
Dyrcona |
jason jason:~/Src/Evergreen$ find ./ -name env_create.sql |
| 09:45 |
Dyrcona |
./Open-ILS/tests/datasets/sql/env_create.sql |
| 10:16 |
|
yboston joined #evergreen |
| 10:24 |
kmlussier |
dbs: I must have missed your comment in IRC regarding adding berick's script-based install to the README, but if you point me in the right direction, I can, at a minimum, add it to the OPW wiki page. |
| 10:25 |
kmlussier |
I'll even try to add it to the README if I get a minute to breathe. :) |
| 10:29 |
|
buzzy joined #evergreen |
| 10:31 |
mrpeters |
hmm, so the env_create is in the tarball, it's just looking for it in the cd, so you have to be in the tests/datasets/sql/ directory |
| 10:31 |
mrpeters |
my fault for the false alarm |
| 10:33 |
tsbere |
mrpeters: Are you loading the files manually, instead of with eg_db_config? |
| 10:33 |
mrpeters |
the test data? i just do psql evergreen < load_all.sql |
| 10:33 |
tsbere |
mrpeters: If you use the flags for eg_db_config it does the cd and such for you. |
| 10:33 |
mrpeters |
i just was supplying the full path to load_all.sql, not realizing i had to be in that directory |
| 10:34 |
mrpeters |
ah, interesting. didn't know you could use eg_db_config to load all of that test data |
| 10:36 |
tsbere |
mrpeters: --load-all-sample or --load-concerto-sample, I think. |
| 10:36 |
mrpeters |
awesome, good to know |
| 10:52 |
|
krvmga joined #evergreen |
| 10:54 |
krvmga |
we've marked a library as opac.holds.org_unit_not_pickup_lib and it's grayed out in the OPAC dropdown list. it's not grayed out in the KPAC dropdown list, though. since getit.tt2 uses the same org_selector.tt2, i'm not sure why one is grayed out and the other not. |
| 10:56 |
tsbere |
different flags on the selector? |
| 10:56 |
|
vlewis joined #evergreen |
| 10:57 |
tsbere |
krvmga: Looks like kpac has "hold_pickup_lib=0" instead of "hold_pickup_lib=1" |
| 10:57 |
krvmga |
tsbere: where are you seeing that? |
| 10:58 |
|
sandbergja joined #evergreen |
| 10:58 |
tsbere |
krvmga: the "INCLUDE build_org_selector" directive has several options after it. name, value, id, can_have_vols_only, hold_pickup_lib - Basically until you hit a ; or %] |
| 10:59 |
tsbere |
krvmga: I then compared the place_hold.tt2 file to the getit.tt2 file for what options are specified. |
| 11:00 |
krvmga |
tsbere: looking |
| 11:00 |
kmlussier |
tsbere: In the quest to make an Evergreen install easier for new contributors, dbs was suggesting we point to an install script from berick. But I'm guessing your work at http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/tsbere/buildvms could serve the same purpose for those using Ubuntu? |
| 11:00 |
tsbere |
kmlussier: Possibly. Dunno how much technical knowledge is needed for berick's. |
| 11:01 |
kmlussier |
tsbere: But I'm guessing that it would be easier for a new contributor to get your script up and running than to install Evegreen from scratch, right? |
| 11:03 |
tsbere |
kmlussier: My script requires a vm host machine. Not all servers can be used as such, and setting up VMs may be beyond some potential contributors even with my script. If you have a single standalone machine my scripts aren't guaranteed to be usable as a result. |
| 11:03 |
kmlussier |
tsbere: OK, understood. Thanks! |
| 11:03 |
mrpeters |
why not archive.georgialibraries.org ? |
| 11:03 |
mrpeters |
apt-get install evergreen-ils, boom, done |
| 11:04 |
tsbere |
kmlussier: In other words, my scripts are a potential option, but may not be suitable for everyone, and berick's script likely has similar limitations in ways. :P |
| 11:04 |
tsbere |
mrpeters: Because packaged evergreen doesn't help you write code for evergreen? |
| 11:05 |
mrpeters |
"In the quest to make Evergreen install easier" |
| 11:05 |
mrpeters |
that makes it pretty freakin easy |
| 11:05 |
berick |
kmlussier: i've been using this one lately, which is my script, but fully automated: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
| 11:05 |
mrpeters |
you can then clone git and start hacking away |
| 11:05 |
kmlussier |
mrpeters: "...for new contributors." |
| 11:05 |
berick |
kmlussier: that's what the QA server uses |
| 11:05 |
RoganH |
I've used berick's scripts and it's pretty straight forward but there are times you need at least a minimal amount of shell scripting experience. |
| 11:06 |
kmlussier |
berick: OK, thanks! That's what I was looking for. :) |
| 11:06 |
mrpeters |
kmlussier: i dont see anything that would stop a "new contributor" from using a packaged install from writing code |
| 11:06 |
mrpeters |
we write custom code for our customers who are built from packaged installs, no issues there |
| 11:06 |
tsbere |
mrpeters: Basically, if you install via packages you *don't* always know how to build and intall your changes. Thus, we shouldn't encourage "install from packages then hack" - Especially as packaged install may actually put perl in different places than a non-packaged. >_> |
| 11:07 |
mrpeters |
ok, well, thats a community decision...just saying, if you want Evergreen up and running in a matter of about 60 seconds (depending on your download speed) thats a pretty darn easy way to do it |
| 11:08 |
krvmga |
tsbere++ |
| 11:08 |
RoganH |
On a slightly different topic, my office is immediately outside the children's programming room and there is a mother there fussing at her child Jason whose name is pronounced JSON. I keep wanting to ask her if she or her husband is a tech geek. |
| 11:08 |
mrpeters |
you're making an assumption that perl is in a different location, i do not beleive it is |
| 11:09 |
tsbere |
mrpeters: I would personally not trust "we installed from packages, then loaded new code on top of that" for a number of reasons. Keeping versions straight being one of them. Package updates possibly overwriting your customizations, without you noticing, being another. If you have to install from git for your changes *anyway* then just install from git! |
| 11:09 |
krvmga |
getit.tt2 was missing hold_pickup_lib=1 and so was defaulting to 0. |
| 11:09 |
kmlussier |
RoganH++ |
| 11:09 |
tsbere |
krvmga: In master I actually set getit.tt2 having hold_pickup_lib=0 |
| 11:10 |
tsbere |
which may have been a typo, not sure |
| 11:10 |
mrpeters |
we're taking about a development machine, are we not? it's disposable. you aren't going to have an issue with an overwrite unless you apt-get and let it upgrade Evergreen, and there happens to be a newer deb on the archive |
| 11:10 |
krvmga |
tsbere: setting it to 1 had the desired effect (grayed out as pickup location to match the OPAC). |
| 11:11 |
mrpeters |
pretty hilarious that you "wouldnt trust installed from packages" when the largest implementation in the world does exactly that, and has no issues in doing so |
| 11:12 |
tsbere |
mrpeters: I am under the impression that the largest implementation installs from packages *made specifically for them, with their customizations* which is entirely different than "install from non-customized packages, then load customizations on top of it" |
| 11:12 |
mrpeters |
you are under the wrong impression |
| 11:13 |
tsbere |
mrpeters: Then I disagree with their method of doing things for the areas they are customizing, and "largest implementation does X" is not a valid reason to do, or trust, X anyway. :P |
| 11:13 |
mrpeters |
our deb_builder script takes a stock tarball ripe from evergreen-ils.org, and builds the evergreen debs from it. you CAN however, supply a "customized" tarball (contianing any files you have changed from core) which gets overlayed on top of stock tarball. |
| 11:15 |
mrpeters |
archive.georgialibraries.org is stock evergreen, 2.7.0 as of today, and isn't "customized" for one implementation |
| 11:15 |
tsbere |
mrpeters: I will also point out that contributors should generally be working off of *master*, not a versioned release, and MVLC also doesn't use versioned releases to begin with. |
| 11:16 |
mrpeters |
you asked for a fast way to install the latest version of evergreen for code contributions, that's exactly what i am offering...use it or don't, i really don't care, but i find it pretty damn convenient to have a new VM up and running in no time |
| 11:16 |
mrpeters |
tsbere: if the community wanted to build a deb for master every day through some automated process a repo could be set up to do so |
| 11:17 |
tsbere |
mrpeters: If the community does anything, "evergreen-prereqs" should be about it for a target, because if you have to be able to run the install steps from the repo *anyway* for development then doing so via a package is a waste of time. :P |
| 11:18 |
mrpeters |
ok, carry on |
| 11:18 |
mrpeters |
just wanted to dispell your incorrect impression |
| 11:18 |
tsbere |
besides, if you screw up the install steps you may not realize you did so if the package has things in the right place and your install has them in the wrong one, then bash your head as to why your changes aren't working. |
| 11:18 |
mrpeters |
the packaged evergreen is a VERY good way for someone to quickly get a test system up and running as long as they understand basic IP addressing and know how to install linux packages |
| 11:20 |
mrpeters |
thats fine, if you dont see it fit for a developer don't use it, no big deal, just sharing the information that this is available to anyone, and the myth that it is "just for PINES" is completely false |
| 11:20 |
tsbere |
mrpeters: My assumption was "PINES has public non-customized and private customized package sets" - I never assumed the ones I could get at were customized for PINES. |
| 11:21 |
gmcharlt |
well, rather depends on what the ultimate purpose is - if you want a running EG instance to test or document, sure, try the packages |
| 11:21 |
gmcharlt |
if you are aiming to do *coding* ... at the moment, I don't see any responsible way around installing from a git clone if the end result is meant to be useful to a *coder* |
| 11:24 |
mrpeters |
that is fair |
| 11:25 |
Dyrcona |
And, what about production? Do you think that would work from a packaged version?\ |
| 11:25 |
Dyrcona |
Right now, Evergreen is very "old school" in how you install it. Not saying I have a problem with that, but that is not noob friendly. |
| 11:26 |
mrpeters |
Absolutely it would |
| 11:26 |
Dyrcona |
Well, I want to add to that I think anyone doing serious customization, not just coding, should probably install from git, too. |
| 11:27 |
Dyrcona |
git is the best way to manage your customizations, IMHO. |
| 11:27 |
mrpeters |
maintain a repo at the site that you're running in production, don't have to use the galibraries repo, the code for the deb builder is all out there |
| 11:27 |
mrpeters |
i agree completely, it is the best way |
| 11:27 |
mrpeters |
but sad fact is, not a large percentage of sites even track their code changes ANYWHERE |
| 11:27 |
Dyrcona |
Yep. That is a sad fact. |
| 11:27 |
mrpeters |
indeed |
| 11:29 |
krvmga |
Dyrcona: i don't know what the problem setting up a git server is. |
| 11:30 |
Dyrcona |
krvmga: Well, you don't even need a server for git, just a local repo on your Evergreen server will do. |
| 11:30 |
mrpeters |
krvmga: you're likely highly technical |
| 11:30 |
Dyrcona |
I think learning git is the problem. |
| 11:31 |
krvmga |
mrpeters: my blushes!! |
| 11:31 |
Dyrcona |
I imagine, but could be wrong, that a number of people feel like, "I had to learn Linux....I had to learn X... I had to learn Y... I had to learn Z... Now, I have to learn git, too?" |
| 11:31 |
mrpeters |
we often deal with libraries who maybe managed to get evergreen installed, and maybe even customize some things, but didn't have the forethought of "hmm, what do i do when we upgrade" |
| 11:31 |
Dyrcona |
heh. that, too. |
| 11:32 |
mrpeters |
we're not even always talking little libraries, either, some pretty big ones kept code changes in word documents or something like that |
| 11:32 |
krvmga |
Dyrcona: i actually didn't find git difficult. |
| 11:32 |
mrpeters |
when i started out, i wasn't using git (community was still using SVN) and we weren't customizing more than logos |
| 11:33 |
Dyrcona |
Git is a major improvement over svn for this sort of thing. |
| 11:33 |
mrpeters |
when the community switched to git, i learned it, and saw how powerful it was to bring forward customizations into new versions |
| 11:33 |
mrpeters |
Dyrcona++ yep, best choice i think this community has ever made. It's been great. |
| 11:34 |
ningalls |
git is the bomb. I still suck at it, but it's the bomb. |
| 11:40 |
gsams |
I've actually been wanting to setup git for our system, but I haven't had much in the way of time to pick it up. gmcharlt's presentation on git at the last conference was a good start but I'm not 100% sure how exactly to apply that to an evergreen instance already in production. |
| 11:40 |
gmcharlt |
gsams: IIRC, tsbere has some writeups and slides floating around |
| 11:40 |
mrpeters |
gsams: take your current version of Evergreen and clone that "tag" to a branch |
| 11:41 |
mrpeters |
and then you'll have to probably work from memory for the most part (though git-diff may help some) to determine what files have changed from "core" of whatever version you are on |
| 11:42 |
gsams |
gmcharlt: I'll have to look into that |
| 11:42 |
csharp |
to enter the packaging conversation for a second, I wanted to clarify the PINES customization process (for the logs and for the curious) |
| 11:42 |
mrpeters |
you can copy them into that newly created branch (likely from your /openils/var/templates/...) for example, to overwrite the original source files in the git repo (do this one "customization" at a time, if possible) |
| 11:42 |
mrpeters |
and when you commit, it will detect the differences, have you resolve any conflicts, etc. |
| 11:42 |
csharp |
1) we build a PINES customization git branch on top of the version we want |
| 11:43 |
mrpeters |
^^^ one just like we're encouraging all sites to do |
| 11:43 |
csharp |
2) we untar the tarballed EG release, created by the EG community, then untar our customized files (created from git diff) on top of that |
| 11:43 |
mrpeters |
this is where git diff rocks :) |
| 11:44 |
csharp |
3) we build a deb from the customized code and install those debs (which are customized on a per-node basis to work with GenaSYS) |
| 11:44 |
gsams |
mrpeters: I think that might have answered my most prominent question I've had. Now hopefully I'll be able to set aside some time to do that. |
| 11:44 |
csharp |
all of our work is public: http://git.evergreen-ils.org/?p=evergreen/pines.git;a=summary |
| 11:44 |
mrpeters |
awesome gsams! |
| 11:45 |
csharp |
obviously there are passwords/sensitive information involved, but most of that is handled outside of the packaging process |
| 11:45 |
gsams |
csharp: thanks for sharing your process! |
| 11:45 |
csharp |
happy to do so |
| 11:45 |
Dyrcona |
We keep private repos with our sensitive stuff/customizations in it. |
| 11:46 |
csharp |
so the end result is "customized for PINES", but the build process is meant to be as generic (i.e., as much like building stock EG from source) as possible |
| 11:46 |
mrpeters |
and then when it comes time to bring those customizations forward you can use the unique commit hash for each commit you have made to your old version, and attempt a git cherry-pick abc123 (supply your commit hash instead of abc123) and it will attempt to merge into whatever "new" version you're trying to bring the changes into |
| 11:46 |
mrpeters |
there are 2 other large implementations running off of GenaSYS, for what it is worth, both very different, infact |
| 11:46 |
csharp |
there are some hard-coded assumptions/choices that we have to make for packaging, but we think they're sane and easily changed |
| 11:47 |
Dyrcona |
For us, we build directly from git, and make an integration branch. |
| 11:47 |
mrpeters |
built right from the same code we use to build up PINES |
| 11:47 |
Dyrcona |
We also have two developers with development and test servers, so we're doing integration on a fairly frequent basis. |
| 11:47 |
csharp |
however, (sorry mrpeters :-) ), I have to agree with others that building from source (either by hand or by script) is the best way to participate in community development |
| 11:47 |
Dyrcona |
Conflicts occur, but are often noticed and resolved quickly, and well before we go into production. |
| 11:48 |
mrpeters |
i agree for CODE development |
| 11:48 |
Dyrcona |
We also load onto the test server several weeks before we go live in production so members can have a go at finding things that might not be quite right. |
| 11:48 |
mrpeters |
but if you just want to quickly test out evergreen, man, its a fast way to do it |
| 11:49 |
csharp |
I completely agree that using our deb repo is the easiest way to get up and running on Ubuntu on the most current stable release |
| 11:50 |
mrpeters |
i just remember the days when we supplied virtual box images for people who just wanted to "test out" evergreen |
| 11:50 |
csharp |
but... it obviously comes with the same limitations as all the other methods people have discussed (preferences, best practices, etc. can vary widely) |
| 11:50 |
mrpeters |
and it was a nightmare, they were always outdated, nobody wanted to manage them, etc. |
| 11:50 |
mrpeters |
had i known about this repo back then, man the pain we could have avoided! |
| 11:51 |
* csharp |
started building one a couple of years back, but lost steam |
| 11:51 |
mrpeters |
4 steps -- find an old PC or server, download ubuntu, run an apt-get command and then go to the download page and grab the staff client |
| 11:52 |
csharp |
yeah, deb-ifying the client was on my wishlist until webby entered the picture ;-) |
| 11:52 |
* csharp |
happily crossed it off the list ;-) |
| 11:58 |
Stompro |
Local added content question - I'm trying to document how to add local content so there is something in the docs. But I'm running into an issue where the ISBN keyed jacket images are not being seen, instead the recordID keyed jacket of "no image" is being shown. |
| 11:58 |
pastebot |
"Stompro" at 64.57.241.14 pasted "Local Added Content issue" (56 lines) at http://paste.evergreen-ils.org/19 |
| 11:58 |
tsbere |
Stompro: Add a recordID jacket instead of an ISBN jacket |
| 12:00 |
Stompro |
tsbere: I would like to have an option where you can add the same image to multiple records by ISBN or other code though. Is it not possible to have ISBN keyed images anymore? |
| 12:01 |
tsbere |
Stompro: The way the locally added ones seem to work (we don't have any, I am running on theory here) is "the filesystem has that file, so we don't hand off to the added content system to get one" - As such the added content system doesn't know they exist, and won't go looking for them. |
| 12:02 |
tsbere |
Stompro: Which does mean "I have an image for this non-recordID identifier" can't be used to fill in multiple records automatically, at least not without looking up records that have that identifier......but also means you can provide images when there are no identifiers available. |
| 12:03 |
|
dreuther_ joined #evergreen |
| 12:06 |
|
ldwhalen joined #evergreen |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:17 |
|
julialima joined #evergreen |
| 12:25 |
Stompro |
tsbere: So the only key that can be used for local conent is the record ID in short. |
| 12:26 |
tsbere |
Stompro: Generally, once "by record ID" was put in place, yes, the local content override became the record ID. |
| 12:26 |
tsbere |
(which I guess means that people who had content *before* that point suddenly had it no longer in place) |
| 12:30 |
* Dyrcona |
wonders if anyone actually uses our MARC templates branch that we've shared. |
| 12:32 |
|
kmlussier left #evergreen |
| 12:37 |
|
nhilton joined #evergreen |
| 12:38 |
Stompro |
tsbere: I guess that using symlinks to share images between multiple records would work also... I'm probably inventing a problem in my own head though. |
| 12:38 |
Stompro |
tsbere, Thanks for the help. |
| 12:43 |
|
dreuther joined #evergreen |
| 12:47 |
jeff |
tsbere: anyone with local content overrides can keep the old overrides by removing the /r/ from the paths in the templates. |
| 12:48 |
jeff |
tsbere: there was the period of time where the isbn key was unpredictable, but that's since fixed (iirc) |
| 12:50 |
tsbere |
jeff: How would just removing the /r/ help? The bib ID is still being put *after* that, you would have to change what value is being dropped in place too, right? |
| 12:52 |
tsbere |
Teaching AC to support multiple providers, and then setting the order to start with some kind of "local storage" that knows how to check for ISBN-based filenames off of a record ID, would probably be the best long-term solution. |
| 12:56 |
|
dreuther_ joined #evergreen |
| 12:58 |
jeff |
tsbere: sorry, yes. |
| 12:59 |
jeff |
tsbere: without the /r/ the following value is treated as an isbn, with it it is a record id. |
| 12:59 |
tsbere |
jeff: I know that. Which is why I commented. The record ID being added after the /r/ would obviously not be the ISBN, right? ;) |
| 12:59 |
jeff |
so it would require moving from /r/{FOO} to /{BAR} |
| 13:00 |
jeff |
tsbere: i think we're saying the same thing now. |
| 13:00 |
jeff |
hence my agreement in my statement above. :-) |
| 13:04 |
|
mjingle joined #evergreen |
| 13:10 |
phasefx |
yboston: remingtron: hey, are you guys fielding the docs@ address? |
| 13:11 |
yboston |
phasefx: I try to but, on occasion I miss stuff |
| 13:11 |
yboston |
phasefx: thanks for covering what I miss |
| 13:11 |
phasefx |
yboston: roger that; I saw a wiki access request come through |
| 13:11 |
yboston |
this time Kathy took care of it as I was about to do it |
| 13:12 |
* phasefx |
is going to send out a suggest to docs@ that folks do Reply-All if they're fielding |
| 13:12 |
yboston |
I try to CC the docs list when I respond to alert the rest that I have replied |
| 13:13 |
phasefx |
yboston: cool deal |
| 13:14 |
phasefx |
and just to be clear, I'm talking about the private email address that gets forwarded to a few people, and not the OPEN-ILS-DOCUMENTATION list |
| 13:15 |
yboston |
yes, I mistyped |
| 13:22 |
|
buzzy joined #evergreen |
| 13:22 |
jeff |
okay, so if anyone looking at this could pretend not to notice the first two records, i'd be interested in opinions on what factors can lead to "large print" SEEMING to often come "first" in search results... example search being: http://catalog.tadl.org/eg/opac/results?query=Roth%20Veronica;qtype=author;locg=22 |
| 13:29 |
|
bmills joined #evergreen |
| 13:31 |
tsbere |
jeff: Why are we pretending to not notice the first records? |
| 13:31 |
|
RoganH joined #evergreen |
| 13:33 |
tsbere |
jeff: Beyond that, relevance includes details like "coverage" - not having dug into the records, perhaps the large print records differ enough to cause that to be a factor? |
| 13:33 |
jeff |
tsbere: the first two have had their MARC "tweaked" in non-MARC ways as a bit of an experiment. it's possible that this makes it a bad example to work from. :-) |
| 13:34 |
jeff |
tsbere: coverage and density being closely related and/or terms for the same thing? |
| 13:34 |
dbs |
related but distinct |
| 13:35 |
jeff |
for a keyword index, i think i know most of the basics in terms of the MARCXML is transformed to MODS, an XSLT rips out some things like originInfo from the MODS, and then PostgreSQL FTS enters the picture |
| 13:35 |
dbs |
jeff: are there any large print records other than the first two in that sample? |
| 13:36 |
jeff |
dbs: third record in my results is a copy of Insurgent with call number LP FIC ROT -- large print. I think in that case there is a 245$h which perhaps has ALSO been tweaked. I should find a more pristine example search. |
| 13:36 |
dbs |
If the indexable content of the records are identical, other than that the large print was published in a subsequent year, then the tie breaker goes to the most recent pub date |
| 13:38 |
|
akilsdonk joined #evergreen |
| 13:38 |
dbs |
so it might just be 2014 vs. 2012 |
| 13:40 |
jeff |
and http://catalog.tadl.org/eg/opac/results?query=top+secret+twenty-one&qtype=keyword&locg=22 is likely another example of that, likely due to the RDA date being missed in the non-large print bib |
| 13:43 |
Dyrcona |
jeff: I don't think our MODS (3.2?) does RDA. |
| 13:44 |
Dyrcona |
Unless I'm missing something in the discussion so far. |
| 13:48 |
dbs |
Might be pulled from the 008 |
| 13:48 |
jeff |
yeah. i was pretty sure our production 2.5 didn't have any such fixes, but now looking for the bugs i was thinking had been fixed in later releases, i don't think we're covered yet. |
| 13:48 |
dbs |
One would have to look at the MRA methinks |
| 13:49 |
Dyrcona |
MODS 3.4 and 3.5 have some RDA support added. Not really looked hard at what it would take to update Evergreen to take advantage of it. |
| 13:50 |
jeff |
there were a handful of 264/RDA/date bugs in launchpad, but they all appeared to address specific issues, not "support dates in 264 across the board" kind of attempts. |
| 13:52 |
Dyrcona |
Yeah, mostly related to pulling data from 264 to display in search results/record view. |
| 13:56 |
jeff |
Hrm. All three of the Top Secret Twenty-One records in my most recent example above have a date1 of 2014. |
| 13:56 |
jeff |
So, I think that means "not the date, look at coverage/etc"? |
| 13:59 |
jeff |
ah. |
| 13:59 |
jeff |
there we go. |
| 13:59 |
dbs |
jeff: Havent' looked at the top secret twenty-one records, but yes, date is just a tie breaker |
| 14:00 |
jeff |
we have a local keyword title field, //mods32:mods/mods32:titleInfo[mods32:title and not (@type)] |
| 14:00 |
jeff |
so while "top secret twenty-one" is similar in coverage/density (not sure which of those terms i'm using wrong right now), one record loses clearly: |
| 14:01 |
jeff |
46753540 | Top secret twenty-one a Stephanie Plum novel |
| 14:01 |
jeff |
46765314 | Top secret twenty-one |
| 14:01 |
jeff |
46765883 | Top secret twenty-one |
| 14:01 |
jeff |
46753540 is the "regular print" edition, appearing third in a keyword search for top secret twenty-one |
| 14:01 |
dbs |
Yeah, so the density is lower |
| 14:02 |
jeff |
okay, good. feeling better about my ability to diagnose this (assuming i've diagnosed correctly here) |
| 14:02 |
|
AliceR joined #evergreen |
| 14:05 |
jeff |
probably better to adjust that xpath down a bit to not include mods/titleInfo/subTitle -- only mods/titleInfo/title... but now i'm not certain why that xpath includes subTitle... |
| 14:06 |
jeff |
aha |
| 14:06 |
tsbere |
jeff: Because some people don't just search on the title itself? Some subtitles are more well known than the titles, I think. |
| 14:07 |
jeff |
tsbere: true, and i'd feel more agreement if this were the actual title index, but it's a local index intended to "bump" keyword searches on titles -- which itself is perhaps now considered bad practice. |
| 14:07 |
tsbere |
ahh |
| 14:07 |
|
atlas__ joined #evergreen |
| 14:07 |
csharp |
"How I Learned to Stop Worrying and Love the Bomb" |
| 14:08 |
atlas__ |
fumbled my way to step 11 here...http://docs.evergreen-ils.org/2.1/html/migrating_records_using_migration_tools.html |
| 14:08 |
jeff |
i'm pretty sure this is an old band-aid for something like "we can't find The Help" |
| 14:08 |
atlas__ |
getting "Can't use an undefined value as a symbol reference at ./parallel_pg_loader.pl line 40." -- any ideas what might have gone wrong along this journey |
| 14:09 |
atlas__ |
totally fumbling my way through this, not sure if there was something I missed that would cause this in the previous steps |
| 14:09 |
Dyrcona |
atlas__: Any reason you are using the 2.1 documentation and not something more recent? |
| 14:09 |
atlas__ |
Dyrcona: great question! couldn't find any documentation of this process that's up to date |
| 14:11 |
jeff |
now, why does //mods32:mods/mods32:titleInfo[mods32:title and not (@type)] apparently result in "Top secret twenty-one a Stephanie Plum novel" (after normalization, I think) given http://catalog.tadl.org/opac/extras/supercat/format/mods32/record/46753540 |
| 14:12 |
jeff |
i have vague memory that "this mods32 is not that mods32" at least at one time, perhaps no longer an issue. |
| 14:13 |
Dyrcona |
jeff: Could be, I recall seeing a comment saying we put something back that some at LC took out. |
| 14:14 |
Dyrcona |
atlas__: I can't really help with that, I always write my own bib loading software. |
| 14:14 |
atlas__ |
line 40 on the parallel_pg_loader script is binmode($main_out,'utf8'); |
| 14:14 |
atlas__ |
maybe missing a utf8 perl library ?? |
| 14:14 |
atlas__ |
though i think it would throw a different error |
| 14:14 |
Dyrcona |
maybe main_out is not defined. |
| 14:15 |
Dyrcona |
It would say something about not finding a library in @INC and it would not compile. |
| 14:15 |
atlas__ |
yeah |
| 14:16 |
atlas__ |
hmmm |
| 14:16 |
atlas__ |
my $main_out = FileHandle->new(">$output.sql") if ($output); |
| 14:17 |
jeff |
Dyrcona: well, that too. In this case I didn't mean "we diverge from LoC", but "I think at least at one time supercat and ingest used XSLT from different places, and they might have diverged from each other, either locally or otherwise (and that might still be the case)." |
| 14:17 |
jeff |
not communicating well today, sorry. :-) |
| 14:18 |
Dyrcona |
jeff: Could be. There is mods in the database, and IIRC, mods in the file system somewhere, too. |
| 14:18 |
Dyrcona |
S'OK. I'm actually in a face to face meeting. |
| 14:19 |
Dyrcona |
atlas__: I usually do my own scripts to load records directly. I've never really used parallel_pg_loader and friends. |
| 14:22 |
dbs |
jeff / Dyrcona: correct, we modify the MODS stylesheets. And our versions are also out of date in terms of the bug fixes released for 3.2.x, 3.3.x, etc |
| 14:24 |
atlas__ |
Dyrcona: I got it...just had a little snaggle in that massive multi-line parallel_pg_loader options list |
| 14:27 |
dbs |
we're 30 revisions behind MODS3.3 XSL, for example |
| 14:31 |
* Dyrcona |
was recently playing with MODS from LoC in some reports. |
| 14:31 |
Dyrcona |
Back to the meeting... |
| 14:56 |
rjackson-isl |
question regarding Patron Search (F4) and the "Limit results to patrons in" pulldown |
| 14:57 |
rjackson-isl |
the pulldown consists of consortium, system and branch - is there a way to save the setting chosen for a given account logged in? |
| 14:57 |
rjackson-isl |
default behaviour appears to show that the setting is saved on local workstation and transistions across accounts logged in at that work station |
| 15:06 |
tsbere |
rjackson-isl: If it appears to be a workstation-level thing normally then I doubt there is any option for a user level default. In part due to how workstation level ones tend to work. |
| 15:07 |
rjackson-isl |
thanks tsbere - was just checking that I wasn't missing something - have ticket from lib and they wnated to save off this setting somehow |
| 15:27 |
yboston |
where can I see a list of languages that EG has been translated to? |
| 15:29 |
yboston |
never mind, I think I dound a place, ./build/i18n/po/ |
| 15:29 |
yboston |
*found |
| 15:39 |
|
nhilton joined #evergreen |
| 15:40 |
|
Shae_ joined #evergreen |
| 15:40 |
atlas__ |
maybe I should have done this http://docs.evergreen-ils.org/dev/_migrating_your_bibliographic_records.html |
| 15:41 |
atlas__ |
it makes a lot more sense than the 2.1 docs using equinox's tools |
| 15:42 |
|
ericar joined #evergreen |
| 15:46 |
|
dreuther joined #evergreen |
| 15:48 |
yboston |
atlas__: I have used that aproach, but it cannot be done in parallel. There are other ways to import that can be done in parallel, but I have never used them |
| 15:50 |
atlas__ |
yboston: so to take advantage of the parallel processing I should probably provision a few more CPUs to this thing |
| 15:51 |
atlas__ |
i just kind of did this on a lark, so it's running with 3.5GBRAM and a single vCPU...ha |
| 15:51 |
yboston |
atlas__: that method, http://docs.evergreen-ils.org/dev/_migrating_your_bibliographic_records.html , as far as I know cannot be doen in parallel |
| 15:52 |
atlas__ |
i'm most of the way through this process right now |
| 15:52 |
yboston |
I have heard of people using a different method that did allow parallel imports |
| 15:52 |
atlas__ |
the extract_holdings script is about half way through 850,000 records |
| 15:52 |
atlas__ |
just stumbled across that in the dev documentation |
| 15:52 |
yboston |
if you don't that have many records, the method in that earlier link should work fine |
| 15:53 |
atlas__ |
theres about 1.2million records, I split off books first and they total about 850,000 |
| 15:53 |
atlas__ |
does that count as many records? |
| 15:53 |
yboston |
that method has been in the docs since like version 2.4 or 2.5 |
| 15:53 |
atlas__ |
okay, I think someone might have pointed me to the 2.1 equinox tool documentation since I was doing over a million records |
| 15:53 |
atlas__ |
or maybe I just got lost ;P |
| 15:54 |
yboston |
yes, that is what I would call a lot |
| 15:54 |
yboston |
though the way your server is set up, it might work fine |
| 15:54 |
atlas__ |
it's a totally naive setup, everything running on a single box with very little hardware provisioned |
| 15:55 |
atlas__ |
but if there's a step that I'm going to hit that could take advantage of a couple more cpus and a bit more ram I might be able to provision it |
| 15:55 |
yboston |
I would not know which step that would be, others might |
| 15:55 |
atlas__ |
all good, I'm this far along anyways learning as I go ;P |
| 15:56 |
yboston |
good luck |
| 16:17 |
|
kmlussier joined #evergreen |
| 16:21 |
bshum |
gmcharlt: Just letting you know that I am likely to have a conflict and will not be able to attend the webteam meeting tomorrow. |
| 16:21 |
gmcharlt |
bshum: sure. thanks for the heads-up! |
| 16:21 |
bshum |
gmcharlt: The only thing I have on my end is some tweaking to fix the wordpress template now that we have the child theme setup. |
| 16:22 |
gmcharlt |
k |
| 16:22 |
bshum |
I haven't had much time to explore my other dream goals for IRC yet. But maybe after I get back from my next travels. |
| 16:27 |
kmlussier |
bshum has dream goals for IRC? |
| 16:28 |
bshum |
kmlussier: It's on my very, very long to-do list to get past IRC logs ported over to the new structure. |
| 16:28 |
bshum |
And also to upgrade/migrate our IRC logging infrastructure. |
| 16:28 |
kmlussier |
Oh, that dream goal! I thought you had something fancy lined up. |
| 16:28 |
bshum |
Right now it's MySQL, there's stuff to run it in PostgreSQL |
| 16:28 |
bshum |
And also lots of changes/fixes for the bots |
| 16:28 |
gmcharlt |
bshum: where are you off to next? |
| 16:29 |
bshum |
gmcharlt: Hello Hong Kong. And a stop in Beijing this time. Never been to that part of China before. |
| 16:29 |
gmcharlt |
cool |
| 16:31 |
|
tspindler left #evergreen |
| 16:31 |
|
atlas__ joined #evergreen |
| 16:47 |
jeff |
hrm. this still gives me MODS that i would not expect to result in the extracted title that I am seeing: select xslt_process((select marc from biblio.record_entry where id = 46753540), (select xslt from config.xml_transform where name = 'mods32')); |
| 16:48 |
jeff |
more digging required, but not right now. |
| 17:35 |
|
tsbere_ joined #evergreen |
| 17:44 |
Bmagic |
Has anyone seen a situation where an item status is available and it still has an open action.circulation? Looking in the auditor table I see this: checked out->reshelving->checked out -> available. Our theory is that the reshelver changed the status from 1->0 because it was* 7 when the query started |
| 17:49 |
berick |
Bmagic: that's probably it |
| 17:50 |
Bmagic |
You think it's possible that the update query from the reshelver could hit on rows that have their status=1 even though the query clearly is looking for 7? |
| 17:51 |
berick |
grr, i opened a LP ticket about this a really long time ago, now i can't find it |
| 17: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:51 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1018011 |
| 17:51 |
pinesol_green |
Launchpad bug 1018011 in Evergreen 2.4 "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 4, heat: 20) [Medium,Confirmed] |
| 17:52 |
berick |
wow, for the first time ever, LP search worked better than google |
| 17:53 |
Bmagic |
hah! |
| 17:53 |
* berick |
does some ticket maintenance on that one |
| 17:54 |
berick |
Bmagic: what version are you running? |
| 17:55 |
Bmagic |
2.6.1 |
| 17:57 |
Bmagic |
berick: Another interesting thing I came across was in the auditor.asset_copy_history table. I found a sequence of events that have the audit_time in reverse compared to the audit_id sequence |
| 17:58 |
Bmagic |
berick: our theory on that one is: postgres started the trigger for the audit row, then another update came along on the same asset.copy row, fired another trigger which completed sooner than the first trigger and the rows landed in the auditor table in reverse order |
| 18:00 |
berick |
seems plausible. Or the second audit row is using the date from when the xact started (before the first insert) instead of when it was actually inserted. |
| 18:00 |
berick |
not sure which PG would do |
| 18:00 |
Bmagic |
now() is probably the moment of insertion |
| 18:01 |
Bmagic |
and not when the trigger started |
| 18:01 |
berick |
good, i would hope so |
| 18:02 |
Bmagic |
berick: the sequence could be getting popped and incremented, then the triggers finish in a different order |
| 18:09 |
|
dreuther_ joined #evergreen |
| 18:11 |
|
dreuther joined #evergreen |
| 21:11 |
|
atlas__ joined #evergreen |
| 21:30 |
|
eby__ joined #evergreen |
| 21:42 |
|
bradl_ joined #evergreen |
| 21:54 |
|
atlas__ joined #evergreen |
| 22:49 |
|
atlas__ joined #evergreen |
| 23:56 |
|
atlas__ joined #evergreen |
