| Time |
Nick |
Message |
| 01:30 |
|
Jillianne joined #evergreen |
| 02:09 |
bshum |
And found it |
| 02:09 |
bshum |
Freddy's problem with the closed date editor is an issue with the Spanish translation file for lang.dtd and the closed date editor. |
| 02:10 |
bshum |
staff.server.admin.closed_dates.editor.allmultiday.format in lang.dtd |
| 02:10 |
bshum |
There's a special note saying: Translators: do not translate "<b>YYYY-MM-DD</b>" or "<b>HH:MM</b>" |
| 02:11 |
bshum |
And the Spanish translation there is |
| 02:12 |
bshum |
"Nota: Todas las fechas deben tener el formato <b> AAAA-MM-DD </ b>. Los " |
| 02:12 |
bshum |
"tiempos deben tener la forma <b> HH: MM </ b>" |
| 02:12 |
bshum |
Changing that back to the right variables, things worked |
| 02:12 |
bshum |
So, bleh |
| 02:13 |
bshum |
Changing that AAAA back to YYYY and made things look closer to the original and things worked out |
| 02:15 |
bshum |
And making it AAAA is fine too. |
| 02:16 |
bshum |
It's probably more of a syntax issue with the code itself, hmm |
| 02:18 |
bshum |
And there is it... |
| 02:18 |
bshum |
The problem is that </ b> is used in the translation. There's an extra space between the / and b in those ending tags |
| 02:18 |
bshum |
Removing the space fixes the problem |
| 02:19 |
bshum |
For installed version; it'll be the entry for that string in /openils/var/web/opac/locale/es-ES/lang.dtd |
| 02:19 |
bshum |
Editing it to remove that space fixes the syntax error in my testing |
| 02:24 |
* bshum |
goes to sleep happier knowing the answer to the problem :) |
| 03:12 |
|
remingtron_ joined #evergreen |
| 03:12 |
|
dbwells_ joined #evergreen |
| 03:23 |
|
Jillianne2 joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
csharp |
bshum++ |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:25 |
|
dteston joined #evergreen |
| 08:27 |
|
kmlussier joined #evergreen |
| 08:27 |
kmlussier |
bshum++ indeed |
| 08:30 |
JBoyer |
bshum++ # for reminding me of a couple ejabber things earlier this week...) |
| 08:35 |
* kmlussier |
imagines bshum tossing and turning all night because he can't stop thinking of a translation issue in Evergreen. |
| 08:36 |
kmlussier |
He gives up on sleep to look further at the issue. Not until he finds the culprit is he able to relax into a full night's sleep. |
| 08:36 |
kmlussier |
It must be Friday. |
| 08:37 |
kmlussier |
@coffee [someone] |
| 08:37 |
* pinesol_green |
brews and pours a cup of Nicaragua El Progresso COE Lot #1, and sends it sliding down the bar to b_bonner |
| 08:37 |
kmlussier |
@tea [someone] |
| 08:37 |
* pinesol_green |
brews and pours a pot of Keemun Full Leaf Tea, and sends it sliding down the bar to Guest72111 (http://ratetea.com/tea/foojoy/keemun-full-leaf/6686/) |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:44 |
|
mmorgan left #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 09:06 |
|
jvwoolf joined #evergreen |
| 09:07 |
|
jvwoolf left #evergreen |
| 09:09 |
|
_adb joined #evergreen |
| 09:10 |
|
maryj joined #evergreen |
| 09:11 |
* Dyrcona |
contemplates making /etc/hosts entries for some of his test vms. |
| 09:15 |
* csharp |
does that |
| 09:21 |
* Dyrcona |
actually does it, too. :) |
| 09:22 |
Dyrcona |
Maybe now, I can copy and paste URLs from my gitlab test vm and they'll actually work. :) |
| 09:32 |
|
Freddy_Enrique joined #evergreen |
| 09:34 |
Dyrcona |
acquisitions-- |
| 09:35 |
Dyrcona |
Freddy_Enrique: Have a look at this http://irc.evergreen-ils.org/evergreen/2017-06-16#i_310838 |
| 09:35 |
Freddy_Enrique |
Hi evergreen |
| 09:35 |
Freddy_Enrique |
Hi Dyrcona :) |
| 09:37 |
Freddy_Enrique |
Let see |
| 09:40 |
Freddy_Enrique |
oh....so its a syntax issue |
| 09:42 |
Freddy_Enrique |
I've got to thank bshum for staying awake to early. |
| 09:42 |
Freddy_Enrique |
Thank you too Dyrcona |
| 09:43 |
bshum |
Freddy_Enrique++ # for pointing out broken stuff that needs fixing in the first place |
| 09:43 |
Dyrcona |
bshum++ |
| 09:43 |
Dyrcona |
Freddy_Enrique++ |
| 09:43 |
bshum |
And thanks folks, just doing my bit to make sure we have a happy Evergreen i18n experience :D |
| 09:44 |
bshum |
I'll try to file the issue and put together either a branch or fix it on LP translation side for the next sync. Either way, the next minor release should contain it |
| 09:44 |
bshum |
I'll probably just suggest it to the LP translation and let it sync on |
| 09:45 |
Freddy_Enrique |
Dyrcona++ |
| 09:45 |
Freddy_Enrique |
bshum++ |
| 09:55 |
bshum |
Unrelated, figuring out which menu option was the one for closed date editor in Spanish was fun, when it reordered the menus alphabetically :) |
| 09:58 |
Dyrcona |
heh |
| 09:59 |
Freddy_Enrique |
:). Im gonna make it worth it. Getting home I'll follow your steps. |
| 10:00 |
Freddy_Enrique |
BTW.... |
| 10:00 |
Freddy_Enrique |
Yesterday when I added a new user again. The problem I described didn't happened again |
| 10:01 |
Freddy_Enrique |
That makes me think, is it mandatory to refresh something when you add lirary units? |
| 10:01 |
Freddy_Enrique |
library units* |
| 10:02 |
kmlussier |
Freddy_Enrique: When you add new library units (what we call org units), you need to run autogen on the server. It's also probably a good idea to log out of the client and back in again. |
| 10:03 |
kmlussier |
Speaking of which, I was going to rebuild the MassLNC community demo server last night and forgot. |
| 10:04 |
Freddy_Enrique |
Oh... thats the explanation why I couldn´t register any patron immediately after I created the org units |
| 10:06 |
Freddy_Enrique |
just to make sure... in which other situations is it required to run autogen? |
| 10:09 |
Dyrcona |
Freddy_Enrique: Pretty much any time you change organizational unit information. |
| 10:09 |
Dyrcona |
And, that's about it. |
| 10:11 |
Dyrcona |
Oh.. If you change the fm_IDL.xml file, too. |
| 10:15 |
Freddy_Enrique |
great! |
| 10:18 |
|
jvwoolf joined #evergreen |
| 10:48 |
Dyrcona |
Anyone have any idea why an update statement would say that fewer rows will be updated than are returned by a select statement with identical join parameters? |
| 10:49 |
Dyrcona |
The select is literally modified from the update without changing the where clause. |
| 10:49 |
JBoyer |
Dyrcona, consistently? Are they statements ok to share? |
| 10:53 |
Dyrcona |
There are OK to share and I am in the middle of pasting them, but I have an idea that I want to check. |
| 10:53 |
Dyrcona |
I think I may be getting multiple matches on one table. |
| 10:54 |
Dyrcona |
And, no, that is not the case. I'll paste. |
| 10:55 |
|
mmorgan1 joined #evergreen |
| 10:56 |
Dyrcona |
never mind. there are duplicate rows. I need my eyes checked. |
| 10:56 |
Dyrcona |
Selecting the id with a count and a group by proves it. |
| 10:57 |
Dyrcona |
So my script that I ran last night updated some rows more than once. |
| 10:57 |
Dyrcona |
Well, somebody else's script that I ran.... :/ |
| 10:58 |
JBoyer |
A simple set ='' so it's not big deal, or was there some math involved and now everything is busted? |
| 11:00 |
Dyrcona |
It's a simple set, and I'm restoring from the audit tables. |
| 11:00 |
Dyrcona |
The script just didn't do what was actually wanted. |
| 11:00 |
Dyrcona |
And, acquisitions-- |
| 11:01 |
JBoyer |
Ah. Fair. |
| 11:02 |
Dyrcona |
The script that ran last night was also a simple set field='value' |
| 11:02 |
Dyrcona |
Well, three update statements. |
| 11:02 |
Dyrcona |
I'm puzzled how the second managed to update some of the rows updated by the first, but I can figure that out later. |
| 11:05 |
Dyrcona |
oof. That means I'll have to update those 12 to the first value.... |
| 11:05 |
Dyrcona |
Guess I'm doing another update statement.... |
| 11:30 |
|
Christineb joined #evergreen |
| 11:59 |
Stompro |
Do any open-ils services need to be restarted when Z39.50 server targets are added? |
| 12:00 |
bshum |
I want to say no... though I imagine it might be necessary to exit and relaunch the staff client |
| 12:00 |
bshum |
By server targets, I assume you mean for the client to grab new records from |
| 12:01 |
bshum |
Or do you mean for Evergreen's z3950 server to add new database target points for sharing with third-parties |
| 12:02 |
Stompro |
bshum, That is what I mean. Admin -> Server Admin -> Z39.50 Servers |
| 12:02 |
bshum |
Stompro: Then yeah, adding a new server works that way. Did you also define attributes for that new server for search purposes? |
| 12:03 |
* bshum |
never really ever used the GUI for it, and just poked directly at the DB tables |
| 12:05 |
Stompro |
bshum, Yes, I just added one attribute for title to test. Works fine from the yaz-client... but no results when tried from the EG client for the same search. |
| 12:10 |
|
mmorgan joined #evergreen |
| 12:17 |
bshum |
maybe someone else will have more ideas to try. I only remember that those code/format/truncation settings for z39.50 attributes can get weird depending on the z39.50 server you're trying to talk to |
| 12:18 |
bshum |
Not all servers are configured the same way, so copying "title" attribute from one to another doesn't guarantee success. |
| 12:21 |
Dyrcona |
BTW, acquisitions-- |
| 12:21 |
Dyrcona |
z39.anything-- |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:32 |
Dyrcona |
sudo-- |
| 12:32 |
Dyrcona |
If you, the regular user, can't see a file in a directory, then sudo rm /path/* can't delete it. |
| 12:33 |
Dyrcona |
I'm just not having a good day so far.... |
| 12:39 |
Freddy_Enrique |
Arriba los animos |
| 12:43 |
Dyrcona |
/boot-- |
| 12:43 |
Dyrcona |
What is with this '90s holdover crap, anyway? |
| 12:43 |
Dyrcona |
No space left on device |
| 12:43 |
Dyrcona |
Guess I should have run autoremove before upgrade. |
| 12:44 |
Dyrcona |
autoremove is likely to fail now, because it run mkinitrd *before* removing the old kernel. |
| 12:46 |
Dyrcona |
I should've chosen an easy career, like neurosurgery. |
| 12:47 |
Dyrcona |
j/k |
| 12:48 |
Dyrcona |
Well, autoremove seems to be working. |
| 12:48 |
kmlussier |
Dyrcona: You could always run for president. I hear that's an easy job. |
| 12:49 |
Dyrcona |
kmlussier++ |
| 12:49 |
Dyrcona |
hah! |
| 12:49 |
Dyrcona |
@who should run for President of the USA. |
| 12:49 |
pinesol_green |
sbrylander should run for President of the USA. |
| 12:50 |
kmlussier |
I think sbrylander would do a fine job! |
| 12:51 |
Freddy_Enrique |
Politics...little by little leaving my keyboard.... |
| 12:51 |
Dyrcona |
Freddy_Enrique: We try to keep politics out of the channel. :) |
| 12:52 |
Freddy_Enrique |
Thats a relief :) |
| 12:53 |
Dyrcona |
@who won't get fooled again. |
| 12:53 |
pinesol_green |
jeffdavis won't get fooled again. |
| 12:53 |
kmlussier |
Yes, I'll back off now. :) |
| 13:19 |
jeffdavis |
pinesol_green: can I quote you on that? |
| 13:19 |
pinesol_green |
jeffdavis: Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP! |
| 13:19 |
jeffdavis |
Such a smart-aleck, that bot. |
| 13:22 |
jonadab |
On my list of things to do in life, running for President ranks somewhere between becoming a printer repair technician and performing elective surgery on myself using garden implements. |
| 13:23 |
jeffdavis |
My list doesn't go into that level of detail. |
| 13:23 |
jonadab |
Heh. |
| 13:23 |
Dyrcona |
haha |
| 13:24 |
Dyrcona |
jeffdavis++ jonadab++ # sense of humo(u)r :) |
| 13:24 |
|
yboston joined #evergreen |
| 13:24 |
Dyrcona |
Hola, yboston! |
| 13:24 |
Freddy_Enrique |
Your made my day jonadab |
| 13:27 |
|
littlet joined #evergreen |
| 13:37 |
Dyrcona |
@who pays [who] not to come home |
| 13:37 |
pinesol_green |
BigRig pays (who [<channel>] <question>) -- Answers <question> with a random nick from <channel>. <channel> is only necessary if the message isn't sent in the channel itself. not to come home. |
| 13:37 |
Dyrcona |
yeah, right... no nesting.... |
| 13:37 |
Dyrcona |
@who pays [someone] not to come home. |
| 13:37 |
pinesol_green |
pastebot pays Bmagic not to come home. |
| 13:38 |
* Dyrcona |
waits on a gitlab-ce upgrade to finish. |
| 13:40 |
* Dyrcona |
likes gitlab, but misses some things from gitolite. |
| 13:40 |
Dyrcona |
But, I could probably learn to do without them. |
| 13:50 |
yboston |
Dyrcona: ¡hola! hope you are well |
| 13:51 |
Dyrcona |
yboston: Not having much luck with technology today, but things are getting better. |
| 15:11 |
|
Freddy_Enrique joined #evergreen |
| 15:26 |
|
mmorgan joined #evergreen |
| 15:51 |
|
Jillianne joined #evergreen |
| 15:54 |
* mmorgan |
is puzzling about auditor.asset_copy_history. |
| 15:55 |
mmorgan |
The most recent entry for an item has audit_user 61, editor 1. The item has editor 1. |
| 15:55 |
* kmlussier |
doesn't recommend puzzling on a late Friday afternoon. |
| 15:56 |
* mmorgan |
always ends up doing that :) |
| 15:56 |
|
jihpringle joined #evergreen |
| 15:56 |
Dyrcona |
mmorgan: The auditor table has the information before the update. |
| 15:56 |
Dyrcona |
So, the last entry is what it looked like before the latest change. |
| 15:57 |
mmorgan |
Right, but I was thinking the audit user is what should end up being the editor in the current item. |
| 15:57 |
Dyrcona |
audit_user can be different from the current editor. |
| 15:57 |
Dyrcona |
Not all updates change the editor unfortunately. |
| 15:57 |
Dyrcona |
And if the audit code can't figure out the current user's db id, it goes with 1 for the audit_user. |
| 15:58 |
mmorgan |
That's unfortunate :-( |
| 15:58 |
Dyrcona |
SQL updates won't change the editor, and not all backend calls change it, either. |
| 15:59 |
mmorgan |
So can I be pretty sure that the audit user was the user that made the change to the item? |
| 16:00 |
Dyrcona |
Yes. |
| 16:00 |
mmorgan |
The particular issue was a status change to Lost and Paid that didn't result from payment of the bill. |
| 16:01 |
Dyrcona |
I believe the copy editor will change the editor. Not sure how the status was changed, though. |
| 16:06 |
jeffdavis |
I wonder if there would be any downside to adding a trigger on bre to update the edit_date on all inserts/updates |
| 16:06 |
jeffdavis |
er acp rather |
| 16:06 |
jeffdavis |
but both would be good :) |
| 16:08 |
Dyrcona |
I don't think either has such a trigger. |
| 16:08 |
Dyrcona |
I could see reasons to do a database update without changing the edit date. |
| 16:08 |
Dyrcona |
I often include the edit date when updating the marc in bre, and the editor for that matter. |
| 16:09 |
mmorgan |
When we do database updates, we generally set the editor and edit date for clarity. |
| 16:10 |
Dyrcona |
I sometimes forget. |
| 16:10 |
Dyrcona |
Well, I often forget, let's put it that way. :) |
| 16:12 |
mmorgan |
We don't always do it, but try to in cases where it might confuse users looking at the records. |
| 16:15 |
Dyrcona |
Yeap. |
| 16:16 |
mmorgan |
I'm going to conclude that the status was edited by the audit_user at the audit_time. |
| 16:16 |
mmorgan |
And not puzzle about it any longer. |
| 16:16 |
Dyrcona |
:) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:09 |
Bmagic |
Anyone using pgpool with Evergreen? |
| 17:18 |
|
jvwoolf joined #evergreen |
| 17:58 |
Bmagic |
I found it here: http://irc.evergreen-ils.org/evergreen/2016-12-14#i_280261 |
| 18:04 |
|
Christineb joined #evergreen |
| 18:37 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "Extra logging for OpenSRF 2.5 write_to_child error" (56 lines) at http://paste.evergreen-ils.org/174 |
| 18:37 |
jeffdavis |
^ I added that to OpenSRF/Server.pm on our production app servers. |
| 18:38 |
jeffdavis |
We got the write_to_child error again today about an hour ago, and I saw this in our logs: |
| 18:38 |
jeffdavis |
2017-06-16T14:30:14.026338-07:00 app2 open-ils.search: [ERR :2738:Server.pm:329:] RT46742: child has been reaped! |
| 18:38 |
jeffdavis |
2017-06-16T14:30:14.026338-07:00 app2 open-ils.search: [ERR :2738:System.pm:122:] server: died with error Can't use an undefined value as a symbol reference at /usr/local/share/perl/5.18.2/OpenSRF/Server.pm line 331. |
| 18:41 |
jeffdavis |
This would appear to confirm that the child process is getting reaped sometime between the start of write_child() and the actual attempt to syswrite to $child->{pipe_to_child} |
| 18:49 |
jeffdavis |
ah, bug 1697029 |
| 18:49 |
pinesol_green |
Launchpad bug 1697029 in OpenSRF "Service Listeners Crash when Using an Undefined Value for Syscalls" [High,New] https://launchpad.net/bugs/1697029 |
| 19:28 |
|
serflog joined #evergreen |
| 19:28 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 22:20 |
|
genpaku joined #evergreen |
