[02:46] "tox -e integration-tests" would be the best way to run integration tests [02:46] you can pass pytest arguments to it [02:46] e.g., tox -e integration-tests tests/integration_tests/modules/test_combined.py [02:47] I'll update the documentation accordingly [03:13] oh cool [14:35] holmanb: any progress on that patch? need help? a review? ping me on github as @igalic [14:47] meena: apologies, I misunderstood. I thought you were going to submit a PR. I'll ping for a review on github shortly [14:48] holmanb: I am, sadly, still swamped in work and childcare duties [14:48] meena: no worries :) [14:49] trying to open my laptop while my toddler is awake, means someone is climbing on me, and that doesn't seem conducive to … doing things [14:49] like, the patch is right there! emaste wrote it :P somebody who's signed a CLA just needs to submit it, and then somebody will ask, but what about tests??!!? [14:54] meena for review when you get a chance: https://github.com/canonical/cloud-init/pull/1236/files [14:54] Pull 1236 in canonical/cloud-init "cc_salt_minion freebsd fix for rc.conf" [Open] [14:56] holmanb: that'll now break on linux. You want this patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254339#c5 [14:56] bugs.freebsd.org bug 254339 in Ports & Packages "net/cloud-init: fix modifying rc.conf in cc_salt_minion" [Affects Only Me, Open] [14:57] no, never mind [14:57] there is no linux code in there lol [14:58] or rather, it's done differently somehow, or it's not necessary [15:00] and on line 64, we could also rename that package to: 'sysutils/py-salt' that would make it future proof. cuz there's no py36-salt anymore [15:03] meena: +1 updated [15:04] holmanb: and tests still somehow pass? [15:06] meena: checking now [15:07] oh, we're still using Travis CI… [15:22] meena: unit and integration tests passed, I just pushed a small format change [15:23] hrm, forgot that my review isn't worth a green tick [15:25] meena: Your review is still appreciated, thanks! === djhankb6 is now known as djhankb [19:44] meena: holmanb thanks. +1 on that PR. do you think it's worth calling out Co-Authored-By: b..@...bsd.org in the changelog there? [19:46] or do we/BSD contributor emails prefer to be anonymous upstream? [19:48] strange question of attribution in this case for me. [19:50] @blackboxsw: +1 good call asking, I'm definitely not the original author :-) [19:53] for sure I'm sitting at the "Squash merge" button in github, so figured we should make sure context on that commit is desired. Also, for BSD cases where we have bugzilla references I wanted to introduce a "bsdbz: #" footer like we have done w/ redhat via "rhbz: |url" and "boo: " [19:54] boo === suse like https://bugzilla.suse.com/show_bug.cgi?id=1080595 not sure why that abbreviation though [19:54] bugzilla.suse.com bug 1080595 in openSUSE Distribution "cloud-init uses missing wheel group" [Normal, Resolved: Fixed] [19:57] hmmm, nothing about boo implies suse to my brain, but bugzilla.opensuse.org -> b.o.o perhaps? [20:04] ahhh yes b.o.[o]rg [21:50] blackboxsw and paride : now that I think about it, I'm not sure we should have jenkins jobs that use IN_PLACE . If we want things to be faster, we can still git clone the repo and run the tests out of git, but instead just specify ppa:cloud-init-dev/daily as the CLOUD_INIT_SOURCE [21:51] falcojr: only diff we have there though is that it's a two hour turnaround after something commits to trunk that optimally we can see those packages hit daily. [21:52] but as pointed out in https://github.com/canonical/cloud-init/pull/1237#pullrequestreview-872443537 , we'll have failures due to configuration files not being in place, and they'll only be in the right place if we use an actual package [21:52] Pull 1237 in canonical/cloud-init "testing: stop universally overwriting /etc/cloud/cloud.cfg.d" [Open] [21:53] that said. grr. ubuntu/bionic daily is recipe broken too. I think when we landed the new-upstream-snapshot to handle black formatting, we inadvertently introduced merge conflicts again main. [21:54] we need notifications for when daily builds fail [21:59] blackboxsw: this doesn't appear to be black related [21:59] it's yelling about some of the recent schema files which are post-black...not sure why we're not seeing a clean upstream snapshot [21:59] yeah, though merge conflicts started Jan 24th I think [22:00] just starting to look too. it coincides with commit 872eebd2cbe6898260e4a8559ce07dc452d84ff4 [22:01] if I git reset to that commit and try new-upstream-snapshot things succeed without conflict I think. double checking [22:01] OH...did we squash that? [22:01] the upstream snapshot is a single commit [22:02] we'll have to reset before that and upstream snapshot again [22:05] yep. darn it. you're right. bbsw squash merge button blame :/ [22:06] blackboxsw: Haha...all good. I've almost done that on packaging branches too many times [22:06] yep will dr the branch now. [22:08] blackboxsw: actually, we could probably interactively rebase and just remove that commit altogether [22:08] then do a new-upstream-snapshot [22:08] might be the easiest way to keep our packaging commits [22:08] ahh, wait...nm [22:09] there's packaging changes in there too [22:09] yeah it's a bit more annoying :/ [22:19] falcojr, holmanb: my blackboxsw/ubuntu/bionic is the unsquashed version of those commits that I rebased/replayed from brett's PR 1203 and JAmes' 1220 [22:19] blackboxsw: did you close the PR already? And how'd you do that so quickly? [22:20] there's no git diff in the upstream/ubuntu/bionic and blackboxsw/ubuntu/bionic but the commit history is different [22:20] falcojr: I closed the PR because I accidentally targeted it to upstream/main [22:20] but github doesn't allow me to create a PR against ubuntu/main because there is no "diff" to speak of (only git history diffs) [22:21] I mean I can't create a PR from blackboxsw/ubuntu/boinic which targets upstream/ubuntu/bionic [22:21] here's my +1 if there's no diff...we usually merge those on the CLI anyway [22:22] the only way to "fix" my error here is either --force push to correct git history there (which should not break our build recipes because they base on number of commits past last annotated upstream version) [22:22] yeah will force push that now and kickoff bionic build recipe [22:22] thx [22:22] and yes we need a better signal for recipe failures [22:28] blackboxsw/ubuntu/bionic doesn't inlcude 1203 or 1220, looks like the latest hash is 65bba5 [22:28] am I looking at the wrong thing? [22:30] holmanb: you are looking at the right thing. /me forgot to hit enter on my git push --force [22:31] holmanb: commit should be a00215bb2139b26859df21121136e6b731132e5a [22:31] I see it now, thx [22:31] blackboxsw: is that local, or did you push that to origin? [22:32] falcojr: https://github.com/blackboxsw/cloud-init/commits/ubuntu/bionic [22:32] falcojr: it is "local to blackboxsw remote" I haven't pushed to origin yet. And github does let me create a PR (now that I correctly pushed to my repo) [22:32] nm...I had seen the same thing as Brett, but after a fetch they match now [22:35] I'm putting a PR up now that github can see the difference so we can track this [22:42] holmanb: falcojr https://github.com/canonical/cloud-init/pull/1242 [22:42] Pull 1242 in canonical/cloud-init "Ubuntu/bionic" [Open] [22:42] if approved. I'll force push this to ubuntu/bionic (once I assert merging and sbuild generates the package without errors [22:49] forced update to make sure I'm using the specific cherry-pick from tip of upsream/ubuntu/bionic stlll no diff, but proper authorship etc. [22:50] running through sbuild etc now and will post results to PR. [23:00] thanks folks. build package is good. just walking throgh manual recipe merge steps to confirm main merge ubuntu/bionic without conflicts [23:14] code sync'd for bionic via jenkins jobs. I'm kicking off the bionic build recipe and will kick off subsequent jenkins jobs for bionic once daily PPA contains latest