[00:55] rbasak: remind me after/before standup to ask about mocking [01:07] https://www.wired.com/story/james-damore-google-memo-harvard/ [01:16] http://www.telegraph.co.uk/news/2017/01/29/dont-call-pregnant-women-expectant-mothers-might-offend-transgender/ [01:16] I recommend buying a shotgun [01:16] mass insanity is around the corner lol === led2 is now known as led1 [06:24] jamespage: dpdk is in a-p likely to fail on tests soon, but ready for you to put the OVS-2.8 you have to its side [07:59] Good morning [08:02] cpaelzer: ack - I'll do a snapshot upload today === Guest21980 is now known as LaserAllan [11:15] jamespage: with the.1 in 17.05.1 it seems that the OVS dep8 tests also successfully run against the current OVS 2.7 [11:16] jamespage: I didn't expect that, but more likely it still finds the OLD libs that it was built against [11:17] jamespage: yeah it does, once your new OVS 2.8 is in we want to drop the old 16.xx DPDK binaries that are left [11:17] we now use version named libs - so all new ones will have 17.05 and such in their names [11:18] jamespage: anyway that makes the new one a valid candidate in a-p, and as discussed is waiting for your snapshot upload [11:19] I'm scheduling myself a check next week if we need/want to remove old binaries then or if all clears automatically [12:05] mdeslaur: good morning! If you have a couple of minutes, I'd appreciate if you could guide me a little in getting https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1709193 fixed [12:05] Launchpad bug 1709193 in gnutls28 (Ubuntu) "Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer" [Undecided,New] [12:07] hi sdeziel === RoyK_Heime is now known as Omninerd [12:08] hey [12:08] sdeziel: hrm, looks like an SRU....is there no patch pilot today that can upload it? [12:08] let me see if we have gnutls updates pending, one sec [12:08] mdeslaur: yes, SRU'ing this to Xenial/Trusty is my end goal === Omninerd is now known as Omninerd^Heime [12:09] mdeslaur: thanks fro letting me know about patch pilot, I didn't know that, joining ubuntu-devel now [12:10] sdeziel: I'm on patch piloting duty tomorrow, I can look at it then [12:11] just realized tomorrow is my turn :) [12:11] mdeslaur: that would be awesome. Until then, should I provide you more debdiffs and attach them to the bug? [12:14] zesty would be nice [12:15] mdeslaur: OK, I'll have zesty and trusty done then, thanks again! [12:15] gnutls28 in trusty is in universe and is missing a crapload of security updates...adding this may be a bit futile [12:15] oh, I would have hope to drop support for TLSv1.0 all around but still have some Trusty boxes... [12:16] sSMTP has always annoyed me for only supporting TLSv1.0 max ;) [12:16] ssmtp in trusty is probably linked to gnutls26 [12:18] you are right [12:19] looks like the same patch would apply to libextra/gnutls_openssl.c in gnutls26 [12:20] alright, thanks for looking === chmurifree is now known as chmuri [14:09] how to tell if a web server is installed? [14:10] any or a specific one [14:11] any [14:12] made a fresh vps install with ubuntu [14:12] apache is not installed because /usr/share/httpd is missing? [14:12] same goes for all? [14:13] sammyg: Check if there is a program listening to port 80/443. [14:13] port listener? what command? [14:14] nmap? [14:14] netstat -natu |grep 80 [14:16] dlloyd, returned something starting with fe80: with 80 colored red [14:16] Or the more recent `ss`: `ss -pln|grep '80\|443'` [14:16] not a lot to list there, if i only use netstat -natu [14:17] dpkg -l |grep 'nginx\|apache' [14:17] lordievader, command not found [14:17] ubuntu 16.04 [14:17] if you are root, netstat -natupd |grep 80 [14:17] will give you the process [14:17] or sudo that [14:18] O.o [14:18] lordievader, yup not found [14:18] what's the output supposed to look like? [14:19] ports are not listed [14:19] proto, rec, send, local, foreign, state [14:19] Custom image install, I suppose? [14:20] probably, it's from vultr [14:20] 0.0.0.0:22 so this would be the port? 22? [14:20] of course this is the ssh [14:22] nmap not installed but suggest installing it [14:22] so what commands can i use for port listening? [14:23] nmap? dpkg? ss-pln? netstat? [14:23] spkg is a package manager? [14:23] where do linux boxes put their web root? [14:24] "/usr/share/httpd"? [14:24] perhaps this is the safest way? for noobs? [14:24] to make sure [14:24] literally what [14:29] sammyg: Ubuntu puts the webroot, by default, at `/var/www`. [14:29] rbasak: around? [14:39] nacc: o/ [14:39] Sorry was otp [14:40] rbasak: cool, give me one sec [14:41] rbasak: so i'm trying to add a unit test for lint::derive_target_branch (new function) [14:41] it currently takes a list of branch of objects [14:42] OK [14:42] what's the best way to mock that? [14:42] as my parameterized unit test just has a list of strings (e.g., 'pkg/ubuntu/devel' [14:42] Does the implementation call many methods on the branch objects? [14:42] only two of them [14:42] b.branch_name [14:42] b.peel().id [14:43] I think you could do something like: [14:43] b.branch_name = unittest.mock.Sentinel [14:43] b.peel().id = unittest.mock.Sentinel [14:43] Oh, b = unittest.Mock() first, sorry. [14:43] You might need branch_name to be a string, actually, if derive_target_branch relies on that. [14:44] yeah, it needs to be astring [14:44] Do you not also need to mock a debian/changelog inside there? Or does derive_target_branch not need to look? [14:44] so that will create a singleton for each value? [14:44] nope [14:44] (at least not in the current implementation) [14:44] Yeah each time you use unittest.mock.Sentinel, it gives you a new value, for comparison purposes later. [14:44] cpaelzer: done - https://launchpad.net/ubuntu/+source/openvswitch/2.8.0~git20170809.7aa47a19d-0ubuntu1 [14:44] what if i want two of them to have the same b.peel().id ? [14:45] Then point them to the same object. [14:45] e.g. for the test of xenial-devel and xenial-updates being the same treeish [14:45] thatnks for your help on expediting the dpdk uploads for 17.05.1 [14:45] Either b2.peel().id = b1.peel().id [14:45] rbasak: right, but then i need to change my parameterization? [14:45] Or same_id = unittest.mock.Sentinel [14:45] b1.peel().id = same_id [14:45] b2.peel().id = same_id [14:45] rbasak: i mean, the test-runner currently doesn't know which case i'm testing :) [14:46] I see. [14:46] rbasak: which *type of test-case [14:46] rbasak: i mean, i can put that in as a parameter [14:46] but that seems a bit kludge-y? [14:46] [list of branch-names], same_hash [14:47] I can't think of a better way to fix this except by using real strings (bytes?) that are different, or by representing that you need them to be the same somehow in the data structure and then creating the mocks appropriately in the test function. [14:47] Another way might be to make a function that creates the structure, and make the parameters calls to that function. That's essentially the same thing though. [14:48] yeah, i think that's where i was getting stuck [14:50] HO if you like, and we can try it in a pad? [14:50] rbasak: joining standup early [14:50] omw [14:50] cpaelzer: can you think of a reason that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-crypt-gpg is only failing on s390x? [14:51] nacc: I'm there but brb. [14:51] rbasak: ack [15:13] nacc: looking === Ussat-1 is now known as Ussat [15:48] nacc: https://usn.ubuntu.com/usn/usn-3382-1/ [15:48] nacc: thanks! [15:49] mdeslaur: nacc: thank you both! [15:50] mdeslaur: nice, thanks! [16:44] nacc_: would you expect me to get the mapping from series codename to distribution from distro-info or from Launchpad? [16:45] distro-info has the advantage that it is faster, but gets blocked on a distro-info-data SRU when a new series is opened. [16:45] (including in Debian) [16:45] I suppose falling back to Launchpad might be an idea. === JanC is now known as Guest25300 === JanC_ is now known as JanC [17:23] rbasak: where distribution is an object? or the xx.yy ? [17:24] rbasak: i would expect we would not add a new dependency on distro-info unless we had an explicit reason to do so (i don't believe we use it at all currently) === nacc_ is now known as nacc [17:41] rbasak: i feel like sentinel is not behaving like i expected [17:41] rbasak: if you're around, i'd like to clarify [18:06] nacc: o/ [18:06] rbasak: i think i figured it out, but i'd like to clarify -- standup HO? [18:07] omw === fffkidney is now known as whitekidney === _ruben_ is now known as _ruben [20:19] nacc: need some help here, I can't figure out what git ubuntu lint is complaining about [20:19] it just says [20:19] ((0855986...))andreas@nsn7:~/git/merges/samba$ git ubuntu lint [20:19] Some lint checks failed. Please investigate. [20:19] let me paste a -v output [20:21] nacc: http://pastebin.ubuntu.com/25285660/ [20:27] I think I need a new way to clean a puppet cert at netboot provisioning, sigh. [20:46] ahasenack: have you pushed your branch anywhere? [20:46] ahasenack: i can try and debug locally [20:46] nacc: yes [20:46] nacc: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+ref/merge-samba-take2-1700644 [20:46] ahasenack: ok, one sec [20:47] thx [20:52] ahasenack: and that's with the snap? [20:52] yes [20:52] r115 === nacc is now known as Guest76500 === nacc_ is now known as nacc [20:58] ahasenack: ok, reproduced with the snap but not with master, checking still [21:00] nacc: ok [21:00] ahasenack: ok, reproduced with master on my bastion, i can debug it now [21:01] thx [21:01] and good luck :) [21:12] ahasenack: can you file a bug? i have the fix, but i need to figure out why it fixes it [21:12] ok, will do [21:15] nacc: done, https://bugs.launchpad.net/usd-importer/+bug/1710015 [21:15] Launchpad bug 1710015 in usd-importer "Unknown lint error" [Undecided,New] [21:17] ahasenack: thank you [21:23] ahasenack: ok, i think i see what's up [21:23] ahasenack: the linter is missing a check [21:23] yes? [21:26] ahasenack: there's a debian/rules change dropped from your deconstruct to your logical [21:26] yes, that famous one [21:26] winbind static buld? [21:26] build* [21:26] right, but that is not how our workflow works [21:26] I keep hitting edge cases [21:26] deconstruct should match logical exactly except for d/changelog and d/control [21:27] i think you just dropped it in the wrong place [21:27] the logical delta should be exactly what was uploaded before? [21:27] then I will have "add fix/drop fix" both under "remaining changes" [21:27] and then you would drop that bit on the rebase to new/debian [21:27] ahasenack: logical is unrelated to the remaining [21:27] ahasenack: it's not part of the new delta, it's all about hte old delta [21:29] ahasenack: that is, there was a bit of delta (afaict), which was this extra d/rules bit [21:29] ok, will try that way [21:29] ahasenack: it's not correct for that bit to not be in the logical delta [21:29] ahasenack: but it might be correct to drop it on the rebase to new/debian [21:29] does that make sense? [21:30] we'll see :) [21:30] i mean, just thoughts-wise, the above idea :) [21:30] I don't recall what we did last time [21:30] just that it was a drop with an empty commit [21:31] which felt very odd to me, because the empty commit was talking about removing that line from d/rules [21:31] right, i think that was on the rebase to new/debian [21:31] but was, you know, empty [21:31] so it was lying a bit [21:31] no, a drop should always be an empty commit (the way I do it) [21:31] as it's a removal of delta that used to exist [21:31] what you're dropping is the delta, which since you're rebasing onto debian means it's now an empty change [21:31] it's a 'documentation' commit :) [21:32] the edge case is that dropping this delta required two drops, in essence [21:32] in different points in time [21:32] I wonder if just uploading this simple fix to artful right now, removing that line from d/rules, and *then* doing this merge, wouldn't be clearer [21:40] ahasenack: right, the point is you can't do that in a merge in the 'old state' [21:41] ahasenack: you do it as part of the merge, in the new state [21:41] ahasenack: right, now, you're changing the delta in the old state [21:48] ahasenack: you absolutely can do what you're suggesting, but what i've been suggesting the whole time was to do it as part of the merge. You had that correct in your old merge. The only mistake (if you want to call it that) in the new merge is you did the change too 'early' :) [21:50] in another revision of the merge I did it later, but that got stale and I had no idea anymore about what was going on [21:50] (today) [21:50] I'll go back to deconstruct and don't drop the two commits, then get logical, and rebase on new/debian [21:51] ahasenack: yeah -- i mean, technically, your merge itself is fine :) [21:51] the end result [21:51] ahasenack: it's the workflow that got borked, which is what the linter is checking [21:51] yeah [21:51] I did check the cmocka builddep today, it's fine for us to keep it [21:51] and I'll explain in the MP what I checked and why it's fine [21:51] nacc: so this still warrants a linter fix? [21:52] ahasenack: yeah, i'm fixing the linter -- basically it hsould have detected a d/rules diff between logical and deconstruct [21:52] it actually was detecting it, just not telling you (becuase of an implicit return) [21:53] nacc: what I keep finding confusing is that by dropping both the commit that added that patch and d/rules, and the one that removed it partially, [21:53] I'm essentially stopping the bug from being introduced [21:53] so there is never a commit that drops just the d/rules bit [21:54] so I keep thinking "hm, let's see the commit that dropped the d/rules change. Oh my, it's emtpy, why?" [21:55] ahasenack: right, there wouldn't be, because you'd either be introducing a 'new' change to old ubuntu or not dropping something that doesn't exist on new debian [21:55] ahasenack: i think it's important to keep those two states distinct in your head (the old and new states) [21:55] ahasenack: old is essentially never changed, it might be refactored/reordered, etc., but the contentful changes are static [21:56] ahasenack: new can be whatever it needs to be to be correct :) [22:27] rbasak: ok, i pushed my branch of bug fixes and refreshed the MP to be ready-to-review, so i think you have 3 pending reviews from me [22:27] ahasenack: --^ that branch (bug-fixes-2 in my namespace) has the fix for your linter issue [22:33] rbasak: also, if you do need achangelog object, then i think we want to land https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/328607 before your branch, at least, so you can use git_repository::Changelog.from_treeish [22:33] rbasak: istr you mentioning that in our HO [22:50] nacc: ok [22:58] sarnold: who should I talk to on security about potential removal of nagios3 (already not in debian) but also promotion of icinga2 so we have a monitoring package in main? [22:58] sarnold: i can file the MIR, but just curious how security feels about nagios3 being in ubuntu and not in debian at this point [22:59] nacc: file a bug against nagios3 in launchpad asking for it to be removed, subscribe the ubuntu archive administrators [22:59] nacc: might not hurt to run it past IS first [22:59] sarnold: yes, that's already done :) [22:59] sarnold: but it's seeded [22:59] sarnold: so i probably will need to replace the seed with icinga2 [22:59] which will end up requiring a MIR, etc. [23:00] so might not happen til 18.04 [23:00] given where we are in the cycle? [23:00] tyhicks: --^ you may have an opinion here too [23:00] could be .. I've lost track of the backlog [23:00] sarnold: yeah, and it's rather late to add another one, i realize [23:00] sarnold: just trying to get my thoughts in order, so, at least, it can get done ASAP in 18.04 [23:01] (well, in that cycle, i mean) [23:14] nacc: still here? [23:15] ahasenack: yes [23:15] nacc: my rebase on new/debian: http://pastebin.ubuntu.com/25286639/ the troublesome commits are 3558c58 and 4b54cdb which I already ordered nicely one after the other [23:16] nacc: so the plan is to drop those two (d), then add an empty commit saying something like http://pastebin.ubuntu.com/25286633/ [23:17] nacc: or maybe change 4b54cdb to include the d/rules bit, and then both really cancel out, and then drop [23:17] reading [23:18] ahasenack: to be clear, both lines 11 and 12 are in the old delta? [23:18] yes, they are in the deconstruct tag [23:18] and logical [23:19] I can push it as it is now [23:19] nacc: I don't have any strong opinions here [23:20] ahasenack: that's ok, i'm just trying to understand [23:20] so say we all :) [23:20] ahasenack: it seems like they should be in the deconstruct but not the logical [23:20] ahasenack: oh but now i remember, they don't actually cancel themselves out all the way? [23:20] no, that's where I dropped them before [23:20] nacc: there's some benefit from focusing on the same system monitoring daemon as Debian but I wouldn't consider it to be a huge benefit from the security team's POV [23:20] nacc: correct [23:20] they don't cancel each other out [23:20] they should, but they don't [23:20] nacc: if icinga makes sense from a market share perspective, it is probably a good move [23:21] does anyone know how to really prevent apt-daily.service from running when booting a cloud-init image? [23:21] the answer here does not work - https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image [23:22] tyhicks: well, there hasn't been a release of nagios3 in ... 4 years [23:22] i passed the script as user-data to my ec2 instance and i still see evidence that the unit ran (by examining syslog) [23:22] tyhicks: that sort of feels ... not great for currency purposes [23:22] tyhicks: but yeah, we should figure that part out [23:22] tyhicks: ok, i'll defer to 18.04 on this, will probably re-engage your team at some point [23:23] nacc: right - Ubuntu would need to move to nagios4 (and maintain it all ourselves) or something else entirely [23:23] nacc: thanks for bringing it up early [23:23] tyhicks: yeah, i think the debian monitoring folks were basically orphaning it, so they let it die (and icinga2 is still maintained) [23:23] tyhicks: np, thanks for responding! [23:25] ahasenack: so this is my initial impression (or what I would expect). I would see in the logical tag's history (but not the deconstruct) a commit that replaces liness 11 and 12 with a commit containing just the change corresponding to http://pastebin.ubuntu.com/25286633/ except it would read "d/rules: compile windbind statically..." [23:25] ahasenack: then in the rebase to new/debian, i woudl expect to see that commit be transformed to an empty commit and dropped [23:26] ahasenack: oftentimes, i put in the [] in my logical something liek [previously undocumented] which is equivalent to your textual explanation [23:26] ahasenack: that way, the logical log still has a line per logical delta [23:26] and i can track each of those bits to commits (empty or not) in the new delta [23:26] nacc: but the removal of the d/rules line is not even in artful now [23:26] I can't put that in the logical [23:26] ahasenack: right, that's why mine doesn't have it as a Drop or anthing else [23:26] ahasenack: it is a literal " d/rules: compile statically" [23:27] ahasenack: which is is in the logical delta, as a difference from debian, in artful as it is now [23:27] isn't logical == deconstruct - changelog - metadata - duplicates? [23:27] duplicate == add and remove [23:27] contentfully (logical == deconstruct - changelog - metadata) [23:28] - duplicates would be a no-op if they are the sum of adds and removes [23:28] there is no add and remove in this case, so I left them in logical [23:28] this rule: [23:28] "An additional goal in this step is to consolidate the delta, e.g. sometimes a change is added in one Ubuntu release and then removed in a subsequent Ubuntu release. The changes, in this case, should simply be dropped. [23:28] " [23:28] doesn't apply [23:28] ahasenack: wait, i thought you just said there was? [23:28] it's an incomplete remove, it didn't remove the "add" fully [23:28] ahasenack: maybe a HO is in order? or we can talk tmrw if you'd rather [23:28] ahasenack: right, so it's still an add and remove [23:29] it just may not fit into the above sentence completely [23:29] Yeah we never figured out good wording for what we mean there. [23:29] logical is the "old state", right [23:29] it's just the delta trimmed down [23:29] it represents an existing state in that package in ubuntu at that version/release [23:29] logical is a description of the logical delta [23:29] yeah [23:30] I can only change that once I apply it to new/debian [23:30] no [23:30] then it becomes a new delta [23:30] well, sort of [23:30] you can change the *wording* as much as makes snese [23:30] Logical should be the previous delta made concise. [23:30] like in this case, where you have an incmpolete revert [23:30] this: [23:30] ahasenack: yeah, i'm fixing the linter -- basically it hsould have detected a d/rules diff between logical and deconstruct [23:30] your'e not changing the patch, just the description [23:30] that's what broke the linter before [23:30] if you are saying now that I should change the logical to drop those "fake dupes", then it will happen again [23:31] ahasenack: well "broke" :) it just didn't tell you why you had incorrect logical :) [23:31] still, incorrect [23:31] something I should fix [23:31] ahasenack: no, it won't happen again [23:31] i'm not telling yout to *drop* anything [23:32] but now you are saying I should indeed drop those two commits at the logical step? [23:32] ahasenack: i'm saying if you combine your two commits into one, there will be a change leftover! [23:32] not drop, combine [23:32] squash :) [23:32] if they were correct, the combine would be a drop [23:32] but they are not [23:32] yeah :) [23:32] so you squash them together, and notice hey, it didn't go empty -- so document what was missed [23:32] in this case, exactly that d/rules still says to compile winbind statically [23:32] not just document [23:32] fix [23:33] no [23:33] just document [23:33] you don't fix anything in the logical [23:33] but then the diff is still there, [23:33] yes [23:33] no [23:33] wait [23:33] what diff? [23:33] the diff *shoudl* be there in logical [23:33] the result of applying the fix and incompletely removing it [23:33] there is a remainder when you do that [23:33] logical == deconstruct - changelog - metadata [23:33] the remainder is in deconstruct [23:33] but not in your currnt logical [23:33] that's the reason the lint failed [23:34] yes, in deconstruct we are applying the fix and not fully removing it [23:34] right [23:34] then in logical I dropped (in the take2 branch) both, and that left a remainder that was unexpected [23:34] which emans you must do the same in logical [23:34] logical can't have different net contents than deconstruct [23:34] that violates the above equality we've said a few times [23:34] ok, with you so far [23:35] so what about this squashing? [23:35] if you had squashed the two commits together rather than dropping them [23:35] then your logical would have been correct [23:35] it would have been described wrong (as it would have a commit message talking about d/p/fix-1584485.patch when in fact the content of the commit was about d/rules [23:35] but it would have been contentfully correct [23:36] I shouldn't change the squashed commit message? [23:36] no you should :) [23:36] i was doing one thing at a time [23:36] ok, so I change it [23:36] do... *? -? [23:37] achiang: I'm playing around w/ ec2 this week (but making dinner right now) will check it tomorrow and see if disabling is possible. we'd had a couple of internal discussions about the viability of disabling it [23:37] but the remainder will still be there, the incorrect d/rules lines will be there [23:37] ahasenack: right, which si good, it's part of the delta currently [23:37] ahasenack: you're going to drop it *in* the merge, not before the merge [23:37] ahasenack: basically, the "old" stuff never changes (this is what i was trying to say before) [23:37] we just changed the commit message of the old stuff [23:37] contentfully never changes [23:38] metadata (like commit messages) can change [23:38] the order thigns are committed in, can change [23:38] but the endpoints should match (a la the equality we expressed above) [23:38] The logical is supposed to be exactly the previous delta, re-described. [23:38] If there was a mistake in the previous delta, the logical will still have the same mistake, but described as one. [23:38] contentfully: reconstruct = deconstruct = logical + changelog + metadata [23:39] what the actual commits look like in each is a separate point, but the above is what the linter is checking for [23:39] see, I'm an elecrtrical engineer, when someone says "exactly the same", that has a strong meaning to me :) [23:39] "actual commits look like in each" == `git log old/debian..` [23:39] ahasenack: exactly the same git-tree [23:39] (meaning filesystem contents) [23:40] Exactly how you choose to describe the logical (in terms of commits and commit messages) is subjective. But the diff of "git diff old/debian old/ubuntu" must be exactly the same as "git diff old/debian logical/..." except for metadata (update-maintainer etc) and debian/changelog [23:41] If the diffs aren't the same (except those exceptions), the logical is always incorrect. [23:41] right, that's what the linter was trying to express here, it just didn't spit out the message saying that (fixed in my branch) [23:41] well, now I have the diff the same [23:41] but the commits are not squashed [23:41] ahasenack: yeah, so i was trying to save you a step in your rebase :) [23:42] ahasenack: it's not strictly necessary, but i think makes it easier to review (given that i'll probably be reviewing, it's even less necessary :) [23:42] blackboxsw: from one developer's opinion, it is really unfriendly -- the service reaches out to the network and takes locks on your system with very little user visibility [23:42] ahasenack: do you want to push your logical as it is now? [23:42] I don't know [23:42] blackboxsw: i agree there is some utility there, but it feels more like an opt-in thing, rather than an opt-out [23:43] to me squashing the logical as you described "changes" it [23:43] or at the very least, make it possible to disable easily, somehow. the ec2 way would be to pass in a user-data script [23:43] but, the normal case where two commits really cancel each other out is a change fit for the logical step [23:44] ahasenack: it can't change it, afaict [23:44]