[13:14] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu MATE: Ubuntu MATE 21.10 Release Notes @ https://ubuntu-mate.org/blog/ubuntu-mate-impish-indri-final-release/
[14:45] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu 21.10 is Now Available to Download @ https://www.omgubuntu.co.uk/2021/10/ubuntu-21-10-is-now-available-to-download (by Joey Sneddon)
[19:00] -SwissBot:#ubuntu-news- ::Portugal:: Ep 164 – Hacktoberfest II – Pedro Silva @ https://podcastubuntuportugal.org/ep-164-hacktoberfest-ii-pedro-silva/
[19:15] -SwissBot:#ubuntu-news- ::Planet:: Podcast Ubuntu Portugal: Ep 164 – Hacktoberfest II – Pedro Silva @ https://podcastubuntuportugal.org/ep-164-hacktoberfest-ii-pedro-silva/
[20:02] <guiverc> https://lists.ubuntu.com/archives/ubuntu-announce/2021-October/000274.html
[20:04] <krytarik> guiverc: Yeah, and I'm here to review the post if you prep one.. :P
[20:05] <guiverc> thanks krytarik, removing /n or the start of one now
[20:13] <guiverc> krytarik, when you can review please  :)  https://fridge.ubuntu.com/?p=9357&preview=true
[20:14] <krytarik> Alright, logging in..
[20:14]  * guiverc is out of page too
[20:14] <guiverc> More Information is larger... I just noticed
[20:15] <guiverc> did I mistype a h3 to be something different maybe?  please check
[20:15] <krytarik> Will do.
[20:16] <krytarik> Yep, the last one looks slightly large.. :P
[20:25] <krytarik> guiverc: Also fixed two links and the usual on-off mess of italics in the footer. :P
[20:27] <guiverc> thanks; did I miss links or what (didn't expect them.. yeah the footer I copy paste then change text & forgot to edit out extra end/start italics etc)
[20:28] <guiverc> https://fridge.ubuntu.com/2021/10/14/ubuntu-21-10-impish-indri-released/
[20:30] <krytarik> Yeah, the links to <https://ubuntu.com/desktop> and <../features> in the middle weren't actual links.
[20:30] <guiverc> sorry (for missing) but thanks for catching..
[20:39] <guiverc> & posted both to twitter & fb; thanks again krytarik
[20:39] <krytarik> No, thank you!
[20:40] <guiverc> i was given control to https://t.me/ubuntunewsletter so am pasting there too
[20:42] <krytarik> Ah, thanks for taking care of that too!
[20:52] <krytarik> Just noticed while the sidebar of the Fridge site got a rather lengthy list of archive links all the way back to 2005, there aren't any links to the social media outlets in it - but updating the content or settings of any widgets still only goes through filing a ticket for it.. :/
[20:53] <krytarik> Oh, and the About page still refers to freenode too.. :3
[20:54] <krytarik> Well, but since that is a page, we could update at least this..
[20:55] <guiverc> :)  good spot & thanks
[21:20] <krytarik> Since apparently <https://ubuntuforums.org/forumdisplay.php?f=122> is closed and we probably don't want people to hijack the UWN threads in the other subforum for unrelated feedback, I think I'll just drop the forums link entirely from the About page..
[23:26] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: 10 Things To Do After Installing Ubuntu 21.10 @ https://www.omgubuntu.co.uk/2021/10/things-to-do-after-installing-ubuntu-21-10 (by Joey Sneddon)


[01:56] <lotuspsychje> good morning
[06:10] <lordievader> Good morning
[07:59] <marcoagpinto> Morning!


