| 01:23 |
|
abowling joined #evergreen |
| 01:29 |
|
beanjammin joined #evergreen |
| 04:12 |
|
yar joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:48 |
|
littlet joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:04 |
|
yboston joined #evergreen |
| 09:16 |
csharp |
so my takeaway from the hatch discussion from yesterday is we need to merge in JBoyer's and berick's branches to Hatch master - is that right? |
| 09:16 |
* csharp |
is happy to test and signoff wherever would help |
| 09:16 |
csharp |
our testers are hitting the WSOD issue a lot now |
| 09:16 |
* csharp |
saw it himself last week |
| 09:19 |
kmlussier |
csharp: When does it come up? |
| 09:20 |
csharp |
for me it was after installing hatch after running the web client without hatch |
| 09:21 |
miker |
csharp: did you tell it to use hatch for storage? I believe the word is, now, "don't do that, only printing" |
| 10:07 |
berick |
does clearing the cache, etc. wipe out the indexdb too? |
| 10:09 |
csharp |
kmlussier: I think the storage options should be at the very least greyed out if they're going to break things |
| 10:10 |
Dyrcona |
Clear browsing data on Chromium gives a list of things to clear with check boxes. |
| 10:11 |
kmlussier |
We tested this at the hack-a-way, I think. IIRC, clearing the cookies would also clear local storage. I'm not sure about indexdb. |
| 10:11 |
csharp |
also, it's almost certainly my own fault for tuning out, but I was in the dark about Hatch not being used for storage - I thought that was the point (or *a* point) of it |
| 10:11 |
kmlussier |
My preference would be to fix the hatch storage issue. |
| 10:11 |
csharp |
I think Terran did see that it at least unlinked the DB from the instance so even if it doesn't blow away data it's no longer functional |
| 10:30 |
csharp |
I see - then let me work with that one then report back |
| 10:30 |
berick |
csharp++ |
| 10:31 |
csharp |
also, need to find a windows (v)box somewhere |
| 10:31 |
berick |
what have you been testing on? |
| 10:31 |
csharp |
this was Ubuntu 17.10 |
| 10:31 |
berick |
ohhh |
| 10:31 |
berick |
didn't realize |
| 12:11 |
Dyrcona |
But, when I had just OpenSRF installed opensrf.math worked just fine. |
| 12:15 |
Dyrcona |
Umm... I thought master installed the libraries correctly as lib.... Apparently that didn't happen for me. |
| 12:16 |
Dyrcona |
Ok. Never mind, my checkout was behind current master by quite a bit. :) |
| 12:52 |
jeffdavis |
I'm seeing a weird thing on a test server where OPAC iframes within the web client fail to load with a "too many redirects" error - but only in Chrome. If I open dev tools and check "Disable cache" it works fine. |
| 12:54 |
jeffdavis |
The iframes also work fine if I use a subdomain to connect (foo.example.com) but the main domain (example.com) always fails. |
| 12:55 |
jeffdavis |
It seems like I'm getting a redirect loop somehow, so going to Catalog > Search the Catalog does 'GET /eg/opac/advanced' but the server responds with a redirect to /eg/opac/advanced, ad infinitum. |
| 12:57 |
jeffdavis |
I can load /eg/opac/advanced just fine outside the web client. |
| 13:03 |
berick |
jeffdavis: using nginx? |
| 13:03 |
jeffdavis |
yeah |
| 13:04 |
jeffdavis |
I'm going to try without the proxy and see if it makes a difference |
| 17:05 |
miker |
I was thinking of https://bugs.launchpad.net/evergreen/+bug/1723977 |
| 17:05 |
pinesol_green` |
Launchpad bug 1723977 in Evergreen "Searching specific location in Advanced Search not limiting correctly in 3.0" [Medium,Fix released] |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
kmlussier |
miker: OK. The testing I did for bug 1736419 was on a recent master system that should already have that fix on it. |
| 17:07 |
pinesol_green` |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 17:07 |
jeffdavis |
likewise, I'm still seeing the luri issue on a 3.0.2 server |
| 17:07 |
miker |
kk, so it's something else |
| 01:39 |
|
RBecker joined #evergreen |
| 02:18 |
|
beanjammin joined #evergreen |
| 03:04 |
|
JBoyer_alt_bin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
rjackson_isl joined #evergreen |
| 07:04 |
|
JBoyer joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 09:33 |
jeff |
Bmagic: yep, that's expected with that command. what were you trying to do? |
| 09:54 |
stephengwills |
is there a common patron records problem one can look for when really_delete_user fails with a 500 error? |
| 09:56 |
Dyrcona |
Not that I'm aware of. The Apache error log is often useful in the event of a 500 error. |
| 09:57 |
Dyrcona |
I got one on a test server this morning that included enough of the Perl error for me to track it down, for example. |
| 09:58 |
stephengwills |
ok thanks. will dig deeper. |
| 09:58 |
Dyrcona |
Sometimes, that information isn't there, unfortunately. |
| 10:01 |
mmorgan |
Our OverDrive login activity type is working! We've recorded almost 30 logins in the first hour. |
| 12:08 |
Dyrcona |
It's a lot faster than pg_restore. |
| 12:09 |
Dyrcona |
But, if you're renaming the db, and you don't have the db already on the server, you have to create an empty db to restore into. |
| 12:11 |
* jeff |
nods |
| 12:12 |
bshum |
Bmagic: re: web client, I recently tested the 2.12.8 tarball and that seemed fine to log in without any errors, same for recent master for me |
| 12:12 |
bshum |
Which version are we talking about on your end of things? |
| 12:13 |
Bmagic |
bshum: it's weird - doesn't happen right away. Seems like its some FF stale cookies or something. Happens on Chrome too. Incognito window "fixes" it sometimes, but still weird |
| 12:13 |
bshum |
Version of EG and Linux distro too |
| 12:13 |
Dyrcona |
Adding on to my last statement, I usually just do a create database statement from psql and don't bother with the create db script these days. |
| 12:58 |
bshum |
sandbergja: I think kmlussier pointed that out to me and asked awhile back |
| 12:58 |
bshum |
Fixing the typo in the .pot and .po files is not a bad thing |
| 12:59 |
Dyrcona |
sandbergja: You generally don't need to fix the .pot and .po files though. They are generated are release time. |
| 12:59 |
bshum |
What'll happen is that the next import from git to LP will update the relevant template strings out there |
| 13:00 |
bshum |
At release time, if the string is already changed in git, it'll just get skipped over by the i18n sync process |
| 13:00 |
bshum |
I'm in favor of git changes like this so that it's easier for folk to install / test with |
| 13:00 |
bshum |
Rather than waiting or learning the i18n dance |
| 13:00 |
bshum |
But I'm okay with it either way |
| 13:00 |
Dyrcona |
I'll defer to bshum on that point, then. :) |
| 13:01 |
sandbergja |
That's helpful -- thanks. |
| 13:01 |
bshum |
For typos, I think it's fine |
| 17:09 |
berick |
change the path to suit |
| 17:11 |
berick |
find ~/ -name org.evergreen_ils.hatch.json |
| 17:12 |
Bmagic |
thanks! |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 22:02 |
|
jvwoolf joined #evergreen |
| 22:25 |
|
jvwoolf left #evergreen |
| 23:00 |
|
Stompro joined #evergreen |
| 00:29 |
|
dbwells_ joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:57 |
|
JBoyer joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 16:11 |
bshum |
kmlussier: Possibly. |
| 16:11 |
bshum |
Not sure if that's the real problem or not based on your errors you saw |
| 16:11 |
* kmlussier |
can try it locally to see if it fixes her issue. |
| 16:13 |
bshum |
And I'm not 100% sure what'll happen if you have both nodejs legacy and then install the nodejs binary |
| 16:13 |
bshum |
If it'll just figure out to use the newer one, or if it'll be unhappy till you remove nodejs legacy |
| 16:13 |
bshum |
I vaguely recall testing that out |
| 16:13 |
bshum |
but it's been awhile.. |
| 16:14 |
jeff |
Bmagic: can you please name the functions in question? |
| 16:14 |
jeff |
Bmagic: my first thought is that you may be running into bug 1671150 |
| 16:14 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Medium,Fix committed] https://launchpad.net/bugs/1671150 |
| 16:28 |
jeff |
or attempting to. |
| 16:29 |
Bmagic |
it is the same db name |
| 16:29 |
Bmagic |
the very tippy top error is complaining about the db already existing, but that is OK because I think I created it just fine |
| 16:30 |
jeff |
the behavior in that case is not defined in the manpage. (-C without --clean where the database name in the dump file already exists in the cluster). I haven't tested to see what the actual behavior is. Were you able to share the \dL and \dx output of the database you're attempting to restore into? |
| 16:30 |
Bmagic |
that went away when I removed -C |
| 16:30 |
jeff |
okay. i still recommend getting out of the habit of using -C, but it sounds like it was not the cause of your issue. |
| 16:31 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "\dL \dx" (22 lines) at http://paste.evergreen-ils.org/948 |
| 16:45 |
Bmagic |
I thought of search path too |
| 16:46 |
jeff |
changing your CREATE EXTENSION for intarray to this might be needed in this case: CREATE EXTENSION intarray WITH SCHEMA evergreen; |
| 16:46 |
jeff |
is the source database available for you to query? |
| 16:48 |
Bmagic |
weird. I can't find the example of query_int in any of my other test machines |
| 16:48 |
Bmagic |
only query_int_wrapper |
| 16:48 |
jeff |
it would be a type, not a function. |
| 16:48 |
jeff |
\dT |
| 17:32 |
Bmagic |
sorry khuckins__ - I have not |
| 18:10 |
|
jvwoolf joined #evergreen |
| 18:11 |
|
JBoyer_alt joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:02 |
|
beanjammin joined #evergreen |
| 19:04 |
beanjammin |
khuckins: You were asking about conditionally adding classes to grid fields? I just finished doing a little bit of that. |
| 19:06 |
khuckins |
beanjammin: Yeah, I've been wracking my brain a bit, specifically trying to make a few glyphicons show up in a field depending on certain values in the item |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:48 |
|
kmlussier joined #evergreen |
| 07:48 |
|
rlefaive joined #evergreen |
| 10:31 |
ejk |
I guess I'll have to make one OpenSRF call after all. =) |
| 10:33 |
ejk |
Thanks again. How did it get to be December already? ... |
| 10:33 |
ejk |
miker++ jeff++ |
| 10:36 |
Dyrcona |
Bmagic: I just tested an upgrade from 2.12.6 to 2.12.8 using your working tag branch for rel_2_12_8 and it works fine. Should we push that to the main repo? |
| 10:37 |
Bmagic |
Dyrcona: I think that's fine, I was just in the middle of testing the tarball myself |
| 10:37 |
Dyrcona |
OK. It can wait a bit longer while you test. |
| 10:37 |
Bmagic |
gmcharlt might be in bed as a "sick pumpkin" - otherwise, he usually does that |
| 10:37 |
Dyrcona |
I'll be doing this upgrade for real next Wednesday. |
| 10:38 |
Dyrcona |
:) |
| 10:38 |
Dyrcona |
Well, :( rather |
| 10:53 |
Bmagic |
Dyrcona: tarball successful. OPAC running, staff client logged in, with concerto. Did not test DB upgrade though |
| 10:54 |
Dyrcona |
Bmagic: Cool! I tested the db upgrades for 2.12.6 to 2.12.7 and 2.12.7 to 2.12.8, and they work for me. |
| 10:54 |
Bmagic |
I think we might be gold |
| 10:54 |
Dyrcona |
I've been kicking the tires and taking it around the block. |
| 10:55 |
Dyrcona |
Yeah. I'll push the branch to the main repository. |
| 12:01 |
|
khuckins joined #evergreen |
| 12:05 |
berick |
csharp: can you clarify, the problem is the Owning Library column does not have enough space? |
| 12:05 |
csharp |
berick: right |
| 12:05 |
berick |
and if you hide other columns (to test) it does eventually show the full names? |
| 12:05 |
csharp |
let me see |
| 12:05 |
berick |
and/or resize the columns via the configurator |
| 12:07 |
csharp |
berick: the full names are visible if there's room, yes - looking at resizing now |
| 12:10 |
berick |
don't forget to "Save Columns" once you have it where you want. |
| 12:12 |
berick |
csharp: if you want to further improve the grid mgmt experience: bug #1730752 :) |
| 12:12 |
pinesol_green |
Launchpad bug 1730752 in Evergreen "Webstaff option to show/hide multiple grid columns" [Undecided,New] https://launchpad.net/bugs/1730752 |
| 12:16 |
csharp |
berick++ # will test |
| 12:17 |
csharp |
apparently our catalogers are unyielding about needing enough columns that the display isn't wide enough :-/ |
| 12:17 |
* csharp |
seethes a little |
| 12:23 |
kmlussier |
Bmagic / Dyrcona: I saw you all talking about the release earlier, but has the tarball uploaded to the server yet? If so, I can put on gmcharlt's hat for the day and upload the downloads page, do announcements, etc. |
| 12:24 |
pastebot |
"berick" at 64.57.241.14 pasted "for csharp if needed -- use shortname" (12 lines) at http://paste.evergreen-ils.org/946 |
| 12:24 |
kmlussier |
No, it doesn't look like the tarball is available or, if it is, I'm not using the correct URL. |
| 15:34 |
csharp |
kmlussier: according to Elaine here, she could delete bucket items but not copy notes |
| 15:34 |
csharp |
after applying the DB scripts |
| 15:34 |
csharp |
I haven't looked into yet, though |
| 15:34 |
kmlussier |
csharp: Yeah, I just tested it. I see it too. Adding a comment to the bug. |
| 15:35 |
csharp |
@blame too many frickin' issues |
| 15:35 |
pinesol_green |
csharp: I know it was you, too many frickin' issues. You broke csharp's heart. You broke csharp's heart. |
| 15:56 |
Bmagic |
Dyrcona kmlussier - it looks like the git repo does not have tags/rel_3_0_2 ? |
| 17:23 |
kmlussier |
Bmagic: Of course, it's easy enough to remove from the slip locally, but I'm always in favor of setting a good example. |
| 17:23 |
Bmagic |
do you know if there is a bug already out there along those lines? |
| 17:34 |
Bmagic |
bug 1735847 |
| 17:34 |
pinesol_green |
Launchpad bug 1735847 in Evergreen "Default hold transit slip should not include patron information" [Undecided,New] https://launchpad.net/bugs/1735847 |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:15 |
|
dbwells joined #evergreen |
| 05:15 |
|
abneiman joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:43 |
|
JBoyer joined #evergreen |
| 07:45 |
|
agoben joined #evergreen |
| 09:41 |
Dyrcona |
Bmagic: I'm getting other errors, too, including a syntax error. |
| 09:42 |
Dyrcona |
I don't feel bad about it, but it's slowing me down a little. I'll have to make a custom upgrade script. |
| 09:42 |
Bmagic |
Syntax errors are among my favorites! Right below runtime whitespace semicolon discovery |
| 09:45 |
bshum |
remingtron++ # adding doc tests to help find oddities |
| 09:49 |
Dyrcona |
This is the standard 2.12.6 to 3.0 upgrade script, too, from tags/rel_3_0_1 |
| 09:52 |
jeff |
bshum: yes. remingtron++ docs build failures becoming live test failures is not a bad thing. :-) |
| 09:58 |
kmlussier |
remingtron++ bshum++ |
| 09:58 |
* gmcharlt |
will be working on release notes for 3.0.2 |
| 09:58 |
gmcharlt |
from my POV, folks have about an hour left for any merges to rel_3_0 |
| 17:02 |
dbwells |
onward and upward, then... |
| 17:03 |
|
mmorgan left #evergreen |
| 18:27 |
|
jvwoolf joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:14 |
|
abowling1 joined #evergreen |
| 21:24 |
|
abowling joined #evergreen |
| 21:27 |
|
dkyle joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:44 |
|
tlittle joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
rlefaive joined #evergreen |
| 10:23 |
|
jvwoolf joined #evergreen |
| 10:23 |
|
rlefaive joined #evergreen |
| 11:23 |
Dyrcona |
So, the point releases are on for today? |
| 11:24 |
* Dyrcona |
asks because he's planning to upgrade to 2.12.8 from 2.12.6 next week and would like to test it tomorrow. :) |
| 11:24 |
Dyrcona |
If it speeds things up, I could help build a tarball. |
| 11:42 |
Dyrcona |
Hmm... 2.12.6 to 3.0.0 db upgrade threw this: |
| 11:42 |
Dyrcona |
psql:Open-ILS/src/sql/Pg/version-upgrade/2.12.6-3.0.0-upgrade-db.sql:6803: ERROR: column "display_field" does not exist LINE 2: ...AY_AGG(id)::INT[] FROM config.metabib_field WHERE display_fi... |
| 11:56 |
jeff |
adjusted milestone/etc on bug 1734963 for 3.0.2 (it was targeting 3.1 beta) |
| 11:56 |
pinesol_green |
Launchpad bug 1734963 in Evergreen "web client: copy template converter doesn't work for older templates" [Medium,Confirmed] https://launchpad.net/bugs/1734963 |
| 12:03 |
pinesol_green |
[evergreen|Chris Sharp] LP#1734963: Teach copy template converter about older templates. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=124f0ff> |
| 12:03 |
jeff |
and now i'm wondering if i should have paired that with a test. :P |
| 12:08 |
* kmlussier |
adds https://bugs.launchpad.net/evergreen/+bug/1671856 to the next dev meeting agenda. |
| 12:08 |
pinesol_green |
Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New] |
| 12:08 |
kmlussier |
I hate seeing code sit just because we haven't reached a consensus. |
| 14:13 |
Dyrcona |
ejk: What fields are you looking for? Some have mappings stored in the Evergreen database. |
| 14:14 |
Dyrcona |
So, I'm having "fun" with the redirect from http to https for the web staff client. |
| 14:14 |
ejk |
Material Type code and Additional Authors were the two that I could only find in the MARC record |
| 14:14 |
Dyrcona |
It works fine on my Ubuntu 16.04 test vm, but I can't get it to work on training server with Debian 7. |
| 14:15 |
|
jvwoolf left #evergreen |
| 14:15 |
Dyrcona |
ejk: There are tables with mappings to get values from MARC, material type is one of them. |
| 14:17 |
Dyrcona |
You want to look at config.marc21_ff_pos_map. |
| 16:05 |
Dyrcona |
jeff: No, I don't. |
| 16:05 |
Dyrcona |
Nor, eg. |
| 16:05 |
Dyrcona |
training.cwmars.org |
| 16:06 |
Dyrcona |
As I mentioned earlier, everything works just fine on a test vm..... :( |
| 16:06 |
Dyrcona |
I did find some mess in the apache2-websockets directory on training, but the behavior is not improved after cleaning that up. |
| 16:10 |
Dyrcona |
I get the same results on production as I do on training, but I've not experimented with configuration there. |
| 16:17 |
Dyrcona |
So, are releases happening today? |
| 16:18 |
dbwells |
Dyrcona: wheels are turning, at least |
| 16:18 |
Dyrcona |
dbwells: Cool! |
| 16:41 |
pinesol_green |
[evergreen|Ben Shum] Docs: fix list item index in basic_holds.adoc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=99e7c52> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:11 |
|
jvwoolf joined #evergreen |
| 17:18 |
|
jvwoolf1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:52 |
|
rlefaive joined #evergreen |
| 22:19 |
ejk |
@marc 880 |
| 22:19 |
pinesol_green |
ejk: The fully content-designated representation, in a different script, of another field in the same record. Field 880 is linked to the associated regular field by subfield $6 (Linkage). The first and second indicator positions in field 880 have the same definition and values as the indicators in the associated field. The subfield codes in field 880 are the same as those defined in the associated (1 more message) |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
kmlussier joined #evergreen |
| 08:36 |
|
collum joined #evergreen |
| 09:53 |
pinesol_green |
csharp: Band 'Responsive XUL' added to list |
| 10:02 |
|
rlefaive joined #evergreen |
| 10:11 |
|
rlefaive joined #evergreen |
| 10:16 |
csharp |
okay, still working on testing bug 1691269 's fix (understanding that it has been committed to master)... |
| 10:16 |
pinesol_green |
Launchpad bug 1691269 in Evergreen "web client: copy templates created on XUL not displayed" [Medium,Fix committed] https://launchpad.net/bugs/1691269 - Assigned to Galen Charlton (gmc) |
| 10:17 |
jeff |
csharp: found more issues? |
| 10:17 |
csharp |
first finding is that my previously-existing XUL client templates do not show up in the web client - not sure if that's expected or not |
| 10:20 |
csharp |
probably a new bug |
| 10:20 |
csharp |
since that one has been accepted |
| 10:20 |
|
jvwoolf joined #evergreen |
| 10:20 |
jeff |
if you can reduce it to a smaller test case that might help also. |
| 10:20 |
csharp |
yeah - this is complex no matter how you slice it :-/ |
| 10:21 |
jeff |
also, you probably already know for certain, but i think there's at least one part where no further attempts are made to migrate templates after it's been "done once" for a given user/workstation/whatever. |
| 10:21 |
jeff |
(as long as you're not running into that in testing, or are accounting for it already) |
| 10:21 |
csharp |
oh wait - let me make sure everything was gone - I know the browser stored pref was deleted |
| 10:21 |
* mmorgan |
did some testing on that bug at one point, and did see existing xul templates imported to the web client successfully, but if any had been created in the web client, it didn't work. |
| 10:22 |
csharp |
right - you have to remove any setting already in the DB |
| 10:22 |
csharp |
*and* the browser-side stored pref |
| 10:23 |
mmorgan |
What setting needs to be removed from the DB? |
| 10:23 |
csharp |
mmorgan: 'webstaff.cat.copy.templates' |
| 10:24 |
mmorgan |
Ah. ok. |
| 10:24 |
* mmorgan |
may have tested an earlier version. |
| 10:24 |
csharp |
I can confirm that my user doesn't have that setting set |
| 10:24 |
csharp |
so we're as pristine as we can be when I attempt this |
| 10:25 |
csharp |
I haven't looked closely at the code that makes the conversion, though, maybe something about the XUL file is unexpected |
| 10:33 |
jeff |
(feel free to just do that in the bug, actually -- i don't mean to waste your time here when you'll probably want to put it in the bug also) |
| 10:34 |
|
rlefaive joined #evergreen |
| 10:35 |
jeff |
tmp_val.match not being a function implies that you're hitting a non-string value where the xul template conversion code isn't expecting it. |
| 10:40 |
csharp |
jeff: thanks - I'mma test this again with the further fixes then open a bug if it's still happening |
| 10:40 |
|
rlefaive joined #evergreen |
| 10:41 |
csharp |
and yes, I would expect lots of potential "garbage" in these templates - I expect many of them have been around since The Beginning™ |
| 10:41 |
jeff |
looks like at a minimum, shelving location in older xul templates can contain a non-string field value, like "Shelving Location":{"value":527,"type":"attribute","field":"location"} |
| 10:41 |
jeff |
and i think that breaks the current conversion code where it assumes a value will be a string. |
| 10:42 |
csharp |
jeff: the file: |
| 11:46 |
csharp |
jeff++ # worked! |
| 11:47 |
csharp |
so... the solution is to further check for number vs. string in the converter? |
| 11:51 |
* csharp |
runs off for a lunch break - back later :-) |
| 11:52 |
jeff |
yes. the solution is to not call .match() on a value that we don't know is a string. |
| 12:02 |
jeff |
lots of possible solutions. not sure which is best / most consistent with existing code: wrap in try/catch (possibly more than one), test for string/number (or existence of .match) using typeof, or... something else i've forgotten. |
| 12:02 |
jeff |
another concern is if the native web template code expects/handles/generates numbers vs strings. |
| 12:04 |
jeff |
be great if the template conversion had the beneficial side effect of normalizing the templates. |
| 12:04 |
|
rlefaive joined #evergreen |
| 12:04 |
jeff |
there are likely to be other quirks about existing templates. anyone want to volunteer up theirs, anonymized or otherwise? :-) |
| 12:07 |
|
rlefaive_ joined #evergreen |
| 12:08 |
|
sandbergja joined #evergreen |
| 12:09 |
miker |
how about tmp_val.toString().match() |
| 14:52 |
* csharp |
is training a new PINES library on local admin stuff and realized he hasn't even installed hatch recently :-/ |
| 14:52 |
csharp |
training is Thursday morning, so I have some time :-) |
| 14:53 |
berick |
we need to get mine and jason's patches merged.. |
| 14:56 |
csharp |
berick: I'm testing from the chrome store, so this'll be a good smoke test |
| 14:56 |
csharp |
I'll look at JBoyer's branch too if I get a chance |
| 14:57 |
* csharp |
forgets what it's like to use Windows natively |
| 14:58 |
csharp |
nice - that's very easy |
| 14:59 |
csharp |
install Java, install extension, open web client and click the checkboxes |
| 14:59 |
berick |
csharp: be sure to use this installer https://bugs.launchpad.net/evergreen/+bug/1708757/comments/2 |
| 14:59 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] - Assigned to Galen Charlton (gmc) |
| 14:59 |
berick |
at least until we build another one based on jason's changes.. |
| 18:10 |
_adb |
Dyrcona++ |
| 18:10 |
Dyrcona |
Cool. Glad my suggestion helped you figure it out. |
| 18:10 |
* Dyrcona |
goes to cook some dinner. |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
jeffdavis |
Are located URIs working in 3.0? On a test server the acts_as_copy flag set to true and a record with a located URI owned by BR1, the record does not show up in search results at any search scope. |
| 18:48 |
miker |
jeffdavis: JBoyer and I addressed an issue with located URI search during the hack-a-way, should be in tomorrow's release. (not at a computer to look for a commit hash ATM) |
| 18:50 |
jeffdavis |
ah, thanks miker |
| 18:57 |
jeffdavis |
5a187c81 looks like the relevant commit |
| 18:57 |
pinesol_green |
jeffdavis: [evergreen|Mike Rylander] LP#1723977: Move no-LURIs test to be a peer of no-copies test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a187c8> |
| 19:17 |
csharp |
7c3cdbbd |
| 19:17 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1706107: Offline mode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c3cdbb> |
| 20:28 |
* csharp |
wonders if the existence of hatch will make a difference in the speed of inserting 1.6M rows into the lovefield DB |
| 01:31 |
|
Jillianne joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 09:03 |
|
_adb joined #evergreen |
| 09:31 |
plux |
jeffdavis: still having issues with pingest .I believe it’s on me and not the script but missing something. Forgot yesterday was Thanksgiving there! |
| 09:40 |
jeff |
plux: are you able to paste your command and output (minus any information you deem sensitive) here? http://paste.evergreen-ils.org/ |
| 09:48 |
jeff |
did you remove some of the lines of output, or are you only getting errors on records 915197, 915198, and 915199? |
| 09:48 |
plux |
I just grabbed a few….the others were/are the same |
| 09:48 |
jeff |
okay, just making sure. |
| 09:49 |
plux |
I can also replicate it by piping in a small test file with small number of bib ids…. |
| 09:51 |
* jeff |
nods |
| 09:52 |
plux |
it seems like the query is passed to postgres without the values being parsed…wondering if the db server is missing some perl class or postgres mod that might impact the prepare statement |
| 09:55 |
jeff |
there was a change to pingest to use named parameters in the call to the function metabib.reingest_metabib_field_entries() |
| 10:35 |
jeff |
Dyrcona: named notation goes back to at least 9.0, but the syntax didn't support arg => 'value' until 9.5 |
| 10:36 |
jeff |
Dyrcona: previous to that, => was an hstore operator, and postgresql has been warning about => for a few versions now, because of the upcoming use of it in 9.5 and above for named notation in functions. |
| 10:40 |
Dyrcona |
Thanks, jeff. I merged it to master and to the evergreen-3.0-compatibility branch. |
| 10:41 |
plux |
just tested on this system (jeff’s first master version) and it’s working on this db |
| 10:41 |
jeff |
rather, hstore defined => as a user-defined operator back in 9.1 (and depending on various things, you could still have an old-style hstore contrib hanging around in newer databases, but you'll trip on it if you try to upgrade to 9.5) |
| 10:41 |
jeff |
plux: yay! |
| 10:41 |
jeff |
Dyrcona: thanks! |
| 10:59 |
jeff |
what, no desire to teach pingest to auto-detect the version based on the database? ;-) |
| 11:00 |
jeff |
at least one of the changes in master mentions 3.0 -- is that a commit that works for both, or is current master already >=3.0-only. |
| 11:00 |
jeff |
s/\./?/ |
| 11:01 |
plux |
just tested the 3.0 branch and it’s working well on this 9.4 db |
| 11:01 |
plux |
so both worked |
| 11:08 |
Dyrcona |
Current master works on 3.0 and lower, but you don't have the option to skip the display ingest. |
| 11:09 |
Dyrcona |
If you try to run the 3.0 branch on a 2.12 or older db, the ingests fail because there's no skip_display option. |
| 11:09 |
Dyrcona |
If it had been added at the end of the other options, I may have a workable solution. |
| 14:05 |
|
rlefaive joined #evergreen |
| 14:14 |
|
Dyrcona joined #evergreen |
| 14:47 |
|
rlefaive joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:21 |
|
beanjammin joined #evergreen |
| 00:10 |
|
Jillianne joined #evergreen |
| 00:27 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Set Per-OU Limits on Allowed Payment Amounts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5e01e8a> |
| 00:58 |
|
jvwoolf joined #evergreen |
| 01:44 |
|
jvwoolf joined #evergreen |
| 01:58 |
|
jvwoolf joined #evergreen |
| 03:55 |
|
jvwoolf joined #evergreen |
| 04:44 |
|
jvwoolf joined #evergreen |
| 05:50 |
|
jvwoolf joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:44 |
|
jvwoolf joined #evergreen |
| 06:55 |
|
jvwoolf joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:27 |
|
plux joined #evergreen |
| 09:01 |
|
_adb joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:07 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating SIP docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe30899> |
| 09:07 |
|
bos20k joined #evergreen |
| 09:16 |
Bmagic |
Dyrcona: I'll see if I can figure it out |
| 09:18 |
collum |
kmlussier: take a look at the proposals page now. I removed some divs that got pasted in from another page. The only indication that there was a problem in chrome on either my mac or pc was a slight indention. |
| 09:19 |
kmlussier |
collum: Yeah, that's what I saw in Firefox. Looks good to me now! Thanks! |
| 09:19 |
kmlussier |
collum++ |
| 10:44 |
* jeff |
looks at the latest test failure, knowing that postgresql folk changed their cipher suites yesterday... |
| 10:44 |
jeff |
> a2x: ERROR: missing resource: /home/opensrf/Evergreen/docs/media/copytags6.PNG |
| 10:44 |
jeff |
failure building asciidoc docs. |
| 10:46 |
jeff |
there is a docs/media/copytags6.png but docs/cataloging/copy_tags_cataloging.adoc references copytags6.PNG |
| 10:48 |
jeff |
we appear to have a mix of uppercase and lowercase filenames on PNGs in docs/media at the moment. |
| 10:55 |
kmlussier |
I think we went through those a few years ago to make them all lowercase. We might have to look into doing that again. |
| 10:55 |
jeff |
the majority are indeed lowercase. |
| 10:55 |
jeff |
has a preference for lowercase been made official anywhere in a style guide / etc? |
| 12:13 |
kmlussier |
_adb: I'm just afraid that if I complain, *it* will notice and start acting up again. |
| 12:13 |
kmlussier |
jeff++ #Docs fix |
| 12:13 |
pinesol_green |
[evergreen|Jeff Godin] Docs: fix broken image reference - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=50ac305> |
| 12:15 |
jeff |
remingtron++ phasefx++ for adding docs building to the tests. |
| 12:16 |
jeff |
and postgresql++ folk for re-adjusting their cipher suites so that we didn't have to work around it. |
| 12:17 |
jeff |
(using curl instead of wget would have fixed the gpg key download, but the actual apt https transport would also have been broken, then) |
| 12:21 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1708487 Add Title and Barcode to Bill Print Templates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=421cdd7> |
| 12:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1708487: Update helper text in print template - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ba737d> |
| 12:33 |
|
beanjammin joined #evergreen |
| 17:34 |
* jeff |
throws a comment on bug 1719986 and heads out |
| 17:34 |
pinesol_green |
Launchpad bug 1719986 in Evergreen "Pg 9.6 unaccent() changes how certain characters are normalized" [Low,New] https://launchpad.net/bugs/1719986 |
| 17:42 |
* Dyrcona |
can't argue with that. :) |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:52 |
jeff |
tests++ |
| 20:05 |
|
rlefaive joined #evergreen |
| 00:54 |
|
Jillianne joined #evergreen |
| 01:24 |
|
beanjammin joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:37 |
|
ariez102 joined #evergreen |
| 06:37 |
ariez102 |
hello and hi! |
| 06:37 |
ariez102 |
i already install evergreen ils |
| 10:06 |
bshum |
It seems to be getting stuck at "gpg: no valid OpenPGP data found." |
| 10:06 |
bshum |
Which is meaning that the wget is coming back without the key data to add, I guess. |
| 10:07 |
bshum |
When I run the command on my other server, it comes back with a good hit, so weird. |
| 10:07 |
jeff |
Dyrcona: tests are failing because the version/config of wget + gnutls on Wheezy does not have support for any of the ciphers offered by most of the postgresql.org servers serving the gpg key which we try to download from them. |
| 10:07 |
Dyrcona |
jeff: Yeah, I got that much. I didn't actually look at the details. |
| 10:08 |
Dyrcona |
Must be something about the way it is scripted. |
| 10:08 |
Dyrcona |
It has worked for me when run from a normal login session. |
| 10:08 |
jeff |
A quick test showed that switching to curl is sufficient to fix the issue at hand. Longer term, wheezy LTS EOL is coming up May 2018. ;-) |
| 10:08 |
|
stephengwills joined #evergreen |
| 10:08 |
jeff |
Dyrcona: no, nothing wrong with the way that it is scripted. |
| 10:09 |
jeff |
Dyrcona: it's failing on all but one of the servers answering https requests for www.postgresql.org |
| 10:09 |
Dyrcona |
Then, I'd go with switching to curl or apply my branches to remove wheezy support. :) |
| 10:10 |
Dyrcona |
We do the same command on Ubuntu 14.04, IANM. |
| 10:12 |
bshum |
I guess we could also report it as a bug to the apt postgresql team? |
| 10:19 |
bshum |
Fixed in version wget/1.16-1 |
| 10:19 |
bshum |
So the one that's installed on Wheezy is wget 1.13.4 I guess, (based on what I see on lupin which is also wheezy) |
| 10:20 |
|
jvwoolf joined #evergreen |
| 10:22 |
Dyrcona |
I don't seem to recall having that problem when testing this on wheezy, though. |
| 10:22 |
jeff |
bshum: that bug is an issue different from the one at hand. |
| 10:22 |
bshum |
Hmm, probably, now that I'm reading it more closely |
| 10:23 |
jeff |
bshum: though the warning/error reported by wget is the same or identical. |
| 10:48 |
berick |
but, having said that, the sigalarm would not affect storage process, just the search procs that fired the alarm. |
| 10:48 |
berick |
s/search procs/search proc/ |
| 10:49 |
jeff |
gave a heads-up to the postgresql folk via irc. they're discussing it now. i suggested just a doc update, not a revert to the old cipher suites. :-) |
| 10:51 |
dbwells |
berick: Ah yes, sorry, misremembered the order a bit. In some of the testing, the involved storage requests complete, but the search backend is gone when it tries to return the result. Is that right? |
| 10:51 |
berick |
dbwells: exactly |
| 10:51 |
bshum |
jeff++ |
| 10:54 |
dbwells |
The point is really that it doesn't affect just facets, but any call to open-ils.search might come up empty, because the errant alarm kills the backend serving some other request. In our case, we were seeing it mostly on open-ils.search.biblio.copy_counts.location.summary.retrieve. |
| 12:17 |
Dyrcona |
I have not had any noticeable cstore issues. |
| 12:17 |
Dyrcona |
Mine all seem to be related to search. |
| 12:19 |
|
khuckins_ joined #evergreen |
| 12:21 |
phasefx_ |
bshum: wget 1.13.4-3+deb7u5 on that server. The tests run a dpkg --list and a cpan -l in the Gathering system information section |
| 12:25 |
Bmagic |
Dyrcona: sorry, yes, search. |
| 12:25 |
Bmagic |
open-ils.storage.biblio.multiclass.staged.search_fts: DBD::Pg::st execute failed: no connection to the server |
| 12:25 |
Bmagic |
I haven't pinpointed a place in the logs that shows me where it was working, then stopped working |
| 13:07 |
* Dyrcona |
hits a totally not Evergreen-related bug: https://bugs.freedesktop.org/show_bug.cgi?id=99714 |
| 13:07 |
pinesol_green |
Dyrcona: Error: Could not parse XML returned by Freedesktop: HTTP Error 404: Not Found (http://bugs.freedesktop.org/xml.cgi?id=99714) |
| 13:13 |
Dyrcona |
Looks like pinesol_green hit a bug, too. :) |
| 13:14 |
Dyrcona |
Whee! More stream crossing: a ssh tunnel I had made on the test db server died and the error output from that is mixed in with the output of a db restore. |
| 13:14 |
Dyrcona |
Makes for a confusing couple of seconds... "packet write error? what?" :) |
| 13:30 |
|
akilsdonk joined #evergreen |
| 13:37 |
|
hbrennan joined #evergreen |
| 15:06 |
Bmagic |
is that your "secret" name? |
| 15:06 |
npoolos |
we are getting so one off haproxy timeouts on search |
| 15:06 |
Bmagic |
You probably need to apply the alarm patch |
| 15:07 |
Bmagic |
In my case, I have that patch in place and our test servers need to have the services restarted every morning |
| 15:07 |
npoolos |
no this is now Nick Poolos. I was looking a something else and holly made me sit down and start talking |
| 15:07 |
Bmagic |
Ubuntu 16.04 / PG 9.5 / OpenSRF 3.0.0 |
| 15:08 |
npoolos |
anything in the logs that is evidence of drone death? |
| 16:23 |
Dyrcona |
Whatever. :) |
| 16:33 |
Dyrcona |
Hm... I keep getting no connection to the database, but I have only 30 postgres processes running and max connections is 100.... |
| 16:34 |
Dyrcona |
Neither machine is particularly busy. |
| 16:34 |
Dyrcona |
This is coming from a storage call on a test vm. open-ils.storage is configured correctly. |
| 16:38 |
Dyrcona |
And drones are up and running just fine.... |
| 16:40 |
Dyrcona |
Hmm... Restart services and apache2 and it works! |
| 16:43 |
Dyrcona |
Well, the alarm timeout patch doesn't fix our issue with the reports template folder not loading all the templates. |
| 17:44 |
Bmagic |
I am pretty sure this wasn't an issue Friday Nov. 3rd |
| 17:44 |
Bmagic |
I am working from 16.04 .01 .... maybe that's my issue? |
| 17:46 |
|
jvwoolf joined #evergreen |
| 17:47 |
Dyrcona |
I doubt it. I've been installing test vms on ubuntu 16.04 since before then. |
| 17:48 |
Dyrcona |
It's curious. I wonder if something is wrong with your pkg-config installation. |
| 17:49 |
Dyrcona |
There's a command to audit the installed packages. I don't remember what it is exactly. |
| 17:50 |
Dyrcona |
dpkg --verify pkg-config |
| 17:53 |
Dyrcona |
dpkg --audit too |
| 17:53 |
|
jvwoolf joined #evergreen |
| 18:14 |
|
_adb joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:44 |
|
jvwoolf joined #evergreen |
| 18:50 |
|
jvwoolf joined #evergreen |
| 19:57 |
|
jvwoolf joined #evergreen |
| 21:52 |
|
jvwoolf joined #evergreen |
| 22:45 |
|
jvwoolf joined #evergreen |
| 22:55 |
|
jvwoolf joined #evergreen |
| 23:33 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: making tt2 docs more modular - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0150bb3> |
| 23:33 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: search scope info - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2a34ead> |
| 23:33 |
pinesol_green |
[evergreen|Jane Sandberg] Merge branch 'master' of git.evergreen-ils.org:Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=119ef7a> |
| 23:44 |
|
jvwoolf joined #evergreen |
| 23:52 |
|
jvwoolf joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
JBoyer joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 09:50 |
kmlussier |
dbwells / Dyrcona: Thanks! Calendar has been updated. :) |
| 09:55 |
Dyrcona |
Cool! My pg_restore on my development db hits Lp 1671150. |
| 09:55 |
pinesol_green |
Launchpad bug 1671150 in Evergreen 3.1 "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Medium,Confirmed] https://launchpad.net/bugs/1671150 |
| 09:56 |
Dyrcona |
So, this will be a complete test of jeff's branch. |
| 10:30 |
Dyrcona |
JBoyer: Should Lp 1707668 have a pull request tag? |
| 10:30 |
pinesol_green |
Launchpad bug 1707668 in NCIPServer "RenewItem Message Crashes Due to Malformed Method Call" [Undecided,New] https://launchpad.net/bugs/1707668 |
| 10:30 |
* Dyrcona |
thinks so. |
| 10:41 |
Dyrcona |
JBoyer: What distro do you use in production, Ubuntu 14.04? |
| 10:42 |
JBoyer |
yes |
| 10:42 |
jeff |
Dyrcona: yeah, regarding the evergreen.unaccent_and_squash bug I don't think you should need to have any particular -j level to hit it. You should just always hit it at pg_restore time if you have those indexes present and the current (unfixed) version of thee function in the dumped db. |
| 10:42 |
JBoyer |
Haven't had much time to test 16.04 on dev yet. |
| 10:42 |
jeff |
(iirc, ottomh, etc) |
| 10:43 |
Dyrcona |
jeff: OK. I guess I haven't paid enough attention when restoring dev dbs since the upgrade. |
| 10:43 |
JBoyer |
A higher -j will likely hit it faster, though. |
| 14:40 |
|
hbrennan joined #evergreen |
| 15:01 |
|
khuckins_ joined #evergreen |
| 15:58 |
|
khuckins_ joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:24 |
|
stephengwills left #evergreen |
| 18:18 |
|
JBoyer_alt joined #evergreen |
| 19:07 |
|
JBoyer_alt_bin joined #evergreen |
| 11:13 |
remingtron |
phasefx: okay, thanks, I'll keep that in mind for future changes. |
| 11:14 |
gsams |
Dyrcona: I have not, I will give that a whirl. |
| 11:20 |
dbs |
gsams: are you seeing the files landing on the share when you import them? |
| 11:21 |
gsams |
dbs: I'm not sure, but I don't think they are. I'll see about running a file through specifically to test that. |
| 11:22 |
|
_adb joined #evergreen |
| 11:26 |
gsams |
dbs: well I used marcedit to split the file I was uploading into 3 parts and it has created a new file on the share. |
| 11:27 |
gsams |
It's not processing the records though, it's stuck at 0% |
| 11:29 |
gmcharlt |
tossing out a suggestion for the maintenance releases - let's defer them to 11/29 rather than tomorrow if buildmasters are available then |
| 11:29 |
gmcharlt |
to incorporate some more bugfixes and to coordinate a major Hatch update |
| 11:29 |
gmcharlt |
I'd otherwise suggest 11/22, but that of course runs into U.S. Thanksgiving |
| 12:11 |
|
khuckins joined #evergreen |
| 12:11 |
|
sandbergja joined #evergreen |
| 12:16 |
|
JBoyer joined #evergreen |
| 12:18 |
beanjammin |
I'm hoping someone can point me in the right direction. I'm just getting started on using angular and am not sure what EG data (if any) is available via javascript and how to access it. |
| 12:18 |
beanjammin |
I am trying to conditionally add a class to a row in the staff web client Items Out list at /eg/staff/circ/patron/16/items_out based on whether the item is overdue or not. I can see in t_autogrid.tt2 how the eg-grid-row-selected class is added via ng-class when the checkbox is checked, but I'm not sure how to do the same based on due date. Is items only available in perl/tt2 or is it or similar info available in js? If so, can I use |
| 12:18 |
beanjammin |
$scope.circIsOverdue from items_out.js to test? |
| 12:19 |
beanjammin |
Thanks for any pointers or doc suggestions. |
| 12:35 |
berick |
beanjammin: sounds like we need a new grid feature -- the ability to apply an arbitrary class to a row based on the row contents. |
| 12:36 |
|
krvmga joined #evergreen |
| 12:39 |
khuckins |
That would be a useful feature for other cards with similar purposes(off the top of my head I can think of lp1635386) as well |
| 15:03 |
rthimons |
I ran the make file so I thought they would have already installed. |
| 15:04 |
Dyrcona |
You did make -f $PATH/src/extras/Makefile.install postgres-server-$distro ? |
| 15:04 |
rthimons |
I'll run it again just to be sure. I have several environments so it's possible I missed something. |
| 15:05 |
Dyrcona |
You probably need to load some extensions in the db also. I'm facing that on my testing server, I think. |
| 15:05 |
rthimons |
I'll run that make file one more time. Any suggestions on how to find the missing extensions? |
| 15:08 |
Dyrcona |
rthimons: Look in Open-ILS/src/sql/Pg/create_database_extensions.sql under your Evergreen directory. |
| 15:09 |
jeffdavis |
If you're using psql you can do \dx to check if the extensions in that file are actually installed on your new server. |
| 15:26 |
* Dyrcona |
messes with bug targets though it may not make it into tomorrow's releases. |
| 15:31 |
abneiman |
Dyrcona: gmcharlt miker & dbwells briefly discussed pushing monthlies back to 11/29 somewhere upthread. So you may have time! |
| 15:32 |
Dyrcona |
abneiman++ # I missed that. I stepped away to have some lunch. |
| 15:33 |
Dyrcona |
Testing this without messing with production will be interesting. |
| 15:33 |
Dyrcona |
I have extra db servers, but moving dumps around will require some networking gymnastics. ;) |
| 15:50 |
csharp |
Dyrcona: pg_basebackup from one of the free servers? |
| 15:50 |
csharp |
requires a bit-for-bit copy of the DB, but very quick and handy |
| 15:51 |
csharp |
s/quick and handy/super damn slow in your case/ |
| 15:51 |
Dyrcona |
rsync with --bandwidth= is my best bet. |
| 15:52 |
Dyrcona |
Well, at one location the bandwidth is asymmetrical and that's the one that I'd be sending from, so I don't want to crush what others are doing. |
| 15:52 |
Dyrcona |
I've had that happen just sending marc records to the masslnc servers for testing. |
| 15:53 |
Dyrcona |
So, yeah, gymnastics are required. :) |
| 15:53 |
Dyrcona |
Hm... It happened on this testing server again with -j 4. |
| 15:54 |
Dyrcona |
I should see if it happens on the development server. |
| 16:43 |
|
gsams joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
bshum |
That's interesting that it failed again |
| 17:02 |
bshum |
On getting the postgresql apt repo key |
| 17:02 |
bshum |
It worked fine this morning, but not in the afternoons. I wonder why. Hmm. |
