| 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 | 08:48 |
|---|---|---|
| ubottu | 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 | 08:48 |
| 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:31 |
| juliank | um, /tmp/autopkgtest.T5cpXr/build.XAo/src/tests//tmp/autopkgtest.T5cpXr/build.XAo/src/tests seems kind of double | 09:35 |
| juliank | The Debian one just always failed, there's nothing fancy going on there. | 09:39 |
| 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:41 |
| juliank | LocutusOfBorg: In that case, adding apt_pkg.init() to clear_apt_config() should fix the issue | 09:43 |
| juliank | In general, all tests should probably run apt_pkg.init() in setUpClass so they can be run in any order. | 09:44 |
| LocutusOfBorg | so juliank can you please fix it? :) | 10:03 |
| doko | jamespage: cantor autopkg test fails with the recent qt5 | 10:30 |
| jamespage | doko: did you mean that for me? | 10:32 |
| doko | jamespage: ahh crap, sorry | 10:34 |
| doko | tsimonq2: ^^^ | 10:34 |
| jamespage | doko: no worries | 10:37 |
| jamespage | I was worried openstack had grown some sort of new dependency :-) | 10:37 |
| === ScriptRipper_ is now known as ScriptRipper | ||
| tsimonq2 | doko: ...please be more specific | 12:25 |
| doko | tsimonq2: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html triggered by python3.6 | 12:34 |
| rbasak | cyphermox: are you aware of the nplan s390x dep8 failure in xenial? | 12:54 |
| rbasak | apw: no SRU paperwork in bug 1737640? I don't know how to check that the SRU verification minimises regression risk. | 12:58 |
| ubottu | 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 | 12:58 |
| apw | rbasak, bah smb should know better | 13:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| apw | rbasak, the primary failure mode was ifup -a would not complete successfully for unrelated interfaces with no fan configuration | 13:07 |
| 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:08 |
| 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 |
| === 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: | ||
| rbasak | OK :) | 13:09 |
| apw | rbasak, i am also worried the promised follow up to get this fixed in later series has not yet happened either | 13:10 |
| 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:11 |
| 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 | 13:16 |
| tsimonq2 | doko: ack | 14:12 |
| smoser | anyone else lately seen chnages in git shell tab complete ? | 14:26 |
| 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:27 |
| smoser | no changes recently to git (which provides /usr/lib/git-core/git-sh-prompt) | 14:28 |
| smoser | hm.. something seemed to have gotten foobarred in shell window i guess. | 14:43 |
| smoser | nothing to see here folks, move along... | 14:43 |
| 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:49 |
| 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:50 |
| 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:51 |
| cyphermox | 0.32 is all good; I'll add workarounds for what's left | 14:52 |
| cyphermox | if things have no tested against 0.32, they're not good | 14:53 |
| 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:55 |
| cyphermox | I see only util-linux, which hasn't tested against nplan 0.32~16.04.3, but it shouldn't really matter there | 14:57 |
| === rbalint_ is now known as rbalint | ||
| 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:38 |
| cascardo | sladen: well, I am just one of guys hitting the buttons | 16:39 |
| cascardo | sladen: some testing has been made by anthonywong | 16:39 |
| sladen | ypwong: ^^ | 16:41 |
| sladen | ypwong: have you got hardware and are in a position to do testing for bug LP#1734147 ? | 16:41 |
| 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:44 |
| cascardo | sladen: oh, you are the one looking on how to recover this by software, kudos to you! | 16:45 |
| sladen | ypwong: have you had contact with Mika W. (other than what I forwarded to the bug report today)? | 16:47 |
| 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:49 |
| sladen | cascardo: ...stuck with not having access to hardware in this case | 16:51 |
| 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:53 |
| 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:55 |
| ypwong | so it's just to prevent more people get burnt | 16:58 |
| cascardo | afaik, we want to prevent more accidents. so even a new image will be built with that kernel | 17:01 |
| tsimonq2 | jackpot51: You might want to check if Pop is affected by the bug in the topic, just an fyi ;) | 17:36 |
| juliank | LocutusOfBorg: on it now | 19:32 |
| juliank | ugh | 19:42 |
| juliank | LocutusOfBorg: Let's hope it's fixed now | 20:17 |
| juliank | LocutusOfBorg: I have no idea, it worked for me | 20:18 |
| juliank | Oh, how I hate global variables. | 20:27 |
| acheronuk | juliank: I think software-properties is still failing from the log of running tests | 20:49 |
| juliank | acheronuk: oh I see | 20:50 |
| juliank | damn | 20:50 |
| juliank | oh right | 20:52 |
| juliank | I have to clear the config first before runninig init() again | 20:52 |
| juliank | for k in apt_pkg.config.keys(): apt_pkg.config.clear(k) | 20:54 |
| juliank | next attempt :D | 20:58 |
| juliank | ugh | 20:59 |
| juliank | uploaded .19 | 21:01 |
| acheronuk | juliank: fingers crossed. thanks | 21:11 |
| 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:19 |
| TJ- | PenguinPerk: the preinst or more likely postinst script | 21:20 |
| 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:21 |
| TJ- | PenguinPerk: check the package's .postinst script | 21:24 |
| 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:26 |
| TJ- | PenguinPerk: don't use @ ... it's enough to tab-complete my nickname | 21:27 |
| 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:28 |
| 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:34 |
| TJ- | PenguinPerk: "apt-get source <packagename>" | 21:35 |
| 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:36 |
| TJ- | PenguinPerk: did you look for "/var/lib/dpkg/info/unifi.*" ? | 21:37 |
| PenguinPerk | TJ-, thanks | 21:41 |
| LocutusOfBorg | thanks juliank :) | 21:53 |
| juliank | Still one failure | 21:53 |
| juliank | but on ppc64el | 21:54 |
| juliank | that might have always failed | 21:54 |
| juliank | amd64 succeeded | 21:55 |
| juliank | i386 too | 21:55 |
| juliank | so the regressions should be taken care of | 21:55 |
| 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:57 |
| 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 | 21:59 |
| acheronuk | juliank: seems to be passing on my retries against pyqt5 as well (amd64,i386). thanks | 22:14 |
| juliank | acheronuk: wonderful | 22:16 |
| === desole is now known as hggdh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!