[00:08] -queuebot:#ubuntu-release- Unapproved: accepted nautilus-dropbox [source] (zesty-proposed) [2015.10.28-1ubuntu1]
[00:11] -queuebot:#ubuntu-release- New: accepted sdpb [amd64] (zesty-proposed) [1.0-3]
[00:11] -queuebot:#ubuntu-release- New: accepted sdpb [armhf] (zesty-proposed) [1.0-3]
[00:12] -queuebot:#ubuntu-release- New: accepted sdpb [ppc64el] (zesty-proposed) [1.0-3]
[00:12] -queuebot:#ubuntu-release- New: accepted sdpb [arm64] (zesty-proposed) [1.0-3]
[00:12] -queuebot:#ubuntu-release- New: accepted sdpb [s390x] (zesty-proposed) [1.0-3]
[00:12] -queuebot:#ubuntu-release- New: accepted sdpb [i386] (zesty-proposed) [1.0-3]
[00:15] <tsimonq2> infinity: TIL, I've been doing it manually this whole time...
[00:34] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [121 => 122] (kubuntu, ubuntu-desktop)
[00:41] -queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.1.4+bzr5591-0ubuntu1~16.04.1 => 2.1.5+bzr5596-0ubuntu1~16.04.1] (ubuntu-server)
[00:43] -queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.4+bzr5591-0ubuntu1~16.10.1 => 2.1.5+bzr5596-0ubuntu1~16.10.1] (ubuntu-server)
[00:50] -queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2-0ubuntu2~16.04.1 => 1.0.0~rc2+docker1.12.6-0ubuntu1~16.04.1] (no packageset)
[00:50] -queuebot:#ubuntu-release- Unapproved: runc (yakkety-proposed/universe) [1.0.0~rc2-0ubuntu2~16.10.1 => 1.0.0~rc2+docker1.12.6-0ubuntu1~16.10.1] (no packageset)
[01:31] -queuebot:#ubuntu-release- Unapproved: hw-detect (zesty-proposed/main) [1.117ubuntu3 => 1.117ubuntu4] (core)
[01:32] <flexiondotorg> infinity I've uploaded a reworked caja-dropbox
[01:33] <flexiondotorg> Time for sleeping Z z .
[01:34] -queuebot:#ubuntu-release- Unapproved: caja-dropbox (zesty-proposed/multiverse) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
[01:40] -queuebot:#ubuntu-release- Unapproved: ubuntu-keyboard (zesty-proposed/main) [0.100+17.04.20170301-0ubuntu1 => 0.100+17.04.20170320-0ubuntu1] (ubuntu-desktop) (sync)
[04:07] -queuebot:#ubuntu-release- Unapproved: yp-tools (zesty-proposed/universe) [3.3-5 => 3.3-5ubuntu1] (no packageset)
[04:07] -queuebot:#ubuntu-release- Unapproved: accepted yp-tools [source] (zesty-proposed) [3.3-5ubuntu1]
[05:28] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (zesty-proposed/universe) [56-1 => 57-1] (no packageset) (sync)
[05:29] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [sync] (zesty-proposed) [57-1]
[05:48] <infinity> flexiondotorg: Looks better.  Not sure why you changed the build-depends, though. :P
[05:48] <infinity> flexiondotorg: But it's basically a no-op at this point in the cycle, so meh.
[05:49]  * infinity goes to sleep now.
[05:50] -queuebot:#ubuntu-release- Unapproved: accepted caja-dropbox [source] (zesty-proposed) [1.18.0-0ubuntu2]
[05:50] -queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (zesty-proposed) [1.117ubuntu4]
[06:09] <tjaalton> infinity: mind letting xorg-server pass so that it would be built. the ffe is acked
[06:10] <infinity> tjaalton: How much did you pay Laney for that ACK?
[06:11] <tjaalton> hehe
[06:11] <tjaalton> passively waiting for someone to act on the bug didn't work out
[06:13] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (zesty-proposed) [2:1.19.3-1ubuntu1]
[07:02] -queuebot:#ubuntu-release- Unapproved: xf86-input-mtrack (zesty-proposed/universe) [0.3.1-1build1 => 0.3.1-1build2] (xorg)
[07:02] -queuebot:#ubuntu-release- Unapproved: xf86-input-xwiimote (zesty-proposed/universe) [0.5-1build2 => 0.5-1build3] (no packageset)
[07:03] -queuebot:#ubuntu-release- Unapproved: accepted xf86-input-xwiimote [source] (zesty-proposed) [0.5-1build3]
[07:04] <tjaalton> wi n29
[07:04] <tjaalton> uh
[07:04] -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (zesty-proposed/main) [1:0.33.0-0ubuntu1 => 1:0.34.0-0ubuntu2] (desktop-core, xorg)
[07:05] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-aiptek (zesty-proposed/universe) [1:1.4.1-2 => 1:1.4.1-2build1] (xorg)
[07:15] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-evdev (zesty-proposed/universe) [1:2.10.2-1ubuntu1 => 1:2.10.5-1ubuntu1] (xorg)
[07:16] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-elographics (zesty-proposed/universe) [1:1.4.1-1build5 => 1:1.4.1-1build6] (xorg)
[07:16] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-mutouch (zesty-proposed/universe) [1:1.3.0-1build8 => 1:1.3.0-1build9] (xorg)
[07:16] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-joystick (zesty-proposed/universe) [1:1.6.3-1 => 1:1.6.3-1build1] (xorg)
[07:16] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-void (zesty-proposed/universe) [1:1.4.1-1build2 => 1:1.4.1-1build3] (xorg)
[07:17] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (zesty-proposed/main) [0.23.0-2 => 0.25.0-0ubuntu1] (desktop-core)
[07:19] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-synaptics (zesty-proposed/main) [1.8.3-1ubuntu1 => 1.9.0-1ubuntu1] (desktop-core, xorg)
[07:23] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (zesty-proposed/main) [1.2.0-1 => 1.3.0-0ubuntu1] (desktop-core)
[07:23] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (zesty-proposed/main) [1:7.8.0-1 => 1:7.9.0-0ubuntu1] (desktop-core, xorg)
[07:26] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-dummy (zesty-proposed/main) [1:0.3.8-1 => 1:0.3.8-1build1] (desktop-core, xorg)
[07:26] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode (zesty-proposed/universe) [2.11.19-1 => 2.11.19-1build1] (xorg)
[07:26] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-neomagic (zesty-proposed/universe) [1:1.2.9-1build2 => 1:1.2.9-1build3] (xorg)
[07:26] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-fbdev (zesty-proposed/main) [1:0.4.4-1build5 => 1:0.4.4-1build6] (desktop-core, xorg)
[07:26] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-mach64 (zesty-proposed/universe) [6.9.5-1build2 => 6.9.5-1build3] (xorg)
[07:29] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-openchrome (zesty-proposed/universe) [1:0.5.0-3 => 1:0.5.0-3build1] (xorg)
[07:29] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-r128 (zesty-proposed/universe) [6.10.2-1 => 6.10.2-1build1] (xorg)
[07:29] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-sisusb (zesty-proposed/universe) [1:0.9.7-1 => 1:0.9.7-1build1] (xorg)
[07:29] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-trident (zesty-proposed/universe) [1:1.3.8-1 => 1:1.3.8-1build1] (xorg)
[07:30] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl (zesty-proposed/main) [0.1.4-3ubuntu3 => 0.1.5-2build1] (desktop-core, xorg)
[07:30] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-tdfx (zesty-proposed/universe) [1:1.4.7-1 => 1:1.4.7-1build1] (xorg)
[07:30] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-savage (zesty-proposed/universe) [1:2.3.8-1ubuntu3 => 1:2.3.9-1ubuntu1] (xorg)
[07:30] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vesa (zesty-proposed/main) [1:2.3.4-1build2 => 1:2.3.4-1build3] (desktop-core, xorg)
[07:30] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vmware (zesty-proposed/main) [1:13.1.0-2ubuntu3 => 1:13.2.1-1build1] (desktop-core, xorg)
[07:39] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (zesty-proposed/main) [2:2.99.917+git20160706-1ubuntu1 => 2:2.99.917+git20170309-0ubuntu1] (desktop-core, xorg)
[07:42] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-siliconmotion (zesty-proposed/universe) [1:1.7.8-1ubuntu6 => 1:1.7.9-2ubuntu1] (xorg)
[07:42] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau (zesty-proposed/main) [1:1.0.13-1 => 1:1.0.14-0ubuntu1] (desktop-core, xorg)
[07:52] -queuebot:#ubuntu-release- Unapproved: mosh (zesty-proposed/universe) [1.3.0~rc2-1 => 1.3.0-1] (no packageset) (sync)
[07:53] -queuebot:#ubuntu-release- Unapproved: accepted mosh [sync] (zesty-proposed) [1.3.0-1]
[07:56] -queuebot:#ubuntu-release- Unapproved: oxide-qt (zesty-proposed/main) [1.20.4-0ubuntu1 => 1.21.5-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[07:58] <apw> tjaalton, i assume all of the deps between these x things are expressed in packaging so we can accept them randomly and things will work ?
[08:00] <tjaalton> apw: right, the xserver is built there already. maybe ack one and I'll verify the build log just to be sure..
[08:02] -queuebot:#ubuntu-release- Unapproved: accepted xf86-input-mtrack [source] (zesty-proposed) [0.3.1-1build2]
[08:02] <apw> tjaalton, ^
[08:02] <apw> tjaalton, and this is all under an FFE already right ?
[08:05] <tjaalton> yep
[08:07] <tjaalton> apw: looks good
[08:16] <apw> tjaalton, ta
[08:18] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-aiptek [source] (zesty-proposed) [1:1.4.1-2build1]
[08:18] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-elographics [source] (zesty-proposed) [1:1.4.1-1build6]
[08:19] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-joystick [source] (zesty-proposed) [1:1.6.3-1build1]
[08:19] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-mutouch [source] (zesty-proposed) [1:1.3.0-1build9]
[08:19] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-void [source] (zesty-proposed) [1:1.4.1-1build3]
[08:23] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-dummy [source] (zesty-proposed) [1:0.3.8-1build1]
[08:23] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-fbdev [source] (zesty-proposed) [1:0.4.4-1build6]
[08:24] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode [source] (zesty-proposed) [2.11.19-1build1]
[08:24] <Laney> aieeee
[08:25] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-mach64 [source] (zesty-proposed) [6.9.5-1build3]
[08:25] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-neomagic [source] (zesty-proposed) [1:1.2.9-1build3]
[08:26] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-openchrome [source] (zesty-proposed) [1:0.5.0-3build1]
[08:27] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-r128 [source] (zesty-proposed) [6.10.2-1build1]
[08:27] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-sisusb [source] (zesty-proposed) [1:0.9.7-1build1]
[08:29] <apw> Laney, ?
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-tdfx [source] (zesty-proposed) [1:1.4.7-1build1]
[08:29] <Laney> all the accepts :-)
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-trident [source] (zesty-proposed) [1:1.3.8-1build1]
[08:29] <apw> and all in your name :)
[08:30] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vesa [source] (zesty-proposed) [1:2.3.4-1build3]
[08:32] <Laney> ohohoho
[08:32]  * Laney 's shoulders slope
[08:33]  * apw adds a little gutter at the bottom of them and plumbs that into your trousers
[08:33] -queuebot:#ubuntu-release- Unapproved: accepted xf86-input-wacom [source] (zesty-proposed) [1:0.34.0-0ubuntu2]
[08:40] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-evdev [source] (zesty-proposed) [1:2.10.5-1ubuntu1]
[08:43] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput [source] (zesty-proposed) [0.25.0-0ubuntu1]
[08:46] -queuebot:#ubuntu-release- Unapproved: s390-tools (zesty-proposed/main) [1.37.0-0ubuntu2 => 1.37.0-0ubuntu3] (core)
[08:50] -queuebot:#ubuntu-release- Unapproved: storage-framework (zesty-proposed/universe) [0.2+17.04.20161212.1-0ubuntu1 => 0.3+17.04.20170320.1-0ubuntu1] (no packageset) (sync)
[08:51] -queuebot:#ubuntu-release- Unapproved: accepted storage-framework [sync] (zesty-proposed) [0.3+17.04.20170320.1-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics [source] (zesty-proposed) [1.9.0-1ubuntu1]
[09:05] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [source] (zesty-proposed) [1.3.0-0ubuntu1]
[09:09] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [source] (zesty-proposed) [1:7.9.0-0ubuntu1]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl [source] (zesty-proposed) [0.1.5-2build1]
[09:16] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-savage [source] (zesty-proposed) [1:2.3.9-1ubuntu1]
[09:19] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vmware [source] (zesty-proposed) [1:13.2.1-1build1]
[09:23] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [source] (zesty-proposed) [2:2.99.917+git20170309-0ubuntu1]
[09:25] -queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (zesty-proposed/main) [1.0.13+17.04.20170307-0ubuntu1 => 1.0.13+17.04.20170324-0ubuntu1] (ubuntu-desktop) (sync)
[09:26] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-siliconmotion [source] (zesty-proposed) [1:1.7.9-2ubuntu1]
[09:28] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau [source] (zesty-proposed) [1:1.0.14-0ubuntu1]
[09:48] -queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (zesty-proposed/main) [17.04.0-0ubuntu1 => 17.04.1-0ubuntu1] (ubuntu-desktop)
[09:53] <caribou> apw: or anybody in the release team who can help, is it possible to review nfs-utils which has been stucked in zesty-proposed for a while
[09:55] <Laney> caribou: It's not waiting for review, it's waiting for the failing tests to be sorted out
[09:58] -queuebot:#ubuntu-release- Unapproved: keyrings.alt (zesty-proposed/main) [1.3-1 => 2.2-1] (core) (sync)
[09:59] <caribou> Laney: which test is failing, I don't see anything in excuse
[09:59] <Laney> caribou: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nfs-utils ?
[10:02] <ginggs> would someone please configure kineticstools autopkgtests to run on large instances?  amd64 and ppc64el tests both fail with 'OSError: [Errno 12] Cannot allocate memory' now
[10:04] <Laney> why did that happen?
[10:06] <ginggs> new version, new tests.  It has only tried to run its tests now that i386 binaries were removed
[10:08] <Laney> ok, done
[10:08] <ginggs> Laney: ta!
[10:09] -queuebot:#ubuntu-release- Unapproved: diffoscope (zesty-proposed/universe) [80 => 81] (no packageset) (sync)
[10:10] <jibel> could someone review ubuntu-ui-extras/zesty, it's part of ubuntu-system-settings that landed yesterday?
[10:10] <apw> jibel, hey i did look at that, it seemed to haave a lot of stuff in it, is that expected
[10:11] -queuebot:#ubuntu-release- Unapproved: accepted diffoscope [sync] (zesty-proposed) [81]
[10:11] <jibel> apw, yes, it adds printing support to ubuntu-system-settings. This is this landing https://bileto.ubuntu.com/#/ticket/2605
[10:14] <jibel> apw, u-s-s, ubuntu-pinting-app and qtprint-ubuntu have been published to zesty, only u-ui-extras is missing
[10:15] -queuebot:#ubuntu-release- Unapproved: networking-l2gw (zesty-proposed/universe) [1:1.0.0+git20170315.37fe94-0ubuntu1 => 1:10.0.0-0ubuntu1] (no packageset) (sync)
[10:16] -queuebot:#ubuntu-release- Unapproved: vmware-nsx (zesty-proposed/universe) [9.0.0~git20160927.64c87d2-0ubuntu1 => 10.0.1~git20170317.bfa48c0-0ubuntu1] (no packageset) (sync)
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted networking-l2gw [sync] (zesty-proposed) [1:10.0.0-0ubuntu1]
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [sync] (zesty-proposed) [10.0.1~git20170317.bfa48c0-0ubuntu1]
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-extras [sync] (zesty-proposed) [0.3+17.04.20170323-0ubuntu1]
[10:20] <apw> ^ though it is unclear whether this needed an FFE as the other half has been release we are in a mess if we do not have these in sync and the non-FFE has already been blown
[10:20] <jibel> thanks
[10:24] <Laney> they do, and we should be more strict from now I think
[10:24] <Laney> at least I haven't heard about / been involved in discussions about any special exemptions this cycle
[10:27] <apw> Laney, indeed, not sure how we got here, but not getting here again sounds good
[10:27] <apw> Laney, there has been some discussion on unity8 session i think having one, but i am not convinced it came to concensus
[10:27] <Laney> mmm
[10:28] -queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.1 => 0.12.2] (no packageset)
[10:29] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.2]
[10:30] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (zesty-proposed) [122]
[10:39] -queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (zesty-proposed) [1.0.13+17.04.20170324-0ubuntu1]
[10:45] -queuebot:#ubuntu-release- Unapproved: accepted keyrings.alt [sync] (zesty-proposed) [2.2-1]
[10:45] <Laney> xnox: DEP3 :(
[10:48] <xnox> Laney, i have no origin.... i had to hand craft this from doing whitespace agnostic diff of tarballs.
[10:50] <Laney> Origin: some random tarball on a bug <url> would be better than nothing imho
[10:52]  * apw stands with Laney
[10:59]  * Laney eyes queue fetch
[10:59] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode (zesty-proposed/universe) [2.11.19-1build1 => 2.11.19-2] (xorg) (sync)
[10:59] <Laney> why are you suspiciously slow
[11:00] <apw> tjaalton, wtf ?  didn't i just review that build1 ?
[11:01] <tjaalton> apw: dunno, someone synced it?
[11:02] <apw> tjaalton, not you then ... hmmm
[11:02] <tjaalton> nope
[11:04]  * apw has a look at it ...
[11:05] <tjaalton> looks innocent enough
[11:06] <apw> tjaalton, yeah i see no reason to ding it, that same thing has happened to a lot of the otehrs in that set too
[11:07] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode [sync] (zesty-proposed) [2.11.19-2]
[11:07] <apw> tjaalton, ^ it is the same other than dbg package handling which matches many of the others
[11:07] <tjaalton> right
[11:34] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (zesty-proposed) [17.04.1-0ubuntu1]
[11:36] -queuebot:#ubuntu-release- Unapproved: accepted oxide-qt [sync] (zesty-proposed) [1.21.5-0ubuntu1]
[12:10] -queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.3 => 1.13.4-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server)
[12:14] -queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3ubuntu0.2 => 1.13.4-3ubuntu0.3] (kubuntu, ubuntu-desktop, ubuntu-server)
[12:21] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.4]
[12:31] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.3]
[12:36] -queuebot:#ubuntu-release- Unapproved: opentk (xenial-proposed/universe) [1.1.4c+dfsg-2 => 1.1.4c+dfsg-2ubuntu<IP_ADDRESS>] (no packageset)
[12:39] -queuebot:#ubuntu-release- Unapproved: opentk (yakkety-proposed/universe) [1.1.4c+dfsg-2 => 1.1.4c+dfsg-2ubuntu<IP_ADDRESS>] (no packageset)
[12:42] -queuebot:#ubuntu-release- Unapproved: activity-log-manager (xenial-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[12:42] -queuebot:#ubuntu-release- Unapproved: activity-log-manager (yakkety-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[12:42] -queuebot:#ubuntu-release- Unapproved: rejected activity-log-manager [source] (xenial-proposed) [0.9.7-0ubuntu23.1~xenial]
[12:43] -queuebot:#ubuntu-release- Unapproved: rejected activity-log-manager [source] (yakkety-proposed) [0.9.7-0ubuntu23.1~yakkety]
[12:44] -queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (yakkety-proposed) [0.9.7-0ubuntu<IP_ADDRESS>]
[12:46] -queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (xenial-proposed) [0.9.7-0ubuntu<IP_ADDRESS>]
[12:46] -queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (trusty-proposed) [0.9.7-0ubuntu14.2]
[12:50] -queuebot:#ubuntu-release- Unapproved: openssh (yakkety-proposed/main) [1:7.3p1-1 => 1:7.3p1-1ubuntu0.1] (core) (sync)
[12:51] -queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.1 => 1:7.2p2-4ubuntu2.2] (core) (sync)
[13:04] -queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (zesty-proposed/universe) [8.2-0ubuntu2 => 8.2.1-1ubuntu1] (ubuntugnome)
[13:17] -queuebot:#ubuntu-release- Unapproved: lernid (zesty-proposed/universe) [1.0.7 => 1.0.8] (no packageset)
[13:17] -queuebot:#ubuntu-release- Unapproved: accepted lernid [source] (zesty-proposed) [1.0.8]
[14:00] -queuebot:#ubuntu-release- Unapproved: multipath-tools (xenial-proposed/main) [0.5.0+git1.656f8865-5ubuntu2.4 => 0.5.0+git1.656f8865-5ubuntu2.5] (core)
[14:04] -queuebot:#ubuntu-release- Unapproved: virtualbox (zesty-proposed/multiverse) [5.1.18-dfsg-1 => 5.1.18-dfsg-1build1] (ubuntu-cloud)
[14:10] -queuebot:#ubuntu-release- Unapproved: multipath-tools (yakkety-proposed/main) [0.5.0+git1.656f8865-5ubuntu7.2 => 0.5.0+git1.656f8865-5ubuntu7.3] (core)
[14:12] <LocutusOfBorg> apw, ^^^ virtualbox :D
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (zesty-proposed) [5.1.18-dfsg-1build1]
[14:24] <LocutusOfBorg> ta
[14:27] <tjaalton> indeed
[14:57] -queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.0~beta3+bzr5815-0ubuntu1 => 2.2.0~beta4+bzr5856-0ubuntu1] (ubuntu-server)
[15:10] -queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5ubuntu<IP_ADDRESS> => 2.2.2-5ubuntu<IP_ADDRESS>] (mozilla, mythbuntu)
[15:13] -queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (xenial-proposed) [2.2.2-5ubuntu<IP_ADDRESS>]
[15:23] -queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5ubuntu<IP_ADDRESS> => 2.2.2-5ubuntu<IP_ADDRESS>] (mozilla, mythbuntu)
[15:23] -queuebot:#ubuntu-release- Unapproved: vlc (yakkety-proposed/universe) [2.2.4-4ubuntu<IP_ADDRESS> => 2.2.4-4ubuntu<IP_ADDRESS>] (mozilla, mythbuntu)
[15:32] <kenvandine> can someone please accept ubuntu-keyboard?
[15:42] <apw> kenvandine, that is pending (in my mind) on whether we have either an FFe or an outstanding exception as it has new functionality
[15:43] <kenvandine> apw, i'm guessing not, but not sure what the procedure is now for the phone stuff
[16:26] <tjaalton> I don't understand the onscripter/yorick test failures on new xorg-server, xvfb-run clearly works on other tests/archs and also locally..
[16:28]  * Laney runs
[16:31] <Laney> yep, fails the same
[16:31] <Laney> autopkgtest --shell-fail -U --apt-pocket=proposed=src:xorg-server onscripter  -- qemu autopkgtest-zesty-amd64.img
[16:31] <Laney> should be debuggable
[16:39] <tjaalton> and that's not just any qemu img?
[16:40] <Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[16:43] <tjaalton> okay
[16:44] <tjaalton> pretty sure i've been here before, but no idea where the images are :P
[16:45] <Laney> there's a command there that builds it
[16:45] <tjaalton> yes
[16:45] <tjaalton> and apparently puts it in $pwd
[16:46] <Laney> yap
[16:46] -queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu1 => 232-21ubuntu2] (core)
[16:48] -queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.2-1ubuntu1 => 17.0.2-1ubuntu2] (core, xorg)
[16:51] <tjaalton> the doc could probably use the current binary name (autopkgtest-buildvm-ubuntu-cloud)?
[16:51] <tjaalton> which has a manpage
[16:52] <tjaalton> oh it's not on the wiki
[16:52] <nacc> the old name is still an alias, iirc
[16:52] <tjaalton> a symlink yes
[16:52] <nacc> but yes, autopkgtest-*
[16:52] <tjaalton> but had no manpage
[16:52] <Laney> you mean https://bazaar.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk/revision/601 ?
[16:52] <nacc> also that page is probably old :)
[16:52] <nacc> heh
[16:52] <tjaalton> Laney: haha :)
[16:53] <nacc> it refers to bzr as being the way to get fixes in, e.g. (udd is still pretty widely documented last i checked)
[16:53] <Laney> that guide has big problems
[16:53] <Laney> the autopkgtest page is largely ok
[16:54] <nacc> Laney: true
[17:06] <tjaalton> oh well, onscripter test runs fine locally via xvfb or on qemu without xvfb
[17:10] <Laney> should be possible to find out what the difference is then
[17:10] <Laney> night!
[17:30] -queuebot:#ubuntu-release- Unapproved: dsdp (zesty-proposed/universe) [5.8-9.1ubuntu2 => 5.8-9.2] (no packageset) (sync)
[17:31] -queuebot:#ubuntu-release- Unapproved: accepted dsdp [sync] (zesty-proposed) [5.8-9.2]
[17:32] -queuebot:#ubuntu-release- Unapproved: dnsmasq (xenial-proposed/main) [2.75-1ubuntu<IP_ADDRESS> => 2.75-1ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop, ubuntu-server)
[17:39] -queuebot:#ubuntu-release- Unapproved: dnsmasq (yakkety-proposed/main) [2.76-4 => 2.76-4ubuntu0.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[17:40] <nacc> bah, can someone reject the yakkety upload? forgot to run update-maintainer!
[17:41] <tjaalton> tw, softhsm 2.2.0 breaks dns integration on freeipa, so could I revert to 2.1.0 for zesty?
[17:41] <tjaalton> *btw
[17:53] <tjaalton> and shouldn't be just freeipa https://github.com/opendnssec/SoftHSMv2/issues/298
[17:56] <nacc> rbasak: --^ can you reject dnsmasq from the  yakkety queue?
[18:14] <nacc> bdmurray: --^ or maybe better for your tz :)
[18:15] <bdmurray> nacc: got it
[18:15] <nacc> bdmurray: thanks
[18:16] -queuebot:#ubuntu-release- Unapproved: rejected dnsmasq [source] (yakkety-proposed) [2.76-4ubuntu0.1]
[18:26] -queuebot:#ubuntu-release- Unapproved: zfs-linux (zesty-proposed/main) [<IP_ADDRESS>-5ubuntu3 => <IP_ADDRESS>-5ubuntu4] (core)
[18:26] -queuebot:#ubuntu-release- Unapproved: dnsmasq (yakkety-proposed/main) [2.76-4 => 2.76-4ubuntu0.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[18:30] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.2-1ubuntu2]
[18:30] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (zesty-proposed) [<IP_ADDRESS>-5ubuntu4]
[18:30] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu2]
[18:31] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (zesty-proposed) [1.37.0-0ubuntu3]
[18:31] <infinity> jbicha: What do you have against history? ;)
[18:31] <infinity> jbicha: http://launchpadlibrarian.net/313174821/chrome-gnome-shell_8.2-0ubuntu2_8.2.1-1ubuntu1.diff.gz
[18:37] <nacc> heh
[19:03] -queuebot:#ubuntu-release- Unapproved: ldns (zesty-proposed/main) [1.7.0-1 => 1.7.0-1ubuntu1] (ubuntu-server)
[19:09] <jbicha> infinity: I can add the old changelog entriesback to that upload if you like, it was a bit more work since I was only applying the Ubuntu patch changes on top of Debian's
[19:18] <jbicha> infinity: could I interest you in reviewing switcheroo-control for zesty? LP: #1671828
[19:27] -queuebot:#ubuntu-release- Unapproved: lshw (zesty-proposed/main) [02.18-0.1ubuntu2 => 02.18-0.1ubuntu3] (core)
[19:41] <tjaalton> infinity: I can't figure out what's wrong with the remaining xserver autopkgtest failures, Xvfb didn't get any new commits in 1.19.x, and it works just fine when these are run manually, even on qemu
[19:42] <tjaalton> I _can_ modify xvfb-run so that it leaves the Xvfb behind, and then attaching the test to it fails the same way
[19:42] <tjaalton> but no idea why
[19:46] <tjaalton> though running any other X app on that same Xvfb again works fine
[19:47] <tjaalton> so it's some libsdl crap I guess
[19:58] -queuebot:#ubuntu-release- Unapproved: rejected aptdaemon [source] (yakkety-proposed) [1.1.1+bzr982-0ubuntu16.2]
[19:59] -queuebot:#ubuntu-release- Unapproved: aptdaemon (yakkety-proposed/main) [1.1.1+bzr982-0ubuntu16.1 => 1.1.1+bzr982-0ubuntu16.2] (kubuntu, ubuntu-desktop)
[20:54] -queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.8 => 1.157.9] (core, kernel)
[21:27] -queuebot:#ubuntu-release- Unapproved: gvfs (zesty-proposed/main) [1.30.3-1ubuntu1 => 1.30.4-0ubuntu1] (ubuntu-desktop)
[21:34] <bdmurray> stgraber: Do you know if you still have access to iso.qa.ubuntu.com or recall where sync-lp-bugs is running?
[21:47] <stgraber> bdmurray: I think I still do, it's on limequat
[21:48] <stgraber> bdmurray: and looks like you're in the right group too
[21:48] <bdmurray> I'll make a note this time then
[21:49] <stgraber> bdmurray: sync-lp-bugs runs as the "db" user on limequat, you should be able to sudo to that user
[21:55] <stgraber> bdmurray: just synced limequat's copy and the bzr branch, so if you need to do some changes, you can push them to the branch and pull on limequat
[21:56] -queuebot:#ubuntu-release- Unapproved: ginga (zesty-proposed/universe) [2.6.1-1 => 2.6.1-1ubuntu1] (no packageset)
[21:57] -queuebot:#ubuntu-release- Unapproved: accepted ginga [source] (zesty-proposed) [2.6.1-1ubuntu1]
[22:13] -queuebot:#ubuntu-release- Unapproved: pysurfer (zesty-proposed/universe) [0.7-2 => 0.7-2] (no packageset) (sync)
[22:14] -queuebot:#ubuntu-release- Unapproved: accepted pysurfer [sync] (zesty-proposed) [0.7-2]
[22:48] -queuebot:#ubuntu-release- Unapproved: mate-menu (zesty-proposed/universe) [17.04.2-0ubuntu2 => 17.04.3-0ubuntu1] (ubuntu-mate)
[22:50] -queuebot:#ubuntu-release- Unapproved: ubuntu-terminal-app (zesty-proposed/main) [0.7.218ubuntu2 => 0.7.218+17.04.20170328.3-0ubuntu1] (ubuntu-desktop) (sync)
[23:01] -queuebot:#ubuntu-release- Unapproved: cyrus-sasl2 (zesty-proposed/main) [2.1.27~101-g0780600+dfsg-2 => 2.1.27~101-g0780600+dfsg-2ubuntu1] (core)
[23:06] -queuebot:#ubuntu-release- Unapproved: rabbitmq-server (xenial-proposed/main) [3.5.7-1 => 3.5.7-1ubuntu<IP_ADDRESS>] (ubuntu-server)
[23:20] -queuebot:#ubuntu-release- Unapproved: rabbitmq-server (yakkety-proposed/main) [3.5.7-1 => 3.5.7-1ubuntu<IP_ADDRESS>] (ubuntu-server)
[23:26] -queuebot:#ubuntu-release- Unapproved: click-reviewers-tools (zesty-proposed/universe) [0.45 => 0.46] (no packageset)
[23:27] -queuebot:#ubuntu-release- Unapproved: accepted click-reviewers-tools [source] (zesty-proposed) [0.46]
[23:34] -queuebot:#ubuntu-release- Unapproved: bibcursed (zesty-proposed/universe) [2.0.0-6ubuntu3 => 2.0.0-6.1] (no packageset) (sync)
[23:34] -queuebot:#ubuntu-release- Unapproved: dsdp (zesty-proposed/universe) [5.8-9.2 => 5.8-9.4] (no packageset) (sync)
[23:34] -queuebot:#ubuntu-release- Unapproved: accepted bibcursed [sync] (zesty-proposed) [2.0.0-6.1]
[23:34] -queuebot:#ubuntu-release- Unapproved: accepted dsdp [sync] (zesty-proposed) [5.8-9.4]


