[01:49] <Trevinho> jbicha: I can't now, but feel free. I am also still wondering if being recommended would be enough for being picked for the other packages though
[03:23] <callmepk> good morning
[03:27] <jbicha> Trevinho: I believe it needs those depends for the scour feature to work automatically. The builders do not install recommends by default. Could you push your changes to the git branch when you can?
[05:11] <duflu> Hi callmepk and jbicha
[05:11]  * duflu assumes Trevinho has finally gone to bed
[05:14] <callmepk> hi duflu
[06:31] <oSoMoN> good morning desktoppers
[06:37] <duflu> Hi oSoMoN
[06:38] <callmepk> hi oSoMoN
[06:44] <oSoMoN> hey duflu, callmepk
[07:07] <didrocks> good morning
[07:12] <callmepk> hi didrocks
[07:12] <didrocks> hey callmepk
[07:13] <duflu> Hi didrocks
[07:16] <didrocks> hey duflu
[07:21] <seb128> goood morning desktopers
[07:24] <duflu> Morning seb128
[07:24] <didrocks> salut seb128
[07:37] <oSoMoN> salut didrocks, seb128
[07:38] <didrocks> salut oSoMoN
[08:02] <seb128> hey duflu, lut oSoMoN and didrocks, how are you?
[08:06] <jibel> Good morning all
[08:07] <didrocks> ça va, et toi seb128 ?
[08:07] <didrocks> salut jibel
[08:07] <jibel> salut didrocks
[08:09] <duflu> seb128, going well. You?
[08:13] <oSoMoN> seb128, feeling slightly better than yesterday, perhaps I won't fall to that cold after all
[08:19] <seb128> oSoMoN, great!
[08:19] <seb128> lut jibel
[08:19] <seb128> didrocks, ca va :)
[08:19] <seb128> duflu, I had a proper uninterrupted night of sleep which is an improvement ;-)
[08:24] <oSoMoN> \o/
[08:52] <jibel> salut seb128
[08:52] <seb128> jamesh, hey, do you know if orca not working with snaps is known?  I was checking bug #1948954 but it seems other snaps have the same issue
[08:59] <jamesh> seb128: yeah. This is down to a change in at-spi2 changing the a11y D-Bus address
[08:59] <seb128> sounds like flatpak fixed in with https://github.com/flatpak/flatpak/commit/de4b6840
[09:00] <seb128> jamesh, is there a bug report or discussion about that ?
[09:02] <jamesh> I don't think we have a bug about it. The change that broke things is https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/51, which says it was designed to intentionally block access to confined apps
[09:05] <jamesh> It's non-trivial to fix this for snaps, since (a) it's using a random file name not unique to at-spi, and (b) the path is under /tmp, which is inaccessible to snaps
[09:10] <jamesh> This change is a lot more recent than that Flatpak change
[09:11] <seb128> jamesh, right, the commit I was refearing to was to give dbus access to atspi
[09:12] <seb128> but they have a dbus proxy for a11y  and they use AT_SPI_BUS_ADDRESS
[09:12] <jamesh> seb128: the  desktop-legacy snapd interface does give access to at-spi's dbus-daemon with the old socket address
[09:12] <seb128> jamesh, I think that's something we need to find a way to address this cycle, could you maybe start a post on the snapcraft forum?
[09:13] <jamesh> sure.
[09:13] <seb128> thanks
[09:13] <seb128> so basically it's an issue on recent distro series only right?
[09:13] <jamesh> yes
[09:13] <seb128> well, that's something
[09:13] <seb128> but we need to fix it for the LTS
[09:14] <seb128> I will add a card on the backlog once you open the forum post
[09:14] <jamesh> I think the solution is going to require some changes on the at-spi side too. I don't think a snapd only solution is going to be possible
[09:15] <seb128> we could revert the at-spi change to lower the issue for Ubuntu users, but that's not a portable solution
[09:15] <oSoMoN> thanks seb128 and jamesh, I'll keep an eye on it and happy to help with implementation/testing
[09:18] <seb128> jamesh, what do you think would be needed on the at-spi side? do you think moving it out from /tmp to another location, maybe /run would be enough?
[09:18] <seb128> if it was a subdir there we could grant access to that one for snaps right?
[09:19] <jamesh> seb128: putting it in XDG_RUNTIME_DIR (maybe even with a fixed path) would be easy to support
[09:19] <jamesh> at the moment, the socket is just named like /tmp/dbus-*
[09:20] <seb128> that sounds like it would be a reasonable change to propose upstream right?
[09:20] <jamesh> yes
[09:21] <didrocks> seb128: mind subscribing desktop-packages to https://launchpad.net/ubuntu/+source/wsl-setup?
[09:21] <seb128> jamesh, do you want to start that discussion with upstream maybe? the sooner the better probably. If you are busy I'm happy to put that on my backlog
[09:22] <seb128> didrocks, subscribed
[09:22] <jamesh> seb128: I'll file a bug
[09:22] <didrocks> seb128: thanks!
[09:22] <seb128> jamesh, thanks!
[09:23] <seb128> didrocks, np! :)
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125517 (build) stage: build, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125516 (extract-source) stage: provisioning, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125518 (build i386) stage: build, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125520 (test-build-any) stage: test, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125519 (build source) stage: build, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125521 (test-build-all) stage: test, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125522 (test-crossbuild-arm64) stage: test, status: created
[09:50] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125523 (reprotest) stage: test, status: created
[09:50] <KGB-1> gnome-shell-extension-caffeine pipeline Simon McVittie 307947 * pending (build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; extract-source: pending)
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125524 (lintian) stage: test, status: created
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125525 (autopkgtest) stage: test, status: created
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125526 (blhc) stage: test, status: created
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125527 (piuparts) stage: test, status: created
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125516 (extract-source) stage: provisioning, status: running. Duration: no time
[09:51] <KGB-1> gnome-shell-extension-caffeine pipeline Simon McVittie 307947 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[09:51] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125528 (extract-source) stage: provisioning, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125529 (build) stage: build, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125530 (build i386) stage: build, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125531 (build source) stage: build, status: created
[09:52] <KGB-1> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 307948 * pending (build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; extract-source: pending; build: created)
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125532 (test-build-any) stage: test, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125534 (test-crossbuild-arm64) stage: test, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125533 (test-build-all) stage: test, status: created
[09:52] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125535 (reprotest) stage: test, status: created
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125536 (lintian) stage: test, status: created
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125537 (autopkgtest) stage: test, status: created
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125538 (blhc) stage: test, status: created
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125539 (piuparts) stage: test, status: created
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125528 (extract-source) stage: provisioning, status: running. Duration: no time
[09:53] <KGB-1> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 307948 * running (extract-source: running; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; build: created)
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125516 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 33 seconds
[09:53] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125517 (build) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125518 (build i386) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125519 (build source) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125528 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 41 seconds
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125529 (build) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125530 (build i386) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125531 (build source) stage: build, status: running. Duration: no time
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125518 (build i386) stage: build, status: success. Duration: 2 minutes and 22 seconds
[09:54] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125519 (build source) stage: build, status: success. Duration: 2 minutes and 25 seconds
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125517 (build) stage: build, status: success. Duration: 2 minutes and 31 seconds
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125520 (test-build-any) stage: test, status: running. Duration: no time
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125521 (test-build-all) stage: test, status: running. Duration: no time
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125522 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125523 (reprotest) stage: test, status: running. Duration: no time
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125524 (lintian) stage: test, status: running. Duration: no time
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125531 (build source) stage: build, status: success. Duration: 2 minutes and 30 seconds
[09:55] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125529 (build) stage: build, status: success. Duration: 2 minutes and 30 seconds
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125535 (reprotest) stage: test, status: running. Duration: no time
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125530 (build i386) stage: build, status: success. Duration: 2 minutes and 35 seconds
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125520 (test-build-any) stage: test, status: success. Duration: 1 minute and 15 seconds
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125532 (test-build-any) stage: test, status: running. Duration: no time
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125533 (test-build-all) stage: test, status: running. Duration: no time
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125522 (test-crossbuild-arm64) stage: test, status: success. Duration: 1 minute and 20 seconds
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125525 (autopkgtest) stage: test, status: running. Duration: no time
[09:56] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125534 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125526 (blhc) stage: test, status: running. Duration: 2 seconds
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125536 (lintian) stage: test, status: running. Duration: no time
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125527 (piuparts) stage: test, status: running. Duration: no time
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125523 (reprotest) stage: test, status: success. Duration: 2 minutes and 19 seconds
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125537 (autopkgtest) stage: test, status: running. Duration: no time
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125521 (test-build-all) stage: test, status: success. Duration: 2 minutes and 28 seconds
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125532 (test-build-any) stage: test, status: success. Duration: 1 minute and 14 seconds
[09:57] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125538 (blhc) stage: test, status: running. Duration: no time
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125539 (piuparts) stage: test, status: running. Duration: no time
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125524 (lintian) stage: test, status: success. Duration: 1 minute and 46 seconds
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125534 (test-crossbuild-arm64) stage: test, status: success. Duration: 1 minute and 16 seconds
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125526 (blhc) stage: test, status: success. Duration: 1 minute and 16 seconds
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125536 (lintian) stage: test, status: success. Duration: 1 minute and 45 seconds
[09:58] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125535 (reprotest) stage: test, status: success. Duration: 2 minutes and 24 seconds
[09:59] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125538 (blhc) stage: test, status: success. Duration: 1 minute and 13 seconds
[09:59] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125533 (test-build-all) stage: test, status: success. Duration: 2 minutes and 28 seconds
[09:59] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125525 (autopkgtest) stage: test, status: success. Duration: 3 minutes and 11 seconds
[10:00] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125537 (autopkgtest) stage: test, status: success. Duration: 3 minutes and 29 seconds
[10:01] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2125527 (piuparts) stage: test, status: success. Duration: 4 minutes and 34 seconds
[10:02] <KGB-1> gnome-shell-extension-caffeine pipeline Simon McVittie 307947 * [10 minutes and 38 seconds] success (piuparts: success; autopkgtest: success; blhc: success; lintian: success; test-build-all: success; reprotest: success; test-crossbuild-arm64: success; test-build-any: success; build: success; build source: success; build i386: success; extract-source: success
[10:02] <KGB-1> shell-extensions)
[10:02] <KGB-1> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 307948 * [10 minutes and 30 seconds] success (piuparts: success; autopkgtest: success; test-build-all: success; blhc: success; reprotest: success; lintian: success; test-crossbuild-arm64: success; test-build-any: success; build i386: success; build source: success; build: success; extract-source: s
[10:02] <KGB-1> shell-extensionsuccess)
[10:02] <KGB-1> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2125539 (piuparts) stage: test, status: success. Duration: 4 minutes and 54 seconds
[10:08] <ack> hi, how can I debug bluetooth issueS? after moving to impish, my headset doesn't connect automatically anymore when I turn it on. it briefly shows as connected and then disconnects
[10:09] <ack> only message I get in bluetoothd logs is this: Oct 28 11:36:48 arrakis bluetoothd[1106]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
[11:17] <Fatal_Sushi> ack: support is in #ubuntu
[11:24] <ack> Fatal_Sushi, thanks
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126611 (build) stage: build, status: created
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126610 (extract-source) stage: provisioning, status: created
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126612 (build i386) stage: build, status: created
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126613 (build source) stage: build, status: created
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126614 (test-build-any) stage: test, status: created
[16:25] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126615 (test-build-all) stage: test, status: created
[16:26] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126616 (test-crossbuild-arm64) stage: test, status: created
[16:26] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126617 (reprotest) stage: test, status: created
[16:26] <KGB-0> mallard-ducktype pipeline Simon McVittie 308081 * pending (build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; extract-source: pending)
[16:26] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126618 (lintian) stage: test, status: created
[16:26] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126619 (autopkgtest) stage: test, status: created
[16:26] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126620 (blhc) stage: test, status: created
[16:27] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126621 (piuparts) stage: test, status: created
[16:27] <mdeslaur> when is desktop switching to subiquity, and is there autoinstall doumentation for desktop somewhere?
[16:27] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126610 (extract-source) stage: provisioning, status: running. Duration: no time
[16:27] <KGB-0> mallard-ducktype pipeline Simon McVittie 308081 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[16:27] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126610 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 30 seconds
[16:27] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126611 (build) stage: build, status: running. Duration: no time
[16:28] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126612 (build i386) stage: build, status: running. Duration: no time
[16:28] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126613 (build source) stage: build, status: running. Duration: no time
[16:28] <mdeslaur> ah, nm, https://discourse.ubuntu.com/t/new-desktop-installer-preview-build/24765/13
[16:29] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126613 (build source) stage: build, status: success. Duration: 2 minutes and 34 seconds
[16:29] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126612 (build i386) stage: build, status: success. Duration: 2 minutes and 39 seconds
[16:29] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126611 (build) stage: build, status: success. Duration: 2 minutes and 48 seconds
[16:29] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126614 (test-build-any) stage: test, status: running. Duration: no time
[16:29] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126615 (test-build-all) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126616 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126617 (reprotest) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126618 (lintian) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126619 (autopkgtest) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126620 (blhc) stage: test, status: running. Duration: no time
[16:30] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126621 (piuparts) stage: test, status: running. Duration: no time
[16:31] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126614 (test-build-any) stage: test, status: success. Duration: 1 minute and 16 seconds
[16:31] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126620 (blhc) stage: test, status: success. Duration: 1 minute and 16 seconds
[16:31] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126616 (test-crossbuild-arm64) stage: test, status: success. Duration: 1 minute and 18 seconds
[16:31] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126618 (lintian) stage: test, status: success. Duration: 1 minute and 54 seconds
[16:32] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126615 (test-build-all) stage: test, status: success. Duration: 2 minutes and 45 seconds
[16:32] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126617 (reprotest) stage: test, status: success. Duration: 2 minutes and 57 seconds
[16:34] <KGB-0> GNOME / mallard-ducktype builds Simon McVittie * Build #2126621 (piuparts) stage: test, status: success. Duration: 3 minutes and 33 seconds


