[01:02] -queuebot:#ubuntu-release- Unapproved: python-pip (xenial-proposed/universe) [8.1.1-2ubuntu0.4 => 8.1.1-2ubuntu0.5] (no packageset)
[03:43] <hellsworth> Laney: the added copy timeout definitely helped and icu passed
[03:43] <hellsworth> autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64
[03:44] <hellsworth> so the only failure i see now for LO arm64 is the uicheck test timing out.. is this a build issue too?
[03:44] <hellsworth> https://paste.ubuntu.com/p/C6gzvvmW4p/
[03:45] <hellsworth> that was taken from the openjdk-lts run that ran for 11.5 hours
[03:45] <hellsworth> full log<EMAIL_ADDRESS>[03:46] <hellsworth> marcustomlinson: could you please rerun the openjdk-lts test and see if it passes? maybe it just needs another run.. i'm not sure what else to do
[03:46] <hellsworth> http://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=openjdk-lts/11.0.6%2B10-2ubuntu2
[03:50] <hellsworth> also marcustomlinson could you please rerun the redland test: http://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=redland/1.0.17-1.1ubuntu1
[05:14] -queuebot:#ubuntu-release- New binary: ponyorm [amd64] (focal-proposed/universe) [0.7.11-1] (no packageset)
[06:14] -queuebot:#ubuntu-release- New binary: gazebo [amd64] (focal-proposed/universe) [9.12.0+dfsg-1] (no packageset)
[06:32] -queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (focal-proposed/universe) [20.04.0] (ubuntukylin)
[06:35] <cpaelzer> hello archive admins - there are new corosync and pacemaker uploades hanging in the new queue
[06:36] <cpaelzer> the former adds vqsync and the latter split out libpacemaker
[06:36] <cpaelzer> both is intentional and expected
[06:36] <cpaelzer> it would be great if someone could accept those in the focal new queue so that the tests kick off and rafaeldtinoco can later (when he gets online) on check those results
[06:38] <cpaelzer> not sure who might still (vorlon) already (doko, apw) be around to process that ^^
[06:39] <vorlon> amazing timing
[06:40] <vorlon> cpaelzer: are these both changes that came from Debian?
[06:40] -queuebot:#ubuntu-release- New: accepted anet [armhf] (focal-proposed) [0.4.2-2]
[06:40] -queuebot:#ubuntu-release- New: accepted liblog4ada [arm64] (focal-proposed) [1.3.1.b6dafb49-2]
[06:40] -queuebot:#ubuntu-release- New: accepted ponyorm [amd64] (focal-proposed) [0.7.11-1]
[06:40] -queuebot:#ubuntu-release- New: accepted gazebo [amd64] (focal-proposed) [9.12.0+dfsg-1]
[06:40] -queuebot:#ubuntu-release- New: accepted liblog4ada [armhf] (focal-proposed) [1.3.1.b6dafb49-2]
[06:41] -queuebot:#ubuntu-release- New: accepted anet [arm64] (focal-proposed) [0.4.2-2]
[06:41] -queuebot:#ubuntu-release- New: accepted golang-github-dreamitgetit-statuscake [amd64] (focal-proposed) [0.0~git20190809.9d26ad7-1]
[06:41] -queuebot:#ubuntu-release- New: accepted golang-github-phpdave11-gofpdi [amd64] (focal-proposed) [1.0.8+git20190928.81a2921-1]
[06:41] -queuebot:#ubuntu-release- New: accepted liblog4ada [amd64] (focal-proposed) [1.3.1.b6dafb49-2]
[06:41] -queuebot:#ubuntu-release- New: accepted liblog4ada [s390x] (focal-proposed) [1.3.1.b6dafb49-2]
[06:41] -queuebot:#ubuntu-release- New: accepted golang-github-apparentlymart-go-dump [amd64] (focal-proposed) [0.0~git20190214.042adf3-1]
[06:41] -queuebot:#ubuntu-release- New: accepted golang-github-svanharmelen-jsonapi [amd64] (focal-proposed) [1.0.0+git20180618.0c0828c-1]
[06:41] -queuebot:#ubuntu-release- New: accepted golang-github-goji-httpauth [amd64] (focal-proposed) [0.0~git20160601.2da839a-1]
[06:41] -queuebot:#ubuntu-release- New: accepted liblog4ada [ppc64el] (focal-proposed) [1.3.1.b6dafb49-2]
[06:41] -queuebot:#ubuntu-release- New: accepted anet [amd64] (focal-proposed) [0.4.2-2]
[06:41] -queuebot:#ubuntu-release- New: accepted anet [s390x] (focal-proposed) [0.4.2-2]
[06:41] -queuebot:#ubuntu-release- New: accepted anet [ppc64el] (focal-proposed) [0.4.2-2]
[06:43] <cpaelzer> vorlon: yes we didn't add them - they are in debian already
[06:44] <cpaelzer> => https://paste.debian.net/1132339/
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [amd64] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [armhf] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [ppc64el] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [amd64] (focal-proposed) [2.0.3-3ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [armhf] (focal-proposed) [2.0.3-3ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [ppc64el] (focal-proposed) [2.0.3-3ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [arm64] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [s390x] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [i386] (focal-proposed) [2.0.3-3ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted corosync [i386] (focal-proposed) [3.0.3-2ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [s390x] (focal-proposed) [2.0.3-3ubuntu1]
[06:46] -queuebot:#ubuntu-release- New: accepted pacemaker [arm64] (focal-proposed) [2.0.3-3ubuntu1]
[06:47] <cpaelzer> thank you vorlon, that allows rafaeldtinoco to later hit the ground running :-)
[06:47] -queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (focal-proposed) [20.04.0]
[06:48] <cpaelzer> vorlon: BTW I have prepared and tested the staged uploads to un-break libnbd/nbdkit
[06:48] <cpaelzer> started the first of three uploads a few minutes ago
[06:48] <cpaelzer> just mentioning as we discussed about it a few days ago
[06:50] <vorlon> \o/
[07:08] -queuebot:#ubuntu-release- New binary: adacgi [amd64] (focal-proposed/universe) [1.6-23] (no packageset)
[07:08] -queuebot:#ubuntu-release- New binary: adacgi [ppc64el] (focal-proposed/universe) [1.6-23] (no packageset)
[07:10] -queuebot:#ubuntu-release- New binary: adacgi [s390x] (focal-proposed/universe) [1.6-23] (no packageset)
[07:10] -queuebot:#ubuntu-release- New binary: adacgi [arm64] (focal-proposed/universe) [1.6-23] (no packageset)
[07:11] -queuebot:#ubuntu-release- New binary: adacgi [armhf] (focal-proposed/universe) [1.6-23] (no packageset)
[07:11] -queuebot:#ubuntu-release- New: accepted adacgi [amd64] (focal-proposed) [1.6-23]
[07:11] -queuebot:#ubuntu-release- New: accepted adacgi [armhf] (focal-proposed) [1.6-23]
[07:12] -queuebot:#ubuntu-release- New: accepted adacgi [s390x] (focal-proposed) [1.6-23]
[07:12] -queuebot:#ubuntu-release- New: accepted adacgi [arm64] (focal-proposed) [1.6-23]
[07:12] -queuebot:#ubuntu-release- New: accepted adacgi [ppc64el] (focal-proposed) [1.6-23]
[08:15] -queuebot:#ubuntu-release- New binary: supysonic [amd64] (focal-proposed/universe) [0.5.0+ds-1] (no packageset)
[08:39] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1003.3]
[08:39] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1003.3]
[08:52] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu20]
[08:52] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu20]
[09:38] <rbalint> sil2100, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/379876 for systemd?
[09:38] -queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu<IP_ADDRESS> => 12.2.13-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[09:47] <sil2100> rbalint: looking
[09:50] <sil2100> rbalint: done
[09:50] <rbalint> sil2100, thanks!
[10:00] -queuebot:#ubuntu-release- Unapproved: ceph (eoan-proposed/main) [14.2.4-0ubuntu<IP_ADDRESS> => 14.2.7-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[11:13] -queuebot:#ubuntu-release- New binary: php-nikic-fast-route [amd64] (focal-proposed/universe) [1.3.0-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [amd64] (focal-proposed/universe) [0.9.1-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [ppc64el] (focal-proposed/universe) [0.9.1-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [s390x] (focal-proposed/universe) [0.9.1-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [arm64] (focal-proposed/universe) [0.9.1-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [armhf] (focal-proposed/universe) [0.9.1-1] (no packageset)
[11:35] -queuebot:#ubuntu-release- New: accepted php-nikic-fast-route [amd64] (focal-proposed) [1.3.0-1]
[11:35] -queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [arm64] (focal-proposed) [0.9.1-1]
[11:35] -queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [ppc64el] (focal-proposed) [0.9.1-1]
[11:35] -queuebot:#ubuntu-release- New: accepted supysonic [amd64] (focal-proposed) [0.5.0+ds-1]
[11:35] -queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [amd64] (focal-proposed) [0.9.1-1]
[11:35] -queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [s390x] (focal-proposed) [0.9.1-1]
[11:35] -queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [armhf] (focal-proposed) [0.9.1-1]
[11:41] -queuebot:#ubuntu-release- New: accepted ovn-octavia-provider [source] (focal-proposed) [0.0.1~git2020022414.000049c-0ubuntu1]
[11:41] -queuebot:#ubuntu-release- New: accepted python-edgegrid [source] (focal-proposed) [1.1.1-0ubuntu1]
[11:43] -queuebot:#ubuntu-release- New binary: python-edgegrid [amd64] (focal-proposed/none) [1.1.1-0ubuntu1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: ovn-octavia-provider [amd64] (focal-proposed/none) [0.0.1~git2020022414.000049c-0ubuntu1] (no packageset)
[12:00] <doko> the mpi4py/ppc64el issues is known upstream: https://bitbucket.org/mpi4py/mpi4py/issues/127/test-failure-with-openmpi-on-ppc64le
[12:01] -queuebot:#ubuntu-release- New: accepted ovn-octavia-provider [amd64] (focal-proposed) [0.0.1~git2020022414.000049c-0ubuntu1]
[12:01] -queuebot:#ubuntu-release- New: accepted python-edgegrid [amd64] (focal-proposed) [1.1.1-0ubuntu1]
[12:07] <Laney> I'm going to kill those in progress libreoffice/arm64 runs against icu
[12:07] <Laney> there have been altogether too many retries of that one
[12:08] <Laney> locutus_: you already got a pass there, so not sure why you have another one in progress, also could you please stop using all-proposed randomly?
[12:10] <Laney> gone
[12:10] <seb128> Laney, http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64 icu got 3 successful retries so yeah, no need to extra ones still
[12:10] <Laney> indeed
[12:11] <Laney> both of the runs in progress were from people who have green ticks there ;-)
[12:12] <seb128> Laney, the timeout increase was not specific to libreoffice right?
[12:12] <Laney> no
[12:12] <Laney> don't know of any other package that was affected by that problem though
[12:13] <Laney> not much that's as big as libreoffice to copy about
[12:13] <seb128> probably not
[12:13] <seb128> right
[12:13] <seb128> I was just curious, I don't have a specific case/example :)
[12:13] <Laney> okey
[12:24] <locutus_> Laney, it was a mistake due to wrong trigger, or me refreshing the page, sorry for that
[12:24] <Laney> that's ok
[12:24] <Laney> it just matters more for libreoffice since that creates more load than most things
[12:24] <locutus_> doesn't use of all-proposed make all of them become green with just one test?
[12:25] <Laney> all of what?
[12:25] <locutus_> if the proposed version is fixed, isn't this the only way to avoid useless rebuilds?
[12:25] <locutus_> sorry let me provide an example
[12:26] <locutus_> openjdk-14 is libreoffice/bad/arm64 same for redland/bad/arm64 openjdk-lts/bad/arm64
[12:26] <locutus_> isn't triggering one of them with all-proposed=1 enough to make them all go green if it passes?
[12:26] <locutus_> instead of triggering three different tests?
[12:26] <Laney> no it's not, you need it in the triggers for that
[12:27] <Laney> all-proposed or not is not looked at by proposed-migration at all
[12:28] <Laney> retry-autopkgtest-regressions generates you retries with triggers consolidated though
[12:28] <Laney> https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=openjdk-14%2F14~36-2&trigger=redland%2F1.0.17-1.1ubuntu1&trigger=openjdk-lts%2F11.0.6%2B10-2ubuntu2
[12:28] <Laney> that's what it makes for libreoffice currently
[12:30] <locutus_> thanks, so using the stuff from ubuntu-archive-tools and doing it by clicking via web has different behaviours
[12:31] <Laney> I mean it's still a bit questionable to consolidate like that, not sure r-a-r is wise to do it
[12:31] <locutus_> I mean, using all-proposed=1 via web, and running retry-autopkgtest-regressions --all-proposed has different meanings, the former uses proposed pocket, the latter uses more triggers
[12:32] <Laney> umm
[12:32] <Laney> the latter gives &all-proposed=1 too, it just gets you the "right" triggers as well
[12:33] <locutus_> oh ok, so the one from cmdline is more powerful
[12:33] <locutus_> I'm trying to do it for llvm now, lets see if I do any mistake
[12:33] <Laney> it's not only the triggers you get from proposed with all-proposed=1, it is everything
[12:33] <Laney> that is pretty much why it's a bad idea
[12:33] <locutus_> ok makes sense
[12:37] <locutus_> apw, autopkgtest for gazebo/9.12.0+dfsg-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Always failed
[12:37] <locutus_> is this one candidate for a forget test?
[12:38] <locutus_> it is amd64 only now
[12:38] <locutus_> so it makes no sense to let it in proposed-forever due to NBS
[12:42] <apw> locutus_, i'd need to think about the 'simplest' graph from there to sanity
[12:42] <apw> (and i am thinking about something esle right now)
[12:45] <Laney> (chips)
[12:48] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html was indicating what 'candidate' items were blocked on some days ago
[12:48] <seb128> does anyone know why it stopped doing that? it was a nice
[12:49] <seb128> (like it would state that things needed icu)
[12:50] <Laney> are you sure it did that?
[12:50] <Laney> because I feel like it was probably before icu became a candidate
[12:51] <doko> coreycb: packages reviewed and accepted.  I did assume that "Openstack developers" == "Neutron developers"
[12:56] <ahasenack> hi release team, I'm not sure how to fix the related bug (or even if it's a bug), so I filed a badtest hint: https://code.launchpad.net/~ahasenack/britney/bind9-i386-dnsutils/+merge/379886
[12:56] <ahasenack> it has more details
[12:58] <Laney> seb128: Looks like that could be added though: it's called migrate-after in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.yaml
[12:59] <Laney> I think the code for this is in lp:ubuntu-archive-scripts
[12:59] <seb128> Laney, I saw it did that for a couple of days which I found cool but maybe I misrember...
[13:00] <seb128> Laney, thx for the pointers, maybe a project for the hack day next week :)
[13:00] <Laney> sure!
[13:37] <coreycb> doko: thanks, and I've added "Neutron developers" to copyright
[14:18] -queuebot:#ubuntu-release- New binary: libserial [s390x] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
[14:19] -queuebot:#ubuntu-release- New binary: libserial [ppc64el] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
[14:21] -queuebot:#ubuntu-release- New binary: libserial [armhf] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
[14:26] -queuebot:#ubuntu-release- New binary: libserial [amd64] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
[14:26] -queuebot:#ubuntu-release- New binary: libserial [arm64] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
[14:43] -queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.3 => 1.10.6-2ubuntu1.4] (kubuntu, ubuntu-desktop)
[15:12] <hellsworth> hey Laney could you take a quick look at this LO test failure? it is timing out but it's not clear why. is there an autopkgtest build infra timeout we could increase?
[15:12] <hellsworth> full log<EMAIL_ADDRESS>[15:12] <hellsworth> snippet: https://paste.ubuntu.com/p/krVHdrXc98/
[15:23] <tkamppeter> Can someone "badtest" gscan2pdf on arm64? Its autopkgtests hang on this platform: bug 1860592 Especially it stops sane-backends from migrating.
[15:24] <seb128> tkamppeter, you can do a merge request against https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu to add it
[15:25] <tkamppeter> hellsworth, if an autopkgtest run takes more than 2:30 hours (150 min) it gets killed.
[15:25] <hellsworth> that's not ture
[15:25] <hellsworth> there are plenty of passing tests listed here http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64 that took longer than 6.5 hours
[15:26] <tkamppeter> hellsworth, is at least my experience, or is it perhaps 150 min hanging, being idle, ...?
[15:27] <hellsworth> idk
[15:27] <RikMills> I recognise the 150 min timeout, but I forget what on exactly. test hanging or buildd?
[15:28] <RikMills> Laney: ^ ?
[15:38] <tkamppeter> seb128, is there any documentation and/or policy about adding entries to hints-ubuntu?
[15:39] <seb128> tkamppeter, not that I know
[16:09] <Laney> hellsworth: no, there is nothing to bump for that
[16:09] <Laney> why is a random test in the middle timing out?
[16:09] <hellsworth> i have no clue, but i thought it wouldn't hurt to ask if it was maybe build related
[16:14] <Laney> I don't know I'm afraid, it's probably going to want someone interested in the package to investigate that specific test and work out what it does and why it might time out
[16:15] <hellsworth> yeah i'm actually trying to find a test timeout now :)
[16:17] <tkamppeter> seb128, LocutusOfBorg: https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379910 I hope it is correct.
[16:20] <Laney> hellsworth: interesting that it's the two java triggers and nothing else, and looks like that test usually only takes ~1h but the timeout happened after like 5.5 hours
[16:20] <Laney> so I would say it probably does look likely that the test itself hung (i.e. has a bug or the new java does or some combination)
[16:21] <hellsworth> oh great points!
[16:21] <rharper> rbasak:  would you have some time to look at   the curtin SRU; it is now verified and ready for release, https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
[16:22]  * Laney eyes the number of libreoffice/armhf/zlib test runs in progress simultaneously
[16:22] <Laney> including an all-proposed one, arrrghghghgh
[16:23] <Laney> LocutusOfBorg: you don't need all-proposed if you include the right triggers!!!!!
[16:23] <hellsworth> what does all-proposed mean?
[16:23] <Laney> unless you *specifically* want everything from proposed for some (good!) reason
[16:23] <hellsworth> oh i see
[16:24] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu21 => 2.04-1ubuntu21] (core)
[16:27] <LocutusOfBorg> Laney, I have to fix my workflow somewhere
[16:27] <LocutusOfBorg> let me see what I did
[16:28] <LocutusOfBorg> ok now my ctrl+r should pick the no all-proposed  version
[16:31] <rbasak> rharper: what's the status of bug 1861452 in Focal?
[16:32] <rharper> rbasak: released, the version is in the archive for focal
[16:32] <rharper> rbasak: I'll mark that now
[16:32] <vorlon> mitya57: qtwebengine-opensource-src is in the middle of the icu transition, please don't do uploads of packages that are waiting on icu in -proposed
[16:32] <rbasak> Thanks
[16:33] <mitya57> vorlon: ok, sorry. In fact I prepared binaries in a PPA in order to reduce harm to the transition.
[16:34] <vorlon> mitya57: it invalidates my hint, which is by version, which means 2h+ after I notice it before I get an updated view of the migration status
[16:35] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu21 => 2.04-1ubuntu21] (core)
[16:35] <ahasenack> vorlon: hi, when you have a moment, https://code.launchpad.net/~ahasenack/britney/bind9-i386-dnsutils/+merge/379886 explains the problem and what I tried (and didn't work)
[16:35] <mitya57> Ack, I won't do any more related uploads.
[16:40] <vorlon> ... and also we're still waiting for test results, so
[16:40] <vorlon> pyside2 tests take 2+h on arm
[16:41]  * vorlon forces qtwebengine-opensource-src to not wait for test results
[16:41] <LocutusOfBorg> yay
[16:46] <rbasak> rharper: is there supposed to be a MAAS test result logged against the Eoan proposed package?
[16:47] <rharper> rbasak: no; maas is not supported on eoan; only on LTS releases
[16:47] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu21]
[16:47] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu21]
[16:48] <LocutusOfBorg> vorlon, FYI ocaml is also mostly ready, entangled only with gnat/gprbuild
[16:48] <rbasak> rharper: but maas ships in Eoan :-/
[16:48] <LocutusOfBorg> I would appreciate if you can do anything in case britney is stuck :(
[16:48] <rbasak> And that's not documented in https://wiki.ubuntu.com/CurtinUpdates
[16:48] <rharper> rbasak: you are correct
[16:50]  * rbasak is reminded of "Papers, please"
[16:53] <vorlon> ahasenack: you say "it didn't help" to mark dnsutils Multi-Arch: foreign, how did you actually test this?  Do you have an autopkgtest commandline that'll work against a ppa?
[16:53] <ahasenack> vorlon: no, I tried "apt install dnsutils:i386"
[16:54] <ahasenack> with my ppa added
[16:54] <vorlon> ahasenack: ok, that's not the command that autopkgtest will run
[16:54] <ahasenack> let me try a dep8 run against the ppa then
[16:54] <ahasenack> but
[16:54] <vorlon> it will decipher that it's Arch: all / Multi-Arch: foreign and will just install the one that's there
[16:54] <vorlon> but it's considered by apt to be arch: amd64 for such purposes
[16:54] <ahasenack> is it fine to try with a local lxd image, or should I use bileto?
[16:54] <vorlon> I'm fine with you testing locally
[16:55] <rbasak> rharper: so I'm looking for a summary of what testing was done, including what version was tested and in this case which type of test each one is, to match against the test plan documented at https://wiki.ubuntu.com/CurtinUpdates
[16:55] <ahasenack> the usual autopkgtest -o logs ... <include ppa>... --apt-pocket=proposed ... ./<source>/ -- lxd ubuntu-daily:focal?
[16:55] <rbasak> rharper: everything else looks fine
[16:55] <rbasak> rharper: the MAAS tests I can see what versions were tested by extracting the zips, which was tedious but I got there
[16:56] <rbasak> rharper: the other test artifacts seem rather unfathomable.
[16:56] <rbasak> Oh, and that each test passed of course
[16:56] <ahasenack> running
[16:56] <rbasak> But I can't see those things, or a summary of those things
[16:56] <rharper> the console.log will show the version use for vmtests,  and for the CDO QA run, it's a click-through to their web form and log with version;
[16:56] <doko> vorlon: please hint in python3.8, while the arm64 tests are still running. the one kopanocore test failure did already succeed. will give a better view on icu again
[16:57] <ahasenack> vorlon: ah, wait, I don't know how to run autopkgtest locally with an i386 focal
[16:57] <rharper> rbasak: I can add a summary entry as  a comment or updated description;
[16:57] <rbasak> rharper: the CDO QA run I did find details for, but that doesn't seem to be required according to https://wiki.ubuntu.com/CurtinUpdates
[16:57] <rharper> ok
[16:57] <ahasenack> vorlon: do I just include "sudo dpkg --add-architecture i386" in the setup commands?
[16:57] <ahasenack> cpaelzer: you did that in the recent past, no? ^
[16:58] <vorlon> doko: it doesn't change the view on icu, python3.8 isn't part of the icu transition
[16:58] <vorlon> ahasenack: you have to --add-architecture and also apt-get update afterwards
[16:58] <ahasenack> vorlon: ok, thanks
[16:59]  * ahasenack crosses fingers
[16:59] <rharper> rbasak: for the vmtest rnus, the -console.log includes curtin versions used at the top; and the bottom includes the summary of tests/passed failed.  in two cases, we re-run tests that fail due to hardware resource issues (timed out); and include a second log (v2);
[17:00] <doko> xnox: so what did you claim? ;p
[17:02] <rbasak> rharper: I'm also a bit puzzled that those console logs seem to be pulling the curtin source package. Is the binary being tested?
[17:02] <doko> I see that ocaml and python3.8 are connected
[17:02] <xnox> xnox:  my claim is confused about life
[17:03] <xnox> doko:  there is pyocaml yes.
[17:03] <rharper> rbasak: curtin is all python, so the source is the binary; curtin is deployed by packing up it's python source and pushing that into the target environment via cloud-init;  this is how MAAS deploys curtin in ephemaral environments, and this is how curtin's vmtest harness does as well
[17:04] <ahasenack> vorlon: Get:59 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 dnsutils all 1:9.16.0-1ubuntu1 [2756 B]
[17:04] <ahasenack> hah
[17:04] <ahasenack> looks like it worked
[17:05] <ahasenack> it pulled the arch-all transitional package from 9.16.0 (and the real package later)
[17:05] <ahasenack> Get:63 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 bind9-dnsutils amd64 1:9.16.0-1ubuntu1 [134 kB]
[17:05] <ahasenack> but amd64,hm
[17:05] <vorlon> ah
[17:05] <ahasenack> let me repeat without dpkg --add-architecture
[17:06] <rbasak> rharper: is the source picked up from the source package or from the binary package? Because packaging can modify Python source when it builds the binary package.
[17:06] <ahasenack> time autopkgtest -o dep8-i386-with-ppa-and-proposed -U -B -s --apt-pocket=proposed --setup-commands="sudo dpkg --add-architecture i386; sudo add-apt-repository ppa:ahasenack/junk -y;sudo apt-get update" ./bind9/ -- lxd ubuntu-daily:focal
[17:06] <ahasenack> that was my command line
[17:06] <doko> promoted ruby2.7 again
[17:06] <ahasenack> maybe without -U? and do a dist-upgrade in my setup-commands
[17:07] <ahasenack> yeah, it didn't use my ppa
[17:07]  * ahasenack checks
[17:07] <rbasak> rharper, powersj: ^ sorry for the pain. AIUI, my reviewing job is to check these things. If you're in a hurry, feel free to pass to someone who already follows all of this. vorlon maybe?
[17:07] <vorlon> ahasenack: bind9-dnsutils isn't Multi-Arch: foreign, so dnsutils -> bind9-dnsutils will follow the dep within the native arch.  And we probably want to be able to install the :i386 one, and it's a utils package so M-A: foreign is probably correct
[17:07] <rharper> rbasak: packing happens from the installed binary;  the installed curtin will pack it's installed code into blob to be written out via cloud-init
[17:07] <rbasak> rharper: OK, so surely the test should be testing from the binary and not the source then?
[17:08] <rharper> it is testing from the binary; we create a container in which we install curtin from -proposed
[17:08] <rbasak> The usual goal of SRU verification is to test the built binary
[17:08] <rbasak> But the first thing it seems to do is pull-lp-source?
[17:08] <ahasenack> wait, it used my ppa, I just happened to have pasted the first grep hit, it later installed mine
[17:08]  * ahasenack continues checking
[17:08] <rharper> and then we call curtin inside this container and run the 'pack' command to build the blob that's deployed into VMs for testing that the version from the archive deploys correctly
[17:09] <ahasenack> it did get my ppa, but I don't see it installing i386 packages
[17:09] <vorlon> ahasenack: oh.  couldn't you fix this by making the autopkgtest depend on bind9-dnsutils in debian/tests/control, instead of the transitional package?
[17:09]  * vorlon whistles innocentl/y
[17:10] <ahasenack> vorlon: oh
[17:10] <ahasenack> someone needs a clue bat looks like it
[17:10] <ahasenack> but I still need a way to verify, I'll try bileto
[17:10] <vorlon> ahasenack: I assumed it was pulling in dnsutils because it had a Depends: @ or something; but in this case it's a simple replace to not pull in the transitional package :)
[17:10] <rharper> rbasak: the source is pulled to acquire the tool to create the container in which we install the binary from -proposed
[17:10] <ahasenack> vorlon: I assumed it was the testbed, because dnsutils was installed already
[17:11] <ahasenack> vorlon: if this fixes it, no need for multi-arch? OR is that still something good to do? Or better wait for bugs to happen, if at all?
[17:11] <ahasenack> weird, I did have this in bileto before, and it passed
[17:11] <ahasenack> anyway
[17:12] <vorlon> ahasenack: no need for multi-arch, it would still be correct but probably useless
[17:12] <ahasenack> ok
[17:12] <ahasenack> thanks for your help
[17:21] <rbasak> rharper: ah, OK
[17:21] <rbasak> Sorry
[17:25] <rbasak> rharper: so I can see that in the Eoan vmtest that failed, but not in the Eoan vmtest that succeeded
[17:25] <rharper> rbasak: not a problem; it's not immediately obvious
[17:26] <rharper> rbasak:  e-console.log ?
[17:26] <rbasak> Sorry no, that's wrong
[17:26] <rbasak> This is confusing!
[17:27] <rbasak> curtin-vmtest-proposed-x-console.log says "installed curtin at 19.3-26-g82f23e3d-0ubuntu1~16.04.1
[17:27] <rbasak> "
[17:27] <rbasak> Which is a convenient confirmation
[17:27] <rbasak> But that's the first one that failed
[17:27] <rbasak> The retry test logs seem to have a different format?
[17:27] <rbasak> And those don't seem to have that output
[17:29] <rharper> rbasak: they are different as it's human (me) re-issuing the command to run a subset of the tests
[17:30] <rbasak> rharper: subset because the remainder passed the previous time?
[17:30] <rharper> correct
[17:30] <rharper> on the jenkins node we have, at some levels of load, tests just timeout due to contrained resourse; we rerun them sequentially (rather than in parallel) to confirm that they are passing
[17:34] <rbasak> vorlon: in https://wiki.ubuntu.com/CurtinUpdates, what do you understand by the MAAS integration test requirement? Is that supposed to apply only to LTS releases, or all supported Ubuntu releases?
[17:34] <vorlon> rbasak: all supported, or else why SRU it to that release?
[17:35] <rbasak> rharper: ^
[17:39] <rharper> We're SRU'ing curtin; not maas.    The code path we (curtin) verify is in an Eoan ephemeral enviroment, does curtin install correctly in all of the integration tests we have.  MAAS QA re-runs a subset of curtin vmtest scenarios, but not all of what we run.    This is a limitation of the MAAS test harness;
[17:46] <rharper> rbasak: I need to relocate; thanks for looking into the SRU; I'll be back online in about 30 minutes or so
[18:49] <locutus__> vorlon, what is wrong with odil?
[18:57] <locutus__> I see update_output failing because of it
[18:59] <locutus__> reverse-depends -r focal  python-odil returns nothing
[19:00] <locutus__>  python-odil | 0.10.0-3ubuntu1 | focal/universe  | amd64, arm64, armhf, ppc64el, s390x
[19:00] <locutus__> any AA please NBS cleanup=
[19:00] <locutus__> doko, ^^
[20:09] <vorlon> locutus__: nothing's wrong with odil, only with the order in which the autohinter is considering packages for inclusion in its hint
[20:10] <vorlon> see also output of my hint in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt , which gets odil just fine but is currently hung up on r-cran-insight
[20:24] -queuebot:#ubuntu-release- Unapproved: flatpak (eoan-proposed/universe) [1.4.3-1 => 1.4.4-0ubuntu0.1] (ubuntugnome) (sync)
[20:25] <kenvandine> ahayzen: ^^
[20:39] -queuebot:#ubuntu-release- New binary: apt [s390x] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:40] -queuebot:#ubuntu-release- New binary: apt [ppc64el] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:40] <juliank> final APT ABI (well, at least the minimum ABI, might make more stuff public again) is coming in! :D
[20:40] <juliank> python-apt 1.9.8 is already uploaded with a build-depends on this version
[20:42] -queuebot:#ubuntu-release- New binary: apt [amd64] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:42] -queuebot:#ubuntu-release- New binary: apt [i386] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:47] -queuebot:#ubuntu-release- New binary: apt [arm64] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:47] -queuebot:#ubuntu-release- New binary: apt [armhf] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
[20:48] <juliank> Would somebody be so kind to approve the apt soname bump?
[20:48] <juliank> I already upload libept as well with the packaging changes for the new apt version
[20:48] <juliank> so hopefully once it's in, libept binaries should get build and hit new
[20:49] <juliank> and once they are in we can build the rest
[20:49] <juliank> well, we can build most before libept :D
[21:39] -queuebot:#ubuntu-release- New binary: kodiplatform [amd64] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
[21:39] -queuebot:#ubuntu-release- New binary: kodiplatform [s390x] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
[21:39] <ahayzen> kenvandine, awesome thanks :-D
[21:40] -queuebot:#ubuntu-release- New binary: kodiplatform [ppc64el] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
[21:41] <rbalint> please reject the kodiplatform binaries
[21:42] -queuebot:#ubuntu-release- New binary: kodiplatform [arm64] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
[21:42] -queuebot:#ubuntu-release- New binary: kodiplatform [armhf] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
[21:52] <vorlon> rafaeldtinoco: I'm rolling back ruby-charlock-holmes in -proposed, the ruby transition can't stack on the icu transition right now
[21:52] <rafaeldtinoco> alright
[21:52] -queuebot:#ubuntu-release- New: accepted apt [amd64] (focal-proposed) [1.9.11]
[21:52] <rafaeldtinoco> kanashiro: ^
[21:52] -queuebot:#ubuntu-release- New: accepted apt [armhf] (focal-proposed) [1.9.11]
[21:52] -queuebot:#ubuntu-release- New: accepted apt [ppc64el] (focal-proposed) [1.9.11]
[21:52] -queuebot:#ubuntu-release- New: accepted apt [arm64] (focal-proposed) [1.9.11]
[21:52] -queuebot:#ubuntu-release- New: accepted apt [s390x] (focal-proposed) [1.9.11]
[21:52] -queuebot:#ubuntu-release- New: accepted apt [i386] (focal-proposed) [1.9.11]
[21:54] <rbalint> the kodiplatform ubuntu2 binaries will be ok
[22:04] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1002.2] (core, kernel)
[22:27] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1002.2]
[22:45] -queuebot:#ubuntu-release- Packageset: Added libfido2 to i386-whitelist in focal
[23:02] <ahasenack> vorlon: hmpf, now I got this, after changing the test builddep to the non-transitional package:  builddeps:/tmp/autopkgtest.ZYqxfY/1-autopkgtest-satdep.dsc:i386 : Depends: bind9-dnsutils:i386
[23:02] <ahasenack> I'll have to look at that tomorrow
[23:02] <vorlon> that alone doesn't look like a problem
[23:02] <vorlon> is there error output?
[23:03] <ahasenack><EMAIL_ADDRESS>is the log
[23:04] <vorlon> ok
[23:04] <vorlon> ahasenack: could be fixed by making bind9-utils Multi-Arch: foreign
[23:05] <ahasenack> but it's not an arch all package
[23:05] <ahasenack> ah, hm
[23:05] <ahasenack> running the tools doesn't really matter
[23:05] <ahasenack> let me check its contents
[23:07] <vorlon> the reason it would fix it is that dnsutils, which is installed for some reason, would still have its dependency satisfied by bind9-dnsutils:i386 instead of bind9-dnsutils:amd64, allowing apt to make the switch
[23:07] <ahasenack> dnsutils is installed because it's a rdep of ubuntu-standard I think
[23:07] <vorlon> "for some reason" - because it's standard, yes
[23:08] <ahasenack> ok, so bind9-utils has /usr/sbin/* binaries and python scripts
[23:09] <ahasenack> and the python module these scripts import: /usr/lib/python3/dist-packages/isc
[23:12] <ahasenack> hm, this worked in bileto just before
[23:15] <ahasenack> vorlon: as simple as this, hopefully? :) https://pastebin.ubuntu.com/p/xMVQjxBDfN/
[23:15] -queuebot:#ubuntu-release- Packageset: Added tepl to i386-whitelist in focal
[23:15] <vorlon> ahasenack: I believe so
[23:15] <ahasenack> vorlon: this is hard to test, I couldn't even get autopkgtest locally to do it, with the new "-a i386" flag from that git repo autokgtest-development
[23:16] <vorlon> cpaelzer, rafaeldtinoco: sorry https://launchpad.net/ubuntu/+source/kronosnet/1.14-1ubuntu2
[23:16] <vorlon> ahasenack: yes, I've had difficulty testing those kinds of changes locally
[23:16] <vorlon> so I tend to just upload them because they don't make it worse ;)
[23:17] <rafaeldtinoco> hey steve
[23:17]  * rafaeldtinoco checks
[23:17] <rafaeldtinoco> yep, my last i386 changes were "best guess" with "local attempts" and "prays"
[23:23] -queuebot:#ubuntu-release- New binary: azure-cosmos-table-python [amd64] (focal-proposed/universe) [1.0.5+git20191025-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: eshell-z [amd64] (focal-proposed/universe) [0.4-3] (no packageset)
[23:30] -queuebot:#ubuntu-release- Packageset: Added fmtlib to i386-whitelist in focal


[09:23] <n0s0r0g> Hi all. Graphic on Asus eeePC 900 (Intel 915GM). Boot from ubuntu-9.04-umpc - very slow UI, glxgears: 18-20 fps. Boot from ubuntu-i386 LiveUSB - UI works well, glxgears: 130-140 fps.


[11:31] <BenC> apw: FYI, the ethernet drivers for the freescale ppc hardware I use have finally sarted to hit mainline. I’d like to be able to reintroduce the kernel configs for them (two configs, one powerpc, the other powerpc64) for yakity.
[12:33] <apw> BenC, did we remove some flavours?
[12:36] <BenC> I know e500 is gone, and that’s perfectly fine with me.
[12:36] <BenC> Speaking of flavours…
[12:37] <BenC> rtg: Does e500mc still get built?
[12:37] <BenC> Do you guys not use kernel.ubuntu.com git anymore?
[12:37] <apw> those names are not great, they are generic to all freescale things right?  a 32 and 64 bit variant thereof ?
[12:38] <rtg> BenC,  powerpc-smp powerpc64-smp powerpc-e500mc powerpc64-emb
[12:38] <BenC> Ok.
[12:39] <BenC> So the e500mc can be generalized a bit, but it doesn’t cover all 32-bit freescale (now nxp, btw)
[12:39] <BenC> e500 is soft-float, so needs a special kernel, but it’s also not used in any general production compete systems that I’m aware of.
[12:39] <rtg> BenC, we do still use kernel.ubuntu.com, but its not a mirror. the primary is on LP
[12:39] <apw> ugg, soft-float is even, die die die
[12:39] <BenC> powerpc64-emb variant is generalized enough for all book3e
[12:39] <rtg> s/not/now/
[12:40] <BenC> rtg: I didn’t notice that the git web listing is some 17 odd pages. I only looked at the first page
[12:40] <apw> BenC, yeah you should see all our trees on k.u.c but launchpad has tehm all now, and the cgit is quicker too
[12:41] <BenC> Anyway, e500mc can be renamed to powerpc-corenet, but I would need to verify the config has the correct things enabled to claim that
[12:41] <BenC> And I can verify that the fman drivers are enabled, since that’s improvement for the newer kernels
[12:42] <BenC> Took 5+ years, but they finally got their drivers upstream.
[12:43] <BenC> Any pull requests can be against: git://kernel.ubuntu.com/ubuntu/ubuntu-yakkety.git ?
[12:43]  * BenC wishes you guys would just use github
[12:44] <rtg> BenC, yeah, that is fine. I think the mirror runs every 30 minutes
[12:44] <apw> every 15m iirc, the master is
[12:44] <apw> https://launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/yakkety
[12:45] <xnox> BenC, you can create pull requests on launchpad =)
[12:46] <BenC> Shows how much I pay attention. I didn’t know lp had git support
[12:46] <xnox> BenC, that's been around for like a year, or maybe more, now.
[12:46] <rtg> BenC, hence the reason we don't use github.
[12:49] <BenC> rtg: Are you ok with renaming powerpc-e500mc to powerpc-corenet in kernel and meta?
[12:49] <BenC> I’m fairly certain I am the only user
[12:49] <apw> what does "corenet" mean in this namespace ?
[12:50] <BenC> It cover a class or Freescale QorIQ SoCs that are powerpc based with frame manager components
[12:50] <rtg> BenC, its a bit late in the process, isn't it ?
[12:50] <BenC> It also covers a class of Freescale QorIQ SoCs that are arm based, but I don’t touch those...
[12:51] <BenC> rtg: I was just hoping to make it less specific for apw’s concern, but I don’t have a preference.
[12:52] <BenC> It will work for e500v2 and e500mc
[12:52] <apw> i was hoping to discover we would need just two variants going forward, always
[12:52] <apw> musch as we now do for powerpc (IBM style for want of a name)
[12:52] <BenC> Unfortunately, freescale SoCs are book3e and not book3s as IBM/Apple powerpc processors are.
[12:53] <BenC> So it will have to always be a seperate kernel build
[12:53] <apw> BenC, right, i mean 32/64 for each of "ibmish" and "freescaleish"
[12:54] <BenC> For 64-bit, it is and can remain that way (the e in book3e is embedded, hence the powerpc64-emb)
[12:55] <apw> and there is no hope of that for powerpc-emb ?
[12:56] <BenC> No. I’ve been down that road with benh and neither he, myself, nor anyone else, wants to perform a ppc32/mmu kenrel reorg to make that happen, and some even say that it can’t be done anyway (technically impossible).
[13:12] <apw> BenC, so no single -emb 32 bit flavour, sigh
[13:13] <BenC> Yeah, unfortunately, it’s not the type of thing that is resolved with device trees
[13:41] <xnox> apw, i think i might be blind
[13:42] <xnox> I'm trying to find which git repository https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1572291 is committed to, if any
[13:42] <apw> xnox, ?
[13:42] <xnox> and i'm failing
[13:42] <xnox> i looked at https://code.launchpad.net/~ubuntu-kernel/+git
[13:42] <xnox> then found linux/+git/xenial and linux/+get/yakkety
[13:42] <xnox> yakkety doesn't have master-next branch
[13:42] <xnox> xenial master-next doesn't appear to have that commit
[13:43] <apw> rtg, ^ ?  he might of course be right in the middle of applying it
[13:43] <apw> xnox, oh but there it is on xenial master-next
[13:43] <xnox> wait maybe found it
[13:43] <xnox> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?h=master-next&id=ab72705a2737c90c03d24b91afa10ef1b7403448
[13:43] <rtg> xnox, not doing anything with yakkety just yet
[13:44] <xnox> rtg, ok, cool.
[13:45] <xnox> i guess once there is yakkety kernel upload, the git forest of trees will look like typical bushes at that point.
[13:46] <apw> xnox, we work in xenail for a bit at this point and copy the kernel forard to yakkety, up till we have something which doesn't utterly stink
[13:46] <xnox> hehehe
[13:46] <xnox> =
[13:46] <xnox> =)
[13:47] <rtg> xnox, which could be 2-3 weeks yet
[14:26] <BenC> rtg: What’s the plan for yakkety’s kernel version? Is it moving past 4.4.x?
[14:27] <rtg> BenC, yup. I'm gonna get the latest one I can
[14:27] <apw> BenC, yep, it will move rather rapidly I am sure
[14:27] <rtg> maybe even an -rc if it is that close
[14:27] <BenC> Ok. The updated drivers I’m looking at are in 4.5+, so I’ll hold off until then to review the config options
[14:28] <BenC> 4.6 is at rc5 as of today. Seems plausible for inclusion.
[14:28] <apw> i'd be supprised if its not 4.7+
[14:30] <BenC> If you see CONFIG_FSL_FMAN come up in the config review, you’ll want to enable it for e500mc and ppc64-emb, but I’ll be sure to verify after you guys sync it up.
[14:30] <BenC> It’s possible you want it for some arm kernels as well, but I can’t comment directly.
[14:30] <rtg> BenC, you could have a look at git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable which is what will become yakkety. I'm currently rebasing against 4.6-rc5
[14:33] <BenC> Thanks, I’ll take a peak
[15:06] <BenC> rtg: Things look good there
[15:06] <BenC> But this:
[15:06] <BenC> config/config.common.ubuntu:CONFIG_FSL_FMAN=m
[15:06] <BenC> Needs to be made =y
[15:06] <BenC> Wait, I’m wrong.
[15:06] <BenC> It can be loaded as a module, but it wont unload, so that’s fine as-is
[16:39] <ben-8409> hello, i think a have a regression with latest kernel version in 16.04 (4.4.0-21) and nvidia drivers. I already filed a bug, but i wanted to check if there is anything more i can do? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574732
[16:39] <ben-8409> using grub to boot into an older release (4.4.0-18-generic) fixes the issue for me.
[19:25] <kristian_on_linu> hi!
[19:25] <kristian_on_linu> how do I disable N support when configuring a kernel?
[19:34] <kristian_on_linu> or, to be specific, 11n
[19:35] <kristian_on_linu> as mentioned here: http://askubuntu.com/questions/529347/how-do-i-keep-my-wifi-from-dropping-out


 damn @Ivoriesablaze getting twitter famous
 PiBakery makes it quicker and easier to get started with Raspberry Pi … http://thenextweb.com/apps/2016/09/06/pibakery-makes-it-quicker-and-easier-to-get-started-with-raspberry-pi/#gref
 @ahoneybun yeah, man, my twitch had its first ever raid last night!
 Yay glasses broke
 Apple just sent a heat seaking missle at me by bringing Shigeru Miyamoto on stage
[17:40] <maxolase1squad> KMyers, put down the Apple pipe and watch https://www.youtube.com/watch?v=T0dabzg9GbM instead.
 Nice!
 Where is that?
[18:53] <maxolase1squad> Abbey Road
 I think I should have enough filament for a while
 Android phone holder?
 Thats what that Green is fo
 ABS
 Yay
 Just waiting for a new print surface I want to try with it called PrintByte
 Hoping it gets here soon
 Ok
 PrintByte is supposed to make printing ABS a lot better
 Oh my gosh guys I just tried the HTC Vive
 Sweet
 This is still a work in progress but what do you all think of my mini makerspace/workshop
 Need to paint and finish setting up the computer
 Whoaah nice
 I want to paint the space soon
 But once it is setup, anyone is free to use it if needed
 Just got the digital caliper in
 opps about the tweet
 I thought it included what I wanted to say
 @Ivoriesablaze https://twitter.com/ATHoneycutt/status/773603416320847872
 XD
 I'm on a roll: https://twitter.com/ATHoneycutt/status/773603847310757888
 btw that other tweet was about the GBA SP removing the headphone jack and Apple doing it now
 bad things repeat themselves
 Chase now supports Android pay. You can add chase cards into Android pay again.
 Yup. as of 9 AM
 I'm late
 Aaron your tweet is great.
 Which one lol
 http://news.softpedia.com/news/kde-neon-linux-developer-edition-now-uses-wayland-by-default-for-kde-plasma-5-8-508025.shtml