| Time |
Nick |
Message |
| 00:51 |
bshum |
So, the setup for pulling from git into bzr is working for rel_2_12, but it looks like the automated export to the translation-export-2.12 branch has not worked since around 5/26 or so |
| 00:52 |
bshum |
So no new changes have been propagating to the export branch |
| 00:52 |
bshum |
Either it's an LP problem, or we have added something new to our code that it's having difficulty working with. |
| 01:39 |
bshum |
So I'm not 100% sure |
| 01:39 |
bshum |
But it looks like a problem with the launchpad import queue for translations |
| 01:40 |
bshum |
Is that it didn't know how to map various language files to the POs |
| 01:40 |
bshum |
Since we name it "ar-JO" instead of just plain "ar" |
| 01:40 |
bshum |
And it also expects it to be with an underscore. So "pt_BR" instead of "pt-BR" |
| 01:40 |
bshum |
I added several of the known variants to the custom language code mapping |
| 01:41 |
bshum |
And it seems like the import queue is already automatically going through and marking what will get imported where based on the new language mappings |
| 01:41 |
bshum |
We'll have to see what happens after the files go from "approved" to "imported" |
| 01:42 |
bshum |
And see if they reflect changes to master and 2.12's LP branches |
| 01:47 |
bshum |
launchpad-- # for being weird and strange with the translations i18n setups :( |
| 01:57 |
* bshum |
will look at it more tomorrow |
| 02:01 |
jeffdavis |
bshum++ |
| 03:12 |
|
RBecker joined #evergreen |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:28 |
csharp |
~~ |
| 07:28 |
csharp |
 |
| 07:28 |
csharp |
Mr. Robot season_1.0 |
| 07:28 |
csharp |
 |