[02:49] <Terces> hi there
[02:50] <Terces> apparently unity interferes with XBMC, but I couldn't find any real information about this on the internet
[02:50] <Terces> I also didn't find any solution (making it not fullscreen but windowed helped a lot though)
[02:51] <Terces> apparently you could set in compiz the setting to "un-redirect fullscreen", which seems to have helped people
[10:39] <Terces> hi everyone
[10:42] <Terces> after a long night of looking, I found out that the window manager really is messing up with xbmc. I could not find a solution to this. I think the problems arise from Unity trying to "do its thing" on full-screen applications..
[10:45] <Terces> any help to resolve this would be great appreciated


[01:29] <macer1> Hello
[01:29] <macer1> I found annoying think on Launchpad
[01:30] <macer1> when apport is collecting bugs to bug that I am subscribed to, it spams me with 30 mails, it should all be send in one
[01:30] <macer1> *thing
[07:53] <micahg> is there a reason why I can't sync wireshark from Debian unstable yet?  It was uploaded a day and a half ago
[07:53] <micahg> it's not showing up in LP under Debian
[08:02] <mrevell> Hello.
[08:05] <wgrant> micahg: Our debian imports are a little behind at the moment -- the migration to set things to superseded/deleted as appropriate is slowing things down.
[08:05] <micahg> wgrant: ah, ok, when do you estimate catching up?
[08:06] <wgrant> micahg: That's difficult to say. sid might not happen for 24 to 36 hours. We'll hopefully have a proper fix early next week, which means it should happen just an hour or so after Debian publishes it.
[08:06] <wgrant> micahg: If it's urgent, you can probably convince someone to use sync-source.py...
[08:07] <micahg> wgrant: right, ok, not so urgent I guess, will try again on Sunday, thanks
[08:15] <ScottSanbar> I have posted a forum post about what I belive are some non-ideal behaviours in launchpad.  If anyone has coments, I would like to here them:  https://answers.launchpad.net/launchpad/+question/172028
[08:17] <wgrant> ScottSanbar: Launchpad can't really automatically do that. How do you normally generate those files?
[08:17] <wgrant> Often there's an autogen.sh in the branch that debian/rules can call to produce configure etc.
[08:20] <ScottSanbar> wgrant: autoconf, then debuild
[08:21] <wgrant> ScottSanbar: You can't do that in debian/rules?
[08:21] <ScottSanbar> wgrant:  If I have an autogen.sh, could the recipe use that to build the autogenerated files?
[08:21] <wgrant> This is completely autoconf/automake-specific, so LP can't exactly do it automatically.
[08:22] <wgrant> Those files shouldn't necessarily be in the source tarball. So you can just fix your debian/rules to generate them first.
[08:22] <wgrant> It's not recipe-specific.
[08:22] <ScottSanbar> wgrant:  I am just learning, and have not gotten to the place in the tutorials that tells about writing stuff in the rules file.  I just do them manually at the moment.
[08:24] <wgrant> You might want to look at dh-autoreconf
[08:25] <ScottSanbar> wgrant: so even if I include all the neccessary stuff in rules to "autogen" or whatever you want to call it the build environment from the .am and .ac files, etc. the recipe still needs some of the autogenerated files uploaded?
[08:26] <wgrant> ScottSanbar: No. Launchpad will build the recipe into a source package that doesn't contain the autogenerated files. Then, when Launchpad builds that source package into binaries with dpkg-buildpackage, your debian/rules file will tell dpkg-buildpackage to generate those files.
[08:28] <ScottSanbar> wgrant:  OK, so then as long as my rules file contains the necessary steps to generate the build system from the .am and .ac, etc. files, it should all work - e.g., dh --with autoreconf $@ (in the rules file)
[08:29] <wgrant> ScottSanbar: I think that will probably work, yes.
[08:29] <wgrant> Launchpad is about to go down for a couple of minutes of database maintenance.
[08:31] <ScottSanbar> wgrant:  Thanks!  That is such a simple change to make, and then I can have a clean bazaar repo with only source files and no need for any auto-generated files.  What about install-sh, debcomp and missing?  Is there a command to tell it to do the autoreconf --install, like dh --with autoreconf --install $@ ?
[08:31] <wgrant> ScottSanbar: --with autoreconf might do that itself. I'm not sure how it works these days.
[08:31] <RAOF> They should be a part of the autoconfing
[08:32] <ScottSanbar> wgrant:  Ok, thanks - you have been most helpful, wgrant and RAOF.  I am very excited to give it a try!
[08:32] <wgrant> And Launchpad is back.
[08:32] <ScottSanbar> Here goes ... :)
[09:13] <fagan> mrevell: hey, what time does flacoste get in at?
[09:14] <mrevell> Hey fagan, 14.00 our time.
[09:16] <fagan> mrevell: cool ill read the books I just got in the meantime. I just got the definitive guide to javascript and a nice one about developing websites with dynamic interfaces so both interesting :)
[09:17] <mrevell> Cool :)
[09:19] <ScottSanbar> wgrant:  Ok, just tried it.  I deleted all my files except my source files for both the build system and c++ on my PC, and then all I had to do was run debuild and it did EVERYTHING!!! Cool.
[09:20] <wgrant> ScottSanbar: That's excellent. Hopefully the recipe will work fine :)
[09:22] <ScottSanbar> wgrant:  However, I ran into a glitch and had to install the dh-autoreconf package, then everything worked hunky-dorey.
[09:22] <wgrant> ScottSanbar: Make sure you add that to Build-Depends in your debian/control.
[09:22] <wgrant> Otherwise the Launchpad builders won't have it installed.
[09:23] <ScottSanbar> wgrant:  Yah, that is what I was going to say - launchpad failed on that not being installed.  Do you have the syntax handy, othewise I can look it up ...
[09:24] <wgrant> ScottSanbar: You'll see a Build-Depends line in debian/control in your branch. Just add ", dh-autoreconf" to the end of it.
[09:26] <soren> On http://launchpad.net/nova, what is shows as the latest download is not actually the latest download. Is this a bug or a misconfiguration issue on our part?
[09:28] <ScottSanbar> Thanks, I had already figured it out from the Debian control file policy document.  You are really being helpful!  Thanks!  Here I go again ...
[09:40] <wgrant> soren: That's certainly a creative interpretation of "Latest version". Let me try to work out what's going on.
[09:41] <soren> wgrant: Lovely, thank you!
[09:47] <ScottSanbar> wgrant:  Here is my depend line in control:
[09:47] <ScottSanbar> Depends: ${shlibs:Depends}, ${misc:Depends}, dh-autoreconf
[09:48] <ScottSanbar> wgrant: However, it still fails to find dh-autoreconf in the recipe build.
[09:49] <ScottSanbar> h: unable to load addon autoreconf: Can't locate Debian/Debhelper/Sequence/autoreconf.pm ... etc, etc. etc.
[09:49] <wgrant> ScottSanbar: Ah, it needs to go in Build-Depends.
[09:49] <wgrant> Depends is put into the built package.
[09:49] <wgrant> The contents of Build-Depends is installed during building of the packaging.
[09:51] <ScottSanbar> wgrant:  I have no Build-Depends file, never have (used dh_make, etc - don't think I ever saw it)
[09:51] <wgrant> ScottSanbar: It should be in the first stanza in debian/control.
[09:51] <wgrant> It's there in the branch you linked to in the question.
[09:52] <ScottSanbar> wgrant:  Ok, now I feel totally stupid - however, I will note that I am eyesight challenged, so somethimes things like this get me ... :)
[09:53] <wgrant> Heh.
[09:53] <wgrant> Hopefully this will fix it.
[09:59] <wgrant> soren: Ah, our series sorting algorithm is somewhat odd.
[09:59] <wgrant> soren: It doesn't handle alphabetical names properly.
[09:59] <wgrant> soren: It will sort them in the opposite order.
[10:00] <wgrant> So cactus sorts before diablo, so its release wins :/
[10:00] <ScottSanbar> wgrant: thanks, building now - I have high hopes ... :/
[10:01] <ScottSanbar> wgrant: I am still doing my make -distcheck manually to create the .orig.tar.gz file.  Can I put that in debian/rules as well?
[10:01] <ScottSanbar> wgrant:  then my world would be complete ... :D
[10:02] <wgrant> ScottSanbar: I believe recipes still only build native packages right now, which means there's no orig.tar.gz.
[10:02] <ScottSanbar> wgrant:  This current build is quilt, but has no patches because I am upstream, I think I am saying that right ...
[10:03] <ScottSanbar> wgrant:  Does recipe change it to native?
[10:03] <wgrant> ScottSanbar: I believe it will be automatically converted to 3.0 (native).
[10:03] <wgrant> dh-autoreconf is installed!
[10:03] <wgrant> Let's see if it builds.
[10:03] <ScottSanbar> wgrant:  I believe you are correct - very sure - it is in the log files of the builds as native
[10:04] <soren> wgrant: So nothing we can do will solve this?
[10:04] <soren> wgrant: Well, we could remove the old downloads, but that's not really an option IMO.
[10:04] <ScottSanbar> (waiting with bated breath ... )
[10:05] <wgrant> soren: It excludes obsolete series, so you could lie and set cactus to obsolete, I guess :/
[10:05] <soren> Works for me.
[10:05] <wgrant> soren: Filing a bug that the series sorting is insane would also be a good start.
[10:05] <ScottSanbar> wgrant:  SUCCESS!
[10:06] <wgrant> soren: It basically expands all numeric components to four digits (padding with 0s), maps 0-9 backwards, the sorts.
[10:06] <wgrant> soren: I've never seen anything quite like it.
[10:06] <ScottSanbar> wgrant:  You are wonderful, thanks so much - I really feel a lot better about my package now.  Now, I will change it to be a source package, not just binary - one step at a time (after I download the .deb and verify it all works)
[10:06] <wgrant> s/the/then/
[10:06] <wgrant> ScottSanbar: The recipe builds a source package.
[10:07] <wgrant> Let's see how the binary builds go...
[10:07] <ScottSanbar> wgrant:  Oh, OK - does that mean when I run debuild it build s a source package, or do I need to do something like debuild -S on my home PC?
[10:07] <wgrant> ScottSanbar: If you want to upload to your PPA without going through a recipe, you need to build with debuild -S locally.
[10:07] <wgrant> ScottSanbar: But recipes do that automatically.
[10:08] <wgrant> They take the branches you specify in the recipe, add a new entry to debian/changelog, run debuild -S, and upload that to Launchpad.
[10:09] <ScottSanbar> wgrant: Cool, that is really helpful.  Do I need a ChangeLog in all the various directories like I have seen around in different packages, like hello-debhelper?  I took them out to clean up lintian output.
[10:10] <wgrant> ScottSanbar: No, you don't.
[10:11] <ScottSanbar> wgrant:  From what I have seen, there are a lot of poorly done packages out there - even Gnu Hello and Gnu Hello debhelper are pretty unclean, and they are supposed to be what we learn from in the tutorials on Ubuntu  and Debian
[10:12] <ScottSanbar> wgrant:  I guess, from the standpoint of recipes and not having unnecessary files that will be auto-generated anyway.
[10:16] <wgrant> ScottSanbar: autoconf/automake are a bit special.
[10:16] <wgrant> ScottSanbar: Because release tarballs normally contain the pre-built configure etc.
[10:17] <wgrant> While branches don't.
[10:17] <wgrant> Release tarballs probably shouldn't have all that prebuilt, but that's the way it's been for a while :/
[10:17] <ScottSanbar> wgrant:  Oh, I see.  So the norm is actually to have all that pre-built stuff in the release tarballs?
[10:18] <wgrant> ScottSanbar: Yes, unfortunately.
[10:18] <wgrant> It does mean that users don't need to have autoconf/automake installed, but it's pretty ugly to have generated files in your "source" tarball.
[10:19] <ScottSanbar> wgrant:  Wow, I would have never known all this either except for being told in the IRC channels by pabs in #debian-mentors and you and a few other people.  This stuff does not seem to be written down well, and when you do it right, it is clean and "beautiful".  Too bad.
[10:20] <wgrant> Yeah, in this respect building from branches is substantially cleaner.
[10:21] <ScottSanbar> wgrant:  When done properly, it is an amazingly well done system.  I am glad I am taking the time to learn Autotools, dh_make/debuild, the recipes and associated stuff from the ground up - I think I will be better off in the long run knowing how to do all this from scratch whenever I want.
[10:21] <wgrant> ScottSanbar: Have you looked at debian/rules from hello and hello-debhelper?
[10:22] <wgrant> ScottSanbar: As you can see, the new version of debhelper that you're using is slightly cleaner :)
[10:22] <wgrant> And.. basically does everything for you.
[10:22] <ScottSanbar> wgrant:  Yes I have, and I am glad I do not have to mess with all that now.
[10:22] <wgrant> Yep.
[10:23] <ScottSanbar> wgrant:  The more I get into Ubuntu/Debian/Gnu/Linux the more impressed I am with how it is all put together.  No wonder it is so successful.
[10:24] <ScottSanbar> wgrant: I hope others will learn in time to take advantage of the advances in debhelper, etc. so they do not have to work so hard.
[10:25] <wgrant> It is all so much easier now.
[10:25] <wgrant> Not as easy as it could be, but there are people working on that :)
[10:26] <ScottSanbar> wgrant: The documentation needs to be updated and examples brought up to date for new people like me - I would have been doing it the old fashioned way if I had not asked so many questions and bugged people on irc
[10:27] <ScottSanbar> wgrant:  actually, that is not altogether true - they have the new way in there, but it did not result in a workable recipe the way they had it, and i did not know what files to include/exclude from my branch in launchpad.
[10:31] <ScottSanbar> wgrant: AAARGH - it did not install my man page.
[10:32] <ScottSanbar> wgrant: never mind - I typed in the wrong package name - AOK on testing, huzzah!
[10:34] <wgrant> /win 9
[10:34] <ScottSanbar> wgrant:  I will now finish up debuild with debuild -S, then on to the next step - pbuilder and chroot, etc.
[10:34] <wgrant> Ah good, you know to use pbuilder :)
[10:35] <wgrant> Sounds like a good plan.
[10:35] <ScottSanbar> wgrant:  Yes, I figure I should learn the "underpinnings" before I go up the toolchain - I like to know a little about what is under the hood of stuff so I can better debug, understand, etc.
[10:36] <ScottSanbar> wgrant:  That is actually why I have a degree in Physics - not only was it fun, but I could understand "why" from basic principles.
[10:37] <ScottSanbar> (Until I learned enough to know we actually don't really know anything at all)
[10:37] <wgrant> And now CERN says we might know even less..
[10:38] <bigjools> ah scientists who question their results and share the data, how novel
[10:38] <ScottSanbar> wgrant:  Funny you should mention CERN - I worked on that project doing programming for the ATLAS detector for the University of Oklahoma High Energy Physics group.
[10:40] <ScottSanbar> wgrant: It was a nightmare - you never saw so much horrible, crappy, ungodly code written by newbie Physics grad students and professors who hate to program but have to to get at the physics.  This project is a dream compared to that one, from a programming perspective.  The physics was ultra-cool, though.
[10:40] <ScottSanbar> (ATLAS being the main detector at CERN)
[10:41] <wgrant> Physicists tend to write some... interesting code.
[10:42] <ScottSanbar> wgrant:  I am not a physicist - I just happen to have a bachelors in Physics.  I hope I have learned some positive coding skills in my career! :)
[10:43] <ScottSanbar> wgrant:  I cannot thank you enough, and pabs from #debian-mentors.  I really feel good about my ability to make packages (up to the point I have reached) now, with the proper guidance and corrections.
[10:45] <wgrant> ScottSanbar: Ah, good excuse!
[10:45] <wgrant> Your packaging looks remarkably good for a first try. Well done!
[10:45] <ScottSanbar> wgrant:  One thing I realize, however, is that I do not have a computer science degree, and so have a lot of work ahead of me to read pedagogical texts to become a better computer scientist - looking back on my career, I really feel I could have benefited from getting an MS in CS
[10:46] <wgrant> ScottSanbar: Mm, a lot of CS stuff is probably better self-taught anyway.
[10:46] <ScottSanbar> wgrant:  Thank you very much for the positive feedback.  It always helps to get some kudos to boost one's ego when in a steep learning curve.
[10:48] <ScottSanbar> wgrant:  Yes, mine is all self-taught - lots of exerience and some pretty good work with some classic texts, but I still have a lot more to go to become a kernel, driver, module and networking guy like I want to be.  I am currently in the middle fo "Modern Operating Systems" by Tannenbaum, which is the book that Linus Torvalds says inspired him to write Linux.
[10:49] <ScottSanbar> (so I read, anyway)
[10:49] <wgrant> It's certainly an informative book. His "Operating Systems: Design and Implementation" isn't bad either.
[10:50] <ScottSanbar> wgrant:  Ok, I'll putit on the list.  Here is my book list, FYI: http://www.sanbarcomputing.com/books.shtml
[10:52] <ScottSanbar> wgrant:  I found a bug in one of his examples in "Modern Operating Systems" and he actually e-mailed me back with a terse "Thanks you" for letting him know and giving him a possible solution.
[10:52] <ScottSanbar> wgrant:  Needless to say, I was amazed when he wrote back and agreed with me - made my week!
[10:54] <ScottSanbar> (I kept expecting him to write back and basically say, "Not if you look at it the right way, stupid!")
[11:04] <ScottSanbar> wgrant: If you know, can you recommend a good Linux kernel book?
[11:05] <ScottSanbar> wgrant: from the prospective of programming it
[11:06] <wgrant> ScottSanbar: Linux Kernel Development is not bad.
[11:16] <ScottSanbar> wgrant:  Oh, good - I researched pretty well and thought it was good, but I am glad to have some positive feedback on it.  I will read it next, then.
[16:07] <JonOomph> Hi!  I have a recipe on LaunchPad that just stopped working, after updating the changelog in my Debian packaging branch:  https://code.launchpad.net/~openshot.code/+recipe/openshot-daily.  The buildlog mentions: "debian/changelog didn't contain any parseable stanzas".  Any thoughts?
[17:11] <JonOomph> Where is the best place / channel to discuss LaunchPad recipes... and recipe build errors?
[21:22] <glyph> hello launchpaddders
[21:23] <glyph> Hopefully it's acceptable to bump a project group request: https://answers.launchpad.net/launchpad/+question/172160 :)
[21:33] <phillw> Hi, Lubuntu is having a problem with the mail archiving system. Is this a known issue affecting many, or just picking on Lubuntu?
[21:43]  * phillw I love net splits! (22:33:27) phillw: Hi, Lubuntu is having a problem with the mail archiving system. Is this a known issue affecting many, or just picking on Lubuntu?


