| # | Time | Nick | Message |
|---|
| # | 00:12:37 | atz has joined #evergreen |
| # | 00:14:54 | atz has left #evergreen |
| # | 02:22:48 | dbwells__ has joined #evergreen |
| # | 02:25:47 | dbwells_ has quit IRC |
| # | 03:24:13 | Yancho has quit IRC |
| # | 03:37:01 | Yancho has joined #evergreen |
| # | 03:37:01 | Yancho has joined #evergreen |
| # | 05:57:11 | Yancho has quit IRC |
| # | 06:10:03 | Yancho has joined #evergreen |
| # | 06:10:03 | Yancho has joined #evergreen |
| # | 06:10:14 | kivilaht3o has joined #evergreen |
| # | 06:10:29 | kivilaht3o | Is anyone out there who can hear me? |
| # | 06:11:27 | kivilaht3o | I am interested about how your system uses URL's. Specifically are there any checks for URL validity from marc data? |
| # | 06:11:56 | kivilaht3o | or for user generated data? |
| # | 06:33:12 | dbwells__ has quit IRC |
| # | 06:33:12 | jeff has quit IRC |
| # | 06:33:12 | bradl_ has quit IRC |
| # | 06:33:12 | mcarlson has quit IRC |
| # | 06:34:59 | dbwells__ has joined #evergreen |
| # | 06:34:59 | jeff has joined #evergreen |
| # | 06:34:59 | bradl_ has joined #evergreen |
| # | 06:34:59 | mcarlson has joined #evergreen |
| # | 07:43:57 | kivilaht3o has quit IRC |
| # | 08:05:52 | akilsdonk has joined #evergreen |
| # | 08:10:59 | j_scott has joined #evergreen |
| # | 08:29:04 | collum has joined #evergreen |
| # | 08:29:54 | Dyrcona has joined #evergreen |
| # | 08:31:37 | gdunbar has joined #evergreen |
| # | 08:31:45 | AaronZ-PLS has joined #evergreen |
| # | 08:37:45 | kivilaht3o has joined #evergreen |
| # | 08:48:07 | kivilaht3o | hi #evergreen! Do you have way to read authorities from external repositories? Like RESTful Ontologies? or any way to create a custom driver for some service? |
| # | 08:49:09 | kivilaht3o | point would be to give cataloguers a tool to choose from, for example, a national library authorities service when fine tuning bilbiographic data |
| # | 08:53:55 | tspindler has joined #evergreen |
| # | 08:54:43 | Callender has quit IRC |
| # | 08:55:47 | kmlussier has joined #evergreen |
| # | 08:57:42 | plux has joined #evergreen |
| # | 09:03:10 | Callender has joined #evergreen |
| # | 09:04:29 | Meliss has joined #evergreen |
| # | 09:37:59 | sal_ has joined #evergreen |
| # | 09:56:18 | tsbere | For kicks I decided to whip this up: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/multibrick_opensrf_xml |
| # | 09:56:21 | tsbere | Seems to work |
| # | 09:56:32 | tsbere barely tested....with a single machine "brick" |
| # | 10:01:22 | tsbere | Well, ok, just noticed that the logs go to the right place....but pids don't? Not sure what is up with that. <_< |
| # | 10:07:37 | mrpeters-isl | mine is still floating around out there somewhere too, i think |
| # | 10:35:16 | bradl_ is now known as bradl |
| # | 10:38:00 | jeff has quit IRC |
| # | 10:38:26 | jeff has joined #evergreen |
| # | 10:38:26 | jeff has joined #evergreen |
| # | 11:13:20 | b_bonner has joined #evergreen |
| # | 11:14:48 | rommeo has joined #evergreen |
| # | 11:15:42 | rommeo has left #evergreen |
| # | 11:17:08 | mrpeters-isl | what am i doing wrong with A/T that this won't come out of pending? http://pastie.org/3328334 |
| # | 11:21:39 | tsbere | mrpeters-isl: Dunno. Would need the event def too. |
| # | 11:21:48 | mrpeters-isl | its the edi |
| # | 11:22:06 | tsbere | and how do I know you haven't broken the event def? :P |
| # | 11:22:20 | senator | not an A/T troubleshooting expert, but I would probably start with two things: first, run that runner command without the redirect to /dev/null just in case there's significant output, and next grep the logs for anything (errors perhaps) related to that event id |
| # | 11:22:24 | mrpeters-isl | because i havent touched it |
| # | 11:22:41 | mrpeters-isl | no output, senator |
| # | 11:22:43 | tsbere | mrpeters-isl: Can you guarantee that nobody else touched it? |
| # | 11:22:54 | mrpeters-isl | nobody else would have the permissions |
| # | 11:23:34 | tsbere | mrpeters-isl: Does it have a granularity set? |
| # | 11:23:39 | mrpeters-isl | hourly |
| # | 11:23:48 | mrpeters-isl | i ran the hourly crontab entry |
| # | 11:24:01 | tsbere | did you run the run-pending one with an hourly granularity option? |
| # | 11:24:16 | mrpeters-isl | see line before yours |
| # | 11:24:29 | tsbere | The line in your paste does *not* say hourly. |
| # | 11:24:39 | mrpeters-isl | again, i said see the line before the last one you sent |
| # | 11:24:47 | mrpeters-isl | i ran the crontab entry for --granularity Hourly |
| # | 11:25:01 | tsbere | Is the granularity in the db set to Hourly or hourly? |
| # | 11:26:08 | mrpeters-isl | Hourly |
| # | 11:26:25 | tsbere | Also, the *default* appears to be no granularity. Thus you *have* edited it :P |
| # | 11:26:41 | mrpeters-isl | you're right, i have no idea what im doing |
| # | 11:27:20 | tsbere | Just paste the result of select * from action_trigger.event_definition where id = 23; so we can see what it says, would ya? |
| # | 11:27:25 | mrpeters-isl | regardless, it ran at some point while discussing here so problem solved |
| # | 11:27:56 | tsbere | Maybe you just hadn't waited until after 11:11 when testing? |
| # | 11:28:20 | mrpeters-isl | maybe i dont know. oh well, it worked. |
| # | 11:28:38 | mrpeters-isl | however, ERROR: attempt_translation failed for event 14639622, PO 102, template_output 4154181 |
| # | 11:28:47 | mrpeters-isl | so i'm sure its more special characters breaking the edit translator |
| # | 11:28:56 | mrpeters-isl | err, edi translator |
| # | 11:32:54 | mrpeters-isl | EDI Translator edi2json failed: RPC::XML::Client::send_request: HTTP server error: Can't connect to localhost:9191 (connect: Connection refused) |
| # | 11:33:24 | mrpeters-isl | is there something else undocumented that was added in 2.1 causing this to fail? I don't recall ever having anything running on 9191. |
| # | 11:33:41 | gmcharlt | mrpeters-isl: make sure edi_webrick is running |
| # | 11:38:51 | mrpeters-isl | thanks. guess i better make sure that starts on boto. |
| # | 11:38:53 | mrpeters-isl | *boot |
| # | 11:43:15 | alynn26 has joined #evergreen |
| # | 11:48:43 | tsbere | Question: In action_trigger event definitions, the "Processing Group Context Field" - Am I correct in assuming that when that is set and events are being processed the Reactor gets *one* call per set of events defined by that field being identical? |
| # | 11:53:15 | berick | tsbere: correct |
| # | 11:54:25 | Rommeo has joined #evergreen |
| # | 11:54:25 | tsbere | berick: Then the SMS hold notification one is likely horribly busted, as it has a context field of "sms_notify" - Would you agree that would be the case? |
| # | 11:54:56 | tsbere | Or is that supposed to hold the phone number for the notification? |
| # | 11:55:48 | tsbere thinks that combining SMS messages is a bad idea anyway |
| # | 11:56:03 | phasefx_ | sms_notify is like phone_notify, free text for holding the number |
| # | 11:56:07 | berick | tsbere: right, it's grouping on the sms phone number. |
| # | 11:56:47 | Rommeo has quit IRC |
| # | 11:57:01 | tsbere | berick: So if you have 5 holds how many of your 160 characters are remaining? <_< |
| # | 11:57:34 | kmlussier | tsbere: Important information is up top. Mainly, the number of holds that are available. |
| # | 11:57:54 | tsbere | kmlussier: Yea, but I know some gateways throw out messages that are too long. Or at least some used to. |
| # | 11:59:23 | kmlussier | tsbere: Do they? The ones we tested either sent piggy-back messages or cut off at the end. But we only tested the major carriers. |
| # | 12:00:04 | kmlussier | IIRC, Library Elf messages sometimes go over the 140 character limit. |
| # | 12:00:56 | tsbere | kmlussier: Last I checked, some do, some don't. Verizon used to when they first turned their gateway on, but they changed their system to stop doing that. |
| # | 12:02:19 | phasefx_ | if need be, we could put in per carrier logic to do our own truncation |
| # | 12:02:52 | phasefx_ grumbles, "SMS is such a rip-off anyway :) |
| # | 12:03:47 | phasefx_ | at $0.XX per msg, some patrons may very well want them grouped |
| # | 12:05:41 | kmlussier | phasefx_: heh, my cell phone bill was a little high the month we tested SMS. But, yes, that's why we liked the idea of grouping. |
| # | 12:12:34 | moodaepo has joined #evergreen |
| # | 12:12:38 | moodaepo has joined #evergreen |
| # | 12:21:24 | youdonotexist has joined #evergreen |
| # | 12:22:44 | tsbere | Anyone have thoughts on why open-ils.cat.biblio.record.metadata.retrieve would say not found for a bib that exists? |
| # | 12:27:13 | tsbere | n/m, had the wrong srfsh config file installed |
| # | 12:36:42 | AaronZ-PLS has quit IRC |
| # | 13:04:49 | dbwells__ is now known as dbwells |
| # | 13:05:58 | atz has joined #evergreen |
| # | 13:07:34 | atz | any evergreen folks at code4lib? |
| # | 13:08:03 | jeff | moodaepo and bshum and csharp are all there, I believe. |
| # | 13:08:11 | jeff | not sure beyond that. |
| # | 13:08:21 | bshum | Yeah moodaepo and I are here now |
| # | 13:08:32 | bshum | csharp is traveling here later today i think. |
| # | 13:08:45 | atz | cool. i'm in dchud's linked data talk right now |
| # | 13:09:02 | bshum | atz: Sweet, I'm upstairs listening to the "breaking silos" discussion. |
| # | 13:09:12 | bshum | I think moodaepo is downstairs listening about Solr stuff. |
| # | 13:09:32 | atz | i would have been at solr, but wasn't sure about it w/ erik not being able to make it |
| # | 13:09:53 | moodaepo | Aye I don't need to say where I am...bshum knows it all : ) |
| # | 13:10:00 | moodaepo | atz: It's stumbling along |
| # | 13:11:23 | denials | @later tell kivilaht3o There's nothing built-in to check URLs for validity from MARC data, but various sites have worked towards custom solutions; NRCan, I think (look for messages from Liam Whalen) |
| # | 13:11:23 | pinesol_green | denials: The operation succeeded. |
| # | 13:15:19 | vicent has joined #evergreen |
| # | 13:23:16 | edoceo has joined #evergreen |
| # | 13:25:28 | Dyrcona growls. |
| # | 13:26:17 | jeff idly wonders how many Growl notifications were triggered by Dyrcona's last action |
| # | 13:32:22 | hopkinsju has joined #evergreen |
| # | 13:35:03 | tsbere | screen scraping vendors-- |
| # | 13:35:38 | atz has quit IRC |
| # | 13:37:02 | AaronZ-PLS has joined #evergreen |
| # | 13:43:41 | hopkinsju has quit IRC |
| # | 13:46:48 | edoceo has left #evergreen |
| # | 13:46:52 | edoceo has joined #evergreen |
| # | 13:47:40 | atz has joined #evergreen |
| # | 13:52:05 | atz has quit IRC |
| # | 13:53:56 | hopkinsju has joined #evergreen |
| # | 14:02:01 | kbeswick has quit IRC |
| # | 14:02:02 | phasefx_ has quit IRC |
| # | 14:02:06 | kbeswick has joined #evergreen |
| # | 14:02:09 | phasefx_ has joined #evergreen |
| # | 14:02:10 | hopkinsju has quit IRC |
| # | 14:09:50 | youdonotexist_ has joined #evergreen |
| # | 14:10:25 | bshum | tag 852 |
| # | 14:10:30 | bshum | Oops |
| # | 14:10:43 | bshum shakes fist at pinesol_green |
| # | 14:11:13 | tsbere grumbles about his preferred server on freenode going down for a week.... |
| # | 14:11:18 | jeff hands bshum a: |
| # | 14:11:21 | jeff | @marc 852 |
| # | 14:11:21 | pinesol_green | jeff: Identifies the organization holding the item or from which it is available. May also contain detailed information about how to locate the item in a collection. (Repeatable) [a,b,c,e,f,g,h,i,j,k,l,m,n,p,q,s,t,u,x,z,2,3,6,8] |
| # | 14:11:33 | bshum | Yeah I just went to look that up ;) |
| # | 14:11:36 | bshum | Thanks jeff |
| # | 14:12:08 | jeff | strikes me that a link to loc might be useful there -- since looking up that many subfields over irc seems inefficient... :-) |
| # | 14:12:36 | jeff | (but who doesn't have the loc urls bookmarked / memorized, eh? ;-) |
| # | 14:13:12 | youdonotexist_ has quit IRC |
| # | 14:13:38 | youdonotexist has quit IRC |
| # | 14:20:18 | gmcharlt | jeff: who indeed? it's perfectly common knowledge, after all ;) |
| # | 14:23:43 | tsbere | Anyone have thoughts on why ONE service (open-ils.cat) would die multiple times (listener seemingly running, responds to nothing) without error messages in logs? |
| # | 14:26:49 | moodaepo has quit IRC |
| # | 14:32:49 | moodaepo has joined #evergreen |
| # | 14:34:02 | asmodai has joined #evergreen |
| # | 14:35:00 | asmodai | Guys, bothered Dan yesterday about this, but would like some other opinions as well. If you could get access to MusicBrainz.org data in the form of dumps or whatever, what aspects and what format would you prefer? |
| # | 14:36:04 | asmodai | Dan mentioned track listings and covers were interesting at least. |
| # | 14:36:11 | jeff | asmodai: json over http was how I had considered it in the past -- we were thinking of what it would take to fingerprint our physical audio collection with musicbrainz IDs in the bibliographic record. |
| # | 14:36:31 | jeff | others here may have other ideas. |
| # | 14:37:03 | jeff | i hadn't looked at it from the standpoint of getting dumps of the data, just looking it up at display time |
| # | 14:37:24 | tsbere will go for "a well defined API using some existing standard" |
| # | 14:37:28 | asmodai | jeff: Well, they were discussing a MARC gateway yesterday |
| # | 14:37:32 | asmodai | and I told them: MARC is evil, evil, evil |
| # | 14:37:39 | jeff | good. |
| # | 14:37:41 | asmodai | :) |
| # | 14:37:51 | denials | FWIW, I had assumed that we would take either the existing dumps or the live data feed from http://musicbrainz.org/doc/Live_Data_Feed |
| # | 14:37:55 | asmodai | That's one aspect I still remember when I worked for the library those years ago :) |
| # | 14:38:25 | asmodai | denials: This is you, right Dan? |
| # | 14:38:29 | denials | it's nice of musicbrainz to offer to format stuff for libraries, but as they're already offering the data... |
| # | 14:38:33 | denials | asmodai: ayup |
| # | 14:38:38 | asmodai | denials: :) |
| # | 14:38:40 | Dyrcona | MARC is great for what it was designed to do, but sucks for what it is used for today. |
| # | 14:38:50 | jeff | yeah, i had missed/forgotten about the live data feed there. musicbrainz++ |
| # | 14:38:54 | asmodai | Well, they seem to be open to whatever you guys deem is a good way forward. |
| # | 14:39:11 | Dyrcona | They have an existing API, don't they? |
| # | 14:39:24 | asmodai | And the MARC gateway, knowing what you guys did with microformats, Evergreen, and such things, really sounded bad |
| # | 14:39:25 | denials | when we were looking at the API, there were limitations on how many calls you could make (for understandable reasons) |
| # | 14:39:47 | Dyrcona | Seems to me I used some program written in Python to tag most of my rips of my CD collection. |
| # | 14:40:04 | jeff | asmodai: since you're here to ask, are you aware of any reliable alternatives to generating fingerprints by inserting the physical media -- can you key a lookup off of the product EAN/UPC, for example? |
| # | 14:40:12 | asmodai | Dyrcona: That's Picard interfacing with MB |
| # | 14:40:23 | Dyrcona | Yes, think it was Picard.... |
| # | 14:40:36 | asmodai | jeff: fingerprint of the disc or the individual tracks? |
| # | 14:40:37 | denials | http://musicbrainz.org/doc/XML_Web_Service/Version_2 at the bottom says "All users of the XML web service must ensure that each of their client applications never make more than ONE web service call per second" |
| # | 14:40:44 | jeff | asmodai: disc |
| # | 14:40:50 | asmodai | jeff: MB uses the disc ids at least |
| # | 14:41:08 | asmodai | jeff: also for lookup |
| # | 14:41:17 | asmodai | I know Picard has this button for looking up the disc |
| # | 14:41:24 | asmodai | The problem is that old CDs suck |
| # | 14:41:32 | asmodai | since they either lack it or are non-sensical |
| # | 14:41:44 | Dyrcona | Well, and ones from local bands no one else has heard of. :) |
| # | 14:41:56 | denials | which would scuttle the API's use for live lookups for added content, thus setting up a local musicbrainz replica server would probably make the most sense - or crawling through the dump and extracting / augmenting data in Evergreen |
| # | 14:42:04 | denials is sick and going home |
| # | 14:42:18 | Dyrcona | delials: go home. get well. |
| # | 14:42:20 | asmodai | denials: :( |
| # | 14:42:23 | asmodai | denials: Get well mate |
| # | 14:43:00 | denials | thanks! seeya |
| # | 14:43:29 | moodaepo has quit IRC |
| # | 14:45:34 | asmodai | jeff: http://wiki.musicbrainz.org/Disc_ID_Calculation |
| # | 14:45:49 | asmodai | jeff: Seems to be much better than the old CDDB IDv1 |
| # | 14:47:11 | asmodai | Also: MBIDs in libraries would be awesome. Rate limiting issues... are a |
| # | 14:47:11 | asmodai | problem how exactly? |
| # | 14:47:28 | moodaepo has joined #evergreen |
| # | 14:47:38 | moodaepo has joined #evergreen |
| # | 14:47:42 | asmodai | (I mean, I wouldn't think a library gets so much *new* stuff as for the |
| # | 14:47:44 | asmodai | rate limiting to be a constant issue) |
| # | 14:47:53 | asmodai | I can see how it'd be a problem while trying to link the back catalog |
| # | 14:48:02 | asmodai loves playing intermediate :) |
| # | 14:48:21 | Dyrcona | asmodai: Depends a lot on how the information is used. |
| # | 14:48:45 | reosarevok has joined #evergreen |
| # | 14:48:54 | reosarevok | asmodai, I can join, yes ;) |
| # | 14:48:55 | asmodai points at reosarevok |
| # | 14:48:58 | warp has joined #evergreen |
| # | 14:49:05 | asmodai | reo, meet the lovely library programmers :) |
| # | 14:49:10 | reosarevok | reosarevok points at warp |
| # | 14:49:17 | reosarevok | Librarians, meet the MusicBrainz programmer |
| # | 14:49:24 | warp | hello :) |
| # | 14:49:30 | asmodai | Hoi Kuno :) |
| # | 14:50:10 | reosarevok | So, asmodai tells me your problems were rate-limit related |
| # | 14:50:14 | asmodai | So basically what I get is that the/a web API is good enough, the problem is adding the new items and back catalogue |
| # | 14:50:14 | reosarevok | Can you elaborate on that? :) |
| # | 14:50:19 | kepstin-netbook has joined #evergreen |
| # | 14:50:32 | jeff | I see example queries using mbid for key, and returning EAN, but none for using EAN as the lookup key. I suppose if the EAN is present, and a full local copy is posessed, EAN lookups could be enabled (if not already possible). I do wonder as to EAN coverage, though. |
| # | 14:51:04 | kepstin-netbook | ean lookups can be done right now using a 'search' query. |
| # | 14:51:10 | reosarevok | Yeah |
| # | 14:51:13 | reosarevok | Lookups are not an issue |
| # | 14:51:16 | reosarevok | Coverage... can be |
| # | 14:51:45 | reosarevok | I wonder how many we have now |
| # | 14:51:51 | reosarevok | warp, can you query for that? ;) |
| # | 14:51:54 | jeff | (for kepstin-netbook / reosarevok 's benefit, my earlier question was) [is there] any reliable alternatives to generating fingerprints by inserting the physical media -- can you key a lookup off of the product EAN/UPC, for example? |
| # | 14:52:14 | reosarevok | So, yes, you can query by EAN/UPC |
| # | 14:52:55 | asmodai | Are the covers from MB, which generally come from Amazon, going to be a problem copyright-wise to reuse in, say, Evergreen ILS? |
| # | 14:53:08 | jeff | and with a dump, we could compare coverage of EAN across our holdings and then we'd have unknowns. those unknowns would either not be in MB, or would be in MB but not indexed by EAN. |
| # | 14:53:13 | reosarevok | Covers *always* are a problem copyright-wise |
| # | 14:53:28 | reosarevok | For everyone, everywhere |
| # | 14:53:33 | jeff | indeed. covera are always a problem. :-) |
| # | 14:53:38 | jeff | covers. |
| # | 14:53:46 | kepstin-netbook | to use the amazon covers, you'd have to independently do amazon api queries for them. |
| # | 14:53:47 | reosarevok | Is there an off-logging option here? |
| # | 14:54:11 | Dyrcona | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:54:11 | asmodai | jeff: At least reducing the list from 100% to a smaller percentage will be a big help already. |
| # | 14:54:14 | reosarevok | Ok |
| # | 14:54:17 | jeff | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:54:31 | asmodai | Ah yea, sorry, forgot to mention then. My bad. |
| # | 14:54:31 | jeff | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:54:34 | reosarevok | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:54:51 | reosarevok | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:54:57 | reosarevok | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:55:11 | warp | we have 981605 releases, 724504 of those have NULL in the barcode column. |
| # | 14:55:25 | reosarevok | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:55:30 | jeff | warp: and the barcode column is where one would find the EAN/UPC? |
| # | 14:55:37 | warp | jeff: yes. |
| # | 14:55:54 | reosarevok | jeff: do you store things like catalog numbers and the like too? |
| # | 14:55:56 | Dyrcona | MB might be able to get better EAN/UPC coverage out of this, though. |
| # | 14:55:58 | reosarevok | I'm guessing yes |
| # | 14:56:05 | moonburn has joined #evergreen |
| # | 14:56:08 | reosarevok | Dyrcona, you read my mind ;) |
| # | 14:56:13 | jeff nods |
| # | 14:56:24 | asmodai | win-win :) |
| # | 14:56:29 | jeff | seems only fair that we contribute back where possible |
| # | 14:56:32 | reosarevok | Basically, you can try to map using anything we both store |
| # | 14:56:38 | Dyrcona | yep |
| # | 14:56:49 | moodaepo has quit IRC |
| # | 14:57:04 | reosarevok | In a lot of cases, it'll need manual confirmation, TBH (even by cat# sometimes although that's less likely) |
| # | 14:57:12 | kepstin-netbook | catalog numbers probably have better coverage on musicbrainz than barcodes, i'd think - but the format is more variable, and they're harder to search |
| # | 14:57:31 | reosarevok | kepstin-netbook, Paul is working on making them easier to search though IIRC |
| # | 14:57:49 | reosarevok | (trying extra searches without spaces for example when searching for cat#s) |
| # | 14:58:58 | reosarevok | jeff, can I look at a sample of data? |
| # | 14:59:05 | reosarevok | One or two albums |
| # | 14:59:28 | reosarevok | I don't really need a big dump, just one example which is fairly complete on your side |
| # | 14:59:44 | moonburn | Hey guys, got some postgres questions, relating to how evergreen does it's thing. I need to be able to insert checkout dates for books, using nothing but a CSV file with the patron barcode, and book barcode (which i can differentiate, and I already have a parser for). What I don't have is the respective tables that the data needs to go in for the checkout history of said barcodes. |
| # | 15:00:30 | j_scott has quit IRC |
| # | 15:00:49 | moonburn | If you can point me in the right direction, I am in phppgadmin and can probably piece it together from that. |
| # | 15:00:55 | Dyrcona | moonburn: look at action.circulation for a start. |
| # | 15:04:12 | moonburn | Okay, all I have work with is the barcodes, and at this point I am just inserting old records. |
| # | 15:04:53 | vicent has quit IRC |
| # | 15:05:06 | vicent has joined #evergreen |
| # | 15:05:19 | Dyrcona | actor.usr and actor.card for patrons asset.copy for books |
| # | 15:05:35 | moonburn | ++ |
| # | 15:09:30 | vicent has quit IRC |
| # | 15:10:42 | vicent has joined #evergreen |
| # | 15:12:36 | reosarevok | Dyrcona / jeff: in any case, right now I'd trust lookup by EAN / cat# more than I trust lookup by disc-in-the-drive |
| # | 15:12:45 | tsbere | boopsie-- |
| # | 15:13:15 | jeff | tsbere: issues? |
| # | 15:13:41 | reosarevok | Mostly because those will give the right tracklist, which is good enough for people ussing it for tagging, but not necessarily the right *release* as per EAN and cat# which I guess would be important for you |
| # | 15:13:53 | jeff | reosarevok: more than the disc-in-drive fingerprint/id? that seems... surprising. why would EAN be more accurate / trustworthy? |
| # | 15:14:00 | tsbere | jeff: Just found out that they don't want to use the "unstable API" but are doing so because screen scraping stopped working due to TPac changing. The "unstable API" appears to be direct use of osrf-gateway-v1... |
| # | 15:14:33 | jeff | tsbere: interesting. thanks for sharing. |
| # | 15:14:37 | reosarevok | jeff: because of the way MB was organised before |
| # | 15:14:54 | reosarevok | Until last year, all releases with the same tracklist shared a MusicBrainz ID |
| # | 15:15:11 | tsbere | jeff: I am now considering a temporary lockout of their access to see if a number of issues stop happening. >_> |
| # | 15:15:14 | Dyrcona | jeff: speaking from experience, i've had some fun with European releases of some CDs with Picard in the past. |
| # | 15:15:16 | reosarevok | Problem with that is, they all also shared the DiscIDs |
| # | 15:15:39 | reosarevok | When we split them into a sensible data model, there wasn't really a right way of finding out what went where |
| # | 15:15:58 | jeff | tsbere: our tech rep there confirmed in late Jan that they are using the opensrf gateway for us. |
| # | 15:16:22 | reosarevok | So while most of them *should* map to the right "release group" (dunno how familiar you are with MB terminology, but that's basically a grouping of all releases of the same "album") |
| # | 15:16:23 | jeff | tsbere: since you mentioned "scraping", I just went and re-verified |
| # | 15:16:44 | reosarevok | It's likely that they won't map to the actual correct *release* |
| # | 15:16:55 | reosarevok | (any awesome ideas on how to solve the issue are welcomed btw) |
| # | 15:17:06 | tsbere | jeff: Well, I keep trying to track down a number of "undefined" values that float around in our logs on a regular basis, yet all normal entry points to those calls I have found check their inputs. If boopsie is calling the things *directly* though..... |
| # | 15:17:06 | jeff | reosarevok: interesting -- thanks for the detail! |
| # | 15:17:51 | reosarevok | The EANs, though, were always per-release-event |
| # | 15:18:10 | reosarevok | So when splitting the tracklists, those didn't become a problem |
| # | 15:18:31 | jeff | tsbere: check availability on an item in the boopsie app, watch for the request, start observing all requests from that IP, confirm your suspicions? :-) |
| # | 15:19:05 | tsbere | jeff: Way too many boopsie requests coming through.....and not sure what records are causing the possible issues. |
| # | 15:19:27 | reosarevok | ping me when your actual urgent problems are solved and we can keep talking :) |
| # | 15:19:42 | Dyrcona | ah, the joys of running the master branch. |
| # | 15:19:48 | jeff | tsbere: ah. |
| # | 15:20:21 | tsbere | jeff: I would look up the record IDs in the logs.....but that is the "undefined" parameter. >_> |
| # | 15:20:48 | jeff | reosarevok / kepstin-netbook / warp / asmodai : thanks for letting us pick your brains! |
| # | 15:21:01 | asmodai | I'm just a facilitator. |
| # | 15:21:04 | asmodai | :) |
| # | 15:21:24 | reosarevok | jeff: about the rate-limiting issues asmodai mentioned... installing your own MB server + search server should fix those |
| # | 15:21:30 | jeff | tsbere: ooh, so check your bib extracts as delivered to boopsie and look to see if your 901$c / 001 is undefined. |
| # | 15:21:43 | reosarevok | As you're a non-commercial service (you are, right?) you would get free hourly replication anyway |
| # | 15:21:56 | tsbere | jeff: Not my job. Dyrcona might be involved with that, though. |
| # | 15:22:11 | jeff | reosarevok: yep, perfectly logical. not sure I was the one who mentioned rate limiting, but a local copy or a shared copy for other libs to use seems like a good solution. |
| # | 15:22:29 | Dyrcona | jeff: denials mentioned the rate limiting. |
| # | 15:23:08 | jeff reminds himself that a bug does not require a patch to be useful |
| # | 15:23:37 | asmodai | reosarevok: Most of the libraries would be at least. |
| # | 15:24:05 | asmodai | << denials>> http://musicbrainz.org/doc/XML_Web_Service/Version_2 at the bottom says "All users of the XML web service must ensure that each of their client applications never make more than ONE web service call per second" |
| # | 15:24:15 | asmodai | << denials>> which would scuttle the API's use for live lookups for added content, thus setting up a local musicbrainz replica server would probably make the most sense - or crawling through the dump and extracting / augmenting data in Evergreen |
| # | 15:24:19 | asmodai | for context |
| # | 15:24:35 | reosarevok | Ok, so yes |
| # | 15:24:42 | reosarevok | Replicated server is the way to go |
| # | 15:24:56 | jeff | yes. |
| # | 15:24:57 | reosarevok | Not sure how it would work if you have both commercial and non-commercial users |
| # | 15:25:40 | Dyrcona deletes the extracts when they are done. |
| # | 15:27:12 | Dyrcona doesn't know of any commercial Evergreen installations, but isn't 100% clear on what we're discussing. :) |
| # | 15:27:32 | reosarevok | http://musicbrainz.org/doc/Live_Data_Feed |
| # | 15:27:49 | Dyrcona | Well, yeah. But are we talking about 1 server for the community, or what? |
| # | 15:28:11 | reosarevok | Good question :p |
| # | 15:28:11 | asmodai | Dyrcona: local premise caching servers I thought? Haha, but I could be wrong. |
| # | 15:28:39 | reosarevok | I don't know a lot about how evergreen-powered libraries actually work tbh |
| # | 15:28:46 | reosarevok | So I don't know what's a good setup |
| # | 15:29:00 | Dyrcona | ok. this is really jeff and denials thing, anyway, I think. |
| # | 15:29:32 | jeff | side project for me. no direct timeline. it interests me and i see some potential. |
| # | 15:29:38 | Dyrcona | for some of the bigger sites, such as mine, having our own server would make sense. |
| # | 15:29:43 | jeff | and dbs is sick -- poor guy |
| # | 15:29:45 | asmodai | Dyrcona: Just for my own sanity, there are for-profit libraries around, aren't there? Otherwise I really need to stfu more :) |
| # | 15:29:47 | Dyrcona | smaller sites might want to share 1. |
| # | 15:30:04 | asmodai | jeff: Well, I asked denials about it, since reosarevok mentioned a MARC gateway yesterday. |
| # | 15:30:08 | gmcharlt | asmodai: they do exist in the sense the commercial entities have libraries |
| # | 15:30:09 | warp | jeff: yeah, I figured dbs would hang out here. I met him at the GSOC summit. |
| # | 15:30:14 | Dyrcona | asmodai: there are, but I don't know of any running evergreen. |
| # | 15:30:23 | asmodai | And my instinct still goes: MARC, AAAAAAAAAAAAAAAAAAAAAAAAAAAAH |
| # | 15:30:30 | asmodai | Fight or flight, right there. |
| # | 15:30:39 | asmodai | gmcharlt / Dyrcona: Point taken. |
| # | 15:30:48 | Dyrcona | asmodai: that's true for those of us who work with it on a daily basis. |
| # | 15:31:09 | gmcharlt | ... save that flight isn't yet an option |
| # | 15:31:16 | Dyrcona writes a little something to looks for missing 001 and 901$c. |
| # | 15:31:28 | asmodai | Dyrcona: I regularly raise a glass of spirits in honour of you guys and your persistence in the face of MARC. |
| # | 15:31:33 | edoceo | If I wanted to torture myself and build a web-front-end for Evergreen using, say PHP (or something else); step one is to build an XMPP api so I can talk to evergreen; yea? |
| # | 15:32:00 | asmodai | warp: Yeah, unfortunately denials went home sick :( |
| # | 15:32:08 | Dyrcona | edoceo: use osrf-http-translator, its easier. |
| # | 15:32:33 | edoceo | Oh, thx! |
| # | 15:32:47 | Dyrcona | actually.... |
| # | 15:32:58 | Dyrcona | I think jeff might have started working on a php implementation. |
| # | 15:33:07 | jeff | when maintain_control_numbers came into existence, I don't think there was anything to ensure that existing records got control numbers. |
| # | 15:33:31 | jeff | but around that time, OpenILS::WWW::Exporter lost the ability to add/update 901$c |
| # | 15:33:39 | Dyrcona | jeff: we migrated when about the time that maintain_control_numbers came into existence. |
| # | 15:34:47 | jeff chuckles at his most recent command history: |
| # | 15:34:49 | jeff | ack maintain_control |
| # | 15:35:30 | Dyrcona | jeff; plus we use our own export program. |
| # | 15:37:00 | jeff nods |
| # | 15:37:13 | jeff | which for one thing means that you can easily fix the matter. |
| # | 15:37:35 | jeff | (not to say that i can't fix the issue here also -- need to) |
| # | 15:45:27 | tsbere | jeff: Figured out how to figure out what boopsie is doing easily. Doesn't look like they are doing anything funky directly.....unapi is likely busted partially though (or, at least, what little digging I have done points in that general direction).....and boopsie uses unapi too. |
| # | 15:52:08 | jeff | tsbere: thanks for the info. |
| # | 15:54:59 | kepstin-netbook has left #evergreen |
| # | 16:00:09 | Meliss has quit IRC |
| # | 16:01:09 | edoceo | Dyrcona: hmm; I'm trying with curl but and sending proper JSON but I get "no message body to process" in the logs; following http://open-ils.org/dokuwiki/doku.php?id=opensrf_over_http |
| # | 16:01:36 | tspindler has quit IRC |
| # | 16:03:23 | Dyrcona | edoceo: you set the headers properly? |
| # | 16:03:42 | Dyrcona | i've played with it a little bit in Java, but don't have the code handy. |
| # | 16:03:53 | akilsdonk has quit IRC |
| # | 16:07:50 | collum has quit IRC |
| # | 16:09:44 | edoceo | Yea, I think I idid |
| # | 16:10:18 | edoceo | Here's my pastebin: http://pastebin.com/UMjU3HYy |
| # | 16:11:18 | Dyrcona | I'm not that familliar with curl. Does --data-binary do a POST? |
| # | 16:11:37 | edoceo | POST /osrf-http-translator HTTP/1.1 |
| # | 16:11:46 | edoceo | Content-Type: application/json; Content-Length: 179 |
| # | 16:12:14 | edoceo | But some show my post content should just be JSON data and some show osrf-msg="$json_data" |
| # | 16:12:49 | Dyrcona | Actually, try it with X-OpenSRF-service an not X-OpenSRF-to. |
| # | 16:13:16 | Dyrcona | You use X-OpenSRF-to for subsequent messages after the server sends a X-OpenSRF-from. |
| # | 16:13:33 | edoceo | Oh |
| # | 16:14:07 | plux has quit IRC |
| # | 16:14:43 | edoceo | K, I tried with "X-OpenSRF-service: opensrf.simple-text" and still get no bytes back :( and "no message body to process" in the logs |
| # | 16:15:02 | plux has joined #evergreen |
| # | 16:17:25 | Dyrcona | edoceo: I'd need to reference my code again. |
| # | 16:17:50 | Dyrcona | I think I made a stateful connection with CONNECT, etc. |
| # | 16:17:56 | edoceo | Hmm, docs don't match code: in osrf_http_translator.c line 123: trans->body = apacheGetFirstParamValue(params, "osrf-msg"); - so we need that param it looks like |
| # | 16:18:31 | edoceo | progress!!! XMPP message resulted in error code 503 |
| # | 16:18:36 | Dyrcona | I know I did a couple of tiny examples: 1 where I made a simple request for bib sources, and another where I logged in, made a request for a patron's data and logged out. |
| # | 16:18:51 | Dyrcona | ah, well, that's something, I guess. |
| # | 16:18:55 | edoceo | I would love you forever if you could send me those samples |
| # | 16:19:01 | edoceo | :* |
| # | 16:19:16 | Dyrcona | They're in java, but I could send them after stripping out the passwords, etc. |
| # | 16:19:46 | gmcharlt | edoceo: if you haven't seen it yet, you may find coffeecode.net/archives/180-Fetching-item-availability-from-Evergreen-using-the-OpenSRF-HTTP-gateway.html useful |
| # | 16:20:24 | edoceo | I had not see that and it is very useful; thank you! |
| # | 16:21:16 | Dyrcona | I suppose you have seen this: http://journal.code4lib.org/articles/3365 |
| # | 16:21:37 | Dyrcona | dbs++ |
| # | 16:24:50 | edoceo | Not that specific article but those samples are repeated around the webs |
| # | 16:26:37 | Dyrcona | The first half of the article is really good, too. I recommend them to anyone getting started in Evergreen hacking. |
| # | 16:27:11 | edoceo | Oddly now I'm getting a 503 from osrf_http_translator but apache responds with a 404 |
| # | 16:29:29 | Dyrcona wonders why the container methods are in open-ils.actor..... |
| # | 16:29:57 | Dyrcona | I guess because they belong to a user, huh? |
| # | 16:32:00 | edoceo | Oh, yea! Got it! Thanks guys! |
| # | 16:33:05 | berick | Dyrcona: iirc, they needed to live somewhere, and one container type is for users, so... |
| # | 16:34:29 | tsbere | berick: open-ils.container sounds like a good name |
| # | 16:34:30 | tsbere ducks |
| # | 16:34:46 | Dyrcona | Yet another listener to run..... Whee! |
| # | 16:35:12 | jeff | hopefully I'm not way off on https://bugs.launchpad.net/evergreen/+bug/927900 |
| # | 16:35:12 | pinesol_green | Launchpad bug 927900 in Evergreen "Bib records may not have a 901$c after upgrade" (affected: 1, heat: 6) [Undecided,New] |
| # | 16:35:18 | berick | sure, but if we add a service for everything that doesn't neatly fit somehwere.. what Dyrcona said (and more) |
| # | 16:37:02 | atz has joined #evergreen |
| # | 16:38:14 | edoceo | Anyone feel like speculating wildly about the performance difference I'd see on native XMPP vs OSRF-HTTP translator ? I'm thinking that if I go native XMPP my tools would be a touch faster? |
| # | 16:39:02 | kmlussier has left #evergreen |
| # | 16:39:29 | gdunbar has quit IRC |
| # | 16:39:31 | gmcharlt | edoceo: IMO, the difference isn't enough to matter -- unless you're keen to implement XMPP in PHP regardless ;) |
| # | 16:42:52 | Dyrcona | edoceo: I've been wanting to make a set of client libs to use osrf-http-translator so you can run the programs from anywhwere. With XMPP, you need to be able to talk directly to the jabber server. With osrf-http-translator, you just need access to www server. |
| # | 16:44:09 | jeff | using the gateway (or the translator, but the gateway gets you a lot) makes it easier to integrate -- especially in a consortium. |
| # | 16:44:50 | jeff crosses his fingers and upgrades virtualbox |
| # | 16:49:22 | vicent has left #evergreen |
| # | 16:55:29 | moodaepo has joined #evergreen |
| # | 16:56:04 | tsbere has decided he procrastinated on "make hold emails obey email_notify" long enough.....and then went further than he had to |
| # | 17:09:49 | atz has quit IRC |
| # | 17:10:12 | atz has joined #evergreen |
| # | 17:12:18 | jeff debates between "push from workstation, pull to test vm" vs "copy working dir to test vm" and opts for "just try one and see how it goes" |
| # | 17:13:35 | atz | pull is easier to roll back (even partially) |
| # | 17:14:26 | jeff | in the case of evergreen, i'm still "make install" from the git working dir, regardless of if i'm pulling or just scping the whole dir over. |
| # | 17:15:16 | jeff | unless i opt for "just replace this one file and restart services", which all too quickly leads me down the path of editing the files in place, and having a "test vm" that contains the only copy of a fix. :P |
| # | 17:15:38 | jeff | like many things, it seems to boil down to breaking bad habits. :-) |
| # | 17:15:45 | Dyrcona | jeff: I typically edit on my workstation, commit, and pull on the test vm. |
| # | 17:16:02 | Dyrcona | then if it is a simple fix, I might copy from the git dir to installation dir on the vm. |
| # | 17:16:06 | tsbere uses the test VM as his dev environment |
| # | 17:16:15 | Dyrcona | well, yeah, so do i. |
| # | 17:16:16 | jeff | cool. pulling from your workstation to the vm, or is there a remote that you push to from your workstation? |
| # | 17:16:16 | moonburn has quit IRC |
| # | 17:16:25 | Dyrcona | i pull from the workstation. |
| # | 17:16:26 | tsbere | But I run windows on my workstation, and paths are a PITA there |
| # | 17:16:35 | jeff | *nod* |
| # | 17:16:48 | tsbere | So I just leave an SSH session to my VM open all the time |
| # | 17:16:54 | tsbere | And do all the work there |
| # | 17:18:41 | youdonotexist has joined #evergreen |
| # | 17:18:56 | Dyrcona | we use ssh keys and key forwarding all over the place, so I add my workstation as a remote on the development vm. |
| # | 17:23:34 | tsbere | Anyone have thoughts? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/hold_available_email_notify |
| # | 17:25:42 | AaronZ-PLS has quit IRC |
| # | 17:30:11 | Dyrcona has quit IRC |
| # | 17:33:58 | bshum | tsbere: Sounds good, based on the commit notes |
| # | 17:34:16 | bshum | tsbere: Scary that it doesn't already do that...? |
| # | 17:39:34 | atz has quit IRC |
| # | 17:50:09 | atz has joined #evergreen |
| # | 17:51:08 | hopkinsju has joined #evergreen |
| # | 17:52:15 | tsbere | bshum: Tis annoying that it doesn't already do that. |
| # | 17:54:34 | atz has quit IRC |
| # | 18:26:59 | grharry has joined #evergreen |
| # | 18:30:07 | grharry | I've setup evergreen ( good howto ! ). I have a situation that when I query a z39.50 server I get responses which are not in UTF-8 charset but in ISO8859-7 or WINDOWS-1253 ... is There a configuration option that lets me figure out that as in yaz-client ??? |
| # | 18:42:15 | sal_ has quit IRC |
| # | 18:47:27 | grharry has left #evergreen |
| # | 19:05:05 | moodaepo has quit IRC |
| # | 19:26:46 | youdonotexist has quit IRC |
| # | 19:53:29 | reosarevok has quit IRC |
| # | 19:59:52 | pmplett has joined #evergreen |
| # | 20:34:56 | atz has joined #evergreen |
| # | 20:39:19 | pmplett has quit IRC |
| # | 20:45:07 | pmplett has joined #evergreen |
| # | 21:29:41 | _bott_ has quit IRC |
| # | 21:30:46 | _bott_ has joined #evergreen |
| # | 21:55:49 | Yancho has quit IRC |
| # | 22:11:13 | Yancho has joined #evergreen |
| # | 22:11:14 | Yancho has joined #evergreen |
| # | 23:01:40 | hopkinsju has quit IRC |
| # | 23:12:34 | pmplett has quit IRC |
| # | 23:54:34 | pmplett has joined #evergreen |
April 10-13