| Time |
Nick |
Message |
| 07:20 |
|
timlaptop joined #evergreen |
| 07:27 |
|
artunit_ joined #evergreen |
| 07:45 |
|
ningalls joined #evergreen |
| 07:49 |
|
misilot joined #evergreen |
| 07:54 |
|
misilot left #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 08:22 |
|
mrpeters joined #evergreen |
| 08:31 |
|
adbowling-isl joined #evergreen |
| 08:33 |
|
Shae joined #evergreen |
| 08:34 |
|
akilsdonk joined #evergreen |
| 08:36 |
|
timhome joined #evergreen |
| 08:38 |
|
kbeswick joined #evergreen |
| 08:38 |
csharp |
wow - lots of new "uninitialized value" perl warnings in the opensrf logs on 2.5.1 |
| 08:39 |
csharp |
looks like checkin/renewal and holds are the offenders |
| 08:39 |
csharp |
Use of uninitialized value in pattern match (m//) at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line 2408. |
| 08:40 |
|
ericar joined #evergreen |
| 08:40 |
csharp |
we're not hearing complaints about it so far, so it must not be affecting the front end, but that's a lot of new noise in osrfwarn.log |
| 08:41 |
berick |
csharp: those are probably not new, yr just seeing them because opensrf directs warnings to the logs now |
| 08:41 |
berick |
instead of foo_stderr.log |
| 08:41 |
csharp |
ah... |
| 08:41 |
csharp |
berick: thanks for that information |
| 08:47 |
berick |
i'm not suggesting they be ignored, of course, just attempting to reduce anxiety ;) |
| 08:51 |
csharp |
berick: thank you |
| 08:54 |
|
Dyrcona joined #evergreen |
| 08:56 |
|
jwoodard joined #evergreen |
| 08:58 |
dbs |
@wunder p3e 2c6 |
| 08:58 |
pinesol_green |
dbs: The current temperature in Sudbury, Ontario is -18.9°F (8:44 AM EST on January 21, 2014). Conditions: Clear. Humidity: 81%. Dew Point: -23.8°F. Windchill: -18.4°F. Pressure: 30.25 in 1024 hPa (Steady). |
| 08:58 |
dbs |
@wunder sudbury, on |
| 08:58 |
pinesol_green |
dbs: Error: No such location could be found. |
| 08:58 |
dbs |
@wunder sudbury, ontario |
| 08:58 |
pinesol_green |
dbs: The current temperature in Sudbury, Ontario is -23.8°F (8:00 AM EST on January 21, 2014). Conditions: Clear. Humidity: 76%. Dew Point: -29.2°F. Windchill: -40.0°F. Pressure: 30.25 in 1024 hPa (Steady). |
| 08:58 |
dbs |
that's more like it. |
| 09:09 |
Dyrcona |
dbs: No thank you. You can keep the cold. |
| 09:09 |
Dyrcona |
@wunder 01844 |
| 09:09 |
pinesol_green |
Dyrcona: The current temperature in WB1CHU, Lawrence, Massachusetts is 9.0°F (9:09 AM EST on January 21, 2014). Conditions: Clear. Humidity: 68%. Dew Point: 1.4°F. Windchill: 8.6°F. Pressure: 30.09 in 1019 hPa (Rising). Winter Storm Warning in effect from 1 PM this afternoon to 1 PM EST Wednesday... |
| 09:10 |
|
mmorgan joined #evergreen |
| 09:10 |
Dyrcona |
kmlussier: Do you have any objections to me reloading my development database this morning? |
| 09:17 |
* csharp |
strenuosly objects! |
| 09:18 |
csharp |
strenuously, even |
| 09:20 |
Dyrcona |
Well, there is some messed up fine data that I want to get rid of, but I don't know if kmlussier is still looking at anything in particular. |
| 09:20 |
kmlussier |
Dyrcona: No objections from me, but let me check with mmorgan and some others to see if they're still looking at anything. |
| 09:21 |
Dyrcona |
I stopped services already this morning, but can restart them, of course. |
| 09:22 |
|
jboyer-isl joined #evergreen |
| 09:34 |
|
tfaile joined #evergreen |
| 09:53 |
|
RoganH joined #evergreen |
| 09:58 |
|
ericar joined #evergreen |
| 10:00 |
|
yboston joined #evergreen |
| 10:01 |
|
afterl joined #evergreen |
| 10:26 |
bshum |
So, if I'm understanding the gist of bug 1271198 right, the key is getting rid of the "has_browse_entry=?????" part of the URL links for things like subject links in the record details. And probably facets too. |
| 10:26 |
pinesol_green |
Launchpad bug 1271198 in Evergreen "Catalog browse search headings link self-referential" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1271198 |
| 10:27 |
bshum |
Well, maybe not facets |
| 10:27 |
bshum |
That's just for refining the existing search set. |
| 10:33 |
jeff |
grr. i really don't want to be considering maintaining a patron stat cat or user setting that contains a date string of "patron's expiration date at time of the most recent NCIP LookupUser request" |
| 10:33 |
jeff |
and i really don't want to be considering building staff-side alerting if the real expiration date doesn't match that value. |
| 10:33 |
jeff |
too late. |
| 10:40 |
tsbere |
jeff: I find myself wondering what the overall issue you are describing is |
| 10:41 |
jeff |
statewide ill system maintains a virtual/shadow/stub patron in their system for each of our patrons that have made requests. this patron record has an expiration date field. |
| 10:41 |
jeff |
under normal circumstances, the expiration date is updated only when a patron makes a request. |
| 10:42 |
jeff |
then when an item is checked out to a patron, the due date will be truncated by the statewide system to the expiration date if it comes before what the calculated (3 weeks later) due date would be. |
| 10:43 |
jeff |
but since the expiration date is updated when the request is placed and not updated before checking the item out, we were attempting to determine a means of alerting staff that they need to manually update the virtual patron record's expiration date by hand. |
| 10:43 |
jeff |
and that was one option that we came up with. |
| 10:44 |
jeff |
for now, it might simply be "always verify that the patron expiration date falls after today + 3 weeks before checking statewide ILL items out to the patron. |
| 10:44 |
jeff |
" |
| 10:44 |
tsbere |
seems like it would make more sense to convince the statewide system to do a "is the patron still valid and what is their current expiration date?" check before determining the due date |
| 10:44 |
jeff |
yes, but that would make sense. |
| 10:45 |
tsbere |
after all, for all the statewide system knows you invalidated the patron for some reason after the request was placed. At "item to fill the request stage" it should really double-check the patron anyway... |
| 10:45 |
jeff |
currently, they're working (for several months now) on getting the expiration date to update at all. the current behavior is that it never updates automatically after the initial virtual patron record is created. |
| 10:45 |
tsbere |
ouch. That sounds annoying. |
| 10:45 |
jeff |
tis. |
| 10:47 |
* tsbere |
would probably have asked if there was an API that could be used to do automatic updates by now and if so write a perl script for cronjob use to update things weekly |
| 10:47 |
jeff |
more annoying to be a patron and have your checkout limited. |
| 10:47 |
jeff |
the api is "wait for us to ask you things via NCIP. respond, and hope that we pay attention someday to things like the patron's new expiration date." :-) |
| 10:48 |
tsbere |
That is a crappy api. :P |
| 10:48 |
jeff |
we also have an option of getting reports from them of our patrons and their expiration dates, which we might opt to do if they can figure out their firewalling issues on their end. |
| 11:00 |
jeff |
starting with a ticket to them to ensure that 1) the behavior is not configurable and 2) we've not missed something like a visual cue in the DCB client or a warning, etc. |
| 11:01 |
jeff |
but if we're looking at needing to manually inspect a patron's expiration date before checking items out to them, we'll probably look at a way to work around that. |
| 11:10 |
graced |
Clearly, you should replace your ILL system with FulfILLment. |
| 11:10 |
graced |
;-) |
| 11:10 |
bshum |
:) |
| 11:10 |
bshum |
graced: It's a nice video, I've been sharing it around. |
| 11:10 |
graced |
thanks bshum |
| 11:11 |
graced |
I was using Jing which has a 5 minute limit so I was rushing a bit |
| 11:11 |
bshum |
I like the update to TPAC. And also ridding ourselves of xul client. |
| 11:12 |
bshum |
It was a nice taste of the potential futures. |
| 11:12 |
graced |
indeed |
| 11:17 |
jeff |
graced: FulfILLment just needs enough connectors to be able to co-exist with a statewide system in a such a way that it can slowly take over, without needing to be a "some people are on X and some people are on Y" scenario. ;-) |
| 11:17 |
graced |
jeff: How many connectors can I sign you up for? |
| 11:17 |
jeff |
:-) |
| 11:19 |
graced |
Based on your statement I think we need a logo for FulfILLment that has more tentacles... |
| 11:20 |
jeff |
were i more artistically-inclined, i'd probably enjoy creating library technology / ILS / vendor propoganda posters. |
| 11:21 |
jeff |
though i'm never quite certain if modern allusions to WWII-era propaganda posters is offensive to some. |
| 11:22 |
jeff |
"something to offend everyone", i guess. |
| 11:25 |
graced |
I've seen library technology posters, I don't think you have to be artistically inclined... |
| 11:27 |
bshum |
Hmm, csharp, I think for new bug 1271218, it might be an interpretation of the wording. When it says "No notification preferences are configured" I think that means server side as far as setting up special opt-in options. |
| 11:27 |
pinesol_green |
Launchpad bug 1271218 in Evergreen "OPAC gives 'No Notification Preferences Are Configured' even when they are" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1271218 |
| 11:27 |
bshum |
Maybe that message shouldn't really exist as is, and the whole block for opt-in disabled unless there actually are opt-in enabled options available for the end users. |
| 11:28 |
bshum |
Ooh |
| 11:28 |
bshum |
Wait, I re-read it again, and now I think I get it. |
| 11:28 |
bshum |
Huh |
| 11:29 |
Dyrcona |
I was going to take a look at that once I get my dev system set up again. |
| 11:30 |
jcamins |
jeff: if you're not creative enough to do agitprop drawing, I recommend manifestoes. Nice, bite-sized absurdism. |
| 11:30 |
* Dyrcona |
waits on a database reload. |
| 11:31 |
Dyrcona |
jeff: You could always take some Soviet WWII posters and have at 'em with GIMP. ;) |
| 11:32 |
jcamins |
"Crush the imperialist under the boot of open source!" |
| 11:32 |
graced |
jcamins++ |
| 11:32 |
jcamins |
"Plan: accomplished! The five year strategic plan has been completed in three and a half years! More than ten million books circulated!" |
| 11:35 |
jcamins |
And, one last caption for jeff's posters: "Hail, fellow bibliophiles! We are proud to welcome you into our ranks!" |
| 11:35 |
csharp |
okay, yeah - we're seeing very long times for hold placement, bshum |
| 11:36 |
csharp |
click Place Hold, wait 30+ seconds, it finally returns |
| 11:36 |
bshum |
Yep, fun times indeed. |
| 11:36 |
csharp |
and that's on our 20Mb connection |
| 11:36 |
bshum |
That one hasn't been bug filed yet. |
| 11:36 |
csharp |
I assume it's the same issue as bug 1185865 |
| 11:36 |
pinesol_green |
Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1185865 |
| 11:36 |
bshum |
Basically. |
| 11:36 |
csharp |
our hold targeter isn't finishing either |
| 11:36 |
bshum |
Should just rename that to "holds SOOOOOO slow" |
| 11:37 |
csharp |
any chance holds proximity adjustment can be disabled? |
| 11:38 |
bshum |
eeevil: see csharp's question --^ |
| 11:38 |
csharp |
our two staff tickets on the issue say "place hold button doesn't do anything" |
| 11:39 |
eeevil |
csharp: you have staff creating adjustments, I take it |
| 11:39 |
csharp |
eeevil: nope - we haven't tested the feature yet |
| 11:40 |
csharp |
it was on our post-upgrade to-do |
| 11:40 |
bshum |
Right, even out of the box, it's been kind of a nightmare. |
| 11:40 |
eeevil |
it requires a permission: ADMIN_PROXIMITY_ADJUSTMENT |
| 11:40 |
eeevil |
out of the box, it's empty |
| 11:41 |
* csharp |
looks |
| 11:41 |
eeevil |
IOW, out of the box, there is no adjustment to turn off |
| 11:42 |
jeff |
csharp: we saw an intermittent issue on a small number of machines (making heavy use of change operator, though that might be a red herring) where the Place Hold button in the staff client was disabled because the javascript that loads the patron name and prefs wasn't completing. |
| 11:44 |
bshum |
It's not so much disabled as it is just taking abnormally long to get to the next step. Either success or failure. At least for us. |
| 11:45 |
csharp |
yeah - that's what I'm seeing too |
| 11:46 |
|
smyers_ joined #evergreen |
| 11:47 |
csharp |
eeevil: I'm going off your comment here https://bugs.launchpad.net/evergreen/+bug/1185865/comments/5 as the basis for my theory that proximity adjustment is the cause of the slowness |
| 11:47 |
pinesol_green |
Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 3, heat: 14) [Undecided,New] |
| 11:48 |
csharp |
is there any way to go *back* to indexed lookup? |
| 11:50 |
|
snowball joined #evergreen |
| 11:50 |
eeevil |
csharp: it's one of many things that was added to 2.4. it's just a theory and a guess, as nobody has attempted to look at it more closely in an environment where the slow down exists. I don't have access to such an environment personally, and haven't see the issue even on the largest systems to which I have access |
| 11:56 |
csharp |
eeevil: curious - are the largest systems you work with using SSDs for storage? |
| 11:56 |
eeevil |
csharp: most, but not all |
| 11:56 |
csharp |
ok |
| 11:56 |
eeevil |
but if it's CPU time of calculating the proximity, SSD doesn't matter |
| 11:56 |
csharp |
ah |
| 11:57 |
* csharp |
hasn't looked closely at the code to see what's what |
| 12:02 |
Dyrcona |
It is on my ever-growing list of things to look at. |
| 12:03 |
bshum |
csharp: I'm going to try asking my people for some specific example bibs that they've had trouble with and then run it through some tests on another server to see if I can get a longer output of what's going on in the behind the scenes. |
| 12:03 |
bshum |
If you see anything interesting, I'd like to compare notes. |
| 12:03 |
csharp |
yeah - that's what I'm doing now too - I'm not even sure of the opensrf call at this point though :-/ |
| 12:04 |
csharp |
in the logs, that is |
| 12:13 |
|
jwoodard joined #evergreen |
| 12:14 |
jeff |
RDA propaganda posters... |
| 12:14 |
|
kbeswick_ joined #evergreen |
| 12:32 |
bshum |
dbwells: I just saw the notification about bug 1261939. Fwiw, the branch worked when I was poking with it. |
| 12:32 |
pinesol_green |
Launchpad bug 1261939 in Evergreen "Add per-library TPAC pages with schema.org structured data support" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261939 - Assigned to Dan Wells (dbw2) |
| 12:33 |
dbwells |
bshum: thanks for the report. Looks good so far for me, hope to have it in today for the alpha cut tomorrow. |
| 12:37 |
bshum |
dbwells: Cool deal, I was going to do one more test before I merged, but since you're on the case, I'll feel better knowing there were more eyes on it. |
| 12:51 |
|
rjackson-isl joined #evergreen |
| 12:57 |
|
mcooper joined #evergreen |
| 13:04 |
Dyrcona |
jeff: "When you ride a lone, you ride with RDA!" |
| 13:05 |
|
sseng joined #evergreen |
| 13:12 |
bshum |
csharp: Are you guys using user defined opt-in for notications? |
| 13:18 |
bshum |
dbs: re bug 1267231, I showed it to my catalogers and they're pleased with the restructuring of the author links. |
| 13:18 |
pinesol_green |
Launchpad bug 1267231 in Evergreen 2.5 "TPAC - added author entries with titles, etc. display" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1267231 |
| 13:18 |
bshum |
dbs: My only wondering is whether 10px padding is too much for the author div tag. Seemed things ended up too far apart for my personal taste, but that might be just me. |
| 13:19 |
bshum |
Granted I'm all thumbs on a phone, so the extra padding is probably quite helpful. |
| 13:20 |
csharp |
bshum: nope we are not |
| 13:23 |
bshum |
Maybe the way that block should work then is to show the table IF ctx.opt_in_settings.size > 0 |
| 13:23 |
bshum |
Otherwise, nothing. |
| 13:23 |
dbs |
bshum: yeah, I played with that for a little bit and decided it was best just to get it out there and have pixel tweaking happen later |
| 13:23 |
bshum |
dbs: Yeah I'm currently playing with 7.5px and 5px to see if it makes my eyes less scared of the extra padding. |
| 13:23 |
bshum |
dbs: But I think maybe I'm just splitting hairs |
| 13:25 |
bshum |
csharp: I might try whipping up a tiny patch to see what it would look like if we restructured in that way. Also whether we need the <div class='user_opt_in_settings'> outside the IF block |
| 13:25 |
bshum |
Maybe we can put it inside and it'll not render the extra div if it isn't needed. |
| 13:29 |
|
dMiller__ joined #evergreen |
| 13:39 |
csharp |
bshum: thanks for taking some time on that |
| 13:40 |
bshum |
csharp: I think it's just interpretation issue. The message isn't there to tell you that the user doesn't have settings set. It's more to tell you that the Evergreen system doesn't have the user opt-in settings configured to give them the choices. |
| 13:40 |
bshum |
But really end-users probably don't need to know that. |
| 13:42 |
bshum |
Either way, probably good to poke at. |
| 13:44 |
pinesol_green |
[evergreen|Dan Scott] TPAC: Use indexed subfields only in author search links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9f7b95c> |
| 13:44 |
pinesol_green |
[evergreen|Dan Scott] TPAC: Display authors using inline-block - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf3b5e0> |
| 13:48 |
Dyrcona |
gmcharlt: Is MARC::File::XML 1.0.2 supposed to be available via CPAN, yet? (I think I may need to wait for my mirror to update.) |
| 13:49 |
gmcharlt |
Dyrcona: yes, it is, but definitely hasn't reached all the mirrors yet |
| 13:50 |
tsbere |
and the fact that our local mirror doesn't always update from the most up to date mirror, and even then only does so nightly, probably isn't helping |
| 13:50 |
bshum |
Do we need to restart anything to upgrade that? |
| 13:50 |
bshum |
*after upgrading |
| 13:51 |
csharp |
gmcharlt: how quickly does Debian accept changed packages in your experience? |
| 13:52 |
pinesol_green |
[evergreen|Pasi Kallinen] LP969312: No warning for Delete All from Catalog in Copy Buckets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a8cb330> |
| 13:53 |
gmcharlt |
csharp: I imagine quite quickly, especially once I finish requesting a CVE number, but there's a snag |
| 13:53 |
gmcharlt |
namely, because dependencies changed from 0.93 to 1.0 of MARC::File::XML, I don't know if it would hit wheezy |
| 13:54 |
csharp |
eww |
| 13:54 |
* csharp |
wonders if it will make it to 12.04 |
| 13:55 |
Dyrcona |
bshum: You should not have to restart anything after upgrading MARC::File::XML. |
| 13:56 |
jeff |
this makes it likely that the debian maintainer or debian security team would (at least attempt to) backport just the fix, leaving the version number the same. |
| 13:56 |
Dyrcona |
Only if you had the Perl modules preloaded in your PostgreSQL config, then you might have to restart PostgreSQL. |
| 14:01 |
gmcharlt |
there are other reasons to upgrade to 1.0.2, though -- speedier processing of MARCXML being the main one |
| 14:01 |
gmcharlt |
(that is, if you're currently running 0.93) |
| 14:01 |
bshum |
csharp: I updated the bug with a comment and link to some working code switching -- https://bugs.launchpad.net/evergreen/+bug/1271218/comments/3 |
| 14:01 |
pinesol_green |
Launchpad bug 1271218 in Evergreen "OPAC gives 'No Notification Preferences Are Configured' even when they are" (affected: 1, heat: 6) [Low,Confirmed] |
| 14:02 |
bshum |
I have to test and see what happens if you do have opt-in settings configured. But it should work, I think. |
| 14:10 |
kmlussier |
csharp: Were you on 2.4 before your upgrade this weekend? |
| 14:11 |
bshum |
I think they were on 2.3. |
| 14:13 |
Dyrcona |
csharp: Is there an official maintainer for the library-related Perl packages on Ubuntu? |
| 14:14 |
csharp |
kmlussier: 2.3.6 |
| 14:14 |
csharp |
Dyrcona: I don't know, I can look |
| 14:15 |
kmlussier |
csharp: OK, thanks. For some reason I had been thinking it was 2.4. I had a sudden fear we would be seeing even more holds targeter slowness in the next upgrade. |
| 14:15 |
csharp |
kmlussier: okay - so you're seeing holds slowness too? |
| 14:15 |
Dyrcona |
csharp: For trusty, it says the ubuntu-motu developers. |
| 14:15 |
csharp |
yeah |
| 14:15 |
csharp |
same for precise |
| 14:16 |
csharp |
that probably means they just rely on the upstream maintainers ;-) |
| 14:17 |
csharp |
one of the complaints about Ubuntu - standing on the shoulders of giants (and others) |
| 14:17 |
kmlussier |
csharp: Yes, I've heard it from C/W MARS. NOBLE just upgraded a couple of weeks ago, so I'm not sure if they've seen it. |
| 14:18 |
csharp |
okay - just keeping a head count since eeevil said he's not seeing it |
| 14:21 |
Dyrcona |
We've seen hold targeting slowness. |
| 14:34 |
|
kbeswick joined #evergreen |
| 14:58 |
pinesol_green |
[evergreen|Steven Callender] Fixed title/author display at checkout for non-pre-cat items. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3bc7d49> |
| 15:03 |
|
finnx_ joined #evergreen |
| 15:04 |
|
finnx joined #evergreen |
| 15:04 |
dbwells |
grabbing 0853 |
| 15:07 |
|
finnx joined #evergreen |
| 15:09 |
|
ericar joined #evergreen |
| 15:10 |
pinesol_green |
Showing latest 5 of 10 commits to Evergreen... |
| 15:10 |
pinesol_green |
[evergreen|Dan Scott] Improve label for library's external web site - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac5acbf> |
| 15:10 |
pinesol_green |
[evergreen|Dan Scott] Copy details link to Evergreen library page by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2a2fcf4> |
| 15:10 |
pinesol_green |
[evergreen|Dan Scott] Add upgrade script for lib.prefer_external_url OUS - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=796eff6> |
| 15:10 |
pinesol_green |
[evergreen|Dan Scott] Release notes for the TPAC library web pages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46f4917> |
| 15:10 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0853: 'Prefer external URL' OUS - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3699196> |
| 15:24 |
|
stevenyvr joined #evergreen |
| 15:28 |
|
mmorgan1 joined #evergreen |
| 15:56 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Serials: improve routing slips per Dan Wells' suggestions on LP #1229349 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8d37382> |
| 16:08 |
dbs |
dbwells++ # good comments on the per-library TPAC pages |
| 16:29 |
kmlussier |
@wunder 02771 |
| 16:29 |
pinesol_green |
kmlussier: The current temperature in Ladd Observatory, Providence, Rhode Island is 11.5°F (4:28 PM EST on January 21, 2014). Conditions: Light Snow. Humidity: 86%. Dew Point: 8.6°F. Windchill: -0.4°F. Pressure: 29.91 in 1013 hPa (Falling). Winter Storm Warning in effect until 1 PM EST Wednesday... |
| 16:33 |
dbs |
@wunder sudbury, ontario |
| 16:33 |
pinesol_green |
dbs: The current temperature in Sudbury, Ontario is -9.4°F (4:00 PM EST on January 21, 2014). Conditions: Partly Cloudy. Humidity: 59%. Dew Point: -20.2°F. Windchill: -22.0°F. Pressure: 30.23 in 1024 hPa (Steady). |
| 16:34 |
dbs |
On the way back down now... |
| 16:35 |
jeff |
temp, pressure, or both? |
| 16:36 |
dbs |
Both temperature and pressure are dropping. Whee! |
| 16:41 |
|
snowball joined #evergreen |
| 16:45 |
|
gmcharlt joined #evergreen |
| 17:09 |
|
mmorgan1 left #evergreen |
| 17:23 |
pinesol_green |
[evergreen|Remington Steed] LP#842991 Reports needs to error when deleting fails - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=400c9c6> |
| 17:23 |
|
dcook joined #evergreen |
| 17:47 |
|
mrpeters left #evergreen |
| 17:53 |
|
dMiller__ joined #evergreen |
| 18:18 |
|
BigRig joined #evergreen |
| 19:28 |
|
ktomita_ joined #evergreen |
| 19:35 |
|
afterl left #evergreen |
| 19:35 |
|
ktomita joined #evergreen |
| 19:58 |
|
remingtron joined #evergreen |
| 20:47 |
|
zxiiro joined #evergreen |
