| 01:27 |
|
abowling joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
Callender joined #evergreen |
| 08:14 |
|
Dyrcona joined #evergreen |
| 08:27 |
|
_adb joined #evergreen |
| 14:49 |
* mmorgan |
just learned that the branches at which an applied patron alert message displays is set at the time it's added to the patron record. |
| 14:49 |
mmorgan |
Changing the org depth of the penalty type does not affect existing messages. |
| 15:20 |
kmlussier |
Dyrcona++ # For rastling with the MassLNC VMs |
| 15:24 |
Dyrcona |
Heh. I just realized that I'm gonna have some "fun" building 2.10 on my test vm with Ubuntu 16.04.... |
| 15:24 |
Dyrcona |
I'll have to check out something more recent to install the prerequisites. |
| 15:26 |
Dyrcona |
I suppose I could use my 2.12 branch from training... |
| 15:29 |
Dyrcona |
Yeah. I'll install my 2.12 branch. I do have another test vm with our production branch already installed. |
| 15:30 |
Dyrcona |
Ah, but I'll have to reconfigure it and change the database because I think they're both using jasontest.... |
| 15:30 |
Dyrcona |
Sorry for thinking out loud. |
| 15:31 |
* Bmagic |
<whisper>use docker</whisper> |
| 16:06 |
jeff |
yay! |
| 16:06 |
jeff |
Dyrcona++ kmlussier++ |
| 16:06 |
Dyrcona |
My production database is affected. |
| 16:06 |
Dyrcona |
So, I'll test with that and a freshly built master. |
| 16:07 |
Dyrcona |
"that" being a copy of the production database. |
| 16:11 |
mmorgan |
jeff++ kmlussier++ dyrcona++ |
| 16:12 |
kmlussier |
I really don't deserve karma. All I did was think about testing a fix. |
| 16:12 |
kmlussier |
Dyrcona++ jeff++ |
| 16:25 |
mmorgan |
I wonder if adding the permission COPY_STATUS_LONG_OVERDUE.override via the client and assigning it to her users would be good advice for Jennifer W. |
| 16:26 |
mmorgan |
Or if it would cause more problems later. |
| 16:27 |
jeff |
it should not. that is one of the scenarios that the upgrade script anticipates. |
| 16:27 |
Dyrcona |
Yeah. It does look like it handles that case. |
| 16:28 |
Dyrcona |
Another situation to test... :) |
| 16:28 |
jeff |
it ended up being a ridiculously long upgrade script for fixing a one character typo. ;-) |
| 16:30 |
kmlussier |
mmorgan: Yes, I sent a reply suggesting that as a solution. It's just taking a while for my message to hit the list. |
| 16:31 |
mmorgan |
Ok, good! I will resist giving you karma, though you deserve it :) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:32 |
kmlussier |
The earlier karma can count towards that. :) |
| 16:33 |
mmorgan |
Perfect! |
| 16:42 |
Dyrcona |
First time I've seen this one: Can't call method "documentElement" on an undefined value at /usr/local/share/perl/5.22.1/OpenSRF/Utils/SettingsParser.pm line 51. |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:17 |
|
kmlussier joined #evergreen |
| 08:23 |
|
rlefaive joined #evergreen |
| 08:32 |
|
krvmga joined #evergreen |
| 10:18 |
kmlussier |
I can give you his email. Hold on... |
| 10:18 |
bshum |
I got it |
| 10:18 |
kmlussier |
bshum++ |
| 10:19 |
bshum |
kmlussier: Okay, all switched |
| 10:19 |
bshum |
Or should be |
| 10:19 |
bshum |
I'll send a test email to verify :) |
| 10:19 |
bshum |
Looks good |
| 10:21 |
kmlussier |
OK, page updated. Looks like the only other update needed now is for conference committees. I'll contact a couple of people to see if I can get those names. |
| 10:22 |
bshum |
kmlussier++ # tidying the website |
| 10:27 |
|
Christineb joined #evergreen |
| 14:34 |
* jeff |
looks to see what we did the last time we phased out an opensrf service |
| 14:38 |
|
rjackson_isl_ joined #evergreen |
| 14:38 |
|
Callender_ joined #evergreen |
| 14:39 |
jeffdavis |
Bmagic: with your test case for bug 1686194, an item with $0.20/day fine and, say, $100.00 max fines gets marked lost after 3 days, returned after 6, and overdues are "reinstated" at the max fines value of $100 (instead of 6 days X $0.20/day) - is that what you're seeing? |
| 14:39 |
pinesol_green |
Launchpad bug 1686194 in Evergreen 2.12 "Fine generation does not factor adjustments into max fines calculation" [Undecided,Confirmed] https://launchpad.net/bugs/1686194 |
| 14:41 |
|
kmlussier joined #evergreen |
| 14:42 |
Bmagic |
jeffdavis: yes, accept it's $10 max |
| 16:03 |
pinesol_green |
Launchpad bug 1411699 in Evergreen "TPAC: Don't load dojo widgets unless we actually need them (for autocomplete)" [Wishlist,Confirmed] https://launchpad.net/bugs/1411699 |
| 16:04 |
dbs |
kmlussier: 1411699 has two branches, one which could go in immediately |
| 16:04 |
dbs |
the other (rewrite to remove dojo) could follow on after 1687545 |
| 16:04 |
gmcharlt |
#info Patches for bug 1685840, bug 1681095, and bug 1411699 are commended to the dev community for general attention and testing |
| 16:04 |
dbs |
not to be confused with the rewrite to remove dojo for google books preview ;) |
| 16:04 |
pinesol_green |
Launchpad bug 1685840 in Evergreen "Google Books Preview should not require Dojo or any other framework" [Wishlist,Triaged] https://launchpad.net/bugs/1685840 |
| 16:04 |
kmlussier |
dbs: OK, thanks for clarifying. |
| 16:05 |
Dyrcona |
gmcharlt++ |
| 16:05 |
phasefx |
gmcharlt++ |
| 16:05 |
remingtron |
gmcharlt++ |
| 16:05 |
Dyrcona |
dbs: I have a question about google books preview: Do I need to do any special signup with Google in order to use/test it? |
| 16:06 |
jeffdavis |
I wanted to invite input on bug 1684988, but no discussion needed |
| 16:06 |
pinesol_green |
Launchpad bug 1684988 in Evergreen "Patron account can be retrieved without opt-in" [Undecided,New] https://launchpad.net/bugs/1684988 |
| 16:06 |
dbs |
Dyrcona: nope, it should just work |
| 16:14 |
jeff |
jeffdavis: i.e., "don't show patrons in searches until they have shown up at least once and been retrieved by barcode and 'opted in'" was the last summary I think I had, but is it just searches, or should patrons also not appear in other interfaces, etc? |
| 16:14 |
dbs |
we use it too. if a patron hasn't opted into sharing their account with another org_unit, they shouldn't be able to be retrieved via anything except barcode (so they can then opt in) |
| 16:14 |
kmlussier |
Dyrcona: And that reminds me that bug 1672434 still needs to be addressed. |
| 16:14 |
pinesol_green |
Launchpad bug 1672434 in Evergreen "Improved method for adding new bib records to test dataset" [Undecided,New] https://launchpad.net/bugs/1672434 |
| 16:15 |
jeff |
dbs: so, they shouldn't show up in a list of holds on a bib, for example? |
| 16:15 |
dbs |
in XUL there is leakage through other interfaces like item circ history, IIRC, but it would be preferred to not show up there |
| 16:16 |
jeff |
okay. is there a document (or commit message, wiki page, sitka/etc third party documentation) that describes how it currently works and how it should work? |
| 16:27 |
Dyrcona |
Maybe if patron from library A has an item checked out from library B, but hasn't opted in at library B, the latter should still the patron's info for that circulation? |
| 16:27 |
jihpringle |
if the item was lent to another library through interlibrary connect, checked out at that library and then returned to it's home library by the patron and something was wrong with the item (ie dvd was missing, item damaged) the owning library would need to know who borrowed the item so they could follow up with that patron's home library |
| 16:28 |
jihpringle |
(patrons in BC can return items to any public library regardless of where they checked it out) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:34 |
jeff |
okay, and the owning library would require the patron name rather than the patron's home library being the only one to look it up. interesting. |
| 16:36 |
jihpringle |
if the item was returned directly to the owning library without the info in the last circ the owning doesn't know which borrowing library to contact for followup |
| 16:36 |
jeff |
would displaying the library instead of the patron details in the circ history be useful in that case? |
| 00:44 |
dbs |
bshum++ # testing! |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:13 |
|
collum joined #evergreen |
| 08:24 |
|
Dyrcona joined #evergreen |
| 08:36 |
miker |
berick: re your z3950 comment, that looks normal to me. see.serverchoice should be an alias for keyword. is this master? |
| 14:37 |
Dyrcona |
@dessert [someone] |
| 14:37 |
* pinesol_green |
grabs some packages of Rolos® for tsbere |
| 14:40 |
kmlussier |
Ooh, Rolos! That's up there with coffee frappes in my book. |
| 14:41 |
berick |
anyone else seen and/or resolved the issue where connecting to ubuntu 16.04 causes XUL client to report "there was an error testing this hostname" even after adding an ssl exception -- yet it still lets you log in? |
| 14:41 |
berick |
i've tweaked a number of apache ssl.conf settings w/ no luck so far |
| 14:42 |
berick |
w/ a self-signed cert |
| 14:47 |
Dyrcona |
I have not seen that myself and I almost exclusively test with Ubuntu 16.04. I'm also running the staff client on Ubuntu, but not on the vm that runs the server. |
| 14:50 |
Dyrcona |
Yeah, I'm using a self-signed cert, too. |
| 14:52 |
berick |
hmm. same setup here. testing a different vm from windows now.. |
| 14:52 |
* berick |
triangulates |
| 14:52 |
Dyrcona |
Not enough free RAM at the moment to fire up the vm and try it right now. |
| 14:52 |
Dyrcona |
I've not ever noticed that. |
| 14:53 |
Dyrcona |
I did have an issue where I got the "Server doesn't support your version" but that was my fault for running the wrong client. :) |
| 14:54 |
dbs |
I mean XUL is primordial ooze |
| 14:54 |
kmlussier |
Bmagic / jlundgren: I'm going to sign out of Google Hangouts for now because I have to disappear for a bit. But feel free to stick around. |
| 14:54 |
Bmagic |
k |
| 14:54 |
berick |
dbs: maybe... |
| 14:55 |
berick |
i'll generate a dummy cert on 14.04 and test that |
| 14:55 |
* dbs |
grasps at straws |
| 14:56 |
Dyrcona |
Could be. Could be the list of ciphers. |
| 14:59 |
berick |
hm, no dice using a cert generated on 14.04 |
| 15:00 |
* gmcharlt |
decides to rebel |
| 15:00 |
* gmcharlt |
pays attention to the test message |
| 15:00 |
berick |
i've tried SSLCipherSuite ALL and SSLProtocol all, no love either way. |
| 15:02 |
berick |
and now I just realized that won't matter, becuase i'm using nginx. same cert, different ssl settings though |
| 15:03 |
Dyrcona |
Ah. I've not tested with a nginx proxy, yet. |
| 15:07 |
gmcharlt |
git-blame-for-giggle turns up senator today |
| 15:07 |
gmcharlt |
line 12 of pen-ILS/xul/staff_client/server/serial/pattern_wizard.js |
| 15:10 |
berick |
Dyrcona: dbs: good times.. if i enter hostname:7443 (apache) into the XUL client, add ssl exception, then go back to just hostname (default 443 -- nginx), the error goes away. |
| 15:36 |
dbs |
bshum: note to self: next phone needs a stylus |
| 15:38 |
Dyrcona |
:) |
| 16:04 |
miker |
dbs: you'll be happy to know I'm indeed using Service Workers for offline. https://www.talater.com/upup/ |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:37 |
Bmagic |
Anyone know off the top of their head why action.hold_transit_copy contains rows where the source=dest ? |
| 16:37 |
Bmagic |
Is it canceled holds on the hold shelf? |
| 16:37 |
berick |
is that the checkin holds local transit stuff? |
| 17:04 |
|
mmorgan left #evergreen |
| 17:05 |
|
jihpringle joined #evergreen |
| 18:43 |
|
Jillianne joined #evergreen |
| 19:17 |
jeffdavis |
I've confirmed bug 1686194 on 2.12 and tested/signed off dbwells's fix. I haven't tested on 2.11 or master so not sure if I should mark the bug as Confirmed for those versions? |
| 19:17 |
pinesol_green |
Launchpad bug 1686194 in Evergreen 2.12 "Fine generation does not factor adjustments into max fines calculation" [Undecided,Confirmed] https://launchpad.net/bugs/1686194 |
| 20:21 |
|
_adb left #evergreen |
| 20:30 |
|
_adb joined #evergreen |
| 03:41 |
|
neady joined #evergreen |
| 04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 11:31 |
|
bos20k joined #evergreen |
| 11:31 |
Dyrcona |
JBoyer: Neither. I'm just trying to use systemd. |
| 11:32 |
Dyrcona |
I am looking into moving to a distro that doesn't have systemd, but lack of time... |
| 11:33 |
jeff |
JBoyer: i threw together unit files for a test system here. it seemed to do the trick. |
| 11:33 |
JBoyer |
I see. There was a bit of a curve, yeah. :/ I've got an opensrf.service and clark-kent.service that work as expected on my laptop if anyone is interested in them. |
| 11:33 |
jeff |
and by "seemed to do the trick", i mean "i could reboot the single-VM test instance and end up with a running evergreen instance" |
| 11:34 |
Dyrcona |
JBoyer: I am opposed to systemd as it not being the "UNIX way." |
| 11:34 |
JBoyer |
If Evergreen is going to continue to prefer Debian based systems then I guess it would be a good idea to get a set of service / unit / whatevs in there. |
| 11:34 |
Dyrcona |
I've also had to reboot far more often with systemd than in the past. |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:18 |
dbs |
jeff++ JBoyer++ |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:30 |
gmcharlt |
miker++ # using createdb --template src_eg_database works a treat for standing up a test DB quickly |
| 12:33 |
Dyrcona |
gmcharlt: I've been doing that for quite a while. It's a lot faster than doing a pg_restore. :) |
| 12:45 |
|
sandbergja joined #evergreen |
| 12:55 |
|
mmorgan joined #evergreen |
| 13:14 |
Dyrcona |
gmcharlt | rhamby: Any reason not to push Lp 1545115 at this time? |
| 13:14 |
pinesol_green |
Launchpad bug 1545115 in Evergreen "config.circ_matrix_matchpoint and config.hold_matrix_matchpoint need a description field" [Wishlist,New] https://launchpad.net/bugs/1545115 - Assigned to Jason Stephenson (jstephenson) |
| 13:15 |
Dyrcona |
I'm looking at it and all the tests pass, and it just works in the web staff client. |
| 13:15 |
rhamby |
Dyrcona: I hadn't tested it in ages but since you and gmcharlt have I have no objection |
| 13:17 |
Dyrcona |
It just shows up in the xul client, too. Same dojo interface. :) |
| 13:19 |
Dyrcona |
rhamby: It looks good to me. The description shows up in the client and the database and that's all anyone could ask for. :) |
| 13:20 |
rhamby |
Dyrcona: well, there's the autofill input from the telepathy API that I'm working on but so far all it does it put in random strings from H.P. Lovecraft short stories. No idea why. |
| 13:20 |
Dyrcona |
Hehe |
| 13:22 |
* kmlussier |
feels bad because she suspects she never loaded that code on a Sandbox for sandbergja to test. :( |
| 13:24 |
Dyrcona |
I guess since gmcharlt signed off, it's OK to push. |
| 13:24 |
|
Newziky joined #evergreen |
| 13:25 |
rhamby |
kmlussier: busy people who volunteer for lots of things shouldn't feel bad when the prove occasionally human |
| 15:14 |
bshum |
gmcharlt: I'm going to try putting together a branch with all the i18n fixes out there and then running things through POT / PO sync for master. Right now, master is busted due to a new table that was added to the fieldmapper but is not part of the PO template. |
| 15:15 |
bshum |
Well, try running the sync using a Trusty server, so that we don't muck up the XUL stuff. |
| 15:15 |
gmcharlt |
bshum: sounds good |
| 15:15 |
bshum |
If the branch tests okay, then I'll put it somewhere and just request to get the whole thing merged for master to get us back up to date and working |
| 15:47 |
|
jvwoolf joined #evergreen |
| 15:50 |
|
jvwoolf left #evergreen |
| 15:51 |
|
mmorgan joined #evergreen |
| 15:59 |
bshum |
dbs: An i18n question or thought... do we want to run the make install for a specific locale and update the POs in git with the latest id data for things like db.seed? |
| 16:00 |
bshum |
Right now, we're not changing the final PO files in git with that data, but I wonder if we should sync that up at some point. |
| 16:05 |
|
khuckins_ joined #evergreen |
| 16:15 |
dbs |
bshum: hmm, probably? |
| 16:16 |
dbs |
I know, that's not particularly helpful |
| 16:16 |
bshum |
dbs: I guess the only reason I'd want to see it included in git is so that we can get towards a clean repo |
| 16:16 |
bshum |
Where changes are actually meaningful |
| 16:17 |
bshum |
Not just generated file differences |
| 16:17 |
bshum |
Though, speaking on that, I still have to go back and figure out what should or shouldn't be added to .gitignore |
| 16:17 |
bshum |
At first I thought everything, then I decided maybe nothing, now I'm thinking maybe a few new things |
| 16:18 |
bshum |
dbs: Either way, if you don't have a strong preference against it, I'd be inclined to add a commit to my new branch to test adding those into history then. Thanks :D |
| 16:18 |
* bshum |
will keep experimenting |
| 16:27 |
dbs |
You are talking about the PO files and not the generated .sql files, etc, right? |
| 16:28 |
bshum |
dbs: Correct, the PO files themselves have a bunch of IDs and stuff already in them |
| 16:29 |
dbs |
okay, yeah that sounds sane |
| 16:29 |
bshum |
And so far, my test with pocommentclean seems to be handling fixing them okay |
| 16:29 |
dbs |
yayz |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:44 |
|
Jillianne joined #evergreen |
| 16:48 |
* mmorgan |
notices that in Checkout in the xul client, spaces are trimmed from the beginning and end of barcodes, so if a leading or trailing space is entered by mistake, it will be ignored and the checkout will proceed. |
| 16:48 |
mmorgan |
I don't see that the same trimming is happening at checkin. |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:58 |
|
Callender joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:47 |
dbwells |
bshum: Are you going to to ahead and push the pot/po bits to rel_2_12? If not, I can take care of it whenever you're done looking them over. |
| 09:50 |
|
rlefaive joined #evergreen |
| 09:54 |
bshum |
dbwells: Feel free to push away |
| 09:59 |
dbwells |
bshum: will do, thanks |
| 10:06 |
|
jvwoolf joined #evergreen |
| 10:15 |
dbwells |
bshum: So, I noticed in this po push the final deletion of string like "Example Branch 2". It seems like we would still want those translated for anyone trying out Evergreen. Perhaps we should add Open-ILS/tests/datasets/sql/libraries.sql to the translation process? |
| 10:16 |
bshum |
dbwells: I noticed that too for other things I was testing |
| 10:16 |
bshum |
dbwells: And yeah, adding the sample dataset as a translation option sounds like a good idea |
| 10:17 |
bshum |
But building that out will require a little more thought I think |
| 10:17 |
bshum |
Probably similar to how we do db.seed-data-values.sql now I guess. |
| 10:18 |
gmcharlt |
maybe? sample data (as opposed to test case data) strikes me as something where we don't necessarily want _mechanical_ localization |
| 10:18 |
gmcharlt |
or, rather, where such a thing would be less ideal than getting somebody from the relevant locale to put together realistic data |
| 10:19 |
gmcharlt |
anyway, here's an easy-peasy webstaff pullrequest for someobdy to test and merge: bug 1685232 |
| 10:19 |
pinesol_green |
Launchpad bug 1685232 in Evergreen "webstaff: pcrud.apply() does not work" [Medium,New] https://launchpad.net/bugs/1685232 |
| 10:19 |
gmcharlt |
also pointing out that pcrud.apply(), when it works, can be quite handy |
| 10:21 |
berick |
gmcharlt: hm, i thought I fixed that already. |
| 15:39 |
|
Jillianne joined #evergreen |
| 15:54 |
|
khuckins_ joined #evergreen |
| 16:29 |
|
khuckins__ joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:19 |
|
jvwoolf left #evergreen |
| 21:02 |
|
khuckins__ joined #evergreen |
| 02:56 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:46 |
|
rlefaive joined #evergreen |
| 07:59 |
|
rlefaive_ joined #evergreen |
| 14:54 |
Dyrcona |
It's ugly, but I guess necessary. |
| 14:55 |
Dyrcona |
Anyway, I'm all for "making it easier to plop fieldmapper into angular input widgets" |
| 14:57 |
berick |
gmcharlt: ah, that's too bad about getterSetter not being supported everywhere. your solution looks reasonable to me. certainly better than a lot of ad-hoc cross-talking |
| 15:01 |
* Dyrcona |
is testing ngingest and it appears to be working. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 16:05 |
|
maryj joined #evergreen |
| 16:24 |
|
mmorgan joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:58 |
|
khuckins_ joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:17 |
|
dteston joined #evergreen |
| 17:21 |
pinesol_green |
[evergreen|Dan Wells] Forward-port 2.11.4 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d3e591d> |
| 18:04 |
|
khuckins_ joined #evergreen |
| 19:16 |
bshum |
Dyrcona++ # for regex help |
| 19:16 |
bshum |
berick++ # for ansible advice |
| 19:17 |
bshum |
I'm doing a full test of the new additions I've made for i18n before I push it to the collab |
| 19:17 |
bshum |
I think I've got all the kinks worked out, and if so, we shall have i18n options built in for the ansible installer very soon |
| 19:17 |
* bshum |
waits for apt-get upgrade to finish on his fresh VM |
| 19:19 |
Dyrcona |
Aw, shucks. 'Twerent' nothin'. |
| 19:24 |
* bshum |
watches the magic unfold |
| 19:40 |
bshum |
Yay! It worked! :D |
| 04:19 |
bshum |
Have to learn how to parse that better to find the culprit issue |
| 04:20 |
* bshum |
stops digging his grave and tries going back to sleep now |
| 04:24 |
pastebot |
"bshum" at 64.57.241.14 pasted "ar-JO error log with fieldmapper parsing" (1 line) at http://paste.evergreen-ils.org/83 |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 09:53 |
Dyrcona |
charsets-- |
| 09:53 |
kmlussier |
Dyrcona: Yes, that's right. Because we missed the maintenance releases last month, and there were a lot of patches in the 2.10 branch that are not yet in a tarball. |
| 09:54 |
kmlussier |
dbwells: Ah, ok. Thanks for the clarification. I was going by the call for buildmasters gmcharlt put out last month. |
| 09:55 |
terran |
kmlussier: Nobody has tested this yet - https://bugs.launchpad.net/evergreen/+bug/1681943 |
| 09:55 |
pinesol_green |
Launchpad bug 1681943 in Evergreen "Improve Responsive Design in My Lists" [Undecided,New] |
| 09:56 |
kmlussier |
terran: Ah, yes. Thanks for the reminder. Given the poor state of the current lists on a small screen, I was planning to treat that as a bug fix. |
| 09:57 |
berick |
kmlussier: i threw my hat in for 3.0 builder (as far as I knew) |
| 16:13 |
dbs |
although it's translating the msgids, not the msgstr. go home google |
| 16:14 |
remingtron |
Bmagic: have you had a chance to build a tarball for 2.12? |
| 16:14 |
Bmagic |
working on it atm |
| 16:14 |
remingtron |
cool, let me know when you want some testing |
| 16:15 |
Bmagic |
shouldn't be too long now (I have been pulled around to all kinds of stuff today ) |
| 16:16 |
Bmagic |
oh, and to make sure, I'm using rel_2_12 ? |
| 16:16 |
gmcharlt |
eyp |
| 16:22 |
gmcharlt |
you'd create a new tags/rel_2_12_1 branch just before doing the make_release step |
| 16:22 |
Bmagic |
This will be a first then |
| 16:29 |
* Dyrcona |
has much rebasing to do today and tomorro. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:09 |
|
mmorgan left #evergreen |
| 17:27 |
|
dcook__ joined #evergreen |
| 18:06 |
|
dcook joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
JBoyer joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:53 |
|
collum_ joined #evergreen |
| 09:38 |
* csharp |
discovers nice tool for initial diagnosis of SPF problems: http://www.openspf.org/Why |
| 09:39 |
bshum |
csharp++ # always handy :) |
| 10:07 |
bshum |
fwiw, I tested my branch changes for newer nodejs for fresh wheezy and it installed with the -developer target there too. |
| 10:38 |
auvajs |
hello.. I succesfully installed Evergreen :)) my first question: how can I change settings so that the stuff browser client is not located at https://localhost/eg/staff/login but on address like https://staff.mydomain.com ? I installed evergreen on a vps so that accessing the site via the vps localhost is kinda uncomfortable.. |
| 10:42 |
bshum |
auvajs: Congrats on the successful install :) |
| 10:44 |
|
auvajs joined #evergreen |
| 15:27 |
berick |
error, success, and zero |
| 15:27 |
berick |
so you might need some additional logic in there to chose the right sound |
| 15:27 |
phasefx |
gotcha |
| 15:27 |
berick |
and probably remove the error sound from the error handler or it will fire 2 times |
| 15:28 |
berick |
patronSvc.patrons.length == 0 for the zero-hits test |
| 15:30 |
berick |
well, no, that's probably over complicating it |
| 15:30 |
berick |
leave error.patron.by_search where it is. put success.patron.by_search and warning.patron.by_search both in the main resolve handler (where warning.patron.by_search is now) |
| 15:31 |
berick |
and just check ofr patronSvc.patrons.length to determine which of those 2 to fire |
| 15:31 |
phasefx |
berick: so I'm assuming putting something in the error handler slot will keep finally from firing.. unless maybe you do a return false; or somesuch from it? |
| 15:32 |
berick |
no, finally always fires |
| 15:32 |
phasefx |
k |
| 15:32 |
berick |
so it makes sense to close the dialog there, because it should always go away, but not so much the sounds, because you don't know how you got there, unless you add other context information |
| 15:34 |
phasefx |
berick: look sane? http://paste.evergreen-ils.org/80 well, need to change close to close() |
| 15:35 |
phasefx |
and get rid of that explicit success earch |
| 15:35 |
phasefx |
sound |
| 15:36 |
phasefx |
http://paste.evergreen-ils.org/81 |
| 15:36 |
phasefx |
well, that could make warning trump the error |
| 15:37 |
phasefx |
so do which_sound <> 'error' && patronSvc.patrons.length == 0 |
| 15:37 |
phasefx |
or == 'success' && etc |
| 15:37 |
* phasefx |
tests all this |
| 15:38 |
berick |
yeah, i think that would do it |
| 15:43 |
phasefx |
berick: found an unrelated bug.. doesn't seem to be a big deal, but if I do a patron search get results, then try to clear out the search form and hit Search again, sometimes I'll get cached results from a previous search |
| 15:44 |
phasefx |
on the bright side, sounds are working :) except for 0 results on a completely empty search, but I'm not inclined to do anything about that |
| 16:02 |
Nina_ |
join |
| 16:03 |
Nina_ |
Hello! |
| 16:30 |
|
jvwoolf left #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:16 |
bshum |
dbs: The more I work on i18n stuff for db.seed fixing, the more I'm starting to think we're missing a major step between newpot and update_pofiles in https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 17:17 |
bshum |
dbs: When I run the option for "make update_all_locales" in the directory to sync the PO templates against the existing PO files, I get a ton of changes |
| 17:17 |
bshum |
And in reading through our wiki steps for release making, I don't think that's happened |
| 17:17 |
bshum |
Which is why there's such a massive upheaval when I run it locally. |
| 17:18 |
bshum |
and it generates out a whole slew of fresh PO files (mostly empty of course) for all the various locales and files we now translate for. |
| 17:18 |
bshum |
I'm not 100% sure if we want it to generate all these empty translation files or not yet. My next step in testing is to see what it'll do with PO sync against the bzr branch for exported translations from LP |
| 17:19 |
bshum |
But I think we might need to invoke some extra steps here |
| 20:08 |
|
Guest35655 joined #evergreen |
| 20:25 |
|
kmlussier joined #evergreen |
| 20:27 |
dbs |
bshum: yeah, translations.launchpad.net / pootle etc are effective just abstracted front-ends for editing those PO files |
| 00:46 |
|
dbwells_ joined #evergreen |
| 00:50 |
|
remingtron joined #evergreen |
| 00:50 |
|
dbwells_ joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:31 |
|
Callender joined #evergreen |
| 08:13 |
|
kmlussier joined #evergreen |
| 09:37 |
Dyrcona |
Java 2 was just marketing hype. |
| 09:37 |
Dyrcona |
They (Oracle) still call it JDK 9, JDK 8. |
| 09:37 |
Dyrcona |
So they have split versioning going on. |
| 09:39 |
Dyrcona |
And my created database finished a few minutes ago. Time to test my eg_staged_bib_overlay script. |
| 09:40 |
Dyrcona |
OK. So I messed up an option, obviously. :) |
| 09:42 |
Dyrcona |
All right. I omitted --dbhost, and this gives me an opportunity to make the script more generic. |
| 09:43 |
|
krvmga joined #evergreen |
| 16:11 |
jeff |
etc :-) |
| 16:12 |
mmorgan |
:) |
| 16:13 |
jeff |
Bmagic: yeah, only minor changes required, and one would probably be handled automatically by git and the other would be a no-op, but I'm commenting on bug 1331174 right now. |
| 16:13 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:37 |
|
khuckins__ joined #evergreen |
| 16:39 |
kmlussier |
I tried installing the web client again. I'm getting an error when I run npm install. https://pastebin.com/qevBnNc0 is what I see in the logs. |
| 16:52 |
jeff |
kmlussier: is that at the point where you've installed the LTS version of node and you're running "sudo npm install -g grunt-cli"? |
| 17:04 |
bshum |
I installed everything earlier this afternoon and all was fine |
| 17:05 |
jeff |
bshum: what version of node and npm do you have installed, and what distro are you using? |
| 17:05 |
kmlussier |
OK, I'm going to have to investigate later. I need to run off for the evening. |
| 17:05 |
bshum |
jeff: I was testing the Ubuntu 16.04 ansible stuff |
| 17:05 |
bshum |
So it used the makefile developer target to install node, etc. |
| 17:06 |
bshum |
I'm spinning up a new fresh VM to try that out again |
| 17:06 |
bshum |
On my other computer |
| 17:07 |
jeff |
bshum: looks like you would end up with nodejs-legacy 4.2.6~dfsg-1ubuntu4 in that case, which might be the difference between success and failure in your case vs kmlussier's case |
| 17:08 |
jeff |
bshum: i.e., what might have worked for you earlier today on xenial might not work for kmlussier on trusty. |
| 17:08 |
bshum |
jeff: Oh I see trusty |
| 17:08 |
bshum |
Ah okay no I just didn't scroll up far enough |
| 17:08 |
bshum |
I haven't built on trusty lately |
| 17:08 |
jeff |
16:55:27 < kmlussier> jeff: No. I run ubuntu-trusty-developer Makefile.install target as the root user in an earlier step, which should install the dependencies for me. |
| 17:09 |
bshum |
Or at least, not before the conference |
| 17:09 |
bshum |
It could be also the new stuff we changed for bower->npm... maybe that's unhappy with something on trusty :\ |
| 17:09 |
bshum |
And I broke it when we merged that |
| 17:09 |
bshum |
I'll spin up a trusty VM to check I guess |
| 17:34 |
* bshum |
thumbs his fingers waiting for Evergreen to finish installing pre-reqs |
| 17:36 |
bshum |
Okay, moment of truth coming up |
| 17:39 |
bshum |
Yup, unhappy :( |
| 17:43 |
bshum |
So it is related to the bower/npm switchup |
| 17:43 |
bshum |
It's choking on "angular-order-object-by": "rxfork/ngOrderObjectBy#npm" |
| 17:43 |
bshum |
Maybe our aged version doesn't know what to make of that line |
| 17:44 |
bshum |
I'll try installing a newer node and seeing what it does differently with that. |
| 17:48 |
* bshum |
hacks his trusty makefile to use the wheezy style for installing newer node |
| 17:54 |
* bshum |
waits, and waits, and keeps waiting... |
| 18:02 |
bshum |
Hmmmm |
| 18:02 |
bshum |
Yeah |
| 18:02 |
bshum |
Okay |
| 18:03 |
bshum |
So using a newer version of node helps with the problem |
| 18:03 |
bshum |
But I have discovered that the Makefile for Wheezy has not been updated to work with a newer version of node |
| 18:04 |
bshum |
It's still installing from source for version 0.10.28 |
| 18:04 |
bshum |
Cause that's what it still says in the Makefile.install source file |
| 18:04 |
bshum |
We fixed it in the eg_wheezy_installer for random repo, for the live test building |
| 18:04 |
bshum |
But the actual installer isn't working quite right |
| 18:05 |
bshum |
So we should rip all that stuff out |
| 18:05 |
bshum |
But yeah, Trusty also won't work without a newer node version |
| 18:05 |
* bshum |
goes to eat |
| 18:06 |
* bshum |
brings his laptop to think with while he eats |
| 18:42 |
bshum |
@later tell kmlussier Check out my work in progress branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/newer-node-for-wheezy-and-trusty |
| 18:42 |
pinesol_green |
bshum: The operation succeeded. |
| 18:42 |
bshum |
I ran those Makefile changes through a test on Trusty and ended up with newer nodejs and able to run all the npm package installs for Trusty |
| 18:42 |
bshum |
Same changes should apply towards Wheezy too |
| 18:43 |
bshum |
If it works out, we need some tweaks to the README instructions so that the Wheezy specific steps can go away and we can just stick to recommending use of the -developer make target |
| 18:44 |
bshum |
I think it ought to work for the debian-wheezy-developer target too. |
| 18:44 |
bshum |
But it's untested |
| 18:44 |
bshum |
I'll try more of it later on. |
| 18:44 |
* bshum |
goes out to enjoy his Friday :) |
| 18:47 |
bshum |
dbs++ # for new nodejs inspiration from the auto installer scripts |
| 18:48 |
bshum |
kmlussier++ # for helping to find the problem |
| 18:48 |
* bshum |
disappears |
| 18:57 |
|
kmlussier joined #evergreen |
| 18:58 |
kmlussier |
bshum++ |
| 21:05 |
jeff |
Looking at circ policy for a library that makes a circ-duration distinction between "new" items and "replacement" items... currently they use a circ modifier on the "new" items, and while it's so tempting to use "Item Age <" in a circ policy matrix, that won't do it... |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:51 |
|
dbs_breaker_of_t joined #evergreen |
| 06:52 |
dbs_breaker_of_t |
Okay, now to find out why that path wasn't happy. |
| 09:26 |
|
maryj joined #evergreen |
| 09:28 |
|
yboston joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:42 |
kmlussier |
dbs: Sometimes phasefx will do an unscheduled livetest run if a fix to the tests is added. |
| 09:46 |
|
terran joined #evergreen |
| 10:00 |
jeff |
just as i was about to remark on how useful irc logs can be, i find a case where i xkcd 979'd myself. |
| 10:00 |
jeff |
"oh hey, there's the error." |
| 15:50 |
Dyrcona |
I haven't tried Haskell, though I've sniffed around the edges. |
| 15:50 |
Dyrcona |
An erlang implementation/transport for OpenSRF seems natural enough without ejabberd. :) |
| 15:51 |
|
kmlussier joined #evergreen |
| 15:51 |
Dyrcona |
But erlang syntax is really weird, and I look at back at the sample/test programs I wrote in 2010/2011, and I wonder, "What does that do, again?" |
| 15:52 |
Dyrcona |
I should write an OpenSRF/gateway client in Emacs Lisp. I might actually have a use for that. |
| 15:52 |
jonadab |
Yeah, I haven't tried Haskell either; from what I know of it, it seems sort like lisp with a higher learning curve, for smarter programmers. Or something. |
| 15:53 |
Dyrcona |
s/smarter programmers/masochists/ # Fixed that for you. :) |
| 16:11 |
Dyrcona |
Lots of database stuff going on. |
| 16:12 |
Dyrcona |
New fingerprints, new 901$s field, browse and facet ingest...something else that update 9 million records in our system, but runs fast compared to the others. |
| 16:21 |
|
mmorgan joined #evergreen |
| 16:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:33 |
bshum |
yay! success! |
| 16:33 |
bshum |
dbs++ |
| 16:36 |
Dyrcona |
:) |
| 18:16 |
|
jvwoolf left #evergreen |
| 18:20 |
|
Jillianne joined #evergreen |
| 19:45 |
* dbs |
breathes a sigh of relief |
| 19:48 |
jeff |
those hourly test failure charges would have made for a terrible weekend. ;-) |
| 19:52 |
dbs |
jeff: that reminded me to shut down my GCE instance |
| 21:04 |
* gmcharlt |
has the first development update blog post queued up to post tomorrow morning |
| 21:12 |
* bshum |
contemplates renaming "2.next" to "3.next" in LP |
| 08:54 |
dbs |
because they were "new" :) |
| 08:54 |
gsams |
oh, so that's why my RSS went crazy |
| 08:54 |
kmlussier |
Ah! That explains everything. I thought the problem was with the app I use to republish the feed on Twitter. |
| 08:54 |
dbs |
I managed to add a "umm, max of 2 new entries per feed" limit after that |
| 08:55 |
dbs |
but too late for the twitter feed (and I bet it shuffled all of the other entries around too) |
| 08:55 |
dbs |
sorry for the churn folks |
| 08:55 |
dbs |
yes I need coffee as I dive in to see what happened with the test build... I see the karma tests failed but WHY? :) |
| 08:56 |
dbs |
thanks for cleaning up the twitter feed kmlussier |
| 08:56 |
gsams |
@coffee dbs |
| 08:56 |
* pinesol_green |
brews and pours a cup of Bonsai Blend Espresso, and sends it sliding down the bar to dbs |
| 08:56 |
kmlussier |
The Twitter stuff made me forget there was a test failure. |
| 08:57 |
kmlussier |
I'm guessing it's related to the removal of bower? |
| 08:59 |
|
rlefaive_ joined #evergreen |
| 09:00 |
dbs |
yep |
| 09:01 |
|
finnx joined #evergreen |
| 09:02 |
|
finnx joined #evergreen |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:06 |
dbs |
oh, I have a theory. live-test builds runs "grunt build && grunt test" whereas our install instructions say to use "grunt all" |
| 09:07 |
dbs |
but just tried that with no failures, albeit not on a wheezy system. hmm |
| 09:09 |
dbs |
ah, [33mWARN [watcher]: [39mPattern "/home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/node_modules/angular-sanitize/angular-sanitize.min.js" does not match any file. |
| 09:13 |
dbs |
weird, it's installing the right version of angular-sanitize. how is it not finding that file? |
| 09:15 |
Dyrcona |
No wonder reporting is so slow...There are so many views that depend on action.all_circulation, at least in our database. |
| 09:25 |
|
yboston joined #evergreen |
| 09:32 |
miker |
dbs++ # cache busting |
| 14:18 |
berick |
that's probably it |
| 14:18 |
berick |
oh |
| 14:18 |
berick |
i would expect that to work.. |
| 14:19 |
csharp |
I expected it too - I'm going to do some more testing on it to try and nail down what's up |
| 14:22 |
|
rlefaive joined #evergreen |
| 14:32 |
kmlussier |
csharp++ # acq bug squashing |
| 14:37 |
csharp |
berick: behavior right now - on a 4-lineitem PO with one copy per lineitem, I activate it, receive 3 copies (which marks the lineitem received), cancel the copy on the last item (which doesn't affect the lineitem status) then I use the dropdown menu to cancel the lineitem - PO stays "on-order" |
| 16:37 |
Dyrcona |
Yeap. That's what happened, and I have four stashes hanging around. |
| 16:38 |
Dyrcona |
Too much swinging from branch to branch. |
| 17:01 |
berick |
csharp: https://bugs.launchpad.net/evergreen/+bug/1257915/comments/14 |
| 17:01 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" [Medium,Confirmed] - Assigned to Chris Sharp (chrissharp123) |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
berick |
gmcharlt: alas, rollover_phone_to_print.pl to print has been disabled here for a while. i'm in the dark on that one. I can eyeball it, though. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:31 |
csharp |
berick: rock on - I'll give your branch a go |
| 18:59 |
|
jvwoolf joined #evergreen |
| 19:26 |
bshum |
dbs: I just added some thoughts for use of pocommentclean on https://bugs.launchpad.net/evergreen/+bug/1681864/comments/1 |
| 19:26 |
pinesol_green |
Launchpad bug 1681864 in Evergreen "db-seed.po files need cleanup to remove duplicate IDs from generated localized seed data" [Medium,Confirmed] |
| 19:26 |
bshum |
In my very limited initial test, I think it'll help us to fix all the IDs in the comments. |
| 19:27 |
* bshum |
will experiment further after dinner. Or maybe tomorrow if he decides to go to bed early instead |
| 19:55 |
|
dcook joined #evergreen |
| 20:12 |
csharp |
berick++ # your branch works for me - signoff on the way |
| 20:39 |
jonadab |
That building was _residential_? I assumed it was office spaces. |
| 21:20 |
jonadab |
Yeah, at the conference. |
| 21:20 |
jonadab |
The blue one. |
| 21:20 |
|
dcook joined #evergreen |
| 22:33 |
dbs |
bshum++ |
| 22:34 |
dbs |
I've had a few issues of the Launchpad "try again later" over the past couple of weeks, yeah |
| 22:34 |
* dbs |
tries to concentrate on the wheezy build issue |
| 22:47 |
dbs |
once this is fixed, maybe it's time to consider jessie or xenial (or both) as the live-testing platforms? |
| 22:47 |
dbs |
wheezy is dead in a year: https://wiki.debian.org/LTS |
| 23:11 |
berick |
can practically hear it wheezing |
| 23:13 |
* dbs |
suspects 'npm --version' returning 1.x when installed with nodejs 0.10.x, vs. npm 3.x with a more modern mode, might be a factor |
| 23:14 |
dbs |
"npm install -g npm" gets us to npm 4.x (and a warning that nodejs 0.10.x is ancient, what are you thinking?!?) and sure enough, angular-sanitize is now installed as a dependency of ng-toast. |
| 23:15 |
dbs |
and that fixed the tests. |
| 23:18 |
dbs |
we should consider updating some of those deps; grunt-cli 0.1.13 was 2014, and as of 2016-04 was at 1.2.0 |
| 23:20 |
dbs |
similar to grunt itself (0.4.5 2014-05; 1.0.1 2016-04) |
| 23:27 |
dbs |
but then we install grunt-cli globally and use that so we get the latest anyway? hmm |
| 23:32 |
dbs |
anyway, pushed a fix to the wheezy_installer so hopefully we'll see the tests back to happy tomorrow |
