| 01:57 |
* bshum |
will look at it more tomorrow |
| 02:01 |
jeffdavis |
bshum++ |
| 03:12 |
|
RBecker joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:28 |
csharp |
~~ |
| 07:28 |
csharp |
 |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:30 |
|
maryj joined #evergreen |
| 10:26 |
bshum |
So it looks like there are three PO templates that are failing to import |
| 10:26 |
bshum |
Two of them appear to be tests |
| 10:27 |
bshum |
build/i18n/tests/data/sql2pot.pot |
| 10:27 |
bshum |
and build/i18n/tests/data/testidl.pot |
| 10:27 |
bshum |
Both of them are dying cause of a missing end qoute on line 6 where the timestamp should be, I guess. |
| 10:28 |
bshum |
I'm not really sure we should worry about these, given that they appear to be really ancient test files for PO Templates, but maybe we should either fix the line, or get rid of the file altogether if they no longer serve a purpose. |
| 10:29 |
bshum |
The other one that appears to be broken is build/i18n/po/multiclass_search_help.html/multiclass_search_help.html.pot |
| 10:29 |
bshum |
Which seems to be pulling the entire HTML in, instead of finding any specific strings |
| 10:29 |
bshum |
And it's choking cause it's expecting a PO template, not raw HTML |
| 10:31 |
bshum |
Since multiclass_search_help.html is part of the XUL server files, I'm not sure if we shouldn't also deprecate that and remove the offending POT and POs that can't be translated anyways |
| 10:35 |
Dyrcona |
I'm still working on setting up Syrup on an alternate host, and I really have no idea what I'm doing. The README is really short on details and seems to assume that you know Django and otherwise know what you're doing. |
| 10:35 |
Dyrcona |
Do I just have to change the settings in localsettings.py and it will just work? For some reason, I doubt that. |
| 10:36 |
jeff |
yep! my experience was similar, though possibly with an AM/PM inversion! |
| 10:42 |
Dyrcona |
So, I have to run the manage.py script in each instance... OK. |
| 10:43 |
Dyrcona |
The vm has a non-routing IP address. It's only visible at central site or via vpn. |
| 10:44 |
jeff |
assuming you're starting with Django 1.4.x, all of the top-level DATABASE_* settings in local_settings.py.example should be commented out, and you should use the example DATABASES= hash to set the various settings. |
| 10:44 |
dbs |
bshum: I think the POT tests are still useful. Looks like there is a small delta required for one or two of the tests to still pass. |
| 10:44 |
bshum |
dbs: Yeah I was just wondering if we run them as part of the nightly test |
| 10:44 |
jeff |
under DATABASES[default], i set ENGINE, NAME, USER, PASSWORD, HOST, and PORT |
| 10:45 |
Dyrcona |
jeff: Yes. I've copied everything from production and just modified the values. |
| 10:45 |
bshum |
dbs: Well, daily I guess. |
| 10:45 |
jeff |
for postgres, i used 'ENGINE': 'django.db.backends.postgresql_psycopg2' |
| 10:45 |
Dyrcona |
jeff: ditto. :) |
| 10:45 |
bshum |
I kind of wish there was a way of excluding the tests from going to LP translations though. |
| 10:45 |
jeff |
Dyrcona: ah! then you're at least starting from a working install, which is possibly better off than starting from scratch! |
| 10:45 |
Dyrcona |
Could be. :) |
| 10:46 |
Dyrcona |
I'm changing the db and the evergreen instance that it talks to. |
| 02:09 |
|
Jillianne2 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
agoben joined #evergreen |
| 08:16 |
|
annagoben joined #evergreen |
| 10:56 |
pinesol_green |
Launchpad bug 1677000 in Evergreen "There is no visual indicator that a patron record has notes in the Web client" [Medium,In progress] https://launchpad.net/bugs/1677000 - Assigned to Jason Etheridge (phasefx) |
| 10:58 |
kmlussier |
Actually, that's not really my question. From what I can tell, some of the commits from collab/phasefx/webstaff-bugs have been merged, but not all of them. Is that right? |
| 10:59 |
* kmlussier |
isn't quite sure what the purpose of the collab branch is |
| 11:07 |
cesardv |
kmlussier: phasefx can correct me if I'm wrong, but basically it's a way to make sure everyone's commits play nicely with each other, avoid merge conflicts, and for testing changes that depend on other changes, or just general testing |
| 11:09 |
kmlussier |
Yeah, I guess I just don't understand why we do things differently for the web client than we do for other parts of the software, particularly when it comes to bug fixes. They could just be merged and backported once tested IMO. |
| 11:10 |
Dyrcona |
The only advantage of collab branches is multiple people can commit to them. |
| 11:10 |
Dyrcona |
That may be why it is being used. |
| 11:11 |
phasefx |
kmlussier: feel free to remove me. I'm not 100% on that branch either |
| 11:15 |
phasefx |
I think the notion is that folks could cherry-pick commits into master as needed but it made things simpler to batch up changes to test over here |
| 11:20 |
* gmcharlt |
notes that given the past practice of doing merges of big webstaff branches where there was relatively little review, at least at the individual patch level, with the bug fixes we've been moving back into a more "normal" workflow |
| 11:22 |
* csharp |
wishes his day job gave him more bandwidth for EG dev :-/ |
| 11:22 |
gmcharlt |
the bugfix collab branch is, at root, more of an artifact of how that particular bugfixing sprint is organized on Equinox's end |
| 14:18 |
Dyrcona |
@clone |
| 14:18 |
pinesol_green |
Dyrcona: I see nothing, I know nothing! |
| 14:18 |
Dyrcona |
:) |
| 15:19 |
pinesol_green |
[evergreen|Ben Shum] i18n: fix syntax for Spanish lang.dtd - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed7ae7c> |
| 15:37 |
|
collum joined #evergreen |
| 16:24 |
|
kmlussier joined #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:52 |
|
kmlussier joined #evergreen |
| 16:52 |
bshum |
@dessert |
| 16:52 |
* pinesol_green |
grabs some Chocolate Eclairs for bshum |
| 01:30 |
|
Jillianne joined #evergreen |
| 02:09 |
bshum |
And found it |
| 02:09 |
bshum |
Freddy's problem with the closed date editor is an issue with the Spanish translation file for lang.dtd and the closed date editor. |
| 02:10 |
bshum |
staff.server.admin.closed_dates.editor.allmultiday.format in lang.dtd |
| 02:10 |
bshum |
There's a special note saying: Translators: do not translate "<b>YYYY-MM-DD</b>" or "<b>HH:MM</b>" |
| 02:11 |
bshum |
And the Spanish translation there is |
| 02:12 |
bshum |
"Nota: Todas las fechas deben tener el formato <b> AAAA-MM-DD </ b>. Los " |
| 02:12 |
bshum |
"tiempos deben tener la forma <b> HH: MM </ b>" |
| 02:12 |
bshum |
Changing that back to the right variables, things worked |
| 02:12 |
bshum |
So, bleh |
| 02:13 |
bshum |
Changing that AAAA back to YYYY and made things look closer to the original and things worked out |
| 02:15 |
bshum |
And making it AAAA is fine too. |
| 02:16 |
bshum |
It's probably more of a syntax issue with the code itself, hmm |
| 02:18 |
bshum |
And there is it... |
| 02:18 |
bshum |
The problem is that </ b> is used in the translation. There's an extra space between the / and b in those ending tags |
| 02:18 |
bshum |
Removing the space fixes the problem |
| 02:19 |
bshum |
For installed version; it'll be the entry for that string in /openils/var/web/opac/locale/es-ES/lang.dtd |
| 02:19 |
bshum |
Editing it to remove that space fixes the syntax error in my testing |
| 02:24 |
* bshum |
goes to sleep happier knowing the answer to the problem :) |
| 03:12 |
|
remingtron_ joined #evergreen |
| 03:12 |
|
dbwells_ joined #evergreen |
| 03:23 |
|
Jillianne2 joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
csharp |
bshum++ |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 09:07 |
|
jvwoolf left #evergreen |
| 09:09 |
|
_adb joined #evergreen |
| 09:10 |
|
maryj joined #evergreen |
| 09:11 |
* Dyrcona |
contemplates making /etc/hosts entries for some of his test vms. |
| 09:15 |
* csharp |
does that |
| 09:21 |
* Dyrcona |
actually does it, too. :) |
| 09:22 |
Dyrcona |
Maybe now, I can copy and paste URLs from my gitlab test vm and they'll actually work. :) |
| 09:32 |
|
Freddy_Enrique joined #evergreen |
| 09:34 |
Dyrcona |
acquisitions-- |
| 09:35 |
Dyrcona |
Freddy_Enrique: Have a look at this http://irc.evergreen-ils.org/evergreen/2017-06-16#i_310838 |
| 12:02 |
Stompro |
bshum, That is what I mean. Admin -> Server Admin -> Z39.50 Servers |
| 12:02 |
bshum |
Stompro: Then yeah, adding a new server works that way. Did you also define attributes for that new server for search purposes? |
| 12:03 |
* bshum |
never really ever used the GUI for it, and just poked directly at the DB tables |
| 12:05 |
Stompro |
bshum, Yes, I just added one attribute for title to test. Works fine from the yaz-client... but no results when tried from the EG client for the same search. |
| 12:10 |
|
mmorgan joined #evergreen |
| 12:17 |
bshum |
maybe someone else will have more ideas to try. I only remember that those code/format/truncation settings for z39.50 attributes can get weird depending on the z39.50 server you're trying to talk to |
| 12:18 |
bshum |
Not all servers are configured the same way, so copying "title" attribute from one to another doesn't guarantee success. |
| 16:16 |
mmorgan |
I'm going to conclude that the status was edited by the audit_user at the audit_time. |
| 16:16 |
mmorgan |
And not puzzle about it any longer. |
| 16:16 |
Dyrcona |
:) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:09 |
Bmagic |
Anyone using pgpool with Evergreen? |
| 17:18 |
|
jvwoolf joined #evergreen |
| 01:37 |
|
Jillianne joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
agoben joined #evergreen |
| 08:36 |
|
_adb joined #evergreen |
| 08:59 |
|
mmorgan joined #evergreen |
| 10:58 |
Dyrcona |
Maybe that's more than you wanted to know. |
| 10:59 |
Freddy_Enrique |
yep, I have a better picture of what is going to happen |
| 10:59 |
Freddy_Enrique |
just a couple of months |
| 10:59 |
Freddy_Enrique |
meanwhile I would like to continue testing the software |
| 11:01 |
Dyrcona |
Freddy_Enrique: I recommend setting up the web client if/when you build your own test system. |
| 11:01 |
Dyrcona |
It is listed as optional at the moment. |
| 11:03 |
Freddy_Enrique |
about the web interface, I consider it a big change. Not so sure if I should call it improvement thought. Why this decision? |
| 11:04 |
Freddy_Enrique |
Personally I found it more convenient |
| 11:30 |
kmlussier |
Is there any particular reason you would find it useful? |
| 11:32 |
Freddy_Enrique |
Well, at least... That approached really worked for koha. People got interested in that ILS cause they more or less knew what the could actually do |
| 11:32 |
Freddy_Enrique |
approach* |
| 11:33 |
kmlussier |
Sure, but I'm not seeing how wiping the data helps with the testing. |
| 11:33 |
kmlussier |
In some cases, I think people are trying out the system over multiple days and find it useful to have the same data there when they return to the server/ |
| 11:34 |
Freddy_Enrique |
Your are right |
| 11:34 |
* kmlussier |
isn't objecting to the idea, but just trying to see the pros and cons. |
| 11:37 |
Freddy_Enrique |
I think call it: try it yourself! . We could enter, experiment with it. and...if by any chance I mess it up. Everything comes back to normal |
| 16:03 |
|
hbrennan joined #evergreen |
| 16:05 |
|
tspindler left #evergreen |
| 16:08 |
|
jvwoolf1 joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
|
mmorgan1 joined #evergreen |
| 18:39 |
csharp |
@band add Highest Karma |
| 18:39 |
pinesol_green |
csharp: Band 'Highest Karma' added to list |
| 03:21 |
|
Jillianne joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
agoben joined #evergreen |
| 08:08 |
|
kmlussier joined #evergreen |
| 10:34 |
Freddy_Enrique |
Great! and finally, is there any recommendation which Library should be in charge of the server where the EG software is implemented? |
| 10:34 |
csharp |
we may keep our DBs on 14.04/PG 9.4 though |
| 10:35 |
jeff |
csharp: The Carrollton Contingency itself would probably make a good band name. |
| 10:35 |
bshum |
In the past, what I ended up doing was keeping our utility server and such on older Ubuntu distros since the upkeep tended to require more thorough testing |
| 10:35 |
csharp |
@band add The Carrollton Contingency |
| 10:35 |
pinesol_green |
csharp: Band 'The Carrollton Contingency' added to list |
| 10:35 |
dbs |
Well, for the first test upgrade I'll give Xenial a run and see what happens |
| 10:35 |
csharp |
jeff++ |
| 10:35 |
bshum |
But move the app servers and DB servers ahead to the latest Ubuntus |
| 10:35 |
dbs |
you people and your multiple app/utility servers :) |
| 10:38 |
dbs |
Bmagic++ |
| 10:39 |
kmlussier |
Freddy_Enrique: Also, following up on what I said earlier about size of the consortium, I'll refer back to what dbs just said about multiple app/utility servers. In our consortium we have Evergreen running on several bricks. |
| 10:39 |
Bmagic |
dbs: It's been working just fine for us. The EDI stuff works too :) |
| 10:39 |
Dyrcona |
dbs: A/T seems to work fine, I've run them on test databases copied from production. |
| 10:39 |
dbs |
excellent! |
| 10:39 |
kmlussier |
Once you need to move to multiple servers, I think it increases the complexity of maintaining the system. But I'm not a systems person - that's just what I've observed. |
| 10:39 |
Dyrcona |
I use Xenial for my test and development vms, mostly. |
| 10:39 |
cfarley |
I'm trying to have evergreen start automatically after a reboot, but having an issue. |
| 10:40 |
cfarley |
When run from a cron job autogen.sh stalls out, but if I run the script manually, it doesn't have any issues. |
| 10:40 |
cfarley |
Anyone played with this before? |
| 13:48 |
Dyrcona |
JBoyer: Staff can access deleted bibs, so if you remove the metabib info, they will not turn up in searches for staff. |
| 13:48 |
JBoyer |
(I hope this DELETE doesn't come back 2 hours after I leave with a "nope, you have to delete this table at the same time, etc.) |
| 13:49 |
Dyrcona |
JBoyer: It might. :) |
| 13:49 |
JBoyer |
Maybe I'll just cancel it and go for 1 bibid to test. I'd like to be able to test things this week. :p |
| 13:50 |
kmlussier |
Staff searches bring up deleted records? That doesn't sound right. |
| 13:50 |
JBoyer |
kmlussier, if you know to type #deleted into a search box. |
| 13:50 |
kmlussier |
Oh, yes. Ignore me. |
| 16:04 |
kmlussier |
miker: Yeah, that proposal is something that's been sitting on our backburner for a while. I need to get focusing on that at some point. |
| 16:22 |
|
jihpringle joined #evergreen |
| 16:37 |
|
cfarley joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:20 |
|
jvwoolf left #evergreen |
| 18:32 |
|
jihpringle joined #evergreen |
| 04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:19 |
|
Sinkme joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 10:39 |
Freddy_Enrique |
So I can get to that page in order to adopt any additional tools for the evergreen, and also fix some bugs. |
| 10:44 |
kmlussier |
Freddy_Enrique: Yes, absolutely. We also have some bugs with a 'bitesize' tag that should be smaller bugs to help new contributors get started. https://bugs.launchpad.net/evergreen/+bugs?field.tag=bitesize |
| 10:47 |
* Dyrcona |
is bepuzzled. |
| 10:47 |
kmlussier |
Speaking of photos for patron records, I wonder if they display in the web client. We don't use them, so I never thought of testing them. |
| 10:52 |
* Dyrcona |
thinks I may not have actually loaded the db modification that I thought I was testing. |
| 10:54 |
|
mmorgan joined #evergreen |
| 10:55 |
|
maryj joined #evergreen |
| 10:55 |
Dyrcona |
No, I did, and it seem to make things worse from one point of view, but more digging is required. |
| 10:56 |
* Dyrcona |
is being cryptic.... |
| 10:59 |
|
mllewellyn joined #evergreen |
| 11:00 |
* kmlussier |
runs a quick test and sees no patron record images displaying in the web client. |
| 11:01 |
* kmlussier |
's dog looks very cute in the xul client. |
| 11:04 |
Dyrcona |
heh. |
| 11:52 |
|
Freddy_Enrique joined #evergreen |
| 11:53 |
|
_adb joined #evergreen |
| 16:49 |
mmorgan |
We had a number of auto-updates fail during our last upgrade. |
| 16:50 |
jeffdavis |
mmorgan: Auto-update worked well for us in our 2.10->2.12 upgrade (also for 2.8->2.10). As a rule, partial update fails but full update works. |
| 16:57 |
* mmorgan |
is not sure what is meant by partial vs. full. |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:00 |
gmcharlt |
mmorgan: partial tries to install only the files that have changed since the previous build; full just does a full overwrite |
| 17:02 |
mmorgan |
Is that an option when building the self-updating client? |
| 17:13 |
kmlussier |
mmorgan: I don't know the answer to your question, but I know when a partial update has failed for me in the past, I'm presented with the option to do the full update. |
| 02:06 |
|
Bmagic joined #evergreen |
| 02:51 |
|
jvwoolf joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:50 |
|
JBoyer joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 16:18 |
JBoyer |
Yeah, the fork is fine and the child is returned because it's a higher demand period (i.e. not on the inactive list), for some reason it can't auth, boom, open-ils.search blows up. :/ |
| 16:19 |
JBoyer |
erlang.log is useless, ejabberd.log shows several connections, but they all appear to have the expected "Accepted legacy authentication for opensrf@..." lines with them. |
| 16:20 |
* JBoyer |
is planning to put together a big 'ol text document for the LP bug) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
jeffdavis |
JBoyer: I'm not seeing errors like that in our logs |
| 16:32 |
Dyrcona |
JBoyer: I've only ever seen messages like that when ejabberd has crashed or hit some limit, that I recall. |
| 16:33 |
Dyrcona |
And, I haven't seen them in a while, except once recently, when I missed one of the settings on a test vm. |
| 16:33 |
Dyrcona |
You still may have encountered something new. |
| 16:34 |
berick |
so, i was testing hold targeter here recently and each parallel process was fetching 100k+ hold ids in "substream" mode (1 jabber message per id). this caused ejabberd to lock up for severl seconds while it routed all the messages. I wonder if the new bundling/chunking osrf 2.5 changes are having a simimlar effect. messages that used to be large, are now a blast of smaller messages, adding load to |
| 16:34 |
berick |
ejabberd. |
| 16:34 |
Dyrcona |
That would make a lot of sense. |
| 16:34 |
Dyrcona |
Or does make a lot of sense. |
| 16:35 |
miker |
berick: have you removed all shapers? |
| 03:12 |
|
book` joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 07:28 |
graced |
Happy Friday, #evergreen! |
| 11:59 |
|
jvwoolf joined #evergreen |
| 11:59 |
berick |
Dyrcona: the api uses new_salt when changing the password. get_salt() is more about handling an existing password (e.g. during login) |
| 12:00 |
berick |
i mean you could re-use the salt, but that seems non-good. |
| 12:00 |
Dyrcona |
OK. In my case, I'm reusing the salt, but this is just to test something not related. :) |
| 12:01 |
Dyrcona |
I wanted to change the password for a user on my test database to try downloading their circ history. |
| 12:01 |
Dyrcona |
I think I will write myself a custom function doing it correctly for future situations like this. |
| 12:02 |
Dyrcona |
I just pulled the salt, etc., from the db tables this time. |
| 12:03 |
berick |
Dyrcona: fyi, Actor::modify_migrated_user_password() shows the typical steps for moding a passowrd. translating that to a DB func would be trivial. |
| 12:04 |
Dyrcona |
OK. |
| 12:04 |
Dyrcona |
I think my test db/vm are too slow. |
| 12:04 |
Dyrcona |
Oh. nice. internal server error. |
| 12:06 |
Dyrcona |
[Fri Jun 09 12:05:20.331897 2017] [perl:error] [pid 20167] [client 192.168.100.100:43488] Apache2::RequestIO::print: (32) Broken pipe at /usr/lib/x86_64-linux-gnu/perl5/5.22/Template.pm line 180, referer: https://10.250.150.80/eg/opac/myopac/circ_history |
| 12:07 |
pinesol_green |
[evergreen|Terran McCanna] LP#1681943 Improve Responsive Design in My Lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d786c57> |
| 15:28 |
pinesol_green |
[evergreen|Galen Charlton] LP#1533326: follow-up to remove extra logging statement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c1ecb35> |
| 15:33 |
Bmagic |
It looks like it's solved in 2.12.x |
| 15:41 |
|
kmlussier joined #evergreen |
| 15:41 |
* kmlussier |
shakes her fist at Comcast |
| 15:45 |
kmlussier |
Of course, now that I think about it, I probably could have continued testing offline circ while Comcast was down. |
| 15:45 |
berick |
Comcast is your mirror cat |
| 15:47 |
kmlussier |
It all comes back to the mirror cat, doesn't it? |
| 15:49 |
mmorgan |
Pay no attention to the cat in the mirror... |
| 16:06 |
* Dyrcona |
makes that one a bit more than he'd like to admit. |
| 16:13 |
miker |
not copy-paste, typo's mine in here :) |
| 16:14 |
miker |
no, it's just that you can't say "no, make that other radio button selected via change to a scope var" |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:51 |
|
Jillianne joined #evergreen |
| 16:55 |
|
jvwoolf left #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:42 |
|
rlefaive joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
agoben joined #evergreen |
| 11:03 |
mmorgan |
Malikythe: Lost item? |
| 11:05 |
Malikythe |
gsams: Gah, I'm dumb. I hit "Display alert and messages" and it told me there were none, so I didn't check the messages tab itself. Apparently something about the non-blocking messages my staff had been adding resulted in the orange color. |
| 11:05 |
gsams |
PINES also has a page on this: https://pines.georgialibraries.org/patron-border-colors |
| 11:06 |
Malikythe |
It's weird, though. I removed all the messages and added a new one to test it, and it turned the border cyan (which is what I'm used to for non-blocking messages) |
| 11:06 |
gsams |
Malikythe++ #It's happened to me a few times |
| 11:06 |
Malikythe |
Dunno where the orange came from |
| 11:06 |
gsams |
According to the PINES page, it means multiple penalties are in place |
| 11:22 |
dbs |
Also penalties show up under the patron's name, such as "Patron exceeds fine threshold" |
| 11:22 |
|
micro_ joined #evergreen |
| 11:22 |
mmorgan |
The patron name shows in red in the web client if they are blocked. |
| 11:22 |
micro_ |
why is the demo test client not work |
| 11:22 |
dbs |
mmorgan: Yeah that's the high-level "problem!" highlight and the details are often also highlighted below |
| 11:22 |
kmlussier |
Guest72111: Which demo test client? |
| 11:22 |
Guest81886 |
I cant connect to either the server |
| 11:22 |
JBoyer |
I need to pull up more patrons with issues, I didn't realize there were colors or penalties listed either. |
| 11:22 |
kmlussier |
Guest72111: There are a few |
| 11:28 |
Guest81886 |
That is for the demo.evergreencatalog.com |
| 11:28 |
kmlussier |
Guest72111: Is anything listed in the Organization dropdown underneath the WS name box? |
| 11:28 |
Dyrcona |
That means your client is not getting the settings from the server. I don't know why. |
| 11:29 |
Guest81886 |
but when i enter mlnc2.noblenet.org it says "There was an error testing this hostname" |
| 11:29 |
kmlussier |
Guest81886: Sorry, I can't help you with demo.evergreencatalog.com. |
| 11:29 |
kmlussier |
Guest81886: Yes, that's what I mentioned above, about the SSL exception. |
| 11:29 |
dbs |
Guest81886: maybe try https://webby.evergreencatalog.com ? |
| 13:08 |
JBoyer |
-u |
| 13:43 |
Dyrcona |
_bott_: While you're around, would you mind branchifying your patches on Lp 1195428? |
| 13:43 |
pinesol_green |
Launchpad bug 1195428 in Evergreen "TPAC reports hold "ready for pickup" before hold_shelf_status_delay expires" [Medium,Confirmed] https://launchpad.net/bugs/1195428 |
| 13:43 |
Dyrcona |
We just got a report of it, and I would like to test your code. |
| 13:55 |
_bott_ |
Let me see if I can track that down! |
| 14:19 |
|
Jillianne joined #evergreen |
| 14:41 |
_bott_ |
Dyrcona: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=c16cfd0f680c7d28b8d201ec79618e2aeac6ff72 |
| 14:57 |
|
Jillianne joined #evergreen |
| 14:59 |
|
kmlussier joined #evergreen |
| 15:58 |
|
Dyrcona joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf left #evergreen |
| 17:25 |
|
rsulejmani joined #evergreen |
| 02:50 |
|
genpaku_ joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:12 |
|
JBoyer joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 08:53 |
|
kmlussier joined #evergreen |
| 08:55 |
|
umarzuki joined #evergreen |
| 08:56 |
umarzuki |
i got "Received no data from server" when testing srfsh request opensrf.math add 2,2 |
| 08:57 |
umarzuki |
shell output > https://pastebin.com/id9VWfrf |
| 09:00 |
umarzuki |
srfsh.log https://pastebin.com/ppnbtLfR |
| 09:23 |
Bmagic |
umarzuki: Trying to get the Evergreen server setup for the first time? |
| 09:25 |
Bmagic |
umarzuki: You might be interested in the "one command to install it all" solution https://hub.docker.com/r/mobiusoffice/evergreen-ils/ |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:53 |
umarzuki |
I'm installing this on vmware workstation |
| 09:56 |
bshum |
With Xenial, another issue that's cropped up lately has been problems where the firewall blocks ejabberd from communicating |
| 09:57 |
bshum |
I thought berick found a workaround for the ansible installer, not sure if that'll help |
| 09:58 |
umarzuki |
bshum: firewalld service not enabled and iptables -L shows no rules |
| 09:58 |
umarzuki |
I'm just using zaq12wsx for password, testing purposes only |
| 10:00 |
bshum |
That doesn't seem too overly complex and should have worked then |
| 10:00 |
bshum |
Hmm |
| 10:01 |
Dyrcona |
umarzuki: Did you change the auth_passwrd_format to plain in ejabberd.yml? |
| 10:52 |
|
collum joined #evergreen |
| 10:52 |
bshum |
JBoyer: cesardv: I'll be curious to see what you guys find with those settings carrying over between retrieved users in the last comments on https://bugs.launchpad.net/evergreen/+bug/1642035 ; I think I saw a similar issue occurring with the patron stat cats where the last entry made on one user was also showing up when retrieving the next user (who didn't have an entry yet) |
| 10:52 |
pinesol_green |
Launchpad bug 1642035 in Evergreen "Web Staff Client - Problems saving notification preferences" [Undecided,Confirmed] |
| 10:59 |
cesardv |
bshum: yeah I noticed that while doing some testing... I'm still pretty new to Evergreen, but yea seems like (according to a comment on regctl.js) there's caching of data unless explicitly click out of the patron tabs |
| 11:02 |
kmlussier |
JBoyer / agoben: Can you remind me what the hack-a-way date is? |
| 11:06 |
agoben |
The EOB day is November 6; the Hack-away is November 7-9. (I've run into an issue with our location from last year, so am working on alternate options for the venue. Will announce as soon as possible.) |
| 11:07 |
berick |
thanks agoben , was wondering myself |
| 15:25 |
berick |
JBoyer: oh, right |
| 15:46 |
|
collum joined #evergreen |
| 15:55 |
|
Jillianne joined #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:14 |
|
mmorgan left #evergreen |
| 19:33 |
|
jihpringle_ joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
Callender joined #evergreen |
| 07:27 |
|
agoben joined #evergreen |
| 13:43 |
Dyrcona |
Also, 84MB of swap used, but I don't worry about such a low number. :) |
| 13:43 |
Dyrcona |
JBoywer: Thanks! |
| 13:43 |
Dyrcona |
JBoyer, even. :) |
| 13:44 |
Dyrcona |
Well, guess I'll do my fourth or fifth code installation on my test vm this week, and I haven't even really started testing it. |
| 13:44 |
Dyrcona |
Looks like that won't happen until next week. |
| 13:45 |
* Dyrcona |
is getting tired of looking at server specs and selecting options. |
| 13:45 |
JBoyer |
Though when I've seen that in the past it was just a controller setting that could be changed whenever, are there really different disks for these types? (I've not dealt with NVMe yet) |
| 13:58 |
Dyrcona |
Did anyone else get an email from HackerEarth to participate in some hackathon? |
| 13:59 |
JBoyer |
I guess the rest of us just have to click on the pi symbol on Mozart's Ghost like it's the 90's. |
| 14:00 |
Dyrcona |
Well, it looked legit, and I was just curious if anyone else got it, i.e. why did I get one? |
| 14:02 |
Dyrcona |
gmcharlt: We had a ticket about the download history just this morning, so I'll use that patron to test. |
| 14:05 |
|
StomproJosh joined #evergreen |
| 14:05 |
|
dbwells_ joined #evergreen |
| 14:11 |
abneiman |
JBoyer++ # investigations :) |
| 15:56 |
jvwoolf |
Dyrcona: Thanks for the feedback. :) |
| 16:37 |
berick |
aww, concerto has a patron street address "Cheerful Animal Valley" |
| 16:37 |
berick |
so much better than "Spotty Chemical Stravenue" |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:08 |
csharp |
@band add Cheerful Animal Valley |
| 17:08 |
pinesol_green |
csharp: Band 'Cheerful Animal Valley' added to list |
| 03:06 |
|
remingtron_ joined #evergreen |
| 04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:30 |
|
Dyrcona joined #evergreen |
| 11:55 |
pinesol_green |
Launchpad bug 821640 in Evergreen master "Define a macro for grand total of all bills listed" [Undecided,Fix released] |
| 11:56 |
bshum |
grand_total_owed ? |
| 11:57 |
bshum |
Yeah that patch in that bug added three new macros: grand_total_owed, grand_total_billed, grand_total_paid |
| 11:58 |
mmorgan |
Just tested, bshum is correct, %grand_total_owed% print the total outstanding for the patron |
| 11:58 |
mmorgan |
er, prints |
| 12:00 |
bshum |
mmorgan++ # thanks for checking out my theory |
| 12:01 |
* bshum |
misses having a real Evergreen server at his fingertips |
| 12:01 |
bshum |
Well, kinda misses. :) |
| 15:58 |
berick |
oddly appropriate, pinesol_green |
| 15:58 |
bshum |
I thought I enabled that one |
| 15:58 |
* kaffenkj |
wishes we could do away with resumes and look at character stat sheets when evaluating new hires |
| 15:58 |
bshum |
Guess not |
| 15:59 |
bshum |
@ana This is a test |
| 15:59 |
pinesol_green |
bshum: Its hastiest |
| 15:59 |
berick |
bshum++ |
| 15:59 |
berick |
@ana Smirnoff Ice Watermelon |
| 16:01 |
Dyrcona |
@quote randome |
| 16:01 |
pinesol_green |
Dyrcona: http://xkcd.com/1739/ |
| 16:01 |
Dyrcona |
@quote |
| 16:01 |
pinesol_green |
Dyrcona: We're going to need a bigger boat. |
| 16:04 |
|
mmorgan1 joined #evergreen |
| 16:27 |
|
jvwoolf left #evergreen |
| 16:55 |
|
khuckins_ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:35 |
|
Jillianne joined #evergreen |
| 19:17 |
jeff |
3 |
| 02:55 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 04:52 |
|
gsams_ joined #evergreen |
| 04:54 |
|
BigRig joined #evergreen |
| 07:12 |
|
agoben joined #evergreen |
| 08:28 |
csharp |
also Bmagic ^^ |
| 08:28 |
csharp |
Bmagic: that could explain your crazy cstore issue |
| 08:29 |
|
jvwoolf1 joined #evergreen |
| 08:31 |
Dyrcona |
csharp: Looks good to me. I'll let Bmagic test it, since he's run into it. |
| 08:31 |
Dyrcona |
Anyway, I think my upgrade script issue is gonna set my testing back a day. I'll have to do a new restore, and that takes about 6 hours on this server. |
| 08:32 |
Dyrcona |
Yeah. The query returns only 1 row on a non-botched database. |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:38 |
Dyrcona |
bleh. |
| 08:42 |
jeff |
but wait, it doesn't fail when you're using pg_restore to create the db instead of creating it first? |
| 08:43 |
Dyrcona |
jeff: When I restore -c -C -d postgres so that the db is restored with the name evergreen, it works. |
| 08:43 |
Dyrcona |
When I create an empty database and restore with just -d dbname it fails. |
| 08:43 |
jeff |
okay. what version of evergreen is the database at restore time? |
| 08:44 |
jeff |
i'm curious to do some more testing myself later. |
| 08:44 |
Dyrcona |
Pg 9.2 restored to a Pg 9.5 db server. |
| 08:44 |
Dyrcona |
Oh sorry, Evergreen: 2.10.7 |
| 08:44 |
jeff |
using pg_dump 9.2 and pg_restore 9.5? |
| 08:48 |
Dyrcona |
The database name is evergreen. |
| 08:48 |
jeff |
(relevant when using -c -C) |
| 08:49 |
Dyrcona |
And, I'm set back a day..... |
| 08:50 |
Dyrcona |
I also specifically want my data from last week for testing purposes. I'm going to test URI deletes with the branch on Lp 1482757, but that's not particularly relevant. :) |
| 08:50 |
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 |
| 08:50 |
jeff |
bug 1671150 -- looks like i need to make a working branch. |
| 08:50 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 - Assigned to Jeff Godin (jgodin) |
| 09:50 |
JBoyer |
Unless we make un-deletion more involved (a full reingest, possibly more) or make it impossible without poking around in the database manually they should probably stick around. |
| 09:50 |
mmorgan |
Dyrcona: In my experience, once added, asset.uri entries don't go away. Part of lp 1482757 is meant to address that bit. |
| 09:50 |
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 |
| 09:50 |
Dyrcona |
Right. I was going to test some of that, but I have a delay because of pg_restore issues. |
| 09:51 |
Dyrcona |
I'm just trying to do some cleanup in production. |
| 09:52 |
jeff |
in terms of pgcrypto, it looks like we use crypt() in actor.set_passwd / actor.verify_passwd and gen_salt() in actor.create_salt |
| 09:53 |
mmorgan |
Oh, I get it. So the deleted records still have the 856, imo, the asset.uri should probably remain. |
| 10:14 |
Dyrcona |
I'm going through the list anyway in case some are not deleted. |
| 10:14 |
Dyrcona |
Mostly romance novels from Freading. |
| 10:16 |
Dyrcona |
and mysteries. |
| 10:20 |
Bmagic |
csharp: I'll test it and get back to you. I'm not positive that we had that exact problem. |
| 10:32 |
|
kmlussier joined #evergreen |
| 10:37 |
csharp |
Bmagic: I'm not sure it's our *only* problem :-/ |
| 10:38 |
csharp |
but it happened last night and I could very easily track the cause in the logs |
| 14:04 |
|
khuckins_ joined #evergreen |
| 14:09 |
jeffdavis |
jeff: you mentioned in the past that you have a PatronAPI shim - is that something you'd be willing to share? |
| 14:11 |
|
jihpringle_ joined #evergreen |
| 14:14 |
jeff |
yes. |
| 14:15 |
jeff |
many of the local patron tests for eligibility are expressed in perl code, but i expect that i can make them commented examples and throw it up on github. |
| 14:17 |
jeff |
we use it as a true/false test -- we are not returning patron data such as name or expiration date or birth date, or even money owed. |
| 14:18 |
jeff |
this doesn't mean that it can't do those things, just that we intentionally didn't. |
| 14:18 |
jeffdavis |
I'm hoping to get some time this summer to make that an option with EG's SIP server too. |
| 14:19 |
jeff |
i'm looking now to see if we're testing password or just using the library card. |
| 14:24 |
jeff |
not checking password (because we did not want patrons to enter their library password into a vendor app / site) |
| 14:25 |
jeff |
it could be added, but i'm okay with it not being there. :-) |
| 14:34 |
jeffdavis |
That would likely be good for Sitka's immediate use case (we've had a patron auth request from another vendor and I'm trying to steer away from SIP for that). |
| 14:38 |
gsams |
https://www.humblebundle.com/books/linux-book-bundle |
| 15:10 |
pinesol_green |
[evergreen|Galen Charlton] LP#1694497: fix record links on 2nd+ page of grouped results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc9b7ea> |
| 15:38 |
|
remingtron joined #evergreen |
| 15:38 |
|
dbwells joined #evergreen |
| 16:20 |
|
Jillianne joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:33 |
kmlussier |
Do we know what needs to be done to fix the tests? |
| 16:36 |
jeff |
did they start breaking on the 28th? |
| 16:36 |
* jeff |
looks |
| 16:36 |
jeff |
29th |
| 16:36 |
Dyrcona |
Looks like apt-get update/upgrade needs to be run or someone broke packages on the Debian side. |
| 16:40 |
jeff |
on May 28, the libdbd-pg-perl package in the postgresql PGDG apt repository was updated: https://www.postgresql.org/message-id/E1dEuUN-0000Q0-Gy%40atalia.postgresql.org |
| 16:41 |
jeff |
for Wheezy, it requires the latest perl package, which is not present on the test system. |
| 16:41 |
jeff |
so yeah, either someone needs to manually apt-get update && apt-get dist-upgrade, or fix whatever automated process is expected to do that which isn't. :-) |
| 16:42 |
Dyrcona |
I don't think I have access. If I do, I never used it. |
| 16:42 |
jeff |
i may. checking. |
| 16:49 |
jeff |
checked. |
| 17:04 |
jeff |
oh wow, and we woke phasefx from a 6+day slumber, to boot. |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
phasefx |
it doesn't |
| 17:10 |
jeff |
current output of http://testing.evergreen-ils.org/~live/test.4.html shows it does... |
| 17:10 |
jeff |
but that the version of perl it installed is still one revision down. |
| 17:10 |
jeff |
hrm. |
| 17:11 |
phasefx |
in build_essentials it's doing apt-get update && apt-get -yq dist-upgrade ... skips the upgrade; would that make a difference? |
| 17:12 |
jeff |
i'm missing the "skips the upgrade" part of your statement. |
| 17:12 |
Dyrcona |
dist-upgrade does an upgrade. |
| 17:21 |
jeff |
phasefx_: in this case, it may simply be a case of the VM not having the security repo enabled as an apt source. |
| 17:21 |
Dyrcona |
ok |
| 17:21 |
jeff |
phasefx_: i don't see security.debian.org in the output of apt-get update |
| 17:21 |
phasefx |
yeah, it simply has: http://testing.evergreen-ils.org/~live/test.4.html |
| 17:21 |
phasefx |
cut/paste across desktops, bleh :) |
| 17:22 |
phasefx |
wheezy main contrib |
| 17:22 |
jeff |
yeah. that's the issue. |
| 17:22 |
phasefx |
jeff++ |
| 17:23 |
jeff |
it broke after the new PGDG package update started requiring the latest perl package for wheezy, which is only available from security.debian.org |
| 19:28 |
Freddy_Enrique |
but how do I Lad the sample data? |
| 19:29 |
Freddy_Enrique |
Load* |
| 19:29 |
Freddy_Enrique |
Its in the instructions, but I wasn't able to figure it out |
| 19:30 |
csharp |
Freddy_Enrique: two ways: 1) add --load-all-sample during the eg_db_config.pl step 2) run psql on Open-ILS/tests/datasets/sql/load_all.sql |
| 19:34 |
Freddy_Enrique |
Let see.... there were 4 step in the eg_db_config. this could be a 5 step. Should it look like this? |
| 19:34 |
Freddy_Enrique |
https://snag.gy/dqlPTv.jpg |
| 19:35 |
csharp |
Freddy_Enrique: that works, yeah |
