Evergreen ILS Website

IRC log for #evergreen, 2018-03-23

| 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
00:19 book` joined #evergreen
06:31 pinesol_green News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live>
07:28 rjackson_isl joined #evergreen
07:44 JBoyer joined #evergreen
08:00 kmlussier joined #evergreen
08:00 kmlussier Hmmm...that pgtap test ran fine for me. :(
08:11 kmlussier Nope, it's failing for me now. I wonder if I ran the correct test yesterday.
08:12 JBoyer The id for the second record is wrong
08:12 JBoyer missing a '5'
08:12 JBoyer (on insert, that is.)
08:13 JBoyer -- create bib 60,501
08:13 JBoyer INSERT into biblio.record_entry (id, marc, last_xact_id)
08:13 JBoyer VALUES (60001,
08:13 kmlussier JBoyer: Yup. I see what you're talking about.
08:15 kmlussier JBoyer++
08:17 rhamby JBoyer++
08:17 kmlussier It still fails after fixing that.
08:17 JBoyer :(
08:20 JBoyer brand new db? (i.e. it's not missing the corrected asset.merge_etc. ?
08:24 kmlussier Well, all pgtap tests are failing for me. Obviously, it's a problem on my end. :) I was on a new VM and had to install pgtap before running the test. I'm guessing I did something wrong.
08:25 collum joined #evergreen
08:25 JBoyer Ah. There is a step you have to take in psql after installing pgTAP to make it actually available in the db you're testing. Maybe that was missed?
08:26 kmlussier Perhaps. I just ran through the steps again and got a successful test. Let me try rhamby's test again.
08:27 kmlussier It works! I'll put that fix in a branch. Thanks JBoyer!
08:29 JBoyer kmlussier++
08:29 rhamby I like to think that I'm keeping QA sharp.
08:29 rhamby kmlussier++
08:30 kmlussier I'm just curious what exactly it was I ran yesterday that gave me a success response.
08:30 rhamby I'm curious too since I ran it several times with no issues as did Cesar.
08:31 ngf42 joined #evergreen
08:44 kmlussier bug 1758322
08:44 pinesol_green Launchpad bug 1758322 in Evergreen 3.0 "pgTap failure for lp1731960_test_preserving_bookbag_entries.pg " [Undecided,New] https://launchpad.net/bugs/1758322
08:46 mmorgan joined #evergreen
08:56 rlefaive joined #evergreen
09:01 bos20k joined #evergreen
09:09 mmorgan1 joined #evergreen
09:12 Dyrcona joined #evergreen
09:35 rlefaive joined #evergreen
09:38 jvwoolf joined #evergreen
10:01 gmcharlt kmlussier: I think I now by the tests worked for you when you merged LP#1731960
10:01 gmcharlt *why
10:02 gmcharlt a couple things are going on
10:03 gmcharlt first, because of the deferred FK contrainst on container.biblio_record_entry_bucket_item, it setting target_biblio_record_entry to the wrong ID value won't cause an error until the transaction commits, but because it was being run in the context of a pgTAP test that rolls back the transaction, it didn't complain
10:04 gmcharlt in contrast, the record_entry_merged_to_fkey constraint on bre is not marked as deferred, and thus complained right away
10:05 gmcharlt but here's the kicker: the 1107 upgrade script is incomplete; it has a version of the stored procedure that lacks the merge tracking logic
10:05 Dyrcona :0
10:07 * gmcharlt will work up a patch
10:09 kmlussier :(
10:11 kmlussier Would the test have different results then if performing it on a system that used the upgrade script vs. one that was a clean install?
10:11 gmcharlt yeah
10:12 gmcharlt run against a clean install, the test would have complained
10:12 kmlussier joined #evergreen
10:13 kmlussier Sorry! Hexchat apparently didn't like what I was typing.
10:14 kmlussier Yeah, I'm pretty sure I ran it yesterday on the system where I had tested the behavior using the upgrade script. This morning, I was on a clean install.
10:14 kmlussier gmcharlt++
10:14 * gmcharlt grabs 1108
10:19 pinesol_green [evergreen|Galen Charlton] LP#1758347: ensure that upgrade includes latest asset.merge_record_assets() - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b6e3608>
10:19 pinesol_green [evergreen|Kathy Lussier] LP#1758322: Fix  lp1731960_test_preserving_bookbag_entries test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c31faa9>
10:20 gmcharlt ok; should now be sorted out
10:21 kmlussier gmcharlt++
10:24 gmcharlt and this seems useful: https://stackoverflow.com/questions/117989​53/is-it-possible-to-restore-deferred-cons​traints-after-setting-set-constraints-all
10:25 rhamby gmcharlt++ : probably happened from me working on one while the other wasn't committed yet
10:25 gmcharlt using set constraints all deferred looks like a good way to catch this sort of thing while still being able to roll back at the end of a pgTAP test
10:34 gmcharlt https://evergreen-ils.org/evergr​een-3-0-5-and-2-12-11-released/
10:35 kmlussier gmcharlt++
10:36 gmcharlt dbwells++ csharp++ Dyrcona++
10:37 kmlussier Indeed. dbwells++ csharp++ Dyrcona++
10:37 rhamby dbwells++ csharp++ Dyrcona++
10:39 * kmlussier notes that the digest discussion on the list will probably lead to an additional digest today, thereby increasing the frequency.
10:39 JBoyer causing in-digest-ion?
10:40 * kmlussier groans
10:40 JBoyer Badum, psh.
10:40 Dyrcona Yes, and I hate to contradict csharp, but I don't think he's correct about the frequency, unless he's running a really old version of mailman.
10:40 kmlussier Dyrcona: Yes, I sent out a message about that. I think that's the volume frequency.
10:42 Dyrcona Two things that would reduce the volume size are if people would stop top posting and would delete unnecessary bits of the previous email chains when replying.
10:43 Dyrcona But, that's like getting people to encrypt email....Ain't gonna happen on a typical list.
10:43 Dyrcona Not that list emails should be encrypted.
10:43 Dyrcona Can't be... Never mind...
10:49 Dyrcona csharp: https://www.gnu.org/software/ma​ilman/mailman-admin/node19.html
10:51 rhamby JBoyer++ : bad puns should be rewarded
10:52 kmlussier I would have to disagree with rhamby on that point.
10:55 csharp Dyrcona: thanks
10:55 remingtron_ joined #evergreen
10:56 Bmagic @coffee
10:56 * pinesol_green brews and pours a cup of Colombia Hato Viejo Cup of Excellence, and sends it sliding down the bar to Bmagic
10:58 kmlussier Is bug 1699838 considered a bug fix or feature? I'm just wondering if we missed the opportunity to get it in 3.1.
10:58 pinesol_green Launchpad bug 1699838 in Evergreen "OU setting needed for default pickup location for staff placed holds" [Medium,Confirmed] https://launchpad.net/bugs/1699838 - Assigned to Jason Stephenson (jstephenson)
11:03 kmlussier_ joined #evergreen
11:04 cesardv kmlussier: it's a new "featured bugfix"
11:05 kmlussier cesardv: I can go with that. :)
11:05 kmlussier Just lost power here. Wonder what that's all about. There isn't a Nor'easter in sight.
11:05 kmlussier_ joined #evergreen
11:06 kmlussier joined #evergreen
11:11 Bmagic welcome back kmlussier
11:11 Bmagic You missed a huge discussion
11:12 Bmagic We solved Evergreen. You will probably have to wait for the announcement email
11:12 kmlussier Darn! That must mean I'm out of a job.
11:13 Bmagic No, just a title change. "Evergreen Vet"
11:14 csharp @fix Evergreen
11:14 pinesol_green csharp: I eat more coconut cream pie before breakfast than most people eat all day
11:15 jeff potentially unpopular opinion: digest mode on mailing lists should be disabled.
11:21 kmlussier jeff: Why?
11:23 Bmagic I agree. I find that digest emails confuse me.
11:23 Bmagic Maybe it's because I don't understand the purpose
11:25 kmlussier I've used the digest option on one list. It was a fairly active list that wasn't terribly important to me, but I needed to be subscribed in case something of interest came up.
11:25 kmlussier Digest mode let me stay aware of what was going on without requiring me to read through countless "has anyone received any tax forms?" emails that occur every February.
11:26 kmlussier Obviously, by the above example, this was a list for librarians.
11:26 bshum I guess my thought is that digests are only useful for passive readers, not active participants. Seeing responses to digests always drive me a little bonkers :\
11:27 csharp it's probably just all best managed on an individual level by the email client software
11:27 Bmagic bonkers++
11:27 kmlussier bshum: Yes, I would agree. In my case, the list was something I never posted to.
11:28 csharp we've been down this road before - I don't feel like we need to have another big discussion because of one single user's preferences :-/
11:28 * kmlussier also eventually turned digest mode off since it's just as easy to hit the delete button.
11:28 csharp don't mind me - I'm just a grumpy admin today :-)
11:28 bshum When we're *not* grumpy admins, we might have cause for concern and worry :)
11:29 csharp I'll change whatever people want though :-)
11:29 Dyrcona Digest mode should only be used by people who want to read a list and not participate. If you want to respond, then don't use digest mode.
11:30 kmlussier I'm guessing there are lots of Evergreen subscribers who use digest mode in just that way.
11:30 Dyrcona on bug 1699838 I'm waiting on Joan to look at it, but I think I busted the server where she was going to look at it.
11:30 pinesol_green Launchpad bug 1699838 in Evergreen "OU setting needed for default pickup location for staff placed holds" [Medium,Confirmed] https://launchpad.net/bugs/1699838 - Assigned to Jason Stephenson (jstephenson)
11:30 Dyrcona I'll remove myself from the bug.
11:31 kmlussier I would be willing to look at bug 1699838, but would need to hear from dbwells is that's still eligible for RC.
11:32 kmlussier s/is/if
11:32 Dyrcona I believe he said, 2:00 PM yesterday, so guess not.
11:32 kmlussier I should probably look at it now, though, in case my battery dies before the power comes back.
11:33 dbwells kmlussier: I am looking at the bug now, actually.  Still trying to digest it fully, but will post a comment in just a moment.
11:33 kmlussier dbwells: Thanks!
11:33 mmorgan joined #evergreen
11:45 rlefaive joined #evergreen
11:48 kmlussier joined #evergreen
12:01 mmorgan1 joined #evergreen
12:25 khuckins joined #evergreen
12:42 jihpringle joined #evergreen
13:03 ngf42 left #evergreen
13:03 ngf42 joined #evergreen
13:50 pinesol_green [evergreen|Kyle Huckins] lp1693036 Patron Editor Print Data - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6b44a06>
13:50 pinesol_green [evergreen|Galen Charlton] LP#1693036: follow-up: fix printing of daytime phone number - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=010eca0>
13:50 pinesol_green [evergreen|Remington Steed] LP#1693036: Simplify template, cleanup preview data - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ef25453>
14:11 abowling1 joined #evergreen
14:17 rjackson_isl anyone have staff report an issue with payments in the web client that did not actually make it to the db? In this case the bill receipt was printed showing the payment but the staff had to turn around and perform a Forgive Payment after the fact since the check payment did not register.
14:18 Bmagic what's the best way to read in mrc files with perl and then write them to a new file? I am using $output.=$marc->as_usmarc(); then open(OUTPUT, '>> '.$file); binmode(OUTPUT, ":utf8"); print OUTPUT "$output"; which seems to work but the encoding gets messed up
14:19 Bmagic rjackson_isl: no, I haven't heard that one
14:19 rjackson_isl yeah - this is the one and only we have had reported as well
14:19 rjackson_isl :(
14:19 rjackson_isl probably just wait and see if it happnes again/regularly going forward - nothing spotted in logs
14:25 Bmagic I think it's the ->as_usmarc that isn't giving me the utf character conversions
14:26 Bmagic maybe I need to encode_utf8($marc->as_usmarc()) ?
14:31 Dyrcona Bmagic: There's a way to do it, but I usuall don't have to. man MARC::Charset.
14:32 Bmagic ah, maybe this is it $record->encoding( 'UTF-8' );
14:32 Dyrcona Bmagic: I don't think so.
14:33 Dyrcona It isn't that simple.
14:33 jeff > WARNING: you should be sure your record really does contain valid UTF-8 data when you manually set the encoding.
14:33 dbwells Bmagic: if you are sure your data is already utf8, I have had cases where I need to use that to leave it alone.  Sometimes the leader 09 lies and causes problems.
14:33 jeff from the docs on that function -- https://metacpan.org/pod/MARC::Record#encoding()
14:33 abowling joined #evergreen
14:33 Dyrcona If I need to convert records, I usually use yaz-iconv
14:34 jeff but Dyrcona's earlier line sums it up well: "It isn't that simple.""
14:34 Bmagic haha
14:35 Bmagic The records seem to be in usmarc which is what encoding ascii? Then I am writing it to a file with utf8 set. I get this example no mapping found for [0x83] at position 1 in Ã1994 g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308.
14:35 dbwells ASCII?  You wish!  :)
14:36 Bmagic it's supposed to come out looking like a copyright symbol
14:36 dbwells MARC8 is it's own awesome proprietary old standard for encoding all sorts of characters.  Unfortunately, what actually gets put in records can (and often is) just about anything.
14:37 Bmagic right, it's MARC8
14:37 Dyrcona Yeap. Often mixes of anything.
14:37 Bmagic I don't think these are weird records. I am just not handling them correctly.
14:38 Dyrcona Bmagic: Are you ignoring me?
14:38 Bmagic no? lol
14:38 Dyrcona Bmagic: man MARC::Charset or use yaz-iconv
14:39 Dyrcona Your best bet is probably converting the file, first, with yaz-iconv.
14:40 Bmagic Dyrcona++ # I'll try some stuff
14:41 dbwells Bmagic: If you can share your existing records and code, I don't mind helping with sanity checks.  We've all been thrown for loops figuring out encoding issues at one time or another.
14:41 Bmagic ty, if I get stuck using some of these other avenues, I will take you up on that!
14:42 Dyrcona My favorites are the records that contain Windows-1252 with "smart" quotes. One of them looks like an end of record marker to MARC.
14:42 Bmagic I remember you telling me about those!
14:42 Bmagic yuk
14:42 dbwells My all time favorite case was when a "zero-width space" somehow made its way into the record header somehow.  Try to find that!
14:43 Dyrcona Ouch!
14:44 Bmagic holy cow
14:44 Bmagic csharp++ # build docs
14:51 Bmagic I think this is working marc8_to_utf8($marc->as_usmarc());
14:53 Dyrcona Bmagic: Yeah, that should work.
14:53 Dyrcona Good luck! :)
14:53 Bmagic ha, thanks
14:54 Bmagic it's definitely slower
14:54 Bmagic which might be a good sign :)
14:55 Dyrcona That's one reason I like using yaz-iconv: it's pretty quick.
14:56 dbwells I agree, yaz kills Perl MARC modules when it comes to speed, in my experience.
15:17 csharp Bmagic: abowling had issues with this same problem recently - turns out the assumption that the char set was UTF-8 was mistaken
15:17 csharp it was isowhateveritis
15:17 Bmagic I think my solution is to write it to disk with :raw
15:18 Bmagic like Dyrcona says, just leave it. I don't need to convert it. My file writing code just uses utf8 by default
15:23 gsams_ joined #evergreen
15:37 kmlussier Calling 1109
15:37 Bmagic When importing authority records, does anyone look for matches and overlay not using the interface? Or is it common to just import authorities wholesale and use authority_authority_linker ?
15:37 Bmagic kmlussier: what's that?
15:38 Bmagic oh, db upgrade number
15:38 Bmagic the numbers 9 and 1 and 1 were in there, I though you were somehow calling 911
15:41 Dyrcona Bmagic: I import the authorities with http://git.esilibrary.com/?p=migration-too​ls.git;a=blob;f=eg_staged_bib_overlay;h=d4​e788a6d3795939d1559b605c68c281edc9a3da;hb=​f2c19308c36af103c2a6f92380a2dd6c1f262be9
15:41 Dyrcona Then, I run authority_authority_linker and the auth bib linker.
15:42 Dyrcona We do this quarterly with records from Backstage Library Works.
15:42 Bmagic that sounds like the right thing!
15:43 pinesol_green [evergreen|Cesar Velez] LP1699838 - add YOUSes for defaulting hold pickup locs - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1114b1d>
15:43 pinesol_green [evergreen|Dan Wells] LP#1699838 Scale back settings for staff-based hold placement - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5a39d42>
15:43 pinesol_green [evergreen|Kathy Lussier] LP#1699838: Stamping upgrade script for default pickup lib YAOUS - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5a6636f>
15:43 Dyrcona kmlussier++
15:44 Dyrcona Now, I don't have to worry about testing it.
15:44 yboston joined #evergreen
16:12 mmorgan1 joined #evergreen
16:14 mmorgan2 joined #evergreen
16:17 mmorgan joined #evergreen
16:35 mmorgan1 joined #evergreen
16:56 mmorgan joined #evergreen
16:56 jvwoolf left #evergreen
16:57 mmorgan2 joined #evergreen
17:07 mmorgan joined #evergreen
17:12 mmorgan left #evergreen
18:32 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
21:27 hbrennan joined #evergreen

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