| Time |
Nick |
Message |
| 01:39 |
|
RBecker joined #evergreen |
| 02:18 |
|
beanjammin joined #evergreen |
| 03:04 |
|
JBoyer_alt_bin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
rjackson_isl joined #evergreen |
| 07:04 |
|
JBoyer joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:37 |
|
jvwoolf joined #evergreen |
| 07:51 |
|
dwgreen joined #evergreen |
| 07:55 |
|
jvwoolf joined #evergreen |
| 08:12 |
kipd |
Regarding https://evergreen-ils.org/documentation/install/README_3_0.html#_creating_the_evergreen_database_and_schema If I'm configuring a new server to point at an existing database on another server, may I simply not use the --create-{database|schema|offline} flags or is there another procedure I'm missing? |
| 08:26 |
|
stephengwills joined #evergreen |
| 08:34 |
bshum |
kipd: Right, skip the create-database and create-schema flags. You might still want offline though, cause that creates an offline.pl file that's used to connect to the database in offline modes for the staff client |
| 08:35 |
bshum |
I'm fairly sure that it'll just modify your opensrf.xml config file to use the corresponding DB credentials you pass for setup to talk to the server you want |
| 08:38 |
kipd |
That's what I was hoping for, thank you. |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:56 |
|
kmlussier joined #evergreen |
| 09:16 |
|
dbwells joined #evergreen |
| 09:23 |
Bmagic |
jeff: sure im down! |
| 09:25 |
Bmagic |
jeff: pg_restore -C dump.dmp > restore.log - did something unexpected. I created a file (restore.log) with all of the commands it should have run but didn't. The file is 200GB clear text. In theory, I could take that file and sneak in the extra extension bits at the top and run it.... |
| 09:25 |
Bmagic |
I/It |
| 09:28 |
Bmagic |
jeff: meeting time, be back in a bit |
| 09:31 |
|
yboston joined #evergreen |
| 09:33 |
jeff |
Bmagic: yep, that's expected with that command. what were you trying to do? |
| 09:54 |
stephengwills |
is there a common patron records problem one can look for when really_delete_user fails with a 500 error? |
| 09:56 |
Dyrcona |
Not that I'm aware of. The Apache error log is often useful in the event of a 500 error. |
| 09:57 |
Dyrcona |
I got one on a test server this morning that included enough of the Perl error for me to track it down, for example. |
| 09:58 |
stephengwills |
ok thanks. will dig deeper. |
| 09:58 |
Dyrcona |
Sometimes, that information isn't there, unfortunately. |
| 10:01 |
mmorgan |
Our OverDrive login activity type is working! We've recorded almost 30 logins in the first hour. |
| 10:01 |
mmorgan |
jeff++ |
| 10:04 |
csharp |
hmm - so how to I get console.debug messages to appear in the console? |
| 10:04 |
berick |
csharp: on chrome, there's a level selector |
| 10:05 |
berick |
next to the filter input |
| 10:05 |
berick |
make sure 'verbose' is checked |
| 10:05 |
csharp |
berick++ # thanks! |
| 10:07 |
jeff |
mmorgan: great! |
| 10:08 |
mmorgan |
:) |
| 10:09 |
mmorgan |
We also plan on breaking out other types of sip authentication to provide some useful statistics. |
| 10:09 |
JBoyer |
mmorgan++ |
| 10:10 |
JBoyer |
Data! |
| 10:10 |
mmorgan |
Our libraries love statistics :) |
| 10:11 |
Dyrcona |
Most do. :) |
| 10:12 |
csharp |
@whocares data |
| 10:12 |
pinesol_green |
csharp: I can't find anyone who loves or hates data. |
| 10:12 |
csharp |
@love data |
| 10:12 |
pinesol_green |
csharp: The operation succeeded. csharp loves data. |
| 10:12 |
csharp |
@love Data from TNG |
| 10:12 |
pinesol_green |
csharp: The operation succeeded. csharp loves Data from TNG. |
| 10:13 |
|
littlet joined #evergreen |
| 10:16 |
jeff |
mmorgan: keep in mind that some vendors poll the ILS only once at the time the patron creates a dedicated account with them, others poll every login, others poll every circ/use, all that. |
| 10:16 |
jeff |
mmorgan: you probably already had it that way. |
| 10:18 |
jeff |
mmorgan: what other external services do you have tied to SIP? |
| 10:18 |
mmorgan |
jeff: It will be interesting to see what the data looks like. |
| 10:18 |
mmorgan |
The first ones that come to mind are selfchecks and Envisionware PC Reservation. |
| 10:20 |
jeff |
ah. i feel better now. |
| 10:21 |
jeff |
i consider those internal, and not problematic like external database vendor auth via sip. :-) |
| 10:22 |
mmorgan |
We do have some of those as well and will keep in mind those caveats :) |
| 10:23 |
jeff |
ah, those were the ones i was interested in. :-) |
| 10:24 |
bshum |
kmlussier: For giggles, I tried using the latest nodejs binary v8.9.1 and grunt all crashed unhappily. But the latest LTS v6, which is v6.12.1 worked just fine for my building web client. So probably "safe" to bump up to that for master/everywhere |
| 11:08 |
|
littlet joined #evergreen |
| 11:14 |
Bmagic |
jeff: well, I was trying to restore the database from the dump file. I realize that the docs on pg_restore tell me that the command I ran would result in what it did. I was just trying different avenues for fun |
| 11:18 |
Dyrcona |
Bmagic: I assume you're doing this on a database server where it doesn't matter if you break it. |
| 11:18 |
Bmagic |
lol, yep |
| 11:18 |
Bmagic |
been dropping the db and recreating it all day |
| 11:19 |
jeff |
Bmagic: got it. as long as it wasn't for my benefit! |
| 11:19 |
rjackson_isl |
kmlussier++ for bug review |
| 11:20 |
kmlussier |
rjackson_isl++ for filing the bug! |
| 11:21 |
kmlussier |
I noticed something was wrong with the Located URI searches on a late afternoon a while back, but then I forgot to investigate further. |
| 11:21 |
Dyrcona |
Bmagic: Are you looking for tips to make it work? |
| 11:21 |
|
Christineb joined #evergreen |
| 11:22 |
Bmagic |
Dyrcona: My original issue are the pg_restore errors complaining about not finding the type evergreen.query_int |
| 11:23 |
Bmagic |
since then, I have been playing with it to see if I can get it to create the db and restore the data without getting that error |
| 11:23 |
Bmagic |
Dyrcona: a couple of pastebins http://paste.evergreen-ils.org/949 and http://paste.evergreen-ils.org/948 |
| 11:26 |
jeff |
Bmagic: do you have any time to share the information i had asked for yesterday? |
| 11:27 |
Bmagic |
jeff: yep! let me see what I can do right now. Dropping the -C |
| 11:27 |
jeff |
pg_restore --schema-only dumpfile | grep 'CREATE EXTENSION' |
| 11:27 |
jeff |
pg_restore --schema-only dumpfile | grep "query_int" |
| 11:28 |
Dyrcona |
You might need |& if the errors got to stderr. |
| 11:29 |
Bmagic |
jeff: perfect! Thanks. inc |
| 11:30 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "query_int" (8 lines) at http://paste.evergreen-ils.org/951 |
| 11:31 |
jeff |
okay, so that seems to confirm that you don't have any outside-of-the-extension defining of the query_int type. |
| 11:31 |
jeff |
next we'll see where the intarray extension is being created and if it differs in the pg_restore output from where you said it was created in the source database. |
| 11:31 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "CREATE EXTENSION" (9 lines) at http://paste.evergreen-ils.org/952 |
| 11:31 |
jeff |
CREATE EXTENSION IF NOT EXISTS intarray WITH SCHEMA evergreen; |
| 11:32 |
jeff |
that seems to explain why you have a function that is returning a value with type evergreen.query_int. |
| 11:32 |
Bmagic |
intarray WITH SCHEMA evergreen; ? |
| 11:33 |
jeff |
the intarray extension is installed in the evergreen schema, likely due to an unintentional search_path side effect. |
| 11:33 |
Bmagic |
sounds promising, I need to reconstruct the dump file somehow I guess? |
| 11:33 |
bshum |
I thought we didn't use tsearch2 extension anymore |
| 11:33 |
jeff |
which means that when you mixed a new DB with intarray in the public schema with the dump file from a database where it exists in the evergreen schema, sadness. |
| 11:33 |
bshum |
Didn't we drop it ages ago? |
| 11:34 |
jeff |
Bmagic: can you double check that \dx on the source database shows intarray in the public schema and not the evergreen schema? |
| 11:34 |
Dyrcona |
Bmagic: What version of Evergreen is you schema from? |
| 11:34 |
Dyrcona |
s/you/your/ |
| 11:35 |
Bmagic |
intarray | 1.0 | public |
| 11:35 |
|
rlefaive joined #evergreen |
| 11:35 |
Bmagic |
Dyrcona: 2.12 |
| 11:36 |
Dyrcona |
You don't need tablefunc (unless you're using it in your queries) and you don't need tsearch2. |
| 11:37 |
Bmagic |
Dyrcona: those are getting installed via dump file I guess. I am manually creating the db with http://paste.evergreen-ils.org/947 |
| 11:37 |
Dyrcona |
Yeah, if they're the db being dumped they will be recreated. |
| 11:37 |
* Dyrcona |
is omitting words today it seems. |
| 11:38 |
Bmagic |
sorry, tablefunc is in my script atm - removing |
| 11:38 |
jeff |
Bmagic: and you're sure that the database you're interrogating with \dx is the same database that the dump file corresponds with? that seems unusual for the extension to appear in one schema in the db and another in the pg_restore output of the dump file. |
| 11:38 |
Dyrcona |
My Pg 9.5 server shows plperl and plperlu as extensions, not just as languages. |
| 11:38 |
Bmagic |
jeff: yes |
| 11:38 |
Dyrcona |
Ok. just plperl. |
| 11:39 |
|
_adb joined #evergreen |
| 11:40 |
|
gsams joined #evergreen |
| 11:42 |
Bmagic |
jeff: I suppose there is a way to get intarray over to evergreen before pg_restore? |
| 11:42 |
|
khuckins joined #evergreen |
| 11:45 |
Dyrcona |
Bmagic: You can create the db with the db create script before doing the restore into it. |
| 11:45 |
Dyrcona |
Then, don't drop it. I'm not 100% certain that fixes your problem. |
| 11:45 |
Bmagic |
Dyrcona: I am doing that, however I am not creating the evergreen schema ahead of the restore |
| 11:45 |
jeff |
Bmagic: i have a query i'd like you to run on the source db to help understand / confirm something: https://gist.github.com/jeff/f225fb4c054d8c3e4f7593af4b7934d4 |
| 11:46 |
Bmagic |
jeff: ok, at what stage/state of the db? |
| 11:46 |
jeff |
i don't understand the question. |
| 11:47 |
Bmagic |
should that be run after I create the db but before --schema-only... |
| 11:47 |
jeff |
the current state of the source database that you're creating this dump file from. |
| 11:47 |
jeff |
the source db should already exist somewhere. |
| 11:47 |
jeff |
that's the database that you created the dump file from, and it's the one you've been running /dx against to look at the namespace of the intarray extension. |
| 11:52 |
jeff |
okay, if you don't have access to the running source database then my understanding of your previous assertions was incorrect, and there's less of a mystery here. |
| 11:53 |
|
sandbergja joined #evergreen |
| 11:53 |
jeff |
in trying to follow the common recommended practice of creating an empty database and creating the required languages and extensions within that database, then restoring to it, the intarray extension is created in the public schema. |
| 11:53 |
jeff |
at pg_restore time, the restore commands include a line like: |
| 11:53 |
jeff |
CREATE EXTENSION IF NOT EXISTS intarray WITH SCHEMA evergreen; |
| 11:54 |
Bmagic |
If I can change the subject for a second |
| 11:54 |
jeff |
in executing that command, postgresql sees that the extension intarray already exists in the target DB, and does not (and cannot) create it a second time. |
| 11:55 |
jeff |
this then breaks some of the explicit references to things like the intarray type at evergreen.query_int. |
| 11:55 |
Bmagic |
Anyone else having some web based staff client funniness. You get the login screen (without workstation), login and the resulting screen is a blank body with the menus along the top. Console is complaining about a link to gihub and lovefield.js.... |
| 11:56 |
jeff |
so, either create the extension in the schema that this particular database expects/requires it to be in, or don't pre-create the extension at all and let pg_dump create it. |
| 11:57 |
jeff |
getting things to a point where the extension exists in the expected schema is left as an exercise to the reader. :-) |
| 11:59 |
jeff |
(depending on... dependencies, it might be easier to adjust that with a pg_dump/pg_restore and some editing) |
| 11:59 |
Bmagic |
jeff++ |
| 11:59 |
Dyrcona |
I usually restore into an existing db with -c -C to drop and recreate it. |
| 12:00 |
jeff |
Dyrcona: with -c and -C, the existing database doesn't really have any impact/influence on the restore. it could be any database. |
| 12:00 |
jeff |
(-c and -C being --clean and --create) |
| 12:01 |
Dyrcona |
jeff: yes. |
| 12:01 |
Dyrcona |
It's like just creating the database via psql, then restoring into the empty database. |
| 12:02 |
jeff |
it also forces use of the database name contained in the dump. |
| 12:02 |
|
beanjammin joined #evergreen |
| 12:03 |
jeff |
were you saying that you create an existing database, or just that the existing database is already there and you're using -c -C as a shortcut to dropping it yourself? |
| 12:04 |
jeff |
i interpreted you to be saying that you were creating a (pointless, imo) empty database first, then using clean+create. |
| 12:06 |
Dyrcona |
No, the database already exists. |
| 12:06 |
Dyrcona |
Normally, I do this on the training or development db servers to refresh data. |
| 12:07 |
Dyrcona |
In training, I use the same db name as production. |
| 12:07 |
Dyrcona |
On the development dbs server, I do the same, but I also have other copies of the data with different db names. |
| 12:08 |
Dyrcona |
I usually remake those other copies by dropping them and then recreating them using the production-named database as a template. |
| 12:08 |
Dyrcona |
It's a lot faster than pg_restore. |
| 12:09 |
Dyrcona |
But, if you're renaming the db, and you don't have the db already on the server, you have to create an empty db to restore into. |
| 12:11 |
* jeff |
nods |
| 12:12 |
bshum |
Bmagic: re: web client, I recently tested the 2.12.8 tarball and that seemed fine to log in without any errors, same for recent master for me |
| 12:12 |
bshum |
Which version are we talking about on your end of things? |
| 12:13 |
Bmagic |
bshum: it's weird - doesn't happen right away. Seems like its some FF stale cookies or something. Happens on Chrome too. Incognito window "fixes" it sometimes, but still weird |
| 12:13 |
bshum |
Version of EG and Linux distro too |
| 12:13 |
Dyrcona |
Adding on to my last statement, I usually just do a create database statement from psql and don't bother with the create db script these days. |
| 12:14 |
Bmagic |
bshum: and not sustainable for the incoming nightmare of possible complaints and issues. |
| 12:16 |
Bmagic |
bshum: I don't have nginx for wbsc though... I wonder if that is the secret sauce |
| 12:19 |
jeff |
Dyrcona: yeah, i've usually used a create step and created the extensions and languages there first, then done a pg_restore with -d, but I'm re-evaluating that. |
| 12:20 |
|
jvwoolf joined #evergreen |
| 12:21 |
kmlussier |
Bmagic: What release is that on? There was a fix to a similar lovefield message in bug 1718301 |
| 12:21 |
pinesol_green |
Launchpad bug 1718301 in Evergreen "Webstaff offline DB connection failures" [High,Fix released] https://launchpad.net/bugs/1718301 |
| 12:22 |
Bmagic |
3.0.2 |
| 12:22 |
Bmagic |
kmlussier: perhaps the browser having been connected to an older web based staff client is keeping some cache? |
| 12:25 |
kmlussier |
Bmagic: Yeah, I think we I had previously seen it, it was after installing a new version of the web client. I needed to clear out local storage to fix it. I don't think I've seen it recently, but it was always a tricky problem to replicate. |
| 12:25 |
kmlussier |
*when* I had previously seen it, not we. |
| 12:26 |
Bmagic |
that is probably it |
| 12:26 |
Bmagic |
kmlussier++ |
| 12:57 |
sandbergja |
I'm trying to fix a typo in the web client interface, and I'm not sure of the i18n implications of correcting that typo. I have a commit here that also includes the relevant .pot and .po files (because I don't want any translation work to be lost), but I'm not sure if I actually need them/should have them there: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=d29d4987b573dda18115fb259b1f866234acf440 |
| 12:58 |
bshum |
sandbergja: I think kmlussier pointed that out to me and asked awhile back |
| 12:58 |
bshum |
Fixing the typo in the .pot and .po files is not a bad thing |
| 12:59 |
Dyrcona |
sandbergja: You generally don't need to fix the .pot and .po files though. They are generated are release time. |
| 12:59 |
bshum |
What'll happen is that the next import from git to LP will update the relevant template strings out there |
| 13:00 |
bshum |
At release time, if the string is already changed in git, it'll just get skipped over by the i18n sync process |
| 13:00 |
bshum |
I'm in favor of git changes like this so that it's easier for folk to install / test with |
| 13:00 |
bshum |
Rather than waiting or learning the i18n dance |
| 13:00 |
bshum |
But I'm okay with it either way |
| 13:00 |
Dyrcona |
I'll defer to bshum on that point, then. :) |
| 13:01 |
sandbergja |
That's helpful -- thanks. |
| 13:01 |
bshum |
For typos, I think it's fine |
| 13:01 |
bshum |
For large scale language changes, like if we altered the entire sentence, then I'd be more wary |
| 13:01 |
bshum |
Since the translated equivalent might no longer be applicable |
| 13:02 |
sandbergja |
Ahhhh, that makes a lot of sense. |
| 13:02 |
|
jihpringle joined #evergreen |
| 13:02 |
sandbergja |
bshum++ |
| 13:02 |
sandbergja |
Dyrcona++ |
| 13:03 |
sandbergja |
thanks to both of you for your help |
| 13:03 |
Dyrcona |
Yeah, that makes sense to me, too. |
| 13:04 |
bshum |
sandbergja++ # fixing typos :) |
| 13:04 |
kmlussier |
sandbergja++ |
| 13:06 |
Dyrcona |
sandbergja++ |
| 13:06 |
Dyrcona |
typos-- |
| 13:10 |
kmlussier |
@karma typos |
| 13:10 |
pinesol_green |
kmlussier: Karma for "typos" has been increased 0 times and decreased 1 time for a total karma of -1. |
| 13:11 |
kmlussier |
typos-- |
| 13:11 |
Dyrcona |
@karma typoes |
| 13:11 |
pinesol_green |
Dyrcona: typoes has neutral karma. |
| 13:11 |
* kmlussier |
almost made a typo while giving negative karma to typos. |
| 13:20 |
|
bkuhn joined #evergreen |
| 13:23 |
|
rlefaive joined #evergreen |
| 13:41 |
Dyrcona |
Was going to report this, but see why it's invalid: https://bugs.launchpad.net/sipserver/+bug/1473538 |
| 13:41 |
pinesol_green |
Launchpad bug 1473538 in SIPServer "Read syslog_facility from configuration file" [Undecided,Invalid] |
| 13:44 |
|
jvwoolf1 joined #evergreen |
| 13:45 |
bshum |
csharp: Hmm |
| 13:45 |
bshum |
The bug you just filed, that's post- https://bugs.launchpad.net/evergreen/+bug/1208875 |
| 13:45 |
pinesol_green |
Launchpad bug 1208875 in Evergreen 2.12 "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" [Medium,Fix released] |
| 13:45 |
bshum |
So I'm wondering why it's broken again, or it was not quite fixed right |
| 13:46 |
bshum |
Re: https://bugs.launchpad.net/evergreen/+bug/1736565 |
| 13:46 |
pinesol_green |
Launchpad bug 1736565 in Evergreen "Circulation History CSV download fails with large number of circulations" [Undecided,New] |
| 13:56 |
Dyrcona |
My first reaction is that csharp is missing the fix, but it could be the same symptom with the new code. |
| 13:57 |
Dyrcona |
It's faster, but that doesn't mean it's going to work in all cases. |
| 13:59 |
kmlussier |
Dyrcona: That's what I was thinking. It may be better, but still have a breaking point. |
| 14:00 |
Dyrcona |
Well, the back end times out at 6 seconds by default, so if a db query/cstore call takes longer than that, there's nothing for it but to up the time out values. |
| 14:44 |
|
littlet joined #evergreen |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:34 |
Bmagic |
what is the answer to using hatch after you enable it and get blank screens in the web based staff client? |
| 15:37 |
Bmagic |
after I "use hatch for storage" - I am left with blank screens from there on out. Logout, login again, and registering the workstation doesn't get forced, just blank screen |
| 15:38 |
JBoyer |
1: In the Chrome Dev Tools click Application, find anything related to using Hatch for Storage and delete it. |
| 15:39 |
JBoyer |
2: close and re-open Chrome and see if it's working |
| 15:39 |
JBoyer |
3: Don't do that again. ;) |
| 15:40 |
Bmagic |
Hatch disconnected: Access to the specified native messaging host is forbidden. |
| 15:40 |
JBoyer |
Also, depending on how Hatch was installed you may want to remove it entirely until there's a newer version available. |
| 15:41 |
JBoyer |
Ah. May have to remove more than that. I've seen things in such a state that the simplest fix was to wipe out all local storage for the Evergreen server. |
| 15:42 |
Bmagic |
reinstall everything.... will do |
| 15:45 |
JBoyer |
To be clear and for the logs: everything in Chrome related to that Eg server, nothing needs to be done on the server itself. |
| 15:45 |
berick |
the latest .exe on LP should work. |
| 15:46 |
|
khuckins joined #evergreen |
| 15:46 |
Bmagic |
I was using https://evergreen-ils.org/downloads/previews/Hatch_Windows_Installer.0.0.3.exe |
| 15:46 |
JBoyer |
berick, Oh, right. I missed that you uploaded the newer version. |
| 15:46 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1733692/comments/5 |
| 15:46 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] - Assigned to Bill Erickson (berick) |
| 15:46 |
JBoyer |
Bmagic, see bug 1733692 |
| 15:47 |
JBoyer |
oops. |
| 15:47 |
Bmagic |
right, I just remembered seeing that |
| 15:48 |
Bmagic |
JBoyer: that branch hasn't been merged right? |
| 15:49 |
JBoyer |
No. it's in working/Hatch and depends on another branch in working. |
| 15:49 |
berick |
Bmagic: it hasn't been merged, but the .exe was built on top of it, so it's OK |
| 15:49 |
berick |
ditto the Chrome web store build |
| 15:50 |
Bmagic |
http://git.evergreen-ils.org/?p=working/Hatch.git;a=tree;f=installer/windows;h=faa62c868027f9be04cf1b40ef1f912442685c7f;hb=refs/heads/user/berick/lp1733692-nsis-best-practices-signoff |
| 15:50 |
Bmagic |
? |
| 15:50 |
berick |
Bmagic: that's the one. |
| 15:51 |
Bmagic |
I'm not seeing an exe file |
| 15:51 |
berick |
Bmagic: see the LP comment link for the .exe |
| 15:51 |
JBoyer |
an attachment to the comment. |
| 15:53 |
|
rjackson_isl_ joined #evergreen |
| 15:55 |
|
mmorgan joined #evergreen |
| 15:56 |
Bmagic |
I see it now.... is the word a little more "published" somewhere else? And I missed it? |
| 16:04 |
berick |
Bmagic: not yet. i have a note in the other open bug about creating space on the downloads page, but nothing moving there yet. |
| 16:04 |
Bmagic |
Also, just so I am clear on this point. After the hatch piece is up and running and we are using it. Does it protect us from preference loss after browser cookie/cache reset? I am imagining the browser getting reset, then login and enable hatch again, and violla preferences restored? |
| 16:06 |
berick |
Bmagic: yep. that's essentially the stop-gap for moving the critical prefs to the server. |
| 16:06 |
Bmagic |
berick++ |
| 16:06 |
Bmagic |
hatch++ |
| 16:06 |
Bmagic |
web_based_staff_client++ |
| 16:07 |
Bmagic |
evergreen++ |
| 16:07 |
berick |
JBoyer++ # installer fixes |
| 16:07 |
Bmagic |
servers++ |
| 16:07 |
Bmagic |
java+- |
| 16:07 |
JBoyer |
scotch++ # NSIS is a combination of what and what now? |
| 16:13 |
berick |
@who needs a 12-year single malt |
| 16:13 |
pinesol_green |
dbwells needs a 12-year single malt. |
| 16:13 |
berick |
@eightball are you sure pinesol_green ? |
| 16:13 |
pinesol_green |
berick: You're kidding, right? |
| 16:14 |
dbwells |
The bot don't lie. |
| 16:15 |
|
JBoyer joined #evergreen |
| 16:16 |
Dyrcona |
:) |
| 17:07 |
Bmagic |
berick JBoyer - For those members who are using OSX, and have already conquered the local hatch component. Will this new branch introduce something new that they will have to recompile from? |
| 17:07 |
|
mmorgan left #evergreen |
| 17:08 |
berick |
Bmagic: you just have to change your native messaging hosts file |
| 17:08 |
berick |
to add the chrome store ID |
| 17:08 |
berick |
i mentioned it in the other bug, sec.. |
| 17:08 |
Bmagic |
oh |
| 17:09 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1708757/comments/3 |
| 17:09 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] - Assigned to Galen Charlton (gmc) |
| 17:09 |
berick |
change the path to suit |
| 17:11 |
berick |
find ~/ -name org.evergreen_ils.hatch.json |
| 17:12 |
Bmagic |
thanks! |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 22:02 |
|
jvwoolf joined #evergreen |
| 22:25 |
|
jvwoolf left #evergreen |
| 23:00 |
|
Stompro joined #evergreen |
| 23:55 |
|
beanjammin joined #evergreen |
