[09:04:55] <Urbanecm>	 Hello, I have a small grid issue. See a group of shell commands at https://pastebin.com/Rqc60f9B . Anybody who knows possible reason? 
[09:05:42] <Urbanecm>	 (just a note, ofc this is just a simulation of another, slightly bigger script which is working fine when executed directly from console but when executed by the grid it throws the same error)
[09:15:03] <Urbanecm>	 Anybody able to help me ^^^^^?
[09:16:51] <legoktm>	 Urbanecm: I'm just guessing, but it seems like a locale issue
[09:18:09] <legoktm>	 Urbanecm: if you just try test = datetime.datetime.strptime('9. 9. 2017, 11:12', '%d. %m. %Y, %H:%M') # so there's no timestamp part, does it work on the grid?
[09:18:29] <Urbanecm>	 legoktm, wait a while, will try. 
[09:19:07] <Urbanecm>	 legoktm, yes, it do. 
[09:19:47] <Urbanecm>	 Also at cmd line I have LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8 (bash environment variables)
[09:19:51] <Urbanecm>	 At the grid they do not exist
[09:20:11] <legoktm>	 the en_US.UTF-8 locales don't exist on the grid? maybe C.UTF-8?
[09:20:24] <Urbanecm>	 legoktm, no, the variables aren't set on the grid
[09:20:30] <legoktm>	 oh
[09:20:31] <legoktm>	 well
[09:20:37] <legoktm>	 try setting those variables on the grid too :p
[09:22:46] <Urbanecm>	 Do not work as well
[09:22:48] <Urbanecm>	 (same error)
[09:24:27] <Urbanecm>	 I've tried to use jsub python test.py as well as putting python test.py into test.sh and trying jsub bash test.sh
[09:24:53] <Urbanecm>	 When I try to echo those variables by test.sh on the grid (executed by jsub) they have the same content as on bastion
[09:28:48] <legoktm>	 Urbanecm: I can't get your script to work even on tools-login with no grid
[09:29:11] <Urbanecm>	 Strange...
[09:29:12] <legoktm>	 Urbanecm: https://paste.fedoraproject.org/paste/UxwUvH-J23UECU50RJhtSw/raw
[09:33:10] <Urbanecm>	 Ha, I've found it. 
[09:33:28] <Urbanecm>	 I've set TZ=CET at grid and it works
[09:36:46] <legoktm>	 nice
[09:36:51] <legoktm>	 so it was the timezone :)
[09:38:43] <legoktm>	 Urbanecm: from brief searching, it looks as if you install https://pypi.python.org/pypi/pytz/ in a virtualenv then it will automatically have all timezones
[17:56:55] <Urbanecm>	 Hello to all, I'm currently solving a Segmentation fault error from my Python script. Do anybody know how can I debug such error? See https://pastebin.com/XBmaFaE2 for details
[17:59:01] <Urbanecm>	 (if anybody wants the 'core' file, it's in /data/project/mostlinkedmissing/mostlinkedmissing/generator/core for Toolforge admins, I'll chmod on request)
[18:02:32] <paladox>	 bd808 hi, is it safe to swtich from jessie to stretch in mediawiki vagrant? or is it not yet fully ready. Is there a migration path?
[18:02:34] <paladox>	 please
[18:03:51] <bd808>	 It’s a work in progress that needs more changes I’m sure. 
[18:04:01] <paladox>	 ok
[18:04:05] <paladox>	 thanks.
[18:04:14] <bd808>	 No migration path. Just build a new vm
[18:04:51] <bd808>	 But if you’d like to start testing and fixing bugs that would help. :)
[18:09:23] <paladox>	 Ok
[18:56:29] <d3r1ck>	 Urbanecm: Maybe you could use "pdb" to debug? It's like "gdb" for C. https://docs.python.org/2/library/pdb.html
[18:56:47] <d3r1ck>	 Maybe you could step through the code using that and see where the segmentation fault occurs?
[18:58:16] <Urbanecm>	 d3r1ck, just found it out, it ran out of memory... I'll optimalize it sometime in the future, now I'm just getting it working :D But thanks!
[18:58:44] <d3r1ck>	 Urbanecm: Great! Happy it's working. I've used pdb, it's a good debugger for Python
[18:58:48] <d3r1ck>	 You can try it out :)
[18:59:14] <d3r1ck>	 Urbanecm: Hope it won't run out of memory again. If I were you, I would just optimize it now :D
[19:09:53] <Urbanecm>	 d3r1ck, no, it threw another error :D. I might expect that fetching large amount of data by cur.fetchall will raise such kind of error :D
[19:11:30] <d3r1ck>	 :D
[19:11:56] <d3r1ck>	 You may want to stream the data, not just return all right?
[19:16:23] <d3r1ck>	 Urbanecm: Maybe this is useful http://code.activestate.com/recipes/137270-use-generators-for-fetching-large-db-record-sets/
[19:22:29] <Urbanecm>	 d3r1ck, I'm copying result of certain SQL query to tools-db database. From that database it's displayed through public interface
[19:22:49] <d3r1ck>	 Okay!
[19:41:56] <zhuyifei1999_>	 Urbanecm: pure python don't usually segfault unless in a very old version. does it call some external C code?
[19:42:28] <zhuyifei1999_>	 uh, nevermind I see you found the issue
[19:42:41] <Urbanecm>	 zhuyifei1999_, as I said, it run out of memory (which THROWS segfault even in language that manage your memory)
[19:43:39] <zhuyifei1999_>	 are you using mysqldb or oursql? external C code may use malloc() to allocate memory
[19:43:57] <zhuyifei1999_>	 if it is out of memory it returns a null pointer
[19:44:05] <zhuyifei1999_>	 dereferencing it segfaults
[19:44:39] <Urbanecm>	 zhuyifei1999_, oursql
[19:44:48] <zhuyifei1999_>	 well, that explains it :P
[19:44:56] <Urbanecm>	 oursql's written in C?
[19:45:07] <zhuyifei1999_>	 yes
[19:45:21] <zhuyifei1999_>	 part of it
[19:45:36] <Urbanecm>	 zhuyifei1999_, well written C codes are usually a little bit faster...
[19:46:05] <zhuyifei1999_>	 https://github.com/python-oursql/oursql 65.5% C
[20:34:46] <paladox>	 bd808 hi, i've converted mysql to mariadb here https://gerrit.wikimedia.org/r/#/c/398648/ :)
[22:08:44] <paladox>	 bd808 heh i broke my install now. I went into the wrong folder and destroyed my jessie one. 
[22:10:19] <Zppix>	 Lol
[22:11:33] <paladox>	 !log git gerrit-test3 ldap down recreating mediawiki-vagrant with stretch after accidentially destroying the jessie one.
[22:11:36] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Git/SAL
[22:17:45] <Zppix>	 Nice one
[22:18:29] <Zppix>	 paladox: i really am starting to wonder if we should let you play with all these toys lol
[22:20:32] <paladox>	 lol
[22:20:39] <paladox>	 it was only an accident
[22:27:53] <paladox>	 bd808 when will stretch be the default image? :)
[22:41:42] <wikibugs>	 (03PS193) 10Ricordisamoa: Initial commit [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296
[22:48:22] <wikibugs>	 (03CR) 10Ricordisamoa: [C: 04-2] "> After 192 patches I guess it is time to get this merged? :]" [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 (owner: 10Ricordisamoa)
[22:48:58] <paladox>	 bd808 wow i think this stretch upgrade may fix reload / mwvagrant forward-port :). using mwvagrant forward-port on jessie failed.
[22:49:06] <paladox>	 also i found another puppet 4 error
[22:49:07] <paladox>	 ==> default: Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Left match operand must result in a String value. Got an Integer. at /vagrant/puppet/modules/logstash/manifests/conf.pp:29:8  at /vagrant/puppet/modules/logstash/manifests/output/elasticsearch.pp:44 on node mediawikivagrant.mediawiki-vagrant.dev
[22:50:20] <wikibugs>	 (03CR) 10Ricordisamoa: [C: 04-2] "PS193 frees LanguageDetector from ConfigAccessor" [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 (owner: 10Ricordisamoa)
[23:00:53] <paladox>	 woo mwvagrant reload's works with stretch :)
[23:01:12] <paladox>	 finally i doint have to restart the instance now. now i can do vagrant reload
[23:02:30] <wikibugs>	 (03PS194) 10Ricordisamoa: Initial commit [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296
[23:07:55] <wikibugs>	 (03CR) 10Ricordisamoa: [C: 04-2] "PS194 frees EditDispatcher from ConfigAccessor" [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 (owner: 10Ricordisamoa)