Evergreen ILS Website

IRC log for #evergreen, 2016-08-12

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:18 dcook joined #evergreen
05:49 lualaba joined #evergreen
05:50 lualaba Hello /var/log/posgressql  GET ERROR:  null value in column "barcode" violates not-null constraint what does this error mean?
05:59 lualaba from web opac we put barcode but time to time we are getting this error
06:29 csharp lualaba: can you share a screenshot?
06:30 lualaba schrenshot of what?
06:30 csharp lualaba: of how you're entering the barcode?
06:31 csharp lualaba: the error means that the INSERT statement to the database contains a null barcode value
06:31 csharp so I'm wondering how to recreate it
06:32 lualaba after this error i am inserting manually in DB
06:33 csharp you said "from web opac we put barcode" - can you describe what you mean?
06:33 csharp (which is why I was asking for a screenshot)
06:35 pastebot "lualaba" at 64.57.241.14 pasted "Full error log" (4 lines) at http://paste.evergreen-ils.org/16
06:36 lualaba when we add call_number, prefix, barcode
06:42 csharp lualaba: http://pastebin.com/TQUTaHK9 - I formatted the INSERT statement and put a comment where the barcode value is (currently "DEFAULT")
06:43 lualaba Thank you, This mean from web gui some process not insert barcode?
06:44 csharp right - and I don't have enough information from you to know which GUI is causing the problem - if you share a screenshot, or describe to me the steps to reproduce the problem, I might be able to help further
06:45 lualaba I will share
06:58 lualaba Holding view -> actions -> edit -> Volumes and Copies
07:00 csharp lualaba: is this in the web client? or the XUL client?
07:00 lualaba web client version 2.10
07:00 csharp ok
07:00 lualaba i can't share screen
07:00 csharp no problem
07:10 csharp hmm - I'm still waking up and am probably missing the obvious, but I don't see where I can enter a barcode in that UI
07:12 csharp (eg/staff/cat/volcopy/<md5-looking hash>)
07:23 agoben joined #evergreen
07:34 JBoyer dbs, If it's not too late, yaz-marcdump can do what you want re: forcing the leader to claim UTF-8 even if it's set to MARC-8 now. Look up the -l flag (Ell)
07:34 Stompro joined #evergreen
07:36 JBoyer "Correcting" the leader, that is. It can also do the MARC-8 -> UTF-8 recode should you need.
07:45 kmlussier joined #evergreen
07:50 lualaba i check all problematic records in DB and realise that all oh them has tcn_source emphty
07:59 Dyrcona joined #evergreen
08:04 JBoyer Dyrcona, you rang? (Yesterday)
08:11 Dyrcona S'all right. I was going to ask about naming the rsyslog.d files...i.e. should they be named for the host that one is logging to or the host that you're logging from. I can look it up.
08:12 ericar joined #evergreen
08:17 rlefaive joined #evergreen
08:20 JBoyer The names don't mean anything except to let you know what they're doing. (and the numbers are for ordering if you're stopping propagation with ~)
08:22 JBoyer I've got a couple templates I could throw out if you want to look up what they do and make changes vs starting from scratch or the Eg examples.
08:22 Dyrcona Nah, that's cool, thanks. What you sent me the other week is all I think I need.
08:24 JBoyer Cool. Good luck with it!
08:24 Dyrcona Thanks.
08:25 Dyrcona Right now, I'm just working on notes and recommendations of things to do on the current servers here.
08:25 Dyrcona I'll probably set it up next week.
08:27 Dyrcona hah... That makes sense: I can't open a screen after sudo to a non-superuser.
08:27 Dyrcona No sarcasm...It makes sense.
08:34 Dyrcona Stupid PASV.....Or, stupid firewalls, rather. ;)
08:51 krvmga joined #evergreen
08:52 Dyrcona Um, that's nice FreeBSD, refuse to build Perl because of the CVE, but I believe the patch for the vulnerability is in there....
08:55 Dyrcona Alright, portversion says I have an update, but the ports tree doesn't think so....
08:56 Dyrcona Erm, no. It says the update is still vulnerable....
08:56 Dyrcona See, this why we have to download tarballs and install everything by hand.....Package maintainers cannot be trusted.
08:57 tsbere What do you mean they can't be trusted?
08:57 tsbere I thought we could trust them to screw up on a regular basis!
08:57 tsbere ;)
08:59 Dyrcona heh
08:59 * Dyrcona threatens himself with Linux From Scratch, again...but the mood passes.
09:00 Dyrcona I guess the package is the rc2 for 5.24.1, but I'm going to force install it anyway.
09:01 Dyrcona The CVE should be fixed in this version. I guess vulnerabilities database wasn't updated properly.
09:01 Dyrcona The OpenBSD version is patched and installed smoothly. Maybe I should just switch everything to OpenBSD? ;)
09:02 _adb joined #evergreen
09:02 Dyrcona For reference, this is what I'm trying to patch, though it probably will not affect me or my servers: https://cve.mitre.org/cgi-bin/​cvename.cgi?name=CVE-2016-1238
09:02 pinesol_green (1) cpan/Archive-Tar/bin/ptar, (2) cpan/Archive-Tar/bin/ptardiff, (3) cpan/Archive-Tar/bin/ptargrep, (4) cpan/CPAN/scripts/cpan, (5) cpan/Digest-SHA/shasum, (6) cpan/Encode/bin/enc2xs, (7) cpan/Encode/bin/encguess, (8) cpan/Encode/bin/piconv, (9) cpan/Encode/bin/ucmlint, (10) cpan/Encode/bin/unidump, (11) cpan/ExtUtils-MakeMaker/bin/instmodsh, (12) cpan/IO-Compress/bin/zipdetai... (http://cve.mitre.org/cgi-b​in/cvename.cgi?name=CVE-20
09:03 Dyrcona I'm sure that Debian and Ubuntu will have patches shortly if not already.
09:12 gsams joined #evergreen
09:12 bos20k joined #evergreen
09:17 Dyrcona So, I had an idea related to my silly NFS questions yesterday.
09:18 Dyrcona If you're virtualizing a brick, say running the brick head, drones, etc., on VMs on the same hardware, you should be able share /openils/var with the actual hardware filesystem, then each brick would have one copy of everything.
09:19 Dyrcona With the caveat that the pids should be on the vm's filesystems separate from each other.
09:19 * Dyrcona runs off to check something related....
09:21 Dyrcona It seems to me that you'd want all bricks to share /openils/var/data/offline and /openils/var/web/reporter, right?
09:27 Dyrcona Oh, I forgot... It's Friday and here I am trying to be serious. :)
09:27 csharp lualaba: are your staff trying to *add* volumes/copies via  Holding view -> actions -> edit -> Volumes and Copies?
09:27 csharp lualaba: or are they editing existing copies?
09:28 csharp Dyrcona: yes, that's what we share (via NFS) across all bricks
09:29 miker Dyrcona: in case it still matters, you can force screen to work by issuing the following before trying to `screen -rd` or whatever: script /dev/null
09:29 miker that causes a real tty to be created and attached to your su'd shell, which is what's lacking in order for screen to let you in
09:29 csharp Dyrcona: awitter was looking into glusterfs to do something similar to what you're playing with
09:30 Dyrcona miker: Thanks. I usually tmux, but haven't installed it on these machines.
09:31 csharp he had a working prototype, but that's as far as he got
09:31 Dyrcona csharp: Thanks. That's what I thought, and I'll look into glusterfs. I'm just brainstorming ideas for server replacements.
09:31 * Dyrcona read IRC logs.
09:36 * Dyrcona sometimes feels like saying, "Screenshots or it didn't happen." ;)
09:38 yboston joined #evergreen
09:38 lualaba Editing existing copies
09:38 lualaba also add new copies
09:41 Dyrcona lualaba: Are you certain that staff are entering barcodes for every copy that they try to create? The errors you shared makes it appear that they are not.
09:42 lualaba i will chech thank you
10:14 tsbere joined #evergreen
10:14 Bmagic I have a clark kent issue. All report slots are full, and it doesn't look like it's formulating a query. The database is not running a query but clark has it listed in the processes. reporter.schedule shows the start_time
10:14 tsbere Bmagic: Sounds like clark died while running things, so the DB has some started but not actually running
10:14 Bmagic I restarted clark
10:14 tsbere You need to reset them in the database
10:15 Bmagic and reset one of the reports
10:15 Bmagic it picked up the one that I set start_time to null
10:15 Bmagic and it's not doing anything with it
10:15 Bmagic at least it doesnt look like it is
10:15 Bmagic This report is the same report it has run everyday for a year
10:15 rlefaive joined #evergreen
10:15 Dyrcona Bmagic: You checked in pg_stat_activity?
10:17 Bmagic I'm watching the queries running on the db, and I should see a reporter query running while clark has it listed in ps aux
10:17 tsbere Bmagic: Did start_time go not-null again?
10:17 Bmagic yes, clark updated the start_time
10:18 Bmagic I wonder if the data coming out of the query is messing up a parse somewhere
10:18 tsbere could be that there is a problem with the two sets of DB credentials clark uses
10:18 jvwoolf joined #evergreen
10:19 tsbere Checking what to run and messing with start_time is one set, actual data fetching is the other
10:24 Bmagic something weird is going on. It might be bigger than the reporter. Investigating...
10:26 Christineb joined #evergreen
10:27 csharp @coffee Bmagic
10:27 * pinesol_green brews and pours a cup of Ethiopia Biloya Special, and sends it sliding down the bar to Bmagic
10:29 Bmagic thanks!
10:29 Bmagic I think I found it yall, the shared NFS server (where the report output goes) IS DOWN!
10:30 csharp aha
10:30 csharp in our setup, reports go into a local directory on the server that runs clark, then we share *that* via NFS
10:31 csharp that way if NFS fails, it just affects people's ability to see the results, not the results themselves
10:31 csharp nfs+-
10:33 Bmagic that sounds like a superior setup
10:34 tsbere We have NFS off of the machine the reports run on so it is somewhat trivial to say "oh, crap, we need to run them somewhere else for a bit"
10:34 tsbere In fact, our NFS machine does not run any part of Evergreen. It stores logs and serves NFS, and that is about it. <_<
10:40 dbs JBoyer: oh I know all about yaz-marcdump & many other tools & libraries options re: overriding the leader for marc8 vs. utf8, I was just daydreaming about adding a field to config.z3950_source to override all records for a given source
10:42 Dyrcona dbs: You could add such a field. It might help a number of issues in the long run. There are Lp bugs....
10:45 dbs Dyrcona: yeah, $avail_time < $required_time (even for opening a bug/feature request). mostly just moaning.
10:46 Dyrcona :)
10:46 dbs @whine about the state of the library world
10:46 pinesol_green dbs: Yeah, well, you know, that's just, like, your opinion, man.
11:01 krvmga will 2.11 require a full ingest?
11:03 Dyrcona krvmga: Not yet, but 2.10 requires some ingests.
11:04 krvmga thx.
11:25 kmlussier krvmga: But there's still more than a week for somebody to add some cool new thing to change that. :)
11:25 krvmga :)
11:26 JBoyer dbs, Ah, I see. I wasn't sure if you had a file full of records that needed changed or if they were indb, etc.
11:28 bmills joined #evergreen
11:40 * tsbere hates being asked to log dive with no indication as to how far back he may need to look
11:56 tsbere gmcharlt: Any chance you can take a quick look at my marc-perl pullrequest changes and let me know if you think they may cause significant issues? I want a second opinion at least before I throw it in our production system for a real world test.
11:58 brahmina joined #evergreen
12:01 gmcharlt tsbere: gut reaction - they're unlikely to cause significant issues, and I'll likely merge it soon after writing some test cases
12:02 gmcharlt my only quibble at the moment is whether to add a flag to specify a strict input mode that squawks if \035 is found inside a record, as there's no (known-to-me) character encoding for MARC records where that would be permissible
12:04 Dyrcona gmcharlt: I've seen a number of MARC records in the wild that do not use valid character encodings for MARC, and sometimes different fields in the same record have different encodings.
12:04 Dyrcona But, I'm going to lunch, so.... ;)
12:04 gmcharlt Dyrcona: well yes :)
12:04 gmcharlt hence "strict" mode
12:04 gmcharlt ... which may be too good for this vale of tears ;)
12:06 Dyrcona :)
12:10 tsbere gmcharlt: In reading some of the specs I think I could argue that the record terminator is only supposed to be a record terminator if it directly follows a field terminator, so that may be another way to look at it?
12:16 * Dyrcona still hasn't left for lunch...
12:16 Dyrcona Hooray for ancient, binary formats!
12:22 bmills joined #evergreen
12:57 JBoyer So it seems that most of my earlier woe is me re: NCIPServer was misplaced. It's handling everything at the system level just fine, I suspect because Dyrcona put more thought into it than strictly necessary at the time. Dinner on me in Covington!
12:57 JBoyer I still want to return users' preferred pickup location, but that's a cakewalk compared to what I was afraid of.
12:58 JBoyer Dyrcona++
13:34 pinesol_green [opensrf|Mike Rylander] LP#1485371: Use client-supplied TZ - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=91a8f05>
13:34 pinesol_green [opensrf|Mike Rylander] LP#1485371: Release notes for TZ handling in OpenSRF - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=f3ac7f1>
13:39 gmcharlt bshum and other Ubuntu users -- as it looks like Precise won't EOL until April 2107, is there a pressing reason to drop support now rather than later?
13:41 gmcharlt to be clear, I'm drawing a distinction between deprecating support, which we announced at the conference, and dropping it
13:55 druthb left #evergreen
13:55 bshum More like 2017. But yeah. I think the idea is that if we drop support for 2.11 it won't end mid cycle during its lifetime
13:56 bshum Also community agreed to only support two Ubuntu LTS at a time
13:57 gmcharlt bshum: only 90 years to go!
13:58 gmcharlt but thanks for reminding me of the bit about about Precise support ending in the middle of 2.11's cycle
13:59 bshum Right we only plan to end it for master for that reason, not backpacking
13:59 bshum Or porting
13:59 bshum Silly autocorrect
14:01 gmcharlt "one must sign off on 250 patches before being considered for the backpacker's bit"
14:02 bshum Just 250?  Please, make it a challenge.  :)
14:03 gmcharlt the undocumented quirk: the backpacker's bit comes with an /obligation/ to immediately hike the Appalachian trail! ;)
14:04 bshum Hahaha, okay you got me there ;)
14:04 csharp looks like we have a rogue unstamped db upgrade file in master: XXXX.schema.authority-vandeley-edit-date.sql
14:05 bshum Though that could be an entertaining trip
14:05 gmcharlt csharp: I'll fix it up
14:05 csharp gmcharlt++
14:06 bshum Wow, after we fix that, only 11 more till we crossover into 1000.upgrade
14:06 * csharp assumes "fix it up" means changing the rogue file's name to "Evergreen: Rogue One"
14:06 gmcharlt Many Bothans died to deliver this technical specifications...
14:11 JBoyer It's an older upgrade stamp sir, but it checks out, I was about to let it pass.
14:11 bshum Come on, let's keep a little optimism.
14:13 gmcharlt claiming 0989 in the name of truth, justice, and the Coruscanti way!
14:15 csharp all_y'all++
14:16 JBoyer I don't know, upgrade casually!
14:16 JBoyer Ah, maybe don't do that one.
14:16 csharp JBoyer++
14:18 pinesol_green [evergreen|Galen Charlton] LP#1587639: stamp schema upgrade - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dffd94b>
15:07 Bmagic Where is the magic sauce to change the logging path for SIP?
15:07 Bmagic oh jeez, nvm
15:11 hbrennan joined #evergreen
15:42 * Dyrcona just added a .netrc for the first time in nearly forever....At least 20 years.
15:47 csharp okay, this is going to sound rudimentary to opensrf/perl pros, but I'm trying to understand where $editor or $e is defined in perl modules like perlmods/lib/OpenILS/Applic​ation/Cat/AssetCommon.pm... could someone please point me in the correct direction?
15:48 csharp alternately, I see AppUtils create a DB session - either way I need access to read and write to the database, and I'm not sure what I'm looking at :-/
15:48 * csharp was assuming "$e" or "$editor" was CStoreEditor, but might be barking up the wrong tree
15:49 berick csharp: OpenILS::Utils::CStoreEditor
15:50 berick usually imported w/ :funcs
15:50 berick and instantiated with new_editor()
15:50 berick you'll see the import at the top of most of the perlmods
15:59 csharp berick: thanks
16:00 csharp I'm understanding :funcs to be referring to the EXPORT_TAGS section at the top of CStoreEditor.pm, which makes it available to the file importing it without having to define it explicitly - is that close? ;-)
16:03 * csharp finds his answer at http://stackoverflow.com/questions/16759808/wh​at-is-the-colon-meaning-in-the-qw-declaration
16:22 Dyrcona csharp: Yeah. If you didn't import any of the tags from CSteditor, you can still call new_editor as OpenILS::Utils::CStoreEditor::new_editor.
16:29 Dyrcona csharp: You might also want to look at OpenILS::Utils::Cronscript if you're writing a stand alone script. It has some features to make that easier to do.
16:45 * kmlussier looks to see if she can get krvmga added to the list of Evergreen patchers before the end of business today.
16:58 hbrennan https://bugs.launchpad.net/evergreen/+bug/1612807
16:58 pinesol_green Launchpad bug 1612807 in Evergreen "Title hold with multiple available copies prevents renewal" [Undecided,New]
16:58 Bmagic Does anyone have SIPServer running on xenial?
17:03 kmlussier hbrennan: There is a way you can handle that. Let me see if I can find an old mailing list thread that shows the better way to prevent renewals on copies with hold.
17:03 Dyrcona Bmagic: Not that I am aware of. Are you having specific issues?
17:03 kmlussier This would be another good thing to document someday.
17:03 Bmagic perl 5.22 is default. SIPServer uses UNIVERSAL which complains upon install in cpan
17:04 hbrennan kmlussier++
17:05 kmlussier hbrennan: OK, so what you are using is a library setting to prevent renewals for copies when there are holds on its record. Rather than using the library setting, you can configure your policies to prevent the renewals in a more sophisticated way.
17:05 kmlussier hbrennan: The mailing list link is here http://georgialibraries.markma​il.org/thread/njevrzhizdugshwd
17:05 kmlussier hbrennan: I mention a bug in that thread, but that bug has since been fixed. I don't know if any of our sites are using it, but, in my testing, the ratios work fairly well now.
17:06 Dyrcona Bmagic: The require UNIVERSAL::require or the UNIVERSAL::can line?
17:06 Bmagic use UNIVERSAL qw(can);
17:07 Bmagic package Sip::MsgType;
17:08 Dyrcona OK. Hadn't got that far, yet.
17:09 Dyrcona Bmagic: You can probably just delete that line.
17:09 Bmagic lol
17:10 Bmagic Im compiling perl 5.24 from source in order to fix this issue on xenial
17:10 Dyrcona Um, why Perl 5.24? That wont' fix it.
17:11 Dyrcona UNIVERSAL doesn't export anything any more.
17:11 Bmagic cpan said I needed it, lol, because UNIVERSAL's latest version required it
17:11 * Dyrcona checks on a system with Perl 5.24 to make sure.
17:11 Dyrcona I don't understand how cpan is involved with Sip::MsgType. Can you explain?
17:12 Dyrcona Yep. I get the message on Perl 5.24...
17:12 Dyrcona UNIVERSAL does not export anything at -e line 1.
17:13 Dyrcona UNIVERSAL comes with Perl, it's the ultimate parent of all objects.
17:13 hbrennan kmlussier: Sorry, got pulled away (ahh, public libraries!)
17:13 kmlussier heh
17:14 Bmagic Dyrcona: weird. So you are getting the same error that I am?
17:14 Dyrcona Bmagic: Yes. I think it is safe to remove that line and the require UNIVERSAL::regquire in SIPServer.pm.
17:14 jvwoolf left #evergreen
17:15 Bmagic alright, I guess that is the fix. Probably should commit that to the repo?
17:15 Dyrcona I don't think they're needed on older versions of Perl.
17:15 hbrennan kmlussier: That library setting sounds like it should... go away.
17:15 Dyrcona Yeah, make a branch and a LP bug. I can check it for real.
17:16 Dyrcona I'm pretty sure it is safe to remove those for at least Perl 5.14 or later, possibly 5.10 or later.
17:16 kmlussier hbrennan: You know, I was thinking the same thing. But I don't think there would be an easy way to automagically move people to the circ policy approach, which means it would require a lot of documentation and outreach.
17:18 hbrennan kmlussier: Right? That's the point of the different hold levels... title level should look for anything available in the record, not search out a single unavailable copy and freeze up
17:20 Dyrcona Bmagic: I swear there was Lp bug about removing a use UNIVERSAL in OpenSRF or Evergreen somewhere in the past, but naturally I can't find it.
17:20 Bmagic oh good, it's on the radar
17:21 Dyrcona Bmagic: No, it was a different instance and it was already fixed. I wanted to share it with your for some context.
17:22 Dyrcona I checked SIPServer, too, but couldn't find anything.
17:22 hbrennan kmlussier: Well I'm going to go to lunch then come back ready to dive into your resources. Thanks!
17:22 kmlussier hbrennan: Good luck!
17:23 kmlussier @marc 260
17:23 pinesol_green kmlussier: Information relating to the publication, printing, distribution, issue, release, or production of a work. (Repeatable) [a,b,c,e,f,g,3,6,8]
17:32 kmlussier krvmga++ #First code contribution.
17:32 Dyrcona Bmagic: For reference, in Perl 5.20 I get this: UNIVERSAL->import is deprecated and will be removed in a future perl at -e line 1.
17:32 Dyrcona So, looks like it has been removed in Perl 5.22.
17:33 pinesol_green [evergreen|Jim Keenan] lp1592934 removed lines referencing edition fields 534 and 775. These fields refer to other, different editions of the work and not to the work actually being returned. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9575fee>
17:33 Dyrcona krvmga++
17:33 Bmagic oh nice!
17:33 Dyrcona That deprecation message has been showing up for a long time, so I think it is safe to remove that line.
17:35 * Dyrcona starts a Trusy Tahr VM at the risk of melting his already hot laptop to check something with Perl 5.18.
17:35 Dyrcona It's nice having different systems around. :)
17:36 Dyrcona Ah. Looks like UNIVERSAL::require is an installable module, but from looking at the code in SIPServer.pm, I'm not sure why it's needed there.
17:37 kmlussier Anyway, time to take my daughter out for dinner. That is, if I want to brave the thunderstorm.
17:37 kmlussier Have a nice weekend to everyone who's still here!
18:02 _adb left #evergreen
18:42 bshum gmcharlt: FYI, I started testing your branch for moving mod_perl over from OpenSRF to Evergreen, but still encounter a few issues
18:42 bshum Specifically, I think https://bugs.launchpad.net/opensrf/+bug/1585041 is still needed for Jessie
18:42 pinesol_green Launchpad bug 1585041 in OpenSRF "Fix OpenSRF debian_sys_config order for Debian" [Medium,New] - Assigned to Galen Charlton (gmc)
18:44 bshum Or hmm
18:46 bshum Nope, yep, we still need to rearrange things for Jessie to install pre-reqs right
18:56 bshum Okay, working OpenSRF on Ubuntu Xenial and Debian Jessie after applying patches
18:56 * bshum will finish up after dinner
20:02 bshum gmcharlt: Okay, finished installing Evergreen side with the move for mod-perl.  Doing the installation over there seems to get past the enabling issue.  Both on Debian Jessie and Ubuntu Xenial, mod_perl was started as expected and nothing blows up on apache
20:03 bshum I think once we also merge that bug I mentioned earlier for Jessie, then we'll be all set moving forward with the basic deps
20:08 bshum And on that fun note, time to weekend
20:08 * bshum disappears for a bit
21:50 bmills joined #evergreen
23:15 gsams joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat