=== _salem is now known as salem_ === salem_ is now known as _salem [02:09] dobey: i thought unity-greeter only handles the login screen, and not the screensaver? [02:09] s/screensaver/lock screen/ [02:10] light-locker makes it so the greeter is the lock screen as well. [02:11] unity-greeter is not the lockscreen [02:11] unity now has its own unity-greeter-esque lockscreen [02:11] https://bugs.launchpad.net/bugs/1292451 <-- well, dobey reassigned this bug to unity-greeter [02:11] Launchpad bug 1292451 in unity-greeter (Ubuntu) "screensaver re-locks itself after unlocking if the configured screen-off timer goes off while screen is locked" [High,Confirmed] [02:12] but the bug is clearly to do with the lockscreen, not the login screen. [02:13] Unit193: what's this light-locker? [02:13] it doesn't show up in dpkg -S for me [02:13] light-locker uses lightdm as the lockscreen [02:13] apart from a light-locker-settings.desktop [02:14] bluesabre: it doesn't seem to be installed on my machine. [02:14] is it a library of some sort? [02:14] so, using light-locker with xubuntu makes lightdm-gtk-greeter the lock screen [02:14] i see. [02:14] I'm not sure what the unity lock screen is called [02:14] it might just be a component of unity [02:14] how odd, why doesn't unity use light-locker then? [02:15] seems like a better way to ensure consistency [02:15] that's up to them :) [02:15] (im a xubuntu dev) [02:15] * hyperair sighs [02:15] okay [02:15] I thought it was, or was planned to be, but seems it's only seeded on Xubuntu and Lubuntu. [02:16] yeah [02:16] i see. [02:51] infinity: /win 25 [02:51] feh [02:52] infinity: so i'm intending to push the pkg in ppa:ubuntu-virt/candidate plus http://people.canonical.com/~serge/qemu-aarch64-into-arm.debdiff [02:52] slangasek: ^ [02:52] dannf was kind enough to do a test build, and the resulting pkgs look sane [02:53] am i thinking clearly in that what we don't want is for qemu-user-static to include /usr/share/binfmts/qemu-$arch only for the native arch? [02:53] hallyn: what do you mean "only"? [02:54] slangasek: so armhf should have all but qemu-user-armhf, and arm64 should have all but qemu-user-aarch64; but having /usr/bin/qemu-user-armhf on armhf is ok [02:54] hallyn: I guess you mean /usr/bin/qemu-user-aarch64 on armhf? [02:54] slangasek: He means that only the native arch should be excluded. [02:54] Erm, I hope that's what he means. :P [02:54] and i mean that it's ok in /usr/bin so long as it's not in /usr/share/binfmts/ [02:55] infinity: yes, but that's not the correct rule; i386 is not "the native arch" on amd64, but we exclude it [02:55] hallyn: So, it's shipped in /usr/bin on x86, so yes. [02:55] hallyn: As to the bin question. [02:56] hallyn: For the binfmts question, excluding things that could run natively on that arch makes sense. [02:56] so http://paste.ubuntu.com/7201561/ is the contents of the armhf qemu-user-static pkg, [02:56] hallyn: note that currently, qemu-user-static excludes both i386 and x86_64 on both i386 and amd64 archs [02:56] http://paste.ubuntu.com/7201562/ for the arm64 pkg [02:56] i dunno, i'm befuddled. i t hink i'll push to ppa only tonight :) [02:57] hallyn: enough with the ppas [02:57] :) [02:57] slangasek: but qemu-user-static on my x86 has /usr/bin/qemu-x86_64-static [02:57] hallyn: yes, but it does not install the binfmt for either of i386 or amd64 [02:57] hallyn: Yes, it has the binaries, but not the binfmt. [02:57] slangasek: last time i fiddled with qemu-user-static i briefly bricked infinity's box [02:57] slangasek: right that was my q [02:57] and that's intentional, because you can run an i386 userspace on an x86_64 kernel [02:57] just making sure that i was thinking right about that :) [02:58] slangasek: So, the binfmts should be skipped for anything that could reasonably be expecte to run natively on the same machine. [02:58] hallyn: so the same should apply to arm+aarch64, since you can run an armhf userspace on an aarch64 kernel [02:58] Err, hallyn ^ [02:58] infinity: cool [02:58] provide the emulator in /usr/bin, but don't enable it via binfmt-misc [02:58] hallyn: powerpc/ppc64/ppc64el, sparc/sparc64, i386/amd64, armhf/arm64, etc. [02:58] slangasek: depends on the soc! [02:58] * mwhudson shuts up again [02:58] mwhudson: I know ;) [02:59] we've already had /that/ discussion on #debian-qemu [02:59] hah [02:59] mwhudson: Yes, not all SoCs can run both, and not all x86 CPUs can run amd64 binaries, but we're approximating for minimal damage, not maximum support. [02:59] bleh [02:59] This is an area where erring on the side of caution is sane. [02:59] but why is there no qemu-user-aarch64 [03:00] hallyn: By which you mean qemu-aarch64-static? [03:00] hallyn: Or the non-static build that no one cares about? :P [03:00] -rwxr-xr-x root/root 2904560 2014-03-21 09:59 ./usr/bin/qemu-aarch64-static [03:01] yeah i didn't do that part right [03:01] what? what's with all these last-minute changes :) [03:03] slangasek: I'm trying to get the qemu-system-aarch64 pkg into qemu-system-arm, was all, [03:03] hallyn: FWIW, those ppc/ppc64 lines should be consolidated the same way you're doing for arm. [03:03] (powerpc) echo ppc ;;\ [03:03] (ppc64) echo ppc ppc64 ppc64abi32 ;;\ [03:03] ^-- Wrong. [03:03] Again, for the same reason that i386 and amd64 were consolidated. [03:04] hallyn: Anyhow, don't let nitpicking stop you from uploading either. If you're sure you're not breaking x86 with your upload, we can iterate bugfixes for other arches as we go along. [03:04] so (ppc64 | powerpc) echo ppc ppc64 ppc6abi32;;\ [03:05] hallyn: And add ppc64el to the () list, yes. :) [03:05] oh that's not in there at all right now [03:06] The mips line is probably eually wrong, but I don't know enough about mips to care today, and it doesn't affect us. [03:06] wiat so you mean (ppc64 | powerpc | ppc64el) echo ppc ppc64 ppc64abi32;; [03:06] infinity: aurel32 will be sad [03:06] hallyn: yes [03:07] (though, boggle at the strange shell convention) [03:07] hallyn: Aye. It's entirely possible the syscall emulation doesn't work across endian-flips anyway, but again, better safe than sorry here. [03:07] alrighty [03:08] dannf: by any chance od you have a victim on which you could install the aarch64 qemu-user-static pkg we built? that you don't mind if you have to recover? :) [03:08] oh, well, noone's gonna be installing that right now anyway are they, so i guess there's no big hurry on that [03:11] oh one more newbie q, [03:11] shoudl i keep all the changelog entries from the ppa? [03:12] hallyn: Yes, though you can ditch all the versions and signatures and collapse it into one big entry for the archive upload if you prefer. [03:12] hallyn: But the log of what was done should be preserved. [03:13] oh hey! upstream tagged rc1 in the meantime, guess i should use that [03:13] infinity: ok, thanks, i will consolidate them and push to trusty tonight. [03:53] hallyn: still around? [03:59] stgraber: yeah, [03:59] hallyn: hey, so we have a bit of a critical problem with your systemd fix :) [03:59] i'd fogotten what a pain it is getting rid of all the roms in the qemu release tarballs [04:00] hallyn: http://paste.ubuntu.com/7201679/ [04:00] hallyn: my best guess is that we shouldn't be doing that nih_error_get in the failing nih_dbus_setup case as that seems to be the source of the assert, I'm just not 100% sure that this is right [04:02] hm [04:03] d'oh yeah [04:03] hallyn: this is causing systemd-logind to crash and die on quite a number of machines (potentially all machines that don't have cgmanager...) [04:03] bc it was a dbus nto nih call [04:03] is there a dbus equivalent we need to do, or can we just ignore that and return? [04:04] we already do that [04:04] doing the dbus_error_init [04:04] and _free [04:04] am i doing the same mistake in lxc? [04:04] i'm not! d'oh. [04:05] well, that's good :) [04:05] stgraber: do you want to test first, or push, or do you want me to push? [04:05] hallyn: ok, so http://paste.ubuntu.com/7201696/ should do it right? [04:05] I'll do a test build and send it to jdstrand for testing [04:05] yeah that should do it [04:30] hallyn: fix worked for jdstrand, uploaded to the archive now. [04:30] stgraber: phew - thanks [04:32] hallyn: np, glad I was still around at the time. It was literally in my last run through IRC windows before going to bed. [04:32] wouldn't have been fun waking up to everyone not having logind running anymore [04:35] yeah, for similar reason si probably should stay up awhile and look for qemu disasters :) === thegatta_ is now known as thegattaca [04:39] hallyn: I thought you said you didn't have a libvirt-bin upload? [04:41] hallyn: we are trying to land libvirt with apparmor signal and ptrace mediation [04:41] hallyn: bug #1298611 [04:41] bug 1298611 in lxc (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Fix committed] https://launchpad.net/bugs/1298611 [04:42] jdstrand: I've rejected hallyn's upload for now, it's not a critical fix (small feature change) so it can go after yours is through [04:43] ok, thank you :) [04:43] jdstrand: 'doh, sorry [04:44] stgraber: well, libvirt will have failures with new vms, but.. [04:44] jdstrand: when is the libvirt fix being pushed? [04:44] so, everything is tested up, just waited on an ack [04:44] waiting* [04:44] jdstrand: a ack from whom? [04:45] stgraber: the release team-- specifically infinity since he has been in the loop on all of it [04:45] jdstrand: ok [04:45] the ffe for apparmor userspace has not been granted yet [04:47] ok, so the situation is, we can't let qemu in without libvirt and we can't let libvirt in because your stuff is in a PPA somewhere [04:48] and we want hallyn's qemu in ASAP because it's a pretty major update and we want as much time as possible to catch problems [04:49] stgraber: i could pop the trusty machien type patch for now in qemu if you've rejected the prvious upload [04:49] we want the same for apparmor :) [04:49] I think we are talking about hours [04:49] jdstrand: i was thinking along different time scales regarding 'if i had anything' [04:49] oh [04:49] except hallyn's FFes have already been granted :) [04:50] I tried to coordinate this ealier [04:50] but yeah, if we can get everything landed tomorrow, then fine but if apparmor is still stuck tomorrow, we should let qemu + libvirt in and you'll have to rebase your libvirt change on top of that next week [04:50] that works for me [04:51] (both libvirt debdiffs are pretty trivial, no biggie rebasing either one or even merging them, ) [04:51] jdstrand: i thought we were coordinated - i saw tyhicks' debdiff posted and thought it was done [04:52] hallyn: right-- you can't push mine before apparmor though, otherwise it will break [04:52] jdstrand: gotcha [04:52] hallyn: ok, so I'll reject your qemu for now just so nobody accepts it by mistake and breaks libvirt. You can still get slangasek or infinity to review it from the rejected queue so that when the apparmor stuff lands we can just accept it from there. [04:52] stgraber: so qemu won't be promoted right? [04:52] uh. ok [04:52] hallyn: he posted it for review, but it is only Fix Committed in the bug [04:53] (it is in a ppa) [04:56] jdstrand: yeah it's a monster bug you've got there :) [04:57] well, it could be worse. the policy changes were minimal due to how we handled the base abstraction [05:00] jdstrand: stgraber: i've got a bad feeling that my precise-plus-ppas-on-trusty-kernel setup is gonna have some broken containers briefly as a result :) [05:00] hallyn: why? [05:01] it will work fine with a new kernel and old userspace [05:01] I don't backport apparmor to any of my precise PPAs so you should be fine [05:01] that is specifically tested and supported for backport kernls [05:02] so containers not specifying 'signal,' or wahtever will be fine? [05:02] if the apparmor userspace doesn't support it, yes [05:02] yep, so long as you don't have the new parser on the host [05:02] and if you are on precise, then it won't [05:02] very good, i'm reassured :) [05:03] I personally tested trusty kernel with ipc on precise with lxc [05:03] (ie, precise system with no changes other than the new kernel) [05:59] mvo: guten Morgen. [06:30] pitti, good morning. FYI I restarted wolfe-0{3,4,6} , dpkg segfaulted and all the tests failed. [06:38] hmm, is somebody else experiencing no sound due to lack of acl permissions on /dev/snd/ ? [06:40] diwic: Welcome to the n-1st systemd upload! [06:41] diwic: Updating and restarting should probably fix it for you. [06:41] RAOF, thanks. That's what I just did and got this - probably need to switch to main archive instead of mirror then [06:41] cjwatson, any ideas what we can do about Bug 1301045? [06:41] bug 1301045 in gnome-bluetooth (Ubuntu) "gnome-bluetooth and empathy pull in unity-control-center on Ubuntu GNOME packageset installation" [Undecided,New] https://launchpad.net/bugs/1301045 [06:43] and of course the GUI does not let me switch mirror :-( [06:44] diwic: it may not yet be in the archive, stgr aber just fixed it roughly two hours ago [06:45] ok, thanks [06:51] good morning [07:02] hey Unit193 - its waiting in approval queue :) [07:02] dholbach: good morning [07:03] Unit193: thanks again for your patience [07:03] mvo: Sweet! Thanks a ton for fixing before trusty. :D [07:06] hey mvo [07:10] Unit193: your welcome [07:20] hum..... [07:20] I have upstart-dbus-bridge.2186.pid and upstart-file-bridge.2186.pid in my home directory [07:20] did anyone else dist-upgrade and reboot today who can confirm this? [07:20] dholbach: moment, I saw that in a bugreport earlier.. [07:21] sarnold, you are unstoppable [07:22] dholbach: hehe, I hope not, it's past my bed time :) [07:22] and ~/Testing as well [07:23] dholbach: ugh, sorry, bad news on this one, the report today is kind of all over the place, and the bots dup'd it to an ancient bug that doesn't feel appropriate: https://bugs.launchpad.net/ubuntu/+source/lxpanel/+bug/1302254 [07:24] Launchpad bug 1106945 in lxpanel (Ubuntu) "duplicate for #1302254 lxpanel crashed with SIGSEGV in menu_cache_create()" [Medium,Confirmed] [07:25] jodh, ^ do you have any idea why this might be? [07:25] dholbach: they disappeared (again) after the systemd breakage was fixed [07:26] new packages in the archive ~10 minutes ago [07:26] ah! [07:28] ah, brilliant [07:28] thanks torkel [07:28] let me try that [07:28] maybe I'll get sound back again as a bonus ;-) [07:28] dholbach: yes - XDG_RUNTIME_DIR is unset. [07:28] dholbach: logind breakage? [07:29] I don't know what it is - I'll try an upgrade an brb [07:31] jodh: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1302264 [07:31] Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released] [07:34] jibel: ah, thanks; so again the "try again" clickery exercise? [07:34] good morning [07:35] sarnold, jodh: thanks that solved the issue for me! [07:38] pitti, yes, I clicked $world-ppc64el [07:38] dholbach, and brought the sound back too [07:38] diwic, it did :) [08:31] guys any idea why on login i would have deja-dup-monitor using 6GB of my memory? [08:34] tsdgeos, bug? [08:35] seb128: as a devel myself i would hate to get a bug saying "i booted up and deja-dup was using 6gb" [08:35] i mean it's non-reproduceable (probably) and doesn't give much info [08:35] I'd hate it more if it wasn't reported. :P [08:35] tsdgeos, use ubuntu-bug deja-dup, that might provide some info [08:36] tsdgeos, you are not the only one, somebody mentioned issues earlier on #ubuntu-desktop [08:36] tsdgeos, mterry is the maintainer, but he's probably still sleeping [08:37] ok === psivaa_ is now known as psivaa [09:27] guys, any idea of what's wrong here? [09:27] http://paste.ubuntu.com/7202446/ [09:28] 2.8.95~2430-0ubuntu5 is not >= 2.8.0-0ubuntu26 ? [09:34] tsdgeos, sudo apt-get install apparmor-easyprof-ubuntu apparmor [09:34] tsdgeos, what does that say/do? [09:35] http://paste.ubuntu.com/7202470/ [09:37] tsdgeos: try and apt-get update first, apparmor-easyprof 1.1.14 is the current version in the archive [09:37] your apt-get install is trying to install 1.1.13 [09:38] jjohansen: i'm updated, maybe my mirror is behind [09:38] tsdgeos: okay that is possible, the new easyprof landed 18 min ago [09:39] or at least that is what lp says [09:42] tsdgeos, right, the issue should resolve itself once the new apparmor-easyprof-ubuntu is available, or you can get it from https://launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu === doko_ is now known as doko [10:17] darkxst: hmm, I would have expected this to be handled by the fact that we install the task, so gnome-control-center and mcp-account-manager-goa ought to be marked for install before apt gets round to trying to resolve broken dependencies, which ought to mean that it doesn't need to try the first alternative because the second is already there [10:17] darkxst: that's how it's meant to work, anyway. if that's not working, somebody probably needs to fiddle with pkgsel.postinst on the fly in the installer to run apt-get with -o Debug::pkgProblemResolver=true so that we can see why it's taking that decision === vibhav is now known as Guest49486 [10:22] cjwatson: Except that his log clearly shows it installing the metapackage, not the task. [10:22] Commandline: apt-get install ubuntu-gnome-desktop [10:23] cjwatson: Which would explain why it works for his livefs (task-based) but not d-i. [10:31] infinity,darkxst: oh, so this just comes down to Jackson's tasksel merge, then [10:32] (probably) [10:32] let me sort that out [10:32] caribou: Err, tasksel? [10:32] cjwatson: ^ [10:33] * infinity assumes you mean something that's changed more recently than raring. [10:33] yeah, so that tasksel is able to install ubuntu-gnome tasks [10:33] infinity: ? [10:33] caribou: misfire. [10:33] infinity: thought so [10:33] I really do mean tasksel, it never got properly mangled for ubuntu-gnome [10:34] so something is probably falling back to metapackages as a result [10:34] cjwatson: Fair enough. So, I guess this has always been broken like this, but it's just now biting them? Makes some sense. [10:34] With all the new control-centre splitting madness. [10:34] I think so. I'm not too sure *how* it's falling back to metapackages [10:36] I guess just some random /xubuntu/ubuntu-gnome/ cargo-cult would DTRT? [10:37] Not entirely sure how tasksel would work at all for ubuntu-gnome in its current state. [10:37] Not without a pkgsel preseed. [10:38] And yet. [10:40] oh, it's not a real d-i log, it's somebody selecting it a bit more manually, I think [10:41] Like, perhaps, pkgsel. [10:41] The lack of d-i syslog makes it a mystery. [10:42] Maybe in pkgsel's aptitude mode. [10:42] Shrug. [10:48] cjwatson: You know what would be nice? If metapckages could be tasks. ie: instead of ubuntu-gnome-desktop depending on 300 packages, if it just depended on task:ubuntu-gnome-desktop [10:49] cjwatson: Though, I suppose that might screw up your point release hacks. :P [10:49] Yeah, it's all a mess ... === MacSlow is now known as MacSlow|lunch [11:40] pete-woods, hey, why did you mark bug #1296715 invalid for the hud? [11:40] bug 1296715 in indicator-appmenu (Ubuntu) "Menu items are greyed out in Libreoffice menu." [High,Confirmed] https://launchpad.net/bugs/1296715 [11:41] seb128: I thought it'd been logged against the wrong package? [11:41] pete-woods, I don't know what's the right package, the user says it happens to both the unity menus and the hud [11:42] pete-woods, but I guess fixing the problem for the appmenu might fix the hud as well? [11:42] tedg, hey, do you think you could have a look to ^ [11:42] seb128: sure, it'd fix the HUD problem too [11:42] k [11:42] pete-woods, thanks [11:43] do you know who is maintaining indicator-appmenu? [11:43] is that ted? [11:43] seb128: it's certainly not me, but sure, ted would be the right person to ask [11:43] k [11:49] Chipaca: sergiusens: jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1302516 [11:49] Launchpad bug 1302516 in upstart (Ubuntu) "upstart-dbus-session-bridge conflicts in stopping certain jobs" [Undecided,New] [11:49] Chipaca: sergiusens: jodh: see the comments on the bug, if one does $ stop upstart-dbus-session-bridge, one can stop any job e.g. usensord and it does stop. [11:51] i'm not sure if something is connected/listening on upstart and starts up the jobs, or if the dbus-bridge is rogue. [11:53] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [11:54] xnox: I don't see the relationship to be honest; but I don't know the innards of the dbus-bridge either [11:55] sergiusens: there might be a negative feedback loop.... upstart events are emitted on the dbus, then dbus bridge feeds them back into upstart..... and maybe just maybe that causes havoc =) [11:56] sergiusens: or there is somebody noticing that usensord goes away and sends "start usensord" to upstart. [11:56] sergiusens: is it a dbus activated service at all? and does something tries to manage it on top of upstart? e.g. unity/life-cycle stuff?! [11:57] xnox: no dbus activation; the only user of usensord is platform api but that integration has been stuck in a silo forever [11:58] that said, I could make it dbus activated instead of started through upstart (for usensord), not sure about the others that have symptons and this would just be a workaround [11:58] usensord runs at a low enough level that unity wont relate to it at all [11:58] (at least not wrt upstart handling) [11:59] sergiusens: nah, no need. it does expose a tricky bug. I'll chat with jodh about it, when he is back from lunch. [11:59] sergiusens, thats pointless, we need it running constantly anyway for all the sensors [11:59] (once it supports all of them :P ) [11:59] sergiusens: but if you do want to stop unstoppable jobs, stop the two dbus bridges first, for now. [11:59] ogra_: yeah; it is; as on first activation it would just be there forever [12:00] right, then we can as well leave that to upstart [12:00] and not add extra saturation the system dbus for it [12:00] xnox: ok; Chipaca will find more use of that; I actually don't need to stop anything; he used me to make an example of :-P [12:00] *of the [12:01] ogra_: agreed; there's a couple more I'd actually like to move to upstart instead of dbus activation; the first one that comes to mind is telepathy-ofono [12:02] right [12:02] for all stuff thats long running we should just use upstart [12:04] xnox: sergiusens: Hi :) [12:04] right now if you apt-get install ubuntu-push, you probably want to be able to stop it after tinkering with it a bit [12:04] just because it's there for testing [12:04] and ... well, it's rather cussed [12:04] :) [12:05] i mean: there's nothing depending on it, nothing calling into it, nothing at all that would make me think something is trying to restart it [12:05] maybe the upstart .config thing is bad? [12:05] i just copied usensord's one :) [12:07] sergiusens, ergh [12:07] stop on runlevel ? [12:07] thats a session job [12:07] you want to stop on session-end or some such [12:07] Chipaca, ^^ [12:08] ogra_: is that causing this breakage? [12:08] Chipaca: no, usensord is fine and ubuntu-push is fine. [12:08] we it is causing the daemon not to stop with the session as it should [12:08] Chipaca: nah, it simply means usensord is killed, rather than stopped on shutdown. [12:09] ogra_: will investigate further [12:09] * ogra_ still thinks we should use system events for session stuff [12:09] ogra_: session force kills all jobs at the end, so one can even leave out "stop on" [12:09] *shouldnt [12:09] ogra_: might be a problem to fix, but it shouldn't restart on a stop request [12:09] xnox, right [12:09] i dont mind leaving stop on out [12:09] xnox: ah, nice; I'd rather have that; as in no stop stanza and let it do the right thing [12:09] ogra_: well, the runlevel event on session init appears as "sys:runlevel" thus "runlevel" is never emitted on the session init, thus "stop on runlevel" for a session job is equivalent to no "stop on" at all =) [12:09] but stop on runlevel seems just ugly [12:10] yeah [12:10] thats what i mean :) [12:10] i can fix that, but that has nothing to do with manually calling $ stop usersensord [12:10] cause that's not event triggered. [12:10] do we actually have a plain dbus event (not started/stopped/starting dbus) [12:10] maybe it shouldn't be 'start on dbus' either? [12:10] Chipaca: for now, $ stop upstart-dbus-sessin-brdige; stop upstart-dbus-system-bridge; and then stopping usernsord/ubuntu-push should work. [12:11] ogra_: yes we do, it's the session dbus [12:11] ok [12:11] Chipaca: start on dbus is correct, if your daemon exports itself on dbus and needs dbus running. [12:11] it'll helpfully wait around until dbus becomes available if it isn't :) [12:12] but, yeah, better to wait and start it after [12:12] 14:12:34 LOOP 200 [12:12] wohooo !!! [12:12] oops, ECHAN [12:13] * ogra_ goes to #ubuntu-ci-eng instead [12:13] Hi people. I've been debugging a trusty issue that has been driving me crazy. initramfs-tools hangs on image generation, calling /libx32/ld-linux-x32.so.2. I'm running kernel -20, and I've confirmed that on kernel -22 this does not happen. However, since my initramfs generation failed, I couldn't reboot into the new kernel. I've now modified /usr/bin/ldd to not call /libx32/ld-linux-x32.so.2, and with that I can upgrade, but I think that [12:13] anybody in the same situation will also go crazy. [12:13] Since this is a problem with dist-upgrading inside trusty... Is it worth reporting a bug about it? [12:13] sounds like a multiarch issue [12:14] ogra_: no, this is multilib issue, not multiarch. [12:14] Yes, multilib. Happens because I have gcc-multilib installed [12:14] well, some multi* issue :) [12:15] marga: yes, please still report it. And possibly assign it to infinity https://launchpad.net/~adconrad [12:15] you definitely dont want update-initramfs to process any foreign arch stuff [12:15] marga: it may have been fixed, but if it's transient maybe we'll need to do something such that this doesn't happen again. [12:15] ogra_: yes you do. === davidcalle_ is now known as davidcalle [12:16] xnox, huh ? what for ? [12:16] ogra_: our user-space is multilib, thus it needs to work =) [12:16] ogra_: and we have x32 enabled on our stack. [12:17] but it is pointless to have any non native stuff in your initrd [12:17] * ogra_ doesnt see a use case for that [12:18] ogra_: the point is that our linker must work, and during initramfs generation we call into linker and ask linker to resolve paths to libraries needed for binaries to generate a full initramfs. And it looks like, marga is reporting that linker got broken and was not resolving libraries. [12:18] ogra_: a broken linker is bad, however you look at it =) [12:18] sure, i know there are hacks in update-initramfs or mkinitrd for that [12:18] thought only for amr stuff iirc ...to work around hf vs el [12:19] actually, this was hanging on a copy_exec on a shell script [12:19] *arm [12:19] yes [12:19] Which is likely a bug as well. [12:19] ogra_: it's not hacks, but the point is that /usr/bin/ldd should be operational no-matter what for native arch. with or without extra packages, foreign or multlib arches are enabled. [12:19] copy_exec is what uses ldd to determine reverse deps of libs for a binary [12:19] But the thing was ld64 was failing, because it was a shell script, and then ldd called ld32 [12:19] xnox, but you dont want two linkers in the initrd [12:20] ogra_: and above it shows that it failed. [12:20] ogra_: we don't have two linkers in the initrd. [12:20] right [12:20] but you would need an x86 one for x86 binaries, no ? [12:20] ogra_: a call to ldd failed, at critical operation, and it should not have. [12:20] (during dist-upgrade / initramfs generation) [12:21] ogra_: and that's a bug. and has nothing to do with what our initramfs generation does. [12:21] (has, should have, doesn't have, etc.) [12:22] ok, i trust you :) [12:23] * ogra_ goes back to cursing cgmanager vs cgroup-lite issues and watching the 220th reboot of his phone [12:23] Chipaca: sergiusens: jodh: the jobs are buggy! [12:23] Chipaca: sergiusens: jodh: "start on dbus" is start on any system/session dbus event. [12:23] heh [12:23] Chipaca: sergiusens: jodh: "start on started dbus" is start after session/system dbus are available [12:23] Chipaca: sergiusens: i'll make merge proposals to fix thsi. [12:24] xnox: ah! excellent, thanks [12:24] Chipaca: where is ubuntu-push code? [12:24] pedronis: we might have another one-liner fix in today's trunk build, then [12:24] xnox: i'm getting thing ready to go into a silo; want me to sneak this in too? [12:25] Chipaca: well, let me make the merge proposal which project/branch do you use? [12:25] xnox: lp:ubuntu-push/automatic [12:25] xnox: branch from there, mp into there; that goes into /trunk once everything is green in the auto tests [12:26]