| sarnold | pitti: good morning; 1388962 mentions some systemd-logind errors in CurrentDmesg.txt, I'm curious if this one is for you :) | 00:27 |
|---|---|---|
| === Elimin8r is now known as Elimin8er | ||
| === Elimin8r is now known as Elimin8er | ||
| === markstar is now known as mark | ||
| === flexiondotorg_ is now known as flexiondotorg | ||
| pitti | Good morning | 06:48 |
| 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 | 06:49 |
| 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 | 07:32 | |
| === maxb_ is now known as maxb | ||
| infinity | pitti: It's still current. | 07:58 |
| pitti | infinity: thanks | 07:58 |
| 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:10 |
| pitti | stgraber: Debian's version now just spits out an error message which explains what to do if it still happens | 09:13 |
| 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:14 |
| 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:17 |
| 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. | 09:18 |
| 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:13 |
| seb128 | those also are all failing to retrace, is there a known issue with utopic e.u.c retracers? | 10:14 |
| pitti | stgraber: I now merged resolvconf, tested in a VM (with static /e/n/i) and my workstation (NM); tested upgrade, purge/reinstall | 10:20 |
| 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/ | 10:21 |
| === _salem is now known as salem_ | ||
| 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:41 |
| 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 | 11:43 |
| === Sweetsha1k is now known as Sweetshark | ||
| geser | probably either redo the autoreconf (and update the patch file) or switch to dh-autoreconf (if possible) | 11:45 |
| infinity | caribou: You shouldn't generally attempt to reapply autoreconf patches to different upstream versions, that way lies madness. | 12:06 |
| 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:07 |
| infinity | caribou: Though, given that it built on all arches in Debian, the autoreconf patch may not be needed? | 12:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| infinity | caribou: Which would also be fix-glibc-test-for-armel-gnueabi.patch, if you didn't already drop that. | 12:12 |
| 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:14 |
| 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:16 |
| caribou | infinity: I took note of everything so I'll do just that; thanks ! | 12:19 |
| 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. | 12:21 |
| 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:01 |
| arges | todays my review day, just working on some other reviews first | 13:02 |
| 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:03 |
| mdeslaur | Laney: oh! I see now | 13:04 |
| arges | mdeslaur: Laney: ok looks good released into trusty-updates. | 13:12 |
| Laney | thanks arges | 13:13 |
| Laney | ♥ | 13:13 |
| mdeslaur | arges: thanks | 13:13 |
| 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:38 |
| infinity | apachelogger: It doesn't. Out of curiosity, why would it matter? | 13:40 |
| apachelogger | infinity: various kubuntu buildtime QA bits only run on arch-indep for some reason | 13:41 |
| 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:42 |
| infinity | apachelogger: Do you have an example? | 13:43 |
| 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:44 |
| * 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:45 |
| 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:46 |
| 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:47 |
| 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:50 |
| apachelogger | I don't even see why | 13:51 |
| apachelogger | post_binary: list-missing lintian | 13:51 |
| 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:53 |
| infinity | apachelogger: post_binary-arch is probably a dep of post_binary, though, so would be called in either case. | 13:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| infinity | apachelogger: Replacing current_series with a proper API lookup of the series you care about... | 14:01 |
| 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:05 |
| 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:07 |
| 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:10 |
| 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:13 |
| 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. | 14:14 |
| === salem_ is now known as _salem | ||
| 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:15 |
| shadeslayer | apachelogger: ack | 14:16 |
| 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:18 |
| 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:19 |
| infinity | We currently hack around it by cross-compiling a few such packages. | 14:20 |
| infinity | But that's gross. | 14:20 |
| * 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:22 |
| infinity | StevenK: LD50 is for the weak, go 100 or go home. | 14:23 |
| 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:24 |
| mdeslaur | infinity: the best stuff is labelled "Whisky" | 14:31 |
| pitti | mdeslaur: oh, so the vitamime "C" expands to "Chivas Regal"? | 14:32 |
| mdeslaur | pitti: hehe :) | 14:32 |
| arges | mlankhorst: i see two mesa uploads in utopic... i'm assuming the old one is no longer needed? | 14:33 |
| mlankhorst | yeah | 14:34 |
| mlankhorst | figured doing .2 was just as much effort as verifying .1 | 14:34 |
| === timrc is now known as timrc-afk | ||
| 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:39 |
| 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:40 |
| 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 | 14:41 |
| === sil2100_ is now known as sil2100 | ||
| bdmurray | seb128: past month is calendar month not 30 days so the week view would include october stuff but the month view would not | 14:55 |
| === _salem is now known as salem_ | ||
| mdeslaur | barry: any idea why this is happening in vivid? the package names are obviously wrong: http://paste.ubuntu.com/8820356/ | 15:13 |
| 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:17 |
| mdeslaur | yeah, I'm diffing it to try and figure it out | 15:18 |
| barry | mdeslaur: to be clear, you don't see that in utopic? | 15:19 |
| 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:20 |
| 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:23 |
| 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 | 15:24 |
| === doko_ is now known as doko | ||
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| barry | mdeslaur: over in #debian-python: <p1otr> barry: which package adds gi.repository.GLib egg-info? | 15:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| pitti | hallyn: logind is told to close a session (ReleaseSession "c1" or so) | 15:45 |
| === salem_ is now known as _salem | ||
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| hallyn | pitti: why is it a grave bug? | 15:57 |
| pitti | hallyn: mostly for the lingering ACLs, I suppose | 15:57 |
| 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 | 15:58 |
| === _salem is now known as salem_ | ||
| hallyn | pitti: thanks much. | 15:58 |
| pitti | hallyn: so the scenario would be something like 1. login locally, get ACLs, log out | 15:59 |
| 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:00 |
| hallyn | right. i'm ok with claling that grave :) thx | 16:01 |
| 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 | 16:05 |
| === josepht_ is now known as josepht | ||
| 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:28 |
| 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:29 |
| bregma | flexiondotorg, I'm surprised it doesn't work out of the box like Gnome-fallback does | 16:30 |
| 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:31 |
| flexiondotorg | bregma, Is is possible to modify to Compiz configuration at a system level via a meta package? | 16:32 |
| pitti | bdmurray: sorry, not yet; overloaded with other stuff ATM :( | 16:34 |
| 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:36 |
| flexiondotorg | bregma, Just tested on a clean system. No window decorations by default in MATE. | 16:39 |
| bregma | flexiondotorg, does MATE use gnome-session? | 16:40 |
| flexiondotorg | bregma, No, it uses mate-session | 16:40 |
| 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:42 |
| mdeslaur | Riddell: thanks! | 16:43 |
| doko | cjwatson, plplot is merged | 16:46 |
| 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:54 |
| 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:55 |
| 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:56 |
| Trevinho | yes, sure... in general in != unity sessions, the default compiz settings should be used | 16:57 |
| Trevinho | like it happens in the flashback | 16:57 |
| flexiondotorg | Trevinho, Thanks. What should the variable be for the standard profile? "Default"? | 17:00 |
| Trevinho | flexiondotorg: you can just unset it | 17:01 |
| 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:02 |
| flexiondotorg | I'll test on real hardware later 😃 | 17:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| sarnold | pitti: thanks :) | 17:44 |
| mlankhorst | arges: I'd have to check, but the xxv-intel driver works at least | 18:12 |
| === fishor is now known as olerem | ||
| === roadmr is now known as roadmr_afk | ||
| cyphermox | xnox: hey | 21:05 |
| cyphermox | xnox: mind if I merge ppp? | 21:05 |
| 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:43 |
| Unit193 | cyphermox: Still looking into NM? | 21:46 |
| === roadmr_afk is now known as roadmr | ||
| === salem_ is now known as _salem | ||
| cyphermox | Unit193: I am, currently building it | 22:37 |
| Unit193 | Fantastic, thanks for letting me know! Some Xubuntu docs will need modified. | 22:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| cyphermox | if you want to help testing, I'll ping you later when I'm done with the merge | 22:41 |
| Unit193 | Sure, though it wouldn't be wireless, those are still on connman/utopic. | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!