[08:44] <rbasak> bdmurray, xnox, klebers: I don't understand why we're SRUing bug 1734908. It seems to have no user impact?
[08:44] <ubottu> bug 1734908 in systemd (Ubuntu Artful) "systemd-rfkill service times out when a new rfkill device is added" [High,Fix committed] https://launchpad.net/bugs/1734908
[08:44] <rbasak> Additionally the Regression Potential and SRU verification process seems to have made no consideration for how to test or verify that rfkill hasn't otherwise regressed by this patch.
[08:44] <rbasak> So I'm reluctant to release it.
[08:56] <klebers> rbasak, hi. Sorry, I mentioned the network-manager testcase issue but didn't state what would be the issue for a user. The user impact is that network-manager can report the wrong status of the rfkill device.
[08:57] <klebers> rbasak, regarding regression with rfkill, the rfkill doesn't have debian autopkgtests, but it's used on the same network-manager testcase so it's indirectly tested, at least on that scenario
[08:58] <rbasak> klebers: thanks. That sounds like it should be SRU'd then. Can we verify that part of the fix though then please? That network-manager now does report the correct status of the rfkill device? Or is the autopkgtest already covering that?
[08:59] <rbasak> klebers: and in your opinion then, are the autopkgtests sufficient to test general regressions in the area of rfkill, or is further manual testing needed?
[09:03] <klebers> rbasak, that network-manager autopkgtest already covers these tests and I verified that with that fix it now reports the correct status.
[09:04] <klebers> rbasak, regarding rfkill coverage, it has four commands: event, list, block and unblock. The last three are covered by that testcase, only event is not. I can run some manual tests to check if the behavior of this command is affected.
[09:06] <rbasak> klebers: thanks. I'm happy to trust your judgement on whether that is needed in relation to this particular patch. But I'd prefer that your judgement be documented so that it's clear that the testing that is and isn't performed is an informed decision rather than an omission. That's what the Regression Potential section is for.
[09:10] <klebers> rbasak, I will run some more manual tests and add all these additional information to the bug report. Thanks for the thorough review.
[09:40] <xnox> rbasak, i was not at all involved in that sru. /me is out
[11:51] <klebers> rbasak, I have run some manual tests with rfkill and added the information we discussed here to the bug description. Please let me know if anything else is needed.
[12:12] <rbasak> klebers: thanks! That looks good and I'm satisfied with SRU verification. There are some autopkgtest failure still, including systemd amd64 which seems quite important as it's worked in the past. I've just retried that one.
[12:13] <klebers> rbasak, thanks!
[12:15] <doko> mwhudson: tracking the golang-defaults induced autopkg test failures?
[12:16] <doko> jamespage: ujson needs a MIR (ceilometer)
[12:16] <jamespage> doko: on my list
[12:17] <jamespage> just digging into why ovs fails on i386 for artful and bionic...
[12:22] <mdeslaur> cpaelzer: are you planning on merging virt-manager soon? Can I do it?
[12:24] <cpaelzer> mdeslaur: you can do if you need, but due to the need to build against latter libvirt (which takes some more time) I planned to do it after libvirt
[12:24] <cpaelzer> mdeslaur: but if you do a merge now you certainly will lower the amount of diff I have to cross when I get to it in ~Feb
[12:29] <mdeslaur> cpaelzer: oh! I'll wait then, thanks
[12:29] <cpaelzer> mdeslaur: if your only concern is "have it updated in 18.04" let it be mine
[12:30] <mdeslaur> cpaelzer: I have a bug fix I want to SRU into artful...so either I merge bionic, or add the bugfix to bionic
[12:30] <mdeslaur> cpaelzer: but now I'm confused...it requires a newer libvirt?
[12:30] <cpaelzer> mdeslaur: ok, then add the bugfix for now if that is ok
[12:30] <mdeslaur> cpaelzer: ok, thanks
[12:31] <cpaelzer> mdeslaur: being not C but python it isn't that hard, but better to do the rebuild
=== alan_g is now known as alan_g|lunch
=== mhcerri_ is now known as mhcerri
[13:30] <rbasak> infinity: missing SRU paperwork for bug 1730627, but also, do we really need to SRU this? Is being able to debootstrap Bionic from Trusty important?
[13:30] <ubottu> bug 1730627 in dpkg (Ubuntu Trusty) "xz compressed control.tar files not supported" [Medium,Confirmed] https://launchpad.net/bugs/1730627
[13:31] <rbasak> We don't support an upgrade from Trusty to Bionic directly, so why do we need to support a debootstrap?
=== alan_g|lunch is now known as alan_g
[14:39] <jamespage> doko: https://bugs.launchpad.net/ubuntu/+source/ujson/+bug/1737989
[14:39] <ubottu> Launchpad bug 1737989 in ujson (Ubuntu) "[MIR] ujson" [Undecided,New]
[14:45] <xnox> rbasak, oh yes we do need that; because we do have clients/deployments that use trusty in production still, and do need/want to create/debootstrap bionic based chroots and docker images.
[14:47] <xnox> rbasak, kernel-wise, these trusty machines that do that, most often run the xenial-lts kernel; which also is expected to be able to execute things in bionic chroots after those have been debootstrapped.
[14:56] <rbasak> OK
[14:56] <rbasak> That should be in the SRU paperwork
[14:56] <rbasak> Unrelated: what's the canonical Ubuntu way to detect the currently running init system?
[15:15] <rbasak> roaksoax: in bug 1732703, I'm not sure that test for systemd is reliable. For example immediately after an upgrade from Trusty to Xenial, before a reboot, /sbin/init will be systemd but the running init system will be upstart.
[15:15] <ubottu> bug 1732703 in MAAS 1.9 "MAAS does not detect properly if Ubuntu is using upstart/systemd" [Critical,In progress] https://launchpad.net/bugs/1732703
[15:16] <rbasak> roaksoax: AFAICT, the "correct" way to test for systemd is its process name or something, but I can't find a good reference.
[15:16] <rbasak> roaksoax: so I'm not really sure what is correct. I'll happily accept whatever a systemd-type person here says.
[15:16] <cjwatson> There should be something in one of the init script layers
[15:17] <cjwatson> /lib/lsb/init-functions.d/40-systemd
[15:17] <cjwatson> if [ -d /run/systemd/system ]; then
[15:17] <rbasak> Ah
[15:17] <cjwatson> I believe that's the canonical method
[15:17] <rbasak> I recalled something about something in /run but was unable to find it.
[15:18] <rbasak> Thanks
[15:18] <cjwatson> rbasak: Found the documentation for that - sd_booted(3)
[15:19] <cjwatson> under NOTES
[15:19] <rbasak> Perfect!
[15:29] <roaksoax> rbasak: i dont understand why upgrading from trusty to xenial in the said patch matters ?
[15:29] <roaksoax> rbasak: the path is for 1.9, not for xenial
[15:29] <roaksoax> rbasak: the path is for 1.9, which does not run in xenial
[15:30] <roaksoax> and maas 2.x, in xenial, always uses systemd
[15:30] <roaksoax> rbasak: that code path no longer exists in 2.x
[15:34] <roaksoax> that said, MAAS currently checks for "/run/systemd/system", but that's proven not to be effective
[15:34] <roaksoax> hence, the bug report
[15:54] <colinl> hello folks :)
[15:55] <colinl> I'm dropping by to make sure I did everything correctly, regarding a patch I'd like to see backported to Ubuntu : https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1714518
[15:55] <ubottu> Launchpad bug 1714518 in gtk+3.0 (Ubuntu) "GTK+3 doesn't show FUSE/GVFS, smb (SMB/CIFS), sftp (SFTP/SSH) network shares in file chooser" [Low,In progress]
[15:55] <colinl> (last comment)
[15:58] <LocutusOfBorg> jbicha, ^^ :)
[15:59] <colinl> (ping seb128, IIRC you were interested in that bug)
[15:59] <colinl> hi LocutusOfBorg and thanks :)
[16:08] <seb128> colinl, I'm adding it to my queue but I'm currently busy with something else, going to have a look later
=== maclin1 is now known as maclin
[16:15] <rbasak> roaksoax: sorry, I didn't realise that you were already testing that
[16:15] <rbasak> Does that mean there's a bug in init-system-helpers because it uses the same test?
[16:20] <colinl> thanks seb128 :)
[16:22] <colinl> seb128: if/when it goes in, I'll submit one for 16.04 :)
[16:25] <cjwatson> I question why testing for /run/systemd/system wouldn't be effective; I've never heard of that existing when systemd isn't the running init system, and I think any such occurrence deserves to be tracked down quite vigorously
[16:25]  * rbasak is trying to reproduce
[16:25] <jbicha> colinl: you need to backport to the newer Ubuntu releases (17.10 and 17.04) at the same time or before
[16:25] <colinl> jbicha: will do, then :)
[16:26] <rbasak> Installing snapd on Trusty does indeed create /run/systemd/system/
[16:26] <cjwatson> is this possibly a snapd bug then?
[16:27] <rbasak> It looks that way. I see snapd.postinst gating on the existence of the directory though, so I don't yet know where it is getting created.
[16:28] <cjwatson> Since this is the documented method for testing whether systemd is running, I think there's a compelling case for leaving MAAS (and init-system-helpers) the way it is and fixing whatever's breaking it.
[16:29] <cjwatson> It shouldn't be particularly widespread breakage.
[16:35] <rbasak> cjwatson: snapd depends on systemd. Installing systemd on Trusty when upstart is running starts a "/lib/systemd/systemd --system" (looks like upstart manages that) and that creates /run/systemd/system.
[16:35] <rbasak> Is it a bug that snapd depends on systemd?
[16:36] <rbasak> The systemd package on Trusty ships a /etc/init/systemd.conf
[16:36] <rbasak> description "run systemd deputy init"
[16:36] <rbasak> pre-start exec mkdir -p /run/systemd/system
[16:36] <cjwatson> Hm.  I'm not sure of the documented semantics for the weird deputy systemd thing in trusty
[16:37] <cjwatson> Foundations may need to work something out there and figure out how it aligns with all the stuff that's following the systemd documentation ...
[16:38] <cjwatson> I wonder if it's possible to configure the deputy systemd to use some other /run subdirectory (but that may have other problems)
[16:38] <cjwatson> There are variant "dsystemd" paths used for cgroups
[16:39] <rbasak> It looks like snapd is using the deputy systemd to manage its daemons
[16:39] <cjwatson> xnox: ^-
[16:39] <cjwatson> Yeah, the deputy systemd was introduced specifically for snapd
[16:39] <cjwatson> https://bugs.launchpad.net/ubuntu/trusty/+source/systemd/+bug/1656280
[16:39] <ubottu> Launchpad bug 1656280 in systemd (Ubuntu Trusty) "Support installing subordinate systemd on Ubuntu Desktop 14.04.5" [High,Fix released]
[16:39] <seb128> jbicha, colinl, I wouldn't bother SRUing to zesty at this point
[16:40] <cjwatson> I think this discovery about its /run/systemd/system behaviour demonstrates that some of the claims in that bug report don't quite hold up
[16:40] <xnox> rbasak, yes that is all true; one can run snapd and snaps on trusty; with systemd package; and lts-xenial kernel installed; there is a branch for that.
[16:41] <xnox> cjwatson, rbasak - i believe on trusty we do not create /run/systemd/system and have it patched to use alternative path names.
[16:41] <rbasak> xnox: that's not true AFAICT. See the upstart snippets I pasted above.
[16:41] <xnox> ditto on trusty it does _not_ use /lib/systemd/system nor /etc/systemd/system
[16:41] <xnox> haha
[16:41] <xnox> well
[16:41] <rbasak> /etc/init/systemd.conf explicitly creates /run/systemd/system
[16:41] <xnox> I inherited that code.
[16:42] <rbasak> What's the right way to fix this?
[16:42] <xnox> i guess we must create that, as things launched by snapd must detect/think that it is running under systemd as pid 1, but not really.
[16:42] <rbasak> Do we treat it as a bug in systemd in Trusty, and not in maas then?
[16:42] <jbicha> seb128: I guess that depends on who on the SRU Team is doing the review :/
[16:42] <cjwatson> It looks to me like we've patched some of the paths to be different, but not that one
[16:43] <seb128> jbicha, the requirement to SRU to non-LTS-non-current to upload a fix to the LTS is boggus imho
[16:44] <cjwatson> If we change maas, I think the change should be confined to trusty rather than leaking to later releases (which don't have this deputy systemd stuff); but hopefully there's some way to change systemd instead to avoid the problem ...
[16:44] <jbicha> seb128: interestingly, it is not mentioned at https://wiki.ubuntu.com/StableReleaseUpdates as far as I can see
[16:44] <xnox> rbasak, my hunch is that said path should have been patched; or at least be created in a namespace not visible in the general system. But i fear we cannot use mount namespaces due to classic confiment snaps.
[16:47] <xnox> rbasak, please open the bug report, and or point me to an existing one, to hack on it. I cannot commit to deliver it before end of year; as I'm end of year on friday.
[16:50] <xnox> rbasak, cjwatson - the maas check; for the purposes that it needs it for; as indicated in the merge proposal; is adequate.
[16:50] <rbasak> xnox: thanks. It's bug 1732703. I'll add a systemd task.
[16:50] <ubottu> bug 1732703 in MAAS 1.9 "MAAS does not detect properly if Ubuntu is using upstart/systemd" [Critical,In progress] https://launchpad.net/bugs/1732703
[16:58] <xnox> rbasak, commented on the bug report.
[16:59] <xnox> rbasak, i'd rather see maas ship the proposed fix in https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/334930 or e.g. compile maas on trusty in such a way that does not introduce systemd management code at all.
[17:00] <xnox> rbasak, e.g. when cloud-init was getting backports, it was excluding systemd support as a compile time / configure option.
[17:07] <slangasek> cjwatson, xnox, rbasak: I recall that we *did* evaluate moving /run/systemd/system to a different path as part of that SRU, and concluded that it wasn't a viable approach
[17:08] <xnox> ack, thanks. I have limited history about that thing.
[17:09] <slangasek> yeah unfortunately that's as much detail as I remember off the top of my head.  If folks think we should be changing the path, I can try to dig into history
[17:18] <rbasak> xnox: it feels to me that the MAAS fix in the queue is the worst of both worlds right now.
[17:19] <rbasak> Hardcoding for upstart would be one way, which is essentially what you say.
[17:19] <rbasak> That would be less error prone I think, as any further disruption to systemd in Trusty wouldn't be able to affect anything.
[17:20] <rbasak> I think that we need to decide what the "official" way of detecting systemd is. And make that work. Or accept that Trusty is broken. But there should be a general answer for Trusty least, and then MAAS should do that.
[17:20] <rbasak> If the general answer is "there's no reliable way; always assume upstart on Trusty" then we can hardcode MAAS to do that.
[17:21] <xnox> rbasak, i think hard-coding to use upstart on trusty is the right way forward; trusty is messed up in many ways with like systemd-services and the deputy systemd as we like migrated to logind but not the rest of it.
[17:22] <xnox> rbasak, and on things later than trusty, the canonical check is to check for /run/systemd/system directory presense.
[17:55] <rbasak> xnox: this may have broken tools like puppet on Trusty too :-/
[18:58] <mwhudson> doko: yes
[22:14] <doko> LocutusOfBorg: was there a specific reason that you dropped the new b-d's for graphviz instead of proposing main inclusion of these packages?
[22:37] <bdmurray> mdeslaur: IIRC you wanted me to look at some debdiffs in bug 1574670. Is there any chance you could submit a bionic MP so it'd be easier to comment on?
[22:37] <ubottu> bug 1574670 in update-manager (Ubuntu Artful) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/1574670
[22:40] <bdmurray> mdeslaur: ah, nevermind