| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
rjackson_isl_ joined #evergreen |
| 07:27 |
|
jvwoolf joined #evergreen |
| 09:14 |
csharp |
kmlussier: thanks! |
| 09:15 |
csharp |
I want to reproduce it - if it's because I connected to multiple EG servers in a single browser (seems to be so, since the failure is related to actor.survey), it may not need to be considered a bug, per se |
| 09:15 |
csharp |
i.e., the answer might just be "don't do that" |
| 09:20 |
kmlussier |
csharp: I have connections open to multiple Evergreen servers in the same browsers all the time. I'm constantly doing side-by-side testing on two different servers. I don't think that should cause the problem. |
| 09:21 |
kmlussier |
csharp: When it previously happened to me, it was more likely to happen after I rebuilt my VM. |
| 09:26 |
|
yboston joined #evergreen |
| 09:26 |
|
rfrasur joined #evergreen |
| 09:32 |
|
mllewellyn joined #evergreen |
| 09:56 |
kmlussier |
pinesol_green: Thank you for not giving me decaf. |
| 09:56 |
pinesol_green |
kmlussier: Have you confirmed your ISBN SPIDs with your service provider? |
| 09:56 |
rfrasur |
kmlussier: anything that helps suss the thing out. |
| 09:57 |
berick |
rfrasur: the print test interface includes an image. does that one work? |
| 09:57 |
rfrasur |
let's see. |
| 09:58 |
rfrasur |
berick: that's on the way. |
| 09:59 |
berick |
rfrasur: next question, are you testing on a machine w/ a valid SSL certificate? |
| 09:59 |
rfrasur |
The image does work. (I'm the go between here, sorry) |
| 09:59 |
berick |
oh, good |
| 09:59 |
rfrasur |
lol, uh huh |
| 10:01 |
rfrasur |
@coffee berick |
| 10:01 |
* pinesol_green |
brews and pours a cup of Hacienda La Esmeralda, and sends it sliding down the bar to berick |
| 10:01 |
rfrasur |
You're a good person. |
| 10:02 |
berick |
heh, ok, backing up.. so the test image works? |
| 10:03 |
rfrasur |
it does, and throwing a new image in there works, but it doesn't seem to work in the actual receipts. |
| 10:04 |
berick |
ah, ok |
| 10:04 |
berick |
which receipt are you testing? |
| 10:04 |
rfrasur |
holds shelf |
| 10:05 |
csharp |
kmlussier: ah - that makes sense - I have rebuilt my test VMs DB recently |
| 10:09 |
berick |
rfrasur: i'm setting up a test to see if I can make it work.. |
| 06:08 |
|
phasefx joined #evergreen |
| 06:09 |
|
berick joined #evergreen |
| 06:10 |
|
maryj joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 07:55 |
|
Dyrcona joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
|
jvwoolf joined #evergreen |
| 08:49 |
|
jvwoolf1 joined #evergreen |
| 09:23 |
csharp |
cool - Fedora (as of 27) has javafx in the repos which means I can theoretically use Hatch on my main OS |
| 09:23 |
csharp |
of course, I've not had great luck with networked printers on Fedora over the last couple of releases :-/ |
| 09:26 |
csharp |
./hatch.sh compile and ./hatch.sh test appear to work fine |
| 09:27 |
Dyrcona |
I build Hatch on Ubuntu 16.04, but have not used it on Linux. |
| 09:27 |
Dyrcona |
s/build/built/ |
| 09:33 |
csharp |
berick: referring back to our exchange last week (http://irc.evergreen-ils.org/evergreen/2017-12-06#i_336931), I'm not seeing org.evergreen_ils.hatch.json in ~/.config/google-chrome/NativeMessagingHosts/ - I do see it in the Hatch git repo thouhg |
| 14:26 |
|
mmorgan left #evergreen |
| 14:33 |
|
rlefaive joined #evergreen |
| 14:36 |
Dyrcona |
fcc-- |
| 14:44 |
csharp |
fcc-- |
| 14:44 |
csharp |
pai-- |
| 14:46 |
csharp |
berick: ok, I've tested the lp1733692-nsis-best-practices-signoff hatch branch on Windows and Linux and all is working - I'm a little confused about what needs signing off for all to be official... |
| 14:47 |
csharp |
bug 1733692 and bug 1708757 |
| 14:47 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692 |
| 14:47 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] https://launchpad.net/bugs/1708757 - Assigned to Galen Charlton (gmc) |
| 14:49 |
csharp |
I see - looks like we're just waiting on signoffs of bug 1708757 |
| 16:04 |
jeff |
alas, this is neither bash nor vim. |
| 16:11 |
|
rlefaive joined #evergreen |
| 16:42 |
csharp |
jeff++ |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:54 |
|
jvwoolf joined #evergreen |
| 19:09 |
|
jvwoolf joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:09 |
|
agoben joined #evergreen |
| 07:37 |
|
dwgreen joined #evergreen |
| 13:25 |
pinesol_green |
Launchpad bug 1730752 in Evergreen "Webstaff option to show/hide multiple grid columns" [Undecided,New] https://launchpad.net/bugs/1730752 |
| 13:42 |
Dyrcona |
Is there a way to get the title of a bib record out of the database in title case without doing oils_xslt_process and oils_xpath_string? |
| 13:42 |
Dyrcona |
If I join with reporter.materialized_simple_record the title is normalized to lower case. |
| 13:43 |
Dyrcona |
And, if I try the oils_xslt_process and oils_xpatch_string method on all of the records in one query, I crash my test db server. :) |
| 13:45 |
csharp |
Dyrcona: depending on the need, you can also use initcap() which will capitalize the first letter in every word (not perfect and not preserving the original case, but maybe better?) |
| 13:45 |
Dyrcona |
Well, it's a dump for Novelist On-the-Shelf. |
| 13:46 |
csharp |
ah' |
| 16:58 |
mmorgan |
So seems like something is different with a new build vs upgrade? |
| 16:58 |
kmlussier |
I think I linked to the log in that bug. |
| 16:59 |
mmorgan |
Indeed you did! |
| 17:00 |
* kmlussier |
hasn't tested miker's patch for that issue yet. |
| 17:01 |
kmlussier |
mmorgan: But the upgrade vs. new build difference makes sense to me. It would explain why you didn't originally see the problem on the upgraded system until you added a new record with a Located URI, while I saw the problem with all the records on my newly-built system. |
| 17:04 |
* mmorgan |
is heading home, but is sure to have dreams about this bug :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:22 |
|
kmlussier joined #evergreen |
| 17:28 |
|
kmlussier joined #evergreen |
| 17:41 |
|
mllewellyn left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:36 |
|
mnsri joined #evergreen |
| 21:36 |
|
rashma joined #evergreen |
| 22:55 |
|
Christineb joined #evergreen |
| 03:44 |
|
sard joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:45 |
|
dwgreen joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 15:37 |
|
bshum joined #evergreen |
| 15:40 |
|
phasefx joined #evergreen |
| 15:45 |
|
RBecker joined #evergreen |
| 15:55 |
jeffdavis |
I'm puzzled that the fix for bug 1736419/1730758 is working for others but not on my test system |
| 15:55 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 15:56 |
* mmorgan |
is puzzled about that, too. |
| 15:59 |
jeffdavis |
https://upstream.catalogue.libraries.coop/eg/opac/record/249 is a record with a located URI at BR1, but the record doesn't show up in a catalog search on that server. |
| 16:04 |
jeffdavis |
mmorgan: hmm, for records with located URIs and no holdings I only have very small values in vis_attr_vector - e.g. the record above has {4} in there which is the actor.org_unit.id of the located URI location |
| 16:06 |
mmorgan |
jeffdavis: Yes, I see similar for most records with located uris and no holdings, but some also show, for example: {268435571,74} |
| 16:07 |
kmlussier |
jeffdavis / mmorgan: Before the fix was even added, I was puzzled that people saw different behavior in the original bug report. |
| 16:08 |
mmorgan |
jeffdavis: is your test system a fresh install of 3.0? |
| 16:08 |
mmorgan |
Ours is an upgrade. |
| 16:10 |
jeffdavis |
Ours a fresh 3.0.2 install with concerto data. |
| 16:12 |
jeffdavis |
kmlussier: yeah, good point |
| 16:17 |
kmlussier |
mmorgan: And you don't see a difference between new Located URI records and ones that were there before the upgrade? |
| 16:36 |
Dyrcona |
No, you're talking about cat.maintain_control_numbers, me thinks. |
| 16:36 |
mmorgan |
kmlussier, jeffdavis: I can retrieve my newly created record in the opac. The link is not showing at the cons level, but the record is retrieved in a search. |
| 16:36 |
Dyrcona |
Or, rather, I think the flag you mentioned affects the behavior of both. |
| 16:38 |
kmlussier |
mmorgan: The link isn't displaying at the cons level? That's strange. In the previous testing, the problem only seemed to affect what was retrieved in searches, not the link display. |
| 16:39 |
mmorgan |
Yes, I hadn't noticed that before. |
| 16:40 |
* csharp |
confirms that OCLC libraries set cat.bib.use_id_for_tcn = false |
| 16:40 |
Dyrcona |
I think you've confirmed that an OCLC library/consortium sets it to false. |
| 17:15 |
miker |
jeffdavis: -^ |
| 17:35 |
jeffdavis |
Ah, ok. Bib source is null for all records on a default install apparently. (Adding a source added a large-number entry to vis_attr_vector, but records with luris still don't show in public search results for me, fwiw.) |
| 17:58 |
|
jvwoolf1 left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:05 |
|
Jillianne joined #evergreen |
| 00:34 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
JBoyer joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 13:28 |
JBoyer |
Nothing useful in the browser console? (there certainly isn't in Firefox when I'm trying to see what's what there. :/ ) |
| 13:28 |
Dyrcona |
By that I mean, if you specify 3 directories, it looks in the last, then the middle, then the first, right? |
| 13:28 |
JBoyer |
Dyrcona, My understanding is that you're right though I haven't tried it. |
| 13:29 |
Dyrcona |
JBoyer: That's what I think, and I'm about to test it, maybe. :) |
| 13:29 |
JBoyer |
Dyrcona++ |
| 13:31 |
Dyrcona |
I can test it in training.. |
| 13:44 |
Dyrcona |
Bleh. Training is behind, or at least we've made many changes to our customizations since I last updated training. I have 13 files with conflicts. |
| 13:55 |
|
khuckins_ joined #evergreen |
| 14:01 |
Dyrcona |
JBoyer: I'm not having any luck, but it looks like my training configuration is kind of messed up. |
| 15:21 |
csharp |
JBoyer: it's pretty great |
| 15:22 |
Dyrcona |
@dunno |
| 15:22 |
pinesol_green |
Dyrcona: Fire BAD! Reading GOOD! |
| 15:22 |
csharp |
@blame add $who tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 15:22 |
pinesol_green |
csharp: The operation succeeded. Blame #29 added. |
| 15:24 |
Dyrcona |
@who loves [band] |
| 15:24 |
pinesol_green |
bwicksall loves C-Sharp and The Servers. |
| 17:37 |
berick |
Bmagic: familar with process of opening the extension console? similarly, ~/.evergreen/hatch.log* may have something useful. |
| 17:37 |
|
gsams joined #evergreen |
| 17:38 |
Bmagic |
berick: yeah, I think I will have to setup a screen sharing session with him and get some of those details. Glad to hear that folks have it working. Lets me know that it should* work |
| 17:39 |
berick |
Bmagic: to be clear, it sounds your user has clocked more time than I did using Hatch on OSX. I just did basic function tests. |
| 17:40 |
Bmagic |
berick: thanks! |
| 17:40 |
berick |
they may be in rarefied air |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:57 |
|
ejk joined #evergreen |
| 19:00 |
|
bshum joined #evergreen |
| 19:01 |
|
eby joined #evergreen |
| 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 |
| 17:13 |
miker |
kmlussier: that suggests you have a NULL bre.v_a_v, as that's how staff search would look at that situation |
| 17:13 |
miker |
good news is, the upgrade script to correct the data should be very targetted and not too painful in terms of run time |
| 17:14 |
kmlussier |
miker: Well, whatever day it gets fixed will be tomorrow on whatever day precedes it. :) |
| 17:16 |
jeffdavis |
I have a test server where a record with located URIs and non-null vis_attr_vector doesn't show in OPAC search. |
| 17:16 |
jeffdavis |
That server has some customizations though, I'll see if I can confirm on a server running vanilla EG. |
| 17:17 |
miker |
jeffdavis: thanks |
| 17:17 |
kmlussier |
miker: I'm seeing null in that field for my two test records. |
| 17:17 |
miker |
kmlussier: good, that's helpful. thanks |
| 17:19 |
kmlussier |
I'll make a comment on bug 173641. I don't think I'll mark it as a duplicate yet since the behavior rjackson described for public catalog searches is a little different. |
| 17:19 |
kmlussier |
Wrong bug number. You all know what I meant. |
| 17:19 |
miker |
kk, thanks |
| 17:25 |
miker |
ah... I think I see it. it'll be at least tomorrow for a fix, though |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 20:10 |
|
beanjammin joined #evergreen |
| 20:11 |
|
Dyrcona joined #evergreen |
| 20:11 |
Dyrcona |
I know no one is likely to be around, but here goes. |
| 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 |
