| 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 |
| 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 |
| 11:55 |
|
bmills joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:40 |
|
DPearl joined #evergreen |
| 14:10 |
jeffdavis |
I'm thinking about live tests for bug 1541559 |
| 14:11 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] https://launchpad.net/bugs/1541559 - Assigned to Jeff Davis (jdavis-sitka) |
| 14:11 |
jeffdavis |
The module is modeled after AddedContent, so there is a main EbookAPI module and separate handler sub-modules for the different vendor APIs (OneClickdigital, OverDrive) |
| 14:13 |
jeffdavis |
I don't think we can hard-code any tests that actually talk to those APIs, so I am thinking of having a "Test" handler that doesn't do any HTTP lookups, just responds correctly to the various ways that the main module can use a handler sub-module. It could also serve as a kind of reference implementation for future handlers. |
| 14:13 |
jeffdavis |
Does that make sense, or is it overkill? |
| 14:16 |
jeffdavis |
"HTTP lookup" is not the right way to put that, hope my technical solecisms don't confuse things too much :) |
| 14:21 |
phasefx |
jeffdavis: you could mockup a web server using expect |
| 14:21 |
phasefx |
and point to localhost and some port instead of an actual third-party host for the config |
| 14:22 |
phasefx |
well, if not using SSL, that is |
| 14:27 |
jeffdavis |
Is that what we want to do for automated testing? |
| 14:28 |
phasefx |
:-/ |
| 14:29 |
jeffdavis |
sorry, afaik we aren't doing anything like that so far, and I don't know enough about tests to know if I'm stepping into a minefield that way |
| 14:29 |
phasefx |
might be easier but more brittle |
| 14:29 |
tsbere |
I think the "Test" module is a good idea, overall, for testing things that would call out to third parties. Though setting up a general test service somewhere that said module could poke at might work too. |
| 14:29 |
tsbere |
At least you get better coverage of some of the code paths with the test module, right? |
| 14:31 |
phasefx |
you tie the test to the implementation with a module, but that's probably okay. But if you ever want to reimpliment, a black box test service could be useful |
| 14:34 |
jeffdavis |
This would have been a good thing to ask about if I were going to the hackaway :) |
| 14:35 |
* phasefx |
had never been in the habit of writing tests when he was more active with coding, so this is all thought exercise for him. "Grain of salt also advised :) |
| 14:38 |
jeffdavis |
all advice and suggestions are appreciated :) |
| 14:53 |
|
gsams_ joined #evergreen |
| 14:55 |
|
gsams joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:40 |
|
remingtron joined #evergreen |
| 08:53 |
Dyrcona |
Hmm... Looks like I used Evergreen backend calls in my Safari record load program. (A propos yesterday's conversation about Overdrive record loading.) |
| 08:57 |
Dyrcona |
One bonus of using DBI or SQL with these loads is it usually easier to point it at a test database/environment. You don't have to setup a full-blown Evergreen installation to test it. |
| 08:57 |
* Dyrcona |
goes back to working on his EBL load. |
| 09:24 |
|
yboston joined #evergreen |
| 09:31 |
jeff |
i'm a fan of making "you don't have to setup a full-blown Evergreen installation to test" sound silly. |
| 09:32 |
|
jvwoolf1 joined #evergreen |
| 09:32 |
jeff |
almost (but perhaps not quite) how git changed how many people from cvs or svn days thought about branches. |
| 09:33 |
jeff |
nobody says "but then i'd have to create a branch, and i don't want to go through that hassle" anymore. |
| 09:34 |
jeff |
(perhaps they never used those exact words -- i'm exaggerating a little bit to try and make this analogy work!) |
| 09:34 |
tsbere |
jeff: I say that on a regular basis! Mainly due to being lazy about making more generic versions of my MVLC-specific solutions. ;) |
| 09:35 |
Dyrcona |
Well, once I started scripting vm creation, I didn't worry so much about setting up a full blown installation to test. :) |
| 09:36 |
|
bos20k joined #evergreen |
| 09:36 |
Dyrcona |
Still, it's nice sometimes to just run a script and change a host name or database name command line option rather than worrying so much about where you are running it. |
| 09:37 |
jeff |
yes. |
| 11:55 |
Dyrcona |
dans-datalogics: Sometimes, just quitting the client and starting it over again fixes that. |
| 11:55 |
|
Callender joined #evergreen |
| 11:55 |
dans-datalogics |
i'm also still a bit worried by the fact that almost all 2 GB of RAM on the server is taken. |
| 11:56 |
Dyrcona |
dans-datalogics: Yeah, 2GB is a bit slim, I prefer 4GB as a minimum or concerto data and 6-8 GB if I'm using production data on a test vm. |
| 11:57 |
dans-datalogics |
Dyrcona: ah, well i can bump it up to 4 then. the system requirements said only 1 GB was needed, so i figured 2 was safe. |
| 11:57 |
dans-datalogics |
also, restarting the client is now giving me a failed status check. i might chalk that up to the memory issue. |
| 11:57 |
Dyrcona |
dans-datalogics: Where are these system requirements? They should be changed, I think. |
| 11:58 |
|
brahmina joined #evergreen |
| 11:58 |
dans-datalogics |
http://docs.evergreen-ils.org/dev/_system_requirements.html |
| 11:58 |
|
Christineb joined #evergreen |
| 11:59 |
bshum |
Change is good. |
| 11:59 |
bshum |
Change is very good. |
| 12:00 |
|
barbara joined #evergreen |
| 12:03 |
* bshum |
feels like 4 GB of RAM is a good "test server" these days |
| 12:03 |
bshum |
And hey, probably at least 2 GB or more of RAM for a client workstation too. 512 MB? No...... |
| 12:04 |
* bshum |
drops the line for "XP, Vista, or 7" |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:08 |
bshum |
Doc change pushed to master and backported to rel_2_11 and rel_2_10 (as the two most recent versions) |
| 12:09 |
bshum |
dans-datalogics++ # thanks for the pointer |
| 12:10 |
pinesol_green |
[evergreen|Ben Shum] Docs: Update base system requirements for Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b92116> |
| 12:17 |
bshum |
Maybe 2 GB is too conservative and I should have changed that to 4 GB too for clients. |
| 12:18 |
bshum |
https://wiki.evergreen-ils.org/doku.php?id=system_requirements is ancient too |
| 08:40 |
pinesol_green |
csharp: As great as you are man, you'll never be greater than yourself. |
| 08:42 |
gmcharlt |
quick heads up - part or all of Dyn.com's DNS services are experiencing a DDoS |
| 08:43 |
gmcharlt |
and this might effect resolution of evergreen-ils.org -- will be curious to know whether anybody is experiencing difficulties there |
| 08:43 |
tsbere |
gmcharlt: Quick test tells me that yes, I am experiencing difficulties there |
| 08:44 |
jeff |
resolves immediately for me. |
| 08:45 |
tsbere |
I don't think anyone here has requested the domain for a few days, thus making it so that our DNS server's cached entries expired |
| 08:45 |
jeff |
also immediate nxdomain as appropriate when requesting a non-existant host within the domain. |
| 08:49 |
|
bos20k joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:10 |
Dyrcona |
So, SIPServer question.... With Socket::Linux installed, it looks like SIPServer gets a 2 minute timeout on idle TCP connections? |
| 09:12 |
jeff |
I can look and test, but: is there an additional question lurking in the shadows? |
| 09:14 |
tsbere |
Dyrcona: I think it might also depend on timeout values in the SIP config, but without knowing why you are asking... |
| 09:15 |
jeff |
Dyrcona: if you're basing the question off of the setsockopt() call that sets TCP_KEEPIDLE to 120 -- that's (i did have to look it up) " The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket." |
| 09:15 |
Dyrcona |
jeff | tsbere: I think I misunderstood the TCP_KEEPIDL option. I now think that corresponds to tcp_keepalive_time, yes? |
| 09:59 |
tsbere |
Dyrcona: At that point I would be tempted to just add to the config file. Or make a local customization. |
| 09:59 |
gmcharlt |
Dyn is saying that they've mitigated the DDoS, by th eway |
| 10:00 |
Dyrcona |
Well, the quick thing is to make a local customization. New config options would be the way to go for a working/enhancement branch. |
| 10:00 |
tsbere |
gmcharlt: And, testing again, I can load things now. So yay! |
| 10:01 |
* Dyrcona |
wonders if the DDOS had to do with the SASL authentication failures... |
| 10:01 |
Dyrcona |
Or is that not to do with Freenode this time? |
| 10:02 |
tsbere |
DNS DDOS was causing issues with evergreen-ils.org for some percentage of the internet |
| 11:15 |
|
cgreen joined #evergreen |
| 11:21 |
|
dans-datalogics joined #evergreen |
| 11:30 |
|
jvwoolf joined #evergreen |
| 11:36 |
cgreen |
Hello, all -- we have an Ubuntu server running Evergreen and the database, and it's lately been acting flaky when one tries to log in or connect to Evergreen. "Re-test[ing] the server" on the web client sometimes takes ages to successfully verify; other times, the server returns a 500 Internal Server Error. We have noticed that it tends to use up quite a bit of memory on our server, even though we have met or exceeded the recommend |
| 11:36 |
cgreen |
It was working well for a week or so. Is there a configuration we may have incorrectly set? Any insight is appreciated, and thank you! |
| 11:37 |
|
Christineb joined #evergreen |
| 11:40 |
miker |
berick: for human use, it works close to that. it drops you into the authority list as close to the bib value as possible. your example should be usable. but, you're talking about machine matching, aren't you :) |
| 11:41 |
miker |
(and not blowing away $v Drama, as well, I suppose) |
| 12:31 |
berick |
gmcharlt: websockets + nginx -- did you encounter roadblocks there or was it more a case of missing tuits? |
| 12:32 |
gmcharlt |
berick: tuits - will be working on it next week as part of 2.5.0-beta, but certainly wouldn't mind if you want to try your hand at it |
| 12:32 |
berick |
Perry Mason and The Case of the Missing Tuits |
| 12:32 |
phasefx |
dans-datalogics: there are scripts that will install an EG test instance on, for example, Debian Wheezy, without all the manual steps |
| 12:32 |
berick |
gmcharlt: ok, good to know, thanks |
| 12:34 |
berick |
may have time to help on that soon |
| 12:39 |
dans-datalogics |
phasefx: i must've missed those. do they install opensrf as well? |
| 17:26 |
miker |
datetime... no :s |
| 17:26 |
berick |
miker: agreed. was just poking around there |
| 17:26 |
|
bmills joined #evergreen |
| 17:28 |
miker |
(my worry is the possibility of moving everything to the db. not because that's bad, but because the current code is so heavily tested) |
| 17:30 |
berick |
yeah, i'm right there with you |
| 17:33 |
miker |
or, just tell patrons that, yeah, you lose a day in the fall but you get it back in the spring! ;) |
| 17:33 |
|
finnx left #evergreen |
| 11:59 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 11:59 |
berick |
reminds me.. I should rebase that before the hackaway |
| 11:59 |
kmlussier |
berick: That's still out there? For some reason, I thought we had merged that one. :) |
| 11:59 |
* berick |
dons his rebasin' britches |
| 11:59 |
berick |
no, alas, it's a pretty big change. needs lots of eyes and testing. |
| 12:01 |
Dyrcona |
berick: This template? /openils/var/templates/acq/po/edi_messages.tt2 |
| 12:02 |
berick |
Dyrcona: action/trigger template ID 23 |
| 12:02 |
berick |
event_def, i mean |
| 12:06 |
Dyrcona |
But, I couldn't remember the branch. |
| 12:06 |
Dyrcona |
I should have just left the ruby alone. :) |
| 12:08 |
* Dyrcona |
searches for orders made since the webrick shutdown and start. |
| 12:08 |
* Dyrcona |
will be more than happy to test the above branch during the hackaway, once we work out how to test it. |
| 12:11 |
Dyrcona |
So, an Ingram order from 10:17 am shows the invoice id. |
| 12:12 |
Dyrcona |
An Ingram order from 11:41 hasn't been processed, yet. |
| 12:15 |
* Dyrcona |
starts to wonder if switching out the webrick didn't break it more. |
| 12:16 |
berick |
Dyrcona: aha, there's a test plan in the bug |
| 12:17 |
Dyrcona |
berick: OK. |
| 12:19 |
berick |
hm, looks like I need to copy the upgrade sql to the schema. i'll do that too.. |
| 12:36 |
csharp |
berick: I'm very interested in continuing testing/work on bug 1373690 at the hackaway |
| 12:36 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 12:37 |
csharp |
(if not before) |
| 12:47 |
|
jihpringle joined #evergreen |
