| 15:08 |
Dyrcona |
The Evergreen side would actually do that, but hey don't send values in the messages that actually work. |
| 15:09 |
rangi |
the RequestItem message? |
| 15:09 |
Dyrcona |
yeah. |
| 15:09 |
rangi |
oh yeah, values that don't work |
| 15:09 |
rangi |
that was 99% of the time testing was, "yeah, you aren't actually sending the correct data" |
| 15:10 |
rangi |
it's passing testing now, but I forget what we had to do to get it to work, I think we finally got them sending the correct barcodes |
| 15:11 |
Dyrcona |
We didn't have trouble with testing until they went to production. |
| 15:12 |
Dyrcona |
Well, a couple of little things. |
| 15:12 |
Dyrcona |
I wasn't sure from the code if the Koha side could place a hold for a local patron in the local ILS. |
| 15:13 |
Dyrcona |
Knowing one way or the other might help me decide if it is worth to figure out their messages to make that work with Evergreen. |
| 15:13 |
rangi |
yup, it does do that |
| 15:13 |
Dyrcona |
Thanks, bro'. :) |
| 15:13 |
rangi |
at least it was in testing, it may be broken in production, but I haven't heard that :) |
| 15:14 |
Dyrcona |
I'll bug them for some of the messages. |
| 15:14 |
Dyrcona |
What I've got has busted codes, so I can't rely on it. |
| 15:20 |
Dyrcona |
rangi++ # 'Cause he should get some karma here. |
| 16:23 |
Bmagic |
for small, medium, large, all complain about NOT FOUND |
| 16:23 |
jboyer-isl |
Maybe I was thinking of something else. :-/ Last thought: you're running this directly on your main memcache machine, yes? The same one pointed to by your app servers' apache configs? |
| 16:23 |
Bmagic |
I assume that means that there isn't anything in the cache. And therefore, when I load the Bib in the OPAC, evergreen should* query our content provider for lc.gif |
| 16:24 |
Bmagic |
yep, for sure, test machine |
| 16:24 |
jboyer-isl |
Huh. Well, I suppose to make sure in that case you can just cycle the service. :D |
| 16:26 |
Bmagic |
i did that too, I'm going to do it again and make sure. I grep the logs for lc.gif on the prod servers, and it's everywhere. Just not when I want it to! |
| 16:26 |
berick |
Bmagic: if it's hitting the added content provider, you'll see something like this in the logs: |
| 08:53 |
|
ericar_ joined #evergreen |
| 08:54 |
csharp |
so, general reports question... would people be interested in a "Classic Item List" and/or "Classic Circulation View" cleansed of PINES-specific fields like "Legacy Stat Cat 1" and such? |
| 08:54 |
mmorgan |
I don't see it on ours: http://catalog.noblenet.org |
| 08:54 |
csharp |
if so, I wouldn't mind creating a branch for testing that sort of thing |
| 08:57 |
csharp |
jeff: our stock 2.9 test server is showing the FOUC too: http://webby.gapines.org/eg/opac/home |
| 08:57 |
* Dyrcona |
missed something. |
| 08:57 |
csharp |
well, it did on first load - subsequent loads are fine |
| 08:57 |
csharp |
Dyrcona: 08:39 < jeff> hrm. haven't seen that before: i get a FOUC on a 2.9 catalog that i recently spun up. i wonder why. |
| 11:47 |
Dyrcona |
or is it delete()? Whatever it is. |
| 11:47 |
Dyrcona |
It happens because you have the workstation registered locally, but the registration doesn't exist in the datbase. |
| 11:54 |
berick |
kmlussier: well, this time last year? it must The Great Pumpkin's fault. |
| 11:55 |
kmlussier |
berick: You're right! We'll wait until the hack-a-way to resume testing in Firefox. :) |
| 11:55 |
berick |
wise |
| 11:55 |
kmlussier |
"This time last year" actually should be interpreted as "when we were testing sprtint 1." |
| 11:55 |
kmlussier |
I don't really remember when that was. It's all become one big blur to me. |
| 11:57 |
Dyrcona |
At some undetermined point in the past.... |
| 12:01 |
jeff |
dbs: regarding earlier: NOBLE's catalog would trigger FOUC only with NoScript in use because it has autofocus, but their WriteLibNameLink script normally "worked around" the autofocus FOUC. |
| 12:06 |
|
bmills joined #evergreen |
| 14:24 |
berick |
krvmga: k. can't really answer the question, then. restarting all services and apache is safest. |
| 14:25 |
krvmga |
berick: thanks. i was starting to think better safe than sorry. :) |
| 14:25 |
|
dMiller_ joined #evergreen |
| 14:26 |
dbwells |
berick: It was 3-4 weeks ago that I was testing this, so I'm not 100% sure what I was thinking, but I believe we'll let them happen naturally. Our non-LDAP accounts are almost entirely staff, so if things go terrible, we should at least have enough attention and control to get through it. |
| 14:27 |
dbwells |
In other words, adapting midstream at least won't have major PR implications. |
| 14:27 |
berick |
dbwells: that's good. sort of a soft launch. |
| 14:32 |
Dyrcona |
krvmga: you probably don't need to restart anything, maybe an apache reload. |
| 14:32 |
Dyrcona |
but better safe than sorry. |
| 15:10 |
berick |
#info berick = Bill Erickson, King County Lib. System |
| 15:10 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:10 |
miker |
#info miker = Mike Rylander, Equinox |
| 15:11 |
dbwells |
#topic Action Items from Last Meeting |
| 15:11 |
dbwells |
#info Dyrcona to update README/INSTALL for master to include web staff client installation instructions for developers by 2.9.0 release date. |
| 15:12 |
dbwells |
Dyrcona looks to be away, but pretty sure this got done. Anyone to confirm that? |
| 15:13 |
dbwells |
#info Status: probably done :) |
| 15:14 |
dbwells |
#info 2) dbwells will attempt to explode berick's Password Managment and Authentication improvements |
| 15:15 |
|
jlitrell joined #evergreen |
| 15:15 |
dbwells |
#info Status: Done. dbwells updated the bug earlier today to note that initial tests went well, and no intends to do some limited production testing. |
| 15:15 |
berick |
dbwells++ # again for good measure |
| 15:15 |
dbwells |
#info 3) gmcharlt to release OpenSRF version 2.4.2 on 8 September 2015. |
| 15:16 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 16:27 |
|
kitteh_ joined #evergreen |
| 16:30 |
dbs |
éwin 36 |
| 16:30 |
dbs |
fr_CA for the win |
| 16:35 |
Dyrcona |
Sorry that I missed the meeting. Had training and then intense NCIP testing that lead to the discovery of a bug in open-ils.circ.copy_transit.receive. |
| 16:36 |
kmlussier |
ugh |
| 16:36 |
kmlussier |
In the MARC editor in the current client, there is a keyboard shortuct to add a row and another keyboard shortcut to insert a row. They appear to do the same thing. Is there a difference? |
| 16:37 |
tsbere |
kmlussier: Do they do said "same thing" in the same place? |
| 14:20 |
krvmga |
bshum: interesting |
| 14:21 |
* kmlussier |
looks more closely |
| 14:22 |
krvmga |
krvmga wants more coffee. Coffee pot is done for the day. :( |
| 14:23 |
kmlussier |
krvmga: I added one here http://mlnc1.mvlcstaff.org/eg/opac/home but I don't know what might be available in the Concerto set with a uniform title to test it with. |
| 14:23 |
bshum |
Yeah, so... |
| 14:24 |
kmlussier |
But the resulting syntax on the search results page looks right. |
| 14:24 |
bshum |
Basic search is based off parts/searchbar.tt2 which pulls from qtype_selector.tt2 |
| 14:24 |
bshum |
Which seems to do coded_value stuff |
| 14:24 |
bshum |
So... different. |
| 14:24 |
bshum |
Hence, my question stands, which search are you working on? :) |
| 14:24 |
kmlussier |
OK, and the test I just did was for basic search. I assume the preference is that it show up in advanced. I hope. |
| 14:25 |
krvmga |
i added it to qtype_selector.tt2 and it shows up in both places |
| 14:25 |
krvmga |
{value => "uniform", label => l("Uniform Title")}, |
| 14:26 |
* bshum |
wonders if maybe it's deeper than he thought then |
| 14:57 |
miker |
krvmga: kmlussier's correct, and you can also use metabib.search_alias to give a specific field a name of its own without the class part. in fact, title|uniform can be spelled bib.titleuniform via alias already http://wiki.evergreen-ils.org/doku.php?id=documentation:technical:search_grammar |
| 14:58 |
kmlussier |
miker++ |
| 14:58 |
krvmga |
miker++ |
| 14:59 |
kmlussier |
miker: Thanks for confirming that. Do you have any thoughts on why it seems to be doing a title search when I tried it on a more recent master release? http://mlnc1.mvlcstaff.org/eg/opac/results?query=violin&qtype=title%7Cuniform&fi%3Asearch_format=&locg=1 |
| 14:59 |
kmlussier |
I don't know if there's a new bug there or if I did something wrong on the test server. |
| 15:01 |
miker |
kmlussier: hrm... I suspect that qtype is interpreted in EGCatLoader instead of simply used |
| 15:03 |
miker |
code suggests I'm wrong |
| 15:04 |
|
jwoodard joined #evergreen |
| 15:24 |
krvmga |
their marc:subfield is the same, just the datafield is different |
| 15:25 |
kmlussier |
krvmga: Yes. |
| 15:25 |
krvmga |
Yay! |
| 15:26 |
kmlussier |
To test it, change the xpath and then edit one record with a 264. After you save it, the publisher should show up in your publisher metabib entry for that record. |
| 15:28 |
jeff |
okay, looks like biblio.extract_metabib_field_entry does the "output a row containing a concatenated version of all the entries" for any field that is a search field. |
| 15:28 |
jeff |
and now i have deja vu. :P |
| 15:29 |
kmlussier |
bug 1251394 is what's needed for the titles to appear in proper capitalization in the web client, right? I should try loading that branch on the test server again. |
| 15:29 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" [Wishlist,Triaged] https://launchpad.net/bugs/1251394 |
| 15:30 |
Bmagic |
it's funny we are talking about xpath, because I have a question about it as well. "//mods32:mods/mods32:titleInfo[mods32:title and not (@type)]" is stock in our DB for "Title Proper" - It looks like it would include the 700t but it doesn't |
| 15:31 |
jeff |
Bmagic: what method are you using to look at the mods32 transform of your example records? |
| 15:35 |
kmlussier |
I'm feeling a sense of deja vu myself. Have you had this discussion before? |
| 15:36 |
Bmagic |
ah relateditem |
| 15:39 |
|
ericar_ joined #evergreen |
| 15:48 |
Bmagic |
jeff: what method are you using to test your mods32 query? |
| 15:53 |
Bmagic |
jeff: Your query does match the 700t but it also gets the 490a? |
| 16:09 |
|
Sessions1024 joined #evergreen |
| 16:27 |
|
jlitrell joined #evergreen |
| 16:46 |
|
mceraso joined #evergreen |
| 16:46 |
|
akilsdonk joined #evergreen |
| 16:50 |
kmlussier |
bshum: bts? I haven't seen that one in a long, long time. |
| 16:50 |
bshum |
kmlussier: I was just testing it. |
| 16:51 |
bshum |
kmlussier: It's still reserved and assigned to my IRC account. |
| 16:51 |
bshum |
But it seems someone else was trying to use it. |
| 16:51 |
|
rangi joined #evergreen |
| 16:51 |
|
rangi joined #evergreen |
| 16:52 |
kmlussier |
OK, I think I've done as much sprint 2 testing as I can handle in a day. |
| 16:58 |
Dyrcona |
jonadab: I has something similar with an in-house GUI application at a place where I used to work. |
| 16:58 |
Dyrcona |
There was no generic search library, so I had to open a window hidden, fill the values in, and then do a search. |
| 16:58 |
Dyrcona |
Worked fine on my brand-new 233 MHz Pentium II. |
| 09:37 |
Dyrcona |
pinesol_green went bye bye last night, just before I signed off. |
| 09:37 |
Dyrcona |
kmlussier: If you read yesterday's logs, you'll see me mentioning something in the afternoon that jeff commented on. |
| 09:38 |
Dyrcona |
kmlussier: It will explain why circulation is currently busted on my development vm. :) |
| 09:38 |
Dyrcona |
So, if you're trying to test anything there today, be warned.... |
| 09:40 |
Dyrcona |
I probably won't get around to fixing it until tomorrow. |
| 09:51 |
kmlussier |
Dyrcona: If I like at anything today, it will be cataloging in the web client, so I'm good. |
| 09:51 |
kmlussier |
Thanks! |
| 11:35 |
|
ericar joined #evergreen |
| 11:56 |
|
rlefaive joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:07 |
gmcharlt |
berick++ # testing stuff even before a pullrequest tag gets applied! |
| 12:09 |
berick |
gmcharlt: some code is hard to resist :) |
| 12:11 |
|
graced joined #evergreen |
| 12:15 |
|
b_bonner_ joined #evergreen |
| 16:01 |
Dyrcona |
I also have one remote, where the local is an empty git repo on my laptop, and the push is my development vm. |
| 16:02 |
Dyrcona |
That way, if dev is shut down and I fetch, I don't have to wait on it to timeout. |
| 16:02 |
jeff |
having the push and pull url for a given remote not point at "the same place" (i.e., point at two completely different instances of a repo) is cautioned against in the git documentation. :-) |
| 16:02 |
Dyrcona |
And, I can push to the remote to distribute the changes for testing. |
| 16:03 |
jeff |
But it's mostly a "you break it, you fix it" kind of thing. |
| 16:03 |
Dyrcona |
jeff: of course it is, 'cause it can get confusing if you don't pay attention. |
| 16:03 |
Dyrcona |
I like the local bare repo trick for pull and something on a vm for push to distribute changes, though. Very handy. |
| 10:50 |
kmlussier |
krvmga: No, I don't think it is. The bug report is unclear. |
| 10:50 |
Dyrcona |
No, I'm asking krvmga. |
| 10:50 |
krvmga |
maybe i should add a note to that bug |
| 10:50 |
kmlussier |
You're seeing the eresource result on the first screen. And that's consistent with what I found when I tested the bug. |
| 10:50 |
kmlussier |
But then, when you click into the results, that's where the e-resources aren't showing up. |
| 10:50 |
krvmga |
kmlussier: yes |
| 10:50 |
Dyrcona |
We find that e-resources on transcendant sources show up where you might not want them. |
| 10:50 |
kmlussier |
In your case, there is just one other record, so it's immediately jumping to that. So I think it's a spin on that bug. |
| 16:34 |
miker |
if I'm reading it right, of course |
| 16:36 |
miker |
if so, a facet_xpath should be able to grab just <title> and not <partNumber> |
| 16:36 |
miker |
(but, again, docs...) |
| 16:37 |
* jeff |
nods |
| 16:38 |
* jeff |
tests |
| 16:45 |
Stompro |
miker, our series titles are stored with 490[ind1=0], so that shouldn't be an issue. |
| 16:46 |
berick |
hmm, in all the discussion of negative balances, has there ever been any talk of avoiding a negative balance only when it's negative because of a forgive payment? |
| 16:46 |
miker |
if I'm, indeed, correct, you could set the facet_xpath to "//*[local-name()='title']" on the series title index definition, then. my tuits are lacking for testing, but give it a try? |
| 16:47 |
miker |
berick: specifically a money.forgive_payment row? I don't thinks so |
| 16:47 |
berick |
for example, if a patron returns a lost item they paid for, they get the money back. but, if a patron returns a lost item whose charge was forgiven, they don't |
| 16:47 |
berick |
miker: right |
| 16:47 |
kmlussier |
berick: We made a distintion between overdue balances and lost items. No talk of forgive fines in discussions I've been involved in. |
| 16:57 |
kmlussier |
There's this http://wiki.evergreen-ils.org/doku.php?id=scratchpad:negative_balances . But then I forgot that I wrote that, so I then did this several months later. http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases |
| 16:57 |
jeff |
kmlussier++ thanks |
| 16:58 |
jeff |
kmlussier: anything else, before you presumably start your weekend? |
| 16:58 |
kmlussier |
The latter is what remingtron referred to when adding some of the live tests with the code. |
| 16:58 |
kmlussier |
Weekend? What's that? |
| 16:58 |
kmlussier |
Nope. That's all. |
| 17:03 |
miker |
Stompro: reingest a record (save it in the marc editor) and search again with a cache killer (put "-sdflkklsdaklsdf" without quotes at the end of the search string) |
| 17:05 |
miker |
berick: entirely unrelated to your topic, we can't cause the webstaff to set is_staff in mod_perl today (and cause staff searches in the embedded opac) because it will force an oils: protocol. correct? |
| 17:07 |
miker |
well, and because it's currently done via an http header |
| 17:12 |
miker |
hrm... ok... thanks. seeing bugs where they don't be. pardon the noise |
| 17:14 |
miker |
and, yep. ye olde "no workstation" prob |
| 17:28 |
Stompro |
miker, no change after reingesting ~10 records and using the cache killer line. Thanks for the help though, I'll keep trying various things. |
| 17:29 |
miker |
np, thanks for testing |
| 17:34 |
|
bmills joined #evergreen |
| 18:06 |
|
Dyrcona joined #evergreen |
| 18:07 |
|
Dyrcona left #evergreen |
| 14:33 |
yboston |
Stompro++ |
| 14:33 |
yboston |
jihpringle: works for me |
| 14:34 |
yboston |
#action jihpringle will send out an email to the list to ask DIG memebers to sign up for pending 2.9 new featutres |
| 14:34 |
* kmlussier |
should start documenting new features while she's testing them. |
| 14:35 |
yboston |
remingtron: about deciding if a new feature/release not entries needs docs. maybe we can team up to make that assesment together? |
| 14:35 |
yboston |
remingtron: so we can save volunteer time? |
| 14:35 |
remingtron |
yboston: yes, I can help with that |
| 14:36 |
yboston |
cool |
| 14:36 |
yboston |
#action yboston & remingtron will asses which 2.9 new features do not require new documentation |
| 14:37 |
yboston |
I'll send you an email |
| 14:37 |
Stompro |
If anyone wants to test out the adding adoc to the release notes commit, that would be appreciated. LP 1482336 |
| 14:37 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
| 14:38 |
yboston |
#action yboston will test and sign-off on Launchpad bug 1482336 - allowing release notes with ".adoc" suffix |
| 14:38 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
| 14:38 |
yboston |
anything else on 2.9 new features? |
| 14:39 |
remingtron |
regarding the .adoc conversion testing, I think we found a reason to halt |
| 14:39 |
yboston |
the git history concern? |
| 14:40 |
remingtron |
yes, git can track history across file name changes, but only if you use an additional command line parameter |
| 14:41 |
yboston |
remingtron: darn, I thought it would do it automatically |
| 14:42 |
yboston |
what is the parameter? |
| 14:42 |
remingtron |
Stompro: yes, I think we should encourage using .adoc for new files |
| 14:43 |
remingtron |
yboston: the parameter is --follow, like 'git log --follow' |
| 14:43 |
yboston |
have we tested that Robert's ascidoc parsing code can handle it? |
| 14:44 |
yboston |
remingtron: had no idea, but I am no git expert. all tutorial made it sound that renaming would "just work" if I used "git mv" |
| 14:44 |
remingtron |
yboston: I guess it works from some perspectives, but not the git log view |
| 14:44 |
Stompro |
yboston, when something gets included from the root.txt I don't think the parser knows what the file extension was, so it shouldn't matter. |
| 14:45 |
remingtron |
yboston: yes, the official docs already include an .adoc file |
| 14:52 |
yboston |
the good news/bad news of all the new content that we pushed probably broke something in the PDF build |
| 14:53 |
yboston |
I will set a generic action item to have folks look into it |
| 14:53 |
remingtron |
hm, guess we should email Robert to ask what errors he's seeing |
| 14:53 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script and test file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9298b2> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 libdbi DATE types translated via gmtime - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c42d4c> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date PGTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174b43> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 Store date of birth as SQL DATE type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7159229> |
| 14:54 |
yboston |
#action need volunteers to see why the 2.9 and the master/dev PDF is not being built |
| 14:54 |
yboston |
#action yboston will send Robert an email to check on problems with 2.9 and master PDF |
| 14:56 |
yboston |
I need to attend a meeting at 3 PM EST |
| 14:56 |
yboston |
final thoughts or questions? |
| 14:56 |
jihpringle |
is it just the MassLNC demo server running on 2.9? (I want to include a link in the email to where people can test features to document if they don't have their own 2.9 server) |
| 14:56 |
kmlussier |
Do we know when it stopped building? |
| 14:56 |
remingtron |
kmlussier: not sure we have that info besides Robert |
| 14:56 |
kmlussier |
Yes. The MassLNC demo server is running 2.9 and the ESI server is running 2.8. We coordinated this time around so that we would have the two stable releases on demo servers. |
| 10:28 |
pinesol_green |
RoganH: But RoganH already hates acquisitions! |
| 10:29 |
RoganH |
@hate acquisitions_with_a_pervasive_enduring_hatred |
| 10:29 |
pinesol_green |
RoganH: The operation succeeded. RoganH hates acquisitions_with_a_pervasive_enduring_hatred. |
| 10:44 |
csharp |
is anyone on 2.9-ish able to test if Offline Transaction Management is busted for them as well? |
| 10:44 |
csharp |
in my case, I enter the interface and get a skull and crossbones error |
| 10:45 |
csharp |
http://pastebin.com/YUtuEBGj |
| 10:46 |
phasefx |
csharp: check your offline-config.pl file? |
| 10:46 |
csharp |
lemme look |
| 10:47 |
csharp |
phasefx: it looks right to me |
| 15:42 |
tsbere |
The more broken I expect things to be without it the more likely I am to want it to finish first |
| 15:42 |
* csharp |
has not investigated why we need a reingest for 2.8 |
| 15:43 |
jeff |
i believe we've gone 'live' post-upgrade with a partial (just what MUST be reingested) while the full runs in the background. the ability to do this may vary between what you're upgrading from/to, but with the newer support for selective/partial reingest will likely help there. |
| 15:43 |
csharp |
our test server is currently in an "upgraded from 2.7 to 2.9 but not yet reingested" state and I'm asking our staff to experiment with searching |
| 15:43 |
csharp |
pretty sure it's just a partial reingest that's required |
| 15:46 |
csharp |
actually it's 2.7.2-2.7.3 that requires the reingest |
| 15:48 |
csharp |
apparently 0904.schema.allow_spaces_as_ff_attr_values.sql |
| 15:49 |
csharp |
bug 1414112 |
| 15:49 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" [Medium,Fix released] https://launchpad.net/bugs/1414112 |
| 15:54 |
csharp |
hmm - miker's comments on the bug report make it seem that a reingest is not required... |
| 15:54 |
csharp |
gmcharlt: any thoughts on this?^^ |
| 08:08 |
|
ericar joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:49 |
jeff |
thought exercise for the day: anonymizing live data for testing purposes. |
| 08:53 |
|
Shae joined #evergreen |
| 08:54 |
Dyrcona |
jeff: Fill names and addresses with pseudo-random noise. |
| 08:54 |
Dyrcona |
Ditto if you have ID fields and phone numbers. |
| 08:54 |
Dyrcona |
Email addresses, too.... |
| 08:54 |
Dyrcona |
Hmm.. Sounds like it could be a big project. |
| 08:58 |
tsbere |
jeff: I had some code for that at one point when I had to do something like that for MassLNC testing |
| 08:58 |
tsbere |
I can check the masslnc server to see if I left a copy sitting there? |
| 08:59 |
|
ericar_ joined #evergreen |
| 09:03 |
jeff |
tsbere: sure, i'd be interested. |
| 09:04 |
jeff |
i'm also trying to keep in mind some of the issues around such things, especially https://en.wikipedia.org/wiki/AOL_search_data_leak |
| 10:01 |
Dyrcona |
jeff: It was used to anonymize patron data during the performance evaluation done by OmniTI. |
| 10:02 |
Dyrcona |
We used actual data from C/W MARS. |
| 10:03 |
jeff |
Got it. That was one of the possibilities that came to mind, but I figured best to ask. |
| 10:05 |
kmlussier |
My use case now is similar. There are times I want to use production data for testing, but, since we work with multiple partners, I prefer to do it with anonymized data. |
| 10:08 |
|
rjackson_isl joined #evergreen |
| 10:19 |
|
dbwells joined #evergreen |
| 10:25 |
|
ericar_ joined #evergreen |
| 11:05 |
remingtron |
both sections have comments about optional steps during an upgrade |
| 11:07 |
kmlussier |
remingtron: Seems reasonable to me. Thanks! |
| 11:08 |
remingtron |
kmlussier: thanks for the feedback |
| 11:42 |
csharp |
jeff: I was just pondering test data anonymization myself - I don't have anything to offer other than "me too", though ;-) |
| 11:50 |
dbs |
remingtron: "If you were still using the JSPAC... Why? WHY?!?!" |
| 11:51 |
csharp |
pinesol_green: WHY?? |
| 11:51 |
pinesol_green |
csharp: have you tried local mean solar time for the named city as the reference point? |
| 16:06 |
yboston |
Dyrcona: Stompro put in a patch, but I think it needs a signoff |
| 16:06 |
kmlussier |
Dyrcona: Yeah, in this case I'm not doing a release notes entry |
| 16:08 |
kmlussier |
28e9f061 |
| 16:08 |
yboston |
kmlussier: I thought that remingtron might still need to do some testing |
| 16:08 |
kmlussier |
That never works for me. |
| 16:08 |
Stompro |
kmlussier, if you are adding something new, I would go with adoc format. We were waiting on figuring out if it is possible to move all the .txt to .adoc without totally screwing up the git history, or making it hard to use. |
| 16:08 |
kmlussier |
Stompro: OK, will do |
| 01:37 |
|
Mark__T joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 09:22 |
kmlussier |
I know the page you're talking about. It is indeed very difficult to find. |
| 09:23 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=website_administration |
| 09:23 |
remingtron |
yeah, I just searched for Chris Sharp and found that page too |
| 09:25 |
kmlussier |
I guess I see the release notes acknowledgements as a way to thank the people/organizations responsible for contributing the code, docs, tests that made a release happen. We could expand upon it, but there may be better places where we can acknowledge other contributions to the community. |
| 09:26 |
remingtron |
kmlussier: on the main website? |
| 09:26 |
kmlussier |
Yes, that seems appropriate. Because they are ongoing contributions. |
| 09:26 |
remingtron |
I agree, ongoing contributions are different than version contributions |
| 12:39 |
bshum |
Disagree? |
| 12:39 |
Bmagic |
or agree |
| 12:41 |
Bmagic |
I think that the issue is the link actually. It should reference "id" instead of "source" |
| 12:50 |
Dyrcona |
csharp: I am installing 2.8.4 so I can test the upgrade script for 2.8.4 to 2.9.0. |
| 12:55 |
mmorgan |
Bmagic: Disclaimer, I don't pretend to have a deep understanding of the idl, but the id field has datatype "id", not "link" so it's not referring to that link field. |
| 12:56 |
Bmagic |
mmorgan: compare to metabib::record_attr |
| 12:56 |
Dyrcona |
Well, it should most likely be a link to bre.id. Does that appear in the list of links? |
| 13:45 |
Dyrcona |
It works for me. I'm going to post a branch based on rel_2_9. |
| 13:46 |
Dyrcona |
You check it out and just try the 2.8.4 to 2.9.0 upgrade script, or you can go through the whole install process from git if you like. |
| 13:52 |
Dyrcona |
csharp: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1497307_fix_upgrade_script |
| 14:27 |
csharp |
Dyrcona: excellent! I'll test |
| 14:27 |
Dyrcona |
csharp++ |
| 14:33 |
csharp |
so far so good - I'm at the authority update, which will take a while |
| 14:33 |
csharp |
I'll update the bug with a signoff unless I hit anything |
| 15:38 |
Dyrcona |
I'll send an email to the general list to let anyone know who has already downloaded it that they should download it again. |
| 15:38 |
csharp |
excellent |
| 15:44 |
kmlussier |
Stompro: Glad you got it to work the way you wanted! |
| 15:52 |
* csharp |
experiments with parallel pg_dump |
| 15:53 |
csharp |
on a test server with SSDs and 64 processor cores (using 48) - this should speed up a couple of upgrade steps ;-) |
| 15:56 |
* jlitrell |
sighs wistfully |
| 16:03 |
Bmagic |
I might have found a bug, would someone confirm. Using the staff client, replacing a barcode using this method: Edit Menu -> Replace barcode. It's resulting in a new item instead of replacing the barcode of the old item. Seems to be new in 2.8+ |
| 16:05 |
* jeffdavis |
submits a feature request entitled "Require all SQL generated by the reporter to be reviewed and approved by a knowledgeable human before being run" |
| 16:13 |
jboyer-isl |
That’s the first I’ve heard of it. Almost like an in-line version of the audit tables (but I assume with a different feature set in mind, long, long ago) |
| 16:14 |
Dyrcona |
Probably. |
| 16:14 |
berick |
apt metaphor. a MARC record eats its owner, its owner goes on to provide power for the MARC record, which would have otherwise died out. |
| 16:14 |
kmlussier |
Bmagic: I tested it on master too and had the same results as mmorgan. |
| 16:14 |
jboyer-isl |
berick++ |
| 16:14 |
Bmagic |
weird |
| 16:15 |
kmlussier |
mmorgan: The sound was a little unexpected, wasn't it? |
| 16:16 |
mmorgan |
Maybe it's the old barcode saying: Noooooo! as it goes poof. |
| 16:16 |
mmorgan |
Actually, we have not replaced it. |
| 16:17 |
mmorgan |
I wonder if our users would miss it if we replaced it now. I think we still have folks that pine for the turtle. |
| 16:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
bmills1 joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 20:31 |
gmcharlt |
doing maintenance on evergreen-ils.org |
| 23:40 |
|
serflog joined #evergreen |
| 23:40 |
|
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 |
| 23:44 |
gmcharlt |
testing |
| 23:48 |
gmcharlt |
ok, all done - everything should be up and running again (with the exception of piwik tracking, which I've mostly disabled) and running Wheezy |
| 23:49 |
csharp |
gmcharlt++ |
| 23:49 |
gmcharlt |
another O/S upgrade is in store some time next week |
| 04:13 |
|
mnsri_ joined #evergreen |
| 05:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:14 |
|
sarabee joined #evergreen |
| 07:31 |
|
graced joined #evergreen |
| 07:39 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
ericar joined #evergreen |
| 07:46 |
|
collum joined #evergreen |
| 08:12 |
miker |
so, that test failure is due to a postgres bug fix which, by the way, we desperately want: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=79af9a1d2668c9edc8171f03c39e7fed571eeb98 |
| 08:12 |
miker |
I'll adjust the test to match modern PG, because everyone should upgrade to the most recent minor version in any case :) |
| 08:25 |
dbwells |
miker: Thanks for the commit link, I've been wondering about the history behind the change. Do you think it's going to cause problems for some of our uses? It seems like in some cases we actually just want an XML fragment, since we're going to insert into another record or whatnot. |
| 08:25 |
miker |
no, the fix is going to allow us to simplify all /sorts/ of xpath-using code |
| 08:27 |
dbwells |
Ah, I wasn't really thinking that direction. There are a bunch of places where we have to dance around not having a proper namespace. |
| 08:32 |
miker |
I look at it like this: it's just space, which is cheap ... and, while I've certainly been known to do it, and it's currently much faster, munging xml via regex is still wrong and shameful |
| 08:33 |
dbwells |
but it's so fast! ;) |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:35 |
miker |
Dyrcona: sorry to pounce immediately, but I have a fix for the test failure, and as RM[aintainer] I'll just ask you: shall I wait for launchpad to load, create a bug, push a branch, and update the bug, or just push the test fix to master? :) |
| 08:36 |
Dyrcona |
That's what has typically been done with test fixes so far, so I'd say yes. |
| 08:36 |
miker |
you mean push to master? |
| 08:36 |
Dyrcona |
No, I mean create a bug on launchpad, etc. |
| 08:37 |
miker |
k |
| 08:38 |
dbwells |
miker: I'm happy to sign off based on what I already know about the situation, so the bug report can be pretty "lite" :) |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
dbwells |
Maybe a small consolation. |
| 08:40 |
Dyrcona |
Well, I don't think we need much for fixing tests. Something like "test [blah] is broken, this should fix it." |
| 08:41 |
|
maryj joined #evergreen |
| 08:43 |
miker |
dbwells: bug 1496837 at ya', and thanks! |
| 08:43 |
pinesol_green |
Launchpad bug 1496837 in Evergreen "xml-related test is invalid" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1496837 |
| 08:45 |
|
mrpeters joined #evergreen |
| 08:47 |
pinesol_green |
[evergreen|Mike Rylander] LP#1496837: Postgres fixed a bug and broke our test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b06b541> |
| 08:47 |
dbwells |
dang, forgot the -s to sign-off. |
| 08:58 |
|
rjackson_isl joined #evergreen |
| 09:08 |
miker |
dbwells++ |
| 14:04 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
| 14:04 |
bshum |
I'll keep us going for now then. |
| 14:04 |
sherbertbc_ |
having connection problems, sorry |
| 14:04 |
bshum |
#topic Minutes/actions from last meeting - http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-07-16-14.00.html |
| 14:05 |
bshum |
1) tspindler will announce a test meeting in the next 2 months to |
| 14:05 |
bshum |
use our GoToWebinar so we can test it and invite other members of the |
| 14:05 |
bshum |
Evergreen community to join if they want. |
| 14:05 |
bshum |
tspindler++ for putting that together |
| 14:05 |
bshum |
And thanks to all of you who participated |
| 14:05 |
rfrasur |
What was the verdict? |
| 14:05 |
bshum |
#info tspindler to test GoToWebinar with other EOB members |
| 14:06 |
bshum |
#info tspindler's results: http://list.evergreen-ils.org/pipermail/eg-oversight-board/2015-September/001114.html |
| 14:06 |
tspindler |
I think it worked well over all. Gives us some different options if you want to use it |
| 14:06 |
yboston |
I thought it worked well. Might want to test it with more people at once to be safe |
| 14:06 |
montgoc1 |
I agree. Seemed like it would be fine. |
| 14:07 |
yboston |
I bet it would be fine |
| 14:07 |
abneiman |
I'm on record before but I like the audio convo better than IRC, I'm more comfortable speaking extemporaneously than typing. Agree on testing with more members. |
| 14:07 |
rfrasur |
And, was the idea that it supports voice and it's recordable? |
| 14:07 |
tspindler |
rfrasur: yes |
| 14:08 |
* rfrasur |
is just restating for the log. |
| 14:12 |
rfrasur |
Let's shoot for October if all are amenable. |
| 14:12 |
montgoc1 |
Sure. |
| 14:13 |
sherbertbc_ |
I'm n/a Oct 15, our annual all staff, but go ahead w/o me! |
| 14:13 |
bshum |
tspindler: Along the way, for those of us who weren't part of the original trial (me, for example, I'm such a slacker), I wonder if we could ask you to help set up another test in between now and then. |
| 14:13 |
abneiman |
10/15 should be OK with me |
| 14:13 |
yboston |
that date works for me |
| 14:13 |
bshum |
And we can do a dry run so to speak of the board procedures. |
| 14:14 |
tspindler |
bshum: i think i could squeeze a date in, I may just have to schedule it and hope it works |
| 14:14 |
rfrasur |
+1 |
| 14:14 |
bshum |
tspindler: That'd be fine, and I will hopefully find myself available this time around. |
| 14:14 |
tspindler |
how is the week of October 5 for a test run? |
| 14:15 |
bshum |
tspindler: Depends on the day of the week for me. |
| 14:15 |
rfrasur |
That Monday, Thursday, or Friday are fine. |
| 14:15 |
tspindler |
I could set up for Thursday, October 8 at 2PM EST if that works for a test for anyone |
| 14:15 |
bshum |
Thursday or Friday afternoon work for me |
| 14:15 |
bshum |
I think there's an academics meeting on that Thursday |
| 14:15 |
sherbertbc_ |
Mon or Fri |
| 14:18 |
tspindler |
rfrasur: +1 |
| 14:18 |
montgoc1 |
rfrasur: +1 |
| 14:18 |
|
maryj joined #evergreen |
| 14:19 |
bshum |
#info Pre-meeting practice for GoToWebinar to occur at 1:30 pm Eastern on October 15 prior to the regular EOB meeting. |
| 14:19 |
bshum |
Cool deal, thanks all, and hopefully we get some good feedback on how that next meeting's test goes via audio. |
| 14:19 |
bshum |
Anything further on that for now? |
| 14:19 |
rfrasur |
And tspindler, you send out the join link? |
| 14:19 |
tspindler |
rfrasur: yes, I'll do that |
| 14:19 |
rfrasur |
tspindler++ |
| 16:24 |
miker |
or not |
| 16:24 |
miker |
bshum++ # thanks |
| 16:25 |
|
jlitrell joined #evergreen |
| 16:44 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:45 |
kmlussier |
Huzzah! |
| 16:55 |
phasefx |
yay |
| 16:57 |
phasefx |
those unrecognized value "" for "ECHO"; assuming "none" warnings are also relatively new, and introduced with a change in psql |
| 11:28 |
jeff |
kmlussier: it's my understanding that currently it's frowned upon to push to master around/near release time without coordination with the RM. i could be wrong. |
| 11:28 |
bshum |
jeff: Huh? |
| 11:29 |
bshum |
Oh hmm.... |
| 11:29 |
kmlussier |
jeff: Ah, ok. But if it were another say, say next week, miker could just push those changes to master since he's reviewed and tested them, couldn't he? |
| 11:29 |
kmlussier |
Apologies for garbling that sentence, but y'all know what I mean. |
| 11:29 |
miker |
also, they haven't been pushed to webby for broader testing yet |
| 11:34 |
miker |
if 2.9 is cut later than today (but don't delay for those minor fixes alone, please!) then broader testing will be applied, and I will push them to master for good and all |
| 11:42 |
kmlussier |
dbwells / Dyrcona: I've been waiting to hear back from one other person to get a sense of how often the void option in Full Details is used. And it may be too late to give feedback if Dyrcona has already started release cutting. |
| 11:43 |
kmlussier |
dbwells / Dyrcona: My personal opinion right now is, to truly prohibit negative balances we we had hope to do, we will need to remove that void permission from our users. And when we remove that void permission, they will lose the ability to do something they previously could do. It's a regression. |
| 11:44 |
kmlussier |
My preference is that they don't lose any functionality when the .0 release is out. But I leave it in the hands of our fearless RM to make the final decision. |
| 12:37 |
miker |
if you don't use circ_mod much in other rules, that might do it |
| 12:38 |
dbs |
bshum: should make things a lot easier for people who want to tailor templates without worrying about breaking the embedded metadata, so would be worth it I think |
| 12:39 |
Bmagic |
miker: right now, we have about a 50/50 split of rules that mention circ mod and those that dont |
| 12:40 |
miker |
Bmagic: if the rule in question is the only one using that particular circ_mod, it still might be OK |
| 12:40 |
miker |
testing would tell, obv |
| 12:41 |
Bmagic |
right on |
| 12:42 |
Bmagic |
it would be neat if there was a mechanizm for "pickup library is NOT x" |
| 12:43 |
Dyrcona |
miker gmcharlt: I'm in favor of web staff client fixes being treated like normal bugs and have considered saying it would be OK to backport them to rel_2_9 once it is branched. |
| 12:55 |
miker |
I can be in a position soon ... in, say, 15min |
| 12:55 |
Dyrcona |
OK. I can wait. |
| 12:55 |
Dyrcona |
I'd prefer to have as much as possible in master before branching. |
| 12:56 |
miker |
Dyrcona: and, to be clear, I'd like to push the top 6 commits of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/sprint2-fixes ... the first 4 are from this morning, the next 2 are fixes that are widely tested |
| 12:57 |
Dyrcona |
OK. That works for me. |
| 12:58 |
miker |
where "widely" means "by more than the author, and don't break webby" |
| 12:59 |
Dyrcona |
:) |
| 12:59 |
Dyrcona |
Should I use Chrome when testing the web staff client? |
| 12:59 |
Dyrcona |
Or, do you want it to work with Firefox, too? |
| 13:00 |
miker |
both ideally, but chrome is moar better in general |
| 13:00 |
Dyrcona |
Thanks! That is what I thought. |
| 14:13 |
bshum |
Does anyone remember offhand what a hold status of -1 means? I know it's indicative of some sort of error failure, I just don't recall the exact nature of it. |
| 14:14 |
Dyrcona |
The hold is in an invalid state. |
| 14:14 |
Bmagic |
bshum: I had this question a few weeks ago...... now I forget what the answer was, lol. Apparently it was important. Let me look back |
| 14:14 |
jeff |
only displayed in the staff client, it's "something isn't what i expect" |
| 14:15 |
jeff |
it's set to "-1" at display time as a fall-through after several conditional tests. |
| 14:15 |
Dyrcona |
Typically happens when some field has or is missing a value that it shouldn't because of other values in the hold request. |
| 14:15 |
berick |
usually a mismatch between copy status and hold disposition |
| 14:22 |
bshum |
Okay, 2.7.8 is all set. But I'll wait to update the downloads page for now. |
| 14:43 |
kmlussier |
Dyrcona: I do have some changes I need to make to the 2.9 release notes. I think I'm done with the neg balance additions from today's branch, but I also need to add acknoledgements. I'll remove those bug fix release note entries at that time. |
| 14:43 |
Dyrcona |
OK. Works for me. |
| 14:44 |
* kmlussier |
will first grab the tea that is probably getting cold by now. :) |
| 14:51 |
jeffdavis |
dbwells: I was finally able to apply your fix for bug 1484989 on a test server. After applying the commit, lost transactions are being closed when the item is checked in and the fine balance hits zero, which is what we want. |
| 14:51 |
pinesol_green |
Launchpad bug 1484989 in Evergreen 2.8 "Fines are not calculating until after circulation is closed" (affected: 1, heat: 6) [Medium,Fix committed] https://launchpad.net/bugs/1484989 |
| 14:51 |
jeffdavis |
dbwells: However, that behavior still does not seem to be governed by the circ.lost.xact_open_on_zero setting, which is what we expected (i.e. the circs are closed even when that setting is true). |
| 14:52 |
jeffdavis |
I haven't replicated our original problem on a stock 2.8 install though. |
| 16:03 |
Bmagic |
yep |
| 16:03 |
pinesol_green |
[evergreen|Kathy Lussier] Additions to the 2.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c06390> |
| 16:03 |
Bmagic |
I reloaded the patron in a new tab just to make sure |
| 16:04 |
kmlussier |
Release note changes are pushed. One change I made to the acknowlegements is that we are thanking people for contributions to tests as well as code and doc patches. |
| 16:04 |
Bmagic |
I tested it on a non-lost circ, and it did increase the count |
| 16:04 |
Dyrcona |
kmlussier++ |
| 16:04 |
Bmagic |
kmlussier++ |
| 16:04 |
mmorgan |
kmlussier++ |
| 16:43 |
kmlussier |
As usual, when working on acknowledgements, it was great to see all the different types of organizations big and small that went into making this Evergreen release. A big y'all++ |
| 16:43 |
kmlussier |
And an even bigger Dyrcona++ |
| 17:08 |
|
mmorgan left #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Update and add detail for Holdings Import profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=584dfb9> |
| 17:46 |
pinesol_green |
[evergreen|Jason Stephenson] Porting 2.8.4->2.9.0 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69bb3ce> |
| 17:48 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.0 translations. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d40524> |
| 18:13 |
Dyrcona |
Well, I hope that's that. |
| 18:16 |
pinesol_green |
[evergreen|Jason Stephenson] 2.9 Release notes creation and cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d10f91> |
| 18:26 |
kmlussier |
Dyrcona++ |
| 23:14 |
bshum |
Well, maybe. |
| 23:15 |
kmlussier |
bshum++ |
| 23:16 |
bshum |
"And now his watch is ended." (almost, almost....) |
| 23:27 |
jeff |
what's the bar for "commissioned developments"? |
| 23:27 |
jeff |
oh, and is there a better method for me to help fix this typo than just mentioning it here? "individuals who contributed code, documentations patche and tests to this release" :-) |
| 23:27 |
jeff |
(first question is just one of curiosity, not thinking that there was an omission or anything) |
| 23:28 |
kmlussier |
jeff: Organizations that contracted for development work that made it into the release. |
| 23:29 |
kmlussier |
In the case of this release, we have organizations that paid for development through Equinox, Sigio, and Catalyst. |
| 23:30 |
bshum |
I think it covers the base of funding partners who don't get their names/organizations represented with the actual authoring/testing/signoff/committing. |
| 23:30 |
kmlussier |
Basically, it's a way to give credit to organizations that may not have the development staff to contribute code, but made one of the features happen through funding. |
| 23:33 |
kmlussier |
bshum: Did you already update the release notes with my feature? If not, can you fix my typo? |
| 23:33 |
bshum |
kmlussier: Already updated, but we can do another one... |
