[09:48:42] ema: the current strategy for releasing pybal is creating a new branch from the previous version (git checkout -b 1.15 origin/1.14) and cherry-pick the desired commits? [10:01:16] vgutierrez: hey! Nope, master -> 1.15 for new minor releases, cherry-pick of selected commits from master for patch releases. See README. [10:02:11] ema: hmmm I tried that, but the changelog that I get from gbp dch is huge :/ I'm doing something wrong obviously [10:09:25] vgutierrez: so, on boron:~ema/pybal, from master branch: `git checkout -b 1.15` [10:09:36] added a new entry to debian/changelog for 1.15.0 [10:09:49] ARCH=amd64 DIST=jessie WIKIMEDIA=yes gbp buildpackage -j8 -us -uc -sa --git-builder=git-pbuilder --git-ignore-branch --git-ignore-new [10:10:07] [...] [10:10:28] debdiff ~ema/pybal_1.14.4.dsc ~ema/pybal_1.15.0.dsc # shows a reasonable diff [10:13:05] right [10:13:54] it looks like it's only an issue with gbp dch and trying to auto-generate the changelog [11:28:39] 10Traffic, 10Analytics, 10Operations: Update documentation for "https" field in X-Analytics - https://phabricator.wikimedia.org/T188807#4023315 (10MoritzMuehlenhoff) p:05Triage>03Normal [14:34:15] 10Traffic, 10Analytics, 10Operations: Update documentation for "https" field in X-Analytics - https://phabricator.wikimedia.org/T188807#4023770 (10Tbayer) Very informative, thanks @BBlack! So I understand that these cases would explain the 1% of requests in T188807#4021737 that have NULL for `x_analytics_map... [15:37:36] 10Traffic, 10Analytics, 10Operations: Update documentation for "https" field in X-Analytics - https://phabricator.wikimedia.org/T188807#4023886 (10BBlack) >>! In T188807#4023770, @Tbayer wrote: > And is it correct to assume besides those HTTP --> HTTPS redirects, there are other cases where we send a 301 rep... [15:48:30] vgutierrez: so, while you're working on 1.15.0, you might want to add yourself to the Uploaders field in debian/control to make lintian happy [15:49:41] and myself too as I've forgotten to do that :) [15:50:00] sure :D [15:57:04] done [15:57:19] vgutierrez: BTW you can either run `lintian -i pybal_1.15.0_amd64.changes` yourself, or look at the debian-glue jenkins job [15:57:44] (eg: https://integration.wikimedia.org/ci/job/debian-glue-non-voting/1778/console) [16:04:42] I see lintian output, but I'm unable to see lintian complaining about us being missing in the Uploaders field [16:05:25] https://integration.wikimedia.org/ci/job/debian-glue-non-voting/1778/artifact/pybal-1.15.0+0~20180305113952.1778+jessie+wikimedia~1.gbp7a84bc.lintian.txt [16:05:45] VS https://integration.wikimedia.org/ci/job/debian-glue-non-voting/1779/artifact/pybal-1.15.0+0~20180305155647.1779+jessie+wikimedia~1.gbpbddbd6.lintian.txt [16:07:58] in one of the last ops meeting it was mentioned that we have defective network hardware at eqsin, that's nothing that would block a reboot of bast5001, though I guess? [16:08:55] vgutierrez: does lintian also complain if you run it by hand? It might be that the jenkins job does some magic using its own stuff as the maintainer name/email in debian/changelog perhaps [16:10:00] lintian on boron is also probably much older than what you have on sid [16:10:36] (you're going to kill me but... I *do* miss fpm so much) [16:10:47] O:) [16:15:35] ema: hmm you were referring to changelog-should-mention-nmu [16:15:37] ? [16:15:42] vgutierrez: yes [16:18:09] right, with the second changeset, in boron it's dropping the warning [16:22:00] very well then, it worked :) [16:58:08] moritzm: no, shouldn't block *logically* reboot of any eqsin servers (can do that at will, e.g. today). But sometime this week, fixing the defective network hardware will cause a site outage for eqsin for a day or two, which may in practice make it difficult to connect to get reboots done. [16:58:50] moritzm: the easy answer is upgrade+reboot all eqsin today. there's no production dependency on any of them, so they can be downtimed and rebooted at-will. [17:00:32] ok, I was just wondering whether the broken switch might cause any complications. I'll reboot the remaining eqsin hosts tomorrow morning Euro time if that's still ok time-wise (I'll be afk after the SRE meeting) [17:03:46] yeah I think if you stick to early half of euro day it should be ok. [17:04:02] after that, I can't make gaurantees about when the fixing starts and access is effectively broken. [17:04:29] (well maybe I should stare at timezones again, it's confusing) [17:04:59] ema: there is any hard difference between the .deb file that ends in /var/cache/pbuilder/result/ and the one in $HOME? [17:05:12] bblack: ok! [17:07:29] 10netops, 10Operations: cr1-eqsin faulty interfaces - https://phabricator.wikimedia.org/T187807#4024176 (10BBlack) The shipping company has updated: `05-Mar-2018 18:34:00 SGT Proof of Delivery Rcvd` [17:12:33] vgutierrez: the one to use is the one in pbuilder's cache, also because is the only one you can rsync from install1002 ;) [17:13:25] also, not sure if there is anything specific, but I don't get any .deb in my $HOME when building [17:15:37] XioNoX: did you wanna make an onsite task for papaul in eqsin [17:15:41] for the new sfp modules? [17:15:48] they are in eqsin shipping awaiting pickup [17:15:57] (ill make the task but id like you to review what ports he is changing out ;) [17:18:34] (post meeting) [17:20:37] https://phabricator.wikimedia.org/T188923 [17:20:40] 10Traffic, 10netops, 10Operations, 10ops-eqsin: replace sfp+ in use in eqsin EX4600 - https://phabricator.wikimedia.org/T188923#4024207 (10RobH) p:05Triage>03High [17:21:29] robh: hi :) I put a task list in the etherpad for asia goal, that's the only place I've pulled them all together for this trip so far, other than linking to papaul privately [17:21:37] robh: but yeah a consolidated task would be nice [17:22:39] 10Traffic, 10Analytics, 10Operations: Investigate and fix odd uri_host values - https://phabricator.wikimedia.org/T188804#4024228 (10fdans) [17:23:50] 10Domains, 10Traffic, 10Operations, 10WMF-Design, and 3 others: Create subdomain for Design and Wikimedia User Interface Style Guide - https://phabricator.wikimedia.org/T185282#4024232 (10Volker_E) @MarcoAurelio As you've accomplished T188887#4023319 I'd like to ask you for support here as well… :) [17:25:36] volans: that makes sense :D [17:33:39] 10Domains, 10Traffic, 10Operations, 10WMF-Design, and 3 others: Create subdomain for Design and Wikimedia User Interface Style Guide - https://phabricator.wikimedia.org/T185282#4024287 (10MarcoAurelio) @Volker_E Sorry but I don't think I'm able to do what it's requested here (that is, create page under the... [17:46:05] 10Traffic, 10Analytics, 10Operations: Investigate and fix odd uri_host values - https://phabricator.wikimedia.org/T188804#4020291 (10BBlack) The bottom line is that the value of `uri_host` is entirely up to the client, and therefore subject to client-side stupidity. It's legal (in all protocol senses) for a... [23:14:07] 10Domains, 10Traffic, 10Operations, 10WMF-Design, and 3 others: Create subdomain for Design and Wikimedia User Interface Style Guide - https://phabricator.wikimedia.org/T185282#3911827 (10Volker_E) Sorry @MarcoAurelio, identified that you were just the courier on the other change. Have reached out to @demo... [23:30:00] 10Traffic, 10DNS, 10Operations, 10Release-Engineering-Team, and 2 others: Move Foundation Wiki to new URL when new Wikimedia Foundation website launches - https://phabricator.wikimedia.org/T188776#4019041 (10Platonides) Please remember to 301 /wiki/.* to the new url…