| Time |
Nick |
Message |
| 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 |
| 05:39 |
|
ldwhalen joined #evergreen |
| 05:40 |
|
mceraso joined #evergreen |
| 05:40 |
|
csharp joined #evergreen |
| 05:40 |
|
phasefx joined #evergreen |
| 05:40 |
|
bwicksall joined #evergreen |
| 05:40 |
|
jboyer-isl joined #evergreen |
| 05:40 |
|
jl- joined #evergreen |
| 05:40 |
|
Sato`kun joined #evergreen |
| 05:41 |
|
BigRig joined #evergreen |
| 05:41 |
|
rri joined #evergreen |
| 05:41 |
|
b_bonner joined #evergreen |
| 05:41 |
|
robbat2 joined #evergreen |
| 05:41 |
|
robbat2 joined #evergreen |
| 05:42 |
|
wjr joined #evergreen |
| 05:43 |
|
dcook joined #evergreen |
| 05:43 |
|
gdunbar joined #evergreen |
| 05:43 |
|
phasefx2 joined #evergreen |
| 05:43 |
|
eeevil joined #evergreen |
| 05:44 |
|
tfaile joined #evergreen |
| 05:44 |
|
dreuther joined #evergreen |
| 05:44 |
|
ktomita joined #evergreen |
| 05:44 |
|
Polonel joined #evergreen |
| 05:44 |
|
pinesol_green joined #evergreen |
| 05:46 |
|
mtate joined #evergreen |
| 05:46 |
|
mtj_ joined #evergreen |
| 05:46 |
|
book` joined #evergreen |
| 05:46 |
|
mtcarlson_away joined #evergreen |
| 05:48 |
|
b_bonner joined #evergreen |
| 05:49 |
|
RBecker joined #evergreen |
| 05:49 |
|
bradl joined #evergreen |
| 05:49 |
|
ldwhalen joined #evergreen |
| 05:57 |
|
wjr joined #evergreen |
| 06:04 |
|
serflog joined #evergreen |
| 06:04 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 06:04 |
|
pastebot joined #evergreen |
| 06:14 |
|
mceraso joined #evergreen |
| 06:15 |
|
bshum joined #evergreen |
| 06:27 |
|
csharp joined #evergreen |
| 06:27 |
|
DPearl joined #evergreen |
| 06:27 |
|
jventuro joined #evergreen |
| 06:27 |
|
dconnor joined #evergreen |
| 06:27 |
|
gsams joined #evergreen |
| 06:28 |
|
mtj_ joined #evergreen |
| 06:29 |
|
eby__ joined #evergreen |
| 06:30 |
|
wjr joined #evergreen |
| 06:32 |
|
gmcharlt joined #evergreen |
| 06:39 |
|
ldwhalen joined #evergreen |
| 06:40 |
|
DPearl joined #evergreen |
| 06:40 |
|
dcook joined #evergreen |
| 06:40 |
|
jboyer-isl joined #evergreen |
| 06:40 |
|
jventuro joined #evergreen |
| 06:40 |
|
phasefx2 joined #evergreen |
| 06:40 |
|
eeevil joined #evergreen |
| 06:40 |
|
gdunbar joined #evergreen |
| 06:40 |
|
ktomita joined #evergreen |
| 06:40 |
|
timlaptop joined #evergreen |
| 06:43 |
|
pinesol_green joined #evergreen |
| 06:44 |
|
shadowspar joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:03 |
|
akilsdonk joined #evergreen |
| 08:17 |
|
wjr joined #evergreen |
| 08:18 |
|
mceraso joined #evergreen |
| 08:18 |
|
bshum joined #evergreen |
| 08:20 |
|
robbat2 joined #evergreen |
| 08:20 |
|
robbat2 joined #evergreen |
| 08:27 |
|
RoganH joined #evergreen |
| 08:39 |
|
Shae joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:49 |
|
ericar joined #evergreen |
| 08:59 |
|
mrpeters joined #evergreen |
| 08:59 |
|
tsbere joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:26 |
|
yboston joined #evergreen |
| 09:44 |
|
kbeswick joined #evergreen |
| 09:51 |
|
mceraso joined #evergreen |
| 09:51 |
|
bshum joined #evergreen |
| 09:51 |
|
asimon 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" |
| 09:59 |
Dyrcona |
asimon: There's a method to obliterate the "deleted" patrons data. I forget what it is off the top of my head. |
| 10:00 |
Dyrcona |
Is this a production server, too? |
| 10:00 |
asimon |
Dyrcona: It is a new production server and I am loading the initial records. |
| 10:01 |
Dyrcona |
asimon: If no one is using it, blow it all out and start over. |
| 10:01 |
asimon |
Dyrcona: I can't. There are many configuration changes that would be lost. |
| 10:01 |
Dyrcona |
asimon: Dump the configuration tables and reload them after. |
| 10:03 |
asimon |
Dyrcona: I am looking for a different solution. |
| 10:03 |
bshum |
asimon: I generally prefer advising you the same way Dyrcona is. It's not good to carry over too much cruft if you can avoid it (you're just setting yourself up for more pain later on, perhaps...) |
| 10:03 |
bshum |
But there is the actor.usr_purge_data function |
| 10:04 |
bshum |
Which should be what's used by the "obliterate" patron in the staff client side |
| 10:04 |
asimon |
bshum: Please elaborate. How would I use that? |
| 10:05 |
* mmorgan |
is interested, too. |
| 10:05 |
Dyrcona |
asimon: Look up the function definition in PGAdmin, that should give you the information that you need. |
| 10:05 |
|
denishpatel joined #evergreen |
| 10:06 |
bshum |
It's good to review what the function does. |
| 10:06 |
Dyrcona |
mmorgan: There is a way to trigger it from the staff client. |
| 10:06 |
Dyrcona |
...for an individual patron, at least. |
| 10:06 |
bshum |
mmorgan: What it'll do is remove most of the identifying data from a given row in actor.usr and transfer any connecting data to another destination user (like circs, holds, acq, whatever) |
| 10:06 |
mmorgan |
Dyrcona: We're interested in doing this for batches of patron records. The one by one thing we use all the time. |
| 10:07 |
bshum |
So you specify a source user and the destination user and it'll move all connecting data to the next user before it kills off the first one. |
| 10:07 |
bshum |
I'm not sure it's the tool you really want. |
| 10:07 |
bshum |
Really depends on the use case |
| 10:08 |
Dyrcona |
There's a backend call isn't there, in open-ils.actor or open-ils.circ? |
| 10:08 |
bshum |
More than likely |
| 10:08 |
Dyrcona |
mmorgan: You'd have to do some programming to obliterate patrons in batches like that. |
| 10:08 |
bshum |
I know in the staff client, it'll ask me what user I want to transfer data to |
| 10:09 |
bshum |
Or maybe that's only if it's a staff member |
| 10:09 |
mmorgan |
figured we'd need a script. |
| 10:09 |
bshum |
And otherwise, it'll just move content to the 1 user |
| 10:09 |
mmorgan |
bshum: yes, that's only for staff. |
| 10:09 |
asimon |
bshum: How about if I change the username data for each of the old patrons, which would change the usr_username_key values, which would then allow me to load the patrons with the valid usernames (=barcodes)? |
| 10:09 |
bshum |
Either way, it's the shotgun approach to things. I highly dislike it because people mis-use it all the time |
| 10:10 |
Dyrcona |
Ah, if it wasn't for those pesky users, our databases would be clean. |
| 10:10 |
Dyrcona |
Useless, but clean. :) |
| 10:10 |
bshum |
asimon: I would imagine that approach would also work. But I would encourage you to check also that you've removed any entries from actor.card related to those users or will relink them to the next batch you load accordingly. Or else I suspect that you'd get conflicts there too for existing barcodes. |
| 10:11 |
|
rjackson-isl joined #evergreen |
| 10:11 |
mmorgan |
asimon: Are you trying to preserve transactions, and just update patron information? Or just load a new batch of clean patrons? |
| 10:11 |
Dyrcona |
Nuke it from orbit. It's the only way to be sure. |
| 10:11 |
bshum |
Dyrcona: +1 |
| 10:11 |
bshum |
Dyrcona++ |
| 10:11 |
asimon |
bshum: I have already removed the entries from actor.card. |
| 10:12 |
asimon |
mmorgan: I am not trying to preserve transactions. |
| 10:12 |
* dbs |
has some revamping to do to the Library structured data pages to get phone number in the format desired by https://support.google.com/webmasters/answer/4620709 (just published yesterday) |
| 10:13 |
asimon |
bshum: How about a TRUNCATE CASCADED on actor usr? |
| 10:13 |
bshum |
asimon: I wouldn't do that. |
| 10:13 |
dbs |
minor, just need to introduce a "ContactPoint" entity |
| 10:14 |
bshum |
asimon: Or at least... I would do that with alot of good WHERE clauses limiting what users you're deleting. And you'd better be sure none of them are connected to any bib loading, item editing or whatnot |
| 10:14 |
bshum |
But uh, I might have been overzealous in my approaches when I was a newbie admin back then trying to do things the quick and dirty way instead. |
| 10:15 |
* bshum |
once deleted his 1 admin user and watched all his bibs and basically everything else vanish too. |
| 10:16 |
Dyrcona |
CASCADE will do that, but it depends on triggers, too. |
| 10:16 |
asimon |
bshum: I only need to protect the first three users. |
| 10:17 |
Dyrcona |
dbs: I wanted to bug you about schema.org stuff, but maybe later. |
| 10:17 |
bshum |
asimon: If we're not laying it on thick enough that there's alot of potential "gotcha's" in all the things you're asking, I'll say it again that what you're asking to do might not be the safest course of action. |
| 10:17 |
* bshum |
steps back from the bomb |
| 10:17 |
Dyrcona |
dbs: We added some RDA stuff to our record summary, and before I make a Launchpad bug, I wanted to add the necessary linked info attributes. |
| 10:17 |
dbs |
Dyrcona: bug me any time you like about schema.org, always happy |
| 10:18 |
Dyrcona |
dbs: It may be easier if I post a branch first so you can look at what I'll be asking about. |
| 10:18 |
dbs |
Dyrcona: sure, or if you make the Launchpad bug and push your branch I can sprinkle in some schema.org bits while signing off on it |
| 10:18 |
dbs |
Dyrcona++ |
| 10:18 |
Dyrcona |
dbs++ |
| 10:18 |
Dyrcona |
:) |
| 10:20 |
bshum |
Dyrcona++ # wading through RDA |
| 10:20 |
bshum |
dbs++ # schema.org bits! :) |
| 10:21 |
Dyrcona |
Now that I mention it, I'm not even 100% sure its all RDA-related. |
| 10:21 |
|
ldwhalen joined #evergreen |
| 10:28 |
|
dluch joined #evergreen |
| 10:29 |
|
kmlussier joined #evergreen |
| 10:32 |
Dyrcona |
dbs: I made lp 1304462 for you and everyone else. |
| 10:33 |
pinesol_green |
Launchpad bug 1304462 in Evergreen "Add 264 tag values to Record Summary" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1304462 |
| 10:34 |
|
Auth-User_ joined #evergreen |
| 10:41 |
|
serflog joined #evergreen |
| 10:41 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 10:47 |
|
jl- joined #evergreen |
| 10:47 |
|
dreuther joined #evergreen |
| 10:47 |
|
rri joined #evergreen |
| 10:47 |
|
bwicksall joined #evergreen |
| 10:48 |
|
egbuilder joined #evergreen |
| 10:48 |
|
remingtron joined #evergreen |
| 10:48 |
|
berick joined #evergreen |
| 10:48 |
|
Callender joined #evergreen |
| 10:50 |
|
edoceo joined #evergreen |
| 10:52 |
|
tfaile joined #evergreen |
| 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:34 |
kmlussier |
Dyrcona: Yup. 2 p.m. EDT |
| 11:34 |
Dyrcona |
kmlussier: Thanks. It is not on the community calendar. |
| 11:34 |
kmlussier |
I just added it to the developers calendar. |
| 11:35 |
kmlussier |
Sorry, I forgot. |
| 11:35 |
Dyrcona |
There's a developers' calendar? |
| 11:38 |
kmlussier |
Dyrcona: Yes, but all of the Evergreen Google calendars display on that community calendar that's on the wiki. I didn't add it until after you asked the question. |
| 11:40 |
|
gerson joined #evergreen |
| 11:45 |
kmlussier |
Is Primary Identification Type one of those fields that can't be hidden from the patron registration screen using an OU setting? |
| 11:45 |
kmlussier |
I know there are a couple of fields that can't be hidden, but I forget which ones. |
| 11:47 |
mmorgan |
kmlussier: I see library settings for ident_value and ident_value2, so I think you can hide that (ident_value) |
| 11:48 |
kmlussier |
mmorgan: Yes, I was looking at that. But I think the ident type still displays. |
| 11:49 |
|
ktomita joined #evergreen |
| 11:49 |
kmlussier |
Looks like Internet Access level is another field that can't be hidden. |
| 11:52 |
mmorgan |
ok, I see, you're right. They're both dropdown fields, maybe that's why? |
| 11:54 |
|
mcooper joined #evergreen |
| 11:54 |
* kmlussier |
shrugs |
| 11:54 |
jeff |
it might have more to do with them both being required values at the underlying database layer. it might have been thought better to not hide something that was going to be set anyway. |
| 11:54 |
kmlussier |
jeff: That makes sense. Is there a reason they are required in the underlying database? |
| 11:56 |
eeevil |
asimon: you could look at using the staged users stuff ... I don't recall if that includes the "merge from staging" functionality or now |
| 11:56 |
eeevil |
not |
| 11:56 |
|
Christineb joined #evergreen |
| 11:56 |
jeff |
i don't believe that there is currently a merge from staging -- you'd create a user from staged, then merge that user with another user. |
| 11:57 |
jeff |
(which is a few steps.) |
| 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:42 |
bshum |
kmlussier: Hmm, hmm, that makes me wonder |
| 12:42 |
bshum |
I was just musing if it has anything to do with the merge profiles we're employing |
| 12:43 |
Dyrcona |
My dev system was updated last Wednesday. |
| 12:43 |
kmlussier |
bshum: Let me give it another try. I didn't use a merge profile that would typically be used when loading order records. |
| 12:44 |
|
RoganH joined #evergreen |
| 12:45 |
|
atlas__ joined #evergreen |
| 12:49 |
|
gerson left #evergreen |
| 12:56 |
kmlussier |
bshum / jihpringle: I take it back. When using a merge profile that replaces the 901c (match-only merge), I'm seeing a similar issue. |
| 12:56 |
kmlussier |
It just keeps spinning. Nothing gets processed and a queue isn't created. |
| 12:57 |
kmlussier |
bshum: If you file a bug, I'll be happy to confirm. |
| 12:57 |
bshum |
kmlussier: Yeah, that's what mllewellyn reported to me too. Gah :( |
| 12:57 |
bshum |
So I guess if we can't load records in acq or cataloging, this could be a big blocker for 2.6? |
| 12:58 |
kmlussier |
+1 |
| 12:58 |
dbs |
+1 |
| 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:09 |
Dyrcona |
kmlussier: OK. Laurie and Regina know about the matching problem. |
| 13:20 |
|
mrpeters left #evergreen |
| 13:24 |
bshum |
Dyrcona: kmlussier: https://bugs.launchpad.net/evergreen/+bug/1304559 |
| 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 |
| 13:46 |
kmlussier |
Do we have a volunteer to run the meeting? |
| 13:48 |
jeff |
i'll run. |
| 13:49 |
kmlussier |
jeff++ |
| 14:01 |
jeff |
alrighty. |
| 14:01 |
* berick |
hears knuckles cracking |
| 14:01 |
dbs |
jeff++ |
| 14:01 |
jeff |
#startmeeting 2014-04-08 - Developer Meeting |
| 14:01 |
pinesol_green |
Meeting started Tue Apr 8 14:01:55 2014 US/Eastern. The chair is jeff. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:01 |
pinesol_green |
The meeting name has been set to '2014_04_08___developer_meeting' |
| 14:02 |
jeff |
#info Agenda is at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-04-08 |
| 14:02 |
jeff |
#topic Introductions |
| 14:02 |
jeff |
#info jeff is Jeff Godin, Traverse Area District Library (TADL) |
| 14:02 |
berick |
#info berick Bill Erickson, ESI |
| 14:02 |
RoganH |
#info RoganH Rogan Hamby, SCLENDS |
| 14:02 |
kmlussier |
#info Kathy Lussier, MassLNC |
| 14:03 |
gmcharlt |
#info Galen Charlton, ESI |
| 14:03 |
dbs |
#info Dan Scott, Laurentian University |
| 14:03 |
bshum |
#info Ben Shum, Bibliomation |
| 14:03 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 14:03 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 14:03 |
eeevil |
#info eeevil is Mike Rylander, ESI |
| 14:04 |
jeff |
While people are making introductions, a small PSA: if you've not read and digested the OpenSSL security advisory from yesterday, go do that instead. Debian Squeeze is unaffected, but if you're running Wheezy or most LTS versionf of Ubuntu, you're probably in need of an openssl upgrade and Apache restart. |
| 14:04 |
dkyle |
#info |
| 14:04 |
gmcharlt |
jeff++ |
| 14:05 |
jeff |
#topic Past Action Items |
| 14:05 |
jeff |
#action bshum to summarize bug tracking based on feedback from developers |
| 14:06 |
jeff |
(based on bshum's status, this is deferred -- anything else to add, ben?) |
| 14:06 |
bshum |
Since we decided at the conference to stick with LP, nothing new on that. Other than it will get done. |
| 14:06 |
jeff |
thanks! |
| 14:06 |
jeff |
#info eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 14:06 |
jeff |
eeevil: I'm guessing that's holding on 2.6.0 being cut? |
| 14:06 |
eeevil |
aye |
| 14:06 |
jeff |
#action eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 14:06 |
jeff |
#info dbwells to backport bugfix for Encode.pm (bug 1242999) issues to rel_2_5, feedback requested on backporting to earlier releases |
| 14:06 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 12) [High,Fix committed] https://launchpad.net/bugs/1242999 |
| 14:07 |
dbwells |
#info done |
| 14:07 |
jeff |
#info bshum to go through and update the bug statuses to ?fix released? for things that are done in milestones for 2.4.5 and 2.4.6 |
| 14:07 |
jeff |
bshum: done and done? |
| 14:08 |
bshum |
Yes, though dbwells++ for getting us the LP bugmaster account now for that stuff |
| 14:08 |
jeff |
dbwells++ bshum++ |
| 14:08 |
jeff |
#info done |
| 14:08 |
jeff |
#info dbwells to add RM dates to dev calendar |
| 14:08 |
dbwells |
#info done, but in a lazy and lackluster fashion |
| 14:09 |
jeff |
#info dbwells to summarize Evergreen 2.6 aspects of PostgreSQL 9.3 support in future 2.6 RM reports |
| 14:09 |
jeff |
i think that's been addressed as well, and 9.3 blockers dealt with, yes? |
| 14:09 |
dbwells |
yes |
| 14:09 |
jeff |
#info done! |
| 14:09 |
jeff |
#info jeff to start dev:hackfest:eg2014 wiki page and announce on dev list, solicit ideas and further discussion |
| 14:10 |
jeff |
#info not done, no longer relevant |
| 14:10 |
dbwells |
I didn't even know that was an action item :) http://evergreen-ils.org/dokuwiki/doku.php?id=dev:hackfest:eg2014 |
| 14:10 |
jeff |
(my fault -- it was my action item!) |
| 14:10 |
dbwells |
Well, it was what it is |
| 14:10 |
jeff |
#topic Release info - OpenSRF |
| 14:11 |
jeff |
gmcharlt: want to cover this? |
| 14:11 |
gmcharlt |
#info OpenSRF 2.3.0 is now available |
| 14:11 |
jeff |
gmcharlt++ |
| 14:11 |
dbwells |
gmcharlt++ |
| 14:12 |
gmcharlt |
my general thinking is to not pour much effort into rel_2_3 -- specifically, only cut a 2.3.1 if a major bug warrants it, or if timing of Debian Jessie warrants it |
| 14:12 |
gmcharlt |
and focus on 2.4.0 for the early summer |
| 14:12 |
jeff |
#info OpenSRF 2.3.0 required for Evergreen 2.6, functionality release that introduces a new control script, osrf_control, and significantly improves one?s ability to stop, start, reload, and manage OpenSRF services. It also adds the ability to run multiple OpenSRF instances simultaneously on a single server. |
| 14:12 |
gmcharlt |
and provisionally, it looks like the big chagnes for 2.4.0 will be |
| 14:12 |
jeff |
#link http://evergreen-ils.org/documentation/release/OpenSRF/RELEASE_NOTES_2_3_0.html OpenSRF 2.3.0 Release Notes |
| 14:12 |
gmcharlt |
- web sockets support |
| 14:12 |
gmcharlt |
- acting on the CORS support pullrqeuest |
| 14:13 |
gmcharlt |
- removal of osrf_ctl.sh |
| 14:13 |
gmcharlt |
- general improvements relfecting higher Perl versions in distros and stricter C compiler settings |
| 14:14 |
jeff |
#info OpenSRF rel_2_3 branch maintenance-only, focus is on 2.4.0 for early summer 2014: web sockets, CORS, removal of deprecated osrf_ctl.sh, improvements for recent Perl versions and stricter C compiler settings |
| 14:14 |
gmcharlt |
a question for the peanut gallery - is anybody inclined to look at the PHP client library pullrequest and try to beat it into shape? |
| 14:15 |
eeevil |
gmcharlt: also, hopefully, improved chunking/bundling, to avoid some currently required ejabberd config changes |
| 14:15 |
gmcharlt |
eeevil: thanks, I knew I'd missed something |
| 14:15 |
|
Sato`kun joined #evergreen |
| 14:15 |
jeff |
I can give the PHP client pullrequest a look-see, and solicit others to do so as well. |
| 14:15 |
jboyer-isl |
I'd rather it be taken behind the barn, but my distaste for php isn't strictly rational. |
| 14:15 |
Dyrcona |
gmcharlt: I looked at the PHP and thought it was in the wrong base repo. |
| 14:15 |
jeff |
#info OpenSRF 2.4 also to focus on improved chunking/bundling, to avoid some currently required ejabberd config changes |
| 14:16 |
Dyrcona |
My memories of it are fuzzy as that was last year sometime before my brain turned to mush. |
| 14:16 |
jeff |
#action jeff to review OpenSRF bug 1109301 for consideration, may solicit the review of others as well |
| 14:16 |
pinesol_green |
Launchpad bug 1109301 in OpenSRF "New submission for a client library in php for openSRF" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1109301 |
| 14:16 |
gmcharlt |
jeff++ |
| 14:16 |
jeff |
anything else for OpenSRF release news? |
| 14:17 |
gmcharlt |
not from me |
| 14:17 |
jeff |
#topic Release Info - Evergreen |
| 14:17 |
bshum |
gmcharlt++ # nice summary of cool things to come |
| 14:18 |
jeff |
#info Evergreen 2.6 release status |
| 14:18 |
jeff |
dbwells: over to you! |
| 14:19 |
dbwells |
I my goal is to make as few commits as we can to get to 2.6.0 as soon as possible. |
| 14:19 |
dbwells |
Here is a list of outstanding bugs for .0 https://bugs.launchpad.net/evergreen/+milestone/2.6.0 |
| 14:19 |
pinesol_green |
dbwells: Error: malone bug 2 not found |
| 14:19 |
dbwells |
uh, okay |
| 14:19 |
jeff |
#link https://bugs.launchpad.net/evergreen/+milestone/2.6.0 Outstanding bugs targeted at Evergreen 2.6.0 |
| 14:20 |
bshum |
Well that was unexpected |
| 14:20 |
dbwells |
8 of those 10 bugs are really simple polishing bugs |
| 14:20 |
dbwells |
2 are big problems which are effectively blockers. |
| 14:21 |
jeff |
#info Blockers |
| 14:21 |
dbwells |
1 was just added a few hours ago |
| 14:21 |
jeff |
#link https://bugs.launchpad.net/evergreen/+bug/1304559 acq and cataloging loader broken in 2.6-rc |
| 14:21 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 3, heat: 18) [Critical,Confirmed] |
| 14:21 |
jeff |
#link https://bugs.launchpad.net/evergreen/+bug/1303940 Bogus data can lead to null values, breaking indexing |
| 14:21 |
pinesol_green |
Launchpad bug 1303940 in Evergreen "Bogus data can lead to null values, breaking indexing" (affected: 2, heat: 10) [High,New] |
| 14:21 |
jeff |
those two, right? |
| 14:21 |
kmlussier |
Not that I consider it close to critical, but is there any chance bug 1301567 could get in 2.6.0? It makes the MVF work a little more useful. |
| 14:21 |
pinesol_green |
Launchpad bug 1301567 in Evergreen "Catalog needs more format icons" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1301567 |
| 14:22 |
dbwells |
Yes, thanks jeff. I had 2.6.0 provisionally on the calendar for tomorrow. |
| 14:22 |
dbwells |
Then 2.6.1 just two week after that. |
| 14:24 |
dbwells |
kmlussier: I'll take a look at that bug. I don't think I considered it because it wasn't targetted at all. |
| 14:24 |
jeff |
are the blockers likely to push 2.6.0 past tomorrow? |
| 14:24 |
asimon |
eeevil: TY. I think that this function will work. |
| 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:26 |
Dyrcona |
heh |
| 14:26 |
jeff |
#info Evergreen 2.6.0 provisionally on calendar for tomorrow, April 9 with 2.6.1 to follow two weeks later. |
| 14:27 |
jeff |
Anything more to add on 2.6? |
| 14:28 |
dbwells |
no, I think we are good |
| 14:28 |
jeff |
dbwells++ # RM2.6 |
| 14:28 |
bshum |
dbwells++ # wrangling and moving things forward |
| 14:28 |
* gmcharlt |
issues final reminder re bug 1302113 |
| 14:28 |
pinesol_green |
Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1302113 |
| 14:28 |
kmlussier |
dbwells++ |
| 14:28 |
gmcharlt |
namely, now's your chance to push any final ack updates to the collab branch |
| 14:28 |
Dyrcona |
dbwells++ |
| 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:31 |
dbwells |
eeevil: that would be even better |
| 14:31 |
dbwells |
jeff: yes |
| 14:32 |
dbwells |
jeff: I don't have much to say about though, other than to say the maintenance release was skipped for March, but is planned for the regular date next week. |
| 14:32 |
jeff |
#info Evergreen 2.5 maintenance release planned for April 16 |
| 14:32 |
jeff |
dbwells++ # double duty |
| 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! |
| 14:37 |
* bshum |
hijacks the agenda |
| 14:37 |
jeff |
before we move on to "Feedback for New Features Under Development |
| 14:38 |
jeff |
", I wanted to stick in an agenda item for bshum's RM 2.7 proposal, since that's where the "feedback for new features" part of the meeting idea came from (iirc) |
| 14:39 |
jeff |
#topic New Business |
| 14:39 |
jeff |
#info Release Manager proposal for Evergreen 2.7 |
| 14:39 |
bshum |
#link RM 2.7 email - http://markmail.org/message/b23u62e6rhebjkhk |
| 14:40 |
bshum |
So as promised at the in-person dev meeting, I did do a short writeup of some of the general plans or ideas on the table for 2.next (or 2.7 or whatever we're going to call it) |
| 14:41 |
bshum |
I was curious if we have any further feedback on that before we get started with laying out the next steps. |
| 14:43 |
kmlussier |
It all looks great to me. |
| 14:43 |
kmlussier |
bshum++ |
| 14:43 |
dkyle |
item 1 from that is why I'm here |
| 14:44 |
dkyle |
plus just looking to get involved again in general |
| 14:44 |
jeff |
I like a number of aspects about the proposal, especially those aspects that deal with communication, focused bug efforts, and deprecation / removal of dead things. :-) |
| 14:44 |
jeff |
bshum++ |
| 14:44 |
jeff |
dkyle++ |
| 14:44 |
kmlussier |
dkyle++ |
| 14:45 |
bshum |
Yeah, regarding deprecation, I think that'll be one of the things we'll have to make a point to announce broadly as gmcharlt suggested in the email thread. |
| 14:45 |
dkyle |
so.. do we mention new features at this point? |
| 14:45 |
bshum |
I know one of the other things we talked about removing is all the leftover code from JSPAC. |
| 14:45 |
jeff |
I don't have notes from the dev meeting in-person at the conference, but bshum's email states that we intended to vote on RM proposals during this dev meeting. Do we intend to do that here, on the list, or are we holding off for now? |
| 14:46 |
jeff |
Looking at the last time we did this, we voted on open-ils-dev. |
| 14:47 |
dbwells |
bshum++ # plan looks good |
| 14:47 |
jeff |
if there's no objection or further comment, I'll give myself an action item for calling for a RM vote on open-ils-dev within the next few days. |
| 14:48 |
kmlussier |
dkyle: We should be getting to that agenda item shortly. |
| 14:49 |
jeff |
#action jeff to call for RM 2.7 vote on open-ils-dev within the next few days |
| 14:49 |
jeff |
#topic Feedback for New Features Under Development |
| 14:49 |
dbwells |
bshum: my only suggestion would be to schedule at least one bug wrangling day in the April/May window. The bugs pile up fast without somebody banging the drum. |
| 14:49 |
jeff |
#info Metabib display fields |
| 14:49 |
bshum |
dbwells: That's probably a good idea. I was thinking about early May myself. |
| 14:49 |
jeff |
#link https://launchpad.net/bugs/1251394 Metabib Display Fields |
| 14:49 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 14) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 14:49 |
dbwells |
bshum: cool, sounds good |
| 14:50 |
bshum |
So I added that as an example of a bug that's been lost in the wilds that probably should see the light of day during 2.next as part of these feature discussion part of the agenda. |
| 14:51 |
jeff |
Metabib Display Fields has benefit for the staff client, reporting, and more. I'm very excited to see it get attention. :-) |
| 14:51 |
bshum |
What I should have done was to email the list ahead of time to ask folks to weigh in on these kinds of bugs. |
| 14:51 |
bshum |
Just a nudge forward kind of thing. |
| 14:51 |
dbwells |
I'll take the blame for any delay on the display fields stuff. I through a big monkey wrench in, then completely turned my attention to 2.6 management and forgot all about it. |
| 14:52 |
bshum |
I'll try to do that next time. And I highly encourage other folks to bring up bugs that are important to them to the attention of the group and me (assuming I win the vote ;)) |
| 14:52 |
|
hbrennan joined #evergreen |
| 14:52 |
jeff |
bshum: going forward, how much time do you envision spending on new feature attention in dev meetings, and what would you like to see happen in this portion of the meeting? |
| 14:53 |
dbwells |
I think berick's approaching of simply materializing the display fields during ingest is a tried-and-true path. |
| 14:53 |
jeff |
bshum: General "hey! this is coming! feedback welcome!", or something else? |
| 14:54 |
bshum |
jeff: That's a good summary for my part of it. I mainly would like to see more early communication if possible of ideas / plans for development; especially with regards to 2.next. I'd like to make sure that we're aware of any potential game-changers before we get too far along. |
| 14:54 |
kmlussier |
I think a general "feedback is welcome" is useful to make sure big changes receive proper attention before anyone starts coding. |
| 14:54 |
jeff |
berick++ eeevil++ dbwells++ work so far on Metabib Display Fields |
| 14:55 |
bshum |
The time requested would be for that sort of "this is coming!" but also if we needed to hash out a specific area, there's always room too for that in the regular chat day or post-meeting. |
| 14:56 |
|
kbutler joined #evergreen |
| 14:56 |
jeff |
#info Smart Float |
| 14:57 |
jeff |
#link http://markmail.org/message/736mp25legftvjld [OPEN-ILS-DEV] Smart Float: Self balancing floating collections |
| 14:57 |
dkyle |
yeah, Smart Float, was looking for any interest, collaboration, and how to go about maybe getting it rolled into a release |
| 14:58 |
dkyle |
should I put something on LP? |
| 14:58 |
jeff |
dkyle: do you have a launchpad account, and have you had a chance to open a wishlist bug for Smart Float? |
| 14:58 |
gmcharlt |
dkyle: yes |
| 14:58 |
dkyle |
jeff: I do. I did create a working branch last week, but no wishlist item yet |
| 14:59 |
jeff |
dkyle: if you can create a launchpad bug against Evergreen with a link to the working branch, etc, that's going to enable the feature to be targeted at an upcoming release. give a shout in here if you run into any issues or have questions. |
| 14:59 |
jeff |
dkyle: judging from the list conversations, people were interested and i think some had some feedback. |
| 14:59 |
* bshum |
will keep an eye out for it too |
| 14:59 |
dkyle |
jeff: will do, thanks. |
| 14:59 |
jeff |
dkyle++ grpl++ |
| 15:00 |
jeff |
#link https://launchpad.net/evergreen/+milestone/2.next bugs currently targeting Evergreen 2.next |
| 15:01 |
jeff |
I'd encourage everyone to review the bugs currently listed there, and to offer feedback, provide review, or even target new bugs. |
| 15:01 |
jeff |
Since we've hit the 3 PM mark, I'm inclined to leave it at that unless anyone else has something they'd like to go over. |
| 15:02 |
bshum |
Just a small thing, berick++ for getting good feedback from the community on the path for the web client work. |
| 15:02 |
jeff |
Does anyone else have a specific upcoming new feature they'd like to bring attention to, or a non-new-feature topic for the meeting? |
| 15:02 |
|
lcathenry joined #evergreen |
| 15:02 |
jeff |
berick++ |
| 15:02 |
jeff |
#link http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes Browser Staff Client Development Notes |
| 15:03 |
jeff |
I would also encourage everyone to read up on the work being done on the web based staff client, and to offer feedback in the various mailing list threads. |
| 15:03 |
* berick |
is always happy to respond to questions, etc. |
| 15:03 |
jeff |
pester berick! |
| 15:04 |
jeff |
#endmeeting |
| 15:04 |
pinesol_green |
Meeting ended Tue Apr 8 15:04:22 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:04 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-08-14.01.html |
| 15:04 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-08-14.01.txt |
| 15:04 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-08-14.01.log.html |
| 15:04 |
jeff |
Thanks, everyone! |
| 15:04 |
bshum |
jeff++ |
| 15:04 |
kmlussier |
jeff++ |
| 15:04 |
dkyle |
jeff++ |
| 15:04 |
berick |
jeff++ |
| 15:05 |
dbwells |
jeff++ |
| 15:06 |
gmcharlt |
jeff++ |
| 15:07 |
bshum |
dbwells: Logistics question, but we haven't branched rel_2_6 yet right? So whatever we're adding for the moment still just goes to master? |
| 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:13 |
eeevil |
yeah, that will def make things better, but I suspect it'll still be slower than the old way. One thing that's not covered at all, currently, is composite attrs in vandelay |
| 15:14 |
eeevil |
(and uncontrolled attrs) |
| 15:17 |
dbwells |
eeevil: I am curious, do you think it would help anything (regarding the speed problems we've found) to define record_attr in terms of the map/vector rather than in terms of record_attr_flat? |
| 15:17 |
dbwells |
I think we could limit that extra level of indirection. |
| 15:17 |
dbwells |
s/limit/eliminate/ |
| 15:18 |
eeevil |
dbwells: the speed change comes primarily from the hstore() call, so IMO, probably not. and we'd have to do what record_attr_flat does, but in-line in the query |
| 15:18 |
eeevil |
that said, it's worth a try |
| 15:19 |
eeevil |
dbwells: objections to me trying to address the lock overflow issue caused by the temp table usage? |
| 15:19 |
dbwells |
It seems like we're hitting planning problems, since we know the underlying structures are plenty fast. |
| 15:19 |
eeevil |
basic idea would be to use unlogged tables and delete from them instead of dropping them |
| 15:20 |
eeevil |
dbwells: well, I'm going to try to get it to use the index over vlist |
| 15:22 |
dbwells |
eeevil: sorry, not catching your context re: lock overflow issue. What are you referring to? |
| 15:23 |
* dbwells |
is working on too many things at once |
| 15:23 |
jeff |
And if I didn't mention it enough earlier, if you're running pretty much anything other than Debian Squeeze, you need to upgrade openssl, restart apache, and consider taking additional steps to deal with CVE-2014-0160 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 |
| 15:23 |
pinesol_green |
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160) |
| 15:23 |
eeevil |
large vandelay queues can fail outright because we create and destroy 2 temp tables per record we try to match |
| 15:23 |
eeevil |
hrm.. might be stack space, not lock space. sec |
| 15:24 |
eeevil |
https://bugs.launchpad.net/evergreen/+bug/1271661 |
| 15:24 |
pinesol_green |
Launchpad bug 1271661 in Evergreen "record import matching can fail with "shared memory" PostgreSQL errors" (affected: 2, heat: 12) [Undecided,Triaged] |
| 15:24 |
Dyrcona |
jeff: Or just leave the Internet, 'cause its never going to be secure enough for you. :) |
| 15:24 |
Dyrcona |
Well, until the power goes out for everyone, for good. |
| 15:25 |
dbwells |
eeevil: If we can keep that fix separate from the 2.6.0 window I would be happier despite the churn. Unless, of course, it happens to be pretty simple, somehow. |
| 15:26 |
eeevil |
dbwells: looks simple. I'll keep it in a separate commit |
| 15:26 |
|
Sato`kun joined #evergreen |
| 15:26 |
dbwells |
eeevil: cool, thank you |
| 15:38 |
|
Melanion joined #evergreen |
| 15:39 |
Melanion |
Howdy folks. |
| 15:40 |
Melanion |
I'm having a bit of an issue and I wondered if anyone had encountered it before. I've got several items which item status show checked out to a patron with a fines stop reason of CLAIMSRETURNED, but they don't show up when viewing that patron. |
| 15:41 |
eeevil |
Melanion: if the fine/fee balance of the circ transaction went to 0 then (IIRC) the circs disappear from the items-out display in the patron |
| 15:42 |
mmorgan |
lp 793550 |
| 15:42 |
pinesol_green |
Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550 |
| 15:42 |
eeevil |
dbwells: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/1304559_and_1271661_vandelay_fixes 1) untested and 2) ignore the top commit if you'd rather |
| 15:42 |
mmorgan |
Melanion: What release are you on? |
| 15:43 |
Melanion |
Ah. So if desk staff applied a nonspecific credit to the account and it wiped any charges the CR had on it out, the CR would disappear from the patron's account? |
| 15:43 |
Melanion |
Windows 2.4.3 |
| 15:44 |
Dyrcona |
Melanion: I don't think the Windows will matter in this case. :) |
| 15:44 |
mmorgan |
This bug should have been fixed with 2.4. We saw it in earlier versions ... of Evergreen:) |
| 15:44 |
Melanion |
I like to be specific. :P Also, derp on me for not reading the bug descrip before asking. |
| 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 |
| 15:54 |
Dyrcona |
Melanion: You say the copies say "checked out" and not "lost" for the status? |
| 15:54 |
Melanion |
Dyrcona: Correct. |
| 15:54 |
Dyrcona |
'Cause I think there might be another, related issue with lost copies. |
| 15:55 |
|
Sato`kun joined #evergreen |
| 16:10 |
Melanion |
Blah, I'm just an underpaid undergrad who barely has the permissions to scratch my chin. I'm just going to tell the desk staff reading the reports to check the items' statuses by the barcode rather than looking at patron info. Still, thanks for the info. |
| 16:15 |
jboyer-isl |
I need to make time to push a branch addressing lp 1241644, it sounds like that's what Melanion is running into. :( |
| 16:15 |
pinesol_green |
Launchpad bug 1241644 in Evergreen "claims_returned and longoverdue counts differ between open-ils.actor.user.checked_out(.count) and open-ils.storage.actor.user.checked_out(.count)" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1241644 |
| 16:16 |
jboyer-isl |
one method looks at checkin_time and xact_finished, the other only cares about checkin_time. (I like the latter. It's "claims returned" until it's "really returned") |
| 16:20 |
jboyer-isl |
Uh, I guess I should have refreshed my memory a little harder on that bug, because there's a branch right there. |
| 16:24 |
jeff |
heh |
| 16:24 |
|
mrpeters joined #evergreen |
| 16:28 |
eeevil |
dbwells / bshum: I'll make 2 upgrade scripts for that branch, one for each commit, if you want |
| 16:29 |
jeff |
oh wacky. dokuwiki sets the following header on password reset emails: List-Id: Evergreen DokuWiki <wiki.evergreen-ils.org> |
| 16:31 |
bshum |
eeevil: I would appreciate it. I tried digging it out and I'm getting some syntax error trying to run the update |
| 16:31 |
eeevil |
bshum: ah, yep. I'll fix those too |
| 16:32 |
eeevil |
bshum: looks like just one, actually. the line looks like this: jrow := jrow || ' mra.vlist @> intset(ccvm.id)' || |
| 16:32 |
eeevil |
bshum: should end in ; instead of ||, obv |
| 16:33 |
bshum |
Whoops, almost ran the query in production's DB.... (triple checking ftw) |
| 16:33 |
eeevil |
heh! |
| 16:34 |
dbwells |
bshum: at least there are worse queries to accidently run in production ;) |
| 16:45 |
eeevil |
bshum: to simplify things, I'm going to push a separate branch that is syntax-fixed from the first commit on, and includes upgrade scripts. sec |
| 16:46 |
eeevil |
bshum: working/collab/miker/1304559_and_1271661_vandelay_fixes_with_upgrades http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/1304559_and_1271661_vandelay_fixes_with_upgrades |
| 16:47 |
eeevil |
DANG IT |
| 16:47 |
eeevil |
ok, the YYYY upgrade needs fixing, but you mostly care about the XXXX script |
| 16:47 |
bshum |
Heh |
| 16:48 |
dbwells |
ah, nothing like the pressure of last second bug discoveries |
| 16:48 |
eeevil |
I totally force-updated it ;) |
| 16:48 |
eeevil |
dbwells: :) |
| 16:49 |
eeevil |
ok ... I'm out for now. let me know if it works out |
| 16: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:04 |
bshum |
dbs: For later, could you add kmlussier to the Evergreen Drivers group so that she can help target bugs to specific series. |
| 17:05 |
bshum |
Related, this is my +1 to giving kmlussier more powers with LP to help organize things. |
| 17:05 |
hbrennan |
+1 kmlussier is a super organizer |
| 17:07 |
kmlussier |
I'm suddenly afraid of what I've gotten myself into. ;) |
| 17:08 |
|
mmorgan left #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. |
| 17:48 |
|
atlas__ joined #evergreen |
| 18:07 |
mrpeters |
this ring any bells for anyone? http://pastie.org/9004788 |
| 18:08 |
mrpeters |
really concerns me that this "oils_xpath" is missing....customized sql to build the database and i think that may have munged something up |
| 18:13 |
gmcharlt |
mrpeters: check search_path |
| 18:13 |
dbwells |
I second that |
| 18:13 |
mrpeters |
where is that defined? |
| 18:14 |
dbwells |
One way would be: SET search_path = evergreen, public, pg_catalog; |
| 18:15 |
mrpeters |
how can i see what search_path is now? |
| 18:15 |
gmcharlt |
and as a Pg GUC variable, it can be set at the database level using |
| 18:15 |
gmcharlt |
ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog; |
| 18:15 |
mrpeters |
just out of curiosity |
| 18:15 |
bshum |
SHOW search_path; |
| 18:15 |
bshum |
From psql |
| 18:15 |
gmcharlt |
this is one of the things that pg_dumpall will emit, but /not/ pg_dump |
| 18:15 |
mrpeters |
tcmc_evergreen=# SHOW search_path; |
| 18:15 |
mrpeters |
search_path |
| 18:15 |
mrpeters |
---------------- |
| 18:15 |
mrpeters |
"$user",public |
| 18:15 |
mrpeters |
(1 row) |
| 18:15 |
mrpeters |
wtfffffff |
| 18:16 |
mrpeters |
that woudl explain why it worked fine when i did the dump, but not otherwise...they must have used dumpall |
| 18:17 |
mrpeters |
so, i assume s/evergreen/mydbname/ there? |
| 18:17 |
gmcharlt |
ayup |
| 18:18 |
mrpeters |
excellent. thanks guys |
| 18:18 |
mrpeters |
gmcharlt++ dbwells++ bshum++ |
| 18:18 |
dbwells |
huh, I though 'evergreen' was a hardcoded schema for our functions |
| 18:18 |
bshum |
dbwells: It is |
| 18:19 |
bshum |
I assume mrpeters meant for the database portion where you set it with ALTER DATABASE |
| 18:19 |
bshum |
The path definitely needs to be evergreen, etc. |
| 18:19 |
mrpeters |
actually i meant in the list of paths |
| 18:19 |
dbwells |
ah, ok, makes sense now |
| 18:19 |
gmcharlt |
but not every reference to such functions are qualified with "evergreen.", hence the dependence on search_path |
| 18:19 |
mrpeters |
i knew to alter my db name :) |
| 18:19 |
mrpeters |
right on |
| 18:20 |
gmcharlt |
alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog; |
| 18:20 |
gmcharlt |
;) |
| 18:20 |
dbwells |
gmcharlt: right, just a little miscommunication there on what mrpeters was s//'ing |
| 18:20 |
gmcharlt |
dbwells: right; mostly for the benefit of the log |
| 18:20 |
bshum |
logs++ |
| 18:21 |
mrpeters |
haha |
| 18:21 |
mrpeters |
thanks guys, im beat...night! |
| 18:24 |
dbwells |
We should probably create one of those one word response things so we can say @search_path or something and have it spit out the essence of this conversation. Seems to come up a lot. |
| 18:27 |
bshum |
Hmm |
| 18:28 |
bshum |
~search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog; |
| 18:28 |
pinesol_green |
I'll remember that, bshum |
| 18:29 |
dbwells |
bshum++ # yeah, like that :) |
| 18:29 |
bshum |
~search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 18:29 |
pinesol_green |
But search_path already means something else! |
| 18:29 |
bshum |
Hmm |
| 18:29 |
bshum |
~search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 18:29 |
bshum |
It doesn't like me |
| 18:30 |
bshum |
~no search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 18:30 |
pinesol_green |
I'll remember that bshum |
| 18:30 |
bshum |
Missing trailing ' |
| 18:30 |
bshum |
~search_path |
| 18:30 |
pinesol_green |
search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 18:30 |
bshum |
That makes me feel better now. |
| 18:33 |
jeff |
evergreen 2.next will eliminate search path issues. it will also bake you a cake. |
| 18:34 |
dbwells |
But shouldn't there be an option for cookies instead? |
| 18:35 |
hbrennan |
I'll vote for either as long as it's chocolate |
| 18:35 |
jeff |
if I want cookies, I'll get them from DTLS heartbeat overflows. |
| 18:36 |
jeff |
(too soon?) |
| 18:36 |
bshum |
jeff: Do we need a factoid for that so that you don't have to type your PSA all over again? :D |
| 18:37 |
* bshum |
jests |
| 18:37 |
bshum |
jeff++ |
| 18:37 |
dbwells |
mmmmm, heartbeat overflows... |
| 19:03 |
|
shadowspar joined #evergreen |
| 20:30 |
|
gsams joined #evergreen |
| 21:08 |
Guest82076 |
@quote add < jeff> evergreen 2.next will eliminate search path issues. it will also bake you a cake. |
| 21:08 |
pinesol_green |
Guest82076: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 21:08 |
hbrennan |
Sneaky guests. |
| 21:08 |
csharp |
@quote add < jeff> evergreen 2.next will eliminate search path issues. it will also bake you a cake. |
| 21:08 |
pinesol_green |
csharp: The operation succeeded. Quote #82 added. |
| 21:11 |
|
csharp joined #evergreen |
| 21:11 |
csharp |
~search_path |
| 21:11 |
pinesol_green |
search_path is When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 21:12 |
csharp |
~no search_path is <reply> When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 21:12 |
pinesol_green |
In #evergreen, csharp said: ~no search_path is <reply> When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 21:12 |
csharp |
~no search_path is <reply> When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 21:12 |
pinesol_green |
I'll remember that csharp |
| 21:13 |
csharp |
~search_path |
| 21:13 |
pinesol_green |
When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 21:16 |
bshum |
csharp++ |
| 21:16 |
robbat2 |
csharp, so the next ver will have all plsql stored procedures using fully qualified names? |
| 21:20 |
dbs |
@later tell kmlussier you are now a member of the Release Drivers |
| 21:20 |
pinesol_green |
dbs: The operation succeeded. |
