[00:27] <sarnold> pitti: good morning; 1388962 mentions some systemd-logind errors in CurrentDmesg.txt, I'm curious if this one is for you :)
=== Elimin8r is now known as Elimin8er
=== Elimin8r is now known as Elimin8er
=== markstar is now known as mark
=== flexiondotorg_ is now known as flexiondotorg
[06:48] <pitti> Good morning
[06:49] <pitti> sarnold: those messages are bug 1359439 and only cosmetical
[06:49] <ubottu> bug 1359439 in systemd-shim (Ubuntu) "[ 7.287663] systemd-logind[1057]: Failed to start unit user@126.service: Unknown unit: user@126.service" [Undecided,Triaged] https://launchpad.net/bugs/1359439
[07:32] <pitti> infinity, ScottK, wgrant: is https://wiki.ubuntu.com/ArchiveAdministration#Blacklisting still current? I thought a while ago we discussed blacklisting the packages with an LP API?
[07:32]  * pitti wants to remove and blacklist init-select
=== maxb_ is now known as maxb
[07:58] <infinity> pitti: It's still current.
[07:58] <pitti> infinity: thanks
[09:10] <pitti> stgraber: for the resolvconf merge, do you think it's ok to drop the resolvconf/fixing-immutable debconf question now? it's a huge delta, and shoudl be obsolete after 12.04 as all the migration (making file un-immutable and move it around) was done in 12.04, right?
[09:13] <pitti> stgraber: Debian's version now just spits out an error message which explains what to do if it still happens
[09:14] <pitti> stgraber: but I'd consider this a "don't do that then" issue -- one doesn't randomly make runtime files immutable and can expect things to work still
[09:17] <pitti> meh, this is a hideously complex merge
[09:17]  * mgedmin wonders how often random websites offer 'chattr +i /etc/resolv.conf' as the "solution" to NetworkManager/resolvconf changing it all the time
[09:17] <pitti> mgedmin: they did in the past, but in 12.04 we moved to resolvconf
[09:17] <pitti> so /etc/resolv.conf is a symlink, and you can make it as immutable as you like
[09:18] <mgedmin> oh, chattr doesn't follow symlinks?  neat
[09:18] <infinity> Why would it?
[09:18] <infinity> It makes the symlink immutable.
[09:18] <infinity> It's just another file.
[10:13] <seb128> bdmurray, ev, hey, do you know why https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=file-roller&period=month lists only a libreoffice issue? changing to "week" makes it have file-roller ones, so there are reports and they should also be in the week view?
[10:13] <seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=file-roller&period=week
[10:14] <seb128> those also are all failing to retrace, is there a known issue with utopic e.u.c retracers?
[10:20] <pitti> stgraber: I now merged resolvconf, tested in a VM (with static /e/n/i) and my workstation (NM); tested upgrade, purge/reinstall
[10:21] <pitti> stgraber: the delta got a bit smaller, fortunately Debian plans to drop the /etc/resolvconf/run bits after jessie (which is 95% of our delta)
[10:21] <pitti> stgraber: do you want to review the merge before I upload? http://people.canonical.com/~pitti/tmp/resolvconf-merge/
=== _salem is now known as salem_
[11:41] <caribou> I'm working at merging libnss-ldap for a critical bug. I'm mostly done, except for one autoreconf.patch patch that fails for a few hunks
[11:41] <caribou> any specific way to deal with such autoreconf issues ?
[11:43] <caribou> LP: #1387594 btw
[11:43] <ubottu> Launchpad bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,Confirmed] https://launchpad.net/bugs/1387594
=== Sweetsha1k is now known as Sweetshark
[11:45] <geser> probably either redo the autoreconf (and update the patch file) or switch to dh-autoreconf (if possible)
[12:06] <infinity> caribou: You shouldn't generally attempt to reapply autoreconf patches to different upstream versions, that way lies madness.
[12:07] <infinity> caribou: Switching to dh-autoreconf is the best answer, if it works.  If it doesn't, fix-and-forward so it does, or redo the patch by hand.
[12:08] <infinity> caribou: Though, given that it built on all arches in Debian, the autoreconf patch may not be needed?
[12:09] <caribou> infinity: well I sort of get caught offguard with this autoreconf patch...
[12:09] <caribou> infinity: I've been hacking at the merge & was almost done, rebuilt many times
[12:09] <caribou> infinity: then I found out that that autoreconf.patch was not applied, then I got into madness :-/
[12:10] <infinity> caribou: I'm pretty sure you can just drop it.
[12:10] <caribou> infinity: it was my feeling. Then if, in your greatness of soul you agree to sponsor the merge, you will be able to confirm ;-)
[12:11] <infinity>    * Apply patch from Peter Green to solve build failure on arm* kfreebsd*
[12:11] <infinity>      (closes: #683011).
[12:11] <infinity> caribou: That's fixing the same thing our patch was meant to fix.
[12:12] <infinity> caribou: Which would also be fix-glibc-test-for-armel-gnueabi.patch, if you didn't already drop that.
[12:14] <infinity> caribou: debian/patches/treat-all-debian-systems-like-linux.patch is the one that superseded our fix-glibc-test-for-armel-gnueabi.patch and autoreconf patch.
[12:16] <infinity> caribou: I'm heading to bed (yes, really), but if you mail me about it, I can review and sponsor.  Looks like a disgusting sort of merge that I might have to re-do just to verify your result. :/
[12:19] <caribou> infinity: I took note of everything so I'll do just that; thanks !
[12:21] <infinity> caribou: Worth noting that fix-glibc-test-for-armel-gnueabi.patch was probably also subtly wrong for armhf, so we might want to SRU the patch swap when you SRU the other fix.
[13:01] <mdeslaur> arges: I think the trusty update in bug 1382133 was skipped by mistake, and is ready to be release
[13:01] <ubottu> bug 1382133 in evolution-data-server (Ubuntu Trusty) "Issue with servers with SSLv3 disabled due to Poodle " [Undecided,Fix committed] https://launchpad.net/bugs/1382133
[13:01] <mdeslaur> released
[13:01] <Laney> I only verified the second SRU today, so probably not
[13:01] <arges> mdeslaur: i'll take a look at it
[13:01] <Laney> but yeah, releasing appreciated
[13:02] <arges> todays my review day, just working on some other reviews first
[13:03] <mdeslaur> Laney: hrm? looks like someone verified it on 2014-10-21
[13:03] <Laney> mdeslaur: the *second* sru, there are two uploads waiting to go in
[13:04] <mdeslaur> Laney: oh! I see now
[13:12] <arges> mdeslaur: Laney: ok looks good released into trusty-updates.
[13:13] <Laney> thanks arges
[13:13] <Laney> ♥
[13:13] <mdeslaur> arges: thanks
[13:38] <apachelogger> does the arch-indep change to amd64 also apply to utopic builds? and if not, how does one find out what architecture is used for arch-indep?
[13:40] <infinity> apachelogger: It doesn't.  Out of curiosity, why would it matter?
[13:41] <apachelogger> infinity: various kubuntu buildtime QA bits only run on arch-indep for some reason
[13:42] <apachelogger> which was hardcoded as i386... so now things fall flat on the face ^^
[13:42] <infinity> apachelogger: That sounds like a bug, not a feature. :P
[13:42] <infinity> apachelogger: Packages should never assume an arch-indep arch.
[13:43] <infinity> apachelogger: Do you have an example?
[13:44] <apachelogger> it's not the packages, it's just additional stuff run before dh_builddeb to output data about the build
[13:44] <apachelogger> infinity: lintian for example
[13:44] <apachelogger> or actually
[13:44] <infinity> apachelogger: By "packages", I meant "source packages".
[13:44] <apachelogger> Riddell: where was it hardcoded anyway?
[13:44] <Riddell> apachelogger: in the script which makes this little report http://qa.kubuntu.co.uk/kf5-status/build_status_5.4.0_vivid.html
[13:45]  * apachelogger scratches head
[13:45] <apachelogger> infinity: ok, so it seems I was wrong it's not the packages at all but the scripts evaluating the output generated by the build
[13:45] <infinity> How is this going wrong for you?
[13:46] <Riddell> it's not now that I updated the script
[13:46] <apachelogger> Riddell: now it's wrong for utopic
[13:46] <apachelogger> infinity: let me read the code, I am very unsure about the details
[13:46] <infinity> Riddell: I guess what I was asking was why was it hardcoding an arch-indep arch, and could it be made smarter? :P
[13:47] <infinity> Riddell: As in, why does it need to know at all?
[13:47] <infinity> But yes, maybe seeing the script would be enlightening.
[13:50] <Riddell> the /usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk makefile which is what we use to build our packages only runs the bits which output list-missing on arch-indep it seems, dunno why
[13:51] <apachelogger> I don't even see why
[13:51] <apachelogger> post_binary: list-missing lintian
[13:53] <apachelogger> ah different target, apparently post_binary-arch is what would be calle don !indep
[13:53] <infinity> apachelogger: post-binary probably only gets run on full builds, on arch-dep builds, it's probably something like post-binary-arch
[13:53] <infinity> apachelogger: Jinx.
[13:54] <infinity> apachelogger: post_binary-arch is probably a dep of post_binary, though, so would be called in either case.
[13:55] <apachelogger> infinity: yes
[13:55] <apachelogger> so in fact lintian and list-missing are only run on arch-indep, not sure why that decision was made
[13:55] <infinity> apachelogger: I doubt it was made on purpose.
[13:56] <apachelogger> infinity: well, it's from debian pkg-kde so it might be to not waste time on the slow architectures
[13:56] <infinity> apachelogger: Unless this is inherited from Debian, then the decision would have been made so that it only ran on developers' systems.
[13:56] <infinity> apachelogger: Since arch:all is never built on buildds.
[13:56] <apachelogger> I see, would make sense
[13:56] <infinity> apachelogger: But they really need to fix that way of thinking in pkg-kde soon, since the old world order is going away. :P
[13:57] <infinity> apachelogger: Anyhow, an Ubuntu delta that did your testing on all arches would seem sane to me.
[13:57] <apachelogger> to be honest I think that would just make things more complicated
[13:58] <apachelogger> 99% of the time we'd only care about the arch-indep architecture as it presents the superset of issues lintian/list-missing would report anyway
[13:58] <infinity> Or just accept the status quo and make your scripts check for the right arch, I guess. :P
[13:59] <infinity> apachelogger: I'd challenge your assertion, though.  It's amazingly common for people to make the "full" build work, and break the arch-only build.
[13:59] <apachelogger> infinity: yeah, that's why I was asking how to figure out what the arch-indep arch is :P
[14:00] <apachelogger> I'd rather avoid fiddling with series versions to decide which log to look at
[14:00] <infinity> apachelogger: Assuming this is an lpapi script, you can use something like:
[14:00] <infinity> (base)adconrad@cthulhu:~$ lp-shell
[14:00] <infinity> E: ipython not available. Using normal python shell.
[14:00] <infinity> Connected to LP service "production" with API version "1.0":
[14:00] <infinity> Note: LP can be accessed through the "lp" object.
[14:00] <infinity> >>> lp.distributions['ubuntu'].current_series.nominatedarchindep_link
[14:00] <infinity> u'https://api.launchpad.net/1.0/ubuntu/vivid/amd64'
[14:00] <apachelogger> that should work
[14:00] <apachelogger> infinity: thanks :)
[14:01] <infinity> apachelogger: Replacing current_series with a proper API lookup of the series you care about...
[14:05] <infinity> apachelogger: Perhaps like so:
[14:05] <infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='utopic').nominatedarchindep_link
[14:05] <infinity> u'https://api.launchpad.net/1.0/ubuntu/utopic/i386'
[14:05] <infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='vivid').nominatedarchindep_link
[14:05] <infinity> u'https://api.launchpad.net/1.0/ubuntu/vivid/amd64'
[14:07] <infinity> apachelogger: Or, to just return the arch string:
[14:07] <infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='vivid').nominatedarchindep.architecture_tag
[14:07] <infinity> u'amd64'
[14:10] <apachelogger> infinity: yeah, we iter through PPA entries using the api, so we should just be able to work our way to the archindep from there
[14:13] <infinity> apachelogger: If you're iterating through builds, there will soon be a tag on each build to tell you if it was archindep or not.  That'll land this week.
[14:13] <apachelogger> ah, cool beans, best fix it next week then I guess
[14:14] <apachelogger> shadeslayer: ^ In case I forget, all tooling needs change to dynamically get archindep for builds instaed of hardcoding one
[14:14] <infinity> apachelogger: For now, though, it's perfectly reasonable to just assume vivid=amd64, and *=i386.
=== salem_ is now known as _salem
[14:15] <infinity> apachelogger: Which is the logic we'll be using to backfill the new DB column. :P
[14:15] <infinity> (Well, minus some annoying bits we need to fix from vivid opening, but la la la)
[14:16] <shadeslayer> apachelogger: ack
[14:18] <infinity> apachelogger: On an academic note that kubuntu might not care about, but is interesting nonetheless, this also fills in one of the missing puzzle pieces for abritrary package-controlled arch-indep affinity.
[14:18] <infinity> apachelogger: (Say, you want a source package to be able to say "I build an arch:all package, but it has to build on powerpc")
[14:18] <infinity> arbitrary, too.  That's an oddly difficult word to type.
[14:19] <Riddell> I do remember that being an issue for someone once
[14:19] <infinity> Yeah, me. ;)
[14:19] <infinity> Well, a few someones.
[14:19] <infinity> But typically, it's when you want to ship firmware or a bootloader or something as a "payload" package that can be installed on all arches.
[14:20] <infinity> We currently hack around it by cross-compiling a few such packages.
[14:20] <infinity> But that's gross.
[14:22]  * infinity heads to the store, wondering what combination of Vitamin C and cough syrup will lead to sleep and waking up feeling less sick.
[14:22] <StevenK> infinity: LD50 minus one teaspoon? :-P
[14:23] <infinity> StevenK: LD50 is for the weak, go 100 or go home.
[14:24] <StevenK> infinity: But that fails your requirements, since it won't lead to sleep
[14:24] <pitti> a rather long sleep..
[14:24] <infinity> StevenK: Fine, 99.
[14:24] <StevenK> Haha
[14:31] <mdeslaur> infinity: the best stuff is labelled "Whisky"
[14:32] <pitti> mdeslaur: oh, so the vitamime "C" expands to "Chivas Regal"?
[14:32] <mdeslaur> pitti: hehe :)
[14:33] <arges> mlankhorst: i see two mesa uploads in utopic... i'm assuming the old one is no longer needed?
[14:34] <mlankhorst> yeah
[14:34] <mlankhorst> figured doing .2 was just as much effort as verifying .1
=== timrc is now known as timrc-afk
[14:39] <pitti> hallyn: cgmanager sets a release_agent, but right now we don't enable notify_on_release anywhere; does cgmanager itself depend on those somehow?
[14:39] <pitti> hallyn: I'm looking into debian bug 756076 (logind sessions don't get cleaned up but stay in "Closing" forever)
[14:39] <ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope'" [Grave,Open] http://bugs.debian.org/756076
[14:40] <pitti> hallyn: systemd installs its own release handler there to tell it when a cgroup got cleaned up, then it cleans up the dangling sessions
[14:40] <pitti> hallyn: and I wonder if systemd-shim can do that, or whether we need to actually call cgmanager's release agent (which we don't ATM)
[14:41] <pitti> at least calling "sudo /run/cgmanager/agents/cgm-release-agent.systemd user.slice/user-1001.slice/session-c2.scope" currently has no effect as the cgroup itself is already gone, so one just gets a dbus error
=== sil2100_ is now known as sil2100
[14:55] <bdmurray> seb128: past month is calendar month not 30 days so the week view would include october stuff but the month view would not
=== _salem is now known as salem_
[15:13] <mdeslaur> barry: any idea why this is happening in vivid? the package names are obviously wrong: http://paste.ubuntu.com/8820356/
[15:17] <barry> mdeslaur: there was a new dh-python uploaded to unstable recently.  this is curious:   * Suggest the right file name for dependency overrides (closes: 748296).  but otoh, it looks like it was just a doco change: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748296
[15:17] <barry>  
[15:17] <ubottu> Debian bug 748296 in dh-python "dh_python2 shouldn't suggest py3dist-override" [Minor,Fixed]
[15:17] <barry> dhpy2
[15:17] <barry> so that's not it
[15:17] <barry> but i'll bet it's the dh-python upload
[15:18] <mdeslaur> yeah, I'm diffing it to try and figure it out
[15:19] <barry> mdeslaur: to be clear, you don't see that in utopic?
[15:20] <mdeslaur> barry: nope, utopic works
[15:20] <mdeslaur> barry: I think it's Add support for guessing dependencies from egg-info files (closes: 756378)
[15:20] <mdeslaur> still looking
[15:23] <barry> mdeslaur: sorry, trying to work on something else atm, but ping me if you find anything interesting
[15:23] <mdeslaur> barry: yeah, my egg-info has stuff like Requires: gi.repository.GLib , but that's definitely not how any of the gi packages are called
[15:24] <mdeslaur> barry: thanks, I'll let you know
[15:24] <mlankhorst> arges: the changelog is correct, it's a copy back from vivid to utopic
=== doko_ is now known as doko
[15:31] <hallyn> pitti: if you configure logind.conf correctly, then systemd-shim will remove the cgroups
[15:31] <pitti> hallyn: that happens by default already
[15:31] <hallyn> if you leave it set to "abandon", then it will only remove the cgroup if all tasks are already gone
[15:31] <pitti> hallyn: the thing that's missing is cleaning up logind sessions after logging out
[15:31] <hallyn> if you set it to kill (wahtever it's called) it will forcibly kill al ltasks and remove the container
[15:31] <hallyn> pitti: it's not missing, so this must be a bug.
[15:31] <pitti> hallyn: right, but the cgroup is already gone, that's not hte problem
[15:32] <hallyn> oh, you mean logind isn't told to forget about it?
[15:32] <pitti> hallyn: the problem is that the cgroups don't have notify_on_release, and no callback which tells logind that those sessions are now gone
[15:32] <pitti> hallyn: right, debian bug 756076
[15:32] <ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out" [Grave,Open] http://bugs.debian.org/756076
[15:32] <hallyn> pitti: if you don't premount the cgroups, then notify_on_release will be set by cgmanager
[15:32] <teward> anyone know what package provides udev rules?
[15:32] <hallyn> but if the cgroups were premounte,d then cgmanager will not set it (and shouldn't)
[15:33] <pitti> hallyn: in our default utopic it's not set
[15:33] <arges> cjwatson: ^^ what is the policy with SRU changelogs for backports? mlankhorst had mesa with <version>ubuntu1 (vivid) then the next entry was <version>ubuntu0.1 (utopic) ... does it make sense to have this kinda changelog?
[15:33] <arges> mlankhorst: can you post the changelog in pastebin really quick?
[15:33] <mdeslaur> barry: filed 1389283
[15:33] <hallyn> pitti: that's a bug
[15:33] <hallyn> pls file against cgmanager
[15:33] <pitti> hallyn: but anyway, even if it would set it, it would then call the cgm_release thing, which doesn't do what we need; so I primarily wondered if we'd ever need to use those for the "systemd" controller
[15:34] <hallyn> what do you mean it doesnt' do what we need
[15:34] <barry> mdeslaur: cool, thanks.  i'll forward that to p1otr
[15:34] <mlankhorst> arges: sec
[15:34] <pitti> hallyn: so the fact is, cgmanager *works*, the org.freedesktop.systemd1.Scope Abandon call now works and does clean up the cgroup (even without release_notify)
[15:34] <pitti> hallyn: but that doesn't tell logind about it, so its sessions forever stay in state "closing" and it never removes dynamic ACLs
[15:35] <hallyn> pitti: ok, that should be up to systemd-shim to do i guess
[15:35] <pitti> hallyn: correct
[15:35] <hallyn> oh, right.  ntify-on-release should NOT be set in utopic..  right
[15:35] <hallyn> pitti: ok.  i assume that's some dbus magic?
[15:35] <pitti> hallyn: but for that I need to use release_notify and plug in my own agent
[15:35] <mlankhorst> arges: i dont have the exact log, so have this mockup instead. http://paste.debian.net/130248/
[15:36] <hallyn> pitti: hold on, lemme switch rooms and get back to you
[15:36] <pitti> hallyn: and my q is whether that's ok for hte "systemd" controller, or whether my own agent should additionally call cgm_release (I don't see what for, but cross-checking)
[15:36] <mlankhorst> this has been how I did mesa updates all along, where they make sense
[15:41] <barry> mdeslaur: over in #debian-python: <p1otr> barry: which package adds gi.repository.GLib egg-info?
[15:42] <mdeslaur> barry: pasaffe (it's not in debian)
[15:42] <barry> ack
[15:42] <mdeslaur> barry: v
[15:42] <mdeslaur> barry: https://launchpad.net/ubuntu/+source/pasaffe
[15:43] <hallyn> pitti: so i'm not following.  Right now, iirc, when you log out, one and systemd-shim is installed, one of two things happens:
[15:43] <hallyn> if you've set to abandon, then cgmanager will (for all cgroup controllers) try to remove the cgroup, then set notify_on_release if the remove failed
[15:43] <hallyn> (so that the cgroup will be deleted when it becomes empty)
[15:43] <hallyn> if you've set to kill, then it'll kill all tasks and rm the cgroup
[15:44] <hallyn> it doe sit for name=systemd a swell as the others, since systemd is presumed not running
[15:44] <hallyn> as yo usaid, systemd-shim should be telling logind to remove the session as well, if that's needed.  i 8thought* that simply replying to the Abandon msg from logind would do that
[15:44] <pitti> hallyn: ok; I didn't test kill mode, just a normal logout (which doesn't leave anything behind, so the cgroup does get removed)
[15:44] <pitti> hallyn: no, it's async
[15:44] <pitti> hallyn: so roughly what happens:
[15:45] <pitti> hallyn: logind is told to close a session (ReleaseSession "c1" or so)
=== salem_ is now known as _salem
[15:45] <pitti> hallyn: then pid1 or shim picks that up, tells cgmanager to clean up etc.; this removes cgroups
[15:45] <hallyn> (or sets notify-on-release if cgroup is not yet empty)
[15:45] <pitti> hallyn: then, systemd sets notify_on_release and installs an agent which then sends the UnitRemoved session-c1.scope back to logind
[15:46] <hallyn> ok
[15:46] <pitti> hallyn: then logind removes the session, removes ACLs, etc.
[15:46] <pitti> hallyn: and the last two lines are currently missing
[15:46] <hallyn> yeah
[15:46] <pitti> hallyn: so what I need to do in shim is enable notify_on_release and install my own agent
[15:46] <pitti> which mimics what systemd as pid 1 would do
[15:46] <hallyn> that's a problem
[15:46] <hallyn> i don't recall - can you set an agent for a cgroup subtree?
[15:46] <hallyn> or only for the whole hierarchy?
[15:47] <pitti> hallyn: no, only from teh top
[15:47] <pitti> hallyn: you need to enable notify_on_release per cgroup, but there's only one global (per controller) agent
[15:47] <pitti> hallyn: so: you are saying that sometimes cgmanager needs its own handler
[15:47] <pitti> hallyn: so if systemd-shim installs its logind callback handler, it could just chainload cgmanager's?
[15:48] <hallyn> we don't know that every use of notify-on-release is going to be for such a rm, so i don't know that we can unconditionally have our release agent send that msg
[15:48] <pitti> hallyn: s/chainload/call/
[15:48] <pitti> hallyn: no no, I'm not going to tell cgmanager's agent about logind
[15:48] <pitti> and I don't want to touch any controller except "systemd"
[15:48] <hallyn> don't you need to do it for all controllers?
[15:49] <hallyn> or doe slogind only need to be told about the one
[15:49] <hallyn> you're making it sound like you would set that shim release agent only for a short time...  is that what you're thinking?
[15:53] <pitti> hallyn: no, logind is only concerned about the systemd controller
[15:53] <pitti> hallyn: hm, I think I need to set it for the entire lifetime of a session
[15:54] <hallyn> pitti: ok, that's better
[15:54] <hallyn> yeah i guess chainload is fine
[15:54] <pitti> hallyn: so systemd-shim should get the current handler, install its own, and chainload the old
[15:54] <pitti> hallyn: from my experiments calling it seems to be harmless if the cgroup is already gone
[15:55] <pitti> (but it's not too hard to check this in advance either)
[15:55] <pitti> if it causes error message spew or so
[15:55] <hallyn> pitti: sounds good.  you can push that change to systemd-shim ?
[15:56] <pitti> hallyn: yes, I'm working on it now (still need to figure out the details)
[15:56] <pitti> hallyn: but I wanted to discuss the cgm release agent with you first
[15:56] <caribou> infinity: sorry got pulled onto something else, I'll send the merge data your way tomorrow morning
[15:56] <pitti> hallyn: it's a grave bug in Debian, so we better get that fixed ASAP for the freeze
[15:56] <pitti> hallyn: I also fixed two other (simple) bugs in git already
[15:56] <arges> mlankhorst: well feel free to re-upload, but I'll let another SRU member review as I'm not confortable accepting. thanks
[15:56] <pitti> so with that one we should have a good release 9
[15:56] <pitti> hallyn: thanks
[15:57] <hallyn> pitti: why is it a grave bug?
[15:57] <pitti> hallyn: mostly for the lingering ACLs, I suppose
[15:58] <pitti> I wouldn't call it "grave" myself, but *shrug*, it should be fixed anyway
[15:58] <hallyn> oh, on sound devices and such?
[15:58] <hallyn> that makes sense
=== _salem is now known as salem_
[15:58] <hallyn> pitti: thanks much.
[15:59] <pitti> hallyn: so the scenario would be something like 1. login locally, get ACLs, log out
[16:00] <pitti> then 2. log in remotely, re-use the old permissions which you shouldn't have
[16:00] <pitti> plus, the sessions pile up, so if you have a lot of logins, it's kind of a memleak
[16:01] <hallyn> right.  i'm ok with claling that grave :)  thx
[16:05] <arges> mlankhorst: one more thing bug 1386620, is this fixed in vivid/utopic for xorg-server?
[16:05] <ubottu> bug 1386620 in xorg-server (Ubuntu Vivid) "re-enable rotation for the intel driver in optimus mode" [Critical,New] https://launchpad.net/bugs/1386620
=== josepht_ is now known as josepht
[16:28] <bdmurray> pitti: any news on bug 1370230?
[16:28] <ubottu> bug 1370230 in Apport "apport-retrace has become slower" [High,Triaged] https://launchpad.net/bugs/1370230
[16:28] <flexiondotorg> bregma, I've created a Compiz meta package for Ubuntu MATE. Which works a treat except I need to have the Window Decoration plugin enabled by default.
[16:29] <flexiondotorg> bregma, Is there a way for me to enable that plugin at the system level without compiling a separate compiz-mate (for example) package?
[16:30] <bregma> flexiondotorg, I'm surprised it doesn't work out of the box like Gnome-fallback does
[16:31] <flexiondotorg> I am going to test again on a fresh install, but without Window Decoration is would seem that the gtk-decorator is not available.
[16:31] <flexiondotorg> Therefore, no window controls.
[16:32] <flexiondotorg> bregma, Is is possible to modify to Compiz configuration at a system level via a meta package?
[16:34] <pitti> bdmurray: sorry, not yet; overloaded with other stuff ATM :(
[16:36] <bregma> flexiondotorg, unfortunately I'm not sure, it's a compizconfig issue and I'm hoping there is a way for other reasons, but really I don't know ... Trevinho do you know^^?
[16:39] <flexiondotorg> bregma, Just tested on a clean system. No window decorations by default in MATE.
[16:40] <bregma> flexiondotorg, does MATE use gnome-session?
[16:40] <flexiondotorg> bregma, No, it uses mate-session
[16:42] <Riddell> mdeslaur: bug 1389296 for some ~ubuntu-security love
[16:42] <ubottu> bug 1389296 in konversation (Ubuntu Vivid) "konversation: out-of-bounds read on a heap-allocated array" [Undecided,New] https://launchpad.net/bugs/1389296
[16:43] <mdeslaur> Riddell: thanks!
[16:46] <doko> cjwatson, plplot is merged
[16:54] <Trevinho> flexiondotorg: decor plugin is enabled by default when using the standard profile
[16:54] <Trevinho> flexiondotorg: however when accessing to an unity session, the plugin is removed using a migrationn script
[16:55] <Trevinho> flexiondotorg: so, in general it should always be there, make sure that one of the migration scripts won't delete it
[16:55] <Trevinho> or that you're using the proper profile (i.e. not the compiz ubuntu profile)
[16:55] <flexiondotorg> Trevinho, Can I enable the standard profile via a meta package? For example, in gsettings or a config file.
[16:56] <flexiondotorg> Trevinho, How can I determine which profile I have defaulted too?
[16:56] <Trevinho> flexiondotorg: migration scripts can do that, or using COMPIZ_CONFIG_PROFILE variable
[16:56] <flexiondotorg> I am a compiz nupty, but my users are really keen to have a easy way to enable compiz.
[16:56] <Trevinho> flexiondotorg: by default ubuntu unity has that variable set as "ubuntu", and that profile is for the unity sesion
[16:57] <Trevinho> yes, sure... in general in != unity sessions, the default compiz settings should be used
[16:57] <Trevinho> like it happens in the flashback
[17:00] <flexiondotorg> Trevinho, Thanks. What should the variable be for the standard profile? "Default"?
[17:01] <Trevinho> flexiondotorg: you can just unset it
[17:02] <flexiondotorg> Trevinho, OK. I'll do some testing later. I only have a VM available here and decor appears to trying to load but claims the is no compositor.
[17:03] <flexiondotorg> I'll test on real hardware later 😃
[17:04] <Trevinho> flexiondotorg: one thing you can also do is provinding a compizconfig profile, in /etc/compizconfig/mate.ini such as the one we ship with unity
[17:04] <Trevinho> flexiondotorg: this is our unity.ini http://paste.ubuntu.com/8821774/
[17:04] <Trevinho> but you can tune it more
[17:05] <flexiondotorg> Trevinho, Oooh. Does the name of the file need to match the session name?
[17:05] <flexiondotorg> I'll give that a test.
[17:05] <Trevinho> flexiondotorg: no, that's defined inside /etc/compizconfig/config
[17:07] <Trevinho> flexiondotorg: something you might look at is also /usr/share/session-migration/scripts/00_remove_unityshell_in_gnome_session.py
[17:07] <Trevinho> and other migration scripts like that
[17:07] <flexiondotorg> Trevinho, This is all very useful. Thanks.
[17:44] <sarnold> pitti: thanks :)
[18:12] <mlankhorst> arges: I'd have to check, but the xxv-intel driver works at least
=== fishor is now known as olerem
=== roadmr is now known as roadmr_afk
[21:05] <cyphermox> xnox: hey
[21:05] <cyphermox> xnox: mind if I merge ppp?
[21:43] <xnox> cyphermox: go for it.
[21:43] <xnox> cyphermox: it's actually in a dire need of a merge I believe, and I was hoping to not touch it =)
[21:43] <cyphermox> ahah, indeed it is
[21:46] <Unit193> cyphermox: Still looking into NM?
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
[22:37] <cyphermox> Unit193: I am, currently building it
[22:37] <Unit193> Fantastic, thanks for letting me know!  Some Xubuntu docs will need modified.
[22:38] <cyphermox> it's also why I asked about ppp; debian has 2.4.6 in the build-deps for NM
[22:38] <cyphermox> Unit193: ah?
[22:38] <Unit193> cyphermox: Yeah. nm-tool is mentioned.  Ah, I see.
[22:38] <cyphermox> oh, yeah
[22:38] <cyphermox> nm-tool no longer exists
[22:39] <cyphermox> you can use nmcli / nmtui instead, one is the straight CLI interface, the other is a curses-based interface
[22:39] <Unit193> Indeed, and I'm personally looking forward to nmtui. :P  But yeah, that's why I asked, know it's missing.
[22:40] <cyphermox> the equivalent of nm-tool is 'nmcli dev list', in case you're wondering
[22:40] <Unit193> Fancy that, thanks.
[22:40] <cyphermox> np
[22:41] <cyphermox> if you want to help testing, I'll ping you later when I'm done with the merge
[22:43] <Unit193> Sure, though it wouldn't be wireless, those are still on connman/utopic.