=== JanC_ is now known as JanC
[05:43] <pitti> mwhudson: err, that bug never affected xenial; it was introduced in some commit in 231 and reverted/fixed shortly after
[05:43] <mwhudson> pitti: it's happening to me right now
[05:43] <mwhudson> and i'm on xenial
[05:43] <pitti> mwhudson: if you see a similar effect under xenial, please file a new bug, it's something completely new and unknown then
[05:43] <mwhudson> pitti: oh goodie
[05:44] <pitti> Good morning
[05:44]  * mwhudson ubuntu-bugs
[05:48] <mwhudson> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1621327
[05:48] <ubottu> Launchpad bug 1621327 in systemd (Ubuntu) "alt-left/right moves VTs even when in X" [Undecided,New]
[05:49] <pitti> mwhudson: oh, so keystrokes don't go to the VTs or mess up the console, only Alt+Left/Right?
[05:49] <mwhudson> pitti: yeah
[05:50]  * pitti actually has no idea what handles [Ctrl+]Alt+Left/Right, I thought that was the kernel itself
[05:50] <mwhudson> so i guess it's not quite the same
[05:50] <pitti> mwhudson: and is that happening in y for you too?
[05:50] <mwhudson> pitti: no, i'm on x
[05:50] <mwhudson> pitti: only started recently, i wonder what the chances that it'll stop if i restart...
[05:51] <pitti> mwhudson: so this only happens after an upgrade, not after a fresh boot?
[05:52] <mwhudson> pitti: to be fair i don't know what caused it
[05:52] <pitti> this needs some reproducer and collecting data, I'm afraid; I don't get that here, nor did I see this before in bugs
[05:52] <mwhudson> i just mentioned my symptoms and someone mentioned that debian bug
[05:52] <pitti> I'll do some research what handles the (Ctrl+)Alt keys
[05:52] <mwhudson> i'll reboot and see if it goes away :-)
[05:57] <mwhudson> pitti: yeah, i rebooted and it's stopped
[05:58] <RAOF> Oh, *that* bug!
[05:58] <RAOF> Oooh, does it happen when updating systemd?
[05:58] <stgraber> mwhudson: sudo kbd_mode -s
[05:58] <RAOF> (That happens on yakkety too)
[05:59] <stgraber> mwhudson: I've had a few systems where the console got reset to non-raw mode (on Xenial) which can cause the symptoms you described above
[05:59]  * pitti runs systemctl daemon-reexec, and sudo apt-get install --reinstall systemd, nothing here
[06:00] <pitti> maybe it sometimes restarts console-setup.service or so? /me tries
[06:00] <stgraber> mwhudson: yep, confirmed that if I intentionaly break it with "sudo kbd_mode -u" I do get exactly what you described, "sudo kbd_mode -s" fixes it
[06:00] <pitti> I tried to restart console-setup.service, keyboard-setup.service, setvtrgb.service, all fine; does that trigger the bug for you?
[06:09] <mwhudson> stgraber: ah
[06:10] <pitti> xnox: hm, today's dist-upgrade pulls in gnupg-l10n gnupg1 gnupg1-curl gnupg1-l10n
[06:10] <mwhudson> pitti: yeah, those don't seem to do anything
[06:10] <pitti> xnox: I thought we wanted to move to 2 only?
[06:11] <mwhudson> stgraber's thing seems to match my symptoms
[07:14] <pitti> Laney: FYI, I got it working last night: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=df691943dc
[07:14] <pitti> Laney: i. e. nothing to change in the charms, just driving the juju-1 vs. -2 CLI in the deploy.sh script needs adjusting; now it works with both
[07:14] <smb> nacc, Not at such times. I am UTC+2 right now ;)
[07:15] <pitti> Laney: I ran into bug 1621336 (but that happens with juju-1 too) and bug 1621237, otherwise works great
[07:15] <ubottu> bug 1621336 in snapd (Ubuntu) "snapd.boot-ok.service hangs eternally on cloud image upgrades" [Undecided,New] https://launchpad.net/bugs/1621336
[07:15] <ubottu> bug 1621237 in Charm Helpers "get_local_nodename() fails in IPv6 addresses" [Undecided,New] https://launchpad.net/bugs/1621237
[07:49] <dholbach> smb, happy birthday! :)
[07:50] <sakrecoer> hi! we have a situation in ubuntu studio, non of our members have upload rights. could anyone of you help us with that or point me to someone who could?
[07:51] <sakrecoer> and happy birfday smb! :) virgo power!
[07:51] <smb> thanks
[07:52] <pitti> ooh, alles Gute smb!
[07:54] <smb> pitti, danke danke :)
[07:56] <sarnold> gratulieren smb :)
[07:56] <smb> danken sarnold
[07:56] <smb> :-P
[07:59] <xnox> pitti, ack. let me look into reverse-deps and kick things out.
[08:00]  * xnox is glad things finally landed.
[08:00] <pitti> xnox: oh, might be because I have signing-party installed
[08:00] <pitti> xnox: indeed, congrats! nice work
[08:00] <xnox> pitti, ... however i will be sad if caff cannot do gnupg2....
[08:01] <pitti> xnox: so indeed my main concern was to not install it by default on images
[08:01] <pitti> Package: gnupg
[08:01] <pitti> Task: minimal
[08:01] <pitti> I suppose we should update that :)
[08:02] <pitti> also, minimal seems harsh
[08:02] <pitti> apt prefers gpgv over gpgv2, at some point we should flip that around
[08:02] <xnox> it's not that harsh. we rely on master key for archive key migrations.
[08:02] <pitti> xnox: but that should be gpgv2, not gnupg
[08:03]  * xnox thought gpgv is now 2.1, gpgv2 transitional, gpgv1 old one? (same as gnupg)
[08:03]  * xnox checks
[08:03] <pitti> xnox: oh, you are right, nice
[08:03] <pitti> so we don't actually seed gpg or gnupg
[08:04] <pitti> must come through dependencies, or the Task: headers didn't get recomputed after that
[08:05] <pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt has a lot of stuff which wants to get lifted, but no gpg 1 stuff to get dropped, hmm
[08:05] <xnox> pitti, https://launchpad.net/ubuntu/+source/gnupg should be demoted to universe and/or removed
[08:05] <xnox> as it should be replaced fully now by src:gnupg2 & src:gnupg1
[08:05] <pitti> indeed, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[08:06] <xnox> cool
[08:06] <pitti> only the source, for some reason
[08:06] <pitti> ah, the gnupg binary is from gnupg2 now
[08:14] <pitti> xnox: hm, do we actually want/need pinentry-curses as Priority: important (i. e. in the standard install, even in containers) now?
[08:15] <xnox> it's either that or
[08:15] <pitti> seb128, Laney: who knows about ubuntu-system-settings these days? it's the remaining thing on http://people.canonical.com/~ubuntu-archive/nbs.html, thus a thorn in my eye :)
[08:15] <seb128> pitti, kenvandine and jgdx
[08:16] <xnox> telling everyone to "echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf" and "echo pinentry-mode loopback >> ~/.gnupg/gpg.conf"
[08:16] <seb128> you probably want Ken for packaging changes
[08:16] <pitti> seb128: thanks
[08:16] <seb128> yw
[08:41] <mitya57> Mirv, I would like to get https://codereview.qt-project.org/170467 and https://codereview.qt-project.org/170460 into yakkety, but I want to wait for +2s first.
[08:42] <mitya57> Maybe there will be one more fix from me, related to desktop notifications. But I have not yet written it :)
[08:43] <Mirv> mitya57: I noticed them both, yes feel free to add them to qtbase packaging once +2. I'm (just) done now with my changes for a while.
[08:44] <Mirv> mitya57: ok :)
[08:45] <mitya57> Mirv, I'm a bit sorry that we now have too many patches, but on the other hand we'll have less bugs and complaints :)
[08:46] <Mirv> mitya57: well this was hoped all along to get appmenu truly fixed for xenial+1, it's great to have these
[08:59] <xnox> pitti, trying out systemd-graphical-session.... do i still need ppa and hud from that ppa and systemd-graphical-session?
[08:59]  * xnox gets no hud/unity running
[09:00] <pitti> xnox: half of it landed in yakkety proper, the other half has been stuck in https://requests.ci-train.ubuntu.com/#/ticket/1710 for a while
[09:00] <pitti> xnox: but I believe Trevinho is working on landing the unity bits
[09:00] <pitti> xnox: but the PPA is still expected to work, for the indicators, hud, and unity
[09:01] <xnox> horum
[09:02] <xnox> bamfdaemon failed for me, and then unity7 failed with dependancy wait
[09:04] <xnox> pitti, i ponder about: alias userctl='systemctl --user'
[09:06] <xnox> manually starting bamfdaemon works, and things look like they work.
[09:06] <pitti> what did it fail on?
[09:06] <xnox> the combos of upstart, systemd, gnome-session are a bit weird =)
[09:06] <xnox> pitti, it was failing to aquire the dbus name for the org.Bamf whatever.
[09:07] <pitti> xnox: hm, did both the upstart and the systemd job try to run?
[09:07] <xnox> so it seems like bamfdaemon was started, respawned, hit limit, before user dbus was up.
[09:07] <xnox> yes. my dbus is under upstart control it seems.
[09:07] <xnox> and gnomne-session
[09:07]  * xnox is weird and i have gnome-session (Unity) also under upstart
[09:08] <pitti> hm, this is all supposed to be moved already
[09:08] <xnox> and url-dispatcher, mediascanner-2.0
[09:08] <pitti> dbus-user-session still installed?
[09:08] <xnox> yeah.
[09:09] <brendand> AdUw3Maa83!
[09:10] <xnox> pitti, i have dbus-user-session installed, and i have two dbuses....
[09:11] <xnox> systemctl --user status dbus pid 25133
[09:11] <xnox> initctl --user status dbus process 27389
[09:12] <doko_> Laney: yes, alan_g is looking at the mir test failure
[09:12] <Trevinho> xnox: yeah... Please add an alias for that... Ora soooo annoying :-)
[09:12] <xnox> i see no override for dbus in /usr/share/upstart/systemd-session/upstart
[09:12] <Trevinho> xnox: as for unity, the other landing should be enough
[09:14] <xnox> how is dbus supposed to run?
[09:18] <xnox> this is amazing.... switched to tty and the gpg-agent still works =)
[09:19] <pitti> xnox: via "systemctl --user status dbus.service"
[09:19] <pitti> xnox: yep, the magic  of user bus :)
[09:20] <Laney> Trevinho: are you still waiting for a second review?
[09:20] <xnox> ok. and the $ initctl --user status dbus -> shouldn't be running? is it on manual for you?
[09:20] <pitti> xnox: i. e. /usr/lib/systemd/user/dbus.service will always run, independent of our systemd-ified session startup
[09:20] <xnox> sure. but something needs to get rid of the upstart user session dbus, no?
[09:20] <Trevinho> Laney: yep...
[09:21] <pitti> xnox: yes, indeed; trying to remember what does that
[09:21] <Laney> meh
[09:21] <pitti> xnox: ah, here: http://launchpadlibrarian.net/261442770/dbus_1.10.6-1ubuntu3_1.10.6-1ubuntu4.diff.gz
[09:21] <pitti> xnox: we built it into the upstart dbus job itself
[09:22] <pitti> xnox: so you should still have the upstart job running as we need it as a "stub" to start reverse dependencies, but it should only run "sleep infinity"
[09:22] <pitti> (this can probably be made more elegant somehow, by merely having it appear as running but not execing anything)
[09:23] <Laney> Trevinho: ted_g approved it
[09:25] <xnox> right that pid is sleep infinity
[09:26] <xnox> more elegantly, one would "initctl emit started JOB=dbus" and that's it.
[09:26] <xnox> without actually running/respawning sleep infinity.
[09:26] <pitti> sounds nice
[09:27] <Laney> wouldn't that make it stop straight away?
[09:27] <xnox> why?
[09:27] <Laney> the process would finish
[09:27] <highvoltage> l/win 46
[09:28] <pitti> right, "stop on stopped dbus" needs to continue to DTRT
[09:28] <pitti> if things are only listening for "started dbus", that'd be fine
[09:29] <pitti> but ISTR having seen a job which does nothign on exec and just has pre/post-start
[09:29] <Laney> RemainAfterExit=yes # oh wait
[09:29] <Laney> yeah, gpg-agent does that
[09:29] <Laney> I forgot precisely what events that causes
[09:29] <Laney> but then you could just do /bin/true
[09:30] <Laney> assuming it goes to started
[09:30] <Saviq> xnox, hey, shouldn't gnupg in yakkety depend on dirmngr now?
[09:30] <pitti> I thought it would only work for that as nothing does "stop on stopped gpg-agent"
[09:30] <Laney> hang on, this is easily testable
[09:30] <Laney> .config/upstart to the rescue
[09:31] <xnox> Saviq, Laney asked me that as well. I'm not sure. what are the symptoms you hit?
[09:31] <Saviq> https://unity8-jenkins.ubuntu.com/job/run-commands/node=jenkins-slave-0/lastBuild/console
[09:31] <Saviq> xnox, ↑
[09:34] <Laney> pitti: Don't think it works, since you still need the exec block for the old case; this trick only works if you have pre-start but no exec (or script)
[09:34] <xnox> Laney, echo 'start on starting xsession-init' > ~/.config/upstart/dbus.conf
[09:34] <xnox> Laney, echo 'stop on stoping xsession-init' > ~/.config/upstart/dbus.conf
[09:34] <xnox> Laney, echo 'stop on stoping xsession-init' >> ~/.config/upstart/dbus.conf
[09:35] <xnox> start dbus; status dbus -> running; stop dbus -> stopped.
[09:35] <xnox> Laney, why do we need it for the old case? systemd user dbus session is always available, even in xenial.
[09:35] <xnox> and we are not double/tripple landing dbus
[09:35] <Laney> then just have it always be started
[09:35] <Laney> pre-start exec /bin/true
[09:35] <xnox> we need dbus events in upstart user session, but dbus can be started/stopped by user systemd
[09:36] <xnox> i don't even need to exec anything.
[09:36] <Laney> if that works, then 'start on startup'
[09:36] <pitti> xnox: no, you can uninstall dbus-user-session, and it's not installed by default in xenial
[09:36] <Laney> I think the old way is still required to be supported
[09:36] <xnox> just have "start/stop on starting/stopping xsession-init" it does make an assuption that dbus is started by systemd before upstart user session is available.
[09:36] <xnox> horum.
[09:37] <xnox> then split into two upstart jobs.
[09:37] <xnox> one is dbus to emit events / become sync point and another is dbus-daemon that actually spawns the daemon if need be, which is start on starting dbus
[09:37] <Laney> sleep infini_ty seems less annoying than that
[09:37] <xnox> true
[09:38] <xnox> gnome-session is also sleep infinity
[09:38] <pitti> the overrides  can go away once we lland systemdification of the rdepends
[09:38] <pitti> i. e. unity and indicators
[09:38] <pitti> so those sleep infinitys are only a temporary shim
[09:39]  * pitti didn't expect unity and indicators to take that long, sorry
[09:40] <xnox> what about the phone though?
[09:40] <xnox> it has more things still....
[09:41] <pitti> xnox: right, still lots of WIs for the phone; but this doesn't run on yakkety, so no sleep i_nfinity there
[09:42] <xnox> Saviq, given that one cannot '--recv-keys' i do think we need/want dirmngr.
[09:42] <Saviq> +1
[09:42] <xnox> however, may i use "Recommends:" instead of "Depends:"?
[09:42] <xnox> that way it will be installed by default on most systems, but bare-minimal offline ones.
[09:43]  * xnox thinks that through for a moment.
[09:43] <xnox> wait it already recommands dirmngr
[09:43] <xnox> so why is it not installed.
[09:44] <Saviq> xnox, likely the way I configured mk-sbuild
[09:44] <xnox> Saviq, you use add-apt-repository, which assumes importing things over the network, maybe that should depend on dirmngr?
[09:44] <xnox> same as e.g. bzr-builddeb, landscape-client, piuparts, python-apt, python-germinate, ubuntu-dev-tools?
[09:45] <xnox> (as in software-properties-common)
[09:45] <Saviq> xnox, wfm
[09:45] <xnox> i'm happy to add depends in software-properties-common.
[09:45] <Saviq> agreed that gnupg2 itself maybe shouldn't depend, since unless you use --recv-keys it will work fine, and the error message than is pretty clear
[09:46] <Saviq> *then
[09:55] <xnox> and done =)
[09:58]  * pitti adds a more tasteful home page to http://autopkgtest.ubuntu.com/
[10:01] <Trevinho> Laney: one more approval, then if you want it's good for your publish button
[10:03] <tseliot> pitti: hey, do you think you can approve those packages for me today?
=== hikiko is now known as hikiko|ln
[11:16] <roaksoax> howdy! are there any issues with apt or archives ?
[11:16] <roaksoax> i'm starting to see issues like: http://pastebin.ubuntu.com/23149808/ in an overlayfs
[11:19] <roaksoax> pitti who should I talk to about issues like http://pastebin.ubuntu.com/23149808/ ? any ideas ?
[11:23] <Anticom> Hi all, I'm looking for jml. According to his readme, he's the guy to talk to about undistract-me
[11:25] <hloeung> roaksoax: larrymi saw the same thing earlier today, so it may be a bad MAAS image. Not sure
[11:26] <roaksoax> hloeung: I don't think it is the maas image itself, but something changed that is causing this issue
[11:26] <roaksoax> hloeung: in an overlayfs
[11:27] <hloeung> roaksoax: oh ok
[11:28] <roaksoax> hloeung: may be related to this: https://bugs.launchpad.net/cloud-init/+bug/1618572
[11:28] <ubottu> Launchpad bug 1618572 in linux (Ubuntu) "apt-key add fails in overlayfs" [High,Confirmed]
[11:47] <pitti> tseliot: looking; FWIW, "low regression potential" is quite an understatement -- this involves new pacakges, new driver on existing systems, etc. :)
[11:48] <pitti> roaksoax: it came up a few times recently with overlayfs (most people experienced that in schroot)
[11:48] <pitti> roaksoax: I think I've overheard xnox saying it's some kernel change, but I'm not sure
[11:49] <pitti> roaksoax: ah yes, that bug looks right
=== dpm_ is now known as dpm
[11:49] <Laney> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1620525
[11:49] <ubottu> Launchpad bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,Triaged]
[11:49] <Laney> xnox pointed me to that one, but might be a duplicate
[11:50] <Laney> and the other one has a fix, go apw!
[11:52] <roaksoax> pitti: yeah it seems it is the same bug
[11:55] <pitti> tseliot: source-NEWed; will wait for the binaries, new them, and then call for testing on the bug
[12:28] <mapreri> jbicha: in debian libsecret was properly fixed (and not just "skip the tests"+hacks..).  The fix is span over pygobject and libsecret itself, which could be both synced, imho.  Though we are in FF so some care could be used..
[12:28] <mapreri> can you please look at it and see whether you could/should sync them?
[12:30] <tseliot> pitti: thanks!
=== _salem is now known as salem_
[12:53] <pitti> tseliot: done
[12:54] <jbicha> pitti: ^ see above about possiblying syncing pygobject 3.21.91
[12:55] <jbicha> maybe I should type a bit slower
[12:55] <pitti> ah, to keep up  with the beta
[12:56] <pitti> jbicha: no objection, we have fairly good test coverage for it
[12:58] <pitti> infinity: http://autopkgtest.ubuntu.com/packages/g/glibc/yakkety/amd64 started failing two weeks ago, is that known? due to gcc 6?
[13:00] <flexiondotorg> I'm working on the this bug for libmateweather
[13:00] <flexiondotorg> https://bugs.launchpad.net/ubuntu/xenial/+source/libmateweather/+bug/1616533
[13:00] <ubottu> Launchpad bug 1616533 in libmateweather (Ubuntu Xenial) ""Forecast not available" error in GNOME Weather app" [High,Triaged]
[13:00] <flexiondotorg> I've released libmateweather 1.12.2 upstream, which fixes the issue.
[13:01] <infinity> pitti: That's LP: #1600000
[13:01] <ubottu> Launchpad bug 1600000 in systemd (Ubuntu) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Undecided,Triaged] https://launchpad.net/bugs/1600000
[13:01] <flexiondotorg> I want to SRU libmateweather to xenial.
[13:01] <infinity> pitti: Please turn off libnss-resolve in autopkgtest VMs until that's fixed? :)
[13:01] <pitti> infinity: oh? we've had resolve a lot earlier than that
[13:01] <infinity> pitti: Well, if you check the log, that's the failure.  *shrug*
[13:02] <flexiondotorg> Do I need to create a additional bug for the SRU to xenial?
[13:02] <pitti> infinity: ack, thanks
[13:02]  * pitti looks into that
[13:06] <jbicha> flexiondotorg: maybe use that bug for tracking the libmateweather issue and have bug 1620557 handle libgweather
[13:06] <ubottu> bug 1620557 in libgweather (Ubuntu Xenial) "weather.noaa.gov was shut down" [High,In progress] https://launchpad.net/bugs/1620557
[13:06] <jbicha> just because the SRU verification is a bit different for the 2 different packages
[13:26] <flexiondotorg> jbicha, Just to be clear. You're suggesting libgweather uses https://launchpad.net/bugs/1620557 for SRUs.
[13:26] <ubottu> Launchpad bug 1620557 in libgweather (Ubuntu Xenial) "weather.noaa.gov was shut down" [High,In progress]
[13:27] <flexiondotorg> ANd libmateweather uses https://launchpad.net/bugs/1616533
[13:27] <ubottu> Launchpad bug 1616533 in libmateweather (Ubuntu Xenial) ""Forecast not available" error in GNOME Weather app" [High,Triaged]
[13:52] <pitti> infinity: https://github.com/systemd/systemd/pull/4111 sent FYI, I'll see to land that soon
[13:54] <infinity> pitti: Excellent.
[13:55] <infinity> pitti: When did systemd-resolve start being a thing we built and shipped?
[13:55] <infinity> pitti: I'd suggest that's broken enough behaviour that it should be SRUed to any release that included the bits, even though we didn't enable it.
[13:56] <pitti> infinity: somewhere end of May or June or so
[13:56] <pitti> infinity: sure, it's simple enough to SRU (even though I don't think it's that important -- other than test suites I don't see what it could realistically break)
[13:56] <pitti> resolving foo.bar.. like foo.bar is hardly completely unexpected
[13:57] <pitti> but I'll cherry-pick it to the xenial branch once it lands
[13:57] <infinity> pitti: Other than being completely wrong, but yeah, I suppose it's not something people are likely to do often.
[13:59] <pitti> infinity: anyway, arguing about whether or not it's important enough would take more time than just cherry-picking the fix once it's in master, so JFDI :)
[14:03] <infinity> pitti: Yeah, I think you're probably right that it's not actually desperately important, I'm just a big fan of not breaking RFCs.
[14:04] <infinity> pitti: But, there's also just the "LTSes deserve polish" argument.
[14:07] <flexiondotorg> jbicha, How to proceed with SRUs for libgweather and libmateweather?
[14:08] <tseliot> pitti: great, thanks again!
[14:10] <davmor2> pitti: JFDI is that yoda's impression of Obi-wan?  Jedi Force Disturbance Is hmmmmmmmm
[14:20] <xnox> infinity, something i hope they don't, even I don't do that =)
[14:21]  * xnox is crap with standards and networking =)
[14:22] <jbicha> flexiondotorg: yes, the libgweather xenial sru is already in the unapproved queue
[14:23] <flexiondotorg> OK, So no problem for me to remove libgweather from #1616533 then?
[14:23] <jbicha> flexiondotorg: sure, go ahead
[14:23] <flexiondotorg> jbicha, Thanks.
[14:23] <pitti> davmor2: it's jedi typoed too indeed, but more commonly "just f** do it" :)
[14:23] <jbicha> and change the title to match :)
[14:24] <davmor2> pitti: I knew what it mean I just thought it was nicer ;)
[15:23] <doko_> kenvandine: libphonenumber ping
[15:25] <pitti> hmm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt are stuck, /me prods
[15:30] <Laney> pitti: Already doing
[15:30] <Laney> see #ubuntu-release
[15:30] <pitti> Laney: just pushing the b1 fix
[15:30] <pitti> Laney: argh
[15:30] <Laney> :|
[15:30] <pitti> Laney: what did you do?
[15:30] <Laney> Nothing
[15:30] <pitti> Laney: just pushed http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/296
[15:30] <Laney> I know what the problem is but I didn't push it yet
[15:31] <Laney> Fine
[15:31] <pitti> Laney: sorry
[15:31] <Laney> You should remove the exit 0 in run-proposed-migration
[15:31] <Laney> doesn't that just push the problem to the next time?
[15:31] <pitti> Laney: how do you mean?
[15:32] <pitti> Laney: exit 0 removed
=== JanC is now known as Guest38270
=== JanC_ is now known as JanC
[16:42] <kenvandine> doko_, there's a test failure for telephony-service in the silo, someone's working on fixing that
[16:46] <drab> hi, couple questions: I'm trying to preseed all my installations and would love to be able to have a preseed common file imported by others. I'm pulling my main preseed file via url over http. There is a preseed/include string but that doesn't seem to be able to fetch from http, or I'm doing it wrong
[16:46] <drab> anybody got a working example? or is there a better place to ask this question?
[16:47] <drab> oh, maybe -installer, trying there
[17:14] <nacc> drab: iiuc, preseed/include will grab relative to whatever directory your main preseed file was obtained from. Have you tried using a relative path? I honestly don't expect that to work (it seems mostly designed for on-cd customization), but it might?
[17:31] <drab> nacc: yeah I read that and tried, it didn't, it never tried to pull from the webserver where the main file comes down from
[17:31] <drab> I'm puzzled why if url works at the very beginning of the process preseed/include can't
[17:31] <drab> but that does seem to be the case
[17:32] <drab> i might look if I can use something like an early_command to pull it down on the system, but not sure that runs as early in the process as needed (ie it can influence partman etc)
[17:33] <nacc> drab: yeah, i don't think early command will help you necessarily, for the reason you said
[20:01] <semiosis> Odd_Bloke: i'm going to take a look into Poma's report about DNS on the new xenial vagrant box
[20:01] <Odd_Bloke> semiosis: Excellent, thanks!
[20:02] <semiosis> Odd_Bloke: if I can reproduce it and dont see a new bug opened tomorrow i'll open it myself.  i think i know were the problem is.  seem to remember something about resolv.conf manipulation in the livecd-rootfs hooks
[21:02] <Bluefoxicy> I wonder how close my response to Thierry would be to something Linus would say, ignoring the many colorful ways in which Linus would say "You are Dumb(TM)" throughout the whole exchange
[23:07] <attente> is anyone here using a yubikey for ssh authentication on yakkety? i'm wondering why the S.gpg-agent.ssh socket is no longer in my .gnupg directory
[23:11] <stgraber> attente: possibly because of the ongoing switch to gpg2? just a guess though, I'm not using the gpg agent for ssh auth