[05:44] <shadeslayer> anyone have a clue on how to pass a env var into a schroot?
[05:45] <shadeslayer> ( I'd rather not pollute it with everything by passing -p , and I just want to specify one var for the setup.d scripts )
[06:20] <darkxst> shadeslayer, just add custom key to schroot conf
[06:34] <pitti> Good morning
[06:41] <pitti> slangasek: hey Steve, how are you?
[07:56] <dholbach> good morning
[08:06] <pitti> dholbach: ooh, hey Daniel! Alles Gute zum Purzeltag! *hug*
[08:06] <dholbach> hi pitti
[08:06] <dholbach> vielen Dank! :)
[08:06]  * dholbach hugs pitti back
[08:23] <DrManhattan> I have upgraded my samba to version 4.1.6 but Im still getting the talloc memory leak error. Is there any way I can keep samba password sync to user accounts and get rid of this memory error? no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
[09:26] <pitti> xnox: FYI, I updated the pad with instructions how to boot touch (in the emulator) with systemd and how to make adb work
[09:51] <LocutusOfBorg1> hi folks!
[10:09] <pitti> hey LocutusOfBorg1, how are you?
[10:19] <LocutusOfBorg1> fine thanks :)
[12:53] <xnox> pitti: \o/ awesome
[13:22] <stevenm> It seems since 11.04 packages like firefox and thunderbird get updates even in LTS released to their latest versions regardless of the fact it introduces new features that may have new bugs (i.e. the updates are not just for security/bug fix reasons like any others) - where can I read about this policy (about the rules for the exception itself) as well as what other packages fall under this rule?
[13:22] <stevenm> *LTS releases
[13:23] <ivoks> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[13:24] <ivoks> iirc, reason was 'mozilla will not allow it to be called firefox/thunderbird if it's a patched version'
[13:27] <jrwren_> so THAT is why debian ships iceweazel
[13:30] <mgedmin> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
[13:31] <mgedmin> "it's unfeasible to try to do our own stable release branch maintenance as this would require far more resources than we can get at any point in the future"
[13:31] <didrocks> kirkland: hey, still interested in powernap? I can handle the systemd transition if you don't have time
[13:32] <kirkland> hey didrocks!  sorry, I had promised pitti I would do it by now, but I haven't gotten to it
[13:32] <kirkland> been a crazy week
[13:32] <kirkland> didrocks: that would be great!
[13:32] <didrocks> kirkland: no worry, doing then ;)
[13:32] <kirkland> didrocks: :-)  thanks!
[13:32] <didrocks> yw ;)
[13:36] <rbasak> Are others seeing many more Hash Sum Mismatches in test builds recently?
[13:36] <rbasak> On Vivid.
[13:53] <hallyn> hm, corrupt ext4, cna't create files.
[14:03] <pitti> hey xnox -- we got unity etc. to work now :)
[14:04] <xnox> pitti: \o/
[14:04] <pitti> rbasak: that happens fairly often to me too
[14:05] <xnox> pitti: i should start pushing patches for testing.
[14:05] <xnox> or run the emulator myself i guess.
[14:05] <Laney> rbasak: on Translation_en I was seeing it often enough to disable translations inside the chroots
[14:06] <rbasak> Laney: yeah - mine seems to be on translations too.
[14:07] <rbasak> pitti, Laney: would you say the rate has gone up recently? I'm seeing far more than a few weeks ago.
[14:07] <pitti> rbasak: not subjectively; I've pretty much always got them, and apt-cacher-ng seems to aggravate it
[14:07] <Laney> I don't really remember a problem before a few weeks ago
[14:08]  * Laney handwaves
[14:08] <rbasak> If I hit it many times more then subjectively I think I'll claim that the rate has gone up, supported by Laney's handwaving, and file an RT I think.
[14:09] <rbasak> There was some careful tuning we did a while ago (a year or two maybe) to try and minimise it happening. Maybe a config was changed that broke this.
[14:19] <pitti> hallyn, stgraber: OOI, when do you plan the next LXC upload? (wrt. bug 1350947)
[14:22] <pitti> jodh: hm, now my http://people.canonical.com/~pitti/systemd/packages-to-convert/2015-01-16.txt suffers from the same problem as your's -- it's behind
[14:22] <pitti> jodh: maybe that's because this is based on Contents.gz which only gets updated once a week or so?
[14:30] <shadeslayer> Hey, anyone know why kde-runtime doesn't migrate? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[14:33] <cjwatson> rbasak: Depending on how fine your tuning was, I suppose it's possible it was exacerbated by the publisher getting in general a bit faster around the start of the year
[14:33] <cjwatson> (apt-ftparchive source caching)
[14:34] <cjwatson> pitti: Contents is supposed to update daily, but there's a race that sometimes breaks it, https://bugs.launchpad.net/launchpad/+bug/1384797
[14:35] <Laney> shadeslayer: because of those test regressions
[14:36] <pitti> cjwatson: ah, thanks
[14:36] <shadeslayer> Laney: were marked to be skipped
[14:36] <shadeslayer> Laney: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files ( see jriddell
[14:37] <shadeslayer> darkxst: btw I'm not exactly clear on the documentation regarding those
[14:37] <shadeslayer> re: env vars in schroot
[14:43] <rbasak> cjwatson: thanks, I'll keep that in mind. I don't recall the details - but they were to do with what cache expiry headers were issued, and with what timing, so that might have something to do with it. Is the publisher still half-hourly?
[14:43] <cjwatson> Riddell,shadeslayer: should be force-badtest ("ignore test failure for this package"), not force-skiptest ("ignore all failed tests triggered by this package"), so it was right before r875.
[14:44] <cjwatson> Riddell: I suggest reverting that
[14:44] <shadeslayer> cjwatson: Riddell's gone out, mind doing it? I don't think I have permission to do that
[14:47] <cjwatson> rbasak: The publisher hasn't been half-hourly for quite some time.  It attempts to run every five minutes, provided that another instance isn't already running; runtimes vary depending on how much work it has to do, but on average it manages about three to four runs per hour.
[14:48] <cjwatson> shadeslayer,Riddell: done
[14:48] <rbasak> cjwatson: ah. I'll need to think about what I recommended before about cache times. Thanks.
[14:48] <rbasak> I think what we did before was arrange for the cache to expire at a time when the publisher was unlikely to publish any updates, thus avoiding the race where the proxy cache sees a half updated state (that breaks apt) and caches it.
[14:49] <rbasak> If the publisher runs as soon as it can, then there isn't any window like that any more.
[14:49] <cjwatson> That's correct, there isn't.
[14:50] <rbasak> I don't see any easy way to work around it now then. Only to make the repository format actually race-free during updates.
[15:01] <smoser> hey. this is something new to me. i fresh installed vivid in december some time, and now something on my desktop is eating 'alt-2' and 'alt-[0-9]' keys. previously i'd use those to interact with qemu-system-x86_64 (both -curses and X). neither are getting key input now.
[15:01] <smoser> also  i notice that shell isn't getting them. in a gnome-terminal window (normally it'd show 'arg 1' or something if you hit that)
[15:02] <pitti> xnox: interested in joining the systemd meeting?
[15:02] <xnox> pitti: yes, one sec.
[15:02] <caribou> is it possible to have a sponsor for Bug #1387594 on trusty & utopic ?
[15:06] <rbasak> caribou: looking
[15:07] <smoser> anyone know how to fix that luser error above ? tried disabling HUD, but that has no affect.
[15:10] <Laney> smoser: in gnome-terminal, clear the keybindings for 'switch to tab'
[15:10] <Laney> if you're seeing it outside of the terminal, don't know I'm afraid
[15:16] <rbasak> caribou: is the patch committed upstream?
[15:16] <rbasak> and/or released?
[15:16] <caribou> rbasak: it's been a while, let me check...
[15:17] <caribou> rbasak: version 265-3 is in Vivid and has the fix
[15:18] <rbasak> caribou: is that via packaging, or direct from upstream?
[15:18] <Odd_Bloke> rbasak: I feel like we might be seeing more Hash Sum Mismatches when building vivid images.
[15:18] <caribou> rbasak: I got it from debian.
[15:19] <smoser> Laney, thank you.
[15:19] <caribou> rbasak: I found out talking to bryanquigley that upstream has abandonned development
[15:19] <rbasak> Odd_Bloke: based on Colin's explanation of how the publisher changed, I now understand and would expect that :-(
[15:19] <roadmr> stgraber: hello :) I'm using attach_wait and lxc.attach_run_command to run "ls -la /", it's somehow seeing the host's FS, not the containers :( what magic am I missing?
[15:19] <rbasak> caribou: I see, OK.
[15:19] <caribou> rbasak: bryanquigley has asked to demote libnss-ldap to Universe
[15:20] <Odd_Bloke> rbasak: Yeah, just caught up with the rest of the backlog.
[15:20] <Odd_Bloke> That's what retry loops are for, I guess. :p
[15:21] <stgraber> rbasak: can you pastebin your code?
[15:22] <stgraber> s/rbasak/roadmr/
[15:22] <roadmr> stgraber: sure, just a sec
[15:23] <rbasak> Odd_Bloke: https://wiki.ubuntu.com/AptByHash was a plan to fix this, if you're interested. I mostly got it working, but never quite finished it.
[15:23] <rbasak> It might be an idea to resurrect that.
[15:26] <caribou> rbasak: someone just commented a few minutes ago that he had the problem & worked around by pulling the Vivid pkg
[15:27] <roadmr> stgraber: here: http://paste.ubuntu.com/9762095/ the problem happens with the provision_container method, right now it's just the dummy ls -la /
[15:27] <rbasak> caribou: so what I don't like about this is that the patch seems a bit invasive in an area where if there's a regression, it'll be in multithreading code that'll be non-deterministic and thus difficult to test.
[15:27] <rbasak> caribou: OTOH, it's broken on ppc64el at the moment? That means we need to fix it.
[15:28] <rbasak> Having an active upstream that had committed the code would give me more confidence that the patch is good (since they're more familiar with the code and will have reviewed it)
[15:29] <rbasak> But Debian have committed it, so that's better than nothing.
[15:29] <caribou> rbasak: yes, it's in jessie
[15:29] <caribou> rbasak: and I pulled the patch w/o any change
[15:30] <stgraber> roadmr: container.attach_wait(lxc.attach_run_command, command)
[15:30] <roadmr> stgraber: ah doh :)
[15:30] <stgraber> roadmr: otherwise, you're passing the result of lxc.attach_run_command(command) to attach_wait() :)
[15:31] <stgraber> roadmr: that's a reasonably common mistake ;)
[15:31] <rbasak> caribou: I think we have no choice but to push it to Trusty (and Utopic), but we should let the SRU team decide at that stage. IMHO, my concern should be noted in "Regression Potential", so I'll do that now.
[15:31] <caribou> rbasak: ok, thanks
[15:31] <roadmr> stgraber: thanks for your help (and politeness, it's my fault for not reading the examples carefully...)
[15:31] <rbasak> caribou: a couple of minor review notes. 264-2.2ubuntu4.14.04.01 is identical to 264-2.2ubuntu4.14.04.1, so probably a little less confusing to others to use the latter.
[15:32] <rbasak> caribou: I'd also note in the changelog that this fixes a segfault on ppc64el and on any rebuilds on other architectures.
[15:32] <caribou> rbasak: true
[15:32] <rbasak> caribou: I'll make those changes now and test and upload if you're happy?
[15:33] <caribou> rbasak: more than happy !
[15:33]  * rbasak gets to it
[15:33] <caribou> rbasak: thank you for your help & valuable comments
[15:37] <xnox> ?
[15:41] <shadeslayer> cjwatson: thx :)
[15:42] <ericsnow> for juju, the template for the upstart job is located at https://github.com/juju/juju/blob/master/service/upstart/upstart.go#L228
[15:42] <ericsnow> we would do something similar for systemd
[15:42] <didrocks> kirkland: uploaded! once you get time, do you mind pulling lp:~didrocks/powernap/systemdification and pushing to lp:powernap? I don't have commit access it seems, I assume you do :)
[15:42] <pitti> ericsnow: ah, thanks
[15:42] <pitti> ericsnow: that doesn't look too bad indeed
[15:43] <pitti> didrocks, xnox: ^ we could just put the whole script into /run/somewhere/ and ExecStart= it, and the rest is pretty straightforward
[15:44] <didrocks> pitti: xnox: indeed, quite simple! I'm happy to do that
[15:44] <xnox> ericsnow: why juju-template-restart.conf instead of telling cloud-init to shutdown at the end?
[15:44] <xnox> ericsnow: in the clonetemplate.go
[15:45] <xnox> ericsnow: then in files.go it references /etc/init
[15:45] <xnox> ericsnow: not sure why static units are created, instead of using instance jobs.
[15:45] <ericsnow> xnox: where are those files you are talking about?
[15:46] <ericsnow> xnox: keep in mind that I haven't spent a lot of time with the upstart code and it predates my time in juju :)
[15:46] <xnox> e.g. you can have juju-machine@.service in debian and then do $ systemctl enable juju-machine@15.service -> thus making this machine boot / start juju-machine 15 service.
[15:46] <xnox> ericsnow: state/backups/files.go
[15:46] <ericsnow> xnox: so I can't say much to rationale
[15:46] <ericsnow> xnox: k
[15:47] <xnox> pitti: ericsnow: $ git grep "etc/init" -> shows a lot of places where upstart assumptions are made
[15:48] <ericsnow> xnox: ah, so having a single unit for juju as a whole and then any other units are set as dependencies?
[15:48] <ericsnow> xnox: then that single unit would be always installed with juju?
[15:48] <xnox> ericsnow: not quite.
[15:49] <xnox> ericsnow: a template is always installed to run e.g. machine $i with juju --machine $i, in the template.
[15:49] <ericsnow> xnox, pitti: yeah, the upstart assumptions are why our job isn't as easy as it could have been :(
[15:49] <xnox> systemctl enable juju-machine@10.service -> would then make an instance, substitue 10 instead of $i and have that start by default on boot.
[15:49] <xnox> anyway.
[15:50] <xnox> pitti: slangasek: what's our upgrade story? dist-upgrade to vivid will install systemd-sysv?
[15:50] <xnox> and break all juju deployed machines?
[15:50] <ericsnow> xnox: that could work, but only one jujud should be running on a host, so I'm not sure what a template buys us
[15:51] <xnox> ericsnow: you have juju-db jujud-machine-* no?
[15:51] <ericsnow> xnox: I'm pretty sure that's just a hold-over from an earlier version of juju that ran more than one jujud on a host
[15:52] <xnox> ack
[15:52] <ericsnow> xnox: however, if I've misunderstood on that point then using a template *would* make sense :)
[15:52] <ericsnow> xnox: so I'll keep that in mind
[15:53] <xnox> ericsnow: doesn't --deploy-to machine make an instance multi-machine
[15:54] <ericsnow> xnox: that just adds more juju agents running in the existing jujud
[16:09] <pitti> xnox: does one actually dist-upgrade workloads?
[16:10] <pitti> ericsnow: ^
[16:10] <pitti> or do you just re-deploy on a new instance?
[16:10] <pitti> as charms often are release specific anyway
[16:11] <pitti> if dist-upgrading running instances to newer releases is a supported thing (although it sounds scaringly brittle), I guess we do need to build that "create mathcing systemd unit" into the upgrade story, either via a generator or by calling juju again
[16:11] <ericsnow> pitti: normal use of juju does not involve sysadmin tasks by users on the instances juju creates
[16:13] <pitti> ericsnow: i. e. dist-upgrading an instance from say precise to trusty wouldn't be supported anyway
[16:13] <ericsnow> pitti: my understanding is that once the instance is set up (right after provisioning), we don't do any further upgrades
[16:13] <pitti> ericsnow: that's my understanding as well; well, certainly -updates/-security, but not a new release
[16:14] <pitti> xnox: anyway, even though we might not strictly need it, the generator is just a too crazy^Wnice idea to not have it :)
[16:14] <ericsnow> pitti: right
[16:14] <ericsnow> pitti: since everything in juju is driven by series
[16:25] <ericsnow> xnox: FYI, juju *does* have a separate juju running (and a separate init script) for each running juju agent
[16:26] <ericsnow> xnox: so using a template makes sense
[16:26] <xnox> ericsnow: yeah.
[16:26] <ericsnow> xnox: sorry for being confusing :/
[16:26] <xnox> pitti: ^
[16:27] <ericsnow> pitti: regarding dist-upgrade, to quote sinzui (on #juju-dev): "Deploy a new service to get the new os, not upgrade an existing one"
[16:29] <ericsnow> pitti, xnox: are you talking about a juju-specific generator or a more generic upstart->systemd one?
[16:29] <ericsnow> pitti, xnox: presumably the latter
[16:30] <pitti> xnox: anything I need to sponsor/review for you?
[16:30] <pitti> ericsnow: no, a juju specific one
[16:30] <xnox> ericsnow: i'm talking about /etc/init/juju-*.conf -> /run/systemd/system/juju-*.service specific generator
[16:30] <xnox> with no future compatibility
[16:30] <pitti> ericsnow: it can only apply to a concrete template; there's no generic way to translate an upstart job to a systemd unit, as the two are conceptually too far apart
[16:30] <ericsnow> got it
[16:31] <ericsnow> pitti: makes sense (too bad)
[16:31] <xnox> ericsnow: that way juju from this week can launch tomorrows vivid.
[16:31] <ericsnow> xnox: cool
[16:31] <xnox> ericsnow: or machines launched with vivid today continue to boot after upgrade to vivid +1 week.
[16:31] <pitti> xnox: e. g. want me to do the update-notifier merge/upload?
[16:32] <xnox> pitti: let me do it now.
[16:32] <ericsnow> xnox: yeah, should be pretty doable given our basic usage with upstart
[16:32] <xnox> pitti: just got off the call.
[16:32] <pitti> cyphermox: file moving resulting in broken permisions> ugh
[16:32] <xnox> ericsnow: imho that is safer. However I will include a safe-guard -> if juju itself generate .service files nothing will be done.
[16:32] <pitti> cyphermox: that also explains why the manual workaround works
[16:32] <cyphermox> pitti: hey ;)
[16:32] <pitti> cyphermox: i. e. rm/cp
[16:32] <cyphermox> yeah
[16:33] <cyphermox> if you rm first, then move, it's fine
[16:33] <pitti> cyphermox: oh, it's moving over an existing file which does that?
[16:33] <cyphermox> if you move back your backup file onto the old position, the backup filename becomes the invalid char device ;)
[16:33] <cyphermox> pitti: er, I'm not sure what you mean by that
[16:34] <cyphermox> from what I can tell it's moving a file from the underlying read-only FS that triggers this
[16:34] <cyphermox> ie. mv /vmlinuz /vmlinuz.backup  -> pain
[16:34] <cyphermox> mv /vmlinuz.backup /vmlinuz -> vmlinuz is fine, but now vmlinuz.backup is your invalid char device :)
[16:35] <tarpman> cyphermox: sounds like bug 1410480
[16:35] <pitti> cyphermox: I mean "mv a b" is fine if b doesn't exist, but if b does exist it causes that bug? or did I misunderstand this?
[16:35] <pitti> cyphermox: ah, ok
[16:35] <cyphermox> tarpman: thanks
[16:35] <cyphermox> pitti: irrelevant to the existance of b
[16:36] <xnox> pitti: system() vs fork()/exec() vs popen() -> any preference with invoking systemctl?
[16:36] <pitti> xnox: oh, plain C, no glib or libpipeline or Qt or libnih or anything?
[16:37] <pitti> xnox: systemctl what?
[16:37] <pitti> xnox: if it's just enable, disable, calling symlink() or unlink() might be miles easier :)
[16:38] <pitti> xnox: i. e. is this a generator you are working on? they shouldn't call a lot of externals if possible, as they run *very* early and are boot time critical
[16:43] <xnox> pitti: upstart-local-bridge calling "systemctl stop android-container@key=*.target"
[16:44] <xnox> pitti: libnih only has helpers to watch children, not exec children.
[16:44] <pitti> xnox: ah, for arbitrary values I think fork/execl is safer; shell injection and stuff
[16:45] <pitti> execlp() even
[17:29] <ericsnow> xnox, pitti: so with that juju-specific generator, keep in mind that juju currently makes explicit calls to initctl
[17:29] <ericsnow> xnox, pitti: does that matter?
[17:29] <pitti> ericsnow: yes, they'll fail
[17:29] <pitti> ericsnow: that should become calls to "service" to start/stop stuff
[17:29] <pitti> (which works with sysvinit, upstart, and systemd)
[17:31] <ericsnow> pitti: so would that unit generator still buy us much?
[17:31] <pitti> ericsnow: no, I guess not then
[17:31] <ericsnow> pitti: :(
[17:32] <pitti> ericsnow: yeah, was a nice idea :/ but trying to emulate initctl would go too far :)
[17:32] <ericsnow> :)
[17:46] <xnox> ericsnow: use "service" command that works on debian/ubuntu against upstart & systemd
[17:46] <xnox> ericsnow: systemctl works against systemd only
[17:46] <xnox> ericsnow: initctl works against upstart only
[17:47] <ericsnow> xnox: right, that's one of the things we have to fix for juju 1.23 :)
[17:49] <xnox> hm waitid is failing for me with no reason.
[17:49] <pitti> xnox: doing the update-notifier upload now
[17:50] <xnox> pitti: oh cool.
[17:50] <xnox> pitti: is there anything special I need to do to run the emulator with systemd?
[17:51] <pitti> xnox: yes, several things; I put all in the pad
[17:51] <xnox> pitti: ok...
[17:52] <tseliot> pitti: apparently my system with nvidia dies (as in nasty backtraces in dmesg) in vivid now. I'll have to investigate this before I can test my changes for systemd. It's probably this: https://devtalk.nvidia.com/default/topic/796559/linux/kernel-3-18-warning-no-drm_driver-set_busid-implementation-provided-by-nvidia_frontend_exit_modu/
[17:52] <tseliot> which I can't fix unless somebody approves my packages in NEW first
[17:53] <pitti> tseliot: the two nivida-graphics-drivers-*?
[17:54] <tseliot> pitti: yep
[17:54] <pitti> you don't have a local build for them?
[17:54] <tseliot> pitti: I do, but I think 331 in the archive is broken too
[17:55] <pitti> xnox: hm, update-notifer FTBFSes due to a test failure
[17:55] <tseliot> so users are probably left with a black screen now
[17:55] <pitti> xnox: unrelated to your change
[18:01] <pitti> xnox: oh, probably because I have an apt proxy
[18:04] <rsalveti> pitti: any specific testing you want to run with silo 1?
[18:05] <pitti> rsalveti: not really; just that it still starts up, i. e. guard against compiler oddities etc.
[18:05] <pitti> rsalveti: it's a no-change for upstart
[18:05] <pitti> xnox: question in https://code.launchpad.net/~xnox/ubuntu/vivid/upstart/fix-rotate-logs/+merge/246052
[18:05] <rsalveti> yeah, unless you want to test the systemd part, we can land it
[18:05] <pitti> rsalveti: I tested a local build of that
[18:05] <rsalveti> alright, landing then
[18:06] <pitti> rsalveti: cool, thanks!
[18:06] <pitti> rsalveti: had to rebuild your's and could add my merge into your landing? or doing that separately?
[18:06] <rsalveti> pitti: landed mine first, then rebuilt yours
[18:07] <rsalveti> once we land yours, I got another one but a rebuild should be fine
[18:07] <pitti> ack, thanks
[18:07] <pitti> rsalveti: I'm afraid I can't test it myself any more today
[18:16] <xnox> pitti: i did a fake in fix-rotate-logs.
[18:17] <xnox> pitti: "normally" - system "rotate-logs" is emitted, event-bridge listens to events, receives it does sprintf(":sys:%s", event_name) and emits again to session init.
[18:18] <xnox> pitti: here i change event name, verbantim, to ":sys:rotate-logs" and emit direct to every session init. Bypassing system init emit, session-event-bridge, reemit.
[18:18] <xnox> pitti: i guess it would be more clear to change "start on :sys:rotate-logs" to "start on rotate-logs" in the session job as well.
[18:18] <pitti> xnox: ah, perhaps I misunderstood the other branch then
[18:18] <xnox> instead of doing this fakery.
[18:19] <pitti> I thought the prefixes would go away entirely
[18:19] <xnox> pitti: automatic ones are. for consistency i guess i should drop them everywhere.
[18:20] <xnox> pitti: let me push something that is obvious.
[18:22] <pitti> xnox: oh, you mean with just that branch but not the other it would work?
[18:22] <pitti> xnox: so yeah, I guess I don't know enough how these are plumbed together
[18:22] <xnox> pitti: user space uses verbantim ":sys:rotate-logs" events, and i've kept that legacy name.
[18:23] <pitti> xnox: like, what consumes them, whether the consumer needs to be adjusted, and how that relates to the no-classes branch
[18:23] <xnox> on the session bus.
[18:23] <xnox> if i emit ":sys:rotate-logs" i don't need to change any consumers of it on the session init.
[18:23] <pitti> xnox: ah ok, so that MP is correct (if we entirely ignore the other MP for a moment)
[18:23] <xnox> nor e.g. to logout.
[18:24] <xnox> pitti: $ sudo initctl foo -> used to emit two events. "foo" (system-level) & ":sys:foo" (session level)
[18:24] <xnox> sudo initctl emit foo, that is.
[18:24] <xnox> i've changed to
[18:24] <xnox> initctl emit :sys:foo
[18:25] <xnox> thus generating ":sys:foo" (session level)
[18:25] <xnox> all events are equal
[18:25] <xnox> pitti: e.g. i guess i can change udev-bridge on the session level to prefix all events with ":sys:" as well thus having no API change on the session level for any existing session  level jobs.
[18:26] <pitti> xnox: oh, and in debian/upstart-bin.upstart.cron.daily there's a small typo: that the# session Inits
[18:26]  * xnox things
[18:26] <pitti> xnox: ah, I guess that would have made the update-notifier one obsolete (but doesn't hurt)
[18:26]  * pitti -> dinner
[18:27] <xnox> pitti: faking ":sys:" prefix is better for 3rd party session jobs if there are any.
[18:27] <xnox> i guess we will have systemd on the session by the next LTS.
[18:29] <xnox> pitti: http://paste.ubuntu.com/9762971/
[18:29] <xnox> pitti: i think this is more clear.
[18:30] <xnox> pitti: http://paste.ubuntu.com/9762982/
[18:30] <xnox> with the grammar fix
[18:32] <tseliot> pitti: I *think* my changes to nvidia-prime worked
[18:38] <tseliot> pitti: http://paste.ubuntu.com/9763020/
[18:39] <tseliot> pitti: sorry, too much detail: http://paste.ubuntu.com/9763024/
[18:40]  * tseliot ended up re-using the systemd unit from the wiki
[18:41] <LocutusOfBorg1> have a nice weekend people!
[19:50] <pitti> tseliot: http://paste.ubuntu.com/9763024/ LGTM, thanks! (you don't need the dirs.in bit, though -- dh_install creates dirs as needed)
[19:52] <pitti> rsalveti: thanks for the landing
[19:53] <rsalveti> np
[20:13] <tseliot> pitti: oh, ok, I'll get rid of that entry then. Thanks
[20:21] <arges> infinity: does bug 1407702 look like an installer issue, I'm not sure the target is correct?
[20:23] <infinity> arges: d-i might be an appropriate place to land the bug for now, assuming it's a question of "why are we spewing that to the console at all" (and, honestly, I'm not sure how they're managing that, it should be in syslog).
[20:24] <arges> infinity: ok i'll re-target it.
[20:24] <infinity> arges: The actual misbehaviour is going to be a combination of kmod and linux, in that either kmod's being too picky or linux isn't shipping a file, or both.
[20:24] <infinity> arges: But d-i is a good place to start for now, and Andy and I can argue about the details. :P
[20:24] <arges> infinity: yea you'd think it would spit out the module it was trying to load. but it says couldn't find the builtin file
[20:25] <arges> infinity: thank
[20:25] <arges> s