| Time |
Nick |
Message |
| 05:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:31 |
|
graced joined #evergreen |
| 07:39 |
|
rjackson_isl joined #evergreen |
| 07:55 |
|
graced joined #evergreen |
| 07:55 |
|
collum joined #evergreen |
| 07:59 |
csharp |
hmm - okay - I'm seeing a need for a link in the reporter between money.materialized_billable_xact_summary (Billable Transaction Summary) and action.circulation (Circulation) so that I can use things like last_billing_type and balance_owed when doing item list reports |
| 07:59 |
csharp |
the use case is a "lost and paid" report |
| 08:00 |
csharp |
anyhoo, just wondering if it makes more sense for the link to be on the action.circulation side or the mmbxs side (or both), and if it makes sense to add the same linkage to other reports sources |
| 08:00 |
* csharp |
is open to suggestions |
| 08:08 |
phasefx |
csharp: not sure how to make use of it in the reporter, but the link would be the id's? |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:16 |
phasefx |
csharp: if you're starting with Item as your source, you may want to add something similar to the "rlc" class in fieldmapper that handles the Last Circulation Date link |
| 08:21 |
csharp |
phasefx: oh - yeah, I can see that now |
| 08:21 |
csharp |
that's probably a better approach |
| 08:30 |
csharp |
ah - Billable Transaction has a Circulation Billing link - that may do what I need without further head-scratching |
| 08:30 |
|
Shae joined #evergreen |
| 08:35 |
|
mrpeters joined #evergreen |
| 08:35 |
|
julialima_ joined #evergreen |
| 08:35 |
|
mdriscoll joined #evergreen |
| 08:40 |
|
Dyrcona joined #evergreen |
| 08:44 |
|
maryj joined #evergreen |
| 08:51 |
|
ericar joined #evergreen |
| 09:09 |
|
krvmga joined #evergreen |
| 09:11 |
krvmga |
i'm doing a fresh install of eg and starting with installing opensrf. when i run autoreconf -i, i get a libtoolize message asking me to consider adding things to configure.ac and Makefile.am. i haven't seen this before. |
| 09:12 |
krvmga |
it's not clear if autoreconf -i is failing |
| 09:12 |
bshum |
krvmga: That's standard |
| 09:12 |
bshum |
By standard I mean, nothing unusual |
| 09:13 |
krvmga |
bshum: so i can ignore it? or do i have to make changes in configure.ac and Makefile.am? |
| 09:13 |
bshum |
See also: https://bugs.launchpad.net/opensrf/+bug/1272937 |
| 09:13 |
pinesol_green |
Launchpad bug 1272937 in OpenSRF "OpenSRF configure.am showing deprecation warnings with autoreconf -i step" (affected: 3, heat: 16) [Undecided,New] |
| 09:13 |
bshum |
krvmga: You can ignore it. |
| 09:13 |
krvmga |
bshum: thanks |
| 09:13 |
bshum |
They're just deprecation warnings. Not errors. |
| 09:14 |
bshum |
krvmga: With autoreconf -i you only do that on git installs, from a tarball OpenSRF, it's not a necessary step. |
| 09:15 |
bshum |
Might be why you never noticed before? Cause it's been doing those little warnings for years now. |
| 09:18 |
StomproJ |
Has anyone tested/used one of the new intel DDR4 memory based servers for postgresql? Does the increased memory bandwidth give a big boost in performance? |
| 09:18 |
bshum |
There's DDR4? :\ |
| 09:18 |
* bshum |
goes back to living under his rocks |
| 09:19 |
bshum |
StomproJ: Might be an interesting question to ask over in the #postgresql channel too :) |
| 09:21 |
bshum |
Hmm |
| 09:22 |
bshum |
@later tell gmcharlt Speaking of OpenSRF bugs to fix before 2.4.1, maybe we can wrap up https://bugs.launchpad.net/opensrf/+bug/1272937 (it's mostly done, just a tidbit question in my last comments) |
| 09:22 |
pinesol_green |
bshum: The operation succeeded. |
| 09:22 |
pinesol_green |
Launchpad bug 1272937 in OpenSRF "OpenSRF configure.am showing deprecation warnings with autoreconf -i step" (affected: 3, heat: 16) [Undecided,New] |
| 09:27 |
StomproJ |
bshum, check out http://ark.intel.com/products/81880/Intel-Server-Board-S2600TPF claims a 115GB/s memory bandwidth, compared to the 14GB/s that the DDR3 server my vendor is quoting me. |
| 09:42 |
|
yboston joined #evergreen |
| 09:45 |
jonadab |
That does sound like a potentially significant difference. If memory bandwidth is a major performance bottleneck for a particular deployment. |
| 09:59 |
|
goood joined #evergreen |
| 10:05 |
Dyrcona |
StomproJ: You might try asking in #postgresql. |
| 10:06 |
Dyrcona |
grabbing 0908 |
| 10:10 |
|
jwoodard joined #evergreen |
| 10:17 |
pinesol_green |
[evergreen|Remington Steed] LP#957466: Update editor/edit_date/source on overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=62510da> |
| 10:18 |
pinesol_green |
[evergreen|Jason Stephenson] LP#957466 Vandelay set the 905$u on imported bib records to current user. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=522b6ff> |
| 10:18 |
pinesol_green |
[evergreen|Jason Stephenson] LP#957466: Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe07338> |
| 10:43 |
jeff |
I've noticed an odd (to me) difference between xulrunner and webstaff, and I think it comes down to pcrud permissions vs open-ils.circ api permissions: |
| 10:47 |
jeff |
given a patron with open circulations at the CONS level (i can't recall offhand if those were generated by concerto or if that was me manually checking things out without having a workstation set), users without the EVERYTHING permission can't see the circs in the web client. |
| 10:47 |
jeff |
but they can in the xulrunner client. |
| 10:47 |
jeff |
I haven't yet given it a more realistic test (usually you wouldn't have circs at CONS, etc) |
| 10:48 |
berick |
jeff: does your login have global VIEW_CIRCULATIONS permissions? |
| 10:48 |
jeff |
And I'm going to take the opportunity to refresh/enhance my understanding of permissions in general, but I wasn't able to make the circs show in the web client even when making someone global admin and assigning them working locations across the org tree. |
| 10:49 |
jeff |
berick: i'll verify that specifically. one set. |
| 10:49 |
jeff |
er, "one sec" |
| 10:50 |
berick |
looks like it's also fleshing copy, workstation, call_number, record, and simple_record |
| 10:50 |
yboston |
kmlussier: got a minute to talk about authority related signoffs? |
| 10:50 |
berick |
so you'd need the necessary view perms on those. (but most of those are public, IIRC) |
| 10:51 |
yboston |
berick: heads up, I started buildign a new VM yesterday to sign off your authorites overlay code. Glad to see that you have a new rebased branch |
| 10:52 |
berick |
yboston++ |
| 10:52 |
berick |
great |
| 10:56 |
jeff |
berick: okay, fresh day, fresh approach, fresh results. i now no longer need to have EVERYTHING, but the behavior does remain changed between open-ils.circ and open-ils.pcrud with regard to permissions required (open-ils.circ is more permissive). |
| 10:56 |
jeff |
This may all be normal and expected, of course. |
| 10:57 |
goood |
berick: I don't know if you saw my note (as eeevil) last night, or responded ... no quassel core ATM, and lost goood's connection on monday (no log) |
| 10:58 |
goood |
berick: nm. irc logs tell the tail |
| 10:59 |
bshum |
++ # yay :) |
| 11:01 |
csharp |
lawgs++ |
| 11:01 |
|
dreuther_ joined #evergreen |
| 11:07 |
goood |
jeff: did you have a workstation set up (and logged out and back in) in the web client? ... which reminds me, we now have the capability to disable (without hiding) OUs in the org dropdown ... we should do that for the workstation UI so you can only select can_have_users OUs |
| 11:22 |
Dyrcona |
I should just call it a day. I'm messing up every other thing that I do. |
| 11:23 |
jeff |
goood: figured it out, thanks! |
| 11:56 |
dbs |
Ah that awesome moment when you choose "All hold requests" as your starting report source because you want *all* hold requests and you discover that it is in fact only the aged hold requests, which is far from all of them |
| 12:09 |
|
dreuther joined #evergreen |
| 13:08 |
|
sandbergja joined #evergreen |
| 13:21 |
|
buzzy joined #evergreen |
| 13:22 |
jonadab |
Hmm... looking at schemata, actor.usr has a passwd field but no salt field? I'm missing something, right? |
| 13:22 |
buzzy |
did any of you get the call a call for sponsors/exhibitors email from me on the the openils list? |
| 13:32 |
kmlussier |
yboston: I'm here now |
| 13:32 |
collum |
Just got it buzzy |
| 13:32 |
csharp |
buzzy: I got it at 1:29 p.m. |
| 13:34 |
yboston |
kmlussier: I sent you an email a little earlier. just letting you know I am building a Vm to test auth overlay. Also that, I if you had time/VM, that I have some auth code needing a sign-off bug 1403967 |
| 13:34 |
pinesol_green |
Launchpad bug 1403967 in Evergreen "Display 'subject heading thesaurus' value in Manage Authorities results" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1403967 |
| 13:35 |
buzzy |
great, thanks. i just did, too. for some reason, it didn't go through the first time |
| 13:37 |
|
mmorgan joined #evergreen |
| 13:41 |
|
maryj_ joined #evergreen |
| 13:42 |
kmlussier |
yboston: OK, good. I'm a little behind in my testing this week. |
| 13:43 |
kmlussier |
yboston: I can take a look at your code. |
| 13:44 |
|
maryj joined #evergreen |
| 13:53 |
jeffdavis |
jonadab: you are correct - passwords stored in the db are hashed but not salted |
| 13:55 |
Dyrcona |
Salt is applied when a user authenticates, but if someone grabs your database, you may have bigger problems than worrying about the user's password hashes. |
| 13:59 |
goood |
berick: re authority match sets 1) thanks for the parens update! 2) everything looks sane ... I'll be pushing it in |
| 14:04 |
berick |
goood++ |
| 14:04 |
berick |
many thanks |
| 14:09 |
jeffdavis |
Dyrcona: I don't want to beat a dead horse, but "you have bigger problems" isn't really an argument in favor of storing pwds insecurely. |
| 14:12 |
rangi |
just my 2cents, instead of adding a salt, (salts stored in the db don't help much, they can still be brute forced in a feasible amount of time) probably better to switch to bcrypt |
| 14:12 |
jeff |
There are few arguments for storing passwords without salt. I think there is agreement that we'd like to improve this. |
| 14:13 |
rangi |
http://codahale.com/how-to-safely-store-a-password/ |
| 14:13 |
Dyrcona |
We have mitigations against remote brute force. |
| 14:13 |
bshum |
I vaguely recall talking about this at the first Evergreen Hack-a-way and reaching the agreement jeff refers to. |
| 14:13 |
rangi |
jeff: the point is, salts dont help you, if someone has your db |
| 14:13 |
Dyrcona |
I know how to store passwords, and I agree that they should be salted. |
| 14:13 |
rangi |
its better to not use old hashing techniques |
| 14:13 |
rangi |
with or without salts |
| 14:14 |
Dyrcona |
That's the trouble with grandfathered data and backward compatibility. |
| 14:14 |
jeff |
rangi: hashes with salt help more than unsalted hashes, but it doesn't raise the bar nearly as high as something like bcrypt does. I think we're in agreement here. |
| 14:15 |
rangi |
one thing we did, is whenever someone logs in, fix their password |
| 14:15 |
* jeff |
nods |
| 14:15 |
rangi |
to ease the transition |
| 14:15 |
jeff |
that's a standard method of migration. |
| 14:15 |
jeff |
though i've also seen the (somewhat less effective) method of upgrading the stored password only on change |
| 14:16 |
rangi |
*nod* |
| 14:16 |
rangi |
does evergreen allow/enforce (koha doesn't yet) a password expiry? |
| 14:17 |
jeff |
not yet. |
| 14:17 |
rangi |
forcing people to change is probably a goodish thing to do i would think |
| 14:17 |
jeff |
though i'd like to see that also, especially for staff reasons. |
| 14:17 |
rangi |
yeah |
| 14:17 |
jeff |
forcing people to change a password doesn't help you upgrade the hash from one version to another -- least, not that I can see. |
| 14:17 |
Dyrcona |
We're doing that on our email server. Staff just \love\ it. |
| 14:18 |
rangi |
jeff if you combine it with the changing the hash on changing password |
| 14:18 |
jeff |
I'm more a fan of strong requirements and two factor auth than I am of forced expiry. |
| 14:18 |
rangi |
was what i was thinking |
| 14:19 |
jeffdavis |
You could always use known techniques to crack your unsalted MD5-hashed pwds in order to re-save them in a more secure form (bcrypt or whatever). :P |
| 14:19 |
jeff |
rangi: where technically possible, i would advocate migrating the hash on login instead of migrating it only on password change -- no expiry requirement there. :-) |
| 14:19 |
rangi |
yep, thats what we do |
| 14:19 |
jeff |
jeffdavis: yes. i've actually used that approach in another context. |
| 14:22 |
jonadab |
jeffdavis, Dyrcona Ok, thanks for the info. |
| 14:22 |
jonadab |
At least they're hashed, that's an improvement over our current situation with our existing ILS. |
| 14:23 |
jeffdavis |
Yes, AFAICT EG is better than common industry practice in this regard. |
| 14:27 |
|
dbwells_ joined #evergreen |
| 14:27 |
goood |
jonadab: fwiw, the auth app itself actually uses (a variant of) CHAP, so the neither the hash nor the cleartext goes over the network between the immediate client and evergreen proper. That said, tpac move the immediate client from the browser into mod_perl on the server, depending on SSL/TLS to protect the channel between browser and apache |
| 14:28 |
goood |
so, you can rainbow table a dump of the passwords, but can't capture them without attacking the database itself ... or being a malicious staff member |
| 14:30 |
jonadab |
Right, just plain hashed is obviously much better than cleartext in the DB. And yes, I know if someone from outside the library captures the DB there are larger privacy issues. |
| 14:30 |
jonadab |
Also I have no argument against bcrypt. |
| 14:31 |
goood |
bcrypt++ # indeed |
| 14:31 |
jeff |
jeffdavis: the "brute force the weak existing keys" works well in the scenario where the new system can't support the older storage method. |
| 14:32 |
jeffdavis |
I feel obliged to mention that I am actually wearing a 2600 t-shirt right now. |
| 14:33 |
Dyrcona |
heh |
| 14:33 |
jeffdavis |
^ not cred, just amusing coincidence |
| 14:34 |
jonadab |
And yeah, upgrading the hashing/salting/whatever on login is standard practice. |
| 14:34 |
jonadab |
(If the passwords are not hashed at *all*, you can upgrade them en masse during an upgrade or migration, which we'll obviously do when we move to Evergreen.) |
| 14:34 |
captncrunch |
jeffdavis: whatevs! |
| 14:35 |
jeffdavis |
lol |
| 14:36 |
csharp |
er... I appear to have two search.query_parser_fts() functions in our database |
| 14:36 |
jeff |
@praise namespaces |
| 14:36 |
* pinesol_green |
namespaces is one of the few who deserves to be praised |
| 14:36 |
|
jihpringle joined #evergreen |
| 14:36 |
jeff |
(just because we have no @sarcasticpraise) |
| 14:37 |
csharp |
they differ in the parameters they take, but looking at the 300.schema.staged_search.sql file, there's only one created in a stock EG |
| 14:37 |
csharp |
or am I missing something? |
| 14:37 |
jeff |
(and really, i should probably blame search_path) |
| 14:37 |
ldw |
csharp: we had a similar thing. I believe the one with fewer arguments if from an older version that was never DROPed. |
| 14:37 |
csharp |
ldw: thanks for that confirmation |
| 14:39 |
csharp |
I ask because the code to fix bug 925776 does not appear to be working - could EG still be calling the older version? |
| 14:39 |
pinesol_green |
Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 8, heat: 46) [Medium,Fix released] https://launchpad.net/bugs/925776 |
| 14:39 |
jeff |
yeah. new CREATE OR REPLACE without a DROP IF EXISTS of an already-present one is usually the cause. fresh 2.7 has one, our prod 2.5 has two. |
| 14:40 |
csharp |
ok |
| 14:42 |
csharp |
well, in any case, the fix for bug 925776 is not working for us and I'm seeking a cause - I'm beginning by attempting to rule out missing upgrade scripts/skipped steps |
| 14:42 |
pinesol_green |
Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 8, heat: 46) [Medium,Fix released] https://launchpad.net/bugs/925776 |
| 14:43 |
csharp |
I can see eeevil's fix for the bug in the longer/newer query_parser_fts function, though, which is why I was curious about seeing two |
| 14:43 |
csharp |
my example is http://next.gapines.org/eg/opac/results?bool=and&qtype=keyword&contains=contains&query=&bool=and&qtype=title&contains=contains&query=hot+zone&bool=and&qtype=author&contains=contains&query=castle&locg=53&pubdate=is&date1=&date2=&sort=&_adv=1 |
| 14:44 |
csharp |
that title shouldn't be showing for Putnam County Public Library since it's owned by a library in another system in the hierarchy |
| 14:44 |
jeff |
but this isn't a staff search... |
| 14:44 |
jeff |
so i would expect the cause/fix to be different. |
| 14:45 |
goood |
csharp: just to make sure the easy stuff is out of the way, it does not have a trancendant [sic] bib source, right? |
| 14:45 |
csharp |
lemme check |
| 14:47 |
csharp |
goood: actually, yes, it is set to transcendant |
| 14:47 |
jeff |
simple cause, simple fix. :-) |
| 14:47 |
goood |
:) |
| 14:48 |
csharp |
so set transcendant to false, and it should work? |
| 14:48 |
* csharp |
never wrapped his head around all this |
| 14:49 |
* csharp |
reads the FM: http://docs.evergreen-ils.org/2.6/_using_transcendent_bib_sources_for_electronic_resources.html |
| 14:49 |
goood |
yes. trancendant means "always show, always" |
| 14:49 |
goood |
they "transcend" location :) |
| 14:50 |
jeff |
if biblio.record_entry.source points at a config.bib_source entry with transcendant [sic] set to true, then that bib can appear in any search regardless of copies or located urls. |
| 14:50 |
csharp |
ha! it works |
| 14:50 |
csharp |
goood++ jeff++ # thanks |
| 15:08 |
kmlussier |
I'm working on bug 1422802 where we want to provide an option to use radio buttons to select a part on the place holds screen. |
| 15:08 |
pinesol_green |
Launchpad bug 1422802 in Evergreen "Parts need to be more visible on the place holds screen" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1422802 - Assigned to Kathy Lussier (klussier) |
| 15:08 |
kmlussier |
Ideally, what our libraries want is to not have one of the parts pre-selected so that the user needs to make an explicit choice when selecting a part. |
| 15:08 |
kmlussier |
However, if we did so, we would need to make this a required a field, and I'm having trouble figuring out how to do so. I initially used the required attribute for the form input, but I've since discovered it's not supported in Safari. |
| 15:09 |
kmlussier |
The only other way I know of to make the field required is to use javascript, but I know we want to avoid using it in the catalog whenever possible. Are there other ways we might be able to tackle this issue? |
| 15:14 |
phasefx |
kmlussier: it's heavy, but you can make the page return itself with an informative error |
| 15:15 |
* phasefx |
found a wish for this earlier when trying to use Consortium as a pickup lib.. wasn't obvious to me at first what was happening |
| 15:16 |
jonadab |
Having the page return a partly-filled form with an informative error about the missing required field(s) is what is what I would probably do, _possibly_ with optional Javascript designed to pre-empt the submit if Javascript is working ok, letting the server-side stuff catch it if not. |
| 15:18 |
kmlussier |
phasefx: You can select the consortium as a pickup library? |
| 15:19 |
phasefx |
kmlussier: I'm sure it was an admin user on a test system, maybe with the consortium as a the workstation lib. Once deselected, you can't reselect it |
| 15:19 |
kmlussier |
jonadab: The problem with the optional Javascript is that we've tried to keep it out of the catalog unless it's aboslutely necessary. |
| 15:19 |
phasefx |
but the user had no sane default for whatever reason |
| 15:19 |
kmlussier |
phasefx: Ah, ok. |
| 15:19 |
phasefx |
kmlussier: in that case, the page just returned itself with no obvious error |
| 15:20 |
jonadab |
kmlussier: Ah. |
| 15:20 |
jonadab |
So yeah, just make the server side handle it then. |
| 15:20 |
phasefx |
kmlussier: it was probably the home lib of the stock admin user at fault |
| 15:20 |
|
maryj joined #evergreen |
| 15:21 |
jonadab |
(My objections to Javascript start when it becomes non-optional or else runs for multiple seconds; but I don't have any particular objection to avoiding it, either.) |
| 15:22 |
* kmlussier |
would be happier if browsers supported HTML5 elements. :) |
| 15:22 |
goood |
grabbing 0909 |
| 15:23 |
Dyrcona |
kmlussier: Most do. Support is just spotty and limited. It always has been for the most part. |
| 15:23 |
jonadab |
Well, HTML5 is pretty new still. Relatively speaking. |
| 15:23 |
Dyrcona |
Plus, which HTML5 and if the living standard, how new? :P |
| 15:24 |
Dyrcona |
Well, in general, HTML support in browsers has always been spotty. ;) |
| 15:24 |
kmlussier |
From what I read, the required attribute for form fields has been around for a while. |
| 15:24 |
jonadab |
I mean, it's only been a couple of years since we got the last major holdout browser to finally do CSS2 correctly. |
| 15:24 |
Dyrcona |
Hey! Here's a standard. Let's ignore it. |
| 15:25 |
jonadab |
(Ok, more like five years. Still. These things take time.) |
| 15:26 |
Dyrcona |
I'm all out of tuits, literally. I gave my last one to our help desk staff. |
| 15:27 |
pinesol_green |
[evergreen|Bill Erickson] LP#1171984 Vandelay authority record matching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af7304c> |
| 15:27 |
pinesol_green |
[evergreen|Bill Erickson] LP#1171984 Vandelay auth. match release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fba2cd8> |
| 15:27 |
pinesol_green |
[evergreen|Bill Erickson] LP#1171984 vandelay authority rec attr create repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fbaa6bb> |
| 15:27 |
pinesol_green |
[evergreen|Mike Rylander] LP1171984: Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6d6130e> |
| 15:35 |
jboyer-isl |
kmlussier: Oh, no! I forgot I had even submitted the code for lp1366026, nevermind that it was waiting for release notes. :( |
| 15:35 |
kmlussier |
jboyer-isl: I was actually going to write the release notes today if you didn't see it. |
| 15:36 |
jboyer-isl |
I'm not sure I'll have time before the cutoff, unfortunately. |
| 15:36 |
kmlussier |
jboyer-isl: OK, I can take care of it. I would hate to see a good feature not make it in due to release notes. :) |
| 15:38 |
jboyer-isl |
As far as release notes go though, I wasn't planning any for the lp1210541, because you can already delete copy locations; it just doesn't usually work. I was veiwing that as a bug fix. |
| 15:39 |
jboyer-isl |
Huh. pinesol doesn't appear to like my lp style. |
| 15:39 |
jeff |
bug 1210541 |
| 15:39 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 15:39 |
jboyer-isl |
lp 1366026 |
| 15:39 |
pinesol_green |
Launchpad bug 1366026 in Evergreen "Add Copy Active Date to Staff Client Display" (affected: 4, heat: 24) [Wishlist,Incomplete] https://launchpad.net/bugs/1366026 |
| 15:39 |
jboyer-isl |
lp 1210541 |
| 15:40 |
jboyer-isl |
Drop the comma or add the space, who knows where things went off. |
| 15:47 |
yboston |
berick: am I wrong, or did your authority overlay code get signed off and merged to master? Should I still test off of master or should I test from your rebased branch? |
| 15:48 |
kmlussier |
jboyer-isl: Hmmm...I was just discussing it with mmorgan. I think there's a fine line between bug fix and enhancement, but if it isn't mentioned in the release notes, then all the people who gave up on deleting copy locations won't know they can delete them now. |
| 15:49 |
dbs |
Bug fixes should have release notes entries too! |
| 15:49 |
goood |
yboston: it got pushed today, you are not wrong. testing on master is best now |
| 15:49 |
jboyer-isl |
Sigh. I suppose that is true. (dbs's point includeD) |
| 15:49 |
dbs |
lots of bug fixes listed in http://www.postgresql.org/docs/9.4/static/release-9-4-1.html :) |
| 15:50 |
* dbs |
promises to start writing now overdue release notes for TPAC features |
| 15:50 |
jboyer-isl |
I'm going to try to make a habit of just writing something up the next time I get a patch put together, I am apparently terrible about fixing it after the fact. |
| 15:50 |
yboston |
goood: OK, was just about to load his branch, will do master intead |
| 15:58 |
jeffdavis |
kmlussier++ # thanks for catching that LP#1423025 was a duplicate! |
| 16:12 |
hopkinsju |
yboston: Any reason we use .txt rather than .asciidoc for our documentation? It never occurred to me until I saw Benjamin's post to the General list, but using .asciidoc would allow for automatic rendering in some cases (e.g. Github) |
| 16:18 |
* dbs |
pushes overdue release notes for TPAC discoverability features |
| 16:18 |
goood |
yboston: I'm about to push your authority thesaurus display branch. thanks for that |
| 16:19 |
pinesol_green |
[evergreen|Dan Scott] TPAC discoverability release notes entry - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12ee39d> |
| 16:21 |
pinesol_green |
[evergreen|Yamil Suarez] LP#1403967: show 'subject heading thesaurus' value in Manage Authorities results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=985313e> |
| 16:22 |
kmlussier |
hopkinsju: rsoulliere may be a better person to answer the AsciiDoc question since he is the person who set up the doc repository. |
| 16:22 |
hopkinsju |
Right on. Thanks kmlussier! |
| 16:23 |
bshum |
dbs: Heh, I think there's an errant copy/paste in your TPAC discoverability note |
| 16:23 |
bshum |
There's a link there to the release note for PG 9.4.1 |
| 16:25 |
bshum |
On line 35 |
| 16:39 |
yboston |
hopkinsju: kmlussier did a much better job answering your question that I would have |
| 16:40 |
yboston |
goood: thanks |
| 16:40 |
hopkinsju |
By telling me to ask someone else? :) |
| 16:41 |
yboston |
hopkinsju: I can't belive it never crossed my mind before, because I end up having to explain to vounteers to use .asciidoc as a file suffix for github gist to render properly |
| 16:42 |
yboston |
hopkinsju: then again I can see some complaining that they don't have an app to open .asciidoc files on their computers; no good deed goes unpunished |
| 16:42 |
hopkinsju |
yboston: I was also thinking how unfortunate it is (for the maintainers) that we use the fist style of headers (where h1's are the same number of ~'s as letters in the heading) |
| 16:43 |
hopkinsju |
When a double = (==) would have done the same thing. Sounds like a real headache. |
| 16:44 |
yboston |
hopkinsju: when preparing training materials I discoverd that other approach, I would hope that the other style worlks. I would consider teaching the other way too |
| 16:44 |
yboston |
hopkinsju: I mean works on our rendering set up |
| 16:45 |
hopkinsju |
Right. One favors readability, the other writeablilty I suppose |
| 16:56 |
dbs |
bshum: aw yeah, that's how I roll. I'll fix it |
| 16:56 |
bshum |
dbs++ |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
vlewis joined #evergreen |
| 17:05 |
|
vlewis joined #evergreen |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
pinesol_green |
[evergreen|Dan Scott] Fix typo in release notes for TPAC discoverability - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0fabd0> |
| 17:15 |
|
wlayton joined #evergreen |
| 17:17 |
* bshum |
waves at wlayton :) |
| 17:24 |
|
mrpeters left #evergreen |
| 17:30 |
|
MrBaggins joined #evergreen |
| 17:30 |
MrBaggins |
Good afternoon evergreen |
| 17:31 |
MrBaggins |
I hope someone can help a poor creature of the shire |
| 17:31 |
MrBaggins |
I'm trying to access the pdf's listed on http://evergreen-ils.org/dokuwiki/doku.php?id=existing-docs:existing-docs |
| 17:31 |
MrBaggins |
more specifically the 4 on reports |
| 17:32 |
MrBaggins |
but the sitka.bclibraries.ca domain links just loop to bc.libraries.coop/wp-login.php |
| 17:36 |
MrBaggins |
http://sitka.bclibraries.ca/documentation/sitka-evergreen-user-documentation/Reports%20Training.pdf for example |
| 17:38 |
jeffdavis |
MrBaggins: I work for Sitka. Give me a minute and I'll see what I can do for you. |
| 17:38 |
jeff |
MrBaggins: i'd start here: https://bc.libraries.coop/support/sitka-support/ |
| 17:38 |
jeff |
ah, but listen to jeffdavis -- he'll likely be of more help! |
| 17:39 |
ldw |
MrBaggins: here is the HTML version: http://docs.sitka.bclibraries.ca/Sitka/current/html/report.html |
| 17:40 |
MrBaggins |
does that contain all the information available on reports? |
| 17:40 |
ldw |
That is Sitka's report documentation. What are you looking for in particular? |
| 17:41 |
MrBaggins |
any and all manuals/guides relating to reports. If that's the only thing thats ok I was just curious |
| 17:42 |
jeffdavis |
Note that the Sitka docs discuss some stuff that is specific to Sitka, like report templates that exist on our system but aren't in a regular Evergreen system. |
| 17:42 |
MrBaggins |
ok that's good to know, thanks |
| 17:43 |
jeffdavis |
http://docs.evergreen-ils.org/2.7/_reports.html is the documentation for version 2.7 of Evergreen |
| 17:44 |
jeffdavis |
That's more general. Not sure how much it differs from the Sitka docs. |
| 17:44 |
MrBaggins |
Might help, thanks for your time Jeff |
| 17:45 |
jeffdavis |
Always happy to help Bagginses. |
| 17:46 |
berick |
huh, looks like chrome beat FF to disallowing synchronous xmlhttprequest's. just like that, vandelay no longer works in chrome. |
| 17:46 |
jeffdavis |
That "existing-docs" wiki page looks like it's a list of what documentation existed 5 years ago, so should probably not be relied on as the most current source of info for anything. |
| 18:00 |
dbs |
berick: fantastic! |
| 18:03 |
berick |
certainly adds pressure to angular-ize (i.e. websocket-ize) legacy UI's |
| 18:03 |
ldw |
MrBaggins: I sent a reports howto to the mailing list in 2011, so some of it may not be applicable now, you can find it here: http://georgialibraries.markmail.org/message/ptlz36kle63spqqb?q=Liam+report+date:201109+ |
| 18:04 |
berick |
hm, patron reg throws the same warning, but still renders OK |
| 18:04 |
berick |
perhaps it's only deprecated, but not yet prevented, and vandelay is just broken for some other reason |
| 18:05 |
berick |
oh well, more testing later |
| 18:06 |
dbs |
all I've been seeing is deprecation notices, but I thought maybe you were on canary or some such advance build |
| 18:12 |
MrBaggins |
Thanks for that ldw, every bit helps |
| 18:23 |
jonadab |
As far as asciidoc and people wanting .txt files so they can double click, it should be straightforward to make the build process turn the former into the latter. |
| 18:24 |
jonadab |
I believe for example that esr set up the NetHack 4 Guidebook that way. |
| 18:25 |
jonadab |
(And then other formats can be generated as well.) |
| 18:38 |
|
gmcharlt joined #evergreen |
| 18:38 |
gmcharlt |
berick: kmlussier: collab/gmcharlt/lp1410369_message_center |
| 19:08 |
|
wlayton joined #evergreen |
| 19:43 |
kmlussier |
gmcharlt++ |
| 19:48 |
kmlussier |
jonadab: Currently, our build process turns the .txt files into html/pdf/epub. I think the question came up because somebody was looking asciidoc files in a github branch that hadn't been merged into master yet, and therefore is not part of the build process. |
| 19:48 |
jonadab |
Ah, I see. |
| 20:56 |
|
graced joined #evergreen |
| 21:12 |
|
ying joined #evergreen |
| 21:15 |
|
bmills joined #evergreen |
| 22:20 |
|
bmills joined #evergreen |