[07:46] <aw-> hi, i'm wondering if there's any "dangers" of reading userdata directly from /var/lib/cloud/instance/user-data.txt - or is it safer to use "cloud-init query userdata" ? I ask because the cloud-init command is unbearably slow
[20:01] <meena> aw-: if it is unbearably, then we should find out why.
[20:03] <meena> i just saw goneri approved two of my patches, which i assume means he tested them… *nice*
[20:15]  * meena distinctly remembers turning on their laptop to do a thing, but not what thing.


[12:07] <dpm> hi fta, I've just had a call with Danilo. Here's an update re: Chromium translations -> he's on community rotation on the Launchpad team today. He'll be looking at the problem and will file a critical bug if he's got time. Otherwise he'll handle it to deryck (on CC on the last e-mail) to deal with. The reason it is like this is because Danilo is no longer working in translations due to the recent move in Launchpad from app-specific teams to featur
[12:07] <dpm> e-work-oriented squads, and deryck's team is working on a translations feature right now. I'm sorry it is being like this, but the process of changing the development process is going to be bumpy community-wise :/. It does not affect only Chromium, but the whole translations community
[13:10] <fta> dpm, ok, thanks. i'm chatting with danilos right now
[13:10] <dpm> fta, yeah, I've just seen that, cool
[14:13] <asac> chrisccoulson: two things ...
[14:13] <asac> do you need help on the po2xpi stuff (i hope not :(()
[14:13] <asac> that was 1.
[14:13] <asac> 2. the awesomebar is often hiding the location text field for me in ffox 4.0 + unity
[14:14] <asac> 2. is my current main annoyance
[14:14] <asac> oh and i have
[14:14] <chrisccoulson> asac - i should be ok with 1
[14:14] <chrisccoulson> 2 - i've not seen that before ;)
[14:14] <chrisccoulson> do you have any trigger for it, or is it random?
[14:14] <asac> 3. if i edit for a while in text fields like wiki, gmail etc. the text i type sometimes doesnt appear (only a few dots) ... until some kind of refresh displays it all
[14:15] <asac> chrisccoulson: i think the awesome drop down hiding things is a recent regression ... on dailies it happens like all the time since a few day
[14:15] <asac> before i never saw that (at least it never annoyed me)
[14:15] <asac> atm i basically cannot see what i type ;)
[14:15] <chrisccoulson> hmmm, i haven't seen that either, although jdstrand did open a bug about text input being really really slow
[14:15] <asac> its happening in fullscreen mode on my 12" screen (1024/768)
[14:15] <chrisccoulson> i need to update to the latest dailies really, once i've fixed them ;)
[14:16] <asac> heh
[14:16] <asac> i see it in _current_ dailies
[14:16] <asac> so let me know when there is new stuff so i can check if those issues are gone now
[14:16] <asac> :)
[14:16] <chrisccoulson> ok, i'll do that today
[14:26] <asac> chrisccoulson: http://people.linaro.org/~asac/tmp/Screenshot-Minefield.png
[14:26] <asac> chrisccoulson: so way to reproduce:
[14:26] <asac> 1. start typing something -> drop down is attached properly to the bottom
[14:26] <asac> 2. hit ESC so it goes away
[14:27] <asac> 3. continue typing -> drop down gets attached to the TOP of the bar like in screenshot
[14:27] <chrisccoulson> asac - ok, will try that in a bit
[14:29] <asac> seems that i often hit esc or something ;)
[14:29] <asac> i guess it can also be triggered in a different way
[15:49] <fta> grr, it's not longer possible to run wireshark as root
[15:49] <fta> -not+no
[15:56] <micahg> fta: well, you can either run with sudo or follow the instructions in the README to set up the groups properly
[15:59] <fta> rahh, just finished the dev and beta merges of chromium, 90 sec before the bot kicks in
[16:03] <fta> micahg, we don't even have that wireshark group :P
[16:04] <micahg> fta: it's not auto created AFAIK
[18:14] <micahg> chrisccoulson: should I hold off on publishing 4.0b10 to the PPA?
[18:14] <chrisccoulson> micahg - no, it's fine. the bug is in the official release builds anyway
[18:14] <chrisccoulson> well, i'd imagine it is, but i should check ;)
[18:15] <chrisccoulson> it's in natty anyway
[18:15] <micahg> chrisccoulson: well, I'm still on the daily from the 20th because of the FTBFS in the trunk branch, I guess I should fix that :-/
[18:16] <chrisccoulson> i was going to fix that today, but got sidetracked


 ok if I add a captcha bot to the support TG group?
 @Sick_Rimmit nice link in the article our daily ISOs. A bit sad that they are quite ***ed and unusable at the moment
