=== ikey|work is now known as ikey|zzz === wgrant__ is now known as wgrant === JoshStrobl is now known as JoshStrobl|zzz [07:01] mvo: hello [07:01] mvo: how are you doing? [07:02] mvo: I updated the mini-lab, the dragon board now has a HDD and swap so should be suitable for more tasks [07:02] hey zyga-ubuntu - good monring. I'm doing well, how are you? [07:02] mvo: I also made ssh keys sync hourly, though not to each device yet (just to the ssh hop) [07:02] mvo: I'm iterating on layouts and feeling good :-) [07:02] mvo: the damp weather is a good motivator to keep warm and code :) [07:03] mvo: I will also add power control to dragon-1, it's already wired but not scripted yet [07:03] mvo: how are your purchases going? [07:05] mvo: while not perfect I found a working way to have home on an external HDD on ubuntu core [07:05] zyga-ubuntu: nice progress! no news on purchases, still pondering [07:05] mvo: same with swap support [07:05] zyga-ubuntu: oh, nice, how do you do it? [07:05] mvo: I created two systemd mount units [07:06] mvo: ssh and have a look, it's remarkably working fine :) [07:06] mvo: I ran some tests on it overnight and I have an idea [07:06] mvo: when idle it could just pull master and run tests in a loop [07:06] mvo: and report failures [07:06] mvo: I saw a few things like "settle" something fail because of timing [07:07] mvo: also noticed that the board only reports 0.7GB RAM, I suspect the rest is used up by GPU, modems and what not [07:07] mvo: and I wanted to ask ogra if that could be tweaked for a headless builder [07:08] zyga-ubuntu: interessting. I have a look in a bit once I finished look at PRs, mail etc :) [07:08] mvo: sure :) [07:21] * zyga-ubuntu -> breakfast [07:22] ogra_: btw. commenting out that stuff in the psplash.c. It actually does not disable psplash-write. So may be you should disable it as well. When psplash-write is called text is drawn just as expected. [07:32] re [07:32] pstolowski: hello [07:32] pstolowski: question, there's a debian bug report about missing manual page for snapctl [07:32] zyga-ubuntu, good morning! [07:33] pstolowski: would you like to write one in restructured text like some of our other manual pages? [07:36] zyga-ubuntu, sure. do we generate man pages from built-in help? [07:41] pstolowski: I think that's largely insufficient, look at the manual page for snap-confine for instance [07:41] pstolowski: the help part is really one element [07:41] zyga-ubuntu, ok, will do, just looked at .spec for fedora and saw man page generated from snap --man tere [07:41] *there [07:42] pstolowski: that's not the same, again [07:42] pstolowski: unless you have 10s of options I really strongly encourage you to write it manually [07:44] zyga-ubuntu, okay. snap-confine.rst it is [07:45] pstolowski: thanks, I'll gladly help if you need anything [07:46] thanks zyga-ubuntu [08:20] * zyga-ubuntu fights the 14.04 battle [08:21] mvo: would it be possible to build snapd with golang 1.6 like on 16.04? [08:21] mvo: I just got a failure about C99 constructs that are probably because of older golang defauls [08:21] zyga-ubuntu: on 14.04? we use a backported go-1.6 [08:21] zyga-ubuntu: bug of course there is an older gcc there [08:21] mvo: aah [08:22] mvo: that makes sense! [08:22] thank you [08:23] well, one more rn [08:23] *run [08:27] zyga-ubuntu, you can turn off the GPU ram but wont be able to run accellerated graphics stuff... just drop the last line in /booot/uboot/config.txt [08:27] ogra_: oh, thank you [08:27] ogra_: do you think that would make sense as a core config option? [08:27] sborovkov, perfect, yeah, i''ll do that [08:28] zyga-ubuntu, probably ... we need to have it on by defautl so trhat mir works thugh [08:30] ogra_: yes, certainly [08:31] ogra_: I don't have /boot/uboot/config.txt - just uboot.env which is binary [08:32] zyga-ubuntu, bah, sory, i mis-read [08:32] i thougth you were n a Pi [08:32] aha, right [08:32] i dont think there is a way to tune that on a dragonboard [08:32] ogra_: ok, thanks [08:32] despite using your own patched kernel or so [08:33] one of those days we will get sodimms on the devkits :) [08:33] zyga-ubuntu, also ... the dragonboard is am64 ... the ram is not really eaten by GPU but by the fact that your binaries are about 1/3 bigge in ram [08:33] arm64 on small boards is a massive insanity [08:34] ogra_: oh? why does linux report 0.7GB memory total then? [08:34] (especially if the same board can run 32bit and eat half the ram in the end) [08:35] well, part of it is surely GPU ... but you will also use massively more ram for the binaries [08:36] sure but it looks like 0.3 is just reserved up front [08:37] yeah [08:37] as i said, i dont think thats tunable [08:37] despite recompilling parts [08:39] Issue snapcraft#1543 closed: Unable to specify make arguments [08:39] just a FYI ... htop in a beaglebone repts 48MB in use on a idle system ... with the same set of snaps installed, htop on rteh dragonboard reports 122MB [08:40] (there is some minimal overhead because the dragonboard uns wpa_supplicant and stuff, but you get the difference between arm64 and armhf) [08:48] ogra_: hi :) so from that script you provided me for using on the first boot. File system is always available? I am a bit confused about what's going on there.. I tried this if [ ! -d "/root/system-data/var/snap/screenly-client/" ] ; then psplash-write.... And checking for snap.json file. Somehow it executes that line on every boot :-( [08:48] sborovkov, oh, sorry, i improved that a lot already ... one sec. let me dicg it up [08:50] sborovkov, checking for state.json is the best thing to do here http://paste.ubuntu.com/25563809/ [08:50] sborovkov, it works fine here [08:51] (only shows on first boot) [08:51] great. [08:51] thanks [08:51] :) [08:51] I was checking it with -f [08:51] not sure why it shows up every time [08:53] ah [08:53] cause I did not check for /root/writable [08:53] but /root/system-data instead [08:53] ah, yeah [08:54] in the forum, when something is fix-committed, do i do anything or do i leave it on upcoming? [08:54] do i leave myself tagged in it? [08:56] isnt there ar "solution" tag that seta a gee checkmark and such ? [08:56] *sets [08:56] *green [08:59] Chipaca: I think we remove upcoming and name only when is fix-release [09:00] d [09:00] k [09:00] Chipaca: unless is some kind of code reorg/internal feature, then probably landing to master is enough [09:08] zyga-ubuntu: did you see that maciattobin board thing? [09:08] zyga-ubuntu: that looks like an arm64 device you could use without endless swearing [09:12] mwhudson: yeah but it's not a ref device, I would probably consider getting one of the server boards if that was one [09:12] true [09:13] mwhudson: (one of the older armv8 server boards with DDR slots and sata and everything) [09:13] which of those? [09:13] mwhudson: any that's available :) [09:13] ah heh [09:13] mwhudson: it would be interesting to have an UEFI device [09:13] zyga-ubuntu: mwhudson: and the OpenQ 820? [09:13] * Chipaca doesn't know what makes something a 'reference device' [09:14] Chipaca: our decision [09:14] ah :-) ok [09:14] Chipaca: btw, can you perhaps ssh into office.zygoon.pl? [09:14] I dunno [09:14] properly get cooties [09:14] I wanted to check if this works for you [09:14] zyga-ubuntu: that's still a mobile phone cpu isn't it? [09:14] mwhudson: ye [09:14] zyga-ubuntu: what's your fingerprint? [09:15] zyga-ubuntu: at least it has usb 3 and pcie so the fastest io probably isn't the wifi :) [09:16] (i read about the macchiatobin and the 820 reading about arm64 laptopts) [09:16] 256 SHA256:C3V0UBPGQHPToLeX/qcEAAGX02XbbwHDx0zQkVQtM74 mini (ECDSA) [09:16] 2048 SHA256:x4RFVP/TtE/nLtJ2WUO3dlLsavKWny7qeXNR1gHL3HA mini (RSA) [09:16] 256 SHA256:adjGbm4pxRSXYErI0y/bnQeaeJqCDfJKYPHPDLQxKoM mini (ED25519) [09:16] https://lwn.net/Articles/733837/ [09:17] oh wait, last two comments should have been at Chipaca :) [09:17] mwhudson: :-) [09:18] zyga-ubuntu: i'm in [09:18] zyga-ubuntu: minicom says i can't use the serial port [09:18] Chipaca: can you ssh into dragon-1 now [09:19] Chipaca: oh, I'll adjust that [09:19] Chipaca: you should be good now, also you should be able to hop onto dragon-1 [09:24] zyga-ubuntu: the pi3 asks me for my password [09:24] zyga-ubuntu: the dragon works [09:25] Chipaca: yes, pi is not configured yet, when I have more time I'll improve the script that sets this up to push accounts there as well [09:25] Chipaca: I mainly wanted to make the dragon available as most people have a working PI already [09:25] ah ok [09:26] Chipaca: and the dragon is a hit and miss it seems [09:26] Chipaca: feel free to use that any time [09:26] zyga-ubuntu: i can confirm minicom now lets me talk to the dragon [09:26] Chipaca: nice [09:26] zyga-ubuntu: why minicom and not screen, btw? [09:26] Chipaca: I will add a way to power the device on and off from mini [09:26] Chipaca: screen was corrupting input heavily [09:26] Chipaca: and minicom was solid [09:26] Chipaca: no idea, try screen [09:27] Chipaca: I also like minicom :) [09:27] :-) [09:36] PR snapd#3930 opened: cmd/snap-repair: integrate root public keys for repairs [09:43] Bug #1717857 opened: UDisks2 interface restricts sending DBus.Properties.Get message from the client to udisksd service [09:44] PR snapd#3931 opened: interfaces/builtin: allow receiving dbus messages [09:45] zyga-ubuntu: hm, is 3931 a regression? [09:46] mvo: no, it's an old bug [09:48] zyga-ubuntu: interessting that we have not gotten bugreports earlier [09:48] mvo: yep, looks like nobody really tried tihs [09:48] ppisati, i have been getting reports about SD corruption lately and i think we are hitting https://github.com/raspberrypi/firmware/issues/397#issuecomment-219287224 with some newer SD cards ... i suspect we'll need to collect some data and will need to ship some quirks like https://github.com/respeaker/openwrt/blob/master/target/linux/brcm2708/patches-4.4/0354-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch [09:49] ppisati, that is raspi2 only though [09:51] (i'm still collecting info, just a FYI) [10:03] ogra_: kernel version? [10:07] ogra_: and we already have those quirks applied [10:08] ogra_: i'm interested to know, if they experienced this on a 4.4.0-1071.79+ version [10:10] mvo: I just noticed reading the topic that the plan was that the script would just call 'repair' (not 'snap-repair') using some kind of symlink, it's a bit annoying but makes sense [10:11] pedronis: I was looking at the summary in the snap-repair show and was wondering if it makes sense to include the summary into the log output, it would make it easier for humans to inject the snap-repair directories using find/less/grep [10:11] pedronis: re 'repair'> sure, I can create a symlink [10:12] mvo: we could, a bit of a question of how to format it there [10:13] and how to present this in show itself [10:14] pedronis: yeah, I was thinking a tiny header like: "repair: canonical-1\nsummary: repair one\noutput:..." and we can/could either show in snap-repair show (even though slightly redundant) or just filter out in the command [10:15] pedronis: feels nice to have the relevant info in the file itself, was thinking e.g. filesystem corruption where fsck might not reconstruct the filename but the content. anyway, maybe overthinking this [10:16] hmm [10:16] Unpacking manpages-dev (4.13-2) ... [10:16] dpkg: error processing archive /tmp/apt-dpkg-install-FOEqdJ/39-manpages-dev_4.13-2_all.deb (--unpack): [10:16] trying to overwrite '/usr/share/man/man4/console_ioctl.4.gz', which is also in package manpages 4.10-2 [10:16] must be my lucky day [10:16] the systemd-virt-detect bug fixed itself [10:17] and now this strikes back from hell [10:17] pedronis: I will modify 3925 to create a dir with "repair" that symlinks to snap-repair and have that in PATH. we only need one,right? i.e. not snap-repair and repair (both names) for the repair script? [10:18] mvo: yes, sounds rights [10:18] *right [10:18] ta [10:18] ppisati, it is the curent pi2-kenel snap, namely AlbertA and bschefer are using the same SD type and brand and both have a corrupted booot pattiion after every core upgrade (which means daily if you use the edge channel... ) [10:19] ppisati, some 32GB sandisk ... i'm waiting for them to get online to get the manfid and stuff [10:20] ogra_: 4.4.0.1071.71 - edge [10:20] (sadly i shuffled the card into another board and cant currently use it in the pi) [10:20] ogra_: then no, it is not what i think [10:20] it seems to be oonly a small set of SDs but i hear about it regulary from users [10:21] mvo: about summary in output, I think it makes sense, just a bit wondering that it would be best to strip it out in show and have it separate, but we need to think what to do about newlines [10:21] ppisati, and i know we already have a quirks patch ... i just think it needs to cover some more cards [10:22] ogra_: ack, is there a way to reproduce it? [10:23] ppisati, for bschefer and AlbertA the overlays subdir on the boot partition gets messed up so the kms dtb doesnt get loaded and they end up without /dev/dri ... for them this is reproducable with every update [10:24] foo me on my card it used to be uboot.env that got corrupt, also reliably with every update [10:25] pedronis: yeah, I will ponder a bit [10:25] ppisati, my idea was to cllect their SD data, and let them try a patched kenel t see if it help ... but the behaviour sounds suspiciously like the erase issue from above [10:26] (specifically because they both have the same card exposing the same issue 100% of the time) [10:26] PR #100: Ongoing work on the capability APIs [10:27] *** baa-dum tish *** [10:27] zyga-ubuntu wins the price fr the 100st PR !!! [10:27] * ogra_ throws confetti [10:27] ogra_: makes sense - do you have an old edge image around? so i can try with some sd cards here, and to some update cycles [10:28] ppisati, http://people.canonical.com/~ogra/snappy/all-snaps/daily/ just pick an old one there [10:28] heh :-) [10:28] ogra_: cool, will do - pi2 or pi3? [10:29] ppisati, pi3 here but i bet it doesnt matter [10:29] * zyga-ubuntu tries a fix for the debian bug and goes to make more tea [10:40] * zyga-ubuntu itereates on manpages bug [10:41] and while spread runs let's test Fedora 25 update [10:45] mvo: that's something for you [10:45] https://github.com/snapcore/snapd/pull/3932 [10:45] PR #3932: spread: work around temporary packaging issue in debian sid [10:45] mvo: locally still going [10:45] PR snapd#3932 opened: spread: work around temporary packaging issue in debian sid [10:46] PR snapd#3933 opened: snap-repair: make `repair` binary available for repair scripts [10:48] zyga-ubuntu: ta [10:52] mvo: tests are rolling so I think this is a good fix [10:58] $ snap list [10:58] No snaps are installed yet. Try "snap install hello-world". [10:58] ppisati, hrm [10:58] ogra_: pi3 image of 3 days ago, i feel confused [10:58] ppisati, sounds like fixrct didnt run [10:58] 14 of sept image [10:59] darn, I ran out of disk space [11:00] ppisati, very weird, i tested them after fixrtc got fixed again [11:00] oh ... one sec [11:00] ogra_: let me try with the 15th and 16th of sept image [11:00] * ogra_ checks if edge actually has the latest kernel [11:02] hmm, no, latest kernel there [11:02] i thought perhaps edge would be behind [11:03] pedronis: do we allow newlines in the summary currently? [11:15] Son_Goku: thank you for pushing the 2.27.6 release out [11:15] my 2.27.6 is special, though :) [11:15] Son_Goku: yes, I know :) [11:15] it's better than all the other snapd 2.27.6 :) [11:15] Son_Goku: I'm testing it on F25 now [11:15] Son_Goku: though it's out already I wanted to finish it [11:15] Son_Goku: sorry for being slow, the weather is getting the better of me :/ [11:16] it's fine [11:17] how are you doing? [11:19] mvo: in principle yes, we don't check for them not to be there? we could prohibit them in asserts/repair.go if we want [11:25] zyga-ubuntu: alright I suppose [11:37] zyga-ubuntu, you should use stgraber's in-browser terminal that he uses for https://linuxcontainers.org/lxd/try-it/ and hook that up to native containers on the pi and dragonboard ;) [11:37] (for your device lab that is) [11:37] ogra_: is there a snap for the client part? [11:38] no idea :) [11:38] ogra_: I've redirected ports for mosh but I don't think we have a working mosh snap [11:38] but that sounds like an awesome spare-time project :) [11:38] ogra_: but you can mosh into the mac mini allright [11:38] having a central website to try ubuntu core in a browser on specific supported boards [11:39] ogra_: I need to get a 2nd hand desk rack [11:39] ogra_: I will add my other boards there but I have no space to make this reliable now [11:42] ogra_: btw, how do you power the dragon board? [11:42] ogra_: I've set 12V and 2A [11:42] yeah, that should be fine [11:42] ogra_: I wonder what the on-board regulators do [11:42] the 96boards boards all support 12-19V iirc [11:43] ogra_: is thre an optimal value that produces least waste heat [11:43] i think 12V/2A is fine [11:43] not sure how much lower you can go, there is a lot HW on the dragonboard [11:44] ogra_: fun fact [11:44] ogra_: I powered it last week using the PSP power adapter [11:44] ogra_: that's 5V [11:45] https://www.96boards.org/product/power/ [11:45] "The 96Boards CE boards require an 8-18V 2A power supply." [11:45] so you were lucky i guess :) [11:45] well now it should be solid :) [11:45] I was thinking about setting the limit to 3A [11:46] but even under load I see at most 0.5A [11:46] fun fact: the spec was *specifically* written to exclude powering it from USB/5V "because that's just too weak" [11:46] because you are not using all HW ... iirc there is GPS and such [11:47] also hook up some USB devices that go to full spec load of 0.5A [11:47] yep [11:47] tbr: it powers an external HDD using two USB ports [11:48] tbr: but now it's on 12V/2A supply [11:48] the 12/2 thing will guarantee that it stays fully functional if all onboard HW is powered and used [11:49] and all USB ports used [11:49] power budget is always spec'd to full load *everything* and a bit of safety margin (at least one would hope) [11:49] right [11:50] * Chipaca grabs the painkillers and heads back to bed [11:50] * zyga-ubuntu hugs Chipaca [11:50] Chipaca: stay strong, it's not even winter yet [11:50] heh [11:50] zyga-ubuntu: it's my back having a bad day, is all [11:50] * zyga-ubuntu reads https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations [11:50] i must've done something unexpected over the weekend [11:50] Chipaca: ouch, even more sympathy then :/ [11:51] like, the dishes /o\ [11:51] I know how bad that is [12:05] Bug #1710637 opened: Input falls through to gdm3 and terminates the session on Ctrl+C

(Ubuntu):Incomplete> [12:07] whaat? [12:07] check the desktop channel :) [12:27] mvo: hey, just FYI in case it blows up on us: https://forum.snapcraft.io/t/snap-remove-somesnap-triggers-keyboard-input-fallthrough-to-vt-ctrl-c-in-terminal-logs-out-of-current-gdm-session/2162/6 and https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637 -- we may need another release for that [12:27] Bug #1710637: Input falls through to gdm3 and terminates the session on Ctrl+C

