Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143

Results for 2017-10-05

06:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:15 rjackson_isl joined #evergreen
07:21 agoben joined #evergreen
07:32 Dyrcona joined #evergreen
07:50 csharp Bmagic: I'm interested in the results of your test as well - that's a long-standing source of confusion for our libraries
08:03 collum joined #evergreen
08:27 Dyrcona So, no one uses retarget local holds when checking in new copies?
08:28 * Dyrcona just got caught up with the logs.
09:24 Dyrcona There are things about syrup that I do not understand.
09:24 Dyrcona i.e. most of it.
09:25 Dyrcona It appears to need an Evergreen installation to talk to via the gateway, yet doesn't work unless services are also running locally.
09:27 * Dyrcona is going to install stock 3.0 on a test server with production data.
09:27 kmlussier No, I don't think that's true. NOBLE doesn't have Syrup running with an Evergreen installation. I'm pretty sure artunit told me it wasn't needed way back when.
09:27 Dyrcona All I can say is what I see in our installation which I did not set up and have had little to do with except upgrading the OpenSRF and Evergreen packages when we upgrade production.
09:28 Dyrcona Ours has configuration to use bark.cwmars.org and it wont' work unless I run services locally.
09:29 Dyrcona That's all I can say for certain at this time.
09:29 Dyrcona I did set up a test vm that uses itself, and the same appears to be true there.
09:29 Dyrcona Hopefully, we will soon abandon Syrup.
09:36 mdriscoll joined #evergreen
09:47 kmlussier I'm curious. Why is the new Overdrive functionality not recommended for production use without careful testing?
09:48 csharp hmm - 2017-10-05 09:15:42 utility03 open-ils.trigger: [WARN:25782:Client.pm:122:] Sending large message of 2544937 bytes to router@private.utility03.gapines.org/open-ils.trigger
09:48 Dyrcona 'Cause it hasn't been thoroughly tested, or at least not beyond Sitka.
09:48 csharp immediately after that, the client is gone from the jabber network
09:48 * Dyrcona is supposed to setup a test with Overdrive, but time.
09:50 csharp that's a PO JEDI a/t event, btw
09:51 Dyrcona csharp: Did the event complete with success and was it properly handled?
09:55 mdriscoll Regarding Syrup, NOBLE has opensrf 2.4.1 installed on our syrup server.  We are not even running opensrf services.  Syrup utilizes the opensrf libraries to talk to whatever evergreen server you point it at.  According to a comment in the code "It [Python OpenSRF library] isn't needed for our read-only ILS operations, only for updates."  So if you are not having Syrup make changes to Evergreen copies like copy location, I
15:06 Dyrcona And, git confirms it.
15:06 Stompro joined #evergreen
15:06 * Dyrcona wanted to make a slashdot joke, about offline being dead, but it didn't seem to fit.
15:25 kmlussier Speaking of offline, I asked this question late Friday afternoon, which is a bad time to ask a question.
15:26 kmlussier All of my offline testing was done when my computer was offline or when I was in offline mode.
15:26 kmlussier I've noticed when rebuilding my VMs that offline doesn't seem to work if the Evergreen server is down.
15:27 kmlussier How will we be handling those situations where the Evergreen server is down?
15:35 Dyrcona I thought that was the point of offline, though granted you may have to make a connection first to get the required data.
15:36 kmlussier Dyrcona: Yes, you do have to make that connection first and load the patron edit screen.
15:38 Dyrcona So, you're saying that after that, it still doesn't work if the server is down?
15:52 kmlussier berick: That's what I did before when I said I went directly to the offline page.
15:52 berick ah, missed that part of the comment
15:52 berick so it fails to render
15:53 kmlussier berick: yes
15:54 kmlussier miker: So have you gotten offline to work in your own testing where the Evergreen server is no longer available?
15:55 miker kmlussier: it's working for me right now on webby
15:55 miker (apache is off)
15:56 miker well, back on now
15:58 kmlussier miker: OK, I visited the patron reg page.
16:00 miker kmlussier: apache's down
16:00 miker hey webby, I'm in your interface offlinin' books ;)
16:02 kmlussier miker: hmmm, so it worked at first, but then after I cleared my browser cache (not app cache), I got the 503.
16:07 kmlussier On my own test server, if I simply stop Evergreen services, offline works.
16:08 miker ah, that's because of ngnix
16:09 miker or... wait...
16:10 miker haproxy on webby, rather
16:20 kmlussier bug 1721636
16:20 pinesol_green Launchpad bug 1721636 in Evergreen "upup needs to learn about i18n.js" [Undecided,New] https://launchpad.net/bugs/1721636
16:20 kmlussier miker++
16:20 miker kmlussier: thanks
16:20 * miker makes a note at the top of base_js.tt2
16:29 miker kmlussier: http://git.evergreen-ils.org/?p=working​/Evergreen.git;a=shortlog;h=refs/heads/​user/miker/lp-1721636-i18n_js-for-upup
16:29 miker kmlussier: you'll need to clear the service worker cache to test, obvs
16:31 * kmlussier prefers WARNING WARNING WARNING over ATTENTION ATTENTION ATTENTION because it reminds her of the Lost in Space robot.
16:31 miker kmlussier: ha! I started with WARNING, but changed it ... sorry :)
16:39 khuckins_ joined #evergreen
17:01 mmorgan left #evergreen
17:05 khuckins__ joined #evergreen
17:37 berick joined #evergreen
18:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:40 BobW__ joined #evergreen
19:47 yar joined #evergreen
22:09 wsmoak_ joined #evergreen

