| Time |
Nick |
Message |
| 02:31 |
|
dcook joined #evergreen |
| 02:32 |
|
sarabee joined #evergreen |
| 05:07 |
|
dkyle joined #evergreen |
| 05:08 |
|
_bott_ joined #evergreen |
| 05:30 |
|
BigRig joined #evergreen |
| 07:18 |
|
Callender joined #evergreen |
| 07:31 |
|
graced joined #evergreen |
| 07:40 |
|
mrpeters joined #evergreen |
| 08:02 |
|
rjackson_isl joined #evergreen |
| 08:07 |
* bshum |
does a little dance knowing that the print notices did not explode overnight... |
| 08:16 |
|
akilsdonk joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:36 |
|
Newziky1 joined #evergreen |
| 08:36 |
|
Newziky1 left #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:42 |
|
jboyer-isl joined #evergreen |
| 08:42 |
|
krvmga joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 09:01 |
csharp |
@dunno search cat |
| 09:01 |
pinesol_green |
csharp: 2 found: #31: "What we have here is a failure to communicate." and #9: "http://cat.evergreen-ils.org.meowbify.com/" |
| 09:06 |
krvmga |
i found a catalog display issue that only seems to affect the firefox browser. |
| 09:07 |
krvmga |
in advanced search, when choosing a format, if you click on the arrow to move down on the list, the list advances in such a way that the fifth item on the list is hidden |
| 09:07 |
krvmga |
you only get to see it if you scroll to the end of the list and then back up |
| 09:07 |
krvmga |
this doesn't happen in IE, Opera, Safari, or Chrome |
| 09:07 |
krvmga |
only firefox |
| 09:08 |
krvmga |
is this worth mentioning on launchpad? |
| 09:09 |
csharp |
krvmga: can you see the same issue on http://gapines.org? |
| 09:10 |
* csharp |
is not, if he's understanding the complaint correctly |
| 09:10 |
csharp |
(FF36 on Fedora 21) |
| 09:11 |
krvmga |
csharp: i don't see it there...i think because the lists are short |
| 09:12 |
csharp |
krvmga: what's the URL for your OPAC? |
| 09:14 |
krvmga |
csharp: i do see it in the gapines.org language selection list. you can check it for yourself. try to choose the language that comes directly after German. |
| 09:14 |
Bmagic |
krvmga: I see it happening on my opac, I'm not sure if this is an EG issue or the browser taking liberties |
| 09:14 |
krvmga |
it's Hindi, but you don't get to see it |
| 09:14 |
krvmga |
the list moves so that you see Italian |
| 09:15 |
krvmga |
Bmagic: since it works fine in the other browsers, i'm inclined to think it might be a firefox issue. |
| 09:16 |
csharp |
so what I'm doing is clicking on the top item of the list, then using the down arrow key to move down the list - is that what you're doing? |
| 09:16 |
krvmga |
csharp: using the down arrow on the slider beside the box |
| 09:16 |
Bmagic |
csharp: You have to click the down arrow on the scroll bar UI |
| 09:16 |
krvmga |
if you use your keyboard down arrow, you'll see Hindi |
| 09:17 |
Bmagic |
It advances 5 lines instead of the displayed 4 |
| 09:17 |
csharp |
ah - Fedora isn't rendering the scrollbar like that |
| 09:18 |
Bmagic |
csharp: I agree, the firefox installation on different OS's changes things |
| 09:18 |
krvmga |
yes, i'm sorry. i should have mentioned this was on windows |
| 09:18 |
Bmagic |
I see the behavior on Windows+Firefox |
| 09:18 |
Dyrcona |
It skips Finnish, too, for the record. |
| 09:19 |
Dyrcona |
My suggestion is open a bug in Mozilla's Bugzilla. |
| 09:19 |
Bmagic |
I wonder what would happen if the scroll box was 5 elements tall? |
| 09:20 |
bshum |
Doesn't help |
| 09:20 |
bshum |
I tried that using the inspector editor |
| 09:20 |
bshum |
And it just skips the sixth entry instead |
| 09:20 |
Bmagic |
haha! |
| 09:20 |
bshum |
So it definitely seems like a weird Firefox issue |
| 09:21 |
csharp |
s/Firefox/Firefox on Windows/ |
| 09:21 |
* csharp |
doesn't know if mac works the same way |
| 09:21 |
* krvmga |
doesn't have a mac to test on. |
| 09:21 |
Dyrcona |
I'm using Firefox 37.0.1 on Ubuntu and I see it the behavior as described. |
| 09:21 |
* jeff |
looks |
| 09:22 |
* jboyer-isl |
is using a mac at this very moment. I’ll go grab FF. |
| 09:22 |
Bmagic |
bshum: Using firebug, I changed the box to have size="5" and it fixed the issue |
| 09:22 |
Bmagic |
<select title="Select item type:" size="5" multiple="multiple" name="fi:item_type" id="adv_selector_item_type"> |
| 09:23 |
jeff |
I'm unable to repro on Firefox 38.0 on OS X |
| 09:23 |
Bmagic |
But perhaps if the page was originally delivered to the firefox engine with size="5" then it would skip the 6th element like you said |
| 09:26 |
Bmagic |
Anyone had success adding z39.50 targets to EG? I am pondering the "Format" and the "Code" values. Title, I have code 4 and Format 6 |
| 09:27 |
Bmagic |
I think I understand what code is from this http://www.indexdata.com/yaz/doc/bib1.html |
| 09:27 |
jboyer-isl |
FF 37.0.1 on OSX also works properly. Does FF still mix custom / native controls depending on the system, or are they all custom or all native? |
| 09:27 |
bshum |
Bmagic: Yes, we've had success. But yes, it also depends on the Z-targets. |
| 09:27 |
Bmagic |
So, a value of 4=Title, What is format? |
| 09:27 |
Dyrcona |
What bshum just said. |
| 09:28 |
Bmagic |
bshum: I figured as much, So I am probing them using ZOOM in perl, and getting success, but EG doesnt return anything |
| 09:28 |
Dyrcona |
Bmagic: Is the target running Evergreen? |
| 09:29 |
Bmagic |
Dyrcona: no, this is my example http://mainecat.maine.edu |
| 09:30 |
Bmagic |
mainecat.maine.edu:210/INNOPAC |
| 09:30 |
Bmagic |
With Zoom, query @attr 1=4 "harry potter" |
| 09:30 |
Bmagic |
I get over 400 results |
| 09:30 |
Bmagic |
0 results on EG |
| 09:31 |
bshum |
Bmagic: What's your settings look like in config.z3950_attr for the source you set up? |
| 09:31 |
Dyrcona |
Format 6 and truncation of 1 usually works for title. |
| 09:31 |
* bshum |
is most interested in the "trunction" |
| 09:31 |
bshum |
*truncation |
| 09:32 |
bshum |
Depends. For LOC you need 1. For OCLC, they set it to 0 (at least in our live settings) |
| 09:32 |
Bmagic |
Source mainecat.maine.edu, Label Maincat, Host mainecat.maine.edu, port 210, DB INNOPAC, Record format FI, transmission usmarc |
| 09:32 |
Bmagic |
I will try changing the truncation number |
| 09:33 |
Dyrcona |
Well, truncation is 0 for all OCLC. |
| 09:33 |
bshum |
Ah, indeed. |
| 09:34 |
|
yboston joined #evergreen |
| 09:34 |
Dyrcona |
Interesting....I just noticed that I have ISBN configured differently for Bibliomation than I do for NOBLE and CW/MARS. |
| 09:35 |
bshum |
Dyrcona: Interesting indeed... I know we tinkered with the z-config when we were testing between us to figure out what was weird with Evergreen... |
| 09:36 |
jeff |
@dunno add Have you confirmed your ISBN SPIDs with your service provider? |
| 09:36 |
pinesol_green |
jeff: The operation succeeded. Dunno #38 added. |
| 09:36 |
Dyrcona |
Ah.... Turns out the configuration for Bibliomation is incomplete, or was partially removed. |
| 09:36 |
bshum |
Heh :) |
| 09:37 |
Dyrcona |
Guess the catalogers didn't want to use you guys as a source for records in production. |
| 09:42 |
Dyrcona |
So, just continuing the z39.50 conversation a bit. |
| 09:43 |
Bmagic |
I had to run into a meeting. I did quickly check the truncation setting and it didn't help. I'll see what I can see in the eg logs |
| 09:43 |
Dyrcona |
If you're configuring an Evergreen target, everything is pretty much the same as LoC or Biblios, except for ISBN. |
| 09:43 |
Dyrcona |
On ISBN you want to set truncation to 100 for Evergreen. |
| 09:44 |
Bmagic |
What is truncation? |
| 09:44 |
Dyrcona |
Bmagic: Don't think you'll see much useful in the logs. |
| 09:45 |
Bmagic |
You think the the biggest impact is in the truncation setting. What about format? |
| 09:46 |
Dyrcona |
Might be format. I've never connected to INNOPAC. |
| 09:46 |
bshum |
well that stuff has to match whatever they're saying. |
| 09:46 |
bshum |
Code and format. |
| 09:46 |
bshum |
and truncation. |
| 09:46 |
Bmagic |
Ok so I need to call them? |
| 09:46 |
Dyrcona |
Here are the allowed truncations from LoC: http://www.loc.gov/z3950/lcserver.html#trua |
| 09:46 |
Dyrcona |
That is what LoC supports for truncation. |
| 09:49 |
Dyrcona |
This library appears to use the same INNOPAC software as maine: http://wellcomelibrary.org/using-the-library/how-to/z3950/#anchor1 |
| 09:51 |
Bmagic |
Oooo, that is a good find |
| 09:51 |
dbs |
speaking of biblios: bug 1441634 |
| 09:51 |
pinesol_green |
Launchpad bug 1441634 in Evergreen "Remove Biblios from the default Z39.50 targets" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1441634 |
| 09:51 |
|
Newziky1 joined #evergreen |
| 09:51 |
bshum |
dbs: +1 |
| 09:53 |
Dyrcona |
Ideally, the target should have information available somewhere on their site. |
| 09:56 |
Dyrcona |
Would we want an upgrade script to also remove it from existing installations? |
| 09:56 |
Dyrcona |
Biblios, that is. |
| 10:04 |
jboyer-isl |
Can someone help me sanity check an opac change? |
| 10:05 |
Dyrcona |
@roll d20 |
| 10:05 |
pinesol_green |
Dyrcona: As great as you are man, you'll never be greater than yourself. |
| 10:05 |
kmlussier |
sure |
| 10:05 |
kmlussier |
I live for sanity checks. |
| 10:05 |
|
jwoodard joined #evergreen |
| 10:06 |
csharp |
@quote add < kmlussier> I live for sanity checks. |
| 10:06 |
pinesol_green |
csharp: The operation succeeded. Quote #109 added. |
| 10:06 |
jboyer-isl |
I’m looking to make the Audience advanced search for juvenile (j) to include several other audience codes (a,b, and c), Is it appropriate to change the coded value map for Juvenile to ‘a,b,c,j’ or to just make a custom Audience filte box for the opac? |
| 10:06 |
kmlussier |
My first quote! You just made my day csharp! |
| 10:07 |
jboyer-isl |
I guess it’s more a question of “Will this require a reingest and break our DB, or does playing with coded value mapes just change what the opac filters do” |
| 10:07 |
|
sarabee joined #evergreen |
| 10:08 |
csharp |
kmlussier++ |
| 10:08 |
kmlussier |
jboyer-isl: Alas, I can't help with this one. :( |
| 10:09 |
csharp |
jboyer-isl: I would assume the latter unless someone like eeevil knows differently |
| 10:09 |
csharp |
sorry, the former |
| 10:09 |
jboyer-isl |
kmlussier: It’s definitely not common knowledge and the docs aren’t really clear on that. :( |
| 10:09 |
csharp |
I would assume breakage/required reingest, that is |
| 10:10 |
tsbere |
jboyer-isl: I can help! If you edit the existing things will get weird. I add a new one, mark it as a "Simple" one to push it to the top. |
| 10:11 |
Dyrcona |
You'll need to do a partial reingest either way, IIRC. |
| 10:11 |
jboyer-isl |
Ah, “Danger, keep fingers clear of machinery” it sounds like. So, tsbere, is it really worth messing with mapping and etc., or just make a custom filter box since it’s so simple? I’m kind of leaning toward the custom box myself. |
| 10:11 |
* eeevil |
's ears are buring, reads up |
| 10:12 |
tsbere |
jboyer-isl: I just add a new CCVM row for the existing set. It won't ever match for indexing but will work for searching. If you want I can dig up some MVLC examples. |
| 10:12 |
jboyer-isl |
Dyrcona: What I’m after is more like selecting multiple values from the audience box when selecting “juvenile,” can that not be done with just a custom template change? |
| 10:15 |
Dyrcona |
jboyer-isl: I was referring to tsbere's suggestion with the either, and I'm apparently wrong in that case. |
| 10:16 |
|
mllewellyn joined #evergreen |
| 10:16 |
Dyrcona |
A template change is relatively cheap. I'd try it on a dev/test system to see if it did what I wanted. If it does, then there you go! |
| 10:17 |
tsbere |
Template change in this case is harder due to the dynamic nature of the advanced search boxes. Database insert (compared to edit) is easier. ;) |
| 10:17 |
Dyrcona |
Well then. I'm wrong again. :) |
| 10:17 |
* Dyrcona |
shuts up. |
| 10:17 |
jboyer-isl |
I’m working on a dev server change, our dev db is just so lousy that it might be quicker to ask people that might nkow one way or the other. ;) |
| 10:17 |
eeevil |
jboyer-isl: you can't use the comma separated "trick" anymore. it was never intended to work that way, it was just an implementation quirk that allowed it. what you want is to use are composite record attributes |
| 10:18 |
eeevil |
s/can't/shouldn't/ |
| 10:18 |
kmlussier |
eeevil: But that would require a reingest, right? |
| 10:18 |
jboyer-isl |
eeevil: That’s what I was thinking, but I don’t want to accidentally change what Juvenile means in the database, just for search filters. Is that still the appropriate place to start changing things? |
| 10:18 |
eeevil |
kmlussier: of the specific (new) attribute, yes, but nothing will break, per se |
| 10:19 |
eeevil |
jboyer-isl: sec, checking the db |
| 10:20 |
* tsbere |
is still find with the comma separated "trick" because it is a lot easier than rigging a new composite variant and requires no reingest of any kind |
| 10:21 |
tsbere |
Oh, and the comma-separated bit doesn't create a new selector, it just adds to an existing one. >_> |
| 10:24 |
|
tsbere_ joined #evergreen |
| 10:37 |
eeevil |
jboyer-isl: so, interestingly, everything is already set up to do exactly what you want, if you just create a new composite attr def called "audience_group" (with parallel ccvm defs for the stock audience) and reingest just that attr def. see: templates/opac/parts/config.tt2:103 (in master) |
| 10:38 |
eeevil |
It would be interesting, I think, to teach the logic using search.adv_config in the tpac to optionally make use of /all/ listed adv_attr values, so you could effectively mix them -- just disable the opac_visible flag on the stock audience:juvenile, and add just audience_group:juvenile |
| 10:39 |
eeevil |
but, that's the future |
| 10:40 |
jboyer-isl |
I see. That way I can also pre-define everything and it can just sit until the reingest and then switch over. |
| 10:41 |
eeevil |
jboyer-isl: yeppers. well, take audience_group out of that list while you're setting it up, then put it back in to enable it in the tpac |
| 10:41 |
jboyer-isl |
Even though it lists audience_group,audience, it only picks the first that exists? |
| 10:41 |
eeevil |
correct |
| 10:41 |
jboyer-isl |
OK. |
| 10:42 |
jboyer-isl |
I might be using that in a couple other places to use some MVR filters for some other search filters. |
| 10:45 |
|
dreuther joined #evergreen |
| 10:48 |
|
dreuther_ joined #evergreen |
| 10:49 |
|
dreuther_ joined #evergreen |
| 10:52 |
kmlussier |
@dessert add pineapple coconut cheesecake |
| 10:52 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #34 added. |
| 10:52 |
kmlussier |
@dessert 34 [someone] |
| 10:52 |
* pinesol_green |
grabs some pineapple coconut cheesecake for substack |
| 11:24 |
csharp |
@quote random |
| 11:24 |
pinesol_green |
csharp: Quote #88: "< eeevil> Now I am become Death, the destroyer of SIP2." (added by csharp at 04:45 PM, August 13, 2014) |
| 11:24 |
csharp |
hehe |
| 11:24 |
|
bmills joined #evergreen |
| 11:24 |
csharp |
@karma sip |
| 11:24 |
pinesol_green |
csharp: Karma for "sip" has been increased 0 times and decreased 4 times for a total karma of -4. |
| 11:24 |
csharp |
@karma sip2 |
| 11:24 |
pinesol_green |
csharp: Karma for "sip2" has been increased 0 times and decreased 6 times for a total karma of -6. |
| 11:26 |
|
abowling joined #evergreen |
| 11:37 |
dbs |
<xsl:output method="xml" indent="yes" encoding="UTF-8"/> vs. <xsl:output method="xml" indent="yes"/> |
| 11:37 |
dbs |
guess which MODS stylesheet has encoding="UTF-8" declared |
| 11:57 |
|
RoganH joined #evergreen |
| 12:03 |
dbs |
Oh, sonofa... |
| 12:03 |
* dbs |
wonders whether the MODS stylesheet encoding corruption is a result of a PostgreSQL xslt behaviour change |
| 12:06 |
|
akilsdonk joined #evergreen |
| 12:06 |
|
buzzy joined #evergreen |
| 12:09 |
jeff |
dbs: what are you chasing down? |
| 12:09 |
jeff |
rather, where should i look for more context, if any? :-) |
| 12:10 |
dbwells |
jeff: I'm guessing the MODS/Zotero issue on the mailing list. |
| 12:12 |
jeff |
ah! i was looking at the list just now. :-) |
| 12:13 |
dbs |
dbwells++ |
| 12:13 |
dbs |
so the "funny" thing is that the MODS3 and on stylesheets have xsl:output encoding="UTF-8" declared, and they're the ones that corrupt characters. |
| 12:15 |
* dbs |
looks at evergreen.oils_xslt_process |
| 12:18 |
dbs |
we use output_string() but http://search.cpan.org/~shlomif/XML-LibXSLT-1.94/LibXSLT.pm says that's deprecated in favour of more explicit output_as_bytes and output_as_chars |
| 12:19 |
dbs |
of course XML::LibXSLT 1.75 on our production box |
| 12:20 |
dbs |
but output_string() was deprecated even then |
| 12:21 |
dbs |
so it appears we want to use output_as_bytes() |
| 12:24 |
pinesol_green |
[evergreen|Dan Scott] LP#1441634 Remove biblios.net from Z39.50 sources - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d601e7c> |
| 12:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1441634: add release notes for removal of biblios.net Z39.50 target - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9629026> |
| 12:25 |
dbs |
gmcharlt++ |
| 12:25 |
* gmcharlt |
sheds a single tear for the promise of biblios.net |
| 12:32 |
jcamins |
gmcharlt: wow, that lasted a really long time in EG. |
| 12:32 |
jcamins |
Didn't it go down four years ago? |
| 12:33 |
gmcharlt |
jcamins: probably; one thing that's deceptive is that it still listens on port 210 and does the initial handshake with a Z39.50 client |
| 12:33 |
gmcharlt |
it just doesn't recognize the "bibliographic" database it used to advertise |
| 12:41 |
|
chatley_ joined #evergreen |
| 12:42 |
|
chatley joined #evergreen |
| 12:44 |
|
chatley__ joined #evergreen |
| 12:51 |
|
jihpringle joined #evergreen |
| 12:53 |
|
chatley joined #evergreen |
| 13:09 |
|
plux joined #evergreen |
| 13:10 |
dbs |
ahhh, and output_string() is also used in WWW::SuperCat::Feed |
| 13:15 |
Dyrcona |
dbs: Would you rather want output_as_chars() ? |
| 13:16 |
Dyrcona |
I guess it comes down to respecting the encoding in the stylesheet or not. |
| 13:17 |
dbs |
Dyrcona: you would think so, but based on the MODS stylesheet not having a declared output encoding and thus defaulting to output_as_bytes (and getting the desired behaviour) |
| 13:18 |
dbs |
alternately, we do output_as_chars() and utf8_encode() throughout |
| 13:18 |
dbs |
More messing about than I had anticipated |
| 13:19 |
Dyrcona |
Well, what do you get with output_as_bytes when no encoding is specified? UTF-8? Something else? |
| 13:21 |
Dyrcona |
It probably makes more sense to just fix the stylesheets and use output_as_bytes. |
| 13:23 |
* dbs |
welcomes anyone else who wants to dig into this to go ahead and put together a fix for the bug. |
| 13:29 |
plux |
on another note….anyone noting SSL issues with 2.74 on Ubuntu 14.04 post openssl upgrades - seems to affect the staff client only |
| 13:29 |
plux |
the infamous “SSL input filter read failed” |
| 13:30 |
Dyrcona |
We're not running production on Ubuntu 14.04, but I have not had any SSL issues with my development VM which runs Ubuntu 14.04. |
| 13:31 |
Dyrcona |
Actually, I just built a new client and updated stuff yesterday. Let me check again with that. |
| 13:34 |
Dyrcona |
Well, yes, guess I do see log messages. |
| 13:35 |
plux |
it may be smoke and mirrors but we’re getting intermittent/erratic hanging in the client that seems to parallel the SSL read fail times |
| 13:36 |
plux |
it seemed fine prior to the latest openssl patches |
| 13:37 |
Dyrcona |
I doubt the hanging has much to do with it. |
| 13:37 |
jeffdavis |
I see a few "SSL input filter read failed" messages in the logs for our Ubuntu 14.04 test server running EG2.8 beta. Haven't had any reports of client issues so far. |
| 13:37 |
Dyrcona |
http://serverfault.com/questions/565703/apache-producing-lots-of-ssl-only-errors-even-though-the-data-in-browser-seems-f |
| 13:38 |
Dyrcona |
Looks it has to do with named virtual hosting and SSL being established before that happens. |
| 13:42 |
Dyrcona |
Well, that's not it in this case, apparently. |
| 13:44 |
dbs |
Oh, for more fun it could be the use of XML::LibXML::Document::toString() without an explicit setEncoding('UTF-8') call messing things up (due to the addition of created strings that have not had the utf8 flag set) |
| 13:45 |
dbs |
@hate encodings |
| 13:45 |
pinesol_green |
dbs: The operation succeeded. dbs hates encodings. |
| 13:48 |
Dyrcona |
Meh, just everyone use American English....problem solved. :) |
| 13:49 |
Dyrcona |
Honestly, though, I mostly agree about encodings. |
| 13:49 |
Dyrcona |
plux: Dunno what's going on. Google points at stuff like the above. Making the config changes and restarting Apache doesn't "fix" it. |
| 13:49 |
plux |
so long as it will copy/paste from MS Word :) |
| 13:50 |
plux |
yes…tried those…..and it may well be unrelated |
| 13:50 |
Dyrcona |
Just don't try middle-clicking with Google Docs! |
| 13:50 |
Dyrcona |
Exact same error, though, so puzzling. |
| 13:52 |
plux |
right…at it’s worst it comes across as a timout which kind of fits…was wondering if it could be related to client mozilla wanting older version of SSLv |
| 13:52 |
Dyrcona |
Hmm. Wonder if XULRunner is trying something like SSLv2 or 3 that is disabled, then going with TLS? |
| 13:53 |
Dyrcona |
heh. |
| 13:53 |
Dyrcona |
I think we just shared the same thought at more or less the same time. :) |
| 13:53 |
plux |
yep |
| 13:53 |
Dyrcona |
That's probably it. |
| 13:54 |
plux |
I’ll play with that and see what I come up with up….keeps them on their toes down at the circ desk |
| 13:57 |
bshum |
bug 1441772 makes my head hurt. |
| 13:57 |
pinesol_green |
Launchpad bug 1441772 in Evergreen "It is possible to delete a patron record with open transactions through Merge Patrons function in patron group" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1441772 |
| 14:02 |
csharp |
@blame powerpoint |
| 14:02 |
pinesol_green |
csharp: powerpoint is NOT CONNECTED TO THE NETWORK!!! |
| 14:09 |
|
mglass joined #evergreen |
| 14:11 |
RoganH |
@blame holds targeter |
| 14:11 |
pinesol_green |
RoganH: Your failure is now complete, holds targeter. |
| 14:13 |
Dyrcona |
@blame Dyrcona |
| 14:13 |
pinesol_green |
Dyrcona: Your failure is now complete, Dyrcona. |
| 14:13 |
Dyrcona |
Ah, bummer. I was hoping to steal my ice cream again. |
| 14:15 |
RoganH |
:) |
| 14:16 |
|
vlewis joined #evergreen |
| 14:18 |
csharp |
@blame search h4x |
| 14:18 |
pinesol_green |
csharp: No matching blames were found. |
| 14:18 |
jboyer-isl |
No matching blames? pinesole si h4x! |
| 14:19 |
csharp |
@blame pinesol_green |
| 14:19 |
pinesol_green |
csharp: itself caused the white screen of death! |
| 14:24 |
|
krvmga joined #evergreen |
| 14:25 |
krvmga |
do we already know that unescaped HTML in a formatted content note can break the OPAC display? |
| 14:25 |
krvmga |
http://bark.cwmars.org/opacrecord/1206603 for example |
| 14:26 |
* bshum |
fixes the rest of that syntax... |
| 14:26 |
bshum |
And looks |
| 14:26 |
bshum |
../eg/opac/record/.. |
| 14:26 |
krvmga |
bshum: sorry typos :( |
| 14:27 |
krvmga |
http://bark.cwmars.org/eg/opac/record/1206603 |
| 14:28 |
tsbere |
That looks like nobody did a "| html" and that it should be in a <pre> block |
| 14:29 |
tsbere |
No, wait, it doesn't look like a <pre> would help now that I opened the source. <_< |
| 14:29 |
|
dMiller_ joined #evergreen |
| 14:29 |
tsbere |
Is -- supposed to be a newline marker? |
| 14:30 |
Dyrcona |
Compared to our record, that one does look a bit borked: http://catalog.mvlc.org/eg/opac/record/1302771 |
| 14:33 |
krvmga |
when i look at the record in MARC View, i can see that some of the section headings in the chapters include the tags. the next section after "Javascript 101" is "<script> element" |
| 14:34 |
tsbere |
I think contents.tt2 needs "total_contents;" to become "total_contents | html;" but I am not sure. |
| 14:35 |
Bmagic |
Has anyone seen an evergreen client display a patron's birthday off by 1 day? The database shows "1958-07-13 00:00:00-05" but the client shows 7/13/1958 ! Only on one workstation. It's doing this for all patrons. Is there a setting somewhere? |
| 14:35 |
Bmagic |
correction 7/12/1958 |
| 14:35 |
krvmga |
there's also a section later on "<embed> element" |
| 14:36 |
bshum |
Bmagic: More like a bad timezone setting on the workstation. |
| 14:36 |
bshum |
What's the PC clock say? |
| 14:36 |
jeff |
Bmagic: first i suspect time zone / DST issues |
| 14:36 |
Bmagic |
bshum: that is the first thing we checked |
| 14:37 |
Bmagic |
So, nothing else comes to mind? |
| 14:37 |
Bmagic |
EG staff client doesn't have time settings of any kind? |
| 14:38 |
krvmga |
tsbere: to answer your question, i think they were using "--" as a divider between sections in chapters. |
| 14:38 |
krvmga |
tsbere: i can change contents.tt2 as you suggest and see what happens |
| 14:39 |
Dyrcona |
Looks to me that the MARC probably had tags in it like so: <embed> <script> |
| 14:39 |
Dyrcona |
That's being stripped/mangled on the way out. |
| 14:39 |
tsbere |
krvmga: If it works make a patch and submit it. If it doesn't or causes other breakage then I didn't dig deep enough. |
| 14:41 |
bshum |
Bmagic: so, it's stored as -05, but right now, we're at -04 aren't we? |
| 14:41 |
Bmagic |
Central is -05 I think |
| 14:41 |
bshum |
Oh right. |
| 14:41 |
bshum |
:) |
| 14:41 |
krvmga |
tsbere: i'm looking in contents.tt2 in BLOCK render_contents |
| 14:43 |
krvmga |
tsbere: that seems to have fixed it. |
| 14:43 |
* bshum |
hates time zones |
| 14:43 |
bshum |
Bmagic: I'm not aware of any time settings in the staff client. I just presumed it grabbed it from Windows or whatnot. |
| 14:43 |
tsbere |
krvmga: Woo then. Make a patch, get credit for actually making the change and testing it. ;) |
| 14:43 |
Bmagic |
ok, cool, I will focus my direction |
| 14:44 |
bshum |
So I have seen it shift dates weirdly if it was recorded in one timezone but got time changed into the wrong time on another workstation |
| 14:45 |
krvmga |
tsbere: thank you. i will do that. |
| 14:45 |
krvmga |
tsbere++ |
| 14:48 |
Bmagic |
bshum: interesting, I will take a close look at that as well |
| 14:48 |
|
bmills joined #evergreen |
| 14:49 |
Dyrcona |
Bmagic: My first thought was, "After 57 years, what difference does a day make?" |
| 14:49 |
Bmagic |
lol |
| 14:50 |
bshum |
Bmagic: Yeah my Googling is only turning up stuff for PC timezone settings stuff. Like right time, wrong timezone in Windows affecting Firefox, etc. |
| 14:50 |
bshum |
Or like DOS variables or something. |
| 14:50 |
bshum |
But yeah... |
| 14:51 |
Bmagic |
roger that, thank you so much for the ideas and your time! |
| 14:51 |
Bmagic |
no pun intended |
| 14:54 |
Dyrcona |
@blame DST |
| 14:54 |
pinesol_green |
Dyrcona: DST stole Dyrcona's ice cream! |
| 14:54 |
Dyrcona |
Well, that figures..... |
| 14:55 |
|
bmills joined #evergreen |
| 14:55 |
|
vlewis_ joined #evergreen |
| 14:56 |
|
vlewis_ joined #evergreen |
| 15:00 |
jeffdavis |
There are a number of LP bugs with the pullrequest tag that apparently haven't been reviewed (status of New, no milestone, no comments). What's the best way to get those reviewed by testers/committers? |
| 15:02 |
jeffdavis |
In the past I've often just mentioned specific bugs here... |
| 15:02 |
Dyrcona |
Well, that's one way. |
| 15:03 |
Dyrcona |
You could email the dev list with the list of bugs. |
| 15:12 |
jeffdavis |
For sure. I guess I'm wondering if it's an indication that there's a gap in the process. |
| 15:13 |
bshum |
jeffdavis: In general, I would also just start targeting things in LP to what you think works. If you feel like being more proactive :) |
| 15:13 |
kmlussier |
Promoting particular bugs right before bug squashing day may be a good idea too. |
| 15:14 |
Dyrcona |
Yeah to both suggestions. Untargeted bugs tend to be ignored. |
| 15:14 |
Dyrcona |
As for "process" there really isn't one. |
| 15:14 |
Dyrcona |
Devs look at stuff that interests them/their employer. |
| 15:14 |
* bshum |
also accepts bribes for pullrequest reviews in the form of cash or chocolates |
| 15:15 |
jeffdavis |
I'm happy to target bugs. I don't have rights in LP to assign milestones though - would someone be willing to grant that (user is jdavis-sitka)? |
| 15:15 |
jeffdavis |
ldw (whalen-ld in LP, I think) could also use that ability I think. |
| 15:16 |
jeffdavis |
bshum: I won't be at the EG conference this year, but perhaps I can get one of my coworkers to smuggle some cash/chocolate there... ;) |
| 15:16 |
Dyrcona |
Maybe we need an official bug wrangler again? |
| 15:17 |
bshum |
Dyrcona: I semi-took that hat from you. But didn't officially declare myself dictator for life |
| 15:17 |
Dyrcona |
Part of the problem is different people have different opinions about a number of the bugs. |
| 15:18 |
bshum |
Well, that's just a given. |
| 15:18 |
Dyrcona |
There are a bunch of old bugs that I think should be just written off as won't fix, or whatever. |
| 15:18 |
bshum |
I do that when I get insomnia early in the morning. From time to time. |
| 15:19 |
jeffdavis |
Hmm, I guess I can apply to join the Evergreen Bug Wranglers team in LP? |
| 15:20 |
Dyrcona |
Yep. That may be all you need. I forget. |
| 15:20 |
bshum |
jeffdavis: That appears to be how it would work, yes. |
| 15:20 |
bshum |
And then one of the admins can approve it. |
| 15:20 |
jeffdavis |
Ok, thanks. |
| 15:21 |
bshum |
jeffdavis: Welcome aboard. |
| 15:21 |
bshum |
Use your powers wisely. And for good. |
| 15:22 |
bshum |
A minor tip for you |
| 15:22 |
bshum |
Since you now have milestone powers |
| 15:22 |
Dyrcona |
@praise bshum |
| 15:22 |
* pinesol_green |
bshum is kind and patient to newbies |
| 15:22 |
bshum |
Try to only target bug fixes to specific milestones. |
| 15:22 |
kmlussier |
jeffdavis++ |
| 15:22 |
kmlussier |
bshum++ |
| 15:22 |
bshum |
If it's a new feature, apply those towards 2.next (or 2.9 or whatever when that comes along) |
| 15:23 |
jeffdavis |
bshum: Noted, will do, thank you. |
| 15:23 |
bshum |
If you have any other questions, feel free to pester someone in IRC. |
| 15:24 |
bshum |
I tend to check in if I have doubts about how to target a bug. |
| 15:24 |
bshum |
Otherwise, no permanent damage ;) |
| 15:24 |
jeffdavis |
heh, sounds good |
| 15:25 |
Dyrcona |
@praise 7 bshum |
| 15:25 |
* pinesol_green |
bshum is the hardest working person in #evergreen. |
| 15:25 |
* kmlussier |
agrees |
| 15:26 |
bshum |
Haha.... wow. |
| 15:26 |
* bshum |
goes back to thinking about candy. |
| 15:26 |
Dyrcona |
hehe |
| 15:28 |
bshum |
So actually I think that they have to be part of the "Evergreen Drivers" team to do things like make Series targets, etc. |
| 15:29 |
bshum |
And that team is moderated by dbs |
| 15:29 |
Dyrcona |
You mean to create the new targets. |
| 15:29 |
bshum |
No that's the "release team" |
| 15:29 |
Dyrcona |
I think bug wranglers can apply them to bugs. |
| 15:29 |
kmlussier |
bshum: I know there was something I could only do by becoming a member of Evergreen Drivers. Yes, it was targeting a series. You can only nominate to target for a series. |
| 15:29 |
bshum |
kmlussier: Yeah that's it. I knew I was missing a minor detail somewhere. |
| 15:30 |
kmlussier |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1245376/comments/2 |
| 15:30 |
pinesol_green |
Launchpad bug 1245376 in Evergreen "Patron Registration "Save & Clone" behaviour is unintuitive" (affected: 3, heat: 16) [Wishlist,Triaged] |
| 15:31 |
bshum |
So jeffdavis, what you'll want to do is apply to https://launchpad.net/~evergreen-drivers and then you can actually setup the series targets for bug fixes to apply multiple milestones for a given bug. If you're feeling extra saucy. |
| 15:32 |
Bmagic |
kmlussier: oh! |
| 15:32 |
bshum |
Unrelated, these will be great notes for me to cover in my Evergreen presentation with ericar... |
| 15:32 |
kmlussier |
Is that the only difference between the two groups? If so, I think it would make sense to merge the two groups, if it's possible. If there are other differences, is there any reason why wranglers couldn't be given the ability to target series? |
| 15:33 |
bshum |
kmlussier: I think it's cause wranglers were a lower barrier in the early days. vs. "trusted" people who knew how to apply series targets, etc. |
| 15:33 |
Dyrcona |
That may be a Launchpad thing.... |
| 15:33 |
jeff |
for some reason bug 1179614 caught my eye. looks like I can set that to Fix Released overall -- am I reading that right? |
| 15:33 |
pinesol_green |
Launchpad bug 1179614 in Evergreen ""Export All Records" does not work from "Manage Record Buckets"" (affected: 2, heat: 12) [Medium,Fix committed] https://launchpad.net/bugs/1179614 |
| 15:33 |
Dyrcona |
I don't know that that was all set up. |
| 15:33 |
bshum |
jeff: Yes, you can flip that over. That's a common quirk of untargeted milestone churn. |
| 15:33 |
Dyrcona |
jeff: I say yes. |
| 15:34 |
jeff |
done. |
| 15:34 |
Dyrcona |
@eightball Is it fix released? |
| 15:34 |
pinesol_green |
Dyrcona: I doubt it very much. |
| 15:34 |
bshum |
:) |
| 15:34 |
Dyrcona |
@eightball Are you good for anything? |
| 15:34 |
pinesol_green |
Dyrcona: Maybe... |
| 15:34 |
Dyrcona |
heh |
| 15:34 |
bshum |
I suppose we could try making the bug wranglers more powerful. |
| 15:36 |
bshum |
jeff: Sigh, and now I feel like going through and finding all the fix committed and making them fix released if they appear done. |
| 15:36 |
* bshum |
wrangles |
| 15:36 |
* bshum |
will use the maintenance account though |
| 15:37 |
* jeffdavis |
requests to join https://launchpad.net/~evergreen-drivers too |
| 15:39 |
|
akilsdonk joined #evergreen |
| 15:39 |
* bshum |
will probably poke dbs about getting admin rights to that group later. |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:14 |
|
mrpeters left #evergreen |
| 17:24 |
|
mmorgan left #evergreen |
| 18:42 |
|
bbqben joined #evergreen |
| 19:03 |
dbs |
All members of the Evergreen Release Team are automatically members of the Evergreen Drivers team |
| 19:04 |
dbs |
So theoretically we should just add people to the Evergreen Release Team? |
| 19:04 |
|
dcook joined #evergreen |
| 19:04 |
dbs |
https://launchpad.net/~evergreen-release/+members#active |
| 19:05 |
* dbs |
heads home |
| 19:09 |
|
akilsdonk joined #evergreen |
| 19:45 |
|
bmills1 joined #evergreen |
| 19:47 |
|
bmills1 left #evergreen |
| 19:55 |
bshum |
dbs: Hmm, the release team has slightly more powers than the drivers team. In that release team can make and close milestones. |
| 19:55 |
bshum |
I think for bug wrangling, we can keep the drivers team around, and just be more inclusive if people want powers over bugs. |
| 19:56 |
* bshum |
went ahead and approved jeffdavis and ldw |
| 19:56 |
bshum |
Welcome aboard. |
| 19:56 |
bshum |
jeffdavis++ ldw++ # use your powers for good :) |
| 20:37 |
|
bmills1 joined #evergreen |
