| 09:50 |
dbs |
f6fbea5a4a1cab03e was the relevant commit, but need to fix initial tab too |
| 09:54 |
dbs |
bshum: pushed a commit to fix that |
| 09:54 |
bshum |
dbs++ |
| 09:55 |
* csharp |
will throw the mobile OPAC code on a 2.5-ish test server later this week for "production" testing |
| 09:55 |
Dyrcona |
It looks good on my Galaxy S4. |
| 09:55 |
csharp |
I'll test some today if I get a chance on a vanilla master server, but today is meeting-ful |
| 09:55 |
csharp |
theory looks great on my Note 2 |
| 09:56 |
bshum |
dbs: Works for theory |
| 09:56 |
csharp |
I got to brag on y'all to my bosses ;-) |
| 09:57 |
dbs |
There are some inconsistencies with Submit button ("Search") vs. Clear Form that we fought with before that raised their heads again last night. Still not pretty. |
| 11:43 |
senator |
well of course, and everyone's doing a great job, and this is an unusually strong, collaborative effort |
| 11:43 |
senator |
i'm not trying to put the brakes on anything here |
| 11:44 |
dbs |
I've got to go get lunch. With the possible exception of experimenting with <button> instead of <a> for .opac-buttons, I think I'm done for a while. |
| 11:44 |
* csharp |
refreshes his dev server to test the mobile OPAC |
| 11:45 |
dbs |
There's a lot more to be done, but it has come a long way. |
| 11:45 |
senator |
but i think our meaningful review/sign-off practices are worth maintaining |
| 11:45 |
dbs |
csharp: collab/dbs/responsive-tpac is the latest, rebased on current master |
| 11:51 |
csharp |
heh |
| 11:51 |
bshum |
senator: I don't really feel like we should review the mobile work in pieces. Lots of what happened was done with the entire experience in mind and I've been finding it hard to say this is exclusively only benefiting one or the other. |
| 11:52 |
csharp |
okay, as a tester, are there places I should poke especially hard? |
| 11:52 |
bshum |
Even with the font-size stuff, that helps in the main catalog, but it impacted significantly how the mobile view worked as well with regards to how much finnessing we needed to deal with. |
| 11:53 |
bshum |
csharp: The big thing I focused on with testing was ensuring that the original functionality was as close as possible. Especially with regards to the login page, my account areas, advanced search, and results view. |
| 11:53 |
bshum |
Those were the four big areas of change I think. |
| 11:53 |
csharp |
okey dokey |
| 11:53 |
bshum |
Oh, the searchbar. |
| 11:54 |
bshum |
The biggest difference visually is the login page I think |
| 12:58 |
ElliotFriend |
agreed. I'm thinking it is more a policy problem than evergreen problem. |
| 12:58 |
csharp |
definitely ;-) |
| 12:59 |
ElliotFriend |
i've not tried checking in non-checked-out items yet, what happens then? |
| 13:00 |
csharp |
ElliotFriend: from my quick test, it puts the item into Reshelving status |
| 13:00 |
dbs |
dbwells++ # overflow:auto does the trick |
| 13:01 |
* csharp |
has supported EG for 5+ years but has never used it day-to-day ;-) |
| 13:01 |
* rfrasur |
uses EG daily and loves it like a child. |
| 15:46 |
bshum |
senator: So dbs and I discovered with tsbere's help that the compatibility mode was screwing with the mobile branch horrifically |
| 15:46 |
bshum |
We added a meta tag to force it off |
| 15:47 |
bshum |
When we turned it off, it looked much better with IE10 for me at least |
| 15:47 |
senator |
and all looks pretty good now? i'm only in a position to test with 8, i think, right now |
| 15:47 |
bshum |
I think he tested IE8 and it was fine |
| 15:47 |
bshum |
senator: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=68d50f2678eb6c558623bfd2c764bc51ec789d5f |
| 15:47 |
bshum |
That's the commit dbs put for the meta tag |
| 15:48 |
senator |
thanks |
| 15:48 |
bshum |
If you toss that on your test system or use theory.biblio.org with IE8 to test; that'd be great. |
| 15:48 |
dbwells |
I am on IE9. It's functional, but with quite a few display regressions. |
| 15:48 |
bshum |
I only have IE10 to test with |
| 15:52 |
jeff |
free IE test VMs here: http://www.modern.ie/virtualization-tools |
| 15:53 |
dbwells |
I can verify that IE10 displays much better than IE9. |
| 15:53 |
jeff |
or http://www.modern.ie/en-us/virtualization-tools#downloads for a barely-more-direct link |
| 15:54 |
kmlussier |
Ugh! Git problems trying to push to dbs' branch. |
| 16:01 |
jeff |
Oh hey. I just realized. The concept of Standards Override Bodies already exists. We call them Vendors, right? |
| 16:02 |
jeff |
(I come to this realization as we are essentially negotiating a likely non-standard NCIP extension with someone else's vendor indirectly via IM and email) |
| 16:05 |
* bshum |
takes his hands off the repo (took a few moments to rebase on top of kmlussier's stuff) |
| 16:08 |
* senator |
tests ie, listens to that silly clicking sound a lot |
| 16:10 |
* dbwells |
imagines the bug report which started that "The instructions said to click the link. I kept pressing the mouse button, but never got any clicking..." |
| 16:10 |
senator |
generally looks good, only noticing two glitches myself so far: green swatch on the right side of the basic search page, and also on the search results page (but not the record detail page). on the search results page, the white background basically ends at the right edge of the initially visible area (the area visible without horizontal scrolling). to the right of that is only green, and long |
| 16:10 |
senator |
titlescut off there instead of wrapping |
| 12:48 |
dbs |
error was at auth_concerto.sql:76 |
| 12:48 |
senator |
jeff: hmm, i think setting pos in URLVerify.pm was just cargo cult |
| 12:49 |
jeff |
senator: your self-awareness and honesty are appreciated. thanks! :-) |
| 12:49 |
senator |
it looks to me, too, like nothing actually cares about the position of cbrebi rows. i guess they don't really have an intrinsic order |
| 12:49 |
senator |
no prob. i would want to test that the link checker still works after any patch that loses that field, just to be on the safe side, of course |
| 12:50 |
jeff |
i'm not proposing losing the field, just doing some recon as i consider adding a "sort by date added to bucket" feature somewhere |
| 12:51 |
senator |
ah |
| 12:56 |
dbs |
Fails on the second auth_concerto record, which is the first to contain unicode XML char entities |
| 16:35 |
Bmagic |
so, fine_generator knows not to create those rows.... my question is which table is it using to decide weather or not to generate inserts into money.billing |
| 16:35 |
jeff |
Bmagic: i think Dyrcona's advice is going to be most useful for you -- you may find that you need to clear the stop_fines and stop_fines_reason for the circulations in question. |
| 16:35 |
Dyrcona |
Bmagic: action.circulation |
| 16:35 |
jeff |
Bmagic: but please consider doing this on a test copy of the database -- it would make me feel much better. :-) |
| 16:36 |
Bmagic |
do you mean the action.circulation - stop_fines (text) stop_fines_time ? |
| 16:36 |
Dyrcona |
yep. |
| 16:37 |
jeff |
Bmagic: yes. sorry, i stated their names incorrectly. :-) |
| 16:42 |
jeff |
most/all of those are set at checkout time. changing the policy/matchpoints in the staff client will not affect existing checkouts. |
| 16:42 |
Bmagic |
I see, would it be cleaner to wipe the rows and import from csv again? |
| 16:43 |
Dyrcona |
Bmagic: maybe. how many rows are you talking about? |
| 16:43 |
jeff |
Bmagic: depends on how you originally imported things. possibly. experimentation on a test copy may be required to answer that question -- lots of variables involved that are only specific to your situation. |
| 16:43 |
Bmagic |
less than 1k |
| 16:44 |
Bmagic |
stop_fines needs to be blank for fine_generator to go again? |
| 16:44 |
Bmagic |
My test set shows "MAXFINES" |
| 16:44 |
jeff |
i'm torn between the trouble of disabling triggers and deleting the rows from action.circulation vs just fixing things in place. i'd almost lean toward fixing in place for that smaller number. |
| 16:44 |
Dyrcona |
both stop_fines and stop_fines_time should be null. |
| 16:45 |
Bmagic |
GOTCHA |
| 16:45 |
* Dyrcona |
leans toward agreeing with jeff. :) |
| 16:45 |
jeff |
ideally you'd have a test copy where this issue was discovered, and could just re-do everything from a pristine copy, but ideals are elusive. |
| 16:45 |
Bmagic |
yeah - the deal is, there have been 3 weeks of live updates to the db since the migration |
| 16:45 |
jeff |
we had lots of "not apparent until in production" post-migration cleanup. :-) |
| 16:46 |
jeff |
(and there are several present who may declare that a huge understatement) |
| 08:59 |
phasefx |
circ.holds.hold_has_copy_at.alert ? |
| 09:00 |
phasefx |
and circ.holds.hold_has_copy_at.block |
| 09:01 |
phasefx |
not quite the same |
| 09:02 |
mmorgan |
mrpeters: Just tested this on our 2.3.7 system. |
| 09:02 |
DPearl |
Is the hackaway in the same library room today? |
| 09:02 |
mmorgan |
Attempted to place a hold on a bib for a patron who had a copy checked out and it was unsuccessful. Problem HOLD_ITEM_ALREADY_CHECKED_OUT with the option to override. |
| 09:03 |
dbs |
bshum: yeesh, the 800px -> 850px has a very bad smell attached to it (the whole px-width thing); why not just put all of the select boxes on a single "line" and let them wrap to the appropriate width? |
| 10:43 |
dbs |
In which case we could add a label + a border to group them, no matter how they break |
| 10:44 |
paxed |
legend? |
| 10:44 |
dbs |
legend-ary! |
| 10:45 |
* rfrasur |
opens "Evergreen 2.4 Testing Documents" with fear and trepidation. |
| 10:45 |
dbs |
Sorry. What I said was, with the current approach, we can remove the special <600px MOPAC CSS |
| 10:45 |
paxed |
koha seems to use legends all over the place. |
| 10:46 |
dbs |
because it's truly responsive, to whatever size of screen you have. |
| 13:33 |
jeff |
and now it's up. |
| 13:33 |
jeff |
> key can be any one of ISBN, OCLC, LCCN, OLID and ID (case-insensitive) |
| 13:47 |
dbs |
Learning point: design for mobile first! |
| 13:51 |
phasefx |
design for testing first, too, but at least one test tool makes use of accessiblity libraries for working the UI, so you can do both |
| 13:52 |
jeff |
man. i thought isbns were messy. lccns and oclc nums are almost worse. |
| 13:54 |
eeevil |
how upgrade-safe are the changes that have been made thus far? |
| 13:54 |
rfrasur |
thanks bshum |
| 13:58 |
pinesol_green |
Launchpad bug 1221411 in Evergreen "Translating the basic search bar is troublesome" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1221411 |
| 13:58 |
dbs |
That's kind of the whole point of a responsive design: it's one design. |
| 13:58 |
rfrasur |
is this referring to font size? sorry...audio is a little hit or miss |
| 13:59 |
dbs |
We were evaluating them on their own merits. And even tested with IE (up to this morning, anyway) |
| 13:59 |
dbs |
rfrasur: all of the changes |
| 13:59 |
rfrasur |
oh...sorry...I meant the 12/14 conversation |
| 13:59 |
|
bott_otr joined #evergreen |
| 14:00 |
dbs |
paxed: nope |
| 15:00 |
eeevil |
array in hand, use foreach; iterator pattern, use while |
| 15:01 |
eeevil |
Dyrcona: also, switching to while means you can use the variable directly, no need to deref and re-ref |
| 15:01 |
eeevil |
also, \@data will be faster (and less memory hungry) than [@data] ... though that may be a micro-optimization in your use case |
| 15:02 |
Dyrcona |
eevil: I'll give it a try, though testing with ten records it won't be noticeable. |
| 15:02 |
Dyrcona |
eeevil ^ |
| 15:02 |
eeevil |
indeed it wont |
| 15:02 |
eeevil |
but, while++ |
| 11:00 |
* dbs |
notes that AngularJS is a framework largely built by Google |
| 11:01 |
paxed |
i'm not convinced upgrading to newer xulrunner will help in the long run. |
| 11:01 |
eeevil |
dbs: and dojo is heavily supported by IBM ... /me attempts to tug at dbs' heartstrings |
| 11:01 |
dbs |
paxed: testing required for _any_ approach, obviously |
| 11:01 |
paxed |
dbs: yeap |
| 11:01 |
dbs |
eeevil: great reason to go angular :) |
| 11:02 |
jeff |
i think what's being discussed is abandoning xul, then xulrunner, but at some point along the way we may support newer xulrunner before exiting it completely. |
| 11:03 |
phasefx |
autohotkey |
| 11:03 |
paxed |
if i get the chance i'll try to pinpoint the xulrunner bug (as i think it is a xulrunner one) that causes the js not get the locale |
| 11:03 |
eeevil |
constrictor is coming back ... VM coming soon |
| 11:03 |
phasefx |
very difficult to use as a general testing framework, but possible |
| 11:04 |
jeff |
i'm inclined to forget testing the xulrunner staff client, and focus on testing and instrumenting the new web-based experiment. |
| 11:04 |
dbs |
jeff++ # thus selenium |
| 11:04 |
Dyrcona |
+elebenty!! |
| 11:05 |
bott_otr |
AngularJS example: function BeerCounter () on homepage. What more do you need? |
| 11:05 |
* phasefx |
thinks selenium would be great for testing web-based stuff.. horrified at the notion of putting selenium into xulrunner, if anyone is thinking of that |
| 11:06 |
|
Dyrcona1 joined #evergreen |
| 11:06 |
jeff |
phasefx: too bad. we're hacking on putting selenium into xulrunner RIGHT NOW. |
| 11:06 |
jeff |
(no, we're not) |
| 11:07 |
jeffdavis |
kmlussier++ |
| 11:08 |
eeevil |
(see: wai-aria in tpac) |
| 11:08 |
dbs |
eeevil: yep |
| 11:11 |
jeff |
i am amused at the idea of testing a receipt printer shim by printing a few hundred receipts to a bank of printers |
| 11:12 |
* dbs |
is torn between mobile catalogue and marc export |
| 11:13 |
dbs |
marque export, to be more canadian |
| 11:14 |
rfrasur |
nice |
| 11:18 |
|
acoomes joined #evergreen |
| 11:19 |
bshum |
maybe tomorrow, we can get phasefx on the big screen to do a rundown of QA stuff :) |
| 11:19 |
bshum |
(or others) |
| 11:19 |
dbs |
dojo and angular, fwiw, each have fairly well-integrated or closely associated test frameworks (Dojo = DOH, or at least used to be; Angular = Jasmine and Karma) |
| 11:20 |
* dbs |
half-raises a hand for mopac |
| 11:20 |
* dbs |
half-raises a hand for marc export |
| 11:21 |
jeffdavis |
Dyrcona: Sitka has some MARC export tools here - http://git.sitka.bclibraries.ca/gitweb/?p=sitka/sitka-tools.git;a=tree |
| 11:21 |
jeffdavis |
I didn't write that stuff and won't be in that hackaway session, but pointing it out in case it's of interest |
| 11:21 |
* rfrasur |
would like to hang out in the mopac |
| 11:28 |
dbs |
I'll poke Dyrcona later on today to hopefully kick export ideas around :) |
| 11:28 |
bott_otr |
mobile catalog thought, via dbs: http://bit.ly/18v26yf |
| 11:29 |
|
bott_otr1 joined #evergreen |
| 11:29 |
dbs |
I think my test server links are dead or at least no longer have that test CSS applied :/ |
| 11:30 |
dbs |
but I could probably get it back into shape |
| 11:31 |
bott_otr1 |
I'm pretty sure I burnt my VM with that work as well |
| 11:31 |
|
remingtron joined #evergreen |
| 11:31 |
eeevil |
bibtemplate! |
| 13:38 |
|
mrpeters joined #evergreen |
| 13:38 |
berick |
@quote add < Rogan_Ni> Star Wars |
| 13:38 |
pinesol_green |
berick: The operation succeeded. Quote #67 added. |
| 13:39 |
berick |
eeevil: ahh, no, i wish |
| 13:39 |
berick |
eeevil: just a slim set of fieldmapper stuff and some other test code |
| 13:40 |
eeevil |
ah. cool. so some custom module rewrapping |
| 13:40 |
tsbere |
Apparently hangouts doesn't like being logged in and active when the play store decides to auto-update it in the background. Go figure. |
| 13:42 |
eeevil |
senator: does your group have a hangout too? |
| 13:44 |
jboyer-home |
} |
| 13:44 |
senator |
eeevil: negative |
| 13:44 |
jboyer-home |
</style> |
| 13:45 |
senator |
we're working on serials, but are less focused than the other groups, participating also in mobile opac discussion and bug testing/merging for now |
| 13:45 |
berick |
eeevil: re, dojo, sort of. for the code I'm using, i had to do surprisingly little |
| 13:45 |
senator |
might lack enough cams |
| 13:45 |
berick |
i'm loading opensrf js directly (via script) and it all works find |
| 13:47 |
berick |
eeevil: i'd like to. my only concern is getting websockets running on the server side is non-trivial at this stage |
| 13:47 |
eeevil |
ah |
| 13:47 |
senator |
Dyrcona: your group seems real serious over there. can you ping me when you've got a second where you wouldn't mind an interruption? |
| 13:47 |
berick |
so it would limit who could test it.. |
| 13:48 |
rfrasur |
is the audio I'm hearing with regard to responsiveness the staff client discussion? or mopac? |
| 13:48 |
* dbs |
assumes Dyrcona is in a group of one :) |
| 13:48 |
phasefx |
rfrasur: I see you in the staff client one, fwiw |
| 11:13 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates their/there. |
| 11:13 |
bshum |
For LDAP goodness |
| 11:13 |
Dyrcona |
@hate English orthography |
| 11:13 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates English orthography. |
| 11:14 |
pinesol_green |
[opensrf|Galen Charlton] LP#1224647: remove two invalid tests - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=9028b02> |
| 11:14 |
dbs |
there there, dyrcona, it'll be okay |
| 11:15 |
dbs |
their they're, Dyrcona. |
| 11:15 |
Dyrcona |
yeah... |
| 12:03 |
gmcharlt |
... which reminds me of the ongoing discussions in Koha-land about the LiveDVD |
| 12:03 |
jbfink |
dbs: yeah, me too, and crouton solves the rest with lubuntu in a chroot. well, not the *rest*, but 98%, and that 2% is things I can't solve due to the chromebook kernel not supporting things. |
| 12:04 |
jbfink |
dbs: Yeah, zero idea about production, but since I'm wrapping *everything* in a container -- including the DB and all that -- I can see it getting too large to be usable. But this is all just me farting around. We're not even running EG here or anything. |
| 12:04 |
gmcharlt |
as it's challenging to communicate to folks who've set up a test system using one that it's not the ideal way to set up a production system |
| 12:04 |
dbs |
gmcharlt: GIVE US THE CREDIT FOR THE LIVEDVD K THX |
| 12:04 |
gmcharlt |
dbs: and yeah, there's that :) |
| 12:06 |
* rfrasur |
pops in and sees a pertinent discussion and now must scroll back. |
| 12:08 |
jcamins |
jbfink: if you need it to exit when the children exit so that docker can clean up, you could also just use wait, since everything has a pidfile. |
| 12:08 |
jcamins |
Kind of late to the party, though, sorry. |
| 12:11 |
jcamins |
gmcharlt: I feel like it's easier to explain with something like docker than with a livedvd because docker is explicitly developer-oriented, whereas the livedvd is more "this is how you install Koha on your computer." |
| 12:12 |
gmcharlt |
jcamins: really? From their home page... "The same container that a developer builds and tests on a laptop can run at scale, in production" |
| 12:13 |
gmcharlt |
of course, as I know nothing of docker, it may well be that it's perfectly plausible (with enough effort) to use it for a production setup |
| 12:13 |
jcamins |
gmcharlt: "Please note ... it should not be used in production." |
| 12:13 |
jcamins |
(from "Learn more") |
| 12:13 |
gmcharlt |
jcamins: mayhap they're trying to have their cake and eat it too? both statements are on their website, and are on the face of it contradictory |
| 13:00 |
* bshum |
sneaks in some lunch first. |
| 13:02 |
dbs |
bshum: direct database updates methinks :) |
| 13:02 |
bshum |
Could be lots of those too. We do like our direct SQL updates too :) |
| 13:04 |
dbs |
eeevil: I think the idea is that the dockerized version will be created from latest OpenSRF/Evergreen master + underlying distro packages on demand, so always up-to-date, vs static VMs |
| 13:05 |
dbs |
ergo good for testing perhaps |
| 13:07 |
eeevil |
dbs: ah ... I figured installation into a doc would still have to be done by hand ... if it can be automated, super! (see: wheezy installer wanting to be merged :) ) |
| 13:10 |
|
dMiller_ joined #evergreen |
| 13:13 |
dbs |
jbfink can correct me if I'm wrong, of course |
| 12:46 |
tony_ |
paxed_ "thru" |
| 12:46 |
dbs |
tony_: still need more of the failure log |
| 12:47 |
tony_ |
_dbs okay hang-on let me pull the logs |
| 12:47 |
dbs |
tony_: well, even just the last 10 lines that were printed to the screen |
| 12:47 |
dbs |
eeevil++ # that looks better. now to give it a shot on our test server... |
| 12:48 |
eeevil |
dbs: thanks, man! |
| 12:52 |
tony_ |
dbs_ Sep 11 18:10:22 finish-install: info: Running /usr/lib/finish-install.d/07brltty Sep 11 18:10:22 finish-install: cat: read error: Is a directory Sep 11 18:10:22 finish-install: sh: you need to specify whom to kill Sep 11 18:10:22 finish-install: info: Running /usr/lib/finish-install.d/07preseed Sep 11 18:10:22 finish-install: info: Running /usr/lib/finish-install.d/07speakup Sep 11 18:10:22 finish-install: info: Running /usr/l |
| 12:53 |
tony_ |
dbs_ Sep 11 18:10:22 finish-install: Disabling CD in sources.list Sep 11 18:10:22 finish-install: info: Running /usr/lib/finish-install.d/10clock-setup Sep 11 18:10:22 anna-install: Installing os-prober-udeb Sep 11 18:10:22 os-prober: File descriptor 3 (pipe:[1247]) leaked on lvs invocation. Parent PID 28714: log-output Sep 11 18:10:22 os-prober: File descriptor 4 (/dev/pts/0) leaked on lvs invocation. Parent PID 28714: log-output |
| 13:11 |
tony_ |
dbs what parts of this log do you want... |
| 13:11 |
tony_ |
dbs can't believe how many times I looked at this file and just couldn't see it |
| 13:13 |
eeevil |
dbs: wheeee.... I'll toss it on LP |
| 13:13 |
tony_ |
dbs here you go: ## ----------- ## ## Core tests. ## ## ----------- ## configure:2342: checking for a BSD-compatible install configure:2410: result: /usr/bin/install -c configure:2421: checking whether build environment is sane configure:2471: result: yes configure:2612: checking for a thread-safe mkdir -p configure:2651: result: /bin/mkdir -p configure:2664: checking for gawk configure:2694: result: no configure:2664: checking fo |
| 13:14 |
tony_ |
configure:2680: found /usr/bin/mawk configure:2691: result: mawk configure:2702: checking whether make sets $(MAKE) configure:2724: result: yes configure:2842: checking build system type configure:2853: error: /bin/bash ./config.sub ./configure failed |
| 13:14 |
dbs |
tony_: when you run ./configure --whatever, just the last screen or two of whatever gets printed to the screen. And ideally paste to http://pastebin.ca or the like |
| 13:18 |
tony_ |
dbs did that work for you |
| 13:21 |
eeevil |
dbs: separately, we should probably move the mrd join up to immediately after the core table |
| 16:14 |
|
AnoopGatewayChec left #evergreen |
| 16:35 |
pinesol_green |
[evergreen|Pasi Kallinen] Allow translation of acq.cancel_reason texts. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=777798d> |
| 16:43 |
pinesol_green |
[evergreen|Bill Erickson] LP#856688 OUS to disable org unit as hold pickup lib - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33206c4> |
| 17:01 |
bshum |
dbwells++ # got the LDAP test script to authenticate with the right credentials. Very handy, thank you sir! |
| 17:10 |
|
mmorgan left #evergreen |
| 17:13 |
|
hopkinsju joined #evergreen |
| 17:18 |
|
mrpeters left #evergreen |
| 11:10 |
Dyrcona |
dbwells: I plan to work on NCIP at the hackaway, but maybe. |
| 11:10 |
kmlussier |
bshum++ |
| 11:10 |
Dyrcona |
bshum kmlussier Neither have I. |
| 11:12 |
eeevil |
kmlussier: re https://bugs.launchpad.net/evergreen/+bug/1174860 ... it applies without conflict to rel_2_3. I have not attemtped to test its efficacy in that situation, but I don't think it will hurt. if reordering the query so that user input is last and widget-derived input comes first makes your 2.3 tests work, then yes, it should be backported |
| 11:12 |
pinesol_green |
Launchpad bug 1174860 in Evergreen "tpac: search filter groups don't play nicely with facets" (affected: 3, heat: 20) [Undecided,Triaged] |
| 11:13 |
kmlussier |
eeevil: OK, thanks. I'll see if I can test it on a 2.3 system. |
| 11:17 |
|
csharp_mtg joined #evergreen |
| 11:17 |
csharp_mtg |
ssh_port_blocking_on_wifi-- |
| 11:20 |
dbs |
running_an_ssh_server_on_port_443++ |
| 11:58 |
bshum |
Sigh |
| 11:58 |
jeff_ |
do you mean that they fall back to the user's preferences, or something else? |
| 11:58 |
|
jdouma joined #evergreen |
| 11:59 |
bshum |
That's worth testing I guess |
| 12:00 |
bshum |
I think if they don't have preferences, it defaults to no notification |
| 12:00 |
bshum |
Which is confusing the library |
| 12:00 |
bshum |
And the patrons too I guess |
| 12:00 |
bshum |
Since they'll never find out they have holds ready for them |
| 12:02 |
|
acoomes joined #evergreen |
| 12:03 |
dbs |
kraftsman-pac |
| 12:03 |
bshum |
Pretty much :) |
| 12:37 |
bshum |
Hmm |
| 12:37 |
* tsbere |
assumes the backend code doesn't look that stuff up because if the frontend had, say, email deselected we don't want the fact it was the user's default to re-enable it |
| 12:38 |
tsbere |
perhaps one solution would be the load the user's prefs into hidden fields in the kpac? At least then any defaults will apply... |
| 12:41 |
jeff |
that would be the quickest short-term solution, assuming that the kpac handlers will do anything with it. a quick experiment would be to manually create the hidden fields with values in them hardcoded in the appropriate template file in a test environment. |
| 12:42 |
jeff |
you might even find that the defaults / user settings have already been looked up and are available to the template with no handler-side modifications. |
| 12:42 |
jeff |
but if they aren't already there, that would be your next step. :-) |
| 12:43 |
|
mrpeters joined #evergreen |
| 12:47 |
bshum |
Alright, I guess I'll start looking a little at that. |
| 12:48 |
bshum |
Thanks jeff and tsbere |
| 14:52 |
bshum |
Sigh |
| 14:53 |
bshum |
Sorry jboyer-isl, not you. That idea sounds worthy of being added to the list. |
| 14:53 |
bshum |
Sighing about other things :) |
| 14:53 |
jboyer-isl |
bshum: I was going to ask if the KPAC holds testing went poorly. :) |
| 14:53 |
bshum |
jboyer-isl: I haven't even had time to get back to that yet. |
| 14:54 |
jboyer-isl |
One of those days, then, eh? |
| 14:58 |
senator |
jboyer-isl: i owe serials some attention and plan to be dbwells' best friend for some of that time, but as a #2 thing to slot in, yeah i would work on that |
| 14:58 |
bshum |
General opinion... should we keep https://bugs.launchpad.net/evergreen/+bug/1086458 open? Now that someone filed https://bugs.launchpad.net/evergreen/+bug/1224042 ? |
| 14:58 |
pinesol_green |
Launchpad bug 1086458 in Evergreen "Staff client memory leaks in 2.3 and later" (affected: 8, heat: 56) [High,Fix committed] |
| 14:58 |
pinesol_green |
Launchpad bug 1224042 in Evergreen "Staff client memory leaks in 2.4" (affected: 1, heat: 6) [Undecided,New] |
| 14:59 |
bshum |
The 2.3 one has lots of things we've tested/tried |
| 14:59 |
bshum |
But the 2.4 one is most recent and does have additional test information attempted by SITKA I guess. |
| 14:59 |
* jeff |
frowns at 1224042 |
| 14:59 |
bshum |
jeff: That's kind of what I was thinking. |
| 14:59 |
jboyer-isl |
senator: I can work on css/html later if I have to, so if time becomes available just let me know. I don't think I've really got enough experience with eg's guts to get going alone. (i.e. none at all with most of EGCatLoader...) |
| 16:17 |
|
kbeswick joined #evergreen |
| 16:35 |
hopkinsju |
bshum: I'm just now getting to look at the new site. Great job dude! |
| 16:35 |
hopkinsju |
bshum++ |
| 16:35 |
bshum |
hopkinsju: Still a work in progress, but thank you :) |
| 16:36 |
bshum |
dbwells: Is there anything in the logs that indicates why an LDAP authentication might be failing? |
| 16:36 |
bshum |
I'm trying to set up a connection for one of our schools and now I'm not sure if it's the AD user creds I was given or improper test account credentials. |
| 16:37 |
dbwells |
bshum: there are a number of different error messages. One second... |
| 16:38 |
dbwells |
bshum: looks like they are all debug level, and all start with "User login failed:". |
| 16:39 |
bshum |
dbwells: Okay, so I need to bump up opensrf_core.xml to debug level (4?) and then try again |
| 16:45 |
bshum |
Now I just have to figure out why that is and what it means... heh |
| 16:45 |
senator |
no, thank you |
| 16:46 |
dbs |
bshum: port may not be open... credentials could be bad... lots of possibilities with LDAP :) |
| 16:46 |
bshum |
dbs: Yep, that's what I figured. |
| 16:47 |
bshum |
I wish there was an easier way to test this stuff. Stupid LDAP |
| 16:52 |
jeff |
Dyrcona++ for JSONPrefs -- interesting |
| 16:54 |
pastebot |
"dbwells" at 64.57.241.14 pasted "test LDAP bind credentials" (8 lines) at http://paste.evergreen-ils.org/12 |
| 16:55 |
dbwells |
bshum: your LDAP stuff is failing at the admin bind stage, so I would use something simple like the paste above to test the credentials. |
| 16:55 |
dbwells |
bshum: If you can bind, you will get a '0' to print out. |
| 16:55 |
bshum |
dbwells: Thank you sir, that will be mighty helpful indeed. |
| 16:56 |
dbwells |
bshum: obviously, you will need to change the hardcoded stuff in there to whatever your values are for hostname, authid, and password. |
| 16:57 |
bshum |
dbwells: Yep, just tried that and got 49 back. Which looks to be a basic bind error |
| 12:11 |
gmcharlt |
er, more of a TA role was what I had in mind :) |
| 12:11 |
csharp |
heh |
| 12:16 |
|
smyers_ joined #evergreen |
| 12:33 |
paxed |
dbs: ok, i now definitely have that opensrf fix. and it doesn't help. |
| 12:34 |
paxed |
dbs: on linux, it usually(?) works. on windows, not at all. |
| 12:37 |
paxed |
would anyone be willing to test this for me? http://62.148.106.91/staff_client/ (use the _testing.exe one), and use that same server to log on. egadmin/egadmin |
| 12:41 |
paxed |
this isn't good. because we should be deploying in few months ... |
| 12:48 |
dbs |
paxed: um, what server? |
| 12:49 |
paxed |
^ |
| 12:50 |
paxed |
the ip |
| 12:50 |
csharp |
paxed: testing... what should I be looking for? |
| 12:50 |
paxed |
csharp: change the staff client language to finnish. see if patron registration is in english or in finnish. |
| 12:50 |
csharp |
(btw, it's weird in an awesome way to see all this finnish!) |
| 12:50 |
csharp |
ah - ok |
| 12:54 |
csharp |
I'm creating a new profile to see if that changes anything... |
| 12:56 |
csharp |
yep - still English |
| 12:56 |
paxed |
both OpenSRF and Evergreen are current master |
| 13:00 |
csharp |
paxed: if I can help test anything else, just let me know |
| 13:00 |
paxed |
i have no idea how to proceed further. |
| 13:02 |
csharp |
sorry, I haven't needed to know this, so I just don't know... at what point should fi-FI be loaded? |
| 13:02 |
csharp |
is it done in the build process or on the fly somehow? |
| 13:06 |
bshum |
paxed: Tested with Linux side and it also doesn't play nicely. |
| 13:06 |
bshum |
(not that you need the extra confirmation I guess) |
| 13:08 |
csharp |
okay, so this - http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=build/i18n/po/fm_IDL.dtd/fi-FI.po - is where the text is that *should* be loaded in the patron registration screen, right? |
| 13:10 |
* csharp |
reads the GNU gettext overview, which answers his questions |
| 13:11 |
csharp |
http://www.gnu.org/software/gettext/manual/html_node/Overview.html |
| 13:21 |
|
_bott_ joined #evergreen |
| 13:29 |
|
DPearl joined #evergreen |
| 13:35 |
|
Dyrcona joined #evergreen |
| 13:43 |
dbwells |
paxed: Maybe you already know all this, but I am trying to familiarize myself with how the translated IDL works. In testing, I could get the translated IDL labels to show in the Patron Reg screen in Firefox. |
| 13:43 |
dbwells |
Here is what I did: |
| 13:44 |
dbwells |
1) In about:config, I set the intl.accept_languages = fi-FI |
| 13:44 |
dbwells |
2) cleared cache, and browsed to http://62.148.106.91/eg/actor/user/register |
| 13:46 |
dbwells |
The 'IDL2js' Apache module looks first in the query string for a locale, then in the 'Accept-Language' header. Since I don't see the locale set in any IDL2js requests, I am assuming it is expecting the "Accept-Language" header to be set. |
| 13:47 |
dbwells |
I don't know how that is supposed to be set in the staff client, but you could use about:config to set it there if needed. |
| 13:48 |
paxed |
dbwells: setting the locale in the staff client sets intl.accept_languages |
| 13:49 |
dbwells |
paxed: where does one set the locale in the staff client? |
| 13:49 |
tsbere |
login screen |
| 14:25 |
dbs |
paxed: you've added alert() or console.log() stuff to dojo/fieldmapper/IDL.js to check on the value of OpenSRF.locale? |
| 14:26 |
paxed |
dbs: istr i did last week, and OpenSRF.locale was '' or something like that - but i could be mistaken |
| 14:27 |
dbs |
That would be a helpful piece. As would seeing if that block of code where the dojo.xhr() call is made is even ever invoked |
| 14:28 |
paxed |
dbs: ah, right - i think that piece of code was never executed in my tests. |
| 14:32 |
paxed |
just put an alert in IDL.js before the dojo.xhrGet() to show OpenSRF.locale - and it just doesn't happen. |
| 14:35 |
|
jbfink joined #evergreen |
| 14:35 |
jbfink |
hey people, help a sleep deprived dude out: |
| 14:35 |
jbfink |
in http://evergreen-ils.org/documentation/install/README_2_4.html section 9, in the eg_db_config thing, what is the right value for <port>? |
| 14:56 |
bshum |
jbfink: Ah, interesting. |
| 14:57 |
berick |
paxed: well, i'm only partly paying attention, but it sounds like the locale is not making it from the staff client to the IDL2js, correct? |
| 14:58 |
eeevil |
paxed: I'm trying to reason in the general area of the problem ... to see if there's some foundational logic problem that we're just now discovering. I think dbwells may be onto something, though, with the oils:// scheme theory |
| 14:59 |
* phasefx |
remembers testing the IDL2js patch for localization support and having it work, specifically with the patron editor |
| 14:59 |
* eeevil |
wonders if there's some way to log incoming headers that apache sees |
| 15:00 |
phasefx |
or, I vaguely remember that |
| 15:04 |
berick |
paxed: is the patron editor what you're looking at? |
| 15:23 |
berick |
the conversation from 14:15 (eastern) says IDL labels are now working.. |
| 15:23 |
jbfink |
now gotta figure out a programmatic way to change ejabberd passes, reflect changes in opensrf_core.xml, and also everything else I assigned a very lame password to. |
| 15:24 |
moodaepo |
bshum++ |
| 15:24 |
paxed |
berick: the idl labels are working because i tested a hard-coding the locale in IDL2js.pm |
| 15:24 |
berick |
oh, ok |
| 15:24 |
|
18WAENSG7 joined #evergreen |
| 15:24 |
paxed |
berick: i'll remove that test, and restart eg &c to clear the cache |
| 15:24 |
berick |
paxed: mind testing this? user/berick/staff-web-ui-idl-locale |
| 15:25 |
berick |
@ working |
| 15:25 |
pinesol_green |
berick: Go away, or I'll replace you with a very small shell script! |
| 15:25 |
|
zerick joined #evergreen |
| 15:26 |
berick |
i don't know why accept-lang is not coming through, but that patch will take advantage of the already-parsed locale and relay it to IDL2js |
| 15:52 |
paxed |
berick: https://62.148.106.91/eg/actor/user/register |
| 15:52 |
paxed |
in firefox, the IDL are in english, the string already in the page are in finnish. |
| 15:53 |
paxed |
you mean apache logs or osrfsys.log or what? |
| 15:55 |
berick |
apache error logs (e.g. /var/log/apache2/error.log) |
| 15:58 |
berick |
that's odd the IDL is english in FF. the IDL link in the source is correct and returns finnish. wonder if a clear-cache is needed in the FF test. /me can't see the IDL strings in the page w/o a login |
| 15:58 |
paxed |
berick: egadmin/egadmin |
| 15:58 |
paxed |
it's a dev server |
| 15:59 |
berick |
phasefx: thanks.. i'm getting finnish for the IDL labels there. |
| 16:06 |
berick |
.label |
| 16:07 |
berick |
hm, ok, something getting cached somewhere? |
| 16:07 |
paxed |
ergh. |
| 16:07 |
dbwells |
berick: Not sure if it helps (not following closely), but I was earlier able to use about:config in FF to set the intl.accept_languages = fi-FI manually, if that helps for testing. |
| 16:07 |
berick |
ah, thanks dbwells |
| 16:07 |
paxed |
well, the linux one shows everything in finnish. the windows one doesn't show the page strings, only idl labels, in finnish. |
| 16:08 |
berick |
w/ that (fi-FI), it's all finnish for me (in FF) |
| 16:25 |
berick |
ok, yeah, that should pretty much never be empty |
| 16:25 |
berick |
if it's being used |
| 16:26 |
berick |
error logs must be going somewhere else |
| 16:26 |
jeff |
Unfortunately, testing with this implementation shows that the mandatory UniqueUserId/UserIdentifierValue is discarded and only the value of UserOptionalFields/VisibleUserId/VisibleUserIdentifier is stored, and used for subsequent requests (in the UniqueUserId/UserIdentifierValue field, of course) |
| 16:26 |
berick |
also, to confirm, the template source in the linux staff client shows the same lang/xml:lang of fi_fi ? |
| 16:27 |
paxed |
berick: yes |
| 16:27 |
berick |
crazy |
| 16:35 |
paxed |
phasefx: interesting though that FF shows the page in Finnish, but the login texts in english, and the page lang/xml:lang = en_us ... |
| 16:37 |
dbwells |
jeff: right, the second. We didn't want users getting a new account whenever they got a new barcode. If they would just "believe" the UniqueUserId we sent them, all would be fine. |
| 16:38 |
* tsbere |
has at least one vendor he wants to use unique IDs from evergreen but can never seem to get anyone willing to talk to him about it - They assume that barcodes never change or something. |
| 16:39 |
dbwells |
jeff: I think we even tested sending back nothing *but* the ID in the the lookupuser response, but it didn't matter; whatever the patron typed in to get looked up, that was their UniqueId for the rest of the interaction (based on my 5 months old memories, at least). |
| 16:41 |
paxed |
berick: |
| 16:41 |
paxed |
Sep 10 23:41:23 egdev apache2[31157]: [debug] EGWeb.pm(77): [client 62.240.71.4] egweb: messages locale = fi_fi |
| 16:41 |
paxed |
Sep 10 23:41:24 egdev apache2[31166]: [debug] IDL2js.pm(79): [client 62.240.71.4] Invalid IDL2js locale ''; using en-US |
| 16:42 |
jeff |
dbwells: yeah. i'm testing a little more, but i've seen nothing that would contradict that. |
| 16:43 |
berick |
paxed: which test does that match? |
| 16:43 |
berick |
which client/locale/etc, i mean |
| 16:44 |
paxed |
berick: windows client, finnish. and shows english, of course. |
| 16:44 |
berick |
paxed: hm, did you remove my working patch? |
| 16:47 |
phasefx |
if I change the URL for the frame containing the patron editor to /IDL2js, I get a decidedly English set of javascript back |
| 07:08 |
kmlussier |
@later tell bshum 246 should be part of the alternative title index, unless the 2nd indicator is set to 1, in which case it should be part of the translated title index. |
| 07:08 |
pinesol_green |
kmlussier: The operation succeeded. |
| 07:09 |
|
jboyer-isl joined #evergreen |
| 07:10 |
kmlussier |
@later tell bshum In either case, I would expect it to show up in a browse search if the browse flag is set to true. But, no, I didn't test it specifically. |
| 07:10 |
pinesol_green |
kmlussier: The operation succeeded. |
| 07:53 |
bshum |
kmlussier: Ah, cool thanks. I will ask Mary to check her examples for indicator flags. |
| 07:54 |
bshum |
We'll have to look in production cause we're live on new master! :D |
| 07:58 |
|
collum joined #evergreen |
| 08:02 |
kmlussier |
bshum: Somewhere in my notes, it says that the 246 with 0 in the 2nd indicator are not indexed as an alternative title. However, I'm not sure where I got that information. It doesn't line up with what I see here: http://www.loc.gov/standards/mods/v3/mods-mapping-3-2.html. |
| 08:09 |
|
Shae joined #evergreen |
| 08:12 |
bshum |
kmlussier: Hmm, thanks. I'll note that in my testing later today. |
| 08:22 |
|
mrpeters joined #evergreen |
| 08:26 |
bshum |
csharp++ GPLS++ awitter++ |
| 08:26 |
bshum |
For keeping the servers happy. :) |
| 08:27 |
bshum |
(and flexible) |
| 08:27 |
csharp |
;-) |
| 08:28 |
csharp |
also, after I solve a networking kink, we can get mundungus up and moving which will allow for community admins to administer the VM host |
| 08:29 |
bshum |
Cool! |
| 09:45 |
|
RoganH joined #evergreen |
| 09:53 |
bshum |
kmlussier: Looking at the mods32.sql |
| 09:53 |
moodaepo |
bshum++ |
| 09:53 |
bshum |
It seems like the metabib_field draws from "alternative-nfi" |
| 09:53 |
|
rjackson-isl joined #evergreen |
| 09:53 |
bshum |
And that in turn does a test for ind1>0 to grab the right substring or not. |
| 09:54 |
bshum |
Other than that, I don't see anything in the mods32 for 246 or alternative title info |
| 09:54 |
bshum |
but I'm definitely not showing any 246 information for a particular bib record |
| 09:54 |
bshum |
Kind of weirding me out |
| 09:55 |
bshum |
For giggles, the ind2 is 0. But even changing that to 1 or whatever doesn't do anything new. |
| 09:55 |
bshum |
So I don't know why it doesn't work yet. |
| 09:59 |
eeevil |
bshum: first thing I'd check is to be super-double-extra sure that config.xml_transform.xslt contains what you believe it to contain ... |
| 10:01 |
bshum |
eeevil: I took a look at that and it seemed right. |
| 10:01 |
bshum |
Or at least no different than what I saw in the .sql version |
| 10:12 |
jboyer-isl |
I don't trust it at all, but a school wants options for their Macs. :) |
| 10:13 |
bshum |
Not ready to build your own mac clients? |
| 10:13 |
bshum |
(not that I fully trust that either) |
| 10:14 |
jboyer-isl |
At least the xulrunner in the app bundle doesn't change on it's own. I think they were interested in the extension because we don't have the OS X client available on our manualupdate.html page. (Don't really want to commit to supporting it, because there aren't many Macs around here to try to test things) |
| 10:15 |
jboyer-isl |
bshum: I also thought you were having some issues with newer clients on Macs? Was that a master thing, or is it all newer xulrunners? |
| 10:16 |
bshum |
jboyer-isl: I don't have enough points of reference to test things. By that I mean I haven't had time to spin up more versions of Evergreen like 2.4, etc. to see if the problems persist. |
| 10:16 |
bshum |
I'll get to it. Sometime. |
| 10:16 |
bshum |
And yes, xulrunner on mac had some weird display bugs. |
| 10:16 |
jboyer-isl |
Ah, ok. Maybe I'll fight with that at home sometime and see what happens. |
| 10:17 |
bshum |
eeevil: I'm going to test that particular portion of the upgrade script again (the mods32 stuff) and see if it changes the xslt or generates some sort of better error telling me something |
| 10:18 |
bshum |
Though I may wait till after I can get a snapshot of the production DB to try again |
| 10:18 |
bshum |
So sometime tomorrow. |
| 10:18 |
bshum |
Though I suppose I should see if this is the case on our previous test server.... presumably it'd be broken there too. |
| 10:18 |
* bshum |
will look at that. |
| 10:19 |
eeevil |
bshum: I will await your report |
| 10:22 |
bshum |
Well that's just annoying |
| 10:22 |
bshum |
The mods32 entry on our test server has the right xslt entry for alternative-nfi |
| 10:24 |
bshum |
I don't know why this is weird. |
| 10:27 |
bshum |
And for the life of me I can't seem to find a metabib.title_field_entry for the bib record anyways. |
| 10:28 |
bshum |
On the test server, even with the proper xslt |
| 10:28 |
bshum |
Well, there are entries, just not for the alternative title |
| 10:30 |
* bshum |
goes back to do more digging |
| 10:31 |
bshum |
Oh, what the heck |
| 10:31 |
bshum |
Okay, I must be seeing things |
| 10:31 |
bshum |
Cause now I'm seeing the alternative-nfi in the xslt entry for mods32 |
| 10:32 |
bshum |
I must have done a bad copy/paste eeevil, sorry for scurrying down the wrong path. |
| 10:33 |
|
rfrasur joined #evergreen |
| 10:33 |
bshum |
Doesn't solve my missing entry problem, but at least it wasn't the upgrade script gone awry |
| 10:40 |
dbs |
jboyer-isl: MARC Editor won't work with recent versions of Firefox/XULRunner due to the removal of E4X XML support, so that much we know would be broken. |
| 10:41 |
dbs |
bshum: all in all, the CSS change doesn't hurt the planet too much; still functional. Lemme know when things settle down. |
| 10:44 |
bshum |
dbs: For me or for the site? :P |
| 14:54 |
bshum |
And then log back in and things seem fine again |
| 14:54 |
bshum |
Very weird. |
| 14:55 |
Dyrcona |
Vandelay? I never use it. Our catalogers curse it. |
| 14:56 |
bshum |
yeah it's vandelay |
| 14:56 |
bshum |
I'm pondering if this is either a side effect of the stuff we changed with dojo filters |
| 14:56 |
bshum |
Or if this is a problem with the new vandelay defaults |
| 14:56 |
bshum |
Slowly testing each thing |
| 15:07 |
bshum |
Well it's not the autogrid stuff, not that I expected it to be. |
| 15:07 |
bshum |
Alright, what else changed... |
| 15:08 |
Dyrcona |
@blame Evergreen |
| 15:08 |
pinesol_green |
Dyrcona: Evergreen musta been an Apple employee. |
| 15:13 |
jeff_ |
bshum: vandelay can be run in a browser, where you might have more ready access to debugging. is it possible that you have an issue with a single backend system or brick? |
| 06:03 |
|
kmlussier joined #evergreen |
| 07:04 |
|
kmlussier joined #evergreen |
| 07:18 |
|
jboyer-isl joined #evergreen |
| 07:36 |
eeevil |
@later tell csharp did I miss your thumbs-up on 2.4.2 smoke testing? |
| 07:36 |
pinesol_green |
eeevil: The operation succeeded. |
| 07:42 |
|
rjackson_isl joined #evergreen |
| 07:44 |
|
rjackson-isl joined #evergreen |
| 07:48 |
eeevil |
jeffdavis: it's not backwards. given (A has_a B) the only side that can be null is the A side (you may have B rows that are not referenced by A rows). you may want to test might_have there, if config.circ_matrix_matchpoint's column is nullable |
| 07:49 |
csharp |
eeevil: you did miss my thumbs up, yes |
| 07:49 |
eeevil |
csharp: ahh! good :) |
| 07:49 |
csharp |
it was in the midst of a lot of chatter ;-) |
| 12:02 |
|
acoomes joined #evergreen |
| 12:08 |
csharp |
tony_: what is the output of 'ps aux | grep ejabberd'? |
| 12:10 |
tony_ |
Hi csharp I got: ejabberd 1392 0.0 0.0 7416 320 ? S 11:53 0:00 /usr/lib/erlang/erts-5.8.5/bin/epmd -daemon root 15256 0.0 0.0 8108 920 pts/0 S+ 16:09 0:00 grep --color=auto ejabberd |
| 12:11 |
csharp |
tony_: when I run that command on a running test server, I get this: http://pastebin.com/2ZaajJnV |
| 12:12 |
csharp |
so it's possible ejabberd is not fully up and running |
| 12:12 |
csharp |
you could try restarting ejabberd? |
| 12:12 |
tony_ |
I tryied that and get the error that I first posted and I get the error when trying to shut it down as well |
| 12:13 |
tony_ |
I give the command osrf_ctl.sh -l -a stop all and I get the following error::::::: Exception: OpenSRF::EX::Jabber 2013-09-06T15:34:32 OpenSRF::Transport::SlimJabber::Client /usr/local/share/perl/5.14.2/OpenSRF/Transport/SlimJabber/Client.pm:150 Jabber Exception: Could not open TCP socket to Jabber server: IO::Socket::INET: connect: Connection refused |
| 12:19 |
csharp |
tony_: what is the output of '/etc/init.d/ejabberd restart'? |
| 17:02 |
|
mrpeters left #evergreen |
| 17:06 |
|
mllewellyn left #evergreen |
| 17:22 |
|
akilsdonk_ joined #evergreen |
| 17:28 |
bshum |
@later tell kmlussier Did anyone ever test having the 246 alternate title show up as part of browse search? Apparently this doesn't seem to be a presently indexed entry. |
| 17:28 |
pinesol_green |
bshum: The operation succeeded. |
| 17:28 |
bshum |
My guess is just tossing it in as another custom index, like variant title or whatnot would do the trick. |
| 17:29 |
bshum |
@marc 246 |
| 08:45 |
|
mrpeters joined #evergreen |
| 08:45 |
paxed |
*insert meme* FIELDMAPPER Y U SHOW ENGLISH? |
| 08:47 |
dbs |
paxed: yeah, but I suspect your patch to make accept_languages hold multiple languages will break other things |
| 08:47 |
paxed |
most likely. |
| 08:48 |
paxed |
dbs: could you test if you can get fieldmapper to show finnish? user/paxed/oplibfi has our current changes. |
| 08:49 |
paxed |
all i can do is short-circuit IDL.js so it loads the full xml every time, or whatever, and then it shows finnish. |
| 08:50 |
dbs |
I'm just looking at dojo/fieldmapper/IDL.js, which uses the Accept-Language header to load the language of choice based on OpenSRF.locale. Maybe try testing your grid with that? |
| 08:51 |
paxed |
but it never even goes that far. i've tried changing OpenSRF.locale in that to hardcoded 'fi-FI' |
| 08:52 |
dbs |
curl -H "Accept-Language: fi-FI" http://localhost/reports/fm_IDL.xml |
| 08:53 |
|
Shae joined #evergreen |
| 08:57 |
dbs |
paxed: Check your Apache configs |
| 08:57 |
Dyrcona |
Yeah, I love it when stuff like that happens. |
| 08:58 |
|
rfrasur joined #evergreen |
| 09:00 |
paxed |
i wonder if it's the different distro... |
| 09:00 |
paxed |
ahwell, need to test moar. |
| 09:00 |
Dyrcona |
Probably different package version, and one has a bug that the other doesn't. |
| 09:01 |
paxed |
my home box runs the bleeding edge debian. |
| 09:01 |
* Dyrcona |
gives libyaz4 on Ubuntu the hairy eyeball. |
| 09:02 |
Dyrcona |
testing or sid? |
| 09:02 |
paxed |
testing |
| 09:02 |
paxed |
not quite insane enough for sid :P |
| 09:03 |
paxed |
hm. curl -H shows it in finnish. |
| 09:08 |
Dyrcona |
i18n ain't easy. |
| 09:08 |
Dyrcona |
but it should be. |
| 09:08 |
paxed |
*insert meme* THE NUMBER OF I18N PATHS ... IS TOO DAMN HIGH |
| 10:20 |
csharp |
but it may be the order in which I did that that made it so I didn't recreate the problem |
| 10:20 |
krvmga |
they didn't tell me the browser. i cant duplicate it either. |
| 10:20 |
krvmga |
i thought i'd mention it here in case anyone else had run across something similar. |
| 10:20 |
csharp |
oh - yeah this is FF23 on Fedora 19 |
| 10:21 |
csharp |
so probably not a good test case for run-of-the-mill patron usage ;-) |
| 10:23 |
rfrasur |
(getting a book catalog from a company named "Firefly" makes me want to order all their books. Just saying) |
| 10:24 |
krvmga |
rfrasur: i could see where you would get a feeling of serenity from doing that. |
| 10:24 |
rfrasur |
krvgma++ #you know it |
| 10:25 |
krvmga |
lol |
| 10:25 |
rfrasur |
browncoats++ |
| 10:25 |
krvmga |
rfrasur++ |
| 10:25 |
jeff |
rfrasur: in any event, after some research and testing, the fix was as simple as unchecking a single checkbox and restarting the selfchecks. :-) |
| 10:25 |
rfrasur |
oh, and I also watched a documentary about the fan stuff as well. |
| 10:26 |
krvmga |
yes, but do you have the complete book of scripts? |
| 10:26 |
krvmga |
as some of us *cough* do |
| 10:51 |
paxed |
(the boxes are set in a table - i know we'll want one of the boxes to be much taller than the others, so a rowspan for it would make sense) |
| 10:54 |
paxed |
would looke like this: http://bilious.alt.org/~paxed/eg/asboxen.png |
| 11:03 |
krvmga |
paxed: mine looks like this atm http://www.randompractice.com/adv_srch.png |
| 11:04 |
paxed |
yeap, i'm just running ~master to test things, i know our people want to change it. i'm just thinking if i should add the configurability as a patch, instead of hard-coding. |
| 11:05 |
paxed |
and not just pondering anymore, i'll add it to the bug 1220310 |
| 11:05 |
pinesol_green |
Launchpad bug 1220310 in Evergreen "Set heights for advanced search boxes in config.tt2" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1220310 |
| 11:14 |
* eeevil |
just noticed that relator codes are in the tpac as constants ... man, I wish those had been added as coded value maps instead :( (one less i18n path, useful outside the tpac (like, in the MARC editor, eventually), probably more benefits) |
| 11:17 |
dbs |
patches welcome, dude. |
| 14:05 |
yboston |
I think we can proceed for now |
| 14:05 |
yboston |
BTW, I just sent an email to the DIG list with some survey related links for a topic I want to address at some point |
| 14:05 |
krvmga |
got it |
| 14:06 |
yboston |
#topic Updates from Content Coordinators |
| 14:06 |
yboston |
We will continue having the content corrdinators try out the "#topic" AND "#info" Meetbot commands for their reports |
| 14:06 |
yboston |
So content coordinators, please use "#topic" for the first post/line of your report |
| 14:06 |
yboston |
then use "#info" for every other chat post/line of your report. |
| 14:06 |
yboston |
for example... |
| 14:06 |
yboston |
#topic this is a test report first post/line |
| 14:06 |
yboston |
#info this is a test report second post/line |
| 14:06 |
yboston |
Again, for everyone else participating in the meeting, don't worry about using any Meetbot commands, participate normally |
| 14:07 |
kmlussier |
Sorry, I don't have anything to report again. I've been really busy the past couple months with other activities. |
| 14:07 |
yboston |
no worries, you are leading the way for the next conference among other things |
| 14:07 |
kmlussier |
But with the 2.5 beta release on the horizon, I'm sure I'll have more to report at the next meeting. :) |
| 14:48 |
yboston |
except Kathy who has learned to do almost all (docs and dev) |
| 14:48 |
yboston |
I don't think so, |
| 14:48 |
kmlussier |
Ha! I know very little dev. But thank you anyway. :) |
| 14:48 |
yboston |
BTW, another requirement for a successful DIG hack-a-way is to have a test server at the ready with the concerto data set pre-loaded |
| 14:48 |
yboston |
also for when we try hacking at the conference |
| 14:49 |
yboston |
DIG needs to "run heavy" we finally get rolling |
| 14:49 |
yboston |
when we finally get going |
| 14:50 |
kmlussier |
I can ask edoceo about his community server. I find that he's usually very responsive if anyone has trouble accessing it. |
| 14:51 |
yboston |
he has been in the past, absolutely |
| 14:51 |
kmlussier |
But it might not be a bad idea to have a multiple communtiy server to have available if one is down. |
| 14:51 |
yboston |
to recap, it will benefit us as we try to increase participation to have ... |
| 14:52 |
yboston |
simple tasks for those that want to help, so they hit the ground running |
| 14:52 |
yboston |
we need to have test servers with the most recent version |
| 14:52 |
yboston |
we also need to tag the simple tasks so that we have those that can be addressed with a copy of Microsoft word to create documentation |
| 14:53 |
yboston |
and those that require just a little bit of asciidoc, etc |
| 14:53 |
yboston |
in other words, these are the are some of the reasons there so few of us :) |
| 14:53 |
yboston |
at this point |
| 14:53 |
rfrasur |
for now |
| 14:53 |
yboston |
:) |
| 14:53 |
rfrasur |
it'll get better |
| 14:56 |
yboston |
I have seen the debs go through a similar process, for example teaching new members to cut releases |
| 14:57 |
yboston |
they had to go back and write down their procedures to make them reproducible by others |
| 14:57 |
rfrasur |
I mean, of course, we want them...but if we can go out and teach people in our spheres...they can do some stuff and we can act as trainers/mediators. |
| 14:57 |
yboston |
BTW, we are at the 57 minute mark |
| 14:58 |
yboston |
#idea (suggested) requirement for a successful DIG hack-a-way is to have a test server at the ready with the concerto data set pre-loaded |
| 14:59 |
kmlussier |
As far as finding a place to list documentation needs, I would like to suggest that, unless somebody is willing to volunteer time to evaluate the project management options that are available and come up with a recommendation, we use our existing community tool - Launchpad. Becauswe otherwise we're going to keep talking about it and never getting the needs posted. |
| 14:59 |
yboston |
#idea prepare lists of documentation "low hanging" fruit for new comers and/or attendees tot he DIG hack-a-way |
| 15:00 |
rfrasur |
kmlussier: +1 so at least there can be some movement on it. If, down the road, a better management tool comes along, we can evaluate it then. |