[12:27]

[12:28] * zyga-ubuntu breaks for lunch before standup === ShalokShalom_ is now known as ShalokShalom [13:11] niemeyer, when you have time, could you have a look at https://github.com/snapcore/snapd/pull/3916 for the addition to the snap.yaml content for apps? [13:11] PR #3916: add support for socket activation in apps [13:17] jdstrand: hello [13:17] jdstrand: thank you for the review, I pushed more things and I think it's ready for re-review [13:18] jdstrand: I'd like to start proposing new PRs instead of iterating on this one as it's veryt hard to keep track of everything [13:19] zyga-ubuntu: I'm done with my big reviews, so anything extra is just making sure what I commented on is done [13:20] zyga-ubuntu: I assume you are talking about PR 3621? [13:20] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [13:22] zyga-ubuntu: that PR is tricky because we are doing retroactive reviews. ie, it is arguably fine when not called from snap-confine but when called from snap-confine, needs changes [13:22] jdstrand: yes [13:22] jdstrand: let's mark it as good then [13:22] jdstrand: and land it :) [13:22] jdstrand: I just cannot land it before you agree [13:22] but anyway, like I said, I finished the big reviews, all that is left is making sure that comments are addressed, so I think it will be mergeable soon [13:22] thank you [13:22] * jdstrand nods [13:37] ppisati, did you get anywhere with the newer images ? [13:39] koza, hmm, https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/reference/sending-files#receiving-files ... it doesnt seem like the mentioned "bluez-test" snap from there is in the store [13:39] *bluez-tests [13:40] ogra_: yes, so all the available daily (14/15/16 of sept) behave the same - snap list is empty [13:40] ogra_: but when installing the hello world snap, tra triggered the update of core [13:40] ogra_: so it did the update and rebooted fine [13:40] ppisati, seems the builder was stuck, there are new images nnow [13:40] $ snap list [13:40] Name Version Rev Developer Notes [13:40] core 16-2.27.6 2849 canonical core [13:40] hello-world 6.3 27 canonical - [13:41] ppisati, no, thats completely broken [13:41] ogra_: yeah, it should show more snaps, but i was looking after the corruption [13:41] ppisati, the device didnt get initialized ... else you would see the gadget and kernel snap in list ... what you have there is simply snapd that pulled in *another* core to be able to run hello-world [13:42] ppisati, well, lets wait for bschaefer or AlbertA ... they can definitely reproduce 100% [13:43] * ppisati tries the new daily [13:43] ppisati, in the case where you have an uninitialized image an upgrade wont actually upgrade the bootloader bits (because the image simply doesnt know about the bootloader) ... so thats pretty different [13:44] on proper images a core update re-writes the bootloader config [13:44] and thats where the corruption usually happens ... the vfat seems to be more prone to corruption than the ext4 partition in that case === ikey|zzz is now known as ikey === chihchun_afk is now known as chihchun [14:02] ogra_: the latest daily (18 of sept) is good, snap list report a list of snaps [14:03] phew [14:03] so the stale builds used soome old kernel before the no-change rebuild [14:04] $ snap refresh core [14:04] snap "core" has no updates available [14:04] yeah ... [14:04] do "snap refresh core --stable" [14:05] that force-switches the channel so it will definitely up/downgrade === JoshStrobl|zzz is now known as JoshStrobl [14:18] ogra_: did it, it rebooted fine and i'm back in - mmcblk0p1 is mounted and i can see its content [14:18] ppisati, great [14:18] ppisati, so your SD isnt affected [14:21] * ppisati tries with another sd card, just in case... [14:25] * zyga-ubuntu forgot about his daughter because of the 2nd call [14:35] pstolowski: hey [14:35] pstolowski: I'll gladly help you on that effort [14:36] mvo: can we land https://github.com/snapcore/snapd/pull/3932? [14:36] PR #3932: spread: work around temporary packaging issue in debian sid [14:39] jdstrand: thank you for a re-review [14:40] zyga-ubuntu: pstolowski: a bit worried that this will mean even more Plug/SlotInfo around and that will be confusing === JanC_ is now known as JanC [14:44] pedronis: if we add a interfaces.Connection type that stores PlugInfo, SlotInfo pointers nothing will (yet) change [14:44] pedronis: then some reshuffling to represent things this way [14:45] pedronis: as long as we don't land the plugdata branches it should not get more confusing than it is now [14:46] jdstrand: I didn't miss those btw, I was still under the impression that those can be merged separately [14:46] jdstrand: (so that this PR can land) [14:46] jdstrand: but I can make them here as well if you think this is necessary [14:46] zyga-ubuntu: is there a bts bug already about this issue in debian? if so, I think we should include a link to that so that we can remove this workaround once its fixed [14:47] zyga-ubuntu: well we have things like Plugs() []*Plug, Plug have identity sort of, PlugInfo don't [14:48] mvo: I didn't look [14:48] pedronis: yes but that won't yet change, I think [14:48] pedronis: unless I'm mistaken and we need to cross that bridge soon [14:49] zyga-ubuntu: there so small I think here is good. if we land them and something happens and the next one gets released, that isn't good. I could try to separate out the must haves and the should haves, but then it just makes the other PR review difficult cause we need to reference back to this one [14:49] thy're* [14:49] meh [14:49] they're* [14:49] jdstrand: yes, that's a good point (about the release) [14:52] zyga-ubuntu: I mean, I guess technically you create a PR for just the security audit changes, land that before 3621, then merge that into 3621, but I don't see any gain in that [14:52] * jdstrand is trying to get this to land fast too :) [14:52] jdstrand: I didn't want to do the simplification changes as I think they are not critical and don't have a security impact [14:53] zyga-ubuntu: those are the should have column [14:53] like I said, we can split it up, but I don't see any reason [14:53]