| Time |
Nick |
Message |
| 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:07 |
|
_bott_ joined #evergreen |
| 08:13 |
csharp |
On a stock ubuntu xenial machine I have run the "grunt all" step, and it creates the build directory within the source, but not in the installation tree |
| 08:13 |
csharp |
still can't seem to suss out what actually copies one to the other |
| 08:13 |
csharp |
@hate javascript |
| 08:13 |
pinesol_green |
csharp: The operation succeeded. csharp hates javascript. |
| 08:16 |
csharp |
alright, so far I have been able to perform these steps post-installation and have a working web client - is this supposed to be done before installing EG? |
| 08:17 |
csharp |
from everything I can see, the Gruntfile just copies everything into "build" in the current working directory and does nothing further |
| 08:19 |
csharp |
manually copying build from the source tree into the installed destination works |
| 08:20 |
csharp |
but shouldn't that happen automatically? |
| 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:18 |
csharp |
ok, so I guess the grunt all step *does* have to be done before installation |
| 09:18 |
csharp |
or at least doing configure/make/make install did put the files in the right place |
| 09:18 |
csharp |
I haven't needed to do that before - I've been able to run those after installing and it works fine |
| 09:19 |
csharp |
oh.... |
| 09:19 |
csharp |
oh |
| 09:19 |
csharp |
hmm |
| 09:19 |
* csharp |
slaps forehead |
| 09:20 |
csharp |
we build production from tarballs where that's already done |
| 09:20 |
csharp |
@monologue |
| 09:20 |
pinesol_green |
csharp: Your current monologue is at least 22 lines long. |
| 09:21 |
* csharp |
runs off to mark his bug invalid |
| 09:24 |
gmcharlt |
... |
| 09:24 |
gmcharlt |
good morning |
| 09:24 |
* gmcharlt |
hesitated only because I didn't want to break csharp's monologue ;) |
| 09:25 |
csharp |
gmcharlt++ |
| 09:28 |
kmlussier |
:) |
| 09:35 |
|
collum joined #evergreen |
| 09:54 |
Dyrcona |
csharp: Yes. When installing from git, the npm install and grunt all steps have to be done before make install. |
| 09:54 |
Dyrcona |
The README has you do them before ./configure, but any time before make install works. |
| 09:55 |
bwicksall |
Yeah, that step confused me at first |
| 09:56 |
Dyrcona |
Also, you have to do it after installing the developer prerequisites. |
| 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. |
| 10:44 |
Dyrcona |
csharp: I believe the problem you encountered yesterday was the tarball built by dbwells. He used wheezy with an apparently old version of Node.js installed. |
| 11:07 |
|
sandbergja joined #evergreen |
| 11:07 |
|
kmlussier joined #evergreen |
| 11:07 |
kmlussier |
comcast-- |
| 11:07 |
kmlussier |
Is today the day that we can move all those fixedinwebby LP bugs to Won't Fix? |
| 11:08 |
Dyrcona |
I say go for it. |
| 11:27 |
abowling |
can't find it in docs. anyone know how to overwrite the database using psql? |
| 11:28 |
abowling |
i know in pg_restore it's "-c" but that doesn't seem to work with psql |
| 11:28 |
berick |
abowling: as in, rebuild the schema? |
| 11:29 |
abowling |
berick: maybe? mostly just trying to wipe the data and re-ingest with a new set, but i'm not upset if the schema gets blown away. |
| 11:29 |
Dyrcona |
You can eg_db_config in support scripts for that. |
| 11:30 |
Dyrcona |
use, that is. |
| 11:30 |
Dyrcona |
If you have a dump, just restore it. |
| 11:30 |
Dyrcona |
What is your end goal? |
| 11:31 |
abowling |
Dyrcona: it's giving me sass that [object] already exists when i use eg_db_config |
| 11:31 |
|
jihpringle joined #evergreen |
| 11:31 |
abowling |
Dyrcona: blowing away the data and reloading it with a different set |
| 11:31 |
Dyrcona |
Is it the sample data or a dump? |
| 11:32 |
abowling |
it's a text dump |
| 11:32 |
abowling |
not a pg_dump |
| 11:32 |
Dyrcona |
eg_db_config with --create-database and --create-schema should work with the other appropriate options: --user, --password, --database, etc. |
| 11:33 |
Dyrcona |
You could also drop the database before if it keeps complaining. |
| 11:35 |
Dyrcona |
But, it has always* worked for me. *For certain values of always. |
| 11:35 |
abowling |
Dyrcona: i think i missed the eg_db_config step before the restore |
| 11:36 |
abowling |
Dyrcona++ |
| 11:37 |
Dyrcona |
If anyone wants to do it the hard way, there are scripts in Open-ILS/src/sql/Pg that will create the db and schema. I'm pretty sure that eg_db_config just runs those. |
| 11:40 |
mmorgan |
Anyone had reports of items being knocked off their call numbers after editing the call number in the unified editor? |
| 11:40 |
mmorgan |
This would be in 2.12. |
| 11:41 |
mmorgan |
The staff user retrieves an item in the unified editor, edits the call number label. Clicks Re-barcode/update... |
| 11:41 |
mmorgan |
But when retrieving the item again, it's uncataloged. |
| 11:42 |
jeff |
web or xul? |
| 11:42 |
mmorgan |
jeff: xul |
| 11:42 |
jeff |
i've seen xul throw a fixme on 2.11 in a scenario close to that, possibly only when there was a call number label conflict. i don't think it resulted in the item being UNCATALOGED / attached to -1 |
| 11:43 |
mmorgan |
Happens intermittently, but enough since our upgrade to 2.12 to suspect a problem. |
| 11:47 |
mmorgan |
2017-10-01 12:38:13 brick3 open-ils.cstore: [INFO:171791:osrf_application.c:1070:150687525017167117] CALL: open-ils.cstore open-ils.cstore.direct.asset.copy.update {"__c":"acp","__p":[2,null,"31867007299790","-1",null,56,"book","t",null,"2017-09-19T08:30:23-0400",null,321,"f",null,"f","0.00",null,null,"now",318,2,"t",10899128,2,1597,"t","30.00","f",5,"2017-09-19T08:30:23-0400","t",null,null,null,null,null,null,null,null, |
| 11:48 |
mmorgan |
The copy update is setting the call_number to -1 :-( |
| 11:51 |
mmorgan |
Here's the threadtrace that should have retrieved the call number for the item: |
| 11:51 |
mmorgan |
2017-10-01 12:36:41 brick0 open-ils.search: [INFO:14504:Application.pm:159:1506875555143939] CALL: open-ils.search open-ils.search.callnumber.fleshed.retrieve.authoritative 17936089 |
| 11:51 |
mmorgan |
2017-10-01 12:36:41 brick0 open-ils.search: [INFO:14504:Event.pm:64:1506875555143939] Loading events xml file /openils/var/data/ils_events.xml |
| 11:56 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Query to identify items with lost call numbers" (6 lines) at http://paste.evergreen-ils.org/851 |
| 11:56 |
|
jonadab joined #evergreen |
| 11:56 |
|
_adb joined #evergreen |
| 12:01 |
bshum |
mmorgan: Is this different than what you originally reported in https://bugs.launchpad.net/evergreen/+bug/1580242 ? |
| 12:01 |
pinesol_green |
Launchpad bug 1580242 in Evergreen "Users without UPDATE_VOLUME perm can orphan copies in the copy/volume editor" [Undecided,Confirmed] |
| 12:03 |
mmorgan |
Hmm. Forgot about that one :) |
| 12:04 |
bshum |
I only found it from using google search for "uncataloged" and "evergreen", my memory on this stuff gets fuzzy these days |
| 12:05 |
bshum |
I had this vague feeling I'd seen it before though, in another context |
| 12:05 |
mmorgan |
So far, the users definitely have permission to edit volumes and copies for the items I've examined. |
| 12:05 |
bshum |
Like not running autogen or something weird happened |
| 12:05 |
bshum |
And it borked the editor's actions |
| 12:05 |
bshum |
But I couldn't find a bug or discussion on those lines, so it's probably a figment of my imagination and there's something else afoot |
| 12:06 |
Dyrcona |
Do they have the UPDATE_VOLUMES permission at the appropriate depth? |
| 12:07 |
mmorgan |
Dyrcona: Yes, they do. |
| 12:07 |
Dyrcona |
If it's granted at branch and the volumes are owned by system, they don't technically have the permission. |
| 12:08 |
mmorgan |
Our volumes are all owned at the branch level, but users generally have permissions at the system level. |
| 12:10 |
* mmorgan |
would be interested if anyone else gets results from the query pasted above. |
| 12:14 |
|
khuckins joined #evergreen |
| 12:20 |
jeffdavis |
mmorgan: I get 101 rows for that query |
| 12:20 |
mmorgan |
jeffdavis++ |
| 12:21 |
* mmorgan |
gets 69, most have been since our upgrade in June |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:22 |
jeffdavis |
3/4 of the results here are since our upgrade to 2.12 |
| 12:25 |
|
kmlussier joined #evergreen |
| 12:26 |
* mmorgan |
wants to blame whatever is causing lp 1704369, but is leaning toward opening a separate bug. |
| 12:26 |
pinesol_green |
Launchpad bug 1704369 in snapd (Ubuntu) "package snapd 2.26.1~14.04 failed to install/upgrade: subprocess new pre-removal script returned error exit status 5" [Undecided,Confirmed] https://launchpad.net/bugs/1704369 |
| 12:26 |
mmorgan |
Oops, not that one. |
| 12:27 |
mmorgan |
lp 1704396 |
| 12:27 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,New] https://launchpad.net/bugs/1704396 |
| 12:30 |
Dyrcona |
I get 22 rows, but some of them are duplicates, i.e. the same copy id appearing more than once. I think you want distinct on cp.id and not just distinct. |
| 12:30 |
Dyrcona |
A good number of the copies are deleted. |
| 12:31 |
Dyrcona |
We also truncate the history tables rather frequently. |
| 12:33 |
Dyrcona |
Finally, we're still on 2.10.7, FWIW. |
| 12:34 |
mmorgan |
Dyrcona: Good to know. That makes me think it's definitely a 2.12 thing, we skipped 2.10. |
| 12:36 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "mmorgan: "Improved" query" (7 lines) at http://paste.evergreen-ils.org/852 |
| 12:36 |
Dyrcona |
That gives me 5 rows. |
| 12:37 |
Dyrcona |
I limited to not deleted copies and did the distinct on the cp.id. I also added the cp.call_number to the output. |
| 12:38 |
gmcharlt |
in case there are any who rely purely on muscle memory when using https://evergreen-ils.org/opensrf-downloads/ ... the order of columns is now switched so that it runs from latest to oldest |
| 12:38 |
gmcharlt |
making it match the Evergreen downloads page |
| 12:39 |
kmlussier |
gmcharlt++ |
| 12:39 |
mmorgan |
Dyrcona: Thanks, I get 12, which are the items needing fixing, but to get an idea of the scope of the problem, I'd want to include deleted. |
| 12:41 |
Dyrcona |
mmorgan: That makes sense. |
| 12:55 |
|
kmlussier joined #evergreen |
| 12:56 |
* kmlussier |
gives up on comcast and switches to data. |
| 12:56 |
kmlussier |
comcast-- |
| 12:56 |
kmlussier |
@karma comcast |
| 12:56 |
pinesol_green |
kmlussier: Karma for "comcast" has been increased 0 times and decreased 18 times for a total karma of -18. |
| 12:56 |
rhamby_ |
comcast-- |
| 12:57 |
|
b_bonner joined #evergreen |
| 12:58 |
|
khuckins_ joined #evergreen |
| 12:58 |
kmlussier |
Also, facebook-- |
| 12:58 |
kmlussier |
I'm tired of getting notifications telling me how I can boost posts from the Evergreen page. |
| 13:00 |
|
krvmga joined #evergreen |
| 13:07 |
rhamby_ |
kmlussier: you and I both |
| 13:24 |
jeff |
kmlussier, rhamby_: Find one of the notifications in question in the desktop web interface, click the associated ellipse menu, try "Turn off notifications about tips for this page" |
| 13:26 |
kmlussier |
jeff++ |
| 13:26 |
kmlussier |
I feel like I've tried finding a way to turn them off before, but I couldn't find it. |
| 13:27 |
jeff |
Also, you can probably fine tune other notifications at https://www.facebook.com/EvergreenILS/settings/?tab=notifications -- but no, the "tips" notifications aren't listed there. |
| 13:28 |
jeff |
And under your personal notification settings there's a "Pages you manage" section where you can set an entire page to On, Off, or Digest. |
| 13:33 |
kmlussier |
jeff: Yeah, I think that's where I went hunting before. |
| 13:57 |
gmcharlt |
https://evergreen-ils.org/evergreen-3-0-0-released/ |
| 13:58 |
jeff |
gmcharlt++ |
| 13:59 |
abneiman |
gmcharlt++ |
| 13:59 |
kmlussier |
Woo hoo! gmcharlt++ |
| 14:01 |
berick |
gmcharlt++ |
| 14:01 |
|
abowling left #evergreen |
| 14:07 |
akilsdonk |
gmcharlt++ |
| 14:08 |
csharp |
gmcharlt++ |
| 14:09 |
kmlussier |
I feel like we should all be opening a bottle of champagne (or your favorite celebratory drink) at the same time and toasting one another. |
| 14:09 |
gmcharlt |
all_you_all++ |
| 14:10 |
dbwells |
gmcharlt++ |
| 14:11 |
abneiman |
kmlussier, I'm cheers-ing everyone with my mug of tea, does that count? :) |
| 14:11 |
kmlussier |
abneiman: Tea works! |
| 14:11 |
berick |
at it turns out i was already halfway through a bottle of mad dog 20/20, so.. cheers! |
| 14:12 |
kmlussier |
Wow. berick's work days are far more interesting than mine. |
| 14:13 |
|
abowling joined #evergreen |
| 14:14 |
abneiman |
https://xkcd.com/323/ |
| 14:18 |
bshum |
abneiman: I think I've gotten some of the best bug fixes ever from post-pub-crawl hacking sessions |
| 14:19 |
bshum |
So that illustration might be pretty accurate, heh |
| 14:23 |
bshum |
gmcharlt: Just FYI, now that rel_3_0 exists, I'll go ahead and setup another LP translation target for that series like we did with rel_2_12, and hopefully that'll work out okay too. I don't expect master to drift so fast along, but you never know :) |
| 14:23 |
bshum |
I'll let you know when that's all done |
| 14:23 |
gmcharlt |
bshum++ |
| 14:23 |
abneiman |
bshum: I do seem to recall that the conference dev meeting seems to coincide with pub crawl fairly often |
| 14:32 |
csharp |
Dyrcona recently spoke about "technical debt" - been thinking a lot about that while I comb through years-old PINES customizations we've been dragging along for the last 4-5 upgrades |
| 14:32 |
csharp |
terran identified about 120 commits we can leave behind ;-) |
| 14:33 |
csharp |
I'm about to dive into my share of the ~300 total |
| 14:42 |
gmcharlt |
courtesy of rhamby_, a 3.0.0 XUL client for OS X is now available from the downloads page |
| 14:42 |
gmcharlt |
rhamby++ |
| 14:46 |
kmlussier |
rhamby++ |
| 14:49 |
* mmorgan |
can't resist |
| 14:49 |
mmorgan |
https://www.youtube.com/watch?v=xOrgLj9lOwk&feature=youtu.be&t=94 |
| 14:50 |
gmcharlt |
heh |
| 14:57 |
kmlussier |
mmorgan++ |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:17 |
|
frank__ joined #evergreen |
| 15:19 |
frank__ |
Hi all, Could someone helpme? It looks like while the cronjobs are been executed, something hapend with the open-ils.search and it stoped, Is there any kind of script to restart the services after run the reshelving_complete.srfsh script? |
| 15:23 |
Dyrcona |
frank__: osrf_control is the script you need. |
| 15:23 |
Dyrcona |
If I understand correctly, that is. |
| 15:25 |
frank__ |
yes, but I can run it after execute the reshelving_complete.srfsh cron task? |
| 15:26 |
Dyrcona |
frank__: Depends on the options. If you restart all services, the reshelving complete will likely fail. |
| 15:26 |
Dyrcona |
If all you want is to restart search, then this ought to do: osrf_control --restart --service open-ils.search |
| 15:27 |
|
mmorgan joined #evergreen |
| 15:27 |
frank__ |
excelent Dyrcona, that is what I was looking for |
| 15:27 |
frank__ |
thanks |
| 15:27 |
Dyrcona |
yw |
| 15:34 |
|
acautley joined #evergreen |
| 15:43 |
|
Wietse_ joined #evergreen |
| 15:44 |
Wietse_ |
hi |
| 15:46 |
|
acautley joined #evergreen |
| 15:47 |
kmlussier |
Wietse_: Hi! |
| 15:48 |
Wietse_ |
hi kmlussier, good to see that at least someone's awake :-) |
| 15:52 |
bshum |
I'm sure others are awake. Well... probably. |
| 15:54 |
Wietse_ |
what brings ppl here ben? |
| 15:56 |
bshum |
Wietse_: This channel is for discussion by developers, users, and other interested parties about the Evergreen open source integrated library system software. |
| 15:56 |
bshum |
There's a link and some other details in the channel topic, of course. |
| 16:02 |
abowling |
Dyrcona: sorry to pester. when i reload the data and restart osrf, i keep getting "OpenSRF::Transport /usr/local/share/perl/5.18.2/OpenSRF/Transport.pm:83 Session Error: router private.localhost/open-ils.cstore IS NOT CONNECTED TO THE NETWORK!!!" when i run autogen.sh. autogen runs just fine before i reload the data. (i.e. the passwords are correct) any ideas? |
| 16:03 |
Dyrcona |
abowling: autogen.sh can't run fine if cstore is not connected to the network. |
| 16:03 |
Dyrcona |
Were the services running when you did the database restore? |
| 16:03 |
|
eady joined #evergreen |
| 16:04 |
Dyrcona |
I guess a better question might be, did you change the opensrf.xml file? |
| 16:05 |
abowling |
Dyrcona: they were, but it seems an opensrf restart was in order. i.e. to your last question, perhaps something got changed in the opensrf.xml file? |
| 16:05 |
Dyrcona |
eg_db_config will change the opensrf.xml file if you specify --update-config. |
| 16:06 |
|
kmlussier joined #evergreen |
| 16:06 |
Dyrcona |
I'd recommend starting services with --force-clean-process, then doing osrf_control --diagnostic to see if any services are not running. |
| 16:07 |
Dyrcona |
If they're not, you can check the logs for messages. |
| 16:36 |
pinesol_green |
[evergreen|Galen Charlton] correct the acknowledgement of Consortium of Ohio Libraries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=98652f2> |
| 16:42 |
|
Jillianne joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 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 |
| 20:46 |
|
_adb left #evergreen |
| 20:46 |
|
_adb joined #evergreen |