[02:18] <powersj> larsks: Could you comment on: https://bugs.launchpad.net/cloud-init/+bug/1724414
[13:12] <larsks> powersj: I don't have a strong preference re: that issue; just make sure that whatever hostname we pick we are consistent.  The current situation is the result of fixing an issue in which cloud-init would select the unqualified hostname initially but the fqdn would be used after a reboot (or something like that), which was causing ugly issues with stuff that used the hostname as an identifier.
[13:12] <larsks> I guess I'll add that to the issue.
[14:12] <smoser> blackboxsw: updated to take your patch on az-ubuntu. thanks.
[14:13] <smoser> the 'azure-ubuntu' that i had was more helpful, it "knew" of regions and sizes and things. i'd like to add that back at some point, but for this at least knows about the '--image=Canonical:UbuntuServer:17.04-DAILY:latest' magic.
[15:09] <blackboxsw> Network dead
[15:24] <rharper> sent over the network
[15:39] <blackboxsw> Heh cellular :)
[15:56] <smoser> powersj: https://github.com/canonical-server/jenkins-jobs/pull/13
[15:58] <powersj> smoser: thanks
[17:27] <smoser> blackboxsw: bug 1724634
[17:27] <smoser> (just fyi)
[17:53] <blackboxsw> checking
[17:54] <blackboxsw> smoser: nice apport bug btw :)
[17:56] <smoser> blackboxsw: yeah. other than i coudlnt type 11
[17:56] <smoser> (bug 1722564)
[17:57] <smoser> blackboxsw: we get double '.txt'
[17:57] <smoser> (see attached files... user_data.txt.txt and cloud-init-output.log.txt.txt)
[17:57] <blackboxsw> I think I'll attach that patch to apport I suggestd to your bug there so there's something to chew on there
[17:58] <blackboxsw> ohh yeah, right, cloud-init apport bug there then.
[17:58] <smoser>  blackboxsw yeah... of course you need to do that. i had thought you had.
[17:59] <smoser> gaughen is the maintainer of apport. lets bother her.
[17:59] <smoser> (per https://launchpad.net/apport)
[17:59] <gaughen> specifically me?
[18:00] <gaughen> oh geez
[18:00] <smoser> :)
[18:01] <blackboxsw> <with devious mousish voice> ... excellent Pinky.... let's take over the Foundations team :)
[18:01] <gaughen> I thought smoser you were making some broad stroke statement of the foundations team
[18:02] <smoser> gaughen: well, that definiteliy would be possible. but no, you are specifically the maintainer.
[18:02] <gaughen> I see that
[18:02] <gaughen> thus my "oh geez"
[18:02] <smoser> yeah, i wonder what other projects you maintain
[18:04]  * gaughen checks to make sure cloud-init isn't on her list
[18:05]  * smoser should have thought of doing that
[18:08] <gaughen> so now I have to look and see why you all are talking about apport... I see bug 1722564
[18:21] <smoser> powersj: i think that moving examples around broke/changed the default tests that are run in cloud_tests.
[18:23] <powersj> smoser: how so
[18:24] <smoser> ok. i guess not. its not running 'examples/' tests though
[18:24] <powersj> let me see if they are enabled
[18:24] <smoser> which the c-i runs
[18:24] <smoser> so i ran something locally, it passed, i pushed a MP, it failed on c-i
[18:25] <powersj> all tests in examples are "enabled: False" in the yaml
[18:26] <powersj> ci runs the following command: sh 'python3 -m tests.cloud_tests run --verbose --os-name xenial --test modules/apt_configure_sources_list.yaml --test modules/ntp_servers --test modules/set_password_list --test modules/user_groups --deb cloud-init_*_all.deb'
[18:26] <powersj> from: https://github.com/canonical-server/jenkins-jobs/blob/master/cloud-init/jobs-ci.yaml
[18:29] <smoser> powersj: powersj i'm missing something
[18:29] <smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/405/console
[18:29] <smoser> test_no_warnings_in_log failed (line 3497)
[18:29] <smoser> the test test_user_barfoo ran
[18:30] <smoser> which is from tests/cloud_tests/testcases/examples/including_user_groups.py
[18:31] <powersj> which also happens to be in ./tests/cloud_tests/testcases/modules/user_groups.py
[18:31] <powersj> grep -ir "test_user_barfoo" .
[18:31] <powersj> ./tests/cloud_tests/testcases/examples/including_user_groups.py:    def test_user_barfoo(self):
[18:31] <powersj> ./tests/cloud_tests/testcases/modules/user_groups.py:    def test_user_barfoo(self):
[18:31] <powersj> python3 -m tests.cloud_tests run --verbose --os-name xenial --test modules/apt_configure_sources_list.yaml --test modules/ntp_servers --test modules/set_password_list --test modules/user_groups --deb cloud-init_17.1-21-gbc70e157-1~bddeb_all.deb
[18:31] <powersj> is the command it ran
[18:31] <powersj> and there is the modules/user_groups test
[18:31] <smoser> huh. indeed it does
[18:31] <smoser> :)
[18:31] <powersj> :)
[18:32] <powersj> while I like the bugs dir and our attempt to organize things
[18:32] <powersj> I'm not a huge fan of the examples dir
[18:32] <powersj> especially if everything is disabled
[18:32] <powersj> seems pointless
[18:32] <powersj> and you know... causes uncessary confusion :)
[18:32] <smoser> *and* its 100% duplicate
[18:32] <powersj> yeah
[18:33] <smoser> at least
[18:33] <smoser>  tests/cloud_tests/testcases/examples/including_user_groups.py
[18:33] <smoser> ==
[18:33] <smoser>  tests/cloud_tests/testcases/modules/user_groups.py
[18:33]  * powersj would be happy to see examples get blown away
[18:33] <smoser> :-(
[18:34] <smoser> yeah
[18:37] <blackboxsw> yeah, I thought the same about duplication. There is merit in making sure that the syntax/intent of our examples is testable. But, I don't think verbatim that example copies into integration tests will really *work* for us.
[18:37] <blackboxsw> too many external services etc that need to be faked
[18:48]  * blackboxsw is cut-n-pasting verification results into each SRU 17.1 sub-bug now.
[18:48] <smoser> blackboxsw: i assumed you were going to be launchpad-libbing that
[18:49] <smoser> blackboxsw: you able to hang out for a minute ?
[18:49] <blackboxsw> good point, will do that. do we want it as a comment of bug description smoser
[18:49] <blackboxsw> yeah definitely
[18:49] <blackboxsw> hanging out
[18:49] <blackboxsw> cloud-init channel
[18:54] <smoser> blackboxsw: almost there.
[18:57] <blackboxsw> no rush. just tweaking your lp-bugs-released script
[19:20] <smoser> blackboxsw: https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1721808
[20:00] <blackboxsw> smoser: ci passed https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332383
[20:01] <blackboxsw> shall I land it in master or are you?
[20:04] <smoser> blackboxsw: i can land
[20:04] <blackboxsw> gr8
[20:11] <smoser> blackboxsw: merged.
[20:11] <smoser> 41152f10ddbd8681cdac44b408038a4f23ab02df
[20:15] <blackboxsw> ok see it. starting the cherry pick
[20:16] <blackboxsw> smoser: wanted to double check. so I'm upstream-snapshotting into ubuntu/devel right?
[20:16] <blackboxsw> then cherry pick into xenial zesty
[20:17] <blackboxsw> or cherry pick all ubuntu/devel, ubuntu/xenial and ubuntu/zesty
[20:18] <smoser> blackboxsw: just ignore artful (ubuntu/devel) for now
[20:19] <smoser> and cherry-pick to ubuntu/xenial and ubuntu/zesty
[20:19] <blackboxsw> ok won't touch it
[20:19] <smoser> have MP ready, and i'll review later. i have to run now.
[20:19] <blackboxsw> see ya
[20:19] <smoser> if you care... here is what i started writing
[20:19] <smoser> http://paste.ubuntu.com/25768023/
[20:19] <smoser> for SRU template on that bug
[20:35] <blackboxsw> ok, debugging cherry-pick not working in my env
[20:35] <blackboxsw> http://pastebin.ubuntu.com/25768117/
[20:41] <blackboxsw> strange thing is if I take the diff from within the cpick file, patch applies cleanly
[20:43] <blackboxsw> ...  I'm not seeing the diff content for cloudinit/config/cc_users_groups.py and other files in the cherry picked patch diff. just a couple of the unit test files listed in the cpick file.
[20:46] <blackboxsw> n/m I see the full diff/patch. looks good relative to changes that went into master... although cherry-pick is claiming it didn't apply cleanly
[20:46] <blackboxsw> checking quilt output
[21:02] <blackboxsw> today bbsw learns about quilt
[21:02] <blackboxsw>  QUILT_PATCHES=debian/patches quilt push cpick-41152f1-schema-Log-debug-instead-of-warning-when-jsonschema-is
[21:03] <blackboxsw> I needed to override QUILT_PATCHES defaults so it can actually find the series file in debian/patches/series so that I can run smoser's cherry-pick script
[21:04] <blackboxsw> ahh much better
[21:04] <blackboxsw> ok
[21:09] <blackboxsw> zesty is up for review https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332446
[21:16] <blackboxsw> xenial is up for review https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332447
[21:16] <powersj> blackboxsw: I added a few things to the SRU checklist
[21:17] <powersj> namely collecting results for other tests, per our SRU exception
[21:17] <blackboxsw> powersj: URL? is it the cloudinit SRU exception page
[21:17] <powersj> https://wiki.ubuntu.com/CloudinitUpdates
[21:17] <blackboxsw> I'll reread now since I'm in the thick https://wiki.ubuntu.com/CloudinitUpdates?
[21:17] <blackboxsw> yeah
[21:18] <powersj> thx
[21:18]  * blackboxsw reads  the page thanks
[21:19] <blackboxsw> ok pulling together suggestions now for that page.
[21:19] <blackboxsw> since I'm through my 2nd round of SRU uploads on this SRU.
[21:22] <blackboxsw> hrm not sure if I have edit rights, I can't seem to login to the wiki.ubuntu
[21:23] <powersj> blackboxsw: best not to make edits, but propose them first somehow
[21:23] <powersj> if it is more than minor, we have to get things approved
[21:24] <blackboxsw> sounds good pooling suggested edits now.
[21:34] <blackboxsw> powersj: this is all I have http://pastebin.ubuntu.com/25768388/
[21:34] <blackboxsw> your changes look good
[21:35] <powersj> blackboxsw: that is 100% fine :) I wasn't sure if you were going to change the process or make changes such that we would need to ask for re-approval
[21:36] <blackboxsw> nah, nothing big, just that we've added attachements to the SRU process bug  with logs instead of dumping all those manual results inline in the SRU template as it is unreadable with all that content
[21:37] <blackboxsw> we will also likely add bug tasks for xenial/zesty on each SRU non-process bug. to allow marking that bug as fix-released in the specific series once it's published (post SRU)
[21:37] <blackboxsw> not sure if that would need documenting on cloudinitupdates wiki page,  but it'll be part of our process going forward
[21:37] <blackboxsw> to really document when a bug is released to a stable series
[21:39] <powersj> blackboxsw: ok, thanks :) as far as bug tasks for that page, we are concerned with the one big that tracks the SRU
[21:41] <blackboxsw> yeah figured
[21:41] <blackboxsw> thx


