| Time |
Nick |
Message |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
Dyrcona joined #evergreen |
| 08:02 |
|
_bott_ joined #evergreen |
| 08:09 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
collum joined #evergreen |
| 08:31 |
|
kmlussier joined #evergreen |
| 08:35 |
kmlussier |
@decide sharable or shareable |
| 08:35 |
pinesol_green |
kmlussier: go with sharable |
| 08:36 |
kmlussier |
pinesol_green: The Grammarist disagrees |
| 08:36 |
pinesol_green |
kmlussier: Thank you kmlussier! But our princess is in another castle! |
| 08:37 |
rhamby_ |
kmlussier: pinesol_green won that exchange |
| 08:38 |
kmlussier |
rhamby_: Yeah, you know it's going to be a great day when you're beaten by a bot. |
| 08:38 |
rhamby_ |
kmlussier: eventually skynet will wipe us out and you'll just have been a trend setter |
| 08:42 |
Dyrcona |
rhamby_: I'm partial to the gray goo hypothesis. I think it's more likely than something like Skynet. |
| 08:42 |
* Dyrcona |
is having fun with his router. Looks like a bad NIC, but I can't tell which one until it fails again. |
| 08:43 |
Dyrcona |
Fortunately, I don't use the crap that the ISP provides, so I can replace the NIC when I know which one it is. |
| 08:43 |
rhamby_ |
Dyrcona: if grey goo eats the world it'll be because someone forgot to patch a library somewhere before compiling the code for the nanites |
| 08:44 |
Dyrcona |
rhamby_: Most likely, yes. |
| 08:44 |
|
jvwoolf joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:46 |
Dyrcona |
Weird thing about the router problem: It still routes Internet traffic for my LAN, serves DHCP, etc. |
| 08:47 |
Dyrcona |
I just can't talk to it from inside the firewall and my mail server is offline. |
| 08:47 |
Dyrcona |
It also won't respond to the keyboard, and the console is flooded with messages. |
| 08:47 |
Dyrcona |
I haven't tried connecting from outside the firewall. |
| 08:48 |
Dyrcona |
This leads me to suspect the NIC that bridges the router with my mail server and is set up as a DMz. |
| 08:48 |
Dyrcona |
hopefully, I'll get the offending device name in the logs when it happens again. :) |
| 08:50 |
Dyrcona |
Too bad you can't hotswap NICs..... |
| 08:51 |
kmlussier |
I have been unable to perform any batch updates from user buckets. I keep getting a message that says "Unable to apply fieldset 5 "fs_group" has no field "can_rollback"" |
| 08:51 |
kmlussier |
Am I doing something wrong? It's my first time looking at them. |
| 08:51 |
Dyrcona |
Wasn't there recently some work done on that? |
| 08:52 |
kmlussier |
These are my steps - https://drive.google.com/file/d/0B74gDMUDwDXqaDNMc1NaeWRlMlE/view |
| 08:52 |
kmlussier |
Dyrcona: Yes, it's a new feature for 3.0 |
| 08:52 |
Dyrcona |
Oh, right! |
| 08:52 |
kmlussier |
I think rhamby_ is scheduled to cover them in next week's video, so we want to make sure they're working. :) |
| 08:53 |
Dyrcona |
:) |
| 08:53 |
rhamby_ |
"that's why we call it a beta folks" |
| 08:55 |
|
_bott_ joined #evergreen |
| 08:55 |
kmlussier |
rhamby_: Sure, and I can file a bug if that's what it is. But since it was my first attempt at using them, I thought I might be missing something. |
| 08:56 |
rhamby_ |
kmlussier: kidding aside I'll look at it today too |
| 08:56 |
mmorgan |
kmlussier: I was just able to batch update expiration date of patrons in a bucket without a problem. |
| 08:57 |
|
krvmga joined #evergreen |
| 08:57 |
kmlussier |
mmorgan: Hmmm, did you do something different from what I did? |
| 08:58 |
mmorgan |
Looking at your steps now. |
| 08:58 |
|
_bott_ joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:01 |
mmorgan |
Looks like the same steps. It's working on our test server. |
| 09:01 |
kmlussier |
I also have hit bug 1718301 again on recent master from yesterday. |
| 09:01 |
pinesol_green |
Launchpad bug 1718301 in Evergreen "Webstaff offline DB connection failures" [High,Fix released] https://launchpad.net/bugs/1718301 |
| 09:03 |
|
bos20k joined #evergreen |
| 09:04 |
kmlussier |
I wonder if it's related to the qstore service. The user bucket issue, not the offline DB issue. |
| 09:09 |
Dyrcona |
Is qstore running? |
| 09:10 |
kmlussier |
That's what I need to check. |
| 09:12 |
|
_bott_ joined #evergreen |
| 09:17 |
kmlussier |
Yes, actually, qstore is running. Now I'm puzzled. |
| 09:18 |
kmlussier |
mmorgan: How old is the code on your test server? |
| 09:19 |
Dyrcona |
kmlussier: Errors from qstore in the logs? |
| 09:19 |
mmorgan |
3.0 beta1 |
| 09:19 |
|
_bott_ joined #evergreen |
| 09:33 |
Dyrcona |
@blame Tuesday |
| 09:33 |
pinesol_green |
Dyrcona: Tuesday is why we can never have nice things! |
| 09:33 |
* Dyrcona |
is already having another one of those days.... |
| 09:35 |
gmcharlt |
me, I blame Thuday https://stackoverflow.com/a/6707326/880696 |
| 09:35 |
kmlussier |
Reporting back that I don't see any qstore errors in the logs. |
| 09:35 |
kmlussier |
I wonder if it's an issue with the user records I'm using. |
| 09:36 |
mmorgan |
Permission? |
| 09:37 |
kmlussier |
I'm logged in as the admin user |
| 09:38 |
|
_bott_ joined #evergreen |
| 09:38 |
Dyrcona |
gmcharlt++ |
| 09:44 |
|
_bott_ joined #evergreen |
| 09:51 |
|
_bott_ joined #evergreen |
| 09:59 |
|
_bott_ joined #evergreen |
| 10:02 |
|
rlefaive joined #evergreen |
| 10:07 |
|
Dyrcona joined #evergreen |
| 10:08 |
|
_bott_ joined #evergreen |
| 10:28 |
|
_bott_ joined #evergreen |
| 10:32 |
Bmagic |
bshum: I am trying to track down an error when starting OpenSRF - Failed to dlopen library file oils_pcrud.so: oils_pcrud.so: cannot open shared object file: No such file or directory |
| 10:34 |
Bmagic |
I don't have an oils_pcrud.so but I do have /openils/lib/liboils_pcrud.so - makes me think that it's an install issue where it passed "lib" twice or something |
| 10:36 |
Dyrcona |
Bmagic: After upgrade to 3.0/master, you need to update the opensrf_core.xml and opensrf.xml files. |
| 10:36 |
Dyrcona |
We changed the library names. |
| 10:36 |
Bmagic |
I see, that's probably it |
| 10:37 |
Dyrcona |
They should have been named with the lib prefix all along. |
| 10:37 |
Dyrcona |
The old names break with newer ld as found on Debian Stretch and recent Fedora releases. |
| 10:38 |
Bmagic |
thanks! |
| 10:38 |
Dyrcona |
yw! |
| 10:38 |
Dyrcona |
I suspect that the old names will break on Ubuntu 18.04, too. |
| 10:39 |
Dyrcona |
Probably dont' work on Ubuntu 17 already. |
| 10:50 |
miker |
kmlussier: looks like the baseline schema for action.fieldset_group is out of date in master :( ... lacking a column that the upgrade script has. I'll branch a baseline schema fix in a bit |
| 10:50 |
kmlussier |
miker++ |
| 10:51 |
miker |
kmlussier: in the mean time -> alter table action.fieldset_group add column can_rollback bool default true; |
| 10:51 |
kmlussier |
miker: Thanks! |
| 10:52 |
miker |
no service restat needed. that column is "hidden" from the biz logic layer. db-only, used in a stored proc |
| 10:52 |
miker |
restart |
| 10:56 |
* Dyrcona |
plays some Rolling Stones and hits the reset button on his tech day. |
| 11:00 |
Bmagic |
forgive me, but Hatch's latest code is still it's own repo right? Not merged into Evergreen repo? |
| 11:02 |
Dyrcona |
Bmagic: I believe so, yes... |
| 11:02 |
Dyrcona |
http://git.evergreen-ils.org/?p=Hatch.git;a=summary |
| 11:02 |
Bmagic |
thanks again! |
| 11:02 |
Bmagic |
Dyrcona++ |
| 11:02 |
Dyrcona |
Thank you! I could use some good karma today. ;) |
| 11:03 |
Bmagic |
It was last updated in Feb, which is why I was second guessing it |
| 11:03 |
Dyrcona |
Consider it "stable," then. :) |
| 11:07 |
|
rlefaive joined #evergreen |
| 11:09 |
kmlussier |
I wonder if anyone has been using it in production yet. |
| 11:09 |
* Dyrcona |
cranks the volume until it hurts. |
| 11:11 |
Dyrcona |
We have it on our training server. I'll need to set it up for production in a week or so. |
| 11:12 |
Dyrcona |
"It" being Hatch. |
| 11:23 |
Bmagic |
Something interesting. Login to the web based staff client, then open another tab and open the Patron OPAC - the page is missing the header (because it thinks cts.staff is true) ? |
| 11:23 |
Bmagic |
cts/ctx |
| 11:24 |
berick |
Bmagic: right |
| 11:24 |
Bmagic |
not much we can do about that I guess |
| 11:24 |
berick |
the auth session is linked to a workstation, so the tpac treats that as a staff login |
| 11:24 |
|
_bott_ joined #evergreen |
| 11:30 |
* Dyrcona |
needs the reset hammer. The button don't work. |
| 11:32 |
|
littlet joined #evergreen |
| 11:33 |
|
jwoodard joined #evergreen |
| 11:38 |
|
sandbergja joined #evergreen |
| 11:43 |
|
_adb joined #evergreen |
| 11:44 |
Dyrcona |
Failed to start reboot.target: Connection timed out |
| 11:44 |
Dyrcona |
See system logs and 'systemctl status reboot.target' for details. |
| 11:44 |
Dyrcona |
systemd-- |
| 11:46 |
|
jihpringle joined #evergreen |
| 11:47 |
Dyrcona |
sudo systemctl status reboot.target |
| 11:47 |
Dyrcona |
Failed to get properties: Connection timed out |
| 11:47 |
Dyrcona |
systemd-- |
| 11:47 |
Dyrcona |
@blame systemd for ALL THE THINGS!!! |
| 11:47 |
pinesol_green |
Dyrcona: systemd HAXORED Dyrcona's SERVERZ!!!! for ALL THE THINGS!!! |
| 11:51 |
Dyrcona |
And, it says this, immediately after a reboot from virsh: *** System restart required *** |
| 11:51 |
Dyrcona |
systemd-- |
| 11:57 |
Dyrcona |
And NOT CONNECTED TO THE NETWORK errors from two drones this morning.... |
| 11:57 |
Dyrcona |
It keeps getting better. |
| 11:57 |
Dyrcona |
Ah well, at least I'm not dealing with a payroll mess....People get bitchy when money is involved. :) |
| 11:58 |
Dyrcona |
Oh, and the logs are so far useless on that systemd problem.... |
| 12:09 |
miker |
systemd-- |
| 12:29 |
|
khuckins__ joined #evergreen |
| 12:39 |
kmlussier |
berick / Bmagic: Sometimes, I'm able to pull up the public catalog screen with the header, and even log in as a patron, while I'm also logged into the web client. I haven't figured out why. |
| 12:43 |
jeffdavis |
incognito mode? |
| 12:44 |
kmlussier |
jeffdavis: nope |
| 12:46 |
kmlussier |
miker: I'm curious now. If I create a record bucket in the staff client and make it pub, how can they be used in searches? And in which searches? |
| 12:46 |
miker |
kmlussier: sec, I'll grab the syntax |
| 12:49 |
miker |
kmlussier: it's a filter spelled like this: container($class, $type, $id[, $auth_token]) |
| 12:49 |
miker |
$class can be one of bre, acn, acp (bib, call number, copy -- we don't have a call number container UI currently) |
| 12:50 |
miker |
$type is the btype column on container.{blah}_bucket |
| 12:51 |
miker |
$auth_token is needed for ownership checking |
| 12:51 |
|
eby joined #evergreen |
| 12:52 |
miker |
we don't have object permission checking currently, but if "friends" happens or we add a way for the owner to specify a target user, we could add that |
| 12:52 |
miker |
ownership checking for non-public buckets, to be clear |
| 12:53 |
miker |
IOW, any container that is either public (pub=TRUE) or that you own (and you're logged in) can be used in a search to specify a record set to search |
| 12:53 |
miker |
well, copy, CN, and bib buckets. no user buckets :) |
| 12:54 |
kmlussier |
miker: Thanks! |
| 12:59 |
kmlussier |
So if I do an empty search with the container filter, it's a way to make the entire contents of a bucket available in the public catalog. |
| 13:01 |
miker |
kmlussier: yep. that's basically how we provide "search within a my-list" functionality |
| 13:02 |
miker |
though I guess we don't spell out the filter in the UI, just when we do the search in the code |
| 13:03 |
kmlussier |
OK, maybe I can update some of the documentation on that tomorrow for Web Client Hacking Day. Not that it's new with the web client, but I'll probably forget if I don't do it tomorrow. :) |
| 13:03 |
* kmlussier |
is going to try to get some last-minute bugs tested before the RC |
| 13:14 |
|
Dyrcona joined #evergreen |
| 13:23 |
Dyrcona |
Re my systemd issues from earlier: https://ubuntuforums.org/showthread.php?t=2355822 |
| 13:23 |
Dyrcona |
systemd-- # Just because. |
| 13:23 |
Dyrcona |
@karma systemd |
| 13:23 |
pinesol_green |
Dyrcona: Karma for "systemd" has been increased 0 times and decreased 6 times for a total karma of -6. |
| 13:23 |
berick |
Luke, use the --force --force |
| 13:25 |
Dyrcona |
berick++ |
| 13:26 |
Dyrcona |
And, yeah the double --force was the trick, one --force didn't do it. |
| 13:26 |
Dyrcona |
After the system came back, everything seems normal. |
| 13:26 |
Dyrcona |
First time that's happened to me after an apt upgrade. |
| 13:27 |
jeff |
Dyrcona: were you hitting the 25 second (or so) timeout? |
| 13:27 |
Dyrcona |
jeff: I was getting timeout errors, yes. |
| 13:28 |
Dyrcona |
I saw some discussion on github where poettering's answer was, "Upgrade your systemd." :) |
| 13:29 |
jeff |
Dyrcona: yeah, or kill pid 1 or use -ff (or --force --force)... |
| 13:30 |
Dyrcona |
Or switch to upstart.... :) |
| 13:30 |
Dyrcona |
systemd: crapifying Linux since whenever! |
| 13:37 |
jeff |
killing pid1 in an attempt to get it to recover is "better", because -ff with halt/poweroff/reboot/kexec tells systemctl "just forcibly kill everything yourself" and per the man page "might result in data loss" |
| 13:37 |
jeff |
for the bug I'm thinking of, you'd have failed assertions in syslog for systemd. |
| 13:42 |
Dyrcona |
No, what I have is a lot of useless nonsense: |
| 13:42 |
Dyrcona |
Sep 26 11:36:46 model0 kernel: [ 1340.684386] cfs_rq[2]:/system.slice/systemd-udevd.service |
| 13:42 |
Dyrcona |
Sep 26 11:36:46 model0 kernel: [ 1340.684831] systemd 1 92.886061 2373 120 104.516157 1917.119763 1291193.283520 0 0 /in |
| 13:42 |
Dyrcona |
stuff like that. |
| 13:43 |
berick |
kmlussier: re: your last comment from bug 1712646 -- does that pullrequest need repatching? |
| 13:43 |
Dyrcona |
As for data loss, there's nothing to lose. It's a freshly installed vm with nothing but the base O/S and OpenSSH installed. |
| 13:43 |
pinesol_green |
Launchpad bug 1712646 in Evergreen "Web Client: Adding bill without billing type fails silently" [Low,Confirmed] https://launchpad.net/bugs/1712646 |
| 13:44 |
Dyrcona |
jeff: Do you think I can trust it to remain stable? I'm going to use this vm as a model for production. |
| 13:46 |
berick |
hm, or maybe the related bug needs repatching (bug 1714390) |
| 13:46 |
pinesol_green |
Launchpad bug 1714390 in Evergreen "Fix for Web Client Copy Editor Fix" [Undecided,New] https://launchpad.net/bugs/1714390 |
| 13:46 |
* berick |
will just comment in the bugs |
| 13:46 |
jeff |
Dyrcona: my data loss warning was more for the logs, so that "just force it twice" didn't become Evergreen systemd cargo-cult. :-) |
| 13:46 |
Dyrcona |
system is a cargo cult. |
| 13:47 |
Dyrcona |
systemd, that is. |
| 13:47 |
jeff |
Dyrcona: as for if the problem with recur, I can't guess -- but that was the kind of thing i had in mind when suggesting logs could confirm which problem you ran into. |
| 13:47 |
Dyrcona |
What I have is a lot of that noise, followed by everything working after the forced reboot. |
| 13:48 |
kmlussier |
berick: I think it could go either way, but when I asked after my testing, the thinking was that bug 1712646 should be patched. |
| 13:48 |
pinesol_green |
Launchpad bug 1712646 in Evergreen "Web Client: Adding bill without billing type fails silently" [Low,Confirmed] https://launchpad.net/bugs/1712646 |
| 13:49 |
Dyrcona |
Guess I have to rebuild this vm for the Nth time.... |
| 13:51 |
berick |
kmlussier: should be patched? meaning merged? or repatched? |
| 13:51 |
kmlussier |
berick: Sorry, repatched |
| 13:52 |
* berick |
nods |
| 13:52 |
berick |
i'll update the bug |
| 13:52 |
kmlussier |
berick: Thanks! |
| 13:56 |
|
acautley joined #evergreen |
| 14:04 |
pinesol_green |
[evergreen|Mike Rylander] LP#1719694: Add missing column in baseline schema for batch patron edit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6037312> |
| 14:09 |
berick |
kmlussier: about about bug 1706415 -- needsrepatch as well? |
| 14:09 |
pinesol_green |
Launchpad bug 1706415 in Evergreen "web client: usability with some menus at bottom of screen" [Medium,New] https://launchpad.net/bugs/1706415 |
| 14:11 |
kmlussier |
berick: I don't know. I like the solution miker suggested, but I don't think it will be done in time for the release. Should we go with what we have in the interim until somebody has the tuits for the better solution? |
| 14:14 |
berick |
kmlussier: is mlnc1 still running this patch? |
| 14:15 |
berick |
n/m i'll install locally |
| 14:15 |
kmlussier |
berick: No, I need to stop posting links to my VMs from LP bugs. I rebuild those VMs too frequently. |
| 14:16 |
berick |
no worries, i assumed it had probably been repurposed |
| 14:27 |
kmlussier |
OK, I have a git question. I just tried merging working/user/khuckins/lp1659181-item-damaged-prompt, but there are merge conflicts. The conflicts are in three files that Kyle's branch didn't change. Why would that happen? |
| 14:31 |
Dyrcona |
You merged or rebased? |
| 14:31 |
berick |
kmlussier: looks like kyle's branch has veered away from master. i suggest cherry-picking instead |
| 14:32 |
Dyrcona |
As to why it would happen, there are a number of reasons. |
| 14:32 |
kmlussier |
Dyrcona: I merged the branch to load it on the test system. |
| 14:32 |
kmlussier |
berick: OK, thanks. |
| 14:33 |
Dyrcona |
Sounds like there is extraneous stuff in the submitted branch... I think that should be cleaned up. |
| 14:33 |
Dyrcona |
That's one reason. |
| 14:33 |
Dyrcona |
Another is you have extraneous stuff in your branch. |
| 14:34 |
Dyrcona |
A third is your branch is not on the same base as the one you're merging, i.e. master vs. rel_2_12 as an example. |
| 14:35 |
Dyrcona |
If it is that there are extra commits in Kyle's, I suggest throwing it back to Kyle to fix. |
| 14:37 |
khuckins__ |
I switched over to my local branch and did a rebase to the latest master, and didn't encounter an conflicts, for what it's worth |
| 14:37 |
khuckins__ |
*any |
| 14:37 |
Dyrcona |
OK. |
| 14:38 |
Dyrcona |
I think mixing merges and cherry-picks can lead to this, since cherry-picks can change hashes and that can lead to merge confusion, though it's pretty smart about it. |
| 14:38 |
* Dyrcona |
has his own merge issues to work out at the moment. :) |
| 14:39 |
|
littlet joined #evergreen |
| 14:39 |
Dyrcona |
And, typos don't help. :) |
| 14:40 |
kmlussier |
khuckins__: The conflicts were in Makefile.debian-stretch, lovefield.js and RELEASE_NOTES_3_0.adoc. They seemed like odd places to find merge conflicts. |
| 14:40 |
|
rlefaive joined #evergreen |
| 14:42 |
khuckins__ |
Yeah I'd definitely describe that as odd |
| 14:42 |
Dyrcona |
It happens....*hand waving* |
| 14:43 |
Dyrcona |
"git cherry <khuckins_branch>" might shed some light. |
| 14:43 |
Dyrcona |
It's like a case of cherry-pick vs. merge. |
| 14:44 |
Dyrcona |
That often leads to "conflicts" with no markers. |
| 14:44 |
kmlussier |
OK, interesting. I cherry-picked as berick suggested, and I still had trouble getting the damaged popups to appear. I tried merging again and resolved the conflicts, and I'm finally getting that popup. |
| 14:44 |
Dyrcona |
When you resolve and continue, you'll get something about empty commits. |
| 14:44 |
kmlussier |
I wonder if there is some commit further down in the branch that I'm missing. |
| 14:45 |
Dyrcona |
kmlussier: git cherry shows the differences between two branches. |
| 14:46 |
bshum |
khuckins__: Could be that your local master hasn't been updated lately with the actual origin/master details. |
| 14:46 |
kmlussier |
When I'm faced with the prospect of learning something new in git, I sometimes want to cover my ears and start singing 'la la la' very loudly. |
| 14:47 |
kmlussier |
But it is nice to finally see that Damaged items popup. :) |
| 14:48 |
|
jeff_ joined #evergreen |
| 14:48 |
Dyrcona |
I was gonna mention one branch being woefully out of date with the origin as another reason that happens. :) |
| 14:49 |
khuckins__ |
did a fetch on master, moved over to my branch, then a pull, and can confirm those same files getting a conflict |
| 14:52 |
Dyrcona |
khuckins__: Pull does a merge. That can lead to this of situation. I recommend rebase instead. |
| 14:52 |
Dyrcona |
git checkout <feature_branch> |
| 14:52 |
Dyrcona |
git rebase origin/master |
| 14:52 |
Dyrcona |
The way we use git, that is much safer than pull. |
| 14:53 |
khuckins__ |
rebase origin/master is telling me everything's up to date, while status is telling me there are 88 and 71 different commits each, respectively(though I suppose that could be because of the rebase I did earlier) |
| 14:54 |
bshum |
I think that's only showing that as the status due to tracking head differences |
| 14:54 |
bshum |
Where it's still tracking the rebased version in your working branch vs. the new rebase branch |
| 14:55 |
* bshum |
has been following along as a learning experience and sees the same thing as you khuckins__ |
| 14:56 |
Dyrcona |
bshum is correct on git status. |
| 14:58 |
bshum |
Doing something like: "git branch --set-upstream-to origin/master" |
| 14:58 |
bshum |
Changes it to track status vs. origin/master |
| 14:58 |
bshum |
And after doing that on my local branch, I get 1 ahead of master, which is what I would expect off the rebase |
| 14:58 |
bshum |
https://stackoverflow.com/questions/520650/make-an-existing-git-branch-track-a-remote-branch |
| 14:58 |
Dyrcona |
bshum++ |
| 14:58 |
bshum |
There's various ways of changing the tracking you're applied depending on which version of git you have installed |
| 14:59 |
khuckins__ |
bshum++ |
| 15:00 |
bshum |
The stuff one picks up by talking to #koha folk about git in years past. :) |
| 15:00 |
bshum |
git++ |
| 15:01 |
* Dyrcona |
gives bshum another lily patch for his black belt. :) |
| 15:02 |
kmlussier |
@praise bshum |
| 15:02 |
* pinesol_green |
And bshum raised the report up on high, saying O Lord, bless this thy circ report, that with it thou mayst blow thine enemies to tiny bits, in thy mercy. |
| 15:02 |
bshum |
"It's been awhile since I smited something evil." |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1622696 Webstaff credit card payment support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9a308a1> |
| 15:05 |
pinesol_green |
[evergreen|Galen Charlton] LP#1622696: don't ask to credit card type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39242c1> |
| 15:15 |
Bmagic |
Is there a reason to hide the version of Evergreen running from the public? |
| 15:15 |
Bmagic |
standard reasons: security through obscurity? |
| 15:15 |
bshum |
Bmagic: Savvy folks can figure out what version you're on using various means, so what do you mean "hiding" ? |
| 15:16 |
Bmagic |
aka footer text in the OPAC |
| 15:17 |
bshum |
Since the footer never contained the version, maybe I'd rephrase by asking if anyone would oppose the addition of version info in the footer as a future enhancement. :) |
| 15:19 |
bshum |
I wouldn't, I mean it's already retrievable via the right API calls to the gateway |
| 15:19 |
Dyrcona |
2.12.5-customized-out-the-wazoo.... :) |
| 15:20 |
Dyrcona |
735 files changed, 75369 insertions(+), 2104 deletions(-) |
| 15:20 |
Dyrcona |
:) |
| 15:20 |
Bmagic |
haha |
| 15:21 |
Dyrcona |
A big chunk of that is a custom db upgrade script. |
| 15:21 |
Bmagic |
bshum: which API calls to the gateway would reveal the version? |
| 15:21 |
berick |
Bmagic: is that what you're asking, if we can/should put the version info in the tpac? |
| 15:21 |
Bmagic |
berick: yes |
| 15:21 |
Dyrcona |
Well, 5,423 lines of it, so not as big a chunk as I thought. |
| 15:22 |
berick |
opensrf.open-ils.system.ils_version |
| 15:22 |
berick |
on any Perl service |
| 15:22 |
* berick |
just did this in the webstaff about page patch |
| 15:23 |
berick |
of course, everywhere I run it it just says HEAD |
| 15:23 |
bshum |
berick++ |
| 15:23 |
Bmagic |
berick: you're not getting the version properly from that call? |
| 15:23 |
berick |
Bmagic: i am, the version for origin/master is just HEAD |
| 15:23 |
Bmagic |
ah |
| 15:24 |
berick |
only the release branches have a usable version |
| 15:24 |
Bmagic |
makes sense |
| 15:24 |
bshum |
https://webby.evergreencatalog.com/gateway?service=open-ils.actor&method=opensrf.open-ils.system.ils_version ; for giggles, webby too is HEAD |
| 15:30 |
Dyrcona |
My test vm returns this: {"payload":["2-12-6"],"status":200} |
| 15:30 |
Bmagic |
gratz! |
| 15:31 |
* Dyrcona |
goes back to creating a final branch for the produciton upgrade to 2.12.6. :) |
| 15:45 |
|
jvwoolf joined #evergreen |
| 15:46 |
|
Jillianne joined #evergreen |
| 15:47 |
* gmcharlt |
grabs 1077 in the name of unqualified schemata everywhere! |
| 15:50 |
jeffdavis |
Anyone else seeing the reporter fail with this error? "DBI connect(...) failed: server closed the connection unexpectedly / This probably means the server terminated abnormally before or while processing the request. at /srv/openils/bin/clark-kent.pl line 142." |
| 15:50 |
jeffdavis |
I see it all the time on our training server, but never on production. |
| 15:50 |
Dyrcona |
jeffdavis: Not enough db connections? |
| 15:51 |
Dyrcona |
And, hey, I got a conflict with two customizations branches because they contain the same commits..... |
| 15:51 |
pinesol_green |
[evergreen|Chris Sharp] LP#1714026 - Schema-qualify maintain_control_numbers function. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c38866b> |
| 15:51 |
pinesol_green |
[evergreen|Galen Charlton] LP#1714026: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8b37fc6> |
| 15:58 |
jeffdavis |
hmm |
| 15:59 |
bshum |
I might have thought maybe an overzealous query killer at work |
| 16:02 |
jeffdavis |
current connection count is well below max_connections, and I don't think we have a query killer running in that environment |
| 16:04 |
Dyrcona |
jeffdavis: Is the configuration correct in opensrf.xml? There are two sections for the reporter. If you copied configuration from production it is easy to miss one. |
| 16:04 |
* Dyrcona |
has done that very thing recently. |
| 16:05 |
jeffdavis |
do you mean database vs state_store? |
| 16:05 |
Dyrcona |
jeffdavis: yes, that. |
| 16:05 |
Dyrcona |
We use different dbs in production. |
| 16:06 |
jeffdavis |
Ah, I see. Our config is ok, but good call. |
| 16:06 |
Dyrcona |
I forget what my error was on a test vm when I missed the reporter section. |
| 16:07 |
jeffdavis |
I wonder if whatever's causing the DBI connection failure could be the same thing that's going on with bug 1704396 - probably not, but... |
| 16:07 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,New] https://launchpad.net/bugs/1704396 |
| 16:09 |
Dyrcona |
jeffdavis: Google suggests either the backend segfaulted or perhaps a dbi connection not surviving a fork() call. |
| 16:09 |
Dyrcona |
Or your credentials are wrong, or pg_hba.conf is not allowing the connection... |
| 16:09 |
|
mmorgan joined #evergreen |
| 16:10 |
berick |
yeah, check dmesg for segfaults |
| 16:11 |
Dyrcona |
If it was pg_hba.conf, nothing would connect, I gather. |
| 16:14 |
jeffdavis |
no recent segfaults in dmesg |
| 16:37 |
jeffdavis |
Seems like clark is smart about always establishing a new db connection after forking. The $sth var does get reused by child processes but not in an obviously unsafe way. |
| 16:38 |
Dyrcona |
OK. I thought that's what it did. |
| 16:45 |
* jeffdavis |
blames fluctuations in the quantum matrix |
| 16:46 |
Dyrcona |
heh |
| 16:46 |
Dyrcona |
@blame Tuesday |
| 16:46 |
pinesol_green |
Dyrcona: Tuesday stole Dyrcona's ice cream! |
| 16:46 |
jeffdavis |
:) |
| 16:47 |
jeffdavis |
anyway, thanks for the suggestions |
| 16:49 |
* Dyrcona |
calls it a day. |
| 16:54 |
|
b_bonner joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
kmlussier |
@quote random |
| 17:06 |
pinesol_green |
kmlussier: Quote #47: "< Dyrcona> The latest Perl is dying post I've seen is in a discussion thread in the Emacs community on G+." (added by csharp at 03:11 PM, March 27, 2013) |
| 17:06 |
|
_adb left #evergreen |
| 17:11 |
gmcharlt |
kmlussier: csharp: miker: note https://bugs.launchpad.net/evergreen/+bug/1719726 |
| 17:11 |
pinesol_green |
Launchpad bug 1719726 in Evergreen "updates to monolithic schema update script for 3.0-rc" [Medium,New] - Assigned to Galen Charlton (gmc) |
| 17:12 |
gmcharlt |
which contains consolidated updates to the schema update for the rc |
| 17:12 |
gmcharlt |
review requested |
| 17:22 |
miker |
gmcharlt: it all looks sane at a glance, but I'll want to look closer in the morning when I'm fresh, eh? |
| 17:22 |
miker |
and... |
| 17:22 |
gmcharlt |
miker: naturally |
| 17:22 |
miker |
gmcharlt++ |
| 17:23 |
gmcharlt |
also, I have discovered an inefficiency in authority.simple_heading_set that ideally should be resolved tomrrow |
| 17:23 |
gmcharlt |
but definitely for the release |
| 17:23 |
gmcharlt |
specifically, it calls authority.extract_headings() rather more often than is necessary |
| 17:26 |
miker |
gmcharlt: the authority.simple_heading_set function? |
| 17:26 |
gmcharlt |
miker: yeah |
| 17:27 |
gmcharlt |
it doesn't need to be in the loop; it can just be called once with its second parameter set to an array of the IDs of the acsaf rows where heading_field is not null |
| 17:28 |
miker |
hrm... I don't see it calling that in master. I must be missing something... |
| 17:30 |
kmlussier |
gmcharlt: https://gitlab.com/snippets/1676297 is up to date as far as you know? |
| 17:30 |
miker |
gmcharlt: ah, the baseline looks out of date |
| 17:30 |
gmcharlt |
miker: gah |
| 17:30 |
gmcharlt |
miker: OK, something more for the RC process tomorrow |
| 17:31 |
gmcharlt |
kmlussier: yes, w.r.t. to code, documentation, i18n, and specification & project management contributions that I know of. one class of folks that are not specifically included are those who made significant testing and bug reporting contributions who are otherwise not accounted for |
| 17:31 |
miker |
:) ... I can put that on my plate for the morning. it's the ELSE branch that's missing, it looks like. if the return doesn't matter, we can just collect the non-heading_field values and do a single shot after the loop |
| 17:32 |
gmcharlt |
yeah |
| 17:33 |
kmlussier |
gmcharlt: Hmmm...I do see some testers in there though. I can try to do a quick survey tomorrow, though, to see if I can find anyone else fitting that category. |
| 17:33 |
miker |
well, rather, the are-heading_field values ... ok, straight-forward |
| 17:35 |
kmlussier |
By survey I mean scan through LP bugs. Not an actual survey. |
| 17:35 |
gmcharlt |
kmlussier: I figured as much :) |
| 17:36 |
kmlussier |
Well, I do sometimes come up with crazy ideas, so you never know. |
| 17:40 |
kmlussier |
gmcharlt: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/kmlussier/docs-3-0-release-notes-web-client-adds |
| 17:41 |
gmcharlt |
kmlussier: want typos now? |
| 17:46 |
gmcharlt |
the main thing that jumped out was the reference to September 2017 as the month that the browser clent got suggested |
| 17:49 |
miker |
gmcharlt: hrm... actually, because we need to return the acsaf.id as res.atag along with the extracted heading_field, I don't think we can do better than what you've got right now. The best case would be a call to extract_headings for each heading field, but plpgsql is woefully underpowered for this work. it would want a temp table, but that's even worse, I think |
| 17:50 |
miker |
well... let me see... |
| 17:51 |
kmlussier |
gmcharlt: You all worked on it very quickly. :) |
| 17:51 |
gmcharlt |
heh |
| 17:52 |
kmlussier |
OK, I'll update it to 2013. Feel free to fix any other typos you see. |
| 17:52 |
* kmlussier |
needs to run to a meeting. |
| 17:52 |
gmcharlt |
will do... tomorrow! |
| 17:52 |
gmcharlt |
have a good evening |
| 17:53 |
kmlussier |
You too! |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
miker |
gmcharlt: can multiple acsaf.heading_field's point to a single authority.heading_field row? if not, then I can solve this directly |
| 18:10 |
miker |
gmcharlt: the stock data says no, but it's not a hard rule ... |
| 18:20 |
miker |
nm, found a way past that. will look in the morning with fresh eyes |
| 18:37 |
|
jvwoolf joined #evergreen |
| 19:02 |
|
Jillianne joined #evergreen |
| 19:12 |
|
_adb joined #evergreen |
| 19:28 |
|
Dyrcona joined #evergreen |
| 20:01 |
|
roycroft joined #evergreen |
| 22:10 |
|
jvwoolf joined #evergreen |
