Time |
Nick |
Message |
07:06 |
|
rjackson_isl joined #evergreen |
07:31 |
|
bdljohn joined #evergreen |
07:53 |
|
jvwoolf joined #evergreen |
08:00 |
|
Dyrcona joined #evergreen |
08:04 |
|
jvwoolf1 joined #evergreen |
08:29 |
|
aabbee joined #evergreen |
08:29 |
* csharp |
wonders if we can disable the "Answers" feature of launchpad and add a redirect to our site's FAQ |
08:34 |
|
rlefaive joined #evergreen |
08:40 |
JBoyer |
I think that's come up before and I thought the answer was "can't do that" :/ |
08:40 |
csharp |
looks like that is possible for someone with higher privileges that I have: https://help.launchpad.net/Answers |
08:40 |
|
mmorgan joined #evergreen |
09:28 |
gmcharlt |
csharp: those instructions seem slightly out of date |
09:29 |
gmcharlt |
but... |
09:30 |
gmcharlt |
bshum: berick: could you add cesardv and csharp to the "Evergreen Release Team" team on Launchpad |
09:30 |
gmcharlt |
and bump up me (and anybody else on it whose interested to admin privs on that team?) |
09:31 |
|
yboston joined #evergreen |
09:32 |
gmcharlt |
also, I don't see an option to turn off Answers |
09:32 |
gmcharlt |
although there's a way to specify that it is external |
09:32 |
gmcharlt |
but then, LP displays something along the lines of "we don't know how this project receives support requests" |
09:32 |
gmcharlt |
i.e., not seeing a way to put in a URL or text saying where to go to get help :( |
09:40 |
|
jvwoolf joined #evergreen |
09:42 |
csharp |
yeah :-/ |
09:43 |
csharp |
gmcharlt: thanks for looking and for trying to up my privs :-) |
09:45 |
bshum |
gmcharlt: csharp and cesardv added to that team in LP |
09:48 |
bshum |
And I don't think we can disable answers |
09:48 |
aabbee |
noting in case anyone else sees similar error: after installing 3.2: i got 500 errors in the browser and /var/log/syslog said 'egweb: Context Loader error: Can't locate object method "retrieve_config_global_flag" via package "OpenILS::Utils::CStoreEditor" at /usr/local/share/perl/5.22.1/OpenILS/WWW/EGCatLoader.pm line 284.\n' |
09:48 |
aabbee |
resolved by restarting apache2. found these logs, which helped: http://irc.evergreen-ils.org/evergreen/2016-09-02#i_265134 |
09:48 |
aabbee |
tsbere++ |
09:48 |
aabbee |
Dyrcona++ |
09:56 |
* gmcharlt |
claims 1130 in the name of folks who don't want to be squished everywhere! |
10:03 |
|
terran joined #evergreen |
10:04 |
bshum |
"I shall call him Squishy and he shall be mine and he shall be my Squishy." |
10:05 |
* gmcharlt |
also claims 1131 in the name of enforcing consistency! |
10:06 |
pinesol |
[evergreen|Jason Stephenson] LP 1786534: Don't merge a user with itself. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ecae2cc> |
10:06 |
pinesol |
[evergreen|Galen Charlton] LP#1786534: make update script reflect other recent changes in actor.usr_merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c58067> |
10:06 |
pinesol |
[evergreen|Galen Charlton] LP#1786534: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6129d52> |
10:07 |
* csharp |
is looking at bug 1773434 |
10:07 |
pinesol |
Launchpad bug 1773434 in Evergreen "Item Status - missing option to "Show in Catalogue"" [Undecided,Confirmed] https://launchpad.net/bugs/1773434 |
10:08 |
|
jwoodard joined #evergreen |
10:08 |
csharp |
looks like we have working code there with a semi-signoff from kmlussier, but it ends with a question about menus |
10:09 |
csharp |
wondering if we shouldn't accept the fix as-is and let kmlussier open a new bug if she thinks it makes sense to change it - thoughts? |
10:09 |
* csharp |
was about to test and sign off |
10:10 |
pinesol |
[evergreen|Galen Charlton] LP#1786534: ensure that changes don't regress - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4894212> |
10:11 |
gmcharlt |
csharp: yeah, I think it makes sense to either leave that for a follow-up bug or just do a quick follow-up patch |
10:12 |
gmcharlt |
either way, so long as it doesn't block /something/ getting in for 3.2 |
10:15 |
csharp |
ok - that's sane - moving forward with that something :-) |
10:30 |
pinesol |
[evergreen|a. bellenir] LP#1773434 missing option to "Show in Catalog" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b19a728> |
10:30 |
pinesol |
[evergreen|a. bellenir] LP#1773434: show in catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fab9098> |
10:31 |
Dyrcona |
Kernel update, going to reboot. BBIAB. |
10:35 |
|
Dyrcona joined #evergreen |
10:36 |
pinesol |
[evergreen|Kathy Lussier] LP#1738688: Add cancel time to Most Recent Transits - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a1a43b> |
10:44 |
pinesol |
[evergreen|Remington Steed] LP#1774724: Fix copy-pasto's in Library Settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=564ba9f> |
10:45 |
berick |
@band add Copy Pasta |
10:45 |
pinesol |
berick: Band 'Copy Pasta' added to list |
10:48 |
JBoyer |
With openers The Electric Italian Heinz Crimes |
10:48 |
|
rebecca_ joined #evergreen |
10:49 |
|
khuckins joined #evergreen |
10:53 |
yboston |
Hello everyone, I am planning relying on batch adding standing penalties to a bunch of users to support a new initiative here |
10:54 |
yboston |
I have figured out how to batch add with SQL the standing penalty that I want to the users I want to target. My question for you folks, is how do I go about using SQL batch deleting standing penalties if the need arises. |
10:54 |
yboston |
It might be as simple as deleting specific rows in actor.usr_standing_penalty, but I wanted to make sure. |
10:54 |
yboston |
I looked over the source code and got as far as seeing entried like this $e->delete_actor_user_standing_penalty($penalty) but I have not been able to find the next logical steps in the code to see how standing penalty deletions are done. |
10:54 |
yboston |
TIA |
10:55 |
Dyrcona |
yboston: That $e->delete_actor_usr_standing_penalty bit just does a SQL delete under the covers. |
10:55 |
Dyrcona |
Any of the CStoreEditor functions end up doing SQL, evenually. |
10:56 |
berick |
and the $e-> methods are auto-generated, so grep won't find them. |
10:56 |
yboston |
Dyrcona: thanks, that is what I suspected. I just never made the leap to understand how the code interacts wtht he CStoreEditor |
10:56 |
Dyrcona |
Right. They're autogenerated from the IDL. |
10:56 |
yboston |
Dyrcona: that is what I thought |
10:57 |
Dyrcona |
So, you can just do a SQL delete if that's easier than figuring out the Perl, which it usually is. |
10:57 |
Dyrcona |
berick++ :) |
10:58 |
yboston |
Dyrcona: for this case I will use SQL, but this is very helpful, it confirmed what I thought was happenng. |
10:58 |
yboston |
Dyrcona: can you tell me a little more of what I should look for in the IDL to at least go a couple more steps deeper in the code logic |
10:59 |
yboston |
Dyrcona: I want to learn a bit more of the CStoreEditor logic today from you (or someone else) if you have a second |
11:00 |
Dyrcona |
Well, the IDL is mainly for Fieldmapper to turn database data into Perl objects, but pcrud, cstorage, and storage use it generate methods to create, retrieve, update, and delete objects. |
11:01 |
|
mmorgan left #evergreen |
11:02 |
Dyrcona |
The CStoreEditor generates search_ delete_ create_ and update_ functions for the objects from the IDL. It uses the oils_obj:fieldmapper attribute with the :: converted to an underscore. |
11:03 |
Dyrcona |
It also requires a transaction for delete, create, and update. |
11:03 |
Dyrcona |
If you have any specific questions, please ask. |
11:05 |
csharp |
jeffdavis: FYI, PINES staff are about to test bug 1715767 - hopefully we'll see a signoff so it can make it to 3.2 |
11:05 |
pinesol |
Launchpad bug 1715767 in Evergreen "Allow others to use my account (privacy waiver)" [Wishlist,New] https://launchpad.net/bugs/1715767 |
11:06 |
csharp |
(unless it's too late for getting that done) |
11:07 |
berick |
csharp: too late on that one for 3.2, but a sign-off now so we can merge as soon as rel_3_2 is branched would be great. |
11:07 |
|
mmorgan joined #evergreen |
11:07 |
csharp |
berick: understood |
11:21 |
yboston |
Dyrcona: thanks a lot for the recap. I knew the basics of what the IDL and fieldmapper did, i.e. creating objects verisosn of DB tables/fields and assist in creating correspnding methods to act upon them, from reading some dev docs. I just had not followed the process before of the other end of callign comands on the CStoreEditor object. ¡¡¡Thanks again!!! |
11:23 |
|
Christineb joined #evergreen |
11:29 |
gmcharlt |
csharp: for that last thing you pushed, the schema update needs to be stamped |
11:29 |
gmcharlt |
do you know how to do that? |
11:30 |
csharp |
oh oops |
11:31 |
csharp |
I've not done it before |
11:31 |
gmcharlt |
ok - so for the room, the process is to |
11:33 |
gmcharlt |
1. look at 002.schema.config.sql for the line INSERT INTO config.upgrade_log |
11:34 |
gmcharlt |
2. claim the next number in sequence in this channel |
11:34 |
gmcharlt |
3. edit 002.schema.config.sql; note that the comment on that line by conventino should be changed to the IRC nicks of the people folks involved in the patch (author, tester, committer) |
11:35 |
gmcharlt |
4. under upgrade/, do a git mv XXXX./whatever/ to /new_stamp/./whatever/ |
11:36 |
gmcharlt |
5. edit /new_stamp/./whatever and ensure that the SELECT evergreen.upgrade_deps_block_check line is uncommented and has the correct new stamp |
11:36 |
gmcharlt |
6. commit and push the result |
11:37 |
berick |
gmcharlt++ |
11:37 |
csharp |
7. profit |
11:37 |
csharp |
thanks I'll do that |
11:38 |
gmcharlt |
NOTE |
11:38 |
gmcharlt |
when backporting, while you can cherry-pick the update |
11:38 |
gmcharlt |
note that you can often expect a merge conflict in 002.schema.config.sql |
11:38 |
gmcharlt |
but of much more import: the schema update itself needs to be looked at for correctness |
11:38 |
gmcharlt |
particularly for changes to functions |
11:38 |
gmcharlt |
since the master version of function foo() may be different from the version in previous rel_* branches |
11:40 |
* Dyrcona |
thinks it is a bad idea to backport db changes, but I do it.... ;) |
11:40 |
gmcharlt |
yeah, it can very much introduce risks |
11:41 |
gmcharlt |
csharp: and that's why commits 4894212ed19a4ab6d90b9afd8505d71043fc6e93, 7c580671be47cb2ea800b3e005f6a281acee4829, and aac44b2b02f791351d7505221d8929a6ee2362eb are what they are |
11:41 |
pinesol |
gmcharlt: [evergreen|Galen Charlton] LP#1786534: ensure that changes don't regress - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4894212> |
11:41 |
pinesol |
gmcharlt: [evergreen|Galen Charlton] LP#1786534: make update script reflect other recent changes in actor.usr_merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c58067> |
11:41 |
pinesol |
gmcharlt: [evergreen|Galen Charlton] LP#1786534: sync schema update with rel_3_x actor.usr_merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aac44b2> |
11:41 |
gmcharlt |
as part of my pushing the fix for bug 1786534 |
11:41 |
pinesol |
Launchpad bug 1786534 in Evergreen 3.1 "Possible to merge a user with itself" [Medium,Fix committed] https://launchpad.net/bugs/1786534 |
11:42 |
Dyrcona |
Yeah, I should have rebased that one after something else went in. |
11:42 |
csharp |
gmcharlt++ # thanks for the thorough explanation! |
11:42 |
gmcharlt |
cesardv: also, please take note of ^^^ |
11:44 |
csharp |
ok, then I'm calling 1132 :-) |
11:48 |
csharp |
oops - didn't sign off on it, but I guess that's probably a minor mistake |
11:50 |
|
beanjammin joined #evergreen |
11:51 |
pinesol |
[evergreen|Chris Sharp] LP#1774724 - stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f594e28> |
11:52 |
gmcharlt |
csharp++ |
12:15 |
|
jvwoolf joined #evergreen |
12:25 |
|
plux joined #evergreen |
12:38 |
|
plux left #evergreen |
12:38 |
|
plux joined #evergreen |
12:39 |
JBoyer |
git --amend --notary |
12:44 |
plux |
working on an upgrade from 3.0.3 to 3.2 beta on a test box - hit issues with the reingest at 1103.data.virtual_index_defs.sql - tried running with just one valid biblio.record_entry id and it just hangs - ditto for other records |
12:45 |
plux |
anyone else seeing issues with that? |
12:46 |
|
beanjammin joined #evergreen |
12:47 |
JBoyer |
plux, is postgresql completely crashing on you? depending on your database you might be running into bug 1764542 |
12:47 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Confirmed] https://launchpad.net/bugs/1764542 |
12:54 |
plux |
that’s the behaviour ….so I set config.metabib_field format = to mods33 for everything that had an xpath with mods but let 1103 reset the xpath value for id 16 (geographicCode) |
12:55 |
plux |
to all the xpath in config.metabib_field shows mods 33 and all the format columns for those are mods 33 with the exception of that one xpath field set by 1103 |
12:55 |
plux |
but it does indeed crash the db to run the 1103 reingest even with just one record |
13:00 |
plux |
reverted that one xpath and it appears to have run OK on that one record so I’ll try to run it again on all |
13:01 |
plux |
not sure if I can accomplish that with pingest.pl anymore or if it has to run sequentially |
13:03 |
Dyrcona |
plux: Browse ingest is the only that has to run serially. Everything else can run in parallel. |
13:03 |
|
jvwoolf1 joined #evergreen |
13:03 |
plux |
@drycona Thanks! |
13:03 |
pinesol |
plux: You probably want hard-boiled eggs. |
13:04 |
|
jihpringle joined #evergreen |
13:04 |
Dyrcona |
pinesol: I do! Bring me some! |
13:04 |
pinesol |
Dyrcona: Fire BAD! Reading GOOD! |
13:04 |
JBoyer |
Sorry to be distracted, what you can do before applying that patch is to just change the default value for the format field to mods33, you don't need to change any other existing values. Then you can apply that upgrade script and reingest without issue. |
13:04 |
* JBoyer |
notices that his prod db STILL doesn't have that set... |
13:15 |
csharp |
hmm - that's interesting :-/ :https://pastebin.com/nrrRPgrX |
13:16 |
|
yboston joined #evergreen |
13:16 |
berick |
would have been more interesting had it returned a result ;) |
13:32 |
csharp |
trying to ferret out an issue where I register a workstation, log in with it, then am brought back to workstation (though it sees the one I registered) and when I click "Use Now" it goes back to the login page with "egAuth found no valid authtoken" in an endless loop |
13:33 |
csharp |
this is on FF and Chrome and cache/cookie clears have all happened |
13:34 |
csharp |
I've applied several patches at the behest of my colleagues for testing bugs, so I don't know what broke it :-/ |
13:36 |
Dyrcona |
charp: Have you tried doing the npm, make, and make install steps again? |
13:36 |
Dyrcona |
csharp, that is. |
13:36 |
csharp |
no, I haven't |
13:36 |
csharp |
we installed with a deb created from the 3.2-beta1 tarball |
13:36 |
csharp |
I'm going to revert to a known-working state |
13:38 |
Dyrcona |
I find reinstalling sometimes helps weird issues when mixing branches. |
13:39 |
csharp |
yeah - definitely gonna be more careful installing a bunch of branches at once :-/ |
13:39 |
JBoyer |
csharp, re those logs: I regularly see things like that with metarecord url params in it. It grabs the MR id, but keeps going (a ';' vs '&' things somewhere?) I haven't been able to track it down. |
13:39 |
csharp |
I've seen things like that before in our prod logs too |
13:56 |
|
rlefaive joined #evergreen |
14:03 |
miker |
csharp: just a thought: https://bugs.launchpad.net/evergreen/+bug/1786987 |
14:03 |
pinesol |
Launchpad bug 1786987 in Evergreen "Autogen does not refresh unlocalized org tree cache" [Undecided,New] |
14:04 |
miker |
but ;-separator is probably a better thread to pull first |
14:05 |
csharp |
miker: it will probably recur and I'll bookmark that bug just in case - thanks! |
14:05 |
* miker |
looks around for tuits to address that... |
14:06 |
* csharp |
reverted to "pure" PINES-ified 3.2-beta1 |
14:06 |
miker |
oh, I already did.. |
14:06 |
csharp |
heh |
14:10 |
gmcharlt |
berick and anybody else who reviewed the recent hold sorting patch - you might be interested in looking at the pull request for bug 1792429 |
14:10 |
pinesol |
Launchpad bug 1792429 in Evergreen "relative queue positions reversed" [High,New] https://launchpad.net/bugs/1792429 |
14:41 |
berick |
gmcharlt: thanks for the heads up |
14:53 |
|
khuckins joined #evergreen |
15:06 |
|
mmorgan1 joined #evergreen |
15:49 |
|
jvwoolf1 left #evergreen |
16:05 |
|
rlefaive joined #evergreen |
17:01 |
|
mmorgan joined #evergreen |
17:01 |
|
bdljohn joined #evergreen |
17:09 |
|
mmorgan left #evergreen |
17:16 |
|
jvwoolf joined #evergreen |
17:54 |
pinesol |
[evergreen|Galen Charlton] LP#1792429: calculate queue position in correct order - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=65f5afc> |
18:26 |
|
khuckins_ joined #evergreen |
21:02 |
|
akilsdonk joined #evergreen |
21:02 |
|
dkyle1 joined #evergreen |
21:02 |
|
phasefx_ joined #evergreen |
21:05 |
|
dbs joined #evergreen |
21:08 |
jeff |
between hurricanes and gas explosions, I hope all of you on the east coast are staying safe. |
23:02 |
|
csharp_ joined #evergreen |
23:02 |
|
miker joined #evergreen |
23:03 |
|
gmcharlt joined #evergreen |
23:03 |
|
cesardv joined #evergreen |
23:05 |
|
pinesol joined #evergreen |
23:16 |
|
agoben joined #evergreen |