Time |
Nick |
Message |
04:34 |
|
artunit_away_ joined #evergreen |
04:38 |
|
webmind_ joined #evergreen |
05:14 |
|
justdoglet joined #evergreen |
05:39 |
|
gsams joined #evergreen |
06:39 |
|
justdoglet joined #evergreen |
06:49 |
|
jyorio joined #evergreen |
06:49 |
|
abowling joined #evergreen |
06:49 |
|
jonadab joined #evergreen |
07:18 |
|
rjackson_isl joined #evergreen |
07:28 |
|
maryj joined #evergreen |
07:36 |
|
graced joined #evergreen |
08:05 |
|
mrpeters joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
08:41 |
|
kmlussier joined #evergreen |
08:58 |
|
Dyrcona joined #evergreen |
09:03 |
Dyrcona |
oc-FR: Occitan, France, not French. The first two are the language and the second are the country. |
09:04 |
Dyrcona |
ar-AR: Arabic, Argentina. Always found that amusing, but there is apparently a tradition of repeating the language code when the country is not known or irrelevant. |
09:04 |
Dyrcona |
Anyway, gonna reply to gmcharlt's email about the threshold of completeness. |
09:07 |
remingtron |
tsbere++ #for sharing 'git whatchanged' yesterday |
09:08 |
tsbere |
remingtron: Happy to help, I almost want to set things up so that "git log" runs "git whatchanged" instead some days... |
09:08 |
tsbere |
But then I will forget that I am really running whatchanged, and will get confused when people can't see filenames, so I probably shouldn't |
09:12 |
remingtron |
tsbere: true, that's the trouble with command aliases |
09:13 |
Dyrcona |
git log -p shows all the diffs |
09:13 |
Dyrcona |
Which is more than whatchanged, but handy some times. |
09:16 |
|
bos20k joined #evergreen |
09:26 |
* tsbere |
got curious about log vs whatchanged, and it looks like "git whatchanged" may be a shortcut for "git log --no-merges --sparse --raw" |
09:27 |
Dyrcona |
Well, whatchanged is a bit easier to type. :) |
09:29 |
tsbere |
Apparently whatchanged comes from an era where log didn't know how to show diffs of any kind. A year or so later they taught log how to load diffs. |
09:35 |
jeff |
and around that time, changed "whatchanged" to an alias for the equivalent new functionality in log? |
09:38 |
tsbere |
jeff: I believe that happened at or shortly after that point, I haven't gone looking for commits or anything |
09:38 |
* jeff |
nods |
09:43 |
tsbere |
As Dyrcona said, "git whatchanged" is easier to type. And remember. |
09:46 |
Dyrcona |
Uh-huh....autogen.sh says cstore is NOT CONNECTED TO THE NETWORK!!! |
09:46 |
Dyrcona |
osrf_control --localhost --diagnostic says it is. |
09:47 |
Dyrcona |
Hmm... Maybe I ran autogen.sh too soon after starting services. :) |
10:02 |
kmlussier |
On bug 1528647, since terran is changing the author to Bob Wicksall, and has hasn't signed off on the bug, should Bob add a DCO to the LP bug before the code gets merged? |
10:02 |
pinesol_green |
Launchpad bug 1528647 in Evergreen "Self-check only accepts user name value if regex for barcode not set up" [Undecided,New] https://launchpad.net/bugs/1528647 |
10:03 |
csharp |
@seen bwicksall |
10:03 |
pinesol_green |
csharp: I have not seen bwicksall. |
10:04 |
Bmagic |
Dyrcona: The sandbox is up and I don't have any plans to take it down. You have several weeks |
10:04 |
Dyrcona |
Bmagic: Thanks. I saw what I needed to see last night. |
10:05 |
Dyrcona |
I have a sandbox of my own to test the fix. |
10:05 |
* Dyrcona |
can't believe he made such a silly error. ;) |
10:06 |
kmlussier |
@dessert 36 [someone] |
10:06 |
* pinesol_green |
grabs some Boston Cream doughnuts for serflog |
10:06 |
Dyrcona |
Well, he can, but.... |
10:06 |
kmlussier |
In honor of National Doughnut Day |
10:07 |
* kmlussier |
doesn't think serflog can truly appreciate a good doughnut |
10:08 |
gsams |
heh, I bought some for the staff today |
10:09 |
kmlussier |
gsams++ # Making staff happy with doughnuts |
10:09 |
kmlussier |
@decide doughnut or donut |
10:09 |
pinesol_green |
kmlussier: go with doughnut |
10:11 |
|
afterl joined #evergreen |
10:15 |
* kmlussier |
will add a comment to the bug regarding the DCO |
10:27 |
Dyrcona |
@decide donut or donut |
10:27 |
pinesol_green |
Dyrcona: That's a tough one... |
10:27 |
Dyrcona |
:) |
10:27 |
Dyrcona |
@decide cruller or fritter |
10:27 |
pinesol_green |
Dyrcona: go with cruller |
10:29 |
gsams |
I feel like pinesol_green is nailing it today |
10:29 |
kmlussier |
Yes, I agree, The cruller is a better choice. |
10:30 |
gmcharlt |
@decide Dunkin Donuts or Krispy Kreme |
10:30 |
pinesol_green |
gmcharlt: go with Krispy Kreme |
10:30 |
gmcharlt |
pinesol_green: you are wrong. your wrongness is immense. |
10:30 |
pinesol_green |
gmcharlt: No, you're a puzzleheaded kraken! |
10:30 |
pinesol_green |
In #evergreen, gmcharlt said: pinesol_green: you are wrong. your wrongness is immense. |
10:30 |
gsams |
well, it had a good run |
10:30 |
* kmlussier |
has never had a Krispy Kreme doughnut |
10:30 |
gsams |
My advice is to not |
10:31 |
gsams |
my opinion of course |
10:31 |
kmlussier |
But, even though I'm from the land of Dunkin Donuts, I have to say I've never been impressed with their doughnuts. |
10:31 |
* Dyrcona |
likes Heav'nly Donuts better than Dunkin'. |
10:31 |
gsams |
I prefer a local shop myself, though we don't have a lot of Dunkin's around here. |
10:31 |
bshum |
Pfft, I like Krispy Kremes :( |
10:32 |
|
Christineb joined #evergreen |
10:32 |
kmlussier |
Dunkin's coffee is okay, as long as you don't get it in the afternoon when it takes on a decidedly burnt taste. |
10:32 |
Dyrcona |
Heav'nly is more local than Dunkin' and a much smaller chain. |
10:32 |
kmlussier |
Yeah, I like Honey Dew Donuts, which is a much smaller chain too |
10:33 |
* tsbere |
prefers Heav'nly to Dunkins, but has no experience with Honey Dew |
10:33 |
gsams |
I go to a local shop called Donut Paradise, really nice lady, supports our summer reading program |
10:36 |
kmlussier |
terran++ # For organizing a great Bug Squashing Day! |
10:36 |
kmlussier |
That I mostly missed. :( |
10:49 |
Dyrcona |
Whee! Fun with new MARC templates: subfield s comes before subfield b in this tag.... |
10:52 |
* Dyrcona |
hands himself a lollipop. :) |
11:02 |
|
jvwoolf joined #evergreen |
11:04 |
rjackson_isl |
all this talk of donuts reminds me of an Indiana chain closed down years ago due to "extra" ingredients added by the 4 legged residents of the shop! :( |
11:05 |
kmlussier |
Ewwww |
11:05 |
rjackson_isl |
fur sure |
11:12 |
jeff |
woohoo! found more hidden-but-useful options in a vendor product. |
11:13 |
berick |
rjackson_isl: sprinkles! |
11:13 |
rjackson_isl |
rice |
11:14 |
Dyrcona |
chocolate rice. |
11:15 |
mmorgan |
What kmlussier said: Ewwww... |
11:22 |
berick |
haha |
11:24 |
* Dyrcona |
is going to try webalizer on the public opac logs to see if our usage has been going up. |
11:25 |
* Dyrcona |
is trying to figure out why we've started having issues after all these months. |
11:26 |
Dyrcona |
Bmagic: Have you worked anything out with your Apache issues? |
11:27 |
Dyrcona |
I increased our settings for MinSpareServers, MaxSpareServers, and let MaxRequestWorkers go to the default, and things have apparently improved for us. |
11:27 |
Bmagic |
Dyrcona: it's a tough nut to crack because it only shows its ugly face during load. We did tweak some settings in lvs: ipvsadm --set 30 30 45 |
11:28 |
Dyrcona |
Bmagic: So, what does that do? |
11:28 |
Bmagic |
Dyrcona: what numbers are you using for those Apache settings? |
11:28 |
Bmagic |
http://linuxcommand.org/man_pages/ipvsadm8.html |
11:28 |
Dyrcona |
MinSpareServers: 20 MaxSpareServers: 40 StartServers: 100 |
11:28 |
Bmagic |
The first number is tcp timeout, the second is after the fin packet and the third number is udp (probably unused) |
11:29 |
Dyrcona |
MaxRequestWorkers is commented out, so it gets the default of 256. |
11:29 |
Bmagic |
Without configuring LVS, the defaults were very high, like lvs was hanging onto connections for 2 minutes after the fin packet |
11:31 |
Dyrcona |
OK. We're just using kvm and libvirt. |
11:31 |
Bmagic |
We are seeing much lower numbers in our LVS connection report (ipvsadm -L) |
11:32 |
Dyrcona |
So then it appears to have helped to lower the timeouts. |
11:32 |
Dyrcona |
That's good. |
11:32 |
Bmagic |
and Apache hasn't been getting clobered on the app servers. CPU is hovering around 1 on each of the 8 |
11:33 |
Bmagic |
however, we have started getting reports of SIP connections not working, and hold requests (of all things) not giving the UI the "submit" button |
11:33 |
JBoyer |
Unless I can't math (checked twice) the default TCP timeout for ldirector/LVS is 15 minutes. I'm losing my mind here. |
11:33 |
Bmagic |
JBoyer: yes, I believe you are correct - we changed that to 30 seconds |
11:33 |
Dyrcona |
JBoyer: I lost mine a long time ago. ;) |
11:34 |
Bmagic |
JBoyer: I was talking about the other setting "TCPFIN" which is defaulted to 120 seconds |
11:34 |
Dyrcona |
Somebody said something about the keep alive setting in Apache the other day...... |
11:34 |
* Dyrcona |
searches logs. |
11:35 |
Bmagic |
JBoyer: Like I said though, Im not entirely sure that we are out of the woods. We have been getting reports of hold requests UI and Overdrive SIP auth failing now with the new LVS config |
11:35 |
berick |
Dyrcona: me. keepalive should be 1. |
11:35 |
JBoyer |
Ah, lots of closed connections just waiting to fall off. |
11:35 |
Dyrcona |
Yep, just found it. |
11:35 |
JBoyer |
Well, the command you posted shows that both the TCP and TCPFIN were set to 30, raising the first one to 60 or 120 may help with those other issues |
11:36 |
Bmagic |
keepalive was set to 5 for us at the beginning of the issues, Changing that to 1 had a profound impact on performance. The CPU's on the bricks never went out of control again, but we still had a "slowness" issue (which in my theory was due to apache not having enough workers to serve everyone, and they had to wait) |
11:37 |
Dyrcona |
That's interesting. Ours is set to 5 still. |
11:37 |
Dyrcona |
I'll try changing that when it acts up again. |
11:38 |
Dyrcona |
Wonder if outright disabling keepalive would help....probably not. |
11:38 |
JBoyer |
Bmagic, are you using persistent connections at all in lvs? |
11:38 |
Bmagic |
Dyrcona: Yes, I believe it needs to be set to 1. The Evergreen install instructions even say that, lol |
11:39 |
Bmagic |
Dyrcona: We did disable keepalive on one brick just to see. We didn't see any difference between off and 1 |
11:39 |
Dyrcona |
Bmagic: Yep. They do. |
11:39 |
* Dyrcona |
fixes that... |
11:39 |
|
brahmina_ joined #evergreen |
11:40 |
Bmagic |
JBoyer: no we are not using persistent currently. We used to use that because there was an issue with SSL connections needing to stay on the same brick |
11:46 |
Dyrcona |
Whee! 161 zombie after apache2 reload.... |
11:46 |
Dyrcona |
And now, 0 zombies. |
11:49 |
* Dyrcona |
gives it 15 minutes or so for the load to settle to see if that helped. |
11:51 |
|
bmills joined #evergreen |
11:53 |
|
rlefaive joined #evergreen |
11:58 |
Stompro |
Hello All, is the staff member that canceled a hold recorded anywhere that is accessible in the staff client? I'm looking through the column picker in the canceled hold screen and nothing is leaping out at me. |
12:00 |
jeff |
Stompro: nope, as that information is not stored in the database. |
12:00 |
jeff |
Stompro: cancel time, cause, and note is it. |
12:00 |
Dyrcona |
Stompro: Doesn't look like that information is available in the database, either. |
12:01 |
Stompro |
Thanks |
12:01 |
jeff |
Stompro: there is some information you could get from logs, and the audit user and audit ws *might* be stored if you have enabled auditing on the action.hold_request table (it isn't audited by default). |
12:02 |
* Dyrcona |
was gonna mention the logs might be useful. |
12:02 |
jeff |
Stompro: do you mind if i remove you as assignee on bug 1519879? I'm not sure if you're actively working on it. |
12:02 |
pinesol_green |
Launchpad bug 1519879 in Evergreen "SIP Precedence Warning, possible logic issue" [Undecided,Confirmed] https://launchpad.net/bugs/1519879 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
12:04 |
Stompro |
jeff, no go right ahead, I haven't done any work on that, just throught about it. |
12:04 |
|
jihpringle joined #evergreen |
12:04 |
|
bmills joined #evergreen |
12:06 |
jeff |
I think that (rather than fix the precedence issue), we can remove both the user active and the card active checks, as they are redundant with code elsewhere. |
12:07 |
jeff |
And the only effective change will be that we will no longer block patrons whose primary card is inactive, but they were retrieved by an active card. :-) |
12:07 |
jeff |
(there are actually other issues with that -- SIP2 code has some problems with multiple cards in general, but that's somewhat tangental) |
12:16 |
jeff |
web staff client does not currently require a workstation, and i think in some ways that may be a good thing. |
12:16 |
jeff |
but there are other ways in which it is probably a bad thing, such as lacking a workstation on payments. |
12:16 |
Dyrcona |
yep. |
12:17 |
jeff |
cash payment doesn't fail on lack of workstation, which it probably should. |
12:17 |
Dyrcona |
or if I login as myself, and everything happens at my home library as a patron, when it should happen at my work_ou. |
12:17 |
jeff |
(at a low level) |
12:17 |
JBoyer |
jeff, I thought that was also in the process of being "corrected." |
12:17 |
mmorgan |
Stompro: lp 1501790 |
12:17 |
pinesol_green |
Launchpad bug 1501790 in Evergreen "action.hold_request should store user and workstation ids related to the cancellation" [Wishlist,New] https://launchpad.net/bugs/1501790 |
12:18 |
jeff |
JBoyer: I think I've been part of a conversation or two regarding that, but I'm not sure if there's any active work or bug toward changing it -- which was part of my reason for bringing it up again. :-) |
12:18 |
kmlussier |
I would prefer that the web client require a workstation. |
12:18 |
JBoyer |
I see. I may have misremembered any progress on it. I'm with kmlussier though, WS or OPAC. |
12:18 |
kmlussier |
At the moment, if you don't have a registered workstation, there are lots of things that don't work properly. |
12:19 |
kmlussier |
JBoyer: There is a bug with plans. But I don't know if anyone is actively working on it. |
12:20 |
JBoyer |
Ok, so that's what I'm remembering. Maybe I should poke about if I could ever find the time. :/ |
12:21 |
* kmlussier |
just noticed bug 1529892. |
12:21 |
pinesol_green |
Launchpad bug 1529892 in Evergreen "Web Client: Wish List - Make it more obvious when there isn't a workstation" [Undecided,New] https://launchpad.net/bugs/1529892 |
12:21 |
JBoyer |
So, Launchpad search, we meet again, for the last time. |
12:21 |
kmlussier |
I'll add my opinion there too. |
12:21 |
kmlussier |
JBoyer: The discussion is on bug 1467663 |
12:21 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,New] https://launchpad.net/bugs/1467663 |
12:25 |
|
brahmina joined #evergreen |
12:32 |
|
brahmina_ joined #evergreen |
12:53 |
|
tspindler joined #evergreen |
13:10 |
Dyrcona |
And, webalizer churns through a 1.7GB gzip file. |
13:57 |
|
ssieb joined #evergreen |
14:03 |
|
tspindler left #evergreen |
14:13 |
|
bmills joined #evergreen |
14:46 |
Dyrcona |
You know you're lazy when you're using perl one liners on the command line as a calculator. |
14:46 |
Dyrcona |
perl -e 'print 100/38.9 . "\n";' |
14:47 |
miker |
Dyrcona: easier to remember than the correct syntax for bc |
14:47 |
Dyrcona |
Yep, and faster than moving the fingers from the keyboard to open the graphical calculator on the local desktop. |
14:49 |
Dyrcona |
Plus, I get decimals without needing it on both sides. |
14:50 |
Dyrcona |
BTW, that's my speed up using dbwells patch for metabib.reingest_record_attrs, approximately 2.5X. |
14:51 |
Dyrcona |
I think my db hardware is the biggest bottleneck in this case. |
14:52 |
dbwells |
Dyrcona: cool, thanks for the update. The 7x in my test was for just the attribute reingest step isolated, so it is expected that the overall speedup will be less than that. |
14:53 |
Dyrcona |
dbwells: my measurements both times were made with this query: SELECT COUNT(metabib.reingest_record_attributes(id)) FROM biblio.record_entry; |
14:54 |
Dyrcona |
I included deleted ones, both times. |
14:54 |
Dyrcona |
Still, any increase is better than nothing.... |
14:54 |
dbwells |
Oh, ok. |
14:54 |
Dyrcona |
26 hours after the patch versus 67 before. |
14:55 |
* Dyrcona |
can't get webalizer to build a proper index page. |
14:56 |
Dyrcona |
I keep running into this: http://askubuntu.com/questions/638887/webalizer-shows-only-2-months-on-summary-page-ubuntu-14-04 |
15:07 |
Dyrcona |
Yay. It worked from the tarball! |
15:19 |
Dyrcona |
So, it shows that hits have generally trended up but not much, while the number of files served has gone up, even over months where the # of hits are basically the same. |
15:23 |
Bmagic |
Is not being able to change your phone number in the OPAC "by design" ? Or is there a setting that I am missing? |
15:24 |
tsbere |
Bmagic: I don't recall it ever being implemented, at least. Though you can change the default hold notification phone number. |
15:24 |
* tsbere |
suspects it is similar to "don't let them change their address(es)" |
15:25 |
Bmagic |
hmmm, the address change is in the OPAC |
15:25 |
tsbere |
Bmagic: Postal address(es), not email address |
15:26 |
Bmagic |
tsbere: that is what I meant, postal address is editable in the OPAC currently. So why not the phone number? |
15:26 |
tsbere |
I wasn't aware postal address was editable |
15:27 |
tsbere |
In fact, in MVLC's catalog, at least, it doesn't appear to be |
15:28 |
Bmagic |
oh, oops, you're right (I misunderstood at a glance when I saw "pending") |
15:28 |
Bmagic |
Well, we have some call for allowing the patron change their phone number. Is there a reason we shouldn't? |
15:29 |
tsbere |
Bmagic: Which one? :P |
15:29 |
Bmagic |
any or all three I would guess |
15:30 |
berick |
you can create pending addresses in the catalog, but staff have to approve them via the user editor |
15:30 |
berick |
if the feature is enabled |
15:31 |
Bmagic |
berick: I was about to say that |
15:31 |
Bmagic |
(I thought so!) |
15:32 |
tsbere |
Bmagic: Staff verification, I guess? :P Add "Pending Phone Numbers"? |
15:32 |
Bmagic |
I suppose. Not sure why though |
15:33 |
kmlussier |
I would think staff verification is needed more for addresses than for phone numbers. |
15:33 |
jeff |
phone numbers are easier (and cheaper) to verify in an automated fashion. |
15:33 |
Bmagic |
I think that leaving it the way it is might be the best course. Because the hold notification business is really the main function of the OPAC, and they can change that! |
15:34 |
jeff |
but yes, i'd like to make it (optionally?) easier for patrons to update their contact info. |
15:35 |
jeff |
for those of you with "sms" notification options enabled for your patrons: would you be willing to share volume statistics, especially if i crafted the query required? |
15:36 |
jeff |
i'd like to get a sense of what it might cost "the average library" to move away from the sms-via-email-gateways approach. |
15:36 |
tsbere |
jeff: I have some queries for statistics already, though I don't know if they would tell you what you want to know. |
15:37 |
jeff |
roughly, "number of email messages sent via sms gateway grouped by day/month/year/something" |
15:37 |
jeff |
broken down by something like A/T hook type. |
15:37 |
jeff |
(since i wouldn't want to rely on stock event_def ids, etc) |
15:39 |
* mmorgan |
would be willing to run a query for sms stats |
15:43 |
phasefx |
hey guys, what could cause the staff client to create a hold transit with the same source and destination orgs? |
15:43 |
tsbere |
capture local holds as transits |
15:43 |
jeff |
"capture local holds as transits" |
15:44 |
jeff |
we use that routinely |
15:44 |
phasefx |
not really familiar with that, what is it, an org setting? |
15:44 |
tsbere |
Modifier |
15:44 |
jeff |
checkin modifier |
15:44 |
phasefx |
ah! |
15:44 |
jeff |
also SIP setting |
15:44 |
phasefx |
jeff++ tsbere++ |
15:44 |
tsbere |
Originally written to be a SIP setting |
15:44 |
* jeff |
nods |
15:44 |
tsbere |
But I added the modifier so I didn't have to use SIP to test |
15:44 |
|
jvwoolf joined #evergreen |
15:44 |
tsbere |
and then decided "this is useful" and left it in the client |
15:45 |
jeff |
useful for: copy has been checked in, but is currently sitting at the bottom of a sorter bin and is not actually ready for pickup yet. |
15:45 |
tsbere |
Yep. Also useful for "We can't actually give you this for three days due to the release date, but want to get holds capturing now" |
15:45 |
jeff |
also useful for: "we sometimes check in items at this desk, but we do not want to print hold slips or have the hold become available until it is actually checked in where normal holds are scanned", etc. |
15:46 |
tsbere |
Can be good for "the library is closed for a week, but we are processing transit bins anyway" too |
15:46 |
* jeff |
deletes line saying similar |
15:46 |
phasefx |
trippy :) thanks guys |
15:47 |
jeff |
just remember: if you're closed for a week and then you have more holds go "available" in one day than you've ever had before... keep an eye on your automated phone notification runtime. |
15:49 |
jeff |
"hi, I got a call that my hold was ready... at 1 AM?" |
15:50 |
kmlussier |
tsbere / jeff: Wow! It's as if you practiced that routine in anticipation of phasefx asking the question. |
15:50 |
Bmagic |
new wishlist bug 1588953 |
15:50 |
pinesol_green |
Launchpad bug 1588953 in Evergreen "WISHLIST: Allow patrons to change account phone number in OPAC My Account Preferences" [Undecided,New] https://launchpad.net/bugs/1588953 |
15:53 |
jeff |
kmlussier: glad you enjoyed the performance! |
15:54 |
kmlussier |
I wish I had thought to make some popcorn ahead of time. |
15:54 |
* mmorgan |
could never come up with any use for capture holds as transits before. |
15:54 |
tsbere |
mmorgan: Now you have a whole pile! ;) |
15:56 |
jeff |
if we were still doing the thing that caused us to desire something like "hold capture verify", and both "hold capture verify" and "capture local holds as transits" existed, we'd probably opt to use "capture local holds as transits" |
15:57 |
mmorgan |
We've had staff users occasionally turn it on by mistake and be VERY confused. |
15:59 |
jeff |
tsbere++ for providing some stats from existing infrastructure |
15:59 |
jeff |
mmorgan++ for being willing to also provide stats |
15:59 |
jeff |
i'll probably throw a query out to the list if i remember to next week. |
16:13 |
|
jlitrell joined #evergreen |
16:14 |
* jeff |
discards draft email requesting gitadmin@ create top-level Hatch repo |
16:14 |
jeff |
(since it already exists!) |
16:16 |
mmorgan |
Hmm. So working in the web client, I'm noticing lots of warnings about unsaved data when leaving a page. |
16:16 |
kmlussier |
mmorgan: Which page? |
16:16 |
mmorgan |
Both in the patron editor and item editor. |
16:17 |
kmlussier |
mmorgan: Take a look at bug 1581196 |
16:17 |
pinesol_green |
Launchpad bug 1581196 in Evergreen "webstaff: fix dirty form detection for the patron editor" [Medium,Confirmed] https://launchpad.net/bugs/1581196 |
16:17 |
kmlussier |
There's a patch there that I don't think has been merged to master |
16:18 |
mmorgan |
Ok, that looks promising. |
16:18 |
mmorgan |
kmlussier++ |
16:18 |
kmlussier |
mmorgan: However, it doesn't ook like it touches the copy editor. |
16:20 |
kmlussier |
ook, that's a new word |
16:20 |
mmorgan |
Been looking mostly at the patron editor, will need to try the copy editor again to be sure. |
16:20 |
mmorgan |
Ook! |
16:20 |
mmorgan |
I like it :) |
16:21 |
berick |
don't ook at me, I'm hiddeous |
16:26 |
JBoyer |
berick, I think you mean iddeous. :D |
16:27 |
jeff |
berick: i rebased collab/berick/hatch2 to eliminate the root commit (the "random" repo readme) and pushed to http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/jeff/master_candidate -- do you have thoughts/objections/alternate plans regarding this becoming the master branch on the top-level Hatch.git repo? |
16:27 |
|
afterl left #evergreen |
16:27 |
jeff |
berick: as a next step in making Hatch be a "thing that exists outside the random repo"? |
16:28 |
berick |
JBoyer: :) |
16:28 |
berick |
jeff: no objections. |
16:28 |
berick |
and thanks! |
16:28 |
tsbere |
jeff: I think I remember making that repo at a hackaway. |
16:36 |
jeff |
that moment when you think you're starting to understand git, then you run "git gc" and your repo swells by a third. |
16:37 |
kmlussier |
There a moment when you think you're starting to understand git? |
16:37 |
kmlussier |
*There's |
16:37 |
tsbere |
jeff: I had that happen at least twice. Once when a sparse file stopped being sparse and another time when it de-compressed a few things that had previously been compressed. |
16:37 |
jeff |
kmlussier: I know -- the epitome of hubris, right? |
17:03 |
jeff |
anyway, Hatch has a home outside of random now: http://git.evergreen-ils.org/?p=Hatch.git;a=summary |
17:04 |
|
gsams_ joined #evergreen |
17:06 |
|
gsams joined #evergreen |
17:12 |
|
mmorgan left #evergreen |
17:13 |
|
jvwoolf left #evergreen |
17:19 |
kmlussier |
jeff++ |
17:28 |
kmlussier |
@quote random |
17:28 |
pinesol_green |
kmlussier: Quote #67: "< Rogan_Ni> Star Wars" (added by berick at 01:38 PM, September 17, 2013) |
17:38 |
|
mrpeters left #evergreen |
17:43 |
Bmagic |
berick++ |