[04:45] -queuebot:#ubuntu-release- New: accepted golang-github-konsorten-go-windows-terminal-sequences [amd64] (eoan-proposed) [1.0.2-1]
[04:46] -queuebot:#ubuntu-release- New: accepted dogtag-pki [source] (eoan-proposed) [10.6.10-0ubuntu1]
[04:52] -queuebot:#ubuntu-release- New binary: dogtag-pki [amd64] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[04:54] -queuebot:#ubuntu-release- New binary: dogtag-pki [i386] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[04:54] -queuebot:#ubuntu-release- New binary: dogtag-pki [ppc64el] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[04:59] -queuebot:#ubuntu-release- New binary: dogtag-pki [arm64] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[05:00] -queuebot:#ubuntu-release- New binary: dogtag-pki [armhf] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: dogtag-pki [s390x] (eoan-proposed/universe) [10.6.10-0ubuntu1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [amd64] (eoan-proposed) [10.6.10-0ubuntu1]
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [armhf] (eoan-proposed) [10.6.10-0ubuntu1]
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [ppc64el] (eoan-proposed) [10.6.10-0ubuntu1]
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [arm64] (eoan-proposed) [10.6.10-0ubuntu1]
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [s390x] (eoan-proposed) [10.6.10-0ubuntu1]
[05:29] -queuebot:#ubuntu-release- New: accepted dogtag-pki [i386] (eoan-proposed) [10.6.10-0ubuntu1]
[09:29] -queuebot:#ubuntu-release- Unapproved: apt (disco-proposed/main) [1.8.0 => 1.8.1] (core)
[10:22] <cpaelzer> Hi, current eoan component mismatch on rdma-core is already covered by MIR https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1732892 - I outlined in an update (comment #27) what is needed and why it should be ok
[10:22] <ubot5`> Ubuntu bug 1732892 in rdma-core (Ubuntu) "[MIR] 18.04 rdma-core as replacement for older ibverbs code" [Undecided,Fix released]
[10:23] <cpaelzer> let me know if there is anything preventing that from being promoted ^^
[10:56] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (cosmic-proposed) [1.7.1]
[10:59] <LocutusOfBorg> ahasenack, I did some paperwork for https://bugs.launchpad.net/ubuntu/+source/kronosnet/+bug/1811139
[10:59] <ubot5`> Ubuntu bug 1811139 in kronosnet (Ubuntu) "[MIR] kronosnet" [Undecided,New]
[10:59] <LocutusOfBorg> I'm doing the corosync/pacemaker merge in bileto
[11:03] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.4]
[11:08] <LocutusOfBorg> xnox, good morning, I really would like to land this ticket soon https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3712/+packages
[11:08] <LocutusOfBorg> I did a lot of work in the last few days on that
[11:10] -queuebot:#ubuntu-release- Unapproved: python-apt (xenial-proposed/main) [1.1.0~beta1ubuntu<IP_ADDRESS> => 1.1.0~beta1ubuntu<IP_ADDRESS>] (core)
[11:13] -queuebot:#ubuntu-release- Unapproved: rejected python-apt [source] (xenial-proposed) [1.1.0~beta1ubuntu<IP_ADDRESS>]
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (xenial-proposed) [1.1.0~beta1ubuntu<IP_ADDRESS>]
[11:37] -queuebot:#ubuntu-release- Unapproved: rejected openjdk-lts [source] (disco-proposed) [11.0.3+7-2ubuntu1]
[11:50] -queuebot:#ubuntu-release- Unapproved: rejected python-glance-store [source] (disco-proposed) [0.28.0-0ubuntu1.1]
[12:17] -queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (disco-proposed) [3.32.1-2ubuntu1~19.04.1]
[12:35] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (disco-proposed) [3.32.1-1ubuntu1~19.04.1]
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (disco-proposed) [0.56.2-1ubuntu1~19.04.1]
[13:03] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1044.48] (kernel)
[13:15] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1044.48]
[13:31] <LocutusOfBorg> mmm librte-pmd-mlx4-18.11/amd64 unsatisfiable Depends: rdma-core
[13:31] <LocutusOfBorg> what?
[13:32] <LocutusOfBorg> this is funny :p src:rdma-core is in main, and binary:rdma-core is in universe... can we please have it propmoted?
[13:53] <cjwatson> LocutusOfBorg: done
[13:54] <LocutusOfBorg> coreycb, I'm doing sbd/pacemaker/dlm/crmsh updates/merges in bileto https://bileto.ubuntu.com/#/ticket/3712
[13:55] <LocutusOfBorg> can you help trying them and see if everything works as expected? thanks!
[13:55] <LocutusOfBorg> I really would like to end that bd-uninstallability nightmare
[13:55]  * LocutusOfBorg thanks cjwatson :)
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (disco-proposed) [2.2.10-4ubuntu1]
[14:03] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (cosmic-proposed) [2.2.8-5ubuntu1.3]
[14:05] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (bionic-proposed) [2.2.7-1ubuntu2.5]
[14:05] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.8]
[14:11] <ahasenack> LocutusOfBorg: ok, thanks! Do you have a personal interest in corosync/pacemaker, or are you just annoyed that it's stuck in migration for so long?
[14:11] <ahasenack> we planned to tackle the ha stack this cycle, bring it up to date
[14:19] <LocutusOfBorg> the latter :D
[14:19] <LocutusOfBorg> ahasenack, I was worried about the CVE fixes needing a rebase, I was doing it manually and then I found them on git master
[14:19] <LocutusOfBorg> so it became trivial
[14:19] <LocutusOfBorg> I also don't want a CVE fix being in -proposed pocket
[14:19] <LocutusOfBorg> and causing autopkgtest regressions (after it landed)
[14:20] <LocutusOfBorg> and yes, I'm tired of stuff not migrating :p
[14:20] <ahasenack> which cve?
[14:21] <LocutusOfBorg> CVE-2018-16877 CVE-2018-16878 CVE-2019-3885
[14:21] <LocutusOfBorg> they seems to be clearly making sbd sad on i386 https://autopkgtest.ubuntu.com/packages/sbd/eoan/i386
[14:21] <LocutusOfBorg> but I can't figure out why
[14:22] <LocutusOfBorg> I can land the bileto and see what happens with autopkgtestsuites if you want
[14:23] <LocutusOfBorg> [   54.481868] Buffer I/O error on dev dm-0, logical block 0, async page read
[14:23] <LocutusOfBorg> [  155.517792] sysrq: SysRq : Resetting
[14:23] <LocutusOfBorg> killing an autopkgtest machine with a CVE fix is not something I like! I'm not sure why security team let it go in -security pocket with such regression...
[14:27] -queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (xenial-proposed) [02.17-1.1ubuntu3.6]
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted gnome-bluetooth [source] (bionic-proposed) [3.28.0-2ubuntu0.2]
[14:55] -queuebot:#ubuntu-release- Unapproved: accepted apt [source] (disco-proposed) [1.8.1]
[14:57] <bdmurray> sil2100: Could you have a look at my u-r-u upload in D's SRU queue?
[15:02] <sil2100> bdmurray: ok o/
[15:03] -queuebot:#ubuntu-release- Unapproved: accepted scite [source] (bionic-proposed) [4.0.0-1ubuntu0.1]
[15:14] <sil2100> bdmurray: I assume the DistUpgrade.cfg.bionic thingy has been sanity-checked? I mean, I don't know the format of that, but the [KernelRemoval] Version=4.2.0 makes me wonder
[15:14] <sil2100> bdmurray: but on the other hand, I don't know what that means or does - but is that correct?
[15:15] <sil2100> bdmurray: DistUpgrade.cfg.xenial had Version=4.4.0
[15:15] <sil2100> bdmurray: so through analogy, I'd expect it to be 4.15.0, but maybe that's completely unrelated?
[15:16] <bdmurray> sil2100: hrm, I'll have a look at what section really does
[15:56] <sil2100> bdmurray: give me a poke once you find out
[15:57] -queuebot:#ubuntu-release- New binary: cpptest [amd64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[15:57] -queuebot:#ubuntu-release- New binary: cpptest [s390x] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[15:58] -queuebot:#ubuntu-release- New binary: cpptest [i386] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[15:58] -queuebot:#ubuntu-release- New binary: cpptest [ppc64el] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[16:00] -queuebot:#ubuntu-release- New binary: cpptest [arm64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[16:00] -queuebot:#ubuntu-release- New binary: cpptest [armhf] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[16:56] <sil2100> bdmurray: any luck with the KernelRemoval section?
[16:57] <sil2100> bdmurray: asking since I'll be going EOD soon
[16:58] <bdmurray> sil2100: if you look at DistUpgrade.cfg it hasn't been updated either. I'm testing an upgrade now to see if that's really needed.
[16:59] <bdmurray> sil2100: so you could let it through and maybe it'll get superseded.
[17:03] <sil2100> bdmurray: ACK o/ So probably it's unrelated to anything
[17:03] <sil2100> As long as you have it on your radar, it's all good
[17:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:<IP_ADDRESS>]
[17:04] <bdmurray> sil2100: I do now, thanks for noticing / reminding me.
[17:09] <sil2100> yw! Approved
[17:52] -queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu6 => 1.78ubuntu7] (core)
[17:57] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.21 => 2.525.22] (desktop-core)
[18:13] <bdmurray> vorlon: bug 1824862 has been verified if you think it warrants a speedy delivery to -updates
[18:13] <ubot5`> bug 1824862 in ubuntu-release-upgrader (Ubuntu Trusty) "Enable upgrading from 12.04 to 14.04 while keeping ESM enabled" [Undecided,Fix committed] https://launchpad.net/bugs/1824862
[18:18] <vorlon> bdmurray: lgtm, releasing, thanks
[18:21] <Eickmeyer> Still looking for someone to put on a MOTU hat to sponsor this guy: bug 1827288
[18:21] <ubot5`> bug 1827288 in Ubuntu Studio "[Needs Packaging] LSP-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1827288
[19:22] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1006.7] (no packageset)
[20:16] <vorlon> tjaalton: well, new dogtag-pki accepted through NEW, but fails autopkgtests
[20:21] <infinity> And Release Schedule is up at https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [amd64] (eoan-proposed) [2.0.0-2]
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [armhf] (eoan-proposed) [2.0.0-2]
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [ppc64el] (eoan-proposed) [2.0.0-2]
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [arm64] (eoan-proposed) [2.0.0-2]
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [s390x] (eoan-proposed) [2.0.0-2]
[20:24] -queuebot:#ubuntu-release- New: accepted cpptest [i386] (eoan-proposed) [2.0.0-2]
[20:37] -queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.37ubuntu0.4 => 0.37ubuntu0.5] (core)
[20:37] -queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.11 => 0.28ubuntu0.12] (core)
[20:37] -queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.12 => 0.18ubuntu0.13] (core)
[20:38] -queuebot:#ubuntu-release- Unapproved: distro-info-data (cosmic-proposed/main) [0.38ubuntu0.3 => 0.38ubuntu0.4] (core)
[20:41] -queuebot:#ubuntu-release- Unapproved: distro-info-data (disco-proposed/main) [0.39ubuntu2 => 0.39ubuntu2.1] (core)
[20:43] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.13]
[20:43] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.12]
[20:44] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (bionic-proposed) [0.37ubuntu0.5]
[20:44] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (disco-proposed) [0.39ubuntu2.1]
[20:44] -queuebot:#ubuntu-release- Unapproved: rejected libsmbios [source] (trusty-backports) [2.4.0-1~ubuntu14.04.1]
[20:44] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (cosmic-proposed) [0.38ubuntu0.4]
[20:44] -queuebot:#ubuntu-release- Unapproved: rejected dianara [source] (trusty-backports) [1.3.6-1~ubuntu14.04.1]
[20:44] -queuebot:#ubuntu-release- New: rejected ibmpmlinux [source] (trusty-proposed) [3.2.2-0ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: rejected navicli [source] (trusty-proposed) [<IP_ADDRESS>.51-0ubuntu<IP_ADDRESS>]
[20:44] -queuebot:#ubuntu-release- New: rejected libjwt [source] (trusty-proposed) [1.6.1-1]
[20:44] -queuebot:#ubuntu-release- New: rejected snapd-glib [source] (trusty-proposed) [1.12-0ubuntu1~14.04]
[20:47] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1006.7]
[21:05] <vorlon> Eickmeyer: why is lsp-plugins anative package?
[21:12] <tjaalton> vorlon: weird, works fine on my eoan machines.. I'll have a look tomorrow
[21:14] <tjaalton> ah, the TPS subsystem.. freeipa uses only CA & KRA
[21:52] <tsimonq2> infinity: Wiki index done: https://wiki.ubuntu.com/EoanErmine
[21:52] <tsimonq2> Ermine, cool.
[21:54] <tsimonq2> infinity: https://launchpad.net/ubuntu/eoan needs moar Ermine.
[21:54] <wxl> definitely not an eagle
[21:54] <tsimonq2> I was really hoping for Electric Eagle. Oh well.
[21:55] <wxl> thank god for that
[21:55] <tsimonq2> XD
[23:10] <Eickmeyer> vorlon: I'm working on your email. Is there a reason why lsp-plugins should not be a native package?
[23:10] <Eickmeyer> er, working on your comment in the bug report.
[23:10] <Eickmeyer> Really, the only thing that is confusing me now is the difference between native/non-native and when each is appropriate.
[23:10] <vorlon> Eickmeyer: native is never appropriate unless it is a package authored as part of the distribution
[23:11] <vorlon> if there is an upstream, you want non-native
[23:12] <Eickmeyer> vorlon: So, in this case, since the github repo (they don't use sourceforge anymore) is the upstream, this means I need to use non-native versioning (1.1.9-0ubuntu1)?
[23:12] -queuebot:#ubuntu-release- New binary: go-qrcode [amd64] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: go-qrcode [s390x] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-koofr-go-httpclient [amd64] (eoan-proposed/none) [0.0~git20180104.0378617-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: r-cran-partykit [amd64] (eoan-proposed/none) [1.2-3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: r-cran-partykit [s390x] (eoan-proposed/none) [1.2-3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [s390x] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-jmespath [amd64] (eoan-proposed/none) [1.4.0-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-socksify [amd64] (eoan-proposed/none) [1.7.1-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-strptime [s390x] (eoan-proposed/none) [0.2.3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: go-qrcode [ppc64el] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-renekroon-ttlcache [amd64] (eoan-proposed/none) [1.4.0+git20190429.e7780e9-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [ppc64el] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-opentracing [amd64] (eoan-proposed/none) [0.5.0-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-heroku-rollrus [amd64] (eoan-proposed/none) [0.0~git20190402.fde2a6b-1] (no packageset)
[23:12] <vorlon> Eickmeyer: yes, and you should use the upstream tarball
[23:12] -queuebot:#ubuntu-release- New binary: ruby-aws-eventstream [amd64] (eoan-proposed/none) [1.0.3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: r-cran-partykit [ppc64el] (eoan-proposed/none) [1.2-3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-strptime [ppc64el] (eoan-proposed/none) [0.2.3-1] (no packageset)
[23:12] <vorlon> Eickmeyer: (where available)
[23:13] -queuebot:#ubuntu-release- New binary: go-qrcode [arm64] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: go-qrcode [i386] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-partykit [i386] (eoan-proposed/none) [1.2-3-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [arm64] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [i386] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-serverengine [amd64] (eoan-proposed/none) [2.1.0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-strptime [arm64] (eoan-proposed/none) [0.2.3-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: go-qrcode [armhf] (eoan-proposed/none) [0.0~git20190110.dc11ecd-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [amd64] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-parallel-tests [amd64] (eoan-proposed/none) [2.28.0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-partykit [arm64] (eoan-proposed/none) [1.2-3-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-strptime [amd64] (eoan-proposed/none) [0.2.3-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: r-cran-psychotools [armhf] (eoan-proposed/none) [0.5-0-1] (no packageset)
[23:13] <Eickmeyer> vorlon: This is all the upstream tarball, as you can see. There's an upstream branch with the exact contents of the tarball and a pristine-tar branch with the tar.
[23:13] -queuebot:#ubuntu-release- New: accepted go-qrcode [arm64] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:13] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [armhf] (eoan-proposed) [0.5-0-1]
[23:13] -queuebot:#ubuntu-release- New: accepted r-cran-partykit [arm64] (eoan-proposed) [1.2-3-1]
[23:13] -queuebot:#ubuntu-release- New: accepted ruby-strptime [arm64] (eoan-proposed) [0.2.3-1]
[23:14] -queuebot:#ubuntu-release- New: accepted go-qrcode [armhf] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [amd64] (eoan-proposed) [0.5-0-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [i386] (eoan-proposed) [0.5-0-1]
[23:14] -queuebot:#ubuntu-release- New: accepted ruby-serverengine [amd64] (eoan-proposed) [2.1.0-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-partykit [i386] (eoan-proposed) [1.2-3-1]
[23:14] -queuebot:#ubuntu-release- New: accepted ruby-parallel-tests [amd64] (eoan-proposed) [2.28.0-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [arm64] (eoan-proposed) [0.5-0-1]
[23:14] -queuebot:#ubuntu-release- New: accepted ruby-strptime [amd64] (eoan-proposed) [0.2.3-1]
[23:14] -queuebot:#ubuntu-release- New: accepted go-qrcode [i386] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:14] -queuebot:#ubuntu-release- New: accepted golang-github-heroku-rollrus [amd64] (eoan-proposed) [0.0~git20190402.fde2a6b-1]
[23:14] -queuebot:#ubuntu-release- New: accepted golang-github-renekroon-ttlcache [amd64] (eoan-proposed) [1.4.0+git20190429.e7780e9-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-partykit [ppc64el] (eoan-proposed) [1.2-3-1]
[23:14] -queuebot:#ubuntu-release- New: accepted ruby-socksify [amd64] (eoan-proposed) [1.7.1-1]
[23:14] -queuebot:#ubuntu-release- New: accepted go-qrcode [ppc64el] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:14] -queuebot:#ubuntu-release- New: accepted r-cran-partykit [amd64] (eoan-proposed) [1.2-3-1]
[23:14] -queuebot:#ubuntu-release- New: accepted golang-github-koofr-go-httpclient [amd64] (eoan-proposed) [0.0~git20180104.0378617-1]
[23:14] -queuebot:#ubuntu-release- New: accepted ruby-aws-eventstream [amd64] (eoan-proposed) [1.0.3-1]
[23:15] -queuebot:#ubuntu-release- New: accepted go-qrcode [amd64] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:15] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [ppc64el] (eoan-proposed) [0.5-0-1]
[23:15] -queuebot:#ubuntu-release- New: accepted ruby-jmespath [amd64] (eoan-proposed) [1.4.0-1]
[23:15] -queuebot:#ubuntu-release- New: accepted ruby-strptime [ppc64el] (eoan-proposed) [0.2.3-1]
[23:15] -queuebot:#ubuntu-release- New: accepted r-cran-partykit [s390x] (eoan-proposed) [1.2-3-1]
[23:15] -queuebot:#ubuntu-release- New: accepted ruby-opentracing [amd64] (eoan-proposed) [0.5.0-1]
[23:15] -queuebot:#ubuntu-release- New: accepted r-cran-psychotools [s390x] (eoan-proposed) [0.5-0-1]
[23:15] -queuebot:#ubuntu-release- New: accepted go-qrcode [s390x] (eoan-proposed) [0.0~git20190110.dc11ecd-1]
[23:15] -queuebot:#ubuntu-release- New: accepted ruby-strptime [s390x] (eoan-proposed) [0.2.3-1]
[23:42] <Eickmeyer> vorlon: Here's a log from a failed auto test: https://launchpadlibrarian.net/421931673/buildlog_ubuntu-eoan-amd64.lsp-plugins_1.1.9-0~201905021445~ubuntu19.10.1_BUILDING.txt.gz
[23:53] <vorlon> Eickmeyer: that doesn't look to me like tests that need to be run manually, given that the test is failing to compile
[23:53] <vorlon> it looks to me like upstream bugs that should be fixed
[23:54] <Eickmeyer> vorlon: Then why, if I compile it manually or overridden, does it work?
[23:54] <Eickmeyer> Oh, upstream bug.
[23:54] <Eickmeyer> vorlon: In that case, is it okay to leave that overridden?
[23:54] <vorlon> how are you compiling it manually that it works?
[23:55] <vorlon> I would not be happy sponsoring upload of a new package whose upstream test suite fails to build
[23:57] <Eickmeyer> vorlon: Per the instructions on https://github.com/sadko4u/lsp-plugins. That works. Building the deb works.
[23:57] <Eickmeyer> The installed binaries work and are well tested.


[15:46] <rick_h__> jcastro: you all cook timetimes right?
[15:46] <rick_h__> jcastro: I've got a free blueapron invite and wanted to see if you're intersted
[15:46] <rick_h__> jrwren: same ^
[15:51] <jrwren> cook timetimes?
[15:51] <jrwren> rick_h__: thanks for offer. My wife is all groceries and from scratch and stuff, so I am out.
[15:52] <rick_h__> jrwren: yea, that's what we like. It's fresh stuff from scratch but always a surprise
[15:52] <jcastro> rick_h__: I've read both your sentences twice and still can't parse wtf you're talking about lol
[15:52] <rick_h__> jcastro: lol would you like a free meal from https://www.blueapron.com/
[15:52] <jcastro> but blueparon looks incredible
[15:52] <rick_h__> jcastro: to try it out
[15:53] <jcastro> I've seen services like this
[15:53]  * rick_h__ has invites
[15:53] <jcastro> I think that if we stopped wasting so much money eating out and being lazy
[15:53] <jcastro> this would work for us and save us money
[15:53] <jcastro> YES, invite me.
[15:53] <rick_h__> yea, that's our thing. It's cheaper than us eating out twice a week and better food/for us
[15:54] <rick_h__> been doing it for 6mo or so and my wife just loves it, but it involved manual cooking
[15:54] <rick_h__> so not everyone's cup of tea
[15:54] <jcastro> I don't mind cooking
[15:54] <jcastro> it's the prep and shopping and stuff that sucks
[15:55] <jcastro> "cook this all prepped for you like they do on TV" is the fun part
[15:55] <jcastro> I can see why this service is valuable
[15:55] <rick_h__> lol, well you still have to chop and dice and such
[15:55] <rick_h__> but what's awesome is they ship you the amount you need for the recipe
[15:55] <jcastro> well yeah
[15:55] <jcastro> but it's the right amount
[15:55] <rick_h__> so I don't have to buy 10lb of kale for one meal
[15:55] <jcastro> it seems better than "we better buy a huge box of XXX at costco in case we need it"
[15:55] <jcastro> right
[15:55] <rick_h__> yea
[15:55] <rick_h__> invite sent
[15:57] <rick_h__> anyone else wants a blueapron meal let me know
[15:58] <jcastro> I might need you to send one to my neighbor, I'll let you know, how many do you have?
[15:58] <rick_h__> 3 more after yours
[15:58] <rick_h__> and then I get a new one every few months or whatever
[16:01] <jcastro> ok I'll probably just sign up
[16:01] <jcastro> how is the food?
[16:03] <rick_h__> so I find we like 3 out of 4 meals pretty well
[16:03] <rick_h__> what's nice is that it's not stuff we'd normally do which is nice after making the same 10 things time after time
[16:07] <jrwren> lactose intollerant vegetarian wife makes these things practically impossible for us :[
[16:07] <jrwren> i'm a tiny bit envious.
[16:16] <greg-g> we were doing something similar out here for a few months, stopped because.. I forget why exactly, but it was nice
[16:16] <greg-g> oh, because it plus our CSA was too much food
[16:16] <rick_h__> greg-g: ah, cool
[16:39] <cmaloney> I'll note that rick_h__ didn't ask me. :)
[16:40] <rick_h__> cmaloney: :P I offered everyone
[16:40] <cmaloney> heh
[16:40] <jrwren> he knows you only eat pizza like a good coder/sysadmin?
[16:40] <rick_h__> but I also don't recall cmaloney going "I <3 cooking all the time"
[16:41] <cmaloney> That's because JoDee is amazed I can boil water without burning the house down
[16:41] <rick_h__> lol
[16:42] <cmaloney> Might hit you up later for an invite. Right now our schedule isn't great for eating at home.
[16:42] <rick_h__> cmaloney: gotcha
[16:43] <cmaloney> and I'd like to learn more of the art of turning stuff into meals.
[19:07] <brousch> rick_h__: Invite me to blueapron
[19:07] <rick_h__> brousch: email addr?
[19:08] <brousch><EMAIL_ADDRESS>[19:08] <rick_h__> brousch: sent
[19:09] <brousch> I do 90% of our cooking, and grocery shopping
[19:09] <brousch> The worst part for me is clean up. I don't mind prep
[19:09] <jrwren> my wife does all, but I usually clean up.
[19:10] <cmaloney> jrwren: ^^
[19:10] <brousch> We currently have organic veg delivered every 2 weeks
[19:10] <cmaloney> I'm the dishwasher
[19:14] <brousch> rick_h__: Thanks. I'm signed up for the trial
[19:15] <rick_h__> brousch: cool
[19:43] <jcastro> smoser: rick_h__: I have 2 roku 3's for sale if anyone is interested
[19:48] <rick_h__> jcastro: thanks but good here
[19:48] <rick_h__> jcastro: hey do you know how i could stream offline google play movies to a tv w/o internet?
[19:49] <jcastro> I know I can download onto a device
[19:49] <jcastro> I am not sure if you can chromecast to a TV from that though
[19:50] <jcastro> let me test, it'll take my device like 10 min to DL it though
[19:52] <rick_h__> yea you can't chromecast it
[19:52] <rick_h__> but rge roku mention reminded me i want to look into that for when i'm camping
[19:53] <jcastro> I wonder if you could do a tablet with an HDMI Out plug
[19:56] <rick_h__> so most don't support it. i used to do that with my nexus 7 or 10
[19:56] <rick_h__> has a cable for it
[20:03] <smoser> some apps can chromecast offline
[20:04] <smoser> jcastro, why are you seeling perfectly good roku?
[20:05] <jcastro> smoser: hardware upgrades so they won't be used, one is missing a roku controller but I got a generic controller that also controls the TV for wife-friendly usage
[20:09] <jrwren> i know how you can stream off line google play movies to a TV w/o internet. 1. Use Kodi. 2. torrent the same movie. 3. play the movie.
[20:09] <jrwren> *zing*
[20:10] <jrwren> sorry, I know that isn't helpful. I just couldn't resist.
[20:39] <jcastro> that still won't work without internet
[20:40] <jcastro> would work with plex with the autotranscoding though
[20:42] <jrwren> um, that works without itnernet. I've done it :p
[20:43] <jrwren> I mean... step 2 has to be done ahead of time, of course.
[20:43] <jcastro> heh
[20:44] <jcastro> rick_h__: Adam got a piece of junk android tablet at Fry's last sprint for $40 with a mini sd card slot
[20:45] <jcastro> http://smile.amazon.com/Proscan-Android-Processor-Lollipop-Certified/dp/B018YGD846/ref=sr_1_1?ie=UTF8&qid=1458247484&sr=8-1&keywords=cheap+android+tablet
[20:45] <jcastro> aisrael: ^^^ like that right?
[20:46] <aisrael> This is the one: http://www.microcenter.com/product/448360/a745_tablet
[20:47] <jcastro> Marshmellow has a new feature
[20:47] <jcastro> where you can slap an sd card in
[20:47] <jcastro> and it will use that + the internal storage as one virtual disk
[20:48] <jcastro> that way you don't have to manually select where to put content and apps, etc.
[20:48] <jcastro> so like, one of these with marshmellow would be a perfect syncing machine for the google content
[20:49] <jrwren> i have something like that. mine is absolute garbage. at least that one has lollipop
[20:49] <jcastro> it's a 40 dollar tablet
[20:49] <jcastro> so yeah, heh
[20:50] <jrwren> yeah.
[20:51] <jrwren> mine was $60, a copule years ago. I thought, even for $60, I'll be able to use it for something... but no. it really is worthless. basic web browsing... tooo slow.  even youtube is too slow. it can play the video sure, but the app navigation and search is so slow its useless.
[20:51] <jrwren> Maybe I'm just too demanding.
[20:51] <jcastro> wait
[20:51] <jcastro> is today st. patty's day?
[20:52] <jrwren> paddy not patty.
[20:52] <jrwren> yes, it is.
[20:52] <jrwren> http://paddynotpatty.com
[20:52] <jcastro> why have we not been drinking all day?
[20:53] <jrwren> I've cut back on drinking a lot.
[20:53] <aisrael> It's never too late to start
[20:53] <jrwren>  I'm getting over a terrible cold.
[20:55] <jcastro> we had bad colds a few weeks ago
[22:19] <cmaloney> jcastro: https://www.youtube.com/watch?v=aSC9A5bPhU4


 Hello, where can I find which version of xscreenserver comes with the latest Lubuntu?
 context:
 https://discourse.lubuntu.me/t/screen-saver-shows-my-desktop-before-login/3390/3
 "[telegram] <Rodrigo> Hello..." <- 5.45 in 22.04 and 6.02 in 22.10
[11:13] <guiverc> @Rodrigo, I'd use `rmadison xscreensaver` to view package versions for Ubuntu releases; but if using a browser or for pasting here I'd likely use https://packages.ubuntu.com/search?keywords=xscreensaver&searchon=names&suite=all&section=all  to view package versions for each release
[11:14] <guiverc> your post on discourse is 5 releases ago (20.04, 20.10, 21.04, 21.10, 22.04 being latest)
[11:16] <guiverc> yeah I've see the issue you describe before... but I can't recall why (there were a number of reasons if I remember correctly; for some it was graphics module (driver) being used; .. but issue was resolved (for the most part anyway) on later releases with later software..
[11:17] <guiverc> you may find just switching to the HWE kernel will also help (ie. using later kernel modules, aka. drivers) - but that's guess only ... I can't recall clearly as 20.04 was a lot of releases ago sorry
 cool, thanks a lot as always guys
[14:38] <da_youngzta> ops!


[06:42] <dholbach> good morning
[06:47] <Guest48666> Good morning dholbach.
[06:47] <Guest48666> Whoops.
[06:47] <Guest48666> I'm a guest!
[06:48] <iulian> Not anymore.
[06:52] <dholbach> hey Guest48666!


[05:46] <ssdd_> Hello. How I can write email to support team
[07:27] <mup> Bug #1784562 opened: Failing to install wichita (P8) <curtin (Ubuntu):New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1784562>
[07:40] <mup> Bug #1784562 changed: Failing to install wichita (P8) <curtin (Ubuntu):New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1784562>
[07:43] <mup> Bug #1784562 opened: Failing to install wichita (P8) <curtin (Ubuntu):New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1784562>
[09:25] <mup> Bug #1784562 changed: Failing to install wichita (P8) - sgdisk fails to create the partition on /dev/md0 <curtin (Ubuntu):Incomplete> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1784562>
[17:13] <ivve> hey guys, how do i find the password for the maas postgres?
[17:13] <ivve> is the secret saved somewhere?
[17:16] <ivve> nvm
[19:59] <mup> Bug # changed: 1622105, 1693299, 1696771, 1707216, 1740442, 1762461, 1770538, 1771885, 1772679, 1772906, 1773385, 1773387, 1773437, 1773454, 1773456, 1773698, 1774016,
[19:59] <mup> 1774024, 1774025, 1774026, 1774422, 1774424, 1774495, 1774538, 1775099, 1775728, 1776604, 1777019, 1777742, 1777924, 1778710, 1779712, 1781275, 1782230


[18:43] <ibeardslee> morning
[18:43] <ojwb> morning
[19:27] <chilts> morning
[19:41] <mwhudson> yes!
[19:41] <mwhudson> last one of the year, in some sense
[19:42] <ajmitch> morning
[19:42] <ajmitch> does the world end on the 21st NZ time, or what timezone does it fall in?
[19:44] <ibeardslee> mayan time
[20:00] <Atamira> morning


[17:10] <holmanb> minimal: sorry, missed your comment before. Adding support in eni seems reasonable, at least without digging into details too much. Are you looking for any input/thoughts in particular?
[17:36] <minimal> holmanb: I guess I'm wondering about the impact of this on other renderers and why things like IPv6 Privacy Extensions are not currently catered for in network config v2
[17:55] <minimal> I guess I'm thinking about IPv6 network configurations that are perhaps not typical in cloud environments but may be in VM or physical host environments
[21:09] <axino> hey there, cloud-init is giving me https://pastebin.ubuntu.com/p/mNBzMpkRdP/ on a physical machine that's getting commissioned by MAAS. Apparently it's not breaking anything though.
[21:09] <axino> happy to provide debugging output to help understand this
[21:41] <blackboxsw> axino: sorry to have missed this. Does `sudo cloud-init  schema --system` present an error due to invalid YAML being provided as user-data?
[21:41] <axino> blackboxsw: hi o/ looking
[21:45] <axino> blackboxsw: Cloud config schema errors: format-l1.c1: File None needs to begin with "#cloud-config"
[21:45] <axino> blackboxsw: that's all this command gives me
[21:52] <blackboxsw> axino: meh, ok user-data provided to this instance isn't #cloud-config specifically (could be b64encoded or scripts or something else ) you can see it with: sudo cloud-init query userdata
[21:53] <blackboxsw> that said, the traceback you mentioned is making me think either the network-config.yaml provided to cloud-unit on this instance is bogus YAML or user-data.
[21:54] <axino> blackboxsw: yeah it's a shell script with a payload
[21:54] <blackboxsw> +1 ok we should have a bug for cloud-niit query being smarter/more informative about non-#cloud-config user-data.
[21:55] <blackboxsw> that said, the mac address provided would likely need to be quoted to avoid YAML parse errors for yaml parse errors I think
[21:57] <axino> blackboxsw: so I can extract this, and it gives me a curtin directory with subdirs
[21:58] <axino> blackboxsw: and the MAC address generating the messages appears only in curtin/configs/config-003.cfg
[21:58] <axino> blackboxsw: which looks like a netplan config with a "network_commands" block appended
[22:00] <axino> blackboxsw: the error appears 3 times, and the MAC address as well, so it looks like a good candidate
[22:07] <blackboxsw> axino: is there a /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg  on the system?
[22:07] <blackboxsw> and is that content shareable(not sensitive)>
[22:07] <blackboxsw> ?
[22:08] <blackboxsw> at least I think that's where curtin via MAAS leaves network config artifacts for cloud-init to apply
[22:09] <blackboxsw> if network config version provided by MAAS is `version: 2` recent cloud-init should actually pass through that content without trying to load the YAML at all, so I wouldn't have expected that error
[22:14] <axino> blackboxsw: OK I can't answer that now, all the nodes are deployed
[22:14] <axino> blackboxsw: I'll try to circle back
[22:15] <blackboxsw> axino: the other error in that log is reminiscent  of the dbus race w/ netplan apply per this bug https://bugs.launchpad.net/cloud-init/+bug/1997124
[22:15] -ubottu:#cloud-init- Launchpad bug 1997124 in cloud-init "Netplan/Systemd/Cloud-init/Dbus Race" [High, In Progress]
[22:16] <blackboxsw> James is already toying with systemd dependency changes to avoid the  activators.py[WARNING]: Running ['netplan', 'apply'] resulted in stderr output: Failed to connect system bus: No su
[22:16] <blackboxsw> ch file or directory
[22:16] <blackboxsw> in this PR https://github.com/canonical/cloud-init/pull/1937
[22:16] -ubottu:#cloud-init- Pull 1937 in canonical/cloud-init "Order cloud-init.service after dbus.socket on Ubuntu" [Open]
[22:17] <blackboxsw> but I think there is a secondary problem with the YAML processing as you mentioned
[22:17] <axino> OK
[22:18] <waldi> bah, can't commet. but how does ordering after dbus.socket help`
[22:19] <waldi> even if, this should be sockets.target. but dbus.socket does not mean it can run dbus yet
[22:21] <waldi> and on debian/ubuntu, there is a cycle between dbus.service and cloud-init if you hold it wrong enough
[22:22] <blackboxsw> systemd-networkd talks to dbus I believe and "netplan apply" on ubuntu systems writes out configuration that is ultimately rendered by networkd
[22:23] <waldi> systemd-networkd, as all systemd services, can connect to dbus late, so does not depend on dbus
[22:25] <waldi> as dbus.service depends on sysinit.target, this reorders the whole startup
[22:29]  * blackboxsw starts looking at wonders about cloud-init services only blocking on presence of an active dbus.socket when we happen to need to run `netplan apply` (which happens only for datasources which are only detected after network is already up and have netplan for their network config 'backend').
[22:30] <blackboxsw> waldi: we don't want After=dbus.service but were thinking about After=dbus.socket ... trying to see if that dep-chain still pulls us into After=sysinit.target
[22:33] <blackboxsw> meh same prob
[22:35] <blackboxsw> root@dev-f:~# systemctl show -p Requires,Wants,Before,After dbus.socket
[22:35] <blackboxsw> Requires=-.mount system.slice sysinit.target
[22:35] <blackboxsw> Wants=
[22:35] <blackboxsw> Before=shutdown.target dbus.service systemd-logind.service polkit.service sockets.target accounts-daemon.service
[22:35] <blackboxsw> After=-.mount system.slice sysinit.target
[22:36] <waldi> you have a socket, try to connect to it and systemd schedules a transaction to start the associated service. at this stage it can only kill the connection or wait until the service is up and running. dbus.service depends on sysinit.target
[22:41] <waldi> the only thing that fixes all those problems is to move dbus.socket/.service before sysinit.target
[22:42] <waldi> debian currently have that problem with firewalld, because it wants to start before network, but after dbus. so sysinit -> dbus -> firewalld -> network -> cloud-init -> sysinit
[22:49] <blackboxsw> thanks waldi for chiming in. hrm. right, ok it looks like the option of re-ordering dependencies for very early cloud-init boot stages (cloud-init.service or cloud-init-local.sevice) to depend on dbus.socket/service is high risk and impactful to overall general boot times and systemd ordering cycles (I had missed the After-sysinit.target in those cases).
[22:50] <blackboxsw> the alternative we could take in cloud-init for the specific case where the datasource is detected after network is up (in init-network stage via "cloud-init.service")
[22:51] <blackboxsw> is to actually just defer the 'netplan apply' call (to apply network configuration) to cloud-config.service
[22:52] <blackboxsw> which is scheduled After=sysinit.target
[22:52] <waldi> why does netplan apply need dbus?
[22:53] <waldi> hmpf, even service reload is implemeted via "networkctl reload"
[22:54] <blackboxsw> I don't think it's netplan per-se, but rather systemd-networkd is complaining about inability to talk to the socket
[22:55] <blackboxsw> but I'm digging in both netplan && systemd to double-check that
[22:55] <waldi> unlikely. systemd-networkd.service does not depend on dbus.*. this is networkctl
[22:56] <waldi> anyway, sleep
[22:57] <blackboxsw> yep https://github.com/canonical/netplan/blob/main/netplan/cli/utils.py#L116
[22:58] <blackboxsw> thx again. will poke at a more reasonable solution for this.
[23:14] <blackboxsw> or, simplest interim solution, we could retry netplan apply in cases where dbus.socket isn't up yet and cloud-init hits this specific error condition


[08:21] <blaze> I see some dangling processes after logging out from plasma session
[08:27] <blaze> another thing some process even prevents my computer from shutting down directly, I have to wait 1.5 min before the actual shutdown happens every time
[08:28] <blaze> but there's a workaround, I can log out from plasma session and __then__ do a shutdown
[08:29] <blaze> that way it works as it should
[08:33] <blaze> aaand it is reproducible for me on a fresh install of hirsute
[12:00] <RikMills> kio-fuse is in the debian NEW queue
[12:36] <blaze> Hmmm, I was building and testing it quite some time ago
[12:41] <RikMills> it has had betas for some time. now an official stable release
[12:43] <blaze> cool
[12:59] <BluesKaj> Happy New Year folks!
[13:50] <sorcerer> happy new year!
[19:59] <Eickmeyer[m]> Hey all! I'm applying for MOTU, would appreciate comments or testimonials: https://wiki.ubuntu.com/Eickmeyer/MOTUApplication
[20:37] <blaze> I see http://feverfew.home.blog/?p=62
[23:53] <valorie> Eickmeyer[m]: cool!


[07:44] <marcustomlinson> morning?
[07:54] <duflu> Afternoon marcustomlinson, but good morning :)
[07:54] <marcustomlinson> :)
[08:02] <Laney> hi hi
[08:04] <marcustomlinson> hey Laney
[08:11] <Laney> hey marcustomlinson, you good?
[08:11] <marcustomlinson> Laney: yeah alright. tired. glad it's friday. you?
[08:11] <Laney> GunnarHj: ahoy, I'm seeing syncs for ibus-avro; is there any reason not to backport those instead?
[08:11] <Laney> I'm alright
[08:12] <Laney> was going to have a lie in, and then the Fedex guy turned up at 07:30
[08:12] <Laney> boooo
[08:14] <marcustomlinson> they always come at the wrong time
[08:14] <marcustomlinson> stop being wrong Fedex
[08:15] <GunnarHj> Laney: The reason would be three more uploads and that I'm disinclined to ask mapreri again. The difference in practice is the summary in an AppStream file and not important enough to justify more work IMO.
[08:15] <Laney> GunnarHj: I'll just run backportpackage :-)
[08:15] <Laney> one of them got (wrongly?) rejected anyway
[08:16] <GunnarHj> Laney: That *must* be wrongly. I have tested the stable releases back and forth a lot (via PPAs).
[08:17] <GunnarHj> Laney: Any link to a build log?
[08:17] <Laney> no, they get built after acceptance
[08:18] <GunnarHj> Ah, *rejected* !!?
[08:18] <duflu> Morning Laney
[08:18] <Laney> can't see why unfortunately
[08:18] <Laney> but it's OK, I'm going to upload -3
[08:18] <Laney> hey duflu
[08:27] <Laney> done donne donnneeeeeeee dooooonnnnnneeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[08:28] <GunnarHj> Laney: Seems so. :) Thanks! (Btw, don't forget the binaries in the new queue in a few minutes.)
[08:28]  * Laney knows
[08:29] <Laney> really I was putting off working on the gnome-settings-daemon merge for a few minutes
[11:39] <Laney> FML
[11:39] <Laney> almost every patch in g-s-d is conflicting this time
[15:01] <Laney> og.gnome.SettingsDaemon.Power
[15:01] <Laney> one tiny letter, and it breaks starting up the session
[15:02] <Laney> unreasonable
[16:04] <marcustomlinson> oMg


[14:21] <rtg> infinity_, please reject the linux-snapdragon package. looks like we might take a different direction.
[15:57] <jderose> cyphermox: you have a chance to look at this yet? https://code.launchpad.net/~jderose/ubiquity/fix-1539266/+merge/284364
[16:01] <cyphermox> jderose: looks fine, I'll merge it
[16:02] <jderose> cyphermox: much thanks!
[16:08] <jderose> cyphermox: how long to you think it will take for this to land in a 14.04.4 daily ISO? I'll test this as soon  as the ISO is available, will report back with the results.
[16:10] <cyphermox> I don't know, it will also be up to the SRU team to review it, and then the usual SRU time.
[16:10] <cyphermox> (provided it's tested quickly enough)
[16:12] <jderose> cyphermox: ah gotcha, so this change will go through the normal SRU process? makes sense considering how late in the game it is. thanks!
[16:23] <cyphermox> well, things have to go through the normal SRU process anyway
[18:54] <infinity> jderose: Accepted.  Should be in the next daily.
[18:54] <jderose> infinity: awesome, thanks!
[18:59] <infinity> jderose: Please give it a spin on old and new hardware and verify it ASAP once you can, we're getting close to the point release.
[19:01] <jderose> infinity: will do. i already checked it (by copying my changed file over the installed file) on hardware that uses SMBIOS newer than 2.8
[19:01] <jderose> infinity: as soon as i can, i'll also double check it on older hardware to make sure there are no regressions because of this change, and will double check it on newer hardware that needed this fix
[19:01] <cyphermox> infinity: could you please also review multipath-tools and parted?
[19:01] <infinity> cyphermox: In a bit, yeah.  Breakfasting. :)
[19:01] <cyphermox> yikes
[19:02] <cyphermox> breakfasting actual breakfast, or shawarma? ;)
[19:03] <infinity> cyphermox: Oatmeal Crisp!
[19:03] <cyphermox> nummy


[10:40] <FabriceMG> superm1, after update , mythtv-setup work now , many thx
[15:51] <williammanda> Hello
[15:51] <williammanda> anyone have vaapi working with sandy bridge?
[15:54] <williammanda> anyone having a problem  with scanning for videos....error...failed to scan SG video hosts...using the latest master?
[16:04] <williammanda>  or should I say the latest mythbuntu repo?
[17:20] <mrand> williammanda: if by latest master you mean 0.25, breakages are not surprising... it's currently undergoing heavy last minute development and bug fixes.
[17:21] <williammanda> yes I understand that but wanted other user input....with the same error
[17:22] <mrand> ah.  Might ask in #mythtv-users... much larger sample size there.
[21:27] <superm1> Fabricemg cool good to hear