[22:41] <mparillo> Shame the the ISOs are not ready. I just zsync'd HH for the first time.
[23:40] <valorie> they worked for a few days, but there are always these glitches


[09:50] <starrats> good morning
[10:19] <starrats> Ubuntu was giving me the same problem as Xubuntu was doing so, sorry folks I re-installed Xubuntu and i got help from a friend on another channel and fixed the bug that was in the kernel so it's probably a bug that's also in the ubuntu kernel.  If anyone wants to know i will tell you.
[11:46] <belkinsa> There was maybe two kernel updates since the release of Ubuntu.  Let me guess, is it the broken trackpad on laptops?
[12:45] <starrats> the touchpad and keyboard lovk=up/freeze upon start-up and reboots
[12:45] <starrats> lock=up
[12:45] <starrats> lock-up
[13:22] <starrats> I do have the line to put into grub to fix this problem/bug in the kernel.
[18:16] <jrgifford> starrats: ah, i've had that happen. was curious about what that was.
[18:27] <starrats> there's a 'bug in the kernel's grub line and it fixable by adding this after 'quiet splash' keeping the entire line as I show you in "...."
[18:29] <starrats> the line is this 'quiet splash i8042.numix=1 i8042.reset"  do this in gedit or whatever 'editor' you have and afterwards run this in term sudo update-grub
[18:30] <starrats> of course start with this in term, sorry:  sudo 'your editor' /boot/rub/menu.lst
[18:31] <starrats> that will take you to your editor and then find the line that ends with "quiet splash' and add that suffix to that line keeping all in "..."
[18:33] <starrats> sorry /boot/grub/menu.lst
[18:57] <starrats> jrgifford:  did you get my notes ^^^^^^^^^^
[22:11] <starrats> going to load up ubuntu on his VBox tonight
[23:32] <starrats> very quiet channel
[23:33] <Unit193> Yep.


