[04:44] <dupingping> https://bugs.launchpad.net/lightdm/+bug/1517309
[05:38] <pitti> smoser, slangasek: booting with systemd.log_target=console will make the logging visible to the console if you don't want it in the journal; systemd.log_level=debug only increases verbosity of systemd itself -- if you want also kernel debugging, use "debug" (the kernel reads that by itself)
[05:39] <pitti> logging to kmsg is also useful in some cases, mostly if the journal is broken
[05:40] <pitti> sarnold, jetsaredim: err, do you still see bug 1511376 with current images? I'm not aware of anything else right now that still creates broken /etc/mtab, what/how did you install?
[05:40] <pitti> and yes, you can ignore kdbus, it's not at all related
[05:40] <jetsaredim> pitti: it got sorted
[05:40] <jetsaredim> thanks
[05:41] <pitti> jetsaredim: still some installer problem?
[05:41] <jetsaredim> turns out systemd was complaining about a fstab entry for a mdadm device that had yet to be created in the boot cycle
[05:42] <pitti> that still sounds like a bug
[05:42] <jetsaredim> it was a user-created md
[05:42] <jetsaredim> if that matters
[05:43] <jetsaredim> I regularly have issues with the system every time it reboots having to go in and manually stop & re-assemble the dev
[05:43] <pitti> I mean, MD arrays are supposed to be auto-assembled at boot, and if fstab wants to mount something from it it should wait until that has happened
[05:43] <pitti> so apparently the waiting part works, but not the assembly
[05:43] <jetsaredim> it certainly waited
[05:43] <jetsaredim> yea
[05:43] <jetsaredim> not sure what's with my config i don't reboot the system that often so it only comes up about twice a year
[05:44] <jetsaredim> its like the auto-config that's supposed to happen on boot is just not smart enough to do it right
[05:45] <jetsaredim> when the system's finally up and I can login I literally just have to run "mdadm -S <dev>; mdadm --assemble <dev>" and all is right with the world
[05:47] <jetsaredim> which you'd *think* would work during boot too...
[07:13] <nils17>  Does any one have an idea: when executing the command (alt+f2)  gksudo xfce4-terminal I get the warning "granted permissions without ask for password"... do you know where this setting is stored? (to disable it)
[07:32] <dholbach> good morning
[07:35] <FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 ?
[07:38] <pitti> FourDollars: that looks more or less like a straight port of the upstream gnome-settings-daemon heuristics, right?
[07:38] <FourDollars> pitti: yes
[07:41] <pitti> replied
[07:42] <pitti> FourDollars: this is loads better than https://code.launchpad.net/~kaihengfeng/unity-settings-daemon/add-brightness-limit-mechanism/+merge/277416 :)
[07:42] <FourDollars> pitti: yup
[07:44] <FourDollars> pitti: Thx a lot. BTW, when will it be merged into lp:unity-settings-daemon if everything is OK?
[07:46] <pitti> FourDollars: it's CI train managed, so I guess you can just reuqest a landing
[07:48] <FourDollars> pitti: How can I request a landing?
[07:48] <pitti> FourDollars: there's a new system, https://requests.ci-train.ubuntu.com/
[07:48] <pitti> I haven't used it myself either yet, but hopefully not too different from the old spreadshet
[07:49] <pitti> otherwise the desktop team can certainly help you with that
[07:49] <seb128> that system is to do landings though
[07:49] <seb128> not to request somebody else to do one for you
[07:49] <pitti> right, but can't FourDollars request/do a landing?
[07:49] <seb128> and we do regular u-s-d landings when there are enough changes to justify one
[07:49] <pitti> ah, ok
[07:49] <seb128> pitti, dunno what team membership is needed
[07:49] <seb128> if you have upload rights you can
[07:50] <seb128> but FourDollars probably doesn't have upload rights on the desktop set
[07:50] <FourDollars> Yup, I don't have the upload rights.
[07:50] <pitti> seb128: I thought that was the purpose of the train?
[07:50] <pitti> most phone developers don't have archive upload rights either
[07:52] <seb128> right
[07:52] <seb128> I think there is a lp team you need to join though
[07:52] <FourDollars> Ha~ After I login https://requests.ci-train.ubuntu.com, there are many pages I can not access.
[07:52] <seb128> better to ask on #ubuntu-ci-eng
[08:23] <LocutusOfBorg1> dupingping, hi, you there?
[08:23] <LocutusOfBorg1> wrt your virtualbox pkg join request
[08:24] <dupingping> LocutusOfBorg1: yes, i'm here.
[08:24] <LocutusOfBorg1> why did you request to join?
[08:24] <LocutusOfBorg1> that team is well... empty
[08:24] <dupingping> debian virtualbox team?
[08:25] <LocutusOfBorg1> you asked to join to the ubuntu virtualbox team, not the debian one
[08:25] <LocutusOfBorg1> I maintain virtualbox, but I use the alioth debian infrastructure for doing it
[08:25] <LocutusOfBorg1> anyway, do you plan to contribute in virtualbox?
[08:25] <dupingping> yes, right.
[08:26] <dupingping> And what is launchpad.net url for join?
[08:27] <LocutusOfBorg1> https://alioth.debian.org/projects/pkg-virtualbox
[08:29] <dupingping> LocutusOfBorg1: I created a new account.
[08:30] <dupingping> It shows me, https://launchpad.net/~pkg-virtualbox-devel and "Debian Virtualbox Team" team.
[08:30] <dupingping> wow, I have been joined.
[08:30] <dupingping> thank you.
[08:30] <LocutusOfBorg1> yes, but there is nothing to do on launchpad
[08:30] <LocutusOfBorg1> you need to apply to alioth
[08:31] <dupingping> oh, yes.
[08:36] <dupingping> I logged in to alioth, LocutusOfBorg1
[08:41] <LocutusOfBorg1> before accepting you I would like to see some patches, or some work on virtualbox
[08:41] <LocutusOfBorg1> it is a really deep package, and *really* difficult to maintain
[08:42] <dupingping> yes, i'll show a patch on oracle i made.
[08:42] <LocutusOfBorg1> e.g. you might start with testing this https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1517161 :)
[08:42] <dupingping> can you see https://forums.virtualbox.org/viewtopic.php?f=37&t=74546&p=345693#p345693 ?
[08:42] <LocutusOfBorg1> "You are not authorised to read this forum."
[08:43] <dupingping> yes, perhaps, you are not a virtual box contributor on oracle?
[08:43] <dupingping> virtualbox 5.0.x's revision r58717 is my patch.
[09:23] <cpaelzer> smb and I were discussing about the proper use of debian/watch
[09:23] <cpaelzer> we wondered if it should be encoded in a way to refer to the latest "possible" tarball
[09:24] <cpaelzer> or the latest tarball to the currently packaged version
[09:24] <cpaelzer> e.g. if we have Package-2.0 - should it
[09:24] <cpaelzer> a) only fetch and report 2.0.x updates
[09:24] <cpaelzer> b) or any >2.0 updates
[09:24] <cpaelzer> rbasak (and others) ^^ ?
[09:36] <pitti> cpaelzer: if you package multiple major upstream series, restricting it to the current microversion of that series seems adequate
[09:44] <LocutusOfBorg1> hi folks, is the ci sleeping today?
[09:44] <LocutusOfBorg1> http://autopkgtest.ubuntu.com/packages/v/virtualbox/xenial/amd64/
[09:44] <LocutusOfBorg1> I don't see the tests going
[09:47] <FourDollars> pitti: I saw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 is changed to "Won't Fix" by you. Could you help to change it back to Confirmed?
[09:48] <pitti> FourDollars: ah, you can't? done
[09:48] <pitti> ("in progress")
[09:48] <FourDollars> pitti: I don't have the permission to do that.
[09:49] <FourDollars> pitti: In fact, I also want to fix it in trusty. But I don't have the permission to also affect trusty series too.
[09:51] <pitti> FourDollars: added
[09:51] <FourDollars> pitti: thx
[09:57] <cpaelzer> pitti: thx
[09:59] <rbasak> cpaelzer: it's entirely up to you. For an Ubuntu-only package there isn't anything that runs uscan automatically for you. So debian/watch is only as useful as your ability to run uscan. So make uscan do what you want :)
[10:01] <cpaelzer> rbasak, thanks++
[10:19] <FourDollars> pitti: Could you help to set https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 as a top approved?
[10:19] <pitti> FourDollars: done
[10:19] <FourDollars> pitti: Cool. Thx.
[10:40] <Laney> cjwatson: What's the status on the ppc64el/wily upgrade?
[10:41] <Laney> We have gtk+3.0 -> mir -> liburcu blockage coming up. :)
[10:43]  * Laney sees some comments on the ticket
[10:57] <cjwatson> Laney: waiting for IS to see if wily images work on arm64 this time, then I should be able to ask for ppc64el/production shortly after
[10:59] <Laney> 'k
[11:11] <cjwatson> Laney: ah, progress on the ticket so I've replied asking for ppc64el/production
[11:12] <Laney> cjwatson: Oh, great, thanks
[11:51] <dupingping> hi lightdm developers.
[13:46] <smoser> pitti, thanks for following up.
[13:46] <pitti> smoser: what? where?
[14:23] <Mirv> could a core-dev do a QA acked copy to xenial (train is not understanding our switch of one binary package to new source package, so publishing manually): ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-005 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b ubuntu-ui-toolkit - everything else is done
[14:24] <Mirv> ticket https://requests.ci-train.ubuntu.com/#/ticket/670
[14:48] <pitti> Mirv: done
[16:41] <MrBIOS> good morning, would anyone who is familiar with the casper/livecd boot process happen to be around? I’m trying to debug some stuff and not having much luck
[17:25] <MrBIOS> bdmurray: ping
[17:27] <bdmurray> MrBIOS: hi
[17:27] <MrBIOS> bdmurray: I wanted to ping you regarding an (old, sadly) casper ticket https://bugs.launchpad.net/ubuntu/+source/casper/+bug/504103
[17:28] <MrBIOS>  any reason why that’s gotten zero love in four years? :"(
[17:29] <bdmurray> MrBIOS: Is that really the question you want me to respond to?
[17:30] <MrBIOS> well, if there’s a known workaround, I’d happily employ that
[17:30] <MrBIOS> I’m unfamiliar with the Ubuntu bug triage process
[17:30] <MrBIOS> all I really want to do is accomplish an install
[17:31] <Laney> xnox: you want to take the mdadm merge off me?
[17:31]  * Laney spots the new maintainer :)
[17:31] <bdmurray> There are lots and lots of bugs and this one only affects a couple of people, based off the bug, and is something of a corner case.
[17:33] <bdmurray> Are you trying to install a desktop version of Ubuntu?
[17:35] <MrBIOS> bdmurray: yes, I’m definitely in corner-case-land
[17:36] <MrBIOS> deep into it. I should set up a fort
[17:36] <MrBIOS> out of curiosity, do you guys accept man page improvements? :)
[17:37] <bdmurray> MrBIOS: Of course we'd accept a fix.
[17:40] <MrBIOS> bdmurray: I’m also getting an error when scripts/casper-bottom/25adduser gets called, where the  step fails with “pwconv: failed to change the mode of /etc/passwd- to 0600” and I have no idea why. Is that a known issue? I see it a lot in google searches, but not as the focus of attention
[17:41] <MrBIOS> this is unfortunate, since I then have no way to log in to examine log files to figure out why things aren’t progressing further
[17:41] <bdmurray> What release are you installing and how did you create the usb stick?
[17:41] <MrBIOS> this is 16.04, and I DD’ed the ISO to the stick.
[17:42] <MrBIOS> the same thing happens with 15.10 and earlier though
[17:56] <tsg> micahg: can you please comment on https://bugs.launchpad.net/trusty-backports/+bug/1515710?  what is needed to resolve this - there are 3 openstack bugs that are pending on this request, so I can provide any help needed
[17:57] <tsg> micahg: the trusty and precise backports are more critical
[18:02] <Laney> cjwatson: https://launchpad.net/ubuntu/+source/liburcu/0.9.1-2/+build/8293095 excellent
[18:02] <cjwatson> Laney: liburcu built now; will just need a bit of proposed-NBS cleaning
[18:02] <Laney> hah
[18:02] <cjwatson> yep :)
[18:02] <cjwatson> ppc64el guests are wily now
[18:02] <Laney> thanks for getting that fixed
[18:02]  * Laney nods
[18:03] <cjwatson> np
[18:03] <Laney> maybe autopkgtest will be less extremely backed up by tomorrow morning
[18:03] <Laney> gtk's triggered tests have barely moved all day
[18:03]  * Laney floats some more clouds
[18:03] <slangasek> according to pitti the queue is about a day long currently
[18:07] <cjwatson> Laney: liburcu2 proposed-NBS cleaned up too.  so now it's just whatever remains from that library transition
[18:07] <cjwatson> (2 -> 4)
[18:08] <Laney> Yeah. I'll look when update_output.txt has something to say about the matter tomorrow
[18:08] <Laney> 'night
[18:59] <lpotter> is there any way to edit my comments on a bug in launchpad?
[18:59] <dobey> no
[19:17] <smoser> hey
[19:18] <smoser> is this a known issue
[19:21] <lpotter> awe: ping
[19:21] <awe> lpotter, pong
[19:22] <lpotter> awe: in regards to nm bearer plugin. upstream has been refactored a bit, so it might benefit to use that
[19:22] <lpotter> I thought it had already been updated to it
[19:23] <awe> lpotter, has the code been released by upstream yet?  or is it just part of their latest devel?
[19:23] <awe> I'm super new to the Qt codebase
[19:23] <awe> I only started looking at as I started chasing this bug
[19:23] <lpotter> I am sure it was released
[19:24] <awe> ok, I'll poke around this afternoon
[19:24] <awe> it'd be great if they've already fixed this match rule leak
[19:24] <awe> it looks to me like a ref count problem
[19:25] <awe> as I'm never seeing the match rules ever get released by QDBusConnectionPrivate
[19:25] <lpotter> well, I refactored all objects so the are derived from QDBusAbstractInterface
[19:26] <lpotter> the old code is pretty fugly
[19:27] <awe> lpotter, I think the current code does that
[19:28] <awe> eg. QNetworkManagerInterfaceAccessPoint does so
[19:29] <awe> and it's the obect that's not properly disconnecting a signal watch for "PropertiesChanged"
[19:29] <awe> it also apparently sends a "GetAll" in response to the "PropertiesChanged" signals
[19:29] <awe> which is kinda broken too
[19:31] <lpotter> hmm.. I must have wrong ubuntu repo or something. all I see is original really ugly code
[19:31] <awe> well.... I've actually downloaded the source package from the phone overlay PPA
[19:32] <awe> as I didn't want to hunt for the VCS
[19:32] <lpotter> upstream uses the property map from PropertiesChanged
[19:32] <awe> when you say upstream, do you mean the 5.5 release, or code in devel branch?
[19:33] <awe> I just cloned the git5 repo...
[19:33] <lpotter> should be 5.5 but I could be wrong. I've lost track of Qt releases
[19:33] <awe> this is a slippery slope
[19:33] <awe> lpotter, k
[19:34] <awe> I'll take a look this afternoon...  so close to solving this bug, which has a *huge* perf impact
[19:35] <lpotter> yes 5.5.0 release has the changes
[19:36] <awe> ok; I'll def compare our code to that branch then
[19:36] <lpotter> :q
[19:41] <micahg> tsg: commented
[19:45] <lpotter> awe: but then the problem will be those blocking dbus GetAll calls when those objects are created. Which cannot really be changed as QNAM depends on syncronous backends
[19:45] <awe> lpotter, so... in the bug I'm working on, it sounded like "blocking" was an ambiguous term
[19:45] <awe> are you describing "blocking IO"?
[19:45] <lpotter> blocking as it waits until is gets an answer
[19:45] <awe> or apparmor "blocking"?
[19:46] <awe> got it
[19:46] <awe> we're on the same page then
[19:46] <lpotter> :)
[19:46] <awe> Mirv mentioned something about "apparmor blocking"
[19:46] <lpotter> there's that too.
[19:47] <awe> I care less about that, as it's a confined app problem, and I'll let others solve it
[19:47] <lpotter> which is why I wrote and suggested the connectivity-api plugin
[19:47] <awe> I'm just trying to ensure the plumbing works when used by unity, maliit, ...
[19:47] <awe> and doesn't gum up the rest of the system
[19:47] <awe> we have a security team to worry about apparmor, and they're all smarter than me anyways...
[19:47] <awe> ;D
[19:48] <lpotter> :)
[19:48]  * awe hopes the qt submodules don't eat all his diskspace
[19:48] <lpotter> at least its not aegis
[19:50] <lpotter> because of app armor restrictions on phone, all thats really needed in bearer is connected/disconnected
[19:50] <awe> for confined apps you mean?
[19:51] <awe> because the system apps need to distinguish between connected 'wifi' vs. connected '3g'
[19:51] <awe> and I think every process also needs to know about flight-mode
[19:51] <awe> and/or individual 3g blocked, wifi blocked
[19:52] <lpotter> do they use QtBearerNetwork?
[19:52] <lpotter> I meant for things using QNetworkAccessManager and QNetworkRequest & friends
[19:53] <awe> it's a bit confusing, and I can't answer all of those questions directly
[19:53] <awe> as I don't know the code bases all that well
[19:53] <lpotter> if they use QNetworkConfigurationManager than yes, that connectivity-api will not be useful
[19:53] <awe> ( I typically work on ofono, NetworkManager, ... )
[19:54] <awe> lpotter, https://bugs.launchpad.net/ubuntu-rtm/+source/location-service/+bug/1480877/comments/68
[19:54] <awe> this doesn't include all system processes, but it mentions the ones that show up in my dbus scans
[20:01] <lpotter> cleanup code rely's on Qt's own object clean up. but if that is delayed due to parent not getting deleted for long time I can see thats a problem. with app armor on top those signals wont get disconnected straight away.
[20:02] <awe> so again... this is only when used from unity8 directly, which should be totally unconfined
[20:02] <lpotter> hmm maybe QDBus does things differently
[20:02] <awe> I'm assuming if the layer can add dbus signal match rules
[20:02] <awe> it can remove them
[20:02] <awe> if it can't
[20:02] <awe> it's badly broken
[20:02] <awe> I see the correct calls happening in the networkmanager plugin
[20:03] <awe> it's just that qtdbus doesn't seem to be removing the rules
[20:03] <awe> it looks like the rules are ref counted
[20:03] <awe> so someone's holding on to a ref somewhere
[20:03] <awe> I'm rebuilding with a bit more debugging added to qtdbus
[20:33] <lpotter> I think the logic in QNetworkManagerEngine::removeAccessPoint is wrong. Are you seeing the QNetworkManagerInterfaceAccessPoint d'tor getting called?
[20:37] <awe> yes
[20:37] <awe> Also, I enabled QDDBUS_DEBUG=1
[20:37] <awe> before starting  Unity
[20:38] <awe> I see a log message that tells me the DBusConnection.disconnect() function succeeded
[20:38] <lpotter> it looks like when an AP is known to the system, the accessPoint object will not get deleted when it is removed
[20:38] <awe> but what I don't see is a corresponding "Removing match rule..." from QDBusConnectionPrivate
[20:38] <awe> it looks like the intention is to reference count them
[20:38] <awe> and remove if/when someone calls disconnect()
[20:39] <awe> and the ref-count == 1
[20:39] <awe> the code in 5.4.1, doesn't explicitly disconnect in that destructor
[20:39] <awe> bottom line is NM is continually adding and removing AccessPoint objects
[20:40] <awe> so the plugin needs to track them, and adjust it's match rules on the fly
[20:40] <awe> otherwise we swamp the dbus daemon
[20:40] <awe> as the plugin just continues to add match rules till WiFi is disabled, or the phone dies and/or reboots
[20:40] <lpotter> I assumed that those got disconnected when it gets desctructed
[20:41] <awe> when what gets destructed? the AccessPoint object?
[20:41] <lpotter> yes. internally to QDbus
[20:41] <awe> I looked at the doc for DBusConnection and it doesn't mention auto-disconnect for signals anywhere
[20:42] <awe> well.. it's not working automatically, and it's not working if I try to explicitly disconnect either
[20:42] <awe> ;(-
[20:43] <lpotter> there is also a problem if two AP's have the same ssid
[20:43] <awe> also, I wrote a small QtCoreApplication and played around with connect/disconnect
[20:44] <awe> and was able to properly add a match rule for the same AP
[20:44] <awe> and then remove it by calling disconnect
[20:44] <awe> so the DBus code works
[20:44] <lpotter> so the engine is holding on to an object :)
[20:44] <awe> lpotter, yea... as previously discussed this is all no-op code
[20:45] <awe> thanks for all your thoughts on this
[20:45] <awe> I'll know more if my build ever finishes
[20:46] <awe> by the way, I diffed our code to 5.5.1 and 5.6
[20:46] <lpotter> I usually try to build only QNetwork library or plugin
[20:46] <awe> and there's very little different in qnetworkmanagerservice/enginer
[20:46] <lpotter> ok
[20:46]  * lpotter wonders where that repo is
[20:46] <awe> however there's quite a bit different in qdbusintegrator.cpp
[20:46] <awe> lpotter, the ubuntu repo?
[20:47] <lpotter> yes, with the newer plugin
[20:48] <awe> well, from what I can tell... our version of Qt isn't that different than the Debian package ( at least that's what it looks like from the debian/changelog )
[20:48] <lpotter> there doesnt seem to be one master-of-all
[20:48] <awe> I'm not sure it was worth us importing into a VCS
[20:48] <awe> but Mirv_ would know better than I
[20:49] <awe> again, I just grabbed the source package from the phone overlay PPA, and extracted it locally.  Some I working with quilt
[20:49] <awe> the base is 5.4.1+dfsg-2
[20:50] <awe> with the "dfsg-2" being what appears to be the Debian version
[20:50] <awe> I've got the upstream git5 repo cloned though, so that's what I'm using for comparison against our source package
[20:56] <lpotter> it's nearing chaos hour where kids wake up and go to school...
[20:56] <stgraber> awe: +dfsg means that the source tarball was repacked by the Debian maintainer to conform to the Debian Free Software Guidelines, so you'll probably be getting a fair amount of diff compared to upstream just for that
[20:57] <stgraber> awe: there typically is documentation as to how the dfsg tarball was generated in debian/ either in a README or as code in debian/rules
[20:57] <awe> stgraber, thanks!
[20:57] <lpotter> not sure I know how to grab the phone overlay PPA
[21:00] <awe> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
[21:01] <lpotter> thanks
[21:01] <awe> you can download the orig tarball, debian diff, and dsc files, and reconstruct with dpkg-source
[21:57] <tsg> micahg: thanks - will resubmit using requestbackport - thanks for your attention!