[01:42] <XV8> !info freeipa-server
[01:42] <ubot3> Package freeipa-server does not exist in groovy
[03:58] <DeeJayTwo> tds: yes from crontab
[06:28] <SuperLag> Can you guys think of a reason why networking would be working on a cloned VM? I'm trying to use Terraform to clone an Ubuntu Server VM on vSphere. And it's failing on the customization phase, and when I log in to the VM, there's no networking. There's an interface, but no IP assigned, and it doesn't seem to be responsive when I run "dhclient ens160"
[06:28] <SuperLag> would NOT be working, that is
[12:50] <tomreyn> SuperLag: sounds like a vmware/vsphere question to me.
[16:37] <SuperLag> tomreyn: well, one of the other questions I have is if there's something I'm doing (or not doing!) that might be breaking things, in terms of prepping this install to be a VM template
[16:38] <SuperLag> I don't know if there's a set of best practices for creating something that's going to be regularly cloned
[22:11] <tomreyn> SuperLag: "golden image" is the term you're looking for. whatever you'll use will need to replace machine id and apply different 'unique' hardware IDs, such as MAC address(es)
[22:26] <SuperLag> tomreyn: is there an Ubuntu equivalent to Window's sysprep that does all that magic?
[22:29] <tomreyn> i'm not sure, nothing standardized AFAIK
[22:31] <tomreyn> it's also a lot less complex and error than windows sysprep, though
[22:32] <tomreyn> the default approach is to just carry out an unattended installation, though, or to use cloud images