Results for 2017-10-04

02:37 jihpringle joined #evergreen
06:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:17 rjackson_isl joined #evergreen
07:32 agoben joined #evergreen
08:07 collum joined #evergreen
10:20 Dyrcona Are you talking about 2.12 or 3.0?
10:20 csharp 2.12/OpenSRF 2.5
10:20 Dyrcona OK. Just makin' sure. :)
10:20 csharp we're going to 3.0 in January - just trying to get it going on all test servers I can get my hands on ;-)
10:21 Dyrcona OK. Thought you were upgrading this weekend, too.
10:21 csharp nah - we moved to 2.12 over Labor Day weekend - I'm a glutton for punishment, but not that much! :-)
10:21 Dyrcona We're looking at maybe next June for 3.0, but that's because there are a ton of other things we want to do in the mean time.
14:38 Dyrcona :)
14:38 Bmagic All FYI - The Evergreen 3.0 docker container is now avaialble for cloning. docker pull mobiusoffice/evergreen-ils:3.0.0
14:43 DPearl joined #evergreen
14:47 jeff Bmagic: only intended for testing use, not production -- per the repository description?
14:48 Bmagic jeff: I don't think there is a problem using it for production, provided you handle the database and configs for your environment
14:48 Bmagic we are using containers for our application bricks
14:48 Bmagic works perfectly fine, the database is separate
16:47 Bmagic blongwell - I always have to use the SQL query to see which one it's deciding
16:48 Bmagic the first part of the routine is to get the ID numbers of the circ staff, patron, item, circ library
16:49 Bmagic then plug those values into action.find_circ_matrix_matchpoint(context_ou integer,    item_object asset.copy,    user_object actor.usr,    renewal boolean)
16:50 berick think you can also grep for 'circulator: circ policy test found matchpoint' (at INFO) in the logs
16:50 Bmagic or rather this one action.find_circ_matrix_matchpoint(    context_ou integer,    match_item bigint,    match_user integer,    renewal boolean)
16:50 Dyrcona I was about to say I think it is logged at a different than normal log level setting.
16:51 Dyrcona But, I'm taking off, so good luck!
17:26 Bmagic it's not a "real" solution I don't think
17:26 Bmagic if it makes it a little better though, might as well
17:27 berick right, it's a back-stop
18:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:54 khuckins__ joined #evergreen
22:01 roycroft joined #evergreen
22:03 Bmagic joined #evergreen

Results for 2017-10-03

06:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:19 rjackson_isl joined #evergreen
08:01 kmlussier joined #evergreen
08:07 rlefaive_ joined #evergreen
08:20 csharp in this case it's the entire directory - when working from the 3.0.rc tarball it was the single file
08:21 csharp @monologue
08:21 pinesol_green csharp: Your current monologue is at least 9 lines long.
08:25 csharp so manually copying build, then manually creating /openils/var/web/js/ui/default/common/build/js (common didn't exist either) and copying jquery.min.js over got everything working
08:26 csharp either I'm reading wrong or something is borked
08:33 bos20k joined #evergreen
08:36 mmorgan joined #evergreen
08:39 csharp same behavior with another xenial test server\
08:44 * csharp files bug 1721015
08:44 pinesol_green Launchpad bug 1721015 in Evergreen ""grunt all" step not installing angular/dependencies" [Undecided,New] https://launchpad.net/bugs/1721015
09:01 Dyrcona joined #evergreen
09:14 yboston joined #evergreen
09:57 Dyrcona And, if you install from a tarball, as csharp points out, you can skip those steps as they should be done as part of the process in making the tarball.
09:57 Dyrcona Just for the sake of clarity in the logs. ;)
10:00 dbwells joined #evergreen
10:34 csharp Dyrcona: thanks for the confirmation
10:35 csharp I was confused because the karma tests shouldn't work at that point, right?
10:35 Dyrcona I think they would still work since they only look at what you have locally.
10:35 csharp ah - ok
10:35 Dyrcona The things just wouldn't be installed unless you ran make install again.
17:35 gmcharlt demo.evergreencatalog.com is now running 3.0.0
17:46 bshum gmcharlt++
17:59 jonadab joined #evergreen
18:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:02 remingtron joined #evergreen
19:04 b_bonner left #evergreen
20:05 rlefaive joined #evergreen

