| 09:32 |
csharp |
pinesol_green: nobody thinks you're intelligent - jeez! |
| 09:32 |
pinesol_green |
csharp: I am only a bot, please don't think I'm intelligent :) |
| 09:32 |
pinesol_green |
csharp: Thank you csharp! But our princess is in another castle! |
| 09:32 |
Dyrcona |
VM is ready, I'll be back in about half an hour to say yay or nay if the test works. |
| 09:36 |
|
maryj joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:47 |
|
kmlussier joined #evergreen |
| 11:03 |
jeff |
berick++ -- we're using 1.7 still, but I've been chewing through the "breaking changes" docs for 2.3 |
| 11:03 |
rlefaive |
beric++ jeff++ |
| 11:04 |
berick |
jeff: not sure if this is a 2.x thing, but I also had to tweak some of the queries for nested data. E.g. https://github.com/berick/marc-indexing-for-es/commit/665ff895a064ce64e81be5f3809e3f3734e94b4b |
| 11:08 |
jeff |
berick: ah! yep, I likely didn't update the rest of the examples when I added https://github.com/tadl/marc-indexing-for-es/commit/5ae1b4380fecef1fb40f9eb2f79753019ba77053 |
| 11:08 |
jeff |
(heh. that test is pretty... specific to us.) |
| 11:09 |
berick |
jeff: oh, cool, glad I'm on the right track. |
| 11:10 |
berick |
jeff: whoa, you're moving to catalog.apps.tadl.org as your main catalog? |
| 11:11 |
jeff |
not until tomorrow. :-) |
| 15:45 |
* Dyrcona |
pretty much agrees with gmcharlt and miker. |
| 15:46 |
bshum |
PG 9.3 buys us a year to decide what happens next time 'round |
| 15:46 |
gmcharlt |
any disagreement with that (i.e., somebody who wants to aim for 9.4 or 9.5)? |
| 15:46 |
bshum |
Well more than a year anyways |
| 15:46 |
bshum |
Plus I feel like there are already lots of us on PG 9.3 or better |
| 15:46 |
bshum |
So it should be "well tested" |
| 15:46 |
miker |
9.3 FTW |
| 15:47 |
gmcharlt |
going once... |
| 15:47 |
jeffdavis |
FWIW, looks like CentOS 6 (EOL 2020) comes with PG8.4, and CentOS 7 (EOL 2024) comes with PG9.2; not sure if major PG version advances happen in minor CentOS releases |
| 15:53 |
berick |
thanks, dbwells |
| 15:53 |
Dyrcona |
Did we talk about sqitch? Do we need to? |
| 15:53 |
kmlussier |
It was an outstanding action item from the last meeting. |
| 15:54 |
berick |
the sqitch branch is ready for wider testing. |
| 15:54 |
gmcharlt |
I can make some time between now and the EG conference to test |
| 15:54 |
berick |
if nothing else, it would be great if someone else got a feel for how it works |
| 15:54 |
Dyrcona |
I should see what it's about, but I have enough action items already. :) |
| 15:54 |
berick |
so I'm not stabbing too long in the dark. i only have my own experiences |
| 09:30 |
|
mrpeters joined #evergreen |
| 09:37 |
|
rlefaive joined #evergreen |
| 09:53 |
|
yboston joined #evergreen |
| 10:00 |
Bmagic |
berick: does the code in Open-ILS/src/perlmods/live_t/ work outside of the application server? Can I use it to connect and test remotely? From a non EG server? I need to make sure that I am involving ejabberd and such |
| 10:01 |
Dyrcona |
Bmagic: I can tell you that it will not work unless OpenSRF is installed. |
| 10:02 |
Dyrcona |
Bmagic: You will also need access to the private domain. |
| 10:02 |
Dyrcona |
Bmagic: The tests in live_t are intended to be used against the concerto dataset. |
| 10:03 |
Bmagic |
there we go, so, I cannot use that perl to test a remote server. I need to employ basically the stuff that the staff client uses in order to properly simulate "real world" ? |
| 10:04 |
Dyrcona |
Bmagic: What are you trying to test? |
| 10:04 |
Bmagic |
Placing holds, circulating an item, renewing, etc |
| 10:04 |
Dyrcona |
live_t is mainly meant to test that functionality remains as expected, not connectivity. |
| 10:05 |
Bmagic |
editing a patron, stuff like that |
| 10:05 |
Dyrcona |
Bmagic: There are tests in live_t that do some of those things, but as I said they are aimed at concerto and meant to be run from the server. |
| 10:06 |
Dyrcona |
For remote testing, you'll need to connect via the gateway or websockets. |
| 10:07 |
Bmagic |
yeah, I wasn't going to use those tests exactly, but perhaps as a guide. But if using the OpenSRF perl modules do not test the servers as the staff client would, then I can't really use them |
| 10:07 |
kmlussier |
miker / berick: Should bug 1347774 still be open? It looks like code was merged at the end. |
| 10:07 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" [Wishlist,Confirmed] https://launchpad.net/bugs/1347774 |
| 10:07 |
Dyrcona |
Is there a particular issue you are trying to resolve? |
| 10:07 |
Dyrcona |
kmlussier: I really doubt that bug is finished. |
| 10:08 |
Bmagic |
I want to be able to test the servers the same way our libraries do when using the staff client. I need to be able to do this easily and regularly |
| 10:11 |
jeff |
you may find some examples in constrictor. |
| 10:11 |
jeff |
are you attempting to add some monitoring, or do you have a different goal? |
| 10:12 |
Dyrcona |
Bmagic: This might be helpful: http://evergreen-ils.org/~denials/workshop.html#_javascript |
| 10:22 |
Bmagic |
Dyrcona: that web page looks helpful. It does seem like the perl bits rely on OpenSRF perl modules, which in turn rely on direct access to the DB? |
| 10:22 |
Dyrcona |
I usually decide everything is OK when all services are running and I can log in with the staff client. |
| 10:22 |
Dyrcona |
Bmagic: The perl does, but the JavaScript uses the translator or the gateway. That's why I linked to where the JavaScript starts. |
| 10:23 |
Bmagic |
Dyrcona: yes, that is how we test it right now as well, but there are things that we miss, especially when autogen is out of whack. And when there are 8 app servers in rotation, the issue may not be obvious |
| 10:23 |
Dyrcona |
Bmagic: One could write Perl modules to use the gateway, or add it as a transport in the OpenSRF Perl modules, if it isn't there already. |
| 10:24 |
Dyrcona |
Bmagic: Always run autogen.sh after an upgrade. |
| 10:24 |
Bmagic |
of course! |
| 10:24 |
Dyrcona |
The IDL usually changes and if it hasn't, there's no harm in it. |
| 10:25 |
Bmagic |
after running autogen - restart services - check each server and verify. It would be nice if a script could check much more like, editing a patron, circing an item and renewing, etc. Just to be able to closely replicate the expierence of our libraries |
| 10:26 |
Bmagic |
the test could time everything and give real data |
| 10:27 |
Dyrcona |
You can write that with the JavaScript. You could also write it in Perl and run it on an app server. |
| 10:27 |
Dyrcona |
The difference is minimal, though doing it from JavaScript would test if the Apache is working, too. |
| 10:28 |
Bmagic |
sounds promising |
| 10:40 |
Bmagic |
executing JS without a browser - from the command line looks challenging. node.js might be required... |
| 10:43 |
Dyrcona |
You could put it in a html file and open it from a browser. |
| 10:43 |
Dyrcona |
I believe that is what dbs expects one to do with the examples from the workshop. |
| 10:45 |
Bmagic |
yeah, I am trying to think of a way to make this more of an automated thing |
| 10:47 |
dbs |
http://jasmine.github.io/2.4/introduction.html says "It does not depend on any other JavaScript frameworks" |
| 10:48 |
dbs |
Pretty sure we already have some javacript tests in the codebase |
| 10:53 |
|
ericar_ joined #evergreen |
| 10:53 |
dbs |
Oh, heh. Good old Dojo Objective Harness in OpenSRF: http://git.evergreen-ils.org/?p=OpenSRF.git;a=blob;f=src/javascript/tests/README;h=d46224aef890afdfbb0b2a03b6a57477d96ecf43;hb=HEAD |
| 10:55 |
|
ericar__ joined #evergreen |
| 11:03 |
|
Christineb joined #evergreen |
| 11:18 |
|
bshum joined #evergreen |
| 11:23 |
Bmagic |
dbs: thanks, I will take a close look |
| 11:34 |
|
JBoyer joined #evergreen |
| 11:36 |
dbs |
I *think* webby has tests but I haven't touched it for months |
| 11:37 |
Dyrcona |
Yeah, I've been meaning to learn how to use karma to write staff client tests. |
| 11:37 |
Dyrcona |
If that is how its done. |
| 11:40 |
|
brahmina joined #evergreen |
| 11:41 |
|
evergreener joined #evergreen |
| 17:09 |
Bmagic |
I should be |
| 17:14 |
|
mmorgan left #evergreen |
| 17:28 |
sandbergja |
Quick question: does the editor column in asset.copy get modified when a staff usr circulates an item to somebody, or is it only stuff like changing barcode/circmod/etc. that tracks the editor? |
| 17:33 |
kmlussier |
sandbergja: I'm pretty sure the editor column only updates if you make actual edits to the copy, not circulations. But I haven't tested it. |
| 17:37 |
sandbergja |
thanks! I'm trying to track down whodunnit, and that's at least a possible lead |
| 17:47 |
bshum |
sandbergja: Whodunnit like who edited the item last or who checked it out? |
| 17:48 |
bshum |
The auditor table could tell you more either way. auditor.asset_copy_history |
| 10:33 |
kmlussier |
csharp++ |
| 10:33 |
dbwells |
tspindler: I'm always happy to help troubleshoot Evergreen LDAP issues. My LDAP experience is framed by what we do locally, so I'm eager to work through issues others may have to help make the code more robust. |
| 10:34 |
tspindler |
Thanks dbwells, our next step will be to see if each academic institution will even allow access ot LDAP servers |
| 10:36 |
yboston |
tspindler: shum told me they were using LDAP in Bibliomation too. I am actually about to launch a test of it very soon too |
| 10:36 |
jeff |
Hrm. There is a Welcome to Night Vale live show in Raleigh on April 20. |
| 10:37 |
tspindler |
thanks yboston, bshum just told me that ;) |
| 10:37 |
tspindler |
yboston, have you looked at it at Berklee |
| 10:39 |
jeff |
tspindler: I figured -- I was just voicing my interest in hearing what they said after you ask. :-) |
| 10:39 |
tspindler |
jeff: once we know I can report back |
| 10:40 |
gsams |
jeff: I have tickets to see the show here in Dallas on July 11. I'm looking forward to it. |
| 10:41 |
yboston |
tspindler: I am just about to fire up a VM with our LDAP credentials then I ill try it in our test Vm hosted by ESI. The long term plan is to use SAML "single sign on" |
| 10:41 |
yboston |
BTW, anyone here using SAML "single signon" with EG? |
| 10:42 |
jeff |
gsams: I was looking at their schedule and thinking "Cleveland... that might be worth the trip... oh, Detroit's a bit closer... oh hey, Raleigh... wouldn't that be funny if it was while I'm already going to be there for... hah!" |
| 10:44 |
jeff |
yboston: I'm not aware of any Evergreen support for SAML (either as IdP or SP), but it is something that interests me. |
| 10:54 |
|
Christineb joined #evergreen |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 Prevent linked address edit on reload - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8605e7d> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:08 |
jeff |
berick++ kmlussier++ gmcharlt++ |
| 17:18 |
Bmagic |
has anyone already developed some perl code that checks various things on an app server. Like, test circ, test patron edit, test renew etc? I'm looking at OpenILS::Utils::Cronscript. |
| 17:20 |
berick |
Bmagic: you might want to look at the stuff in Open-ILS/src/perlmods/live_t/ |
| 17:33 |
Bmagic |
berick: ty |
| 21:33 |
|
geoffsams joined #evergreen |
| 08:53 |
Dyrcona |
It is still active in the wip branch. |
| 08:53 |
Dyrcona |
I can choose either option. |
| 08:54 |
Dyrcona |
If it is left active, the JavaScript console will get a lot of messages about what is filling grids added to it. |
| 08:54 |
Dyrcona |
Dunno if you want that while testing or not. |
| 08:55 |
kmlussier |
Dyrcona: I think you can leave it commented out at this point. |
| 08:55 |
Dyrcona |
OK. |
| 09:00 |
Dyrcona |
The branch is ready. Time to build it, and upgrade the database. |
| 12:07 |
jeffdavis |
pg_dump -i -Fd -Z 9 -f /path/to/dumpfile --serializable-deferrable evergreen |
| 12:07 |
jeffdavis |
^ that's basically the command we use to create a dump of our db - note that it does not output a .sql file |
| 12:08 |
jeffdavis |
for restore, we create a new database using Evergreen's create_database_extensions.sql script, then use pg_restore to load the dumped data into it |
| 12:09 |
Bmagic |
jeffdavis: yeah, I was going to basically do those steps in testing today |
| 12:10 |
Bmagic |
Which switches do you use for eg_db_config.pl ? |
| 12:11 |
jeffdavis |
perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all --create-offline |
| 12:11 |
jeffdavis |
plus user, password, host, port, and database |
| 16:29 |
Bmagic |
miker: so, in this one paticular case, I could drop the index and create it again with the correct locale option? |
| 16:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1373601: Consider relevant characters before using word-boundary checks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e7c8785> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:36 |
miker |
Bmagic: I think you'd want to set the collation on the column and then reindex it ... that should be enough, I believe. a test server could tell. that said, I do think normalizing the sort value differently would be a good step to avoid this altogether ... like, replace spaces with +s or some such (more thought than I've just given it would be warranted, of course) |
| 17:37 |
|
maryj joined #evergreen |
| 17:39 |
Bmagic |
miker: thanks again! |
| 17:49 |
Bmagic |
I guess I have to drop the column and add it again. alter table metabib.browse_entry alter column sort_value SET NOT NULL COLLATE 'C'; does not work. errors on "COLLATE" |
| 16:51 |
Dyrcona |
Is 2.8 going to security-only or is it still open for regular bug fixes? |
| 16:51 |
Dyrcona |
And, it's a bit late to be asking questions. |
| 16:54 |
|
afterl left #evergreen |
| 16:55 |
Dyrcona |
I should find some more bug fixes to test, but two's enough for tomorrow. |
| 16:56 |
gmcharlt |
Dyrcona: I believe security-only at this point (or well, perhaps after 2.8.8 is cut), following the pattern |
| 16:57 |
Dyrcona |
OK. Sounds reasonable. |
| 16:57 |
Dyrcona |
The next dot releases are scheduled for the same day as the hackfest at the conference, btw. |
| 17:18 |
Bmagic |
does the purchase need to take place through acq in order for those requests to be acted on? |
| 17:19 |
jihpringle |
Bmagic: yes, staff have to place the requests |
| 17:19 |
Bmagic |
ah, sorry, im not coming up with much for documentation on the subject |
| 17:20 |
jihpringle |
we tested the functionality a while ago and decided that it wasn't ready for our libraries yet |
| 17:20 |
jihpringle |
I don't think it's been documented yet |
| 17:20 |
Bmagic |
right on - well, it looks promising. Perhaps a new tab in the patron OPAC interface? |
| 17:22 |
jihpringle |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1234247 |
| 17:22 |
pinesol_green |
Launchpad bug 1234247 in Evergreen "Request for Improvements to the Patron Requests UI" [Wishlist,Triaged] |
| 17:24 |
pinesol_green |
Launchpad bug 1269865 in Evergreen "ACQ user request can result in double (or quadruple) holds placement" [Medium,Confirmed] |
| 17:24 |
Bmagic |
ooo, good info! |
| 17:24 |
Bmagic |
jihpringle++ |
| 17:26 |
jihpringle |
I know I have some notes somewhere about other bugs/development needs for this from when we tested it that never made it to launchpad |
| 17:26 |
jihpringle |
I'll see if I can find them and get them up |
| 17:27 |
kmlussier |
Bmagic: I'm not sure about a new tab in the OPAC interface (I would have to give it some thought), but, if you could handle it elegantly without cluttering the interface, I think it would make sense to put something on a search results page. |
| 17:27 |
kmlussier |
Since that's the place where the user is most likely to discover that the library doesn't own the item. |
| 17:28 |
kmlussier |
Of course, I imagine it would also lead to many requests for things that just weren't found, even if the library owns it. |
| 19:48 |
|
pinesol_green joined #evergreen |
| 19:57 |
|
pastebot joined #evergreen |
| 19:59 |
|
pastebot joined #evergreen |
| 20:00 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "test paste of the answer to life, the universe, and everything" (1 line) at http://paste.evergreen-ils.org/11 |
| 20:01 |
|
pastebot joined #evergreen |
| 20:09 |
|
serflog joined #evergreen |
| 20:09 |
|
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 |
| 15:31 |
Dyrcona |
That's strange. I've run that script two or three times now and not had a problem with it. |
| 15:35 |
jeffdavis |
Yeah, the asset.copy record with id = 9680394 still exists just before COMMIT. |
| 15:36 |
jeffdavis |
Maybe this db snapshot is corrupt or something. |
| 15:37 |
jeff |
test by creating a dummy table with a BIGINT NOT NULL REFERENCES asset.copy(id) and then try to insert 9680394 to that field? |
| 15:37 |
Dyrcona |
Doesn't look like that part of the upgrade scripts does any deletes. |
| 15:37 |
berick |
jeff: i'm guessing you have not tried the 2.10 upgrade script yet... |
| 15:37 |
jeff |
it's possible that a bad index could be causing you grief... |
| 15:49 |
berick |
jeff: ugh, well, i was just wondering what the odds of this actually being a problem are |
| 15:49 |
berick |
but, i guess 100% in your case :) |
| 15:50 |
* berick |
will continue opening bug |
| 15:50 |
* tsbere |
wonders if there is a difference between "select from asset.copy where id = blah" and "select from only asset.copy where id = blah" in this case |
| 15:51 |
* tsbere |
has also not actually been following anything |
| 15:52 |
tsbere |
jeffdavis / jeff/ berick : Do you all remember that serial.unit inherits from asset.copy so all serial.unit entries are also asset.copy entries, but that as a result foreign keys don't work to asset.copy.id? |
| 15:53 |
* tsbere |
bases this question on the comment about testing with a REFERENCES asset.copy(id) earlier |
| 15:54 |
jeffdavis |
tsbere: ah! |
| 15:54 |
berick |
trying to remember how serials + circulation works now.. |
| 15:54 |
Dyrcona |
jeffdavis: That would be something to check if the id exists in serial.unit. |
| 16:15 |
jeffdavis |
Well, removing the FK reference on action.usr_circ_history.target_copy did allow the upgrade script to commit without errors. |
| 16:15 |
jeff |
> These deficiencies will probably be fixed in some future release, but in the meantime considerable care is needed in deciding whether inheritance is useful for your application. |
| 16:16 |
Dyrcona |
:) |
| 16:16 |
berick |
jeffdavis: thanks for testing and confirming that |
| 16:17 |
jeff |
that statement (or a singular variant of it) has been in the Postgresql docs at least as early as 7.3 :-) |
| 16:17 |
Dyrcona |
Well, jeff, you can always step up to write the code to address the deficiencies. :) |
| 16:17 |
jeffdavis |
berick: easily done, and now I have a 2.10 server to play with - thanks for the help! |
| 16:20 |
jeff |
tsbere: patches welcome! |
| 16:20 |
Dyrcona |
heh |
| 16:20 |
jeff |
:-) |
| 16:20 |
* tsbere |
doesn't know enough about using serials to test anything he did write, so will have to pass on writing the changes himself <_< |
| 16:21 |
* Dyrcona |
thinks someone who uses serials should do that one. :) |
| 16:30 |
* miker |
scrolls up... |
| 16:38 |
|
abneiman joined #evergreen |
| 17:06 |
|
mmorgan joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 18:01 |
|
dbwells_ joined #evergreen |
| 19:35 |
* kmlussier |
likes test plans that end with "the checkout should not explode." |
| 19:35 |
kmlussier |
berick++ |
| 19:47 |
|
bmills joined #evergreen |
| 19:59 |
|
Newziky joined #evergreen |
| 21:22 |
|
brahmina joined #evergreen |
| 13:25 |
|
Newziky left #evergreen |
| 13:35 |
|
jeff_ joined #evergreen |
| 14:11 |
|
b_bonner joined #evergreen |
| 14:14 |
Dyrcona |
I'm trying to figure out staff passwords from concerto for test writing, and I must be missing something. |
| 14:16 |
Dyrcona |
The usrname and passwd do not match what is in tests/datasets/sql/users_staff_134.sql. |
| 14:17 |
|
b_bonner_ joined #evergreen |
| 14:17 |
|
b_bonner joined #evergreen |
| 14:17 |
|
mnsri_away joined #evergreen |
| 14:17 |
|
rashma_away joined #evergreen |
| 14:20 |
Dyrcona |
All right I figured it out. |
| 14:21 |
Dyrcona |
At some point, they get the shortname of their home/work ou tacked onto the front of the usrname. |
| 14:24 |
Dyrcona |
Writing and testing the tests is taking more time than the original code, a lot more time.... |
| 15:08 |
Dyrcona |
Great. Severe query error and nothing in the postgres logs that looks related. |
| 15:10 |
Dyrcona |
Figured it out.... |
| 15:10 |
Dyrcona |
typo in a field name. |
| 15:13 |
pinesol_green |
JBoyer: It is so. |
| 15:13 |
JBoyer |
BOOM. |
| 15:18 |
Dyrcona |
Not my day.... |
| 15:18 |
Dyrcona |
I reloaded the database, ran the test again, and boom! |
| 15:18 |
Dyrcona |
I forgot to git pull, first.... |
| 15:19 |
Dyrcona |
So, reloading the database, yet again... |
| 15:19 |
Dyrcona |
I'm not counting. |
| 12:13 |
|
tarac_ joined #evergreen |
| 12:31 |
mmorgan |
related question. Is a database query to update money.billing.voided = true sufficient to void a billing, or does something else need to happen? |
| 12:32 |
phasefx |
mmorgan: I believe there's also voider and void time |
| 12:34 |
mmorgan |
Ah. Ok. Of course, that makes sense. Thanks. |
| 12:35 |
* mmorgan |
will try it out on a test system. |
| 12:36 |
mmorgan |
phasefx++ |
| 12:37 |
phasefx |
mmorgan: I would sanity check the associated transaction in money.materialized_billable_xact_summary |
| 12:37 |
|
sandbergja joined #evergreen |
| 12:37 |
phasefx |
mmorgan: I don't know how, but sometimes I would get that table out of sync with stuff I did with the payments and billings tables, and would have to recreate it |
| 17:31 |
kmlussier |
miker++ |
| 18:00 |
jeff |
most recent comment on bug 1174498 makes me concerned |
| 18:00 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" [Wishlist,Triaged] https://launchpad.net/bugs/1174498 |
| 18:00 |
* jeff |
looks |
| 18:00 |
jeff |
well that's unfortunate. |
| 18:01 |
jeff |
my fault for not being more forceful with my feedback. |
| 18:02 |
jeff |
it seems that we've moved away from a linear timeline with billings and payments, though i could be wrong. more digging required. |
| 18:03 |
jeff |
if that is the case, i'm strongly in favor of fixing it. the bad news is that it will probably take some work. the good news is that it will probably result in a lot more tests being written. ;-) |
| 18:05 |
jeff |
drat. dug, found it. |
| 18:05 |
jeff |
# Try to map payments to bills by amounts starting with the |
| 18:05 |
jeff |
# largest payments: |
| 18:05 |
jeff |
|
| 18:06 |
jeff |
that's not how this works. that's not how any of this works. :-) |
| 18:23 |
jeff |
first i should catch up on the rest of the billing changes. |
| 18:47 |
jeff |
I wonder if there's a way to fix this without resorting to two types of transactions. |
| 19:08 |
|
kitteh__ joined #evergreen |
| 19:48 |
* jeff |
reads old bugs |
| 20:24 |
|
rlefaive joined #evergreen |
| 21:18 |
miker |
jeff: oh, I should have been paying more attention too... yeah, matching amounts seems like a non-starter to me |
| 21:29 |
jeff |
@praise SIGSTOP |
| 22:05 |
jeff |
heh |
| 22:05 |
Bmagic |
yeah, it gets muddy for sure. I look at mmpbbt as "best effort" or "best guess" |
| 22:05 |
Bmagic |
and I think our libraries undestand that. Sometimes, a human still needs to step in and make a call |
| 22:07 |
Bmagic |
with that said - I have put untold hours into testing and watching the code interact with the data, and I'm feeling pretty good about the job that it will do for our libraries who look at the results |
| 22:20 |
jeff |
Bmagic++ |
| 22:21 |
Bmagic |
jeff++ |
| 09:37 |
jeff |
Some other things to consider are that you're going to need a decent amount of RAM (2 to 3 GB dedicated to Evergreen's use) on that laptop to run Evergreen with any kind of success, even for evaluation purposes. What is your goal with this installation? |
| 09:38 |
scrawler |
ok I'm back. |
| 09:38 |
scrawler |
this thing has 4 gigs of ram. I'd like to evaluate evergreen for use in a high school library. |
| 09:38 |
jeff |
And expanding on what was said earlier and repeating something that was said when you were changing clients: Arch Linux may work, but is not supported or tested, and you may run into difficulties during installation or operation that we won't be able to help you with easily. |
| 09:39 |
scrawler |
I understand. |
| 09:41 |
Dyrcona |
scrawler: If you're running the database and everything on the same system, I recommend at least 8GB of RAM just to kick the tires, particularly if the hardware is not solely dedicated to Evergreen. |
| 09:41 |
Dyrcona |
I build vms with 4GB of RAM for test purposes and the database runs on a dedicated server, and that is cutting it close sometimes. |
| 09:42 |
csharp |
scrawler: I would scrounge around for an unused desktop with at least 4GB of RAM and install Ubuntu (server) or Debian (with no GUI) and start there |
| 09:43 |
Dyrcona |
Yeah, 4GB might work for everything, but it would be a tight fit. |
| 09:44 |
scrawler |
Well, this very box had debian on it to begin with, and I successfully got opensrf running, at least. |
| 09:54 |
scrawler |
ok, thank you guys. I'm going to see if I can put together an old desktop and try again with debian. |
| 09:56 |
scrawler |
are there any alternative (quicker) ways to evaluate, like a hosted instance? |
| 09:56 |
scrawler |
a really cheap hosted instance? |
| 09:57 |
csharp |
scrawler: http://wiki.evergreen-ils.org/doku.php?id=community_servers has some test servers you can play in |
| 09:58 |
csharp |
scrawler: also, if you want to investigate paid support options: http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_companies |
| 10:00 |
|
mmorgan joined #evergreen |
| 10:01 |
scrawler |
thanks for the links--looking at them now :) |
| 10:05 |
scrawler |
Thanks again everybody. ttys. |
| 15:26 |
|
bmills joined #evergreen |
| 15:26 |
kmlussier |
miker: The activity metric for holds ratios, the first number of the ratio is looking at the number of holds in the action.hold_copy_map? Am I interpreting that correctly? |
| 15:31 |
miker |
kmlussier: yes, you are. holds-on-copies / copies |
| 15:32 |
kmlussier |
miker: Thanks! |
| 16:00 |
|
jlitrell joined #evergreen |
| 16:16 |
* kmlussier |
decides to test the 'o, africa!' bug fix while waiting for activity badge scores to recalculate. |
| 16:17 |
mmorgan |
kmlussier++ |
| 16:18 |
kmlussier |
What I like about that bug is that it's easy to find in LP. There aren't many eg bugs that have o africa in them. |
| 16:33 |
abneiman |
miker: thanks for the additional info! Sorry, I wandered off for 2 hrs -- was forced to drive around the county on a beautiful day to fix some printers. Tough life. :) |
| 17:52 |
pinesol_green |
gmcharlt: Quote #35: "<tsbere> We have collective sanity left? We might want to double-check on that. ;)" (added by bshum at 05:00 PM, November 06, 2012) |
| 21:13 |
|
jihpringle joined #evergreen |
| 21:17 |
kmlussier |
@quote random |
| 21:17 |
pinesol_green |
kmlussier: Quote #134: "10:04 < Dyrcona> He's running the scripts....He's checkin' 'em twice. He's gonna find out which are naughty or nice. Santa Dev is testing a branch." (added by csharp at 11:11 AM, December 16, 2015) |
| 21:53 |
bshum |
gmcharlt++ # web server poking |
| 21:58 |
bshum |
@roulette |
| 21:58 |
pinesol_green |
bshum: *click* |
| 10:08 |
jeff |
what, you were planning on porting to openbsd running on an E25K or something? :-) |
| 10:09 |
Dyrcona |
Well, I've got a spare box with an Atom D525 and 2GB of RAM..... ;) |
| 10:09 |
Dyrcona |
But, seriously, I think finishing the FreeBSD port and then working on OpenBSD would be a good way to go. |
| 10:23 |
Dyrcona |
So, I'm looking at writing a Perl test for a change to abort transit behavior. |
| 10:23 |
Dyrcona |
I wonder if we want to renumber the names of some of the test in live_t? |
| 10:23 |
Dyrcona |
kmlussier asked about this before. |
| 10:24 |
Dyrcona |
We've got 3 tests numbered 10- and 2 that are 12-. |
| 10:24 |
kmlussier |
+1 to renumbering |
| 10:39 |
Dyrcona |
Tests are often more complicated than the code changes that they are testing. |
| 10:49 |
Dyrcona |
Speaking of tests: Bailout called. Further testing stopped: cannot test opt-in unless enabled in opensrf.xml |
| 10:50 |
Dyrcona |
Maybe that should fail a bit more gracefully, with the remaining tests being optional? |
| 10:51 |
|
rlefaive joined #evergreen |
| 10:57 |
Dyrcona |
Two hundred lines of test script for a 4-line change in the code....Sounds about right. ;) |
| 11:00 |
|
mmorgan1 joined #evergreen |
| 11:01 |
jeff |
in theory, those two hundred lines now will be run many times over their lifetime, and will prevent future headaches. :-) |
| 11:10 |
|
remingtron joined #evergreen |
| 11:10 |
Dyrcona |
Y'know, I find myself copying and pasting a lot of code from test script to another. |
| 11:11 |
Dyrcona |
Maybe that should get added to TestUtils? |
| 11:11 |
Dyrcona |
Specifically code to retrieve patrons and copies. |
| 11:30 |
|
bmills joined #evergreen |
| 15:44 |
|
brahmina joined #evergreen |
| 15:44 |
|
jlitrell joined #evergreen |
| 15:53 |
dbs |
csharp++ # fedora fedora fedora |
| 16:15 |
* Dyrcona |
thinks he has seriously underestimated the lines of test script. |
| 16:17 |
JBoyer |
"I have made the test more trying; pray I do not try it any further." |
| 16:18 |
kmlussier |
miker / gmcharlt: What exactly is the On-line bib has attributes parameter looking at? Is it any record with a particular record attribute, even if it doesn't have URIs? |
| 16:19 |
Dyrcona |
JBoyer: In a private convo with kmlussier, I said, "These are no the Perl tests you are looking for." |
| 16:19 |
Dyrcona |
s/no/not/ |
| 16:19 |
* Dyrcona |
shoulda copied and pasted. |
| 16:20 |
kmlussier |
It's always a shame when you mess up a punchline with typo. |
| 16:20 |
Dyrcona |
Indeed. |
| 16:21 |
JBoyer |
It was either that, or "You may test me now, but I shall become more powerful than you can possibly imagine" |
| 16:30 |
miker |
kmlussier: the intent is those with located URIs |
| 16:33 |
JBoyer |
csharp, do you know if anyone at PINES is running reports that look at the Dewey ranges? We've got a couple simple reports that try to do circ counts by range and they take over 4 hours to run. Not good. :-/ |
| 16:34 |
kmlussier |
miker: Ah, ok. The on-line one is uris' only, "bib has attributes and copies" is copies only, and then "bib has attributes and copies or URIs" is a combination of the two? |
| 09:38 |
csharp |
@loves |
| 09:38 |
pinesol_green |
csharp loves supybot plugins; virtualization; lasagna; logs; clarity; all y'all; upgrades; tpac; git; this venue; google; not being evil; when evergreen problems turn out to be staff error; the Jedi; pgadmin; policy; lynx; autoupdate; coffee; db02; kvm; CWMARS; mobile catalog; vim; snow; pizza; google forms; chicken soup; cilantro; actual fun; supybot; vimdiff; felafel; and postgresql |
| 09:38 |
csharp |
@hates |
| 09:38 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (1 more message) |
| 09:38 |
csharp |
@more |
| 09:38 |
pinesol_green |
csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; and omg I love acq |
| 09:42 |
gmcharlt |
csharp: some rebalancing may be in order... ;) |
| 13:03 |
|
brahmina joined #evergreen |
| 13:05 |
jeffdavis |
jeff: Theoretically yes. Work is focused on having a more generic "API integration" module for EG, with OneClickdigital as the first target (sort of like the added content module). |
| 13:06 |
jeffdavis |
We've been talking about it at Sitka in terms of OneClickdigital specifically but I would expect to extend that for Zinio. |
| 13:08 |
* jeff |
nods |
| 13:08 |
jeff |
It sounds like we have some interest here. I'd be happy to test and/or collaborate. Keep it in mind. I'll keep my eyes on the bug. :-) |
| 13:33 |
|
rlefaive joined #evergreen |
| 13:39 |
dbs |
Dyrcona++ # pingest |
| 13:47 |
|
rlefaive joined #evergreen |
| 14:49 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-22-14.04.html |
| 14:49 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-22-14.04.txt |
| 14:49 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-22-14.04.log.html |
| 15:15 |
gmcharlt |
kmlussier: worked this up for your benefit in testing, but others may find it useful |
| 15:15 |
gmcharlt |
memcdump --servers localhost|grep open-ils.search | xargs -n 1 memcrm --servers localhost |
| 15:16 |
gmcharlt |
^^ way to clear all cached catalog search results -- can be useful when testing certain tweaks |
| 15:56 |
|
artunit_away_ joined #evergreen |
| 15:56 |
|
jlitrell joined #evergreen |
| 15:56 |
|
mmorgan1 joined #evergreen |
| 11:22 |
berick |
huh, a "round" of robins |
| 11:24 |
mmorgan |
Really? |
| 11:24 |
* mmorgan |
didn't know that |
| 11:25 |
berick |
first time using virt-manager's network install option today. (testing xenial). pleased at how simple it is. |
| 11:27 |
Dyrcona |
berick++ |
| 11:27 |
jeff |
where you're PXE booting a vm or other client, and installing from the network with a preseed.txt or similar so that you've got a zero-prompt install? |
| 11:27 |
Dyrcona |
I've mostly used virt-manager to fix a "busted" vm. |
| 11:38 |
|
brahmina joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:02 |
* tsbere |
has come up with a way to make AddedContent use B&T ISBNs, but isn't sure he likes it |
| 12:05 |
StomproJosh |
tsbere, I would be happy to test it out. |
| 12:09 |
tsbere |
StomproJosh: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/lp1559281_bt_isbns |
| 12:09 |
* tsbere |
dumped a link onto bug 1559281 as well |
| 12:09 |
pinesol_green |
Launchpad bug 1559281 in Evergreen "Added Content: Allow fake ISBNs to be sent to providers" [Undecided,New] https://launchpad.net/bugs/1559281 |
| 12:14 |
StomproJosh |
gmcharlt, I've only seen a few, we try to add the UPC if it isn't there to bypass this issue, I don't know how often that is needed though. |
| 12:18 |
jeff |
Sure would be nice if the Business::ISBN docs matched the code. |
| 12:20 |
jeff |
is_valid_checksum returns Business::ISBN::BAD_CHECKSUM for 9786316294241, but Business::ISBN::GOOD_ISBN if we set $Business::ISBN::country_data{631} as in tsbere's branch. |
| 12:22 |
tsbere |
jeff: And to think, I just kindof guessed as to how I should set it, found it worked on one test, and then made a branch. |
| 12:23 |
jeff |
lovely, if i run ->fix_checksum (which seems like a terrible idea in almost every case), the isbn value is not modified but now is_valid_checksum returns Business::ISBN::GOOD_ISBN |
| 12:24 |
jeff |
(that last was with no changes to $Business::ISBN::country_data) |
| 12:24 |
jeff |
at least at first glance, that behavior strikes me as a bug in Business::ISBN, but even if so, and if reported, we pretty much need to at least work around it for now. |
| 15:12 |
Dyrcona |
It caused too much confusion when different libraries were doing parts differently. |
| 15:12 |
* mmorgan |
nods. |
| 15:16 |
Bmagic |
gmcharlt bummer :( |
| 15:18 |
* Dyrcona |
doesn't generally test Vandelay. |
| 15:19 |
gmcharlt |
it appears that the upgrade script was created by copying and pasting some bits from a terminal that was 80 characters wide |
| 15:20 |
gmcharlt |
and, amazingly, one line was truncated there but ended up with the results being syntatically correct |
| 15:20 |
mmorgan |
:-( |
| 17:37 |
dbs |
Looks like we have 2 total copies since we migrated that have that. |
| 17:37 |
Bmagic |
it's fooling me. The example I have from 2016, had it's status changed in 2011 |
| 17:41 |
* dbs |
wonders if IRC search is known not-working: http://irc.evergreen-ils.org/evergreen/search/?nick=dbwells&q=datafield returns an "Internal search error" |
| 17:42 |
dbwells |
dbs: anything I can help answer, or am I just a test case? :) |
| 17:44 |
dbs |
dbwells: sorry, just a test case, I was trying to track down the xpath discussions from before |
| 17:44 |
dbs |
found them manually, but was surprised search was erroring out |
| 17:45 |
Bmagic |
google is handy for me |
| 17:45 |
Bmagic |
site: http://irc.evergreen-ils.org xpath |
| 17:46 |
dbs |
Bmagic: sure, but the internal search should either work or not be there |
| 14:57 |
kmlussier |
miker: Do you think it's useful to point people to the logs before the discussion or at the end? |
| 14:58 |
berick |
Dyrcona: if you are switching between master and 2.9, you'll have to ./configure again |
| 14:58 |
Dyrcona |
I'm building from the tarball and things seem really wrong. |
| 14:59 |
berick |
ah, haven't tried that yet. i'm building a 2.8.6 install now to test the upgrade script. will test my tarball in a few mins |
| 14:59 |
Dyrcona |
My server seems to be adding the unaccent extension or something, and then everything blows up. |
| 15:00 |
afterl |
kmlussier: I'm not miker, but I think having the logs handy during the discussion is a good idea - you can easily search on a word like "popular" like I just did to see if it had already been discussed |
| 15:00 |
Dyrcona |
No, unaccent is not in the list of extensions, but meeting.... |
| 15:19 |
kmlussier |
sarahchilds: Ah, I see. So it's a "Did you mean?" but leveraging authority data. Gotcha. |
| 15:19 |
sarahchilds |
If you do a search for Samuel Clemens, it would suggest Mark Twain |
| 15:20 |
dbs |
I'd like to see grouping of search results based on external links to, say, OCLC Work Entities |
| 15:20 |
kmlussier |
To follow up on what afterl said, we do have activity metrics coming to search that afterl and I have been testing. But the blending of popularity with relevance is tricky. And we're still working on it / testing it. |
| 15:21 |
kmlussier |
dbs: Can you give me an example of a search that would use that and how the info would be presented to the user? |
| 15:24 |
dbs |
kmlussier: sure. A regular search for "Huckleberry Finn" would give you all of the hits for "Adventures of Huckleberry Finn" based on keywords |
| 15:24 |
dbs |
but using links to OCLC Work Entities, you could group those records even if they were in different languages and the words appeared nowhere in the record |
| 15:25 |
kmlussier |
Ah, nice! Thanks for the explanation dbs! |
| 15:33 |
kmlussier |
sarahchilds: So improvements in relevance. Do you find there are specific problems in relevance that cause those records to appear low in the list? |
| 15:34 |
terran |
And of course, a good "did you mean...?" service to accommodate mis-spellings and related topics |
| 15:35 |
sarahchilds |
One of the issues I get complaints about is that our users expect to be weighed more heavily |
| 15:35 |
kmlussier |
terran / rhamby: On the popularity front, afterl had brought this up earlier, but there is an ongoing project as rhamby noted, but, from early testing, we're also looking at ways to better blend bib relevance with popularity. Which is tricky. |
| 15:35 |
sarahchilds |
expect *title* to be weighed more heavily |
| 15:35 |
kmlussier |
sarahchilds: Thanks! Then field-weighting is important. |
| 15:36 |
terran |
Yes, I strongly agree with weighing title (and primary author) more heavily |
| 11:18 |
mmorgan |
Forsyth: One more question: To recover, do you force close Evergreen and restart the client, or is it necessary to reboot the workstation? |
| 11:18 |
Forsyth |
on the ram, i have checked resources as well as other apps work fine. just evergreen stops responding to keyboard and mouse input |
| 11:18 |
gmcharlt |
Forsyth: what sort of internet connection does that branch have? a high-latency one could cause issues. Another potential source of problems is that branch (and only that branch) running a firewall, content filter, or caching proxy server that adds latency to interactions with Evergreen |
| 11:19 |
kmlussier |
For the logs, after several tests, I'm confirming that the regex for the username setting is not consulted at patron registration or when editing a patron record. |
| 11:19 |
Forsyth |
they have a 35/5 time warner connection, as our other branches |
| 11:19 |
* kmlussier |
will file a bug to update the description for the setting. |
| 11:20 |
Forsyth |
as you can see it is one of those frustrating intermittent issues we can't put a finger on |
| 11:22 |
Dyrcona |
@blame bad Feng Shui |
| 11:22 |
pinesol_green |
Dyrcona: bad Feng Shui wants the TRUTH?! bad Feng Shui CAN'T HANDLE THE TRUTH!! |
| 11:24 |
Forsyth |
i'd like to perform a ping test from our network router to the evergreen server if possible, to see if we have any drops throughout the day |
| 11:24 |
Forsyth |
is there a server name or IP i could use |
| 11:26 |
Dyrcona |
Forsyth: That would be the name of your Evergreen server from the staff client login screen. |
| 11:26 |
Forsyth |
ok, thanks |
| 09:27 |
|
jboyer joined #evergreen |
| 09:30 |
jboyer |
berick: did you mention in the last couple of months that you couldn't disable some version of ssl because the XUL client could no longer connect? Google-ing the logs is letting me down if so. |
| 09:32 |
|
mmorgan1 joined #evergreen |
| 09:32 |
Dyrcona |
jboyer: That is true. berick did say that, and I confirmed it with a quick test on my development system. |
| 09:32 |
Dyrcona |
You can, I believe disable SSL, but you can't disable certain versions of TLS. |
| 09:33 |
* Dyrcona |
can't comma right. |
| 09:34 |
jboyer |
Oh. That does sound more familiar. TLS 1.1 or 1.2 maybe. I was trying to look it up while I wait for my car to be repaired, this is how I stay entertained these days, I guess. |
| 10:12 |
|
mmorgan joined #evergreen |
| 10:42 |
|
Christineb joined #evergreen |
| 11:07 |
|
vlewis joined #evergreen |
| 11:08 |
Bmagic |
bug 1437112 - was tested on bug squashing day and received sign offs. I noticed that it may* have introduced issues with the search screen |
| 11:08 |
pinesol_green |
Launchpad bug 1437112 in Evergreen "not possible to set workstation preferences in web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437112 |
| 11:08 |
Bmagic |
https://sb1.missourievergreen.org/eg/staff/cat/catalog/index |
| 11:08 |
Bmagic |
gadmin/admin |
| 11:29 |
|
mmorgan1 joined #evergreen |
| 11:37 |
|
JBoyer joined #evergreen |
| 11:46 |
|
sandbergja joined #evergreen |
| 12:09 |
kmlussier |
Bmagic: I believe Dyrcona loaded it on his dev server at one time along with several other branches. There were some issues, and he removed most of the branches because I had to focus my testing elsewhere. I never identified which branch was causing the problem. |
| 12:10 |
kmlussier |
Bmagic: I'm pretty sure it was the same issue you're seeing now. I would say that branch isn't ready to go. |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:15 |
kmlussier |
Bmagic: Hmmm...It looks like the weird behavior happens only if you don't set your workstation search preferences. Once you set them, the advanced search screens come up okay for m. |
| 12:16 |
kmlussier |
Perhaps the tester started by setting the worsktation preferences and didn't notice that the search screen was messed up when the preferences weren't set. |
| 12:19 |
Bmagic |
kmlussier: I registered my workstation, and I am still getting {{label}} all over that page |
| 12:19 |
kmlussier |
Bmagic: That's the branch where you had to resolve conflicts, right? That should also be noted on the bug. Do you want to add a comment to the bug or should I? |
| 12:19 |
kmlussier |
Bmagic: No, it's not the workstation registration that fixed the display. It was setting the default search preferences. |
| 09:34 |
Dyrcona |
csharp: Makes sense to me. |
| 09:34 |
Dyrcona |
If it appears to work, I'll sign off on the branch, and then comment on the bug that I don't think it should be backported and why. |
| 09:42 |
kmlussier |
Dyrcona: +1 |
| 09:43 |
* Dyrcona |
adds accents to his name, so he has something to test with. |
| 09:43 |
kmlussier |
Dyrcona: I think there are two types of reingests required: record attribute and then another one for the new genre index. |
| 09:44 |
Dyrcona |
So, would that be a search reingest? |
| 09:44 |
Dyrcona |
Or facets.... |
| 10:02 |
Dyrcona |
Too many staff clients open.... :) |
| 10:02 |
Dyrcona |
OK, fine with me. |
| 10:02 |
|
jvwoolf joined #evergreen |
| 10:04 |
Dyrcona |
My name turns out to be a good one to use for testing, because we have about 35 patrons with the same last name. |
| 10:07 |
Dyrcona |
There aren't any tests on that branch. |
| 10:07 |
Dyrcona |
So, it needs another signoff anyway. |
| 10:12 |
|
terran joined #evergreen |
| 10:14 |
hopkinsju |
Good morning my friends! Happy Bug Squashing Day! |
| 10:35 |
Dyrcona |
I can add the new cancel reason, but the check boxes are all inactive. |
| 10:36 |
Dyrcona |
lualaba__: Did you see the bug that I mentioned to you above? |
| 10:39 |
lualaba__ |
https://bugs.launchpad.net/evergreen/+bug/1491962 ? |
| 10:39 |
pinesol_green |
Launchpad bug 1491962 in Evergreen 2.8 "Fix for 1484281 breaks live test" [Undecided,Fix released] |
| 10:39 |
lualaba__ |
what i understand here in new release was fixed |
| 10:40 |
Dyrcona |
lualaba__: No, lp 1531953 |
| 10:40 |
pinesol_green |
Launchpad bug 1531953 in Evergreen "Z39.50 Import Fast Item Add Yields Unsaved Data Popup " [Undecided,New] https://launchpad.net/bugs/1531953 |
| 10:44 |
lualaba__ |
thats no problem just popip thank you |
| 10:44 |
mmorgan |
lualaba__: It's just a pop up issue. Here is a related bug: https://bugs.launchpad.net/evergreen/+bug/1491875 |
| 10:44 |
pinesol_green |
Launchpad bug 1491875 in Evergreen "Erroneous "Tab may have unsaved data" message when creating new MARC record" [Undecided,New] |
| 10:44 |
csharp |
Dyrcona: in my testing, the newly created reason is "checkable" - the ones that are inactive have ids < 2000 |
| 10:44 |
Dyrcona |
you click the exclamation point next to "Does this bug affect you?" and that might help it get more attention for a fix. |
| 10:44 |
mmorgan |
These two bugs may actually be the same issue |
| 10:45 |
Dyrcona |
csharp: I can't check anything, not even the new one. |
| 10:45 |
csharp |
hmm - I'll try again after I get done testing dbwells's branch for bug 1528627 |
| 10:45 |
pinesol_green |
Launchpad bug 1528627 in Evergreen "Feature Request: Evergreen "su/sudo" functionality" [Undecided,New] https://launchpad.net/bugs/1528627 |
| 10:46 |
Dyrcona |
Switch User is not good enough, eh? :) |
| 10:47 |
csharp |
:-) |
| 11:11 |
|
agent11 joined #evergreen |
| 11:18 |
Dyrcona |
csharp: Your branch fixes it for me. |
| 11:19 |
csharp |
Dyrcona: awesome |
| 11:20 |
Dyrcona |
I'll run your test. Looks like it should work with my data. |
| 11:20 |
Dyrcona |
If that passes, I'll push it. |
| 11:22 |
Dyrcona |
Works for me! :) |
| 11:22 |
csharp |
Dyrcona++ |
| 14:30 |
bshum |
Wrong user or missing bashrc path. |
| 14:30 |
* bshum |
will take Evergreen Troubleshooting for 400, please Alex. |
| 14:31 |
Dyrcona |
Tell 'im what he didn't win, Don Pardo. |
| 14:38 |
jihpringle |
kmlussier: I'm testing the two unclaimed self check bugs (1370694 and 1551447) |
| 14:38 |
kmlussier |
jihpringle++ |
| 14:39 |
kmlussier |
jihpringle: You've got the server details, right? |
| 14:39 |
jihpringle |
yes |
| 08:24 |
* pinesol_green |
Shall I compare Terran to a summer's day? Terran is more lovely and more temperate. |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:36 |
pinesol_green |
[evergreen|Galen Charlton] LP#1371647: fix thinko with ID re-pinning - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=896461c> |
| 08:42 |
kmlussier |
I had a thought for doing something new for this Bug Squashing Day that we might want to do on the days that fall after a beta release. |
| 08:43 |
kmlussier |
It might be a good opportunity to get volunteers to walk through some of the test cases on the Evergreen wiki to check for bugs in the beta release. Just to make sure it really does get tested. |
| 08:49 |
Dyrcona |
Yep, and/or run the test suite. |
| 08:50 |
gmcharlt |
Dyrcona: would you have a moment now to test a patch for 1505286? |
| 08:51 |
Dyrcona |
gmcharlt: I would, but I also made my own yesterday. :) |
| 08:52 |
JBoyer |
lp 1505286 |
| 08:52 |
pinesol_green |
Launchpad bug 1505286 in Evergreen "set limit on facets retrieved during search" [Wishlist,Fix committed] https://launchpad.net/bugs/1505286 |
| 08:53 |
Dyrcona |
gmcharlt kmlussier: BTW, I just installed screen on my development system. I thought you might prefer that over tmux. |
| 08:53 |
gmcharlt |
Dyrcona: ah, cool; I'll just run with that, though I'm inclined to add a second update to force cases where the patch applied successfully on 9.2+ to use the older-style syntax |
| 08:54 |
Dyrcona |
gmcharlt: That works for me, if you think it is best. |
| 08:54 |
kmlussier |
Well, then test suite is already running twice a day, isn't it? |
| 08:55 |
Dyrcona |
kmlussier: Yes, I suppose it is. |
| 08:56 |
* gmcharlt |
claims 0970 |
| 08:57 |
|
jwoodard joined #evergreen |
| 17:48 |
jeffdavis |
dbs: I'm not sure whether to laugh or cry at that |
| 17:49 |
jeffdavis |
berick: cool, thank you |
| 18:05 |
|
Christineb joined #evergreen |
| 18:36 |
bshum |
Well, we're making some progress |
| 18:36 |
bshum |
http://testing.evergreen-ils.org/~live/test.24.html |
| 18:36 |
bshum |
Failed test because opt-in wasn't enabled in opensrf.xml |
| 18:36 |
bshum |
But the DB build works now |
| 18:43 |
kmlussier |
OK, all the Sandbox details have been emailed to our Bug Squashers. I'm calling it a night. G'night #evergreen! |
| 18:53 |
|
bmills joined #evergreen |
| 19:27 |
|
grabiel joined #evergreen |