[03:00] <Montresor> bluesabre: TBH, I'm not keen on 10MB just to have the possibility, I think if people want it they should get it.  But I'm not going to object either, do what you feel is best and I won't be annoyed with you. :P
[03:00] <Montresor> (Just not in core please, but that's not just "mine" either!)
[10:04] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfconf 4.17.0 released<EMAIL_ADDRESS>[10:04] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-session 4.17.1 released<EMAIL_ADDRESS>[10:04] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-power-manager 4.17.0 released<EMAIL_ADDRESS>[10:04] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: thunar-volman 4.17.0 released<EMAIL_ADDRESS>[10:04] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: exo 4.17.3 released<EMAIL_ADDRESS>[10:05] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-settings 4.17.0 released<EMAIL_ADDRESS>[10:05] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: thunar 4.17.11 released<EMAIL_ADDRESS>[10:11] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfwm4 4.17.0 released<EMAIL_ADDRESS>[11:14] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfwm4 4.17.1 released<EMAIL_ADDRESS>[13:52] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: Xfce 4.18pre1 released<EMAIL_ADDRESS>[22:21] <Unit193> I guess perhaps I should say that I did in fact upgrade openssl stuff, and restarted the affected services.


[06:35] <eoli3n> Hi
[06:35] <eoli3n> xnox there is a regression about chromium-browser
[06:36] <eoli3n> https://x0.at/9E-.txt
[06:39] <eoli3n> added to -> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232
[08:02] <rbasak> eoli3n: please file a new bug to report a regression and tagg ig regression-updates. Looking at your comment, IMHO it needs more explanation of your specific situation, but maybe developers closer to the package will understand. In any case that's best discussed in a separate bug if necessary.
[08:02] <rbasak> tagg ig -> tag it :)
[08:02] <rbasak> Oh and regression-update, not regression-updates
[09:15] <eoli3n> rbasak thanks, xnox know what it is about, and the full bug report explain it well i think
[09:15] <eoli3n> lets open a new bug
[09:20] <eoli3n> -> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1927071
[09:20] <rbasak> Thanks!
[09:20]  * rbasak will be offline for a bit
[15:12] <seb128> amurray, congrats on joining the coredev ;-)
[15:13] <amurray> thanks seb128 :)
[15:59] <dbungert> would someone assist with a retest for xfig?  https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=xfig&trigger=xfig/1%3A3.2.8-2
[16:05] <seb128> dbungert, clicked