Results for 2017-10-02

01:08 pinesol_green [evergreen|Jane Sandberg] Docs: Juvenile-to-adult script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=717bb89>
01:24 abowling joined #evergreen
06:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:16 agoben joined #evergreen
07:16 rjackson_isl joined #evergreen
07:16 JBoyer joined #evergreen
09:57 csharp gonna try on a stock machine, manually building via instructions
09:57 csharp but our debs/config scripts don't touch JS at this point
09:59 gmcharlt csharp: yeah - and they shouldn't have to, at least in the case of using a release tarball
10:00 csharp yeah, this is built from the tarball
10:02 mmorgan1 joined #evergreen
10:09 csharp leaving that alone for now - manually copying the angular-sanitize.min.* files solved the immediate problem - I'll test and report back later this afternoon
10:26 mmorgan joined #evergreen
10:33 collum joined #evergreen
10:44 Dyrcona csharp: I build a fresh master vm yesterday and had no problems.
11:22 gmcharlt hmm, I've gone ahead and expanded the tarball
11:22 gmcharlt and yeah, no angular-sanitze* in Evergreen-ILS-3.0.rc/Open-ILS/w​eb/js/ui/default/staff/build/js
11:23 gmcharlt dbwells: out of curiosity, what platform did you build on?
11:24 dbwells gmcharlt: our main dev box is still on wheezy
11:25 mdriscoll joined #evergreen
12:08 dbwells csharp++ # testing the RC and finding a problem I caused
12:09 sandbergja joined #evergreen
12:09 dbwells csharp: It appears that I have a too-old npm version which led to this bad build.
12:11 dbwells Should be simple to correct, but also hoping to find time to actually understand the issue (I've been coasting with my understanding of some of this).
12:20 jihpringle joined #evergreen
12:23 khuckins__ joined #evergreen
12:45 csharp dbwells: oh - cool
16:25 kmlussier I won't be here long. :)
16:32 khuckins joined #evergreen
17:04 mmorgan left #evergreen
18:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:37 Dyrcona joined #evergreen
19:50 jonadab joined #evergreen
21:14 gmcharlt https://evergreen-ils.org/evergreen-deve​lopment-update-16-on-the-eve-of-release/

Results for 2017-10-01

04:00 acautley joined #evergreen
05:00 acautley joined #evergreen
06:00 acautley joined #evergreen
06:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:30 eady joined #evergreen
07:00 acautley joined #evergreen
07:56 gsams joined #evergreen
10:00 acautley joined #evergreen
11:00 acautley joined #evergreen
12:00 acautley joined #evergreen
13:16 pinesol_green [evergreen|Jane Sandberg] Docs: Adding search config info to client admin manual - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=52facdb>
13:16 pinesol_green [evergreen|Jane Sandberg] Docs: cleaning up client sysadmin manual - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=86c1ed7>
16:06 pinesol_green [evergreen|Jane Sandberg] Docs: documenting copy locations - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e9bb2ff>
17:01 gsams joined #evergreen
18:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>

Results for 2017-09-30

04:00 acautley joined #evergreen
05:00 acautley joined #evergreen
06:00 acautley joined #evergreen
06:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:00 acautley joined #evergreen
08:00 acautley joined #evergreen
08:25 eady joined #evergreen
17:03 Dyrcona But, what I don't get is how the existing getElementsByClassName code works when getElementById in the same place does not.
17:14 Dyrcona Guess I'll figure it out later.
18:00 acautley joined #evergreen
18:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:12 Dyrcona joined #evergreen
18:13 Dyrcona For the logs: Fixed it. Trouble wasn't what I thought it was. I had a typo in the string constart for the confirm dialog.
19:00 acautley joined #evergreen

Results for 2017-09-29

03:59 acautley joined #evergreen
04:59 acautley joined #evergreen
05:59 acautley joined #evergreen
06:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:00 acautley joined #evergreen
07:09 rjackson_isl joined #evergreen
07:36 Dyrcona joined #evergreen
07:52 Dyrcona heh
08:00 acautley joined #evergreen
08:17 collum joined #evergreen
08:20 kmlussier lol - a follow-up to my question about the staff client library timeout setting. It appears that this setting is consulted for web client timeouts.
08:21 kmlussier I had set it to 10 seconds the other day when I was testing it, and was just cursing at the web client this morning because it kept logging me out.
08:22 kmlussier I'm not sure why it didn't work in my earlier testing, though. Could it be a browser issue? I tested it in Firefox, but was using Chrome this morning when it started working.
08:23 kmlussier No, it's working in Firefox now too.
08:34 Dyrcona Could be a cache issue.
08:45 kmlussier @marc 130
08:45 pinesol_green kmlussier: A uniform title used as a main entry in a bibliographic record. [a,d,f,g,h,k,l,m,n,o,p,r,s,t,6,8]
09:20 pinesol_green Launchpad bug 1720345 in Evergreen "Cannot create copy tags" [Medium,Confirmed] https://launchpad.net/bugs/1720345
09:20 kmlussier gmcharlt: Thanks! If it looks good, is it something that can be merged or do I need to wait until after .0 is out?
09:21 gmcharlt it's enough of a regression that I've targetted it for 3.0.0
09:21 kmlussier gmcharlt: OK, I'll test it now.
09:35 kmlussier joined #evergreen
09:46 pinesol_green [evergreen|Galen Charlton] LP#1720345: ensure egEditFmRecord's customFieldTemplates is optional - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7f23400>
09:51 kmlussier gmcharlt++
16:34 kmlussier @hate inconsistent bugs
16:34 pinesol_green kmlussier: The operation succeeded.  kmlussier hates inconsistent bugs.
16:42 pinesol_green [evergreen|Jane Sandberg] Docs: Adding some use cases to MARC Batch Edit - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=24c896d>
16:57 kmlussier Before I leave for the day, I'm going to leave a question about offline circ. When I tested offline circ, I always tested it in an environment where I lost Internet.
16:58 kmlussier But I never tested the scenario where people need to use offline because the system is down.
16:58 kmlussier I've noticed that when I bring my VMs down, the staff login page shows the menu bar, but, otherwise, is white. How will staff get to offline circ in those cases when the system is down?
16:59 * kmlussier now needs to run but wanted to post the question before forgetting about it again.
17:00 acautley joined #evergreen
17:57 abowling left #evergreen
18:00 acautley joined #evergreen
18:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:00 acautley joined #evergreen
20:00 acautley joined #evergreen
21:00 acautley joined #evergreen

Results for 2017-09-28

02:25 gsams joined #evergreen
06:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:04 agoben joined #evergreen
07:11 rjackson_isl joined #evergreen
08:06 collum joined #evergreen
15:20 berick csharp: can you paste a few context lines?
15:20 berick from the source file
15:20 berick not seeing what I would expect to see at that line in master
15:20 Dyrcona csharp: PhantomJS is used by the karma unit tests.
15:21 csharp berick: which is the source file?  sorry - I'm truly at a loss :-/
15:21 * csharp is also sick, so brain is not 100%
15:21 berick /home/opensrf/pines/Open-ILS/web/js/​ui/default/staff/circ/patron/app.js
15:47 kmlussier @hates
15:47 pinesol_green kmlussier hates Launchpad search; Internet Explorer; snow; scheduling meetings; Starbucks; negative balances; undrinkable coffee; winter; blizzards; spam; dojo interfaces; Windows line endings; peanut M&Ms; bad technology days; authorities; pollen; comcast; and comcast even more
15:53 csharp @hates
15:53 pinesol_green csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (2 more messages)
15:53 csharp @more
15:53 pinesol_green csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; and (1 more message)
15:53 csharp @more
17:33 b_bonner left #evergreen
17:43 Jillianne joined #evergreen
17:59 acautley joined #evergreen
18:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:59 acautley joined #evergreen
19:59 acautley joined #evergreen
21:00 acautley joined #evergreen

Results for 2017-09-27

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/m​obiusoffice/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-cand​idate-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>

Results for 2017-09-26

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/gat​eway?service=open-ils.actor&amp;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

Results for 2017-09-25

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++

Results for 2017-09-24

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
09:49 Dyrcona joined #evergreen
13:39 Dyrcona joined #evergreen
18:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
22:37 roycroft joined #evergreen

Results for 2017-09-23

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
08:57 _adb joined #evergreen
12:03 Dyrcona joined #evergreen
12:19 Dyrcona joined #evergreen
13:20 Dyrcona part_holds-- # Parts are too fragile.
15:19 csharp anybody in Evergreen-land already written a systemd service unit file for opensrf?
15:34 jonadab joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:58 JBoyer joined #evergreen

Results for 2017-09-22

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

Results for 2017-09-21

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

Results for 2017-09-20

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/angul​ar-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/E​vergreen.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/evergr​een-2-11-9-and-2-12-6-released/
22:17 gmcharlt Bmagic++
22:17 gmcharlt dbwells++

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143