| 01:27 |
|
zerick joined #evergreen |
| 04:41 |
|
dbs joined #evergreen |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:58 |
|
timlaptop joined #evergreen |
| 07:51 |
|
collum joined #evergreen |
| 08:04 |
|
rjackson-isl joined #evergreen |
| 09:17 |
jl- |
fgin=fine |
| 09:18 |
RoganH |
jl-: Is it fine for each cataloger to edit each bib record? |
| 09:18 |
dbwells |
jl-: Yes, search scoping can happen via the call number /copy ownership. |
| 09:18 |
jl- |
RoganH: at this point it's test run and there won't be any catalogers (library staff?) |
| 09:18 |
jl- |
it's more of a proof-of-concept |
| 09:19 |
RoganH |
jl-: Ah. Well, when you get to that stage that will be a big deal. If they feel territorial and each university has to "own" their bib that will be a big issue. |
| 09:19 |
Dyrcona |
Yeah, jl-, the more you learn now, the better off you will be later. |
| 09:19 |
jl- |
well they certainly own the individual books? |
| 10:54 |
yboston |
Any US citizens that want to give me tips of how to submit the RDA records I am acquiring to be added tot he communtiy dataset? |
| 10:54 |
dbs |
And then download the MARC (Unicode) records one by one. You could put them all together and submit them as a branch, after which they would get munged into the sample loader format |
| 10:55 |
yboston |
(nevermind) |
| 10:55 |
dbs |
(e.g. drop them into a Open-ILS/tests/datasets/RDA/ subdirectory and then they could get reformulated) |
| 10:55 |
yboston |
(thanks for the path, was just about to ask) |
| 10:58 |
yboston |
I assume it OK if I start with a branch with just a few RDA files , then create more branches later |
| 10:58 |
yboston |
s/it/it is/ |
| 11:05 |
mrpeters |
one of our customers wants to become a target for the community so i'm just relearning the process. It was kind of a set it and forget it thing when I did it the other time. |
| 11:08 |
|
ldwhalen joined #evergreen |
| 11:09 |
jeff |
Dyrcona: sounds like a bug (re: gists). have an example? |
| 11:10 |
* dbs |
doesn't know if there's a way to search catalog.loc.gov for 264 ind2 != 1 though, which is what we need to test Dyrcona's branch |
| 11:14 |
Dyrcona |
jeff: I would have said open any gist, click on the link for raw, right-click in the window, choose save as, and then open the file in a text editor to see the HTML. |
| 11:15 |
Dyrcona |
I've seen that twice. |
| 11:15 |
Dyrcona |
However, when I tried to repeat that just now, it didn't happen. I got plain text. |
| 11:31 |
RoganH |
asimon: it doesn't really affect availability per se, we are configured so that it can still be targeted for holds and checked out |
| 11:32 |
asimon |
*: TY to all. I have to run. |
| 11:34 |
|
denishpatel joined #evergreen |
| 11:35 |
dbwells |
So, I've already cut 2.6.0 and am testing now, but can anyone take a look at the newly posted bug #1308590? |
| 11:35 |
pinesol_green |
dbwells: Error: Could not gather data from Launchpad for bug #1308590 (https://launchpad.net/bugs/1308590). The error has been logged |
| 11:38 |
gmcharlt |
hmm; LP isn't responding ATM |
| 11:39 |
dbwells |
eyeball test says it won't cause any harm, but better to be sure. Branch is here, since LP isn't responding: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1308590_fix_schemaorg_type |
| 11:39 |
gmcharlt |
https://bugs.launchpad.net/evergreen/+bug/1308590 |
| 11:39 |
pinesol_green |
Launchpad bug 1308590 in Evergreen "CCVM/icons broke schema.org type matches" (affected: 1, heat: 6) [Undecided,New] |
| 11:41 |
|
mmorgan left #evergreen |
| 11:41 |
|
mmorgan joined #evergreen |
| 11:41 |
gmcharlt |
dbwells: I can test and push to master in the next 15 minutes or so |
| 11:41 |
gmcharlt |
up to you whether to recut 2.6.0, but I certainly have no objection if your doing that |
| 11:41 |
gmcharlt |
*to your doing that |
| 11:42 |
dbwells |
gmcharlt: excellent, thanks |
| 11:43 |
|
RoganH left #evergreen |
| 11:44 |
|
jventuro joined #evergreen |
| 16:45 |
shart290 |
already |
| 16:46 |
Dyrcona |
shart290: Yep. So, what happens if you do cd to go back to your home directory and then run osrf_control without the ./? |
| 16:48 |
shart290 |
it worked when I entered a login session for opensrf but not when I use sudo -u opensrf |
| 16:49 |
dbs |
mrpeters: are the staff hitting the big red "X" button to delete the address? |
| 16:49 |
dbs |
'cause that's what ours do. |
| 16:50 |
* dbs |
just fired up the staff client for the first time in *months* and added a user on the test server |
| 16:51 |
Dyrcona |
shart290: osrf_control starts daemon processes and that may not work with sudo. |
| 16:51 |
shart290 |
is there another way to execute as one user from another? |
| 16:51 |
* dbs |
does "sudo su - opensrf" and then runs the commands. |
| 16:54 |
* csharp |
usually does 'sudo -i' then 'su opensrf' so I can move between opensrf and root, but tomayto/tomahto |
| 16:55 |
shart290 |
ok, lemme try this. I am so close and my head is about to implode |
| 16:55 |
* dbs |
confirms "sudo -i -u opensrf osrf_control -l --stop-all" works whereas "sudo -u opensrf osrf_control -l --stop-all" does not |
| 16:56 |
shart290 |
bingo |
| 16:56 |
shart290 |
thanks you all |
| 16:57 |
shart290 |
dbs++ Dyrcona++, mrpeters++ csharp++ |
| 16:57 |
shart290 |
now to get the client to test. I will be setting up another computer to handle the staff client. |
| 16:57 |
shart290 |
just need to get an interface. |
| 16:58 |
Dyrcona |
I always login to the server as the opensrf user, then sudo if I need root. |
| 16:58 |
Dyrcona |
Anyway, time for me to go. |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:23 |
hbrennan |
Haha |
| 17:28 |
gmcharlt |
Evergreen: keeping circ desk staff alert since 2007 |
| 17:28 |
gmcharlt |
s/2007/2006/ |
| 17:29 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
shart290 |
gonna reboot. |
| 17:42 |
|
shart290 joined #evergreen |
| 17:47 |
pastebot |
"shart290" at 64.57.241.14 pasted "Issues running evergreen after install" (58 lines) at http://paste.evergreen-ils.org/60 |
| 01:28 |
|
eby__ joined #evergreen |
| 04:17 |
|
tfaile joined #evergreen |
| 05:12 |
|
phasefx joined #evergreen |
| 05:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:00 |
|
timf joined #evergreen |
| 07:03 |
|
Callender joined #evergreen |
| 07:04 |
|
tfaile joined #evergreen |
| 09:35 |
jl- |
jcamins: what are the implications of that? I've been using equinox migration tools and they have served me well so far |
| 09:36 |
jl- |
mrpeters: http://paste.debian.net/hidden/46f59b30/ |
| 09:36 |
jcamins |
jl-: potentially you'll run into a situation where existing tools don't seem to be giving you the expected result. That's all. |
| 09:37 |
jl- |
jcamins: yes, thankfully this is a test run |
| 09:37 |
jl- |
I've already had to do some costumizing |
| 09:38 |
jl- |
*custom |
| 09:38 |
jl- |
and thanks for the koha link jcamins, that is the next ILS we are wanting to test |
| 09:39 |
jcamins |
There are other versions of the migration toolkit, so you might want to look around to see if anyone has anything better. |
| 09:39 |
dbs |
jl-: mfhd for serials may end up going into serial.record_entry if your library doesn't circulate your serials |
| 09:39 |
Dyrcona |
jl-: Looking at the code that jcamins pointed out, it appears to expect some item information in the bibliographic (MARC) records. That gets matched up with other information from items.txt later. |
| 13:23 |
Dyrcona |
csharp: Did you do it as a consortial admin or did library staff do it? |
| 13:23 |
csharp |
library staff |
| 13:23 |
Dyrcona |
I agree that it sounds like a bug. |
| 13:23 |
csharp |
we tested it on our test system as a local admin |
| 13:23 |
RoganH |
did the local admin have all working locations assigned? |
| 13:24 |
csharp |
RoganH: I don't know who did it |
| 13:24 |
RoganH |
I want to say the issue for us came up when internal help desk staff who had all working locations did it. |
| 13:24 |
csharp |
it appeared on everyone's closed dates, though, and it's 2 weeks away (our normal checkout duration) |
| 13:25 |
kmlussier |
Looking at the Closed Dates Editor, my expectation would be that it would apply to all the children of the OU that's selected at the top of the screen. |
| 13:25 |
csharp |
could someone please test after me? |
| 13:25 |
kmlussier |
Even if the person using the editor had permission at more working locations. |
| 13:25 |
csharp |
it may be something local |
| 13:25 |
RoganH |
I'll test right now. |
| 13:25 |
csharp |
RoganH: much appreciated |
| 13:34 |
RoganH |
csharp: just tested with my 2 account. Account A has all working locations. Account B only has the locations in one system. In both cases the closed date applied to all locations where that account has working locations regardless of where in the org tree they applied the date. |
| 13:34 |
RoganH |
If the "apply to all my libraries" is checked. |
| 13:35 |
RoganH |
If that is not checked it is only applied to the individual library. |
| 13:36 |
jeff |
gmcharlt: thanks! (re: libki) |
| 13:36 |
RoganH |
In neither case does it go down the org unit tree and apply to child org units. |
| 13:37 |
csharp |
RoganH: thanks |
| 13:39 |
dkyle |
Jeff: we are testing libki. bott has done a few mods for EG integration |
| 13:40 |
RoganH |
csharp: one of the reasons I never reported it as a bug is I'm OK with it functioning like that. It means it's not practical for me to set the closed dates for each library system and they have to do it. |
| 13:50 |
|
jwoodard joined #evergreen |
| 14:16 |
|
mcooper joined #evergreen |
| 14:18 |
|
RoganH joined #evergreen |
| 14:23 |
|
geoffsams joined #evergreen |
| 14:34 |
|
mrpeters joined #evergreen |
| 14:36 |
dbs |
Dyrcona: finally running your branch with test RDA bibs. Very interesting. |
| 14:36 |
|
kmlussier1 joined #evergreen |
| 14:37 |
dbs |
Dyrcona: in the case of record matching (OCoLC)825763702, there's "264 4 ‡c℗2013" that doesn't appear to be displayed anywhere |
| 14:38 |
* Dyrcona |
is in a meeting. I'll look later. |
| 14:39 |
dbs |
Also looks like, with more descriptive 7xx fields, we're going to have to revise the added author stuff further (probably picking up from a discussion that bshum and I were having a while back) |
| 14:39 |
dbs |
cool |
| 14:58 |
|
kayals_ joined #evergreen |
| 15:05 |
dbs |
@later tell Dyrcona dang, the batch of RDA bibs you supplied only has 18 records with "264 ind2=<anything other than 1>" and all of those simply have 264 ind2=4 $c<date>" which doesn't get displayed; that is, |
| 15:05 |
pinesol_green |
dbs: The operation succeeded. |
| 15:06 |
dbs |
@later tell Dyrcona that is, the test bibs don't really help with testing that part of the patch. Really useful for the added author / schema.org type matching though! |
| 15:06 |
pinesol_green |
dbs: The operation succeeded. |
| 15:06 |
Dyrcona |
dbs: Hmm. sorry. I grabbed records that had all the RDA fields that came up in the IRC discussion. |
| 15:09 |
dbs |
Dyrcona: no worries! if you want to hand-pick a few that have more interesting 264 fields for your patch's purpose, it would be easy to roll those in |
| 15:10 |
Dyrcona |
dbs: If I can find the ones that I tested with, sure. |
| 15:10 |
Dyrcona |
Movies seem to be good choices. |
| 15:10 |
dbs |
Dyrcona++ |
| 15:23 |
yboston |
dbs & Dyrcona : the two Berklee catalogers will start picking RDA records to be added to the EG data set |
| 15:33 |
kayals_ |
yes |
| 15:34 |
kayals_ |
Electronic resources does NOT show in the search result page but does show up in record summary |
| 15:34 |
kmlussier |
kayals_: Does it show up in the search results after you click the "Show more details" button at the top of the page? |
| 15:34 |
kayals_ |
i know other libraries have their search result page show Electronic Resource listed with links |
| 15:35 |
kayals_ |
we do not use show/hide more details as we removed that tabs |
| 15:35 |
kayals_ |
i can add it and test it |
| 15:53 |
kayals_ |
kmlussier - I added back show/hide more details in the results.tt2 file still no luck |
| 15:53 |
kayals_ |
it does not show electronic resource |
| 15:56 |
|
kmlussier1 joined #evergreen |
| 16:07 |
bshum |
kayals_: URI entries for 856 only appear when making use of the $9 trick |
| 16:07 |
rjackson-isl |
right and don't you need to be logged in to the branch showin gin the $9 as well? |
| 16:35 |
gmcharlt |
yboston: sorry for the delay; it shoudl work now |
| 16:40 |
yboston |
gmcharlt: thanks, it works |
| 17:07 |
|
RoganH left #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 18:43 |
bshum |
Hmm |
| 18:43 |
bshum |
So in Open-ILS/xul/staff_client/server/circ/checkout.js |
| 00:33 |
bshum |
@later tell kmlussier The LJ article about open source systems is up online now: http://www.thedigitalshift.com/2014/04/ils/open-source-options-library-systems-landscape/ |
| 00:33 |
pinesol_green |
bshum: The operation succeeded. |
| 01:12 |
|
b_bonner joined #evergreen |
| 01:13 |
|
mtcarlson_away joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:45 |
|
pastebot0 joined #evergreen |
| 05:47 |
|
jventuro joined #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 11:32 |
|
asimon joined #evergreen |
| 11:33 |
Dyrcona |
kmlussier: Could be the version. I think bibliomation and MVLC are on a newer "release." We're on the equivalent of 2.5+. |
| 11:34 |
kmlussier |
Dyrcona: This is 2.5.3 |
| 11:38 |
asimon |
I'm attempting to overlay the action_trigger schema using pg_restore, but I keep getting hung up on restoring the *pkey table constraints, even after using the --clean and --data-only options. Attempting to drop one of the constraints as a test suggest that I use CASCADE, but that affects indices. Is there an easier way to do this? |
| 11:43 |
bshum |
Yeah, we're like halfway to 2.6 |
| 11:43 |
bshum |
Well, more like 75% of the way |
| 11:44 |
csharp |
asimon: so by "overlay" do you mean "remove the data that's there and insert new data"? |
| 16:15 |
bshum |
To get things to pop up |
| 16:15 |
bshum |
I remember this bug now |
| 16:17 |
bshum |
gmcharlt++ # thanks |
| 16:18 |
eeevil |
kmlussier: so phasefx ran the auth-auth linker on cwmars' test system, but that will only cause a reingest on the /unauthorized/ side of an auth-auth link (that's the record that changes with the addition of a $0). the remainder of the auth records would not have been reingested, thus the lowercased main entries. After the current auth-bib linking work, the plan is to do a non-propagating auth reingest, which will clear up those remainders |
| 16:18 |
bshum |
Good ol' https://bugs.launchpad.net/evergreen/+bug/1091885 |
| 16:18 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] |
| 16:19 |
kmlussier |
eeevil: OK, I though they said a full authority reingest had been done, but they have misunderstood. |
| 16:36 |
kmlussier |
eeevil: I don't know if this makes a difference, but the lowercase display was not for the main entries. It was only for the unauthorized headings. If the auth-auth script reingested the unauthorized heading, shouldn't those be displaying in proper case? |
| 16:36 |
kmlussier |
Sorry if I'm missing something obvious. |
| 16:42 |
|
finnx joined #evergreen |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
dbwells |
eeevil: yboston: I've been in meetings all afternoon, sorry. The upgrading section of the docs is pretty generic. The salient instructions about reingesting are dumped to screen at the end of the big 2.5.0 upgrade script. |
| 17:02 |
yboston |
dbwells: good to know |
| 17:03 |
dbwells |
I do think it makes sense to get that info into the docs as well. |
| 00:17 |
Guest40233 |
I'm curious...what does Evergreen need to know about RDA? |
| 00:17 |
Guest40233 |
^bshum dbs |
| 00:21 |
bshum |
dcook: Well, the thing we're working on is some new work to show more RDA 264 tag elements in the catalog. Thing is, we don't have any sample bib records in our test dataset that ships with Evergreen that include 264 (or other RDA tags) |
| 00:22 |
bshum |
dcook: dbs' idea is to get some sample bibs that do contain these new tags into our test dataset so that future testing / work with RDA can be checked using those test bibs. |
| 00:22 |
dcook |
Mmm. Fair enough. I can certainly get behind that idea. |
| 00:22 |
dcook |
It would be nice to have a quintessial RDA record set |
| 00:22 |
dcook |
Man, that wasn't even spelled anywhere near correctly |
| 01:02 |
dcook |
It makes showing multiple 264s a breeze. At the moment, I don't think we differentiate between the different types of 264, but it would be a trivial change to make. |
| 01:02 |
dcook |
In any case, sleep well! |
| 01:57 |
|
zerick joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:38 |
|
akilsdonk joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:07 |
Dyrcona |
So, I get daily promotional emails from Packt Publishing because I've bought some ebooks directly from them in the past. |
| 08:44 |
* bshum |
wonders how this became popular again |
| 08:48 |
Dyrcona |
bshum: If its there, someone will use it. |
| 08:48 |
bshum |
I suppose that's true. |
| 08:48 |
dbs |
bshum: to follow up on your convo with dcook, no, koha doesn't have a sample set of RDA records; I always load sample records from Evergreen's test datasets into Koha :) |
| 08:49 |
bshum |
Dyrcona: Maybe we need something in Questions on LP like what jcamins did for our issues tracker in github: https://github.com/evergreen-library-system/Evergreen/issues/9 |
| 08:49 |
bshum |
But to subtly point people at the lists |
| 08:49 |
dbs |
The "trawl LoC for sample RDA records" approach could work, although it's not as though LoC hasn't made errors before. |
| 08:50 |
Dyrcona |
dbs: I can throw some records with some of the 264 data at you. |
| 08:50 |
Dyrcona |
OCLC be damned. :p |
| 08:51 |
dbs |
Some is better than none. |
| 08:51 |
Dyrcona |
I'll see if I can dig up the IDs of the two or three that I used for testing. |
| 08:52 |
* dbs |
also hopes, like bshum, that the 3xx were taken into account with all the MVF/CRA stuff |
| 08:53 |
* dbs |
peers with interest at http://www.loc.gov/standards/mods/mods-conversions.html - nope, still no MARCtoMODS3.5 XSLT |
| 08:54 |
dbs |
Although there is an RDAtoMODS3.4 XSL (as in, Excel spreadsheet; and it's horrible) |
| 11:54 |
csharp |
mmorgan: that assumes that you chop your logs up by date/hour like we do |
| 11:56 |
mmorgan |
csharp: Thanks, that's helpful. Yes we do chop them up by hour. |
| 11:57 |
csharp |
mmorgan: you can also search the threadtrace in the activity.log (assuming that's there too) |
| 11:59 |
Dyrcona |
mmorgan: Circulation code is a mess, I see things going through it 3 and four times, even when testing and I know I only checked it in once. |
| 12:00 |
Dyrcona |
mmorgan: There's a) too much logging and b) too much bouncing back and forth among different methods. |
| 12:00 |
mmorgan |
yes, activity is there, too. I get a single line from activity for one of these threadtraces, and a whole bunch of stuff going on with the other one. |
| 12:01 |
mmorgan |
I know we have had a few situations where the same item was captured by two different holds. That's what brought me to this. |
| 12:59 |
|
hbrennan joined #evergreen |
| 13:03 |
|
fparks joined #evergreen |
| 13:27 |
eeevil |
dbwells: just a head's up, if gmcharlt's fixed field seed data ends up getting into 2.6.0, that needs to come /before/ the MVF/CRA conversion dance, so that the existing values are seen as controlled instead of uncontrolled |
| 13:39 |
* csharp |
really dislikes "does program X work with Evergreen?" questions |
| 13:39 |
csharp |
my pat answer is "test it and see" |
| 13:42 |
tsbere |
csharp: My first desire is to turn around and say "Does it have any reason to interact with the ILS directly?" For example, "Does Office work with Evergreen?" Well, since it doesn't actually interact with Evergreen at all to begin with.... |
| 13:47 |
_bott_ |
Reporter creates .xls files, so yes. In a 7 degrees of Kevin Bacon kinda way. |
| 13:48 |
jeff |
i need to work on guidelines for transitioning some willing initial staff members from "one account for all" to "this is my patron account" and "this is my staff member account" |
| 13:48 |
|
bibliophylum joined #evergreen |
| 13:51 |
csharp |
tsbere: this particular question is more about extending the OPAC with vendor widgets |
| 13:51 |
tsbere |
csharp: Ahhh. That can be more complicated and/or annoying. <_< |
| 13:51 |
csharp |
usually both in my experience ;-) |
| 13:52 |
csharp |
and I'm usually dealing with it after a library has purchased said service on the breezy assurances of the vendors |
| 13:52 |
csharp |
rather than after a rigorous test, which I'm happy to coordinate on our end ;-) |
| 13:53 |
csharp |
at least this particular library asked ahead of time, so I should be happy, not complaining |
| 13:53 |
* csharp |
is just tired today |
| 13:54 |
csharp |
jeff: are you doing that in a software-based way, or from a "this is my staff card, but *this* is my patron card" way? |
| 13:55 |
_bott_ |
jeff: we chose to transition unwilling staff into "this is your only account and you'll like it" |
| 13:58 |
* tsbere |
would like to move to *either* of those setups at MVLC, but can't |
| 13:59 |
bibliophylum |
Hey folks... I'm trying to explain to non-technical bosses what the implications of Heartbleed on Evergreen systems are. I've already covered, "we're aware of this *because* it's open source" and "no, there's no way of telling if a system was targeted", and "yes, it's patched". Any thoughts/tips? |
| 14:46 |
gmcharlt |
tsbere: on the face of it, looks much nicer than an attribute reingest |
| 14:49 |
eeevil |
agreed. purty |
| 14:49 |
gmcharlt |
tsbere++ |
| 14:50 |
* tsbere |
almost finds the WITH block abuse scary, though |
| 14:53 |
tsbere |
eeevil / gmcharlt: I very lightly tested it. Was thinking it might be best set up as a cron job, but not sure. |
| 14:53 |
jeff |
for evergreen specific impacts, if your ssl-speaking front-ends were apache linked against a vulnerable version of openssl, it was trivial to steal recently used session keys as well as cleartext credentials for recent logins. (or not-so-recent in terms of "wall clock time" if the target system was idle). |
| 14:54 |
* eeevil |
grumbles about CHAP ... ;) |
| 14:54 |
* Dyrcona |
just read some articles saying that exploits may have been circulating as long as last November. |
| 14:55 |
jeff |
if your front end was pound or nginx linked against a vulnerable version of openssl, i make no assertions because i didn't test that. :-) |
| 14:55 |
jeff |
we were happily on squeeze for ssl-speaking production systems. :-) |
| 14:57 |
Dyrcona |
'Ow nice for you. |
| 15:24 |
|
ldwhalen joined #evergreen |
| 15:54 |
jboyer-isl |
Does anyone else have any issues with Clark processes piling up around midnight (when most "I don't care when" reports are run)? Ours can creep up to 40+ processes a night, triggering an icinga alert almost daily. (we only run with -c 5, so that's over 8x the expected number of processes) |
| 16:55 |
jcamins |
(where body is a placeholder for the element, and styles might be called style) |
| 16:55 |
jcamins |
dbs: BTW, Laurentian's catalog looks fine without JS. |
| 16:55 |
jeff |
bshum: "swivels!" -- talk about missing some context. hopefully you didn't have a terrible run-in with an AMH/sorter? :-) |
| 16:56 |
* jcamins |
just tested it to see if TPAC handled no-JS pleasantly. |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
bshum |
jeff: I was just remarking where dbs mentioned avoiding JS as much as possible and how berick and senator at the hackaway two years ago had thoughts about more swivels with JS to smooth out the transitions in record summary |
| 16:57 |
bshum |
For the added content, etc. |
| 16:57 |
Dyrcona |
jcamins: That was kind of the point of TPAC, no JS. |
| 17:41 |
|
ldwhalen joined #evergreen |
| 17:41 |
|
atlas__ joined #evergreen |
| 17:48 |
hbrennan_at_lunc |
It's possible I may be hungry |
| 17:51 |
gmcharlt |
hbrennan_at_lunc: enjoy testing that hypothesis empirically! |
| 18:27 |
dbs |
gmcharlt: I believe it's possible to issue multiple requests per Read API request; travelling back in time to when I was talking with the OpenLibrary folk about their rate-limiting etc |
| 18:28 |
dbs |
I brought up the exact same point: "So, you're not rate limiting the Read API, but I end up making _more_ requests than via the Cover API?" They agreed that was silly. |
| 18:28 |
gmcharlt |
dbs: I've verified that is is; possibly something for mark 2 of my patch for bug 1306258 |
| 01:25 |
|
bwicksall joined #evergreen |
| 03:25 |
|
ldwhalen joined #evergreen |
| 03:51 |
|
atlas__ joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:47 |
csharp |
@later tell jeff yeah - it was to update openssl, etc. |
| 07:47 |
pinesol_green |
csharp: The operation succeeded. |
| 08:06 |
|
kmlussier joined #evergreen |
| 09:42 |
csharp |
jeff: sorry - looking at dpkg.log and it appears I read "openssh" as "openssl" |
| 09:45 |
jeff |
csharp++ mischief managed! |
| 09:54 |
jboyer-isl |
jeff: my memory appears to have failed me. I know I saw it somewhere, but it's possible it was on a forum or something not quite official. (I'd imagine the official advice is always "update everything unless you have a good reason not to") |
| 09:55 |
csharp |
gmcharlt: following up on my testing the 14.04 install scripts for OpenSRF/Evergreen... you probably saw that I stalled on libdbi location issues - I haven't had a chance to get back to it, FYI |
| 09:55 |
|
denishpatel joined #evergreen |
| 09:56 |
* csharp |
is busy today and tomorrow putting in hardware orders, troubleshooting something that has broken multiple PINES reports templates, and other paperwork-y things |
| 10:04 |
|
atlas__ joined #evergreen |
| 10:07 |
|
kmlussier joined #evergreen |
| 10:13 |
|
jwoodard joined #evergreen |
| 11:29 |
kmlussier |
@marc 240 |
| 11:29 |
pinesol_green |
kmlussier: The uniform title for an item when the bibliographic description is entered under a main entry field that contains a personal (field 100), corporate (110), or meeting (111) name. [a,d,f,g,h,k,l,m,n,o,p,r,s,6,8] |
| 11:40 |
dkyle |
In 2.6, anyone else see marc expert search queries take way too long, resulting in nothing found? |
| 11:41 |
yboston |
Dyrcona: I loaded up your RDA changes to my EG 2.5.x test server. Waiting for cataloger feedback |
| 11:42 |
Dyrcona |
yboston: OK. |
| 11:42 |
* dbs |
adds "Add schema.org to RDA branch" to his actual to-do list, not just his mental overload list |
| 11:45 |
gmcharlt |
heads up -- I will be running apt-get upgrade on the Git server shortly |
| 13:10 |
|
kbeswick_ joined #evergreen |
| 13:10 |
eeevil |
there we go |
| 13:13 |
|
rfrasur joined #evergreen |
| 13:15 |
gmcharlt |
I've just discovered an annoying little dependency glitch |
| 13:15 |
|
hbrennan joined #evergreen |
| 13:17 |
gmcharlt |
Business::Stripe has POD test cases that are broken, so if Test::Pod is installed (which it would be on Debian and Ubuntu if you follow the OpenSRF install instructions), cpan Business::Stripe fails |
| 13:18 |
gmcharlt |
so I think that for the moment Business:Stripe will need to be moved to CPAN_MODULES_FORCE |
| 13:18 |
eeevil |
gmcharlt: do we have a "force" list? |
| 13:18 |
gmcharlt |
just curious whether anybody else had run into this |
| 13:18 |
eeevil |
heh ... so, yeah |
| 14:18 |
kmlussier |
I concur. yboston is awesome! :) |
| 14:18 |
tonyb_ohionet |
and I have some 2.6 stuff bit size to try but we're still at 2.4 |
| 14:18 |
kbutler |
yboston++ |
| 14:18 |
* yboston |
blushes |
| 14:19 |
yboston |
ESI has a 2.5 server that can be used for updating docs |
| 14:19 |
yboston |
Eventually they can provide a 2.6 test server |
| 14:19 |
dkyle |
eeevil: will sign off... trying to figure out how, i haven't used git much lately |
| 14:19 |
jihpringle |
yboston: the Sitka 2.6beta server can still be used at the moment |
| 14:19 |
tonyb_ohionet |
gotcha...I could start with that then... |
| 14:19 |
akilsdonk |
yes, the ESI test server will be upgraded for 2.6 |
| 14:19 |
yboston |
akilsdonk: cool |
| 14:20 |
yboston |
so should those that can commit to the July 1st deadline add ourselves to one of the wiki pages, then we can start assigning stuff to ooursleves or each other? |
| 14:21 |
kmlussier |
Let's start with the 2.6 wiki page to make sure those features are done. |
| 14:39 |
remingtron |
and asking the developers is a great idea too. they can explain more about their features. |
| 14:39 |
kmlussier |
I'm happy to pair up with someone too. |
| 14:40 |
remingtron |
who wants a DIG partner for this round of features? |
| 14:40 |
jl- |
I'm currently in the process of migrating 18 libraries (for test purposes) from voyager -> eg, so I'm hoping I can add something about migration or voyager specific migration at some point. migration seems to be rather undocumented (because ILS.* are unfortunately so different) |
| 14:40 |
yboston |
I always want to ask developers where they envisioned the documentation living, in case they had thought about it. it can be tricky deciding in a vacuum if it should be in admin settigns or in OPAC settings, etc |
| 14:40 |
yboston |
hence why I suggest teaming up for the first month |
| 14:41 |
dbs |
yboston: devs might not be the best people to ask about where docs should live; different mindsets |
| 15:08 |
jeff |
shart290: first question -- was the machine in question running just the staff client, or was it running the server components of Evergreen as well? |
| 15:08 |
jeff |
ah, sounds like it was running server components as well. |
| 15:08 |
shart290 |
it was running everything. It was the server. |
| 15:09 |
jeff |
Was this a testing/development instance of Evergreen, or something that was being used in production for real work? |
| 15:09 |
|
Dyrcona1 joined #evergreen |
| 15:09 |
shart290 |
it was production, something happened to the machine a couple of months ago and nobody said anything til last week. I got in yesterday, never having laid a finger on it before. |
| 15:10 |
shart290 |
I am familiar and comfortable with Linux, but I have hit a dead end in my expertise |
| 17:27 |
bshum |
That's why I'm concerned as to why the misc_util.tt2 seems to be lying to us |
| 17:27 |
yboston |
in the reults |
| 17:27 |
yboston |
*resutls |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
bshum |
Grr, finding a bib with actual holdings is such a chore sometimes |
| 17:31 |
* bshum |
is looking for a sample from my system |
| 17:32 |
bshum |
Interesting... |
| 17:35 |
dbwells |
Well, we've been teetering on the edge of a 2.6.0 release for a while now. Anyone wishing to push us over, please do: https://launchpad.net/evergreen/+milestone/2.6.0 |
| 17:37 |
yboston |
bshum: also, movie bib records also tend to be slighly different than books, often they don't have 1xx fields and I guess in this case they have a distributor and not a publisher> |
| 17:37 |
yboston |
? |
| 17:37 |
dbwells |
I wish I could recreate the acq bug, so I could have a bit more confidence that we've solved it, but I just don't have a test server big enough right now. |
| 17:38 |
bshum |
yboston: I could see that. I'm trying to trace back where in the code this might have gone off the rails. |
| 17:38 |
bshum |
I have an idea. |
| 17:38 |
bshum |
dbwells: I wish we could have tested it more fully too. Other than the limited, "seems to work" that we quickly did |
| 17:38 |
dbwells |
The acq bug is the only true blocker, at the moment at least :) |
| 17:39 |
bshum |
dbwells: I have nothing new to add to it at this time though :\ |
| 17:40 |
yboston |
bshum: feel free to post the bug if you want, but if not I will do it tomorrow morining (need to finsish somehting else tonight) |
| 17:50 |
pinesol_green |
[evergreen|Dan Wells] LP#1304559 Fix slow Vandelay-based imports - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d42fbec> |
| 17:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1304559 - stamping upgrade script for vandelay_record_attr_to_flat - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1fa38c> |
| 18:02 |
|
jboyer-isl joined #evergreen |
| 18:05 |
bshum |
Huh |
| 18:05 |
bshum |
args.pubinfo = "$args.pubplace $args.publisher $args.pubdate"; |
| 18:05 |
bshum |
But then later on, it also sets |
| 18:05 |
bshum |
args.pubinfo = (args.pubinfos.size) ? args.pubinfos.0 : ''; |
| 18:06 |
bshum |
So wouldn't that mean that it'll replace pubinfo with the results from the graphic_880s hunt for tags 260 and 264 |
| 18:06 |
bshum |
Which is probably why it doesn't narrow it to only 264 with ind2=1 |
| 18:07 |
|
csharp joined #evergreen |
| 18:09 |
* bshum |
ponders this more. |
| 18:17 |
bshum |
Yep, I think that's the problem |
| 18:20 |
bshum |
Maybe we should just explicitly name all the different parts pubplace, publisher, pubdate in the results, same as we do for record. |
| 18:20 |
bshum |
And skip this combined pubinfo, and reserve that for the 880s dance |
| 18:21 |
|
Dyrcona joined #evergreen |
| 18:23 |
bshum |
At that point, if we desired, we could add Dyrcona's additional RDA 264 definition types as other things to be displayed in the more details instead of publisher, etc. but with the right designations. Distributor instead of publisher, and so forth. |
| 18:24 |
bshum |
Hmm |
| 18:25 |
|
Dyrcona joined #evergreen |
| 18:43 |
bshum |
And boo, dbs is right, there are no 264 samples in the test data. |
| 18:43 |
bshum |
Guess we really ought to make several to test all the variations out. |
| 18:45 |
bshum |
Maybe after dinner. |
| 18:45 |
bshum |
@monologue |
| 18:45 |
pinesol_green |
bshum: Your current monologue is at least 16 lines long. |
| 18:57 |
bshum |
Hmm, maybe an IF publisher, ELSIF distributor, and down the list of potential 264 types for results... |
| 19:24 |
|
csharp joined #evergreen |
| 10:52 |
Dyrcona |
Hmm. Our records are using OCLC elvl with capital letters sometimes. Could that a part of why it doesn't work for me? |
| 10:52 |
gmcharlt |
eeevil: I'm actually right at the end of that mode - was focusing on 2.6.0 bugs specifically, and you saw my request for somebody to deal with the fixed-field editor pullrequests |
| 10:53 |
eeevil |
I did indeed |
| 10:53 |
gmcharlt |
I may poke at testing and writing test cases for 1304559 later this afternoon, but that shouldn't be construed as a reason for anybody to not work on that one |
| 10:54 |
eeevil |
Dyrcona: shouldn't be ... the current content of the field should not matter to the existence (or not) of the context menu. only missing cmf and ccvm rows should cause what you're seeing. (a missing ELvl ccmv ctype and set of values, specifically) |
| 10:56 |
|
kbutler joined #evergreen |
| 10:57 |
Dyrcona |
No elvl in ccvm. |
| 11:10 |
pinesol_green |
[evergreen|Jeff Godin] Add alert in user editor for method errors - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d59a01> |
| 11:10 |
Dyrcona |
I have 7 distinct ctypes in production and 11 in development. |
| 11:10 |
Dyrcona |
I wonder if an upgrade script is missing somewhere. |
| 11:11 |
bshum |
I have 13 ctypes in our test system |
| 11:13 |
* bshum |
wonders what the extras are |
| 11:13 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "My ctypes in development" (14 lines) at http://paste.evergreen-ils.org/52 |
| 11:14 |
bshum |
The only additional ones I seem to have are "biog" and "ser_type" |
| 11:14 |
Dyrcona |
Well, I dunno. |
| 11:21 |
eeevil |
let me retract that statement |
| 11:21 |
eeevil |
those are NOT stock |
| 11:22 |
Dyrcona |
Should they be? |
| 11:22 |
eeevil |
ideally, yes, but they were added by hand on a test system. |
| 11:22 |
eeevil |
by not-me ;) |
| 11:22 |
bshum |
Hmm |
| 11:24 |
bshum |
Well that's... special. |
| 11:24 |
* bshum |
waits for eeevil's next trick |
| 11:24 |
bshum |
:D |
| 11:24 |
gmcharlt |
Dyrcona++ # stumbling across a potential new release-blocker ;) |
| 11:24 |
eeevil |
Dyrcona: so, to test, you'd have to create a ccvm set attached to the enc_level crad |
| 11:25 |
eeevil |
well, now, getting the appropriate data is non-trivial, and it is 100% configuration (as in, you can do it all through the staff client) |
| 11:25 |
eeevil |
so I really hesitate to consider that a release blocker |
| 11:26 |
* bshum |
twitches |
| 11:32 |
Dyrcona |
Do the ctype values matter? I mean are those referenced in code somewhere? |
| 11:32 |
eeevil |
Dyrcona: they are fkeys to crad.name |
| 11:35 |
Dyrcona |
jeff: The plug-in? Or did the use the --app command line option? |
| 11:36 |
bshum |
Unrelated, I think the docs site is down :( |
| 11:36 |
gmcharlt |
eeevil: release blocker may be too strong, but IMO most of it *ought* to be in the seed data |
| 11:36 |
* bshum |
concurs with Dyrcona on the upgrade script being helpful to get everybody following along on the same page for testing consistently. |
| 11:37 |
eeevil |
I'm not against that in the least |
| 11:38 |
gmcharlt |
a timing and tuit issue, then |
| 11:41 |
Dyrcona |
I'll do it. |
| 12:02 |
|
kmlussier joined #evergreen |
| 12:12 |
|
Christineb joined #evergreen |
| 12:13 |
phasefx |
Dyrcona++ |
| 12:24 |
Dyrcona |
phasefx gmcharlt eeevil: Could one of you paste the results of "select * from config.coded_value_map" on that test server, please? That would speed up the work that I need to do to write an upgrade script. |
| 12:30 |
remingtron |
bshum: docs site is alive again |
| 12:30 |
kmlussier |
Yay! |
| 12:33 |
Dyrcona |
yay! |
| 12:38 |
|
atlas__ joined #evergreen |
| 12:39 |
|
ericar_ joined #evergreen |
| 12:55 |
|
hbrennan joined #evergreen |
| 12:59 |
eeevil |
Dyrcona: I can, but it contains both incomplete and test (read: fake, incorrect) values. if that's still of use to you, I'll grab it |
| 13:00 |
Dyrcona |
eeevil: Never mind, then. I'll see what I can come up with on my own, then. |
| 13:03 |
gmcharlt |
Dyrcona: a possiblity for you - http://git.koha-community.org/gitweb/?p=koha.git;a=tree;f=koha-tmpl/intranet-tmpl/prog/en/data;h=129c3a2518f0df1b1012ad3d2ee6851385c2f9eb;hb=HEAD |
| 13:04 |
gmcharlt |
specifically, it may give you something more readily parseable than screen-scraping LC's website |
| 13:20 |
* bshum |
will report back |
| 13:25 |
|
ldwhalen joined #evergreen |
| 13:25 |
|
kbeswick_ joined #evergreen |
| 13:30 |
dbwells |
bshum: rats. I will be in meetings from now through 3:30, but will try to check it out again after that. Thanks for testing. |
| 13:35 |
Dyrcona |
Oh forget it. I don't have time for that. |
| 13:41 |
|
Dyrcona joined #evergreen |
| 13:42 |
Dyrcona |
Damn laptop. |
| 14:12 |
hbrennan |
Where issuances can be edited or deleted |
| 14:12 |
kmlussier |
Oh, sorry. I misunderstood. |
| 14:12 |
hbrennan |
kmlussier: How is that possible? There are only a thousand different methods of looking at serials. :) No worries |
| 14:13 |
bshum |
dbwells: Using the replaced function the way you wrote it I guess for _flat, Mary reports successful linking in her test between bibs in the queue vs. catalog. |
| 14:14 |
bshum |
So that's better than hanging forever |
| 14:14 |
eeevil |
bshum: cool. let's go with that one, then |
| 14:14 |
kmlussier |
bshum: How is the speed? |
| 14:14 |
bshum |
kmlussier: Unsure |
| 14:15 |
kmlussier |
Phew! |
| 14:16 |
kmlussier |
mllewellyn++ bshum++ |
| 14:16 |
* rfrasur |
smiles |
| 14:16 |
bshum |
It's only a 3 bib file she says, but certainly faster than not completing at all. |
| 14:16 |
bshum |
:) |
| 14:16 |
bshum |
She's testing a vandelay load next. Her first test was with acq only. |
| 14:21 |
bshum |
Regular loader seems fine too |
| 14:21 |
bshum |
mllewellyn++ |
| 14:21 |
rfrasur |
mllewellyn++ |
| 14:22 |
kmlussier |
@dessert mllewellyn |
| 14:22 |
* pinesol_green |
grabs a scoop of Lemon Sherbert and sends it sliding down the dessert bar to mllewellyn |
| 16:14 |
Dyrcona |
I see why the bookmobile would not work outside of its parent branch. |
| 16:16 |
|
jwoodard joined #evergreen |
| 16:16 |
Bmagic |
Dyrcona: That's right! I think I can close the book on this one. I will check that next time. The answer here is that the patron's ou is not "branch" but instead "bookmobile" and the permissions for the staff is set to "branch" |
| 16:21 |
dbwells |
bshum: meetings ran over, just got back. Thanks for the testing on bug #1304559. |
| 16:22 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 4, heat: 22) [Critical,Confirmed] https://launchpad.net/bugs/1304559 |
| 16:23 |
Dyrcona |
Bmagic: Do your users have more than 1 work_ou in the work_ou_map? |
| 16:23 |
dbwells |
bshum: would you mind posting an update on the bug? I'm not sure if I'll be able to do anything with it right away, so I don't want to be the bottleneck if someone else can take your info and run with it. |
| 17:00 |
Bmagic |
Dyrcona: But doing that doesn't solve my issue. It souds like I need to elevate the staff client login to system |
| 17:00 |
Bmagic |
later |
| 17:00 |
Bmagic |
Dyrcona++ |
| 17:14 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
* csharp |
runs apt-get update && apt-get dist-upgrade on lupin |
| 17:20 |
pinesol_green |
[evergreen|Mike Rylander] LP#1303987: Fully populate Ills from context menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f82055d> |
| 00:27 |
|
zerick joined #evergreen |
| 01:05 |
|
timlaptop joined #evergreen |
| 05:14 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:39 |
|
jboyer-isl joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 09:52 |
asimon |
What is the best way to delete all patrons from the database and load them again (with the same barcode numbers)? |
| 09:53 |
bshum |
asimon: Out of curiousity, what are you attempting to gain by doing so? |
| 09:53 |
Dyrcona |
asimon: Blow the database out and start over. |
| 09:54 |
asimon |
bshum: I'm trying to replace a test set of patrons with the latest information. |
| 09:54 |
asimon |
Dyrcona: I can't do that because of all the other information in the database. |
| 09:55 |
Dyrcona |
asimon: Then, you're mostly stuck because of referential integrity triggers. |
| 09:55 |
Dyrcona |
asimon: Assuming the patrons are tests, shouldn't the rest of the data be test data, too? [Though I guess not.] |
| 09:56 |
|
atlas__ joined #evergreen |
| 09:57 |
bshum |
In our system, we load student data during new schoolyears and overlay the original entry in Evergreen with new data based on a matching identifier (like student ID or barcode) |
| 09:59 |
asimon |
Dyrcona: No. I have deleted the sample bib and copy records and I am loading a new set beginning with a different id range, and I want to do the same thing with the patron records, but I'm getting: ERROR: duplicate key value violates unique constraint "usr_usrname_key" |
| 10:55 |
|
phasefx joined #evergreen |
| 10:56 |
|
jwoodard joined #evergreen |
| 10:57 |
|
Sato`kun joined #evergreen |
| 11:00 |
yboston |
Dyrcona++ # wading through RDA |
| 11:01 |
|
ericar joined #evergreen |
| 11:03 |
yboston |
Dyrcona: let me know how I can help. I don't have a 2.6.x VM set up right now but I can set one up to test RDA or authority code out, etc. |
| 11:06 |
|
pmurray_away joined #evergreen |
| 11:10 |
Dyrcona |
yboston: That branch should apply to 2.5 at least. |
| 11:10 |
yboston |
Dyrcona: that is what I was hoping as I looked at the code |
| 11:11 |
yboston |
Dyrcona: would you like me to try it out on my test 2.5.x server? |
| 11:11 |
|
Wyuli joined #evergreen |
| 11:11 |
Dyrcona |
yboston: If you want to, just cherry-pick the top commit. |
| 11:12 |
yboston |
Dyrcona: I will have to do it manually since the tests ervers I have are not git based, but it should not be too hard |
| 11:20 |
|
kmlussier joined #evergreen |
| 11:27 |
|
Guest25194 joined #evergreen |
| 11:34 |
Dyrcona |
Is the dev. meeting today? |
| 11:57 |
eeevil |
asimon: it does not. jeff: right |
| 11:57 |
* eeevil |
looks for that code... |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:22 |
bshum |
kmlussier: I think they're required because PINES required them :) So we inherit that from them. |
| 12:25 |
bshum |
jihpringle: Huh... have you guys updated your test server to 2.6-rc yet? |
| 12:25 |
|
ningalls joined #evergreen |
| 12:26 |
bshum |
jihpringle: I've got some reports on our test system that the acq/cataloging loader (vandelay) isn't matching anymore and basically just running forever with no results. |
| 12:26 |
jihpringle |
bshum: not yet, but we're hoping to have a test server running 2.6rc soon |
| 12:27 |
bshum |
jihpringle: All good, I'm digging through things on my end to try figuring out what's happening with our system and if maybe we're just on the tail end of some bad setup |
| 12:27 |
bshum |
jihpringle: I'm crossing my fingers that it's something small and we didn't break acq and cataloging before 2.6.0 :\ |
| 12:27 |
jihpringle |
fingers crossed |
| 12:28 |
jihpringle |
I'll find out when we're getting our new test server and take a look at this as soon as we do |
| 12:41 |
Dyrcona |
bshum: I've emailed our catalogers to ask them to test Vandelay on our training server. It is up to date as of Friday. |
| 12:41 |
bshum |
Dyrcona: Cool, that's appreciated. |
| 12:41 |
eeevil |
asimon: http://pastebin.com/nDj80KVW ... that's from a pre-staging schema, custom thing, but I think it's close. it'll update or insert staged patrons, matching on the barcode |
| 12:42 |
kmlussier |
bshum / jihpringle / Dyrcona: I just loaded order records on Dyrcona's dev system without any problems. |
| 12:59 |
dbs |
Even the bestest RDFa in the world isn't going to smooth that over. |
| 13:01 |
kmlussier |
Dyrcona: How recent is master on your training server? I know this was working a couple of weeks ago, but if you've updated it since then, it might affect your acq pilots. |
| 13:04 |
Dyrcona |
kmlussier: I updated it Friday. |
| 13:05 |
Dyrcona |
kmlussier: I reloaded the database, too, forgetting that it would blow out their test acquisitions data. |
| 13:05 |
Dyrcona |
On the plus side, they get more acquisitions practice. :) |
| 13:06 |
Dyrcona |
+1 to release blocker status |
| 13:06 |
kmlussier |
Dyrcona: Heh. I'll send them a quick e-mail asking them to hold off on trying order record uploads for a while. |
| 13:24 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 1, heat: 6) [Critical,Confirmed] |
| 13:24 |
bshum |
I'll start looking for what's broken next, but I've filed the bug to start |
| 13:24 |
bshum |
Well, maybe right after lunch |
| 13:34 |
* jeff |
exploits a test wheezy system |
| 13:34 |
jeff |
yup. |
| 13:34 |
jeff |
that easy. |
| 13:46 |
bshum |
14 minutes till the dev meeting |
| 13:46 |
bshum |
There's a few action items on the list from past meeting |
| 13:46 |
bshum |
See agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-04-08 |
| 14:24 |
kmlussier |
dbwells: Yes, looks like I fogot to do that. I can target it now. |
| 14:24 |
dbwells |
kmlussier: thank you! |
| 14:25 |
eeevil |
I'll raise my hand for 1304559 ... I think dbwells is on the right track in the bug comment |
| 14:25 |
bshum |
fwiw, we added the icons kmlussier mentions in the branch to our test system and it seemed fine. So I'd be happy to push things along. |
| 14:25 |
gmcharlt |
jeff: I think 1303940; since it looks like Dyrcona has reviewed it and given a (virtual) signoff, I'll do a final test and push it today |
| 14:25 |
gmcharlt |
s/1303940/1303940 is/ |
| 14:26 |
dbwells |
jeff: I guess we'll see :) |
| 14:26 |
Dyrcona |
I'd like to see some thought given to dbwells' suggestion on 1303940. |
| 14:26 |
gmcharlt |
(and look at dbwells comment) |
| 14:29 |
jeff |
#info Please review the acknowledgements for Evergreen 2.6 and make any additions/updates |
| 14:29 |
jeff |
#link https://bugs.launchpad.net/evergreen/+bug/1302113 bug 1302113 - acknowledgments in release notes |
| 14:29 |
pinesol_green |
Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New] |
| 14:29 |
dbwells |
eeevil: I did a very quick test of subbing in record_attr_flat for record_attr in vandelay._get_expr_push_jrow(). So far, nothing exploded, but I haven't tested it very hard yet. |
| 14:29 |
jeff |
#info Evergreen 2.5 bug fixes? |
| 14:30 |
jeff |
dbwells: you're still wearing the release maintainer hat for 2.5, correct? |
| 14:30 |
eeevil |
dbwells: that will work fine, I'm only concerned about performance ... my plan is to look directly at the vector |
| 14:33 |
jeff |
#info Evergreen 2.4 - final release? |
| 14:33 |
eeevil |
I'll align that with dbwells' next week |
| 14:33 |
eeevil |
after pushing in as many fixes as we can safely |
| 14:34 |
jeff |
#info Final planned Evergreen 2.4 maintenance release scheduled for April 16 |
| 14:35 |
jeff |
eeevil, dbwells: any specific things that either of you would like to call attention to in terms of things that you'd like more testing/eyeballs on for any of the above releases? |
| 14:35 |
dbwells |
jeff: nothing I can think of, thanks |
| 14:36 |
eeevil |
nothing specific |
| 14:37 |
jeff |
moving on! |
| 15:08 |
dbwells |
bshum: I was thinking of branching at RC, but at this point, we might as well wait for .0, I think. |
| 15:08 |
dbwells |
so, yest |
| 15:08 |
dbwells |
I mean yes |
| 15:09 |
bshum |
Cool deal. I'll try adding new things later this evening if I can carve out some time to test more and signoff |
| 15:09 |
dbwells |
bshum: kmlussier: here's a very quick attempt at ferreting out the Vandelay issue - http://pastebin.com/CtujPy6z |
| 15:09 |
bshum |
I can drop that into our test system and see what happens. |
| 15:10 |
dbwells |
I know eeevil is cooking up something better, but this should be really easy to test, and might tell us if we're on the right track. |
| 15:10 |
bshum |
Will do |
| 15:10 |
kmlussier |
dbwells++ |
| 15:10 |
kmlussier |
I'll leave it in bshum's capable hands while I head home. :) |
| 15:45 |
Melanion |
The CRs in question were added in 8/13, at which time our system was running..2.3? Maybe 2.2. So it could have happened before the fix. |
| 15:47 |
dbwells |
bshum: you can ignore my earlier function paste, I accidentally threw an extra '=' in there anyway. |
| 15:48 |
mmorgan |
Someone correct me if I'm wrong, but I believe nullifying action.circulation.xact_finish for those transactions would make them reappear on the patron records. |
| 15:48 |
dbwells |
bshum: We're better off testing this, since it's ready now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/1304559_and_1271661_vandelay_fixes |
| 15:49 |
Dyrcona |
mmorgan: I believe it would. |
| 15:52 |
bshum |
dbwells: That I can do. We didn't get to work on the first one, mary ended up heading out early for something else |
| 15:53 |
|
CleverNameHere joined #evergreen |
| 16:53 |
|
kmlussier joined #evergreen |
| 16:54 |
CleverNameHere |
So when running a report through evergreen it sends me a link to https://localhost/blah/blahblah/blahblahblah. Anyone know how |
| 16:54 |
CleverNameHere |
iI can configure that to our evergreen servers name |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:58 |
jeff |
CleverNameHere: in your opensrf.xml configuration file, look at the value under reporter/setup/base_uri |
| 16:58 |
kmlussier |
I don't know the answer, but I wish I had come up with a screen name that's as clever as CleverNameHere's. :) |
| 17:03 |
|
Wyuli joined #evergreen |
| 17:18 |
* gmcharlt |
grabs 0854 |
| 17:19 |
gmcharlt |
bah |
| 17:19 |
gmcharlt |
correction, 0878 |
| 17:33 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1303940: pg_tap regression test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=16eec85> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: improve readability of test case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1764ceb> |
| 17:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1303940: Protect against bogus data that can breaking indexing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c964cd4> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: don't attempt to store NULL values in keyword, browse, or facet indexes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9984b11> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: pin schema upgrade to 0878 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=149ffb3> |
| 17:33 |
jeff |
@who can breaking indexing? |
| 17:33 |
pinesol_green |
pmurray_away can breaking indexing. |
| 17:34 |
CleverNameHere |
Thanks Jeff. I found it. |
| 10:07 |
Dyrcona |
I think we might have changed one or two, but my memory is fuzzy. I'll have to compare with the stock entries in 950.*.sql or wherever. |
| 10:07 |
bshum |
Dyrcona: Unfortunately no, I was just messing with the function's definition directly in my pgadmin window and learning how to apply the raise statements. |
| 10:07 |
Dyrcona |
bshum: NP. Just thought I'd ask. |
| 10:07 |
bshum |
I don't think I have that anymore because we blew away that test system already :( |
| 10:08 |
Dyrcona |
I am going to run another browse ingest and capture all of the output to a file. |
| 10:08 |
Dyrcona |
Then, I'll know if it is every record or just some records. |
| 10:08 |
Dyrcona |
Maybe I'll try adding the raise statements beforehand. |
| 13:55 |
eeevil |
Dyrcona: k. you got an LP already? if not, I'll create one and toss this up |
| 13:55 |
Dyrcona |
eeevil: No, I didn't make a bug, yet. |
| 13:55 |
eeevil |
on it |
| 13:56 |
dbs |
For further win, add a pgtap test that triggers the problem (until the fix goes in, natch) |
| 13:56 |
|
hbrennan joined #evergreen |
| 13:56 |
eeevil |
dbs: this is a good point. Dyrcona, do you think you could do that? |
| 13:57 |
phasefx |
jeff: tsbere: do either of you know how to configure a staff client for a "silent" install? |
| 13:58 |
Dyrcona |
eeevil dbs: I don't usually use concerto, but I could add a record from our collection that triggers it. |
| 13:58 |
tsbere |
phasefx: What kind of silent install are you looking for? |
| 13:58 |
dbs |
Dyrcona: yeah, for a pgtap test you could just insert the record directly as part of the test. No need to rely on concerto |
| 13:58 |
eeevil |
Dyrcona: that, or forcing in a record shaped like this one at id=-2, say, and watching it blow up |
| 13:59 |
phasefx |
tsbere: the only context given to me was for "automated background installation", but I can solicit more info |
| 14:00 |
tsbere |
phasefx: Look into passing /S to the installer, if my memory is correct. If that doesn't work I can google the information. |
| 14:00 |
phasefx |
tsbere: thanks man |
| 14:01 |
Dyrcona |
dbs: I'll look into inserting the record. I recall seeing another test that does that. |
| 14:03 |
|
Wyuli joined #evergreen |
| 14:04 |
tsbere |
phasefx: I think that /autoupdate, /noautoupdate, /permachine, /nopermachine, and /developer are also accepted (when the client was built with those options) |
| 14:06 |
dbs |
Pg/t/regress/lp1242999_unbreak_new_encode.pg may be what you're looking for :) |
| 14:07 |
eeevil |
Dyrcona: a branch to base your tap test on: working/user/miker/lp1303940-browse-hates-null |
| 14:07 |
Dyrcona |
dbs && eeevil Thanks to you both. |
| 14:09 |
dbs |
eeevil is in my head |
| 14:10 |
eeevil |
dbs: it's very cold, but polite, in here |
| 14:11 |
jl- |
uhm, so about that bib_tag in the database for each record.. what is it? |
| 14:11 |
eeevil |
jl-: I confess, I have no idea what you are describing... |
| 14:11 |
jl- |
makes 2 of us |
| 14:13 |
eeevil |
oh! hah... that just pins the bib id of the records in that test dataset |
| 14:13 |
phasefx |
tsbere: invoking the installer works with /S, not sure if we can build an installer with that behavior enabled by default, but maybe /S to the installer will suffice. thanks man |
| 14:13 |
tsbere |
phasefx: I believe we could make it do so by default |
| 14:14 |
tsbere |
would require editing the nsi file, though |
| 14:16 |
* tsbere |
isn't sure that is the best idea and prefers the /S option |
| 14:16 |
* phasefx |
nods |
| 14:16 |
eeevil |
it looks to be used for constructing the last_xact_id. you can ignore that, unless you want to be able to use that to identify batches of records that you use marcxml_import() to pull in |
| 14:18 |
jl- |
eeevil: correct, but in my case it's not a test dataset I'm using it to load our university bibs |
| 14:20 |
eeevil |
jl-: so ... what's your question. last_xact_id is used for optimistic locking in the normal workflow. it can also do double duty as a way to identify records that came into the system in batch. you can ignore it, or use it, but it's just an opaque string, insofar as the software is concerned... does that help? |
| 14:20 |
jl- |
eeevil: yes, so it might be useful in the database, but it has no functionality in the frontend? |
| 14:22 |
jl- |
see the example here: http://paste.debian.net/92250 |
| 14:22 |
jl- |
of course I have ~200k following |
| 14:28 |
Dyrcona |
jl-: Note what eeevil said about "optimistic locking in the normal workflow." If a user has a record open while something else changes it in the background, the staff client won't save the user's changes if the last_xact_id has changed in the meantime. |
| 14:29 |
Dyrcona |
jl-: It's particular value is usually unimportant. |
| 14:31 |
jl- |
Dyrcona: in my case I'm planning ahead, we don't have any users. I'm running test-migrations |
| 14:32 |
Dyrcona |
jl-: I understand. We're telling you what that field is used for. Basically, it doesn't matter what you put into it at the start. |
| 14:33 |
Dyrcona |
jl-: I did something like IMPORT-{UNIX_timestamp} during our migration. |
| 14:37 |
|
RoganH joined #evergreen |
| 15:17 |
Dyrcona |
wifi-- |
| 15:18 |
bshum |
@blame wifi |
| 15:18 |
pinesol_green` |
bshum: wifi 's bugfix broke bshum's feature! |
| 15:18 |
kmlussier |
berick: I got a little lost in the discussion for bug 1187993. Would it indeed be useful for me to ask somebody to do a small JAWS test of a site using HTML5 datalist elements? |
| 15:18 |
pinesol_green` |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187993 |
| 15:18 |
Dyrcona |
So, is it normal for pg_tap to say that you gave it a bad plan if a test fails? |
| 15:18 |
kmlussier |
berick: If so, I'll do it ASAP. |
| 15:18 |
jeff |
I see no left joins, SET copy_id, or even UPDATE statements in that trigger. |
| 15:19 |
jeff |
anyone else who cares to, i'd be interested if this turns up a non-zero value: select count(*) from asset.opac_visible_copies where copy_id is null; |
| 16:57 |
jeff |
gsams: pay particular attention to the basics, like the reverse DNS (PTR) record for the mail server. |
| 16:58 |
gsams |
jeff++ #that will be super helpful! |
| 16:59 |
gsams |
jeff: yeah the basics, I'm pretty sure are solid. But the also recommend portion is definitely questionable for us. |
| 16:59 |
jeff |
also, generating some test messages to a gmail account you control can help when you get to the point of reviewing your SPF record, etc. -- it's useful to do a before and after there. |
| 16:59 |
jeff |
FWIW, we do not currently do DKIM or DMARC on our transactional email from the ILS, and have not had problems. |
| 17:00 |
jeff |
But we also have a pretty strong separation between transactional and promotional -- our promotional stuff goes through completely different channels. |
| 17:01 |
jeff |
The unfortunate truth is that in some cases, a handful of users hitting "this is spam" can hurt you regardless of what you do. |
| 17:01 |
jeff |
for sufficiently large values of "handful" :-) |
| 17:01 |
gsams |
yeah, that also had occured to me. I know at least this is purely transactional though, so I've got that going for me. |
| 17:02 |
gsams |
and SPF is setup already... |
| 17:02 |
jeff |
worth a test to ensure that your spf record as seen by and interpreted by google is resulting in a pass. |
| 17:03 |
jeff |
(headers as viewed in gmail "View Original" will help there) |
| 17:03 |
gsams |
well, the odd thing for me: v=spf1 include:_spf.google.com ~all |
| 17:05 |
gsams |
I'm honestly not sure if that is odd actually... |
| 17:05 |
jeff |
sounds like you're a google apps user, and sounds like that SPF record is intended to identify the mail for that domain that is sent through google apps. it does not appear to account for the mail being sent from the ILS. |
| 17:09 |
jeff |
with ~all and the sending server not in the list, you'll get a softfail. |
| 17:09 |
jeff |
which is in most cases worse than not having any SPF record. :-) |
| 17:09 |
jeff |
even with the "Receiving software SHOULD NOT reject the message based solely on this result" bit. |
| 17:26 |
gsams |
well a postfix test showed it heading to spam for my gmail. I've gone in and added an SPF record for our system, so we will see in a bit if it helps us out. |
| 17:26 |
gsams |
jeff++ Dyrcona++ |
| 17:26 |
gsams |
thanks again! |
| 17:26 |
gsams |
bshum++ as well |
| 17:27 |
bshum |
gsams++ # raising the question and getting me wondering about our own systems too.... |
| 17:31 |
gsams |
roanoke_patrons++ #for raising the issue enough times to get me to do that! |
| 17:31 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:46 |
|
book` joined #evergreen |
| 18:56 |
gmcharlt |
FYI, OpenSSL has released a major security fix http://heartbleed.com/ |
| 18:56 |
rangi |
yeah, upgrade all the things |
