| Time |
Nick |
Message |
| 01:32 |
|
Jillianne joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:29 |
|
Dyrcona joined #evergreen |
| 07:41 |
csharp |
2a87597d |
| 07:41 |
pinesol_green |
csharp: [evergreen|erickson] plugged in charge-on-damaged logic, org settings, and billing type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2a87597> |
| 07:42 |
csharp |
c0c60f45 |
| 07:42 |
pinesol_green |
csharp: [evergreen|erickson] use the event def template for the bill note (thanks, miker) instead of using a param. Created a system billing type of Notification Fee, also so none is needed via event param. Added first billing type const (yay). - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0c60f4> |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
rhamby |
there's a strange moment when you're going through the stock test data and find a Goodread review you wrote in a 520 tag of a bib |
| 08:57 |
Dyrcona |
Callender_++ gmcharlt++ # They know why. :) |
| 08:57 |
Dyrcona |
rhamby++ # That's funky. :) |
| 08:58 |
* Dyrcona |
is about to let staff back into the client... |
| 09:09 |
gmcharlt |
rhamby: you should totally add a $c to that 520 |
| 09:18 |
jeff |
this morning i have moved from "why is this slightly broken?" to "how is this working at all?", and am now appending "and what else is it breaking when it works?" |
| 09:23 |
csharp |
jeff++ |
| 09:23 |
csharp |
@quote add < jeff> this morning i have moved from "why is this slightly broken?" to "how is this working at all?", and am now appending "and what else is it breaking when it works?" |
| 09:23 |
pinesol_green |
csharp: The operation succeeded. Quote #163 added. |
| 09:29 |
|
yboston joined #evergreen |
| 09:33 |
|
kmlussier joined #evergreen |
| 09:35 |
kmlussier |
Good morning #evergreen! |
| 09:38 |
mmorgan |
kmlussier: Good Morning! |
| 09:39 |
kmlussier |
bshum and I spent a bit of time last night looking into perl live test failures resulting from new records added to the test dataset. |
| 09:40 |
kmlussier |
bshum has a branch he posted at https://bugs.launchpad.net/evergreen/+bug/1541559/comments/19 that addresses the current perl live test failures that came from the new ebook records, but doesn't address the PgTAP test that had previously been failing. |
| 09:40 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,Fix committed] |
| 09:41 |
kmlussier |
I'm wondering if anyone has other ideas for loading new records to the dataset so that it doesn't move copy numbers around in a way that breaks our tests. I'm not sure bshum's branch is the best long-term solution. |
| 09:52 |
tsbere |
kmlussier: I have ideas....that may not work at all for what I am assuming the problem may be. :/ |
| 09:55 |
* tsbere |
isn't actually 100% positive what the issue is |
| 09:55 |
kmlussier |
tsbere: Well, I'm hoping for a long-term solution that might allow us to add bib records to the test data in a way that puts them to the back in the line so that they don't disrupt the ids for the existing test records. |
| 09:56 |
kmlussier |
tsbere: The issue is that when we add new bib records to the test dataset, it shifts the copy ids around in such a way that the tests are no longer pointing to the correct data. |
| 09:56 |
kmlussier |
I don't know that the ideal, long-term solution is something we can put in place for today's beta release. |
| 09:57 |
bshum |
tsbere: http://testing.evergreen-ils.org/~live/test.24.html <-- it shows up here in the recent live test runs. Test 2 dies, so does 3, 4, 9 (yikes neg balances), and 14. |
| 09:57 |
bshum |
Due to the shifted copies as kmlussier says |
| 09:57 |
* tsbere |
takes a quick look at things and throws his previous ideas out the window |
| 10:00 |
kmlussier |
@coffee |
| 10:00 |
* pinesol_green |
brews and pours a cup of Panama Gesha 2011, and sends it sliding down the bar to kmlussier |
| 10:03 |
tsbere |
I have another idea, but I want to check something first before I elaborate |
| 10:08 |
dbs |
hmm, I'm not surprised checking for a specific database ID (like in 02_simple_circ.t) isn't robust. bshum's approach is expedient, but we should pursue a better longer-term fix post-beta? |
| 10:10 |
tsbere |
I actually wonder why the extra bibs being moved further down is fixing things. Or is this a "the call numbers got moved around due to located URIs" issue? |
| 10:10 |
bshum |
dbs: I've been wondering if we shouldn't consider either adapting the test data to always create specific copies that are intended for passing the tests properly, and leave the rest random, or if we need to make the whole thing less randomly generated to begin with. and do X bibs random, Y bibs more specifically, and Z bibs exactly one way |
| 10:10 |
dbs |
tsbere: it's how we create copies |
| 10:11 |
dbs |
tsbere: when we had one set of bib records, it was easy enough to say "Create a batch of call numbers, and then a batch of copies, based on this set of MARC" |
| 10:11 |
bshum |
but then I worry about curbing the helpfulness of the tests |
| 10:11 |
JBoyer |
I don't actually see any benefit to the random generation and think that a fully hard coded test set would make things a lot simpler in the long run. (Especially in those instances where someone resets a server every day, say, and goes to some lengths to make sure everything ends up the same... ;) ) |
| 10:12 |
dbs |
bshum: well, looking at 02-simple_circ.t, I'm not convinced it's a great test either |
| 10:12 |
bshum |
dbs: That too crossed my mind :) |
| 10:12 |
JBoyer |
Then ids in failed tests also become a lot more useful. |
| 10:12 |
dbs |
JBoyer: here's the thing, the call numbers and barcodes are already unique |
| 10:13 |
dbs |
so using the database IDs in the tests is probably not a great practice |
| 10:13 |
dbs |
JBoyer: they're not randomly generated, they have a very specific pattern |
| 10:13 |
JBoyer |
That's also true. |
| 10:14 |
* csharp |
votes for *not* relying on DB serial IDs for tests |
| 10:14 |
bshum |
Given that the generated call numbers and barcodes are based on the bib ID numbers right? Isn't it safe to assume to they'll usually generate out the same way as long as the bib order loading proceeds as expected? |
| 10:14 |
bshum |
Well maybe not, it is a little random I guess |
| 10:14 |
* bshum |
stops talking and runs to his next meeting |
| 10:14 |
csharp |
it's annoying enough that we rely on things like perm IDs when perm codes make way more sense |
| 10:15 |
dbs |
bshum: yeah, database doesn't guarantee specific ids when it hands out serial types, it just ends up that way |
| 10:15 |
tsbere |
So, looking at things *very* quickly, I suspect that just skipping the marcxml_import table (insert directly like the auth_concerto.sql file does) and putting the various "assets" lines after the appropriate "bibs" line in load_all would be at least a little more robust to future changes. |
| 10:15 |
JBoyer |
Agreed on not depending on ids, that's not why I'd like a more static sample. We've considered putting together a small static set for training purposes and have been (ab?)using concerto for that through the years. |
| 10:20 |
kmlussier |
For today, I'm thinking we can use bshum's approach to make the tests temporarily happy. rhamby is also working to take a similar approach with the records from bug 1665626. |
| 10:20 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 10:21 |
kmlussier |
And then we can consider other options for better loading of test data / better tests in the near-term future? |
| 10:21 |
dbs |
sounds good |
| 10:21 |
* kmlussier |
can try out tsbere's suggestion to see how it works. But not today. |
| 10:23 |
kmlussier |
As I told bshum in a pm, the good news is the fact we are seeing so many test failures speaks to the fact that we've gotten very good about adding live tests since the last time new records were added to the dataset. |
| 10:23 |
kmlussier |
We just need to robust-ify them. |
| 10:25 |
|
tspindler joined #evergreen |
| 10:29 |
dbs |
+1 |
| 10:30 |
|
Jillianne joined #evergreen |
| 10:31 |
|
brahmina joined #evergreen |
| 10:34 |
|
sandbergja joined #evergreen |
| 10:43 |
csharp |
JBoyer: Bmagic: or anyone else on 2.11-ish - have you seen any issues with "large" (75+) item buckets not opening correctly in the staff client? |
| 10:44 |
JBoyer |
csharp, I haven't heard of anything like that, no. We've been on basically-2.11.3 since it was released. |
| 10:44 |
csharp |
we have reports from two libraries that buckets that opened fine pre-upgrade are now causing the client to hang/crash |
| 10:45 |
csharp |
unrelated question - does the fm_IDL.xml file in /openils/var/web/reports/ need to have the label strings in i18n format (e.g., &field.uvs.create_time.label;)? |
| 10:46 |
csharp |
our fm_IDL.xml files are out of sync and I was hoping to just copy the one from /openils/conf/ over |
| 10:48 |
berick |
csharp: that's what I do on my dev servers, copy directly from /openils/conf/ |
| 10:48 |
csharp |
ok - cool |
| 10:48 |
berick |
i assume if you only use en-US, it's not an issue |
| 10:48 |
csharp |
in the client, yes, only en-US |
| 10:48 |
csharp |
OPAC includes es-ES |
| 10:49 |
Dyrcona |
"Things look bad. Things look tragic." |
| 10:49 |
Dyrcona |
"Quoting Ellen West. Dancing on her grave." |
| 10:50 |
JBoyer |
csharp, I pulled up some buckets at various sizes, the only one that was really miserable had around 4000 items in it, though even the 75 and 100-ish ones I wouldn't call "fast." :/ |
| 10:50 |
csharp |
JBoyer: hmm - weird |
| 10:50 |
rhamby |
"just when things look darkest, they go black." - John Newman |
| 10:50 |
csharp |
thanks for testing after me |
| 10:50 |
JBoyer |
Given that they're supposed to only pull details about the 30-ish or so you can see does make that seem odd. |
| 10:51 |
berick |
csharp: i don't remember if the tpac references any IDL strings, but if I had to guess, i'd say it doesn't. |
| 10:51 |
csharp |
berick: k - thanks |
| 10:51 |
csharp |
I guess we'll learn fast if it's off :-) |
| 10:54 |
JBoyer |
"Hello, helpdesk? I tried to run a financials report and it just kept coming back "Ia! Ia! Cthulhu Fhtagn!" How much is that?" |
| 11:10 |
|
khuckins_ joined #evergreen |
| 11:28 |
Dyrcona |
Too much Throwing Muses...They must be bringing the bad luck. |
| 11:34 |
dbs |
There can never be too much Throwing Muses |
| 11:35 |
Dyrcona |
"She has a hook in her head...." |
| 11:35 |
Dyrcona |
:) |
| 11:36 |
Dyrcona |
So, things got worse just as I was about to let staff in. |
| 11:36 |
Dyrcona |
Hence, the quotes from "Ellen West." |
| 11:37 |
|
genpaku joined #evergreen |
| 11:38 |
csharp |
I had a friend in college who was devoted to Throwing Muses, but I could never get into them |
| 11:38 |
csharp |
I liked Belly, though (Kristen Hersh's (step-?)sister) |
| 11:43 |
|
bmills joined #evergreen |
| 11:46 |
Dyrcona |
Tanya Donnelly who was/is in Throwing Muses. |
| 11:46 |
csharp |
right |
| 11:46 |
Dyrcona |
"Take your hat off, boy, when you're talking to me." ;) |
| 11:47 |
kmlussier |
bshum++ |
| 11:49 |
dbs |
And then Tanya and Kim Deal got together to create The Breeders which blew my mind as a Throwing Muses/Belly/Pixies fan |
| 11:49 |
pinesol_green |
[evergreen|Ben Shum] LP#1541559: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a9b812> |
| 11:50 |
rhamby |
dbs: The Breeders were awesome. Iliked Belly and Pixies too but never got into Throwing Muses. |
| 12:01 |
dbs |
I was hooked when I got Garoux des Larmes on a mixtape from a girl I didn't know in California :) |
| 12:06 |
Dyrcona |
dbs: There's a Monty Python retort in there somewhere, but I'm too busy. |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:23 |
|
Christineb joined #evergreen |
| 12:27 |
csharp |
JBoyer: with one of the 100+ buckets, could you try clicking "Show Status"? |
| 12:28 |
tspindler |
Dyrcona: "And now for something completely different" |
| 12:31 |
JBoyer |
csharp, Intense unhappiness. A tiny window with no contents opened in the middle of the screen and everything is frozen. I expect it to time out soon. |
| 12:32 |
csharp |
ok - that's the complaint |
| 12:32 |
csharp |
I'm about to fire up a 2.9.1 client to see if it happens on our old test server |
| 12:32 |
JBoyer |
Or, you could click the X on the little window to make it go away, though it doesn't seem to do much. |
| 12:32 |
csharp |
actually, I'm not seeing the window - just nothing happening and frozen client |
| 12:36 |
Dyrcona |
tspindler: More like "farsical aquatic ceremonies." |
| 12:39 |
berick |
@who has a mandate from the masses |
| 12:39 |
pinesol_green |
dbwells has a mandate from the masses. |
| 12:39 |
csharp |
okay, I can confirm that Show Status is working in 2.9.1 |
| 12:40 |
JBoyer |
Not that I don't want it fixed, but that seems like THE WORST idea in an enormous bucket... |
| 12:42 |
* csharp |
agrees |
| 12:42 |
csharp |
honestly, I only find how Evergreen is *actually* used when something like this breaks |
| 12:43 |
mmorgan |
csharp: Maybe I missed this, but is show status failing only for large copy buckets or all buckets? |
| 12:43 |
csharp |
mmorgan: large buckets |
| 12:43 |
csharp |
"large" = "over 40 items" (in one report) |
| 12:45 |
mmorgan |
ok, it's working for me for buckets of ~100 items, but a 200+ bucket failed to load into item status. Didn't freeze my client, though. |
| 12:45 |
csharp |
mmorgan: what happens when it fails to load? |
| 12:46 |
dbwells |
mandate from the masses? sweeeeet |
| 12:47 |
mmorgan |
The Show Status shows with a blue border, like it's been clicked, but nothing else happens. I can continue to use the client, and even choose another bucket in the same tab. |
| 12:48 |
Dyrcona |
gmcharlt++ |
| 12:48 |
* mmorgan |
is using Windows 10 if that adds anything to the equation. |
| 12:48 |
csharp |
mmorgan: I feel certain workstations issues will be a factor here, so that does help |
| 12:49 |
csharp |
I'm using the x86_64 Linux client on Fedora 25 |
| 12:55 |
mmorgan |
Interesting, in my bucket of 289 items, I am able to load into item status if I scroll down the bucket and see that the data has filled in for all the copies. |
| 12:57 |
JBoyer |
Oh. Depending on what's passed to Item Status (I'm guessing Barcode) it has to load EVERYTHING for all of the copies, even though it is throwing away 90%+ of it. :/ |
| 12:57 |
JBoyer |
Since containers only hold the item ids |
| 12:58 |
JBoyer |
(The JS Console points that way also, for every row in IS, there's a call that sends a barcode and the another that sends an item id.) |
| 13:01 |
csharp |
mmorgan: ha! that works for me with a bucket of 768 |
| 13:01 |
csharp |
okay - so that's a viable workaround in my book |
| 13:01 |
csharp |
and just continue to let the xul client sink into the deep dark waters |
| 13:03 |
Dyrcona |
So, my server that normally runs EDI crashed yesterday. |
| 13:03 |
Dyrcona |
I've temporarily replaced it with a Jessie VM. Am I going to be able to get EDI to install and/or work? |
| 13:04 |
Dyrcona |
Ah, wait a minute. I don't have to run it there, do I? |
| 13:04 |
Dyrcona |
It doesn't need access to the NFS shares. |
| 13:07 |
mmorgan |
Hmm. Just killed my client. Clicked Show Status while viewing the copy bucket, THEN tried to scroll down the list of items. |
| 13:07 |
csharp |
yeah - that's what we're hearing from the wild |
| 13:11 |
Bmagic |
I have not received a report about this issue but it sure sounds like it's a real issiue |
| 13:14 |
kmlussier |
OK, I've squashed rhamby |
| 13:14 |
kmlussier |
Ugh. Didn't mean to hit <enter>. I didn't really squash Rogan. |
| 13:15 |
kmlussier |
I've squashed rhamby's commit and added my own commit to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1665626-fix-metarecord-test-rebase |
| 13:15 |
rhamby |
I assumed I was being abused as normal /shrug |
| 13:15 |
JBoyer |
Sometimes I don |
| 13:15 |
JBoyer |
t like the single quote being right next to Enter. |
| 13:15 |
kmlussier |
But it isn't working for me. When I load the new bibs, I'm getting a bunch of perl live test failures. I'm putting it out there for additional eyes. |
| 13:19 |
csharp |
@who squashed rhamby? |
| 13:19 |
pinesol_green |
phasefx_ squashed rhamby. |
| 13:21 |
* kmlussier |
has a theory. |
| 13:21 |
kmlussier |
Unfortunately, it takes many minutes to test out my theories. |
| 13:42 |
|
collum joined #evergreen |
| 14:31 |
kmlussier |
All tests successful. |
| 14:32 |
kmlussier |
Now I just need to squash some commits and update the metarecord test. I should have something for somebody to merge in the next 15 minutes. |
| 14:38 |
|
collum joined #evergreen |
| 14:45 |
mmorgan |
kmlussier++ |
| 14:56 |
kmlussier |
working/user/kmlussier/lp1665626-fix-metarecord-test-rebase is ready for testing and, hopefully, signoff and merging. |
| 14:56 |
kmlussier |
Once that fix gets into master, we'll close off new code for 2.12beta and hand things over to gmcharlt to perform his magic. |
| 14:57 |
gmcharlt |
speaking of which |
| 14:57 |
gmcharlt |
the OpenSRF beta tarball will definitely be available today |
| 14:57 |
gmcharlt |
but the Evergreen one may not be until tomorrow |
| 14:58 |
kmlussier |
Works for me! gmcharlt++ |
| 14:58 |
kmlussier |
Also, bshum++ rhamby++ # Helping with tests. |
| 15:02 |
Dyrcona |
Chtulhu Fhtagn! |
| 15:03 |
Dyrcona |
At least, I can end today with most things working, thanks in part to gmcharlt and Callender_. |
| 15:03 |
kmlussier |
gmcharlt++ Callender++ |
| 15:04 |
Dyrcona |
Callender++ # I've incr'd gmcharlt twice already. |
| 15:05 |
Bmagic |
kmlussier++ gmcharlt++ rhamby++ bshum++ |
| 15:05 |
kmlussier |
Hey, it's a karma party! |
| 15:10 |
Dyrcona |
You get karma! You get karma! Everybody gets karma! |
| 15:10 |
|
mmorgan joined #evergreen |
| 15:17 |
kmlussier |
Tomorrow is National Margarita Day. Just in case anyone is looking for a way to celebrate the 2.12 beta release. :) |
| 15:19 |
bshum |
Good enough reason as any to me... |
| 15:19 |
bshum |
kmlussier++ rhamby++ |
| 15:20 |
rhamby |
kmlussier++ bshum++ gmcharlt++ bmagic++ |
| 15:28 |
tspindler |
gmcharlt++ Callendar |
| 15:28 |
tspindler |
Callendar++ |
| 15:39 |
|
tspindler left #evergreen |
| 16:10 |
pinesol_green |
[opensrf|Mike Rylander] LP#1616501: teach mod_perl handlers how to detect client disconnects - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=9ca5c3d> |
| 16:26 |
JBoyer |
quick poll at the end of the day: bug 1274999 is fixed (Next 10 link showing up when there are no more copies on record detail page), warrant a release note or no? |
| 16:26 |
pinesol_green |
Launchpad bug 1274999 in Evergreen "Next 10 Link erroneously available at the end of holdings in OPAC, intermittent " [Undecided,Confirmed] https://launchpad.net/bugs/1274999 |
| 16:27 |
kmlussier |
JBoyer: Since it's a bug fix, I say no. |
| 16:27 |
JBoyer |
(spoiler alert: any time the total number of copies mod copy_limit == 0 you get a Next link, even if there are only copy_limit copies total.) |
| 16:27 |
kmlussier |
Speaking of release notes, I just remembered there are still some stray entries from 2.11 that need to be cleared out. |
| 16:27 |
JBoyer |
kmlussier, That's how I was leaning, miiiiight be able to squeeze it in today yet in that case. :) |
| 16:29 |
kmlussier |
JBoyer: Might be a nice thing to test during Bug Squashing week. :) |
| 16:30 |
JBoyer |
kmlussier++ |
| 16:46 |
|
hbrennan joined #evergreen |
| 16:48 |
bshum |
All tests pass for me in the branch |
| 16:48 |
bshum |
Anyone else testing and signing off to push? |
| 16:48 |
* bshum |
will go ahead and get it in otherwise |
| 16:50 |
* bshum |
whistles a happy tune |
| 16:52 |
pinesol_green |
[evergreen|Rogan Hamby] LP#1665626: adding new records to the meta group and breaking into new file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ecb690> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44644b4> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Update metarecord_constituent_result_reroute.pg test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02a62c2> |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
bshum |
Aw, not fast enough. Didn't get the latest commits in that test run. Have to wait till tomorrow I guess. |
| 17:02 |
* phasefx |
can force another run |
| 17:02 |
bshum |
The build test failure though, hmm |
| 17:02 |
bshum |
That's something else |
| 17:02 |
phasefx |
oh, in that case, no need for me to force it |
| 17:03 |
bshum |
Yeah, best to figure out what that one is about too and then fix all the things |
| 17:03 |
bshum |
But later |
| 17:03 |
bshum |
Dinner first :) |
| 17:07 |
Dyrcona |
So, errors in EDI that look familiar, probably caused by perl version > 5.18 or thereabouts. |
| 17:08 |
* Dyrcona |
searches for Lp bugs that are fix released. |
| 17:08 |
|
mmorgan1 joined #evergreen |
| 17:10 |
Dyrcona |
Use of uninitialized value $filename in concatenation (.) or string at /usr/local/share/perl/5.20.2/OpenILS/Utils/RemoteAccount.pm line 619. |
| 17:11 |
Dyrcona |
That happens, but it shouldn't happen. |
| 17:11 |
Dyrcona |
Because line 609 is if ($@ or not $filename) { |
| 17:11 |
Dyrcona |
and there's a return inside that if block. |
| 17:12 |
Dyrcona |
And this seems like something that Bmagic ran into and I helped him fix, but my Launchpad Fu has failed me. |
| 17:13 |
Bmagic |
hmmm |
| 17:13 |
* berick |
seems to recall some unepxected precedence handling with 'or' vs. '||' |
| 17:14 |
|
mmorgan1 left #evergreen |
| 17:14 |
Dyrcona |
berick: I'll change to || and see if that helps. |
| 17:15 |
Dyrcona |
I also wonder if ftp get returned 0E0 which is zero, but true, IIRC. |
| 17:17 |
Dyrcona |
I need to stop vi from telling me the file that I'm loading and press enter to continue. I'll google that after. |
| 17:19 |
berick |
yeah, it does that for me when using -p. it's annoying. |
| 17:19 |
berick |
tell me what you find :) |
| 17:22 |
pinesol_green |
[opensrf|Galen Charlton] LP#1666706: add --with-websockets-port configure option - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=fca2dcf> |
| 17:24 |
Dyrcona |
Nothing works so far. |
| 17:27 |
Dyrcona |
berick: set cmdheight=2 in .vimrc does it for me. |
| 17:28 |
Dyrcona |
That's literally "set cmdheight=2" |
| 17:31 |
Dyrcona |
|| didn't make any difference apparently. |
| 17:40 |
gmcharlt |
opensrf-2.5.0-beta is now available |
| 17:49 |
rhamby |
gmcharlt++ |
| 17:49 |
berick |
gmcharlt++ indeed |
| 17:55 |
bshum |
gmcharlt++ |
| 18:11 |
Dyrcona |
hm... The line where filename is set suddenly looks wrong, there's a space: $self-> ftp_get. I think that should be all right, but I'll verify. |
| 18:13 |
Dyrcona |
yeah, a space there should not be a problem. |
| 18:14 |
Dyrcona |
oh, duh. it's _ my block cursor on the line below obscured it. |
| 18:14 |
Dyrcona |
Even so, a space still seems to work from a quick test. |
| 18:14 |
* Dyrcona |
calls it a day. |
| 19:07 |
|
brahmina joined #evergreen |
| 19:43 |
bshum |
Hmm, confirmed that the make check fails on the build test with 23-OpenILS-Application-EbookAPI.t |
| 19:43 |
bshum |
At least, confirmed for me on my own VM, not just the builder test |
| 20:37 |
pinesol_green |
[evergreen|Galen Charlton] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a67e294> |
| 21:54 |
|
denials_exile joined #evergreen |
| 21:55 |
denials_exile |
In case anyone is looking for the Planet, it will be down until this is fixed: https://status.linode.com/incidents/2ns3cw1dsymf (hopefully soon, sigh) |
| 22:07 |
|
gmcharlt joined #evergreen |
| 22:10 |
|
dbs joined #evergreen |
| 22:26 |
* denials_exile |
claps for the return of gmcharlt and dbs, then disappears in a puff of redundant smoke |
