| Time |
Nick |
Message |
| 00:29 |
|
Akum joined #evergreen |
| 00:30 |
Akum |
Hi |
| 05:54 |
|
yar joined #evergreen |
| 06:01 |
|
dbs joined #evergreen |
| 06:01 |
|
jeff joined #evergreen |
| 06:02 |
|
serflog joined #evergreen |
| 06:02 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 06:25 |
|
pastebot joined #evergreen |
| 06:25 |
|
dbs_ joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 2. <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 06:31 |
|
jeff___ joined #evergreen |
| 06:31 |
|
RBecker_ joined #evergreen |
| 06:38 |
|
serflog joined #evergreen |
| 06:38 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 07:02 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
rlefaive joined #evergreen |
| 07:43 |
|
rlefaive joined #evergreen |
| 07:53 |
|
akilsdonk joined #evergreen |
| 08:04 |
|
rlefaive joined #evergreen |
| 08:14 |
|
rlefaive joined #evergreen |
| 08:18 |
|
collum joined #evergreen |
| 08:34 |
|
ngf42 joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:01 |
|
dbs joined #evergreen |
| 09:05 |
csharp |
shared in #code4lib: https://github.com/npm/npm/issues/19883 |
| 09:05 |
csharp |
yowza |
| 09:13 |
|
kmlussier joined #evergreen |
| 09:17 |
dbwells |
whoa |
| 09:17 |
ngf42 |
O_O https://media.giphy.com/media/DGiZfWmc0HWms/giphy.gif |
| 09:25 |
|
yboston joined #evergreen |
| 09:27 |
Bmagic |
yeah, that is a doozy |
| 09:27 |
Bmagic |
csharp++ |
| 09:30 |
|
dkyle joined #evergreen |
| 09:31 |
JBoyer |
csharp++ |
| 09:32 |
miker |
that's so bad that I'm afraid to click on the link to the commit... |
| 09:32 |
JBoyer |
miker, it's worth it to see what they called the function call. |
| 09:33 |
JBoyer |
named, rather. |
| 09:34 |
miker |
HA.. first, the old name is GOLDEN. "make derp". yes, yes you did |
| 09:34 |
dbwells |
ah, to laugh or to cry |
| 09:35 |
miker |
second, "you keep using this word 'correct' ..." |
| 09:35 |
dbs |
Do we recommend using "sudo npm" in our install docs at any point? |
| 09:35 |
dbs |
(or running npm commands as root, perhaps in some broader context)? |
| 09:36 |
|
jeff___ joined #evergreen |
| 09:36 |
JBoyer |
I don't believe we do, it appears to be run as opensrf normally. |
| 09:36 |
dbs |
http://docs.evergreen-ils.org/reorg/dev/command_line_admin/_extra_steps_for_web_staff_client.html doesn't say what user to run those steps as |
| 09:37 |
jeff |
do we document steps where we use npm to update/upgrade npm itself? |
| 09:37 |
dbs |
but the previous step at http://docs.evergreen-ils.org/reorg/dev/command_line_admin/_installing_prerequisites.html are to be done as root; and normally we say "Perform the following steps as the XXX user", so it's likely some people are running the npm steps as root |
| 09:37 |
jeff |
it looks like that's the only way you end up with the (unclearly tagged) pre-release version with this (impressive) bug. |
| 09:38 |
miker |
dbs: grep says we have, but it doesn't look like that's the case in recent master |
| 09:38 |
jeff |
and running as root (without sudo) doesn't trigger the bug, at least per what portion i've read so far. |
| 09:38 |
miker |
have recommended 'sudo npm' in the past, I mean |
| 09:39 |
dbwells |
Yeah, it seems our npm instructions have gotten more fuzzy recently, but I wasn't sure of the intention. |
| 09:40 |
JBoyer |
jeff, well, most of the things touched should already be owned by root; without poring over it in depth I would guess that appears to work as a lucky accident |
| 09:40 |
|
Dyrcona joined #evergreen |
| 09:42 |
dbs |
http://docs.evergreen-ils.org/2.12/_optional_extra_steps_for_browser_based_staff_client.html says "sudo npm update" |
| 09:43 |
dbs |
but that's after installing node from source, which... |
| 09:43 |
dbs |
v0.10.28 at that |
| 09:45 |
bshum |
Hmm |
| 09:45 |
bshum |
The main readme for 2.12 doesn't say to install that source anymore |
| 09:45 |
bshum |
Sounds like something slipped through the cracks in the docs |
| 09:48 |
Dyrcona |
Yeah. You should be installing 6.11 something. |
| 09:48 |
bshum |
dbs: http://docs.evergreen-ils.org/2.12/_optional_extra_steps_for_web_staff_client.html ; when I navigate through the doc book, it changes the page to this one |
| 09:48 |
bshum |
Which just says to install the nodejs LTS |
| 09:48 |
bshum |
I don't know how that extra page ended up in the middle that you found :) |
| 09:48 |
bshum |
But it's an old page |
| 09:48 |
Dyrcona |
Did 2.12 get updated to install the LTS? |
| 09:48 |
bshum |
And probably shouldn't be there |
| 09:49 |
bshum |
Dyrcona: Yeah kmlussier pushed that fix into 2.12 series cause of the problems with old Node |
| 09:49 |
Dyrcona |
Ah, cool. I haven't checked. |
| 09:50 |
|
littlet joined #evergreen |
| 09:51 |
dbs |
bshum: seems likely that the doc build process doesn't clean up the directories after they're built; I found that page through Google |
| 09:52 |
dbs |
"site:docs.evergreen-ils.org npm" |
| 09:53 |
Dyrcona |
Documentation lies.... :) |
| 09:53 |
* Dyrcona |
just had to say it. |
| 09:53 |
Dyrcona |
So, who's "in charge" of the doc process these days? |
| 09:54 |
* dbs |
also wonders where "the previously described Optional: Developer Addition" can be found (as referenced in current docs)... heh |
| 09:54 |
Dyrcona |
That's the distro-release-developer target. |
| 09:54 |
dbs |
grep says it can't be foudn in the docs |
| 09:55 |
Dyrcona |
My advice is never use the online installation docs. Always use the README. |
| 09:55 |
Dyrcona |
It's 5. in the README. |
| 09:57 |
dbs |
README is a symlink to docs/installation/server_installation.adoc |
| 09:57 |
Dyrcona |
Yes, I'm aware of that. |
| 09:57 |
dbs |
"Developer Additions" appears there only in the sentence "the previously described Optional: Developer Additions" |
| 09:58 |
|
terran joined #evergreen |
| 09:58 |
dbs |
The online docs are built from the README, which is docs/installation/server_installation.adoc |
| 09:58 |
Dyrcona |
I know that, too, but as you've discovered errors happen. |
| 09:59 |
dbs |
So what I'm trying to do is say a) there is a dangling reference in the README aka docs/installation/server_installation.adoc that either needs to be corrected or removed and b) we need to revisit the doc build process to do something like mv the old docs out of the way if the build is successful |
| 10:00 |
dbs |
Saying "always use the README" doesn't get us closer to solving either of those problems |
| 10:02 |
kmlussier |
dbs: I think the previously described Optional: Developer Additions are from step 5 of Installing prerequisites. |
| 10:03 |
kmlussier |
It makes more sense if you follow the link from the Downloads page since it's all on one page. In the official doscs, you need to click the 'Prev" link to see it. |
| 10:04 |
Dyrcona |
dbs: I agree, but all too often I find new people coming in channel trying to install using out of date docs from the web site. |
| 10:05 |
Dyrcona |
So, I recommend use the README from the tar ball until the docs are fixed. |
| 10:05 |
Dyrcona |
That's why I asked "who's in charge." |
| 10:05 |
dbs |
kmlussier: ah i get it, the mismatch in case ("Developer additions" vs. "Developer Additions") was breaking my search |
| 10:05 |
dbs |
kmlussier: so we need to add a proper link target to that |
| 10:06 |
kmlussier |
dbs: Yes, that would be a useful addition, I think. |
| 10:07 |
* dbs |
will give that a shot as a way of procrastinating writing |
| 10:07 |
kmlussier |
dbs++ |
| 10:08 |
remingtron |
dbs: Robert Soulliere is still hosting the live docs server, so he's "in charge" of implementing build changes in a visible way. But we have a docs dev server too, where things can be tested. |
| 10:08 |
remingtron |
docs-testing.evergreen-ils.org |
| 10:11 |
|
mmorgan1 joined #evergreen |
| 10:12 |
dbs |
ah installing 200mb of packages for latex support :) |
| 10:13 |
Dyrcona |
Yeah, there is that...Just so that asciidoc can generate PDFs. |
| 10:14 |
dbs |
The five minutes are a worthwhile one-time cost :) |
| 10:14 |
Dyrcona |
Yes, unless you promised to reboot the z39.50 server at 10:00 am and apt says it's going to take 7 more minutes to download the rest of the packages at 9:59. :) |
| 10:15 |
Dyrcona |
And, yes, that happened this morning. |
| 10:15 |
dbs |
ouch |
| 10:15 |
Dyrcona |
Ctrl-c is your friend. :) |
| 10:15 |
Dyrcona |
We had some networking fallout after switching out the load balancers this week. |
| 10:16 |
Dyrcona |
Seems odd, but the machines (real and virtual) with two ip address on different networks had to have the gateway changed to the internet-routable network before they would completely funtion. |
| 10:17 |
Dyrcona |
Dunno what necessitated that because I used the same ip-tables config. |
| 10:18 |
Dyrcona |
But, now I know when I set up the others later this month. |
| 10:18 |
Dyrcona |
Or next month. |
| 10:18 |
|
mmorgan joined #evergreen |
| 10:20 |
|
beanjammin joined #evergreen |
| 10:32 |
dbs |
hmm, pdf transform is dying during dblatex step because "*** Error: orderedlist too deeply nested (> 4)" |
| 10:32 |
dbs |
happens with stock master for me *sigh* |
| 10:33 |
csharp |
@who is too deeply nested? |
| 10:33 |
pinesol_green |
Glen is too deeply nested. |
| 10:34 |
dbs |
oh i guess we're using fop now? |
| 10:45 |
dbs |
successful build (using 'a2x --format pdf --fop docs/root.adoc' for posterity) |
| 10:46 |
dbs |
branch is at user/dbs/link_to_optional_developer_additions if anyone wants it |
| 10:46 |
* dbs |
out |
| 10:49 |
dbs |
well not quite out, jamesrf asked to join https://gitlab.com/evergreen-library-system/evergreen-library-system which had automatically been migrated over from gitorious years ago, so I added him and set up automatic syncing of the repo from git.evergreen-ils.org |
| 10:49 |
|
Christineb joined #evergreen |
| 10:50 |
|
beanjammin joined #evergreen |
| 11:07 |
remingtron |
anyone know if the password changed for web client on demo.evergreencatalog.com? |
| 11:07 |
remingtron |
We've been using it for taking screenshots, but today we can't login. |
| 11:08 |
Dyrcona |
The password for which user? There are several in concerto. |
| 11:08 |
remingtron |
admin |
| 11:08 |
Dyrcona |
Have you tried another user? |
| 11:08 |
remingtron |
I haven't tried others, no |
| 11:09 |
remingtron |
other concerto logins seem to work |
| 11:10 |
Dyrcona |
Then, it's likely the password for admin changed. |
| 11:10 |
Dyrcona |
But, I don't know. |
| 11:10 |
Dyrcona |
Can you use the other accounts to get your screen shots, or is there something about admin that you need? |
| 11:10 |
remingtron |
some concerto's don't work, some do |
| 11:11 |
remingtron |
yes, I think we can use one of the logins that has worked. Thanks for the suggestion. |
| 11:11 |
remingtron |
Dyrcona++ |
| 11:11 |
Dyrcona |
Sounds like someone has been messing around. I don't think I have access to that server to reset anything. |
| 11:13 |
remingtron |
Look what happens when you give people a demo server! |
| 11:13 |
remingtron |
:) |
| 11:16 |
Dyrcona |
:) |
| 11:43 |
|
yboston joined #evergreen |
| 12:03 |
csharp |
@blame whoever broke the demo server |
| 12:03 |
pinesol_green |
csharp: Your failure is now complete, whoever broke the demo server. |
| 12:04 |
|
beanjammin joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:07 |
eby |
speaking of the demo server, would anyone have a second to try duplicating something for me |
| 12:07 |
eby |
in webby |
| 12:15 |
kmlussier |
sure |
| 12:15 |
* mmorgan |
can have a go, too. |
| 12:15 |
eby |
if you go to /eg/staff/circ/holds/shelf/XXX with XXX being a hold id that has already been picked up by a patron |
| 12:15 |
eby |
i'm curious what the status shows as |
| 12:19 |
berick |
BTW, that's select hold in row -> choose Detail View |
| 12:20 |
mmorgan |
9 |
| 12:21 |
mmorgan |
eby: what do you see? |
| 12:22 |
eby |
9 |
| 12:22 |
* mmorgan |
has no idea what "9" means. |
| 12:22 |
eby |
we've had some lag we are looking into so we've seen checked out holds still show up on the shelf list for a little bit |
| 12:23 |
eby |
but wanted to make sure wasn't something else with that 9 |
| 12:23 |
eby |
thanks for testing |
| 12:23 |
berick |
9 == hold fulfilled |
| 12:23 |
berick |
sounds like a bug in the UI |
| 12:23 |
mmorgan |
np! |
| 12:24 |
berick |
in the sense that it should show a friendly status label, not 9, obviously |
| 12:24 |
mmorgan |
Ideally you would not get there for a fulfilled hold, since it would no longer show on your holds shelf. |
| 12:24 |
berick |
oh yeah |
| 12:25 |
mmorgan |
Unless you had the detail page open already, and realoaded. Or if there's a lag with filled holds coming off the shelf as eby reports. |
| 12:26 |
eby |
yeah the hold_strings.tt2 only goes up to 8. I think us seeing it is performance related. I just added a 9 = checked out to our tt for now until we get to the bottom of our performance |
| 12:27 |
|
alynn26 joined #evergreen |
| 12:28 |
eby |
thanks again |
| 12:36 |
alynn26 |
I am working on our Custom Receipts for the web client, and was working on the holds pull list. Currently it sorts by the hold ID. I trying to get it to sort by shelving location, I've used ng-repeat="hold_data in holds | orderBy:hold_data.copy.location" but it still only sorting by the ID. Any suggestions |
| 12:46 |
eby |
mmorgan / berick would you prefer i open a bug on the missing translation? |
| 12:47 |
berick |
eby: well, like mmorgan said, you should not be seeing captured holds in that interface |
| 12:47 |
berick |
unless the hold was already selected, and the page was later refreshed |
| 12:47 |
berick |
but I suppose having the translation won't hurt |
| 12:47 |
berick |
and could help in these unexpected cases |
| 12:49 |
berick |
eby: so, yeah, i guess a bug would be good, but maybe clarify in the description it's an edge case |
| 12:49 |
* mmorgan |
would agree it wouldn't be a bad thing. |
| 12:49 |
eby |
thanks |
| 12:56 |
berick |
alynn26: couple things to consider.. the argument for orderBy needs to be in qotes. also, if you want to order by location name, you'll probably need ...copy.location.name. |
| 12:57 |
berick |
alynn26: so orderBy:'hold_data.copy.location.name' -- but I'm not 100% sure ordeBy supports nested values like that. not seeing any good examples of that in our code. |
| 12:57 |
berick |
alynn26: and finally, if you use Copy Location Order configs, it should sort by that for you automatically |
| 12:58 |
|
mmorgan joined #evergreen |
| 12:58 |
berick |
that's the default sort, followed by request time (same as id sorting in most cases) |
| 13:03 |
alynn26 |
I went back and reread the orderBy information, and found the quote issue. We do not user Copy Location Order, so it was only using the request time. But not my receipt will print in Shelving Location order. Thanks berick. |
| 13:04 |
|
hbrennan joined #evergreen |
| 13:04 |
alynn26 |
ng-repeat="hold_data in holds | orderBy:'copy.location.name'" worked like a charm. |
| 13:05 |
berick |
alynn26: nice! |
| 13:06 |
alynn26 |
now if i can figure out how to sort it by location then by call number my staff would be happy. |
| 13:08 |
kmlussier |
alynn26: bug 1749502 |
| 13:08 |
pinesol_green |
Launchpad bug 1749502 in Evergreen "Web Client Holds Pull List Printing" [Undecided,New] https://launchpad.net/bugs/1749502 |
| 13:08 |
kmlussier |
I think Joan mentions in that bug how to get the call number sorting in there. |
| 13:09 |
kmlussier |
Which reminds me of a question Joan asked me about call number sorting in that print template... |
| 13:10 |
alynn26 |
I did a bug search but did not see that one. Thanks for pointing it out to me. I will make my changes now. Thanks. |
| 13:10 |
kmlussier |
In the holds pull list, there is a call number label column, which I believe is a combination of the cn prefix, label, and suffix. |
| 13:10 |
kmlussier |
We wanted to sort by that full call number in the print template, but we weren't sure if it could be done. |
| 13:11 |
* kmlussier |
hasn't had much time to look into it, but since we were chatting about pull list templates, I'll throw the question out there. |
| 13:18 |
alynn26 |
There is a hold_data.call_number.label vs the hold_data.volume.label. I cannot tell if there is a difference as we do not use the prefixes or suffixes so, they both print the same thing. |
| 13:22 |
miker |
fwiw, there should also be a label_sortkey which normalizes the CN value. however, it does /not/ include affixes |
| 13:28 |
|
khuckins joined #evergreen |
| 13:28 |
JBoyer |
miker, re: label sortkeys not incluing affixes, is there a specific reason for that? One of the reasons some of our libraries don't use them is that they don't sort as expected when using things like OPAC browse and etc. |
| 13:30 |
JBoyer |
There hasn't been enough interest in them to have much of a discussion about it (Is it a bug? add an OUS? etc.) I'm just curious. |
| 13:30 |
kmlussier |
We have many people who would love to see them included in the sort order. |
| 13:30 |
miker |
JBoyer: well, affixes are "local" additions to what, say, LoC would consider a call number. for instance, a JUV prefix is important to humans because it effectively removes the need to look at the shelving location of an item (it's in the juvenile section) but it doesn't have anything to do with what the book is about. |
| 13:31 |
miker |
IOW, it's not part of, say, a Dewey number |
| 13:32 |
miker |
the "answer" is, include the shelving location (under the assumption that that's the purpose of the prefix. does that assumption generally hold?) |
| 13:33 |
miker |
note: that's just the logic behind the decision. I'm not arguing that it's the best UX for librarians that want to shortcut the shelving location and use the prefix instead |
| 13:34 |
miker |
(or the best UX for any given workflow other than "be technically correct about CN normalization") |
| 13:34 |
kmlussier |
miker: I've been told there are times when multiple prefixes can be used within a shelving location. I'm not sure how often that happens. |
| 13:35 |
JBoyer |
That's a difficult assumption with fiction. Are the SCI FIC items shelved with regular FIC? how about MYSTERY, WESTERN, etc. |
| 13:35 |
miker |
it also makes normalization monumentally simpler, because the main CN label can reasonably be expected to follow the rules of the assigned label_class |
| 13:35 |
JBoyer |
We have both kinds of libraries in our group (it's all fic, or each genre has an acpl) I'm sure BISAC has other warts that I'm not aware of. |
| 13:36 |
kmlussier |
Moving off topic. When is the beta deadline again? |
| 13:36 |
dbwells |
Next Wednesday, 2/28 |
| 13:36 |
miker |
heh... I used to advocate for bisac. and then I went to a book store last week and spent 45mins hunting for something :) |
| 13:36 |
kmlussier |
dbwells: Thanks! |
| 13:37 |
* kmlussier |
is taking the day off tomorrow and was wondering how much she needed to stress about getting things in before beta. |
| 14:00 |
|
rlefaive joined #evergreen |
| 14:49 |
mmorgan |
Regarding the call number prefix/shelving location discussion - one example where prefix is important is a shelving location "Adult Video", and prefixes "DVD", "Blu-Ray" |
| 14:52 |
* miker |
wishes that would just come out of the MARC |
| 14:53 |
|
collum_ joined #evergreen |
| 14:55 |
jeff |
or two shelving locations. |
| 14:56 |
jeff |
but I suspect the number of call numbers with Blu-Ray or DVD in the label which don't 1:1 match with what's in the MARC is also a bit of a problem there. |
| 14:58 |
kmlussier |
miker++ |
| 14:58 |
kmlussier |
No for the current discussion, but for ongoing bug fixing for our search highlighting. |
| 15:00 |
mmorgan |
Also, combopacks have one of each format. |
| 15:00 |
jeff |
sure, but those have a challenge in the call number label/prefix are also :-) |
| 15:01 |
jeff |
s/are/area/ |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:17 |
kmlussier |
@marc 242 |
| 15:17 |
pinesol_green |
kmlussier: A translation of the title proper that is made by the cataloger when the translated title does not appear as a parallel title on the item. For a note, the introductory phrase Title translated: may be generated based on the field tag for display. (Repeatable) [a,b,c,h,n,p,y,6,8] |
| 16:49 |
|
mmorgan joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:37 |
miker |
thanks for being down, launchpad... |
| 18:30 |
|
jwoodard joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
