[05:46:37] In 15 minutes we'll switchover x1's master [08:35:18] volans: is there any documentation on how to (debian) package a new python library in our environment? [08:35:52] kormat: not sure, but I can walk you through it (and maybe we can improve wikitech in the process) ;) [08:37:20] 🏃‍♀️ [08:37:54] also there are multiple ways to do it ofc, I can tell you the one I used for existing projects [08:38:28] "multiple ways" -> they're all terrible, but _differently_ terrible :) [08:38:36] ofc [08:39:21] I see you're looking at the slides of the onboarding chat... it's great you remembered they exists :D [08:39:56] so, in short the way I used is: [08:40:09] - have a debian branch in the repo that will contain only the debian/ dir [08:40:16] it's not that bad these days, things are converging to common tooling (except the usual exceptions :-) [08:40:56] - use dh pybuild, that takes care automatically of the Depends (but not Build-Depends) [08:41:32] - might need to override the unit test stanza and/or the installman one [08:41:48] you can use https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/spicerack/+/refs/heads/debian/debian/ as bootstrap [08:42:28] and ask mor.itz any question you have :-P (joking, bother me first, no need for the big guns right away) [08:43:04] just ask here on IRC, many people will be able to help [08:43:16] 80% is really straightforward [08:43:26] 20% is magic :D [08:43:49] edge cases are projects which ship or depend prebuilt binaries (which is a constant pain for obvious reasons) [08:44:31] and sometimes packaging something unveils bugs in the project's setup/requirement definitions which were previously overlooked [08:44:39] kormat: then to build on deneb, see for example /home/volas/spicerack-release [08:44:51] * volans will maybe generalize it at some point [08:45:30] and there's also https://people.wikimedia.org/~jmm/slides/ [08:45:42] https://people.wikimedia.org/~jmm/slides/deb-101.pdf [08:47:43] moritzm: that looks useful, thanks :) [08:49:23] I should actually re-do the onboarding session for this for all the recent hires, I think the last one was mid March, so shortly before you joined :-) I'll ping you and everyone who joined SRE in the last months in the next days to coordinate a time slot [09:19:41] kormat: moritz will not much more than me, but our GSoC studend did I think a good job on packaging transfer.py at https://phabricator.wikimedia.org/diffusion/OSTP/browse/master/debian/ [09:23:59] indeed, that transferpy packaging looks really nice and clean, the only thing I noticed is that cumin should most probably be in Depends, not Build-Depends, as it will be needed at runtime, not build time [09:25:26] ? [09:25:30] it is a dependency [09:25:37] let me check [09:26:01] Depends: cumin, python3:any [09:26:18] you may not see it because it is a python-automatically solved dependency [09:26:52] great, I didn't expect cumin to do the right thing there, my bad :-) [09:27:31] yeah, python build tools solve most of the work for us [09:28:39] I think the biggest mistakes / aka know issues is the lack of a man page [09:28:49] and the binary being called transfer.py [09:29:59] but I belive most of the work was copy on paste from cumin, so that may also work for you, kormat 0:-) [09:30:04] *and [09:33:18] cumin has a manpage and a binary :-P [09:35:03] yeah, manpage is WIP [09:35:13] we run out of ideas to what to put there that is not just --help [09:36:09] the other was just habit, but it goes against debian policy [09:43:47] a man page with the help is a good thing, also it's zero-effor with sphinx [09:44:08] the only thing zero-effort with sphinx is swearing at it [09:44:21] see https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/cumin/+/refs/heads/debian/debian/rules#16 [10:53:50] <_joe_> volans: you don't even need a debian branch [10:54:07] <_joe_> Imho it's more work for no reward [10:55:16] kormat++ [10:55:20] <_joe_> moritzm: onboarding chats should be recorded so you don't have to re-do it every time :) [10:56:09] kormat: although I must say that getting creative with the insults can sometimes be a little tiring too [10:59:02] <_joe_> kormat: sphinx is zero-effort if you linted your code comments to be shpinx ready. So the trick is swearing all the time while you write code, so that then sphinx is "zero" "effort" [10:59:50] <_joe_> kormat: also add some linters to ensure you keep your docstrings in that insane format, and ofc those linters will break compatibility *with themselves* and *between themselves* every 3 months [11:15:47] 3.1415 months to be precise [11:26:56] <_joe_> that's not being precise at all [11:27:13] <_joe_> I mean, mediawiki does better than that [11:28:16] lol [11:48:12] _joe_: :D [12:36:29] PSA, T239928 was fixed and gerritbot will no longer spam IRC for new patchsets and such if you mark your patch as WIP. perfect when you're working on tricky puppet patches that involve a lot of running PCC over and over [12:36:30] T239928: wikibugs2 should not post on IRC for Gerrit changes marked 'WIP' - https://phabricator.wikimedia.org/T239928 [12:43:26] cdanis: neat :) [12:54:50] thanks, good to know! [19:10:23] ever noticed how Gerrit says "Consider how comments may be interpreted" message if you do inline comments that link to https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html ? i don't think i noticed before and not sure if it is trying to detect certain language. but all i did was completely agree with someone, not a hint of disagreement :) [19:11:26] ah, qchris found the upstream code. and it is completely randomized when you get it and when you don't. ok :) [19:28:03] <_joe_> mutante: yes it is and it irritated me because it was at the end of a long, helpful comment :P [19:28:33] <_joe_> and I went to re-read it, found nothing wrong, then wondered myself [19:28:48] <_joe_> and found it in the upstream code and I wasn't impressed [19:29:20] <_joe_> I mean I get the good intentions, but it actually made me waste time :P [19:31:21] _joe_: for a moment it felt like that is AI trying to interpret language but it seemed really unlikely Aaron implemented that as an easteregg :) [19:31:45] yea, confused me too because it was a very short but entirely positive comment [19:32:58] the tips are not bad but also somewhat culture dependent. for example the use of "i'm not sure" where the author is actually very sure [19:33:42] qchris is opening an upstream bug, fwiw