| Time |
Nick |
Message |
| 00:24 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1447746: Fix lp957466_update_date_and_source regression test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8ab6306> |
| 00:58 |
|
webmind joined #evergreen |
| 01:17 |
|
jonadab joined #evergreen |
| 01:21 |
|
berick joined #evergreen |
| 01:25 |
|
BunnyRider joined #evergreen |
| 01:25 |
|
Bmagic_ joined #evergreen |
| 01:28 |
bshum |
gmcharlt: I put together branches for the two things to fix for Debian and OpenSRF master, but just realized they'll probably have a minor conflict with each other. Simple enough to resolve whichever one we push in first. |
| 01:29 |
bshum |
I'll test Wheezy later, but Jessie installs all the pre-req's happily with the combined branch content. |
| 01:29 |
* bshum |
tries to sleep |
| 02:00 |
|
dcook joined #evergreen |
| 02:12 |
|
artunit joined #evergreen |
| 02:18 |
|
dcook joined #evergreen |
| 03:47 |
|
gsams joined #evergreen |
| 03:50 |
|
gsams joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:16 |
|
gsams_ joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
Christineb joined #evergreen |
| 07:42 |
bshum |
Test success! Yes! :) |
| 08:05 |
|
collum joined #evergreen |
| 08:06 |
|
JBoyer joined #evergreen |
| 08:17 |
|
ericar joined #evergreen |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:30 |
csharp |
@test |
| 08:30 |
pinesol_green |
csharp: As great as you are man, you'll never be greater than yourself. |
| 08:53 |
|
aubjordan joined #evergreen |
| 08:55 |
|
mmorgan joined #evergreen |
| 09:00 |
|
maryj joined #evergreen |
| 09:06 |
|
mdriscoll joined #evergreen |
| 09:21 |
|
bos20k joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:25 |
|
jvwoolf joined #evergreen |
| 09:36 |
|
terran joined #evergreen |
| 10:00 |
|
rfrasur joined #evergreen |
| 11:02 |
|
Dyrcona joined #evergreen |
| 11:03 |
Dyrcona |
Ah, bummer. |
| 11:03 |
Dyrcona |
Signed in to chat with someone in particular and that someone is not in channel. |
| 11:04 |
|
kmlussier joined #evergreen |
| 11:09 |
|
JBoyer_alt joined #evergreen |
| 11:10 |
|
brahmina joined #evergreen |
| 11:10 |
|
JBoyer_alt joined #evergreen |
| 11:21 |
Dyrcona |
Heh. A psql session that I forgot about survived my laptop going to sleep and than the IP address changing. |
| 11:21 |
Dyrcona |
s/than/then/ |
| 11:23 |
Dyrcona |
Actually, I'll bet it really didn't. |
| 11:23 |
|
bjwillis joined #evergreen |
| 11:23 |
Dyrcona |
Probably would have blown up if I had tried a query. |
| 11:24 |
Dyrcona |
just a fyi: I plan to add yet another comment on LP 1306666 later. |
| 11:24 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get Reshelving status." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
| 11:24 |
|
rjackson_isl_ joined #evergreen |
| 11:24 |
Dyrcona |
I should have really thought about it more before replying earlier. |
| 11:24 |
Dyrcona |
I'll probably wait until I get home after today's meetings. |
| 11:29 |
JBoyer_alt |
Quick Q if anyone knows off hand: we have a location closing for a couple weeks and they want to stop INCOMING holds. (the closed dates are already in so that's covered.) |
| 11:29 |
JBoyer_alt |
I'm considering freezing all holds for pickup at that location with a thaw date maybe the day before they reopen unless I'm told that's madness. |
| 11:30 |
jeff |
JBoyer_alt: keep in mind that the holds in question may already be frozen with no thaw date, or with a thaw date after the date you'd be thawing. also, patrons may thaw them... |
| 11:30 |
jeff |
There might be a more clever way to do what you're trying to do, but nothing off the top of my head that I'd have enough confidence in to suggest. |
| 11:36 |
Dyrcona |
JBoyer: We've done that, frozen holds that were not already frozen or in transit. |
| 11:37 |
JBoyer_alt |
That's the best I can figure for now. (it' There are settings that say "don't target holds here!" and even settings to target holds while you're closed, but none that look at the pickup location. |
| 11:37 |
JBoyer_alt |
Oops. that parenthetical is supposed to be (it's just for 2 weeks). |
| 11:37 |
Dyrcona |
JBoyer_alt: Yeah, I think there is... |
| 11:37 |
Dyrcona |
JBoyer_alt: But it isn't timed, you'd have to turn it off after. |
| 11:38 |
Dyrcona |
I don't remember the setting off the top of my head. |
| 11:38 |
JBoyer_alt |
Oh, that would be perfect, I just couldn't find it when I was perusing the LSE. |
| 11:38 |
Dyrcona |
It may not be a LSE. |
| 11:38 |
mmorgan |
JBoyer_alt: When we had a similar situation, I think I remember changing the hold policies to make the particular pickup point not holdable. |
| 11:38 |
Dyrcona |
JBoyer_alt: Let me check some of my old scripts/notes. |
| 11:39 |
JBoyer_alt |
Dyrcona, thanks. |
| 11:39 |
Dyrcona |
JBoyer_alt: circ.holds.target_skip_me in LSE. |
| 11:39 |
Dyrcona |
Set to true for the OU in question. |
| 11:40 |
Dyrcona |
In one case, we froze all non-frozen holds or holds that thawed before the library reopened. |
| 11:40 |
mmorgan |
JBoyer_alt: Dyrcona: We used the ou setting also, to stop new holds. |
| 11:41 |
JBoyer_alt |
Dyrcona, that's the one we were looking at earlier, but the description implies it prevents items at that location from being targeted. I'm trying to stop holds at other locations from being targeted for transiting to the closed location. |
| 11:41 |
Dyrcona |
Yeah, that is what it does. Let me keep looking. |
| 11:42 |
mmorgan |
JBoyer_alt: This is the ou setting we used: "OPAC: Org Unit is not a hold pickup library" |
| 11:42 |
jeff |
keep in mind that some of these may prevent patrons from placing new holds for pickup at that library (which may or may not be desireable) |
| 11:42 |
Dyrcona |
mmorgan: Yeah, that's the one I was originally thinking of. |
| 11:43 |
Dyrcona |
jeff: I think that is the point temporarily. |
| 11:43 |
JBoyer_alt |
Ah, mmorgan, I like that suggestion. I thought you meant adding a row to the hold matrix denying holds for pickup at the closed location. |
| 11:44 |
Dyrcona |
Looks like in the particular case I'm looking at we made the library not visible in the OPAC while it was closed. |
| 11:44 |
JBoyer_alt |
jeff, Dyrcona, The hope isn't necessarily to prevent new holds, but that's a perfectly acceptable side effect for that amount of time. |
| 11:45 |
Dyrcona |
I don't think there is a way to allow holds and prevent them from filling temporarily, at least not easily done just from parameters. |
| 11:45 |
JBoyer_alt |
That was the other option we were considering, I wanted to see if there was a simpler (non-autogen.sh) option first. |
| 11:45 |
mmorgan |
JBoyer_alt: We did both, actually. Set the library NOT to be a pickup point and temporarily had rules in the hold matrix set so existing holds wouldn't capture - until they were ready to receive items again. |
| 11:46 |
Dyrcona |
mmorgan's suggestion should work. |
| 11:46 |
|
jihpringle joined #evergreen |
| 11:46 |
JBoyer_alt |
It'll be ok if they can't place new holds at the time. |
| 11:46 |
Dyrcona |
In this case, we decided to hide the library after discussion with the director. |
| 11:47 |
JBoyer_alt |
mmorgan, Ah, I suppose you would have to, I just looked at the setting and it doesn't effect targeting. |
| 11:47 |
mmorgan |
JBoyer_alt: Right. |
| 11:47 |
Dyrcona |
JBoyer_alt: If you freeze the holds, it won't matter. |
| 11:47 |
Dyrcona |
I think we added something to freeze the holds every night. |
| 11:48 |
Dyrcona |
This stuff often ends up being done rather ad hoc. :) |
| 11:48 |
JBoyer_alt |
Oh, yes. I thought "if we freeze the holds there may still be more coming in" but not if you can't choose that location. Excellent. |
| 11:49 |
Dyrcona |
In this particular case, we sent an email to patrons with an email address who had their holds suspended. |
| 11:49 |
JBoyer_alt |
I am the last person you'd expect to hear this from, but I /guess/ this would be an ok place for YAOUS since we have similar settings in place already, from the other way around. |
| 11:49 |
Dyrcona |
Part of it said that they could choose another library if they wanted to unsuspend the hold. |
| 11:49 |
mmorgan |
Dyrcona: When unfreezing, how did you identify those that had been frozen by the patron so they could stay frozen? |
| 11:50 |
JBoyer_alt |
That's not a bad idea, might run that by the library too. |
| 11:50 |
Dyrcona |
JBoyer_alt: You mean a setting to not target holds going to a particular location? |
| 11:50 |
Dyrcona |
mmorgan: We set a thaw date when we froze them, so they'd automatically thaw when the library was supposed to be opened again. |
| 11:51 |
jeff |
mmorgan: First thing that comes to mind for me would be to unly thaw holds having the very specific thaw date that you set in your batch update. |
| 11:51 |
jeff |
mmorgan: but then again, what Dyrcona just said makes even more sense |
| 11:51 |
mmorgan |
Ah Ok good iedea! |
| 11:51 |
mmorgan |
idea, even. |
| 11:52 |
Dyrcona |
Looks like we messed with transits, too, in this case. |
| 11:52 |
Dyrcona |
We've done this a few times and every time, I think it was a little different. |
| 11:53 |
Dyrcona |
In some case, I know we've informed the delivery company and they would hold things for a few days. |
| 11:56 |
mmorgan |
I like JBoyer_alt's idea about an ou setting to stop hold transits to a particular library. |
| 11:56 |
JBoyer_alt |
Thanks everyone for the suggestions. |
| 11:56 |
JBoyer_alt |
Dyrcona++ jeff++ mmorgan++ |
| 11:57 |
Dyrcona |
mmorgan: Yeah, I like the idea of that setting, too. |
| 11:57 |
|
JBoyer joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:07 |
|
glenm joined #evergreen |
| 12:07 |
jeff |
Another question is... what do you want to happen with the copies in question? Do you want them to go out to another patron in the meantime? |
| 12:10 |
* mmorgan |
would say Yes, they should go to another patron in the meantime. |
| 12:11 |
* Dyrcona |
is going to sign out for a bit. |
| 12:11 |
|
bmills joined #evergreen |
| 12:20 |
JBoyer |
jeff, we're freezing the holds over a week out so the holds can hopefully be picked up and used rather than sit for 2 weeks. |
| 12:22 |
jeff |
reasonable. |
| 12:33 |
jeffdavis |
We've had a few libraries running Windows report that their staff client "disappears" during automatic update - after downloading a partial update and restarting, the desktop shortcut is gone and apparently the evergreen.exe has vanished from their existing staff client folder as well. |
| 12:33 |
jeffdavis |
Has anyone seen something like this? |
| 12:39 |
mmorgan |
jeffdavis: Not that exactly. Could there be some overzealous antivirus software at work? |
| 12:40 |
jeffdavis |
It's possible. We've had similar reports from a few different libraries (all running Windows 7 I believe), I'll ask about antivirus. |
| 12:40 |
mmorgan |
We have had rare occasions where a cleanup utility run on a pc has caused problems, but never the client disappearing that I can recall. |
| 12:41 |
jeff |
jeffdavis: Any chance you can get access to a pre-upgrade-attempt workstation at a site that has experienced the issue? I suspect a local difference in permissions or similar. |
| 12:41 |
mmorgan |
Could they also have different Window profiles that maybe don't have the same shortcuts? |
| 12:42 |
jeff |
If so, then you could survey the land and then run something like procmon (from the sysinternals suite) to see what happens. Of course, there's the chance that you wouldn't experience the same issue on a different workstation, but could be worth a shot. |
| 12:51 |
jeffdavis |
problems_that_are_not_caught_in_testing_and_cannot_be_reproduced_by_support_staff-- |
| 12:52 |
bshum |
Darn chaos monkey :( |
| 12:52 |
|
sandbergja joined #evergreen |
| 12:52 |
jeff |
jeffdavis: yeah. :-( |
| 12:53 |
jeff |
jeffdavis: we do not use auto update here, so i can't offer any data points. |
| 12:53 |
jeffdavis |
the good news that this is our only upgrade problem so far (aside from an issue with a third-party vendor), and there's a quick solution: install the new client manually |
| 12:54 |
jeffdavis |
those suggestions are quite useful though, jeff++ mmorgan++ |
| 12:54 |
jeffdavis |
hopefully some of the more tech-savvy onsite folks can help us figure out the problem |
| 12:58 |
mmorgan |
jeffdavis: On the same subject, during our last upgrade, we did have a large number of workstations that, during the client auto-update, complained that the update could not be verified. Finally had to do a manual update. |
| 12:58 |
mmorgan |
Never did figure that out. I was wondering if it could be some kind of timeout issue. |
| 13:01 |
jeffdavis |
not an SSL problem? |
| 13:03 |
mmorgan |
Don't think so. Some worktations auto-updated just fine, some worked after a couple of tries. |
| 13:08 |
csharp |
I would be curious about the contents of the autoupdate.js file on the ones that didn't work |
| 13:11 |
mmorgan |
csharp: Is that on the workstation? |
| 13:11 |
csharp |
mmorgan: yes |
| 13:12 |
* csharp |
tries to find the file path |
| 13:12 |
jeffdavis |
components/defaults/autoupdate.js |
| 13:12 |
csharp |
jeffdavis++ |
| 13:13 |
* mmorgan |
looks |
| 13:15 |
jeffdavis |
bah sorry, defaults/preferences/autoupdate.js |
| 13:15 |
jeffdavis |
that's what I get for trying to do it from memory :) |
| 13:17 |
* mmorgan |
will have to find a workstation that is not an early adopter ;-) |
| 13:17 |
|
Dyrcona joined #evergreen |
| 13:19 |
|
jlitrell joined #evergreen |
| 13:21 |
* Dyrcona |
checks logs. |
| 13:22 |
Dyrcona |
We've not had problems with clients disappearing after updates, but we have had autoupdates fail from time to time. |
| 13:22 |
Dyrcona |
I can also add that I've never seen the partial update done by auto update work on Mac OS X nor on Linux. |
| 13:24 |
Dyrcona |
Not that helpful, but there it is. |
| 13:24 |
Dyrcona |
One question for my own sake: Were these 2.9 updates on the Evergreen side of things? |
| 13:24 |
|
kmlussier joined #evergreen |
| 13:26 |
* Dyrcona |
noticed something building the 2.9.5 tarball that just might be relevant. |
| 13:27 |
Dyrcona |
Complained that I didn't have libbzip2 installed, but that code should get rebuilt when you build from the tarball, so I'm not sure it matters. |
| 13:27 |
jeffdavis |
Dyrcona: in my case, 2.8.1 -> 2.10.2 |
| 13:27 |
jeffdavis |
I didn't notice any errors while building the updates, perhaps I missed something though |
| 13:27 |
jeffdavis |
autoupdate worked fine during testing |
| 13:28 |
Dyrcona |
jeffdavis: I didn't notice anything when testing the tarball and I was looking for it. |
| 13:28 |
Dyrcona |
I don't test autoupdates though. |
| 13:28 |
jeffdavis |
oh and we install from git, not from official release tarballs |
| 13:28 |
Dyrcona |
Bascially, just build from the tarball, log in with the staff client, and make sure a few things work. |
| 13:29 |
Dyrcona |
jeffdavis: OK, then. |
| 13:29 |
Dyrcona |
I have since installed libbzip2-dev on the laptop. |
| 13:29 |
Dyrcona |
Somehow that was not installed.... |
| 13:30 |
Dyrcona |
When I noticed the message, I thought it was a big deal at first, but later realized that it shouldn't be. |
| 13:31 |
Dyrcona |
For production, we typically install from git. |
| 13:31 |
pinesol_green |
[evergreen|Bill Erickson] LP#1580676 MARC stream authority cleanup repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fceb8d6> |
| 13:31 |
pinesol_green |
[evergreen|Galen Charlton] LP#1580676: fix error message - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c48288d> |
| 13:33 |
Dyrcona |
Other than it might have been a tarball issue, I don't have any new suggestions than have already been made. |
| 13:34 |
Dyrcona |
Unless it is failing everywhere, but it doesn't sound like it is. |
| 13:35 |
* Dyrcona |
is in between meetings and lunch was served. |
| 13:36 |
Dyrcona |
It's the annual meeting. |
| 13:37 |
pinesol_green |
[evergreen|Josh Stompro] LP#1517556 - Exclude inactive event defs from find_event_def_by_hook. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a05d872> |
| 13:38 |
Dyrcona |
gmcharlt++ pushing patches |
| 13:40 |
kmlussier |
gmcharlt: I'll push your patch for 1584801 shortly |
| 13:40 |
kmlussier |
bug 1584801 |
| 13:40 |
pinesol_green |
Launchpad bug 1584801 in Evergreen 2.9 "tagging previously borrowed items in metarecord searches fails" [Medium,Confirmed] https://launchpad.net/bugs/1584801 |
| 13:40 |
gmcharlt |
kmlussier++ |
| 13:40 |
Dyrcona |
Oh yeah... getting ready for the next 2.10 tomorrow.... |
| 13:41 |
Dyrcona |
Should I do a 2.9 at the same time to keep in sync? |
| 13:47 |
pinesol_green |
[evergreen|Jason Boyer] LP1567514 - Don't Output Null Byte for Spool Files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=48698ad> |
| 13:47 |
gmcharlt |
Dyrcona: eh, since you released last week, I suggest not bothering unless you feel like it; we can get back in sync in June |
| 13:47 |
kmlussier |
Since we just had a 2.9 release last week, I wouldn't think another one is needed yet. Just one person's opinion. |
| 13:48 |
kmlussier |
Or two people's opinion |
| 13:48 |
Dyrcona |
OK. I don't have a problem with that. |
| 13:55 |
pinesol_green |
[evergreen|Galen Charlton] LP#1584801: fix tagging of previous circs in metarecord search results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a4551e> |
| 14:04 |
berick |
@love digging around in Open-ILS/src/support-scripts/test-scripts and finding a 7 year old script that does exactly what I needed. |
| 14:04 |
pinesol_green |
berick: The operation succeeded. berick loves digging around in Open-ILS/src/support-scripts/test-scripts and finding a 7 year old script that does exactly what I needed.. |
| 14:12 |
|
jihpringle_ joined #evergreen |
| 14:17 |
kmlussier |
gmcharlt: Thanks for adding that link. I spent some time Googling yesterday and found lots of UX articles regarding column sorting, but none of them talked about the third, click option. |
| 14:19 |
kmlussier |
It did leave me to the discovery, though, that the triangles used to illustrate sort order in Thunderbird work the opposite of almost every other web-based soring table I've seen. |
| 14:19 |
gmcharlt |
kmlussier: bug 1585320 |
| 14:19 |
pinesol_green |
Launchpad bug 1585320 in Evergreen "display whether an item was previously borrowed on more TPAC pages" [Wishlist,New] https://launchpad.net/bugs/1585320 |
| 14:20 |
kmlussier |
gmcharlt++ #Thanks! |
| 14:36 |
dbs |
So, uh, do the previous years' funds just keep getting added to the bottom of the Acq Search "LID - Fund" select list forever? |
| 14:37 |
dbs |
We have a relatively tiny 341-item select list after a few years of funds :) |
| 14:40 |
berick |
dbs: i would expect them to go away once the funds are marked as inactive |
| 14:40 |
berick |
but don't recall OTTOMH if they actually do |
| 14:40 |
berick |
I know in most places they disappear |
| 14:41 |
gmcharlt |
barring something coming up, I've pushed what I intended to include in 2.10.4 |
| 14:42 |
kmlussier |
There are a couple of other places where inactive funds still appear. Looking at bug 1175293 |
| 14:42 |
pinesol_green |
Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 14:42 |
kmlussier |
But, like berick, I don't know off-hand if this issue also occurs in the search. |
| 14:56 |
JBoyer |
mmorgan, Dyrcona, jeffdavis: I've done some learning recently re: updates that couldn't be verified. If you built your clients on more than one app server your chances of failure go up significantly. |
| 14:57 |
Dyrcona |
That's interesting. We only build updates on 1 machine because we only have 1 that staff access. |
| 14:57 |
JBoyer |
So if you ask server A "Is there an update?" and it says "But of course", you may ask server B for the actual file and the odds of the checksums and so on matching are... not good. |
| 14:57 |
JBoyer |
so I had to copy all of /openils/var/updates to all 13 of our app servers to make updates work consistently |
| 14:58 |
JBoyer |
... but it looks like that's not Dyrcona's problem. Bummer. :-/ |
| 14:58 |
Dyrcona |
I think we just had one bad/corrupted file and blew the whole thing away. |
| 14:59 |
Dyrcona |
I think tsbere blew away the update files once to force a full upgrade pre-emptively, too. |
| 14:59 |
Dyrcona |
He's out this week, so probably not paying much attention. |
| 15:01 |
mmorgan |
JBoyer: Interesting. So building it on on server and copying it to all the others seems like a good plan. |
| 15:02 |
mmorgan |
JBoyer++ |
| 15:02 |
Dyrcona |
Y'know, I wouldn't be surprised if the updates are different if built at different times. |
| 15:03 |
JBoyer |
Probably. |
| 15:03 |
Dyrcona |
I don't think there is any code in the mar program that enforces any order. |
| 15:03 |
JBoyer |
And mmorgan, if you do that, I'd recommend copying everying below updates/ because I don't know how the various files are related. |
| 15:04 |
JBoyer |
It only took me months and 2 upgrades to figure this out! Learn from my copious mistakes. |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:05 |
Dyrcona |
JBoyer++ |
| 15:58 |
|
jvwoolf left #evergreen |
| 15:58 |
dbs |
berick: it kind of makes sense for the funds to show up in the Acq General Search forms, given that you might want to find out what you paid last year for a given thing |
| 15:58 |
berick |
dbs: ah, yeah, makes sense |
| 15:59 |
dbs |
As a query interface, we would rapidly run into Reporter UI insanity if we added in Fund attributes like Active and fund tags, I guess. |
| 16:00 |
dbs |
Still... we'll be adding 100+ funds per year at this rate. Heh |
| 16:01 |
dbs |
One of the most interesting thoughts expressed at I/O last week was about how web components & Polymer effectively took the Dojo widget model as a core use case |
| 16:03 |
* dbs |
also musing about possibilities for using service worker threads to intelligently cache network requests, etc |
| 16:03 |
dbs |
Just need unlimited times |
| 16:29 |
|
mmorgan joined #evergreen |
| 16:41 |
kmlussier |
mmorgan just pointed out a problem on webby that we don't see on demo.evergreencatalog.com. I wonder if it's another issue with the new AngularJS. |
| 16:41 |
kmlussier |
The input boxes in the copy editor for adding volume and barcode info appear to be missing. See http://www.screencast.com/t/YDGf3MHdwvl |
| 16:42 |
kmlussier |
I don't have another test server to compare it against. Is anyone else seeing the same thing |
| 16:42 |
kmlussier |
? |
| 16:56 |
berick |
kmlussier: meaning there should be inputs below Owning Library, Volumes, Classification, etc? |
| 16:56 |
kmlussier |
berick: Yeah |
| 16:57 |
berick |
k. i'm seeing the same as you running master on my local dev VM |
| 16:58 |
kmlussier |
This is what it should look like. http://www.screencast.com/t/JbB7gHufypI |
| 16:58 |
kmlussier |
berick: OK, thanks. I'll file a bug then. |
| 16:58 |
berick |
ah, ok |
| 17:08 |
* kmlussier |
just noticed a Zazzle $10 off coupon in her Inbox and used it towards her new YAOUS mug. :D |
| 17:09 |
mmorgan |
Oooh! That's timely. |
| 17:09 |
kmlussier |
yes, I got the email four days ago, and they said the discount was only good for three days. |
| 17:09 |
kmlussier |
They lied. |
| 17:11 |
|
mmorgan left #evergreen |
| 17:26 |
|
yboston joined #evergreen |
| 19:32 |
|
dcook joined #evergreen |