[00:23] <mup> Bug #1589736 opened: BootstrapSuite.TestBootstrapPrintClouds unqeual fred and mary <blocker> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1589736>
[00:53] <mup> Bug #1589372 changed: state: state test failure during stress test <juju-core:New> <https://launchpad.net/bugs/1589372>
[01:02] <davecheney> that feel when cpu drops to 0% during tests and you know someone has used time.Sleep
[01:16] <davecheney> ?       github.com/juju/juju/state/statetest    [no test files]
[01:16] <davecheney> ok      github.com/juju/juju/state/storage      0.209s
[01:16] <davecheney> ?       github.com/juju/juju/state/testing      [no test files]
[01:16] <davecheney> why does the state set of package have _two_ testing helper packages ?!?!?
[01:16] <natefinch> davecheney: just in case?
[01:17] <davecheney> better add a third, that's the juju way
[01:17] <natefinch> davecheney: belt and suspenders
[01:18] <davecheney> and two pairs of underpants
[01:21] <wallyworld> anastasiamac: could you +1 this for me? http://reviews.vapour.ws/r/4995/
[01:23] <perrito666> thumper: hey, have a moment I think I migt be reading a test wrongly
[01:23] <perrito666> or the test migt be wrong
[01:23] <thumper> perrito666: my head is in the middle of something else just now
[01:23] <thumper> gimmie 15-20?
[01:23] <perrito666> sure
[01:23] <perrito666> ill ping back
[01:24] <wallyworld> perrito666: could you +1 the above trival pr while you are waiting?
[01:24] <perrito666> wallyworld: checking
[01:26] <anastasiamac> wallyworld: lgtm... maybe we should have a test for it tho \o/
[01:26] <wallyworld> thre is
[01:26] <wallyworld> a test
[01:26] <wallyworld> it failed
[01:26] <wallyworld> hence the fix
[01:26] <wallyworld> it failed sometimes
[01:26] <perrito666> wallyworld: how much of an ass am I being if I say that your for defines I before but it could get it from unpacking the slice
[01:27] <wallyworld> damn yeah, will fix that was left over from previous code
[01:27] <wallyworld> tnks
[01:27] <perrito666> lgtm for the rest
[01:44] <perrito666> thumper: ping?
[01:44] <thumper> perrito666: actually, this will take longer L(
[01:44] <thumper> :(
[01:44] <thumper> sorry
[01:44] <thumper> with natefinch on a hangout
[01:44] <perrito666> lol, no worries
[01:44] <thumper> bitching about networking
[01:44] <perrito666> uh, bitching, I wish I was invited to that
[01:44] <perrito666> I am a great complainer
[01:47] <mup> Bug #1589748 opened: commands should prompt you to "juju login" if your password has expired <juju-core:Triaged> <https://launchpad.net/bugs/1589748>
[02:27] <perrito666> mpf, is it possible that acl tests where broken?
[02:31]  * perrito666 does not want to be right about this
[02:36] <davecheney> thumper: still running stress tests of my patch
[02:36] <davecheney> i hope to submit it this afternoon
[03:17] <mup> Bug #1589774 opened: Ghost models exist after being destroyed <juju-core:New> <https://launchpad.net/bugs/1589774>
[03:31] <davecheney> thumper: dagnabit, i think there is still one test case left
[03:31] <davecheney> just had another "session closed" failure in myu stress tets
[03:37] <thumper> :(
[03:38] <thumper> anyone else having trouble with the charmstore?
[03:39] <natefinch> thumper: not I
[03:45] <anastasiamac> axw_: PR for no cotntroller/model on cli.. http://reviews.vapour.ws/r/4997/
[03:45] <axw_> anastasiamac: thanks, will take a look a bit later on
[03:46] <anastasiamac> axw_: no rush.. i will need to make sure that unit tests are aligned.. if there are any that are checking err cause and/or msgs
[04:17] <mup> Bug # changed: 1466629, 1496143, 1522090, 1531886, 1534804
[04:32] <natefinch> thumper: I'm off to bed.  Good luck with that bug.
[05:14] <davecheney> thumper: http://reviews.vapour.ws/r/4990/
[05:14] <davecheney> Patch set 4 should be the good one
[05:14] <davecheney> I've been stress testing it for an hour and I think I've found all the places we were leaking watchers
[05:38] <menn0> thumper: charm migration done: http://reviews.vapour.ws/r/4998/
[05:40] <redir> wallyworld: axw_ either of you around?
[05:40] <axw_> redir: yup
[05:40] <wallyworld> maybe :-)
[05:41] <redir> got a minute to look at something?
[05:41] <wallyworld> an offer i can't refuse
[05:41] <redir> tanzanite?
[05:42] <wallyworld> sure
[05:58] <redir> night
[05:58] <redir> and thanks wallyworld axw_
[05:58] <wallyworld> see you later alligator
[06:04] <davecheney> the state/presence tests run in 5 seconds in a variety of machines
[06:04] <davecheney> someone's put a sleep in there
[06:09] <wallyworld> axw_: once you land your current work, and i land the initial controller config branch, i have another ready to propose (after resolving any conflicts) which does the shared config thing from bootstrap. i also realised the current PR does correctly reject UpdateModelConfig attrs that are controller ones, so I'll remove that unnecessary TODO in this next branch
[06:10] <axw_> wallyworld: ok, but I'm not really comfortable with shared model config anymore. I think it may need more thorough design and discussion
[06:10] <axw_> (see my comments in review)
[06:11] <wallyworld> ok, looking
[06:12] <axw_> wallyworld: I'm not really convinced that it's that worthwhile either. how often will or should a controller admin be enforcing shared config for all models?
[06:12] <wallyworld> a lot in maas
[06:12] <wallyworld> apt mirror for example
[06:12] <wallyworld> mainly for private cloud case
[06:12] <wallyworld> or tools url etc
[06:13] <axw_> wallyworld: so then I think it might make more sense as cloud config, rather than controller-wide
[06:14] <axw_> wallyworld: tools url will be going away
[06:14] <axw_> wallyworld: either way, I think it needs  a bit more thought before we go changing something so fundamental
[06:15] <wallyworld> it can be made cloud specific fairly easily
[06:15] <wallyworld> either way, the PR to pull out controller config should be good
[06:15] <axw_> wallyworld: absolutely 100% agreed
[06:16] <axw_> wallyworld: just finishing up my branch now, it's going to be big...
[06:16] <wallyworld> tis ok
[06:16] <wallyworld> i got to do school pickup, bbiab
[06:52] <wallyworld> axw_: i think shared cloud (not controller) config is worth persuing. it will work now with one cloud per controller, and later too. it will be easy to add a global clouds collection and store the settings docs on that, keyed on cloud name. the vast majority of the other code in the branch remains the same. this then allows maas specific apt mirrors etc to be easily set up across hosted models, based on what's in clouds.yaml
[06:55] <axw_> wallyworld: sure, just so long as we can do it safely
[06:55] <axw_> wallyworld: and without confusing semantics around updating/removing config
[06:56] <wallyworld> axw_: yeah, i guess it depend on how confusing is defined. we can certainly warn if a user deletes a model attr that is also shared
[06:56] <wallyworld> and tell them that the shared value will now be is use
[07:00] <axw_> wallyworld: can you please write down what you think the end solution should look like, in terms of user commands, and we can discuss at the tech board again
[07:00] <axw_> I don't think we really covered the inheritance side of things well before
[07:00] <axw_> and it was just you me and william
[07:00] <wallyworld> ok. that bit doesn't necessarily need to land before beta9 as it won't affect upgradability
[07:01] <axw_> wallyworld: yep, +1
[07:01] <wallyworld> my focus today and tomorrow is very tightly focused on beta9 sadly
[07:01] <axw_> wallyworld: gotta go get charlotte in a moment, will then do a live test and propose my branch
[07:01] <wallyworld> ok, i'll look either before or after soccer
[07:01] <axw_> wallyworld: then there's a tonne of other stuff to do as follow ups :/
[07:02] <wallyworld> axw_: and my PR needs another look too when you get done proposing
[07:02] <wallyworld> yep
[07:02] <axw_> okey dokey
[07:02] <wallyworld> so long as what we land is upgradable
[07:04] <axw_> wallyworld: food for thought: I wonder if things like apt-mirror would be better suited as being cloud-specific, and you *cannot* set them at the model level
[07:04] <axw_> wallyworld: then there would be one place for each thing
[07:04] <wallyworld> axw_: maybe, but what if i wany *my* model to use something else
[07:05] <axw_> and I would be much happier at least ;p
[07:05] <axw_> wallyworld: why would you?
[07:05] <wallyworld> eg i set up my own mirror for testing or whatever
[07:05] <wallyworld> or to get my own packages
[07:05] <axw_> wallyworld: if it's just for testing, set up a test cloud?
[07:05] <axw_> (you're asking legitimate questions, I'm just wondering if we can/should go down that route)
[07:05] <wallyworld> that seems unwieldy just to use a different setting to one that's shared
[07:05] <axw_> eep, gtg
[07:05] <wallyworld> ttyl
[07:28] <axw_> wallyworld: it's a more work, yes, but I expect that's a very uncommon thing to do (setting apt-mirror on a per-model basis). if we have one and only one place for each config attribute, then we can have very clear semantics for updating/removing/etc.
[07:28] <axw_> wallyworld: BTW I think we want to add identity-url and identity-public-key to the controller-specific config?
[07:36] <wallyworld> axw_: we problaby should, i was just going by what was currenty ordained as controller specific, seems like those ones were missing
[07:38] <wallyworld> axw_: although, unless those are set at bootstrap, there would be no way of setting them after at the moment
[07:38] <axw_> do we error in validation?
[07:38] <wallyworld> i can ping uros about how he sets that stuff up
[07:38] <wallyworld> yes
[07:38] <wallyworld> if you try and set a controller attr via set-model-config it will error
[07:38] <axw_> wallyworld: ok. even still, I think we should add it to the list in case we need to change that behaviour
[07:39] <wallyworld> so if i add those, it just eans they need to be set at bootstrap and are then invariant
[07:39] <wallyworld> for now
[07:39] <axw_> wallyworld: that's the same as controller-uuid, ca-cert, etc.
[07:40] <wallyworld> yep
[07:40] <wallyworld> i just don't know the workflow for setting those
[07:40] <wallyworld> i'll check with uros
[07:40] <axw_> okey dokey
[07:40] <wallyworld> if they set them after bootstrap, then boom
[07:41] <wallyworld> i do disagree with you about the benefit of shared config, so we'll see what others think
[07:41] <axw_> wallyworld: sure, I've added my 2c to the thread
[07:43] <wallyworld> axw_: whether we go for inheritance or not, the bootstrap code in the wip branch will still work - we'd just count stuff in clouds.yaml as cloud config
[07:43] <wallyworld> all the serialisation etc is there now, and the backend storage
[07:44] <wallyworld> just need to remove the inheriance bit if that's what we decide
[07:44] <wallyworld> so i should be able to get all this landed tomorrow
[07:57] <mup> Bug #1589736 changed: BootstrapSuite.TestBootstrapPrintClouds unequal fred and mary <blocker> <ci> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1589736>
[08:02] <voidspace> hey all
[08:03] <frobware> dimitern: ping, 1:1?
[08:03] <dimitern> frobware: sorry, omw
[08:03] <dimitern> voidspace: o/
[08:03] <axw_> wallyworld: sorry for the delay, LGTM
[08:04] <wallyworld> axw_: nw, tyvm. am landing the feature branch before i head off to soccer
[08:04] <wallyworld> will have to jfdi it
[08:09] <axw_> wallyworld: finally, http://reviews.vapour.ws/r/5000/
[08:09] <axw_> as you'll see from the description, still lots TODO
[08:09] <wallyworld> axw_: ty, i'll have to look after soccer now
[08:09] <axw_> wallyworld: no worries
[08:10] <axw_> wallyworld: I'll be tackling the references next I think, to avoid upgrade steps
[08:10] <wallyworld> +1
[08:10] <axw_> and then removing cloud endpoints/creds/etc. from model config
[08:10] <axw_> probably after your branch lands
[08:51] <dimitern> dooferlad: ping
[08:51] <dooferlad> dimitern: hi
[08:51] <dimitern> dooferlad: so I tried testing my patch against LACP bonds on the NUCs ... and failed miserably
[08:52] <dimitern> dooferlad: morning :)
[08:52] <dooferlad> dimitern: I am not entirely surprised.
[08:52] <dimitern> dooferlad: can I ask you to try it on your hw setup?
[08:52] <dimitern> dooferlad: it's here http://reviews.vapour.ws/r/4959/
[08:53] <dooferlad> dimitern: sure, but can we discuss it with Andy and see how it meshes with our plan for the iproute2 / rebooting / ifupdown in the standup?
[08:54] <dimitern> dooferlad: sure, ok
[09:01] <dooferlad> dimitern: frobware voidspace hangout time!
[10:00] <mup> Bug #1589890 opened: juju2 azure fail with error 409 network conflict <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1589890>
[10:01] <hoenir> https://bugs.launchpad.net/juju-core/+bug/1588143
[10:01] <mup> Bug #1588143: cmd/juju/controller: send on a closed channel panic <blocker> <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1588143>
[10:07] <hoenir> it is because we have defer in a defer stmt?
[10:08] <hoenir> because defers saves the state of the program and it mangles up the program?
[10:09] <hoenir> who not delete the defer inside that defer and put the estate.mu.Unlock() before the <-OpDestroy{//code}
[10:09] <hoenir> ?
[10:09] <hoenir> why not*
[10:13] <hoenir> https://paste.ubuntu.com/17085985/
[10:14] <hoenir> so why not like this.. anyway one go rutine will access the channel because the estate.mu.Lock() and after unlock it.
[10:15] <hoenir> thoughts on this?
[10:15] <hoenir> anyone?
[10:16] <hoenir> and I'm reffering at this bug https://bugs.launchpad.net/juju-core/+bug/1588143
[10:16] <mup> Bug #1588143: cmd/juju/controller: send on a closed channel panic <blocker> <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1588143>
[11:31] <voidspace> back
[11:31] <voidspace> man a long wait at the hospital :-(
[11:33] <dimitern> voidspace: o/
[11:33] <voidspace> dimitern: hi
[11:33] <dimitern> voidspace: everything went ok?
[11:34] <voidspace> dimitern: yeah, routine tests for my wife - just checking something out
[11:34] <voidspace> dimitern: mostly her being paranoid I think
[11:34] <dimitern> voidspace: I see, ok
[11:35] <dimitern> voidspace: btw I'd appreciate a second review on http://reviews.vapour.ws/r/4959/
[11:41] <voidspace> dimitern: looking
[11:42] <dimitern> voidspace: ta!
[12:04] <anastasiamac> voidspace: wives are never paranoid \o/
[12:12] <voidspace> dimitern: why are you removing all the pre-up (etc) parts of /e/n/i ?
[12:12] <voidspace> dimitern: why were they needed and why are they no longer needed?
[12:13] <dimitern> voidspace: they aren't necessary anymore
[12:13] <voidspace> dimitern: why were they needed and why are they no longer needed?
[12:13] <voidspace> I'd like to understand if you don't mind
[12:14] <dimitern> voidspace: they were there to work around known issues when trying to ifup multiple static interfaces
[12:15] <voidspace> dimitern: and how do we work around it now?
[12:16] <mup> Bug #1589890 changed: juju2 azure fail with error 409 network conflict <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1589890>
[12:16] <dimitern> voidspace: well, we don't :) all my tests on trusty and xenial in the past weeks confirm the initial boot slowdown is gone with simple, statically configured interfaces
[12:16] <voidspace> dimitern: ok, have you talked it through with dooferlad?
[12:17] <voidspace> dimitern: he added that stuff IIRC
[12:20] <dimitern> voidspace: we did talk; but those the pre-up and etc. steps were my doing, which I'm glad to drop actually :)
[12:20] <voidspace> dimitern: ah right, ok - my mistake
[12:20] <voidspace> LGTM then
[12:20] <dimitern> voidspace: tyvm!
[12:25] <dimitern> dooferlad: any update on testing with bonds btw?
[13:03] <dooferlad> dimitern: was having lunch after my second stand up of the day. On it now.
[13:03] <dimitern> dooferlad: ok, np - just checking
[13:05] <dooferlad> dimitern: why bridge_maxwait 0?
[13:05] <dooferlad> surely we want the bridge to enter forwarding mode before we continue?
[13:06] <dimitern> dooferlad: that's the intent
[13:07] <dooferlad> dimitern: http://manpages.ubuntu.com/manpages/precise/man5/bridge-utils-interfaces.5.html says it won't wait for the bridge to enter forwarding mode
[13:07] <dimitern> dooferlad: otherwise maxwait is 32s by default (although in most of my tests it's a lot shorter in reality)
[13:07] <dooferlad> dimitern: yea, waiting is good.
[13:08] <dimitern> dooferlad: with multiple bridges it gets very slow very quickly
[13:08] <dooferlad> dimitern: if you want that change locally when you are iterating on something that is one thing, but landing it in production code seems wrong.
[13:09] <dimitern> dooferlad: how about a compromise?
[13:09] <dimitern> dooferlad: e.g. 5s
[13:10] <dooferlad> dimitern: I am not comfortable with that either. I assume that 32s was chosen for a reason. If we want to change it we need a better reason.
[13:10] <dimitern> dooferlad: I can compare the boot times with different values of maxwait, but not specifying it is bad pretty much every time you have >1 br
[13:11] <dooferlad> dimitern: why? Shouldn't the bridge come up and boot continue? It doesn't always wait 32s right?
[13:11] <dimitern> dooferlad: what's there to wait for? the port was up and running just before the script was run
[13:12] <dooferlad> dimitern: if that is the case, why does it not just continue anyway?
[13:12] <dimitern> dooferlad: it does come up, eventually, but with 7 VLANs => 7 bridges, it can take more than 75s for some bridges
[13:13] <dooferlad> dimitern: that really doesn't seem bad to me
[13:13] <dooferlad> dimitern: and, as I said, if we are going to change a default we need to justify it
[13:14] <dooferlad> dimitern: I would assume that the default is very widely tested and setting it to 0 isn't.
[13:15] <dimitern> dooferlad: ok, fair enough (will still test with the default maxwait to compare); not having addresses on both nics and bridges seems to be the most important part for reliability, along with stp
[13:15] <dooferlad> dimitern: Agreed. I just don't want any surprises :-|
[13:16] <dooferlad> dimitern: though I would love to have it as 0 if it didn't make any difference other than booting faster. Perhaps when we aren't trying to get a release out and we can throw some CI resources at it!
[13:17] <dimitern> dooferlad: +1
[13:21] <dooferlad> dimitern: so what do you want me to run as a test? Just see if a bonded interface still works on boot?
[13:21] <dooferlad> dimitern: then stick a lxc on a machine and check it works/
[13:21] <dooferlad> ?
[13:22] <dimitern> dooferlad: I'd suggest - bootstrap on bonded dual-nic with no vlans first
[13:23] <dimitern> dooferlad: then tear it down, add a couple of VLANs on the bond and bootstrap + add a couple of LXDs to machine 0 (switch controller first)
[13:23] <dimitern> dooferlad: and in both cases before tearing down, try rebooting and see if it still works
[13:24] <dimitern> if you can ssh into the node, you should be able to also ssh into the containers
[13:25] <dimitern> dooferlad: and I'd at least check 'ping google.com' and 'ip r' from inside the container
[13:25] <dimitern> that should cover most cases
[13:25] <dimitern> (common ones)
[13:27] <dooferlad> dimitern: about stp - it was disabled for security reasons according to http://manpages.ubuntu.com/manpages/xenial/man5/bridge-utils-interfaces.5.html so do we have a good reason for turning it on?
[13:27] <dooferlad> dimitern: is that another boot time thing?
[13:29] <dimitern> dooferlad: that sounds terribly handwavy
[13:29] <dimitern> dooferlad: what security concerns?
[13:30] <dooferlad> dimitern: that is what it said in the man page.
[13:30] <dooferlad> dimitern: I would like to know more too.
[13:30] <dimitern> dooferlad: yeah, so far I haven't seen references to such issues
[13:31] <dimitern> dooferlad: but I did notice improved UX and stability with STP on (I was having terrible broadcast storms with incorrectly configured switches)
[13:32] <dooferlad> dimitern: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge_stp
[13:32] <dooferlad> dimitern: looks like a win on trusted networks
[13:33] <dooferlad> dimitern: were you having any problems on correctly configured switches?
[13:33] <dimitern> dooferlad: I see, ok - makes sense and our networks are usually trusted
[13:34] <dimitern> dooferlad: nope
[13:34] <dimitern> dooferlad: it might be a problem with certain setups (on a shared substrate)
[13:34] <dimitern> (you know where..)
[13:34] <dooferlad> dimitern: so... is there any advantage really? I don't care about poorly configured networks. That is somebody else's problem.
[13:35] <dimitern> dooferlad: the issue is entirely not apparent when it happens
[13:36] <dimitern> dooferlad: i.e. you might have initial connectivity, which suddenly drops due to e.g. arping an unknown IP
[13:36] <dooferlad> dimitern: that isn't STP fixing your network - that is broken.
[13:36] <dimitern> dooferlad: it does fix it though
[13:36] <dooferlad> dimitern: and Juju deploys servers that are public, i.e. HTTP[S]
[13:36] <dimitern> dooferlad: by blocking the loops that otherwise happen
[13:37] <dooferlad> dimitern: I think it really should be something that users can turn on, but shouldn't be on by default.
[13:37] <dimitern> dooferlad: why?
[13:38] <dimitern> dooferlad: it affects MAAS setups a lot more than SDNy clouds
[13:38] <dooferlad> dimitern: turning it on turns on a security hole.
[13:38] <dooferlad> dimitern: see the linuxfoundation.org page
[13:39] <dooferlad> The Spanning Tree Protocol has no authentication; all participants are assumed to be trustworthy and correct. This assumption is not true if bridging between a hostile environment like the Internet and a private network. For this reason, STP is turned off by default on the recent versions of Linux.
[13:39] <dimitern> dooferlad: how does that apply here? we're not bridging hostile networks
[13:40] <dimitern> dooferlad: all of them are managed by maas
[13:40] <dooferlad> dimitern: a Juju deployed node could have a public interface
[13:40] <dimitern> dooferlad: on MAAS?
[13:40] <dooferlad> dimitern: why not?
[13:41] <dimitern> dooferlad: not the typical case
[13:41] <dooferlad> dimitern: a MAAS network could have some machines in a DMZ that are just open to the net. There is no reason why not.
[13:41] <dimitern> dooferlad: I'm not saying it's impossible, but your maas is likely firewalled deep inside your network
[13:42] <dooferlad> dimitern: I don't really care about typical for MAAS. I care about changing a default that is that way for a good reason. Doing something unexpected that can result in security problems is bad.
[13:44] <dooferlad> dimitern: I think it is perfectly reasonable to schedule work to turn STP on if a user asks for it. I think it being a space or subnet wide setting would be a good fit.
[13:45] <dimitern> dooferlad: pretty much every guide on networking I've read strongly recommends enabling STP especially in complex setups like with MAAS where it's quite easy to have multiple redundant links across
[13:45] <dooferlad> dimitern: fine, so lets do the right thing please? Not just turn it on everywhere and hope we haven't screwed someone.
[13:47] <dimitern> dooferlad: oh alright
[13:48] <dimitern> dooferlad: in the interest of getting something else done, sure
[14:13] <mup> Bug #1589890 opened: juju2 azure fail with error 409 network conflict <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1589890>
[14:47] <dimitern> dooferlad: any issues btw?
[14:48] <dooferlad> dimitern: sorry, I thought you were updating your patch.
[14:48] <dimitern> dooferlad: oh, sorry I wasn't sure it was needed for that test
[14:49] <dooferlad> dimitern: since all your bridge script changes are going away I don't think a bond will make any difference for what it's worth.
[14:49] <dimitern> dooferlad: but ok, will push an update dropping stp on and maxwait 0
[14:49] <dooferlad> dimitern: unless I missed something!
[14:49] <dimitern> dooferlad: no, not all
[14:49] <dimitern> dooferlad: only the extra bridge settings
[14:50] <dooferlad> dimitern: in that case I would get that change landed if it works for you. The bond won't make any difference.
[14:50] <dimitern> dooferlad: without testing it at least once?
[14:51] <dooferlad> dimitern: 'if it works for you' implied you could at least do a little test :-)
[14:52] <dimitern> dooferlad: well, not with bonds :)
[14:52] <dooferlad> dimitern: yea, it won't care
[14:52] <dooferlad> dimitern: it is a tube with bits going in and out of it :-)
[14:52] <dimitern> dooferlad: but otherwise I've done enough tests to be reasonably certain it works well
[14:53] <dooferlad> dimitern: in the container, why eth0 being special?
[14:53] <dimitern> dooferlad: the thing is, I didn't change how we bridge bond slaves (e.g. removing duplicated IPs from there and leaving the on the bridge)
[14:54] <dooferlad> dimitern: MAAS only gives an address to one interface IIRC
[14:54] <dooferlad> dimitern: from the containers POV (which this change is about) it is just a connection to a network.
[14:55] <dimitern> dooferlad: it's not special, just the first one is connected to the bridge which took over the NIC on the default route
[14:56] <dooferlad> dimitern: so eth0 is always connected to <dev?> that has the default route on it?
[14:56] <dimitern> dooferlad: true, having more than 1 gateway rendered in /e/n/i doesn't work
[14:57] <dooferlad> dimitern: I was more thinking about eth1 having the default route on the host.
[14:57] <frobware> dooferlad, dimitern: I just asked larry for more details regarding this ^^
[14:57] <dimitern> dooferlad: "eth0" can be connected to e.g. br-eth3 on the hosty
[14:58] <dimitern> dooferlad: the names don't have to match
[14:58] <frobware> dooferlad, dimitern: I wanted to clarify his setup so that we could reproduce and confirm the bug fixes that
[14:58] <dimitern> frobware: ok, it's good to know that
[14:58] <dooferlad> dimitern: I would be tempted to copy /etc/network/interfaces from the host to the guest and change IP and MAC addresses to match the container config. If guest-ethx is always connected to host-br-ethx that would work.
[14:59] <dimitern> frobware: have you tried rebooting a machine with deployed lxd containers?
[14:59] <frobware> dimitern: that sounds ominuous
[14:59] <dimitern> frobware: I've just discovered none of the lxds come up
[14:59] <frobware> oh la la
[14:59] <dimitern> frobware: they seem to be not set to auto-start on boot, as starting them manually otherwise works fine
[15:00] <frobware> dimitern: lxc config show <container> -- should show autostart state
[15:00]  * dooferlad goes to get a cup of tea and spend a few minutes not thinking about routes.
[15:01] <dimitern> frobware: it does say `user.boot.autostart: "true"`
[15:01] <dimitern> hmm.. looking at the logs
[15:03] <frobware> dimitern: what's the state of your patch w.r.t. backing out bridge script changes? I see stuff in there for the stp and explicitly matching "vlan_id"
[15:05] <babbageclunk> voidspace: ping?
[15:05] <voidspace> babbageclunk: pong
[15:06] <babbageclunk> voidspace: if a juju deploy failed because the image wasn't available in my maas, how can I ask it to try again now that the image is available?
[15:06] <dimitern> frobware: as discussed with dooferlad, I'm dropping the added stp on and maxwait 0 options
[15:06] <voidspace> babbageclunk: just try again with the deploy command?
[15:06] <babbageclunk> voidspace: I tried retry-provisioning, but it doesn't seem to have done anything.
[15:06] <voidspace> babbageclunk: I'm assuming you tried that and it didn't work
[15:07] <dimitern> frobware: and the 2 rm calls for eth0.cfg and 50-cloud-init..
[15:07] <voidspace> babbageclunk: destroy-service (or application) first?
[15:07] <babbageclunk> voidspace: ok, just destroy the applications and the deploy again?
[15:07] <dimitern> frobware: and I think we should land the rest
[15:07] <voidspace> babbageclunk: I would *expect* that to work
[15:08] <dimitern> frobware: `error: open /var/lib/lxd/containers: no such file or directory` << in /v/l/syslog on one of the hosts..
[15:09] <babbageclunk> voidspace: sweet, seems like it.
[15:16] <natefinch> alexisb: just verifying... is the lxc to lxd work higher priority than that ipaddress borked bug? https://bugs.launchpad.net/juju-core/+bug/1537585   Ian gave me the impression I should work on the lxc to lxd stuff instead of that bug.
[15:16] <mup> Bug #1537585: machine agent failed to register IP addresses, borks agent <2.0-count> <blocker> <cdo-qa-blocker> <landscape> <network> <juju-core:In Progress by natefinch> <juju-core 1.25:In Progress by natefinch> <https://launchpad.net/bugs/1537585>
[15:24] <dimitern> frobware: ping
[15:31] <mup> Bug #1590045 opened: Uniter could not recover from failed juju run <juju-core:New> <https://launchpad.net/bugs/1590045>
[15:37] <frobware> dimitern: pong
[15:37] <dimitern> frobware: I've updated the PR as agreed and set it to merge
[15:38] <dimitern> (it's not picked up yet for some reason though)
[15:39] <frobware> dimitern: oh. because I wanted to talk about matching on vlan_id
[15:39] <dimitern> frobware: there's no such setting 'vlan_id'
[15:39] <frobware> dimitern: so vlan_is no longer propgated to the bridge device, correct?
[15:40] <dimitern> frobware: see vlan-interfaces(5)
[15:40] <dimitern> frobware: correct - it should've been there to begin with
[15:40] <dimitern> frobware: only vlan-raw-device is needed
[15:40] <mup> Bug #1590045 changed: Uniter could not recover from failed juju run <juju-core:New> <https://launchpad.net/bugs/1590045>
[15:41] <frobware> dimitern: ok, makes sense.
[15:41] <frobware> dimitern: so, switching topics... LXD reboots...
[15:42] <dimitern> frobware: yeah
[15:42] <frobware> dimitern: let's HO - typing takes too logn
[15:43] <dimitern> frobware: ok
[15:44] <dimitern> frobware: I'm in our 1:1
[15:46] <voidspace> hah, starting 13 lxd instances is slowing my machine down a bit
[15:47] <alexisb> natefinch, sorry was otp and missed you ping
[15:52] <mup> Bug #1590045 opened: Uniter could not recover from failed juju run <juju-core:New> <https://launchpad.net/bugs/1590045>
[16:31] <mup> Bug #1590065 opened: container/lxd: One rename too far -> "application", "restart", "lxd-bridge" <blocker> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1590065>
[17:44] <redir> is txn.Op.ID mapped to a mongo collection _id?
[17:46] <redir> ericsnow natefinch katco ^
[17:47] <ericsnow> redir: it is always manually set, though always to the "_id" field :)
[17:47] <redir> sorry that should be txn.Op.Id
[17:48] <redir> mmm I guess I don't understand ModelUsers yet.
[17:48]  * redir reads more
[17:49] <redir> and tx ericsnow
[17:49] <ericsnow> redir: np
[18:08] <mup> Bug #1590095 opened: Model name validation error doesn't specify model name <juju-core:New> <https://launchpad.net/bugs/1590095>
[18:21] <cmars> now that service-to-application is landed, this unblocks a dependency update. can i get a review of http://reviews.vapour.ws/r/5001/ ?
[18:31] <redir> cmars: done, but you'll need someone else to bless.
[18:31] <cmars> redir, thanks
[18:35] <redir> heh
[18:36] <redir> is there a way to turn down logging on test failure? DEBUG=0 or -q or something?
[19:41] <mup> Bug #1590119 opened: add-credential for an openstack cloud asks for domain-name and bootstrap errors with unknown config field <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1590119>
[19:56] <thumper> natefinch: hey
[19:56] <natefinch> thumper: yo
[19:56] <thumper> natefinch: as you can see from the email, there is some screwyness going around with mgo
[19:56] <thumper> according to what I dumped out, the assertions are met
[19:56] <thumper> but they fail
[19:57] <thumper> I want to talk with menno about this when he gets on
[19:57] <natefinch> thumper: yep.... good luck... hope you can figure it out.
[19:57] <thumper> well, I hope menno can work it out, really I've got nothing
[19:58] <thumper> I think we are going to have to sprinkle mgo with extra logging...
[19:58] <natefinch> good times
[20:02] <alexisb> thumper just so you know I asked natefinch to stay focused on lxd updates
[20:02] <alexisb> given the state of that bug
[20:08] <mramm> thumper: sounds like a lot of fun ;)
[20:08] <thumper> alexisb: ok
[20:10] <mramm> cmars: you have a min to talk about using omnibus for metering instance usage data in openstack for China Mobile?
[20:10] <mramm> had a very quick chat with Carlos about metering in openstack/ceilometer and I think we have a better system....
[20:17] <mup> Bug #1590119 changed: add-credential for an openstack cloud asks for domain-name and bootstrap errors with unknown config field <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1590119>
[20:41] <mup> Bug #1590143 opened: deploying to cluster for vsphere as provider <oil> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1590143>
[20:57] <ericsnow> katco: multiple reviewers are required now, no?
[20:57] <katco> ericsnow: actually, i think that remained undetermined. alexisb, was a decision ever made?
[20:58] <alexisb> ericsnow, no not at this stage, we do have a review process update planned but it is not rolled out yet
[20:58] <ericsnow> alexisb: k
[21:14] <cmars> wallyworld, can i get a review of http://reviews.vapour.ws/r/5001/ ? post-renaming romulus update..
[21:26] <alexisb> thumper, do you have five minutes to catch up with me before the release call?
[21:26] <thumper> yep
[21:26] <alexisb> cmars, wallyworld is out for a bit
[21:26] <alexisb> thumper, can you join the release standup
[21:27] <cmars> alexisb, thanks. anyone available for a short review? http://reviews.vapour.ws/r/5001/
[21:41] <mup> Bug #1590161 opened: apiserver/client: panic: Session already closed <juju-core:New> <https://launchpad.net/bugs/1590161>
[21:58] <wallyworld> cmars: lgtm, tv
[21:58] <wallyworld> ty
[22:25] <wallyworld> katco: ericsnow: did you have a few minutes to chat about dtag?
[22:25] <ericsnow> wallyworld: sure
[22:25] <wallyworld> https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
[22:29] <mup> Bug #1590172 opened: ERROR cmd supercommand.go:448 autorest:WithErrorUnlessStatusCode POST https://login.microsoftonline.com/fb30bf07-xxxx-xxxx-xxxx-02ef08680fb9/oauth2/token?api-version=1.0 fa iled with 400 Bad Request <juju-core:New> <https://launchpad.net/bugs/1590172>
[22:30] <katco> wallyworld: sorry just saw this. sure
[22:30] <redir> where does juju log?
[22:31] <redir> ~/.local/share?
[22:31] <redir> duh, nm
[22:55] <bogdanteleaga> what's the best supported maas on master?
[22:56] <anastasiamac> bogdanteleaga: both maas 2 and 1,9 should work... prefereance is most likely 2 \o/
[22:56] <bogdanteleaga> anastasiamac, cheers
[23:46] <wallyworld> thumper: did you have 5 minutes for a question?
[23:46] <wallyworld> or 2 minutes
[23:46] <thumper> not just now
[23:46] <thumper> otp with menn0
[23:46] <wallyworld> ok
[23:46] <thumper> dealing with this shitty mgo issue
[23:46] <wallyworld> yay, ping when free
[23:46] <wallyworld> should be quick
[23:52] <perrito666> wallyworld: dont forget about me after redir :)
[23:52] <wallyworld> i won't