[06:07] <mup> PR snapd#8068 closed: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8068>
[06:10] <mvo> hey mborzecki
[06:10] <mborzecki> mvo: hey
[07:46] <zyga> Hey mvo
[07:46] <mborzecki> mvo: pushed the change with link structure to #7972
[07:46] <mborzecki> zyga: hey
[07:46] <mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
[07:46] <zyga> I was woeking till 2am
[07:46] <zyga> Somewhat sleepy still
[07:46] <zyga> Kids woke me up
[07:46] <zyga> Sick and staying at home
[07:46] <mborzecki> zyga: i know you were playing c&c red alert :P
[07:46] <zyga> I wish :-)
[07:47] <zyga> I went for a walk at 2am
[07:47] <zyga> With my sleeping dog in my hand :]
[07:48] <zyga> He dislikes water so much I had to carry him for a while to convince him to walk
[07:48] <zyga> I wrote first spread tests for apparmor prompting
[07:51] <zyga> I’ll start later today
[07:51] <zyga> Need to wake up first
[07:57] <pedronis> mborzecki: mvo: hi, is one of you going to work on #8064 this morning?
[07:57] <mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[08:02] <mborzecki> pedronis:  i was thinking about #8001 but i can look into 8064 first
[08:02] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[08:03] <pedronis> mborzecki: I made comment there and I didn't make on 8001
[08:03] <pedronis> mvo extracted it
[08:16] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
[08:17] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
[08:23] <mvo> mborzecki: thank you, I check 7972
[08:33] <mup> PR snapd#8070 opened: dirs: fixlet for XdgRuntimeDirGlob <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8070>
[09:04]  * Chipaca returns from the doctor's and has breakfast
[09:05] <mup> PR snapd#8071 opened: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
[09:05] <pedronis> Chipaca: ^
[09:06] <Chipaca> pedronis: you ok with the toctou race there?
[09:06] <pedronis> Chipaca: for now yes
[09:07] <pedronis> the current behavior is kind of worse
[09:07] <Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the system user, remove the home and spool
[09:07] <Chipaca> your question last night left me thinking and that's what i thought we'd do
[09:07] <Chipaca> er
[09:08] <Chipaca> insert 'release the lock' after 'remove system user'
[09:08] <pedronis> Chipaca: well, if you think is doable simply enough you can do it on top of my PR
[09:08] <pedronis> otherwise leave possible todo
[09:08] <Chipaca> gah i made a mess
[09:08] <Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the auth user, release the lock, remove the home and spool
[09:08] <Chipaca> ^ there better
[09:09] <Chipaca> the split of the current remove-user-and-home being so as not to hold the lock for ages
[09:09] <pedronis> yes, I understand that
[09:11] <pedronis> Chipaca: I also think that snap remove-user email should do something, given create-user email
[09:11] <pedronis> but that we can deal with it
[09:11] <Chipaca> pedronis: given we're looking it up anyway, sure :-)
[09:11] <pedronis> (it's a bit of a mess of its own)
[09:12] <pedronis> because there might many users with the email and some might not have a username
[09:24] <zyga> o/
[09:24] <zyga> how are you guys
[09:28] <Chipaca> zyga: we're latest/edgy
[09:29] <pedronis> could be better
[09:29] <zyga> tired?
[09:29] <zyga> I'm energized, despite not sleeping much
[09:39] <mborzecki> mvo: pedronis: i've updated #8064
[09:39] <mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[09:41] <mvo> mborzecki: thank you!
[09:44] <Chipaca> did the change to warn about invalid seeds get done?
[09:51] <Chipaca> kenvandine: where should bugs for desktop-launcher go, on launchpad?
[09:52] <pedronis> mborzecki: thanks, small remark
[09:53] <Chipaca> mvo: maybe you know ^^
[09:54] <mvo> Chipaca: do you know the package name? I guess not :) or a binary name in /usr or something?
[09:54] <mborzecki> pedronis: ack
[09:54] <Chipaca> mvo: i mean the snapcraft desktop laucnher helper thing
[09:55] <Chipaca> desktop-helper? worker-dancer? warrior-priest?
[09:55] <mvo> Chipaca: haha - sorry, now I get what you mean
[09:56] <mvo> Chipaca: my guess is snapcraft itself but I'm not super confident, kenvandine will know but it's very early for him I guess
[09:57] <Chipaca> you mean kenvandine isn't a robot?
[09:57] <Chipaca> mvo: I think I'm leaving #1861177 as New so either you or Ian take a look at it when it's your triage day
[09:57] <mup> Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:New> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177>
[09:59] <mvo> Chipaca: nice! let me check that
[09:59] <mvo> Chipaca: that looks pretty neat
[09:59] <Chipaca> mvo: i'm assuming the <patch> bit :-)
[09:59] <Chipaca> not the actual 'iz slow' bit
[10:03] <mvo> Chipaca: yeah, the patch bit
[10:10] <mvo> mborzecki: feedback in 7972, looks very nice now
[10:11] <Chipaca> pedronis: I hope https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1860769/comments/3 isn't too much of a lie :-)
[10:11] <mup> Bug #1860769: should record changes after snap transactions <etckeeper (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1860769>
[10:14] <ogra> Chipaca, https://github.com/ubuntu/snapcraft-desktop-helpers/issues
[10:14] <Chipaca> ogra: what part of 'on launchpad' is that
[10:16] <Chipaca> also why is that still pointing people to rocketchat
[10:16] <Chipaca> is rocketchat/snapcraft still a thing?
[10:18] <ogra> o idea, but that tree is the source people typically include in their snapcraft.yaml to get the launchers
[10:18] <ogra> s/o/no/
[10:29] <mborzecki> mvo: can you take a look at #8064 ?
[10:29] <mup> PR #8064: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[10:29] <pedronis> mvo: #8064 needs some kind of 2nd review
[10:29] <mborzecki> if it's ok, i'll land it an update 8001 accordingly
[10:31] <mvo> pedronis, mborzecki sure, on it
[10:33] <pedronis> #8071 also needs a 2nd review
[10:33] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
[10:34] <mvo> pedronis: was looking at this one as we speak :)
[10:36] <pedronis> mborzecki: 8064 should be ok to land once gree and then we can pick up 8001
[10:36] <pedronis> green
[10:36] <mup> PR snapd#8071 closed: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:36] <zyga> pedronis: (post merge) https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
[10:36] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:36] <mborzecki> pedronis: ok
[10:37] <pedronis> Chipaca: #8071 is in, you might want to update your PRs also consider zyga suggestion but I thought of it myself and not sure whether it makes the message too clunky
[10:37] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:38] <Chipaca> pedronis: which suggestion would that be?
[10:38] <pedronis> Chipaca: https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
[10:38] <Chipaca> grah, it now conflicts
[10:38] <Chipaca> not fair
[10:39] <pedronis> Chipaca: not suprising though, no
[11:00]  * Chipaca takes a break
[11:14] <mup> PR snapd#8064 closed: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8064>
[11:21] <juliank> Hey folks, I ended up with 6 loop devices with deleted snap squashfs: https://paste.ubuntu.com/p/ry5ZKGqxCS/
[11:21] <zyga> hey
[11:21] <juliank> This machine has an uptime of 9 days
[11:21] <juliank> It's running focal
[11:21] <zyga> this is a known issue, it feels like a systemd / libmount bug
[11:21] <zyga> we never manage loop devices ourselves
[11:22] <zyga> it is reported on launchpad
[11:22] <juliank> hmm
[11:23] <juliank> The problem is that, as mentioned on #ubuntu-devel, these now show up in nautilus, confusing users (in this case, me)
[11:23] <juliank> Not sure how to solve that
[11:24] <juliank> Probably udisks should look if backing file is in /var/lib/snapd/snaps, and then set HintIgnore to true
[11:31] <zyga> there's logic like that
[11:31] <zyga> it's a different problem
[11:31] <zyga> it shows up as deleted, unmounted loop device you can mount (??) by clicking on it
[11:31] <zyga> but it isn't possible because it is deleted
[11:32] <zyga> I really don't know what to do about it, apart from chasing kernel/libmount/systemd internals
[11:32] <zyga> I think we used to have a reproducer script
[11:32] <zyga> but perhaps I'm confusing this with another issue
[11:40] <juliank> zyga: Oh you can absolutely mount them, the loop device still has an open file descriptor, so the inode is never actually freed
[11:41] <zyga> the loop devices, yes
[11:41] <zyga> the backing file they used is not linked to the filesystem anymore (but still takes space)
[11:41] <juliank> yes
[11:43] <juliank> Couldn't snapd like look once each hour / after it updates a snap for loop devices that point to deleted snap files and delete them?
[11:44] <juliank> Hah no
[11:44] <juliank> If I losetup -d the loop device it remains active
[11:45] <ogra> well, effectively systemd should do this
[11:45] <juliank> ogra: But I can't even do it manually, so something is off there
[11:45] <juliank> Ah
[11:46] <juliank> So closing my telegram window removed the loop device
[11:46] <juliank> Which I guess means the loop device is used in a different mount namespace?
[11:47] <ogra> hmm, doesnt for me .... but then ... unity7 here ...
[11:47] <juliank> OK, I also ran losetup -d multiple times before, it might have marked it for dettachment
[11:47] <ogra> yeah, that might be
[11:51] <juliank> Confirmed
[11:52] <juliank> The lxd snap still has deleted loop devices mounted
[11:52] <juliank> /proc/1425517/mounts:/dev/loop53 /bin/kmod squashfs ro,nodev,relatime 0 0
[11:53] <juliank> and various other processes
[11:55] <juliank> I don't understand why the mount point is listed as /bin/kmod, though
[11:57] <juliank> Running unmount /bin/kmod inside the namespace a few times made all except one lxd snap loop device go away
[11:57] <ogra> lxd modprobing something inside the container ?
[11:58] <ogra> probably squashfuse related ?
[11:59] <zyga> juliank: if you come up with a reliable way to reproduce
[11:59] <zyga> we can start chasing this more aggresively
[12:00] <zyga> aggressively
[12:08] <juliank> hmm I'm not sure I have time to come up with a reproducer
[12:09] <juliank> Given the number of lxd in there, I'd sort of expect that just switching around lxd versions should trigger this, but not tried it
[12:17] <mup> PR snapd#8070 closed: dirs: fixlet for XdgRuntimeDirGlob <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8070>
[12:57] <pedronis> mvo: is #7999 ready for re-review?
[12:57] <mup> PR #7999: devicestate: allow encryption regardless of grade <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
[13:11] <mvo> pedronis: yes, I think so
[13:13] <pedronis> mvo: it's failing though? it's a new initramfs to land?
[13:13] <pedronis> *it needs
[13:25] <mvo> pedronis: yeah, I pinged dimitri earlier
[13:26] <mvo> pedronis: but yeah, this will only work once the initrd can open it
[13:32] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8067#discussion_r372947893 please
[13:32] <zyga> is that sensible?
[13:32] <zyga> if so I'll make that happen and we can merge this
[13:32] <zyga> maybe for .3?
[13:32] <mup> PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067>
[13:32] <zyga> mvo: we will have .3 - correct?
[13:33] <mvo> zyga: well, maybe
[13:33] <mvo> zyga: there is a (small) chance that we can get away witout
[13:33] <mvo> without
[13:44] <zyga> brb
[13:44] <zyga> see you at the standup
[13:55] <ijohnson> morning folks
[13:58] <mborzecki> ijohnson: hey
[13:58] <ijohnson> hey mborzecki
[13:58] <mborzecki> ijohnson: 8064 landed, i've pushed some updates to #8001 and doing a little cleanup now, i'll push it after the standup hopefully
[13:58] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[13:59] <ijohnson> mborzecki: ack thanks for doing that
[13:59] <mborzecki> ijohnson: or maybe i should push it to my fork, in case it's too dramatic :)
[13:59] <ijohnson> mborzecki: how dramatic of a change is it ?
[14:00] <mborzecki> ijohnson: splitting the boot state update 20 commit() into separate successful/candidate kernel code paths
[14:01] <ijohnson> mborzecki: you meant a separate commit for setNext and markSuccessful ?
[14:01] <ijohnson> err commit() method I mean
[14:01] <mborzecki> ijohnson: yeah, actually doing that via 2 separate types, each implementing bootStateUpdate
[14:01] <ijohnson> mborzecki: smells a lot like my rewrite I have locally for the next step with base snaps
[14:02] <mborzecki> hahah ;)
[14:02] <ijohnson> mborzecki: but sure feel free to push it, I can always re-work mine on top of yours
[14:26] <sdhd-sascha> Hi, should i ask here, or on #maas, about:
[14:26] <sdhd-sascha> # snap install maas
[14:26] <sdhd-sascha> 2020-01-30T14:25:28Z INFO Waiting for restart...
[14:26] <sdhd-sascha> error: cannot perform the following tasks:
[14:26] <sdhd-sascha> - Run configure hook of "maas" snap if present (run hook "configure": chown: changing ownership of '/var/snap/maas/common/log/proxy': Operation not permitted)
[14:38] <ijohnson> mborzecki: let me know when you've pushed that up
[14:38] <mborzecki> ijohnson: sure
[14:38] <zyga> sdhd-sascha: chown is usually not allowed, the exception is chown to a special snapd daemon user
[14:39] <zyga> sdhd-sascha: I'm not sure if that's what maas is doing
[14:41] <sdhd-sascha> zyga: i just installed the `apt` version. I tried the snap inside of lxd ...
[14:42] <sdhd-sascha> maybe, i look later deeper into the script.
[14:42] <zyga> sdhd-sascha: I don't know how that's related
[14:43] <pedronis> mvo: Chipaca: I'm having a break, ping me later when you want to chat about download
[14:43] <zyga> I'll grab lunch/dinner now
[14:43] <zyga> and finish my cold soup :)
[14:52] <mvo> pedronis: are you ok with picking 8067 for 2.43? if we have to do a release it seems like a nice and simple fix
[15:02] <ijohnson> pedronis: mvo: mborzecki: sorry I forgot to inquire during SU, but shall I go with mvo's suggestion and extract the initramfs-mounts bits from #8001 into a separate pre-req PR, or are we looking okay to merge with that in there?
[15:02] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[15:04] <zyga> mmm
[15:04] <zyga> yummy food today :)
[15:04] <zyga> polish salad and veggie soup :)
[15:04] <zyga> mvo: you should try the polish salad one day
[15:05] <zyga> mborzecki: ^ do you know how it's called in English?
[15:11] <zyga> random falures
[15:11] <zyga> just love'm
[15:11] <Eighth_Doctor> mmm failure :D
[15:12] <zyga> just slower, travis stopped
[15:12] <zyga> eh
[15:30] <mborzecki> ijohnson: meh, i don't think i'll push it anytime today, got more complicated that i hoped
[15:31] <pedronis> ijohnson: well, I reviewed that code and what it needs is really to be some kind of helper, I don't think splitting helps at this point
[15:31] <pedronis> but maybe other reviewers have other preferences
[15:36] <mborzecki> zyga: polish salad?
[15:36] <zyga> mborzecki: yeah... geez how to explain that
[15:36] <mborzecki> zyga: photo?
[15:36] <zyga> https://www.google.com/search?q=sa%C5%82atka+jarzynowa
[15:36] <zyga> something like this?
[15:40] <mborzecki> zyga: ah, well, no clue whether there's an generally accepted english name for it, veggie salad? boiled veggie sald?
[15:40] <zyga> but it's nothing like I've seen in other countries
[15:40] <zyga> anywy
[15:40] <zyga> we need a sprint in poland
[15:40] <zyga> lodz would be great
[15:41] <zyga> :)
[15:47] <Chipaca> mvo: pedronis: shared a doc with you about download. GOing to step out for ~40 minutes, let's talk when i get back?
[15:48] <pedronis> Chipaca: ok
[15:48] <mup> PR snapcraft#2894 closed: Fix issue with multipass mount on win32 <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2894>
[15:48] <mup> PR snapcraft#2895 closed: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2895>
[15:54] <mup> PR snapcraft#2897 closed: meta: include environment in hook wrappers <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2897>
[16:00] <mup> PR snapcraft#2898 closed: meta: remove dead code from snap packaging <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2898>
[16:07] <ijohnson> pedronis: ok I asked mvo about splitting it and I think it's best to leave it in for now, and I can refactor the bootloader kernel bits in initramfs-mounts into a helper later
[16:09] <ijohnson> mborzecki: sure, I will go through the rest of the comments in 8001 and address them then, perhaps you can cleanup anything else you need tomorrow AM
[16:40] <sdhd-sascha> how can i debug or step this process:
[16:40] <sdhd-sascha> ```
[16:40] <sdhd-sascha> $ sudo snap refresh lxd
[16:40] <sdhd-sascha> error: snap "lxd" has "auto-refresh" change in progress
[16:40] <sdhd-sascha> ```
[16:40] <sdhd-sascha> stop
[16:45] <pedronis> Chipaca: back?
[16:49] <Chipaca> pedronis: back
[16:49] <Chipaca> sdhd-sascha: snap watch --last auto-refresh
[16:51] <sdhd-sascha> Chipaca: thank you. It's seems to hang
[16:51] <Chipaca> sdhd-sascha: snap tasks --last auto-refresh would be the next thing to look at
[16:55] <pedronis> Chipaca: should we have the chat?
[16:55] <sdhd-sascha> Is it normal, that three times `snap-confine` runs, like this:
[16:55] <sdhd-sascha> ```
[16:55] <sdhd-sascha> $ ps -Af | grep lxd
[16:55] <sdhd-sascha> root        3504       1  0 Jan29 ?        00:00:49 lxcfs /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
[16:55] <sdhd-sascha> root      264698    2355  0 05:10 ?        00:00:02 systemctl start snap.lxd.activate.service
[16:55] <sdhd-sascha> root      264699       1  0 05:10 ?        00:00:00 /bin/sh /snap/lxd/13073/commands/daemon.activate
[16:55] <sdhd-sascha> root      264758  264699  0 05:10 ?        00:00:00 lxd activateifneeded
[16:55] <sdhd-sascha> root     2561183       1  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561205 2561183  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561206 2561183 98 17:53 ?        00:00:21 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561767 2554559  0 17:53 pts/7    00:00:00 sudo systemctl restart snap.lxd.daemon.service
[16:55] <sdhd-sascha> root     2561768 2561767  0 17:53 pts/7    00:00:00 systemctl restart snap.lxd.daemon.service
[16:56] <Chipaca> pedronis: I'll ping mvo and get a cuppa and yes
[16:56] <pedronis> Chipaca: I'm in the standup
[16:56] <mvo> Chipaca: here
[16:57]  * sdhd-sascha I killed all the process. Now it seems to work
[17:40]  * Chipaca resumes all the downloads
[17:45] <mup> PR snapd#8067 closed: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8067>
[18:27] <mup> PR snapcraft#2900 opened: Travis pr snapstore <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2900>
[18:51] <pedronis> Chipaca: I added to your doc
[18:52] <Chipaca> pedronis: thanks
[18:52] <Chipaca> pedronis: I don't think I can wrangle that in tomorrow tho
[18:52] <Chipaca> pedronis: that == the hmac option
[18:52] <pedronis> Chipaca: that's fine, it's not hard to add once we have the basics
[18:52] <pedronis> of the rest
[18:52] <pedronis> HEAD support and resume params
[18:52] <Chipaca> that one i probably can get up tomorrow :)
[18:57] <pedronis> ijohnson: as far as I can tell this are the not yet applied/answered things in #8001: https://github.com/snapcore/snapd/pull/8001#discussion_r368975082 , https://github.com/snapcore/snapd/pull/8001#discussion_r372449659 , https://github.com/snapcore/snapd/pull/8001#discussion_r372451326
[18:57] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[18:58] <ijohnson> pedronis: this is what I have that I'm doing now https://pastebin.ubuntu.com/p/YsN6rDWqq4/
[18:59] <pedronis> sounds right
[18:59] <ijohnson> so I think your 3 things are contained in that
[19:01] <ijohnson> good that we found the same things just about
[21:01] <mup> PR snapcraft#2899 closed: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2899>


[02:29] <elcaset> creepy Krampusnacht everyone!
[07:27] <ahoneybun> so who is online?
[07:30] <Noskcaj> o/
[07:30] <valorie> o/
[07:30] <valorie> unpacking my new coffee grinder
[07:30] <valorie> now I need to get some fresh beans
[07:30] <valorie> :-)
[07:37] <ahoneybun> sweet
[07:37] <ahoneybun> I got Kubuntu 12.04 in a VB
[07:37] <ahoneybun> updating backports on it to KDE 4.12
[07:42] <valorie> ah, you like the LTS
[07:43]  * valorie prefers just under leading edge
[07:44] <ahoneybun> well just for a VB
[07:44] <ahoneybun> 13.10 dual boot
[07:45] <valorie> nice
[07:45] <ahoneybun> yep
[07:45] <ahoneybun> just messing around I got a great xmas gift
[07:45] <valorie> a new computer?
[07:46] <ahoneybun> http://aokp.co/devices/m7vzw
[07:46] <ahoneybun> I'm good wiith my laptop
[07:47] <valorie> aha, same phone I have
[07:47] <valorie> love it
[07:47] <Noskcaj> ahoneybun, Your laptop must be better than mine then. This one won't run ubiquity in a VM, so linux AU got me a new PC for christmas
[07:47] <valorie> I found out today that both my sons have it as well
[07:47] <Noskcaj> And nice phone
[07:47] <Noskcaj> I probably should get a phone
[07:47] <valorie> kdeconnect works well on it
[07:47] <ahoneybun> Noskcaj: new lenovo ideapad y510p
[07:47] <valorie> I can control amarok with my phone!
[07:48] <ahoneybun> I need to fix it can't get it to work right for some reason
[07:50] <ahoneybun> kdeconnect
[07:51] <ahoneybun> just waiting on that email about wiki.kubuntu.org redirect, and for the pages to be reviewed
[07:52] <ahoneybun> valorie: https://lh6.googleusercontent.com/-y7lPJr20f2c/UruxQVErVaI/AAAAAAAAcYc/W0N3GjyyIAY/w640-h602-no/fly.png
[07:53] <ahoneybun> also got my pi to work as a server
[07:54] <valorie> haha
[07:54] <valorie> I've not watched the special yet
[07:54]  * valorie has self control!
[07:54] <ahoneybun> sorry
[07:54] <valorie> but I probably will next
[07:54] <valorie> oh, it's fine
[07:54] <ahoneybun> was on google drive somewhere
[07:54] <valorie> character is what I find most interesting
[07:54] <valorie> not so much plot
[07:55] <valorie> although, doctor who plots are usually devilishly fun
[07:55] <ahoneybun> yep
[07:55] <valorie> they mess with your head
[07:55] <ahoneybun> yea lol
[08:10] <jalcine> they really made it full circle with the plot for Who.
[08:10]  * jalcine isn't sure if valorie is watching atm
[08:28] <valorie> I'm watching the farewell to Matt Smith
[08:29] <valorie> I'm going to miss him a lot
[08:29] <valorie> he was FUN
[09:47] <ovidiu-florin> Hello world
[09:48] <ovidiu-florin> Merry Christmas Every one and happy hollydays.
[11:29] <BluesKaj> Hiyas all
[11:37] <BluesKaj> kded keeps crashing so I can't file a bug report , perhaps somebody here can look at, and copy the info posted here, http://pastebin.kde.org/peb3400ff , and post it to the KDE Bug Tracking System
[11:43] <yofel> same here, doesn't look like kde's fault though
[11:54] <BluesKaj> ok yofel , i logged into kde and it's already been reported
[11:54] <BluesKaj> Qt?
[11:54] <yofel> not that they can do anything about it as this seems to be a broken ntrack
[11:56] <BluesKaj> ntrack? , pls explain, yofel
[11:57] <yofel> BluesKaj: still looking into it, but it seems like a FTBFS fix for ntrack is the problem
[11:58] <yofel> try downgrading ntrack-module-libnl-0 to 016-1.1 and see if kded works
[12:09] <BluesKaj> the bug seems to be a dup , someone already filed aone
[12:56] <yofel> xnox: bug 1264293
[12:56] <yofel> if you have some time to look at it
[13:05] <yofel> BluesKaj: do you have the kde report at hand?
[13:08] <BluesKaj> yofel, http://pastebin.kde.org/peb3400ff
[13:13] <yofel> hm, thanks
[13:42] <lordievader> Good afternoon.
[14:45] <Quintasan> !@#$!@
[14:45] <Quintasan> I'm full and there is still a ton of cake to eat.
[14:45] <Quintasan> What am I supposed to do?
[15:09] <ovidiu-florin> Quintasan: share
[15:11] <Quintasan> ovidiu-florin: Come to Poland then :P
[15:11] <Quintasan> ovidiu-florin: How is ufw-kde packaging coming along?
[15:11] <ovidiu-florin> haven't been thare yet
[15:11] <ovidiu-florin> slow
[15:11] <Quintasan> If you need some help then I'm can lend you a hand
[15:11] <ovidiu-florin> I've had lot's of projects for school + work...
[15:11] <Quintasan> I can*
[15:11] <ovidiu-florin> and now the hollydays
[15:12] <ovidiu-florin> I think I can handle it if I'll gather the time
[15:12] <Quintasan> Sure, take your time.
[15:12] <Quintasan> Well, back to eating I guess.
[15:12] <ovidiu-florin> but I'll have to ask about a few specific things
[15:13] <ovidiu-florin> yeah.. FOOOOOOD
[15:15] <BluesKaj> running 13.0 now since 14.04 segfaults kded , no power mgmnt or startup /service manager available on both 14.04 installs . laptop and desktop
[15:15] <BluesKaj> 13.10
[15:16] <ovidiu-florin> does plasma2 come in trusty?
[15:20] <BluesKaj> never rteally checked
[15:24] <Quintasan> I do not think we are going to ship plasma2 in Trusty
[15:24] <Quintasan> it's an LTS
[15:24] <yofel> we are not
[15:26] <yofel> BluesKaj: if you're on amd64 you can install http://people.ubuntu.com/~yofel/tmp/ntrack-module-libnl-0_016-1.1ubuntu2_amd64.deb to fix kded
[15:26] <yofel> though I added a (small) memory leak as far as I see
[15:26] <BluesKaj> yofel, thanks
[15:27] <BluesKaj> my laptop is an intel 64 bit , but desktop is amd64
[15:27] <yofel> should be the same thing - unless that's an itanium ^^
[15:29] <BluesKaj> nope . it's just an i3
[15:30] <BluesKaj> ok , bbl
[15:31] <yofel> then it's both x86_64 (just usually called amd64 because amd invented it)
[19:16] <yofel> xnox: ping
[19:16] <yofel> can it be that you uploaded my debdiff with the fix taken out of it?
[19:17] <yofel> http://paste.ubuntu.com/6641259/ might be a better solution btw.
[19:37] <shadeslayer> Riddell: *nod*
[19:38] <yofel> stop talking about dr.who ;P
[19:38] <yofel> I want to catch up on the old episodes first (still a few to go)
[19:42] <shadeslayer> :)
[19:42] <Quintasan> I'm still free from Dr. Who plague o/
[19:43] <shadeslayer> unfortunately ^^
[19:43] <yofel> no fez for you then ^^
[19:43] <Quintasan> I don't need it. I need more free time
[19:44] <Quintasan> ;_;
[19:44] <shadeslayer> sounds like a time machine
[19:44] <shadeslayer> *like you need a
[19:45] <Quintasan> Time stopping machine
[19:45] <shadeslayer> I totally kludged that up, real life does not mingle well with IRC
[19:46] <Quintasan> It does, start lurking on your phone xD
[19:54] <shadeslayer> no thx
[19:54] <shadeslayer> I started doing that at one point
[19:54] <shadeslayer> lost all sanity
[19:55] <Quintasan> Lol
[20:01] <xnox> yofel: lol, yes. yeah looks better, let me upload that into debian.
[20:04] <yofel> heh, thanks
[20:08] <xnox> yofel: i thought it's 3.0 (quilt) but it clearly isn't, hence broken upload =)


[16:18] <SudoFox> ' Hello
[20:24] <taowa> !lococouncil
[20:24] <ubot4> lococouncil is The Loco Council is itnet7, czajkowski, paultag, huats, leogg, popey - they are there to help, just ask! :) You can send them an email at<EMAIL_ADDRESS>[20:27] <nigelb> ...
[20:42] <czajkowski> hmm pinged and no message
[20:51] <paultag> hey y'all
[20:51] <paultag> oh, lame
[20:55] <nigelb> paultag!
[20:55] <paultag> nigelb!
[20:55] <nigelb> Hows the mentors conf going?
[20:55] <paultag> nigelb: http://i.imgur.com/kc52V.jpg
[20:55] <paultag> like that
[20:55] <paultag> taken a few minutes ago
[20:55] <paultag> that's all chocolate
[20:55] <paultag> welcome to 'earf
[20:55] <nigelb> \o/
[20:56] <paultag> http://i.imgur.com/YPNWW.jpg
[20:56] <czajkowski> paultag: met norin yet?
[20:57] <paultag> czajkowski: I'm not sure
[20:57] <nigelb> paultag: I thought it was a conf, not playing with legos ;)
[20:57] <paultag> I've met all the Debian folks (3 of them))


[08:48] <guiverc> lp 1904297 just marked as opinion  (suggested user seek support too); not worth a look in my opinion; gripe about update-notifier frequency, yell at me if anyone disagrees  (may even be duplicate; but I didn't find it)
 We fixed that after 20.04.
 There probably was a bug that got closed when we uploaded the new version.
 I guess there is always the option of doing the update so it doesn't bother you anymore.
[09:47] <guiverc> it doesn't bother me.. but thanks for info on change; i was convinced it was changed.. but yeah I mention it in the answer on askubu... I'll add that to lp bug report.
[09:56]  * guiverc is/was probably tired.. (I am)  yeah the change does imply the OP's point is valid!


[00:17] <fmarier> morning
[00:17] <fmarier> ibeardslee: at what time are you leaving for the bnz foodcourt?
[00:24] <ibeardslee> about 12:15
[04:40] <snail> nice earthquake
[04:56] <Atamira> another earthquake?
[04:57] <ajmitch> apparantly one in a north island, nothing to be excited about
[04:57] <ibeardslee> nice bit of a fright here
[04:58]  * ojwb didn't even notice it
[04:58]  * ajmitch certainly didn't notice it
[04:59] <ojwb> 6.5 near taupo
[05:02] <chilts> didn't like that one :(
[05:03] <ajmitch> chilts: why not?
[05:03] <chilts> biggest one I've felt since being here (8 years now)
[05:03] <chilts> plus my buidling rattled like no-one's business
[05:03] <ibeardslee> serious?
[05:03] <chilts> yeah, I was close to getting under my desk, which I've never done in a shake before
[05:04] <chilts> I can still feel it in my mouth (you know that flight or fight taste) ... I guess it all depends on the building you're in
[05:21] <ojwb> it seems there may have been a quake near Nelson at a similar time
[05:22] <ajmitch> uh oh, the whole country is about to split apart & rivers of lava shall spill out over the land
[05:23] <ibeardslee> ohhh my plan is coming together nicely
[05:24] <ojwb> new zealand split in two?  how will we cope
[05:24] <ajmitch> as long as it splits along the bombays?
[05:25] <ibeardslee> north/south? MMP/FPP?


[12:07] <seanius> hi guys, is there an authoritative guide for job file syntax somewhere?  most of the stuuff on the upstart wiki seems more "proposal-ish"
[12:08] <seanius> specifically wrt the version in hardy
[12:08] <Keybuk> man 5 init
[12:08] <Keybuk> oh, in hardy, no
[12:09] <seanius> yeah i've already heard through the grapevine that it might have changed since then
[12:10] <Keybuk> yes, and it will change again
[12:10] <seanius> should i just forget about trying then, and use something like rc.local?
[12:10]  * seanius would prefer inittab, but that's gone now it seems
[12:12] <seanius> or, is inittab supported in the -compat-sysv package but just not shipped by default?
[12:20] <seanius> ...it seems not (beyond default runlevel at least)
[12:21] <Keybuk> it's not supported, no
[12:21] <seanius> sorry for flooding teh channel btw :)
[12:22] <seanius> i have a service i'd like to run with supervision (i.e. "respawn") which should start after ssh/networking/postgres is brought up
[12:24] <seanius> is this possible to do in hardy's 0.3.9 upstart?
[12:29] <ion> Probably best to start it when rc2 has finished. But i don’t remember the precise syntax for 0.3.
[12:30] <ion> Something like
[12:30] <ion> start on EVENTSPEC
[12:30] <ion> service
[12:30] <ion> respawn
[12:30] <ion> exec yourservice
[12:31] <seanius> okay, i htink i can take that and what's sitting in event.d to try something, thanks!
[12:31] <ion> where EVENTSPEC is the correct string to match whatever happens when rc2 has finished.
[12:40] <seanius> ion: okay so that would be something like "start on started rc2"?
[12:41] <seanius> ...which is output from initctl events when i run "telinit 2"
[12:41] <ion> I take it there’s a /etc/event.d/rc2?
[12:42] <seanius> yeah
[12:42] <ion> Do you get a ‘stopped rc2’ when rc2 finishes?
[12:43] <seanius> i think i get that if i switch to runlevel 3
[12:43] <ion> You’ll probably want ‘start on stopped rc2’ or something like that.
[12:43] <ion> Hmh, not that, then...
[12:44] <seanius> yeah this is what i get http://paste.debian.net/48855/
[12:44] <seanius> this is switching from 2->3 and then back from 3->2
[12:45] <seanius> oh, it looks like it is saying "stopped rc2" last then isn't it...
[12:45] <ion> Did stopped rc2 happen before or just after switching to a new runlevel?
[12:46] <seanius> it looks like it's the last thing that happens when switching *to* that runlevel
[12:46] <seanius> so then i'd want "start on stopped rc2"
[12:46] <ion> Alright, that should work.
[12:47] <seanius> and if i want to stop it on reboot/shutdown would that be "stop on runlevel [06]" ?
[12:49] <ion> Look at what the tty* jobs do, that should work.
[12:49] <seanius> ah, just multiple stop stanzas
[12:50] <ion> The [016]-style pattern might only be supported in a newer version of Upstart.
[12:50] <seanius> there was a runlevel [!2] in the rc2 file at least
[12:51] <ion> Ok, it probably would work then.
[12:52] <seanius> allright, looks like we're up and running
[12:52] <seanius> thanks for the help
[13:23] <Keybuk> ion: I think I always used fnmatch() for that
[18:22] <akk> Hi! I updated karmic yesterday and now I can't boot with my self-compiled kernel -- mountall complains about /proc/filesystems, I think because I'm not using an initrd.
[18:22] <akk> I'm wondering if this is a permanent change, and if there's any workaround to boot without initrd?
[19:39] <sadmac> Keybuk: what are operations that one does on a device node that don't start with opening it and acting on the resulting descriptor?
[20:08] <JanC> akk: I've been looking at it a bit & I think a solution/workaround would be to edit the existing "mountall.conf" upstart script to add a 'pre-start' script that makes sure /proc (and maybe other requirements?) exist before mountall runs
[20:08] <JanC> but Keybuk or somebody else probably knows more about what the "right" solution would be  ;)
[20:11] <akk> JanC: Thanks for looking! Wouldn't I have to delay running mountall at all until it had mounted root readonly?
[20:12] <akk> Though d found that mountall 0.1.8 worked (two revs back).
[20:16] <JanC> akk: whatever requirements mountall has should go in the pre-start script (or in a separate upstart job on which mountall depends?)
[21:51] <chergert> can i have multiple "start on " lines in an upstart config? or do they need to be on one line?
[22:08] <mugwump> Anyone have any tricks for debugging early boot process with upstart?
[22:10] <Keybuk> sadmac: none that I can think of
[22:14] <sadmac_> Keybuk: well the mount command takes the path, but that can be gotten around...
[22:14] <sadmac_> Keybuk: a shocking proposal: axe device nodes. replace with connect(AF_DEVICE...)
[22:14] <Keybuk> sadmac_: then you can't alias them ;)
[22:14] <Keybuk> the network people (who have this) are trying to go the other way
[22:15] <Keybuk> akk: this is generally a channel for Upstream issues, try #ubuntu
[22:15] <Keybuk> akk: though because I'm nice, see bug 447947
[22:15] <sadmac_> Keybuk: sure you can. DNS can alias IP addresses, why can't some similar service alias major/minor pairs?
[22:15] <Keybuk> sadmac_: how so?
[22:16] <Keybuk> chergert: no.
[22:16] <Keybuk> mugwump: --debug on the kernel command-line is always fun
[22:16] <Keybuk> but you need quick reactions on the old scroll lock key ;)
[22:16] <Keybuk> (and a scroll lock key, bloody netbooks!)
[22:16] <mugwump> heh
[22:16] <mugwump> ctrl+s does the same thing on the console, no?
[22:16] <Keybuk> no...
[22:16] <Keybuk> :(
[22:17] <akk> Keybuk: Thanks!
[22:17] <sadmac_> Keybuk: basically you have a gethostbyname equivalent like getdevicebyname. you pass it a name, and it communicates to some service (probably a very re-invented udev) and returns a major/minor in a struct socaddr_device
[22:17] <mugwump> well, that's useful, thanks.  I actually ended up reinstalling because I couldn't figure out why the system wouldn't boot...
[22:18] <Keybuk> sadmac_: device filesystems are a more popular way of doing that <g>
[22:18] <sadmac_> Keybuk: but they suck.
[22:18] <mugwump> it would be nice to have details like that on the upstart man page
[22:18] <Keybuk> sadmac_: the only API I can think of that sucks more is, err, DNS
[22:19] <Keybuk> mugwump: it's a good point that init(8) doesn't document the options, could you file a bug about that?
[22:19] <sadmac_> Keybuk: if you tried out a web browser, and when you launched it instead of a website it gave you a blank window and the glade interface designer and said 'draw yourself a UI', and it did this every time you started it would you keep it?
[22:19] <mugwump> to which bugtracker?
[22:19] <mugwump> launchpad?
[22:19] <sadmac_> Keybuk: by that logic, where the fuck does the kernel get off giving userspace a some-assembly-required interface to hardware?
[22:20] <Keybuk> mugwump: http://launchpad.net/upstart/+reportbuf
[22:20] <Keybuk> mugwump: http://launchpad.net/upstart/+reportbug
[22:20]  * mugwump reports a buf
[22:20] <Keybuk> it might be +filebug ;)
[22:20] <mugwump> I'll find it :)
[22:26] <mugwump> Keybuk: https://bugs.launchpad.net/upstart/+bug/449883
[22:28] <mugwump> though it would be nice to have an option which starts a shell or something and requires you to prod it to make the next event fire
[22:28] <mugwump> quite often in that sort of situation I'll be doing diag checks between init scripts
[22:29] <Keybuk> yes, we should have that
[22:29] <Keybuk> in fact, my thought is that init will look at the kernel command-line options
[22:29] <Keybuk> and if any job exists with the names given, it will start that
[22:29] <mugwump> sure, why not
[22:29] <Keybuk> so you could have /etc/init/emergency.conf containing the code for a console root shell
[22:29] <mugwump> the decision to run as real init, it makes that based on the pid, right?
[22:29] <Keybuk> then if you stuck emergency on the kernel command-line then it would give you that
[22:30] <mugwump> that sounds pretty clean
[22:30] <Keybuk> that'd same code would make implementing things like "single" really easy too
[22:30] <Keybuk> (and most importantly let the mobile phone developers *not* have that <g>)
[22:30] <mugwump> do you use lxc for testing already?
[22:31] <mugwump> It should let you start a process that thinks it's pid 1
[22:31] <mugwump> and can't see any other processs
[22:31] <Keybuk> no, the test suite is pretty comprehensive though
[22:32] <mugwump> ah, good to know
[22:32] <mugwump> presumably you mock that somehow in the test suite
[22:32] <Keybuk> actually, very little requires that init be pid 1
[22:32] <Keybuk> the only reason, in fact, is because sysv let people call init to change the runlevel ;)
[22:32] <Keybuk> if you build upstart a certain way, you can cheerfully run it as any user
[22:33] <Keybuk> and use that one for testing
[22:33]  * Keybuk does that a lot
[22:33] <mugwump> reparenting I would have thought was pretty important
[22:33] <mugwump> or I guess not, maybe you only care about immediate children
[22:33] <Keybuk> not really, we don't get told about it
[22:33] <mugwump> do you get SIGCHLDs from them?
[22:34] <Keybuk> eventually yes
[22:34] <Keybuk> but there's no use for that, because we don't know what process it was ;)
[22:34] <Keybuk> pid 4131 died ... that's nice
[22:34] <mugwump> heh
[22:34] <Keybuk> kernel helpfully reaps info from /proc first
[22:34] <Keybuk> not that it would be reliable anyway
[22:35] <mugwump> or portable... any bsd users?  :)
[22:35] <Keybuk> I'm utterly uninterested in portability
[22:35] <Keybuk> Upstart is a Linux program
[22:39] <mugwump> fair enough, you won't find me complaining or submitting portability patches
[22:39] <Keybuk> I've suggested to the Debian/kFreeBSD nutters that they branch the code and rewrite it to be a BSD program ;)
[22:45] <sadmac_> ugh. I keep getting to places where I want to commit, but I don't want to because it would mean committing or digging out the piles of printfs that I want to still be in place for the next phase of implementation.
[23:13] <ion> keybuk: Btw, there’s the mnt->device "none" change sitting in my branch. Not very important, but anyway. :-)
[23:36] <ion> keybuk: The latest commit in the mountall repo breaks the code. I’m not quite sure what it’s attempting to do.
[23:37] <ion> Ah, now i get it. Yeah, just a missing ||
[23:39] <ion> keybuk: Fix in my branch.
[23:43] <Keybuk> oh, the fix is already in mine
[23:43] <ion> Alright
[23:44] <ion> uncommited and pushed; my branch still contains the (not very important) mnt->device "none" change.
[23:47] <Keybuk> the whuh?
[23:47] <Keybuk> oh that, I'll merge that in


[01:05] <lifeless> wgrant: sure
[12:05] <wgrant> cjwatson: So that branch isn't terrifying at all.
[12:16]  * cjwatson attempts to apply sarcasm detector to wgrant
[12:17] <StevenK> cjwatson: Surely that always returns true.
[12:17] <wgrant> No it doesn't.
[12:18] <StevenK> wgrant: Liar.
[12:19] <wgrant> I don't know why I'd be terrified of a branch that changes the behaviour of lots of scripts that haven't been touched since I refactored this four years ago :)
[12:19] <cjwatson> I've done a lot of grepping trying to think of patterns that might be problematic; direct use of test_emails, catching SMTPExceptions, aborted transactions, that kind of thing
[12:19] <wgrant> Yeah
[12:19] <wgrant> We'll need to do a lot of weird QA.
[12:19] <wgrant> But it's manageable.
[12:20] <cjwatson> Can you think of any other patterns I might have missed?
[12:20] <wgrant> I don't think so.
[12:20] <wgrant> The only other big risk I see is that some things might somehow break the email commit hook.
[12:21] <wgrant> Or not commit at all.
[12:21] <cjwatson> Well, if they don't commit at all then the operation being notified about doesn't happen either.  Unless they commit before sending mail
[12:21] <wgrant> Right, but errors might do that.
[12:22] <wgrant> Some errors abort because they don't LBYL
[12:22] <wgrant> but others will.
[12:22] <cjwatson> I'm definitely spooked by the oops/error handling in jobs, I don't really understand that yet
[12:23] <cjwatson> (which is why I applied the context manager to those for now)