/srv/irclogs.ubuntu.com/2015/01/16/#ubuntu-devel.txt

=== _salem is now known as salem_
=== salem_ is now known as _salem
=== lfaraone is now known as lfaraone_
=== 18VABY2YZ is now known as elmo
=== seelaman` is now known as seelaman
=== Guest97735 is now known as mfisch
=== beuno_ is now known as beuno
=== achernya_ is now known as achernya
=== Nigel_ is now known as G
shadeslayeranyone have a clue on how to pass a env var into a schroot?05:44
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 )05:45
=== marcusto_ is now known as marcustomlinson
=== fabo_ is now known as fabo
darkxstshadeslayer, just add custom key to schroot conf06:20
=== pitti` is now known as pitti
pittiGood morning06:34
pittislangasek: hey Steve, how are you?06:41
=== PaulW2U_ is now known as PaulW2U
dholbachgood morning07:56
=== buxy_bak is now known as buxy
pittidholbach: ooh, hey Daniel! Alles Gute zum Purzeltag! *hug*08:06
dholbachhi pitti08:06
dholbachvielen Dank! :)08:06
* dholbach hugs pitti back08:06
=== Wellark_ is now known as wellark
=== wellark is now known as Wellark
DrManhattanI 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 memory08:23
=== Spads_ is now known as Spads
=== lan3y is now known as Laney
=== ochosi_ is now known as ochosi
pittixnox: FYI, I updated the pad with instructions how to boot touch (in the emulator) with systemd and how to make adb work09:26
=== Riddelll is now known as Riddell
=== greyback__ is now known as greyback
LocutusOfBorg1hi folks!09:51
=== kickinz1` is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
pittihey LocutusOfBorg1, how are you?10:09
LocutusOfBorg1fine thanks :)10:19
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
=== sunweave1 is now known as sunweaver
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
=== _salem is now known as salem_
=== doko_ is now known as doko
=== MacSlow is now known as MacSlow|lunch
xnoxpitti: \o/ awesome12:53
=== ian__ is now known as ian-weisser
stevenmIt 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 releases13:22
ivokshttps://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions13:23
ivoksiirc, reason was 'mozilla will not allow it to be called firefox/thunderbird if it's a patched version'13:24
jrwren_so THAT is why debian ships iceweazel13:27
=== jrwren_ is now known as jrwren
mgedminhttps://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model13:30
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
didrockskirkland: hey, still interested in powernap? I can handle the systemd transition if you don't have time13:31
kirklandhey didrocks!  sorry, I had promised pitti I would do it by now, but I haven't gotten to it13:32
kirklandbeen a crazy week13:32
kirklanddidrocks: that would be great!13:32
didrockskirkland: no worry, doing then ;)13:32
kirklanddidrocks: :-)  thanks!13:32
didrocksyw ;)13:32
rbasakAre others seeing many more Hash Sum Mismatches in test builds recently?13:36
rbasakOn Vivid.13:36
=== oSoMoN_ is now known as oSoMoN
=== Pici is now known as Guest66126
=== Guest66126 is now known as Pici
hallynhm, corrupt ext4, cna't create files.13:53
pittihey xnox -- we got unity etc. to work now :)14:03
xnoxpitti: \o/14:04
pittirbasak: that happens fairly often to me too14:04
xnoxpitti: i should start pushing patches for testing.14:05
xnoxor run the emulator myself i guess.14:05
Laneyrbasak: on Translation_en I was seeing it often enough to disable translations inside the chroots14:05
rbasakLaney: yeah - mine seems to be on translations too.14:06
rbasakpitti, Laney: would you say the rate has gone up recently? I'm seeing far more than a few weeks ago.14:07
pittirbasak: not subjectively; I've pretty much always got them, and apt-cacher-ng seems to aggravate it14:07
LaneyI don't really remember a problem before a few weeks ago14:07
* Laney handwaves14:08
rbasakIf 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:08
rbasakThere 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:09
pittihallyn, stgraber: OOI, when do you plan the next LXC upload? (wrt. bug 1350947)14:19
ubottubug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [High,Fix committed] https://launchpad.net/bugs/135094714:19
pittijodh: 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 behind14:22
pittijodh: maybe that's because this is based on Contents.gz which only gets updated once a week or so?14:22
=== MacSlow|lunch is now known as MacSlow
shadeslayerHey, anyone know why kde-runtime doesn't migrate? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html14:30
=== rickspencer3_ is now known as rickspencer3
cjwatsonrbasak: 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 year14:33
cjwatson(apt-ftparchive source caching)14:33
=== zbenjamin_ is now known as zbenjamin
cjwatsonpitti: Contents is supposed to update daily, but there's a race that sometimes breaks it, https://bugs.launchpad.net/launchpad/+bug/138479714:34
ubottuLaunchpad bug 1384797 in Launchpad itself "Contents generation races with publisher" [Low,Triaged]14:34
Laneyshadeslayer: because of those test regressions14:35
pitticjwatson: ah, thanks14:36
shadeslayerLaney: were marked to be skipped14:36
shadeslayerLaney: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files ( see jriddell14:36
shadeslayerdarkxst: btw I'm not exactly clear on the documentation regarding those14:37
shadeslayerre: env vars in schroot14:37
rbasakcjwatson: 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
cjwatsonRiddell,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:43
cjwatsonRiddell: I suggest reverting that14:44
shadeslayercjwatson: Riddell's gone out, mind doing it? I don't think I have permission to do that14:44
cjwatsonrbasak: 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:47
cjwatsonshadeslayer,Riddell: done14:48
rbasakcjwatson: ah. I'll need to think about what I recommended before about cache times. Thanks.14:48
rbasakI 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:48
rbasakIf the publisher runs as soon as it can, then there isn't any window like that any more.14:49
cjwatsonThat's correct, there isn't.14:49
rbasakI don't see any easy way to work around it now then. Only to make the repository format actually race-free during updates.14:50
=== kickinz1 is now known as kickinz1|afk
smoserhey. 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
smoseralso  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:01
pittixnox: interested in joining the systemd meeting?15:02
xnoxpitti: yes, one sec.15:02
caribouis it possible to have a sponsor for Bug #1387594 on trusty & utopic ?15:02
ubottubug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/138759415:02
rbasakcaribou: looking15:06
smoseranyone know how to fix that luser error above ? tried disabling HUD, but that has no affect.15:07
Laneysmoser: in gnome-terminal, clear the keybindings for 'switch to tab'15:10
Laneyif you're seeing it outside of the terminal, don't know I'm afraid15:10
rbasakcaribou: is the patch committed upstream?15:16
rbasakand/or released?15:16
caribourbasak: it's been a while, let me check...15:16
caribourbasak: version 265-3 is in Vivid and has the fix15:17
rbasakcaribou: is that via packaging, or direct from upstream?15:18
Odd_Blokerbasak: I feel like we might be seeing more Hash Sum Mismatches when building vivid images.15:18
caribourbasak: I got it from debian.15:18
smoserLaney, thank you.15:19
caribourbasak: I found out talking to bryanquigley that upstream has abandonned development15:19
rbasakOdd_Bloke: based on Colin's explanation of how the publisher changed, I now understand and would expect that :-(15:19
roadmrstgraber: 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
rbasakcaribou: I see, OK.15:19
caribourbasak: bryanquigley has asked to demote libnss-ldap to Universe15:19
Odd_Blokerbasak: Yeah, just caught up with the rest of the backlog.15:20
Odd_BlokeThat's what retry loops are for, I guess. :p15:20
stgraberrbasak: can you pastebin your code?15:21
stgrabers/rbasak/roadmr/15:22
roadmrstgraber: sure, just a sec15:22
rbasakOdd_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
rbasakIt might be an idea to resurrect that.15:23
caribourbasak: someone just commented a few minutes ago that he had the problem & worked around by pulling the Vivid pkg15:26
roadmrstgraber: 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
rbasakcaribou: 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
rbasakcaribou: OTOH, it's broken on ppc64el at the moment? That means we need to fix it.15:27
rbasakHaving 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:28
rbasakBut Debian have committed it, so that's better than nothing.15:29
caribourbasak: yes, it's in jessie15:29
caribourbasak: and I pulled the patch w/o any change15:29
stgraberroadmr: container.attach_wait(lxc.attach_run_command, command)15:30
roadmrstgraber: ah doh :)15:30
stgraberroadmr: otherwise, you're passing the result of lxc.attach_run_command(command) to attach_wait() :)15:30
stgraberroadmr: that's a reasonably common mistake ;)15:31
rbasakcaribou: 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
caribourbasak: ok, thanks15:31
roadmrstgraber: thanks for your help (and politeness, it's my fault for not reading the examples carefully...)15:31
rbasakcaribou: 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:31
=== Guest8667 is now known as balloons
rbasakcaribou: I'd also note in the changelog that this fixes a segfault on ppc64el and on any rebuilds on other architectures.15:32
caribourbasak: true15:32
rbasakcaribou: I'll make those changes now and test and upload if you're happy?15:32
caribourbasak: more than happy !15:33
* rbasak gets to it15:33
caribourbasak: thank you for your help & valuable comments15:33
xnox?15:37
shadeslayercjwatson: thx :)15:41
ericsnowfor juju, the template for the upstart job is located at https://github.com/juju/juju/blob/master/service/upstart/upstart.go#L22815:42
ericsnowwe would do something similar for systemd15:42
didrockskirkland: 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
pittiericsnow: ah, thanks15:42
pittiericsnow: that doesn't look too bad indeed15:42
pittididrocks, xnox: ^ we could just put the whole script into /run/somewhere/ and ExecStart= it, and the rest is pretty straightforward15:43
didrockspitti: xnox: indeed, quite simple! I'm happy to do that15:44
xnoxericsnow: why juju-template-restart.conf instead of telling cloud-init to shutdown at the end?15:44
xnoxericsnow: in the clonetemplate.go15:44
xnoxericsnow: then in files.go it references /etc/init15:45
xnoxericsnow: not sure why static units are created, instead of using instance jobs.15:45
ericsnowxnox: where are those files you are talking about?15:45
ericsnowxnox: 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
xnoxe.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
xnoxericsnow: state/backups/files.go15:46
ericsnowxnox: so I can't say much to rationale15:46
ericsnowxnox: k15:46
xnoxpitti: ericsnow: $ git grep "etc/init" -> shows a lot of places where upstart assumptions are made15:47
ericsnowxnox: ah, so having a single unit for juju as a whole and then any other units are set as dependencies?15:48
ericsnowxnox: then that single unit would be always installed with juju?15:48
xnoxericsnow: not quite.15:48
xnoxericsnow: a template is always installed to run e.g. machine $i with juju --machine $i, in the template.15:49
ericsnowxnox, pitti: yeah, the upstart assumptions are why our job isn't as easy as it could have been :(15:49
xnoxsystemctl 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
xnoxanyway.15:49
xnoxpitti: slangasek: what's our upgrade story? dist-upgrade to vivid will install systemd-sysv?15:50
xnoxand break all juju deployed machines?15:50
ericsnowxnox: that could work, but only one jujud should be running on a host, so I'm not sure what a template buys us15:50
xnoxericsnow: you have juju-db jujud-machine-* no?15:51
ericsnowxnox: I'm pretty sure that's just a hold-over from an earlier version of juju that ran more than one jujud on a host15:51
xnoxack15:52
ericsnowxnox: however, if I've misunderstood on that point then using a template *would* make sense :)15:52
ericsnowxnox: so I'll keep that in mind15:52
=== roadmr is now known as roadmr_afk
xnoxericsnow: doesn't --deploy-to machine make an instance multi-machine15:53
ericsnowxnox: that just adds more juju agents running in the existing jujud15:54
=== Guest52246 is now known as charles
pittixnox: does one actually dist-upgrade workloads?16:09
pittiericsnow: ^16:10
pittior do you just re-deploy on a new instance?16:10
pittias charms often are release specific anyway16:10
pittiif 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 again16:11
ericsnowpitti: normal use of juju does not involve sysadmin tasks by users on the instances juju creates16:11
pittiericsnow: i. e. dist-upgrading an instance from say precise to trusty wouldn't be supported anyway16:13
ericsnowpitti: my understanding is that once the instance is set up (right after provisioning), we don't do any further upgrades16:13
pittiericsnow: that's my understanding as well; well, certainly -updates/-security, but not a new release16:13
pittixnox: anyway, even though we might not strictly need it, the generator is just a too crazy^Wnice idea to not have it :)16:14
ericsnowpitti: right16:14
ericsnowpitti: since everything in juju is driven by series16:14
ericsnowxnox: FYI, juju *does* have a separate juju running (and a separate init script) for each running juju agent16:25
ericsnowxnox: so using a template makes sense16:26
xnoxericsnow: yeah.16:26
ericsnowxnox: sorry for being confusing :/16:26
xnoxpitti: ^16:26
ericsnowpitti: regarding dist-upgrade, to quote sinzui (on #juju-dev): "Deploy a new service to get the new os, not upgrade an existing one"16:27
ericsnowpitti, xnox: are you talking about a juju-specific generator or a more generic upstart->systemd one?16:29
ericsnowpitti, xnox: presumably the latter16:29
pittixnox: anything I need to sponsor/review for you?16:30
pittiericsnow: no, a juju specific one16:30
xnoxericsnow: i'm talking about /etc/init/juju-*.conf -> /run/systemd/system/juju-*.service specific generator16:30
xnoxwith no future compatibility16:30
pittiericsnow: 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 apart16:30
ericsnowgot it16:30
ericsnowpitti: makes sense (too bad)16:31
xnoxericsnow: that way juju from this week can launch tomorrows vivid.16:31
ericsnowxnox: cool16:31
xnoxericsnow: or machines launched with vivid today continue to boot after upgrade to vivid +1 week.16:31
pittixnox: e. g. want me to do the update-notifier merge/upload?16:31
xnoxpitti: let me do it now.16:32
ericsnowxnox: yeah, should be pretty doable given our basic usage with upstart16:32
xnoxpitti: just got off the call.16:32
pitticyphermox: file moving resulting in broken permisions> ugh16:32
xnoxericsnow: imho that is safer. However I will include a safe-guard -> if juju itself generate .service files nothing will be done.16:32
pitticyphermox: that also explains why the manual workaround works16:32
cyphermoxpitti: hey ;)16:32
pitticyphermox: i. e. rm/cp16:32
cyphermoxyeah16:32
cyphermoxif you rm first, then move, it's fine16:33
pitticyphermox: oh, it's moving over an existing file which does that?16:33
cyphermoxif you move back your backup file onto the old position, the backup filename becomes the invalid char device ;)16:33
=== roadmr_afk is now known as roadmr
cyphermoxpitti: er, I'm not sure what you mean by that16:33
cyphermoxfrom what I can tell it's moving a file from the underlying read-only FS that triggers this16:34
cyphermoxie. mv /vmlinuz /vmlinuz.backup  -> pain16:34
cyphermoxmv /vmlinuz.backup /vmlinuz -> vmlinuz is fine, but now vmlinuz.backup is your invalid char device :)16:34
tarpmancyphermox: sounds like bug 141048016:35
pitticyphermox: 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
ubottubug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/141048016:35
pitticyphermox: ah, ok16:35
cyphermoxtarpman: thanks16:35
cyphermoxpitti: irrelevant to the existance of b16:35
xnoxpitti: system() vs fork()/exec() vs popen() -> any preference with invoking systemctl?16:36
pittixnox: oh, plain C, no glib or libpipeline or Qt or libnih or anything?16:36
pittixnox: systemctl what?16:37
pittixnox: if it's just enable, disable, calling symlink() or unlink() might be miles easier :)16:37
pittixnox: 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 critical16:38
=== ampelbein_ is now known as Ampelbein
=== Guest4292 is now known as kgunn
xnoxpitti: upstart-local-bridge calling "systemctl stop android-container@key=*.target"16:43
xnoxpitti: libnih only has helpers to watch children, not exec children.16:44
pittixnox: ah, for arbitrary values I think fork/execl is safer; shell injection and stuff16:44
pittiexeclp() even16:45
=== oSoMoN_ is now known as oSoMoN
ericsnowxnox, pitti: so with that juju-specific generator, keep in mind that juju currently makes explicit calls to initctl17:29
ericsnowxnox, pitti: does that matter?17:29
pittiericsnow: yes, they'll fail17:29
pittiericsnow: that should become calls to "service" to start/stop stuff17:29
pitti(which works with sysvinit, upstart, and systemd)17:29
ericsnowpitti: so would that unit generator still buy us much?17:31
pittiericsnow: no, I guess not then17:31
ericsnowpitti: :(17:31
pittiericsnow: yeah, was a nice idea :/ but trying to emulate initctl would go too far :)17:32
ericsnow:)17:32
xnoxericsnow: use "service" command that works on debian/ubuntu against upstart & systemd17:46
xnoxericsnow: systemctl works against systemd only17:46
xnoxericsnow: initctl works against upstart only17:46
ericsnowxnox: right, that's one of the things we have to fix for juju 1.23 :)17:47
xnoxhm waitid is failing for me with no reason.17:49
pittixnox: doing the update-notifier upload now17:49
xnoxpitti: oh cool.17:50
xnoxpitti: is there anything special I need to do to run the emulator with systemd?17:50
pittixnox: yes, several things; I put all in the pad17:51
xnoxpitti: ok...17:51
tseliotpitti: 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
tseliotwhich I can't fix unless somebody approves my packages in NEW first17:52
=== mbarnett` is now known as mbarnett
pittitseliot: the two nivida-graphics-drivers-*?17:53
tseliotpitti: yep17:54
pittiyou don't have a local build for them?17:54
tseliotpitti: I do, but I think 331 in the archive is broken too17:54
pittixnox: hm, update-notifer FTBFSes due to a test failure17:55
tseliotso users are probably left with a black screen now17:55
pittixnox: unrelated to your change17:55
pittixnox: oh, probably because I have an apt proxy18:01
rsalvetipitti: any specific testing you want to run with silo 1?18:04
pittirsalveti: not really; just that it still starts up, i. e. guard against compiler oddities etc.18:05
pittirsalveti: it's a no-change for upstart18:05
pittixnox: question in https://code.launchpad.net/~xnox/ubuntu/vivid/upstart/fix-rotate-logs/+merge/24605218:05
rsalvetiyeah, unless you want to test the systemd part, we can land it18:05
pittirsalveti: I tested a local build of that18:05
rsalvetialright, landing then18:05
pittirsalveti: cool, thanks!18:06
pittirsalveti: had to rebuild your's and could add my merge into your landing? or doing that separately?18:06
rsalvetipitti: landed mine first, then rebuilt yours18:06
rsalvetionce we land yours, I got another one but a rebuild should be fine18:07
pittiack, thanks18:07
pittirsalveti: I'm afraid I can't test it myself any more today18:07
xnoxpitti: i did a fake in fix-rotate-logs.18:16
xnoxpitti: "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:17
xnoxpitti: 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
xnoxpitti: 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
pittixnox: ah, perhaps I misunderstood the other branch then18:18
xnoxinstead of doing this fakery.18:18
pittiI thought the prefixes would go away entirely18:19
xnoxpitti: automatic ones are. for consistency i guess i should drop them everywhere.18:19
xnoxpitti: let me push something that is obvious.18:20
pittixnox: oh, you mean with just that branch but not the other it would work?18:22
pittixnox: so yeah, I guess I don't know enough how these are plumbed together18:22
xnoxpitti: user space uses verbantim ":sys:rotate-logs" events, and i've kept that legacy name.18:22
pittixnox: like, what consumes them, whether the consumer needs to be adjusted, and how that relates to the no-classes branch18:23
xnoxon the session bus.18:23
xnoxif i emit ":sys:rotate-logs" i don't need to change any consumers of it on the session init.18:23
pittixnox: ah ok, so that MP is correct (if we entirely ignore the other MP for a moment)18:23
xnoxnor e.g. to logout.18:23
=== superm1_ is now known as superm1
xnoxpitti: $ sudo initctl foo -> used to emit two events. "foo" (system-level) & ":sys:foo" (session level)18:24
xnoxsudo initctl emit foo, that is.18:24
xnoxi've changed to18:24
xnoxinitctl emit :sys:foo18:24
xnoxthus generating ":sys:foo" (session level)18:25
xnoxall events are equal18:25
xnoxpitti: 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:25
pittixnox: oh, and in debian/upstart-bin.upstart.cron.daily there's a small typo: that the# session Inits18:26
* xnox things18:26
pittixnox: ah, I guess that would have made the update-notifier one obsolete (but doesn't hurt)18:26
* pitti -> dinner18:26
xnoxpitti: faking ":sys:" prefix is better for 3rd party session jobs if there are any.18:27
xnoxi guess we will have systemd on the session by the next LTS.18:27
xnoxpitti: http://paste.ubuntu.com/9762971/18:29
xnoxpitti: i think this is more clear.18:29
xnoxpitti: http://paste.ubuntu.com/9762982/18:30
xnoxwith the grammar fix18:30
tseliotpitti: I *think* my changes to nvidia-prime worked18:32
tseliotpitti: http://paste.ubuntu.com/9763020/18:38
tseliotpitti: sorry, too much detail: http://paste.ubuntu.com/9763024/18:39
* tseliot ended up re-using the systemd unit from the wiki18:40
LocutusOfBorg1have a nice weekend people!18:41
=== zumbi_ is now known as zumbi
=== roadmr is now known as roadmr_afk
pittitseliot: http://paste.ubuntu.com/9763024/ LGTM, thanks! (you don't need the dirs.in bit, though -- dh_install creates dirs as needed)19:50
pittirsalveti: thanks for the landing19:52
rsalvetinp19:53
tseliotpitti: oh, ok, I'll get rid of that entry then. Thanks20:13
argesinfinity: does bug 1407702 look like an installer issue, I'm not sure the target is correct?20:21
ubottubug 1407702 in linux (Ubuntu) "Console message "could not open builtin file '/lib/modules/3.16.0-28-generic/modules.builtin.bin' " is got while installing Ubuntu15.04" [Undecided,New] https://launchpad.net/bugs/140770220:21
infinityarges: 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:23
argesinfinity: ok i'll re-target it.20:24
infinityarges: 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
infinityarges: But d-i is a good place to start for now, and Andy and I can argue about the details. :P20:24
argesinfinity: yea you'd think it would spit out the module it was trying to load. but it says couldn't find the builtin file20:24
argesinfinity: thank20:25
argess20:25
=== wendar_ is now known as wendar
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== bse_ is now known as behseh
=== iulian_ is now known as iulian

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!