[00:45:21] @.@ [00:45:43] * NativeForeigner tries to figure out hte labs config again [00:46:41] PiRSquared: Same idea; just use the instance name. [00:48:35] excellent. time to see if this also works on labs [02:14:41] (03PS4) 10Tim Landscheidt: Work around pbuilder not properly setting $USER [labs/toollabs] - 10https://gerrit.wikimedia.org/r/106283 [02:25:35] (03PS2) 10Tim Landscheidt: Fix Lintian errors in jobutils man pages [labs/toollabs] - 10https://gerrit.wikimedia.org/r/106648 [02:28:46] (03PS3) 10Tim Landscheidt: Fix Lintian errors in jobutils man pages [labs/toollabs] - 10https://gerrit.wikimedia.org/r/106648 [02:32:12] (03PS2) 10Tim Landscheidt: Retrieve $PACKAGE_VERSION from debian/changelog [labs/toollabs] - 10https://gerrit.wikimedia.org/r/106747 [10:06:00] Coren: what about turning off swap on -login in order to make it faster? it currently swap like hell [10:14:00] !log tools petrb: disabled 1 job in cron in -login of user tools.tools-info which was killing login server [10:14:04] Logged the message, Master [13:08:09] petan: Better yet, on Monday I turn off /cron/ on -login. :-) [13:17:19] Coren: not until you make sure you dont break anything [15:54:59] Something like "du -sb /data/project/* >eqiad-dirsize 2>/dev/null" is also not very reliable for non-public data. But Betacommand is right, making sure nothing breaks should be paramount :-). I think anomie's comment about what happens to redirections is still unanswered. [15:55:44] scfc_de: and ensuring that the same data is emailed [15:56:51] scfc_de: right now all but 1 cron uses jsub that one doesnt use it for a reason, I need the output emailed to me [15:59:39] Betacommand: +1 [16:13:25] * hedonil reads backscroll [16:15:04] Hmm. So that simple command made some trouble... Didn't expect neither check. So sry for that. it's ok. [16:16:26] scfc_de: can't find something 'unreliable' in listing bytecount of a directory [16:18:16] actually it is for spotting tools that have no function at all, as it became really confusing/a pain finding a tool by looking at tools homepage [16:19:41] hedonil: Isn't du meant to be recursive? [16:20:33] http://tools.wmflabs.org/tools-info/migration-status.php lists currently 93 out of 674 tools (~14%) with absolutely no data [16:20:52] scfc_de: the -s just gives a total [16:25:21] hedonil: Yes, but to calculate the total, du needs to recurse, doesn't it? [16:25:35] scfc_de: but yes it's recursive, of course [16:26:07] So it can't get a bytecount for tools that don't have their directories world-readable. [16:26:18] *reliable [16:29:20] scfc_de: yep. they are marked 'blank' ,not open source ;) [16:30:34] scfc_de: but at least for this 93 'empty' tools you can omit your effort trying to find a working tool [16:33:23] That's usually not my mo :-). If I want to do something, I search how to do that, or look at a curated listing on some wiki page. Empty tools don't bother me, as long as noone links to them as working :-). [16:41:57] unfortunately we don't have a per-tools Icinga yet, also we don't have any kind of categorization for tools [16:42:13] some tasks for a todo list ;) [16:44:05] I think there are bugs for both of them :-). [16:45:17] https://bugzilla.wikimedia.org/show_bug.cgi?id=51434 ("Setup an icinga instance to monitor tools on tool-labs") [16:45:59] https://bugzilla.wikimedia.org/show_bug.cgi?id=49937 ("Clean up list of projects on Tool Labs home page") [16:47:52] scfc_de: hell yeah. voluntary on the front! :) [16:49:49] scfc_de: maybe some discussion about valid/useful categories.. and some (minor) changes to the service group interface and LDAP [16:51:30] * hedonil heard whispers about the tactics of creating a tool just to obtain a LDAP service group for other purposes... ;) [16:54:36] so retaining 'emtpy' tools would be absolutely fine, if they could be marked as dead/abandoned whatever [17:01:48] "Other purposes"? [17:03:36] scfc_de: just noises, never mind ... [17:09:43] I don't understand what one could gain from "a LDAP service group", but if it is something illicit, I'm pretty sure the Labs admins would like to hear about it before the shit hits the fan. [17:16:00] scfc_de: hell no ;) no shit, no fan (/chuckles). You could, hm let's say make access more fine grained [17:17:59] but back to the categorization thingy. Good tools deserve good presentation. for the good of all [17:18:44] according to todays standards and maybe even to ISO/IEC 25010:2011 [17:19:18] haha [17:20:52] * hedonil laughs too [17:21:09] but it's the hell of a paper ;) [17:22:06] but to serious again, tools webpage needs some extensions [17:23:32] tools need more bureaucracy, err documentation and proper licensing :) [17:26:17] and some 'like' buttons [17:28:35] really? o.o [17:29:23] why not? it's a community thing [17:43:21] !sexytime [17:43:21] xxx [17:43:45] hedonil: :O [17:44:00] :-D [17:47:11] Where's the code for labslogbot live? [17:48:10] Reedy: if you want the commands/keys http://bots.wmflabs.org/~wm-bot/dump/%23wikimedia-labs.htm [17:49:06] Nope [17:49:20] I want to fix what it thinks should link to gerrit [17:49:31] {{Gerrit|2014}} in the server admin logs is useless [17:49:59] IIRC labslogbot is distinct from wm-bot. petan? [17:51:57] thanks [17:53:33] no obvious mention of gerrit there [17:54:09] debian/changelog: * Don't auto-link SHA1s and Gerrit change IDs [17:54:09] debian/changelog: * Auto-link SHA1s and Gerrit change IDs [17:54:10] lol [17:54:40] Perhaps old version deployed? [17:55:01] https://github.com/wikimedia/operations-debs-adminbot/commit/a5051c5a6f2fb5872917e2f58a94f0769b19343d [17:55:03] Looks like it [18:00:05] I am just about to swap the bastion dns names over to eqiad, and then turn off the pmtpa bastions. Is anyone logged in to one of them right now? [18:01:09] Hm, I guess there's no real need for me to shut them down today, might as well let people finish up their sessions. [18:07:42] andrewbogott: But you already changed bastion.wmflabs.org? [18:07:51] scfc_de: only just a minute ago. [18:08:37] k [18:10:25] scfc_de: if you have a second, want to double-check that I put up the right fingerprints on https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints ? [18:28:28] andrewbogott: bastion{,2,3}.wmflabs.org look good to me. [18:28:37] great, thanks [20:08:11] Hi everyone, [20:09:10] While working on the enwiki_p database, I am unable to find the exact number of Wikipedia article's view count. I found that on the page table there is page_counter column that is updated by the hit_counter table on periodically. I searched, 'Anarchism' that is viewed 5252 times but when I searched similar term on "http://stats.grok.se/en/201403/Anarchism", I found totally different number of views. Can anyone tell me, how can [20:09:13] ??? [20:16:01] the db numbers aren't real numbers [20:16:08] just forget them [20:17:15] was bastion moved to eqiad and changed keys, or am i being under a mitm ? [20:17:32] andrewbogott: ^ ? [20:17:35] matanya: the former [20:18:03] thanks gifti this was suspicouis [20:18:11] gifti: so what should I do ? [20:18:41] asad_: use the the stats.grok.se numbers [20:18:44] matanya: yes, moved. The new fingerprints are here: https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints [20:18:53] matanya: Are you subscribed to labs-l? [20:19:02] thanks, yes I am scfc_de [20:19:06] i think [20:20:28] gifti, but I have almost 1Million record, then I have to make 1Million request on stats grok. Is it ok ? or is there other mechanism ? [20:20:41] idk [20:21:34] matanya: andrewbogott posted a message about the new fingerprints a few hours ago. [20:21:41] asad_: no, that's not OK. [20:22:00] scfc_de: ah, i'm mail bcaklogged, by a day or so [20:22:04] asad_: try http://dumps.wikimedia.org/other/pagecounts-raw/ [20:25:19] valhallasw: ok. thanks [20:26:08] I will try to use it, but unfortunately previously I found some difficulties while using it. [20:53:52] petan: wm-bot @relay on bots-labs? [20:54:25] a930913: I had to move it [20:54:31] a930913: now it's wm-bot [20:54:34] instance name [20:58:03] petan: Ta, cron was mailing me every five minutes for its failing D: [20:58:16] *Cough* UDP *Cough* [20:58:46] if it was UDP you would never even know it doesn't work [20:59:08] petan: Just like we don't know whether black holes exist? ;) [20:59:51] UDP is good just for video streaming and such :P [21:00:05] anything what needs to be at least a bit reliable should use tcp [21:00:42] petan: Convinience logging to IRC should break anything when it fails. [21:02:02] should or shouldn't? btw that's up to you as a programmer if command make the application crash or continue even on fail [21:06:00] petan: It becomes greatly complex to not crash for me. I'd rather it failed silently. [21:06:25] command > /dev/null [21:06:32] makes it fail silently ;) [21:06:44] command 2>&1 1> /dev/null [21:06:49] that does even the error stream [21:07:02] petan: You're thinking bash. [21:07:22] I am thinking every language I know. you are the programmer you control what it does [21:08:56] petan: You are making me program something I don't even want to be thinking of. [21:09:12] just replace if (!sendtoirc(blabla)) { throw Exception("failed to send to irc"); } with sendtoirc(blabla); // convert from c++ to your prefered language [21:09:56] a930913: if your programming language requires some thinking in order to disable error checks, it's a weird language [21:11:00] petan: It's a very basic script, what you're suggesting increases the complexity by many factors. [21:11:27] on other hand if it was using UDP what about potential users who would like to catch the exception? you would reduce the possibilities if you did that [21:12:13] many factors? I just provided 2 examples in 2 languages, 1 is half a line, second one is less than 2 lines, that is many factors? [21:12:38] every sane programming language can deal with this using a one line change [21:13:27] petan: except your examples could hang indefinitely, if the server does not respond to the SYN in a timely manner. [21:13:47] valhallasw: no they wouldn't [21:13:52] @help [21:13:52] I am running http://meta.wikimedia.org/wiki/WM-Bot version wikimedia bot v. 2.0.0.4 my source code is licensed under GPL and located at https://github.com/benapetr/wikimedia-bot I will be very happy if you fix my bugs or implement new features [21:14:10] valhallasw: the first one was refering to my sample bash script which uses -w 0 [21:14:25] that makes netcat immediately exit without waiting for server [21:16:50] do you *think* that or have you actually *tried* that? [21:17:33] (because it seems to mean 'indefinitely', not '0 seconds') [21:17:41] this way I give people freedom to decide if they want to know about the error or if they don't, and you know that freedom is one of most important things in your life [21:18:10] valhallasw: yes I have tried that and I am actively using it, and 0 doesn't mean indefinitely, but literally 0 seconds [21:21:01] With the nc on tools-login? I call BS. [21:21:10] nc -w 0 80.112.160.213 22 [21:21:16] try it, then change 0 to 1 [21:21:52] if the server drops packages on that port (as opposed to closing the connection), -w 0 will hang indefinitely [21:26:45] hmm, indeed [21:27:34] but still, if it result in error in his script, that error can be surely somehow ignored, or its cause removed [21:27:50] (in case it really isn't important if there is an error) [21:28:40] the point is TCP is not as simple as you would expect [21:29:07] and having your code hang because the logging server is down would be a bit weird [21:29:15] at least with UDP you get what you ask for [21:29:39] I am not expecting anything here I just say that as a programmer you are the person to make your program behave as you need [21:30:16] with UDP I definitely wouldn't get what I ask for because what I ask for is a way to either use this feature for both, reliable and non-reliable purposes [21:30:31] someone is using it for logging that isn't important, someone might be using for stuff that is important [21:30:57] it's for a bot that relays the message *to IRC* [21:31:05] yes [21:31:13] someone consider IRC just as important as e-mail [21:31:16] you know, the medium that frequently is down due to netsplits, DDOS'es, etc [21:31:20] someone even more :P like me [21:31:38] medium down? it's just freenode that is down, due to poor operation [21:31:50] there are many more servers out there [21:32:07] I like how you're completely missing the point. [21:32:10] I know how IRC works. [21:32:22] indeed I do, what is the point? [21:32:56] that you're complaining about the unreliability of UDP, while it's used to message to a medium that's probably less reliable [21:33:01] I could implement UDP port as well as TCP port, if you need that in order to make your work easier (and my harder :P, but I don't mind, I like programming) make a ticket in bugzilla [21:33:26] valhallasw: which medium? [21:33:35] IRC, and in this specific case Freenode [21:33:40] valhallasw: IRC is using TCP [21:33:54] (also, saying Freenode is down due to 'poor operation' is really unreasonable) [21:33:59] I know it uses TCP [21:34:04] reliability is more than 'using TCP' [21:34:11] well, then I really miss the point [21:34:12] it's also 'being accessible' [21:34:41] if wm-bot, or the recepient, are unable to connect to Freenode for some reason, the message is lost [21:35:09] you mean "you are complaining about reliability of UDP, while you are using TCP to message a medium that is less reliable"? in that case I might start to understanding the point :P [21:35:19] thus the message delivery cannot be relied on in the first place [21:35:37] thus the argument 'you cannot be sure the message is delivered if you're using UDP' is not a good reason to choose TCP over UDP [21:35:40] valhallasw: the message is lost, but we know about that [21:35:59] it's never gonna be 100% reliable, nothing really is, but it helps to find out there is a problem [21:36:05] the program that's connecting to wm-bot would not know [21:36:10] it makes it more reliable that if it was UDP [21:36:19] how do you know that? [21:36:37] how would it know if Freenode has a netsplit or not? [21:37:17] ok in case of netsplit I don't know, but again, it's not 100% reliable, but it's meant to be reliable, forcing everyone to use ONLY udp would make it significantly less reliable [21:37:37] because you wouldn't just not be notified when freenode has netsplit, you also would not be notified if there was problem on labs side [21:37:49] this way you are notified at least about 1 issue, and that already makes it more reliable [21:37:59] even if not 100% [21:39:22] only point I see in this UDP thing is to make this easier for people who want to ignore errors but don't want to mess up with their source code [21:39:54] in this case [21:40:44] that's a valid point, but replacing current TCP implementation with UDP would make it IMHO much worse, so only solution I am fine with is opening both protocols [21:41:37] I think the use case 'I want to be sure wm-bot got the message, but I don't care whether the message actually got passed on to IRC' is a very limited use case. [21:41:58] I think the use case 'I would like this message on IRC, and hopefully it arrives" is more general [21:42:42] and unless the network is completely saturated, UDP is not really less reliable than TCP [21:42:58] the use case is actually "I want to send this to IRC and I want to know about any errors that it is possible to detect during delivery" [21:43:30] I'm fairly certain you *could* detect more errors and report them. [21:43:44] btw your argument that there can be something preventing you from detecting an error could be used to almost anything [21:43:58] yes I could [21:44:11] I am trying to detect all and report all I can [21:44:22] hmkay [21:44:22] but for example as you said, it's pretty hard to determine when there is a netsplit [22:28:14] Cyberpower678, Gloria: where do I should file a bug for the by you maintained https://tools.wmflabs.org/erwin85/ ?