[09:40] <cyking> i find these instructions a bit ambiguous https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1453391/comments/14
[10:38] <ePirat> Hello
[10:39] <ePirat> I filed a kernel bug and was asked to do a full commit bisect
[10:39] <ePirat> but I can't follow the guide on the wiki
[10:39] <ePirat> as I can't find the debian.master file where to make the changes
[10:40] <ePirat> should I just adjust the version number in makefile instead?
[12:05] <Taloth> ePirat: try ./debian.master/changelog
[12:26] <ePirat> Taloth, there is no debian.master folder
[12:26] <Taloth> http://kernel.ubuntu.com/git/ubuntu/ubuntu-trusty.git/tree/debian.master
[12:27] <Taloth> which version were you supposed to bisect?
[12:27] <ePirat> I am using the vivid repo
[12:28] <ePirat> 3.18.6 to 3.19.x (most recent one I guess)
[12:28] <Taloth> you already bisected the released versions (package)?
[12:30] <ePirat> yes, those are the working/non-working versions I identified, I can't narrow down more as other 3.18 versions higher mess up everything making reproducing my bug impossible there
[12:30] <ePirat> the issue is that wifi stops working after some time/data downloaded
[12:31] <ePirat> even though it still shows up as connected it behaves like it is not
[12:31] <ePirat> for testing I need to be able to run the system for at least an hour while downloading stuff
[12:31] <Taloth> In the bugreport you mentioned 3.18.6 working while 3.18.11 doesn't.
[12:32] <Taloth> so I assume you'll be commit bisecting from there on.
[12:33] <ePirat> 3.18.11 shows different non working behavior than I have actually observed in 3.19 (i get popups that errors occured in the system but those seems to not really be related to wifi)
[12:33] <Taloth> what's the next lower version you checked?
[12:34] <Taloth> 3.18.0-10 or something else?
[12:36] <ePirat> let me check (need to boot the affected machine)
[12:38] <ePirat> 3.18.6-031806 was the last working version for me, 3.18.11-031811 was the one I could not test properly with
[12:38] <Taloth> As for your original question, if you check out the repo from  http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git the ./debian.master dir should be there.
[12:39] <Taloth> Maybe you're bisecting the upstream kernel tree? which wouldn't have debian.master
[12:40] <ePirat> I cloned from git://kernel.ubuntu.com/ubuntu/ubuntu-vivid.git
[12:42] <ePirat> I do have a debian.master folder in master, but not in my branch which I am using for bisect (which is currently at 0ce3c06)
[12:47] <Taloth> which branch are you bisecting on? seems to me like you should be using master.
[12:48] <ePirat> I followed the guide linked in the bug ticket, so I branched from master in a branch called mybisect and started the bisect
[12:54] <Taloth> which commit did you mark as good?
[12:56] <ePirat> bad: 83f803a good: f8e80fa
[12:58] <Taloth> but yeah, you're in the commit history of the upstream kernel, hence the missing debian.master. tbh, not sure how to normally deal with that.
[13:00] <ePirat> oh
[13:00] <ePirat> ok
[13:01] <Taloth> but did you install 3.18.0-14.15 from package?
[13:04] <ePirat> not sure… could you explain me how this versioning stuff works? I am confused by all the -x.x suffixes
[13:06] <Taloth> that's because ubuntu is based on the mainline kernel, which uses different version numbers.
[13:07] <Taloth> Your problem boils down to https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_bisect_the_upstream_kernel.3F
[13:08] <ePirat> ah
[13:08] <Taloth> welcome down  the rabbit hole btw.
[13:08] <Taloth> :D
[13:09] <ePirat> :P
[13:09] <ePirat> I wish my  bug would at least be easier to reproduce
[13:11] <Taloth> i had a bug that made mono crash on users systems at unpredictable times. sometimes minutes sometimes days. Took quite some time till I isolated the kernel commit breaking it.
[13:11] <Taloth> fortunately wasn't hardware related like your wifi issue
[13:13] <ePirat> usually I would just have used an older versions but there my trackpoint click buttons do not work properly…
[13:14] <Taloth> On the other hand, now you'll helping to make the world a better place :P
[13:15] <ePirat> it seems switching kernels so often messed something up as I now get the system error popup even on previously fine kernel versions… great…
[13:15] <ePirat> and I can't even report those as report fails with some error…
[13:18] <ePirat> I wonder why no other thinkpad x250 user has had this wifi problem yet
[13:18] <Taloth> they quite possibly did, and are angry atm but don't know how to fix it.
[13:20] <ePirat> tbh, reporting the ubuntu kernel bug was one of the hardest bug reporting experiences I ever had
[13:26] <ePirat> I wonder if it wouldn't be possible to narrow it down to a few commits, since it is some wifi related thing?
[13:30] <Taloth> that's where a bisect comes in.
[13:33] <Taloth> from what I could see the bisect is 13 steps, over 7000 commits. It's going to take a while.
[13:35] <ePirat> indeed, specially since reproducing the bug takes hours sometimes
[13:38] <Taloth> but don't give up, take your time, you'll be helping out the devs immensely. It will be near impossible for them to reproduce, much less fix.
[13:40] <ePirat> ok :)
[13:41] <ePirat> I think I will reinstall ubuntu later (specially since 15.04 is officially released now) and try to narrow it a bit more down with packaged kernel versions


