| 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-bin/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/Application/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/what-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.markmail.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 |
