Time |
Nick |
Message |
00:08 |
|
sarabee joined #evergreen |
05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:42 |
|
ericar joined #evergreen |
07:51 |
|
graced joined #evergreen |
07:55 |
|
jboyer-isl joined #evergreen |
07:56 |
|
rjackson_isl joined #evergreen |
08:09 |
|
Newziky joined #evergreen |
08:11 |
|
collum joined #evergreen |
08:30 |
|
akilsdonk joined #evergreen |
08:32 |
|
mrpeters joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
08:40 |
|
Shae joined #evergreen |
08:45 |
|
Dyrcona joined #evergreen |
08:56 |
Dyrcona |
And, today we build a new development VM and attempt to install the browser-based staff client. |
08:56 |
dkyle1 |
`history |
08:58 |
mrpeters |
morning guys -- i've talked to a few of you about being able to obtain information about the staff member that created a record and many have asked "why?" -- I got an answer, and I think it's a pretty fair one. |
09:01 |
Dyrcona |
AFAIK, that information is only kept for bibliographic records. |
09:02 |
mrpeters |
A library is finding that about 5% of their new patron records are being entered incorrectly (errors in permissions, typos, etc.) and they are trying to identify whether or not this is isolated to 1 or 2 staff members, or spread amongst all staff. We have creator/editor information for bibs, I think for similar reasons, so I'm going to file a wishlist bug to modify the actor.usr schema to include this information. |
09:02 |
mrpeters |
I should clarify -- i know that is not the ONLY reason that info is kept for bibs, but I'm sure it is one of them |
09:04 |
mrpeters |
as for how to deal with upgrades, i would propose setting the global superuser (au.id=1) as the creator for all records when the upgrade is applied, and then going forward, record the actor.usr.id of the creating staff user |
09:04 |
Dyrcona |
Yeah, put it in the bug. Doubt it would go in soon, though. |
09:05 |
|
Newziky joined #evergreen |
09:05 |
mrpeters |
yeah, probably not, and they are ok with that -- they realize it was just probably one of those things nobody ever brought up, but as things have evolved, it's become something that would be handy in the future |
09:13 |
bshum |
Drycona: When you say I'm missing a sudo, what are you working from? |
09:19 |
|
maryj joined #evergreen |
09:20 |
Dyrcona |
http://evergreen-ils.org/~bshum/Evergreen-README.html#_optional_extra_steps_for_browser_based_staff_client |
09:20 |
Dyrcona |
bshum: I was gonna ask you if there is a git branch for that. |
09:21 |
bshum |
Ah, that thing. Okay, I think that there might be some lingering issue on that step. |
09:21 |
Dyrcona |
Are those the best instructions available? |
09:21 |
bshum |
There used to be a git branch somewhere for that, though I'm not 100% where right now. |
09:22 |
bshum |
More or less, I based them on the README file in the webclient directory. |
09:22 |
bshum |
I'll dig up the branch for you in a bit. |
09:22 |
|
yboston joined #evergreen |
09:24 |
bshum |
Hmm, I thought I made one but now I can't seem to locate it. I'll make a new branch for you. |
09:26 |
Dyrcona |
One thing that isn't answered by any of the docs is do you do this before installing the rest of Evergreen, or can it be done after? |
09:27 |
bshum |
It's supposed to be before you compile |
09:27 |
bshum |
Otherwise the web client pages aren't in place before you do the configure/make steps |
09:28 |
bshum |
And it doesn't automatically get moved into the installed places during make install |
09:28 |
Dyrcona |
OK. That might explain my problems yesterday. |
09:28 |
Dyrcona |
I'll give it another shot. |
09:29 |
bshum |
Yeah, the position of the instruction in my doc is intentionally if not explicitly defined. |
09:29 |
Dyrcona |
My VM is almost done being created. |
09:29 |
Dyrcona |
Oh. It finished 6 minutes ago. Another window was covering the prompt in the terminal. ;) |
09:30 |
bshum |
You might be right about that npm install needing a sudo on it. I vaguely recall doing something similar at one point. |
09:30 |
bshum |
Though I'm unsure if maybe there were weird permission issue or something. |
09:31 |
Dyrcona |
Well, I got several errors about stuff not being installed/not able to be opened without the sudo. |
09:31 |
Dyrcona |
With sudo, it just worked. |
09:31 |
bshum |
You testing with Ubuntu 12.04 or 14.04? |
09:37 |
bshum |
Alright, so I can't find the branch anywhere, so I must have just been modifying a local copy Evergreen-README on lupin directly. We can diff those changes against master and get a branch started though. |
09:42 |
|
RoganH joined #evergreen |
09:54 |
Dyrcona |
14.04 |
09:55 |
bshum |
Dyrcona: I pushed a collab branch with the changes I started to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/README-webclient |
10:00 |
|
mllewellyn joined #evergreen |
10:01 |
|
tsbere_ joined #evergreen |
10:05 |
Dyrcona |
If I'm using OpenSRF from master is there anything that I need to do for the browser-based staff client in OpenSRF? |
10:06 |
bshum |
Dyrcona: I believe the websocket steps were incorporated into the README for OpenSRF master/2.4 series |
10:06 |
bshum |
So you should be fine there as long as that's all setup. |
10:07 |
Dyrcona |
Do you need websockets if I'm not using hatch? I assume yes. |
10:07 |
bshum |
gmcharlt was going to add some samples later on for proxy to get it to run websockets off more traditional ports, or something. |
10:07 |
bshum |
Yes, you need websockets configured or else you won't even be able to log into it. |
10:07 |
Dyrcona |
OK. Thanks. |
10:31 |
|
Stompro joined #evergreen |
10:59 |
|
Stompro joined #evergreen |
11:10 |
|
Shirleyh joined #evergreen |
11:18 |
|
Shirleyh_ joined #evergreen |
11:30 |
|
jjk joined #evergreen |
11:32 |
|
Shirleyh joined #evergreen |
11:42 |
jjk |
Good morning |
11:42 |
jeff |
jjk: good morning! |
11:43 |
jjk |
I'm attempting to upgrade an older 2.3 install to the current version but have run into issues with the database schema updates. I'm hoping some folks here can point me in the right direction. |
11:45 |
jjk |
I have a test database that started at 2.3.5 and I've successfully run the schema updates all the way up to 2.3.12. |
11:47 |
jjk |
When trying to upgrade the schema using 2.3-2.4.0-upgrade-db.sql I quickly receive the following errors: |
11:47 |
jjk |
psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:96: NOTICE: extension "tsearch2" already exists, skipping |
11:47 |
jjk |
psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:98: ERROR: cannot drop extension tsearch2 because other objects depend on it |
11:48 |
jjk |
I've not found much in the way of similar issues. |
11:53 |
bshum |
jjk: So that sounds like you have something custom in your database that relies on tsearch2 extension |
11:54 |
bshum |
I found something like that when we upgraded as well, some locally created views for reporting had used that extension and needed to be rewritten |
11:55 |
* bshum |
upgraded forever ago and doesn't remember how he ultimately identified all the things that used that extension. |
11:57 |
jjk |
bshum: Thanks. I'll look at the reports. |
11:58 |
|
TaraC joined #evergreen |
12:01 |
bshum |
jjk: Out of curiosity, what version of PostgreSQL are you using for your tests? |
12:01 |
bshum |
(i.e. did you also test upgrading your postgresql installation to newer versions 9.1+) |
12:02 |
bshum |
And you might find it interesting |
12:02 |
bshum |
To try the drop extension directly |
12:02 |
bshum |
And see if it spits back what is still depending on it |
12:03 |
bshum |
Hmm |
12:03 |
bshum |
csharp: Did we archive the old evergreen-admin mailing list? |
12:04 |
bshum |
csharp: Nevermind, found what I was looking for |
12:04 |
bshum |
jjk: You might see some value in discussion from this mailing list entry: http://list.evergreen-ils.org/pipermail/evergreen-admin/2014-May/000086.html |
12:05 |
jjk |
bshum: I'm running 9.1 on Debian, specifically 9.1.14-0+deb7u1 |
12:05 |
bshum |
jjk: Based on what they say there, I would check to make sure the search_path is set right, and then see if there's any "DETAIL" that comes up after the "ERROR" part when you try to drop the extension. |
12:05 |
bshum |
~search_path |
12:05 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
12:08 |
jjk |
Thanks, I'll look these. |
12:08 |
bshum |
jjk: As you work upwards in versions, I want to point you towards http://docs.evergreen-ils.org/2.7/_upgrade_the_evergreen_database_schema.html |
12:08 |
bshum |
Which describes the path you'll want from 2.5+ |
12:09 |
bshum |
Specifically, you might want to skip over certain numbered scripts to avoid conflicts in the upgrade scripts. |
12:09 |
bshum |
Due to x.y.z releases coming out at different times. |
12:10 |
bshum |
i.e. skip 2.5.3-2.5.4 (if you're going to go past 2.5 towards 2.6), etc. |
12:10 |
bshum |
You're not there yet. But you'll get there, sometime. And that can be a weird little stumbler. |
12:10 |
jjk |
Does this apply for just 2.5 or 2.6 and 2.7 branches too? |
12:10 |
* jeff |
somewhat idly wonders if he should expect to be able to make it from gate to shuttle in time to make the noon departure, or if he should plan on the 2:30 |
12:11 |
bshum |
jjk: It applies to everything. I'm not sure how far along 2.3 went after 2.4 came along, etc. |
12:11 |
bshum |
So you might find stuff in later version upgrade scripts that have already happened previously and might not successfully apply or whatnots. |
12:12 |
bshum |
So you'll want to follow the path as best as you can if you want to cut down on the amount of manual intervention you'll need. |
12:12 |
jeff |
hah! wondered why there were two calendar entries for my flights. one i created by hand, the other google created automatically. |
12:12 |
bshum |
I'm unsure how comfortable you are with SQL stuffs. |
12:12 |
bshum |
But if you love SQL, you'll enjoy it. Or learn to enjoy it? :\ |
12:13 |
csharp |
jeff: you might ask Buzzy or Brent about it - I'm in a similar spot with the 5:00 (final) shuttle |
12:13 |
csharp |
they made it sound like they'd be able to hold it for me |
12:13 |
jeff |
csharp: youch -- 9 minutes |
12:13 |
csharp |
(arriving at 4:51 pm) |
12:13 |
csharp |
yeah |
12:14 |
* csharp |
doesn't have a very good backup plan :-/ |
12:14 |
Dyrcona |
csharp: Tuesday? You hang around until midnight when bshum and I get there. |
12:14 |
csharp |
ha! |
12:15 |
csharp |
if you see me asleep on a couch, please wake me up and drag me along ;-) |
12:15 |
bshum |
Heh |
12:16 |
jjk |
bshum: clear as mud! It's not clear to me what is meant by 'run all incremental scripts' if for example 2.4.0-2.4.1 is not an incremental script. |
12:17 |
bshum |
jjk: I think that's exactly what it means. (And that the doc writer got lazy and meant to say, run 2.4.0-2.4.1, 2.4.1-2.4.2, 2.4.2-2.4.3 |
12:17 |
bshum |
Which is three incremental scripts |
12:17 |
bshum |
*three separate |
12:18 |
kmlussier |
csharp: I'm arriving at 5:15, just after the last shuttle. I've hitched a ride with gmcharlt later in the night. I don't know if he has more spots, but you might want to check. |
12:18 |
jjk |
bshum: That's what I thought. What is meant by 'additional scripts'? |
12:18 |
Dyrcona |
Speaking of upgrade scripts, I have plans to make db_upgrade.pl smarter. |
12:18 |
jeff |
The interesting one will be the return for me -- looks like I'll have 5 hours or so to burn. |
12:18 |
* kmlussier |
has noticed that csharp and I have very similar flight times next week. |
12:19 |
|
wjr joined #evergreen |
12:19 |
Dyrcona |
db_upgrade.pl is available here if you're scratching your head: http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=tree;f=scripts;h=05bddb674e4d91760392fc31333ef1104a055648;hb=5ec82e38e8465bafc56fdb19961b1b78c49f5075 |
12:20 |
bshum |
jjk: "additional scripts?" |
12:20 |
bshum |
I'm not sure I know what you mean by that. |
12:20 |
jjk |
Dyrcona: Is that directed at me? I looked at db_upgrade.pl breifly but didn't see any mention in the docs and so chickened out. |
12:21 |
jjk |
bshum: The docs read: 'Note that you do not want to run additional 2.5 scripts to upgrade to the newest version of 2.5' |
12:21 |
bshum |
jjk: Right... so... |
12:21 |
Dyrcona |
jjk: No, it's directed in general. db_upgrade.pl won't help you right now, but the changes I have in mind might help you in the future. |
12:21 |
jjk |
got it. |
12:21 |
bshum |
jjk: Gotcha now. So, let's say there were other scripts like, 2.5.3-2.5.4, 2.5.4-2.5.5 |
12:22 |
bshum |
If you ran those, then the script for 2.5.3-2.6.0 (major upgrade) may not (read, *will not*) function seamlessly. |
12:22 |
bshum |
Cause your database would be at the wrong state |
12:22 |
bshum |
And you would end up having to edit the major upgrade script to remove stuff that might have already been applied during one of the other incremental scripts. |
12:23 |
bshum |
Things of that nature. |
12:25 |
jjk |
I think I understand. Once I get over the 2.3-2.4 hurdle I'll compose a list of sql scripts that I believe should be run. Can I post the URL to that file here and get a sanity check? |
12:26 |
csharp |
kmlussier: thanks - I'll check |
12:26 |
bshum |
jjk: You can always ask, but I don't promise I'll personally answer if I'm not around later. (though I'm sure others might chime in, if you're patient) |
12:26 |
bshum |
:) |
12:27 |
bshum |
Upgrading from older versions can be interesting. And that's where you discover all the quirks. |
12:27 |
bshum |
jjk: Out of curiousity, who are you upgrading? |
12:28 |
csharp |
kmlussier: looks like gmcharlt's car is full - I'll try to get some assurance that the 5:00 shuttle doesn't leave without me ;-) |
12:29 |
|
kmlussier joined #evergreen |
12:29 |
|
mceraso joined #evergreen |
12:29 |
|
bshum joined #evergreen |
12:29 |
bshum |
kmlussier: Sorry about that, I think my linode's quasslcore just updated... |
12:29 |
bshum |
And bumped us all around a bit |
12:30 |
Dyrcona |
Looks like it. |
12:30 |
kmlussier |
bshum: Oh, that was you? I thought our wireless went out. |
12:30 |
bshum |
Yeah I was doing an update and didn't notice it said "quassalcore" amongst the packages being updated. |
12:30 |
bshum |
Sorry for the interruption there. |
12:30 |
csharp |
@blame updates |
12:30 |
pinesol_green |
csharp: updates caused the white screen of death! |
12:30 |
bshum |
Carry on |
12:30 |
|
jihpringle joined #evergreen |
12:31 |
jboyer-isl |
bshum: That's almost as fun as doing a remote Windows Update and noticing the network drivers are in there. It was a very tense couple of minutes before the remote desktop was available again. :D |
12:32 |
bshum |
jboyer-isl: I've been there before... scary stuff. |
12:32 |
bshum |
I feel that way every time I have to change the IP address for a system. |
12:32 |
bshum |
Where are you and why aren't you online yet? |
12:33 |
csharp |
jboyer-isl: whenever I hear the words "remote Windows Update", I'm reminded of this: http://thenextweb.com/shareables/2014/05/16/emory-university-server-accidentally-sends-reformat-request-windows-pcs-including/ |
12:34 |
jeff |
we live in a weird world. |
12:34 |
jeff |
i just searched google for "quassel sasl" |
12:35 |
* csharp |
watches his Helpdesk ticket queue grow as he tries to catch up on paperwork neglected during last week's PINES meetings |
12:44 |
bshum |
berick: I'm going through master's server_upgrade doc and getting it updated to reflect path up towards 2.8.1 |
12:44 |
kmlussier |
OK, the group working on Evergreen outreach met today and talked about adding a contact email to the handouts we'll be distributing at conferences. I know we already have a feedbackevergreen-ils.org address, but we were thinking infoevergreen-ils.org might make more sense for the people we would be reaching at conferences. |
12:44 |
kmlussier |
Is that something we could have set up? |
12:44 |
bshum |
I'll push that out in a bit and we can get the docs server rebuilt overnight to put up a proper link for 2.8 upgrade path later tomorrow. |
12:45 |
* kmlussier |
isn't sure if that's a csharp request or a gmcharlt request. |
12:48 |
gmcharlt |
kmlussier: looking |
12:49 |
|
jeff_ joined #evergreen |
12:50 |
* jeff_ |
waves |
12:50 |
gmcharlt |
kmlussier: there's no info@ reflector, but I can easily create it given a set of email addresses |
12:51 |
gmcharlt |
or it could be mapped to the set underlying list as feedback@ |
12:52 |
kmlussier |
Awesome! I think I like the idea of mapping it with the feedback address because it seems like they serve similar purposes. It really is just a matter of semantics. |
12:52 |
kmlussier |
Who is on the feedback address? |
12:52 |
* kmlussier |
waves to jeff_ |
12:53 |
csharp |
kmlussier: me, dbs and phasefx |
12:53 |
csharp |
it's unfortunately 99.4% spam |
12:53 |
csharp |
which reminds me |
12:53 |
kmlussier |
ugh |
12:53 |
kmlussier |
@hate spam |
12:53 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates spam. |
12:53 |
csharp |
note to self: set up spam filtering somewhere |
12:54 |
gmcharlt |
csharp: kmlussier: also eeevil |
12:54 |
csharp |
oh? good |
12:55 |
csharp |
kmlussier: the other 0.6% are questions that would be better asked on Open-ILS-General (or even of specific sites' Helpdesks) |
12:55 |
gmcharlt |
coins, sides, two |
12:56 |
gmcharlt |
kmlussier: in fact, there'd be an argument to be made that info@ should be publicized *only* on printed materials |
12:56 |
kmlussier |
csharp: Yeah, I think I heard that was the case. But if we were distributing the address in handouts at conference, it might get more use. |
12:56 |
kmlussier |
gmcharlt: So that we could have an informational address that doesn't receive so much spam? |
12:56 |
gmcharlt |
kmlussier: right |
12:57 |
kmlussier |
gmcharlt: In that case, it might be better to separate it out from the feedback address, right? |
12:57 |
csharp |
I think filtering is the only reasonable approach to the spam issue |
12:57 |
csharp |
any address that is public anywhere is subject to that |
12:57 |
gmcharlt |
and conveniently, open-ils-general already has filtering :) |
12:57 |
csharp |
if'n y'all want, I can get awitter on the case ;-) |
12:58 |
csharp |
he's a seasoned veteran of such things |
12:58 |
Dyrcona |
Even ones that aren't public, you should see all of the unknown address bounces in my logs. :) |
12:58 |
jeff |
info@ is going to get spam even if it's only on printed materials. |
12:58 |
kmlussier |
Good point |
12:58 |
csharp |
I'm pretty sure list.evergreen-ils.org has filtering on it too |
13:01 |
pinesol_green |
[evergreen|Ben Shum] Docs: Change references to release 2.8.1 for server upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dedc2dc> |
13:05 |
kmlussier |
csharp: Sure, why not? Even without the info question, it sounds like it would benefit the people on feedback. :) |
13:10 |
berick |
bshum++ # i've never actually looked at that doc |
13:10 |
bshum |
berick: I started watching it after Stompro gave us all these patches for it. And now I just try to keep it going. |
13:11 |
bshum |
I'm editing up the various pages on the wordpress site too, to move things onto the "more staff clients" downloads page, and get rid of all the 2.5 stuff and put it onto the code museum page. |
13:11 |
bshum |
Lots of editing. |
13:14 |
bshum |
I suppose I should copy all the 2.6 stuff to the museum too in preparation for that going away. |
13:14 |
bshum |
Since I'm editing anyways |
13:30 |
bshum |
I'm kicking OpenSRF 2.2 off the screen from http://evergreen-ils.org/opensrf-downloads/ No currently supported Evergreen target it, so we can safely remove it. |
13:41 |
Stompro |
bshum++, I was just thinking of working on the upgrade docs for 2.8, thanks. |
13:42 |
bshum |
I'm spinning up a Jessie image to take a look over all the stuff you said was broken |
13:45 |
Stompro |
Thanks, let me know if you see any issues with the patches that you would like me to look at. |
13:46 |
bshum |
Stompro++ # I'm sure they'll help |
13:56 |
|
buzzy joined #evergreen |
14:08 |
gmcharlt |
kmlussier: ok, info@ now exists, is directed towards feedback@, and has better filtering |
14:08 |
gmcharlt |
also, you're now subscribed to it |
14:08 |
kmlussier |
Wow! That was fast. Thanks gmcharlt! |
14:08 |
kmlussier |
gmcharlt++ |
14:19 |
jeffdavis |
What's the status of NCIPServer? |
14:22 |
kmlussier |
jeffdavis: We have it in testing now to use with AutoGraphics. |
14:22 |
jeffdavis |
kmlussier: that's excellent, thank you |
14:24 |
Dyrcona |
jeffdavis: You can't use the master branch with Evergreen at the moment. |
14:24 |
Dyrcona |
rangi or someone (me?) has to do some integration. I changed the interfaces a good bit. |
14:25 |
kmlussier |
Dyrcona: I was just looking for that. Is the Evergreen side of it available somewhere else? |
14:25 |
Dyrcona |
It's in the better_abstraction working branch. |
14:26 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/NCIPServer.git;a=shortlog;h=refs/heads/user/dyrcona/better_abstraction |
14:27 |
Dyrcona |
magnus over in #koha on oftc.net has apparently made his own branch for more internationalization or something to do with how NCIP is being used in Norway. |
14:27 |
Dyrcona |
his nick is magnuse |
14:27 |
jeffdavis |
FWIW we're not planning to use it at the moment, I'm just anticipating some questions about third-party integration with EG. |
14:27 |
bshum |
Oy, the new ejabberd.yml config file layout is freaking me out. |
14:28 |
Dyrcona |
jeffdavis: Lovely thing about NCIP, you need a new implementation for just about every vendor. |
14:28 |
bshum |
Screwing with muscle memory for my OpenSRF installs. |
14:29 |
Dyrcona |
And sometimes different products from the same vendor. |
14:31 |
|
kitteh_ joined #evergreen |
14:31 |
jeffdavis |
Dyrcona: ah yes, "standards" that are actually their own special case of https://xkcd.com/927/ -- good times! |
14:31 |
bshum |
Haha, the hover is funny |
14:32 |
bshum |
Stompro++ # tested the change for OpenSRF instructions for Ejabberd for Debian Jessie and they look good. I'll sign and push that on for a future OpenSRF 2.4.1 release. |
14:33 |
Dyrcona |
Well, I don't even really consider NCIP to be a standard myself. It's list of features that you can implement. |
14:34 |
Dyrcona |
And every vendor seems to pick their own way to do things, and too many messages are similar, but different. |
14:34 |
Dyrcona |
So, yeah, we need an actual standard. |
14:35 |
Dyrcona |
Where there's one way to do a given task. |
14:35 |
bshum |
Stompro: Well, after I fix up some asciidoc weirdness in the formatting. |
14:35 |
Dyrcona |
If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe. |
14:38 |
jeffdavis |
heh |
14:38 |
jeffdavis |
Someone should add that to pinesol_green's quote repository. |
14:43 |
berick |
@quote add "<Dyrcona> If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe." |
14:43 |
pinesol_green |
berick: The operation succeeded. Quote #114 added. |
14:43 |
berick |
@quote get 114 |
14:43 |
pinesol_green |
berick: Quote #114: "<Dyrcona> If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe." (added by berick at 02:43 PM, May 04, 2015) |
14:43 |
berick |
can't believe that worked the first time |
14:46 |
jeffdavis |
berick++ |
14:46 |
bshum |
Bleh, asciidoc syntax can be annoying when you don't use it regularly :( |
14:47 |
Dyrcona |
heh to berick and to bshum. :) |
14:47 |
* Dyrcona |
wonders if asciidoc really has syntax. :) |
15:21 |
|
dkyle1 left #evergreen |
15:22 |
* bshum |
has wrestled with asciidoc and is losing :( |
15:24 |
Bmagic |
if I wanted to manually change a password in the database, I need to sha1? md5? update actor.usr set passwd=digest('password', 'sha1') where id=926 ?? |
15:24 |
tsbere |
Bmagic: None of the above? |
15:24 |
bshum |
Bmagic: Nah, there's a DB function that'll do that for you |
15:24 |
tsbere |
Bmagic: set passwd = 'new password' ;) |
15:24 |
Bmagic |
oh, lol |
15:24 |
bshum |
Bmagic: You can just do UPDATE actor.usr SET passwd = 'something' WHERE id = sillyuser; |
15:24 |
Stompro |
bshum, it took me a while to add the second example to the docs also... I thought I compiled it and tested how it looked, did you not like how it looked or did it break when you tried it. |
15:24 |
bshum |
and the function will hash it out for you |
15:25 |
Bmagic |
great! that worked |
15:25 |
bshum |
Stompro: I was just trying to see if I could make it more consistent looking with the rest of the styling. |
15:25 |
bshum |
Stompro: Your approach isn't wrong, just different. |
15:25 |
bshum |
For myself, I might put the OS ahead of the Ejabberd version in the subheadings |
15:26 |
bshum |
So like "(Debian Jessie) Ejabberd 13.x and 14.x" instead of "Ejabberd 13.x and 14.x, Debian Jessie" |
15:26 |
bshum |
That seems to be how everything else is done. |
15:26 |
bshum |
Then when I tried to make it the bold blue text with the .inlead, then I got weird generation errors with the bullets under each section. |
15:27 |
bshum |
Still playing with it more |
15:29 |
Stompro |
I wasn't quite sure with all the numbered steps how to best add in the different options, while continuing the numbering after those steps. I think I remember that trying to use ".section" headings broke all the numbering afterwards. |
15:29 |
bshum |
Yep, that's what I'm seeing too. |
15:29 |
bshum |
I'm wondering next if we have to number it at all, and maybe we can get away with bullets instead. |
15:33 |
Stompro |
I don't have a strong opinion on it, but don't the docs generally use numbed steps for most things. |
15:34 |
Dyrcona |
Can you get "a" and "b" on the numbers? like 4.1a 4.1b |
15:34 |
Dyrcona |
Or maybe something like X.Y option A X.Y option B |
15:35 |
Dyrcona |
But, seriously if there are options, don't go past C, 'cause people just get confused at that point. |
15:44 |
mmorgan |
I'm puzzling over some strange catalog searches in our logs. Wonder if anyone has seen searches similar to the following ... |
15:44 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Curious catalog search" (217 lines) at http://paste.evergreen-ils.org/50 |
15:45 |
mmorgan |
The searches have a random string of characters for author, title, etc, and have multiple languages and filter groups selected. |
15:46 |
bshum |
Sounds like a very entertaining advanced search. |
15:46 |
mmorgan |
I see a fair number of similar searches in the logs. |
15:46 |
* bshum |
doesn't know anything, is just musing |
15:46 |
mmorgan |
Heh. "Entertaining" for sure ;-) |
15:47 |
mmorgan |
Had to kill about ten of these today. |
15:47 |
|
bmills joined #evergreen |
15:49 |
bshum |
That join against a facet looks interesting. |
15:49 |
mmorgan |
They all seem to limit to "before(1012)" |
15:54 |
kmlussier |
mmorgan: Before 1012, eh? |
15:55 |
mmorgan |
Yeah. Don't *think* we have anything that old. ;-) |
15:56 |
kmlussier |
mmorgan: Given that it's before the Pilgrims landed, I would think not. :) |
15:56 |
bshum |
Well it is a geographic search for "asia" so, I dunno..... |
15:56 |
bshum |
subject|geographic[Asia] |
15:56 |
bshum |
Whee |
15:58 |
mmorgan |
And some of them don't seem to have any 'real' search terms in them at all. Just the random characters and the limiters. |
15:58 |
bshum |
Yeah, (-"OQcYe" && title:-"2scg4") && author:-"V3oH2") doesn't seem quite... real looking at all. |
15:59 |
kmlussier |
They look like passwords |
15:59 |
tsbere |
Or some of the random negations someone might use to do a "not cached' search |
16:00 |
bshum |
mmorgan: Have you tried tracing back into apache what leads to these queries? |
16:00 |
kmlussier |
Ah, that's true. I do thsoe sometimes. But usually you have a real keyword with those negations. |
16:01 |
bshum |
kmlussier: Well, keyword: subject|geographic[Asia] seems real to me. |
16:01 |
bshum |
If a bit broad. |
16:02 |
* kmlussier |
isn't looking at the queries closely enough. |
16:04 |
mmorgan |
bshum: How would I go about that? |
16:04 |
bshum |
Well I would have gone with time. |
16:05 |
bshum |
Like, before the timestamp of the DB query, what happens in apache, osrfsys, etc. |
16:05 |
bshum |
And slowly try recontructing the actual thing that made that weird query |
16:06 |
mmorgan |
Ok, I have done some poking around, but haven't been able to pin anything down. |
16:06 |
mmorgan |
Our logs are very busy :) |
16:08 |
mmorgan |
And I'm not sure of all the ways to follow the threads of what's going on. :-( |
16:11 |
kmlussier |
Isn't there a conference presentation next week on reading Evergreen logs? |
16:12 |
|
Newziky left #evergreen |
16:12 |
bshum |
kmlussier: Yeah, csharp is giving one. |
16:12 |
kmlussier |
mmorgan: I'll try sitting in on that one so that I can bring back lots of knowledge for you. :) |
16:12 |
kmlussier |
I hope it isn't up against one of my programs. |
16:13 |
mmorgan |
kmlussier: Thanks! |
16:15 |
mmorgan |
I'm sure the presentation will be posted, too, afterward for posterity :) |
16:25 |
mrpeters |
is an INSERT INTO config.metabib_field, followed by a reingest of those records, still the fastest way to add a particular marc tag to a keyword search? |
16:43 |
* mrpeters |
takes note that "label" is also a new required field so that magic spell is a little dated |
16:44 |
mmorgan |
mrpeters: Not an expert, but I don't know of any other way to do that. |
16:44 |
Dyrcona |
I was going to say that I think it is the only way to do it, but got sidetracked. |
16:45 |
mrpeters |
mmorgan: i didnt think so either, but so much awesome stuff has been done with the in-staff client configuration menus that i wasnt sure |
16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Keep all source syntax consistent in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=ef80e4c> |
17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Add [source, bash] to code blocks that were not defined in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=52b6eca> |
17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Emphasize variables and paths consistently in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=86e6d84> |
17:16 |
pinesol_green |
[opensrf|Josh Stompro] LP#1445503 - Updated Ejabberd setup steps for Ejabberd 14.x for Debian Jessie - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e421bb3> |
17:18 |
pinesol_green |
[opensrf|Ben Shum] Docs: Fix mailing list link for help in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=966fb05> |
17:18 |
bshum |
I give up on the asciidoc syntax for now. I will slay that eventually though. |
17:18 |
|
mmorgan left #evergreen |
17:21 |
bshum |
So, for the Evergreen bugs targeting issues with Debian Jessie |
17:21 |
bshum |
I'm thinking to backport those to rel_2_8 and rel_2_7 |
17:22 |
bshum |
Since both of those versions contained support for Jessie as a target. |
17:22 |
bshum |
And likely require those fixes to work successfully. |
17:23 |
Stompro |
That makes sense to me. |
17:27 |
* bshum |
is going to create new milestones |
17:28 |
pinesol_green |
[evergreen|Josh Stompro] LP#1445150 Update Debian Jessie depend make to PG9.4 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7cc3ee6> |
17:29 |
bshum |
dbwells: I'm not going to add a 2.6 milestone unless we determine more work is to be done for that series. |
17:29 |
dbwells |
bshum: sounds good |
17:33 |
* bshum |
shakes fist at Launchpad for timing out |
17:34 |
jeff |
@blame launchpad |
17:34 |
pinesol_green |
jeff: launchpad wants the TRUTH?! launchpad CAN'T HANDLE THE TRUTH!! |
17:37 |
jeff_ |
No results for search _TRUTH_ |
17:38 |
pinesol_green |
[evergreen|Josh Stompro] LP#1447195 Updates for Debian Jessie in README - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3200c8d> |
17:44 |
pinesol_green |
[evergreen|Josh Stompro] LP#1445187 - Force disable of deflate - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b949202> |
17:44 |
pinesol_green |
[evergreen|Josh Stompro] LP#1362260 - Email::Sender/libemail-send-perl change in Jessie - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad879d4> |
17:50 |
pinesol_green |
[evergreen|Josh Stompro] LP#1445182 Changed Debian Jessie dependency install to use packages for dbi dbd-pgsql. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5089b7> |
17:54 |
bshum |
Stompro++ # I pushed ahead everything and I seem to be well on my way towards a happy Jessie test server. |
18:08 |
bshum |
Hmm |
18:10 |
bshum |
Looks like we'll need to create a file for 000.english.pg94.fts-config.sql |
18:10 |
bshum |
In order for PG 9.4 to be used when creating the database |
18:11 |
bshum |
To test, I've just copied the 93 one to be named 94 and seeing how that goes. |
18:25 |
bshum |
I appended my findings to the bug |
18:30 |
bshum |
Stompro: I set https://bugs.launchpad.net/evergreen/+bug/1445150 back to Triaged while we test the last little bit I think we need to create a working database on PG 9.4 using the scripts. |
18:30 |
pinesol_green |
Launchpad bug 1445150 in Evergreen 2.7 "Debian Jessie includes Postgresql 9.4 - update software dependency makefile" (affected: 1, heat: 6) [Medium,Triaged] |
18:31 |
bshum |
When we get time, someone else should check that initial working branch, and then make any special adjustments. |
18:31 |
bshum |
Otherwise, as far as I can see, I have a functional Evergreen install on Debian 8.0 Jessie |
18:32 |
* bshum |
shuts down his VMs and goes to find a quiet (and cooler) room to space out in |
19:03 |
* kmlussier |
wonders how jcamins packs cookies when he goes to conferences. |
19:05 |
dcook |
kmlussier: The last cookies I had from jcamins at a conference were a bit squished... but yummy! |
19:06 |
dcook |
Oh man... I forgot that it's spring/summer in North America... |
19:27 |
kmlussier |
dcook: The calendar says it's spring, but I don't think the weather has been paying attention to the calendar. |
19:27 |
kmlussier |
Although the last few days have been quite nice. |
19:28 |
dcook |
Yeah, it's supposed to be autumn/winter here, but I think it's supposed to be something like 26 today |
19:28 |
dcook |
This has to be one of the weirder years I've been in Oz... |
19:42 |
jonadab |
Where I come from, 26 is a nice brisk fall day. (Granted, that's 26 F.) |
19:42 |
dcook |
I was waiting for that ;) |
19:44 |
kmlussier |
Heh |
19:45 |
jonadab |
Happy to oblige. |
19:51 |
|
sarabee joined #evergreen |
20:03 |
jcamins |
kmlussier: how far is the conference? |
20:03 |
kmlussier |
jcamins: All the way across the country. Hood River, Oregon |
20:03 |
jcamins |
And how many cookies? |
20:03 |
jcamins |
Hm. |
20:04 |
kmlussier |
I don't know how many yet. I'm thinking I may make bshum and his crew get theirs at another time. Since they aren't that far away from me. |
20:04 |
kmlussier |
I offered to make them for Evergreen sites that partnered with us on development projects. |
20:05 |
kmlussier |
The conference seemed so far away back then. |
20:05 |
bshum |
kmlussier: So in other words I'll probably never get cookies |
20:05 |
jcamins |
Are you checking any luggage? |
20:05 |
kmlussier |
bshum: Of course you'll get them! |
20:05 |
kmlussier |
Yes, I was planning to pack it in the checked luggage |
20:05 |
kmlussier |
I didn't know if I could get them through security. |
20:05 |
kmlussier |
How many do you usually travel with? |
20:06 |
kmlussier |
bshum: When you get yours, they probably won't be squished. |
20:06 |
jcamins |
I'd probably bring 4-5 takeout containers with cookies, then. |
20:06 |
kmlussier |
What kind of takeout containers do you use? |
20:06 |
jcamins |
The cookies dcook had were squished because I wasn't checking a suitcase, so I put them in ziploc bags, the better to fit them in my single carry-on. |
20:06 |
kmlussier |
Ah. |
20:06 |
jcamins |
My favorite are the rectangular Chinese ones. |
20:07 |
bshum |
I had those cookies, didn't I? |
20:07 |
jcamins |
*The cookies dcook and bshum had... |
20:08 |
jcamins |
Of course, if you really need to bring a *ton* your best bet is fudge. |
20:08 |
jcamins |
Though you'll spend hours wrapping it. |
20:09 |
kmlussier |
Fudge is yummy. |
20:09 |
kmlussier |
But I haven't made it in years. |
20:10 |
jcamins |
I make cheating fudge. |
20:11 |
kmlussier |
I don't really need to bring that many. There's PINES, COOL, and rfrasur's library. Since I've already decided that Bibliomation can wait. |
20:11 |
jcamins |
Yeah, true. PINES is really small. |
20:11 |
* dcook |
is getting hungry now but it's only 10:11am... |
20:11 |
kmlussier |
Yeah, that's what people always say when they talk about PINES. It's so small! |
20:11 |
* dcook |
needs to figure out when Aussies take tea... |
20:12 |
jcamins |
dcook: 10, 11... |
20:12 |
jcamins |
Oh, hey, it's 10 11, time for tea! |
20:12 |
dcook |
hehe |
20:13 |
dcook |
I could actually really go for some hummus about now... |
20:15 |
jcamins |
I should eat some dinner... |
20:15 |
jcamins |
kmlussier: isn't it a bit late for you? |
20:15 |
kmlussier |
Yeah, I'm suffering the consequences of my procrastination. |
20:16 |
kmlussier |
I have a presentation to deliver at 8:30 a.m. tomorrow. |
20:16 |
bshum |
Can you fit chocolate in your presentation |
20:16 |
bshum |
? |
20:16 |
bshum |
I think that always makes things better. |
20:17 |
kmlussier |
Chocolate at 8:30 a.m.? |
20:17 |
bshum |
True, might be too early for most. |
20:19 |
* bshum |
might just be thinking about chocolate cause he wants some right now. |
20:21 |
jcamins |
kmlussier: sounds good to me! |
20:22 |
jonadab |
Is there ever a wrong time of day for chocolate? |
20:22 |
jonadab |
8:30am is a good time of day for hot chocolate. |
20:23 |
jcamins |
jonadab: any kind of chocolate, really. |
20:29 |
jeff_ |
Hrm. I don't think quasseldroid is what I'm looking for. |
20:38 |
jeff |
theae aren't the droids you're looking for? |
21:55 |
|
bmills joined #evergreen |
22:21 |
|
sarabee joined #evergreen |
23:01 |
|
book` joined #evergreen |
23:22 |
|
sarabee joined #evergreen |
23:23 |
|
book` joined #evergreen |
23:49 |
|
sarabee joined #evergreen |