[00:54] <SpamapS> smoser: well my theory seems to not be true.. I added a 50ms delay to the bit of udev where I thought the race was happening but it didn't seem to make the race more likely. :-/
[00:56] <ubuntucloud523> hello
[01:41] <smoser> SpamapS, are you able to reproduce at will ?
[01:42] <SpamapS> smoser: no, thats what I was hoping
[01:43] <smoser> ah.
[01:54] <SpamapS> smoser: hmm.. found another spot to try actually
[10:35] <koolhead17> hi all
[10:42] <flaccid> suup
[10:54] <kim0> koolhead17: howdy
[10:54] <kim0> flaccid: monrning :)
[10:54] <flaccid> evening
[10:55] <kim0> oh hehe
[10:55] <kim0> flaccid: you're working with cloudstack right
[10:56] <koolhead17> hi kim0 flaccid
[10:56] <flaccid> not much yet
[10:56] <flaccid> i work at RightScale
[10:56] <kim0> ah .. is that based on openstack, or a separate product
[10:56] <flaccid> separate
[10:56] <kim0> ah I see
[14:49] <keyz182> Hi, has anyone here successfully set up Puppet on a UEC  cloud? I'm trying, but failing. on the puppet master, I'm getting "puppet-master[3153]: Could not resolve <IP_ADDRESS>: no name for <IP_ADDRESS>" in syslog. I have DNS_DISABLE set to no to enable DNS
[15:05] <kim0> keyz182: looks more like a #puppet question
[15:07] <keyz182> kim0; No, I'm pretty sure it's a networking/UEC issue. running hostname -f or dnsdomainname fail.
[15:07] <keyz182> I'm not sure however if the issue is misconfiguration on my behalf (probably) or a UEC problem
[15:23] <keyz182> Ok, sorted it now. I had to change /etc/dhcp3/dhclient.conf to supersede the domain-name and domain-search, and prepend the clc IP address as the primary dns
[15:24] <keyz182> you have to use the CLC internal/private address though, i.e. in my case <IP_ADDRESS>, otherwise it sees queries returned from that address even though they were sent to the public address
[15:41] <keyz182> Are there any UEC/Eucalyptus developers in? I'm trying to find the best place to modify Eucalyptus so that custom dhcp options can be added (and not overwritten), e.g. setting the domain-search, and dns servers etc. To me, it looks like tools/eucanetd is the place to do it in, as it appears to be writing the dhclient.conf file, does that sound right?
[18:57] <smoser> mathiaz, i just uploaded builds to awstools ppa
[21:40] <navanjr> looking for help troubleshooting performance issues in my setup...  NC has 16cores and 24gb ram and a small instance with 1core and 1gb ram is performing poorly.  htop uses 30% of the CPU in the instance
[21:40] <navanjr> I have looked over the logs for any obvious errors
[21:42] <navanjr> and googled and read all i can find to help me trouble shoot.
[21:46] <navanjr> CPUs on NC are 2.4
[21:46] <SpamapS> navanjr: do you definitely have hardware virtualization support?
[21:46] <TeTeT> navanjr: yeah, check kvm-ok if possible
[21:47] <navanjr> yes... INFO: Your CPU supports KVM extensions, INFO: /dev/kvm exist, KVM acceleration can be used
[21:48] <TeTeT> navanjr: on the nc, when you grep for kvm, it is truely kvm running and not qemu by some strange config problem?
[21:50] <navanjr> yes, top says... 25026 libvirt-  20   0 1698m 1.3g 3564 R  100  5.4 109:39.03 kvm
[21:56] <SpamapS> navanjr: also is it actually performing poorly, or is it just showing high load?
[21:57] <SpamapS> navanjr: there have been bugs in the past where the kernel said it was busier than it actually was.
[21:58] <navanjr> it is very sloooow.
[21:58] <navanjr> http://pastebin.com/0iaNGTDb
[21:58] <navanjr> there is my pstree
[21:58] <navanjr> fwiw
[22:00] <navanjr> for my tests i have been running a pretty simple instance loading a few packages from user-data
[22:00] <navanjr> what should take 5 min takes over an hour
[22:30] <TeTeT> navanjr: how is disk i/o on the instance with dd or spew or bonnie? Any good or garbage? How is network IO?
[22:35] <navanjr> should i check this within an instance? or on the NC or CLC
[22:38] <TeTeT> navanjr: on the instance I think
[23:07] <TeTeT> navanjr: good luck, need to logoff now


[19:14] <ibeardslee> morning
[22:07] <olly> morning
[22:11] <mwhudson> really?
[22:11] <mwhudson> not sure it's light yet
[22:18] <chilts> almost morning perhaps
[22:18] <chilts> more like a morn..
[22:18] <ibeardslee> better than a mourn
[22:19]  * olly wonders how different the weather is over the CBD
[22:20] <ibeardslee> it's grey in the (wellington) CBD


[00:52] <CShadowRun> Is there any page with a list of supported phones?
[00:57] <GrueMaster> Phones?  Did you not read the FAQ so well prominently displayed at the top of the screen when you enter the room?


[18:39] <OerHeks> !pokemon
[18:39] <Pici> thankfully, no factoids
[18:40] <OerHeks> Yes, we are safe :-D
[18:40] <Pici> and surpirsingly no one has any that are for -offtopic only.


[07:35] <mup> Bug #1650671 opened: Content sharing from snap common is broken <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1650671>
[07:50] <Chipaca> zyga: have you looked at snapd#3499 at all? (is that a "you" pr? or is it one for jamie? or...?)
[07:50] <mup> PR snapd#3499: Spi patch <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
[07:54] <zyga> mvo: +1 to merge https://github.com/snapcore/snapd/pull/3464
[07:54] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[07:56] <mvo> zyga: did one of the reviewer check each individual snippet that its the same  as in the old big table?
[07:56] <mvo> zyga: other than that, +1
[07:57] <zyga> mvo: I cannot say but since jdstrand reviewed it I really trust it is
[07:57] <zyga> mvo: if you want just go over each patch (they are structured for thaT)
[07:57] <zyga> mvo: so that you see the same stuff in green and red
[07:59] <mup> PR snapd#3464 closed: interfaces: put base policy fragments inside each interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3464>
[08:04] <ogra_> ppisati, mind taking a look at bug 1701018 ? (your opinion would be helpful there i think)
[08:04] <mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:New> <https://launchpad.net/bugs/1701018>
[08:07] <ppisati> ogra_: yep, as far as i know when you enable the spashscreen you have to select a bitmap
[08:07] <ogra_> and it defaults to the penguin ...
[08:07] <ppisati> ogra_: yep
[08:08] <ogra_> the prob is that they currently use our linux-generic-raspi2 snap ... so they will likely have to rebuild
[08:08] <ogra_> (which will make their security story a bit awkward)
[08:08] <ogra_> can you mention that on the bug ?
[08:09] <ppisati> ogra_: yeah. go ahead
[08:11] <ogra_> ppisati, i was hoping you can do that (i want a more authoritative person speaking than me :) )
[08:12] <ppisati> ogra_: oh k, no prob
[08:12] <ogra_> thanks :)
[08:38] <mup> PR snapd#3541 opened: snapd: fix for snapctl get panic on null config values <Created by stolowski> <https://github.com/snapcore/snapd/pull/3541>
[08:38] <ppisati> ogra_: replied, but actually his request make sense - he wants to setup the splash screen from uboot and then make the kernel pick it up without touching, i wonder if someone already did it
[08:39] <ppisati> ogra_: but they probably did per-build, i doubt there's something generic
[08:41] <ogra_> yeah
[08:42] <ogra_> ppisati, what i tried here was to set "stdout=" in u-boot (i.e. drop serial and vga) but that just ends up with the kernel blanking the console (and not showing any further output) instead of leaving it untouched
[08:42] <ogra_> so i guess you would have to actually turn off the console completely in the kernel and have it not take over hdmi at all
[08:43] <ogra_> ... pprob is ... they do digital signage ... so they will need the display later from userspace
[08:44] <ppisati> so they want the splashscreen till userspace picks up, then they'll mess with fb from there
[08:44] <ppisati> uhm
[08:45] <ogra_> well, either that or have the kernel show the same splash when it inits the screen
[08:45] <ogra_> they simply want a splash during the whole boot til userspace ... i guess they dont care how they get there
[08:45] <ppisati> k
[08:45] <ppisati> but no, no dynamic splash support in the kernel
[08:46] <ogra_> yeah ... and plymouth is really not an option for the generic initrds
[08:46] <ogra_> they might be able to buuld their own ... and end up with a 20MB initrd or so
[08:46] <ppisati> i wonder if there's a way to embed a bitmap in DT so both uboot and kernel can be teached to use whatever is there
[08:46] <ogra_> *build
[08:46] <ppisati> that would generic enough
[08:47] <ogra_> oh
[08:47] <ogra_> now thats an idea
[08:47] <ppisati> but then, we need first to find if they want binary data in DT
[08:47] <ppisati> and that will probably blow the space reserved for DT at boot
[08:48] <ppisati> in rpi2 at least
[08:48] <ogra_> yeah
[08:48] <ogra_> but thinking about it ... android also manages to have a bootloader splash that stays
[08:48] <ogra_> until surfaceflinger starts in userspace
[08:49] <ogra_> though they usually dont have any framebuffer console at all
[08:49] <ppisati> but they build the kernel fr that device, so they can hardcode the bitmap there
[08:50] <ppisati> ogra_: have you tried asking this question to the graphics people? perhaps they know a way to skip fb initialization if it's already setup
[08:51] <ogra_> i'm not sure they build the kernel ... afaik they use our snap and want to get the security benefits from it
[08:52] <ppisati> ogra_: they can use our src tree, and just apply a single patch (config + bitmap on top of it), and every time we cut a new release, they rebase and rebuild
[08:56]  * ogra_ finds psplash ...
[08:58] <ogra_> i wonder if we could ship that in our initrd ... looks a lot easier than plymouth
[08:58] <ogra_> http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/
[09:00] <ogra_> PSplash is a userspace graphical boot splash screen for mainly
[09:00] <ogra_> embedded Linux devices supporting a 16bpp or 32bpp framebuffer. It has
[09:00] <ogra_> few dependencies (just libc), supports basic images and text and handles
[09:00] <ogra_> rotation.
[09:01] <ppisati> ogra_: but don't they have to add their logo to initrd though?
[09:06] <ogra_> yeah
[09:09] <mup> PR snapd#3542 opened: cmd,client,daemon: expose "force devmode" in sysinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/3542>
[10:39] <ogra_> jdstrand, do we have any interface that allows direct access to /dev/fb0 (i suspect i know the answer, but thought i'd ask anyway) ...
[10:40] <ogra_> i just makes a psplash snap that runs fine in devmode ...
[10:45] <mup> Bug #1699504 changed: "network" plug does not allow outbound ping <Snappy:Invalid> <https://launchpad.net/bugs/1699504>
[10:56] <ogra_> kyrofa, http://paste.ubuntu.com/24980409/
[11:03] <ogra_> kyrofa, looks like your devices uses at91-sama5d3_xplained.dtb ... which isnt in our kernel
[11:03] <ogra_> kyrofa, https://goembed.in/2016/03/18/build-and-install-linux-for-arm-cortex-a5-based-embedded-board/ looks like a useful starting page
[11:05] <kyrofa> ogra_, ah, thank you! How did you find the at91 bit?
[11:05] <ogra_> google ;)
[11:05] <ogra_> seraching for "ATSAMA5D36 dtb"
[11:22] <jdstrand> ogra_: yes, framebuffer
[11:25] <jdstrand> mvo (cc zyga): I reviewed every line of https://github.com/snapcore/snapd/pull/3464 and I used the debug functionaility to compare outputs before and after
[11:25] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3464>
[12:02] <matteo> hey guys
[12:07] <ogra_> jdstrand, bah ... the tool i use uses "dup()" ...
[12:08] <ogra_> jdstrand, that is why framebuffer doesnt work ... still blocked by seccomp
[12:08] <ogra_> do you think that could be allowed ?
[12:12] <ogra_> HAH ...
[12:13] <ogra_> cheating helps ... if i use docker-support i get access to the dup syscall
[12:13] <ogra_> :D
[12:14] <cachio> niemeyer, https://paste.ubuntu.com/24980832/
[12:15] <niemeyer> cachio: Aw, it removed the disks..
[12:15] <cachio> yes
[12:15] <niemeyer> cachio: Can you retry with --debug?
[12:18] <cachio> niemeyer, it the same with -debug
[12:19] <cachio> something is hepening before the machine is ready
[12:19] <cachio> after the step Creating configuration on linode:ubuntu-core-16-64
[12:19] <niemeyer> cachio: Ah, of course, sorry :(
[12:19] <niemeyer> cachio: Hmmm
[12:19] <cachio> it waits until boot
[12:19] <cachio> and then it is removing disks
[12:19] <cachio> it is like the image could not be booted
[12:19] <niemeyer> cachio: Can you rebuild spread locally and disable the disk removal logic?
[12:19] <niemeyer> cachio: We want to keep around a machine that failed with that error, just once, so we can hand it to support
[12:20] <cachio> niemeyer, ok sure
[12:28] <mup> PR snapd#3536 closed: snap-seccomp: deal with mknod on aarch64 in the seccomp tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3536>
[12:29] <cachio> niemeyer, (Spread-04): <IP_ADDRESS>
[12:32] <cachio> niemeyer, cannot boot linode:ubuntu-core-16-64 (Spread-04): configID not found
[12:34] <cachio> niemeyer, (Spread-68): <IP_ADDRESS>
[12:34] <cachio> this failed
[12:51] <jdstrand> ogra_: dup, dup2 and dup3 are alreadyin the default seccomp template
[12:54] <cachio> niemeyer, (Spread-68): <IP_ADDRESS>
[12:54] <mup> PR snapd#3543 opened: osutil: allow building on ppc64 (not LE) <Created by zyga> <https://github.com/snapcore/snapd/pull/3543>
[12:54] <cachio> this last one has the disk and config
[13:34] <tintou> Jun 29 12:03:07 Coco-XPS-13-9360 kernel: [12493.683255] audit: type=1400 audit(1498734187.179:530): apparmor="DENIED" operation="open" profile="snap.test-gst-clutter.test-gst-clutter" name="/sys/devices/pci0000:00/0000:00:02.0/vendor" pid=30120 comm="test-gst-clutte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13:37] <tintou> https://www.irccloud.com/pastebin/5o8o4aC3/gst-error
[13:38] <kyrofa> tintou, got it, sorry
[13:38] <kyrofa> Didn't realize I was offline :)
[13:54] <mup> PR snapcraft#1384 closed: Support yaml merge tags <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1384>
[14:18] <mup> PR snapcraft#1378 closed: Integration tests for snap command with target arch <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1378>
[15:07]  * Chipaca hugs jdstrand
[15:12]  * jdstrand hugs Chipaca back :)
[15:38] <mup> PR snapd#3544 opened: tests: make main/help run on opensuse and fedora again <Created by chipaca> <https://github.com/snapcore/snapd/pull/3544>
[15:38] <Chipaca> fginther: Pharaoh_Atem: ^
[15:38] <Chipaca> um
[15:38] <Chipaca> i meant fgimenez, but he's not here
[15:48] <mup> PR snapd#3532 closed: many: support snap title as localized/title-cased name <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3532>
[18:25] <stgraber> sergiusens, kyrofa: is https://bugs.launchpad.net/snapcraft/+bug/1590767 somewhere on the roadmap for the next snapcraft?
[18:25] <mup> Bug #1590767: Support snap installed completion scripts <isv> <lxd> <snapd-interface> <Snapcraft:Triaged> <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1590767>
[18:26] <stgraber> or is there already some way of passing the completer through to snapd which I'm not aware of?
[20:23] <sergiusens> stgraber: I've updated the bug status for snapcraft.
[20:23] <stgraber> sergiusens: great, thanks!
[20:24] <sergiusens> stgraber: would be nice for the snapd side of the bug to be updated though, your comment gives me confidence it is already available for all snapd installations though
[20:27] <stgraber> sergiusens: yeah, I remember mvo saying it would be in 2.26 and the release notes for 2.26 seem to confirm it
[20:27] <stgraber> sergiusens: there may issues though since I doubt anyone actually used it given that snapcraft doesn't support it
[23:28] <cjwatson> Could somebody please retry https://travis-ci.org/snapcore/snapd/builds/248376205 ?  I don't think the timeout is the fault of my PR.


