| 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/11798953/is-it-possible-to-restore-deferred-constraints-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/evergreen-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/mailman/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-tools.git;a=blob;f=eg_staged_bib_overlay;h=d4e788a6d3795939d1559b605c68c281edc9a3da;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 |
