| 00:30 |
|
phasefx_ joined #evergreen |
| 02:51 |
|
JBoyer_alt joined #evergreen |
| 02:52 |
|
ohiojoe_ joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
agoben joined #evergreen |
| 07:17 |
|
JBoyer joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 13:04 |
mmorgan |
Bmagic: We're happy with the policy following the owner, so never investigated changing it. |
| 13:04 |
library |
instruction said to type following command. so i did. then re-read instruction and it said to replace "prefix" with default opensrf folder... grr |
| 13:07 |
|
jvwoolf joined #evergreen |
| 13:08 |
Bmagic |
library: yeah, the instructions have a lot of details that make a big difference. If you want to get an Evergreen server up and running for testing purposes, you can skip the full installation process and use the docker container |
| 13:09 |
Dyrcona |
Bmagic: The answer to your question is "It depends on what you mean by lost policy, and if you only want the lost policy." |
| 13:09 |
library |
there are already existing test servers for evergreen that i've visited from the URL. We're looking to install and run evergreen on a localhost machine |
| 13:10 |
Dyrcona |
library: Bmagic's docker container is a quick way to set up a test Evergreen instance with stock test data. |
| 13:11 |
Dyrcona |
Bmagic: It is pretty straightforward to set up the circ matrix so that the owning libraries circulation rules are used. |
| 13:12 |
Bmagic |
library: https://hub.docker.com/r/mobiusoffice/evergreen-ils/ |
| 13:12 |
* Dyrcona |
can spell, honestly.... :) |
| 14:15 |
Dyrcona |
library: I'm not so sure about that. |
| 14:15 |
library |
sledgehammer flyswatter perhaps. but I'm curious |
| 14:16 |
Dyrcona |
Bmagic: I don't think I understand your question. |
| 14:17 |
Bmagic |
kmlussier: the docker container option seems relevant for library. library could get the server running for testing purposes in a few minutes. |
| 14:17 |
Bmagic |
Dyrcona: The age to lost concept is handled via action trigger in Evergreen right? |
| 14:18 |
Dyrcona |
Bmagic: Yes, but it's the second part that I don't understand. It ages thing regardless of where they're checked out. I don't think I understand your goal. |
| 14:18 |
Bmagic |
library: if you are not sure weather or not you are going to use the Evergreen ILS as your solution and you are just needing to test it out, then the docker container is it! |
| 14:18 |
Dyrcona |
library: This is the most eclectic consortium that I'm aware of. They are using Koha: http://www.masscat.org/current-members-list/ |
| 14:19 |
|
sandbergja joined #evergreen |
| 14:19 |
Bmagic |
Dyrcona: some of our members would like to know if it's "easy" to institute the lost action trigger on ALL items checked out at their library, instead of having the owning library's AT act upon the item that is circed at their library |
| 14:20 |
Dyrcona |
library: No law firms in that list, but a hospital or two. |
| 14:20 |
library |
there are already existing test servers for evergreen that i've reviewed... is the docker somehow different than these web-accessible test sites? |
| 14:20 |
Dyrcona |
Bmagic: That sounds like the opposite of what you asked earlier, but I'm getting old. :) |
| 14:21 |
Bmagic |
library: it would be running on your machine |
| 14:21 |
Dyrcona |
Bmagic: I think you'd have to change the trigger code or use a filter, but I'm also not an expert on A/T. |
| 14:21 |
Bmagic |
library: I could ask you the same question - installing Evergreen on your local machine is somehow different than the web-accessible test sites? |
| 14:21 |
Dyrcona |
Bmagic: I think library is ready to go beyond the kick the tires stage. |
| 14:21 |
library |
i cannot create records that a lawyer on site can search for and find a text on our shelf from? |
| 14:22 |
library |
none of our lawyers are going to waste their time searching a test database for books about kitty cats |
| 14:22 |
Bmagic |
library: you would like to import MARC into the test site? I believe that's possible (however, the databases on the test sites might be subject to reset from time to time) |
| 14:22 |
library |
I want MARC book records added |
| 14:22 |
Dyrcona |
You can do that with the docker image. |
| 14:23 |
Bmagic |
library: and, yes, you can do that with the docker image |
| 15:24 |
pinesol_green |
Launchpad bug 1719986 in Evergreen "Pg 9.6 unaccent() changes how certain characters are normalized" [Low,New] https://launchpad.net/bugs/1719986 |
| 15:25 |
Dyrcona |
Fun... |
| 15:26 |
Dyrcona |
Something told me we should have gone with Perl module instead on that one. |
| 15:27 |
kmlussier |
In my testing, which could be flawed, the staff login inactivity timeout OU setting does not affect web client authentication sessions. Is there anything ATM that will automatically log out staff after a period of idleness? |
| 15:27 |
gmcharlt |
eh, that would have not provided additional guarantee of things not hcanging |
| 15:28 |
Dyrcona |
gmcharlt: True. |
| 15:31 |
berick |
kmlussier: i've noticed in passing the automatic logout only works sometimes. |
| 17:04 |
Dyrcona |
But, like I said, I think the confusion outweighs the benefit. |
| 17:05 |
Bmagic |
I have a cell phone that charged me per text, and I wouldn't mind getting the text for this one book but I don't care to pay for the text messages for the others.... |
| 17:05 |
kmlussier |
However, if we implement it with YAOUS, then we avoid some of those potential pitfalls. |
| 17:05 |
jeff |
kmlussier: right, we shouldn't determine concensus based on who happens to be non-idle on irc at any given time. |
| 17:05 |
jeff |
kmlussier: still useful for a smoke test, though. |
| 17:05 |
mmorgan |
regarding my previous comment about patron visibility, lp 1720005 |
| 17:05 |
pinesol_green |
Launchpad bug 1720005 in Evergreen "Provide a way for patrons to see and update hold notification preferences while logged into the opac" [Undecided,New] https://launchpad.net/bugs/1720005 |
| 17:05 |
kmlussier |
mmorgan++ |
| 17:24 |
jeff |
hah! surely you jest. |
| 17:30 |
kmlussier |
Looks like I just have that one small web client doc contribution for today. Maybe I can carve out more time on Friday. |
| 17:30 |
kmlussier |
Have a nice night everyone! |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 20:04 |
gmcharlt |
https://evergreen-ils.org/release-candidate-for-evergreen-3-0-now-available/ |
| 23:25 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: root.adoc can now compile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b2ee1ea> |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
Dyrcona joined #evergreen |
| 08:02 |
|
_bott_ joined #evergreen |
| 08:56 |
mmorgan |
kmlussier: I was just able to batch update expiration date of patrons in a bucket without a problem. |
| 08:57 |
|
krvmga joined #evergreen |
| 08:57 |
kmlussier |
mmorgan: Hmmm, did you do something different from what I did? |
| 08:58 |
mmorgan |
Looking at your steps now. |
| 08:58 |
|
_bott_ joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:01 |
mmorgan |
Looks like the same steps. It's working on our test server. |
| 09:01 |
kmlussier |
I also have hit bug 1718301 again on recent master from yesterday. |
| 09:01 |
pinesol_green |
Launchpad bug 1718301 in Evergreen "Webstaff offline DB connection failures" [High,Fix released] https://launchpad.net/bugs/1718301 |
| 09:03 |
|
bos20k joined #evergreen |
| 09:04 |
kmlussier |
I wonder if it's related to the qstore service. The user bucket issue, not the offline DB issue. |
| 09:09 |
Dyrcona |
Is qstore running? |
| 09:10 |
kmlussier |
That's what I need to check. |
| 09:12 |
|
_bott_ joined #evergreen |
| 09:17 |
kmlussier |
Yes, actually, qstore is running. Now I'm puzzled. |
| 09:18 |
kmlussier |
mmorgan: How old is the code on your test server? |
| 09:19 |
Dyrcona |
kmlussier: Errors from qstore in the logs? |
| 09:19 |
mmorgan |
3.0 beta1 |
| 09:19 |
|
_bott_ joined #evergreen |
| 12:59 |
kmlussier |
So if I do an empty search with the container filter, it's a way to make the entire contents of a bucket available in the public catalog. |
| 13:01 |
miker |
kmlussier: yep. that's basically how we provide "search within a my-list" functionality |
| 13:02 |
miker |
though I guess we don't spell out the filter in the UI, just when we do the search in the code |
| 13:03 |
kmlussier |
OK, maybe I can update some of the documentation on that tomorrow for Web Client Hacking Day. Not that it's new with the web client, but I'll probably forget if I don't do it tomorrow. :) |
| 13:03 |
* kmlussier |
is going to try to get some last-minute bugs tested before the RC |
| 13:14 |
|
Dyrcona joined #evergreen |
| 13:23 |
Dyrcona |
Re my systemd issues from earlier: https://ubuntuforums.org/showthread.php?t=2355822 |
| 13:23 |
Dyrcona |
systemd-- # Just because. |
| 13:47 |
Dyrcona |
systemd, that is. |
| 13:47 |
jeff |
Dyrcona: as for if the problem with recur, I can't guess -- but that was the kind of thing i had in mind when suggesting logs could confirm which problem you ran into. |
| 13:47 |
Dyrcona |
What I have is a lot of that noise, followed by everything working after the forced reboot. |
| 13:48 |
kmlussier |
berick: I think it could go either way, but when I asked after my testing, the thinking was that bug 1712646 should be patched. |
| 13:48 |
pinesol_green |
Launchpad bug 1712646 in Evergreen "Web Client: Adding bill without billing type fails silently" [Low,Confirmed] https://launchpad.net/bugs/1712646 |
| 13:49 |
Dyrcona |
Guess I have to rebuild this vm for the Nth time.... |
| 13:51 |
berick |
kmlussier: should be patched? meaning merged? or repatched? |
| 14:31 |
Dyrcona |
You merged or rebased? |
| 14:31 |
berick |
kmlussier: looks like kyle's branch has veered away from master. i suggest cherry-picking instead |
| 14:32 |
Dyrcona |
As to why it would happen, there are a number of reasons. |
| 14:32 |
kmlussier |
Dyrcona: I merged the branch to load it on the test system. |
| 14:32 |
kmlussier |
berick: OK, thanks. |
| 14:33 |
Dyrcona |
Sounds like there is extraneous stuff in the submitted branch... I think that should be cleaned up. |
| 14:33 |
Dyrcona |
That's one reason. |
| 14:33 |
Dyrcona |
Another is you have extraneous stuff in your branch. |
| 15:24 |
berick |
only the release branches have a usable version |
| 15:24 |
Bmagic |
makes sense |
| 15:24 |
bshum |
https://webby.evergreencatalog.com/gateway?service=open-ils.actor&method=opensrf.open-ils.system.ils_version ; for giggles, webby too is HEAD |
| 15:30 |
Dyrcona |
My test vm returns this: {"payload":["2-12-6"],"status":200} |
| 15:30 |
Bmagic |
gratz! |
| 15:31 |
* Dyrcona |
goes back to creating a final branch for the produciton upgrade to 2.12.6. :) |
| 15:45 |
|
jvwoolf joined #evergreen |
| 16:05 |
Dyrcona |
jeffdavis: yes, that. |
| 16:05 |
Dyrcona |
We use different dbs in production. |
| 16:06 |
jeffdavis |
Ah, I see. Our config is ok, but good call. |
| 16:06 |
Dyrcona |
I forget what my error was on a test vm when I missed the reporter section. |
| 16:07 |
jeffdavis |
I wonder if whatever's causing the DBI connection failure could be the same thing that's going on with bug 1704396 - probably not, but... |
| 16:07 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,New] https://launchpad.net/bugs/1704396 |
| 16:09 |
Dyrcona |
jeffdavis: Google suggests either the backend segfaulted or perhaps a dbi connection not surviving a fork() call. |
| 17:28 |
miker |
hrm... I don't see it calling that in master. I must be missing something... |
| 17:30 |
kmlussier |
gmcharlt: https://gitlab.com/snippets/1676297 is up to date as far as you know? |
| 17:30 |
miker |
gmcharlt: ah, the baseline looks out of date |
| 17:30 |
gmcharlt |
miker: gah |
| 17:30 |
gmcharlt |
miker: OK, something more for the RC process tomorrow |
| 17:31 |
gmcharlt |
kmlussier: yes, w.r.t. to code, documentation, i18n, and specification & project management contributions that I know of. one class of folks that are not specifically included are those who made significant testing and bug reporting contributions who are otherwise not accounted for |
| 17:31 |
miker |
:) ... I can put that on my plate for the morning. it's the ELSE branch that's missing, it looks like. if the return doesn't matter, we can just collect the non-heading_field values and do a single shot after the loop |
| 17:32 |
gmcharlt |
yeah |
| 17:33 |
kmlussier |
gmcharlt: Hmmm...I do see some testers in there though. I can try to do a quick survey tomorrow, though, to see if I can find anyone else fitting that category. |
| 17:52 |
gmcharlt |
will do... tomorrow! |
| 17:52 |
gmcharlt |
have a good evening |
| 17:53 |
kmlussier |
You too! |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
miker |
gmcharlt: can multiple acsaf.heading_field's point to a single authority.heading_field row? if not, then I can solve this directly |
| 18:10 |
miker |
gmcharlt: the stock data says no, but it's not a hard rule ... |
| 18:20 |
miker |
nm, found a way past that. will look in the morning with fresh eyes |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
JBoyer joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 08:07 |
|
agoben joined #evergreen |
| 09:59 |
* mmorgan |
can imagine :) |
| 09:59 |
kmlussier |
bug 1672435 |
| 09:59 |
pinesol_green |
Launchpad bug 1672435 in Evergreen "Monographic parts in sample data live in non-holdable copy locations" [Low,New] https://launchpad.net/bugs/1672435 |
| 10:00 |
Dyrcona |
kmlussier: That makes testing my holds work difficult. :) |
| 10:00 |
kmlussier |
Dyrcona: Yes, it makes testing almost anything related to parts difficult. |
| 10:00 |
Dyrcona |
Easy enough to remedy that, though. |
| 10:00 |
Dyrcona |
parts-- |
| 10:00 |
kmlussier |
Yes, it's just a matter of changing the holdable flags on those copy locations, but we should probably try to remedy it at some point. |
| 16:46 |
gmcharlt |
I'm inclined to push bug 1718036 as is for the RC so that we have it essentially as a placeholder |
| 16:46 |
pinesol_green |
Launchpad bug 1718036 in Evergreen "wishlist: show version information somewhere in web client" [Wishlist,Confirmed] https://launchpad.net/bugs/1718036 |
| 16:47 |
gmcharlt |
I can imagine, though, extending the stock about page with a lot of additional stuff |
| 16:47 |
* bshum |
thinks that is the perfect page to test his idea to incorporate a PO tag for "translator-credits" :) |
| 16:48 |
bshum |
I kind of want to name the menu item "About Evergreen" though, not just "About" to give it a little clarity |
| 16:48 |
bshum |
Or "About this client" I guess is what we put on the title of the page already |
| 16:48 |
bshum |
So that could work too for the menu entry |
| 16:49 |
bshum |
Nope, "About Evergreen" is what's on the page blob |
| 16:49 |
* bshum |
ponders |
| 17:04 |
|
mmorgan left #evergreen |
| 17:12 |
|
_adb joined #evergreen |
| 17:13 |
|
_bott_ joined #evergreen |
| 17:14 |
cesardv_ |
berick: thanks! I'm trying :) |
| 17:44 |
pinesol_green |
[evergreen|Galen Charlton] LP#1713764: fix 'Retrieve Patron' action from webstaff pull list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f64731e> |
| 17:55 |
Bmagic |
which step of the Evergreen installation would result in this file existing: /openils/lib/liboils_pcrud.so |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:04 |
bshum |
Bmagic: isn't that one of the new library files for OpenSRF 3.0? |
| 18:04 |
bshum |
Or err Evergreen 3.0 |
| 18:11 |
gmcharlt |
tossing bug 1622696 out there for further testing before it gets merged |
| 18:11 |
pinesol_green |
Launchpad bug 1622696 in Evergreen "web client: error when trying to pay by credit card" [High,Confirmed] https://launchpad.net/bugs/1622696 - Assigned to Galen Charlton (gmc) |
| 18:11 |
gmcharlt |
berick: ^^ and note the follow-up I added |
| 18:12 |
berick |
gmcharlt++ |
| 03:34 |
|
RBecker joined #evergreen |
| 04:14 |
|
sandbergja joined #evergreen |
| 04:24 |
|
abowling joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:55 |
|
book` joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
Dyrcona joined #evergreen |
| 09:12 |
csharp |
JBoyer++ |
| 09:12 |
Bmagic |
I'm worried about the upgrade time, and that we can predict how long so we don't ask people to close longer than they have to, or worse, expect it to be done sooner and it's not |
| 09:13 |
csharp |
Bmagic: exactly - after those changes, I'm comfortable predicting an overnight/1.5 day downtime |
| 09:13 |
Dyrcona |
Bmagic: You have a database server where you can test? |
| 09:13 |
Bmagic |
yep |
| 09:13 |
Dyrcona |
Well, there you go! |
| 09:13 |
Bmagic |
I'm on similar hardware for test |
| 09:14 |
Bmagic |
now I am debating killing it and starting it over..... |
| 09:14 |
csharp |
we do our upgrades over holiday weekends (Monday holidays), so I just say down on Saturday evening, back Tuesday morning |
| 09:14 |
Bmagic |
it's in a transaction right now, so that should reverse everything back to before the start of the script |
| 09:27 |
Bmagic |
does a reingest double as a vis_attr_vector = assignment? |
| 09:31 |
|
yboston joined #evergreen |
| 09:38 |
dbwells |
Bmagic: I don't think so. I believe the record_entry visibility trigger only cares about changes in deleted-ness. |
| 09:52 |
csharp |
PINES A/T update: working without errors since re-enabling parallel processing |
| 09:53 |
csharp |
still haven't ferreted out the acq a/t issue, but installed the stock PO JEDI template and waiting for our acq person to create test POs |
| 09:53 |
mmorgan |
csharp++ |
| 09:54 |
|
roycroft joined #evergreen |
| 09:56 |
berick |
csharp: interesting, re: parallel. thanks for updating. |
| 10:28 |
Bmagic |
which schema is it supposed to be in? evergreen? |
| 10:29 |
bshum |
Depends on how your search_path is set, I suppose, with unqualified function name. |
| 10:30 |
|
jvwoolf joined #evergreen |
| 10:30 |
berick |
csharp: here's another thought. the PO you're testing, can you confirm all acq.lineitem_detail.eg_copy_id values refer to copies that actually exist? |
| 10:30 |
berick |
the logs stop right where one might expect a copy to be |
| 10:35 |
csharp |
berick: https://pastebin.com/raw/hfkVLTN2 |
| 10:35 |
csharp |
berick: will check |
| 10:36 |
berick |
ok, in both cases, it's trying to reference an asset.copy |
| 10:58 |
csharp |
about 1100 lines |
| 10:58 |
csharp |
gmcharlt: thanks |
| 10:58 |
berick |
csharp++ |
| 11:00 |
csharp |
berick: and I have another test PO ready to run with more logging, but I'll wait for you to review that |
| 11:00 |
berick |
csharp: please run |
| 11:00 |
csharp |
k |
| 11:01 |
gmcharlt |
"Leeeeeroy Jeennnnn... oh wait, not that kind of running" |
| 11:02 |
berick |
hah |
| 11:03 |
Dyrcona |
"Chree-us!" |
| 11:03 |
berick |
csharp: while you wait, do all of the lineitem_details's have uniqe eg_copy_id's ? there's no overlap? |
| 11:04 |
csharp |
in the cases I'm testing today, this are single lineitems with one copy |
| 11:04 |
berick |
ah, ok |
| 11:04 |
berick |
that makes it cleaner |
| 11:05 |
csharp |
I can look at older ones that failed though (didn't have the logging in place then at that point) |
| 11:11 |
csharp |
bug 1702489 |
| 11:11 |
pinesol_green |
Launchpad bug 1702489 in Evergreen "Wrong Join Type In Acq Lineitem Detail Causes Inaccurate Reports" [Low,New] https://launchpad.net/bugs/1702489 - Assigned to Chris Sharp (chrissharp123) |
| 11:12 |
csharp |
another dichotomy between reports and production use |
| 11:12 |
berick |
csharp: you up for testing with the original reltype to confirm it's an issue? |
| 11:12 |
csharp |
berick: absolutely |
| 11:12 |
berick |
i'm just pointing out stuff that looks unusual |
| 11:13 |
csharp |
I'll need to let these circ notices finish |
| 11:13 |
csharp |
"I'mma let them finish" |
| 11:14 |
berick |
"but hold notices are the best notices" |
| 11:14 |
csharp |
kind of between test servers right now |
| 11:14 |
csharp |
heh |
| 11:14 |
csharp |
I suspect this is the reason for it though |
| 11:15 |
csharp |
"return rows even if null" |
| 11:18 |
csharp |
right - this makes sense - I changed it in the reports version of fm_IDL.xml, but not the main one before |
| 11:19 |
csharp |
I think we have enough divergences between usage to consider leveraging the 2 separate files into 2 separate uses |
| 11:19 |
csharp |
not sure if that was the original intent |
| 11:19 |
berick |
it was not |
| 11:19 |
berick |
one is just a web/locale-friendly version |
| 11:19 |
* csharp |
figured it wasn't ;-0 |
| 11:19 |
csharp |
ah, ok |
| 11:20 |
berick |
assuming that's the issue, A/T could be made smarter |
| 11:20 |
csharp |
yeah, thought of that too |
| 11:20 |
csharp |
I've got Tiffany creating me a new PO on a test server I've reverted that change on |
| 11:22 |
csharp |
Dyrcona thought of fieldmapper right off |
| 11:22 |
csharp |
since it was syntactically correct, I moved right past it |
| 11:25 |
|
rlefaive joined #evergreen |
| 11:32 |
csharp |
berick++ # works |
| 11:32 |
berick |
*phew* |
| 11:32 |
csharp |
seriously |
| 11:33 |
csharp |
I've been sweating bullets |
| 13:14 |
berick |
yeah.. responses just never arriving |
| 13:20 |
miker |
to the tcpdump-mobile! (j/k) |
| 13:28 |
|
kmlussier joined #evergreen |
| 13:30 |
csharp |
well, since this is our highest priority issue now that acq ordering is back, I'm happy to keep providing log data, experimenting with patches, etc. |
| 13:30 |
csharp |
for the moment, I have to go back to installing OpenSRF 3.0.0-alpha/EG 3.0-beta2 on our test cluster |
| 13:52 |
csharp |
is there a tags/rel_3_0_beta2 on the way? |
| 13:53 |
dbwells |
csharp: there is now :) |
| 13:53 |
csharp |
dbwells++ |
| 13:55 |
dbwells |
csharp: sorry about that, it's there now. There is somewhat less to it, though, given that the upgrade script is hand-committed and the translation pushes are being done separately. Still good for tracking, though. |
| 15:12 |
* pinesol_green |
rubberduck goes to eleven |
| 15:12 |
berick |
and how |
| 16:58 |
|
acautley joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:50 |
|
Jillianne joined #evergreen |
| 18:38 |
|
acautley joined #evergreen |
| 03:35 |
|
remingtron_ joined #evergreen |
| 03:56 |
|
acautley joined #evergreen |
| 04:59 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:49 |
|
acautley joined #evergreen |
| 06:56 |
|
acautley joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:25 |
gmcharlt |
good morning |
| 09:26 |
csharp |
@coffee gmcharlt |
| 09:26 |
* pinesol_green |
brews and pours a cup of Sumatra Danau Toba, and sends it sliding down the bar to gmcharlt |
| 09:26 |
gmcharlt |
csharp++ |
| 09:27 |
gmcharlt |
so, general heads-up, I think master is in shape for the beta2 release, barring any last-minute updates to the draft release notes |
| 09:27 |
gmcharlt |
but given the spate of last-minute patches last night, would appreciate some testing on a fressh install, particularly on Jessie and Xenial, before we give the word to dbwells to start building |
| 09:28 |
* csharp |
volunteers |
| 09:28 |
gmcharlt |
I also call miker's and berick's attention to commit 474afc447 for more pairs of eyes |
| 09:28 |
pinesol_green |
gmcharlt: [evergreen|Galen Charlton] LP#1718301: catch it when multiple connection attempts fail - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=474afc4> |
| 10:35 |
|
kmlussier joined #evergreen |
| 11:45 |
gmcharlt |
opensrf 3.0.0-alpha is now available for download at https://evergreen-ils.org/opensrf-downloads/ |
| 11:45 |
gmcharlt |
no broader announcement just yet; plan to announce the same time as the beta2 |
| 11:49 |
* Dyrcona |
is struggling with vmbuilder to make fresh vms for testing. |
| 11:49 |
Dyrcona |
If it doesn't work this time, I'm going back to virtinstall and ISO images. |
| 11:50 |
* Dyrcona |
keeps hitting bugs that have solutions on Lp and each patch gets it that much closer to working.... |
| 11:50 |
Dyrcona |
And people think we're bad about keeping up with Lp..... |
| 13:44 |
pinesol_green |
[evergreen|Kathy Lussier] More release note edits for 3.0 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7960a55> |
| 13:44 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Add an entry for web staff client offline circ - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33b6a01> |
| 13:46 |
|
rgagnon joined #evergreen |
| 13:52 |
gmcharlt |
csharp: does it abort the test, or just display? |
| 13:53 |
csharp |
gmcharlt: just displays |
| 13:54 |
|
tspindler joined #evergreen |
| 13:54 |
gmcharlt |
csharp: ok, that's benign, at least as far as the test suite is concerned |
| 13:54 |
csharp |
gmcharlt: ok - will move on |
| 13:55 |
|
yboston joined #evergreen |
| 13:56 |
bshum |
miker++ # i18n fixing |
| 14:37 |
gmcharlt |
#info The second beta release will come out today |
| 14:37 |
gmcharlt |
#info Important to emphasize that Evergreen 3.0 now requires OpenSRF 3.0, which has an alpha release today |
| 14:37 |
gmcharlt |
that's it unless there are questions for me |
| 14:38 |
terran |
We're starting training PINES staff on it next Monday so that they can do more testing and be fully prepared for our January upgrade. |
| 14:38 |
terran |
Everyone is very excited. |
| 14:38 |
tspindler |
terran++ |
| 14:38 |
tspindler |
we will be interested how it goes for PINES |
| 14:38 |
ScottThomas |
We also hope to upgrade asap. Looking at very early January |
| 16:33 |
gmcharlt |
AllYall++ |
| 16:41 |
abneiman |
gmcharlt++ |
| 16:43 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
khuckins__ joined #evergreen |
| 17:03 |
csharp |
seeing some sporadic complaints of network errors and slow response times from catalogers on 2.12/OpenSRF 2.5.2 - anyone else? |
| 17:03 |
csharp |
I don't have many specifics |
| 00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=203dd19> |
| 00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.6 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b38b3e5> |
| 00:24 |
|
acautley joined #evergreen |
| 01:46 |
|
acautley joined #evergreen |
| 02:55 |
|
acautley joined #evergreen |
| 03:49 |
|
acautley joined #evergreen |
| 04:37 |
|
Jillianne joined #evergreen |
| 04:58 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:55 |
|
acautley joined #evergreen |
| 06:59 |
|
acautley joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:55 |
|
acautley joined #evergreen |
| 08:59 |
|
bos20k joined #evergreen |
| 09:10 |
|
kmlussier joined #evergreen |
| 09:12 |
bshum |
gmcharlt (and others): FYI, I'll angle to do another i18n POT and PO sync later tonight after today's work is done prior to 3.0-beta2 cutting (tomorrow?) |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:14 |
bshum |
Looking at LP translations, looks like Eva's finished translating for Czech all the latest strings we added for 3.0-beta1 for webstaff/db.seed so there's plenty to test and check out |
| 09:28 |
|
yboston joined #evergreen |
| 09:59 |
|
acautley joined #evergreen |
| 10:08 |
|
rlefaive_ joined #evergreen |
| 10:09 |
gmcharlt |
bshum: noted, and thanks |
| 10:09 |
kmlussier |
Oops. The 2nd time this week I forgot to vote. |
| 10:18 |
csharp |
miker: pretty sure at this point that RAM was part of (if not the cause of) the problem - thanks for the pointer! |
| 10:18 |
Stompro |
Beta2 tomorrow... I'm just finishing with a test database upgrade of beta1... sigh. |
| 10:18 |
csharp |
Stompro: right there with ya |
| 10:19 |
csharp |
JBoyer's disable ALL THE TRIGGERS! solution made mine pretty painless though after sifting out PINES database particularities |
| 10:20 |
Stompro |
No problems with a 2.10.6 -> 3.0.Beta1 database upgrade so far though, so that is good. Some parts take a long time on my non ssd test vm though. |
| 10:21 |
Stompro |
csharp, could you point me to more info on that? |
| 10:26 |
csharp |
Stompro: here's what I did http://git.evergreen-ils.org/?p=evergreen/pines.git;a=blobdiff;f=Open-ILS/src/sql/Pg/version-upgrade/2.12.5-3.0-beta1-upgrade-db.sql;h=3a4f54fecc0b4c37b627da2963fe1e50e259aa02;hp=0da18594c992f7050b0ea907600e318af117d6da;hb=99d5c1164f7180117760d48245db54a5a7bc0296;hpb=dfc8e3892d76af32162e1069c2c620139449ce2f |
| 10:28 |
Stompro |
csharp++ thanks |
| 10:36 |
kmlussier |
Recalculating fingerprints? |
| 10:38 |
Dyrcona |
Yeap. |
| 10:39 |
Dyrcona |
csharp++ # For the links.. |
| 10:40 |
Dyrcona |
I'm supposed to set up a 3.0 testing server, too, but I'm focusing on the upgrade, first. :) |
| 10:40 |
Dyrcona |
miker: Do you have any code for that set replication suggestion from last week? I might give that a go, though I said it made me uneasy. |
| 10:41 |
Dyrcona |
If not, I suppose I could figure it out. |
| 10:43 |
miker |
Dyrcona: it's basically just, "set session_replication_role to 'replica';" before the big update, and then "set session_replication_role to 'origin';" after |
| 10:44 |
Dyrcona |
miker: Thanks! I'll give that a whirl when do it the 3.0 upgrade on the testing server. |
| 10:44 |
pinesol_green |
[opensrf|Ben Shum] LP#1708048: Add support for Debian 9 Stretch - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a85132e> |
| 10:44 |
miker |
awesome |
| 10:44 |
pinesol_green |
[opensrf|Jason Stephenson] LP#1708048: Fix ld problems by renaming libraries. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cace46d> |
| 11:35 |
gmcharlt |
tossing in bug 1715503 as ready for review and merging today |
| 11:35 |
pinesol_green |
Launchpad bug 1715503 in Evergreen "Complain if minimum Pg version for 3.0 is not met" [Medium,New] https://launchpad.net/bugs/1715503 |
| 11:40 |
|
rlefaive joined #evergreen |
| 12:46 |
bshum |
miker++ # I'll test your branch for bug 1717777 later tonight |
| 12:46 |
pinesol_green |
Launchpad bug 1717777 in Evergreen "Need to load all the PO files for a locale" [Undecided,Confirmed] https://launchpad.net/bugs/1717777 |
| 12:47 |
miker |
bshum++ # thanks |
| 12:47 |
bshum |
Fwiw, I also noticed that there could be differences in the various PO files too |
| 13:45 |
Dyrcona |
Wheezy is old and...wheezy...it should be replaced by Jessie. :) |
| 14:10 |
Dyrcona |
FYI: Master Evergreen seems to be broken on Debian 8 Jessie. |
| 14:11 |
Dyrcona |
karma:unit starts out with this warning: WARN [watcher]: Pattern "/home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/node_modules/angular-sanitize/angular-sanitize.min.js" does not match any file. |
| 14:12 |
Dyrcona |
Then all following tests blow up with with various long messages. |
| 14:13 |
Dyrcona |
I'm testing a branch that has this commit as head: bed0acd1b197af590da729b6e1c29839580d1c5b |
| 14:13 |
Dyrcona |
Oh, right. It doesn't look at the working repository. |
| 14:14 |
Dyrcona |
I may have botched a prereq in the makefile, but I don't think so. |
| 14:14 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1718459-remove-debian7-wheezy |
| 15:22 |
bshum |
Dyrcona: Yep, if I yank out the prereqs for nodejs-legacy and npm for Jessie, and then install the NodeJS binary like we do for old-Wheezy, or Trusty, then run the usual npm install, grunt all is happy |
| 15:22 |
bshum |
So it is a problem with our package list and having old node on Jessie that's broken it for master |
| 15:23 |
gmcharlt |
and seems to have /just/ broken |
| 15:24 |
bshum |
I guess we should test it on Xenial where we also use the packaged nodejs and see if it's broken there too |
| 15:24 |
bshum |
gmcharlt: Extra fun! :) |
| 15:25 |
Dyrcona |
Yeah, we should test on Xenial and bug it, too. |
| 15:25 |
gmcharlt |
OK! fess up! who started using leftpad? ;) |
| 15:25 |
Dyrcona |
heh |
| 15:35 |
bshum |
Hmm, well the lovefield warning shows up in Xenial when doing the npm install |
| 16:07 |
pinesol_green |
[evergreen|Bill Erickson] LP#1718301 Offline db connections via promise - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b87a437> |
| 16:17 |
kmlussier |
berick++ |
| 16:29 |
* berick |
saw "leftpad", read it as "leafpad", started getting defensive |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
genpaku joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
* gmcharlt |
claims 1076 in the name of ghosts that are tired of being invisible everywhere! |
| 18:08 |
csharp |
that was yesterday^^ again - same second |
| 18:21 |
|
acautley joined #evergreen |
| 18:39 |
|
Jillianne joined #evergreen |
| 18:40 |
bshum |
Bah |
| 18:40 |
bshum |
The xenial grunt test blows up on my latest VM rebuild test |
| 18:40 |
bshum |
So I guess that's all they wrote for that |
| 18:41 |
bshum |
I'll mock up my change branch for installing nodejs source and apply that in my test building |
| 18:44 |
bshum |
And in the meantime, while I wait for ansible to rebuild my test server (again), I'll go and make a bug for that change |
| 18:54 |
bshum |
Ho hum, might be a bigger problem than that.... sigh |
| 19:02 |
|
Dyrcona joined #evergreen |
| 19:02 |
bshum |
Well, clean repo copy, and still getting npm and dependency problems. Going to try nailing a copy of the errors this time around |
| 19:03 |
Dyrcona |
bshum: with the latest Node.js? |
| 19:04 |
bshum |
Dyrcona: Yep, I was getting failures, so I removed the legacy nodejs and npm from my xenial box and then tried using the latest NodeJS and it is still bombing on trying to grab all the stuff for web client |
| 19:04 |
bshum |
I'm not sure if it's NodeJS issues, or if it's changed that were merged last minute to master |
| 19:04 |
bshum |
Just to check |
| 19:04 |
Dyrcona |
OK. |
| 19:05 |
Dyrcona |
Do you have a branch with the changes, yet? |
| 19:05 |
Dyrcona |
It would make it easier for me to test, too. |
| 19:05 |
bshum |
For NodeJS? |
| 19:05 |
Dyrcona |
Yeah. |
| 19:05 |
bshum |
Yeah I was just adding the LP# and making the branch |
| 19:12 |
bshum |
Yep |
| 19:12 |
bshum |
Reverting b87a437825a531a3e6977d1e0b17e48d8f41f74a fixing my web client building |
| 19:12 |
pinesol_green |
bshum: [evergreen|Bill Erickson] LP#1718301 Offline db connections via promise - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b87a437> |
| 19:12 |
bshum |
So something in that new commit broke nodejs fresh setup |
| 19:14 |
bshum |
Maybe all those nodejs changes that recently happened are unhappy with the change, but whatever gmcharlt/miker had installed during their testing was fine. |
| 19:15 |
bshum |
Either way, that's definitely the source of my breakage once I backed that back out |
| 19:15 |
* bshum |
resumes building out his test server for i18n stuff |
| 19:16 |
Dyrcona |
bshum: You typoed the Lp number in your branch, you swapped the 4 and 5. I noticed, 'cause you have my bug number from today. :) |
| 19:16 |
bshum |
Oops |
| 19:17 |
bshum |
That always happens to me :( |
| 19:17 |
gmcharlt |
bshum: hmm, I'l look at it after dinner |
| 19:17 |
gmcharlt |
maybe (hopefully) just a matter of tweaking a test |
| 19:18 |
bshum |
Dyrcona: I can fix and force push a replacement |
| 19:18 |
Dyrcona |
bshum: It's just the branch name no big deal for now. |
| 19:18 |
bshum |
Dyrcona: Ah okay, yes, I see that now. Doh. |
| 19:18 |
Dyrcona |
The commit messages have the correct number. |
| 19:19 |
bshum |
gmcharlt: Sounds good, I'll keep testing other stuff around it for now. Reverting it locally till I know what to do about it :) |
| 19:19 |
* bshum |
waits for the LONG i18n dance on his test server to play out |
| 19:21 |
|
jihpringle joined #evergreen |
| 19:23 |
gmcharlt |
https://www.youtube.com/watch?v=sArAC2_ow2k |
| 19:23 |
bshum |
gmcharlt: That helps actually, thanks :) |
| 20:50 |
gmcharlt |
k, got a patch for you to look at in a minute |
| 20:50 |
bshum |
Working my way through a Stretch VM install :) |
| 20:50 |
Dyrcona |
I'm here also. |
| 20:56 |
bshum |
Fwiw, using "grunt all --force" let me proceed through the whole install even with the failed stuff. So it does appear to be the tests like you said |
| 20:56 |
bshum |
I havent' tried installing Hatch and trying out everything else though |
| 20:56 |
gmcharlt |
user/gmcharlt/lp1718301_lf_no_multi_connect |
| 20:57 |
Dyrcona |
Well, given the message that I got earlier, I assumed a --force would fail to work in the end. |
| 21:01 |
bshum |
gmcharlt: That patch worked for me |
| 21:22 |
gmcharlt |
if so, I can grab it |
| 21:22 |
bshum |
gmcharlt: Yep, it's in https://bugs.launchpad.net/evergreen/+bug/1718549 |
| 21:22 |
pinesol_green |
Launchpad bug 1718549 in Evergreen "install NodeJS from source for all supported distributions" [High,Triaged] |
| 21:22 |
bshum |
The thing I'm testing right now is whether you have to do something first to remove old npm and nodejs-legacy too |
| 21:22 |
bshum |
And I think you might |
| 21:23 |
bshum |
Cause when I run my patch through, it installs new nodejs and I get node --version = 6.11.3 as I expect, but still getting npm --version of 1.4.21 |
| 21:23 |
bshum |
So not sure it's not acting funny |
| 21:23 |
bshum |
But for fresh installs, should go perfectly |
| 21:24 |
bshum |
Oh, could just be my environment |
| 21:24 |
gmcharlt |
which npm |
| 21:25 |
bshum |
3.10.10 now showing |
| 21:25 |
bshum |
So that means it overwrites correctly with the installed source |
| 21:55 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d019d22> |
| 21:55 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a078f4> |
| 21:58 |
|
_bott_ joined #evergreen |
| 22:09 |
bshum |
Okay, xenial builds fine for me with the latest master as of all the POT/PO. I'll test further tomorrow. Thanks again gmcharlt for the patch |
| 22:09 |
bshum |
gmcharlt++ |
| 22:09 |
bshum |
Goodnight #evergreen :) |
| 22:17 |
gmcharlt |
https://evergreen-ils.org/evergreen-2-11-9-and-2-12-6-released/ |
| 22:17 |
gmcharlt |
Bmagic++ |
| 22:17 |
gmcharlt |
dbwells++ |
| 00:23 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: TPAC bib_source variable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d163e4> |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:13 |
|
rkw joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 10:25 |
pinesol_green |
Launchpad bug 1712637 in Evergreen "Web Client: Default Hold Pickup Location Errors" [High,Confirmed] https://launchpad.net/bugs/1712637 |
| 10:29 |
kmlussier |
berick: In the hold pickup location selector? No. |
| 10:29 |
kmlussier |
I was about to build a new VM this morning and was going to include that branch. I can check again just to be sure. |
| 10:30 |
berick |
kmlussier: that would be appreciated. I'm not seeing what you are seeing. |
| 10:30 |
berick |
they are greyed out and un-select-able for me |
| 10:32 |
berick |
i just rebased to master and re-tested |
| 10:37 |
dbs |
berick: in terms of clearing cached proxy entries for given URIs, I started using the proxy_cache_bypass directive recently |
| 10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: adding the MARC Templates documentation back - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=899b6a5> |
| 10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs reorg: splitting action/triggers into command-line and staff-client manuals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10c578a> |
| 10:43 |
dbs |
thank you https://serverfault.com/questions/493411/how-to-delete-single-nginx-cache-file for showing me the way :) |
| 10:45 |
|
mmorgan joined #evergreen |
| 10:51 |
berick |
i also had to find an example... docs are spare on that one. |
| 11:00 |
kmlussier |
berick: I don't know why it didn't work in my earlier test, but it's working for me now. I'll sign off and push it now. |
| 11:01 |
berick |
kmlussier++ |
| 11:21 |
|
ningalls joined #evergreen |
| 11:25 |
gmcharlt |
survey on what version number to use for the next major OpenSRF release https://gmcharlt.limequery.org/523355 |
| 13:42 |
csharp |
examples here (for the logs): http://gapines.org/eg/kpac/category?trail=30 |
| 13:43 |
* mmorgan |
remembers making buckets OPAC-able by doing what csharp said, changing btype AND public. But since both changes are required, the 'publicly visible' checkbox in the web client won't do the whole job. |
| 13:45 |
berick |
doesn't the pub checkbox in the web client determine if staff A can view a (staff) bucket created by staff B? or is that just permission-based? |
| 13:47 |
csharp |
for webstaff installation, is there anything wrong with having test/data/idl2js.pl use the installed versions of fm_IDL.xml and fm_IDL2js.xsl? since we install from debs, we're trying to work around needing the source tree installed |
| 13:47 |
csharp |
btw, what I'm suggesting *works*, I'm just wondering if there's a good reason not to do so by default or just instead |
| 13:52 |
berick |
csharp: it uses the source version so it's possible to build EG without installing it. |
| 13:53 |
kmlussier |
berick: Yeah, that's what I'm testing now. But I keep messing up my tests. |
| 13:56 |
csharp |
berick: ah |
| 13:59 |
kmlussier |
Yeah, I can retrieve somebody else's bucket by id whether it's publicly visible or not. |
| 14:01 |
kmlussier |
That's a copy bucket. I haven't tried it with a record bucket yet. |
| 14:37 |
kmlussier |
csharp: Too late! I've already tweeted about it. |
| 14:50 |
csharp |
crap |
| 14:51 |
csharp |
:-D |
| 15:18 |
pinesol_green |
[evergreen|Bill Erickson] LP#1537233 Copy bucket handles mis-scans, improve focus - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40d8ce3> |
| 15:24 |
|
tlittle joined #evergreen |
| 15:50 |
|
jvwoolf left #evergreen |
| 16:39 |
|
jihpringle_ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:07 |
|
acautley joined #evergreen |
| 17:09 |
|
khuckins joined #evergreen |
| 17:20 |
pinesol_green |
[evergreen|Ben Shum] LP#1717715: Fix typo in webstaff serials - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7a98ff> |
| 17:26 |
|
Jillianne joined #evergreen |
| 18:01 |
|
tlittle left #evergreen |
| 18:27 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1716486: fix hotkeys - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb85fcd> |
| 07:32 |
csharp |
@quote add * miker shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 07:32 |
pinesol_green |
csharp: The operation succeeded. Quote #175 added. |
| 07:46 |
csharp |
@later tell RyanM see https://bugs.launchpad.net/evergreen/+bug/1541801 - should be fixed in the web client for 2.12 and newer (but not the XUL staff client) |
| 08:54 |
|
_adb joined #evergreen |
| 08:54 |
* csharp |
needs the fix, just wants to be sure we're on sure footing before experimenting too much |
| 08:57 |
Dyrcona |
csharp: I'm confident that gmcharlt's patch that I pushed last night fixes the problem. |
| 08:57 |
Dyrcona |
I'm going to build a new vm today to do some more testing. |
| 08:58 |
Dyrcona |
This is mainly 2.10.7 -> 2.12.5 upgrade testing, but this code will get another workout. |
| 08:59 |
Dyrcona |
I've got another machine that I'm supposed to install 3.0-beta onto, but I may just go with master. |
| 08:59 |
Dyrcona |
Until rel_3_0 is branched, that is. |
| 09:01 |
Dyrcona |
heh. It helps not to typo the db user name, huh? :) |
| 09:03 |
csharp |
Dyrcona: thanks ;-) |
| 09:04 |
Dyrcona |
Anyway, I think it is safe to apply the patch from last nigh if you've already installed OpenSRF 2.5.1. |
| 09:05 |
Dyrcona |
Oh, I can see it's going to be one of those typo kind of days. |
| 09:05 |
Dyrcona |
This is where testing with production data comes in handy. |
| 09:08 |
gmcharlt |
I am inclined to cut 2.5.2 now; the other changes can wait |
| 09:08 |
gmcharlt |
thoughts? |
| 09:09 |
|
bos20k joined #evergreen |
| 11:36 |
Bmagic |
Dyrcona++ |
| 11:36 |
Dyrcona |
I don't see anywhere that a SAN i put into an outgoing message. |
| 11:37 |
Dyrcona |
And yeah, right after that it looks up the address by SAN. ;) |
| 11:39 |
Dyrcona |
csharp: I haven't test a/t on 2.12. I probably should after making sure email goes nowhere. |
| 11:54 |
|
jvwoolf1 joined #evergreen |
| 11:57 |
|
sandbergja joined #evergreen |
| 11:58 |
csharp |
Dyrcona: A/T generally works - email notices are working fine - just the PO JEDI event with the undef variables that I'm trying to suss out |
| 13:24 |
Dyrcona |
Whee! tail -f /openils/var/log/osrfsys.log goes by too fast to follow. |
| 13:25 |
csharp |
berick: will do |
| 13:25 |
* berick |
always has to read "Fix for Web Client Copy Editor Fix" twice |
| 13:25 |
csharp |
I did verify that the template/environment/params have not changed between versions |
| 13:26 |
csharp |
but I haven't tested against stock yet |
| 13:26 |
Dyrcona |
csharp: You added lines to log the context, yeah? |
| 13:26 |
csharp |
yes |
| 13:27 |
kmlussier |
miker: mmorgan and I already verified the search slowness is still a problem on 2.5.1. Do you think 2.5.2 will make a difference? |
| 13:27 |
Dyrcona |
my events all went to invalid, but it could be because they are so old. |
| 13:28 |
miker |
kmlussier: that's what I want to test, yes. 2.5.1 has a bad bug, so an upgrade to the brand new 2.5.2 is indicated in any case |
| 13:28 |
Dyrcona |
I don't know enough about acq to setup an invoice to have a fresh one. |
| 13:28 |
csharp |
invalid probably means they aren't EDI vendors |
| 13:28 |
mmorgan |
miker: kmlussier: We slipped in the 2.5.2 fix this morning on our training server and still saw the issue. |
| 13:29 |
* csharp |
makes a sad face at mmorgan's last :-( |
| 13:29 |
csharp |
we're getting slow/timeout on searching too |
| 13:29 |
kmlussier |
Sure, I'll also update the OpenSRF on the test system I've been using just to be sure. |
| 13:29 |
* mmorgan |
forgot to supply same :-( |
| 13:30 |
* csharp |
was hoping the latest fixes would Just Work™ |
| 13:31 |
miker |
mmorgan: thanks, that's the confirmation I wanted. I just wanted to take something off the table to look at |
| 13:33 |
berick |
Dyrcona: to test the ACQ A/T stuff, i think all you need to do is activate a PO whose provider has an edi_default value |
| 13:33 |
berick |
the edi_account itself can be all dummy data |
| 13:33 |
csharp |
yeah |
| 13:34 |
Dyrcona |
berick: 1) I have no idea how to actually use acq. 2) I have 3-month old data that I can test with at the moment. |
| 13:34 |
Dyrcona |
I just make the dog food. I don't eat it. :) |
| 13:34 |
berick |
heh |
| 13:34 |
berick |
but it's delicious! |
| 13:35 |
berick |
TFW you remember you don't have to launch the XUL client |
| 13:35 |
csharp |
berick: did that earlier |
| 13:35 |
csharp |
"wait, why did I bother opening this?" |
| 13:36 |
berick |
:) gonna take some getting used to |
| 13:41 |
berick |
csharp: tested on master/master w/ stock data. had no problem generating JEDI. |
| 13:41 |
berick |
order had 1 LI and 25 copies, so not huge |
| 13:43 |
* berick |
is also using the large max_stanza_size, in case it's relevant |
| 13:49 |
csharp |
yeah our max_stanza_size is at 2000000 |
| 13:53 |
Dyrcona |
mine is the default 65536 |
| 13:53 |
Dyrcona |
Of course, my events failed to validate, so that's no helpful at this point. |
| 13:58 |
berick |
reminder to set an edi_default value on the provider after creating the edi_account. |
| 13:58 |
* berick |
got stuck on that |
| 14:03 |
* csharp |
just busted his test server by inserting the stock PO JEDI template into ALL THE EVENT DEFS |
| 14:04 |
csharp |
I was about to blow it away to start testing 3.0 anyway |
| 14:04 |
csharp |
and I did preserve the old defs, but I don't want to worry about spending the required time fixing it |
| 14:04 |
berick |
YOU GET EDI, AND YOU GET EDI |
| 14:04 |
berick |
noooooo |
| 14:05 |
csharp |
@oprah EDI |
| 16:48 |
Dyrcona |
Do it right, now, or pay for it later. |
| 16:48 |
Dyrcona |
Again, just a suggestion... :) |
| 17:00 |
miker |
parseFloat+printf (yes, we have a printf implementation stashed away somewhere in the code base) |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:22 |
|
acautley joined #evergreen |
| 17:36 |
|
tlittle joined #evergreen |
| 17:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1708951: fix tabbing in webstaff catalog app for Firefox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c43bc5b> |
| 18:00 |
|
kmlussier joined #evergreen |
| 19:17 |
|
Jillianne joined #evergreen |
| 20:29 |
|
tsbere joined #evergreen |
| 15:02 |
jeffdavis |
I can email you the scripts I used it you like |
| 15:02 |
jeffdavis |
*if |
| 15:02 |
Dyrcona |
That's OK. I think I know what I need to do. |
| 15:03 |
Dyrcona |
I'm going to test upgrading OpenSRF but leaving Evergreen untouched, first. |
| 15:05 |
abneiman |
anyone else getting timeout errors from docs.evergreenils.org? the main page loads but links into the docs themselves are timing out for me. |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:08 |
berick |
abneiman: site doesn't load at all for me |
| 15:43 |
Dyrcona |
So, after that I get a different error message. I'll save those logs, too. |
| 15:52 |
Dyrcona |
Register workstation seems to work in the web staff client, btw. |
| 15:54 |
jihpringle |
Drycona: we could register workstations in the web client too |
| 15:55 |
Dyrcona |
I'll open a bug for now. I want to test with a clean installation tomorrow. |
| 16:02 |
* bshum |
grumbles as he makes himself a new Mac client |
| 16:10 |
Dyrcona |
jeffdavis jihpringle: bug 1717350 |
| 16:10 |
pinesol_green |
Launchpad bug 1717350 in Evergreen "Upgrading to OpenSRF 2.5.1 appears to break XUL 2.12.5" [Undecided,New] https://launchpad.net/bugs/1717350 |
| 16:20 |
jeffdavis |
followed by the usua "Request Completed Successfully" + request time |
| 16:20 |
jeffdavis |
*usual |
| 16:20 |
jeffdavis |
I need to step away for a bit, happy to try more stuff later on |
| 16:20 |
berick |
huh |
| 16:20 |
berick |
thanks |
| 16:21 |
berick |
just trying to boil it down to the simplest possible test case |
| 16:23 |
Dyrcona |
berick: FWIW the first request above gives the same message in the lp bug. |
| 16:25 |
Dyrcona |
And I get the osrfResultPartialComplete exception for the second, so same as jeffdavis, more or less. |
| 16:26 |
* Dyrcona |
calls it a day. |
| 16:48 |
gmcharlt |
berick: yeah, I was just about to reproduce it by expanding aou |
| 16:49 |
bshum |
New staff client, hmm... |
| 16:49 |
berick |
i tried installing rel_2_12 on top of osrf master and cannot reproduce, fwiw |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
khuckins__ joined #evergreen |
| 17:05 |
miker |
berick: can't reproduce in srfsh, you mean? |
| 17:06 |
berick |
miker: i couldn't reproduce locally in srfsh or xul |
| 17:39 |
dbwells |
gmcharlt's bug is the killer, but FWIW, I think we also have another issue with that loop. We're looping until num_bytes, but still chunking on chars. Since bytes >= chars, the effect will be possible empty responses at the end of the loop (rather than missing data, and depending on chunk boundary), so not the end of the world. If anyone agrees with this diagnosis, I can open a bug about it for a future fix. |
| 17:39 |
gmcharlt |
dbwells: I think it's worth exploring |
| 17:40 |
miker |
yeah, breaking when the substr is empty seems sane |
| 17:43 |
dbwells |
Okay, I will try to concoct a test case and go from there. I'm not very familiar with this layer, so should be interesting at least :) |
| 17:45 |
miker |
hrm... I wonder if the C version is at risk of spliting 2+ byte utf8 chars ... I suspect so. I'll make a note to look at that first thing tomorrow. |
| 17:46 |
* miker |
shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 17:53 |
miker |
actually, nevermind. we \u-encode 2+ byte chars |
