| Time |
Nick |
Message |
| 03:04 |
|
RBecker joined #evergreen |
| 03:58 |
|
RBecker joined #evergreen |
| 04:22 |
|
RBecker joined #evergreen |
| 04:36 |
|
RBecker_ joined #evergreen |
| 04:38 |
|
fparks joined #evergreen |
| 04:38 |
|
sseng joined #evergreen |
| 04:54 |
|
RBecker joined #evergreen |
| 04:54 |
|
bshum joined #evergreen |
| 04:55 |
|
RBecker joined #evergreen |
| 06:30 |
|
mtcarlson_away joined #evergreen |
| 07:12 |
|
timhome joined #evergreen |
| 07:19 |
csharp |
@quote random |
| 07:19 |
pinesol_green |
csharp: Quote #5: "<senator> the armenian regression sounds like a spy novel" (added by bshum at 03:44 PM, February 22, 2011) |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:51 |
|
kmlussier joined #evergreen |
| 08:14 |
|
collum joined #evergreen |
| 08:22 |
|
rjackson-isl joined #evergreen |
| 08:32 |
|
Shae joined #evergreen |
| 08:42 |
|
RoganH joined #evergreen |
| 08:49 |
|
akilsdonk joined #evergreen |
| 08:49 |
|
mrpeters joined #evergreen |
| 08:54 |
|
ericar joined #evergreen |
| 08:57 |
|
mmorgan joined #evergreen |
| 09:12 |
|
Keggle joined #evergreen |
| 09:12 |
|
mdriscoll joined #evergreen |
| 09:15 |
Keggle |
if possible could someone point me to information on migrating/updating OPAC to TPac? |
| 09:16 |
kmlussier |
Keggle: http://docs.evergreen-ils.org/2.5/_designing_your_catalog.html might be a good place to start. |
| 09:17 |
|
goooood joined #evergreen |
| 09:18 |
|
mdriscoll1 joined #evergreen |
| 09:19 |
|
mtcarlsoz joined #evergreen |
| 09:20 |
|
danzewa joined #evergreen |
| 09:20 |
RoganH |
Keggle: depending on your needs the TPAC works out of the box for a lot of people. Many just fiddle with the CSS, add logos and links a bit then maybe simplify the search options and those can be done fairly easily. |
| 09:21 |
Keggle |
I am starting to gather that we are going to need to update our whole system haha |
| 09:21 |
RoganH |
What version of Evergreen are you on? |
| 09:22 |
Keggle |
me and my IT team kind of " inherited " this Evergreen install and have had to correct MANY mistakes and errors from the old migration |
| 09:22 |
Keggle |
our client is 2.3.2 |
| 09:22 |
RoganH |
Not unusual with any big IT project really. |
| 09:23 |
RoganH |
That's not horrible. I was afraid you were going to say 1.4.1 or something :) |
| 09:23 |
Keggle |
haha |
| 09:23 |
Keggle |
is the TPAC strictly packaged with newer compilations of Evergreen? |
| 09:24 |
RoganH |
I'm not sure what you mean by strictly in this context. Do you mean exclusively? |
| 09:25 |
|
karjak joined #evergreen |
| 09:25 |
RoganH |
You might be able to run the JSPAC with newer versions but if you can I think you'd find a lot of challenges. The community development has strongly moved away from it. |
| 09:25 |
Keggle |
we were hoping to update the Catalog seperately |
| 09:26 |
Keggle |
there are many fixes needed before we feel comfortable with updating the whole system |
| 09:26 |
RoganH |
The TPAC still has a list of features that haven't caught up with JSPAC but it also has some advantages so that's a decision everyone has to make for themselves. |
| 09:26 |
kmlussier |
Keggle: tpac can be run on a 2.3 system if you're looking to update just the catalog. |
| 09:26 |
kmlussier |
We went live on 2.2 with tpac. |
| 09:29 |
RoganH |
If you're looking to update the system without the OPAC that might be more of a challenge. I don't know off hand of any parties using JSPAC with newer (2.4, 2.5) versions but that may just be my ignorance. |
| 09:35 |
Keggle |
the library staff is very much interested in getting rid of the current JSPAC |
| 09:36 |
bshum |
To my recollection, JSPAC had some compatibility issues that prevents it from working with more recent browsers. You're best off making the transition to TPAC as that's the only supported catalog with the current versions of Evergreen. |
| 09:36 |
csharp |
yep the JSPAC fails on IE and Safari |
| 09:37 |
bshum |
As of 2.4, I think we even removed the config pointers to JSPAC. At some point, we have to remove the files completely, but I think there's still hanging CSS bits for parts of the staff client. |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:42 |
|
RBecker joined #evergreen |
| 09:43 |
Keggle |
the link you shared earlier I see a lot of info on configuring or customizing but where to actually get the TPAC is still lost on me |
| 09:51 |
kmlussier |
Keggle: The tpac files should be part of your install. However, there is something you need to do in 2.3 to make Evergreen default to tpac. Unfortunately, I can't remember how we did it. |
| 09:51 |
* kmlussier |
isn't being super helpful. |
| 09:52 |
Keggle |
haha |
| 09:54 |
|
BigRig joined #evergreen |
| 09:55 |
dbs |
Keggle: you might be able to get to your TPAC via http://<hostname>/eg/opac/ - assuming that your apache config files were updated when upgrades occurred |
| 09:55 |
* RoganH |
thinks kmlussier is probably more helpful than she realizes. |
| 09:56 |
dbs |
and then it becomes "just" a matter of changing the default "/" redirect from pointing at the JSPAC to pointing at /eg/opac instead. ish. |
| 09:57 |
|
mdriscoll joined #evergreen |
| 09:57 |
|
afterl joined #evergreen |
| 09:58 |
|
yboston joined #evergreen |
| 10:00 |
csharp |
Keggle: you may have to change a line or two in /etc/apache2/eg_vhost.conf to enable it - see the "<LocationMatch ^/$> |
| 10:00 |
csharp |
..." section at the top |
| 10:04 |
dbs |
bshum: that sounds more like a description of our problems with ye olde white screen of death |
| 10:09 |
|
kbeswick joined #evergreen |
| 10:13 |
|
graced joined #evergreen |
| 10:14 |
|
ningalls1 joined #evergreen |
| 10:15 |
|
collum joined #evergreen |
| 10:29 |
|
Bmagic joined #evergreen |
| 10:44 |
|
mmorgan joined #evergreen |
| 10:44 |
|
ericar joined #evergreen |
| 10:44 |
|
bshum joined #evergreen |
| 10:45 |
|
ktomita_ joined #evergreen |
| 10:45 |
|
ericar joined #evergreen |
| 10:46 |
|
sseng joined #evergreen |
| 10:46 |
|
akilsdonk_ joined #evergreen |
| 10:46 |
|
rjackson_isl joined #evergreen |
| 10:46 |
|
afterl1 joined #evergreen |
| 10:48 |
|
ericar joined #evergreen |
| 10:49 |
|
dbs_ joined #evergreen |
| 10:49 |
pinesol_green |
[evergreen|Galen Charlton] LP#1254816: prevent cases where a Google Book preview is not displayed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bfb0c97> |
| 10:50 |
|
smyers_ joined #evergreen |
| 10:50 |
|
mtcarlson_away joined #evergreen |
| 10:52 |
|
rfrasur joined #evergreen |
| 10:53 |
|
sseng_ joined #evergreen |
| 10:53 |
|
mmorgan joined #evergreen |
| 10:54 |
|
pmurray left #evergreen |
| 10:56 |
|
jeff_ joined #evergreen |
| 10:56 |
jeff |
hrm. |
| 10:56 |
jeff_ |
odd. |
| 10:57 |
|
Guest74609 joined #evergreen |
| 10:57 |
|
jeff_ left #evergreen |
| 10:57 |
|
jeff_ joined #evergreen |
| 11:00 |
|
b_bonner_ joined #evergreen |
| 11:03 |
|
fparks joined #evergreen |
| 11:04 |
|
mdriscoll joined #evergreen |
| 11:09 |
|
kmlussier joined #evergreen |
| 11:11 |
|
shadowsp1r joined #evergreen |
| 11:14 |
|
mtcarlsoz joined #evergreen |
| 11:16 |
|
jeffdavi1 joined #evergreen |
| 11:21 |
|
rjackson_isl joined #evergreen |
| 11:21 |
|
akilsdonk__ joined #evergreen |
| 11:21 |
|
akilsdonk joined #evergreen |
| 11:21 |
|
fparks joined #evergreen |
| 11:21 |
|
b_bonner joined #evergreen |
| 11:21 |
|
jeff_ joined #evergreen |
| 11:21 |
|
mmorgan joined #evergreen |
| 11:21 |
|
sseng_ joined #evergreen |
| 11:21 |
|
bshum joined #evergreen |
| 11:21 |
|
yboston joined #evergreen |
| 11:21 |
|
pastebot joined #evergreen |
| 11:21 |
|
pinesol_green joined #evergreen |
| 11:21 |
|
gsams joined #evergreen |
| 11:21 |
|
wjr joined #evergreen |
| 11:21 |
|
jcamins joined #evergreen |
| 11:21 |
|
phasefx2 joined #evergreen |
| 11:21 |
|
paxed joined #evergreen |
| 11:21 |
|
tsbere joined #evergreen |
| 11:23 |
|
akilsdonk joined #evergreen |
| 11:24 |
pinesol_green |
[opensrf|Galen Charlton] LP#1180849: test case - ignoring subrequest responses after respond_complete() - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=59b4dd7> |
| 11:24 |
pinesol_green |
[opensrf|Mike Rylander] Protect subrequests from post-complete messages - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a0d5b05> |
| 11:26 |
|
jboyer-isl joined #evergreen |
| 11:26 |
|
jeffdavis joined #evergreen |
| 11:30 |
pinesol_green |
[opensrf|Bill Erickson] OpenSRF client disconnect robustification (Perl) - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b0a41d3> |
| 11:30 |
bshum |
I hate netsplits. |
| 11:30 |
rfrasur |
I hate socks that slide off when you're wearing snow boots. |
| 11:36 |
|
b_bonner_ joined #evergreen |
| 11:40 |
|
akilsdonk joined #evergreen |
| 11:44 |
|
mmorgan joined #evergreen |
| 11:46 |
|
b_bonner_ joined #evergreen |
| 11:51 |
|
ktomita joined #evergreen |
| 11:52 |
csharp |
dbwells: re: bug 1261355, my next step in troubleshooting was to begin commenting out each numbered script subsection in turn until I find the cause on our DB |
| 11:53 |
pinesol_green |
Launchpad bug 1261355 in Evergreen "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1261355 |
| 11:55 |
dbwells |
csharp: sounds like a good approach. I was assuming the 'SET CONSTRAINTS' was part of the issue, but Robert's comment makes it sound like the same error can happen when skipping straight to 'COMMIT' |
| 11:55 |
bshum |
dbwells: fwiw, I also tried using a 2.4.3 DB with concerto yesterday when csharp first mentioned it in IRC and couldn't replicate the problems either. |
| 11:56 |
bshum |
I don't have a younger DB (not master) to test further with. |
| 12:02 |
csharp |
it's possible that it's something about older installs that have been upgraded through each release? |
| 12:02 |
* csharp |
shrugs |
| 12:03 |
bshum |
Or it's just a table that has stuff in it that concerto doesn't normally. |
| 12:04 |
bshum |
But event_definition should have stuff in it. If it is 0827. |
| 12:06 |
bshum |
ldwhalen: Re: comments in bug 925776, I can write a reply onto the bug, but in case you're also watching IRC... |
| 12:06 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 5, heat: 30) [Medium,Confirmed] https://launchpad.net/bugs/925776 |
| 12:06 |
csharp |
I think 0827 is a red herring - I think the SET CONSTRAINTS command elicited the behavior, but when I commented it out, COMMIT; did the same thing |
| 12:06 |
csharp |
so it's something further up |
| 12:06 |
bshum |
The upgrade directory is organized as a series of steps to be run sequentially. So while a function is modified numerous times over the course of the runnings, it'll take the final shape of whatever is run most recently. |
| 12:07 |
bshum |
I think the idea is that the base files (that create the stock DB) are changed. And then an upgrade SQL is added to change an existing DB. |
| 12:07 |
bshum |
The upgrade SQL would take the next available four digit stamp number. |
| 12:07 |
bshum |
To continue the sequence. |
| 12:09 |
csharp |
bshum: no, I mean that 0827 is the last part of the 2.4.3-2.5.1 upgrade script so it's something earlier in that script |
| 12:09 |
bshum |
csharp: Yeah, I gotcha. My comments are all for ldwhalen. Probably should have prefixed his name ;) |
| 12:10 |
csharp |
bshum: ah gotcha! |
| 12:10 |
* bshum |
is juggling like 5 things in his head and is being bad about mixing them up :( |
| 12:11 |
* csharp |
is working like a madman this week so he can jump right back into upgrade mode after his 2 weeks off |
| 12:18 |
bshum |
csharp: It wouldn't surprise me if it was something else in the upgrade SQL. Those things are giant time bombs to me. |
| 12:19 |
csharp |
bshum: you mean the numbered scripts? |
| 12:19 |
bshum |
It's why I love my smaller upgrade chunks with numbered scripts following along master :P |
| 12:19 |
csharp |
oh - the big monoliths, yeah |
| 12:20 |
bshum |
Fwiw, it's not unprecedented to split apart pieces of the major version upgrade scripts into separate BEGIN; COMMIT; blocks. It's just not good for safe rollbacks :( |
| 12:20 |
tsbere |
The big monolithic upgrade scripts should probably be rigged in "schema changes first, then data changes" order or something. But I don't use them so I dunno. |
| 12:20 |
bshum |
Yeah, there's alot of hand editing that goes into them. |
| 12:21 |
csharp |
well, there has been less hand editing this go-round for me, but yeah |
| 12:22 |
|
enrichtomsk joined #evergreen |
| 12:23 |
csharp |
for our 2.5.1 test server, running the numbered upgrade scripts to go from 2.4.3 to 2.5.1 was fine, so I may do 'for i in `cat list-of-numbered-scripts`; do PGUSER=evergreen psql -f $i evergreen; done' |
| 12:26 |
csharp |
the only issue with that is the partial reingests that get kicked off sometimes, but Ctrl-C is easy enough |
| 12:27 |
bshum |
See, csharp, you're only inches from just running master :) |
| 12:27 |
csharp |
well, on the DB, maybe ;-) |
| 12:27 |
* csharp |
resists the pull of the dark side |
| 12:28 |
bshum |
If you only upgrade once a year or whatever, then just upgrade to the latest cut of master that basically became whatever the .0 or .1 was |
| 12:28 |
bshum |
:) |
| 12:28 |
bshum |
It's all just commits anyways |
| 12:28 |
bshum |
Point in time |
| 12:28 |
bshum |
:D |
| 12:29 |
bshum |
But yes, yes, resist, resist ;) |
| 12:30 |
csharp |
well we still haven't really settled the question of whether a release is a beautiful package of new goodies wrapped in a bow or an arbitary cut of a point in time |
| 12:31 |
csharp |
it doesn't matter to me as long as I can say "the upcoming release contains this set of features that we all need to learn together" |
| 12:31 |
csharp |
s/this set/this static set/ |
| 12:31 |
bshum |
Feels entirely arbitrary to me. More so, if we actually stuck to time based releases instead of feature ones. But I'm just one voice. |
| 12:32 |
csharp |
nah, I've heard eeevil saying that pretty recently too |
| 12:47 |
|
kitteh_ joined #evergreen |
| 12:52 |
|
linuxhiker joined #evergreen |
| 12:52 |
linuxhiker |
Has anyone tried using a different jabber server (say openfire) with evergreen? |
| 13:01 |
csharp |
linuxhiker: not in practice that I've heard about |
| 13:02 |
linuxhiker |
csharp: thanks |
| 13:09 |
* dbs_ |
tried openfire years ago |
| 13:09 |
dbs_ |
didn't seem to be much point though as it came with its own baggage |
| 13:10 |
linuxhiker |
dbs_: certainly. every software does |
| 13:17 |
bshum |
we use openfire for internal chat, but never thought to combine it with Evergreen action. |
| 13:18 |
tsbere |
We used to run a xmpp server for internal chat, the intent being "be able to tell the libraries things faster than with email", but our members didn't buy into it. |
| 13:20 |
csharp |
yeah, I can totally see our libraries rejecting that idea on the basis of "yet another login" |
| 13:20 |
tsbere |
csharp: That wasn't the issue. >_> |
| 13:22 |
|
jeffdavis joined #evergreen |
| 13:25 |
|
siruskabir joined #evergreen |
| 13:30 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation for 2.5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ba77efd> |
| 13:32 |
|
oriloux joined #evergreen |
| 13:35 |
|
ldwhalen_mobile joined #evergreen |
| 13:37 |
|
koliss joined #evergreen |
| 13:41 |
|
dMiller__ joined #evergreen |
| 13:47 |
|
bastami joined #evergreen |
| 13:50 |
|
dMiller___ joined #evergreen |
| 13:52 |
|
glamorous joined #evergreen |
| 13:54 |
|
eby joined #evergreen |
| 14:03 |
dbs |
ah the joys of creating a fresh VM image relatively smoothly... |
| 14:03 |
jeff |
:-) |
| 14:04 |
dbs |
I'm tempted to add the "chown opensrf /var/lock/apache2" instruction to the README for Precise but don't want to help entrench the run-apache-as-opensrf approach :/ |
| 14:04 |
bshum |
dbs: Yeah that's a real stumbler for new folks |
| 14:05 |
dbs |
And then change from osrf_ctl.sh to osrf_config. I guess in master, at least, assuming that people will have the right version of OpenSRF for that. |
| 14:12 |
dbs |
If anyone wants to peek at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/README_osrf_config I'd be most obliged |
| 14:14 |
berick |
dbs: s/osrf_config/osrf_control/ |
| 14:14 |
* dbs |
is running a KVM instance with virt-manager for the front end; pretty nice experience, and seems a lot less intrusive than virtualbox |
| 14:14 |
jeff |
dbs: s/osrf_config/osrf_control/ ? |
| 14:14 |
jeff |
berick++ |
| 14:14 |
dbs |
berick++ # thanks, yeah |
| 14:15 |
* dbs |
had noticed that when running the command but failed to apply that change along with the /-a start_all/--start-all/ bit, obviously :) |
| 14:16 |
berick |
dbs++ # docs ftw |
| 14:17 |
* dbs |
rebases that out of existence |
| 14:18 |
|
brent_SAGE joined #evergreen |
| 14:18 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1157897 has a mix of Lucid-oriented doc & makefile problems, for anyone running on Lucid |
| 14:18 |
pinesol_green |
Launchpad bug 1157897 in Evergreen 2.4 "PostgreSQL PPA for Ubuntu Lucid" (affected: 1, heat: 6) [Medium,Confirmed] |
| 14:19 |
* dbs |
hasn't run Lucid for ages but the three separate issues in that single commit on that bug seem legit |
| 14:19 |
bshum |
Personally I'd rather rip Lucid out of the mix in future builds. |
| 14:20 |
bshum |
We're going to need to start gearing up for Trusty soon enough |
| 14:20 |
* dbs |
is in favour of that. Squeeze too I guess? |
| 14:22 |
gmcharlt |
FWIW, I prefer that for Debian we do stable and oldstable, which means Squeeze drops out in May 2014 or so |
| 14:23 |
dbs |
So maintain squeeze for 2.5 but fire-kill it for 2.6? |
| 14:23 |
gmcharlt |
yeah |
| 14:24 |
bshum |
2.5 or 2.6? Or 3.0? (doesn't know the timing of things anymore) |
| 14:25 |
csharp |
incidentally, for fun, I got OpenSRF running on CentOS 6 last week |
| 14:26 |
csharp |
http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/csharp/centos_6_support for the curious |
| 14:26 |
csharp |
it's pretty well in line with the fedora makefile |
| 14:27 |
gmcharlt |
bshum: yeah, I think 2.6 will be out roughly the same time that Squeeze would stop being oldstable |
| 14:28 |
bshum |
gmcharlt: With master of now becoming 2.6, does that mean we're basically already giving up general support of Squeeze for master then? |
| 14:28 |
* bshum |
doesn't offer tips on Debian either way, but just curious to the language vs. practical terms of what we're saying we're doing |
| 14:28 |
csharp |
I would make 2.6 the last squeeze release |
| 14:29 |
pinesol_green |
[evergreen|Dan Scott] Update README to address Apache locking problem - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a22c60d> |
| 14:29 |
bshum |
Ah, I see. |
| 14:30 |
gmcharlt |
csharp: the problem with that is that squeeze would shortly become impossible to get through standard means around the same time that 2.6 is released |
| 14:30 |
|
stevenyvr2 joined #evergreen |
| 14:31 |
csharp |
gmcharlt: makes sense |
| 14:31 |
dbs |
and no more security updates from Debian for squeeze at that point either, right? |
| 14:32 |
csharp |
right |
| 14:32 |
jeff |
squeeze stops being supported by the debian security team on "about" 2014-05-04 (1 year after wheezy's release), unless the next release (sessie) comes out early. |
| 14:32 |
jeff |
in which case debian security team support for squeeze stops early (they do not attempt to support three releases) |
| 14:33 |
gmcharlt |
bshum: as far as master is concerned, squeeze support may as well stay in (so that backports of squeeze-related patches to rel_2_5 don't become painful) until shortly before 2.6 is released |
| 14:34 |
jeff |
http://www.debian.org/security/faq#lifespan documents the "about one year [or less]" policy. |
| 14:34 |
gmcharlt |
and once squeeze goes away, if we're still doing maintenance releases on rel_2_5 (as is likely) ... squeeze support would have to be dropped with the next point 2.5 release |
| 14:35 |
bshum |
Ugh, so messy :) |
| 14:35 |
csharp |
yeah |
| 14:36 |
* dbs |
thinks that maybe instead of documenting all of the PostgreSQL apt repo steps in our README, we should just point at the apt.postgresql wiki page instead |
| 14:36 |
bshum |
dbs: +1 |
| 14:36 |
csharp |
dbs: +1 |
| 14:36 |
gmcharlt |
dbs: +1 |
| 14:36 |
bshum |
I agree, I was just thinking the same thing |
| 14:40 |
bshum |
gmcharlt: Thanks for the explanations. I appreciate the background thinking with Debian support. |
| 14:40 |
bshum |
jeff: You too, thanks jeff :) |
| 14:49 |
jeff |
today hopefully i can employ the patron email regex [a-zA-Z0-9\._+-]+@([a-zA-Z0-9-]+\.)+[a-zA-Z0-9]+ |
| 14:55 |
jeff |
i think that's a pretty permissive regex, yet still catches the majority of syntactically-invalid email addresses. |
| 14:59 |
tsbere |
jeff: Are there any TLDs with 0-9 in them? >_> |
| 15:01 |
|
stevenyvr2 left #evergreen |
| 15:02 |
tsbere |
jeff: Also, I would replace the last + with a {2,} or {2,6} |
| 15:03 |
ldwhalen |
bshum: thank you for the explantion of the sql/Pg/upgrade directory |
| 15:03 |
bshum |
ldwhalen: I hope it makes some sense. |
| 15:04 |
ldwhalen |
yep, it made perfect sense |
| 15:04 |
jeff |
i considered a {2,} |
| 15:04 |
jeff |
{2,6} is pretty quickly going to be outdated. :-) |
| 15:06 |
ldwhalen |
^ internet provider problems fixed |
| 15:19 |
jeff |
{2,6} is pretty quickly going to be outdated. :-) |
| 15:19 |
jeff |
bah. wrong terminal. |
| 15:25 |
jeff |
tsbere, bshum, anyone else interested: i'd be curious to know if this query turns up any legit email addresses in your db -- there's a redacted column that should result in a safe-to-share string: https://gist.github.com/jeff/ed8f9acd3e501b52875c |
| 15:25 |
jeff |
adjust org unit argument as needed to exclude known-problematic datasets. |
| 15:25 |
* csharp |
continues to inch backwards up the 2.4.3-2.5.0 upgrade script, commenting out sections, run, rinse, repeat |
| 15:27 |
bshum |
jeff: That's a fun query |
| 15:27 |
jeff |
whose chaos powers reign supreme? phasefx's, or the PINES dataset's? |
| 15:27 |
csharp |
@developer |
| 15:27 |
pinesol_green |
csharp: Communication:11, BigPicture:8, DetailOriented:10, KungFu:11, GetsStuffDone:13, FlakeFactor:15, JavaAvoidance:6 |
| 15:28 |
csharp |
wow - pinesol_green's got my flake factor pretty well nailed ;-) |
| 15:28 |
bshum |
Hehe |
| 15:28 |
tsbere |
jeff: I don't like the fact that I get over 600 rows when I run that. |
| 15:28 |
bshum |
I got 2008 |
| 15:28 |
bshum |
My favorites right now are all the ones with spaces in them |
| 15:28 |
csharp |
9923 rows |
| 15:28 |
bshum |
ZZZZZZZZ@ ZZZZZZZ.ZZZ |
| 15:28 |
bshum |
Sigh |
| 15:29 |
tsbere |
Most of our "bad" ones have commas at the end |
| 15:29 |
csharp |
many of ours have commas at the end |
| 15:29 |
bshum |
These ones are more fun: ZZZZZ <ZZZZZZZ ZZZZZZZZZ.ZZZ> |
| 15:29 |
tsbere |
Or are obviouly 100% positively not email addresses |
| 15:29 |
bshum |
Name and then email in brackets |
| 15:29 |
bshum |
Yeah I got lots of commas too csharp :( |
| 15:29 |
jeff |
tsbere: 11 here, though that's because i invalidated about 476 last week. |
| 15:30 |
csharp |
ZZZZZZZZZZZZZZZZZZ.ZZZ! |
| 15:30 |
csharp |
funny - one of those is yahoo! |
| 15:30 |
csharp |
yahoo.com! |
| 15:30 |
tsbere |
jeff: Ooooh, found one that is apparently 100% valid but in the list |
| 15:30 |
jeff |
tsbere: redacted version appreciated! |
| 15:30 |
tsbere |
"ZZZZZ-ZZZ.Z'ZZZZZZZZZ.ZZZ" |
| 15:31 |
jeff |
sorry, they're going to have to get a new email address. |
| 15:31 |
tsbere |
The single quote in there is perfectly valid and doesn't seem to cause issues anywhere. The double quotes are because I ran things in pgadmin. |
| 15:31 |
jeff |
:-) |
| 15:31 |
csharp |
haha |
| 15:32 |
* tsbere |
found more of those, actually, like "ZZZZZZZZ.Z'ZZZZZZZZZZZZZZ.ZZZ" ;) |
| 15:32 |
|
ktomita__ joined #evergreen |
| 15:32 |
bshum |
Oh tons of "None" |
| 15:32 |
bshum |
Well that's nice folks |
| 15:33 |
berick |
heh |
| 15:33 |
berick |
very helpful |
| 15:33 |
csharp |
we have lots of * and . |
| 15:33 |
jeff |
yeah. single quote is valid. |
| 15:33 |
berick |
"My email is Mind your own business!" |
| 15:33 |
jeff |
heck, lots of other characters are... they're just very uncommon. |
| 15:34 |
* csharp |
sees lots of gun, princess, and UGA bulldog references in his sample |
| 15:34 |
bshum |
What the heck... @gmail, but not @gmail.com ? |
| 15:34 |
bshum |
Sigh, come on |
| 15:34 |
* tsbere |
likes the numerous examples like "@ZZZZZZZ.ZZZ", not to mention fun things like "ZZZZZZZZZZZZZZZZZZZZZZZ..ZZZ" and "(ZZZ) ZZZ-ZZZZ" |
| 15:35 |
bshum |
Yeah, that phone one got me too |
| 15:35 |
csharp |
I also see several with an email address and extra text like (DON'T USE) or (Mom) |
| 15:35 |
tsbere |
How about "ZZZZZZZZ ZZ:ZZ:ZZ" - AKA, a date/time stamp |
| 15:35 |
tsbere |
"ZZ. ZZZZZZ ZZ." - Street address. >_> |
| 15:35 |
jeff |
ZZZZZZZZZZZ.ZZZ;ZZZZZZZZZ: Z/ZZ/ZZ (ZZZZ ZZZ ZZZZ ZZ ZZZZZZZZZ ZZZZZ) |
| 15:36 |
jeff |
the freeform ones are amusing when redacted. |
| 15:36 |
csharp |
"ZZZ# ZZZZ / Z.Z. ZZZ ZZZZ / ZZZZ# ZZZZ" |
| 15:36 |
tsbere |
Lots of "email then barcode" and "email then phone", oh, and here is one that looks like "email;username;password;phone;barcode" |
| 15:36 |
csharp |
translation: "Please mail me my email by USPS" |
| 15:36 |
jeff |
ZZZZZZZZZZZ.ZZZ;BIRTHDATE: Z/ZZ/32 (WILL NOT SAVE IN BIRTHDATE FIELD) |
| 15:36 |
bshum |
o.O |
| 15:37 |
tsbere |
First names, nicknames, "whatever,@domain.ext" for some reason.... |
| 15:37 |
csharp |
"thisishiswork#@dont. leaveamessage" |
| 15:38 |
csharp |
wow - lots of 'n/a' variants and "NONE" |
| 15:38 |
tsbere |
"NOT YET CIRCULATING ONLINE", lots of .c0m entries, or .co.m, randomly inserted spaces..... |
| 15:39 |
eby |
@who didn't validate |
| 15:39 |
pinesol_green |
eby: You probably want hard-boiled eggs. |
| 15:39 |
jboyer-isl |
Sigh. I feel pretty comfortable letting this one out un-redacted: |
| 15:39 |
jboyer-isl |
x |
| 15:39 |
jboyer-isl |
Three of those, actually. |
| 15:39 |
tsbere |
oh, hey, that one actually works. "ZZZ/ZZZZZZZZZZ.ZZZ" |
| 15:39 |
jeff |
:-) |
| 15:41 |
jboyer-isl |
I wonder about this one though: ZZZZ.Z.ZZZZZ!@ZZZZ.ZZZ |
| 15:41 |
tsbere |
huh, and we have been successfully sending to a "ZZZZ/ZZZ=ZZZZZZZZ.ZZZ" too, according to our logs |
| 15:41 |
jboyer-isl |
Aren't exclamation points valid in certain situations? (possibly only as an alternate separator, maybe) |
| 15:42 |
jeff |
so yeah, for now we're going to start using [a-zA-Z0-9\._+-]+@([a-zA-Z0-9-]+\.)+[a-zA-Z]{2,}+ |
| 15:43 |
csharp |
jeff++ |
| 15:43 |
* tsbere |
needs to improve MVLC's a bit, apparently |
| 15:44 |
tsbere |
jeff: Is that even valid? The {2,}+ part in particular, shouldn't the + not be there? |
| 15:45 |
jeff |
in addition to that regex, !#$%&'*/=?^`{|}~ are all valid in the localpart. |
| 15:46 |
jeff |
tsbere: typo. that should have been [a-zA-Z0-9\._+-]+@([a-zA-Z0-9-]+\.)+[a-zA-Z]{2,} |
| 15:46 |
jeff |
that's what's entered into the library settings editor. |
| 15:46 |
jboyer-isl |
jeff: ah, thought so. But I imagine the library is the least of their concerns when it comes to getting people to accept such an address. :D |
| 15:46 |
jeff |
different from the syntax used in the sql query. |
| 15:47 |
csharp |
we just had a fascinating policy discussion about a patron who had legally changed his name to a single capital letter |
| 15:47 |
csharp |
the new policy is that in the case of one-letter names, we, like the DMV, enter the letter as the first and last name |
| 15:48 |
csharp |
public_libraries++ |
| 15:49 |
RoganH |
Makes me wonder how we would handle a symbol name that we don't have unicode for (as Prince did once upon a time). |
| 15:50 |
* senator |
is actually wondering whether it's once upon a time because prince changed his name again or because it got added to unicode |
| 15:50 |
jboyer-isl |
"The patron formerly known as Tony" |
| 15:50 |
csharp |
jboyer-isl++ |
| 15:50 |
* csharp |
peruses http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode/ |
| 15:50 |
jeff |
technically you also can't have .. consecutively, and you can't have . as the first or last part of the local-part. |
| 15:50 |
bshum |
Eh, they're all just ID numbers to me. |
| 15:54 |
tsbere |
jeff: Doesn't \. in a [] block mean \ or ., as neither \ or . is special in there? |
| 15:56 |
tsbere |
(compared to what I suspect was your intent of "a literal .") |
| 15:59 |
jeff |
it does. conveniently, \ is valid. ;-) |
| 15:59 |
jeff |
but i had noticed that and forgotten to follow up on it. in our data, we have no \ and i'm almost okay with keeping it that way. |
| 16:03 |
jeff |
odd. just tried to send to .user, us..er user. and us.er from one google apps mailbox to another. so far, none have bounced or gone through. i'd expect at least us.er to have gone through. |
| 16:04 |
|
Callender joined #evergreen |
| 16:04 |
jeff |
aha! google apps vs gmail difference. |
| 16:04 |
jeff |
"Dots (.) are recognized by Google Apps. This is not the same as Gmail." https://support.google.com/a/answer/33386?hl=en |
| 16:04 |
jeff |
and i already know the reason why the others didn't bounce yet (they will) |
| 16:13 |
jeff |
tsbere++ thanks for the feedback. |
| 16:20 |
RoganH |
senator: did he make it a symbol again? |
| 16:21 |
senator |
RoganH: no, i'm just terribly behind on my prince trivia it seems |
| 16:37 |
|
mrpeters joined #evergreen |
| 16:43 |
|
ktomita___ joined #evergreen |
| 16:43 |
|
ktomita____ joined #evergreen |
| 16:43 |
|
ktomita_____ joined #evergreen |
| 16:46 |
jeff |
syntactically, .usernameexample.com is invalid. |
| 16:48 |
jeff |
but it's accepted by gmail. :-( |
| 16:51 |
jeff |
wow. CLPS.KIZ.MI.O5 vs CLPS.K12.MI.US |
| 16:51 |
|
stevenyvr joined #evergreen |
| 16:52 |
tsbere |
jeff: I could see OCR doing that |
| 16:53 |
jeff |
in this case, i'm pretty sure that was a handwritten email address being entered by a human. |
| 16:53 |
tsbere |
I could argue that many humans are horrible at OCR themselves. ;) |
| 16:55 |
RoganH |
tsbere: I was forced to learn to type because most humans OCR couldn't recognize my fonts reliably. |
| 16:59 |
tsbere |
RoganH: At one point in school I stopped having to improve my writing because it was better than one of my teacher's, and everyone grading my work had no problem reading mine. >_> Then I ended up at a different school and nobody could make my writing out anymore. |
| 17:00 |
|
mdriscoll left #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:15 |
|
dcook joined #evergreen |
| 17:38 |
|
stevenyvr joined #evergreen |
| 18:17 |
|
mrpeters joined #evergreen |
| 18:55 |
|
stevenyvr joined #evergreen |
| 19:07 |
|
stevenyvr2 joined #evergreen |
| 19:34 |
|
ktomita joined #evergreen |
| 20:07 |
|
stevenyvr2 left #evergreen |
| 20:34 |
csharp |
hmm - interesting - when I commented out 0841 in the 2.4.3-2.5.1 upgrade script - the error did not occur |
