[08:48] <mvo> smb: hey, I "stole" lp 1623125 from you. I hope you don't mind. uploaded the fix to bionic and sru-ed to xenial
[09:31] <LocutusOfBorg> hello juliank can you please have a look at https://ci.debian.net/packages/s/software-properties/ and https://autopkgtest.ubuntu.com/packages/software-properties/bionic/amd64 ?
[09:31] <LocutusOfBorg> they are blocking qt migration... I have no clues
[09:35] <juliank> um, /tmp/autopkgtest.T5cpXr/build.XAo/src/tests//tmp/autopkgtest.T5cpXr/build.XAo/src/tests seems kind of double
[09:39] <juliank> The Debian one just always failed, there's nothing fancy going on there.
[09:41] <juliank> LocutusOfBorg: So, I may be wrong, but maybe the test suite runner runs all tests in the same process, and the sources.list setting from test_aptsources.py sticks around where it shouldn't
[09:43] <juliank> LocutusOfBorg: In that case, adding         apt_pkg.init() to clear_apt_config() should fix the issue
[09:44] <juliank> In general, all tests should probably run apt_pkg.init() in setUpClass so they can be run in any order.
[10:03] <LocutusOfBorg> so juliank can you please fix it? :)
[10:30] <doko> jamespage: cantor autopkg test fails with the recent qt5
[10:32] <jamespage> doko: did you mean that for me?
[10:34] <doko> jamespage: ahh crap, sorry
[10:34] <doko> tsimonq2: ^^^
[10:37] <jamespage> doko: no worries
[10:37] <jamespage> I was worried openstack had grown some sort of new dependency :-)
[12:25] <tsimonq2> doko: ...please be more specific
[12:34] <doko> tsimonq2: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html triggered by python3.6
[12:54] <rbasak> cyphermox: are you aware of the nplan s390x dep8 failure in xenial?
[12:58] <rbasak> apw: no SRU paperwork in bug 1737640? I don't know how to check that the SRU verification minimises regression risk.
[13:01] <apw> rbasak, bah smb should know better
[13:02] <apw> rbasak, this is a regression in -updates which prevented juju deployments iirc, so the verification was to confirm that juju would now deploy with that update
[13:02] <rbasak> apw: what about non-Juju use of fanctl?
[13:04] <apw> rbasak, i believe it would be similarly affected, but that to trigger the failure you had to have an unconfigured interface something like that
[13:04] <apw> rbasak, clearly i am not the one who should write that up, as i am short some context
[13:05] <rbasak> apw, smb: I mean: is there any non-Juju use case that might be regressed? What areas should SRU verification cover to mitigate this, if any?
[13:06] <apw> rbasak, i do remmber we struggled to get this to reproduce at all outside of that envionment, it was not a common case
[13:06] <apw> rbasak, though always present in the juju deployments they were testing
[13:06] <rbasak> apw: I'm not so worried about the bug. I'm thinking about the change.
[13:07] <apw> rbasak, the primary failure mode was ifup -a would not complete successfully for unrelated interfaces with no fan configuration
[13:08] <apw> rbasak, the change itself is to fix a deficieny which leads to an uncaught error in the normal case, which is benign if ugly
[13:08] <apw> rbasak, but in ifup -a form they were becoming fatal
[13:09] <apw> rbasak, the fix is needed and correct for all use cases, it is just that the benign error has no effect outside of that model
[13:09] <apw> rbasak, but none of this is very coherant, and someone should be writing it up properly
[13:09] <rbasak> OK :)
[13:10] <apw> rbasak, i am also worried the promised follow up to get this fixed in later series has not yet happened either
[13:11] <rbasak> I hadn't even noticed that.
[13:11] <rbasak> You accepted it on an urgent basis because of the Juju regression I presume.
[13:16] <apw> rbasak, indeed, it was on fire at the time, the engineer was able to use a version of this package from PPA to continue
[13:16] <apw> rbasak, and i was promised follow up on the other series etc, and that has not occured
[13:16] <rbasak> apw: understood. I commented on the bug.
[13:16] <apw> rbasak, i think leaving it be is appropriate
[14:12] <tsimonq2> doko: ack
[14:26] <smoser> anyone else lately seen chnages in git shell tab complete ?
[14:27] <smoser> it doesnt seem to me to be workign as well as it used to. i'm not sure what would have changed... just looking to see if someone else saw something.
[14:27] <smoser> i'm on bionic
[14:28] <smoser> no changes recently to git (which provides /usr/lib/git-core/git-sh-prompt)
[14:43] <smoser> hm.. something seemed to have gotten foobarred in shell window i guess.
[14:43] <smoser> nothing to see here folks, move along...
[14:49] <cyphermox> rbasak: I am, this is not a nplan issue -- network-manager and say, wpa, other things would fail the same. This is because s390x is no longer marked to not support machine-isolation (because it does support it now), but there are things not available on it (cfg80211, iw)
[14:50] <cyphermox> iw is arguably something that needs to be depended on (and I'm a little surprised it's not), but cfg80211 is a kernel thing
[14:50] <rbasak> cyphermox: OK, so in your view, nplan is ready to release despite that failure?
[14:50] <cyphermox> rbasak: correct
[14:51] <rbasak> cyphermox: OK, I'll review. There are other SRUs for which nplan dep8 has failed too. Are these the same - do we need a force-badtest, or to fix the nplan dep8 test somehow?
[14:52] <cyphermox> 0.32 is all good; I'll add workarounds for what's left
[14:53] <cyphermox> if things have no tested against 0.32, they're not good
[14:55] <rbasak> I suppose we need to land nplan 0.32 into the updates pocket first then, and then retry those SRUs
[14:55] <rbasak> Uh, those other rdep dep8 tests
[14:57] <cyphermox> I see only util-linux, which hasn't tested against nplan 0.32~16.04.3, but it shouldn't really matter there
[16:38] <sladen> cascardo: hello, kudos for the upload for LP#1734147
[16:38] <sladen> cascardo: what's the present state in terms of who in the HW can perform testing/
[16:39] <cascardo> sladen: well, I am just one of guys hitting the buttons
[16:39] <cascardo> sladen: some testing has been made by anthonywong
[16:41] <sladen> ypwong: ^^
[16:41] <sladen> ypwong: have you got hardware and are in a position to do testing for bug LP#1734147 ?
[16:44] <ypwong> sladen, i will go to ODM tomorrow to test things suggested by mika
[16:44] <ypwong> to see if we can recover from failed bios
[16:45] <cascardo> sladen: oh, you are the one looking on how to recover this by software, kudos to you!
[16:47] <sladen> ypwong: have you had contact with Mika W. (other than what I forwarded to the bug report today)?
[16:49] <sladen> ypwong: wondering if there is more information that can get in one place, on the bug report, so that it is not lost
[16:51] <sladen> cascardo: ...stuck with not having access to hardware in this case
[16:53] <sladen> ypwong: cascardo: (both), and what's your collective understanding of the result of disabling the spi-intel driver loading on boot ... is it just that additional machines will not be bricked, or is it expected, that after 2+ reboots without the driver having been auto-loaded these machines will be usuable again?
[16:55] <ypwong> sladen, yes i got more from mika but because they are unproven so i want to confirm by myself first before posting on launchpad
[16:55]  * sladen silently bangs head against wall
[16:55] <ypwong> sladen, once the bios is affected the kernel update cannot help
[16:58] <ypwong> so it's just to prevent more people get burnt
[17:01] <cascardo> afaik, we want to prevent more accidents. so even a new image will be built with that kernel
[17:36] <tsimonq2> jackpot51: You might want to check if Pop is affected by the bug in the topic, just an fyi ;)
[19:32] <juliank> LocutusOfBorg: on it now
[19:42] <juliank> ugh
[20:17] <juliank> LocutusOfBorg: Let's hope it's fixed now
[20:18] <juliank> LocutusOfBorg: I have no idea, it worked for me
[20:27] <juliank> Oh, how I hate global variables.
[20:49] <acheronuk> juliank: I think software-properties is still failing from the log of running tests
[20:50] <juliank> acheronuk: oh I see
[20:50] <juliank> damn
[20:52] <juliank> oh right
[20:52] <juliank> I have to clear the config first before runninig init() again
[20:54] <juliank> for k in apt_pkg.config.keys(): apt_pkg.config.clear(k)
[20:58] <juliank> next attempt :D
[20:59] <juliank> ugh
[21:01] <juliank> uploaded .19
[21:11] <acheronuk> juliank: fingers crossed. thanks
[21:19] <PenguinPerk> I am working on automating an install of unifi controller into aws. I have a directory mount for the a backup directory. When I run the installed (as Root), apt install unifi. I am getting an error: chown: changing ownership of '/var/lib/unifi/backup': Input/output error. My goal is to find the script that will provide what UID/GID and permission the installer is trying to set.
[21:20] <TJ-> PenguinPerk: the preinst or more likely postinst script
[21:21] <PenguinPerk> @TJ-, here is the error: chown: changing ownership of '/var/lib/unifi/backup': Input/output error
[21:21] <udevbot_> Error: "TJ-," is not a valid command.
[21:24] <TJ-> PenguinPerk: check the package's .postinst script
[21:26] <PenguinPerk> @TJ-, What is the best way to find the .postinst script, I ran a file listing of the package and i don't see it?
[21:26] <udevbot_> Error: "TJ-," is not a valid command.
[21:27] <TJ-> PenguinPerk: don't use @ ... it's enough to tab-complete my nickname
[21:28] <TJ-> PenguinPerk: Pull the source of the package, or look at /var/lib/dpkg/info/<package-name>/postinst
[21:28] <PenguinPerk> I will look, I may not have access to the src
[21:34] <PenguinPerk> @TJ-, I just confirmed i don't have access to src files. Are there any options available for me to run it in a verbose mode?
[21:34] <udevbot_> Error: "TJ-," is not a valid command.
[21:35] <TJ-> PenguinPerk: "apt-get source <packagename>"
[21:36] <PenguinPerk> @TJ-, no luck...I can call Ubiquiti support line if i have to....trying to work around with having to call.
[21:36] <udevbot_> Error: "TJ-," is not a valid command.
[21:37] <TJ-> PenguinPerk: did you look for "/var/lib/dpkg/info/unifi.*" ?
[21:41] <PenguinPerk> TJ-, thanks
[21:53] <LocutusOfBorg> thanks juliank :)
[21:53] <juliank> Still one failure
[21:54] <juliank> but on ppc64el
[21:54] <juliank> that might have always failed
[21:55] <juliank> amd64 succeeded
[21:55] <juliank> i386 too
[21:55] <juliank> so the regressions should be taken care of
[21:57] <juliank> that said: it might not migrate either, because livecd-rootfs regressed somehow, maybe temporary (for .18, let's see what happens for .19)
[21:59] <juliank> but: since I only made changes to tests/ I guess that can easily be overridden
[21:59] <juliank> as obviously my changes to tests/ can't cause regressions in other packages :D
[22:14] <acheronuk> juliank: seems to be passing on my retries against pyqt5 as well (amd64,i386). thanks
[22:16] <juliank> acheronuk: wonderful