| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T04:52:32,076196669-0500 -0> |
| 07:05 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 09:51 |
|
yboston joined #evergreen |
| 09:54 |
RMiller |
Hi, quick Evergreen install question. In step 11 of the Evergreen install, it tells me to copy the opensrf_core.xml file again, then modify it the same way I did in OpenSRF setup |
| 09:55 |
RMiller |
Since I only installed OpenSRF for the purposes of using Evergreen, do I need to do this step? |
| 09:56 |
JBoyer |
RMiller, yeah, the one included in OpenSRF only has a couple testing services defined, the example included with Evergreen defines the other services required by Evergreen and a couple testing services. |
| 09:56 |
RMiller |
So the Evergreen setup replaced that example file with something more thorough? |
| 09:57 |
RMiller |
It's the same location and filename, so that just seemed weird |
| 09:58 |
|
bwicksall joined #evergreen |
| 14:15 |
jeff |
if your backend systems are not sharing a memcached instance, then the session token from one would not be considered valid on another. |
| 14:16 |
jeff |
so unless you have taken some extraordinary steps to ensure that requests by a given client are only ever serviced by a specific backend host, you're going to run into issues where it appears that you are not logged in. you may never be able to successfully log in and could loop, like you're seeing. |
| 14:16 |
stephengwills |
ok. makes sense. |
| 14:17 |
jeff |
if haproxy was connecting over http and you weren't taking other steps to inform the backend systems of the client <-> haproxy protocol being https, then you'd run into similar redirect issues because the backend systems would think the client connection was over http and try to redirect to https, looping. |
| 14:19 |
jeff |
if you rule out those two issues and are still having problems with a "fresh" client, you might consider configuring haproxy to only use a single backend system as a next troubleshooting step. |
| 14:20 |
jeff |
and by a "fresh" client, I mean you might want to clear cache and restart the web browser, or try a new incognito/private browing session to test, to rule out the possibility that the client had cached a problematic redirect, etc. often not necessary, but good to rule out... |
| 14:21 |
stephengwills |
fair. thanks will do |
| 14:21 |
jeff |
good luck! |
| 14:26 |
jeff |
another issue that we might still be susceptible to is if you've created a directory in your DocumentRoot titled "eg", or if your hostname contains (or perhaps just starts with) "staff". I should find or create bugs for those two. They're less common, but if either rings a bell for you, could be that. :-) |
| 15:29 |
|
bdljohn1 joined #evergreen |
| 16:51 |
stephengwills |
one of the hosts I am retiring was named staff but that is no longer an issue. I fixed the eg_vhost to rewrite all traffic to https and now haproxy delivers a user to one of the hosts and that user should stay put for the druation of thier session, anyway. not fool proof but it got me past that issue. I’ll look into shared memcache after dinner. thanks for the suggestions. |
| 16:57 |
|
stephengwills left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T16:53:56,389847953-0500 -0> |
| 17:33 |
|
stephengwills joined #evergreen |
| 18:17 |
|
nfBurton joined #evergreen |
| 20:27 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T04:52:13,436767412-0500 -0> |
| 07:02 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
bdljohn joined #evergreen |
| 09:24 |
RMiller |
The passwords are in there correctly, as far as I can tell; two are inside <password> tags and two are inside <passwd> tags. Is that right? |
| 09:27 |
aabbee |
yes. the <password> tags are for router users, <passwd> tags for opensrf users. note that these do not appear in the opensrf_core.xml file in the same order that the users were created in step 11. |
| 09:28 |
RMiller |
I gave them all the same password, so the order shouldn't matter... :) |
| 09:29 |
Dyrcona |
RMiller: For testing purposes, I use "password" so I don't have to change the configuration file. |
| 09:30 |
Dyrcona |
Did you restart ejabberd after making the changes to ejabberd.yml? |
| 09:31 |
Dyrcona |
You probably could not have registered the users unless you did, though. |
| 09:32 |
RMiller |
I'm sure I did (this has been a month-long on-and-off process, long story) but I just did again, and no change. |
| 10:32 |
RMiller |
4! Hooray! |
| 10:33 |
Dyrcona |
I'm concerned about the amount of RAM. I never go with less than 4GB. You may find yourself running out once you get PostgreSQL and everything else running. |
| 10:36 |
RMiller |
Ok. It's virtualized, so I'd have to ask the IT guy for that one. Are we talking increasing swap space or just actually adding another stick of RAM or what? |
| 10:37 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Free on Ubuntu 18.04 test VM" (4 lines) at http://paste.evergreen-ils.org/14378 |
| 10:38 |
Dyrcona |
That's after having done very little, just looking up a book and editing it's information. |
| 10:38 |
Dyrcona |
Is this going to be for production use or just for testing? |
| 10:39 |
RMiller |
Production on a small scale- we're one K-12 school library. |
| 10:40 |
Dyrcona |
You'll probably want 8GB in the end. If it's virtualized, they should be able to increase the RAM rather easily, just a config change and VM restart. |
| 10:41 |
RMiller |
Ok. Thank you again for all your help! I really appreciate it |
| 16:58 |
bshum |
It's kind of like you'd have to though. In order to preserve the original displayed content vs. the new variable you'd rather be searching on |
| 16:59 |
|
khuckins joined #evergreen |
| 17:01 |
nfBurton |
I thought one would exist already. Thanks for the sanity check. |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T16:54:23,308313503-0500 -0> |
| 17:02 |
bshum |
It wouldn't be the first time we broke up an existing field definition into more granular pieces to achieve certain goals |
| 17:04 |
|
mmorgan left #evergreen |
| 17:54 |
|
aabbee left #evergreen |
| 08:54 |
mmorgan |
@coffee |
| 08:54 |
* pinesol |
brews and pours a cup of Kenya Mamuto Kirinyaga, and sends it sliding down the bar to mmorgan |
| 08:55 |
mmorgan |
@coffee [someone] |
| 08:55 |
* pinesol |
brews and pours a cup of Costa Rica Finca Cerro Palado, and sends it sliding down the bar to dbwells |
| 09:11 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:33 |
phasefx |
not really a success, but getting there |
| 09:35 |
mmorgan |
Less of a failure is a success |
| 09:45 |
rhamby |
mmorgan: unless the less of a failure is a failure to correctly diagnose the scale of failure (I'm clearly in an optimistic mood today) |
| 10:01 |
Dyrcona |
Unfortunately, the ejabberd log only shows it closing the connection, not why. |
| 10:02 |
|
yboston joined #evergreen |
| 10:06 |
Dyrcona |
OK. Looks like we need some chunking/bundling work there, possibly. |
| 10:22 |
Dyrcona |
So, I got it to work on a "test" server by setting max_stanza_size to 2,000,000 and firing the event by itself. |
| 10:23 |
Dyrcona |
The server that normally runs the events already has max_stanza_size set to 2,000,000, so it can't be just that. |
| 10:26 |
* Dyrcona |
wishes the perl debugger was actually useful. |
| 10:33 |
Dyrcona |
So, I may just go back to using 1 collector and 1 reactor. It seems we've had the --run-pending a/t runner get hung up about 1/week since changing the configuration. That's far more often than before. |
| 10:33 |
Dyrcona |
csharp: Have you encountered any similar issues? |
| 10:41 |
|
khuckins joined #evergreen |
| 10:41 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:50 |
Dyrcona |
I lowered our collect and react settings to 2, just to see if that helps. |
| 10:50 |
* Dyrcona |
doubts it. |
| 11:10 |
|
terran joined #evergreen |
| 11:11 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 11:12 |
phasefx |
getting there |
| 11:13 |
phasefx |
the pgTAP failure is legit |
| 11:15 |
Dyrcona |
phasefx: I've discussed that failure with someone (gmcharlt?) at the hack-away. I noticed when going to Pg 10. |
| 11:17 |
phasefx |
Dyrcona++ |
| 11:18 |
berick |
and phasefx++ |
| 11:18 |
Dyrcona |
phasefx: What version of Pg is installed? |
| 11:18 |
berick |
building test server on ub 18? |
| 11:18 |
phasefx |
Dyrcona: PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit |
| 11:19 |
Dyrcona |
OK. I don't recall if I've ever run the tests on Pg 9.6. |
| 11:19 |
phasefx |
berick: debian stretch, but we have or are close to having multi-server support |
| 11:20 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.xml;h=6e3952d0b1f47e2a1898d3048ebe6153ce4da547;hb=refs/heads/collab/phasefx/eg_live_tests |
| 11:20 |
berick |
nice! |
| 11:21 |
Dyrcona |
Looks like we'll have to modify the test to accommodate 9.6 also.... |
| 11:31 |
phasefx |
right now testing.evergreen-ils.org is still running test.sh (http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test.sh;h=11d96d5b42eb05d513e6bea63d75a29983175246;hb=refs/heads/collab/phasefx/eg_live_tests), but we can eventually switch it over to and smoke test test_runner.pl http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.pl;h=4fc672529021ec2b74bcf83d69dc22bf74ff3c73;hb=refs/heads/collab/phasefx/eg_live_test |
| 11:32 |
phasefx |
then folks with commit access to the branch can just add their servers (there's an ssh pubkey for testin.evergreen-ils.org in the branch) |
| 11:33 |
Dyrcona |
phasefx: Sound interesting/useful. I'll take a look some day. |
| 11:38 |
jeff |
what keeps us using the random repository for all manner of things? would gitlab and/or something else help us get away from that practice, because it would potentially reduce the burden of creating a repo? |
| 11:38 |
jeff |
(tangent, i know) |
| 12:25 |
|
bdljohn1 joined #evergreen |
| 12:36 |
|
beanjammin joined #evergreen |
| 12:39 |
Dyrcona |
jeff: Gitlab will let you create your own repositories just by pushing to them be default. It can be done with gitolite using a wildcard repo configuration. |
| 12:42 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,428726255-0500 -0> |
| 12:42 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,450827934-0500 -2> |
| 12:42 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,472980231-0500 -4> |
| 12:47 |
dickreckard |
uhm, is there a way to list the last records added to the catalog in the staff client? |
| 13:01 |
miker |
dickreckard: in the staff client directly? hrm, probably not. but in another tab: http://sandbox-32.evergreencatalog.com/opac/extras/feed/freshmeat/opac/biblio/import/10/ |
| 13:05 |
* jeff |
notes the Apache "Found" 3xx body appended to the end of that document |
| 13:12 |
jeff |
also, if you're not logged in to the staff client in that browser when you fetch that url, if the most recent 10 bibs aren't otherwise visible in searches, you may get zero results, or more likely less than the number requested. |
| 13:14 |
jeff |
but if there are zero results you'll get an error that references record IDs, which you can then individually retrieve. |
| 13:16 |
Dyrcona |
dickreckard: What problem are you trying to solve? Do you want to see X of the most recent records you've added or just the previous one? This sounds like a potentially useful feature request. |
| 13:16 |
dickreckard |
no it's for the staff indeed |
| 13:17 |
dickreckard |
just wanted to check how the staff is doing in the test installation, and export the records that were added |
| 13:17 |
dickreckard |
so maybe make a csv with the IDs and use the batch export |
| 13:18 |
dickreckard |
cos I will need to merge the old database with the recods that were added in the test installation, into a new installation |
| 13:20 |
dickreckard |
I think a record query " * sort(create_date) #descending " solve my needs.. but indeed the last x records instead of just the 'retriev last bib record' button could be nice |
| 13:26 |
dickreckard |
also I finally solved the problem I had with vandelay batch imports.. I found the issue was that systemd creates a private /tmp folder nested inside an apache2 private folder, so it couldn't find the uploaded temporary .mrc file as it was inside the private tmp instead of /tmp. I wanted to somehow add that note somewhere, cos it would be useful to add in the documentation as from debian stretch it's the |
| 13:26 |
dickreckard |
default behavior. |
| 13:27 |
dickreckard |
I looked on launchpad and couldn't find mentions about it. so let me know if I can add notify this somewhere. |
| 13:29 |
jeff |
It might be reasonable to review changing the default value of <importer>/tmp</importer> in openils.xml.example |
| 13:31 |
Dyrcona |
dickreckard: You should be able to get marc records out of the URL that miker shared earlier. |
| 13:31 |
|
sandbergja joined #evergreen |
| 15:07 |
JBoyer |
++ |
| 15:08 |
* berick |
wonders if csharp is in the house |
| 15:08 |
berick |
in any event, I'll note that in the LP |
| 15:08 |
* Dyrcona |
was thinking we could assign testing with Firefox to csharp. :) |
| 15:08 |
JBoyer |
The thing that's primarily being tested is the Windows installer. The extension can function without changes so long as the windows bits are updated. |
| 15:08 |
gmcharlt |
ok |
| 15:08 |
gmcharlt |
so I'll take this as |
| 15:09 |
gmcharlt |
#info Next Hatch release is close |
| 15:09 |
JBoyer |
+1 |
| 15:09 |
gmcharlt |
#action berick, JBoyer, csharp, et. al. will collaborate on final testing |
| 15:09 |
gmcharlt |
Bmagic: we can discuss the Dymo stuff later in the agenda |
| 15:09 |
Bmagic |
sure |
| 15:10 |
gmcharlt |
but I note that since there's a direct Evergreen dependency with the "compatiblity mode", we may not want to couple that issue with the other stuff that's being worked on for the Hatch release |
| 15:10 |
|
khuckins__ joined #evergreen |
| 15:11 |
gmcharlt |
^ that one looks straightforward; I'll run it through its paces and will merge today |
| 15:12 |
gmcharlt |
the other is bug 1729610 |
| 15:12 |
pinesol |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:12 |
gmcharlt |
which I know miker will test, but it would be nice to have additional eyes on it |
| 15:12 |
gmcharlt |
I'll write up draft release notes as well |
| 15:12 |
gmcharlt |
request chunking will /not/ make it into 3.1-beta for lack of code |
| 15:12 |
gmcharlt |
any questions? |
| 15:12 |
* miker |
hangs head in shame |
| 15:13 |
JBoyer |
Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too. |
| 15:14 |
|
bdljohn1 joined #evergreen |
| 15:14 |
* Dyrcona |
is using websocketd in production and it is very reliable. |
| 15:14 |
berick |
just noticed I need a better commit message on the websocketd patch... |
| 15:25 |
gmcharlt |
ok, moving on |
| 15:25 |
gmcharlt |
#topic Hatch |
| 15:25 |
|
Topic for #evergreen is now Hatch (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:26 |
berick |
I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing. |
| 15:26 |
gmcharlt |
berick++ |
| 15:26 |
berick |
I don't have a Dymoe printer, alas |
| 15:27 |
berick |
so kind of like the other Hatch issue, more help testing would be appreciated |
| 15:27 |
gmcharlt |
I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting |
| 15:27 |
dbwells |
We've got a million Dymos and can help with testing. |
| 15:27 |
Bmagic |
I solicited my libraries and was able to borrow one more long term. |
| 15:28 |
gmcharlt |
as ultimately that's meaningless to the user |
| 15:28 |
Bmagic |
I'm not married to the term either. |
| 15:47 |
berick |
and when it's enabled it will be clearly /other/ |
| 15:47 |
berick |
and not a replacement |
| 15:47 |
gmcharlt |
but I'm wondering if we can go so far as to also deprecate the old embedded OPAC at the same time, with a stated goal of removing it in 3.4 |
| 15:47 |
JBoyer |
+1 to having the code in core, possibly just have 2 entries in the cat menu "Search Catalog" and "Testing Catalog" or similar. |
| 15:47 |
Dyrcona |
I'd be inclined to leave it out. |
| 15:47 |
berick |
Dyrcona: well, it's already in there |
| 15:47 |
berick |
or do you mean the menu entry? |
| 15:48 |
berick |
Dyrcona: gotcha |
| 15:48 |
miker |
is it Decided(tm) that the embedded catalog must die? (sorry if that's been made clear or is obvious) |
| 15:48 |
JBoyer |
Does seem a little early to deprecate embedded tpac in 3.3, though |
| 15:48 |
berick |
it could still be easily tested even if it weren't listed in the menu, of course |
| 15:49 |
berick |
miker: that is certainly my hope, but no decisions on that have really been made. also why I wanted to raise the topic |
| 15:49 |
JBoyer |
miker, if it went up to a vote among circ staff they wouldn't think twice, as the iframe eats the shortcut keys. |
| 15:49 |
gmcharlt |
miker: in the long run, I don't think it does us much good to support two different staff OPACs (although obviously there will need to be a way to quickly open a bib in the OPAC) |
| 15:49 |
berick |
make sure I'm tilting at the correctly shaped windmills |
| 16:05 |
berick |
that's my take as well. |
| 16:05 |
miker |
gmcharlt: that's totally fair |
| 16:05 |
jeffdavis |
I think deprecating in 3.3 is too aggressive, but a soft goal of defaulting to angular OPAC in 3.4 (+ deprecating TPAC in client) is ok with me. |
| 16:06 |
gmcharlt |
I also think that it should be a bit easier than editing navbar.tt2 (or the equivalent) to make it avaialble in 3.3 for testing purposes |
| 16:06 |
gmcharlt |
YAOUS, perhaps? |
| 16:07 |
JBoyer |
A reasonable compromise; that way Library A can get their staff started early even if Library B isn't sure how this whole "online" thing is going to shake out. |
| 16:07 |
miker |
I'm mainly curious as to whether we can, or should, write an Ang egFrame component so we can make use of what's there, or will the whole catalog in the client continue to be AngJS until we switch? |
| 16:08 |
berick |
miker: as it stands, I'm making the Ang catalog jump to AngJS for anything it's not prepared to deal with |
| 16:08 |
berick |
to ease integration / testing |
| 16:09 |
berick |
e.g. it jumps to AngJS for holdings maintenance, holds lists, and a few others |
| 16:09 |
berick |
but AngJS stays within its own sphere for now |
| 16:09 |
berick |
it never jumps back to Ang (unless you use the back button) |
| 16:10 |
berick |
which as it stands would be confusing for most staff, but certainly usable / testable |
| 16:10 |
miker |
sure, that makes sense |
| 16:11 |
berick |
but to answer your questoin, I think yes, there has to be a single catalog that's the main one |
| 16:11 |
berick |
which will be angjs until it's not |
| 16:15 |
* JBoyer |
can't wait for the hip-hop remix of the discussion. |
| 16:15 |
berick |
i think that's it so far |
| 16:15 |
berick |
miker: :) |
| 16:16 |
gmcharlt |
ok, so I think to sum up, it sounds like we have |
| 16:16 |
gmcharlt |
(a) general willingness that the Ang staff OPAC be made available in 3.3 in some fashion for testing |
| 16:17 |
gmcharlt |
(b) a new shared sense of what the issues will be around when (or if) to make a full transiition to it at some point |
| 16:17 |
gmcharlt |
accurate? |
| 16:17 |
miker |
+1 |
| 16:17 |
JBoyer |
+1 |
| 16:17 |
berick |
+1 |
| 14:49 |
jeff |
similarly, History (bib_source(1)) does not restrict to bib source 1 |
| 14:51 |
miker |
jeff: that's both interesting and annoying... I'll see if there's something obvious |
| 14:52 |
jeff |
thanks. in the meantime, i'm learning new things. :-) |
| 14:52 |
miker |
jeff: the one common thing there is that locations and bib source are part of the new int_array-based attribute vector visibility tests, and audience is not -- it's a standard coded value map thing |
| 14:53 |
jeff |
problem came to light because we have some search filter groups that use locations() |
| 14:55 |
jeff |
and locations(123) and bib_source(1) seem to do the expected thing with regard to the SQL using search.calculate_visibility_attribute_test |
| 14:56 |
jeff |
but (locations(123)) and (bib_source(1)) eventually lose the filter before it gets to the sql. |
| 15:01 |
|
bdljohn joined #evergreen |
| 15:02 |
|
yboston joined #evergreen |
| 15:05 |
Dyrcona |
So, if someone has a bad url on a provider and activates a PO and pushing the edi fails, does fixing the url automagically fix it all, or do I need to update some other fields? |
| 15:14 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 15:14 |
* berick |
chuckles |
| 15:15 |
berick |
as if millions of QA tests suddenly cried out in terror |
| 15:16 |
Dyrcona |
:) |
| 15:16 |
Dyrcona |
Well, if you can't clone the repo.... |
| 15:19 |
|
jvwoolf1 joined #evergreen |
| 16:42 |
|
dkyle2 left #evergreen |
| 16:42 |
Dyrcona |
Yeah, that PO definitely causes some kind of problem. |
| 16:42 |
* Dyrcona |
will look into it more tomorrow. |
| 17:06 |
jeff |
miker: the patch supplied above doesn't seem to improve the issue. testing with opac and with Open-ILS/src/support-scripts/test-scripts/query_parser.pl |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf1 left #evergreen |
| 17:18 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 17:24 |
dbwells |
:( |
| 17:36 |
|
khuckins joined #evergreen |
| 17:54 |
Bmagic |
Grrrr, xpath yall |
| 17:54 |
Bmagic |
oils_xpath('//datafield[@tag="856"]/subfield[@code="u"]/text()',marc) doesn't seem to work |
| 17:57 |
Bmagic |
ha! //*[@tag="856"]/*[@code="u"] worked |
| 18:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 171. <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:08 |
|
jvwoolf joined #evergreen |
| 10:10 |
|
yboston joined #evergreen |
| 10:39 |
|
khuckins joined #evergreen |
| 10:40 |
Dyrcona |
remingtron | mmorgan: I've made the branches and pushed them to the working repo. I'm going to test them on MassLNC VMs before updating the bug and adding the pullrequest tag. |
| 10:44 |
remingtron |
Dyrcona++ |
| 10:45 |
|
abneiman joined #evergreen |
| 10:46 |
Dyrcona |
@blame [band] |
| 10:46 |
* Dyrcona |
waits on the installation script.... |
| 10:51 |
Dyrcona |
It takes about 20 to 25 minutes from start to finish, if anyone cares. :) |
| 11:40 |
Dyrcona |
After some fun with clearing the cache and cookies, the 3.1 branch works for me. |
| 11:41 |
Dyrcona |
bshum suggested using incognito mode windows for testing, which I think is a good idea. I'll try that next time. |
| 11:42 |
mmorgan |
Dyrcona: I would second the use of incognito mode |
| 11:43 |
Dyrcona |
And, hey! There's a developers' meeting scheduled for this afternoon. |
| 11:44 |
Dyrcona |
mmorgan: You would be interested to know that I have updated the build scripts for the MassLNC VMs and fixed most of the issues. I will send an email to the interested parties later. This branch testing also constitutes testing of the scripts. |
| 11:45 |
mmorgan |
Dyrcona++ |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 13:12 |
|
beanjammin joined #evergreen |
| 13:17 |
|
stlink joined #evergreen |
| 13:21 |
stlink |
Problem solved: they had blocked cookies from being accepted from the PINES server. |
| 13:28 |
remingtron |
Seems like the qatests haven't run in a while |
| 13:28 |
remingtron |
According to IRC logs, looks like this is the last day it ran (or logged to IRC anyway): http://irc.evergreen-ils.org/openils-evergreen/2018-08-27 |
| 13:29 |
remingtron |
er, I guess the test output says Sept 10, but that's still a while ago |
| 13:30 |
remingtron |
phasefx: what's the state of the test server? |
| 13:45 |
remingtron |
sandbergja: Seems like we need to remove old docs files, like "circulating_items.adoc |
| 13:45 |
remingtron |
", which has been replaced by "circulating_items_web_client.adoc". Keeps causing confusion. |
| 13:46 |
remingtron |
sandbergja: if you have any thoughts on how to approach that process, I'd love to hear them! |
| 13:47 |
* miker |
will not be able to make it to the dev meeting today :( |
| 13:57 |
phasefx |
remingtron: re: test server, on my plate for next Tuesday |
| 13:57 |
remingtron |
phasefx: awesome |
| 13:57 |
* dbwells |
will also miss the dev meeting today |
| 14:02 |
berick |
in light of the above, and given there's no agenda or email reminder, perhaps we should push the dev meeting back a week. |
| 10:06 |
Dyrcona |
Anyone using the Hold Expires from Shelf Soon email notice care to discuss how you run it? |
| 10:07 |
Dyrcona |
We're running it daily with a delay of -2 days and finding that they usually go out for the next day, not two days ahead. |
| 10:08 |
Dyrcona |
I think that's because the shelf expire time is not 23:59:59 but the actual time the item went on the shelf + our 7 day interval. |
| 10:08 |
Dyrcona |
If I run it later in the day on a test VM, I get more that are 2 days out but still get some that are for 1 day. |
| 10:12 |
* Dyrcona |
is considering changing the delay to -3 days, but wonders if running it hourly would make a difference. |
| 10:15 |
JBoyer |
We don't use it here (probably should consider it) but if there's a preference for 2 days it might help to add an additional 12 hours, so 60 hours rather than 2 days? Depending on how things line up that should fairly well cover the second day without creeping into the third or leaving many behine. |
| 10:17 |
|
kmlussier joined #evergreen |
| 13:33 |
sandbergja |
That makes sense. I'm not sure how we came to the decision to use suffixes for volume indications; it was before my time |
| 13:36 |
Dyrcona |
I think added the volume to the end of call numbers is a fairly common thing in libraryland. |
| 13:50 |
Dyrcona |
Back to my hold expires from shelf soon thing: I just noticed that the 2 day courtesy notice that we use has a delay of -3 days and a max delay of -2 days. I'm going to use those settings. |
| 13:56 |
* Dyrcona |
tests it, first. |
| 14:58 |
|
yboston joined #evergreen |
| 15:04 |
mmorgan |
Dyrcona: FWIW, our 2 day courtesy notices have those same settings. |
| 15:04 |
Dyrcona |
mmorgan: -3 days, -2 days, daily granularity? |
| 15:05 |
Dyrcona |
It's looking like that would work, but I'm testing -2 days, -1 days, hourly granularity. |
| 15:05 |
mmorgan |
Dyrcona: Yes, daily |
| 15:12 |
JBoyer |
A late in the day thought re: acp.alert_message in a post 3.1/3.2 world, is there any reason for it to even be in the IDL at all? After running the upgrade script and updating the copy editor there's really no way to use it anymore, and it's displayed by default in a few grids... |
| 15:13 |
JBoyer |
I don't think it's worth altering the db tables just yet, but if it can't be set and can't be changed, maybe it's time it can't be seen. |
| 15:47 |
mmorgan |
I had caramel apple bullseyes once. They were surprisingly not bad. |
| 15:51 |
kmlussier |
I don't think I would like that. |
| 16:20 |
Dyrcona |
Jabber disconnects.... |
| 16:21 |
Dyrcona |
On a test server but sure is making testing rather difficult. |
| 16:23 |
|
khuckins_ joined #evergreen |
| 16:34 |
|
nfburton joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 12:03 |
stephengwills |
I assume it’s a better practice to have one copy of a funtion and have it living in the schema my target version expects? |
| 12:03 |
stephengwills |
function* |
| 12:06 |
blongwel |
jeff:after getting a help ticket from one of our libraries I looked up some emails in patron records and tried a search on them. |
| 12:11 |
jeff |
blongwel: auditor.actor_usr_lifecycle could help determine if the email address value changed in any way, but if you're confident that the value before and after save was identical, it's possible that you have a corrupt index on that column. have you tested at the database level with something like SELECT id, email FROM actor.usr WHERE deleted = false AND lowercase(email) = |
| 12:11 |
jeff |
lowercase('someaddress example.org');? |
| 12:11 |
jeff |
(sorry, that split across messages) |
| 12:11 |
jeff |
a corrupt index would be worrisome unless you know what led to the corruption, but a REINDEX can fix it. |
| 12:11 |
jeff |
but I'd suggest confirming the symptoms before trying that. |
| 12:13 |
blongwel |
jeff: I will give that a try. Thanks for the assist |
| 12:13 |
jeff |
What does the index look like currently in the psql output of \d+ actor.usr |
| 12:14 |
jeff |
mine looks like: "actor_usr_email_idx" btree (lowercase(email)) |
| 12:43 |
kmlussier |
stephengwills: What release were you on previously? |
| 12:43 |
* kmlussier |
can't back pies until tonight or maybe tomorrow morning. |
| 12:44 |
kmlussier |
s/back/bake |
| 12:44 |
stephengwills |
I’m moving from 2.8.3 to 3.1.7 on my test bed. |
| 12:44 |
jeff |
impressive. beats our 2.10 -> 3.1 jump back in September. |
| 12:44 |
kmlussier |
Wow! That's a lot of fun new features packaged in there. |
| 12:45 |
bshum |
stephengwills: When you go through the motions |
| 15:18 |
pinesol |
Launchpad bug 1529969 in Evergreen "double-scan during check-in still troublesome" [Undecided,New] |
| 15:33 |
|
stephengwills left #evergreen |
| 15:57 |
kmlussier |
mmorgan: I'm confused. I thought the Retarget All Statuses modifier covered those non-holdable statuses. Am I misremembering? |
| 16:00 |
mmorgan |
It's been a while since I tested this, but for an item in a non-holdable status, the first checkin would clear the status, possibly the retargeting would happen in the background, but the item was non-holdable, so it wouldn't capture. The second checkin would capture. |
| 16:01 |
* mmorgan |
should re-confirm that with a current test |
| 16:04 |
kmlussier |
OK, if that's the case, then that bug can probably be set to Incomplete. I'll add a comment. |
| 16:05 |
kmlussier |
I don't think I understand what the use case is for retargeting all statuses if it's not there to capture those items that were not in the hold copy map. |
| 16:07 |
jeff |
without "retarget all statuses", it only attempts to retarget copies that had a pre-checkin status of "In Process". |
| 09:10 |
bshum |
I guess I did do placeholder upgrade scripts for continuity back in bug 925776. Once upon a time. |
| 09:10 |
pinesol |
Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" [Medium,Fix released] https://launchpad.net/bugs/925776 |
| 09:10 |
bshum |
Calling 1137 and 1138 |
| 09:28 |
pinesol |
[evergreen|Rogan Hamby] LP#1643709 purge users on merge instead of flag deleted - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ded488> |
| 09:28 |
pinesol |
[evergreen|Rogan Hamby] LP#1643709 User merge + purge pgtap test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4791ce> |
| 09:28 |
pinesol |
[evergreen|Ben Shum] LP#1643709: Stamping upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71f5ed7> |
| 09:40 |
|
yboston joined #evergreen |
| 10:02 |
|
sandbergja joined #evergreen |
| 11:08 |
|
khuckins joined #evergreen |
| 11:13 |
|
khuckins_ joined #evergreen |
| 11:23 |
pinesol |
[evergreen|Jane Sandberg] Docs: adding release notes for 3.1.8 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a19990c> |
| 11:29 |
pinesol |
[evergreen|Jane Sandberg] Docs: release notes for 3.2.2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2867043> |
| 11:43 |
dbwells |
FYI: Cutoff for 3.1.8 and 3.2.2 will be today at 12:30 EDT. If anyone needs a little more time than that, please let me know. Thanks! |
| 11:53 |
pinesol |
[evergreen|Jane Sandberg] Docs: documenting multiple emails in patron editor (LP1755625) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ebb67d> |
| 11:55 |
* jeff |
digs to see why dojo fieldmapper-related things are broken on a new web client setup on a 3.1 system |
| 11:57 |
|
mdriscoll joined #evergreen |
| 12:04 |
|
khuckins joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:06 |
JBoyer |
re: dbwells's comment above: lp 1793154 should be a super simple test. Bug 1772062 might not take much effort either. |
| 12:06 |
pinesol |
Launchpad bug 1793154 in Evergreen "Web client: Can't Cancel Hold from Title Records" [Undecided,Confirmed] https://launchpad.net/bugs/1793154 |
| 12:06 |
pinesol |
Launchpad bug 1772062 in Evergreen 3.1 "Copy Template Missing Values When Applied" [High,Confirmed] https://launchpad.net/bugs/1772062 |
| 12:07 |
JBoyer |
Uh oh. That's not the right bug number at all. (1772062 will in fact, not be easy to test, but the bug it actually addresses would be.) |
| 12:09 |
JBoyer |
It's bug 1804038 that should be ready to go. |
| 12:09 |
pinesol |
Launchpad bug 1804038 in Evergreen "Password Reset results in Internal Server Error" [High,Confirmed] https://launchpad.net/bugs/1804038 |
| 12:10 |
JBoyer |
I apparently copypasta'd the wrong number into muy branch name... |
| 12:16 |
* mmorgan |
will grab lp 1793154 |
| 12:16 |
pinesol |
Launchpad bug 1793154 in Evergreen "Web client: Can't Cancel Hold from Title Records" [Undecided,Confirmed] https://launchpad.net/bugs/1793154 |
| 12:17 |
dbwells |
JBoyer: about that bug, 'clense' was a misspelling which was meant to be eradicated long ago, but some stragglers remained. I think a better fix would be to move the fixed spelling, which in general will not need to be namespaced (provided we are importing :datetime). |
| 12:17 |
dbwells |
JBoyer: I can create such a branch if you want to test and signoff, or we could do it the other way if that works better for you. |
| 12:20 |
dbwells |
Actually, I am not sure why the misspelling wasn't working, since that should be exported, too. Hmmmm. |
| 12:22 |
|
kmlussier joined #evergreen |
| 12:24 |
dbwells |
Ah, I see, the function has been moved/renamed again :) |
| 12:33 |
dbwells |
ok, branch incoming shortly |
| 12:35 |
|
nfburton joined #evergreen |
| 12:37 |
mmorgan |
JBoyer++ |
| 12:37 |
mmorgan |
lp 1793154 was an annoying one! |
| 08:57 |
|
stephengwills joined #evergreen |
| 09:04 |
stephengwills |
I’ve upgraded db schema to 3.1 and srfsh allows me to log in but my search reveals no items. I tried reingesting and still no joy. suggestions? |
| 09:06 |
|
ningalls__ joined #evergreen |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Add optional context to interval_to_seconds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac48931> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737: Unit tests for DST and date math - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a659357> |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Use new OpenSRF interval_to_seconds() context - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd047ba> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737 Apply DST-aware timezone to context dates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=319f82d> |
| 09:12 |
pinesol |
[evergreen|Bill Erickson] LP#1635737 Due date DST-aware thinko fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e067e00> |
| 09:22 |
|
yboston joined #evergreen |
| 09:27 |
berick |
dbwells: working/user/berick/lp1635737-syntax-fix |
| 09:29 |
|
abowling joined #evergreen |
| 12:27 |
jeff |
heh. |
| 12:29 |
jeff |
that's a slightly more complicated answer, and requires delving into the "novel data structure" |
| 12:31 |
Bmagic |
hmmm, that is one number and not several numbers concatenated (grasping at straws)... I do notice that the same bib has a source id |
| 12:31 |
mmorgan |
Bmagic: I have a concerto test system that shows 2 biblio.record_entry rows with that value in vis_attr_vector |
| 12:32 |
Bmagic |
interesting, with that value, which search scopes will it result the bib? |
| 12:32 |
mmorgan |
and one record that has {268435457} |
| 12:33 |
jeff |
268435458 indicates "bib source 2" |
| 14:47 |
|
Dyrcona joined #evergreen |
| 14:48 |
* Dyrcona |
got bumped in DTW (Detroit) not leaving until 10:00 PM tonight. |
| 14:48 |
JBoyer |
D: |
| 14:49 |
* Dyrcona |
will also have questions about action_trigger_runner.pl because it is not working on my test vm, but it was a couple of weeks ago. (I know that's vague, but I have to start looking at it again.) |
| 14:49 |
|
kmlussier joined #evergreen |
| 14:58 |
csharp |
has anyone out there done a batch forgive of bills that I might crib from? starting from scratch is... not fun |
| 14:59 |
mmorgan |
csharp: I asked a similar question a week or two ago without response :-( |
| 15:34 |
mmorgan |
Bmagic++ |
| 15:34 |
mmorgan |
Dyrcona++ |
| 15:42 |
|
plux left #evergreen |
| 15:42 |
Dyrcona |
So, I'm trying to figure out why action_trigger_runner.pl appears to do nothing on my test VM. It was working a week or so ago. |
| 15:42 |
Dyrcona |
It runs but says there's nothing to do, basically. |
| 15:42 |
Bmagic |
what are all of the arguments, granularity? |
| 15:43 |
Dyrcona |
Specifically, I'm trying to get the hold expires from shelf soon to run for a test. |
| 15:43 |
Dyrcona |
I have it set up with -2 days delay and a granularity of daily. |
| 15:43 |
Dyrcona |
I have other daily granularity events that ought to fire, too. |
| 15:43 |
mmorgan |
Dyrcona: Is the event definition enabled? |
| 14:46 |
aabbee |
yes, sorry. |
| 14:47 |
aabbee |
well, it's an angular6 question. not much of an evergreen question. |
| 14:47 |
rhamby |
aabbee: I think the first part is really specific but I'll pass on the question about debugging |
| 14:48 |
sandbergja |
I just threw a question into the livestream, but I'll repeat it here: How much have y'all been using the ng generate command in the ang6 cli? More broadly, what is the best way to get started with a new module, component, etc.? |
| 14:50 |
sandbergja |
Thanks! |
| 14:50 |
|
abowling1 joined #evergreen |
| 14:50 |
sandbergja |
I have another one: what about the e2e tests? |
| 14:51 |
rhamby |
sandbergja: ah, we shut down, but they might see it here in channel |
| 14:51 |
sandbergja |
berick++ |
| 14:51 |
Bmagic |
berick++ |
| 14:51 |
rhamby |
berick: gmcharlt: any objections to posting the archived video on the channel later? |
| 14:52 |
gmcharlt |
no objection from me |
| 14:52 |
berick |
rhamby: no objection |
| 14:52 |
sandbergja |
gmcharlt: berick: I'm curious about the e2e folder in the ang6 code. Is there a plan to write e2e tests for the ang6 app? |
| 14:53 |
sandbergja |
or is it ng cli boilerplate? :-) |
| 14:53 |
berick |
sandbergja: it's cli boilerplate :) |
| 14:53 |
berick |
we do have unit tests |
| 14:53 |
berick |
'npm run test' |
| 14:53 |
sandbergja |
oh cool! where do the unit tests live? |
| 14:54 |
berick |
sandbergja: along with the code, it's very handy. e.g. eg2/src/app/core/idl.spec.ts |
| 14:56 |
sandbergja |
Cool! I will take a look |
| 14:58 |
aabbee |
clarification on my question earlier: "ERROR Error: "[object Object]" core.js:1673" is a very specific error message, you're right. but i've seen that exact message (same line number and everything) for wildly different mistakes. |
| 16:16 |
ejk |
eby: csharp says "yes" |
| 16:16 |
eby |
thanks ejk |
| 16:18 |
ejk |
(too many /e.{2}/ nicks from aadl) |
| 16:24 |
kmlussier |
If anyone is looking for easy branches to test at the hack-a-way (or for those following along from home), I'm really hoping all of my pullrequests can be reviewed before I leave. It looks like I only have two at the moment. |
| 16:24 |
kmlussier |
bug 1755543 |
| 16:24 |
pinesol |
Launchpad bug 1755543 in Evergreen 3.1 "web client: Replace spine label settings descriptions with help tips" [Low,Confirmed] https://launchpad.net/bugs/1755543 |
| 16:25 |
kmlussier |
bug 1783602 |
| 16:25 |
pinesol |
Launchpad bug 1783602 in Evergreen "Copy counts should be removed from metarecord search results page" [Medium,New] https://launchpad.net/bugs/1783602 |
| 16:26 |
kmlussier |
remingtron++ |
| 16:26 |
remingtron |
I'll start looking at the first one, 1755543 |
| 16:43 |
remingtron |
kmlussier: how do you get to the "print spine labels" screen? |
| 16:43 |
kmlussier |
If you pull up an item on the item status screen, there is a Print Labels options under Show in the actions menu. |
| 16:44 |
kmlussier |
It's also available from copy buckets and holdings view, but I usually use item status in my testing. |
| 16:44 |
remingtron |
kmlussier: thanks |
| 16:46 |
pinesol |
[evergreen|Bill Erickson] LP#1789747 SharedWorker sanity checks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe6bd46> |
| 16:46 |
pinesol |
[evergreen|Bill Erickson] LP#1789747 More SharedWorker sanity checks for egLovefield - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=66f3d11> |
