| 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 |
| 11:32 |
|
bmills1 joined #evergreen |
| 11:32 |
|
bmills1 joined #evergreen |
| 12:08 |
|
sandbergja joined #evergreen |
| 12:10 |
berick |
wow. just realized I wrote a series of perl live tests based on data I thought came from concerto, but must have come from me. |
| 12:11 |
* berick |
adds to concerto |
| 12:11 |
jeff |
heh. |
| 12:15 |
|
brahmina joined #evergreen |
| 12:25 |
|
jvwoolf joined #evergreen |
| 15:12 |
* csharp |
agrees |
| 15:12 |
gmcharlt |
yup |
| 15:12 |
* abowling |
agrees, too |
| 15:13 |
gmcharlt |
next up - web client sprint 3 testing... is underway |
| 15:13 |
gmcharlt |
and finally, here I am, leading the September^W October development meeting |
| 15:13 |
gmcharlt |
so, I think that does it for action items |
| 15:13 |
kmlussier |
:) |
| 15:13 |
gmcharlt |
so, let's move on |
| 15:14 |
gmcharlt |
#topic OpenSRF release info |
| 15:24 |
gmcharlt |
so, on to maintenance releases |
| 15:25 |
gmcharlt |
miker: dbwells: y |
| 15:25 |
gmcharlt |
y'all are prepared to do a 2.11.1 later this month? |
| 15:25 |
miker |
I will be out of pocket on the normal date ... if I'm to be involved it'll need to slip a week |
| 15:26 |
miker |
which, really, isn't terrible -- there are several bug fixes to test and pull in, and .0 is not a brown bag |
| 15:26 |
dbwells |
I should be available to handle 2.11.1. |
| 15:26 |
dbwells |
If need be. |
| 15:27 |
dbwells |
10/19? |
| 16:01 |
dbwells |
gmcharlt++ |
| 16:02 |
kmlussier |
Bmagic++ |
| 16:02 |
Dyrcona |
gmcharlt++ |
| 16:02 |
* phasefx |
wants to throw out one thing post-meeting, live tester is showing some failed tests: http://testing.esilibrary.com/~live/ I can scrutinize later, but someone may get the itch sooner |
| 16:03 |
kmlussier |
phasefx: csharp had thoughts on the transit status failure yesterday afternoon. |
| 16:03 |
phasefx |
rock |
| 16:03 |
Dyrcona |
paper |
| 16:03 |
phasefx |
rock bug paper |
| 16:04 |
kmlussier |
Speaking of live tests, did we ever figure out why the results aren't posting to the channel anymore? Was it related to the RSS feed? |
| 16:04 |
jeff |
I think it was something along those lines. I can volunteer to look into it again. |
| 16:04 |
gmcharlt |
dbs: your key is in place now - sorry abou the delay |
| 16:05 |
dbs |
gmcharlt++ |
| 16:05 |
jeff |
I think it came down to supybot not thinking that the new test results were new. |
| 16:05 |
dbs |
thank you |
| 16:05 |
Dyrcona |
I meant to fix that one Perl test some time ago, but new job got me sidetracked. |
| 16:20 |
kmlussier |
@quote random |
| 16:20 |
pinesol_green |
kmlussier: Quote #159: "< jeff> Oh honey, he's teasing you. Nobody has two library card numbers." (added by csharp at 10:09 AM, August 25, 2016) |
| 16:21 |
kmlussier |
I think I was on vacation for that one. |
| 09:56 |
|
Dyrcona joined #evergreen |
| 09:57 |
Dyrcona |
And now, I remember one of the reasons that I always used to use a separate partiton for /home.... |
| 09:59 |
Dyrcona |
You can't safely fsck a mounted volume, and you can't unmount / if you want to run fsck, so I need to make a recovery disk. |
| 10:00 |
Dyrcona |
I ain't got time for that, so at the risk of having corrupted files, I continue with testing my 2.9.5 to 2.10.7 upgrade. |
| 10:28 |
StomproJ |
Ahhhahh, my memcache server is hitting a openvz tcprcvbuf limit, causing connections to fail. |
| 10:31 |
* Dyrcona |
uses kvm, so wouldn't know about that. :P |
| 10:34 |
StomproJ |
Proxmox has moved away from openvz, so I won't use it in the future either. |
| 13:32 |
* Dyrcona |
drives his wife nuts. :) |
| 13:33 |
Dyrcona |
NCIP isn't a standard so much as it a smorgasboard of options. That's why "profiles" exist, though NCIPServer was not written to target any specific profile. |
| 13:34 |
Dyrcona |
I was given some documentation and "sample" messages. |
| 13:34 |
Dyrcona |
Spent several months coding, then got it to actually work with the vendor once testing starting. |
| 13:35 |
Dyrcona |
Changes have accrued while it is in production and real things happen. |
| 13:35 |
|
ssieb joined #evergreen |
| 13:35 |
* kmlussier |
feels sympathy for Dyrcona's wife. |
| 14:05 |
|
Christineb joined #evergreen |
| 14:21 |
Dyrcona |
Can someone see what's wrong with this: [% date.format(helpers.format_date(circ.due_date), '%A, %B %d, %Y') %] |
| 14:21 |
Dyrcona |
I put that in a template and it is erroring out with invalid date format, but that looks correct to me. |
| 14:22 |
Dyrcona |
I don't have a quick way to test it, unfortunately. |
| 14:27 |
berick |
Dyrcona: see if circ.due_date is null |
| 14:27 |
dbs |
is it an invalid input date perhaps? |
| 14:28 |
Dyrcona |
In every single courtesy notice for the past week? |
| 14:35 |
bshum |
pinesol_green is wise to keep its opinion to itself... |
| 14:35 |
pinesol_green |
bshum: I am only a bot, please don't think I'm intelligent :) |
| 14:35 |
pinesol_green |
bshum: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:38 |
* Dyrcona |
pines for a test environment. |
| 14:39 |
* jeff |
uses PINES for a test environment |
| 14:39 |
Dyrcona |
:) |
| 14:39 |
jeff |
(not really, but i couldn't let that pun opportunity go to waste) |
| 14:46 |
* jeff |
sends out a few emails in an attempt to gather iNCIPit forks |
| 15:37 |
csharp |
@karma karma karma karma karma chameleon |
| 15:37 |
pinesol_green |
csharp: karma karma karma chameleon has neutral karma. |
| 15:38 |
berick |
chameleon++ |
| 15:40 |
csharp |
@who is using PINES as a test environment? |
| 15:40 |
pinesol_green |
Stompro is using PINES as a test environment. |
| 15:40 |
miker |
whew! I thought pinesol was about to rat me out... |
| 15:41 |
miker |
CRAP ... I said the quiet part loud again |
| 15:41 |
kmlussier |
@blame miker |
| 15:41 |
pinesol_green |
kmlussier: miker stole bradl's tux doll! |
| 15:41 |
csharp |
@blame inner monologues |
| 15:41 |
pinesol_green |
csharp: inner monologues musta been an Apple employee. |
| 15:41 |
berick |
wait, we're not supposed to be using PINES as a test environment? |
| 15:42 |
miker |
berick: define "supposed" .... |
| 15:42 |
miker |
also, define "test" |
| 15:42 |
berick |
hah |
| 16:13 |
Bmagic |
csharp: was it you who used the TTP-247 barcode printers for replacing barcodes during migration? |
| 16:19 |
|
jvwoolf joined #evergreen |
| 16:52 |
kmlussier |
We're getting some test failures on the purge-user-activity tests. http://testing.evergreen-ils.org/~live/test.html |
| 16:53 |
kmlussier |
And on the abort transity copy status live test. |
| 16:53 |
* kmlussier |
misses the twice daily test results that used to post in channel. |
| 16:57 |
csharp |
Bmagic: nope, not me |
| 16:57 |
Bmagic |
cool, no biggie |
| 17:01 |
csharp |
kmlussier: I see what's happening with the perl test - it's expecting the copy status to be "Reshelving" after transit abort and it's now "Canceled Transit" |
| 17:01 |
|
mmorgan joined #evergreen |
| 17:03 |
kmlussier |
csharp: Ah, ok. So is that the one Dyrcona did for his fix before your new feature went in? |
| 17:03 |
csharp |
right |
| 17:31 |
csharp |
Bmagic: the first example's supposed to happen - the transit stores the status it was in when it went into transit so it can resume that status when it gets to its destination |
| 17:32 |
csharp |
and the second problem can have multiple causes, including "checkout fills related hold"-type stuff (probably the most common) |
| 17:32 |
Bmagic |
csharp: right, I understand that part. Missing items are being reported as being on the pull list. Would the hold targeter target missing items? Perhaps it wasn't missing when the targeter ran? |
| 17:32 |
csharp |
oh - yeah, it shouldn't target missing copies |
| 17:33 |
csharp |
auditor.asset_copy_history might help know what happened |
| 17:36 |
csharp |
dbs: are you still managing buildbot/testing.evergreen-ils.org? |
| 17:36 |
* csharp |
would like to create a few new builders on mundungus |
| 17:40 |
dbs |
csharp: I might still be able to! |
| 17:41 |
dbs |
Trying to prep for a hands-on Angular 2 session that I'm supposed to be leading in 1.25 hours atm though |
| 17:41 |
csharp |
dbs: no prob - it will take a while to set up the VMs anyway |
| 17:41 |
csharp |
thanks! |
| 17:41 |
dbs |
Really should have carved out some time before... |
| 17:42 |
dbs |
Looks like my ssh key might have gone dead on testing.evergreen-ils.org |
| 17:43 |
csharp |
ok, I'll see if phasefx_ or miker or someone can get me going |
| 17:57 |
dbs |
gmcharlt used to be my partner in crime for testing.evergreen-ils.org |
| 17:58 |
|
jvwoolf left #evergreen |
| 18:03 |
gmcharlt |
dbs: send me the current one(s) and I'll get you set up again |
| 18:03 |
* gmcharlt |
goes poof, braves Atlanta traffic |
| 08:23 |
jeff |
dbs: regarding your conversation with Apache this morning: is the server_status count showing requests and not connections, while MaxConnectionsPerChild is counting connections not requests? |
| 08:26 |
jeff |
(where one connection may serve up to MaxKeepAliveRequests requests) |
| 08:27 |
* jeff |
starts to wonder if he's running a config different from that which is on disk. short of hijacking a configured perl handler with code that would attempt to read config settings, i'm not sure if there's a way to check that. |
| 08:51 |
StomproJosh |
csharp, re bug 1616220 - There are a bunch of dojo related warnings that my fix doesn't touch. So it doesn't get rid of all the warnings, just reduces the number of them. I can provide some specific examples to make testing easier. |
| 08:51 |
pinesol_green |
Launchpad bug 1616220 in Evergreen "XUL Staff Client CSS Fixes" [Undecided,New] https://launchpad.net/bugs/1616220 |
| 09:02 |
|
bos20k joined #evergreen |
| 09:07 |
|
mmorgan joined #evergreen |
| 09:27 |
dbs |
but the server_status display shows an "Acc" column of 0/85/1186 and I was interpreting the "85" as # requests (per the legend at the bottom "Acc: Number of accesses this connection / this child / this slot") |
| 09:28 |
dbs |
But yeah, maybe I was interpreting it wrong, and now that I'm dropped KeepAlive to 2 from 5 there are more connections turning over |
| 09:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1623955: Keep periods in subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4c7efc> |
| 09:32 |
csharp |
Stompro: thanks - I'll re-test with your new info when you post them :-) |
| 09:33 |
csharp |
Stompro: re: staff initials, at least one of our libraries uses patron stat cats for that |
| 09:36 |
Stompro |
csharp, thanks for the staff initials info. |
| 09:42 |
JBoyer |
Stompro, csharp, I was going to say, initials for patron reg wasn't ringing any bells for me, but csharp's stat cat idea is a good one. I'd poll your members and see if it's worth making a consortium wide stat cat rather than trying to talk a lot of libs through it through it. |
| 09:44 |
|
kmlussier joined #evergreen |
| 10:42 |
jeff |
isn't this expected to fail on recent Encode.pm? |
| 10:43 |
Dyrcona |
jeff: Yes. That was what I was testing, but this is not a recent Encode AFAIK. |
| 10:43 |
jeff |
ah. |
| 10:43 |
Dyrcona |
It failed on 16.04, and I'm testing 14.04 for duplication, etc. |
| 10:44 |
jeff |
my guess right now is that you're running into the bug where sipserver doesn't properly flush the buffer on the socket. |
| 10:44 |
jeff |
because it's not counting bytes. |
| 10:44 |
Dyrcona |
Encode is 2.49... |
| 10:51 |
dbs |
coffee++ |
| 10:51 |
|
Christineb joined #evergreen |
| 10:52 |
csharp |
NOBLE++ |
| 10:55 |
Dyrcona |
I'm going to test and push Bmagic's branch on Lp 1613326. (I think I promised to do that last month, and never found my tuit.) |
| 10:55 |
pinesol_green |
Launchpad bug 1613326 in SIPServer "SIPServer UNIVERSAL removed" [Undecided,New] https://launchpad.net/bugs/1613326 |
| 10:56 |
berick |
noble++ kmlussier++ |
| 10:56 |
jeff |
Dyrcona: pretty sure user/jeff/fix_universal_can will fix your "I want to fix the UNIVERSAL does not export anything message on Ubuntu 16.04" issue |
| 11:08 |
Dyrcona |
I'll add Bmagic's bug number and give him some credit in commit message. How's that? |
| 11:08 |
jeff |
i'll push a new branch with a reasonable commit message and comment on the bug. |
| 11:10 |
Dyrcona |
OK. I'll wait. |
| 11:13 |
Dyrcona |
dbs | jeff: I'm convinced my solution to the Encode issues is not optimal. I haven't even really tested it yet, either. |
| 11:23 |
|
brahmina joined #evergreen |
| 11:29 |
Dyrcona |
jeff++ |
| 11:29 |
Bmagic |
jeff++ |
| 12:19 |
Dyrcona |
Y'know. I may just try putting clean_text() on autoload Item fields and see what that does. |
| 12:20 |
Dyrcona |
But first, I'll finish lunch. |
| 12:20 |
jeff |
title/author with mangled characters were the most common trigger for us. i think that's due to a different issue in how MODS transforms are being done. |
| 12:25 |
terran |
Bug Squashing Day Update: 6 patches have been tested & signed off on, and 3 new patches have been submitted! |
| 12:34 |
jeff |
Dyrcona: bug 1628995 |
| 12:34 |
pinesol_green |
Launchpad bug 1628995 in SIPServer "SIPServer can incorrectly calculate output message length, which can lead to clients hanging" [Medium,New] https://launchpad.net/bugs/1628995 - Assigned to Jeff Godin (jgodin) |
| 12:37 |
dbs |
jeff++ # different fun with encodings (bytes vs. length), heh |
| 12:54 |
* Dyrcona |
adds use bytes; before POSIX::write to see if that makes a difference. |
| 12:55 |
Dyrcona |
Bingo! We have a winner! |
| 12:56 |
Dyrcona |
pysip2 doesn't choke on the multi-byte call number. |
| 12:56 |
csharp |
@blame testing the wrong git branch |
| 12:56 |
pinesol_green |
csharp: testing the wrong git branch WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 12:58 |
Dyrcona |
I'm inclined to fix the length calculation as its own bug and not mix it up with the Encode changes. |
| 12:58 |
jeff |
i don't know that that's the best / long term fix, but i'll amend my commit message and push that branch. we've been using it in production for a while. |
| 12:59 |
Dyrcona |
Where'd you put the use bytes; out of curiosity. |
| 12:59 |
Dyrcona |
? |
| 13:06 |
dbs |
makes sense to keep it locally scoped to the length() call, to avoid having any other side effects |
| 13:07 |
* dbs |
greps to see 15 length() calls to audit to see whether use bytes would be warranted or not |
| 13:07 |
Dyrcona |
yeah, in my test, I did the same. |
| 13:09 |
dbs |
+1 to fixing this one little bug first |
| 13:10 |
* miker |
thinks `require bytes; ... bytes::length()` may be better? |
| 13:10 |
Dyrcona |
miker: It may be better. |
| 13:23 |
Dyrcona |
lines 95, and maybe 179 and 199 |
| 13:24 |
Dyrcona |
I misspoke about SIPServer.pm abov. |
| 13:24 |
Dyrcona |
above. |
| 13:29 |
abowling |
i've tackled this before, but i've slept and forgotten. trying to get a test server up and running to get rid of these darned bugs, and getting: /usr/bin/ld: cannot find -ldbdpgsql |
| 13:29 |
abowling |
anyone have any suggestions/memories? |
| 13:29 |
abowling |
i have installed 9.3 |
| 13:36 |
berick |
abowling: what's the output of: cat /etc/ld.so.conf.d/evergreen.ld.conf |
| 13:39 |
abowling |
berick: might be part of my probelm |
| 13:39 |
abowling |
cat: /etc/ld.so.conf.d/evergreen.ld.conf: No such file or directory |
| 13:40 |
jeff |
miker, others: opinions on "require bytes" being in the same lexical scope as the POSIX::write / bytes::length call? I'm tempted to put it in the Sip package itself, since 1) "require bytes" shouldn't have any side effects and 2) there is a slight possibility we may find other calls to length() that should be bytes::length() before we're done. |
| 13:40 |
abowling |
berick: root evergreen-2-10-6-test:/etc/ld.so.conf.d# cat /etc/ld.so.conf.d/eg.conf |
| 13:40 |
abowling |
/usr/local/lib/dbd |
| 13:41 |
berick |
abowling: is there stuff in /usr/local/lib/dbd/ ? |
| 13:42 |
abowling |
berick: there is, but nothing for psql |
| 13:42 |
berick |
k, you should see libdbdpgsql.so |
| 14:34 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 14:38 |
miker |
Dyrcona: mess away |
| 14:39 |
Dyrcona |
miker: Will do, as bug manager. |
| 15:04 |
mmorgan |
dbwells: I'm testing lp 1422379 and see mention of a less onerous upgrade script than originally proposed https://bugs.launchpad.net/evergreen/+bug/1422379/comments/13 |
| 15:04 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" [Medium,Triaged] - Assigned to Michele Morgan (mmorgan) |
| 15:05 |
mmorgan |
, but don't see the alternate upgrade script, but agree that it sounds much less onerous. |
| 15:06 |
kmlussier |
@praise bug squashers |
| 15:06 |
* pinesol_green |
bug squashers goes to eleven |
| 15:06 |
kmlussier |
Bad grammar. |
| 15:06 |
mmorgan |
I've done a lot of testing, generating a lot of fines for hourly as well as daily loan periods and finesk and it looks good so far. |
| 15:08 |
mmorgan |
Did I really say that??? Been a long day... |
| 15:11 |
|
ethomsen joined #evergreen |
| 15:22 |
jeff |
mmorgan: were you able to do any testing on a system with billings dating back a long ways, to Evergreen 1.2.x.x and such? |
| 15:23 |
mmorgan |
jeff: no, I don't have access to such a system. |
| 15:24 |
mmorgan |
Is the only concern there the upgrade script for such systems? |
| 15:26 |
jeff |
i wouldn't say it's my *only* concern, no. :-) |
| 16:50 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 17:01 |
terran |
Dyrcona: Yes, I counted the bugmaster changes that I saw |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:09 |
dbwells |
mmorgan: Thanks for testing that branch! I pushed a rebased version with the reworked upgrade script just now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1422379_move_billing_timestamps_rebase_v3 |
| 17:16 |
abowling |
berick++ |
| 17:16 |
abowling |
berick: you led me down the trail. the fix is this: cp -R /usr/lib/i386-linux-gnu/* /usr/lib/x86_64-linux-gnu/ |
| 17:16 |
abowling |
after that, make runs fine |