[04:28] <IdleOne> !ot > kj4
[11:12] <bazhang> like herding cats today
[13:29] <vibhav> Can somebody have a look at the discussion going at the off topic channel?
[13:34] <vibhav> ah wait, I think I can resolve this.
[18:40] <OerHeks> goodevening, there is a nasty person with us, in #ubuntu-nl, he is also kicked in #ubuntu, no ops available ..
[18:41] <Fuchs> hmm, neither staff nor ubuntu members nor the IRCC are on the access list
[18:41] <OerHeks> see screenshot http://picpaste.com/ops-Bf0LKAub.png
[18:42] <OerHeks> oh he just left ..
[18:42] <OerHeks> sorry for disturbing
[18:45] <OerHeks> http://picpaste.com/ops3-F2ab3BcW.png maybe he is running other channels
[18:46] <IdleOne> Fuchs: that is 4 different ubuntu channels he disrupts
[18:46] <Fuchs> Aware of it,
[18:46] <Fuchs> it also hit one that I am op in,
[18:46] <Fuchs> already talking to the user
[18:46] <Fuchs> poke me if he hits more
[18:51] <IdleOne> Will do and thank you
[18:51] <Fuchs> You're welcome
[18:54] <tsimpson> Fuchs: they hit #ubuntu-desktop now (and probably -discuss)
[18:55] <EXORCIST> !ops
[18:55] <Pricey> Howdy EXORCIST. Can I help you?
[20:44] <Flannel> is junior the guy who had that bot that "needed" to be tested in #ubuntu?
[20:45] <ikonia> don't think so
[20:45] <ikonia> (hope not - as he's behaving like a fool)
[20:46] <Flannel> Well, maybe his AI will learn that being disruptive causes people to become unhappy with you.
[20:49] <Fuchs> iuser in -offtopic might need some attention, just as a sidenote. <iuser> chinese race is a fake lie  <iuser> a black president makes you poor
[20:50] <ikonia> thank you fuchs
[21:41] <juniour> hi
[21:41] <juniour> i got baned in
[21:41] <ikonia> yes, you got banned
[21:41] <juniour> ubuntu
[21:41] <ikonia> hello juniour
[21:41] <juniour> hi
[21:42] <ikonia> I know, I did it
[21:42] <juniour> y ?
[21:42] <ikonia> you know why
[21:42] <juniour> y?
[21:42] <ikonia> I asked you to stop saying pointless/random things,
[21:42] <ikonia> you said "no"
[21:42] <ikonia> so I banned you
[21:42] <ikonia> you'd already been kicked by Flannel as a warning
[21:42] <juniour> i am working on artificial intelligence
[21:42] <juniour> o i ask some unrelevetn question to chack bot
[21:42] <ikonia> so ?
[21:42] <juniour> k
[21:43] <ikonia> no
[21:43] <ikonia> unacceptable
[21:43] <ikonia> #ubuntu is not a bot testing channel
[21:43] <juniour> i just checking the intelligence
[21:44] <ikonia> yes, and I've just said "unacceptable"
[21:44] <ikonia> and others from this team have tried to contact you about your bot before
[21:44] <juniour> wt?
[21:44] <juniour> i dient got you
[21:45] <ikonia> look - you're banned from the channel for the moment, you where asked to stop doing something, you ignored it, you got kicked, you where asked again, you ignored it, you got banned
[21:45] <ikonia> you're testing a bot - #ubuntu is not a bot testing channel, use another channel
[21:45] <juniour> i am using this channel from last four years
[21:46] <ikonia> ok, well you're not at the moment
[21:46] <ikonia> it's not a bot testing channel and random words in the channel and bad language is not welcome
[21:46] <ikonia> as you where told
[21:48] <juniour> so wt should i do
[21:48] <AlanBell> juniour: create a channel in which to test your bot
[21:49] <ikonia> a.) not have a bot in the channel b.) not say random things in the channel c.) not swear in the channel d.) listen / comply when people tell you things to do within the channel guidelines
[21:50] <juniour> a)wrong other accecpted
[21:50] <juniour> k
[21:50] <juniour> got
[21:50] <ikonia> sorry, I don't understand, what do you mean ?
[21:50] <juniour> leave
[21:50] <juniour> i got
[21:50] <juniour> how do i unban my self
[21:51] <ikonia> you don't, we will unban you when you can comply with the reasons/resolution as to why you got banned
[21:51] <juniour> i told i got
[21:52] <juniour> i written above accecpted
[21:52] <ikonia> I don't understand, and now I have to leave, so hopefully one of the others will help
[21:52] <juniour> you told a.) not have a bot in the channel b.) not say random things in the channel c.) not swear in the channel d.) listen / comply when people tell you things to do within the channel guidelines
[21:52] <juniour> i got
[21:52] <juniour> that
[21:52] <juniour> accecpted
[21:52] <juniour> above
[21:53] <juniour> u there?
[21:54] <AlanBell> juniour: ikonia has left, but others are here
[21:54] <AlanBell> what was your bot called?
[21:54] <juniour> AlanBell i told some random word to bot
[21:55] <AlanBell> what is the name of your bot?
[21:55] <juniour> ubottu
[21:55] <AlanBell> that is our bot
[21:55] <juniour> yep
[21:55] <AlanBell> oh, so you were trying to test ubottu
[21:55] <juniour> yep
[21:55] <AlanBell> it works. Thanks for the testing.
[21:56] <juniour> i am working on artificial intelligence
[21:56] <juniour> .
[21:56] <IdleOne> ubottu: has none
[21:56] <juniour> AlanBell can you help
[21:56] <juniour> to unban me
[21:56] <AlanBell> http://ubottu.com/factoids.cgi
[21:56] <AlanBell> that is a place you can find out about ubottu factoids
[21:57] <AlanBell> also look at the code for ubottu here https://launchpad.net/~ubuntu-bots
[21:57] <AlanBell> and you can message ubottu directly if you want
[21:57] <AlanBell> there is no need to do research in the #ubuntu channel
[21:58] <juniour> k
[21:58] <juniour> got
[21:58] <juniour> how do i unban my self
[21:59] <IdleOne> please try to respond with full sentences
[21:59] <IdleOne> You don't unban yourself
[21:59] <knome> juniour, start with listening
[22:00] <juniour> Knome i am listening
[22:02] <juniour> can any one unban
[22:02] <juniour> me
[22:02] <AlanBell> juniour: you have been removed from our channels on a number of occasions for flooding and disruptive language
[22:03] <juniour> AlanBell I think this is the first time
[22:05] <juniour> hi
[22:06] <juniour> AlanBell unban me
[22:06] <juniour> i wont repeat
[22:07] <knome> telling orders to ops won't help you, quite the opposite
[22:08] <juniour> knome i am not giving order
[22:08] <juniour> i have al written
[22:08] <juniour> i have also written i wont repeat
[22:08] <IdleOne> juniour: The ban will remain for now. Please come back in 24 hours and we can discuss then if the ban will last longer.
[22:10] <IdleOne> juniour: Please /part this channel now.
[22:53] <humans> good morning
[22:53] <humans> why im ops?


