| Time |
Nick |
Message |
| 01:11 |
|
sandbergja joined #evergreen |
| 02:39 |
|
beanjammin joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:29 |
|
Dyrcona joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:16 |
JBoyer |
dbwells++ |
| 08:13 |
|
mmorgan joined #evergreen |
| 08:19 |
|
littlet joined #evergreen |
| 08:54 |
|
agoben joined #evergreen |
| 09:03 |
|
aabbee joined #evergreen |
| 09:06 |
Dyrcona |
So, who wants to spend bug squashing week going through the XUL bugs and marking them as "Wont' Fix?" |
| 09:07 |
mmorgan |
@who wants lots of bug squashing week karma? |
| 09:07 |
pinesol |
yar wants lots of bug squashing week karma. |
| 09:40 |
|
yboston joined #evergreen |
| 09:49 |
|
sandbergja joined #evergreen |
| 10:18 |
phasefx |
or learn some launchpad API and automate it :) |
| 10:19 |
Dyrcona |
phasefx: I did that sort of thing before, but it stopped working. |
| 10:19 |
phasefx |
fun |
| 10:19 |
Dyrcona |
I shared the scripts with gmcharlt at one point. |
| 10:19 |
gmcharlt |
yeah |
| 10:20 |
Dyrcona |
I think it came down to a case of the API changing and the libs on whatever Ubuntu release I was on stopped working. |
| 10:20 |
gmcharlt |
and then... lack of tuits |
| 10:20 |
gmcharlt |
(plus the general frustration of LP not actually being friendly to external API clients) |
| 10:20 |
Dyrcona |
Also, I think they started limiting requests, because it seemed to work up to X number of bugs and then stop. |
| 10:21 |
JBoyer |
640k of bugs is definitely enough for anyone. |
| 10:21 |
JBoyer |
:D |
| 10:21 |
Dyrcona |
ha! |
| 10:21 |
Dyrcona |
JBoyer++ |
| 10:21 |
Dyrcona |
@quote add <JBoyer> 640k of bugs is definitely enough for anyone. |
| 10:21 |
pinesol |
Dyrcona: The operation succeeded. Quote #197 added. |
| 10:22 |
gmcharlt |
JBoyer++ |
| 10:23 |
JBoyer |
"Congratulations Bill, you've made huge advances in the software industry, you made great strides toward ending Polio on the planet earth, but I have to say, that 640k line..." |
| 10:23 |
|
jvwoolf joined #evergreen |
| 10:35 |
|
khuckins joined #evergreen |
| 10:57 |
|
Christineb joined #evergreen |
| 11:13 |
|
sandbergja joined #evergreen |
| 11:30 |
|
jvwoolf joined #evergreen |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:41 |
jeffdavis |
Every night, before he falls asleep, Bill Gates thinks of that line and sheds a single tear into a $640,000 bowl. He uses a different bowl every night. |
| 13:05 |
|
yboston joined #evergreen |
| 13:39 |
csharp |
jeffdavis++ |
| 13:39 |
|
Christineb joined #evergreen |
| 13:45 |
|
makohund joined #evergreen |
| 13:49 |
makohund |
I'm fumbling around trying to remember where in a staff client one manages the bib sources found in config.bib_source. Easy enough to just do it in the db, but thought I'd take a peek at the interface. And now I can't seem to find one? Gah. Pointer, please? |
| 13:50 |
jihpringle |
makohund: are you wanting to update the bib source for a record or add an entirely new one? |
| 13:51 |
makohund |
jihpringle: add a new one, change the name of an existing one, delete one that isn't being used, etc. |
| 13:53 |
jihpringle |
makohund: as far as I'm aware there isn't a way to do that through the client, only through the database |
| 13:54 |
makohund |
ah... ok, I feel a little less silly at being unable to find it, then. :) |
| 13:54 |
jihpringle |
if it's there somewhere I can't find it either :) |
| 13:55 |
makohund |
thanks, though |
| 13:55 |
jihpringle |
np |
| 14:00 |
makohund |
Any insight into the "can_have_copies" field? I am adding two sources that will be for electronic resources, with URI's & location orgs in 856. Makes me think "no copies", but... I like to see docs. Not finding docs. |
| 14:02 |
jihpringle |
makohund: http://docs.evergreen-ils.org/reorg/3.2/cataloging/_using_transcendant_bib_sources_for_electronic_resources.html |
| 14:07 |
makohund |
jihpringle: yes, thank you, read that one... found it was telling me "what" it did, but not "why" one might choose one over the other (or the intended purpose). But I did just find this... http://librarypolice.com/~gmc/evergreen/x.txt |
| 14:07 |
makohund |
"To enable libraries to designate specific sets of records as only for use as electronic resources, it is possible to configure a bibliographic source such that physical copies or MFHD records may not be attached to records from that source." |
| 14:07 |
Dyrcona |
makohund: The can_have_copies field presently does nothing. |
| 14:07 |
makohund |
Perfect... |
| 14:08 |
makohund |
Dyrcona: ok, maybe not perfect then? lol... |
| 14:08 |
rjackson_isl |
seems we have transcendant of f and can_have_copies of f for our electronic resources governed by the 856 $9 entries |
| 14:08 |
Dyrcona |
It will prevent manually adding copies/volumes to the bibs in the XUL client, but the web staff client and everything else ignores the field. |
| 14:08 |
makohund |
rjackson_isl: yes, that's just what I was thinking I'd do |
| 14:09 |
Dyrcona |
transcendant[sic] makes the bibs show up without copies or "located URIs." |
| 14:09 |
csharp |
right - if it's "transcendant" it displays everywhere regardless of who owns the bib - 856 $9 lets you restrict where it shows up in the OPAC |
| 14:10 |
* Dyrcona |
should update Lp 1805663 |
| 14:10 |
pinesol |
Launchpad bug 1805663 in Evergreen 3.2 "Can Add Copies to Bibs with Source that Does Not Allow Copies" [Medium,Confirmed] https://launchpad.net/bugs/1805663 |
| 14:10 |
makohund |
Ah, thank you. OK, I guess I'll set it then, but... if the web client and whatnot ignores it, sounds like the field is going away anyway, so it doesn't really matter. |
| 14:10 |
Dyrcona |
makohund: It's an oversight that the web client ignores can_have_copies. |
| 14:11 |
dbwells |
Also, pretty sure that x.txt link above has the flag backwards as well, FWIW :o Not that it can't still be understood in intention. |
| 14:12 |
makohund |
Dyrcona: so go ahead and set it how I like then, and eventually in a future version the web client might honor it again |
| 14:12 |
Dyrcona |
Hopefully, yes, and acquisitions and vandelay and... |
| 14:14 |
makohund |
dbwells: Main thing is that I often find it quite helpful to know what the point/reason/intention of a setting is, not just purely "what does it do". And that doc gives me exactly that. |
| 14:14 |
dbwells |
Yes, just change 'TRUE' to 'FALSE' :) |
| 14:16 |
makohund |
dbwells: OK, yeah, see that mistake there... hadn't even read it that far, just that first sentence was all I was looking for. :) |
| 14:18 |
makohund |
Sometimes I wonder if documentation for settings could have footnotes with links back to the release notes of when the setting was new... because that's usually where the best explanation of what it is for can be found. |
| 15:07 |
makohund |
Ok, could use some advice about 856 fields and the $9 entries. Looks like my incoming records have four 856's... a link to the whole thing, two to different formats of excerpts, and one to an image file. I need to add $9's to those, OR add more 856's... one with $9s for each of the libraries subscribing to it, or one for each of them, with a single $9 apiece. Any recommendations, and reasons? |
| 15:10 |
makohund |
Thinking in terms of mass editing, importing, future changes to those "holdings", etc. |
| 15:18 |
Dyrcona |
makohund: We do a $9 for the main URL for each library that subscribes/"owns" the resource. You also need to make sure that the indicators have certain values, but I don't recall what those are off the top of my head. |
| 15:18 |
Dyrcona |
In some cases, the URLs are different for each library because of EZ-Proxy, etc. |
| 15:20 |
makohund |
Dyrcona: So you edit the 856 with the main URL of each incoming record, adding a $9 to it for each subscribing library? |
| 15:20 |
Dyrcona |
Not me personally, but yeah. |
| 15:21 |
makohund |
Any particular tools used for that? |
| 15:21 |
Dyrcona |
We have an automated process for matching them up with existing records and adding the new URLs from the incoming records, but mostly I think cataloging staff do the overlays with Vandelay. |
| 15:21 |
Dyrcona |
:) |
| 15:23 |
makohund |
I'm looking at adding large batches (about 15K or so) of new records for the first time, with no exiting $9s of course. |
| 15:24 |
Dyrcona |
We usually put the $9 in, first. I think the cataloging staff might use MARCEdit for that. |
| 15:25 |
Dyrcona |
https://pastebin.com/g4RGDJLr is what I use for loading batches of records that already have the $9 in them. It matches on ISBN and some other things. |
| 15:25 |
makohund |
That's what I'm up to... have MARCEdit open right now, poking around looking for the simplest way to go about it, to then train our catalogers how to do it. |
| 15:28 |
makohund |
Ooo... that looks neat... |
| 15:29 |
Dyrcona |
It works for us. You might want to change the match criteria. |
| 15:29 |
Dyrcona |
It used to be faster than Vandelay, but at one point got slower. I haven't tried it since I "improved" the optimization on our database server. |
| 15:30 |
makohund |
So basically... feed it a prepped MARC21 file, and it imports it. An alternative to Vandelay? |
| 15:31 |
makohund |
A bit better at handling large batches? |
| 15:35 |
Dyrcona |
Yes. You can run an arbitrary number of records through it without having to do smaller batches through Vandelay. |
| 15:36 |
Dyrcona |
Things may have improved in Vandelay recently, but we used to not be able to tens of thousands of records at once in Vandelay, at least not in a manner reasonable for the cataloging staff. |
| 15:38 |
Dyrcona |
I'd put the MARC file on a utility vm, and then schedule the program to run sometime at night. |
| 15:40 |
makohund |
Cool, thank you. Will have to take a bit of time to suss it out (I don't know the MARC functions very well), but bypassing chunking it up for Vandelay's sake sounds great to me. |
| 15:41 |
Dyrcona |
You'll notice it doesn't actually use MARC to parse the file. That's because "smart quotes" will break the MARC parsers in Perl. |
| 15:42 |
Dyrcona |
And, yes, you will eventually find MARC records with smart quotes in them. Copy and paste.... |
| 15:45 |
makohund |
Ack. Sounds like they need an "eat smart quotes, spit out regular quotes" filter of sorts. |
| 15:46 |
jonadab |
That would in principle not be a difficult regular expression. |
| 15:46 |
Dyrcona |
Well, the record terminator character in MARC 0x1E, is apparently part of a Windows smart quote regular expression. |
| 15:46 |
jonadab |
Oh. |
| 15:46 |
jonadab |
Eww. |
| 15:46 |
Dyrcona |
bleh.... reading and typing at the same time.... :) |
| 15:47 |
Dyrcona |
That's why I set the Perl record separator to the combination of the stop and start characters for the record. I think tsbere opened a bug on this for MARC::Record and/or MARC::Batch over a cpan some years ago. |
| 15:47 |
makohund |
Wow... what an ugly coincidence. |
| 15:51 |
makohund |
I'd wondered previously if perl might not be a better route for messing with the incoming 856's & $9's than MarcEdit. Any thoughts on that before I investigate either option? |
| 15:53 |
Dyrcona |
Well, it could be, but you'd have to layout what you want to add somehow. |
| 15:53 |
Dyrcona |
As for that "bug," I can't find it. |
| 15:57 |
makohund |
All I'm going to need to do is add three $9's & shortnames to the main url of every incoming record. Or maybe three new 856's, each with a $9. (Same three, to every record.) Thinking that if in the future another lib subscribes, I can just add another 856 for it. And if one stops subscribing, I can just delete the matching line. |
| 15:59 |
makohund |
Depends on how EG treats those $9s on separate 856s, if it is any different than when they are in the 856 with a particular URI. |
| 16:01 |
Dyrcona |
Well, the $9 has to be with the URL, and as I said with a new 856 for each library with the $u and the $9, because the $u is sometimes (often) different. |
| 16:08 |
makohund |
I'm pretty sure our $u is going to be the same across the board for these (no EZProxy or embedded subscription ID's or anything). So it looks like I'd just be needing to add three $9's to them. |
| 16:18 |
Dyrcona |
Yeah, not sure if that works, but I think it does. |
| 16:41 |
|
jvwoolf left #evergreen |
| 16:47 |
|
yboston joined #evergreen |
| 17:00 |
pinesol |
[evergreen|Bill Erickson] LP1806087 Ang catalog pending tabs offer manual redirect - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c2c4916> |
| 17:00 |
pinesol |
[evergreen|Bill Erickson] LP1806087 Synchronize browse code for staff cat / tpac - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1e58bb> |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-01T16:59:25,736751945-0500 -0> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:06 |
|
sandbergja_ joined #evergreen |
| 17:15 |
sandbergja |
For anybody who wants to shake up their bug squashing week, here's a simple python script that will give you a link to a random Evergreen bug every time you run it: https://github.com/sandbergja/random_evergreen_bug |
| 17:15 |
sandbergja |
full disclosure: it can keep me entertained for hours haha |
| 17:18 |
berick |
sandbergja++ |
| 17:18 |
berick |
heh |
| 17:18 |
berick |
we should add that to @pinesol |
| 17:19 |
sandbergja |
oh, that would be fun! |
| 17:23 |
sandbergja |
I feel like I saw a document at some point about how to make pinesol do fun things like that -- where would I find that? |
| 17:24 |
csharp |
sandbergja++ |
| 17:24 |
csharp |
sandbergja: https://limnoria.readthedocs.io/en/latest/ |
| 17:25 |
sandbergja |
ooh, thanks! |
| 17:25 |
sandbergja |
csharp++ |
| 17:25 |
csharp |
bshum has kind of been the supybot/limnoria master for a long time, so consult with him too :-) |
| 17:25 |
sandbergja |
Sounds like a plan |
| 17:26 |
csharp |
and we can get you access to lupin if wanted/needed for your mad-scientist experiments |
| 17:26 |
sandbergja |
mwahahaha |
| 17:26 |
csharp |
:-) |
| 17:45 |
|
eeevil joined #evergreen |
| 17:45 |
|
akilsdonk_ joined #evergreen |
| 17:45 |
|
ejk_ joined #evergreen |
| 17:45 |
|
Glen__ joined #evergreen |
| 17:53 |
bshum |
Ha! Sounds like a fun plugin idea to me sandbergja, sharp |
| 19:33 |
|
remingtron_ joined #evergreen |
| 23:11 |
|
sandbergja joined #evergreen |
