| Time |
Nick |
Message |
| 01:34 |
|
gsams joined #evergreen |
| 05:07 |
|
chatley joined #evergreen |
| 05:48 |
csharp |
@later tell gsams when our libraries tell us that transactions take 5, 10, or 15 minutes, it's always something on their end related to workstation duress or network congestion, FYI. You can verify how long things are taking on the server side and show that to your end-user staff for proof. |
| 05:48 |
pinesol_green |
csharp: The operation succeeded. |
| 06:14 |
csharp |
@blame reports |
| 06:14 |
pinesol_green |
csharp: reports 's bugfix broke csharp's feature! |
| 06:14 |
|
remingtron_ joined #evergreen |
| 07:13 |
|
wsmoak joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 08:18 |
|
ericar joined #evergreen |
| 08:21 |
|
mrpeters joined #evergreen |
| 08:22 |
|
rjackson-isl joined #evergreen |
| 08:27 |
|
akilsdonk joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:50 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
tspindler joined #evergreen |
| 09:19 |
mmorgan |
csharp: How do you go about verifying how long transactions are taking on the server side? From logs? |
| 09:27 |
csharp |
mmorgan: yep - you have to get the threadtrace from the activity log, then grep for that in osrsys logs (this assumes your system is set up to use syslog and uses the rsyslog config at http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/examples/evergreen-rsyslog.conf;h=ba25cea727c4aadead5635197f86040392c5ecf2;hb=HEAD) |
| 09:29 |
csharp |
example log line: |
| 09:29 |
csharp |
2014-11-07 09:28:48 brick02-head osrf_json_gw: [ACT:17179:./osrf_json_gateway.c:323:14153703101717933] [216.130.129.70] [auth token redacted] [en-US] open-ils.circ open-ils.circ.checkin "auth token redacted", {"barcode":"31022007414326","backdate":"2014-11-06T00:00:00-05:00"} |
| 09:30 |
csharp |
(from activity.log) the threadtrace is 14153703101717933 - you can then grep for that in the osrfsys.HH.log for that hour |
| 09:31 |
mmorgan |
ok, gotcha so far |
| 09:32 |
mmorgan |
So the actual time the transaction takes, is that the "Message processing duration.."? |
| 09:32 |
mmorgan |
looks like a lot of those for the same threadtrace. |
| 09:35 |
csharp |
yeah - there's a duration for each individual opensrf message |
| 09:36 |
mmorgan |
ok, so the actual time of the transaction is the difference between the first and last timestamp for the threadtrace? |
| 09:36 |
csharp |
also, it depends on your loglevel (set in opensrf_core.xml) as to whether you get duration for full "transactions" (for lack of a better term to describe something like a checkin) |
| 09:36 |
csharp |
yes |
| 09:37 |
csharp |
if you up one of the loglevel values to debug (4), you get more information |
| 09:37 |
csharp |
but also far larger log files, so it's a tradeoff |
| 09:39 |
csharp |
I think it's the private opensrf loglevel that you'd need to increase - we do that on test servers, but not production |
| 09:40 |
|
yboston joined #evergreen |
| 09:41 |
mmorgan |
ok thanks. This is all really helpful. I spend a fair amount of time poking through logs, nice to understand them a little better. |
| 09:41 |
mmorgan |
csharp++ |
| 09:44 |
csharp |
mmorgan: happy to help! I've been meaning to put together a presentation for an EG conf on stuff like this, but I'm always afraid it will reveal more what I *don't* know ;-) |
| 09:45 |
csharp |
I'm kicking around an idea for a sys admin full- or half-day training as a preconf on the "hackfest" day |
| 09:46 |
mmorgan |
csharp: Both awesome ideas! |
| 09:46 |
csharp |
getting people like Callender and bshum and mtate to talk about sys admin best practices, logs, Linux, etc. |
| 09:47 |
csharp |
monitoring... that kind of thing |
| 09:48 |
mmorgan |
unless I've missed it (which is entirely possible) there doesn't seem to be much reference info for novices for reading logs and day to day sysadmin type stuff, so that type of session would be great |
| 09:55 |
Dyrcona |
csharp: pingest.pl is going to get some major work done on it this morning. |
| 09:56 |
Dyrcona |
csharp: I am going to add options to skip the browse ingest, the metabib field ingest, and the record attribute ingest. I'll probably add options to override the constants for batch size and max children. |
| 10:11 |
bshum |
Sigh, I hate that I always forget to install ntp to keep things better sync'd on our servers for time :( |
| 10:13 |
|
kmlussier joined #evergreen |
| 10:27 |
kmlussier |
ie-- |
| 10:27 |
kmlussier |
@karma ie |
| 10:27 |
pinesol_green |
kmlussier: Karma for "ie" has been increased 0 times and decreased 61 times for a total karma of -61. |
| 10:39 |
jeff |
bshum: nagios checks for ntp are handy there. |
| 10:43 |
bshum |
jeff: I'll add it to my list of things to build into my monitoring server |
| 10:43 |
bshum |
When I build it later :) |
| 10:44 |
csharp |
jeff: great idea |
| 10:45 |
csharp |
Dyrcona: awesome! I'm using yesterday's version on a test server now |
| 10:46 |
|
RoganH joined #evergreen |
| 10:48 |
|
kmlussier joined #evergreen |
| 10:51 |
Dyrcona |
csharp: cool. I'm testing the command line options to skip browse, search and facet reingest and just do the record attributes, now. |
| 10:51 |
* csharp |
signs off on the fix for bug 1390225 |
| 10:51 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225 |
| 10:51 |
csharp |
Dyrcona: rock on |
| 10:54 |
|
rfrasur joined #evergreen |
| 10:54 |
rfrasur |
@karma parts |
| 10:54 |
pinesol_green |
rfrasur: Karma for "parts" has been increased 26 times and decreased 26 times for a total karma of 0. |
| 10:54 |
csharp |
hahaha |
| 10:55 |
rfrasur |
:D, mornin' |
| 10:55 |
csharp |
@who will bring the Force back into balance? |
| 10:55 |
pinesol_green |
RBecker will bring the Force back into balance. |
| 10:56 |
rfrasur |
RBecker is idle. Muahahahahah! |
| 10:57 |
* rfrasur |
accepts ceasefire for today. |
| 10:57 |
rfrasur |
Just ridin' the wall. |
| 11:01 |
kmlussier |
rfrasur: If you have the urge to send negative karma somewhere, you can always give it to IE. We can agree on that, right? :) |
| 11:01 |
rfrasur |
We can. We definitely can. |
| 11:01 |
rfrasur |
I'd like to do more than send negative karma to IE. |
| 11:02 |
rfrasur |
I'd like to deface its monuments and strike it from the annals of history. |
| 11:02 |
rfrasur |
Can we do that in here? |
| 11:02 |
* kmlussier |
was stuck on a computer that only had IE for 15 minutes this morning. |
| 11:02 |
kmlussier |
rfrasur: Absolutely! |
| 11:02 |
rfrasur |
Ugh. My has it off to you. I wouldn't have made it 15 minutes. |
| 11:03 |
rfrasur |
yeah. s/has/hat |
| 11:03 |
|
Shae joined #evergreen |
| 11:09 |
|
buzzy joined #evergreen |
| 11:18 |
Stompro |
bshum: Bug 1390138 - I had no trouble upgrading from 2.6.3 to 2.7.1 using the upgrade docs I edited. Now I'm just trying to figure out the client auto update stuff. I noticed that there are no upgrade docs for opensrf, is that on anyone's todo list? |
| 11:18 |
pinesol_green |
Launchpad bug 1390138 in Evergreen "Documentation: 2.7 upgrade docs need to be updated" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1390138 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 11:19 |
bshum |
Stompro: I don't know of any active work on creating upgrade steps for OpenSRF |
| 11:19 |
yboston |
Stompro: neither have I |
| 11:23 |
Stompro |
Ok, I'll put that on my list of things to take a stab at, it is mostly just stripping out the things that don't need to get redone from the opensrf install docs. I would also like to see the opensrf install docs start with downloading and untaring the software, I think someone was confused by that on the listserve a week or two ago. |
| 11:23 |
|
RoganH joined #evergreen |
| 11:25 |
Stompro |
Oh, and I think if we moved the opensrf user creation to the first step, and then just did the upgrade/install using the opensrf user as the non-priviledged user, it would match up with the evergreen install/upgrade style a little better. |
| 11:36 |
|
sandbergja joined #evergreen |
| 11:47 |
bshum |
Stompro: That's not always assumed anymore that the opensrf user is always the user used to do all the work. |
| 11:48 |
bshum |
But I get what you mean :) |
| 11:54 |
Dyrcona |
Stompro: Upgrading OpenSRF is just reinstall it. |
| 11:56 |
Dyrcona |
As for making auto-updates clients, include updates-client in the make arguments when you build the client. |
| 11:58 |
Stompro |
Dyrcona: But you don't need to do all of the steps that a first time install needs. You don't need to create the Opensrf user, you don't need to make any ejabberd changes, you don't need to adjust the /openils/conf files. |
| 11:58 |
Dyrcona |
Well, yeah, that *should* be obvious. |
| 12:00 |
Dyrcona |
bshum dbwells: Should we have a 2.5.9 target? |
| 12:01 |
dbwells |
Dyrcona: yes, for security bugs. Feel free to add one if you can, or let me know and I will. |
| 12:01 |
Dyrcona |
I'm mainly thinking in terms of lp 1390225 as it is related to a security fix. |
| 12:01 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225 - Assigned to Jason Stephenson (jstephenson) |
| 12:01 |
Dyrcona |
I think I can. |
| 12:02 |
Dyrcona |
I guess a better question is does that bug warrant another 2.5 release? |
| 12:02 |
dbwells |
Probably not. |
| 12:03 |
dbwells |
If the "hotfix" works fine, I'd lean toward a "b" release. |
| 12:04 |
Dyrcona |
OK. I'll push it to rel_2_5 if it works for me and let you sort it out. :) |
| 12:04 |
jeff |
this version of postgresql is too old to support multirow INSERT syntax. |
| 12:04 |
Dyrcona |
jeff: What version? |
| 12:04 |
dbwells |
Dyrcona: sounds good, thanks! |
| 12:04 |
jeff |
psql (PostgreSQL) 8.1.19 |
| 12:05 |
Dyrcona |
jeff: I thought that version could....Maybe that was 8.3? |
| 12:05 |
jeff |
Dyrcona: 8.2 and above, based on docs. |
| 12:06 |
Dyrcona |
Ah, so looks like it is time to upgrade, then. :) |
| 12:07 |
jeff |
well past. |
| 12:14 |
|
nhilton joined #evergreen |
| 12:20 |
Stompro |
Dyrcona: auto-updates - I think it is more complex than that, at lease for my testing system. Looks like the auto-update requires a valid SSL cert, and some options that are set at configure time. And it doesn't look like the auto-update works if I used the staff client listed on the egdownloads page, you have to have already installed a custom built staff client. |
| 12:21 |
tsbere |
Stompro: Auto-updates don't work with community staff clients, but you don't have to use configure-time options. Staff-client build time options work as well, though the configure time options speed that up. As for the valid SSL cert, if your update host starts with http:// you can bypass that (though I wouldn't do that for production systems) |
| 12:22 |
* tsbere |
will also admit to not having *tested* http:// updates in quite a while, though |
| 12:23 |
Stompro |
tsbere: Thanks for the tips. |
| 12:24 |
tsbere |
Stompro: Oh, and while it is certaintly *easier* when it is, your updates host doesn't have to be the same server as your evergreen install. |
| 12:26 |
Dyrcona |
Heh. You'd think I would have rememberd updates_host. I just did an update with updates-client this morning. :p |
| 12:28 |
Stompro |
tsbere++ Dyrcona++ I know this stuff is all on the wiki, I just haven't gotten through it all yet, there is a lot of info there. |
| 12:28 |
Dyrcona |
Yep, there is a lot on the wiki. |
| 12:37 |
pinesol_green |
[evergreen|Mike Rylander] LP#1390225: redirect to ctx.home_page instead of through ctx.logout_page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31b47b2> |
| 12:37 |
pinesol_green |
[evergreen|Mike Rylander] LP#1390225: Fail to care about errors from auth.session.delete - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a5f306> |
| 12:47 |
Dyrcona |
And that was pushed to master, rel_2_7, rel_2_6, and rel_2_5. |
| 12:47 |
bshum |
Should we roll a "b" build for all the releases? |
| 12:47 |
bshum |
(can't do it right now, but later this evening) |
| 12:48 |
Dyrcona |
I'll leave that up to you and dbwells to decide. :) |
| 13:04 |
* phasefx_ |
has a fix for lp1386260 if someone wants to poke at it |
| 13:06 |
bshum |
bug 1386260 |
| 13:06 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:08 |
phasefx_ |
you can do perl live_t/03-overdue_circ.t to test on a stock install with concerto |
| 13:09 |
* phasefx_ |
will add that to the bug |
| 13:10 |
Dyrcona |
csharp: I pushed the changes I mentioned to my evergreen_utilities repo. I also made a change to db_upgrade.pl, but you probably don't use that one. |
| 13:10 |
|
akilsdonk_ joined #evergreen |
| 13:14 |
Dyrcona |
csharp: might want to wait. I just noticed a serious thinko/bug in my pingest changes. It won't work right as is if you try to do attribute and search or facet ingest at the same time. |
| 13:19 |
phasefx |
oy, I just fixed one test.. not all of them, doh |
| 13:39 |
csharp |
Dyrcona: no problem - I haven't pulled in today's changes yet |
| 13:39 |
|
kmlussier joined #evergreen |
| 13:40 |
phasefx |
alright, fix re-pushed for bug 1386260 :-) |
| 13:40 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:41 |
Dyrcona |
csharp: I'm having some "fun" with a little hidden global variable voodo.... I was wondering why it worked at all until I noticed a little $lists++; tucked away in the browse_ingest subroutine. |
| 13:42 |
jeff |
blargh. character encoding issues. |
| 13:44 |
Dyrcona |
Anyway, the bug I noticed is that I had doubled the number of child processes without also adjusting the number of lists, so the program could exit prematurely. |
| 13:44 |
Dyrcona |
I'm tying not to double the child processes this time around. |
| 13:44 |
Dyrcona |
jeff: That seems an everyday thing for me. |
| 13:45 |
jeff |
yeah. |
| 13:45 |
Dyrcona |
"Hi, I'm a MARC8 record." |
| 13:45 |
Dyrcona |
"But, no, you contain KOI8 or some such." |
| 13:45 |
jeff |
in this case it was my own fault. i was eating MARC-8 with MARC::Record then writing out to a file that I had set as :utf8 |
| 13:46 |
Dyrcona |
Yep. |
| 13:47 |
jeff |
I'm tempted to transform these incoming records to UTF-8 using yaz-marcdump. |
| 13:47 |
Dyrcona |
But, I always seem to have the UTF-8 characters that won't map to MARC-8. |
| 13:48 |
Dyrcona |
When exporting to a vendor. |
| 13:48 |
Dyrcona |
jeff: Might be a good idea. |
| 13:48 |
Dyrcona |
I like using yaz-marcdump to convert binary MARC to xml and UTF-8 at the same time, even. :) |
| 13:49 |
jeff |
I thought that MARC::Record had more obvious transcoding support. Maybe I'm just thinking of MARC::File::Encode |
| 13:49 |
Dyrcona |
Often makes those "vendor records" easier for MARC::Record to digest. Just ignore the comments in the output. :) |
| 13:50 |
jeff |
no, if yaz-marcdump can't parse without errors/warnings, you reject the file ;-) |
| 13:51 |
Dyrcona |
Then, I'd almost never load anything. ;) |
| 13:51 |
jeff |
last if $outcount >= 50; |
| 13:51 |
* jeff |
frowns |
| 13:52 |
jeff |
i need to develop better habits with regard to "# XXX: remove after testing" or somesuch. |
| 13:52 |
jeff |
though part of me wants hard limits (just not that low) in place for some automated things. |
| 13:52 |
Dyrcona |
jeff: command line option to limit, by default set to zero, which means do the whole thing. |
| 13:54 |
Dyrcona |
Well, perl -c says syntax OK. Guess that means I can commit. :) |
| 13:54 |
tsbere |
jeff: I tend to use TODO for things I intend to change/remove before pushing, and XXX for things I see as longer-term warning notes |
| 13:54 |
jeff |
what, no "i was able to commit, i guess that means perl -c passed!"? :-) |
| 13:55 |
jeff |
tsbere: heh. i often end up with exactly the opposite. |
| 13:55 |
* jeff |
wonders what the larger convention is |
| 13:55 |
jeff |
i suppose what matters most is the local / codebase convention |
| 13:55 |
tsbere |
jeff: Oh, and "To whomever works on this code next:" for "we should do this later, because I am being lazy and don't feel like doing it now" (but I avoid doing that if I know what should be changed/done anyway) |
| 13:59 |
Dyrcona |
jeff: I've sometimes added --dry-run or similar options to my own stuff for testing purposes. |
| 13:59 |
* jeff |
nods |
| 13:59 |
jeff |
lots of this kind of thing is solved by good habits early: config file, command line arguments, etc. |
| 13:59 |
Dyrcona |
Or in a case where I was deleting files, a --delete option to actually do the delete, otherwise it just printed out what would be deleted without deleting. |
| 14:00 |
Dyrcona |
Yep. |
| 14:00 |
jeff |
with some small / quick scripts, things that start as variables in the top of the script never graduate to command line arguments / config files. |
| 14:01 |
Dyrcona |
I also like to take advantage of the environment, particularly with DBI scripts. |
| 14:02 |
Dyrcona |
I won't configure PGDATABASE in .bashrc, but will have some files hanging around that do set the environment. |
| 14:02 |
Dyrcona |
Then I'll source them in my shell before running a DBI script. |
| 14:02 |
* jeff |
ponders commit checks that include perl -c as well as "are there any instances of "if (1 || ..." |
| 14:04 |
tsbere |
jeff: what about "if (0 && ..."? :P |
| 14:05 |
jeff |
right. |
| 14:05 |
dbwells |
jeff: I also use XXX for 'near-future' (aka 'I need to come back to this before I finish / close this out') and TODO for 'less-near-future/someday'. Never thought about it too hard, but I can see others using 'XXX' as more like 'warning/poison!' |
| 14:06 |
jeff |
dbwells: yeah, XXX: for me is "if you see this still, you're probably not ready to push" |
| 14:16 |
jcamins |
dbwells: "XXX" being what you replace your comments with if you want to maintain a reputation for gentility? |
| 14:17 |
dbwells |
jcamins: uh, but of course (?) |
| 14:18 |
jcamins |
dbwells: am I the only one whose comments can't be read aloud around children? |
| 14:18 |
dbwells |
:) |
| 14:30 |
Dyrcona |
I usually use TODO: to tell myself and others where improvement would be welcome. :) |
| 14:33 |
jeff |
i also need to make a habit of preserving more one-off ad-hoc queries. |
| 14:34 |
Dyrcona |
I keep a git repo for such things actually. |
| 14:34 |
Dyrcona |
One for SQL and a separate one for Perl. |
| 14:34 |
kmlussier |
dbwells: Is 2.5 only being updated for security releases now? |
| 14:35 |
jeff |
Dyrcona: yeah, i was thinking of automatic presevation via .psql_history archiving or other. |
| 14:35 |
dbwells |
kmlussier: yes, other than the small bug in the latest release |
| 14:35 |
kmlussier |
dbwells: OK, thanks! |
| 14:37 |
Dyrcona |
kmlussier: To be fair, the latest fix is a fix for the security fix, so should be considered part of it, IMHO. |
| 14:38 |
Dyrcona |
It's not major, though, but people don't like see Internal Server Error pages come up. |
| 14:41 |
kmlussier |
Dyrcona: OK. I was just wondering about bug fixes that still have yet to be merged. I just happen to be looking at a lot of them right now since Bug Squashing Day is on its way. :) |
| 14:42 |
Dyrcona |
Yep. Makes sense. |
| 14:44 |
dbwells |
2.5 is fading into the ether, but it will always hold a special place in my git history. |
| 14:45 |
bshum |
git branch -D rel_2_5 |
| 14:45 |
Dyrcona |
dbwells++ |
| 14:45 |
dbwells |
bshum: hey! :) |
| 14:45 |
bshum |
:) |
| 14:47 |
kmlussier |
dbwells++ |
| 14:47 |
kmlussier |
:) |
| 15:06 |
RoganH |
dbwells++ |
| 15:20 |
|
akilsdonk joined #evergreen |
| 15:36 |
|
rfrasur left #evergreen |
| 15:36 |
|
rfrasur joined #evergreen |
| 15:49 |
|
RoganH joined #evergreen |
| 15:53 |
kmlussier |
OK, I give up on trying to figure this out by myself. I've seen other people create a branch in the working repository out of branches that came from github. I thought I would try doing the same for https://github.com/evergreen-library-system/Evergreen/pull/29 |
| 15:53 |
kmlussier |
I was looking at the instructions set up to help DIG with github requests. http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:github-workflow |
| 15:55 |
kmlussier |
When I fetch the branch into my local branch, I get a message that says "From https://github.com/evergreen-library-system/Evergreen * branch refs/pull/29/head -> FETCH_HEAD |
| 15:55 |
kmlussier |
If I try to rebase, it tells me there is nothing to rebase. What am I doing wrong? |
| 15:55 |
kmlussier |
Wait, I just tried it again, and it seemed to work this time. Never mind. |
| 15:58 |
kmlussier |
@eightball does git like to play mind games with me? |
| 15:58 |
pinesol_green |
kmlussier: What are you asking me for? |
| 16:01 |
kmlussier |
pinesol_green: No need to get snippy with me. |
| 16:01 |
pinesol_green |
kmlussier: You keep using that word. I do not think it means what you think it means. |
| 16:01 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 16:07 |
mmorgan |
kmlussier: Sorry, I don't think I can be of anymore help than pinesol_green :-( |
| 16:08 |
kmlussier |
mmorgan: That's okay. At least your not snippy like pinesol_green. |
| 16:08 |
kmlussier |
@dessert mmorgan |
| 16:08 |
* pinesol_green |
grabs some Mint Chocolate Chip Ice Cream for mmorgan |
| 16:08 |
Dyrcona |
kmlussier: Sounds like you forget to specify the remote or local branch that you wanted to rebase onto, but you figured it out. |
| 16:08 |
* Dyrcona |
speak like bad fortune cookie. |
| 16:09 |
Dyrcona |
Or, type like, rather. |
| 16:09 |
kmlussier |
Dyrcona: Yes, I did figure it out, but I'm pretty sure I specified the remote the first time around. |
| 16:09 |
kmlussier |
Mmmm...fortune cookie. Now you're making me hungry. |
| 16:11 |
jcamins |
Mmmm... cookie. |
| 16:11 |
jcamins |
What kind of cookie should I bake this weekend? |
| 16:12 |
kmlussier |
jcamins: What's your specialty? |
| 16:12 |
jcamins |
kmlussier: I have a lot of specialties. |
| 16:12 |
jcamins |
Double-chocolate mint. |
| 16:12 |
jcamins |
Coconut oatmeal chocolate chip. |
| 16:13 |
kmlussier |
jcamins: That's so funny. When you asked what you should bake, my first thought was a chocolate mint cookie. |
| 16:13 |
jcamins |
Sandtarts (lemon-tinged chocolate chip cookies). |
| 16:13 |
jcamins |
There we go, then. |
| 16:13 |
kmlussier |
Which is what I would be baking if I had the mint chips. |
| 16:13 |
jcamins |
Chocolate mint it shall be. |
| 16:13 |
jcamins |
Do you have peppermint schnapps? |
| 16:13 |
kmlussier |
jcamins: No. My recipe doesn't call for peppermint schnapps. And I don't think I've drunk any kind of schnapps since I was a teenager. |
| 16:14 |
jcamins |
If you had peppermint schnapps, you wouldn't need mint chips! |
| 16:15 |
kmlussier |
Oh, but mint chips can be used for lots of things, like an ice cream topping. |
| 16:15 |
jcamins |
Peppermint extract also works, but it's $5 for a half ounce of extract or $5 for a half gallon of peppermint schnapps that works just as well and never goes bad... |
| 16:15 |
jcamins |
True. Any stores that stock them on the way home? |
| 16:15 |
jcamins |
:) |
| 16:15 |
kmlussier |
Nope. I can only find them online. |
| 16:15 |
jcamins |
Maybe I should try a new kind of mint chocolate cookie. |
| 16:15 |
jcamins |
Mint-wasabi? |
| 16:16 |
Dyrcona |
Waah-saah-beee! |
| 16:16 |
* kmlussier |
wanders off to the ghirardelli web site. |
| 16:16 |
jcamins |
kmlussier: no time! Chocolate chip cookies have been mentioned, they must be eaten! |
| 16:16 |
* Dyrcona |
snickers. |
| 16:17 |
jboyer-isl |
Et tu, candy bars? |
| 16:20 |
jcamins |
Ooh... I even have food coloring so I can make the wasabi-mint cookies green! |
| 16:21 |
jeff |
hah! this is apparently the first time i've had occasion to enter the reporter since "sort by name" became a thing. |
| 16:21 |
jeff |
confused me for a moment until i remembered. |
| 16:42 |
Dyrcona |
It's Friday! (Well, unless it is Saturday where you are.) |
| 16:43 |
kmlussier |
Dyrcona: Happy Friday afternoon! |
| 16:43 |
Dyrcona |
kmlussier: Thank you. Same to you! |
| 16:44 |
Dyrcona |
I hope I just sent my last work email of the day/week. |
| 16:50 |
kmlussier |
tsbere / csharp: What is the status of bug 778989? |
| 16:50 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 3, heat: 16) [Medium,In progress] https://launchpad.net/bugs/778989 - Assigned to Thomas Berezansky (tsbere) |
| 16:51 |
kmlussier |
We have a Sandbox request for that branch, but it looks like csharp already signed off on it? Is it still being worked on? |
| 16:53 |
kmlussier |
Late Friday afternoon is probably not the best time to ask questions. :-/ |
| 16:53 |
berick |
@who has the friday answers? |
| 16:53 |
pinesol_green |
ldw has the friday answers. |
| 16:53 |
tsbere |
kmlussier: Well, I think it is good to go, but I unassigned myself. |
| 16:53 |
kmlussier |
That makes sense. It isn't late yet for ldw. |
| 16:53 |
kmlussier |
tsbere: OK, thanks! |
| 16:55 |
Dyrcona |
I suppose we can worry about that one next week. |
| 16:55 |
Dyrcona |
It took a couple of years to get signed off, so what's a few more days? :) |
| 16:55 |
kmlussier |
Heh |
| 16:56 |
kmlussier |
It's nice to see some dusty bugs making forward progress. :) |
| 16:57 |
|
tspindler left #evergreen |
| 16:57 |
Dyrcona |
Yeah. |
| 16:57 |
Dyrcona |
Well, have a nice weekend, everybody! |
| 17:02 |
kmlussier |
OK, MassLNC Sandboxes are ready to go for Bug Squashing Day. Have a nice weekend everyone! |
| 17:02 |
mmorgan |
Have a nice weekend! |
| 17:11 |
|
mmorgan left #evergreen |
| 20:21 |
|
pastebot0 joined #evergreen |
| 20:22 |
|
mtcarlsoz joined #evergreen |
| 20:22 |
|
jcamins joined #evergreen |