[03:32] <EagleScreen> when I build a source package, the pinentry window appears a fraction of second and the debsign fails by wrong passphrase
[03:32] <EagleScreen> gpg-agent problem
[03:36] <micahg> NCommand1r: hi, do you still intend to upload mame?
[08:31] <bilalakhtar> nigelb: Looking at your tweets about CakePHP, is it easy-to-use?
[08:32]  * bilalakhtar is annoyed to see a 14 MB ubuntu delta when merging
[08:34] <nigelb> bilalakhtar: Its pretty good, yes, but that depends on what you're looking for.
[08:38] <bilalakhtar> Fellow MOTUs:
[08:39] <bilalakhtar> I would like to advice everyone of you to please check the debdiff from the previous ubuntu version when uploading, to make sure there is no unnecessary change. This needs to be done in the case of ALL uploads (especially merges)
[08:41] <bilalakhtar> Package gnumeric had 14MB of Ubuntu delta, but later it turned out to be an unnecessary change that occured because the uploader called debuild (without any args) in the extracted source of the package before running debuild -S .
[08:41] <bilalakhtar> This is not the first time I have seen such a package
[08:42] <bilalakhtar> As for the gnumeric merge, after solving that problem, the delta was cut down to a mere 10 KB
[08:42] <bilalakhtar> 14 MB and 10 KB, the difference is huge
[09:12] <micahg> bilalakhtar: I would suggest you talk to a flavor dev before working on a merge for their packages
[09:12] <bilalakhtar> micahg: I did
[09:14] <bilalakhtar> micahg: oh no I didn't; I talked to the previous uploader and not an xubuntu-dev :( doing that now
[09:14] <micahg> bilalakhtar: ah, sorry, I see you weren't the last one to do the upload, but another MOTU was :_/
[09:14] <bilalakhtar> Bhavani, right? I talked to him, but to be sure, I will talk to an xubuntu-dev as well
[09:14] <micahg> bilalakhtar: I need to send a mail to the ML about this
[09:16] <bilalakhtar> micahg: to ubuntu-devel or ubuntu-motu?
[09:16] <micahg> bilalakhtar: ubuntu-motu
[09:16] <bilalakhtar> micahg: good, do send
[09:17] <micahg> bilalakhtar: yeah, it'll just be an awareness e-mail
[09:17] <bilalakhtar> micahg: about debdiffing or about contacting TIL?
[09:17] <micahg> bilalakhtar: neither
[09:17] <micahg> bilalakhtar: about packages that belong to packagesets
[09:17] <bilalakhtar> hmm
[09:17] <bilalakhtar> okay, do send it
[09:18] <bilalakhtar> Merging is a pain now
[09:18] <micahg> bilalakhtar: how so?
[09:18] <bilalakhtar> 95% of the remaining merges in universe are commented in MoM
[09:19] <micahg> bilalakhtar: there are other tasks besides merges that can be done
[09:19] <micahg> bilalakhtar: there are also main merges
[09:19] <bilalakhtar> micahg: I know, I fix FTBFS, SRU, NBS, but merging is the main need ATM
[09:20] <micahg> bilalakhtar: actually, the Universe merge list is very small ATM
[09:24] <bilalakhtar> micahg: That's due to a merging effort by debfx, coolbhavi and ari-tczew
[09:24] <micahg> bilalakhtar: indeed
[09:24] <bilalakhtar> and me as well, though I did very little
[09:28] <micahg> bilalakhtar: actually, I think it would be great if you can fix any of the remaining Debian RC bugs to help squeeze release
[09:28] <bilalakhtar> micahg: I can't get a list of open RC bugs anywhere
[09:28] <bilalakhtar> http://bugs.debian.org/release-critical/ has some fixed ones
[09:28] <micahg> bilalakhtar: http://udd.debian.org/bugs.cgi?release=squeeze&patch=&pending=ign&security=&notmain=&notsqueeze=&merged=ign&done=ign&outdatedsqueeze=&outdatedsid=&needmig=&newerubuntu=&fnewer=&fnewerval=7&rc=1&sortby=last_modified&sorto=asc&chints=1
[09:29] <bilalakhtar> thanks
[09:29] <bilalakhtar> bookmarked
[09:29] <micahg> bilalakhtar: great, if you can help squeeze release, then a lot of new upstream versions will flood into Debian, then we'll need lots of merging help :)
[09:30] <bilalakhtar> hmm
[09:30] <bilalakhtar> brb
[10:32] <bilalakhtar> So squeeze won't release until all RC bugs have been fixed?
[10:32] <geser> in theory
[10:33] <geser> in practice the release team will decide that the RC bug count is low enough for release
[10:34] <bilalakhtar> hmm
[18:45] <ari-tczew> who is responsible to @ubuntu.com aliases?
[18:45] <ebroder> ari-tczew: I think they're generated automatically based on your LP username and your primary e-mail on LP
[18:46] <ebroder> https://wiki.ubuntu.com/UbuntuEmail
[18:46] <ari-tczew> ebroder: I didn't ask how is adress created.
[18:46] <ari-tczew> ebroder: one server doesn't send mail on my alias
[18:47] <ebroder> https://answers.launchpad.net/launchpad/+faq/71 says "Ubuntu IS", which I assume is actually Canonical IS
[18:47] <ari-tczew> I have to get in touch with admins
[18:47] <ebroder> "Should you require more assistance, please email<EMAIL_ADDRESS>with a link to your Launchpad profile and the details of your problem."
[18:47] <micahg> ari-tczew: that's most likely an issue with the sending server then
[18:47] <micahg> ari-tczew: or on the receiving end, but not the alias
[18:48] <ari-tczew> micahg: I'm too small person to be a good person to contact with this server admin.  Canonical looks more seriously
[18:50] <micahg> ari-tczew: these's requests are usually taken seriously by administrators as it means their system isn't functioning properly
[18:51] <bilalakhtar> FYI fiodorland.canonical.com is responsible for forwarding mail to the respective addresses
[18:51] <bilalakhtar> (don't just type that in the address bar of your browser_
[18:51] <bilalakhtar> )
[18:51] <ari-tczew> micahg: because if server is sending mail to normal address, I got mail.
[18:52] <micahg> ari-tczew: to the same address it's being fwded to?
[18:52] <ari-tczew> micahg: yes
[18:53] <ari-tczew> so problem is with alias
[18:53] <ari-tczew> I'm afraid that more servers could not handle with @ubuntu.com aliases
[18:53] <micahg> ari-tczew: yeah, so open an RT ticket as ebroder suggested
[18:54] <bilalakhtar> ari-tczew: Appreciate the fact that one server has been chosen solely for this purpose :)
[18:54] <ari-tczew> lol
[18:55] <bilalakhtar> there is nothing funny in that
[18:56] <ari-tczew> bilalakhtar: s/lol/sigh
[18:56] <ari-tczew> better?
[18:56] <bilalakhtar> better
[19:30] <FTMichael> I'm using an application that needs its version updated in the repos.  (It's in Universe.)  How do I submit a bug report to request that the maintainer update it?
[19:31] <micahg> FTMichael: you can file a bug: ubuntu-bug logjam and request the upgrade
[19:32] <FTMichael> micahg: Excellent, thanks. :)  I didn't know if ubuntu-bug would have a space to request upgrade or if it would only find existing errors
[22:02] <ari-tczew> micahg: you might be interested in sponsor bug 682386
[22:03]  * micahg loves how people don't ask...
[22:03] <micahg> ari-tczew: thanks
[22:06] <ari-tczew> you're welcome
[22:12] <ari-tczew> micahg: you didn't comment this one so angelabad took merge
[22:13] <ari-tczew> I know that anyway he should ask, but this policy is dying.
[22:14] <micahg> ari-tczew: it's not as much a matter or right and wrong as it is of courtesy
[22:14] <micahg> ari-tczew: the assumption should be the TIL person will take the merge as it says on the top of the MoM page
[22:15] <ari-tczew> micahg: not always it works
[22:15] <micahg> ari-tczew: the problem isn't the policy
[22:17] <micahg> No one should have to waste their time to rush to MoM to comment that they'll take a merge, there is plenty to be worked on that contributors shouldn't be bored (including merges marked free to take on MoM)
[22:21] <ari-tczew> micahg: sometimes ago I had an idea, that MoM will send mail to TIL when merge is available. this information mail includes request to reply for confirm read. if receiver click yes, MoM will assign merge to TIL.
[22:22] <micahg> ari-tczew: that shouldn't be necessary
[22:22] <micahg> it shouldn't only be an issue when we're close to feature freeze
[22:23] <micahg> ari-tczew: you, bhavi, debfx, and bilalakhtar(sp?) have done a great job at reducing the amount of available merges in universe, it seems to be quite manageable now
[22:23] <ari-tczew> micahg: heh, contributors like to update merges ASAP, and I agree with that. If Debian has released a new package revision, we should merge ASAP. why be late?
[22:23] <ari-tczew> micahg: thanks
[22:24] <ari-tczew> It isn't done yet :P
[22:30] <micahg> ari-tczew: well, if someone has a particular interest in a package, that's great, but for the packages w/out a personal stake, it seems to make sense to only merge once or twice per cycle instead of 10 times (security fixes excluded of course), i.e. otherwise, I would think it's really hard to scale
[22:32] <ari-tczew> micahg: anyway, I disagree with you. You have your point of view, I have my point of view.
[22:33] <ari-tczew> how can I close multiple bugs in syncpackage?
[22:34] <micahg> ari-tczew: -b XXXXXXX,XXXXXX?
[22:34] <ari-tczew> micahg: syncpackage: Error: Invalid bug number(s) specified: 427308,680410
[22:34] <micahg> -b XXXXXXX -b XXXXXX?
[22:35] <ari-tczew> micahg: yeah, it works. However, this method to fix multiple bugs is strange. I should report bug to make it easier way. thanks
[23:43] <Laney> There's no point in merging for the sake of it
[23:52] <stgraber> Laney: +1


[10:14] <zman_> Hi
[10:14] <zman_> I have a bug - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/980519 refer here for the bug i'm facing
[10:14] <zman_> it feels like ubuntu kills the x session
[10:15] <zman_> most of the people that are facing this have nvidia on a 64-bit machine
[10:15] <zman_> can anyone help?