| # | Time | Nick | Message |
|---|
| # | 00:01:02 | collsk12_ | dbs: Do you want me to submit this bug through launchpad or the mailing list, etc.? |
| # | 00:01:10 | dbs | please do |
| # | 00:02:32 | collsk12_ | dbs: ok...I will try my best to explain it. |
| # | 00:03:31 | dbs | collsk12_: something simple like "latest rel_2_1 OpenLibrary added content handler attempts to call a non-existent method - and paste the error message" |
| # | 00:04:10 | collsk12_ | dbs: Thank you. |
| # | 00:08:10 | dbs | aha - rel_2_1 is missing commit 0a56871c84a00f77352e9b7c08a16d201dd8b51f |
| # | 00:08:24 | dbs | Ah, the good old days of SVN |
| # | 00:09:47 | phasefx | dbs++ |
| # | 00:17:28 | dbs | oh man, I hate revisiting this code |
| # | 00:17:53 | collsk12_ | dbs: Lol...sorry bout that. |
| # | 00:18:54 | dbs | @later tell eeevil check out user/dbs/array_accum_2_array_agg for a work in progress; tested most of the functions so far; some don't seem to work even with array_accum() |
| # | 00:18:54 | pinesol_green | dbs: The operation succeeded. |
| # | 00:20:08 | dbs | collsk12_: no, it's okay; complex though. I rewrote it all this summer to use the OpenLibrary Read API instead of their details / data APIs, the code in master is probably way more robust than the 2.1 code would be even if I fixed it up |
| # | 00:23:02 | collsk12_ | dbs: I see. Well, what do you suggest? |
| # | 00:23:25 | dbs | collsk12_: you open the bug, I'll work it out |
| # | 00:25:00 | collsk12_ | dbs: Thanks, dbs. And thanks phasefx, for all of your help. I have to try to get a couple of hours of sleep before work, so I'll be checking out. But I apologize for my frustration and I appreciate all of your efforts. |
| # | 00:25:18 | dbs | thanks for sticking with it |
| # | 00:25:45 | collsk12_ | dbs: I will. Thanks again and have a great night. |
| # | 00:26:06 | collsk12_ has quit IRC |
| # | 00:33:52 | dbs pushes user/dbs/lp872651-fix-openlibrary-ac to @working for a quick fix |
| # | 00:34:44 | rangi | dont u need sleep? :) |
| # | 00:39:01 | dbs | rangi: I really do |
| # | 00:39:15 | dbs | responded to the bug report as well |
| # | 00:41:58 | dbs also getting used to the changed asset.uri visibility scoping behaviour - will have a lot of 856 $9 subfields to update when that hits |
| # | 00:42:08 | dbs | gnite |
| # | 07:13:33 | Callender has quit IRC |
| # | 07:28:31 | bjwebb has quit IRC |
| # | 07:35:45 | Callender has joined #evergreen |
| # | 07:42:03 | collum has joined #evergreen |
| # | 07:59:30 | dbs has quit IRC |
| # | 08:02:33 | Callender has quit IRC |
| # | 08:06:29 | tspindler has joined #evergreen |
| # | 08:06:59 | wolf29 has joined #evergreen |
| # | 08:07:30 | wolf29 | Morning! |
| # | 08:09:27 | wolf29 | Following the 2.1.0 readme.. This doesn't seem to go on my remote db server: postgres@EVERGREEN-TEST-02:~$ psql -vdb_name=evergreen -vcontrib_dir='pg_config --sharedir'/contrib -p 5433 |
| # | 08:10:36 | wolf29 | where is it invoking 'createdatabase.sql'? |
| # | 08:12:02 | wolf29 | I had already gotten an evergreen db, which my dump from 9.0 doesn't work on (lots and lots of errors) |
| # | 08:14:46 | adbowling-isl has quit IRC |
| # | 08:19:02 | wolf29 | Oh! now I see! The create-database.sql script doesn't work on 9.1. The errors show plainly that the sql is invoking stuff that did work on 9.0 |
| # | 08:19:43 | wolf29 | ..but doesn't work in 9.1 |
| # | 08:20:50 | Callender has joined #evergreen |
| # | 08:21:28 | wolf29 | I am giving up on postgresql-9.1 for the present. Thanks! |
| # | 08:31:30 | Dyrcona has joined #evergreen |
| # | 08:31:40 | AaronZ-PLS has joined #evergreen |
| # | 08:36:35 | tsbere | wolf29: The create-database I wrote should support 9.0 and 9.1 |
| # | 08:37:52 | tsbere | Of course, there is a 9.0 and earlier create script and a 9.1 and later create script to do that |
| # | 08:40:03 | wolf29 | I am using the script from the master git repo just before the release of 2.1.0 |
| # | 08:41:18 | tsbere | There should be a create_database_9_1.sql that is called from the --create-database parameter of the db config script if your server is running 9.1+ |
| # | 08:41:49 | tsbere | Which will fail if you don't have the contrib package installed on your db server, for the record. |
| # | 08:41:50 | wolf29 | my swap just failed. Possibly because /openils/var/log/osrfsys.log is 16GB |
| # | 08:42:24 | wolf29 | tsbere: I am pretty sure the database server has contrib-9.1 |
| # | 08:42:56 | wolf29 | I will check that, though. |
| # | 08:43:34 | wolf29 | The psql -vdb_name=evergreen -vcontrib_dir='pg_config --sharedir'/contrib -p 5433 thing just opened psql |
| # | 08:43:44 | wolf29 | ..from the readme |
| # | 08:43:55 | tsbere hasn't read the readme |
| # | 08:44:34 | wolf29 | I was blissfully unaware of the issue until dbs reminded me for the 23rd time to read the readme. :-) |
| # | 08:45:51 | tsbere | Hmmm |
| # | 08:46:05 | wolf29 | I was going to tail the 16GB osrfsys.log, but it is frozen. rm *.log appears to be in order. |
| # | 08:47:34 | Dyrcona | wolf29: If it's not a production system, you might want to run truncate -s0 /openils/var/log/*.log from time to time. |
| # | 08:48:26 | Dyrcona | on a production system, you might want to set up a cron job to rotate logs on a daily basis, and only keep a week or so of logs around. |
| # | 08:49:02 | wolf29 | Dyrcona: that is good advice. I was running loglevel=5, which probably contributes to the issue |
| # | 08:49:28 | tsbere | wolf29: For 9.1 just use the --create-database flag on eg_db_config.pl |
| # | 08:49:38 | Dyrcona | wolf29: oh, yes, definitely. log level 4 spews out tons more information than does the default of 3. |
| # | 08:50:11 | Dyrcona crashed his dev system by leaving it running at log level 5 for a few days. |
| # | 08:50:18 | wolf29 | tsbere: I will try that - it seemed to work, where the other thing does not. |
| # | 08:51:23 | wolf29 | Dyrcona: my dev system is purely crashed. I am going in to truncate the logs and see if I can get a look at the tails |
| # | 08:51:35 | raynerj has joined #evergreen |
| # | 08:51:53 | Dyrcona | wolf29: truncate -s0 will zero out the fails, there won't be any tails. |
| # | 08:52:07 | Dyrcona | ^fails^files |
| # | 08:52:10 | Dyrcona | :p |
| # | 08:52:37 | jeff | also worth noting, i believe you need to close any open filehandles on the logs to see the full effect of truncate. |
| # | 08:52:45 | jeff | though i defer to Dyrcona's experience there |
| # | 08:52:47 | tsbere | @later tell dbs The README currently only covers proper instructions for 9.0. I propose the following fix: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/readme_91 |
| # | 08:52:47 | pinesol_green | tsbere: The operation succeeded. |
| # | 08:53:26 | wolf29 | ^Tails^Fails^files lol |
| # | 08:55:05 | dbs has joined #evergreen |
| # | 08:55:11 | dbs has quit IRC |
| # | 08:55:11 | dbs has joined #evergreen |
| # | 08:55:27 | dbs | tsbere: along with your README fix, you'll need to add targets for the Makefile.install |
| # | 08:56:00 | Dyrcona | If anyone is looking for some rather small pull requests to review, might I suggest the following: |
| # | 08:56:12 | tsbere | dbs: What, I can't rely on people figuring that out themselves? ;) |
| # | 08:56:16 | Dyrcona | https://bugs.launchpad.net/evergreen/+bug/851871 |
| # | 08:56:21 | tsbere will take a shot at that in a few min |
| # | 08:56:32 | Dyrcona | https://bugs.launchpad.net/evergreen/+bug/851898 |
| # | 08:56:52 | Dyrcona | https://bugs.launchpad.net/evergreen/+bug/856566 |
| # | 08:57:10 | Dyrcona | https://bugs.launchpad.net/evergreen/+bug/859970 |
| # | 08:58:59 | dbs | tsbere; heh :) |
| # | 09:00:05 | dbs | tsbere: fwiw, it should just be a copy and paste of the pgsql server 90 debs with s/90/91/ - I just can't claim to have tested either debian or ubuntu with 91 targets, so have been reluctant to add that myself |
| # | 09:00:59 | csharp | I may be able to test that today - I'm planning to do a test import of pg_dumped 8.4 data into 9.X - might as well be 9.1 |
| # | 09:01:04 | csharp | (on squeeze) |
| # | 09:01:22 | dbs | csharp++ |
| # | 09:02:08 | tsbere | dbs: There anything I should know about 9.1 RPMS for that possible target? |
| # | 09:02:17 | tlilleberg has joined #evergreen |
| # | 09:02:38 | dbs | tsbere: I'm just waiting for my Fedora 16-beta system to finish updating its packages to see what it comes with |
| # | 09:02:54 | dbs | last I saw, it was nip and tuck as to whether 9.1 was going to make it in before the freeze |
| # | 09:03:20 | dbs | I'm honestly a little worried about throwing more complexity into the mix for 2.1 |
| # | 09:03:46 | dbs | documenting and supporting both 9.0 and 9.1 just seems headachey |
| # | 09:04:18 | tsbere | Then only commit the changes to master? |
| # | 09:04:50 | dbs | tsbere: that would be a great place to start, for sure |
| # | 09:05:25 | dbs | and if other folks have strong feelings about getting it all into 2.1, okay, as long as they commit to the support time :) |
| # | 09:06:07 | tsbere is currently only making changes for Debian/Ubuntu Server packages, no client package mods, and no Fedora instructions |
| # | 09:06:19 | dbs | tsbere++ |
| # | 09:07:19 | csharp | looks like ubuntu 11.10 has moved to 9.1 (not that we support non-LTS, of course); looks like wheezy has 9.0 and 9.1 |
| # | 09:07:45 | dbs hopes he can get some people to confirm some of the weird things he was seeing last night with in-db unapi and the like |
| # | 09:07:52 | dbs | fedora 16 has 9.1 |
| # | 09:08:25 | tsbere | dbs: Pushed the new commit to the same branch. I figure you can do fedora, since you have a machine to test with ;) |
| # | 09:09:58 | Meliss has joined #evergreen |
| # | 09:09:59 | dbs | thanks tsbere |
| # | 09:10:20 | Shae has joined #evergreen |
| # | 09:10:34 | dbs | csharp: are you suggesting that progress is inevitable? NO, I will fight to defend our dojo 1.3.3 / CDBI 3.0.1 / yaz 3.0.x FOREVER |
| # | 09:10:50 | csharp | heh |
| # | 09:11:15 | csharp | Evergreen::Frozen_at_1_6_0_1 |
| # | 09:14:14 | wolf29 | dbs: change is the only constant |
| # | 09:14:40 | dbs | So, buglet #1: if you have a test system around, SELECT asset.merge_record_assets(1,2); # should move a located URI 856 from bib 2 to bib 1; never works for me, looks like uri_text is NULL when it comes out of the counter loop |
| # | 09:15:12 | dbs | wolf29: thanks heraclitus |
| # | 09:15:38 | dbs | somewhere bradl is relishing his philosophy degree |
| # | 09:17:59 | wolf29 | dbs: I am about to be quoting the red queen from "Alice: Through the looking glass." |
| # | 09:18:13 | tsbere | I am going to try and implement this mess today: http://egdev.mvlcstaff.org/Circ_Matrix_Limits - Anyone have any comments/objections to that overall plan before I start? |
| # | 09:19:59 | lisah_ has joined #evergreen |
| # | 09:20:21 | atz__ has joined #evergreen |
| # | 09:20:55 | dbs | tsbere: not having used or done any dev on in-db circ, I'm not much use I'm afraid :( |
| # | 09:22:43 | tsbere | dbs: You might be able to point out a flaw or two that I am blinded to because I have done so much dev on in-db circ, though. |
| # | 09:23:26 | edoceo has joined #evergreen |
| # | 09:23:48 | dbs | tsbere: I'm undoubtedly missing something - it seems like config.limit_group needs something more than just id and name? just trying to figure out how a limit group gets attached to a patron, say |
| # | 09:24:15 | dbs is trying to get from here to there without knowing much about here or there :) |
| # | 09:24:16 | tsbere | They don't get attached to patrons, they get attached to circ matrix matchpoint rows. |
| # | 09:24:21 | atz has quit IRC |
| # | 09:24:24 | jeff | sounds like the current system does not permit the "local library or everywhere" limits, and doesn't work when items lack circ mods? there's no explicit "this is what the current system doesn't do" |
| # | 09:24:38 | jeff | dbs: nice |
| # | 09:24:41 | eeevil | tsbere: one objection, instead of config.circ_matrix_limits.global, I think a config.circ_matrix_limits.depth (ranging, instead of binary "here or everywhere" would be more generally useful |
| # | 09:25:12 | jeff | eeevil: sounds useful. |
| # | 09:25:13 | tsbere | jeff: Current system can only do limits when the items being counted have circ mods attached (but the item being restricted need not have one) |
| # | 09:25:51 | jeff | the second half of that part makes me scratch my head some :-) |
| # | 09:26:06 | eeevil | tsbere: another objection, pleasepleaseplease avoid array columns :) |
| # | 09:26:38 | jeff | how does the current system know what items to count by what circ mod if the item being restricted has no circ mod? |
| # | 09:26:43 | tsbere | jeff: Basically, the current system is also attached to a matchpoint row. So any item that matches the row can be limited (although only if that is the most specific row). The limit is then a collection of circ mods to count checked out items within. |
| # | 09:27:28 | jeff | got it. |
| # | 09:27:42 | eeevil | jeff / tsbere: the current system can count all circs, and circs grouped by one or more circ mod |
| # | 09:27:47 | tsbere | eeevil: Aww, but the only other way to accomplish that is with a secondary many to many table. And I wanted to avoid that. |
| # | 09:28:39 | eeevil | tsbere: for technical or effort reasons? |
| # | 09:28:56 | tsbere | Probably equal effort either way |
| # | 09:29:44 | tsbere | From a technical standpoint, checking would require a join on said table from action.circulation, which I think may be slower than doing a check on an array column contained within action.circulation |
| # | 09:29:51 | eeevil | tsbere: can it only ever be expected to be used inside the db? |
| # | 09:30:04 | tsbere | I wasn't even sure I would make it visible via the reporting interface |
| # | 09:30:08 | mrpeters-isl | tsbere: about srfsh call, from yesterday -- request open-ils.actor open-ils.actor.user.delete userid, destuserid, "hash" |
| # | 09:30:36 | tsbere | mrpeters-isl: Your authtoken hash should be the first param, I think. Could be wrong. |
| # | 09:30:50 | Dyrcona | it always is the first param. |
| # | 09:30:55 | mrpeters-isl | aha ok |
| # | 09:31:16 | sfortin has joined #evergreen |
| # | 09:31:27 | mrpeters-isl | ok, that worked |
| # | 09:32:18 | tsbere | eeevil: If you think the limit group(s) should be visible to the reporting interface I can make it a many to many table instead (but will still likely be passing some arrays around due to other limitations) |
| # | 09:32:51 | tsbere | eeevil: Or I could make it a space-delimited text field or something instead, as another possibility. |
| # | 09:35:57 | mrpeters-isl | http://paste.lisp.org/display/125273 -- syntax is ok, what is the can't locate object method via OpenILS::Utils::CStoreEditor trying to tell me? |
| # | 09:36:26 | mrpeters-isl | err wait...that paste isnt right...i did change the NULL's to undef |
| # | 09:37:08 | tsbere | You need a json query call. You can't just $e->$queryvar. |
| # | 09:38:22 | mrpeters-isl | hmm ok. was hoping i could just do an sql query, and die if it returns any results |
| # | 09:38:31 | akilsdonk has joined #evergreen |
| # | 09:41:10 | dbs | tsbere: thought - for master, maybe we only want to support fresh installs of 9.1? |
| # | 09:41:20 | dbs | (at least on distros where 9.1 is an option?) |
| # | 09:41:38 | tsbere | dbs: I have no problem with that, personally, as I dev on 9.1 now anyway ;) |
| # | 09:41:43 | dbs | heh |
| # | 09:41:56 | tsbere tweaks his circ matrix limits doc a bit |
| # | 09:42:48 | eeevil | tsbere: if there's no obvious use for reporting, how about use the array (but boo on no RI), don't put it in fm_IDL at all, and if we need to expose it we'll make a view that maps that field to a subordinate table [ select row_number() over (), * from (select id, unnest(limit_groups) from action.circulation)x ] ... maybe we don't even need the outer row_number() query |
| # | 09:43:09 | dbs will make it so, leaving the 9.0 instructions in place just for Fedora 15 until Fedora 16 is official |
| # | 09:43:17 | yboston has joined #evergreen |
| # | 09:43:34 | dbs | look at eeevil showing off his new love of windowing functions |
| # | 09:43:55 | tsbere | eeevil: Perl code will need to be able to dump data into wherever the data lives, due to how the entire checkout process works. I think that means it needs to be in the IDL, now that I think about it. |
| # | 09:44:26 | eeevil | booo |
| # | 09:44:49 | eeevil | dbs: I KNOW, RIGHT?! THEY'RE TOTALLY BADASS |
| # | 09:46:12 | dbs | tsbere: pushed your changes, and a few further tweaks to focus on 9.1, to master |
| # | 09:46:16 | wolf29 | tsbere: here is the error that shows when I run the /usr/lib/postgresql/9.1/bin/psql -p 5433 < lts-evg.sql :=: http://pastebin.com/jYzJ187t |
| # | 09:48:12 | dbs | wolf29: I guess the question is "what is lts-evg.sql?" |
| # | 09:48:23 | dbs is interested in "WARNING: => is deprecated as an operator name" |
| # | 09:48:41 | tsbere | dbs: That is hstore, been happening for a while. |
| # | 09:48:50 | tsbere | Nothing in our code specifically |
| # | 09:48:53 | dbs | tsbere: I know it's hstore |
| # | 09:49:19 | dbs | I guess the extension will take care of itself in the future |
| # | 09:49:40 | wolf29 | dbs: lts-evg.sql is the dump of the postgresql-9.0 database that was running on the same server |
| # | 09:49:53 | tsbere | eeevil: I can't see how the matchpoint-based limits can do an "all items out" check. Or is that somewhere else and you were just lumping that in due to it being a limit? |
| # | 09:50:42 | dbs | wolf29: so... you're trying to load a 9.0 database into a 9.1 server? |
| # | 09:51:21 | wolf29 | dbs: sort of the same as when the 8.4 was loaded into the 9.0.. |
| # | 09:51:38 | eeevil | tsbere: it's the group max out thing. not on the matrix proper, but might as well be -- treated equally |
| # | 09:51:49 | wolf29 | that worked somewhat. |
| # | 09:51:52 | dbs | wolf29: and you dumped the database using raw SQL? |
| # | 09:52:24 | wolf29 | pg_dumpall |
| # | 09:52:28 | wolf29 | :-) |
| # | 09:52:49 | dbs doesn't want to put any time into trying to support that |
| # | 09:54:07 | wolf29 | dbs: is it as bad as all that? |
| # | 09:54:32 | dbs | wolf29: an hour here, an hour there |
| # | 09:55:08 | wolf29 | dbs: there was a better way to gre the dump, then? |
| # | 09:55:41 | dbs | wolf29: here's how the upgrade instructions suggest handling database upgrades: http://evergreen-ils.org/dokuwiki/doku.php?id=upgrading:evergreen:2.0.10_to_2.1.0 |
| # | 09:56:00 | wolf29 | dbs: thanks |
| # | 09:56:01 | dbs | step 5 |
| # | 09:56:37 | wolf29 | aha! |
| # | 09:58:55 | wolf29 | but that does not exactly address 9.0->9.1 either.. |
| # | 09:59:29 | dbs | oh, you got me there. I wonder if there are 9.0 / 9.1 analogues of the 8.4 / 9.0 commands and directories |
| # | 09:59:42 | dbs wrings his hands anxiously |
| # | 10:00:21 | wolf29 | 9.1 is different even from my viewpoint (woodland creatures et al..) |
| # | 10:01:18 | dbs | wolf29: so maybe you should stay on 9.0 |
| # | 10:02:37 | wolf29 | dbs: it would be different if I was just starting fresh, I guess. Then it would just be the issue of importing from marc records someplace. |
| # | 10:03:02 | dbs | why are you trying to get to 9.1? |
| # | 10:03:40 | dbs | trailblazing is great, but you need your own machete |
| # | 10:04:55 | wolf29 | dbs: I am working on preparation for our community bleeding edge machine, and Ubuntu gave me 9.1 as part of a recent dist-upgrade. I have them in tandem on all my 9.0 machines |
| # | 10:05:41 | bshum | Bleeding edge Evergreen probably doesn't mean you have to be bleeding edge PG/Ubuntu |
| # | 10:05:52 | tsbere | eeevil: Updated my plans there with a depth setting (kept the global flag, changed meaning a bit), changed so that the same limit rule can be applied to multiple matchpoints by changing that linkage out a level, added an action.circulation_groups for the circ/group linkage. That cover anything you were concerned about? |
| # | 10:05:54 | bshum | Just saying, though I admire your guts |
| # | 10:06:55 | wolf29 | bshum: Thanks. I think I will stay with 9.0 for a little while, then. |
| # | 10:08:19 | dbs | Dyrcona: am i missing something, or does https://bugs.launchpad.net/evergreen/+bug/851871 not identify the branch that you want pulled? |
| # | 10:08:46 | eeevil | tsbere: ... after stepping away for a bit, I'm thinking more now that a mapping table with actual RI is really needed here |
| # | 10:09:09 | Dyrcona | dbs: you're not missing anything, the bug is. hang on a sec. |
| # | 10:10:31 | Dyrcona | dbs: I added the branch info. |
| # | 10:11:20 | mrpeters-isl | ok...i know i've got to be knocking on the door here with this -- http://pastie.org/2683125 -- the result of each json query should be setting $open_circs/$open_bills = an array of database id's if there are any open bills/circs, right? |
| # | 10:11:41 | mrpeters-isl | so the deletion should fail if $open_bills/$open_circs = anything other than undef |
| # | 10:12:46 | tsbere | eeevil: I think you lost me. Partially because my brain doesn't want to come up with anything reasonable for "RI" due to that being a common abbreviation in the game I played for 4 hours last night. |
| # | 10:13:21 | eeevil | tsbere: referencial integrity |
| # | 10:13:53 | eeevil | tsbere: circs, being important objects, shouldn't be wishy-washy about what they link out to |
| # | 10:14:16 | tsbere | ok |
| # | 10:14:39 | tsbere | But at the same time circs can be aged, and that would break quite a few links at that point, unless you want them to no longer be linked at that point. |
| # | 10:15:18 | eeevil | well, why are we recording them? I mean, what's the purpose |
| # | 10:16:11 | tsbere | My purpose? To be able to limit things based on things that aren't circ mods. Someone else's? Who knows. Technically you could use this with limits of 0 to tag circulations and never limit them. |
| # | 10:19:05 | eeevil | tsbere: no, sorry, I mean why put them on the circ object |
| # | 10:19:24 | tsbere | Because I can't put them on the copy or the patron? |
| # | 10:19:40 | tsbere | And the circ object retains no other possible linkages to the matchpoint after it is created? |
| # | 10:20:03 | eeevil | I mean, you test them and get a go or no-go answer. what purpose is there beyond that |
| # | 10:20:27 | senator | mrpeters-isl: couple things |
| # | 10:20:31 | eeevil | the circ doesn't retain a whole lot of other caclulated values (fallthrough) too |
| # | 10:20:34 | tsbere | eeevil: Attaching the limit groups *that are not based on circ mods* to the circs so you can count the number of open circs with them later? |
| # | 10:20:45 | senator | 1) no results from a query is not the same thing as undef |
| # | 10:21:17 | kmlussier has joined #evergreen |
| # | 10:21:32 | senator | 2) you want your checkauth line (48 in your paste) to happen before you call $e->json_query() |
| # | 10:21:52 | senator | if i understand your intention correctly and you want to know whether there are results from those json_queries, |
| # | 10:21:58 | tsbere | eeevil: I want to create, say, a limit group of "Videos" and attach anything that is of that general marc type to it, so I can say "you can only have 10 videos out at a time", without needing to have circ mods on all the videos. |
| # | 10:21:58 | mrpeters-isl | right |
| # | 10:22:12 | mrpeters-isl | if any id's are in the result, then there are open circs or bills so the delete should die |
| # | 10:22:23 | eeevil | tsbere: ahh, see, what is going on here is not clear to me, then. I think what you're saying is that these are tags on circs, surrogates for (or similar to) circ mod, for use by later circ tests, not just for "this one" |
| # | 10:22:41 | eeevil | that wasn't clear in wiki page, to me, at least |
| # | 10:23:53 | senator | mrpeters-isl: cool. you want to do two things then. first make both your json_query calls look like this my $open_thing = $e->json_query({query...}) or return $e->die_event; what that does is bail out in case of actual error (not the same as getting an empty result set) |
| # | 10:25:55 | senator | mrpeters-isl: second thing, lines 51-52 should look like return $e->die_event unless @$open_bills; # no results |
| # | 10:25:56 | mrpeters-isl | ok. done. |
| # | 10:27:24 | tsbere | eeevil: Basically, the limit groups I want to link to circulations are a replacement for circ-mod centric limiting, with the added bonus of being able to add things that fall under multiple categories to multiple groups (say, a book/CD combo could count as a book and a CD, without needing a circ mod specific to that combination that both types of rules can check) |
| # | 10:28:00 | mrpeters-isl | senator: how does @$ differ from $@ |
| # | 10:28:18 | senator | well, my if/unless may be backwards from what you meant, but you get the idea |
| # | 10:28:34 | senator | mrpeters-isl: significantly, but you might want to google perl operators for a quality explanation |
| # | 10:28:46 | eeevil | tsbere: I get it now, I think. do these things aggregate when more than one matrix entry contributes to the final test set? |
| # | 10:28:59 | senator | my head is elsewhere and i don't want to give a faulty explanation |
| # | 10:29:01 | mrpeters-isl | yep thats what i was doing, and only came accross $@ so just wanted to check that was what you intended to use |
| # | 10:29:14 | mrpeters-isl | dont worry...i appreciate the help |
| # | 10:29:16 | tsbere | eeevil: Only if the fallthrough flag is set. If not, only the most specific one will catch (like the current system) |
| # | 10:31:47 | eeevil | tsbere: what this is really saying is "limit circs based on the use of this (these, in fallthrough) matchpoint" |
| # | 10:32:17 | tsbere | eeevil: With the possibility of not having a clue what the other matchpoints are saying, yea. |
| # | 10:32:32 | tsbere may need to add an owning lib to his limit groups, now that he isn't locking them to matchpoints directly |
| # | 10:33:25 | eeevil | well, wait now ... the config.circ_matrix_limits points at one matchpoint, you can't use one limiter (tag, whatever) across matchpoints |
| # | 10:34:03 | tsbere | The tags are defined by config.limit_group |
| # | 10:34:05 | eeevil | seems like you'd want different matchpoints to be able to "label" themselves with the same limiter |
| # | 10:34:18 | mrpeters-isl | we have progress! but, "Selected class not in FROM clause in JSON query" http://pastie.org/2683223 |
| # | 10:34:57 | eeevil | mmm... ok, got it |
| # | 10:35:02 | eeevil | strike my last |
| # | 10:36:28 | eeevil | now, you're recording groups in your array |
| # | 10:36:37 | eeevil | but, those can change while a circ is in flight |
| # | 10:36:48 | eeevil | shouldn't we record the limits themselves? |
| # | 10:36:58 | dbs | phasefx: you might want to peek at https://bugs.launchpad.net/evergreen/+bug/851898/comments/2 - "Import from z39.50 non-scrollable width UI issue", if you have any thoughts maybe post on the list (or just post a branch :)) |
| # | 10:39:18 | eeevil | hrm... no, not if it's only to be used for future circs |
| # | 10:39:43 | eeevil | create table action.circulation_circ_limit_map ( id bigserial primary key, circ FK action.circulation(id), limit_group FK config.limit_group(id) ); |
| # | 10:39:44 | yboston | hello everyone: when building the win-client, the makefile is using a bad XULrunner URL. It is trying to download xulrunner-3.6.22, but Mozilla is only currently offering 3.6.21 OR 3.6.23. Which one should I use for my win client? |
| # | 10:39:58 | yboston | For the record I am using a clean EG instalation from a recent branch belonging to senator (collab/senator/authorities-indb-with-nfi) |
| # | 10:40:08 | tsbere | eeevil: You looking at the latest revision of my page there? I did update it. |
| # | 10:40:22 | eeevil | and then, I'm down to nit-picking on things like table names (circ.limit_group should have a "circ_" in there somewhere) |
| # | 10:40:31 | eeevil | tsbere: I'll refresh |
| # | 10:41:13 | eeevil | tsbere: ahh, rock |
| # | 10:41:29 | tsbere is willing to adjust table names |
| # | 10:41:51 | eeevil | tsbere: re multi-column pkey, not supported in CDBI (and, by extension, cstore) so, surrogate key time! :) |
| # | 10:42:01 | dbwells | mrpeters-isl: I don't know the whole history of what you are working on, but are you referencing this page? http://www.open-ils.org/dokuwiki/doku.php?id=documentation:technical:jsontutorial |
| # | 10:42:26 | tsbere | eeevil: Bah. Stupid limits. :P |
| # | 10:42:56 | dbwells | mrpeters-isl: the examples are in Javascript, but the concepts are generally the same. |
| # | 10:43:27 | dbs | ahh. so now I grok why we have so many surrogate keys. CDBI |
| # | 10:43:34 | eeevil | tsbere: re config.circ_matrix_matchpoint_limits ... shouldn't that map between a group and a matchpoint, not a limit? |
| # | 10:43:59 | mrpeters-isl | dbwells: no, i hadn't seen that. thank you |
| # | 10:44:46 | eeevil | dbs: that was the original driver, yes ... and writing an ORM that understands multi-column keys is more non-trivial than, well, not. (also a factor: slony's need for single-column pkeys, at least in the olden days |
| # | 10:46:17 | mrpeters-isl | dbwells: history, is that i'm trying to modify open-ils.actor.user.delete to disallow a deletion when the patron has open bills or circs |
| # | 10:46:25 | mrpeters-isl | https://bugs.launchpad.net/evergreen/+bug/872862 |
| # | 10:46:55 | dbwells | mrpeters-isl: is this your latest code? http://pastie.org/2683125 |
| # | 10:47:10 | mrpeters-isl | no, let me repaste |
| # | 10:47:44 | mrpeters-isl | http://pastie.org/2683308 |
| # | 10:47:45 | tsbere | eeevil: let me tweak a few things naming-wise to make things clearer |
| # | 10:49:43 | mrpeters-isl | perhaps i'm doing something wrong in aliasing the "id" column to circid/billid |
| # | 10:50:27 | dbwells | mrpeters-isl: yes. It looks like you are being a bit more specific than necessary in a few places, but in general, changing 'billid' to 'mbts' should fix the first query, I think. |
| # | 10:50:36 | dbwells | mrpeters-isl: then same idea for the other. |
| # | 10:51:00 | mrpeters-isl | yeah, i don't think i even need to have the column => 'id' stuff, do you? |
| # | 10:51:34 | dbwells | mrpeters-isl: no, you don't. Something like 'select' => { 'mbts' => [ 'id' ] } |
| # | 10:51:45 | mrpeters-isl | yeah, was just typing that up heh |
| # | 10:51:53 | mrpeters-isl | that json tutorial is great, thanks for that |
| # | 10:53:19 | dbwells | mrpeters-isl: It's a must have, really, other than just poking around the code. I am pretty sure it is in the source tree somewhere, but I think the wiki page is up to date (probably hasn't changed much in a long time, if at all). |
| # | 10:59:38 | tsbere | eeevil: I did a bit of re-naming of tables (and some fields) |
| # | 10:59:43 | tsbere | and added some more explanation |
| # | 11:01:03 | phasefx | 0636 -> INSERT has more expressions than target columns on the null's |
| # | 11:02:08 | tsbere | Hmm |
| # | 11:02:11 | eeevil | phasefx: branch? |
| # | 11:02:18 | phasefx | master |
| # | 11:02:39 | tsbere | eeevil: Grace extend stuff. I apparently grabbed the seed values and forgot to remove the ,null at the end of each. |
| # | 11:02:41 | tsbere | tsbere-- |
| # | 11:02:56 | eeevil | I'll kill those |
| # | 11:03:03 | phasefx | fm_class is the column being used by the seed data variant |
| # | 11:03:55 | eeevil | change those too? |
| # | 11:04:04 | eeevil | looks like the upgrade script is correct |
| # | 11:04:09 | eeevil | should be bool |
| # | 11:04:41 | eeevil | oh, nm |
| # | 11:04:45 | eeevil | I was confused |
| # | 11:04:56 | eeevil | upgrade script fixed, pushing soon |
| # | 11:04:59 | dbs | anyone object to backporting https://bugs.launchpad.net/evergreen/+bug/851871 (use 'identifier|is[bs]n' instead of 'keyword' for import z39.50 local catalog searches) to rel_2_1? Seems like a fix, not a feature, to me |
| # | 11:05:40 | eeevil | dbs: agreed, sir |
| # | 11:05:49 | dbs | it shall be done |
| # | 11:06:57 | eeevil | phasefx: pushed |
| # | 11:07:10 | phasefx | eeevil: 0637 also busted (wrong version in the dependency check) |
| # | 11:07:17 | eeevil | cool... :( |
| # | 11:07:24 | wolf29 | does this make any sense? I am pointed back at the 9.0 db. The front-end is working - cannot log in on staff-client, web, srfsh and srfsh says " srfsh# math add 2 2 |
| # | 11:07:26 | wolf29 | ???: math add 2 2 |
| # | 11:07:27 | wolf29 | srfsh# |
| # | 11:08:10 | eeevil | phasefx: fixing in both master and 2.1 |
| # | 11:08:25 | phasefx | eeevil: thank you sir |
| # | 11:09:31 | eeevil | phasefx: actually, it's correct in 2.1 |
| # | 11:10:16 | phasefx | eeevil: fun |
| # | 11:10:41 | wolf29 | settings-test.pl shows everything is ok, except psql (PostgreSQL) 9.1.1 .. This is probably because on the frontend server it still is |
| # | 11:14:41 | tsbere | eeevil: Any questions/complaints about my current revision of my limits bit there? (And do you think I should keep the limits around for aged circs, or make them go away when circs are aged?) |
| # | 11:19:45 | eeevil | tsbere: I think recording the matchpoints is of more use for aged circs, but that's still a hard case to argue, since that's configuration and not real-world data ... so, shorter answer, I'm not at all in favor of keeping limits around for aged circs |
| # | 11:20:33 | tsbere | eeevil: Makes sense. |
| # | 11:21:55 | dbs | eeevil: unapi.biblio_record_entry_feed isn't actually being used anywhere, right? because I can't get it to work without throwing errors like http://pastebin.com/V6ui5D86 |
| # | 11:21:57 | AaronZ-PLS has quit IRC |
| # | 11:23:51 | eeevil | dbs: weird ... no, it's not in use yet, but I'd like to get something like it put together to replace (most of) supercat, at some point |
| # | 11:24:25 | dbs | eeevil: right. ran across that testing out ARRAY_ACCUM -> ARRAY_AGG replacements, and was surprised when it wouldn't work for me at all |
| # | 11:24:48 | eeevil | I'm surprised too ... |
| # | 11:25:07 | eeevil | dbs++ on the array_agg fun, though |
| # | 11:25:31 | dbs | eeevil: next up, replacing ARRAY_TO_STRING(ARRAY_AGG()) with STRING_AGG() |
| # | 11:26:08 | eeevil | dbs: curious, though, what's not working with array_accum? is it a "return null instead of empty array" thing of 9.1 vintage? |
| # | 11:26:35 | dbs | It seems to be working everywhere, I'm just (manually) testing to be sure |
| # | 11:27:17 | dbs | we've seen how relying on custom functions screwed over the postgresql planner before (see explode_array vs. unnest) |
| # | 11:27:20 | eeevil | ahh, so just looking to move to the built-in (c-based) one? |
| # | 11:27:26 | eeevil | indeed |
| # | 11:27:28 | dbs | exactly |
| # | 11:27:31 | mrpeters-isl | really_delete_user = really_frustrating_mrpeters-isl |
| # | 11:27:43 | mrpeters-isl | http://pastie.org/2683505 seems right...but i get "no data returned from server" |
| # | 11:27:59 | dbs | and ARRAY_TO_STRING(ARRAY_AGG()) with STRING_AGG() promises major performance improvements - at least in some cases |
| # | 11:28:42 | eeevil | cool |
| # | 11:31:31 | AaronZ-PLS has joined #evergreen |
| # | 11:31:50 | jeff | dbs++ |
| # | 11:32:22 | dbs repeats himself from last night, still doesn't get unapi.sitem - stream, unit, and uri are always going to be null from what he can see |
| # | 11:34:38 | mrpeters-isl | senator: dbwells: anything stick out at you in those json queries? it appears i'm doing them exactly as, say, hold_request_count does |
| # | 11:34:55 | egrev has joined #evergreen |
| # | 11:35:21 | mrpeters-isl | oh hey...helps if i put $user_id = $e->requestor->id unless defined $user_id; back :( |
| # | 11:36:52 | eeevil | dbs: hrm.. they shouldn't be (if there's data) ... however, I see the unit is using the "stream" column, which is wrong |
| # | 11:38:21 | dbs | eeevil: there's that. I just don't see where stream, unit, and uri get any non-NULL value before the CASE stmts |
| # | 11:38:30 | kfrg56 has joined #evergreen |
| # | 11:39:05 | eeevil | dbs: oh, you have to use the includes array to make them show up |
| # | 11:39:36 | eeevil | is that what you mean? |
| # | 11:40:26 | dbs | no. bah. stupid me, they're just columns on serial.item |
| # | 11:40:32 | eeevil | right |
| # | 11:40:33 | dbs | <!-- BANG |
| # | 11:42:45 | Dyrcona | #!/ |
| # | 11:43:05 | dbs | Dyrcona++ |
| # | 11:43:43 | mtate has quit IRC |
| # | 11:44:33 | mtate has joined #evergreen |
| # | 11:45:37 | kfrg56 | Good day everyone. I was wonderring if someone could give me a hand. Im currently in the process of starting and testing evergreen. For step 3 of starting Evergreen ( ./autogen.sh -c /openils/conf/opensrf_core.xml -u) and am currently receiving the error stating "router@private.localhost/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!!" any suggestions? |
| # | 11:47:39 | mrpeters-isl | put my changes to really_delete_user in a branch, as well, if that makes it easier to follow -- http://git.evergreen.lib.in.us/git/?p=Evergreen/.git;a=commitdiff;h=fde9ef3a281462789cd70d49f72e6bc33e3761ac |
| # | 11:50:11 | eeevil | dbs: I'll push a branch to fix s/stream/unit/ if you'd like to merge |
| # | 11:50:58 | eeevil | but it's just 'cwunit' in vim (and an upgrade script) so I'm fine just pushing it in. objections |
| # | 11:51:41 | dbs | eeevil: I have no objections. had made the change locally |
| # | 11:52:31 | mrpeters-isl | SELECT id FROM money.billable_xact_summary WHERE xact_finish IS NULL AND usr = 1003; returns "3" so why does srfsh respond with "Received no data from server" |
| # | 11:52:35 | mrpeters-isl | quit |
| # | 12:00:37 | dbs | eeevil: the "WHEN $4" in the REVERSE ARRAY_UPPER loop of biblio_record_entry_feed should be a $3, I think, but still throws a syntax error |
| # | 12:03:14 | kfrg56 has quit IRC |
| # | 12:03:42 | kmlussier has quit IRC |
| # | 12:04:34 | kmlussier has joined #evergreen |
| # | 12:05:12 | yboston | kfrg56: I am not an Evergreen expert, but it helps to know 1) which OS you are running; 2) which version of EG you are trying to install; 3) which set of instructions you are following |
| # | 12:11:02 | wolf29 | kfrg: did your srfsh tests work after you installed evergreen? (yboston++ - it helps to know what the basic install plaform is.) |
| # | 12:16:26 | dbwells | mrpeters-isl: sorry, stepped out for a bit. Nothing jumps out at me as incorrect in your code. Are you still getting an error? |
| # | 12:18:25 | jeff | sanity check 1: are you running the most recent copy of your code? :-) |
| # | 12:22:53 | dbwells | mrpeters-isl: I am off for lunch, will check back. |
| # | 12:26:14 | bshum | Hmm, anybody play with MARC federated search much? |
| # | 12:26:50 | gmcharlt | bshum: in general? yes |
| # | 12:27:18 | bshum | gmcharlt: We're checking on an issue that was recently reported about ISBN searching |
| # | 12:27:28 | bshum | gmcharlt: It seems that the search hangs and spins forever |
| # | 12:28:23 | gmcharlt | bshum: is it associated with particular Z39.50 targets or with the inclusion or exclusion of the Evergreen catalog in the search? |
| # | 12:28:52 | wolf29_ has joined #evergreen |
| # | 12:29:34 | wolf29 has quit IRC |
| # | 12:29:58 | bshum | gmcharlt: It's only the local catalog search. Which seems to be basing off keyword search? |
| # | 12:30:17 | bshum | If the logs are any indication |
| # | 12:30:31 | bshum | So maybe our keyword search is taking too long to resolve and the search spins to death? |
| # | 12:35:31 | mrpeters-isl | dbwells: yep, "Recieved no data from server" no matter what user I try to delete. One with bills, one with circ, one with nothing. |
| # | 12:36:41 | bshum | gmcharlt: Well, I guess I'm going to look at the dojo page for this (and js?) to see how it determines searching. Either way, looks like we should find a way of getting it to recognize the identifier metabib entries instead of just using keyword. |
| # | 12:37:09 | dbs | bshum: you're in luck |
| # | 12:37:31 | dbs | I just merged Dyrcona's fix that uses identifier|isbn / identifier|issn instead of keyword, where appropriate |
| # | 12:38:02 | dbs | assuming / hoping that the federated search uses the same back end and doesn't dupe code, of course :) |
| # | 12:38:56 | bshum | dbs: Oh, interesting. Also hoping it won't break 2.0 in weird ways. |
| # | 12:39:24 | bshum | Thanks for letting me know about that change either way. I'm sure it'll be handy |
| # | 12:40:17 | dbs | bshum: of course, only backported that to rel_2_1 |
| # | 12:40:40 | bshum | dbs: Our 2.0 system is slowly becoming a maze of special backports. |
| # | 12:41:02 | bshum | I'll be thankful to escape this version |
| # | 12:42:41 | tsbere | bshum: Backport enough stuff and you will find you are all of a sudden on 2.1 ;) |
| # | 12:47:08 | bshum | tsbere++ # funny |
| # | 12:48:19 | tsbere | mrpeters-isl: On your issues there, I think you don't need to do the open circs call at all. mbts should, I believe, contain the exact same info. |
| # | 12:48:47 | tsbere | mrpeters-isl: Beyond that, you get anything in the stderr logs? |
| # | 12:53:27 | mrpeters-isl | tsbere: what if they had open circs, but no bills on them? |
| # | 12:53:49 | tsbere | mbts would have a row saying "total owed: 0.0" |
| # | 12:53:56 | mrpeters-isl | oh, interesting |
| # | 12:53:56 | mrpeters-isl | ok |
| # | 12:54:21 | mrpeters-isl | let me get back to you on the logs...pulled away on something else right now |
| # | 12:57:30 | mrpeters-isl | i am having a hell of a time figuring out where patron.credit_forward_balance is getting it's data |
| # | 12:57:34 | dbs | did we ever solve the "titles sometimes are missing in overdue/reminder notices" issue? that thing sucks |
| # | 12:57:43 | tsbere | I think so |
| # | 12:57:55 | tsbere | But not in "hold couldn't be filled" notices |
| # | 12:58:06 | wolf29_ | tsbere: speaking of logs when memcached has an error, does it come up with "ERR" in the log? |
| # | 12:58:25 | tsbere | wolf29_: Dunno. You tell me. I haven't had to debug memcache errors. :P |
| # | 12:59:03 | wolf29_ | I am thinking along the lines of'grep "ERR" /openils/var/log/*.log ' |
| # | 12:59:05 | tsbere | dbs: Ahh, hasn't gotten anywhere yet. https://bugs.launchpad.net/evergreen/+bug/820006 |
| # | 12:59:09 | mrpeters-isl | ugh actor.usr.credit_forward_balance |
| # | 12:59:17 | mrpeters-isl | the last place i would have looked...i was in the money schema |
| # | 12:59:24 | dbs | tsbere: thanks, I guess :) |
| # | 12:59:54 | tsbere has a small pile of other changes in the MVLC production system templates, but included a variant of that for many |
| # | 13:01:46 | jeff | wolf29_: memcached itself will not log an error, but in at least some cases opensrf services will log at ERR when they encounter a problem stuffing something in memcached. i'm not certain about get failures, though. |
| # | 13:02:04 | jeff | open-ils.auth 2011-10-11 17:06:50 [ERR :1536:osrf_cache.c:63:131830348828173] Failed to cache key:value [oils_auth_jeff]:[b7110ae1ac58b4337217eabce41e50cc] - UNKNOWN READ FAILURE |
| # | 13:02:08 | jeff | (for example) |
| # | 13:03:43 | wolf29_ | jeff: I am bored with constant failure, so I am looking at the troubleshooting process itself. |
| # | 13:04:13 | mrpeters-isl | tsbere: http://paste.lisp.org/display/125276 --- logs |
| # | 13:04:23 | mrpeters-isl | so, my json query works |
| # | 13:04:25 | mrpeters-isl | it finds 1 result |
| # | 13:04:35 | wolf29_ | I have seen errors like that. Just restarting the memcached clears that sort of error, mostly, doesn't it |
| # | 13:05:14 | mrpeters-isl | strangely, it then tries to go on and do the circ query. should ahve just died after 1 result for the bill query |
| # | 13:05:30 | wolf29_ | jeff: memcached errors would be harder to regex http://fauna.github.com/fauna/memcached/classes/Memcached/Error.html |
| # | 13:05:31 | jeff | wolf29_: restarting memcached without restarting opensrf services will trigger that error the first time you try to log in -- and you may encounter it once for each active child process that HAD a connection to memcached before it was restarted. |
| # | 13:05:41 | tsbere | mrpeters-isl: No, you don't die until *after* you do both queries (if they came back with results) |
| # | 13:06:00 | mrpeters-isl | aha, so maybe killing the circ one like you say will be the fix |
| # | 13:06:02 | tsbere | mrpeters-isl: Your "or die_event" after the json query lines only catch if the json queries failed outright. |
| # | 13:06:10 | jeff | wolf29_: keep in mind the errors will usually be those generated by libmemcached, the client library that opensrf uses. |
| # | 13:07:53 | tsbere | mrpeters-isl: Also.....return $e->die_event unless @$open_bills; <-- That means "die unless we FOUND open bills", I think. Change the unless to if. |
| # | 13:08:58 | wolf29_ | jeff: I really want to develop efficient troubleshooting steps for myself. It will help me figure out what is happening when the next failure comes down the path. |
| # | 13:09:01 | mrpeters-isl | oh, duh |
| # | 13:09:57 | wolf29_ | jeff: of course, I will run right down the edge, which makes finding others' solutions more difficult. |
| # | 13:10:57 | jeff | wolf29_: if you're interested specifically in memcached errors from OpenSRF, you can look at ./src/perl/lib/OpenSRF/Utils/Cache.pm and ./src/libopensrf/osrf_cache.c in the OpenSRF source |
| # | 13:11:22 | mrpeters-isl | tsbere: http://paste.lisp.org/display/125276#1 looks like a winner, eh? (since it rolls back because the user has open bills) |
| # | 13:11:53 | tsbere | mrpeters-isl: You tell me. Does it work from the client? :P |
| # | 13:12:12 | mrpeters-isl | not that far yet hehe -- was a little spooked since it still returns Received no data from server |
| # | 13:12:20 | mrpeters-isl | but, deleting a user with no bills returns 1 |
| # | 13:12:21 | jeff | wolf29_: they seem to be logged at ERR level in both places, though I only gave it a casual glance. |
| # | 13:13:48 | mrpeters-isl | doesn't throw me an error, but the patron isn't deleted...so that's some progress |
| # | 13:14:12 | wolf29_ | Jeff: Thanks - That makes it easier. |
| # | 13:15:05 | mrpeters-isl | so, next step is to make the staff client throw a friendly error saying why the delete failed |
| # | 13:15:16 | mrpeters-isl dances!!!!!! |
| # | 13:19:27 | bshum | dbs: Handpatched the isbn/issn thing to our test system and it didn't break anything so far. Looks like the acq search is using the same code. |
| # | 13:19:48 | bshum is maybe "lucky" |
| # | 13:22:17 | bshum | It seems the initial search is fine, but subsequent searches for the same isbn fail to create a page. Maybe it's an acq.lineitem create problem of some kind... |
| # | 13:22:47 | senator | no results? or just blank screen? or what? |
| # | 13:22:52 | senator | bshum: ^-- |
| # | 13:23:52 | tater-laptop has joined #evergreen |
| # | 13:23:53 | bshum | senator: It's a white screen with the spinning logo |
| # | 13:23:58 | bshum | Just spins and spins |
| # | 13:24:02 | bshum | I'm checking osrfsys now |
| # | 13:24:11 | senator | also check the javascript console |
| # | 13:24:15 | senator | esp for anything about localeStrings |
| # | 13:25:46 | bshum | Ah, javascript console shows me what I was getting in osrfsys |
| # | 13:26:35 | bshum | http://paste.lisp.org/display/125277 |
| # | 13:27:12 | bshum | I'll annotate that with some other details from osrfsys |
| # | 13:27:23 | bshum | It's complaining about foreign key constraints |
| # | 13:27:24 | berick | tsbere: for your copious free time, there's a tiny logging patch for the auth blocking code at working/user/berick/auth-failures-block-log-msg. not sure it warrants an LP ticket. |
| # | 13:28:12 | tsbere is staring at a "NOT NULL" column with a comment saying "NULL means skip" |
| # | 13:28:28 | eeevil | haha |
| # | 13:28:32 | gmcharlt | no skipping for YOU! |
| # | 13:29:57 | tater-home has joined #evergreen |
| # | 13:30:32 | mtate has quit IRC |
| # | 13:32:08 | bshum | senator: Let me know if that means anything to you. I annotated the paste I linked to with some osrfsys entries |
| # | 13:32:37 | tsbere | berick: Dunno if I will get to that today. Working on a sizable project at this point. |
| # | 13:33:15 | berick | tsbere: no problem, i just knew I'd forget it if I didn't do something with it |
| # | 13:33:17 | gmcharlt | berick: tis small, I'll review and push |
| # | 13:33:23 | berick | gmcharlt++ |
| # | 13:33:41 | senator | bshum: i think it may. i take it this is on a system that has this? https://bugs.launchpad.net/evergreen/+bug/869581 |
| # | 13:33:57 | bshum | senator: Read my mind, I was just checking on that. |
| # | 13:34:04 | bshum | senator: It does have that patch applied to it. |
| # | 13:34:24 | senator | perhaps my bugfix is your bugcause |
| # | 13:34:32 | senator | scrutinizing |
| # | 13:34:39 | bshum | Yeah, I'm undoing it now to see how it behaves :) |
| # | 13:35:15 | bshum | And like that, searches are magical again |
| # | 13:36:52 | berick | why's it broken? just bugcause. |
| # | 13:37:17 | dbs | bshum: makes sense that the isbn/issn thing could be backported to rel_2_0, all the pieces are in place |
| # | 13:37:36 | dbs | if bshum says it works, I'll backport away |
| # | 13:37:51 | bshum | It seems to be fine as near as I can tell. |
| # | 13:37:56 | gmcharlt | @quote add <berick> why's it broken? just bugcause. |
| # | 13:37:56 | pinesol_green | gmcharlt: The operation succeeded. Quote #16 added. |
| # | 13:37:58 | bshum | Though that's on our dinky test server. |
| # | 13:38:14 | bshum | I can add it to production tonight and see if we burn tomorrow, if you want some live testing :) |
| # | 13:43:55 | senator | bshum: if there are any more lines in your osrfsys.log containing 1318439631234141] they may be useful to me. glad you're in good shape for now just by removing that picklist patch. i'll see if i can figure out how to make a not broken version of it later today if i can. |
| # | 13:44:57 | bshum | I'll pull all those lines out for you and annotate |
| # | 13:44:58 | Jennifer has joined #evergreen |
| # | 13:45:17 | gmcharlt | berick: all pushed up |
| # | 13:45:24 | Jennifer is now known as Guest72072 |
| # | 13:46:01 | dbs gets a rather disturbing mental image of gmcharlt |
| # | 13:46:20 | phasefx | tsbere: jeff: I'm seeing some examples of data is null and data.replace is not a function in escape_html in print.js. I think we should robustify that |
| # | 13:46:24 | gmcharlt | heh |
| # | 13:46:31 | bshum | senator: All set: http://paste.lisp.org/display/125277#2 |
| # | 13:46:34 | berick | thanks gmcharlt |
| # | 13:46:46 | senator | bshum++ |
| # | 13:47:02 | bshum | senator: Happy hunting, sorry to be the bad bug reporter |
| # | 13:47:25 | senator | they're wascawwy |
| # | 13:47:28 | tsbere | phasefx: robustify away, then. You apparently have the test data ;) |
| # | 13:47:30 | bshum | senator: Oh and senator++ for suits tomorrow. Have someone take your picture! |
| # | 13:47:42 | phasefx | tsbere: will do |
| # | 13:48:03 | senator | bshum: i won't have to have them do it. they'll be lining up to do it of their own accord. ;-) |
| # | 13:48:24 | tsbere | phasefx: Probably sufficient to say "if this appears to be null, return an empty string, otherwise .toString it or something" |
| # | 13:48:36 | phasefx | yeah |
| # | 13:50:37 | phasefx | another fun one in the wild, ReferenceError: print_init is not defined |
| # | 13:50:48 | phasefx will scrutinize |
| # | 13:57:33 | dbs | bshum: backported the isbn/issn thing to rel_2_0 |
| # | 13:57:42 | bshum | dbs: Yay, thanks |
| # | 14:12:11 | edoceo | I've been looking at integrating the Asterisk calling features with Evergreen, does anyone else have interest in using FreeSWITCH in place of * ? |
| # | 14:14:41 | jeff | edoceo: sell it. what are the advantages of FreeSWITCH as you see them? Is there reason to not support more than one option? |
| # | 14:14:57 | edoceo | Oh, doing both FS & * would be great |
| # | 14:15:17 | edoceo | I've got a good amount of experience with both systems, and prefer FS |
| # | 14:15:31 | edoceo | Not much of a sales pitch huh? |
| # | 14:15:43 | adrienne_ has joined #evergreen |
| # | 14:15:49 | jeff | not much :-) |
| # | 14:18:11 | dbs | edoceo: the major reason doing both would _not_ be great is that it increases support complexity |
| # | 14:18:37 | gordonja_ has joined #evergreen |
| # | 14:18:39 | justinhopkins has joined #evergreen |
| # | 14:19:47 | edoceo | Well, that makes sense. What if I try a buzz-word pitch? FS is more reliable and scalable than * and configuration is loads easier (those * config files are ugly) |
| # | 14:22:32 | tsbere | How about you try a code pitch? Provide a version of the code that works with FS! ;) |
| # | 14:22:56 | edoceo | That's what I'm building now. :D |
| # | 14:23:31 | jeff | edoceo: tsbere can probably set you up with access to the community git server. |
| # | 14:26:44 | dbs | http://open-ils.org/dokuwiki/doku.php?id=dev:git#git_administrators (weirdly far down the page) |
| # | 14:27:13 | dbs | send SSH pubkey to gitadmin@evergreen-ils.org to be able to push to working repo |
| # | 14:27:52 | dbs | http://open-ils.org/dokuwiki/doku.php?id=contributing#code_contribution for general guidelines |
| # | 14:27:59 | dbs feels like a bot |
| # | 14:28:01 | mrpeters-isl | is it considered acceptible to use OpenILS::Event to return something like this -- return OpenILS::Event->new( 'User has open transactions and cannot be deleted.' ) unless @$open_bills; |
| # | 14:28:17 | mrpeters-isl | or should it be something like ACTOR_USER_DELETE_FAILED |
| # | 14:31:10 | chtrotter has joined #evergreen |
| # | 14:31:55 | dbs | mrpeters-isl: it should be a textcode that appears in extras/ils_events.xml |
| # | 14:32:02 | Guest72072 | Hello! Are we ready for the EG reports meeting? |
| # | 14:32:11 | chtrotter | hello, all, I am here for the reports meeting. |
| # | 14:32:16 | Guest72072 | Who else is joining us for today's meeting? |
| # | 14:32:22 | mrpeters-isl | thanks, dbs. i thought there was a way to map those but couldn't recall where. |
| # | 14:32:23 | justinhopkins is Justin Hopkins, MOBIUS |
| # | 14:32:37 | Guest72072 | Hi Justin, its jennifer bielewski |
| # | 14:33:07 | justinhopkins | Hey Jennifer |
| # | 14:33:28 | bshum is Ben Shum, Bibliomation. |
| # | 14:33:42 | Guest72072 | Hi Ben |
| # | 14:34:05 | Guest72072 | we'll wait a little longer. I have it is right at 2:31 |
| # | 14:34:11 | Guest72072 | how's everyone today so far? |
| # | 14:34:24 | tspindler | * tspindler is Tim Spindler (late just getting out of meeting) |
| # | 14:34:31 | Guest72072 | hi Tim |
| # | 14:34:36 | chtrotter | * chtrotter is Cristina Trotter, Oconee Regional Library System (PINES) |
| # | 14:34:55 | Guest72072 | Hi Cristina |
| # | 14:35:01 | tspindler | * Tim Spindler (C/W MARS) |
| # | 14:35:04 | csharp is Chris Sharp, GPLS, mostly lurking |
| # | 14:35:21 | Guest72072 | Ill be keeping the minutes for all of us |
| # | 14:35:51 | Guest72072 | Hi Chris |
| # | 14:36:21 | mrpeters-isl | jennifer -- if you'd like to change your name type "/nick yourdesiredusername" -- minus the quotes, of course |
| # | 14:36:35 | adrienne_ is Adrienne Detwiler, MOBIUS |
| # | 14:36:42 | Guest72072 is now known as jenniferbielewsk |
| # | 14:36:51 | jenniferbielewsk | well thanks!!! that was easy :) |
| # | 14:36:54 | jenniferbielewsk | Hi Adrienne |
| # | 14:37:19 | jenniferbielewsk | ok, let's go ahead and get started. |
| # | 14:37:25 | jenniferbielewsk | does everyone have a copy of the agenda? |
| # | 14:37:37 | jenniferbielewsk | if not it is here: http://open-ils.org/dokuwiki/doku.php?id=evergreen-reports:meetings:2011-10-12-agenda |
| # | 14:38:02 | gordonja_ is Janine Gordon, MOBIUS |
| # | 14:38:09 | jenniferbielewsk | Hi Janine |
| # | 14:38:59 | afterl has joined #evergreen |
| # | 14:39:11 | egrev | egrev -- Elaine from TNRD Lib System observing |
| # | 14:39:19 | jenniferbielewsk | Hi Elaine |
| # | 14:39:52 | jenniferbielewsk | hello everyone and welcome to the Oct meeting! |
| # | 14:40:09 | jenniferbielewsk | Jennifer is at a conference so, me, another Jennifer will be moderating and taking notes :) |
| # | 14:40:27 | chtrotter | Thanks, Jennifer. |
| # | 14:40:33 | mtate has joined #evergreen |
| # | 14:40:40 | jenniferbielewsk | we'll go ahead and take a look at the 1st agenda item- introductions |
| # | 14:41:07 | justinhopkins | Sounds like we've got that done |
| # | 14:41:17 | jenniferbielewsk | cool. Ok, item 2- |
| # | 14:41:47 | jenniferbielewsk | I know some were here for the sept meeting but what do we think about the aug notes? |
| # | 14:41:52 | jenniferbielewsk | any questions? comments? |
| # | 14:42:52 | jenniferbielewsk | if not, we'll move to item #3 |
| # | 14:42:59 | jenniferbielewsk | any updates from GPLS? |
| # | 14:43:29 | chtrotter | Well, the minutes helped remind me that I need to still link my reports documentation on the wiki, As for updates re: GPLS, yes I have an update. |
| # | 14:43:43 | jenniferbielewsk | great! lets hear it :) |
| # | 14:44:18 | tater-laptop has quit IRC |
| # | 14:44:18 | csharp | we have met with Emerald Data Networks, who will be developing the reports interface for PINES. Everything is in an early information gathering stage, so still very nebulous |
| # | 14:44:30 | chtrotter | GPLS has asked some PINES folks to work together to help get together use case scenarios. |
| # | 14:44:37 | csharp | chtrotter: sorry - didn't mean to walk on your answer ;-) |
| # | 14:44:47 | chtrotter | I will be working on that committee. |
| # | 14:44:56 | jenniferbielewsk | if you need help with that Cristine, send the documentation to Jennifer or me (jennifer/bielewski@lyrasis.org) and we'll get them up |
| # | 14:45:06 | jenniferbielewsk | excellent Chris with Emerald |
| # | 14:45:24 | jenniferbielewsk | do we have a timeframe, a rough timeframe yet? |
| # | 14:45:42 | chtrotter | The plan is to get use case scarios and functional requirements together by the end of Dec. |
| # | 14:45:53 | chtrotter | Active development begins in Jan. |
| # | 14:46:11 | chtrotter | In Feb. first formal review of the interface. |
| # | 14:46:12 | jenniferbielewsk | great! |
| # | 14:46:20 | chtrotter | May second formal review. |
| # | 14:46:33 | jenniferbielewsk | sounds great! |
| # | 14:46:42 | chtrotter | The whole thing should be done by Sept. 30, |
| # | 14:46:49 | lisah__ has joined #evergreen |
| # | 14:46:50 | jenniferbielewsk | do you need more voluneers for the commitee? |
| # | 14:46:51 | chtrotter | That is when the contract ends. |
| # | 14:47:11 | chtrotter | No, thanks for asking. This is a PINES-specific project. |
| # | 14:47:19 | jenniferbielewsk | thanks Cristine! |
| # | 14:47:42 | jenniferbielewsk | We'll keep this agenda item on the meetings to follow |
| # | 14:48:04 | chtrotter | Oh, I should add this... |
| # | 14:48:21 | justinhopkins | PINES-specific as in "only useful for PINES" or "we've got this, thanks"? Is the project to improve the EG reports interface generally? |
| # | 14:48:31 | chtrotter | Taken straight from the email I received: "This project will involve the design and development of a new interface for Evergreen reports. This will not replace the existing interface but should provide a streamlined easier-to-use access point to generate reports." |
| # | 14:48:48 | justinhopkins | ic |
| # | 14:48:49 | lisah_ has quit IRC |
| # | 14:49:06 | chtrotter | Oh, Justin..let me see if I can find a better answer for you... |
| # | 14:49:57 | chtrotter | Well, in reviewing the email, I can't find a better answer other than..." it is a PINES-specific project. " |
| # | 14:50:53 | jenniferbielewsk | ok, next item? documentation? any changes or additions? |
| # | 14:51:04 | justinhopkins | This is the first time I've come to a reports meeting. I was just taking for granted that the topic of "creating a more streamlined easier-to-use" interface had come up. Hoping someone will have some improvements to share. |
| # | 14:51:49 | jenniferbielewsk | I would love to see something easier |
| # | 14:52:07 | jenniferbielewsk | im ok with reports but I always have to create them a few times and make changes |
| # | 14:52:34 | chtrotter | I am assuming that the development that PINES is paying for...will eventually be shared with the larger community...but to be honest, I am a bit clueless about that developmenty-side of things. Maybe Chris can chime in... |
| # | 14:53:13 | chtrotter pokes Chris |
| # | 14:53:24 | csharp got caught by a phone call... |
| # | 14:54:11 | csharp reads up |
| # | 14:55:20 | csharp | okay - the interface will be developed specifically to PINES requirements, but in such a way that allows further development |
| # | 14:55:41 | justinhopkins nods |
| # | 14:55:51 | jeff | csharp: and will it be released under a specific license? |
| # | 14:56:00 | csharp | and we believe that whatever we develop for PINES will almost certainly be generally usefule |
| # | 14:56:26 | csharp | jeff: probably GPL v2 or later, like the rest of the program |
| # | 14:56:59 | jeff | csharp: so, contracts have not yet been signed and that's up in the air? |
| # | 14:57:25 | justinhopkins | Since nobody's asking I'll just throw in that a "preview output" button would be the bees knees. |
| # | 14:58:45 | dbs | given the complexity of the underlying database schema, the only way I can think of streamlining the interface would be to create a handful of the most commonly required views, thus masking the underlying complexity; which would be good as far as it goes |
| # | 14:59:12 | csharp | jeff: contracts have been signed - I can check into the details about licensing |
| # | 14:59:22 | jeff | csharp: thanks! |
| # | 14:59:47 | jenniferbielewsk | thanks everyone. |
| # | 14:59:51 | csharp | it is our intention that everything is open and shared, so I would be suprised (and dismayed) to learn that the contract says otherwise |
| # | 15:00:01 | dbs | pines++ |
| # | 15:00:08 | csharp | @karma pines |
| # | 15:00:08 | pinesol_green | csharp: Karma for "pines" has been increased 1 time and decreased 0 times for a total karma of 1. |
| # | 15:00:17 | jenniferbielewsk | we'll keep us posted :) |
| # | 15:00:19 | justinhopkins | dbs: The interface as it relates to the schema isn't my issue, it's the insane number of steps it takes to create a report and the fact that you can't edit a report except by cloning. Makes trial and error the only, painful option. |
| # | 15:00:34 | dbs | justinhopkins: okay |
| # | 15:01:22 | chtrotter | justinhopkins: i feel your pain. it's insane, i know. |
| # | 15:01:33 | Dyrcona often thinks that using LibreOffice base as a reports front end makes more sense than using the current reports interface. |
| # | 15:02:17 | chtrotter | dyrcona: Are you doing that now? Tell us more. |
| # | 15:02:56 | Dyrcona | not really but tinkered with it a while ago. you have to understand the schema, but the current reporter requires that, anyway. |
| # | 15:03:10 | dbs | Dyrcona: that, or jasper, or whatever... if the database complexity isn't an issue, and visibility of data isn't an issue, then I guess I don't know why you would want to develop a new front end; but I'm a raw SQL person, so what do I know |
| # | 15:03:39 | dbs apologizes for stumbling into this, will step away |
| # | 15:04:04 | tspindler | I agree with justinhopkins, getting preview and streamlining some of the clicks would help a lot |
| # | 15:04:17 | chtrotter | I *think* the idea is to create a new front end so that branch managers and other front end folks can just get the data they need...without having to go through a WHOLE BUNCH of training. |
| # | 15:04:19 | justinhopkins | Yeah, I don't want to get off topic - I'm down to hear about jasperreports - but we will always have circ folks at small libraries that want to run a simple report. |
| # | 15:04:31 | justinhopkins | chtrotter: and involve us? |
| # | 15:04:57 | csharp | other front-ends like LibreOffice or even PGAdminIII require direct DB access - something that's not available to librarians in the field -FYI |
| # | 15:05:50 | dbs | csharp: we've created specific postgresql accounts with limited perms for direct db access for some apps, actually |
| # | 15:06:15 | csharp | dbs: cool - I'd like to know more about that (later of course ;-)) |
| # | 15:06:40 | chtrotter | csharp: I want direct db access!!! :) |
| # | 15:07:00 | chtrotter | (For those folks who don't know, I am a front-end librarian without direct db access.) |
| # | 15:07:21 | csharp | but one who works reports magic nonetheless ;-) |
| # | 15:07:46 | afterl | way to finesse that one, charp |
| # | 15:07:47 | chtrotter | Anyways.... |
| # | 15:07:56 | binaryflow has joined #evergreen |
| # | 15:08:28 | csharp | chtrotter: keep an eye out for GPLS job postings - I don't know where in the process they are, but I understand that job descriptions for PINES openings are in the works |
| # | 15:08:47 | csharp | sorry - mean that to be a PM |
| # | 15:08:51 | csharp blushes |
| # | 15:09:19 | jenniferbielewsk | ok should we move on? |
| # | 15:09:19 | binaryflow | Hello everyone! I am installing OpenSRF for the first time (on the way to a complete Evergreen install). I've made it all the way to step 8 of the installation guide. It looks like ejabberd won't start. The error in /var/log/ejabberd/ejabberd.log says that it needs rw access to /var/lib/ejabberd. |
| # | 15:09:21 | csharp | afterl: finesse, eh? |
| # | 15:09:38 | binaryflow | Checking the perms shows that user ejabberd has rw perms and group ejabberd has r. |
| # | 15:09:46 | binaryflow | Any thoughts as to what the default perms should be? |
| # | 15:10:17 | csharp | binaryflow: there's a meeting going on... would you mind holding your questions for about 30 mins or so? |
| # | 15:10:24 | binaryflow | Ah, sorry... |
| # | 15:11:16 | bshum | jenniferbielewsk: Looks like we're ready. |
| # | 15:11:48 | tspindler_ has joined #evergreen |
| # | 15:12:00 | Jennifer has joined #evergreen |
| # | 15:12:14 | Jennifer | I got booted off. Im back |
| # | 15:12:26 | Jennifer is now known as Guest97693 |
| # | 15:12:27 | justinhopkins_ has joined #evergreen |
| # | 15:12:29 | egrev_ has joined #evergreen |
| # | 15:13:11 | gordonja__ has joined #evergreen |
| # | 15:13:52 | chtrotter has quit IRC |
| # | 15:13:52 | adrienne_ has quit IRC |
| # | 15:13:52 | jenniferbielewsk has quit IRC |
| # | 15:14:14 | gordonja_ has quit IRC |
| # | 15:14:14 | egrev has quit IRC |
| # | 15:14:17 | Guest97693 | Seems I am having trouble staying logged in |
| # | 15:14:34 | justinhopkins_ | Same, looks like people are dropping like flies |
| # | 15:14:59 | Guest97693 | wah! |
| # | 15:15:06 | chtrotter has joined #evergreen |
| # | 15:15:08 | Guest97693 | who's still with us? |
| # | 15:15:10 | tspindler_ | i had to reconnect also but I seem stable |
| # | 15:15:18 | chtrotter | I am back. |
| # | 15:15:20 | justinhopkins has quit IRC |
| # | 15:15:20 | tspindler has quit IRC |
| # | 15:15:27 | egrev_ | I am back hopefully |
| # | 15:15:32 | tspindler_ has quit IRC |
| # | 15:15:50 | tspindler has joined #evergreen |
| # | 15:15:56 | tspindler | spoke too soon |
| # | 15:16:29 | Guest97693 | ok, im not sure where we left off. |
| # | 15:16:47 | bshum | I think we were about to move onto the next agenda items. |
| # | 15:16:55 | Guest97693 | Im not sure if Jeff Godin is here. Jeff? |
| # | 15:17:05 | tspindler | i think we were about to go to documentation on the agenda |
| # | 15:17:09 | Guest97693 | ok great! |
| # | 15:17:27 | Guest97693 | i saw Cristina's chat earlier about adding docs to documentation |
| # | 15:18:26 | chtrotter | well, my stuff is not for the official documentation. It is more for the community-produced documentation page on the wiki. |
| # | 15:18:38 | Guest97693 | i c |
| # | 15:18:50 | jeff | I'm here, when we get to that point in the agenda. |
| # | 15:19:06 | Guest97693 | thanks Jeff! we'll be there soon! |
| # | 15:19:14 | Guest97693 | any more on Documentation? Updates? |
| # | 15:19:27 | adrienne_ has joined #evergreen |
| # | 15:21:06 | Guest97693 | ok, I say we move along to Jeff. Is that ok? |
| # | 15:21:23 | chtrotter | Sounds good. |
| # | 15:21:50 | Guest97693 | Jeff is going to give an update on Jasperreports. Jeff? (thanks!!) |
| # | 15:22:08 | jeff | I've been experimenting with JasperReports and JasperServer as an alternative front end for Evergreen reporting. |
| # | 15:22:35 | jeff | So far, things have gone well enough that we're going to be using it internally for most if not all of our Evergreen reporting here at TADL. |
| # | 15:23:03 | jeff | I hope to have an external demo system up "soon", as we're looking forward to getting others excited and involved. |
| # | 15:23:34 | justinhopkins_ | jeff: Maybe you could do a short video demo? I'm not familiar with Jasper. |
| # | 15:23:58 | justinhopkins_ | Screencast or what-not |
| # | 15:24:03 | jeff | JasperReports is a reporting framework, JasperServer is a self-service web interface for running reports on demand and/or scheduling reports to be generated on a recurring basis, delivering results via email, etc. |
| # | 15:25:15 | jeff | This does use "direct" database access (using a JDBC driver to make a native postgresql connection), and requires some knowledge of SQL to design a report template. |
| # | 15:25:37 | jeff | Once that part is done, and you have your useful templates, running them is a fairly simple process from the JasperServer web interface. |
| # | 15:26:19 | jeff | We're focusing on designing reports to meet our needs first, but with an eye toward what would need to take place for someone to make this work in an environment where not everyone has access to every report / bit of data, etc. |
| # | 15:27:14 | Guest97693 | sounds interesting and good! |
| # | 15:27:33 | jeff | For us, it eliminates a lot of post-processing of report output. |
| # | 15:28:08 | jeff | In addition to a demo system to poke at, I had also thought it would be useful to have some sample report output. A screencast of "here's how you run a report" might be useful also. Thanks! |
| # | 15:28:49 | jeff | That's all I have to share today. I'd be happy to answer questions now or after the meeting. |
| # | 15:29:37 | justinhopkins_ | Sounds good. jeff++ |
| # | 15:29:51 | wolf29_ has quit IRC |
| # | 15:30:03 | Guest97693 | thanks Jeff! |
| # | 15:30:07 | chtrotter | Thanks, Jeff! |
| # | 15:30:16 | jeff | You're welcome! |
| # | 15:30:19 | Guest97693 | on to the next item--reports training at the EG conference? |
| # | 15:30:36 | Guest97693 | I would say yes! along with an update from GPLS and Jeff with demos :) |
| # | 15:31:13 | lisah__ has quit IRC |
| # | 15:31:16 | lisah_ has joined #evergreen |
| # | 15:32:07 | bshum | I'll remind jenny / conference people about that. I haven't heard anything new about it in a bit. |
| # | 15:32:15 | tspindler | it would be nice at the conference to see what Jeff is doing |
| # | 15:33:01 | bshum | Last I heard, we were on the market for someone to run the training, but also to find out whether there's space/time availability around the conference itself for that. |
| # | 15:35:13 | Guest97693 | ok, I can find out maybe from the conference committee if there is space |
| # | 15:35:23 | Guest97693 | or time available |
| # | 15:36:24 | Guest97693 | ok, next? Anything else from past meetings? |
| # | 15:37:54 | dbs | @later tell eeevil updated user/dbs/array_accum_2_array_agg with some probable goodness for vandelay as well |
| # | 15:37:54 | pinesol_green | dbs: The operation succeeded. |
| # | 15:39:32 | Guest97693 | ok, any new business? |
| # | 15:41:08 | chtrotter | None here. I'll keep everyone updates as I can about the new development project here. |
| # | 15:41:14 | Guest97693 | thanks very much! |
| # | 15:42:07 | Guest97693 | ok, format of future meetings. Would you all like to meet in adobe? its similar to webex. We have a chat but we have a screen where we can see demos, go online etc |
| # | 15:42:14 | Guest97693 | it also handles microphones |
| # | 15:42:22 | Guest97693 | or we can stay in IRC |
| # | 15:42:22 | tspindler | that would be good |
| # | 15:42:39 | Guest97693 | it records the meetings too, adobe |
| # | 15:42:49 | tspindler | I don't know if we would have any fewer attend ;) |
| # | 15:42:52 | dbs has quit IRC |
| # | 15:42:54 | csharp | Guest97693: one of the advantages of IRC is that it is logged and preserves the conversation in an easily web-searchable way |
| # | 15:43:06 | Guest97693 | oh i see |
| # | 15:43:08 | csharp | just to put in a vote for keeping it here |
| # | 15:43:10 | justinhopkins_ | I'd prefer IRC |
| # | 15:43:15 | Guest97693 | yeas this would not be searchable |
| # | 15:43:17 | Guest97693 | ok |
| # | 15:43:21 | Guest97693 | we can keep it here |
| # | 15:43:51 | Guest97693 | if you all want a demo one day or even if there is a demo of the projects and you want them in adobe we can do it. I just need a couple days of set up |
| # | 15:44:38 | Guest97693 | anything else? |
| # | 15:45:36 | binaryflow has quit IRC |
| # | 15:46:00 | chtrotter | Thanks so much for moderating, Jennifer, |
| # | 15:46:13 | Guest97693 | thank you all for joining! |
| # | 15:46:32 | Guest97693 | if there is anything else, just give me an email, jennifer.bielewski@lyrasis.org |
| # | 15:46:43 | Guest97693 | ill send the notes to Jenny and we'll post them :) |
| # | 15:47:04 | chtrotter | Bye, y'all! |
| # | 15:47:22 | binaryflow has joined #evergreen |
| # | 15:47:39 | chtrotter has quit IRC |
| # | 15:47:53 | csharp | binaryflow: the meeting is done, so feel free to ask your questions ;-) |
| # | 15:48:13 | adrienne_ has left #evergreen |
| # | 15:48:25 | binaryflow | csharp: Thanks! Sorry for the interruption. |
| # | 15:48:37 | csharp | binaryflow: not a problem |
| # | 15:48:40 | binaryflow | So, I have moved beyond the original question. I can get ejabberd to start now. |
| # | 15:49:04 | binaryflow | The issue I am having now is in creating the public/private router/opensrf user accounts in ejabberd. |
| # | 15:49:08 | mrpeters-isl | i notice the README derived install instructions for 2.1 don't include information on setting up reports. Most of us know how, from experience, but new users might be frustrated as to why their reports aren't running if they don't know to start clark. |
| # | 15:49:20 | binaryflow | When I try to issue the command to register a user I get the following error: |
| # | 15:49:30 | binaryflow | Can't register user router@private.localhost at node ejabberd@localhost: not_allowed |
| # | 15:49:47 | mrpeters-isl | are you root? |
| # | 15:49:48 | binaryflow | I set up the domain private.localhost in /etc/hosts. |
| # | 15:49:50 | Guest97693 has quit IRC |
| # | 15:49:52 | binaryflow | I can also ping it properly. |
| # | 15:49:54 | jeff | are you running the ejabberdctl command as the root user? |
| # | 15:49:59 | binaryflow | Yes = root privs |
| # | 15:50:05 | mrpeters-isl | hmm |
| # | 15:50:10 | binaryflow | I'm copying the command from the docs. |
| # | 15:50:16 | binaryflow | ejabberdctl register router private.localhost <password> |
| # | 15:50:21 | binaryflow | Changing the pwd of course. |
| # | 15:50:27 | gordonja__ has quit IRC |
| # | 15:50:33 | mrpeters-isl | only reason i can think of is that you arent root |
| # | 15:50:43 | jeff | so, from a root shell you're running: jabberdctl register router private.localhost foobar |
| # | 15:51:16 | binaryflow | root@srvrname:~# ejabberdctl register router private.localhost <redacted> |
| # | 15:51:26 | binaryflow | Can't register user router@private.localhost at node ejabberd@localhost: not_allowed |
| # | 15:51:45 | binaryflow scratches head. |
| # | 15:51:50 | jeff | binaryflow: what linux distribution? |
| # | 15:51:52 | binaryflow | On paper this should work. |
| # | 15:51:57 | binaryflow | Ubuntu 11.04. |
| # | 15:52:05 | binaryflow | Server version that is. |
| # | 15:52:48 | binaryflow | I have already added the four passwords to opensrf_core.xml btw. |
| # | 15:53:48 | jeff | binaryflow: can you try running the command as the "ejabberd" user? |
| # | 15:53:54 | binaryflow | Sure. |
| # | 15:53:58 | mrpeters-isl | binaryflow: what does your ejabberd.cfg look like? |
| # | 15:54:06 | mrpeters-isl | i'm betting private.localhost and public.localhost aren't in there |
| # | 15:54:26 | binaryflow | ejabberdctl: not found |
| # | 15:54:40 | jeff | full path is /usr/sbin/ejabberdctl |
| # | 15:54:41 | mrpeters-isl | if it doesn't find your hostname in the config, it won't allow you |
| # | 15:54:44 | mrpeters-isl | http://www.ejabberd.im/node/355 |
| # | 15:54:45 | binaryflow | Oh, sorry. |
| # | 15:54:54 | binaryflow | I'll try that and check ejabberd.cfg. |
| # | 15:55:15 | mrpeters-isl | change to {hosts, ["localhost", "private.localhost", "public.localhost"]}. |
| # | 15:55:27 | mrpeters-isl | betting you only have {hosts, ["localhost"]}. |
| # | 15:55:49 | binaryflow | Same error as user ejabberd. |
| # | 15:55:55 | jeff | or haven't successfully restarted ejabberd after editing the config. |
| # | 15:56:01 | mrpeters-isl | that too, jeff |
| # | 15:56:17 | mrpeters-isl | http://open-ils.org/dokuwiki/doku.php?id=opensrf:2.0:install -- start back at step 5 |
| # | 15:57:10 | binaryflow | Ah, the most painful wounds are the self inflicted ones. |
| # | 15:57:29 | binaryflow | mrpeters = a genius. |
| # | 15:57:34 | binaryflow | Thanks for the help. |
| # | 15:57:38 | mrpeters-isl | oh, no...FAR from it |
| # | 15:57:43 | mrpeters-isl | glad you got it working |
| # | 15:57:46 | binaryflow | Moving on to the next steop. I'm sure I'll be back for more help soon. :) |
| # | 15:58:00 | binaryflow | step |
| # | 15:59:44 | jeff | mrpeters-isl++ |
| # | 15:59:46 | jeff | binaryflow++ |
| # | 15:59:55 | Meliss has quit IRC |
| # | 16:04:46 | Dyrcona | Gotta love running out of open-ils.actor drones..... |
| # | 16:05:12 | justinhopkins_ has quit IRC |
| # | 16:07:35 | mrpeters-isl | no you dont! |
| # | 16:07:45 | egrev_ has left #evergreen |
| # | 16:07:59 | mrpeters-isl | running out of drones is never a love fest |
| # | 16:09:44 | Dyrcona | Too much open-ils.auth.session.retrieve going on. |
| # | 16:11:42 | binaryflow | Ok, trying to start OpenSRF Perl as user opensrf returns the following error: |
| # | 16:11:45 | binaryflow | Can't call method "documentElement" on an undefined value at /usr/local/share/perl/5.10.1/OpenSRF/Utils/SettingsParser.pm line 39. |
| # | 16:12:00 | binaryflow | Is that a perl package that the installer missed? |
| # | 16:12:08 | mrpeters-isl | hmm Re: https://bugs.launchpad.net/evergreen/+bug/873047 -- is that really a dupe since they're different interfaces? |
| # | 16:12:30 | mrpeters-isl | "A" is used several other places, as well |
| # | 16:13:41 | tspindler has quit IRC |
| # | 16:15:43 | jeff | binaryflow: check your opensrf.xml and opensrf_core.xml files for xml well-formedness? |
| # | 16:16:23 | jeff | binaryflow: xmllint --noout file.xml |
| # | 16:18:24 | collum has quit IRC |
| # | 16:20:49 | binaryflow | OpenSRF router starts successfully. The xml files look good to me. I ran that xmllint program and tried starting again. Same results. |
| # | 16:24:13 | binaryflow | Wait, I've got it. |
| # | 16:24:23 | binaryflow | Looks like I missed setting up opensrf.conf. |
| # | 16:24:37 | binaryflow | Sorry, I've been working on this for awhile today... :( |
| # | 16:25:43 | jeff | binaryflow: just to be clear, that xmllint command should have either returned nothing (meaning the file contained valid xml), or returned a visible error regarding something that was malformed |
| # | 16:29:31 | binaryflow | It returned nothing. |
| # | 16:29:39 | binaryflow | And I've now finished installing opensrf. |
| # | 16:29:48 | binaryflow | I missed a conf file along the way. |
| # | 16:29:55 | binaryflow | Moving on to the main evergreen installation now. |
| # | 16:38:43 | kmlussier has quit IRC |
| # | 16:50:07 | dbwells | quick question for all: How are you entering diacritics in the Evergreen Staff Client? I am used to using alt codes in other places, but it just switches tabs |
| # | 16:54:15 | tsbere | dbwells: OOOH, I can answer that one! |
| # | 16:54:31 | tsbere | dbwells: Not helpfully, though, because my answer is "I don't" |
| # | 16:54:34 | tsbere | <_< |
| # | 16:55:27 | binaryflow has quit IRC |
| # | 16:55:50 | raynerj has left #evergreen |
| # | 16:56:50 | phasefx | anyone got a 2.1.0 system handy? wondering if Print List from the checkout screen works for you |
| # | 16:59:40 | _bott_ | phasefx: I believe we needed a newer xul/server/util/print.js to make it work |
| # | 17:00:13 | Shae has quit IRC |
| # | 17:00:27 | _bott_ | wait, maybe I'm confusing issues... I know we had a problem with it at some point |
| # | 17:02:33 | phasefx | it seems like print_win.js isn't loading with the print dialog |
| # | 17:03:31 | phasefx | but works with Print List in Item Status |
| # | 17:03:36 | tlilleberg has quit IRC |
| # | 17:05:01 | phasefx | I don't even get a hit in apache |
| # | 17:05:13 | phasefx | for that nor print_custom.js |
| # | 17:05:31 | dbwells | tsbere: thanks ;) It seems for us it is a once every two years sort of problem, so the answer is "copy and paste from somewhere else" |
| # | 17:06:18 | yboston has quit IRC |
| # | 17:06:23 | tsbere actually has a reason to *delete* entire entries from the IDL |
| # | 17:06:33 | tsbere | What happens if I do that and people have reports using them? |
| # | 17:12:59 | _bott_ has quit IRC |
| # | 17:13:30 | _bott_ has joined #evergreen |
| # | 17:15:25 | dbwells | phasefx: I have a 2.1 system handy, but I don't see Print List on the checkout screen |
| # | 17:16:12 | phasefx | dbwells: sorry, Print Receipt? |
| # | 17:16:33 | phasefx | lower left |
| # | 17:16:37 | dbwells | phasefx: okay trying it |
| # | 17:19:23 | dbwells | phasefx: it worked alright printing to a PDF. Do you get the dialogs, or does it do nothing? |
| # | 17:20:19 | phasefx | an error alert pops up, essentially the catch(E) { alert(E); } in the dialog @onload, print_init not found, then the print content sits there in a modal window |
| # | 17:21:53 | dbwells | phasefx: not getting any errors here. |
| # | 17:21:58 | phasefx | maybe it's template related, but I didn't see anything out of the ordinary |
| # | 17:22:00 | phasefx | dbwells: thanks man |
| # | 17:22:47 | tsbere | phasefx: Your client up to date? |
| # | 17:23:13 | phasefx | tsbere: I've used both the stock 2.1.0 client from the website and my master built client |
| # | 17:23:30 | phasefx | works for me in master, incidentally |
| # | 17:23:36 | tsbere | So master is fine, 2.1 isn't? |
| # | 17:23:46 | phasefx | 2.1 is fine for dbwells |
| # | 17:23:58 | phasefx | oh, sorry |
| # | 17:24:07 | phasefx | ambiguity :) master client fails the same way against the 2.1 server |
| # | 17:24:22 | tsbere | huh |
| # | 17:29:34 | dbwells | phasefx: my 2.1 dev server is not the release code, but installed from the repo as of 9/27, so it should be very close. I also lazily installed it on top of an existing 2.0 installation, so if there is a file missing from 2.1 for some reason but present in 2.0, I couldn't tell. |
| # | 17:30:06 | phasefx | thanks. I'll try a pristine install tomorrow |
| # | 17:32:57 | Dyrcona has quit IRC |
| # | 17:40:44 | matt_carlson has joined #evergreen |
| # | 17:56:03 | tater-home has quit IRC |
| # | 17:56:49 | sfortin has quit IRC |
| # | 17:58:41 | akilsdonk has quit IRC |
| # | 18:02:26 | bshum | senator++ #new version of acq delete patch seems to behave much better as far as picklist creation |
| # | 18:02:41 | bshum | I'll write up our findings to the LP |
| # | 18:02:52 | senator | bshum: awesome. thanks again |
| # | 18:02:55 | senator | bshum++ |
| # | 18:06:09 | bshum | And deletion is happy too. |
| # | 18:06:13 | bshum | Looks like a winner |
| # | 18:06:18 | bshum | Thanks senator! |
| # | 18:11:04 | matt_carlson has quit IRC |
| # | 18:50:18 | lisah_ has quit IRC |
| # | 19:43:23 | lisah_ has joined #evergreen |
| # | 20:11:25 | lisah_ has quit IRC |
| # | 20:30:20 | wlayton has joined #evergreen |
| # | 21:02:07 | jeffdavis has quit IRC |
| # | 21:18:50 | wlayton has quit IRC |
| # | 21:21:32 | atz has joined #evergreen |
| # | 21:24:46 | atz__ has quit IRC |
| # | 21:27:40 | jeffdavis has joined #evergreen |
| # | 22:41:03 | dbs has joined #evergreen |
| # | 23:43:39 | dbs | hmm. just me and my XULRunner 1.9.2.17 on Linux combo, or are the MARC Batch Import/Export tabs for "Inspect Queue", "Record Display Attributes", "Merge/Overlay Profiles", "Record Match Sets", and "Import Item Attributes" dead? |
| # | 23:43:58 | dbs | Clicking on those tab headings turns them bold, but nothing displays on the screen |
| # | 23:44:07 | dbs | (Evergreen master) |
| # | 23:46:12 | dbs | @later tell csharp bottom of http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=blob_plain;f=src/sql/Pg/solr.sql;hb=c67ec7184f86babe079684455da11e282ef8ef2a as an example limited database role (complemented by port-forwarding via a limited UNIX account, etc) |
| # | 23:46:12 | pinesol_green | dbs: The operation succeeded. |
| # | 23:59:18 | dbs | @later tell mrpeters-isl I deliberately cut the reporter bit out of the README because I wanted to cut the line between initial build and install at "core working system". Otherwise, README would expand to include Z39.50 server, SIP, cron jobs, A/T notices... and we do have a DIG, right? |
| # | 23:59:18 | pinesol_green | dbs: The operation succeeded. |
April 10-13