| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:31 |
|
agoben joined #evergreen |
| 08:29 |
|
Callender joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 16:18 |
* pinesol_green |
grabs some Supreme Brownie Sundae for Dyrcona |
| 16:18 |
* Dyrcona |
studies up on PostgreSQL tuning, again. :) |
| 16:18 |
Dyrcona |
Looks like they took my pgtune away. |
| 16:20 |
Dyrcona |
I inherited a server with RAID already configured to use as a test/development db server. |
| 16:20 |
Dyrcona |
"RAID 5 is not a very good option for databases unless you have more than 6 disks in your volume." |
| 16:21 |
Dyrcona |
Fortunately, for me, the RAID 5 has 8 disks. :P |
| 16:22 |
Dyrcona |
I'm not expecting it to be blazing fast, anyway, but we'll need to replace the production database server sooner or later. |
| 16:50 |
jeff |
berick++ thanks! |
| 16:51 |
berick |
jeff++ right batch atcha. I think this is a much nicer approach. plus, we get to put a little Hatch icon in the browser -- makes it look official ;) |
| 16:52 |
berick |
now we just need some icon art |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:56 |
|
dcook joined #evergreen |
| 21:48 |
|
Stompro joined #evergreen |
| 00:00 |
* bshum |
didn't test the feature, but wonders idly how it aligns with the action_trigger_runner script and various timings |
| 00:00 |
bshum |
It seems to have a 5 min delay after the checkout, so I would expect it to take that long before it did anything, and also only happen when the actiontrigger runner script runs |
| 00:00 |
* bshum |
might have to play and learn how it's supposed to work :) |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 08:14 |
|
collum joined #evergreen |
| 08:22 |
|
kmlussier joined #evergreen |
| 09:44 |
jeff |
I'd be interested in hearing more details about the "client would suddenly behave like they were logged into a different workstation at a different branch" part. |
| 10:00 |
tsbere |
That almost sounds like either corruption of memcache's memory space or something isn't acting properly when things can't be returned |
| 10:05 |
jeff |
or a re-prompt for auth using au.home_ou instead of workstation ou, etc. |
| 10:34 |
miker |
Bmagic: where (and how many times) are you running memcache? |
| 10:35 |
miker |
kmlussier: I've tested rebasing the sprint4 branch against master ... it applies cleanly. do you have any desire to merge some of the webstaff bug fixes into the collab branch, and then merge the whole shebang into master soon-ish? |
| 10:36 |
pinesol_green |
[evergreen|Kyle Huckins] LP1537214 Staff Initials in Patron Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fbaa1d> |
| 10:38 |
kmlussier |
miker: I could test and merge what's there now. Did that last commit mess up your rebase? |
| 10:38 |
miker |
no, it didn't. it happened after my rebase test :) |
| 10:39 |
kmlussier |
OK, I'll take a look at it now then. I've already tested most of what's in the collab branch, so it shouldn't take too long. As long as I don't get distracted. |
| 10:40 |
miker |
I actually was thinking more about the outstanding LP pullrequests |
| 10:40 |
miker |
fwiw |
| 10:41 |
miker |
pulling those into the collab branch, and then shoving the lot into master |
| 10:48 |
Bmagic |
miker: memcache is running on a single machine with 4096 as the limit. 3 bricks. |
| 10:56 |
|
sandbergja joined #evergreen |
| 10:59 |
miker |
kmlussier: but either way is fine. we may just find we're fixing collab code instead of pullrequest code if there's conflict |
| 11:00 |
kmlussier |
miker: OK, I'm testing a couple of small things to possibly put in the collab branch before I look at the larger branch. |
| 11:01 |
miker |
kmlussier: one situation that might go the other way would be obviously backportable fixes ... |
| 11:04 |
kmlussier |
miker: Yeah, I haven't been backporting as much based on brief discussion with berick last week http://irc.evergreen-ils.org/evergreen/2016-11-16#i_276134 |
| 11:04 |
kmlussier |
It seemed best to focus efforts on trying to get web client code into 2.12 sooner. |
| 13:11 |
|
genpaku joined #evergreen |
| 13:38 |
|
bmills joined #evergreen |
| 13:38 |
|
terran joined #evergreen |
| 13:50 |
terran |
Hi gang - I'm trying to figure out how to enable Spanish on a 2.11.1 test server. I've updated eg_vhost.conf so the dropdown appears, but nothing happens when I try to use it - can someone push me in the right direction? |
| 13:51 |
bshum |
terran: Hi Terran! Spanish you say? Fascinating :) |
| 13:51 |
terran |
bshum: I saw you were working on that :) |
| 13:52 |
bshum |
terran: So when you say you have a dropdown for the language picker, what languages show up there? And you select and hit the change button and nothing? |
| 14:19 |
* berick |
has some rebasing to do |
| 14:19 |
bshum |
So maybe it's not copying over the locale files right during the install phase |
| 14:19 |
terran |
bshum: sure thing, I'll let you know what he says |
| 14:19 |
bshum |
terran++ # testing things |
| 14:19 |
* csharp |
appears just at that moment |
| 14:20 |
csharp |
oh - spanish, I see |
| 14:21 |
bshum |
To get things rolling, I think it should be as simple as "mkdir /openils/var/data/locale" and Then "cp /home/wherever/Evergreen-ILS-2.11.1/Open-ILS/src/data/locale/opac/es-ES.po /openils/var/data/locale/es-ES.po" |
| 16:31 |
JBoyer |
Happy Thanksgiving #evergreen! |
| 16:34 |
kmlussier |
Yes, Happy Thanksgiving all! |
| 16:34 |
mmorgan |
Happy Thanksgiving! |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 19:52 |
|
StomproJ joined #evergreen |
| 00:07 |
|
tsbere_ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 12:01 |
Dyrcona |
Yeah, that decode_utf8 is part of the problem. |
| 12:02 |
Bmagic |
so, blanket the whole thing, removing all calls to decode_utf8. got it |
| 12:05 |
Dyrcona |
I'd try that. You might find you need to put some back, but I don't know for sure. |
| 12:05 |
Dyrcona |
I've not tested SIP extensively on 16.04, but I suppose that I should. |
| 12:06 |
Dyrcona |
Trouble is, my day job has me doing other things, and I'm not that motivated to continue working on Evergreen in all of my free time. :) |
| 12:06 |
dbs |
Bmagic: I can tell you where we have clean_text for our many french users and items - although we're on ubuntu 14.04, there were clean_text() calls we had to add, not take away |
| 12:06 |
Bmagic |
Dyrcona++ |
| 12:09 |
dbs |
Dyrcona: yeah, I really don't know about Perl 5.20. |
| 12:09 |
Dyrcona |
Bmagic: It is worth looking into. |
| 12:09 |
Dyrcona |
Merging records is one thing that I know I did not do on 16.04. |
| 12:10 |
dbs |
is it clear that the same problem does not impact perl 5.18? https://bugs.launchpad.net/evergreen/+bug/1542495 mentions testing with 16.04 and Jessie, nothing about ubuntu 14.04 |
| 12:10 |
pinesol_green |
Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] - Assigned to Jason Stephenson (jstephenson) |
| 12:11 |
Bmagic |
well, I removed that single call to decode in Sip.pm and boom, it's working |
| 12:12 |
Bmagic |
All of the other modules have no mention of decode |
| 15:48 |
berick |
no worries |
| 16:11 |
|
bmills joined #evergreen |
| 16:43 |
berick |
@band add Hamburger Hatch |
| 16:43 |
pinesol_green |
berick: <shaggy>We're, like, doomed.</shaggy> |
| 16:44 |
|
mmorgan joined #evergreen |
| 16:45 |
|
afterl left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:39 |
|
bmills joined #evergreen |
| 17:57 |
|
bmills1 joined #evergreen |
| 20:04 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: documenting new authority features - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f0de98b> |
| 20:20 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1528916 Patron Holds Ready/Total - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8defb7f> |
| 20:44 |
|
bmills joined #evergreen |
| 21:30 |
pinesol_green |
[evergreen|Billy Horn] LP#1621799: disable checkout for inactive patrons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2652801> |
| 23:30 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Incorporating overlay/merge profiles documentation from Evergreen in Action + new 2.11 feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4c1146f> |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:58 |
|
kmlussier joined #evergreen |
| 05:58 |
kmlussier |
@coffee |
| 05:58 |
* pinesol_green |
brews and pours a cup of Kenya Mamuto, and sends it sliding down the bar to kmlussier |
| 12:36 |
pinesol_green |
Launchpad bug 1488655 in Evergreen 2.10 "Metarecords are not being maintained properly" [Medium,Confirmed] https://launchpad.net/bugs/1488655 |
| 12:36 |
gmcharlt |
csharp: thanks |
| 12:50 |
* csharp |
notices rhamby's comment on the bug indicating his signoff |
| 12:50 |
rhamby |
csharp: yeah, I tested it ... last week? time is blurring together into an endless wave of projects .... |
| 12:52 |
Dyrcona |
"Time keeps on slippin', slippin', slippin' into the future..." |
| 12:54 |
kmlussier |
That is not a song I want in my head. |
| 12:55 |
kmlussier |
Too late |
| 13:38 |
bshum |
Packager just contains all the stuff for asciidoc building and i18n |
| 13:38 |
kmlussier |
OK, thanks for confirming bshum! |
| 13:38 |
kmlussier |
bshum++ |
| 13:38 |
bshum |
I've been thinking about adding a new make target to split i18n away from packager too |
| 13:38 |
bshum |
So that I can install stuff more quickly to test that piece. |
| 13:38 |
|
sandbergja joined #evergreen |
| 13:41 |
Dyrcona |
I mentioned to bshum (yesterday? Monday?) that sounded fine to me as long as packager depended on the new i18n target. |
| 13:44 |
kmlussier |
Yay! The root user wasn't required for npm install this time. Progress. |
| 14:56 |
dbs |
best I could come up with was to add a Direct Charge on the invoice for the second part of the payment, with a note on the direct charge reflecting that it was a split payment |
| 14:57 |
dbs |
With a separate Funding Source -> Fund -> Invoice path for the second part of the payment to at least link the two funding sources through the invoice piece |
| 14:58 |
dbs |
(this is for big ticket items like databases or journal suites that often are shared costs between departments or separate institutions) |
| 14:59 |
pinesol_green |
[evergreen|Galen Charlton] LP#1488655: regression test for metarecord remapping - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31108a7> |
| 14:59 |
pinesol_green |
[evergreen|Galen Charlton] LP#1488655: fix MR remapping upon fingerprint change - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a27eaba> |
| 15:00 |
pinesol_green |
[evergreen|Galen Charlton] LP#1488655: stamp schema upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ab51669> |
| 15:07 |
pinesol_green |
[evergreen|Galen Charlton] updates to 2.11.1 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ab807aa> |
| 15:08 |
pinesol_green |
[evergreen|Galen Charlton] update 2.10.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=166aa9e> |
| 15:12 |
gmcharlt |
OK, after checking with miker, I'm declaring rel_2_10 and rel_2_11 "done" with respect to substantive changes for the 2.10.8 and 2.11.1 releases |
| 15:13 |
gmcharlt |
dbwells: I believe you're building the 2.11.1 tarball, right? |
| 15:13 |
dbwells |
gmcharlt: yes sir |
| 16:45 |
Dyrcona |
gmcharlt++ dbwells++ |
| 16:58 |
|
bmills joined #evergreen |
| 16:58 |
|
jvwoolf left #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:16 |
gmcharlt |
OK, post ready to go when 2.11.1 is |
| 17:36 |
dbwells |
gmcharlt: everything is in place, downloads page is updated |
| 01:42 |
|
gsams joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 08:20 |
|
collum joined #evergreen |
| 10:59 |
Bmagic |
another issue with 2.11 we are finding Uploading PO MARC throws an error |
| 10:59 |
Bmagic |
ERROR: new row for relation "lineitem" violates check constraint "picklist_or_po" |
| 10:59 |
Dyrcona |
I don't know of any where in the interface that we leak user ids via URL, which is what I had in mind. |
| 11:02 |
kmlussier |
Bmagic: Do you have any details on what options were selected when they were uploading the PO? |
| 11:03 |
* kmlussier |
can fire up a VM to test a PO upload. |
| 11:04 |
Bmagic |
acq.lineitem.create id= selector=201704 picklist= purchase_order= provider=18 create_time=now edit_time=now........ |
| 11:05 |
Bmagic |
shouldn't there be a purchase_order there? |
| 11:09 |
tsbere |
Bmagic: According to the DB it isn't required? |
| 11:51 |
csharp |
and works in Chrome for me too |
| 11:52 |
mmorgan |
Not sure if this might an example of bug 1546128 |
| 11:52 |
pinesol_green |
Launchpad bug 1546128 in Evergreen "eg.hatch.required not parsed correctly" [Undecided,New] https://launchpad.net/bugs/1546128 |
| 11:52 |
kmlussier |
mmorgan: I tested workstation registration the other day, but I can't recall if I tested FF. I would add a comment to the workstation registration bug. |
| 11:52 |
* kmlussier |
doesn't have the bug number at her fingertips. |
| 11:54 |
mmorgan |
This one? lp 1467663 |
| 11:54 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Fix committed] https://launchpad.net/bugs/1467663 |
| 11:54 |
csharp |
"Firefox can’t establish a connection to the server at wss://localhost:8443/hatch." |
| 12:02 |
csharp |
huh - it works for me now (even in private browsing) |
| 12:02 |
csharp |
I was using private browsing in an attempt to get around cache issues |
| 12:02 |
mmorgan |
kmlussier: No, not in private browsing mode. |
| 12:03 |
kmlussier |
mmorgan: Try clearing your cache and then re-test? |
| 12:03 |
|
krvmga joined #evergreen |
| 12:04 |
JBoyer |
Are you waiting long enough? I tried it out in my FF (49.something) private window, and it took a good while for the workstation dropdown to appear, but once it did I was able to signin using the new workstation I had just created. |
| 12:07 |
mmorgan |
JBoyer: Stared at it for a good long time, but didn't actually time it. Must've been at the login screen for at least a couple of minutes and the dropdown didn't show up. |
| 12:36 |
kmlussier |
Yeah, I think you all should take the keys to that account away from me and give them to somebody else who can better handle the responsibility. ;) |
| 12:37 |
csharp |
@intervention kmlussier |
| 12:37 |
pinesol_green |
csharp: Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP! |
| 13:33 |
Bmagic |
Importing marc acq records works bus the resulting line items in the purchase order do not link to the catalog. The import settings had a match profile and "import non-matching records" checked. All of the 8 records in my test do not match, but they are not imported. |
| 13:34 |
Bmagic |
I take that same file and use on batch import, and it works fine. |
| 13:39 |
kmlussier |
Bmagic: Has the order been activated yet? |
| 13:40 |
Bmagic |
no |
| 13:54 |
Bmagic |
I think I'm onto something |
| 14:08 |
kmlussier |
Bmagic: As I mentioned earlier, when I load records, I'm getting a hanging progress bar, but the PO is created with lineitems. In my case, the lineitems are not linked to the catalog either. |
| 14:09 |
Bmagic |
ah, interesting |
| 14:09 |
kmlussier |
I saw the same behavior on master and on the community demo server, which I loaded with the 2.10 release branch yesterday, so it's pretty much 2.10.7 with a few additional branches that have recently been merged. |
| 14:10 |
kmlussier |
However, when testing on a 2.10.5 server, the upload performed as expected. The non-matching records were imported. |
| 14:18 |
kmlussier |
I get an error message that says: Caught error from 'run' method: Can't locate object method "max_chunk_count" via package "OpenSRF::AppRequest" at /usr/local/share/perl/5.18.2/OpenILS/Application/Vandelay.pm line 904. |
| 14:19 |
Bmagic |
hmmm, different |
| 14:20 |
Bmagic |
we are on 16.04 which is why we installed OpenSRF from master |
| 14:20 |
Bmagic |
which could* be playing a role in this |
| 14:21 |
dbwells |
Bmagic: looking that above errors, sounds like a good guess to me |
| 14:21 |
Bmagic |
dbwells: I'm running through installation on another server to test it against 2.4.1 tarball |
| 14:21 |
kmlussier |
tsbere could confirm, but I'm guessing my VMs are installing OpenSRF from master too. |
| 14:34 |
|
collum joined #evergreen |
| 14:34 |
dbwells |
kmlussier: looks like "chunking" was renamed to "bundling" in 01f95834835bed94 in OpenSRF. It seems like references to "max_chunk_count" in Vandelay may need to move to "max_bundle_count" to work with OpenSRF master. |
| 14:37 |
Bmagic |
so, now, is there anyone here running OpenSRF 2.4.1 on Ubuntu 16.04? |
| 14:37 |
dbwells |
Bmagic: just a hunch, but I see that alt_holds_print.js references "chunk_size", so maybe new OpenSRF was the cause of that issue as well? |
| 14:37 |
Bmagic |
it sure could be! |
| 14:38 |
Bmagic |
Which explains why it was working on my test machine and not on production |
| 14:38 |
Bmagic |
my test machine was Ubuntu 14.04 and therefore it could run 2.4.1, so I didnt have a need to run OpenSRF master |
| 14:38 |
kmlussier |
dbwells++ # Good sleuthing! |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:20 |
|
bmills joined #evergreen |
| 16:49 |
tsbere |
Stompro: In non-reporter queries I tend to string_agg them together, just so you know. |
| 16:50 |
* tsbere |
doesn't usually use the flat view though, as there shouldn't ever be uncontrolled versions of composites |
| 16:53 |
|
BigRig joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
kmlussier |
Huzzah! |
| 17:05 |
|
mmorgan left #evergreen |
| 17:51 |
Bmagic |
Stompro: select string_agg(value,$$,$$) from metabib.record_attr_flat where attr=$$icon_format$$ and id=$bibid |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 07:21 |
|
Callender joined #evergreen |
| 10:52 |
Dyrcona |
Maybe the user's work_ou is not set properly? |
| 10:52 |
Bmagic |
hmmm |
| 10:52 |
* Dyrcona |
just speculates. I don't know that part of the staff client. |
| 10:53 |
Bmagic |
It's happening everywhere, all branches. Im digging. It's working on my test server.... |
| 10:55 |
Dyrcona |
Hmm. Maybe changes for the browser staff client or something happened during the upgrade? |
| 10:56 |
Bmagic |
alt_holds_print.js are identical |
| 10:57 |
Dyrcona |
Well, that's the end of my speculations. |
| 11:06 |
Bmagic |
how about this |
| 11:06 |
Bmagic |
File does not exist: /openils/var/web/js/dojo/fieldmapper/OrgLasso.js |
| 11:07 |
Dyrcona |
That might be it. |
| 11:08 |
Bmagic |
hmm, well that file is missing on the test server too |
| 11:19 |
kmlussier |
Bmagic: I don't know if this is what your users are seeing, but I just tried to use the alternate strategy on a VM with master. I just get a progress bar that hangs, and no titles load. |
| 11:19 |
Bmagic |
that is what we are seeing |
| 11:19 |
Bmagic |
however, my test machine with the exact same data has no issues..... |
| 11:20 |
kmlussier |
There was one test in which 10 of the 41 titles did load successfully, but the progress bar hung after that. |
| 11:20 |
Bmagic |
Obviously, my test machine has a different set of code on it, I'm digging to find the differences |
| 11:21 |
kmlussier |
If you end up filing a bug, I can confirm it. I'm not sure where you saw that error, so I don't know if we get the same error. |
| 11:22 |
|
Christineb joined #evergreen |
| 11:23 |
Bmagic |
kmlussier: thanks |
| 11:28 |
Bmagic |
ok, my test server used rel_2_11 and the production machine used tags/rel_2_11_0 |
| 11:41 |
csharp |
Bmagic: my 2.11.0 test server just pops up with an alert that says "No Results" |
| 11:42 |
Bmagic |
csharp: yeah, you need to have at least one item on the pull list |
| 11:43 |
csharp |
trying a branch with items |
| 11:45 |
csharp |
Bmagic: yep - same behavior - same errors in the osrfwarn.log |
| 11:48 |
csharp |
2.11.0 |
| 11:48 |
csharp |
(the tarball release) |
| 11:55 |
Bmagic |
I see |
| 11:56 |
Bmagic |
Somehow it's not broken on my test machine. But I will report the bug on launchpad after this conference call |
| 12:04 |
csharp |
Bmagic: here's the call I see: open-ils.circ open-ils.circ.hold_pull_list.print.stream "<authtoken>", {"org_id":null,"limit":null,"offset":null,"chunk_size":null,"sort":["acplo.position","prefix","call_number","suffix","request_time"]} |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:04 |
csharp |
"org_id":null seems to be the relevant part |
| 15:43 |
dbs |
Bmagic++ |
| 15:57 |
|
RBecker joined #evergreen |
| 16:57 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:05 |
phasefx |
incidentally, I tried to build a clean wheezy install I could run an actual report on (to test the last fix for the failure above), and ran into different issues with libdbi (where the debian-jessie way of doing it should work). Will still revisit |
| 20:33 |
|
makohund joined #evergreen |
| 20:56 |
|
hbrennan joined #evergreen |
| 21:00 |
|
makohund left #evergreen |
| 04:54 |
|
finnx joined #evergreen |
| 04:55 |
|
finnx joined #evergreen |
| 04:58 |
|
finnx joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 08:48 |
|
bos20k joined #evergreen |
| 09:38 |
|
_adb joined #evergreen |
| 09:51 |
|
maryj joined #evergreen |
| 13:37 |
bshum |
So you don't have much time to get off it either. |
| 13:38 |
bshum |
14.04 is conservatively best choice, just cause I don't think anyone is using 16.04 in production. But I am out of touch lately. |
| 13:39 |
hbrennan |
yeah systemd in 16.04 is my hold up on production there |
| 13:39 |
bshum |
Fair enough, I only helped to test the installation procedures for 16.04; I haven't used it :) |
| 13:40 |
bshum |
at least not outside playtesting and developments |
| 13:41 |
hbrennan |
okay holly is sounding fine with feature upgrades in 2.10 train so that's the plan 2.10.7 and hit another maintinace window in Jan/Feb |
| 13:41 |
bshum |
For the conservatives, let's say Debian is your best bet. If you're a little more edgy, go with Ubuntu. And if you're crazy like dbs or csharp, there's always Fedora. |
| 13:41 |
hbrennan |
fedora isn't around long enough for production |
| 16:59 |
csharp |
ah |
| 17:00 |
csharp |
yeah - it was kindof a brittle one-off that I didn't think much about forward porting |
| 17:00 |
csharp |
probably worth grabbing a ruby version string somehow so that won't break |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
csharp |
pinesol_green: no, you're the failure |
| 17:01 |
pinesol_green |
csharp: have you tried local mean solar time for the named city as the reference point? |
| 17:01 |
pinesol_green |
csharp: I am only a bot, please don't think I'm intelligent :) |
| 00:49 |
|
Christineb joined #evergreen |
| 03:11 |
|
Mark__T joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:43 |
|
kmlussier joined #evergreen |
| 07:14 |
|
dcook__ joined #evergreen |
| 09:15 |
dbs |
runtime or compile-time error? |
| 09:16 |
dbs |
I dunno. another meeting to prep for :( |
| 09:16 |
Dyrcona |
dbs: The assignment does happen in an eval block, but the if is outside the eval block, so if it was undefined outside of the eval, the if should still trigger. |
| 09:19 |
dbs |
maybe the "or not $filename" normally never gets tested because the error condition occurs and so evaluation of the if condition stops at $@ |
| 09:20 |
dbs |
and maybe now you're seeing a case where the return value is undefined, without an error occurring. |
| 09:20 |
dbs |
that _almost_ makes sense but then the "or not" should catch it! hah |
| 09:21 |
* dbs |
really goes into meeting prep mode |
| 09:22 |
Dyrcona |
dbs: I've tried replicating it with a smaller script, and I can't. |
| 09:22 |
Dyrcona |
Even running it on the server that runs edi_fetcher to use the same version of Perl. |
| 09:32 |
Dyrcona |
Oh, nice. This server is losing messages in rsyslog by the hundreds, so no wonder I can find neither success nor failure messages in the logs. |
| 16:58 |
jeff |
also, a bug can "affect" multiple projects. |
| 17:00 |
Dyrcona |
csharp: I think the supports section is actually used. |
| 17:01 |
Dyrcona |
I'd have to look at the code again to be sure. |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:02 |
jeff |
supports and policy are different things. |
| 17:02 |
csharp |
well, either way, I indicated to the library that it's not supported and they'll just need to take them out of service when the connections aren't working (a separate issue on their end they are trying to resolve) |
| 17:03 |
* csharp |
once again broadcasts his wish to the universe that libraries would consult with us before purchasing things and expecting them to work based on sales pitches |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
JBoyer joined #evergreen |
| 08:06 |
|
collum joined #evergreen |
| 16:04 |
jeff |
Consult your /opensrf/default/email_notify/smtp_server config setting on the OpenSRF host(s) in question, go from there. |
| 16:04 |
jeff |
If it's localhost, MTA may be eating / queueing the mail. If it's non-localhost, you might be getting firewalled or rejected (relaying denied, whatever) -- you'd likely be seeing those rejects in your logs, so firewall/routing is more likely? |
| 16:04 |
Dyrcona |
jeff: That's the same. When we switched to GMail, I don't think I configured the drones to use a smarthost. |
| 16:05 |
Dyrcona |
I found that the test I tried to send myself was handled on drone 2 of brick 2. |
| 16:06 |
Dyrcona |
I'll check mail logs there. |
| 16:08 |
jeff |
Also, info/warn opensrf logs containing "SendEmail Reactor" |
| 16:11 |
Dyrcona |
jeff: That latter gives me what I expect: a number of entries from the drones saying that they can't send email. |
| 16:25 |
Dyrcona |
Well, I still need to configure the smarthost on the drones. :) |
| 16:36 |
Dyrcona |
So, slightly different plan: I'll configure the server that sends the action trigger emails to relay for the local IPs, and then configure the drones to use that server as a smarthost. |
| 16:36 |
Dyrcona |
That cuts down on extra configuration to keep track of. This is, after all, being done in "the Debian way." |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:13 |
bmills |
anyone had luck with getting autosuggest to stop crashing on search terms beginning with punctuation? or could point me in the right direction? |
| 17:14 |
bmills |
thinking along the lines of lp 1161095 |
| 00:19 |
|
Bmagic joined #evergreen |
| 01:40 |
|
dteston joined #evergreen |
| 02:16 |
|
jihpringle joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:45 |
|
collum joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:09 |
gmcharlt |
I've made a couple config changes to the wiki that may be of interest |
| 09:30 |
|
mmorgan1 joined #evergreen |
| 09:31 |
rhamby |
kmlussier: I vaguely remember doing that once I read it so ... sure |
| 09:31 |
kmlussier |
rhamby: OK, thanks! |
| 09:31 |
rhamby |
kmlussier: I wouldn't think anything between now and then in the staff client would have broken it so test away |
| 09:33 |
kmlussier |
rhamby: I'll give jsandberg a chance to test it first, but will keep it on my radar if she doesn't have a chance to test it. |
| 09:33 |
gmcharlt |
jeff: https://wiki.evergreen-ils.org/doku.php?id=archive:start |
| 09:33 |
Dyrcona |
I wanted that at one point recently. |
| 09:34 |
gmcharlt |
tsbere: and yeah, you're probably right, but I'm hoping it will encourage people to get rid of outdated content, as a provides a way to ensure that it's not *forever* |
| 09:41 |
jeff |
and of course there's always a quick journey to the files-on-disk on request/need. |
| 09:51 |
|
jvwoolf joined #evergreen |
| 09:54 |
|
dteston joined #evergreen |
| 10:10 |
Dyrcona |
csharp++ # Fixing my busted tests. |
| 10:11 |
Dyrcona |
Should that be backported to 2.11? |
| 10:12 |
dbs |
gmcharlt++ |
| 10:12 |
|
yboston joined #evergreen |
| 10:20 |
|
Christineb joined #evergreen |
| 10:28 |
kmlussier |
csharp++ Dyrcona++ |
| 10:28 |
pinesol_green |
[evergreen|Chris Sharp] Fix purge_user_activity.pg live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c62be18> |
| 10:28 |
pinesol_green |
[evergreen|Chris Sharp] LP#1640153 Fix abort-transit-copy-status.t perl test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2057458> |
| 10:29 |
csharp |
now once I can get testing.evergreen-ils.org credentials for the new builder servers on mundungus, we can resume testing on multiple OS platforms/releases |
| 10:30 |
Dyrcona |
Well, I figured tests would be easy to test. :) |
| 10:32 |
* kmlussier |
just noticed new acq menu on webby. Hooray! |
| 10:33 |
|
sandbergja joined #evergreen |
| 10:34 |
Bmagic |
You all are making Evergreen great.... again |
| 11:12 |
kmlussier |
What do we do with bugs like bug 1467663, where the code is now incorporated in the sprint4 collab branch? Is it okay to merge berick's branch, in which case I assume it should be taken out of the collab branch? Or has past practice been that we wait until the full collab branch is merged? |
| 11:12 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Confirmed] https://launchpad.net/bugs/1467663 |
| 11:15 |
jeff |
kmlussier: i have similar questions also. |
| 11:21 |
kmlussier |
My inclination is to merge berick's branch sooner, because the original issue reported in the bug can be a big PITA for people testing/working on the web client if they use a test system where the database is constantly reloaded. |
| 11:22 |
berick |
kmlussier: i don't imagine there would be any opposition to merging to master. I find this bug to be a real PITA as well. |
| 11:26 |
gmcharlt |
kmlussier: and from the POV of the folks maintaining the collab branch, it doesn't cause any significant problems patches are picked from it sooner |
| 11:26 |
gmcharlt |
although it would be handy if any additions or changes to such patches existed as separate patches |
| 11:27 |
kmlussier |
berick / gmcharlt: Ok, thanks! I want to test it outside of webby before merging. I'll try to make time to do so today. |
| 11:40 |
|
brahmina joined #evergreen |
| 11:41 |
berick |
kmlussier++ gmcharlt++ |
| 11:59 |
|
jihpringle joined #evergreen |
| 16:53 |
Bmagic |
crazy |
| 16:54 |
Bmagic |
It's showing it's face now because I have left memcached off on the app servers now |
| 16:57 |
Bmagic |
jeff++ Dyrcona++ |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:02 |
jeff |
okay, the "report on circ counts for copies attached to titles in a shared bucket with a specially prefixed name" report works well. |
| 17:04 |
|
mmorgan left #evergreen |
| 17:08 |
|
bmills joined #evergreen |
| 04:50 |
|
lualaba joined #evergreen |
| 04:50 |
lualaba |
hello. i am not able to delete row delete from asset.copy_location where id = 113 please help |
| 04:59 |
lualaba |
select * from asset.copy where location = 113 (zero result) |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:02 |
lualaba |
i need just remove from asset.copy_location one record (deleted = 't') but anyway i see in web staff client record |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
JBoyer joined #evergreen |
| 11:52 |
berick |
dteston: the MD5 hashing occurs at a layer above the password storage. it's only used for communicating with the authentication API. at the storage/db layer, there is no md5, with the 1 exception of the password migration function. |
| 11:53 |
berick |
well, that and existing passwords are derived from the old md5 hashed passwords |
| 11:53 |
Stompro |
Is it ok for multiple ts_config metabib classes to have the same index_weight? It looks like title, english_nostop will share the same weight as the new synonym ts_config I created. |
| 11:56 |
kmlussier |
Stompro: I don't think that would be a problem. |
| 12:07 |
* kmlussier |
did a quick test and can confirm that the synonym should show up in the index_vector. |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:15 |
|
mmorgan joined #evergreen |
| 12:33 |
mmorgan |
Stompro: We tried to add "&" and "and" to the synonym list also, but were not successful with that particular entry either. |
| 13:27 |
lualaba |
let me check |
| 13:27 |
JBoyer |
I haven't used the web client to check on some of those things, I'm not certain the version I'm on (2.9) would be helpful to check against. :( |
| 13:29 |
lualaba |
oho cache clean help for org_unit, but old shelving locations is still there |
| 13:29 |
JBoyer |
lualaba, is this a production system or testing? I wonder if restarting the memcache server might help, but that would be a bad idea on a production server in the middle of the day. |
| 13:29 |
lualaba |
production |
| 13:30 |
lualaba |
i already restart memchached |
| 13:33 |
JBoyer |
I see. I don't have enough experience troubleshooting the web client to be much help, sorry about that. |
| 13:33 |
lualaba |
now i have problem with shelvin locations (in asset.copy_location delated = 't') but anyway i see on web |
| 13:33 |
lualaba |
Thank you JBoyer |
| 13:39 |
kmlussier |
I don't know. I just went on to webby and deleted a copy location, which should set the asset.copy_location deleted flag to true. It immediately disappeared without a refresh. |
| 13:40 |
kmlussier |
The admin interfaces were still fairly new in 2.10. Maybe it's not the best release to test this interface in. |
| 13:40 |
lualaba |
possible to remove totaly copy location without change flag? |
| 13:41 |
lualaba |
delete from asset.copy_location where id =113, but this just change this flag |
| 13:43 |
lualaba |
affected row = 0 |
| 16:35 |
|
jvwoolf left #evergreen |
| 16:35 |
|
jvwoolf joined #evergreen |
| 16:48 |
JBoyer |
For jeff and the logs: Dyrcona is right, I meant we have to use Java Hatch on Windows at first because I can't get anything else done in time for 2.12 and possibly 3.0. It's something I want to see done but don't yet have a time line on. (work piles up around me like flakes of snow, but less flurry than blizzard. :( ) |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan left #evergreen |
| 18:05 |
csharp |
looks like the Open-ILS/src/sql/Pg/live_t/purge-user-activity.pg test doesn't account for the actor.usr_activity_transient_trg trigger on actor.usr_activity, which deletes a row of the same activity type if transient without checking whether the time is newer or not |
| 18:15 |
berick |
tfw you realized you launched irssi w/o screen |
| 18:15 |
|
berick joined #evergreen |
| 18:16 |
berick |
quickly remedied |
| 18:56 |
csharp |
hmm - so if I want to fix a test, does that warrant a bug report? feels kinda meta |
| 19:13 |
csharp |
b1f4d599 |
| 19:13 |
pinesol_green |
csharp: [evergreen|Bill Erickson] LP#1570909 User activity transient default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b1f4d59> |
| 20:00 |
|
dteston joined #evergreen |
| 20:39 |
|
abowling left #evergreen |
| 02:16 |
|
dcook joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:58 |
|
dbwells joined #evergreen |
| 06:45 |
|
wsmoak joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:46 |
|
bos20k joined #evergreen |
| 08:57 |
gmcharlt |
here are a couple pullrequests of mine if somebody is looking for something to test |
| 08:57 |
gmcharlt |
bug 1528901 |
| 08:57 |
pinesol_green |
Launchpad bug 1528901 in Evergreen "biblio fingerprint should distinguish between elements contributing to the fingerprint" [Medium,Confirmed] https://launchpad.net/bugs/1528901 - Assigned to Galen Charlton (gmc) |
| 08:57 |
gmcharlt |
and related, bug 1488655 |
| 08:57 |
pinesol_green |
Launchpad bug 1488655 in Evergreen 2.10 "Metarecords are not being maintained properly" [Medium,Confirmed] https://launchpad.net/bugs/1488655 |
| 09:11 |
|
JBoyer joined #evergreen |
| 09:13 |
|
JBoyer joined #evergreen |
| 09:15 |
|
abowling1 joined #evergreen |
| 09:19 |
chreeus |
Bmagic: ./edi_order_pusher.pl --test-mode --po-id 227 > brodart_new.edi # sample invocation |
| 09:20 |
|
yboston joined #evergreen |
| 09:23 |
Bmagic |
csharp: thanks |
| 09:50 |
berickm |
Bmagic: select * from acq.lineitem_attr where lineitem = ID and attr_type = 'pagination' |
| 10:05 |
pinesol_green |
[evergreen|Christine Morgan] LP 1628966: View Temporary/My Lists from Record Summary - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad0f60a> |
| 10:33 |
* phasefx |
is going to point the live tester temporarily to user/dyrcona/lp1639250-wheezy-excel-writer-xlsx-from-deb |
| 10:37 |
berickm |
csharp: https://gist.github.com/berick/5f791a64bf56ea5b50940761f71aee29 |
| 10:38 |
Dyrcona |
phasefx: Cool! I am setting up a new wheezy vm to test it manually. |
| 10:50 |
|
mmorgan1 joined #evergreen |
| 11:05 |
gmcharlt |
bshum: miker: user/gmcharlt/lp1612771_fix_chunking_for_atomic_c for OpenSRF for your consideration |
| 11:13 |
rhamby |
gmcharlt: I tested the fingerprinting patch and it's related one and putting in signoffs for both |
| 11:15 |
gmcharlt |
rhamby++ |
| 11:19 |
miker |
gmcharlt: that looks eminently sane, sir |
| 11:25 |
gmcharlt |
heh - that just made me think that there really needs to be a sequel to this book: https://www.gutenberg.org/ebooks/2447 |
| 11:39 |
|
jvwoolf joined #evergreen |
| 11:43 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 12:10 |
bshum |
gmcharlt: reinstalled with that patch and it is much better indeed |
| 12:11 |
bshum |
I'll get it signed later this evening or so unless someone beats me to it, but looks good to me. |
| 12:13 |
gmcharlt |
bshum: great, thanks for testing |
| 12:13 |
gmcharlt |
miker is also doing a final sanity check - mind if he adds your signoff? |
| 12:13 |
bshum |
Not at all, glad to help along |
| 12:13 |
bshum |
gmcharlt++ miker++ |
| 12:14 |
miker |
bshum: i'll name my signoff branch here for you ... will be just a few minutes if all goes well |
| 14:57 |
mmorgan |
hackers++ |
| 16:36 |
|
brahmina joined #evergreen |
| 16:59 |
|
mmorgan left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:18 |
|
gsams_ joined #evergreen |
| 09:17 |
bshum |
So, with https://bugs.launchpad.net/opensrf/+bug/1612771, gmcharlt removed the max_stanza_size change for ejabberd, but without changing it upwards, I'm getting jabber errors like "XML stanza size too big" and things like doing the srfsh login is slow to respond. Searches, haha. |
| 09:17 |
pinesol_green |
Launchpad bug 1612771 in OpenSRF "Chunking and bundling" [Wishlist,Fix committed] |
| 09:18 |
tsbere |
I will admit to having been surprised at that change |
| 09:18 |
bshum |
Not sure if anyone else has tested OpenSRF master since those things got added |
| 09:18 |
bshum |
But just tossing out a little feedback |
| 09:18 |
bshum |
Now that I finally have a functional VM built. |
| 09:18 |
tsbere |
bshum: Was there a corresponding EG change you need as well? |
| 09:19 |
bshum |
tsbere: That's something I'm wondering too, I didn't see one yet |
| 09:20 |
|
JBoyer joined #evergreen |
| 10:10 |
bshum |
tsbere: So it does eventually respond with success for the srfsh login. But TPAC searches almost always time out :( |
| 10:10 |
bshum |
I guess things get too congested |
| 10:10 |
gmcharlt |
bshum: yep, I'll look into it |
| 10:10 |
bshum |
And it times out waiting for the chunked messages to come across |
| 10:11 |
bshum |
gmcharlt: Happy to help test things out. I'm going to bump things up for now and go back to playing with i18n areas |
| 10:13 |
kmlussier |
phasefx++ # Looking into live tester rss feed |
| 10:14 |
phasefx |
going to try switching from RSS to Atom, mimic what Launchpad does |
| 10:25 |
pinesol_green |
News from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live#abcdef> |
| 10:25 |
bshum |
Dun, dun, dun |
| 10:25 |
bshum |
phasefx++ |
| 10:25 |
phasefx |
not there yet, that was by hand |
| 11:24 |
csharp |
berick's bug: https://bugs.launchpad.net/evergreen/+bug/1554714 |
| 11:24 |
pinesol_green |
Launchpad bug 1554714 in Evergreen "Migrate Browser Client to Angular 1.5 + Dependencies" [Medium,Fix committed] |
| 11:25 |
bshum |
fwiw, the client built fine for me with angular 1.5.8 last night :) |
| 11:26 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 11:37 |
Bmagic |
miker: 1638921 |
| 11:44 |
|
Dyrcona joined #evergreen |
| 11:48 |
berickm |
csharp: https://www.unece.org/trade/untdid/d00a/tred/tred6063.htm |
| 12:00 |
|
brahmina joined #evergreen |
| 12:06 |
|
kmlussier joined #evergreen |
| 12:14 |
|
alynn26 joined #evergreen |
| 12:26 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 12:43 |
|
jihpringle joined #evergreen |
| 13:00 |
gmcharlt |
bshum: figured out issue is with sending responses from atomic methods -- working up a patch |
| 13:04 |
|
jvwoolf joined #evergreen |