| 07:28 |
csharp |
Mr. Robot season_1.0 |
| 07:28 |
csharp |
argh |
| 07:29 |
csharp |
well, take that as a double recommendation for Mr. Robot, Season 1 |
| 07:56 |
|
agoben joined #evergreen |
| 08:39 |
|
mdriscoll joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:56 |
remingtron |
csharp++ #double recommendations |
| 08:56 |
csharp |
middle_click_paste-- |
| 08:56 |
|
mmorgan joined #evergreen |
| 09:02 |
|
kmlussier joined #evergreen |
| 09:11 |
kmlussier |
gmcharlt++ Bmagic++ dbwells++ miker++ |
| 09:11 |
kmlussier |
bshum++ # Working through our translation woes. |
| 09:11 |
|
_adb joined #evergreen |
| 09:12 |
* kmlussier |
heads into LP to do the necessary release updates. |
| 09:15 |
Dyrcona |
everybody++ ;) |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:30 |
|
maryj joined #evergreen |
| 10:26 |
bshum |
So it looks like there are three PO templates that are failing to import |
| 10:26 |
bshum |
Two of them appear to be tests |
| 10:27 |
bshum |
build/i18n/tests/data/sql2pot.pot |
| 10:27 |
bshum |
and build/i18n/tests/data/testidl.pot |
| 10:27 |
bshum |
Both of them are dying cause of a missing end qoute on line 6 where the timestamp should be, I guess. |
| 10:28 |
bshum |
I'm not really sure we should worry about these, given that they appear to be really ancient test files for PO Templates, but maybe we should either fix the line, or get rid of the file altogether if they no longer serve a purpose. |
| 10:29 |
bshum |
The other one that appears to be broken is build/i18n/po/multiclass_search_help.html/multiclass_search_help.html.pot |
| 10:29 |
bshum |
Which seems to be pulling the entire HTML in, instead of finding any specific strings |
| 10:29 |
bshum |
And it's choking cause it's expecting a PO template, not raw HTML |
| 10:31 |
bshum |
Since multiclass_search_help.html is part of the XUL server files, I'm not sure if we shouldn't also deprecate that and remove the offending POT and POs that can't be translated anyways |
| 10:35 |
Dyrcona |
I'm still working on setting up Syrup on an alternate host, and I really have no idea what I'm doing. The README is really short on details and seems to assume that you know Django and otherwise know what you're doing. |
| 10:35 |
Dyrcona |
Do I just have to change the settings in localsettings.py and it will just work? For some reason, I doubt that. |
| 10:36 |
jeff |
yep! my experience was similar, though possibly with an AM/PM inversion! |
| 10:36 |
jeff |
i knew some Django already, which was helpful. |
| 10:38 |
Dyrcona |
Do I need to run the manage.py command? |
| 10:40 |
jeff |
at some point you do need to run some manage commands to init the db, etc. |
| 10:40 |
jeff |
and running the django app in dev mode on an alternate port is useful when you're trying to get things working. |
| 10:40 |
jeff |
(you should never never never expose debug mode to any untrusted clients) |
| 10:41 |
Dyrcona |
The postgresql db or something else? I have copies of the dbs from production. |
| 10:42 |
jeff |
i was talking about init of the django database which at least in our case is a postgres db, yes. |
| 10:42 |
Dyrcona |
So, I have to run the manage.py script in each instance... OK. |
| 10:43 |
Dyrcona |
The vm has a non-routing IP address. It's only visible at central site or via vpn. |
| 10:44 |
jeff |
assuming you're starting with Django 1.4.x, all of the top-level DATABASE_* settings in local_settings.py.example should be commented out, and you should use the example DATABASES= hash to set the various settings. |
| 10:44 |
dbs |
bshum: I think the POT tests are still useful. Looks like there is a small delta required for one or two of the tests to still pass. |
| 10:44 |
bshum |
dbs: Yeah I was just wondering if we run them as part of the nightly test |
| 10:44 |
jeff |
under DATABASES[default], i set ENGINE, NAME, USER, PASSWORD, HOST, and PORT |
| 10:45 |
Dyrcona |
jeff: Yes. I've copied everything from production and just modified the values. |
| 10:45 |
bshum |
dbs: Well, daily I guess. |
| 10:45 |
jeff |
for postgres, i used 'ENGINE': 'django.db.backends.postgresql_psycopg2' |
| 10:45 |
Dyrcona |
jeff: ditto. :) |
| 10:45 |
bshum |
I kind of wish there was a way of excluding the tests from going to LP translations though. |
| 10:45 |
jeff |
Dyrcona: ah! then you're at least starting from a working install, which is possibly better off than starting from scratch! |
| 10:45 |
Dyrcona |
Could be. :) |
| 10:46 |
Dyrcona |
I'm changing the db and the evergreen instance that it talks to. |
| 10:48 |
dbs |
bshum: might have been under buildbot? doubt it for the live reporter though |
| 10:48 |
bshum |
dbs: That's kind of what I figured |
| 10:49 |
dbs |
bshum: if launchpad is purely filename-based, we could do a workaround like having the setup / teardown rename a file from blah.pot.example to blah.pot for the test, then rename it back |
| 10:49 |
bshum |
dbs: Yeah it seems to be targeting only things with .po or .pot |
| 10:50 |
dbs |
testIDL and testSQL just need a single space removed from their POT test file to make their tests pass |
| 10:51 |
bshum |
Alternatively, we could create a different repo for translations right? And only sync that stuff against master or whatnot for the files we specify to target for translation efforts |
| 10:51 |
bshum |
Or do we want to keep everything as bound together as we can |
| 10:51 |
bshum |
(thinking ahead to when we replace LP translations) |
| 10:53 |
bshum |
I guess I'm thinking of a world where we have direct translation against the git branch; would we want to see random drive-by commits flow through |
| 10:53 |
bshum |
Or we keep the translation branch separate, and pull back automated sync or something to Evergreen |
| 10:54 |
bshum |
Just thinking aloud |
| 10:54 |
bshum |
It's not today's problem |
| 10:56 |
* bshum |
reads about Koha's thoughts on that in https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking |
| 10:58 |
bshum |
I guess they keep their POs as part of their main code still |
| 10:58 |
* bshum |
ponders that further |
| 10:58 |
dbs |
user/dbs/tiny_i18n_test_fix working branch has fixes for two of the i18n tests that were failing on my Fedora 25 machine |
| 10:58 |
dbs |
to test: cd build/i18n; python tests/testIDL.py; python tests/testSQL.py |
| 10:59 |
* dbs |
returns to prepping for Senate meeting |
| 11:00 |
bshum |
dbs++ # thanks |
| 11:26 |
Dyrcona |
jeff: Should I do manage.py syncdb or manage.py migrate? |
| 11:27 |
jeff |
syncdb in this case. |
| 11:28 |
jeff |
looks like i ended up calling syncdb and then migrate. |
| 11:29 |
jeff |
i think both may be required due to syrup using South. |
| 11:29 |
jeff |
but the migrate command is likely a no-op. |
| 11:30 |
jeff |
from our most recent install, i have history of commands but no transcript of results. |
| 11:30 |
jeff |
so, to answer your original question in a more accurate way: Yes! |
| 11:39 |
Dyrcona |
:) |
| 11:39 |
Dyrcona |
I did both. |
| 11:39 |
Dyrcona |
So runserver starts it up? |
| 11:43 |
Dyrcona |
Um, guess not. |
| 11:47 |
Dyrcona |
Apparently, we're serving it through apache in production somehow. |
| 11:48 |
jeff |
runserver should start it in debug mode (localhost port 5000 by default, I think?) |
| 11:48 |
jeff |
for Apache, you're probably running it through mod_wsgi |
| 11:49 |
jeff |
look for WSGIScriptAlias in your apache config |
| 11:51 |
Dyrcona |
mod_python it looks like. I found it in eg.conf. |
| 11:51 |
Dyrcona |
I'll have to copy that over. |
| 11:53 |
jeff |
And I'd recommend adding a task to your todo list to move away from mod_python. |
| 11:55 |
jeff |
Though it doesn't seem to be *completely* dead yet... |
| 11:55 |
Dyrcona |
On a related note, I've been meaning to try mod_wsgi with my flask apps. |
| 12:05 |
Dyrcona |
I'd be dangerous if I could type available on the command line without typos. :) |
| 12:06 |
Dyrcona |
And, what do you know? It appears to work! |
| 12:06 |
Dyrcona |
jeff++ |
| 13:54 |
Dyrcona |
Anyone seen this before? |
| 13:54 |
Dyrcona |
2017-06-22 13:53:52.102 [error] <0.38.0>@ejabberd_config:get_plain_terms_file:222 Cannot load /etc/ejabberd/ejabberd.yml: Syntax error on line 130 at position 1: did not find expected key |
| 13:54 |
Dyrcona |
That's not a line that we modify according to the README. |
| 13:56 |
berick |
not I |
| 13:58 |
Dyrcona |
It's in the ssl config. My file has just a - |
| 13:59 |
JBoyer |
What's on the next line? Errant enter key perhaps? |
| 13:59 |
berick |
same here, just above the port: 5269 |
| 13:59 |
Dyrcona |
Yeah, port: 5269 |
| 13:59 |
Dyrcona |
I don't see any obvious errors before that line. |
| 13:59 |
berick |
Dyrcona: what OS? |
| 13:59 |
Dyrcona |
Ubuntu 16.04 |
| 14:00 |
berick |
k, same here |
| 14:01 |
|
jamesrf joined #evergreen |
| 14:05 |
Dyrcona |
I'm guessing a non-printing space snuck in. |
| 14:07 |
Dyrcona |
Nope. |
| 14:07 |
Dyrcona |
Guess, i'll just blow it away and start over. |
| 14:09 |
berick |
Dyrcona: if you want to diff it against something.. http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=opensrf/ejabberd-config.yml;hb=refs/heads/collab/berick/ansible-installer-ubuntu-16.04 |
| 14:11 |
Dyrcona |
Thanks! I'll have a look. It looks like all of the leading spaces were stripped in my file. Must have been an errant vim command. |
| 14:11 |
Dyrcona |
vim-- :) |
| 14:12 |
JBoyer |
Somewhere miker's "Space isn't syntax" senses just started going off. |
| 14:14 |
Dyrcona |
:) |
| 14:14 |
Dyrcona |
After diffing, I see several whitespace errors. |
| 14:14 |
Dyrcona |
I just copied the example above into place and it's working. |
| 14:14 |
Dyrcona |
berick++ |
| 14:15 |
Dyrcona |
Dunno what exactly I did, but I guess I fudged something in vim. |
| 14:16 |
berick |
cool |
| 14:16 |
berick |
note that version still has shapers enabled, which apparently need to be set to none to avoid clog-ups |
| 14:18 |
Dyrcona |
I haven't run into that, but I did see your conversation with miker. |
| 14:19 |
JBoyer |
Might also see about removing the max_fsm_queue setting also or it'll just start discarding messages if they're not picked up fast enough. |
| 14:20 |
Dyrcona |
I don't think I've run into that, either. :) |
| 14:20 |
Dyrcona |
I'm not using 16.04 in production, yet. |
| 14:30 |
Dyrcona |
All these deprecation warning from npm install.... |
| 14:30 |
Dyrcona |
Development at the speed of JavaScript. :) |
| 14:31 |
Dyrcona |
Oof! |
| 14:32 |
Dyrcona |
This is a first for me, too: |
| 14:32 |
Dyrcona |
PhantomJS 2.1.1 (Linux 0.0.0) ERROR |
| 14:32 |
Dyrcona |
ReferenceError: Can't find variable: angular |
| 14:32 |
Dyrcona |
at /home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/services/core.js:6 |
| 14:36 |
|
jihpringle joined #evergreen |
| 14:48 |
eeevil |
berick: re shapers, that's less of an issue with chunking (no more 2MB stanzas) but for our use case it's best to toss 'em |
| 14:49 |
eeevil |
Dyrcona: your problem is you're using a pre-release version of Linux, obv ;) |
| 14:50 |
Dyrcona |
:) |
| 14:54 |
berick |
eeevil: hm, doesn't chunking essentially mean we send more (but smller) messages? seems like shapers would have even more impact w/ chunking. |
| 14:56 |
eeevil |
berick: unintuitively, no. because the shapers are about B/s. if you send a 2MB stanza and it takes .1s you get penalized for (basically) 20MB/s and have to wait until your moving average comes down |
| 14:56 |
eeevil |
if you send a bunch of small messages, the delay (if it happens) is spread out more. |
| 14:57 |
eeevil |
plus, since everyone is using the same user name, any backend can cause all others to be penalized with one big stanza |
| 14:58 |
eeevil |
and, more, big messages take longer to transfer (deserialize, reserialize), and that stops all other messages en route. a bunch of small messages from all over are interleved |
| 14:59 |
eeevil |
effectively parallelizing responses at the opensrf level (even if they're serialized at the ejabberd level) |
| 14:59 |
berick |
that makes sense, but lots of smaller messages also means lots more message boilerplate (to, from, etc.) per byte transferred |
| 15:01 |
eeevil |
well, sure, but with bundling we're averaging messages of ~20k (up to ~50k), so the 200 boilerplate bytes are in the noise for practical purposes. (also, it's possible that the envelope is ignored by the shaper counters ... I don't know either way for sure, though) |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:03 |
eeevil |
but, best to get rid of shapers on safe networks in any case |
| 15:03 |
berick |
right, ok, bundling gets us back to multiple osrf blobs per message for tightly packed stuff |
| 15:03 |
eeevil |
right |
| 15:03 |
berick |
yes, agreed, i'm testing no-shapers now |
| 15:11 |
Dyrcona |
That grunt all error didn't happen on a Debian 7 server with a similar, but not identical branch. |
| 15:12 |
Dyrcona |
One big difference: The Debian 7 server had the staff client installed before, the Ubuntu vm is fresh. |
| 15:17 |
Dyrcona |
Happens with rel_2_12 on that same vm. I'll build a fresh one. |
| 15:49 |
eeevil |
aaaaaand, there's the tornado warning |
| 15:50 |
* eeevil |
saves all open files |
| 15:54 |
berick |
get all the bits into the shelter! |
| 16:08 |
|
mmorgan joined #evergreen |
| 16:57 |
|
jihpringle joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
jwoodard joined #evergreen |
| 17:04 |
|
jihpringle joined #evergreen |
| 17:05 |
|
jvwoolf left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:11 |
|
jihpringle_ joined #evergreen |
| 17:13 |
|
jihpringle__ joined #evergreen |
| 17:22 |
csharp |
hmm - probably been mentioned before, but on pg_restore 9.4 to 9.5: ERROR: function unaccent(text) does not exist when creating unaccent and squash indexes |
| 17:23 |
|
jihpringle_ joined #evergreen |
| 17:24 |
|
Jillianne joined #evergreen |
| 17:24 |
|
jihpringle joined #evergreen |
| 17:32 |
|
jihpringle_ joined #evergreen |
| 18:19 |
eeevil |
csharp: if you're using pgdump output (rather than pgdumpall) then I think you need to create the extensions (and set the search path, etc) before restoring. pgdump/restore is so much more finicky than pgupgrade... |
| 18:20 |
|
jihpringle joined #evergreen |
| 18:23 |
csharp |
eeevil: ah - thanks - in this case I'm dumping from our 9.4 prod db into a 9.5 test db - looks from stack exchange posts that the problem is that the extension isn't created in the right order |
| 18:24 |
csharp |
also doing parallel restore, so maybe that's a factor too |
| 18:42 |
|
jamesrf joined #evergreen |
| 19:29 |
jeff |
csharp: you've run into bug 1671150 which i should probably actually take a moment to work on. |
| 19:29 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 - Assigned to Jeff Godin (jgodin) |
| 19:31 |
csharp |
jeff++ # I knew it sounded familiar :-) |
| 19:32 |
jeff |
csharp: if you have a chance to run an upgrade script after i push a branch, i'd be interested in hearing how long it takes to run on a PINES-sized dataset. |
| 19:34 |
csharp |
sure - happy to do it |
| 19:35 |
csharp |
running upgrade scripts now, actually |
| 19:35 |
csharp |
(version-upgrade 2.11.1 - 2.12.2) |
| 20:06 |
jeff |
csharp: user/jeff/unaccent_fix_lp1671150 has an XXXX upgrade script which should work for 2.12 and master. It will probably not break 2.11, but it will likely introduce a new feature where it "shouldn't" |
| 20:07 |
jeff |
I'm pretty sure we had some conversation a while back about fixes where the backport needs to be different, but I don't recall what the guidance is. I'll look. |
| 20:38 |
csharp |
bug 1517137 |
| 20:38 |
pinesol_green |
Launchpad bug 1517137 in Evergreen "Missing Permissions omnibus bugfix package Nov 2015" [Wishlist,Fix released] https://launchpad.net/bugs/1517137 |
| 20:43 |
jeff |
bug 1618183 was one where we had a 2.10-only upgrade script which existed as a no-op placeholder in later releases. |
| 20:43 |
pinesol_green |
Launchpad bug 1618183 in Evergreen 2.10 "add Spanish to config.i18n_locale" [Medium,Fix released] https://launchpad.net/bugs/1618183 |
| 20:44 |
jeff |
csharp: did you run into trouble with something related to bug 1517137, or were you citing it as an example of something i was looking for? |
| 20:44 |
pinesol_green |
Launchpad bug 1517137 in Evergreen "Missing Permissions omnibus bugfix package Nov 2015" [Wishlist,Fix released] https://launchpad.net/bugs/1517137 |
| 20:45 |
jeff |
sometimes it's hard to tell if someone's looking something up for their own purposes or citing it to contribute to the topic at hand :-) |
| 21:36 |
csharp |
jeff: ran into trouble ;-) |
