[11:00] <Laney> nacc: bdmurray: Got a new idea...
[11:28] <Laney> attached
[14:30] <nacc> Laney: nice catch, i think that's pretty reasonable
[15:01] <Scars> So I was just reading on here: http://packaging.ubuntu.com/html/udd-intro.html
[15:01] <Scars> Are you telling me this is dead?
[15:02] <rbasak> Correct.
[15:02] <ogra_> udd never really came to life actually
[15:02] <rbasak> We're making good progress on a git-based replacement though
[15:02] <Scars> Any alternative yet? Or any other way to learn how to contribute?
[15:03] <ogra_> https://wiki.ubuntu.com/ContributeToUbuntu
[15:03] <ogra_> perhaps ?
[15:03] <rbasak> We can give you a usable git repo on request.
[15:03] <rbasak> Or you can do it the non-VCS way.
[15:03] <nacc> Scars: how comfortable are you with debian / ubuntu packaging?
[15:06] <nacc> Scars: so it's not strictly required (although helpful) to fix issues
[15:07] <nacc> there is some overview here: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow, but it needs some updating again
[15:07] <Scars> Im completely new
[15:07] <nacc> Scars: i'm on a call right now, but can help give you a guide in a few, if that's ok
[15:09] <jackpot51> Laney: Do you need more testing on the DKMS patch?
[15:09] <jackpot51> I could test the NVIDIA package
[15:09] <lan3y> More is good.
[16:03] <xnox_> sladen, cyphermox: in the latest debian upload pitti is disabling DNSSEC in resolved by default (include zesty)
[16:03] <xnox_> because the support is not mature enough.....
[16:03] <xnox_> sladen, unping
[16:03] <xnox_> slangasek, ^
[16:03] <xnox_> should I pick that up into zesty SRU?!
[16:07] <cyphermox> xnox_: I'd tentatively say yes?
[16:08] <cyphermox> it tends to break things
[16:09] <slangasek> xnox_: there are certainly outstanding issues with dnssec, though I don't know if anyone ever filed a proper bug report; I'd say we need some sort of dnssec fix srued, yes
[16:10] <xnox_> slangasek, the bit where it cannot validate things and internets not working is what concerns me
[16:10] <xnox_> also pitti's commit in the debian's git doesn't mention a specific bug report/reports so it's a general statement.
[16:11] <slangasek> xnox_: the last information I had on this is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647031/comments/33
[16:11]  * xnox_ feels like it should be cherrypicked into zesty.
[16:11] <xnox_> but that one is fixed.
[16:11] <xnox_> i thought
[16:11] <xnox_> (the following bit)
[16:13] <xnox_> things like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1672235 ?
[16:19] <slangasek> xnox_: bug #1647031 was fixed but that bug wasn't about dnssec, the dnssec was pile-on comments.  if there's a separate bug filed, ok good
[16:20] <xnox_> ah
[16:29] <jbicha> I saw comments today from people upgrading to 17.04 and having network problems
[16:30] <jbicha> is this something you're considering doing a 0-day SRU for?
[16:30] <wxl> where's the bug number?
[16:31] <jbicha> some comments on http://www.omgubuntu.co.uk/2017/04/ubuntu-17-04-review-new-features
[16:32] <jbicha> https://ubuntuforums.org/showthread.php?t=2356828
[16:32] <wxl> i'd encourage them to make a bug report
[16:32] <wxl> i'm sure with enogh activity something would get done
[16:32] <jbicha> wxl: I believe that's what's being talked about with systemd ^
[16:33] <wxl> oh. harumph
[17:37] <ilmaisin> xnox_: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966 did you notice this? the change in your patch wasn't enough for xenial, it probably is necessary to reload systemd configuration in the post-installl script also
[17:42] <ilmaisin> xnox_: however if it is the old package's preremoval script that fails it probably does not matter what there is in the new package's scripts
[17:43] <infinity> Reloading systemd from packages should never be necessary.
[17:43] <infinity> systemd has a dpkg trigger for this very prupose.
[17:43] <infinity> purpose, too.
[17:44] <ilmaisin> infinity: hmm
[17:45] <ilmaisin> infinity: if you can tell what's wrong with the update i'll be grateful
[17:45] <infinity> I'm having a hard time following the bug comments to see that anything's wrong with it at all. :P
[17:46] <infinity> Ahh, found it.
[17:47] <infinity> So, if old prerm is failing on a bad unit, then new prerm is attempted.  New prerm should be written in a way that it skips/ignores the failure.
[17:49] <infinity> ilmaisin: Informed xnox of the above (he's right next to me)
[17:50] <ilmaisin> infinity: thx
[20:18] <ilmaisin> xnox_: the root cause of the problem seems to be that if there is a stuck job, "invoke-rc.de cups stop" fails
[20:19] <ilmaisin> xnox_: this probably means that we can't have any updates to cups now, not even critical security updates
[20:48] <DPK_> not sure if this is the right place to ask this, but i've been pulling my hair out lately trying to preseed/config a ubuntu install w/ a custom internal mirror of security.ubuntu.com -- the problem is our internal mirror is https
[20:48] <DPK_> i'm trying to figure out how to override that in preseed config
[20:49] <DPK_> initially i have just this:
[20:49] <DPK_> d-i apt-setup/services-select multiselect security
[20:49] <DPK_> d-i apt-setup/security_host string internal.mirror.net
[20:49] <DPK_> d-i apt-setup/security_path string /current/security.ubuntu.com/ubuntu
[20:49] <DPK_> but i can't figure out how to configure it such that it'll be https://internal.etc instead of http://internal.etc
[21:15] <xnox_> DPK_, there is one more key for protocol i think
[21:15] <xnox_> but i can't remember if we ask that for security too, let me check quickly
[21:16] <xnox_> (cause we support http, ftp, https)
[21:17] <xnox_> DPK_, ha, we do not it is hardcoded to http
[21:17] <xnox_> for the security
[21:18] <xnox_> DPK_, i think you may need to apply sed to either generators/91security during install; or in the install hook; or post install.
[21:18] <xnox_> DPK_, could you please open a bug report against apt-setup requesting to support apt-setup/security_protocol key?
[21:19] <xnox_> (cause e.g. for regular mirrors protocol question is a thing that is supported)
[21:59] <DPK_> @xnox sure will do
[21:59] <udevbot> Error: "xnox" is not a valid command.
[22:00] <dobey> heh
[22:00] <dobey> bots
[22:34] <jbicha> I guess LP: #1681513 is another reason why some people are having network trouble after the update
[22:36] <wxl> jbicha: someone here in #kubuntu-devel has the problem and tested with the 4.10.x mainline kernel and problem is solved. not sure it's the same thing. there might be multiple issues.