| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 10:02 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Thika Gethumbwini, and sends it sliding down the bar to Freddy_Enrique |
| 10:02 |
Dyrcona |
@tea |
| 10:02 |
* pinesol_green |
brews and pours a pot of Laoshan Black, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/verdant/laoshan-black/6664/) |
| 10:33 |
csharp |
hmm - interesting: https://metacpan.org/pod/Email::Send |
| 10:33 |
csharp |
"Email::Send is going away... well, not really going away, but it's being officially marked "out of favor." It has API design problems that make it hard to usefully extend and rather than try to deprecate features and slowly ease in a new interface, we've released Email::Sender which fixes these problems and others. As of today, 2008-12-19, Email::Sender is young, but it's fairly well-tested. Please cons |
| 10:33 |
csharp |
ider using it instead for any new work." |
| 10:36 |
Dyrcona |
Yeah, that rings a bell. Think I've known that for a while. |
| 10:36 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1466502 ? |
| 10:36 |
Dyrcona |
I believe our use of Email::Send predates that though. |
| 10:56 |
jvwoolf1 |
Is anybody using the ebook integration as-is in 2.12? Or are you waiting until circulation is in play? |
| 10:59 |
|
rlefaive joined #evergreen |
| 11:02 |
Freddy_Enrique |
*reading the manual while listening megalovania |
| 11:21 |
Dyrcona |
jvwoolf1: We're testing it on training, but I've only had reports that someone's circulations are not showing up and have not looked into it. |
| 11:22 |
gsams |
So it looks like we've had reports start duplicating for some reason, has anyone ever seen that happen? |
| 11:27 |
csharp |
gsams: outputs or scheduled reports? |
| 11:27 |
gsams |
csharp: schedule reports |
| 14:20 |
Dyrcona |
miker++ # Thanks, also. |
| 14:51 |
Dyrcona |
Now, to tune the beast. |
| 15:26 |
|
kmlussier joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:51 |
|
tsadok joined #evergreen |
| 20:37 |
|
jvwoolf joined #evergreen |
| 21:26 |
|
jvwoolf joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:30 |
|
rlefaive joined #evergreen |
| 07:03 |
|
JBoyer joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 08:52 |
|
_adb joined #evergreen |
| 08:52 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Add doc for Cash Reports feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a61058> |
| 08:52 |
kmlussier |
Happy Friday #evergreen! |
| 08:53 |
kmlussier |
@coffee everyone |
| 08:53 |
|
bos20k joined #evergreen |
| 13:40 |
berick |
Dyrcona: you mean any patron? i grab from money.usr_summary with balance_owed <> 0 -- not exactly "easy" |
| 13:40 |
Dyrcona |
berick: Thanks. I was think of doing something like that. |
| 13:40 |
Dyrcona |
thinking... |
| 13:41 |
Dyrcona |
I'm testing some SIP code and need a patron with fines. |
| 13:53 |
csharp |
heh - just found an ack-grep easter egg: "ack --bar" |
| 13:54 |
csharp |
well, "found" means "read the man page and saw the option", but still :-) |
| 13:56 |
bshum |
HA! hilarious, csharp :) |
| 15:17 |
csharp |
Dyrcona: yeah - I used to stay logged in there, but only lurked |
| 15:18 |
csharp |
Freddy_Enrique: hope to see you there |
| 15:18 |
Dyrcona |
I still lurk, occasionally chime in. |
| 15:19 |
Dyrcona |
So, looking for patrons for this test from money.usr_summary isn't working or the changes broke the SIP code more than one would expect. |
| 15:19 |
Dyrcona |
I've tried hundreds of patrons so far, and not one has had a fine items count greater than 0 or returned a list of fine item details. |
| 15:20 |
Freddy_Enrique |
yeah, For what I can tell, anyone could attend it |
| 15:20 |
Freddy_Enrique |
Ill take a BIG dictionary with me in case i make it in tiem |
| 16:31 |
jeff |
only on tuesdays. |
| 16:31 |
|
rlefaive joined #evergreen |
| 16:31 |
Dyrcona |
If it's Tuesday, this must be Belgium! |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 18:03 |
|
Freddy_Enrique left #evergreen |
| 18:30 |
|
dbwells joined #evergreen |
| 01:11 |
|
barbara joined #evergreen |
| 01:20 |
|
sallyf_ joined #evergreen |
| 03:12 |
|
remingtron_ joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:54 |
|
remingtron joined #evergreen |
| 06:54 |
|
dbwells_ joined #evergreen |
| 15:02 |
ohiojoe |
#topic Ongoing Business |
| 15:02 |
sandbergja |
Sure! |
| 15:03 |
ohiojoe |
Progress on Docs Reorganization project |
| 15:03 |
sandbergja |
With the help of a student here, we were able to put together a proof-of-concept |
| 15:04 |
sandbergja |
that divides the big monolith of official documentation into different manuals for different folks in the library |
| 15:04 |
sandbergja |
#link http://docs-testing.evergreen-ils.org/ |
| 15:04 |
sandbergja |
there's something wrong with the serials module, but the others should be ready to explore |
| 15:04 |
katiemartin |
neat! |
| 15:05 |
sandbergja |
they are not perfect by any means, but should help to give us a feel for what our docs would look like in a more audience-focused format |
| 15:05 |
jihpringle |
that's awesome! |
| 16:51 |
|
mmorgan joined #evergreen |
| 16:52 |
|
jeffdavis joined #evergreen |
| 17:00 |
Bmagic |
When the EDI mechanism FTP's a file from the Evergreen server to the vendor, can we customize the file extension to meet the vendor's requirements? |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
berick |
Bmagic: yes, somedir/*.edi (for example) should do it |
| 17:02 |
Bmagic |
that belongs in the "out" |
| 17:03 |
Bmagic |
Their server has a directory "in" and "out" - which I suppose is in their point of view. Therefore, "in" means incoming TO THE VENDOR. And "out" is FROM THE VENDOR |
| 20:33 |
Fr0z |
evergreen* |
| 20:34 |
jonadab |
The catalog maybe? |
| 20:34 |
Fr0z |
yes |
| 20:34 |
jonadab |
I mean, I don't know that much about penetration testing. I know what it _is_, but it's not something I've ever dabbled in. |
| 20:35 |
Fr0z |
and one more thing :P.is it easy to handle as a newcomer? |
| 20:35 |
jonadab |
Only if somebody else does the installation. |
| 20:35 |
jonadab |
Installing Evergreen is more complicated than installing most software.\ |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:30 |
|
collum joined #evergreen |
| 10:24 |
jeff |
alas, we also don't use trac, so some of the comments in that bug lack context. |
| 10:26 |
csharp |
looks like tsbere's fix would solve the original problem though |
| 10:27 |
csharp |
it disables gzip for conify stuff, which is what appears to have been the original problem |
| 10:28 |
jeff |
but since many installations run with mod_deflate disabled thanks to the pre-req makefiles, the existing fix might not be as widely tested as we might hope. :-) similar to what dbs pointed out in comment 10 on that bug https://bugs.launchpad.net/evergreen/+bug/652343/comments/10 |
| 10:28 |
pinesol_green |
Launchpad bug 652343 in Evergreen 2.1 "use of mod_deflate can break XMLENT" [Undecided,Fix released] |
| 10:28 |
csharp |
right - saw that |
| 11:10 |
jeff |
a2dismod gained the feature of warning on "essential" modules back in 2014. the logic seems to be "we enables these by default and permit packages to use config directives from these modules without them being wrapped in an IfModule" |
| 15:56 |
mmorgan |
Freddy_Enrique: You could, but would need to click on the link to see the image. |
| 15:58 |
Freddy_Enrique |
oh...... I thought I could make it appear on the TPAC :( |
| 16:21 |
|
Jillianne joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:41 |
kmlussier |
@quote [random] |
| 16:41 |
pinesol_green |
kmlussier: Error: The command "random" is available in the LoveHate and Quote plugins. Please specify the plugin whose command you wish to call by using its name as a command before "random". |
| 16:41 |
kmlussier |
@quote random |
| 16:50 |
|
grue left #evergreen |
| 16:50 |
* cesardv |
scratches his head |
| 16:51 |
kmlussier |
cesardv: Yes, those are definitely ones that should be more clearly defined. pullrequest, needstest, signedoff, needsrepatch, needsreleasenote. |
| 16:51 |
cesardv |
kmlussier: for me the pullsrequest tag didn't assume that the code had been "tested" |
| 16:51 |
kmlussier |
There has been an ongoing to-do item on the web team's list to create a page that better explains our use of Launchpad. |
| 16:52 |
kmlussier |
Speaking of the web team, I think I forgot to schedule a meeting. |
| 16:52 |
Freddy_Enrique |
Guys, when I want to create a Record a couple of fields appear to be filed (until 650). I just checked the concerto record examples and have more fields than I was given. |
| 16:54 |
Freddy_Enrique |
Can i modify the template which contains the marc fields? |
| 16:54 |
Freddy_Enrique |
is it possible? |
| 16:55 |
cesardv |
kmlussier: or we can get rid of launchpad all together :) |
| 16:56 |
kmlussier |
cesardv: Yeah, now that you mention it, I don't know if I want to invest time into a LP doc page if we really are planning to leave it soon. |
| 16:57 |
kmlussier |
cesardv: But for now, I think the important thing to know is that when you're code is ready for testing, slap on that pullrequest tag. If more work is needed, the reviewer will probably let you know with a comment at the same time they add a needstest, needsrepatch or needsreleasenote tag. |
| 16:57 |
kmlussier |
But those last three tags are generally added when somebody notices there is something missing from your code. |
| 16:58 |
mmorgan |
Freddy_Enrique: Yes, this should help explain how: https://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:customization:cat |
| 16:58 |
cesardv |
kmlussier: got it, thanks! |
| 16:59 |
Freddy_Enrique |
wow |
| 16:59 |
Freddy_Enrique |
thanks! |
| 16:59 |
kmlussier |
cesardv: Also, needs test will be used if the reviewer thinks a test as required according to the QA guidelines at https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 16:59 |
Freddy_Enrique |
mmorgan++ |
| 17:02 |
* kmlussier |
has fun clearing out serials wishlist items from the MassLNC ideas site based on improvements coming with the web client. |
| 17:03 |
Freddy_Enrique |
wait....I thought I added an Image, why does this chart keep showing? : https://snag.gy/vmOWZV.jpg |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:15 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 14:17 |
bshum |
I think if you don't pass that argument for the next client you build, you could end an update line |
| 14:17 |
bshum |
Or I have done that by accident before.. |
| 14:17 |
* bshum |
whistles innocently |
| 14:18 |
bos20k |
So, if you are running a client that is pointing at production.domain.com, it will only ever look there. Even if you try to log in to testing.domain.com it will not see the updates sitting on testing.domain.com? |
| 14:18 |
Dyrcona |
It's set at configure time. --with-autoupdates-host= |
| 14:18 |
bshum |
Right, you would need to build a different client to point at auto-updates elsewhere I would think. |
| 14:18 |
Dyrcona |
Yes, that is my understanding. |
| 14:19 |
bos20k |
Ok, just want to make sure that was correct. |
| 14:19 |
jeffdavis |
The autoupdate hostname is saved in the defaults/preferences/autoupdate.js file in your copy of the client, so you can edit that for testing purposes too. |
| 14:19 |
bos20k |
Otherwise I'm doing something wrong on my testing setup since the production client doesn't want to update from the testing server. |
| 14:19 |
bshum |
Yeah, but... the files on the server side have to be able to upgrade from X to Y version. So that sounds messy to me jeffdavis |
| 14:20 |
bshum |
I mean you could copy production XUL and let the test server build on top of it |
| 14:20 |
bshum |
But yuck |
| 14:20 |
Dyrcona |
I always build custom clients for testing, often with a different app name to store preferences in a different place. |
| 14:20 |
jeffdavis |
That's what we do during pre-upgrade testing. |
| 14:20 |
Dyrcona |
just use the web staff client? :) |
| 14:20 |
bos20k |
:) Soon enough... |
| 14:21 |
bos20k |
Thanks everyone |
| 14:21 |
Dyrcona |
bos20k: you know about the manualupdates.html page, right? |
| 14:22 |
bos20k |
Dyrcona: yes, I was just trying to test the auto update stuff. Will do it a different way that should work. |
| 14:22 |
Dyrcona |
OK. |
| 14:22 |
Dyrcona |
In my experience auto updates work on Windows, but not Linux. |
| 14:22 |
jeffdavis |
^ To be clear, "that's what we do" = copy existing updates from production to our upgrade testing server, build the client on the test server with autoupdate_host set to our production URL, manually edit the autoupdate.js file to point at the test server for testing purposes, and copy the new updates from the test server back to production during the upgrade proper. |
| 14:23 |
jeffdavis |
Cumbersome, but works for us. (And yeah, web client will be nice!) |
| 14:23 |
bshum |
jeffdavis: That makes more sense to me. I didn't think diverging prod / test without copying something would work cleanly |
| 14:23 |
bshum |
jeffdavis++ # satisfying my curiousity :D |
| 14:24 |
Dyrcona |
I'd set the autoupdate host on the testing server at configure time and save a step or two. |
| 14:24 |
jeffdavis |
Dyrcona: well, we want to test the actual client that we make available to our libraries, and we want that client to have the production autoupdate_host built-in. |
| 14:25 |
Dyrcona |
But, I also would build everything fresh again on production proper. :) |
| 14:25 |
jeffdavis |
We have libraries that want the new client available to install several weeks in advance of the upgrade. |
| 14:26 |
jeffdavis |
Building on prod would be preferable for me, but not possible in that case, alas. :) |
| 14:26 |
Dyrcona |
See, I'd just tell them No, but I can be a jerk like that. :) |
| 14:27 |
Dyrcona |
j/k |
| 14:27 |
bshum |
I think ever since like 2.7, I stopped paying attention to XUL stuff, since it's basically been frozen |
| 14:27 |
bshum |
All that extra testing sounds boring when nothing is supposed to be different :) |
| 14:28 |
bshum |
But yay, testing |
| 15:13 |
bos20k |
I changed the hostname in autoupdate.js but it still says there is no update... |
| 15:14 |
jeffdavis |
Does your test server have a valid SSL certificate? |
| 15:14 |
|
rjackson_isl_ joined #evergreen |
| 15:15 |
bos20k |
jeffdavis: yes, it does |
| 15:15 |
bos20k |
I also tried changing https:// to http:// in autoupdate.js but that didn't make a difference either. |
| 15:28 |
Dyrcona |
bos20k: You can always do make updates-client again to be sure. |
| 15:28 |
bshum |
I wonder if it does matter what you name the thing |
| 15:29 |
bos20k |
Dyrcona: That has been done many times. |
| 15:29 |
bshum |
https://developer.mozilla.org/en-US/docs/Toolkit_version_format gets linked to from old https://wiki.evergreen-ils.org/doku.php?id=mozilla-devel:deploying_automatic_updates |
| 15:30 |
bshum |
and that talks about version numbering |
| 15:30 |
bshum |
Maybe it doesn't think biblio_2_12 is newer ? |
| 15:30 |
* bshum |
hasn't really tested |
| 15:31 |
bshum |
I mean I haven't tested words ahead of the numbers |
| 15:31 |
bshum |
The doc seems to say numbers, then letters |
| 15:31 |
bshum |
2.2.0mvlc.0 from the wiki |
| 15:31 |
bshum |
I'm really just spitballing and guessing; I don't know |
| 15:32 |
bos20k |
Hmmm, well, the default name is rel_2_12_3 I will try that next. If that doesn't work I will try just 2_12_3 |
| 15:33 |
bos20k |
Or maybe even 2.12_3... |
| 15:34 |
Dyrcona |
bos20k: The stamp id is not the version number. I skip stamp id and specify STAFF_CLIENT_VERSION when building. |
| 15:35 |
Dyrcona |
I'd have to check again how the version is determined from the STAMP_ID. |
| 15:36 |
Dyrcona |
bos20k: Probably. |
| 15:36 |
Dyrcona |
I believe the version needs to begin with digits or it gets confused, and use dots, not underscores for best results. |
| 15:39 |
bos20k |
Yup, don't mess with STAFF_CLIENT_STAMP_ID... It offers to update now. Now to clean up my mess and test the procedure again. |
| 15:40 |
bos20k |
Thanks again! |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:38 |
|
maryj joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:29 |
cesardv |
random fact: apparently mongoDB built a CI server called Evergreen https://jira.mongodb.org/browse/EVG |
| 17:37 |
berick |
huh, this is the first time i've made the connection of "ever green" to "always good/OK/GO" -- i'm guessing that was the motivation for the name. |
| 17:38 |
berick |
here I was just thinking about trees |
| 17:39 |
cesardv |
berick: they do have a green basil type of "leaf" as their logo |
| 17:40 |
berick |
cesardv: indeed, matching the color of the 'success' blocks on their test coverage grids |
| 17:40 |
berick |
(presumably, looks close) |
| 17:40 |
cesardv |
berick: yep definitely could be |
| 17:42 |
rhamby |
cesardv: our trademark requires they enter enter the realm of library services for infringment ... once they do though ... POW ZOOM TO THE MOON! |
| 17:43 |
phasefx |
unless we were Apple or somebody huge, then they'd sue or at least send nasty letters no matter what the domain :) |
| 01:36 |
|
BigRig joined #evergreen |
| 01:37 |
|
mnsri_ joined #evergreen |
| 01:39 |
|
abneiman joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:27 |
|
pinesol_green` joined #evergreen |
| 05:28 |
|
Bmagic_ joined #evergreen |
| 05:29 |
|
jeffdavi1 joined #evergreen |
| 10:13 |
Dyrcona |
Plus, it's easier to cherry-pick all of the commits and sign them all at once. :) |
| 10:14 |
Dyrcona |
I should see the fifth element. |
| 10:15 |
|
frank___ joined #evergreen |
| 10:15 |
frank___ |
Hi all, I am still trying to upgrade from 2.8.4 to 2.12.3, (from one sorver to another too), all the migration is fine, but when I test creating a marc record something weird hapends, for example, If I create/import a new record with this "©" character, it is saved in the database with an strange character "�", but if I re-open the same marc record register, and replace the character with the correct one it is saved correctl |
| 10:16 |
bshum |
Dyrcona: WHAT? You haven't seen the Fifth Element?! |
| 10:16 |
Dyrcona |
No, I have not, just bits and pieces. |
| 10:17 |
|
Freddy_Enrique joined #evergreen |
| 10:30 |
Dyrcona |
You could try that and see if it works better with a new record. |
| 10:30 |
frank___ |
ok, let me try |
| 10:33 |
Dyrcona |
phasefx++ gmcharlt++ |
| 10:35 |
abneiman |
Dyrcona++ for 1208875 test -- will make lots of people happy! |
| 10:51 |
dbs |
frank___: that sounds very familiar, I think we fought a similar battle when we upgraded to 2.9 or 2.10 (lots of French in use here)... I'll try to look at my notes about that |
| 10:52 |
dbs |
frank___: but check first to be 100% sure that your MARC record templates are correctly saved in UTF8 encoding |
| 10:52 |
dbs |
(our battle had more to do with MARC record copy catalogying from Z39.50 I think) |
| 16:12 |
* dbs |
does not enjoy reliving last September |
| 16:21 |
|
b_bonner joined #evergreen |
| 16:27 |
frank___ |
dbs: let me try |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:34 |
|
jwoodard joined #evergreen |
| 16:35 |
frank___ |
dbs: It works |
| 16:35 |
frank___ |
excellent |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
rlefaive joined #evergreen |
| 07:31 |
|
JBoyer joined #evergreen |
| 13:19 |
jonadab |
Ah. I was thinking more deletions than additions usually means the code got easier to maintain. |
| 13:20 |
Dyrcona |
Well, it did, since these files are separate from the others. |
| 13:20 |
Dyrcona |
Most of these are one shots, too. |
| 13:43 |
jeff |
has anyone here written tests (pgtap or other) for circ policies? |
| 13:44 |
jeff |
"if i check this item out to this patron it should go out for this long / with this rule? even if you were just testing circ matrix matchpoints exclusively to start... |
| 13:45 |
Dyrcona |
No, but I have used the database functions to check that certain rules are working as expected. |
| 13:47 |
jeff |
Dyrcona: for your syrup install(s), are staff logging into syrup with their evergreen credentials, or are you setting a password for each syrup-using staff member in syrup itself? |
| 13:47 |
Dyrcona |
jeff: I think they're using their evergreen credentials, but I wasn't here for the initial setup. |
| 13:47 |
JBoyer |
I don't know if I understand databases anymore. I take a query with 7 inner joins and 12 outer, add *9 more* outer joins and exec time goes from 184 seconds to 41. Consistently (+- a couple seconds; it's not caching that helps). |
| 13:48 |
Dyrcona |
JBoyer: The magic of indexes.... :) |
| 13:48 |
JBoyer |
jeff, I haven't written circ policy tests, but it seems like it would take significant setup to actually test properly. |
| 13:49 |
jeff |
JBoyer: could be that one or all of the additional joins are forcing the planner to make a decision it wouldn't normally make -- and it ends up being a better decision after all! |
| 13:49 |
JBoyer |
I suppose I should throw a couple EXPLAINs at it, that should make for some interesting reading... |
| 13:50 |
JBoyer |
jeff, Oh, re: policy testing, are you thinking just some tests that you can run against your own real data to make sure things work the way you expect? |
| 13:50 |
jeff |
JBoyer: right. |
| 13:50 |
Dyrcona |
I'm looking through some of my old stuff to see what I've got. |
| 13:51 |
JBoyer |
That does sound interesting. |
| 13:52 |
JBoyer |
Dyrcona, Sure, but it has a built in reminder to update the check to reflect the new policy. ;) |
| 13:52 |
Dyrcona |
heh |
| 13:53 |
Dyrcona |
IIRC, I mostly ran stuff in the database with the find_circ_matrix_matchpoint and related functions. |
| 13:56 |
jeff |
and for the exhaustive test, you just join actor.usr with asset.copy and actor.org_unit... |
| 13:59 |
Dyrcona |
heh |
| 13:59 |
Dyrcona |
Well, you basically need some representative transactions where you know what the outcome should be ahead of time....but you knew that. |
| 13:59 |
* jeff |
nods |
| 16:25 |
Dyrcona |
Oh. I think I may have copied the wrong apache2.conf for websockets. |
| 16:26 |
Dyrcona |
Looks like I got the Apache 2.2 version and this host is running apache 2.4. |
| 16:29 |
Dyrcona |
Yeap. |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:58 |
|
frank_guel joined #evergreen |
| 16:59 |
|
frank_guel joined #evergreen |
| 17:03 |
frank_guel |
Hi all, I am still trying to upgrade from 2.8.4 to 2.12.3, (from one sorver to another too), all the migration is fine, but when I test creating a marc record something weird hapends, for example, If I create/import a new record with this "©" character, it is saved in the database with an strange character "�", but if I re-open the same marc record register, and replace the character with the correct one it is saved correc |
| 17:04 |
frank_guel |
I tested in two diferent server and is the same, |
| 17:06 |
|
mmorgan left #evergreen |
| 17:58 |
|
Freddy_Enrique joined #evergreen |
| 18:05 |
|
Freddy_Enrique joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:38 |
|
Dyrcona joined #evergreen |
| 09:35 |
|
yboston joined #evergreen |
| 09:59 |
Dyrcona |
Yeap, grunt all blows up on me again on a fresh install on Ubuntu Xenial. This time I'm installing rel_2_12 with no customizations. |
| 10:02 |
Dyrcona |
I can try again with a fresh Debian 8. |
| 10:02 |
JBoyer |
Dyrcona, Not that I think this is a good thing to do full time, but if you just do a grunt build does it work? (i.e. skipping the test) |
| 10:02 |
Dyrcona |
I am installing the developer prereqs and not building node from source. |
| 10:02 |
Dyrcona |
JBoyer: I'll try that. It does look like a test that's failing. |
| 10:03 |
csharp |
npm feels fragile to me - kinda like ruby gems |
| 10:03 |
Dyrcona |
The build "succeeds" with this message from cssmin:combine : |
| 10:03 |
Dyrcona |
>> Destination not written because minified CSS was empty. |
| 10:04 |
csharp |
or even CPAN, though that's been more consistently stable than I've seen the other two be |
| 10:04 |
Dyrcona |
csharp: Node feels fragile to me, not just npm, worse than ruby gems. |
| 10:04 |
JBoyer |
I think the last time I was having issues with grunt test it was something of ours, but it's been a minute. |
| 10:05 |
Dyrcona |
I get that same reference error from yesterday. |
| 10:08 |
Dyrcona |
Hmm... Something isn't getting loaded in the tests, I assum. |
| 10:08 |
Dyrcona |
Assume, even. |
| 10:09 |
JBoyer |
It's ok, dropping the e in Assumr would be hipster, but dropping the e from Assum is tres Unix. |
| 10:09 |
Dyrcona |
It's complaining about the angular.module() line at the top of services/core.js. |
| 11:03 |
Dyrcona |
It might. I don't remember. |
| 11:04 |
berick |
Bmagic: a copy does not have to pass action.hold_request_permit_test to appear in the hold_copy_map. |
| 11:04 |
Bmagic |
i see |
| 11:05 |
berick |
only directly targeted (or op-captured) copies have to pass the test |
| 11:06 |
Bmagic |
I think we are getting warm |
| 11:06 |
Bmagic |
mmorgan: no penalties |
| 11:11 |
pinesol_green |
[evergreen|Jason Etheridge] lp1653998 webstaff redirect to login page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=518023b> |
| 15:33 |
jeffdavis |
If you have older records with old-style Overdrive URIs you don't need the 037. |
| 15:33 |
hbrennan |
We have the option of importing the MARC Express records to get caught up, and I haven't looked closely at them yet |
| 15:43 |
|
jihpringle joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:40 |
Dyrcona |
And, just like that: 92,811 lines of code written... |
| 16:40 |
Dyrcona |
emacs++ |
| 16:41 |
* berick |
chuckles |
| 16:42 |
* Dyrcona |
just mangled a spreadsheet into a ridiculous number of SQL inserts. :) |
| 16:43 |
Dyrcona |
About 5 lines for each insert. |
| 16:45 |
|
dbwells joined #evergreen |
| 16:50 |
jeff |
live test failure does not at first glance appear to be a transient one, nor does it seem to be what Dyrcona ran into recently. commit 518023b might need some followup. |
| 16:50 |
pinesol_green |
jeff: [evergreen|Jason Etheridge] lp1653998 webstaff redirect to login page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=518023b> |
| 16:50 |
jeff |
"Unknown provider: $routeProvider" |
| 16:56 |
Dyrcona |
Ah.. this just went in this afternoon. |
| 01:57 |
* bshum |
will look at it more tomorrow |
| 02:01 |
jeffdavis |
bshum++ |
| 03:12 |
|
RBecker joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:28 |
csharp |
~~ |
| 07:28 |
csharp |
 |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:30 |
|
maryj joined #evergreen |
| 10:26 |
bshum |
So it looks like there are three PO templates that are failing to import |
| 10:26 |
bshum |
Two of them appear to be tests |
| 10:27 |
bshum |
build/i18n/tests/data/sql2pot.pot |
| 10:27 |
bshum |
and build/i18n/tests/data/testidl.pot |
| 10:27 |
bshum |
Both of them are dying cause of a missing end qoute on line 6 where the timestamp should be, I guess. |
| 10:28 |
bshum |
I'm not really sure we should worry about these, given that they appear to be really ancient test files for PO Templates, but maybe we should either fix the line, or get rid of the file altogether if they no longer serve a purpose. |
| 10:29 |
bshum |
The other one that appears to be broken is build/i18n/po/multiclass_search_help.html/multiclass_search_help.html.pot |
| 10:29 |
bshum |
Which seems to be pulling the entire HTML in, instead of finding any specific strings |
| 10:29 |
bshum |
And it's choking cause it's expecting a PO template, not raw HTML |
| 10:31 |
bshum |
Since multiclass_search_help.html is part of the XUL server files, I'm not sure if we shouldn't also deprecate that and remove the offending POT and POs that can't be translated anyways |
| 10:35 |
Dyrcona |
I'm still working on setting up Syrup on an alternate host, and I really have no idea what I'm doing. The README is really short on details and seems to assume that you know Django and otherwise know what you're doing. |
| 10:35 |
Dyrcona |
Do I just have to change the settings in localsettings.py and it will just work? For some reason, I doubt that. |
| 10:36 |
jeff |
yep! my experience was similar, though possibly with an AM/PM inversion! |
| 10:42 |
Dyrcona |
So, I have to run the manage.py script in each instance... OK. |
| 10:43 |
Dyrcona |
The vm has a non-routing IP address. It's only visible at central site or via vpn. |
| 10:44 |
jeff |
assuming you're starting with Django 1.4.x, all of the top-level DATABASE_* settings in local_settings.py.example should be commented out, and you should use the example DATABASES= hash to set the various settings. |
| 10:44 |
dbs |
bshum: I think the POT tests are still useful. Looks like there is a small delta required for one or two of the tests to still pass. |
| 10:44 |
bshum |
dbs: Yeah I was just wondering if we run them as part of the nightly test |
| 10:44 |
jeff |
under DATABASES[default], i set ENGINE, NAME, USER, PASSWORD, HOST, and PORT |
| 10:45 |
Dyrcona |
jeff: Yes. I've copied everything from production and just modified the values. |
| 10:45 |
bshum |
dbs: Well, daily I guess. |
| 10:45 |
jeff |
for postgres, i used 'ENGINE': 'django.db.backends.postgresql_psycopg2' |
| 10:45 |
Dyrcona |
jeff: ditto. :) |
| 10:45 |
bshum |
I kind of wish there was a way of excluding the tests from going to LP translations though. |
| 10:45 |
jeff |
Dyrcona: ah! then you're at least starting from a working install, which is possibly better off than starting from scratch! |
| 10:45 |
Dyrcona |
Could be. :) |
| 10:46 |
Dyrcona |
I'm changing the db and the evergreen instance that it talks to. |
| 10:48 |
dbs |
bshum: might have been under buildbot? doubt it for the live reporter though |
| 10:48 |
bshum |
dbs: That's kind of what I figured |
| 10:49 |
dbs |
bshum: if launchpad is purely filename-based, we could do a workaround like having the setup / teardown rename a file from blah.pot.example to blah.pot for the test, then rename it back |
| 10:49 |
bshum |
dbs: Yeah it seems to be targeting only things with .po or .pot |
| 10:50 |
dbs |
testIDL and testSQL just need a single space removed from their POT test file to make their tests pass |
| 10:51 |
bshum |
Alternatively, we could create a different repo for translations right? And only sync that stuff against master or whatnot for the files we specify to target for translation efforts |
| 10:51 |
bshum |
Or do we want to keep everything as bound together as we can |
| 10:51 |
bshum |
(thinking ahead to when we replace LP translations) |
| 10:56 |
* bshum |
reads about Koha's thoughts on that in https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking |
| 10:58 |
bshum |
I guess they keep their POs as part of their main code still |
| 10:58 |
* bshum |
ponders that further |
| 10:58 |
dbs |
user/dbs/tiny_i18n_test_fix working branch has fixes for two of the i18n tests that were failing on my Fedora 25 machine |
| 10:58 |
dbs |
to test: cd build/i18n; python tests/testIDL.py; python tests/testSQL.py |
| 10:59 |
* dbs |
returns to prepping for Senate meeting |
| 11:00 |
bshum |
dbs++ # thanks |
| 11:26 |
Dyrcona |
jeff: Should I do manage.py syncdb or manage.py migrate? |
| 11:27 |
jeff |
syncdb in this case. |
| 15:03 |
eeevil |
but, best to get rid of shapers on safe networks in any case |
| 15:03 |
berick |
right, ok, bundling gets us back to multiple osrf blobs per message for tightly packed stuff |
| 15:03 |
eeevil |
right |
| 15:03 |
berick |
yes, agreed, i'm testing no-shapers now |
| 15:11 |
Dyrcona |
That grunt all error didn't happen on a Debian 7 server with a similar, but not identical branch. |
| 15:12 |
Dyrcona |
One big difference: The Debian 7 server had the staff client installed before, the Ubuntu vm is fresh. |
| 15:17 |
Dyrcona |
Happens with rel_2_12 on that same vm. I'll build a fresh one. |
| 15:54 |
berick |
get all the bits into the shelter! |
| 16:08 |
|
mmorgan joined #evergreen |
| 16:57 |
|
jihpringle joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
jwoodard joined #evergreen |
| 17:04 |
|
jihpringle joined #evergreen |
| 17:05 |
|
jvwoolf left #evergreen |
| 17:32 |
|
jihpringle_ joined #evergreen |
| 18:19 |
eeevil |
csharp: if you're using pgdump output (rather than pgdumpall) then I think you need to create the extensions (and set the search path, etc) before restoring. pgdump/restore is so much more finicky than pgupgrade... |
| 18:20 |
|
jihpringle joined #evergreen |
| 18:23 |
csharp |
eeevil: ah - thanks - in this case I'm dumping from our 9.4 prod db into a 9.5 test db - looks from stack exchange posts that the problem is that the extension isn't created in the right order |
| 18:24 |
csharp |
also doing parallel restore, so maybe that's a factor too |
| 18:42 |
|
jamesrf joined #evergreen |
| 19:29 |
jeff |
csharp: you've run into bug 1671150 which i should probably actually take a moment to work on. |
| 19:29 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 - Assigned to Jeff Godin (jgodin) |
| 02:09 |
|
Jillianne2 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
agoben joined #evergreen |
| 08:16 |
|
annagoben joined #evergreen |
| 10:56 |
pinesol_green |
Launchpad bug 1677000 in Evergreen "There is no visual indicator that a patron record has notes in the Web client" [Medium,In progress] https://launchpad.net/bugs/1677000 - Assigned to Jason Etheridge (phasefx) |
| 10:58 |
kmlussier |
Actually, that's not really my question. From what I can tell, some of the commits from collab/phasefx/webstaff-bugs have been merged, but not all of them. Is that right? |
| 10:59 |
* kmlussier |
isn't quite sure what the purpose of the collab branch is |
| 11:07 |
cesardv |
kmlussier: phasefx can correct me if I'm wrong, but basically it's a way to make sure everyone's commits play nicely with each other, avoid merge conflicts, and for testing changes that depend on other changes, or just general testing |
| 11:09 |
kmlussier |
Yeah, I guess I just don't understand why we do things differently for the web client than we do for other parts of the software, particularly when it comes to bug fixes. They could just be merged and backported once tested IMO. |
| 11:10 |
Dyrcona |
The only advantage of collab branches is multiple people can commit to them. |
| 11:10 |
Dyrcona |
That may be why it is being used. |
| 11:11 |
phasefx |
kmlussier: feel free to remove me. I'm not 100% on that branch either |
| 11:15 |
phasefx |
I think the notion is that folks could cherry-pick commits into master as needed but it made things simpler to batch up changes to test over here |
| 11:20 |
* gmcharlt |
notes that given the past practice of doing merges of big webstaff branches where there was relatively little review, at least at the individual patch level, with the bug fixes we've been moving back into a more "normal" workflow |
| 11:22 |
* csharp |
wishes his day job gave him more bandwidth for EG dev :-/ |
| 11:22 |
gmcharlt |
the bugfix collab branch is, at root, more of an artifact of how that particular bugfixing sprint is organized on Equinox's end |
| 14:18 |
Dyrcona |
@clone |
| 14:18 |
pinesol_green |
Dyrcona: I see nothing, I know nothing! |
| 14:18 |
Dyrcona |
:) |
| 15:19 |
pinesol_green |
[evergreen|Ben Shum] i18n: fix syntax for Spanish lang.dtd - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed7ae7c> |
| 15:37 |
|
collum joined #evergreen |
| 16:24 |
|
kmlussier joined #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:52 |
|
kmlussier joined #evergreen |
| 16:52 |
bshum |
@dessert |
| 16:52 |
* pinesol_green |
grabs some Chocolate Eclairs for bshum |
