[01:03:05] <wikibugs>	 6Labs, 10Tool-Labs: Create Tool Labs packages key - https://phabricator.wikimedia.org/T112905#1664880 (10scfc) I created a test key with:  ``` root@toolsbeta-puppetmaster3:~# gpg --gen-key gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc. This is free software: you are free to change and re...
[01:16:46] <wikibugs>	 6Labs, 10Tool-Labs, 5Patch-For-Review: Packages from the aptly server are not installable - https://phabricator.wikimedia.org/T112699#1664883 (10scfc) I created a test key (cf. also T112905).  I tested the pre-state by purging package `jobutils` on `toolsbeta-webproxy-01` which caused:  ``` Error: Could not...
[01:50:25] <wikibugs>	 6Labs, 7Database, 5Patch-For-Review: watchlist table not available on labs - https://phabricator.wikimedia.org/T59617#1664891 (10MZMcBride) I just left a note on <https://gerrit.wikimedia.org/r/225218>. We should already have all the necessary infrastructure built and available here to safely expose this dat...
[04:06:31] <wikibugs>	 6Labs: Fix check_disk bogus alerts on labstore1002 - https://phabricator.wikimedia.org/T113435#1664934 (10yuvipanda) 3NEW a:3coren
[04:18:52] <Krinkle>	 Coren: Any ETA on https://phabricator.wikimedia.org/T60196? I'm curious if/what it's blocked on. It'd essentially be a derivative column of user_touched. cropped to YYYYMM. And with current month shifted to -1 to avoid exposure of identifying properties when the month rolls over on small wikis (as previously discussed and approved afaik).
[04:23:55] <wikibugs>	 10Tool-Labs-tools-Other, 6Discovery, 10Maps: GeoHack's list of mapping service links does not include maps.wikimedia.org - https://phabricator.wikimedia.org/T113438#1664972 (10Spage)
[04:26:20] <Krinkle>	 Ah, I see it's blocked on https://phabricator.wikimedia.org/T92841
[04:34:49] <wikibugs>	 10Tool-Labs-tools-Other, 6Discovery, 10Maps: GeoHack's list of mapping service links does not include maps.wikimedia.org - https://phabricator.wikimedia.org/T113438#1665018 (10Yurik) I also left a note on the [[ https://en.wikipedia.org/wiki/Template_talk:GeoTemplate#Wikimedia_maps_service_is_now_live | talk...
[04:39:59] <wikibugs>	 6Labs, 6Discovery, 7Elasticsearch: Replicate production elasticsearch indices to labs - https://phabricator.wikimedia.org/T109715#1665035 (10Deskana) @ebernhardson Can you add some of the use cases for this to the task description?
[04:42:43] <wikibugs>	 10Tool-Labs-tools-Other, 6Discovery, 10Maps: GeoHack's list of mapping service links does not include maps.wikimedia.org - https://phabricator.wikimedia.org/T113438#1665044 (10Krinkle)
[04:43:50] <wikibugs>	 10Tool-Labs-tools-Other, 6Discovery, 10Maps: GeoHack's list of mapping service links does not include maps.wikimedia.org - https://phabricator.wikimedia.org/T113438#1664962 (10Krinkle) GeoHack is operated by @Magnus.  The source code at [https://bitbucket.org/magnusmanske/geohack/src/master/public_html/](htt...
[07:51:36] <wikibugs>	 6Labs, 10wikitech.wikimedia.org: Can't login into a newly created nova instance through ssh - https://phabricator.wikimedia.org/T113451#1665419 (10devunt) 3NEW
[09:16:18] <wikibugs>	 6Labs, 10Tool-Labs: Install composer on tools-login - https://phabricator.wikimedia.org/T104789#1665643 (10valhallasw) After discussing with @joe and @hashar:   - backporting the package to precise and trusty is probably difficult.  - to solve the issue on the integration cluster, https://github.com/wikimedia/...
[09:46:12] <wikibugs>	 6Labs, 10Continuous-Integration-Infrastructure, 10Labs-Infrastructure: integration-slave-trusty-1014 and integration-slave-trusty-1017 instances can't boot anymore, ended up corrupted. Need rebuild - https://phabricator.wikimedia.org/T110052#1665732 (10hashar) Recreating integration-slave-trusty-1014 and int...
[12:35:12] <wikibugs>	 6Labs, 10Continuous-Integration-Infrastructure, 10Labs-Infrastructure: integration-slave-trusty-1014 and integration-slave-trusty-1017 instances can't boot anymore, ended up corrupted. Need rebuild - https://phabricator.wikimedia.org/T110052#1666142 (10hashar) 5Open>3Resolved We have rebuild: * integrati...
[12:35:21] <wikibugs>	 6Labs, 10Continuous-Integration-Infrastructure, 10Labs-Infrastructure: integration-slave-trusty-1014 and integration-slave-trusty-1017 instances can't boot anymore, ended up corrupted. Need rebuild - https://phabricator.wikimedia.org/T110052#1666144 (10hashar) (npm / grunt-cli are up-to-date)
[12:47:19] <wikibugs>	 6Labs, 3Labs-Q4-Sprint-2, 3Labs-Sprint-114, 3ToolLabs-Goals-Q4: Remove dependencies on LDAP from labstore100[12] - https://phabricator.wikimedia.org/T95558#1666151 (10akosiaris) Any news on this ?
[12:52:36] <Krenair>	 yuvipanda, would https://gerrit.wikimedia.org/r/#/c/160628/1 affect labs?
[12:53:27] <valhallasw`cloud>	 Krenair: yes
[12:53:48] <valhallasw`cloud>	 Krenair: when NFS was down, the only way to login was by using the fallback root keys
[12:54:00] <valhallasw`cloud>	 (to projects that have /home on NFS, anyway)
[12:58:01] <Krenair>	 I managed to break a couple of instances recently where the only way to log in again was by adding my key to the root-authorised-keys
[12:59:08] <valhallasw`cloud>	 yeah, that as well
[12:59:17] <Krenair>	 if an instance loses access to ldap or dns, this would mean no one could log in
[12:59:51] <valhallasw`cloud>	 the alternative is having a non-root 'admin' account that can sudo, but that doesn't really have an advantage over root login
[13:00:48] <JohnFLewis>	 valhallasw`cloud: it wouldn't be a root account :)
[13:02:30] <valhallasw`cloud>	 unixlawyering? :-p
[13:03:04] <valhallasw`cloud>	 passwordless sudo means the account that can sudo effectively is a root account, I'd say
[13:08:49] <valhallasw`cloud>	 or, to use old-new-thing-speak: it's on the other side of the airtight hatchway ;-)
[13:57:26] <krrrit-wm>	 (03PS1) 10Niharika29: Send all Community-Tech-* traffic to #wikimedia-commtech [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/240363 
[14:01:09] <krrrit-wm>	 (03CR) 10Merlijn van Deen: [C: 032] Send all Community-Tech-* traffic to #wikimedia-commtech [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/240363 (owner: 10Niharika29)
[14:01:24] <krrrit-wm>	 (03Merged) 10jenkins-bot: Send all Community-Tech-* traffic to #wikimedia-commtech [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/240363 (owner: 10Niharika29)
[14:02:21] <wikibugs>	 !log tools.wikibugs Updated channels.yaml to: 06f2a7d0a89baac1a1255c8e2524afa9654e09c1 Send all Community-Tech-* traffic to #wikimedia-commtech
[14:02:24] <labs-morebots>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL, Master
[14:37:42] <sDrewth>	 when I am running a python environment, setup for mwlib, it is telling me ... local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. 
[14:38:14] <sDrewth>	 and searches say that one should run 2.7.9
[14:39:03] <sDrewth>	 or use pyOpenSSL
[14:39:14] <sDrewth>	 is there any guidance internally?
[14:43:11] <sDrewth>	 I did read and tried "pip install requests[security]" but no effect
[15:08:05] <wikibugs>	 6Labs, 10Tool-Labs, 10Labs-Infrastructure, 3Labs-Sprint-115: Can't delete rule in default security group - https://phabricator.wikimedia.org/T112492#1666495 (10Andrew) Here is the issue:      MariaDB MISC m5 localhost nova > show columns from security_group_rules;     +-----------------+--------------+----...
[15:12:38] <wikibugs>	 6Labs, 10Tool-Labs, 10Labs-Infrastructure, 3Labs-Sprint-115: Can't delete rule in default security group - https://phabricator.wikimedia.org/T112492#1666508 (10Andrew) a:5Andrew>3jcrespo Jaime, is changing the type of that field easy?
[15:25:38] <Le0n>	 Hi peoples! the Xtools is inactive, anyone can restart it?
[15:39:54] <James_F>	 valhallasw`cloud: BTW, issue with RTB – it's looking to add mw1.26 and mw1.26wmf25 to things, not mw1.27 and mw1.27wmf1…
[15:40:24] <James_F>	 valhallasw`cloud: Do we just fix that by changing the repo it checks to say the current version is mw1.27wmf0 or some other hack?
[15:42:32] <valhallasw`cloud>	 James_F: how did we do this for 1.26wmf1?
[15:42:46] <James_F>	 valhallasw`cloud: We didn't. The hackathon happened after that.
[15:42:55] <valhallasw`cloud>	 ah :D
[15:42:58] <James_F>	 valhallasw`cloud: Hence why I'm asking you as the inventor. :-)
[15:43:13] <valhallasw`cloud>	 then we probably decided not to care about this edge case ;-)
[15:43:22] <James_F>	 "Edge".
[15:43:32] <valhallasw`cloud>	 yes! it's a step function with lots and lots of edges
[15:43:34] <valhallasw`cloud>	 ;-)
[15:43:42] <James_F>	 https://tools.wmflabs.org/forrestbot/log.txt is getting icky.
[15:43:46] <James_F>	 (Also we should rotate the log.)
[15:44:33] <valhallasw`cloud>	 I'm not sure what the list error is, probably that it can't find the slug?
[15:44:39] <James_F>	 Yeah.
[15:44:46] <James_F>	 The returned list is zero-length.
[15:44:53] <James_F>	 So it fails, leaving the e-mails unread.
[15:45:07] <valhallasw`cloud>	 well, it assumes it's a dict, not a list
[15:45:11] <valhallasw`cloud>	 but *shrug* php and josn
[15:45:16] <James_F>	 Sure.
[15:45:27] <valhallasw`cloud>	 so let me think. we get mw27wmf1 after branch 1.26 is tagged, right?
[15:45:28] <James_F>	 Details.
[15:45:44] <valhallasw`cloud>	 or can 1.26 be tagged before the last wm1.26x?
[15:45:49] <James_F>	 We get mw27wmf1 after mw26wmf24 is branched.
[15:45:56] <James_F>	 1.26 might not be tagged for days.
[15:45:59] <valhallasw`cloud>	 ok
[15:46:11] <James_F>	 And '24' could change to a different number.
[15:46:18] <valhallasw`cloud>	 *nod*
[15:46:21] <James_F>	 We could just add a specific hack for now.
[15:46:28] <James_F>	 If 24 => major = 27.
[15:46:41] <valhallasw`cloud>	 is this decided somewhere machine-readable?
[15:47:08] <James_F>	 No.
[15:47:11] <valhallasw`cloud>	 oh, I think I know what our suggested solution was
[15:47:17] <James_F>	 It's decided in people's heads.
[15:47:25] <James_F>	 But 24 is the modal max number.
[15:47:36] <James_F>	 (It's been 22 a few times too.)
[15:47:38] <valhallasw`cloud>	 add #mw1.26wmf25 as alias to #mw.127wmf1
[15:47:50] <James_F>	 valhallasw`cloud: No.
[15:48:05] <James_F>	 valhallasw`cloud: That will mean tasks get tagged #mw127wmf1 and #mw126
[15:48:09] <James_F>	 Which is… not fun.
[15:48:17] <James_F>	 Because it will need manual fixing later.
[15:48:20] <valhallasw`cloud>	 Ah. Yes, you're right.
[15:48:45] <James_F>	 (Patch merged last week and patch merged this week means #mw127 and #mw126 should both apply, so can't blindly replace later.)
[15:49:22] <valhallasw`cloud>	 *nod*
[15:50:11] <valhallasw`cloud>	 so I'm thinking of the following. we can filter branches in get_master_branches, and use refs/heads/wmf/mw1.27 as marker instead
[15:50:16] <valhallasw`cloud>	 which wil lreturn an empty list
[15:50:29] <valhallasw`cloud>	 which we can then handle? meh.
[15:50:42] <valhallasw`cloud>	 it's not too ugly, I guess.
[15:51:40] <James_F>	 Yeah.
[15:52:00] <James_F>	 But we still need to handle back-ported things.
[15:52:14] <James_F>	 (For the next week and a half.)
[15:52:24] <James_F>	 (To 1.26wmf23,4)
[15:53:39] <valhallasw`cloud>	 I'm confused. Why is that different for this release?
[15:55:36] <James_F>	 valhallasw`cloud: Because we can't just hack in a mw127 assumption for things.
[15:56:00] <valhallasw`cloud>	 bah. right
[15:58:06] <valhallasw`cloud>	 and then the next issue is
[15:58:10] <valhallasw`cloud>	 because 1.26 hasn't been branched
[15:58:18] <valhallasw`cloud>	 the logic will always add REL1.26
[15:58:23] <valhallasw`cloud>	 :(
[15:59:10] <valhallasw`cloud>	 I need to go shopping now
[16:27:22] <valhallasw`cloud>	 James_F: ok, so I don't understand the MW release process well enough to completely get this I think
[16:27:43] <valhallasw`cloud>	 but should the bugs be tagged #mw1.27 and #mw1.27wmf1?
[16:27:53] <valhallasw`cloud>	 or #mw1.26 #mw1.27 #mw1.27wmf1?
[16:28:04] <valhallasw`cloud>	 or #Idon'tknowthereleasehelp #mw1.27wmf1?
[16:28:25] <James_F>	 Yes.
[16:28:29] <James_F>	 #mw1.27 and #mw1.27wmf1
[16:28:34] <valhallasw`cloud>	 ok
[16:28:40] <James_F>	 And then later when REL1_26 is created (which will be mw1.26wmf24 plus extra patches) we can start.
[16:29:10] <valhallasw`cloud>	 buuut
[16:29:17] <valhallasw`cloud>	 REL1_26 is branched from master
[16:29:25] <valhallasw`cloud>	 so everything that gets merged now gets in 1.26
[16:29:27] <valhallasw`cloud>	 right?
[17:34:30] <krrrit-wm>	 (03PS1) 10Legoktm: Add manifest_version info [labs/tools/extreg-wos] - 10https://gerrit.wikimedia.org/r/240422 
[17:34:32] <krrrit-wm>	 (03PS1) 10Legoktm: Add timestamp report was generated, and link to JSON format [labs/tools/extreg-wos] - 10https://gerrit.wikimedia.org/r/240423 
[18:21:25] <wikibugs>	 6Labs, 6Discovery, 7Elasticsearch: Replicate production elasticsearch indices to labs - https://phabricator.wikimedia.org/T109715#1667207 (10EBernhardson)
[18:22:11] <valhallasw`cloud>	 !log tools experimenting with https://github.com/jordansissel/fpm on tools-packages, and manually installing packages for that. Noting them here.
[18:22:15] <labs-morebots>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL, Master
[18:22:49] <valhallasw`cloud>	 !log tools here = https://etherpad.wikimedia.org/p/74j8K2zIob
[18:22:52] <labs-morebots>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL, Master
[18:31:41] <yuvipanda>	 valhallasw`cloud: you know 'fpm' stands for 'fuck package management' right :D
[18:31:56] <yuvipanda>	 Which is maybe not that terrible an attitude actually 
[18:31:58] <valhallasw`cloud>	 :D
[18:32:21] <valhallasw`cloud>	 anything which doesn't require debian/rules and debian/changelog makes me a happy valhallasw`cloud 
[18:32:48] <yuvipanda>	 I've never had to write either of those. 
[18:32:59] <yuvipanda>	 At least for python packages 
[18:34:19] <valhallasw`cloud>	 the deb route has the advantage of building easily for multiple distros, I suppose
[18:35:04] <yuvipanda>	 Stdeb is also not bad for python 
[18:35:12] <yuvipanda>	 Also what package are you building?
[18:35:24] <valhallasw`cloud>	 composer
[18:35:28] <valhallasw`cloud>	 from https://github.com/wikimedia/integration-composer
[18:35:29] <yuvipanda>	 Ok
[18:35:34] <yuvipanda>	 Ok
[18:54:01] <andrewbogott>	 Coren, yuvipanda, any objection to https://gerrit.wikimedia.org/r/#/c/221042/ ?
[18:54:44] <yuvipanda>	 Do merge 
[18:54:53] <yuvipanda>	 I don't have any objections 
[18:54:56] <andrewbogott>	 ok
[18:55:15] <andrewbogott>	 hm, will puppet apply that or does it require a package rebuild?
[18:55:42] <Coren>	 andrewbogott: wfm
[18:59:18] <valhallasw`cloud>	 yuvipanda: and now of course pushing this to gerrit is going to be the hardest part :/
[18:59:33] <yuvipanda>	 valhallasw`cloud: why? 
[18:59:42] <valhallasw`cloud>	 because I'm logged in as tools.dpkg
[18:59:49] <yuvipanda>	 Aaaah
[18:59:53] <valhallasw`cloud>	 and gerrit complains if committer != me
[19:00:04] <valhallasw`cloud>	 because gerrit likes to make life difficult for people
[19:00:15] <yuvipanda>	 Heh
[19:00:23] <yuvipanda>	 You can change that with --author
[19:00:41] <valhallasw`cloud>	 no
[19:00:44] <valhallasw`cloud>	 that changes author
[19:00:44] <andrewbogott>	 Coren: how is maintain-replicas deployed?
[19:00:45] <valhallasw`cloud>	 not committer
[19:01:02] <yuvipanda>	 You can set committee too
[19:01:06] <yuvipanda>	 Committer
[19:01:42] <valhallasw`cloud>	 yuvipanda: how?
[19:02:29] <valhallasw`cloud>	 but I remembered the trick
[19:02:31] <valhallasw`cloud>	 HOME=/home/valhallasw git
[19:02:38] <valhallasw`cloud>	 HOME=/home/valhallasw git commit --amend --reset-author
[19:02:45] <Coren>	 andrewbogott: 'deployed'?  Do you mean ran?
[19:02:50] <yuvipanda>	 http://stackoverflow.com/questions/7013085/git-removing-commiter-information
[19:03:00] <yuvipanda>	 Reset author works too
[19:03:15] <andrewbogott>	 Coren: I mean… now that I’ve changed the file in git… how does that change land in the actual place where the actual tool is used?
[19:03:31] <andrewbogott>	 in other words, ‘deployed’ :)
[19:04:04] <valhallasw`cloud>	 yuvipanda: so with complicated env vars? :P
[19:04:41] <Coren>	 andrewbogott: It's not done automatically atm; I normall just do a clone and run it there.  There is one in root's home on labstore1002 which is handy - you can simply git pull and run it there.
[19:05:06] <Coren>	 andrewbogott: ~/maintain-replicas
[19:05:07] <andrewbogott>	 Coren: ok, as long as you clone each time before running then that’s fine
[19:05:10] <yuvipanda>	  Life is complicated man. After trying to find an apartment in SF I'll take git any day over that.
[19:05:29] <Krenair>	 You can tell it's not automatically run by the current table being out of date :)
[19:05:38] <Coren>	 andrewbogott: Does your change have an impact we want to push now?
[19:05:38] <valhallasw`cloud>	 yuvipanda: :D
[19:05:52] <andrewbogott>	 Coren: It’s just cleanup as far as I know, but it might make Krenair happy
[19:06:08] * Coren runs it now then. Happy is good.
[19:06:47] * andrewbogott acts in the spirit of Cleanup Day
[19:07:08] <valhallasw`cloud>	 yuvipanda: https://gerrit.wikimedia.org/r/#/c/240451/
[19:07:17] <valhallasw`cloud>	 lintian cried
[19:07:25] <Coren>	 Krenair: What was your change?  Just to check it applies right
[19:07:34] <yuvipanda>	 Awesome 
[19:08:11] <Krenair>	 Coren, change to the script or the data it's supposed to be outputting?
[19:08:24] <valhallasw`cloud>	 yuvipanda: so for the backporting route, I think we need to backport several packages. That's not necessarily a bad thing (means more is available for php users) but also more work
[19:08:34] <Coren>	 Krenair: Well, I expect the former was made for the latter?  :-)
[19:08:41] <Krenair>	 no
[19:08:46] <valhallasw`cloud>	 yuvipanda: this took me about half an hour including shouting at gem
[19:08:58] <Krenair>	 the data is out of date because you haven't run it for a while (it should be automated)
[19:09:09] <Krenair>	 the script was changed to not make that nonsense centralauth entry
[19:09:42] <Coren>	 Krenair: There have been enough issues with replication in the past that I absolutely don't want it to run without having a human around to double check the results.  Although, nowadays, that may not be as critical as it once was.
[19:11:30] <Coren>	 Krenair: It's just that this should be a step in what to do when doing schema changes or new wikis.
[19:12:05] <Krenair>	 Or changing the names of existing wikis
[19:12:07] <Krenair>	 Or renaming wikis
[19:12:23] <Coren>	 Does that ever happen?
[19:12:24] <Krenair>	 Or changing VE/Echo/whatever status on a wiki
[19:12:29] <Krenair>	 Does what ever happen?
[19:12:37] <Coren>	 renaming existing wikis?
[19:12:44] <Krenair>	 Yes, just last week
[19:12:47] <Coren>	 Oh.
[19:12:53] * Coren ponders.
[19:13:28] <Coren>	 Well, I think that the maintain-replicas process has been stable enough for long enough that automating it wouldn't be insane anymore.
[19:13:40] <Krenair>	 Recently, chapcom.wikimedia.org was moved to affcom.wikimedia.org, be-x-old.wikipedia.org to be-tarask.wikipedia.org and et.wikimedia.org to ee.wikimedia.org
[19:13:41] <valhallasw`cloud>	 yuvipanda: ok, so added tools.admin to tools.dpkg, so you should be able to login there as well. Although sudo would have done the job as well ;-)
[19:13:52] <Krenair>	 more are planned once some interwiki/sitematrix/langlist stuff is sorted
[19:27:51] <valhallasw`cloud>	 yuvipanda: yeah, I think we should go the fpm route
[19:28:03] <valhallasw`cloud>	 backporting makes me very unhappy
[19:28:33] <valhallasw`cloud>	 errors, errors everywhere
[19:30:11] <valhallasw`cloud>	         --version-string=1.3.1-2~toollabs1+1)   <-- ) unexpected
[19:30:14] <valhallasw`cloud>	 I don't even.
[19:30:42] <valhallasw`cloud>	 crappy debian/rules, I guess.
[19:32:48] <valhallasw`cloud>	 sed 's/.*(//;s/-.?*).*//'   <-- what does that do O_o
[19:33:10] <valhallasw`cloud>	 expecially the //;s/-.?* part
[19:41:04] <Coren>	 valhallasw`cloud: That's just two s// commands separated by a ;
[19:41:15] <valhallasw`cloud>	 oooooooooh
[19:41:29] <valhallasw`cloud>	 ok, that makes sense
[19:47:26] <valhallasw`cloud>	 and of course the debian bug tracker is impossible to work with as well
[19:47:28] <valhallasw`cloud>	 emails :(
[20:19:27] <krrrit-wm>	 (03CR) 10Niedzielski: "@Yuvipanda bump" [labs/tools/wikipedia-android-builds] - 10https://gerrit.wikimedia.org/r/231697 (https://phabricator.wikimedia.org/T99115) (owner: 10Niedzielski)
[20:20:35] <krrrit-wm>	 (03CR) 10Yuvipanda: [C: 032 V: 032] "goodenough :)" [labs/tools/wikipedia-android-builds] - 10https://gerrit.wikimedia.org/r/231697 (https://phabricator.wikimedia.org/T99115) (owner: 10Niedzielski)
[20:20:40] <valhallasw`cloud>	 yuvipanda: so for tools-packages, do you want to install the package-builder role?
[20:20:44] <valhallasw`cloud>	 or do you want to keep that seperate?
[20:21:03] <yuvipanda>	 hmmm
[20:21:05] <yuvipanda>	 I don't know
[20:21:08] <valhallasw`cloud>	 it's a Jessie host, which is good because pacakge-builder was built for that
[20:21:13] <yuvipanda>	 wait
[20:21:15] <yuvipanda>	 what's tools-packages?
[20:21:17] <yuvipanda>	 is that a new host?
[20:21:36] <valhallasw`cloud>	 the aptly host
[20:21:58] <yuvipanda>	 aptly was in tools-services-01
[20:22:13] <valhallasw`cloud>	 eeeeh
[20:22:17] <valhallasw`cloud>	 I don't know then/
[20:22:50] <valhallasw`cloud>	 maybe tools-packages was scfc's test host?
[20:23:00] <yuvipanda>	 I think so
[20:23:10] <yuvipanda>	 but yeah, I'm ok with creating a new host for package building
[20:23:12] <yuvipanda>	 and making it jessie
[20:23:26] <yuvipanda>	 but idk, long term we shouldn't really be building packages iMO
[20:23:27] <yuvipanda>	 IMO
[20:23:34] <yuvipanda>	 long term ~ a year or so, I guess
[20:23:40] <valhallasw`cloud>	 yuvipanda: so what do you want to do with composer, then?
[20:24:19] <yuvipanda>	 valhallasw`cloud: git clone them symlink to /usr/local/bin?
[20:24:49] <valhallasw`cloud>	 ew.
[20:25:00] <valhallasw`cloud>	 I mean, it's an option
[20:25:13] <valhallasw`cloud>	 but the whole point of packages is to have that stuff nice and bundled
[20:25:21] <yuvipanda>	 well
[20:25:25] <yuvipanda>	 if we update compose
[20:25:27] <yuvipanda>	 r
[20:25:29] <yuvipanda>	 in the repo
[20:25:32] <yuvipanda>	 then we'd have to rebuild
[20:25:33] <yuvipanda>	 and re-deploy
[20:25:36] <valhallasw`cloud>	 *nod*
[20:25:46] <yuvipanda>	 if composer itself had packages...
[20:25:49] <yuvipanda>	 and other people took care of the updating
[20:26:12] <valhallasw`cloud>	 we could automate the building, I suppose.
[20:26:26] <yuvipanda>	 and the deploying
[20:26:39] <valhallasw`cloud>	 yeah, fpm-aptly and then apt does the rest
[20:28:53] <yuvipanda>	 fpm-aptly?
[20:28:54] <yuvipanda>	 is that a thing?
[20:29:01] <valhallasw`cloud>	 heh, no
[20:29:16] <valhallasw`cloud>	 it should be ;-)
[20:30:24] <yuvipanda>	 :D
[20:30:30] <yuvipanda>	 depends on how much time we want to put into it I guess
[20:34:06] <valhallasw`cloud>	 I would really like there to be a puppet wrapper saying 'everything in this wrapper should be packages and installed as MyAwesomeThing.deb'
[20:34:23] <valhallasw`cloud>	 but that's probably not very realistic ;-)
[20:34:32] <yuvipanda>	 yeah
[20:34:40] <yuvipanda>	 also I am curious how this will intersect with docker
[20:34:47] <yuvipanda>	 for things like scipy and stuff
[20:34:58] <yuvipanda>	 they provide official containers we can make available to people
[20:35:07] <valhallasw`cloud>	 a scipy container?
[20:35:26] <valhallasw`cloud>	 that's cool
[20:35:43] <valhallasw`cloud>	 so I think for containers, we might want to provide pre-built wheels?
[20:35:47] <yuvipanda>	 valhallasw`cloud: https://hub.docker.com/u/scivm/
[20:35:53] <yuvipanda>	 we don't need to provide wheels
[20:36:23] <yuvipanda>	 we can just provide base images
[20:36:36] <yuvipanda>	 my goal is also to allow people to tes locally
[20:36:39] <yuvipanda>	 so they can develop locally
[20:36:47] <valhallasw`cloud>	 ok, so now I've got a base image 'scivm' and one which includes some other hard-to-build package, and I need both
[20:36:48] <yuvipanda>	 still working out details slowly
[20:37:19] <yuvipanda>	 let's handle that problem when we get there :D Most I think will just be numpy / scipy / scikitlearn
[20:37:22] <valhallasw`cloud>	 oh but people can just apt-get of course!
[20:37:25] <yuvipanda>	 yeah
[20:37:26] <yuvipanda>	 they can
[20:37:39] <valhallasw`cloud>	 brilliant
[20:37:43] <yuvipanda>	 so it's a problem only if they want to use a really old or really new version
[20:46:45] <UA31_>	 When I start a process with jstart, the process does not write files
[21:09:28] <ottomata>	 heya, i made a new instance in the deployment-prep project yesterday
[21:09:52] <ottomata>	 looks like puppet isn't configured properly there?
[21:09:54] <ottomata>	 Could not request certificate: Connection refused - connect(2) for "" port 8140
[21:09:59] <wikibugs>	 6Labs, 10Tool-Labs, 5Patch-For-Review: Require membership in the Tools project for mail forwards to work - https://phabricator.wikimedia.org/T93526#1667969 (10scfc) 5Open>3Resolved a:3scfc Tested with `scfc` and `zvd` to succeed and fail respectively.
[21:10:01] <ottomata>	 that's from get console output
[21:10:24] <ottomata>	 Could not request certificate: getaddrinfo: Name or service not known
[21:15:08] <shinken-wm_>	 PROBLEM - Puppet staleness on tools-worker-02 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [43200.0]
[22:42:30] <wikibugs>	 6Labs, 6operations, 10wikitech.wikimedia.org: intermittent nutcracker failures - https://phabricator.wikimedia.org/T105131#1668438 (10chasemp) 5Open>3Resolved a:3chasemp It's been 3 weeks now without a repeat, I'm going to resolve this but will be the first to reopen if we see it again :)
[22:50:13] <wikibugs>	 6Labs, 10Tool-Labs, 5Patch-For-Review: Convert updatetools.pl into a puppetized Python service with monitoring - https://phabricator.wikimedia.org/T94858#1668470 (10scfc) 5Open>3Resolved