[08:48] smb: hey, I "stole" lp 1623125 from you. I hope you don't mind. uploaded the fix to bionic and sru-ed to xenial [08:48] Launchpad bug 1623125 in initramfs-tools (Ubuntu) "fixrtc script does not catch "Last mount time: n/a" string" [Medium,In progress] https://launchpad.net/bugs/1623125 [09:31] 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] they are blocking qt migration... I have no clues [09:35] um, /tmp/autopkgtest.T5cpXr/build.XAo/src/tests//tmp/autopkgtest.T5cpXr/build.XAo/src/tests seems kind of double [09:39] The Debian one just always failed, there's nothing fancy going on there. [09:41] 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] LocutusOfBorg: In that case, adding apt_pkg.init() to clear_apt_config() should fix the issue [09:44] In general, all tests should probably run apt_pkg.init() in setUpClass so they can be run in any order. [10:03] so juliank can you please fix it? :) [10:30] jamespage: cantor autopkg test fails with the recent qt5 [10:32] doko: did you mean that for me? [10:34] jamespage: ahh crap, sorry [10:34] tsimonq2: ^^^ [10:37] doko: no worries [10:37] I was worried openstack had grown some sort of new dependency :-) === ScriptRipper_ is now known as ScriptRipper [12:25] doko: ...please be more specific [12:34] tsimonq2: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html triggered by python3.6 [12:54] cyphermox: are you aware of the nplan s390x dep8 failure in xenial? [12:58] apw: no SRU paperwork in bug 1737640? I don't know how to check that the SRU verification minimises regression risk. [12:58] bug 1737640 in ubuntu-fan (Ubuntu) "/usr/sbin/fanctl: arithmetic expression: expecting primary | unconfigured interfaces cause ifup failures" [Critical,Confirmed] https://launchpad.net/bugs/1737640 [13:01] rbasak, bah smb should know better [13:02] 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] apw: what about non-Juju use of fanctl? [13:04] 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] rbasak, clearly i am not the one who should write that up, as i am short some context [13:05] 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] 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] rbasak, though always present in the juju deployments they were testing [13:06] apw: I'm not so worried about the bug. I'm thinking about the change. [13:07] rbasak, the primary failure mode was ifup -a would not complete successfully for unrelated interfaces with no fan configuration [13:08] 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] rbasak, but in ifup -a form they were becoming fatal [13:09] 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] rbasak, but none of this is very coherant, and someone should be writing it up properly === sladen changed the topic of #ubuntu-devel to: Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: [13:09] OK :) [13:10] rbasak, i am also worried the promised follow up to get this fixed in later series has not yet happened either [13:11] I hadn't even noticed that. [13:11] You accepted it on an urgent basis because of the Juju regression I presume. [13:16] 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] rbasak, and i was promised follow up on the other series etc, and that has not occured [13:16] apw: understood. I commented on the bug. [13:16] rbasak, i think leaving it be is appropriate [14:12] doko: ack [14:26] anyone else lately seen chnages in git shell tab complete ? [14:27] 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] i'm on bionic [14:28] no changes recently to git (which provides /usr/lib/git-core/git-sh-prompt) [14:43] hm.. something seemed to have gotten foobarred in shell window i guess. [14:43] nothing to see here folks, move along... [14:49] 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] 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] cyphermox: OK, so in your view, nplan is ready to release despite that failure? [14:50] rbasak: correct [14:51] 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] 0.32 is all good; I'll add workarounds for what's left [14:53] if things have no tested against 0.32, they're not good [14:55] I suppose we need to land nplan 0.32 into the updates pocket first then, and then retry those SRUs [14:55] Uh, those other rdep dep8 tests [14:57] I see only util-linux, which hasn't tested against nplan 0.32~16.04.3, but it shouldn't really matter there === rbalint_ is now known as rbalint [16:38] cascardo: hello, kudos for the upload for LP#1734147 [16:38] cascardo: what's the present state in terms of who in the HW can perform testing/ [16:39] sladen: well, I am just one of guys hitting the buttons [16:39] sladen: some testing has been made by anthonywong [16:41] ypwong: ^^ [16:41] ypwong: have you got hardware and are in a position to do testing for bug LP#1734147 ? [16:44] sladen, i will go to ODM tomorrow to test things suggested by mika [16:44] to see if we can recover from failed bios [16:45] sladen: oh, you are the one looking on how to recover this by software, kudos to you! [16:47] ypwong: have you had contact with Mika W. (other than what I forwarded to the bug report today)? [16:49] 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] cascardo: ...stuck with not having access to hardware in this case [16:53] 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] 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] sladen, once the bios is affected the kernel update cannot help [16:58] so it's just to prevent more people get burnt [17:01] afaik, we want to prevent more accidents. so even a new image will be built with that kernel [17:36] jackpot51: You might want to check if Pop is affected by the bug in the topic, just an fyi ;) [19:32] LocutusOfBorg: on it now [19:42] ugh [20:17] LocutusOfBorg: Let's hope it's fixed now [20:18] LocutusOfBorg: I have no idea, it worked for me [20:27] Oh, how I hate global variables. [20:49] juliank: I think software-properties is still failing from the log of running tests [20:50] acheronuk: oh I see [20:50] damn [20:52] oh right [20:52] I have to clear the config first before runninig init() again [20:54] for k in apt_pkg.config.keys(): apt_pkg.config.clear(k) [20:58] next attempt :D [20:59] ugh [21:01] uploaded .19 [21:11] juliank: fingers crossed. thanks [21:19] 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] PenguinPerk: the preinst or more likely postinst script [21:21] @TJ-, here is the error: chown: changing ownership of '/var/lib/unifi/backup': Input/output error [21:21] Error: "TJ-," is not a valid command. [21:24] PenguinPerk: check the package's .postinst script [21:26] @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] Error: "TJ-," is not a valid command. [21:27] PenguinPerk: don't use @ ... it's enough to tab-complete my nickname [21:28] PenguinPerk: Pull the source of the package, or look at /var/lib/dpkg/info//postinst [21:28] I will look, I may not have access to the src [21:34] @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] Error: "TJ-," is not a valid command. [21:35] PenguinPerk: "apt-get source " [21:36] @TJ-, no luck...I can call Ubiquiti support line if i have to....trying to work around with having to call. [21:36] Error: "TJ-," is not a valid command. [21:37] PenguinPerk: did you look for "/var/lib/dpkg/info/unifi.*" ? [21:41] TJ-, thanks [21:53] thanks juliank :) [21:53] Still one failure [21:54] but on ppc64el [21:54] that might have always failed [21:55] amd64 succeeded [21:55] i386 too [21:55] so the regressions should be taken care of [21:57] 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] but: since I only made changes to tests/ I guess that can easily be overridden [21:59] as obviously my changes to tests/ can't cause regressions in other packages :D [22:14] juliank: seems to be passing on my retries against pyqt5 as well (amd64,i386). thanks [22:16] acheronuk: wonderful === desole is now known as hggdh