| Time |
Nick |
Message |
| 00:00 |
bshum |
So there's a "keyword_entry" table that stores all the keyword data for every record. |
| 00:00 |
bshum |
And a title_entry table, tec. |
| 00:00 |
bshum |
*etc. |
| 00:00 |
bshum |
And you can add custom definitions for each type of search |
| 00:00 |
bshum |
That's where "reingest" comes into play. Basically there are triggers on bibs where when you update them, it goes and updates corresponding entries in these other metabib tables. |
| 00:01 |
bshum |
So we force it to update the corresponding entries by re-running those on any given biblio record |
| 00:02 |
dcook |
Intriguing! |
| 00:02 |
bshum |
This is many years removed, but my remembering of Koha is that there's a separate index that sort of gets used for search purposes. Zebra or such? |
| 00:03 |
bshum |
Anywho |
| 00:03 |
dcook |
Yeah, Zebra does most of the indexing for Koha. We send over Z39.50 queries for most of our MARC searches. |
| 00:03 |
bshum |
I like to believe that future versions of PostgreSQL with improvements for full text search will lead to more fun times. :D |
| 00:04 |
dcook |
Is that fun times or "fun" times :p |
| 00:04 |
dcook |
? |
| 00:04 |
bshum |
I like to think fun. |
| 00:04 |
dcook |
Cool! |
| 00:04 |
dcook |
I've only used PostgreSQL a bit with DSpace but it looks interesting. |
| 00:04 |
dcook |
The CLI is a bit...different but interesting. |
| 00:04 |
bshum |
I keep hearing about nice speed performance improvements with newer indexes. I don't know if we can use them right away, but I think it'll be fun to poke at down the road. |
| 00:05 |
* bshum |
probably doesn't know what he's talking about entirely :) |
| 00:05 |
dcook |
hehe |
| 00:05 |
dcook |
So do you just store the MARC for a record? |
| 00:06 |
dcook |
With Koha, we store a blob of MARCXML, assorted data extracted from the MARCXML, then we also index the MARCXML using Zebra |
| 00:06 |
dcook |
The idea being that the MARCXML blob is the source of truth, which updates the assorted other fields (for faster retrieval little bits of info here and there) and the Zebra indexes (for more intense searching) |
| 00:07 |
dcook |
Err...what I meant was. |
| 00:08 |
dcook |
You clearly store the indexed data in those entry tables. I assume then there are either blobs somewhere with full records, or lots of rows where a MARC record has been decomposed into rows? |
| 00:09 |
bshum |
Oh sure |
| 00:09 |
bshum |
So biblio.record_entry in our database stores marcxml |
| 00:09 |
bshum |
And that gets split out into the various metabib tables for each type of search. |
| 00:10 |
bshum |
I guess that's similar. |
| 00:10 |
bshum |
But still all in the same database |
| 00:12 |
dcook |
Pretty similar. |
| 00:12 |
dcook |
So biblo.record_entry would just store the whole record in one field? |
| 00:13 |
bshum |
Indeed. |
| 00:13 |
dcook |
Sweet |
| 00:13 |
dcook |
I think I like your way better :p |
| 00:14 |
bshum |
I think there's a metabib.real_full_rec which shards out each field of MARC |
| 00:14 |
bshum |
That's one of the largest tables in our systems. |
| 00:14 |
dcook |
Hehe. I was just thinking it must be fairly massive. |
| 00:15 |
dcook |
biblioitems in Koha is rather enormous though. It stores the full MARCXML (minus items) in a field, then bits and pieces in other fields. |
| 00:15 |
dcook |
Anyway, thanks for the info :) |
| 00:17 |
bshum |
Sure thing :) |
| 00:20 |
bshum |
@later tell dbwells Oh you know... maybe this is weird 9.3 stuff. This is a newer postgres we're using for our test server and maybe it's mucking something up? I really will look more closely tomorrow on why it's creating nonsense. |
| 00:20 |
pinesol_green |
bshum: The operation succeeded. |
| 00:25 |
bshum |
Well it works fine with our concerto database. So, maybe I just have some really strange records causing things to break down. |
| 00:28 |
bshum |
I can't even figure out why it would even try inserting what it did. We don't have any bib IDs that go that high. |
| 00:28 |
bshum |
(yet) |
| 00:30 |
bshum |
Huh.... |
| 00:30 |
bshum |
Though we seem to have four bibs where the 800 $t is a semicolon and indexed as '' |
| 00:30 |
bshum |
That's weird. |
| 00:31 |
bshum |
Well, that there exists a screwed up $t and a good $t that is. |
| 00:31 |
bshum |
There's two |
| 00:31 |
* bshum |
hits head on table |
| 00:49 |
dcook |
:( |
| 01:07 |
bshum |
Grr |
| 01:07 |
bshum |
It's got to be something weird with some other browse index in my system. I removed the one we're testing and it's still failing and doing weird stuff. |
| 01:07 |
bshum |
I wish I could figure out which bib was breaking this |
| 01:15 |
* dcook |
believes in bshum! |
| 01:49 |
bshum |
Whee, added a RAISE NOTICE statement to read off the bib_id for whatever it tries inserting |
| 01:49 |
bshum |
Now I'll find the culprit bib! |
| 01:49 |
bshum |
(maybe) |
| 01:54 |
bshum |
Hmm |
| 02:00 |
bshum |
Aha |
| 02:00 |
bshum |
Well that's weird. |
| 02:00 |
bshum |
Guess it's one of our custom indexes |
| 02:01 |
bshum |
For authors, we added one for tag 720 subfield a |
| 02:01 |
bshum |
And it's marked a browse field and had browse_xpath stuff |
| 02:01 |
bshum |
We have to look more closely at how that's defined I guess |
| 02:01 |
bshum |
Sigh |
| 02:02 |
bshum |
Oh well, fun learning experience, and now I know how to add RAISE NOTICE to my functions to learn where in the function things break down. |
| 02:02 |
bshum |
Yay! |
| 02:04 |
* bshum |
goes to sleep with one minor mystery solved. |
| 06:30 |
|
artunit_ joined #evergreen |
| 07:28 |
|
rjackson-isl joined #evergreen |
| 07:29 |
eeevil |
bshum: if you'll pastebin the index def, list of normalizers applied (and their pos) and offending MARC, I'll try to spot the exact problem with th 720 |
| 07:29 |
eeevil |
should'a later'd that... |
| 07:29 |
eeevil |
@later tell bshum if you'll pastebin the index def, list of normalizers applied (and their pos) and offending MARC, I'll try to spot the exact problem with th 720 |
| 07:29 |
pinesol_green |
eeevil: The operation succeeded. |
| 08:12 |
|
ckolasinski joined #evergreen |
| 08:15 |
|
akilsdonk joined #evergreen |
| 08:17 |
|
artunit joined #evergreen |
| 08:25 |
|
timf joined #evergreen |
| 08:28 |
|
kmlussier joined #evergreen |
| 08:43 |
|
Callender joined #evergreen |
| 08:53 |
kmlussier |
@tea |
| 08:53 |
* pinesol_green |
brews and pours a pot of Tsui Yu Jade Oolong Tea, and sends it sliding down the bar to kmlussier (http://ratetea.com/tea/eco-cha/tsui-yu-jade-oolong-tea/6778/) |
| 08:53 |
kmlussier |
bshum++ |
| 08:54 |
kmlussier |
@tea [someone] |
| 08:54 |
* pinesol_green |
brews and pours a pot of Dong Ding Oolong, and sends it sliding down the bar to Go away, or I'll replace you with a very small shell script! (http://ratetea.com/tea/tradition/dong-ding-oolong/4660/) |
| 08:54 |
bshum |
Well, it's not *that* smart yet :( |
| 08:54 |
kmlussier |
bshum: Is that how it's supposed to work? |
| 08:54 |
bshum |
No. |
| 08:54 |
bshum |
It's generating an error on the [someone] part. |
| 08:54 |
kmlussier |
Oh well. |
| 08:55 |
kmlussier |
@tea afterl |
| 08:55 |
* pinesol_green |
brews and pours a pot of Dong Ding Oolong, and sends it sliding down the bar to afterl (http://ratetea.com/tea/tradition/dong-ding-oolong/4660/) |
| 08:55 |
bshum |
eeevil: Thanks for the offer! I think what's happening is that the 720 is being added via marcxml but using similar browse_xpath as the other author entries which use the mods32 definitions. I'll have to poke at it some more to see what's where and what changed. |
| 08:56 |
bshum |
eeevil: In our production environment, it doesn't complain, but I don't know if it's just been producing nonsense anyways :) |
| 08:56 |
eeevil |
bshum: gotcha... based on that, all I may need is the index def |
| 08:59 |
bshum |
@swill [someone] |
| 08:59 |
* pinesol_green |
grabs a forty of Country Club and sends it sliding down the bar to berick_ |
| 08:59 |
bshum |
kmlussier: There you go :) |
| 09:00 |
kmlussier |
bshum++ |
| 09:00 |
bshum |
@quote [someone] |
| 09:00 |
pinesol_green |
bshum: Fire BAD! Reading GOOD! |
| 09:00 |
bshum |
Heh |
| 09:00 |
bshum |
Okay, so not that. |
| 09:01 |
bshum |
eeevil: http://pastie.org/8975924 -- that's the current definition as it exists in our production system |
| 09:02 |
bshum |
So basically I think it's looking for the 720 subfield a |
| 09:02 |
bshum |
I think maybe we need to rethink how it gets that information though |
| 09:02 |
bshum |
I might poke at it some more when I get to the office. |
| 09:02 |
|
kbutler joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:06 |
|
Callender joined #evergreen |
| 09:10 |
_bott_ |
Can I get an opinion, bug or not bug? |
| 09:10 |
bshum |
@coffee kmlussier |
| 09:10 |
* pinesol_green |
brews and pours a cup of Ethiopia Sidamo Special Prep, and sends it sliding down the bar to kmlussier |
| 09:10 |
bshum |
Success :) |
| 09:11 |
bshum |
Okay, now I can go to work. |
| 09:11 |
_bott_ |
Numeric search by barcode. If you Show more Details, you do not get copy listings. Would others expect to? |
| 09:11 |
_bott_ |
super easy to flesh acp and get them |
| 09:15 |
eeevil |
bshum: you're correct about the incorrect browse_xpath ;) |
| 09:19 |
|
dluch joined #evergreen |
| 09:21 |
|
mrpeters joined #evergreen |
| 09:28 |
dbwells |
_bott_: looks like a bug to me |
| 09:30 |
_bott_ |
I believe the MARC expert search has the same issue. I'll toss a bug out there noting both and roll up a patch. |
| 09:32 |
|
mllewellyn joined #evergreen |
| 09:33 |
|
mdriscoll joined #evergreen |
| 09:34 |
|
denishpatel joined #evergreen |
| 09:36 |
tsbere |
fun with SIPServer: https://bugs.launchpad.net/sipserver/+bug/1298985 <_< |
| 09:36 |
pinesol_green |
Launchpad bug 1298985 in SIPServer "Invalid Summary Type crashes SIPServer" (affected: 1, heat: 6) [Undecided,New] |
| 09:38 |
dbwells |
bhsum: It looks like your author|uncontrolled is going to overlap with author|other. If you are okay with that, I'd suggest either removing the browse_xpath (and falling back to the main xpath), or setting browse_field to false (to simply disable browse for that def). |
| 09:39 |
kmlussier |
@coffee [someone] |
| 09:39 |
|
yboston joined #evergreen |
| 09:39 |
* pinesol_green |
brews and pours a cup of Espresso Nuevo, and sends it sliding down the bar to bradl |
| 09:39 |
kmlussier |
Excellent! Thank you bshum! |
| 09:46 |
Dyrcona |
@swill |
| 09:46 |
* pinesol_green |
grabs a bottle of Smirnoff Ice Pineapple and sends it sliding down the bar to Dyrcona |
| 09:46 |
Dyrcona |
@developer |
| 09:46 |
pinesol_green |
Dyrcona: Communication:14, BigPicture:10, DetailOriented:13, KungFu:16, GetsStuffDone:17, FlakeFactor:17, JavaAvoidance:16 |
| 09:51 |
|
tspindler joined #evergreen |
| 09:58 |
dbwells |
bshum: I just force pushed an update to the 800t branch. It isn't related to the problem you were having, but to prevent duplicates in the search index. |
| 10:01 |
|
RoganH joined #evergreen |
| 10:07 |
|
bibliophylum joined #evergreen |
| 10:09 |
jl- |
is there a list of academic libraries using eg? |
| 10:10 |
jl- |
I know villanova is one of them, I'm sure there are many others |
| 10:11 |
kmlussier |
jl-: It isn't separated out by library type, but you could look at the list here: http://wiki.evergreen-ils.org/doku.php?id=evergreen_libraries |
| 10:12 |
kmlussier |
jl-: Also, I don't think villanova is on Evergreen. |
| 10:12 |
jl- |
kmlussier: last time I talked to damien katz they still were |
| 10:12 |
jl- |
thanks for the link tho |
| 10:14 |
kmlussier |
Off the top of my head, I can think of Conifer (a consortium of academics), Mohawk College, Calvin College. C/W MARS and NOBLE are two multi-type consortia in Massachusetts that include academics. |
| 10:15 |
jl- |
trying to find conifer on the list |
| 10:15 |
kmlussier |
It's in Canada. |
| 10:16 |
jl- |
ah |
| 10:17 |
jl- |
any other, big name US academic libraries? it will help my case |
| 10:19 |
kmlussier |
jl-: I don't know of anyone beyond who is on that list. But I'm still skeptical of Villanova being an Evergreen library. I know they use VuFind for a discovery layer. |
| 10:20 |
jl- |
yes they do |
| 10:20 |
jl- |
as do we for 1/5 |
| 10:20 |
bshum |
jl-: kmlussier: To my recollection from Damien a few years ago, he had rolled up an Evergreen system to toy with the Vufind connectors, but I didn't think they were actively using it. |
| 10:20 |
bshum |
If they are using it, they're quiet about it. |
| 10:21 |
* bshum |
pokes |
| 10:21 |
jl- |
eg is one of the supported drivers for vufind as far as I remember they are using eg as the ils driver but I might be wrong |
| 10:21 |
Dyrcona |
You also can't tell what is running behind their VuFind. |
| 10:22 |
eeevil |
dbwells: where's your branch? |
| 10:22 |
eeevil |
(for 800t) |
| 10:23 |
bshum |
I think they're still using Voyager |
| 10:23 |
bshum |
http://voyager.villanova.edu/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First |
| 10:23 |
bshum |
With VuFind on top of it |
| 10:23 |
bshum |
But yes, there are VuFind drivers. |
| 10:23 |
jl- |
ah |
| 10:23 |
jl- |
I stand corrected |
| 10:24 |
Dyrcona |
That is what Voyager's OPAC looks like? No wonder they created VuFind. |
| 10:25 |
jl- |
indeed |
| 10:29 |
kmlussier |
berick: I think dbwells mentioned this yesterday, but we're having trouble logging into the web client using Firefox. I was using Chrome yesterday with no trouble. |
| 10:29 |
jl- |
here's one of our voyager instances with vufind on top |
| 10:29 |
jl- |
vf-stlib.klnpa.org/vufind/ |
| 10:29 |
jl- |
http://vf-stlib.klnpa.org/vufind/ |
| 10:29 |
jl- |
looks so much better |
| 10:30 |
berick |
kmlussier: yep, known issue. will get back to that soon |
| 10:30 |
jl- |
http://vf-stlib.klnpa.org/vufind/Search/Results?lookfor=test&type=AllFields&submit=Find |
| 10:30 |
kmlussier |
berick: Thanks! |
| 10:31 |
* dbs |
submitted some fixes for the Evergreen driver for VuFind recently, that were accepted. |
| 10:32 |
dbs |
jl-: Conifer is Laurentian University, Algoma University, Northern Ontario Medical School, Collège Boréal, and a bunch of smaller libraries. |
| 10:32 |
jl- |
dbs: yes I saw your commits tu vufind :) |
| 10:32 |
jl- |
I am working on a few things for them right now |
| 10:32 |
dbs |
(the Evergreen VuFind driver is a direct-to-the-database thing which makes it brittle but it worked as of a few months ago) |
| 10:33 |
* dbs |
guilty of not reading _allllll_ the way back |
| 10:50 |
|
kbeswick joined #evergreen |
| 10:58 |
dbwells |
eeevil: the branch is on the bug (#1259665) |
| 10:58 |
dbwells |
eeevil: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1259665_series_browse_reconfig |
| 10:59 |
Bmagic |
Anyone out there familiar with the retrieve_hold_status function? I am trying to deduce the situation that would cause "wrong shelf" |
| 11:01 |
eeevil |
dbwells: thanks! was mostly just curious ... looks good upon a quick eyeballing |
| 11:02 |
dbwells |
eeevil: cool, thanks for giving it a look |
| 11:04 |
tsbere |
Bmagic: "Hold was captured, placed on hold shelf, then someone changed the pickup library" |
| 11:04 |
Bmagic |
ah! |
| 11:05 |
Bmagic |
tsbere: Thanks! |
| 11:11 |
jl- |
any idea why step 11 procudes an empty bibrecords.sql? http://docs.evergreen-ils.org/2.1/html/migrating_records_using_migration_tools.html |
| 11:11 |
|
RoganH joined #evergreen |
| 11:12 |
jl- |
the .bre file is 600mb |
| 11:18 |
dbs |
methinks those instructions are no longer used for current versions of evergreen |
| 11:18 |
dbs |
And 2.1 is no longer supported |
| 11:21 |
* Dyrcona |
thinks there are no good instructions for migrating data into Evergreen. It is a dark art. |
| 11:21 |
dbs |
Dyrcona: there is truth in what you say |
| 11:22 |
dbs |
But some instructions are less misleading than others |
| 11:22 |
gmcharlt |
FWIW, the tools are still in use |
| 11:23 |
gmcharlt |
that is, the ones referenced in the 2.1 manual |
| 11:23 |
* gmcharlt |
would agree with a statement that techniques for migrating data to Evergreen are mostly undocumented |
| 11:24 |
kmlussier |
dbs: Didn't you write up some migration documentation for Evergreen in Action? |
| 11:25 |
yboston |
kmlussier: I have been using dbs instructions for less than 1k records so far with success |
| 11:26 |
jl- |
I've had mild success with the concerto sql loader (50k records) and the staging table (http://docs.evergreen-ils.org/dev/_migrating_your_bibliographic_records.html) however, for the records past that number both scripts went into a crazy loop, never stopping until disk space (>100GB) was full |
| 11:26 |
jl- |
it might be my records fault tho but I did clean them |
| 11:27 |
jl- |
Im not sure what technique to stick with |
| 11:27 |
jboyer-isl |
This is semi-recent, though not personally tested: http://docs.evergreen-ils.org/2.5/_migrating_your_bibliographic_records.html |
| 11:28 |
jboyer-isl |
That section covers more than just records. |
| 11:28 |
jl- |
http://docs.evergreen-ils.org/2.5/_migrating_your_bibliographic_records.html |
| 11:28 |
jl- |
sry |
| 11:28 |
jboyer-isl |
Oh, hey, you apparently were looking at a recent version of that. Oops. :( |
| 11:29 |
jl- |
yes |
| 11:29 |
yboston |
that link from jboyer-isl is the dbs written code that originally appeared in "evergreen in action" that dbs wrote |
| 11:29 |
yboston |
the one I have been using this month for ebook records without items |
| 11:29 |
|
erick joined #evergreen |
| 11:31 |
Dyrcona |
I have done, or assisted with, four migrations, and I usually take each one as a unique case, particularly since I've never gotten records from the same source ILS. |
| 11:33 |
jl- |
dbs: I changed the function to returns VOID instead of NULL because of an error I got |
| 11:33 |
jl- |
sorry gotta go to lunch |
| 11:33 |
jl- |
bbl |
| 11:38 |
yboston |
dbs: I am going to change that NULL to VOID in the stored procedure code, I have been meaning to do that |
| 11:38 |
yboston |
(in the docs) |
| 11:39 |
Dyrcona |
yboston: You're talking about the staging_importer() function? |
| 11:40 |
yboston |
Dyrcona: yes |
| 11:40 |
Dyrcona |
yboston: OK. Changing it to void looks right to me. |
| 11:40 |
yboston |
Dyrcona: I noticed it a while ago, that it was a tiny mistake |
| 11:41 |
yboston |
Dyrcona: meant to ask on IRC to confirm, but realized it was just a tiny mistake |
| 11:41 |
Dyrcona |
In theory, it should be harmless, but jl- mentions an error associated with it. |
| 11:41 |
|
Shae joined #evergreen |
| 11:42 |
yboston |
Dyrcona: I always got an error |
| 11:42 |
yboston |
Dyrcona: until I changed it |
| 11:42 |
* Dyrcona |
tries something. |
| 11:47 |
Dyrcona |
Pg 9.1 won't let me create a function that returns null. |
| 11:49 |
yboston |
Dyrcona: I am about to push the docuemntation chnage, should I not proceed? |
| 11:52 |
Dyrcona |
yboston: Go ahead. |
| 12:00 |
yboston |
Git question concerning pushing changes to main repo |
| 12:01 |
yboston |
I am supposed to have rights to commit changes to /docs |
| 12:01 |
yboston |
I am getting errors when pushing |
| 12:01 |
yboston |
what sytax should I use to push my one word change? git push origin ??? |
| 12:02 |
gmcharlt |
yboston: paste the errors, please |
| 12:02 |
yboston |
git push origin |
| 12:02 |
yboston |
fatal: Could not read from remote repository. |
| 12:02 |
yboston |
Please make sure you have the correct access rights |
| 12:02 |
yboston |
and the repository exists. |
| 12:02 |
yboston |
LB-ysuarez-iMacIntel:Evergre |
| 12:02 |
gmcharlt |
paste your .git/config, then |
| 12:02 |
yboston |
[remote "origin"] |
| 12:02 |
yboston |
url = git://git.evergreen-ils.org/Evergreen.git |
| 12:02 |
yboston |
fetch = +refs/heads/*:refs/remotes/origin/* |
| 12:03 |
gmcharlt |
ok |
| 12:03 |
yboston |
I think I have to chage the URl to not use hhttp protocol? |
| 12:03 |
gmcharlt |
then to be able to push, the url should be git git.evergreen-ils.org:Evergreen |
| 12:03 |
gmcharlt |
you can also add a separate remote that is used just for pushing |
| 12:03 |
gmcharlt |
e.g., |
| 12:03 |
yboston |
OK, this is all making sense |
| 12:03 |
gmcharlt |
git add remote egpush gitgit.evergreen-ils.org:Evergreen |
| 12:04 |
gmcharlt |
then |
| 12:04 |
gmcharlt |
git push egpush master |
| 12:04 |
yboston |
the options make sense, not sure which one I prefer. |
| 12:05 |
gmcharlt |
(which assumes that your master branch is up to date, and that the commits that you are pushing are only affecting files under doc/*) |
| 12:05 |
yboston |
I understand that with the new remote I will need to use something like: git push egpush |
| 12:05 |
yboston |
your assumptions are correct, I made sure of both |
| 12:06 |
yboston |
I suspect it is OK to just change the original config "origin" URL, and that nothing bad will happen form then on when I fetch/pull |
| 12:10 |
yboston |
I used vim to update the config origin URL |
| 12:10 |
yboston |
[remote "origin"] |
| 12:10 |
yboston |
url = gitgit.evergreen-ils.org:Evergreen |
| 12:10 |
yboston |
fetch = +refs/heads/*:refs/remotes/origin/* |
| 12:10 |
yboston |
but I got this error |
| 12:10 |
yboston |
git push origin |
| 12:10 |
yboston |
FATAL: W any Evergreen ysuarez DENIED by fallthru |
| 12:10 |
yboston |
(or you mis-spelled the reponame) |
| 12:10 |
yboston |
fatal: Could not read from remote repository. |
| 12:10 |
yboston |
Please make sure you have the correct access rights |
| 12:10 |
yboston |
and the repository exists. |
| 12:16 |
gmcharlt |
yboston: does a git fetch origin work without error? |
| 12:16 |
yboston |
yes |
| 12:17 |
gmcharlt |
could you pastebin the results of git diff --stat origin/master ? |
| 12:17 |
yboston |
git diff --stat origin/master |
| 12:17 |
yboston |
docs/admin_initial_setup/migrating_your_data.txt | 2 +- |
| 12:17 |
yboston |
1 file changed, 1 insertion(+), 1 deletion(-) |
| 12:18 |
gmcharlt |
ah, I see the problem |
| 12:18 |
gmcharlt |
one moment |
| 12:18 |
yboston |
sub folders in the path under docs? |
| 12:18 |
gmcharlt |
no, error in the gitolite config |
| 12:19 |
gmcharlt |
ok, please try the push again |
| 12:20 |
yboston |
interesting |
| 12:21 |
gmcharlt |
interesting could be good or bad... :) |
| 12:21 |
jcamins |
gmcharlt: wahanui, is that you?!? |
| 12:21 |
Dyrcona |
:) |
| 12:21 |
gmcharlt |
jcamins: hey! I pass the Turing test at least 3/4 of the time! |
| 12:24 |
Dyrcona |
yboston: Have you changed your ssh key lately? |
| 12:25 |
yboston |
I switch to a new machine, but I was under the impression that the old key came over |
| 12:25 |
yboston |
but I was wondering if this was part of the issue |
| 12:25 |
gmcharlt |
what error are you getting now? |
| 12:25 |
yboston |
I think it owrked? |
| 12:26 |
yboston |
*worked |
| 12:26 |
gmcharlt |
ah, so it ahs |
| 12:26 |
kmlussier |
yboston++ |
| 12:26 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: Changed return type of staging_importer() SP - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ab20899> |
| 12:27 |
yboston |
thanks gmcharlt, I was terrified that I had made a mistake, though my remote URL was using the wrong protocol |
| 12:28 |
Dyrcona |
yboston++ |
| 12:28 |
gmcharlt |
yboston: not to worry -- you would have to try very hard to do something that tsbere and I couldn't fix |
| 12:28 |
yboston |
gmcharlt: BTW I have been watching your Git tutorial video, good job |
| 12:29 |
gmcharlt |
how was the recording? |
| 12:29 |
yboston |
though not done watching yet. I also watched a 5 hour lynda.com training videeos that was good too |
| 12:29 |
yboston |
the audio and video are not perfect, but I had a very clear shot of the screen |
| 12:30 |
yboston |
I am watching it without any compression (audio or video), so if I post it to YOutube, etc it might nto be as goos |
| 12:30 |
yboston |
*good |
| 12:30 |
yboston |
I can prepare a sample on youtoube as a test |
| 12:31 |
gmcharlt |
ok |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:46 |
|
mrpeters joined #evergreen |
| 12:55 |
tsbere |
So, does anyone have any thoughts on moving events from the xml file to the database? I have some things I would like to do with event codes at the DB level and would rather not duplicate things too much. |
| 13:02 |
|
bmills joined #evergreen |
| 13:03 |
jl- |
yboston: did you use the python script from the link when you migrated? |
| 13:05 |
kmlussier |
yboston: I know very little about git, so I may be steering you in the wrong direction, but I've never used those tags when I've pushed backports for documentation. In this case, I would push to rel_2_5. |
| 13:07 |
kmlussier |
I answer you here instead of on the mailing list thread because, if I'm wrong, I'm guessing somebody in here will correct me. :) |
| 13:07 |
eeevil |
tsbere: it's entirely untested at this point (may not even compile) but, as promised, I started on a branch to teach cstore et al about arrays (entirely optional): working/user/miker/collapsed-context-org |
| 13:08 |
eeevil |
tsbere: as for events in the db, that's a broad change ... perhaps outline the effected entry points that'll need a rewrite to use the db version, and the cost of loading that data from the db, and when to do so, etc |
| 13:09 |
gmcharlt |
yboston: I've responded at more length in the thread, but the tl;dr version is: what kmlussier said |
| 13:10 |
tsbere |
eeevil: I haven't even figured out some of that myself in regards to events. |
| 13:10 |
kmlussier |
gmcharlt: Thanks! It's good to see I've been doing it correctly. |
| 13:10 |
jl- |
I am ben wiens btw, for those who don't know |
| 13:10 |
tsbere |
eeevil: In regards to your branch there, it doesn't compile, looks like undeclared variable issues. |
| 13:11 |
eeevil |
tsbere: likely. I won't have time to look anymore today, but feel free to whack it about if you're so inclined |
| 13:12 |
|
Christineb joined #evergreen |
| 13:12 |
Dyrcona |
jl-: It was nice to put a face with the alias at the conference. |
| 13:13 |
tsbere |
eeevil: Huh, just noticed some " error: 'for' loop initial declarations are only allowed in C99 mode" in the mix too. I might take a look, but probably not today. |
| 13:13 |
jl- |
Dyrcona: likewise |
| 13:16 |
Dyrcona |
tsbere: -std=c99 fixes that. :) |
| 13:28 |
eeevil |
tsbere / Dyrcona: meh, I should probably just use c89 for loops instead. LATER! :) |
| 13:39 |
yboston |
jl-: no we paid ESI to migrate us back in 2012. I have been using those scripts using pythonn to just move batches of new ebook MARC records |
| 13:42 |
|
kbeswick joined #evergreen |
| 13:51 |
dbwells |
I know bshum was poking it and got derailed, but if anyone can review and commit https://bugs.launchpad.net/evergreen/+bug/1259665 , I'd be very appreciative. It is the only thing holding up the RC at this point. |
| 13:51 |
pinesol_green |
Launchpad bug 1259665 in Evergreen "Series search in 2.5 does not retrieve 800 |t" (affected: 3, heat: 20) [High,Confirmed] |
| 13:52 |
dbwells |
It is my understanding the bshum's issues were not related to the minor changes in this branch, but I can't say that 100%. |
| 13:52 |
bshum |
dbwells: Correct, my issues seem unrelated. I did find a few 800t's to test with and they seemed fine on reingest. But I have to enable the browse stuff fully to check things out. |
| 13:53 |
bshum |
Pretty confident we can just merge though :) |
| 13:53 |
bshum |
I'll try and do that after a few more meetings end. |
| 13:53 |
bshum |
Sorry :\ |
| 13:57 |
Dyrcona |
@marc 800 |
| 13:57 |
pinesol_green |
Dyrcona: An author/title series added entry in which the author portion is a personal name. (Repeatable) [a,b,c,d,e,f,g,h,j,k,l,m,n,o,p,q,r,s,t,u,v,4,6,8] |
| 13:57 |
Dyrcona |
t is the title? |
| 13:58 |
Dyrcona |
yep. |
| 14:16 |
jl- |
if I want to commit, does my pub key need to be added to the eg repo? or just to my github acc? |
| 14:16 |
jl- |
for a pull request |
| 14:19 |
Dyrcona |
jl-: I think someone has talked about making pull requests from github more visible to devs, but the best thing is to have your pub key added to the Evergreen working repo. |
| 14:19 |
Dyrcona |
There's an email list for sending your key to. |
| 14:20 |
Dyrcona |
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git |
| 14:20 |
Dyrcona |
For more information. |
| 14:20 |
jl- |
thx |
| 14:23 |
jl- |
email sent |
| 14:28 |
jl- |
Dyrcona: I already have a github account tho, which has my pub key |
| 14:28 |
Dyrcona |
jl-: So do just about all of the devs. |
| 14:29 |
jl- |
does the commit still go through my github account when I push? |
| 14:29 |
Dyrcona |
Not unless you explicitly push to your github account. |
| 14:31 |
jl- |
with "through" I mean, it will link your username to your profile |
| 14:31 |
|
denishpatel joined #evergreen |
| 14:32 |
Dyrcona |
Oh. If your email address and/or username are the same, your commits will show up in your github profile if that's what you mean. |
| 14:32 |
jl- |
yeah that's what I thought, just wasn't sure |
| 14:33 |
Dyrcona |
If you look at my profile, https://github.com/Dyrcona , you'll see Evergreen shows up as a repo to which I have contributed, though I've not cloned it on github. |
| 14:34 |
jl- |
yup |
| 14:35 |
jl- |
I'll have to wait until someone adds my key |
| 14:39 |
Dyrcona |
jl-: What is it you want to commit? You did read on the dev:git page about the signoffs and how things end up in the main repository, yes? |
| 14:42 |
jl- |
Dyrcona: yes, it's adding some documentation in /docs/admin for the staff client that I recently found helpful |
| 14:43 |
Dyrcona |
OK. You might want to coordinate that with yboston and DIG. |
| 14:43 |
jl- |
yeah I'm sure it will get reviewed |
| 14:43 |
jl- |
before approval |
| 14:46 |
Dyrcona |
Documentation commits usually are easier to get in. |
| 14:46 |
Dyrcona |
You might want to make sure about the license of any documentation that you found online, first. |
| 14:55 |
|
kmlussier joined #evergreen |
| 15:10 |
|
akilsdonk joined #evergreen |
| 15:37 |
|
gerson joined #evergreen |
| 15:43 |
kmlussier |
@swill |
| 15:43 |
* pinesol_green |
grabs a forty of Private Stock and sends it sliding down the bar to kmlussier |
| 15:45 |
kmlussier |
@bartender |
| 15:45 |
* pinesol_green |
fills a pint glass with Samuel Adams Summer Ale, and sends it sliding down the bar to kmlussier (http://beeradvocate.com/beer/profile/35/103/) |
| 15:45 |
kmlussier |
Oh, pinesol_green, you know me so well. |
| 15:48 |
kmlussier |
@coin |
| 15:48 |
pinesol_green |
kmlussier: tails |
| 15:49 |
|
gerson left #evergreen |
| 15:49 |
|
gerson joined #evergreen |
| 15:49 |
|
gerson left #evergreen |
| 15:58 |
|
denishpatel joined #evergreen |
| 16:03 |
afterl |
kmlusssier: are you drinking again? [grin] |
| 16:05 |
kmlussier |
afterl: I'm just getting ready for 5 o'clock! :) |
| 16:05 |
kmlussier |
@bartender afterl |
| 16:05 |
* pinesol_green |
fills a pint glass with Edison Light Beer, and sends it sliding down the bar to afterl (http://beeradvocate.com/beer/profile/629/1689/) |
| 16:05 |
kmlussier |
afterl: There's one for you. |
| 16:07 |
phasefx |
@developer |
| 16:07 |
pinesol_green |
phasefx: Communication:8, BigPicture:13, DetailOriented:12, KungFu:8, GetsStuffDone:15, FlakeFactor:10, JavaAvoidance:9 |
| 16:08 |
gmcharlt |
@librarian |
| 16:08 |
pinesol_green |
gmcharlt: Management:8, Cataloging:7, Acquisitions:15, Reference:11, Circulation:15, Systems:10, Research:15, Custodial:15 |
| 16:09 |
afterl |
Sweet. I was just thinking I could use a light beer with a punny name. From Massachusetts. |
| 16:10 |
kmlussier |
afterl: But the rating is a little low. |
| 16:12 |
afterl |
kmlussier: have you had it? Just curious. |
| 16:12 |
jl- |
I have some Spaten in my fridge for later |
| 16:12 |
kmlussier |
afterl: Not that I know of. |
| 16:13 |
jl- |
yboston: how big are your batches usually, using the staging importer? |
| 16:14 |
afterl |
kmlussier: now you've got me thinking beer when all that I have is wine. [sigh] Thinking of leaving work early for a beer run .... |
| 16:14 |
kmlussier |
@wine afterl |
| 16:14 |
pinesol_green |
kmlussier: Go away, or I'll replace you with a very small shell script! |
| 16:14 |
kmlussier |
I guess we don't have wine here. |
| 16:15 |
gmcharlt |
rather definitively, we don't have wine |
| 16:15 |
afterl |
gmcharlt: I can so picture you saying that. |
| 16:15 |
gmcharlt |
heh |
| 16:18 |
|
denishpatel joined #evergreen |
| 16:26 |
Dyrcona |
Hey, bartender! Hey, man! Lookee here! Draw one, draw two, draw three, four glasses of beer! |
| 16:26 |
* Dyrcona |
channels Floyd Dixon. |
| 16:28 |
yboston |
jl-: My biggest batch with that script was like 2200 records without holdings from EBSCO ebooks service via OCLC. It ran fine on my test server, but I had a timeout error when loading them to my production server hosted by ESI |
| 16:28 |
yboston |
jl-: which is a few states away from here, so there shoudl have been latency issues |
| 16:29 |
yboston |
jl-: BTW< did we meet at the conference? |
| 16:34 |
|
afterl left #evergreen |
| 16:38 |
|
afterl joined #evergreen |
| 16:45 |
|
afterl left #evergreen |
| 16:51 |
|
kmlussier joined #evergreen |
| 16:52 |
bshum |
Calling 0877 |
| 16:55 |
bshum |
Ack, rebase on other pushed commits. |
| 16:55 |
* bshum |
does the dance |
| 16:55 |
bshum |
And we're good |
| 16:56 |
yboston |
mceraso++ for testing OSRF |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:56 |
kmlussier |
mceraso++ |
| 16:57 |
bshum |
mceraso++ |
| 16:58 |
pinesol_green |
[evergreen|Dan Wells] LP#1259665 Split series browse config from search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca359de> |
| 16:58 |
pinesol_green |
[evergreen|Ben Shum] LP#1259665 Stamping upgrade for 800t search and facets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f92e1ff> |
| 16:59 |
jl- |
yboston: yes we met, I'm ben wiens |
| 16:59 |
jl- |
I think alex zalar introduced us |
| 16:59 |
yboston |
yes, from Pennsylvania? |
| 16:59 |
jl- |
yup |
| 16:59 |
bshum |
Another Ben, eh? |
| 16:59 |
bshum |
:) |
| 17:00 |
jl- |
indeed |
| 17:00 |
jl- |
hehe |
| 17:01 |
jl- |
anyone in here that can add my ssh key to the git repo? |
| 17:01 |
bshum |
There's a few folks. You sent something to the git-admin email right? |
| 17:01 |
* bshum |
is not one of them |
| 17:01 |
yboston |
jl-: it start with sending an email to that email address |
| 17:02 |
jl- |
gitadminevergreen-ils.org |
| 17:02 |
jl- |
yup |
| 17:02 |
jl- |
ok |
| 17:02 |
bshum |
I'm sure they'll respond soon. |
| 17:02 |
jl- |
great |
| 17:02 |
bshum |
That said, today is Friday, hmm |
| 17:02 |
bshum |
:P |
| 17:03 |
jl- |
true ^^ |
| 17:03 |
gmcharlt |
I have a feeling that if you write within the next half hour |
| 17:03 |
gmcharlt |
that gitadmin might just respond |
| 17:03 |
gmcharlt |
a pretty strong feeling, in fact ;) |
| 17:03 |
jl- |
I sent it at 2:24 |
| 17:03 |
jl- |
:P |
| 17:04 |
bshum |
We'll just blame it on the time zone. gmcharlt won't see it for another 20 minutes then. |
| 17:04 |
bshum |
(was kidding) |
| 17:04 |
gmcharlt |
ah |
| 17:04 |
gmcharlt |
actually ... I don't see it |
| 17:04 |
gmcharlt |
could you resend? |
| 17:05 |
jl- |
gmcharlt: sure |
| 17:06 |
gmcharlt |
jl-: there we go |
| 17:06 |
gmcharlt |
preferred username? |
| 17:07 |
jl- |
won't it use my github account? https://github.com/bwiens/ user: Benjamin Wiens email: benjamin.wiensgmail.com |
| 17:07 |
jl- |
I sent it also from ship.edu but the gmail should be better |
| 17:08 |
gmcharlt |
there's no inherent connectinon between github and the name that our setup uses for branches |
| 17:08 |
gmcharlt |
but I gather bwiens is OK? |
| 17:08 |
jl- |
sure |
| 17:10 |
jl- |
gmcharlt: will the commit be linked to my github profile? |
| 17:10 |
jl- |
if it gets approved |
| 17:12 |
gmcharlt |
I believe github will try to match up commits via email address |
| 17:12 |
jl- |
great |
| 17:34 |
eeevil |
tsbere: fwiw, the branch now compiles ... still untested. also cleaned up two remaining fixable warnings (one remains, but it is known, harmless, and unfixable without deeper surgery) |
| 18:07 |
|
tspindler left #evergreen |
| 18:22 |
jl- |
gmcharlt: I'm getting the same error yboston had earlier |
| 18:22 |
jl- |
FATAL: W any Evergreen bwiens DENIED by fallthru |
| 18:22 |
jl- |
(or you mis-spelled the reponame) |
| 18:22 |
jl- |
fatal: The remote end hung up unexpectedly |
| 18:22 |
jl- |
rootdebian:/home/ben/Desktop/egreen/Evergreen/docs/admin# git diff --stat origin/master |
| 18:22 |
jl- |
docs/admin/staff_client-password-reset.txt | 16 ++++++++++++++++ |
| 18:22 |
jl- |
1 file changed, 16 insertions(+) |
| 18:51 |
|
bmills left #evergreen |
| 20:01 |
dbs |
jl-: the pubkey that you sent matches what we have in the keydir for "bwiens". are you trying to push to the working/Evergreen.git repository and to a /user/bwiens/branch-name branch? |
| 21:37 |
|
kmlussier joined #evergreen |
