[03:41] <pleia2> adding 16.04.3 release announcement from yesterday to the fridge
[03:46] <tsimonq2> pleia2: thanks


[00:13] <shaunm> mdke: mallard is designed to allow you to add functionality by using elements and attributes in different xml namespaces
[00:13] <shaunm> mdke: e.g. the mouseovers on index.page
[00:14] <shaunm> those are extensions
[00:14] <Captainkrtek> hey shaunm think you could look over two pages I wrote?
[00:14] <shaunm> j1mc: http://blogs.gnome.org/shaunm/tag/mallard/
[00:14] <shaunm> j1mc: ^^^ facets
[00:15] <shaunm> Captainkrtek: I can, but I'm not in a position to test technical accuracy
[00:15] <Captainkrtek> oh okay
[00:15] <Captainkrtek> well anything helps
[00:15] <Captainkrtek> if anyone could as well: see the last 4 commits, https://code.launchpad.net/~steven.richards/+junk/gnome-help
[00:19] <jbicha> Captainkrtek: I'll look at them now too
[00:19] <Captainkrtek> thanks jbicha !
[00:19] <Captainkrtek> Not sure if all the terminology is correct, haven't used unity much
[01:04] <jbicha> Captainkrtek: there already is a dash search page: unity-dash-intro
[01:06] <jbicha> and shell-apps-favorite is the one we're using for favoriting or pinnings apps to the launcher
[01:07] <jbicha> and if you want to rename or move files, use bzr mv
[01:08] <jbicha> but the rest is good I'm committing in just a moment
[03:08] <Captainkrtek> thanks jbicha :)
[10:41] <jbicha> mdke: oops I forgot to push an update from last night
[10:41] <jbicha> is that pot thing something I should run?
[10:43] <mdke> jbicha: nope, I'll do it. I'm updating the template in Launchpad after doing so
[10:43] <mdke> whoops
[10:43]  * mdke thanks bzr uncommit
[10:45] <jbicha> ok, pushed, talk to you later
[10:45] <mdke> jbicha: cheers


[13:03] <Lindon-Wynta> 52GB done, ~47GB to go :/
[13:04] <Lindon-Wynta> Downloading a copy of Precise repos for offline use
[13:05] <Lindon-Wynta> Then I gotta get KDE3 repos and some others...
[13:06] <Lindon-Wynta> Does anyone know if Ubuntu Software Store will actually work, if sources.list is directed to local repos?
[13:07] <Lindon-Wynta> Or will if everything be greyed out, if Software Centre detects no Internet connection?
[13:07] <sagaci> just in case the internet goes down
[13:08] <jaddi27> i think you can set it up to use a local repo
[13:08] <Lindon-Wynta> Hmmm
[13:08] <sagaci> Lindon-Wynta: no, they come from extras.ubuntu.com
[13:08] <sagaci> I might be wrong
[13:08] <jaddi27> head_victim would know more - he has done it before
[13:08] <sagaci> sorry
[13:08] <Lindon-Wynta> That's ok, I'm more of a Synaptic / CLI guy
[13:09] <Lindon-Wynta> Software Centre is nice, little slow for me
[13:09] <sagaci> I thought you meant that special part of the store
[13:09] <Lindon-Wynta> That's ok, thanks anyway
[13:09] <sagaci> in that case, it should all work, unless you install a package that need to download from external source, ie. flash, ms fonts
[13:10] <Lindon-Wynta> yeah, been trying to take care of that too lol
[13:10] <Lindon-Wynta> I found an offline-MSFont installer
[13:10] <Lindon-Wynta> Flash is easy
[13:12] <Lindon-Wynta> It's all easy, really, just very tedious over a ~5Mbit - 6Mbit connection :/
[13:13] <Lindon-Wynta> Well, it's not so much that, mainly the servers seem to take their time sending me the data
[13:13] <head_victim> Lindon-Wynta: what we did for an installfest was rsync an entire repository (it's around 500GB from memory?) and then do some dns foo to make everything point to a webserver running the repo
[13:13] <head_victim> It took me a couple of days to sync the whole repo over Telstra cable from aarnet
[13:14] <head_victim> The idea being all computers on the network use the local copy then and it's super quick to install software.
[13:14] <Lindon-Wynta> head_victim, yeah I'm using debmirror for Ubuntu via aarnet and rsync (custom script) for openSUSE
[13:14] <head_victim> Ah, I didn't do anything custom for the rsync, I literally just rsynced the whole mirror (archive and releases)
[13:17] <Lindon-Wynta> Yeah, rsync doesn't descriminate against which files it pulls
[13:17] <Lindon-Wynta> Which I think is rather handy
[13:18] <head_victim> Yeah, it was handy. Took forever and still chewed over 100gb a month keeping it up to date
[13:19] <head_victim> I haven't updated it since January though (the USB drive it's on is sitting in the cupbaord) so I'm thinking maybe a whole new download would be easier.
[13:19] <Lindon-Wynta> Yeah, well mine will mainly be "fire and forget". I'll grab what updates for Prices there are now (or soonish), but after that, that's it.
[13:19] <Lindon-Wynta> *Precise
[13:19] <head_victim> Yeah, I had everything from 10.04 up here so figured may as well do the lot.
[13:20] <Lindon-Wynta> Ahhh can't wait for Quetzal, I have enough issues with Precise typos lol
[13:20] <head_victim> I gotta charge, feel to hang around and ask questions though. sagaci and jaddi27 are both pretty clued in :)
[13:20] <Lindon-Wynta> Cya head_victim
[13:20] <Lindon-Wynta> Thanks
[13:23] <Lindon-Wynta> sagaci, So, I was planning on pulling extras.ubuntu, does this mean I should have the "meta-data" (fancy stuff) for Software Store?
[13:51] <sagaci> Lindon-Wynta: I'm not sure how that would work since some of that is proprietary and/or paid for softwares


[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