| Time |
Nick |
Message |
| 01:12 |
|
mnsri joined #evergreen |
| 02:42 |
|
shresh joined #evergreen |
| 03:33 |
|
RBecker joined #evergreen |
| 06:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:01 |
|
artunit_ joined #evergreen |
| 07:03 |
|
Callender joined #evergreen |
| 08:00 |
|
eeevil joined #evergreen |
| 08:02 |
|
akilsdonk joined #evergreen |
| 08:05 |
|
mtate joined #evergreen |
| 08:06 |
|
graced joined #evergreen |
| 08:11 |
|
rjackson-isl joined #evergreen |
| 08:24 |
|
StephenGWills joined #evergreen |
| 08:24 |
|
mrpeters joined #evergreen |
| 08:33 |
|
mnsri joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:35 |
|
Shae joined #evergreen |
| 08:51 |
* csharp |
targets bug 1202742 for 2.7.1 since that was supposed to have been included in "Longoverdue" to begin with ;-) |
| 08:51 |
pinesol_green |
Launchpad bug 1202742 in Evergreen "Support alert/print message for transiting, non-active copies " (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1202742 |
| 08:56 |
|
ericar joined #evergreen |
| 09:03 |
tsbere |
That kind of development for transiting copies doesn't help those of us with "you don't print slips for 99% of transits" setups much. |
| 09:18 |
csharp |
tsbere: does it interfere with how your libraries do things? |
| 09:19 |
tsbere |
csharp: Probably not. But still not that useful either. :P |
| 09:19 |
|
RoganH joined #evergreen |
| 09:19 |
tsbere |
No slip to print the notice on to alert the destination to pay special attention or sort differently after all |
| 09:19 |
csharp |
our libraries depend heavily on printed transit slips |
| 09:20 |
tsbere |
Our delivery system currently does SIP2 checks for "where is this going?" for the majority of items, thus no slips. |
| 09:20 |
RoganH |
csharp: I would assume all consortiums with heavy intra-system lending do. |
| 09:20 |
csharp |
yeah, I'm actually not sure this particular feature will do much for our libraries either, but the idea is "staff will see that this is a longoverdue item and treat it differently" |
| 09:20 |
csharp |
RoganH: yep |
| 09:21 |
csharp |
tsbere: huh - you'll have to give me details on that sometime - sounds interesting |
| 09:22 |
RoganH |
tsbere: using RFID? |
| 09:22 |
tsbere |
csharp: Er....the delivery company calls it something like "sort to light" or something. Our barcodes should, generally, be on the outside of items. Thus they scan the barcode, SIP2 gives the destination shortcode, and it goes into the bin for that destination. I think cross-system stuff is still slips, but I dunno how we actually handle those right now... |
| 09:23 |
csharp |
huh |
| 09:23 |
RoganH |
I think I saw a vendor showing that at ALA this year. I'd forgotten about it. |
| 09:23 |
tsbere |
As such, most of our transits have no slips, only things going to other consortia or where the barcode is not on the outside of the case, generally, should have one. |
| 09:23 |
RoganH |
If it's the same thing that I saw it was pretty slick and the conveyers worked a lot better than the ones I'm used to seeing on sorters. |
| 09:24 |
csharp |
in our perfect world, transit bins would be barcoded so we could track where an item is at any point, but that's pie-in-the-sky when it's on a PINES scale |
| 09:24 |
csharp |
well, to say that differently, we're happy with what we're getting at the price we're getting it ;-) |
| 09:25 |
tsbere |
heh |
| 09:25 |
jeff |
http://www.masslibsystem.org/optima-sort-to-light-delivery-operations/ has a video -- loud music but no words. It appears that the different sort floor employees have a handheld barcode scanner and an assigned color. They scan the item, their color LED lights above the bin, they drop the item and scan the bin's barcode to confirm. |
| 09:25 |
jeff |
the vendor is http://www.shipoptima.com/ |
| 09:26 |
* tsbere |
had never actually figured out the "light" portion of the name, but that makes sense. "Sort it to the light that lit up" |
| 09:26 |
RoganH |
csharp: we use a state department that does our shipping the inter agency mail service and whatever failures they have are made up for in being cheap |
| 09:27 |
csharp |
we have a great balance of price, dependability/responsiveness to complaints, and reasonable shipping times right now |
| 09:27 |
csharp |
(we use stat courier, btw) |
| 09:28 |
jeff |
http://www.masslibsystem.org/faq/ has a FAQ section on sort to light |
| 09:28 |
csharp |
jeff: ooooooo nice |
| 09:33 |
|
RoganH joined #evergreen |
| 09:56 |
csharp |
bleh... I'm having trouble finding the cause of this JS error: 'ReferenceError: circStrings is not defined' when clicking the "Macros" button with the transit_slip template in focus in Admin -> Workstation Administration -> Receipt Template Editor after applying the patch for bug 1202742 on our 2.5.1 system |
| 09:56 |
pinesol_green |
Launchpad bug 1202742 in Evergreen "Support alert/print message for transiting, non-active copies " (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1202742 |
| 09:57 |
|
yboston joined #evergreen |
| 09:58 |
csharp |
var circStrings = document.getElementById('circStrings'); appears twice within the file |
| 09:58 |
csharp |
I don't know if 'circStrings' refers to the variable or the 'getElementById' portion |
| 10:00 |
csharp |
JS console is unhelpful - not even a message to correspond with the alert box popup |
| 10:00 |
csharp |
in any case, I see the patch working fine when applied to current master, but not on 2.5.1 |
| 10:00 |
|
BigRig joined #evergreen |
| 10:00 |
csharp |
@monologue |
| 10:00 |
pinesol_green |
csharp: Your current monologue is at least 7 lines long. |
| 10:01 |
|
dbwells joined #evergreen |
| 10:01 |
|
sseng joined #evergreen |
| 10:01 |
csharp |
the patch itself was developed last summer, so that's pre-2.5 |
| 10:05 |
Stompro |
Anyone know what is up with the "Washington County Public Library, Kentucky" they are listed on the Evergreen Libraries page, but their hostname is taken over by a squatter, and the page I can find http://www1.youseemore.com/washingtoncountypl/ seems to use a tlc catalog. tlcdelivers.com |
| 10:06 |
csharp |
Stompro: that page isn't well maintained that I know of - prolly something to point out to gmcharlt/web team ;-) |
| 10:07 |
tsbere |
csharp: circStrings would refer to the variable. Generally, the javascript is running on a page without an id="circStrings" element within it, so getElementById is returning null, so the variable isn't defined. Perhaps circStrings was added as an element post-2.5? |
| 10:07 |
Stompro |
csharp, it is on the Wiki, so I'll update it, I'm just wondering if anyone heard anything about them moving away from evergreen. |
| 10:08 |
csharp |
Stompro: sometimes things like this are how we find out ;-) |
| 10:09 |
yboston |
phasefx: are you around for a quick community question? |
| 10:09 |
Stompro |
Ahh, youseemore.com is also a TLC product. They must have moved over to TLC and dropped eveything else. I'll send them an email. |
| 10:09 |
csharp |
usually it's only the high-profile systems who get reported out via Marshall Breeding & co. |
| 10:10 |
csharp |
tsbere: I'll check out that |
| 10:10 |
csharp |
s/out/on/ |
| 10:11 |
|
ericar joined #evergreen |
| 10:11 |
|
ericar left #evergreen |
| 10:17 |
csharp |
looks like circStrings first appeared in early 2008 with commit 4e3c634, so that's not it |
| 10:17 |
pinesol_green |
[evergreen|dbs] Start tackling circ/util.js i18n - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e3c634> |
| 10:17 |
csharp |
however, I can report that whatever's wrong is only affecting slips with type: transit |
| 10:18 |
phasefx |
yboston: I'm off today, but still around as it happens :) what's up? |
| 10:21 |
tsbere |
csharp: That sounds fairly straightforward to look at. Want me to take a quick look? |
| 10:26 |
csharp |
tsbere: yes, please... should I pastebin our util.js post-patch? |
| 10:26 |
tsbere |
csharp: I was thinking I could just cherry-pick the commit into a rel_2_5 checkout to take a look. |
| 10:26 |
csharp |
or is there another file? I've never fully untangled receipt templates ;-) |
| 10:27 |
csharp |
ah - okay - yeah - that'd be great |
| 10:32 |
tsbere |
csharp: Is it only when hitting the macros button, or are you seeing it elsewhere too? |
| 10:33 |
csharp |
there was a FIXME in one of the circ interfaces (sorry I don't remember now) but the message provided to me was... lemme paste it |
| 10:34 |
pastebot |
"csharp" at 64.57.241.14 pasted "fixme error for tsbere" (7 lines) at http://paste.evergreen-ils.org/18 |
| 10:34 |
csharp |
not much meat there, but there is a line number |
| 10:42 |
tsbere |
csharp: Do you have specific instructions for what you are doing to get the error? Because at this point I am wondering if some other pines change has caused it. |
| 10:43 |
csharp |
in my case, go to Admin -> Local Administration -> Receipt template editor, then select transit_slip, then click Macros |
| 10:43 |
tsbere |
csharp: Stock rel_2_5 with the commit cherry-picked in does not, for me, generate errors there. |
| 10:44 |
tsbere |
csharp: Thus, if you are getting errors I would need your version of the file at a minimum, perhaps more. :/ |
| 10:47 |
csharp |
yeah - just a minute - I'm going to diff the pines version with "vanilla" 2.5.1 |
| 10:48 |
csharp |
nope - no customizations in util.js - lemme check circ.properties |
| 10:53 |
csharp |
no customizations in circ.properties either - hmm |
| 10:54 |
tsbere |
csharp: Check server/circ/print_list_template_editor.xul |
| 10:54 |
csharp |
k |
| 10:54 |
* bshum |
gets twitchy with string changes |
| 10:55 |
csharp |
no differences there either |
| 10:55 |
csharp |
damn |
| 10:56 |
csharp |
I applied the change by copying the 'raw' version of the commit into a file and using 'patch' |
| 10:58 |
tsbere |
csharp: why not just use git cherry-pick? |
| 11:00 |
tsbere |
csharp: Also, given that you apparently have no differences, it seems odd that my line numbers are off by quite a bit from yours on the error |
| 11:00 |
csharp |
huh - interesting |
| 11:00 |
csharp |
I don't use cherry-pick when patching a running server |
| 11:00 |
csharp |
just create a patch and apply manually |
| 11:01 |
|
sarabee joined #evergreen |
| 11:01 |
* csharp |
is happy to learn better ways to do things ;-) |
| 11:01 |
tsbere |
csharp: Cherry-pick into the branch, generate patch from *that*? |
| 11:01 |
csharp |
ah |
| 11:01 |
tsbere |
added bonus: Your git branch then has the changes ;) |
| 11:03 |
tsbere |
csharp: Also, once you have cherry-picked you can use "git format-patch" to get a patch file out |
| 11:03 |
|
ericar joined #evergreen |
| 11:03 |
|
ericar left #evergreen |
| 11:03 |
tsbere |
csharp: Or, in the case where you are putting whole file updates into place, once you have the commit cherry-picked just copy the file over |
| 11:05 |
csharp |
tsbere: thanks for the help... I think I'm going to have to walk away from this problem for a bit, maybe get some lunch :-/ |
| 11:06 |
tsbere |
csharp: Feel free to direct message me or email me with questions about any of this as well. I wouldn't even object to a phone call, though I suppose you would need my phone number for that. |
| 11:07 |
csharp |
thanks :-) |
| 11:07 |
csharp |
working_while_sick-- |
| 11:07 |
RoganH |
csharp: stop working, get soup and watch bad movies |
| 11:08 |
bshum |
csharp: I'm not sure about targeting bug 1202742 at 2.7.1 as though it were a bug fix. It's got string changes (which we don't do past beta) and otherwise reads as a new feature to Evergreen? It should stay in the hopper for 2.8. |
| 11:08 |
pinesol_green |
Launchpad bug 1202742 in Evergreen "Support alert/print message for transiting, non-active copies " (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1202742 |
| 11:11 |
csharp |
bshum: no objections here |
| 11:16 |
pinesol_green |
[evergreen|Ben Shum] LP#1306814: Make use of patron timeout setting for selfcheck - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7edee6> |
| 11:20 |
bshum |
Calling 0893 |
| 11:26 |
pinesol_green |
[evergreen|Chris Sharp] LP#1368314: Add RDA support to reporter.simple_record. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbee3de> |
| 11:26 |
pinesol_green |
[evergreen|Ben Shum] LP#1368314: Stamping upgrade script for RDA support to reporter.simple_record - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2b3925b> |
| 11:31 |
dbwells |
yboston: Better authority fix for bug #1233350 is now posted as bug #1379824 |
| 11:31 |
pinesol_green |
Launchpad bug 1233350 in Evergreen "Cannot edit an authority record twice without reloading authorities, " (affected: 3, heat: 16) [Undecided,Confirmed] https://launchpad.net/bugs/1233350 |
| 11:31 |
pinesol_green |
Launchpad bug 1379824 in Evergreen "Make PermaCrud.js disconnect() actually disconnect" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1379824 |
| 11:33 |
yboston |
dbwells: nice! |
| 11:34 |
bshum |
Calling 0894 |
| 11:37 |
yboston |
dbwells: is there anything I can help with? do you need me to test the commit and sign it off? |
| 11:38 |
pinesol_green |
[evergreen|Chris Sharp] LP#1374551: Create index on money.billing.voider to speed user merge. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44bca3b> |
| 11:38 |
pinesol_green |
[evergreen|Ben Shum] LP#1374551: Stamping upgrade script for new index on money.billing.voider - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=896dea5> |
| 11:38 |
dbwells |
yboston: testing and signoffs are always appreciated! |
| 11:50 |
bshum |
Hmm, California. |
| 11:55 |
|
ldwhalen joined #evergreen |
| 12:02 |
|
nhilton joined #evergreen |
| 12:11 |
bshum |
eeevil: csharp: Is there anything special that needs to happen after applying the new fixed fields from https://bugs.launchpad.net/evergreen/+bug/1309664 |
| 12:11 |
pinesol_green |
Launchpad bug 1309664 in Evergreen "Add some fixed field seed data for COM and SER" (affected: 1, heat: 6) [Wishlist,New] |
| 12:11 |
bshum |
Or it's just stuff employed by the editor? |
| 12:17 |
bshum |
And I wonder how that relates to gmcharlt's work in https://bugs.launchpad.net/evergreen/+bug/1306258 |
| 12:17 |
pinesol_green |
Launchpad bug 1306258 in Evergreen "more seed data for MARC21 fixed field values would be nice" (affected: 1, heat: 6) [Wishlist,Triaged] |
| 12:18 |
bshum |
Actually they look a little different |
| 12:18 |
* bshum |
shrugs it off |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:33 |
eeevil |
bshum: nothing to do after adding that. it's really mainly for the benefit of the context menus in the FF editor. a reingest would allow you to set up filters and stuff on them, but, those are very rare FFs in practice |
| 12:33 |
bshum |
eeevil: That's what I was thinking as I looked at it more. Thanks for confirming! :D |
| 12:33 |
bshum |
I'll get that pushed along then shortly. |
| 12:34 |
bshum |
eeevil++ csharp++ |
| 12:36 |
|
Christineb joined #evergreen |
| 12:41 |
|
RBecker joined #evergreen |
| 13:02 |
|
ldwhalen joined #evergreen |
| 13:07 |
|
ericar joined #evergreen |
| 13:08 |
|
ericar left #evergreen |
| 13:16 |
bshum |
Calling 0895 |
| 13:20 |
RoganH |
bshum: did 0895 ever call you back? |
| 13:20 |
bshum |
Hehe |
| 13:20 |
RoganH |
:) Tip your waiters folks, I'll be here all week. |
| 13:20 |
bshum |
RoganH: You know I never really asked why I say that. I just followed everybody else's example. |
| 13:20 |
bshum |
:) |
| 13:20 |
pinesol_green |
[evergreen|Mike Rylander] LP#1309664: Add some fixed field seed data for COM and SER - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cca294d> |
| 13:20 |
pinesol_green |
[evergreen|Ben Shum] LP#1309664: Stamping upgrade script for new seed data for COM and SER - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f3e9100> |
| 13:20 |
bshum |
RoganH++ |
| 13:31 |
RoganH |
I'm headed out. Have a good weekend! |
| 13:32 |
|
bmills joined #evergreen |
| 13:33 |
|
dreuther_ joined #evergreen |
| 13:35 |
bshum |
bmills: I just pushed the selfcheck timeout fix to the repos. Hopefully you can make use of that fix sometime. :) |
| 13:37 |
bmills |
bshum: thanks! |
| 13:38 |
bmills |
bshum++ |
| 13:39 |
bshum |
mmorgan++ # thanks for testing! |
| 13:39 |
bshum |
jboyer-isl++ # think check on the JavaScript. |
| 13:53 |
|
RBecker joined #evergreen |
| 14:07 |
mmorgan |
bshum++ # thanks for fixing :) |
| 14:09 |
|
RBecker joined #evergreen |
| 14:17 |
|
dreuther joined #evergreen |
| 14:38 |
|
RBecker joined #evergreen |
| 14:39 |
|
akilsdonk joined #evergreen |
| 14:41 |
|
ldwhalen joined #evergreen |
| 14:54 |
|
bmills joined #evergreen |
| 14:58 |
pinesol_green |
[evergreen|Dan Scott] LP#1305958 Change copy table header atts to scope attributes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf421fe> |
| 15:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1379824 Make PermaCrud.js disconnect() actually disconnect - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18ef1ce> |
| 15:20 |
Bmagic |
General question - if I want to set a variable in the perl backend for the template toolkit to read later can I use ctx? or cgi? AKA $cgi->{add_item_success} = $bib and in the ttl tempval = CGI.add_item_success; (this doesnt work) |
| 15:26 |
tsbere |
Bmagic: I would go with ctx |
| 15:26 |
Bmagic |
tsbere: it doesnt seem that the ttl gets my variable |
| 15:26 |
tsbere |
Bmagic: I would need more information, such as where you are trying to set and use, in order to help you further. |
| 15:28 |
Bmagic |
tsbere: Im setting it on the server side Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Account.pm and I am trying to read it from templates/opac/parts/bookbag_actions.tt2 |
| 15:29 |
Bmagic |
the code I have tried in Account.pm is $self->ctx->{add_item_success} = $bib on line 2220 and I dumped the variable to the logs to make sure it's set and it is |
| 15:31 |
tsbere |
Bmagic: That code block appears to go into a redirect on success. As such I believe you will lost ctx in the process. |
| 15:31 |
Bmagic |
ah |
| 15:31 |
Bmagic |
I need to carry it through somehow |
| 15:32 |
tsbere |
Bmagic: To carry through you will need to add to $url |
| 15:32 |
Bmagic |
tsbere: my first was to add it to $url |
| 15:32 |
Bmagic |
and that worked |
| 15:32 |
Bmagic |
but then the mkurl function keeps that URI for all of the subsequent links |
| 15:34 |
Bmagic |
Does EG use session variables? |
| 15:34 |
Bmagic |
I don't see Apache::Session being used anywhere |
| 15:35 |
tsbere |
Bmagic: You can get some session like stuff with memcache, but I am not sure I would want to rely on it |
| 15:35 |
Bmagic |
tsbere: oh yeah, that's right, because the traffic is load balanced. OK, why not rely on memcache? |
| 15:36 |
tsbere |
Bmagic: Because someone doing multiple things with the same authtoken, or those not logged in, will likely get confusing. |
| 15:36 |
Bmagic |
the ttl can talk to memcache? |
| 15:36 |
tsbere |
Bmagic: Well, no, the backend would have to do that and then store things in ctx |
| 15:37 |
Bmagic |
tsbere: so, you would put my var in the URL and then teach mkurl to ignore it? |
| 15:38 |
tsbere |
Bmagic: That would be one option. You could store it in a cookie and fetch it afterwards too. |
| 15:38 |
Bmagic |
tsbere: the cookie sounds cleaner |
| 15:39 |
tsbere |
Bmagic: What are you aiming to do, anyway? |
| 15:39 |
Bmagic |
I would like to display a message in the OPAC after a bib is added to a list saying something like "Success" |
| 15:42 |
tsbere |
And the way things currently work that is an "easier said than done" thing. :/ |
| 15:42 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1182547 |
| 15:42 |
pinesol_green |
Launchpad bug 1182547 in Evergreen "OPAC -"Add to my list" not displaying properly" (affected: 8, heat: 36) [Undecided,Confirmed] |
| 15:43 |
Bmagic |
tsbere: it seems like storing a quick bib id somewhere and referring to it in the opac should be pretty easy |
| 15:43 |
Bmagic |
the redirect is the issue, and a cookie could be the solution |
| 15:44 |
tsbere |
Bmagic: Perhaps going a different route would be better: Teach TPac to check *all* of a user's lists for the bib? |
| 15:45 |
Bmagic |
tsbere: I understood that was discussed and voted against for performance concerns |
| 15:45 |
Bmagic |
tsbere: when really a simple "it worked" would/could resolve the issue |
| 15:45 |
tsbere |
Shouldn't be hard to, at the very least, say "this is on one of your lists" - Not necessarily saying *which* list in the dropdown or anything. |
| 15:47 |
Bmagic |
tsbere: I think your idea will work as well, want to code it for me? |
| 15:47 |
tsbere |
not really |
| 15:47 |
Bmagic |
I suppose that would be pure ttl code |
| 15:47 |
tsbere |
and that is also a "not really" :P |
| 15:47 |
Bmagic |
haha |
| 15:50 |
* tsbere |
blinks at the bookbag loading code and wonders if something is horribly broken |
| 15:50 |
* Bmagic |
ponders |
| 15:52 |
tsbere |
So, yea, under some normal circumstances it doesn't happen, but there is some funky stuff going down there... |
| 15:53 |
Bmagic |
in Account.pm sub load_myopac_bookbag_update ? |
| 16:33 |
jeff |
lists were very... interesting when we were scraping them |
| 16:33 |
jeff |
some of the interesting things were just due to the hackish nature of scraping in general |
| 16:33 |
jeff |
other things were... perhaps not exclusive to that :-) |
| 16:35 |
|
mrpeters left #evergreen |
| 16:48 |
|
StephenGWills left #evergreen |
| 16:55 |
|
nhilton_ joined #evergreen |
| 16:58 |
|
nhilton joined #evergreen |
| 17:00 |
|
vlewis joined #evergreen |
| 17:10 |
bmills |
has anyone experienced evergreen locking up when creating a new marc record and then hitting the validate button with new authority headings put in? we've had a few instances reported where the staff member will have their machine lock up and then return a "Validate -650 -650" etc… depending on how many times they've hit validate. we then get a postgres process for it that runs at 100% until being killed off with pg cancel backend. |
| 17:12 |
|
mmorgan left #evergreen |
| 17:12 |
Bmagic |
bmills: We haven't see than behavior, what version of EG and postgres? |
| 17:13 |
|
bbqben joined #evergreen |
| 17:13 |
bmills |
2.5.1 and postgres 9.1.14 |
| 17:16 |
yboston |
I always forget every year, happy Canadian Thanksgiving to our Canadian EG folk! |
| 17:16 |
yboston |
thanks to bbqben for reminding me |
| 17:16 |
bmills |
@Bmagic example error message after canceling the query http://pastebin.com/wLHKeYgy |
| 17:16 |
pinesol_green |
bmills: Yeah, well, you know, that's just, like, your opinion, man. |
| 17:21 |
jihpringle |
yboston: thanks! we'll be eating lots of turkey :) |
| 17:22 |
Bmagic |
bmills: I'm not going to be much help as our system is not currently using authority. I hope there is someone here with more expierence with the DB authority.normalize_heading. You could bring it to the email list and get more response. |
| 17:23 |
bmills |
Bmagic: thanks! |
| 17:42 |
|
bmills1 joined #evergreen |
| 17:43 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:44 |
|
nhilton_ joined #evergreen |
| 17:54 |
bbqben |
jihpringle: bring leftovers to the office next week? |
| 17:55 |
jihpringle |
bbqben: I wish, I'm going to family friends for dinner so I won't have leftovers :( |
| 17:55 |
bbqben |
jihpringle: bring small tupperware ;) |
| 17:56 |
jihpringle |
:) |
| 18:44 |
|
nhilton joined #evergreen |
| 19:43 |
|
atlas__ joined #evergreen |
| 19:45 |
atlas__ |
hello ! installing evergreen for the first time and having fun getting ejabberd to start |
| 19:45 |
atlas__ |
any ideas whats causing this: http://imgur.com/iNAbZkP |
| 19:49 |
jihpringle |
atlas__: Welcome! This channel is usually busiest between 9-5 ETMonday to Friday. I'd recommend that you try asking your question again on Monday |
| 19:50 |
jihpringle |
or you could try posting your question to general mailing list - http://evergreen-ils.org/communicate/mailing-lists/ |
| 20:01 |
bshum |
atlas__: Which distribution are you installing on? |
| 20:06 |
atlas__ |
bshum: Fedora 20 |
| 20:07 |
bshum |
Aha |
| 20:07 |
bshum |
I thought it looked a little different. |
| 20:07 |
bshum |
My experience thus far is primarily Debian/Ubuntu. |
| 20:08 |
atlas__ |
I figured I should have started with one of those since they are listed first in the instruction order |
| 20:08 |
atlas__ |
so when I try to start all the opensrf services I just get 'authentication failed' and its because ejabberd seems to be borked |
| 20:09 |
bshum |
atlas__: Fedora is one of the targets, but nobody actively uses Fedora in production for Evergreen (as far as I know) |
| 20:10 |
bshum |
I think it's mainly there cause there's a few Fedora enthusiasts among the developers :) |
| 20:10 |
bshum |
It's entirely possible that something needs more love with Fedora 20. Just a quick glance at the instructions for OpenSRF seem to me that they were written with Fedora 17+ in mind (which might also mean that they haven't been fully tested yet with 20) |
| 20:10 |
atlas__ |
what do people run in production |
| 20:11 |
bshum |
Yeah, the Fedora build slave at testing.evergreen-ils.org is only Fedora 18. |
| 20:11 |
bshum |
atlas__: Go for Debian or Ubuntu. |
| 20:11 |
bshum |
Presently, Debian Wheezy (7.0) or Ubuntu 12.04 server would be my best recommendations. |
| 20:12 |
bshum |
Ubuntu 14.04 support is still... being worked out. |
| 20:12 |
atlas__ |
any reason to do one over the other? i've got more experience with ubuntu, but yeah 14.04 would be a lot better |
| 20:13 |
atlas__ |
I'd rather Fedora (clearly!). But if Debian is what most use in production I could probably figure it out. |
| 20:13 |
bshum |
atlas__: I consider it to be a personal preference. I use Ubuntu 12.04 for our systems. |
| 20:13 |
atlas__ |
okay |
| 20:15 |
atlas__ |
nuking the f20 vm :( |
| 20:16 |
bshum |
atlas__: If you're interested in Fedora, I would consider mailing the list as jihpringle suggested. Perhaps the Fedora folks will chime in when they can. :) |
| 20:16 |
* bshum |
stares off in dbs' direction |
| 20:16 |
bshum |
But yeah, if you're thinking to work with Evergreen in production, I think people usually stick with Debian or Ubuntu. |
| 20:17 |
bshum |
I think they use Fedora as a development platform. |
| 20:18 |
atlas__ |
tempted to try this out https://github.com/mark-cooper/evergreen-playbook |
| 20:19 |
bshum |
Hmm, fancy. |
| 20:22 |
atlas__ |
crawl walk run though eh |
| 20:22 |
atlas__ |
hehe |
| 20:31 |
|
bmills joined #evergreen |
| 21:53 |
atlas__ |
bshum: I think I know where I went wrong. it probably would have just worked on fedora 20 |
| 21:55 |
bshum |
atlas__: It's entirely possible. |
| 21:55 |
bshum |
One of these days I'll try building Evergreen on Fedora again. But not this weekend :) |
| 21:58 |
bshum |
Out of curiosity, what do you think happened? |
| 22:00 |
atlas__ |
I think I ran make as root user on opensrf instead of as 'user' |
| 22:12 |
|
sbrylander joined #evergreen |
| 22:24 |
atlas__ |
nope |
| 22:24 |
atlas__ |
same error in ubuntu 12.04 damnit |
| 22:25 |
bshum |
Hmm |
| 22:27 |
bshum |
So the error you're seeing is... the authentication failure? |
| 22:28 |
bshum |
When you registered the ejabberd users, did you use any special characters in the password? |
| 22:29 |
bshum |
I wonder if the logs will have any more clues for why things aren't working correctly. |
| 22:31 |
atlas__ |
yes...I did use special characters in the password.. |
| 22:31 |
atlas__ |
i had thought about that.. |
| 22:31 |
bshum |
atlas__: So, ejabberd has a bug in it where use of some characters can break things |
| 22:31 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/714694 like dollar signs, etc. |
| 22:31 |
pinesol_green |
Launchpad bug 714694 in OpenSRF "Passwords cannot contain certain special characters" (affected: 1, heat: 6) [Medium,Won't fix] |
| 22:31 |
atlas__ |
ba dum tish |
| 22:31 |
bshum |
You'll want to try something a little simpler for testing :) |
| 22:32 |
atlas__ |
can I just re-run these register commands to get new ejabbderctl passwords |
| 22:33 |
bshum |
I was just looking up how to change the passwords |
| 22:33 |
atlas__ |
thank you thank you |
| 22:33 |
bshum |
ejabberdctl man page, whee |
| 22:34 |
bshum |
So maybe something like |
| 22:34 |
bshum |
sudo ejabberdctl change-password opensrf private.localhost password |
| 22:34 |
bshum |
Repeat for all four users |
| 22:34 |
bshum |
But basically "ejabberdctl change-password <user> <hostname> <password>" |
| 22:35 |
bshum |
And then make sure you change up your opensrf_core.xml passwords to match it |
| 22:35 |
bshum |
And .srfsh.xml too |
| 22:35 |
bshum |
For purposes of getting going, I'd do something alphanumeric. |
| 22:35 |
bshum |
Or if it's purely a test system... *cough, cough* "password" is probably fine :) |
| 22:37 |
bshum |
Maybe we ought to consider putting a note on that in the OpenSRF README on how people should avoid certain special characters that are known to break things. |
| 22:37 |
* bshum |
adds reminder for his future self. |
| 22:40 |
|
atlas__ joined #evergreen |
| 22:43 |
|
buzzy joined #evergreen |
