=== _salem is now known as salem_ === salem_ is now known as _salem [04:40] On Ubuntu Core, how can I find a listing of packages that are available for `snappy install`? [04:41] Just guessing names hasn't gotten me very far [04:44] Hmm, reading through the channel description, I might be in the wrong room...sorry! Is there a better room for these questions? [05:05] bryce__: Not to my knowledge. [05:06] Gotcha! Is there a syslog package available that you know of? [05:06] Nah, I'm pretty out of the loop vis-a-vis Ubuntu Core. [05:06] Sorry. :) [05:06] cool -- thanks anyway :-) [05:07] is there a better room or place to ask ubuntu core questions? [05:07] it seems like an awesome project [05:08] bryce__: Hm, https://developer.ubuntu.com/en/snappy/ suggests “snappy search syslog” might be relevant to your interests. [05:09] bryce__: Ah! #snappy on freenode is apparently your winning ticket. [05:09] woot! thanks [05:22] slangasek: It's not an Ubuntu start page bug, it's because you upgraded firefox and didn't kill/restart it. [05:22] slangasek: The old running firefox has a hissy with the new language bits, ignores your en-us/en preference, and picks the first one in its internal list, which is Arabic. [05:23] slangasek: Old windows and tabs are fine, entire new processes are fine (since they're the new firefox), but new windows as children to the old firefox lose their mind. [05:23] chrisccoulson: ^ [05:24] Given slangasek's language preferences, that make even be an excuse to learn Arabic? :-P [05:24] Every time it happens to me, I'm reminded that I keep meaning to learn Arabic, yes. [05:24] But man, right-to-left web browsing is confusing. [05:25] I don't tend to see pages in Arabic. It tends to show up for me as some elements not rendering or the interface itself having issues [05:26] Different symptom, same bug. [05:26] In your case, it's the old xulrunner and new xul disagreeing. [05:26] In our case, old firefox and new firefox locales. [05:27] In every case, "restart firefox" is the answer. [05:27] After killing it with fire. [05:27] Or just a reboot, for the "Adam's parents" demographic. [05:27] Haha [06:23] Good morning === kickinz1|afk is now known as kickinz1 [08:06] good morning [08:14] hey dholbach, happy friday! [08:15] hi seb128 [08:15] and the same to you! [08:16] thanks :-) [08:41] hi people! [08:44] pitti, sorry did you receive the mail? ;) [08:44] hey LocutusOfBorg1 [08:44] LocutusOfBorg1: yeah, fished it out of my spam filter this morning; I'll get to it ASAP [08:48] this is why I asked :) [09:53] didrocks: hey, thanks for packaging xdg-utils. sadly it looks like something broke. one of the patches was created against another one which was dropped. [09:53] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/xdg-utils/vivid/view/head:/debian/patches/xfce-blanking.diff [09:55] if you follow the upstream link in the patch header, you will see that the applied upstream patch has a case for "xfce" and for "''". however, the patch in the ubuntu package replaces the "''" one with "xfce". [09:55] original author is gone for a week or so :/ [09:56] brainwash: I didn't review the first commit as it was already approved by a core dev and discussed, I thought that this was intended [09:57] brainwash: ok, so, the fix is to have "xfce" and "''"? [09:58] didrocks: yes [09:59] brainwash: mind giving a debdiff? I will just sponsor it then :) [10:00] didrocks: ok, but it will take some time [10:01] I'm not a packaging expert :) [10:02] brainwash: well, if there is no hurry as long as it's fixed for today, it's a good practice :) [10:02] brainwash: tell me if you need any help, sorry for the breakage :) [10:04] didrocks: alright. luckily we did not SRU it to trusty right away :D [10:05] yep! [10:37] didrocks: totally agree with you on http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html [10:37] didrocks: trying to have sane /etc and sane /usr is impossible. [10:38] xnox: ah, you climbed that long thread! how long did it take you? :) [10:38] xnox: I plan to bring back the topic at the hackfest, we need to settle on something [10:39] didrocks: well i'm eager to solve it as well. [10:39] didrocks: imho it's outright wrong that .wants/foo.service -> actually does not matter where it points. [10:40] didrocks: i raised same topic again yesterday on the mailing list "Unwants" and was pointed to your thread. [10:41] xnox: yeah, I saw your unwants one, and thought "ah, this is actually how we started this thread" ;) [10:41] didrocks: right. [10:41] xnox: I think you, pitti and I should meet before the hackfest and try to summarize (I have http://pad.ubuntu.com/systemd-enablement-handling and http://pad.ubuntu.com/systemd-usr-etc) [10:41] so that we can think of all cases (I tried at least) and sum that up [10:42] didrocks: note that i'm only interested in the context of system-image updates, which themself have been compiled / assembled from packages. [10:42] didrocks: which i think is broadly the scope of the problem. [10:43] didrocks: i'm in brussels from thursday evening. [10:44] xnox: I think that the 2 use cases should converge, basically, it's "we don't want cruft" :) [10:44] an defaults in /usr [10:44] and* [10:44] xnox: I am as well, let's wait for pitti if he can be available? [10:44] yeah [10:46] didrocks: i hate pad and it's insistency on doing 2fa [10:46] didrocks, xnox: what's up? [10:46] pitti, did you test your systemd upload on a phone ? (stgraber: same question to you for lxc) ... seems we cant boot anymore in vivid ... [10:46] pitti: we want a secret kabahl within the systemd kabahl. [10:46] * pitti reads backscroll; sorry, snappy day today.. [10:46] [10:47] (and systemd as well as lxc look most suspicious on http://people.canonical.com/~ogra/touch-image-stats/74.changes) [10:48] ogra_: no, I didn't test it there; what fails? [10:48] the container? early boot? [10:48] dunno, i only have an unsupported phone with vivid atm, but it doesnt even seem to get to mount a rootfs here [10:48] should show up on the emulator [10:48] which points to udev perhaps ... [10:48] but it seems mako is not even starting lightdm/system-compositor [10:49] yeah, I'm currently building an emulator image [10:49] (wildly guessing here) [10:49] rsalveti, ogra_: checking logs on my bricked device, but yeah it's either udev, lightdm, lxc or systemd [10:49] This image had all of them [10:49] :-) [10:49] * xnox cannot boot any ubuntu emulator with vivid, ever. can't find rootfs - either on trusty or vivid, with distro goget tools or compiled trunk (from launchpad) [10:49] xnox: that was fixed with latest goget-ubuntu-touch [10:50] https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.14-0ubuntu1 [10:50] sil2100, oh, so yours gets far enough to adb shell in ? [10:50] rsalveti: where is that - in vivid distro, some ppa, bzr launchpad upstream? [10:50] thanks. [10:50] bug 1412495 [10:50] bug 1412495 in goget-ubuntu-touch (Ubuntu) "ubuntu-emulator fails to start on Vivid" [Undecided,Fix released] https://launchpad.net/bugs/1412495 [10:50] vivid distro [10:50] ogra_: no... it stays on the ubuntu logo [10:50] (I mean, manufacturer logo) [10:51] But I booted up into recovery and try to see what's up [10:51] yeah, ubuntu logo would mean lightdm is up [10:52] sil2100, ok, i see the same here [10:52] * ogra_ rolls back to 73 === doko_ is now known as doko [10:57] mount: mounting /dev/mtdblock2 on /root/android//cache failed: Invalid argument [10:57] ogra_: ^ is that something to worry about, or normal? [10:57] it still seems to be stuck in initramfs [10:58] if it is actually not mounted thats something to worry about indeed [10:58] thouh /cache is not essential for the boot [10:58] for emulator that is fine [10:58] afaik [10:58] k [10:59] ok, thanks [10:59] i was only thinking about /init running set -e [10:59] (i wasnt sure if we shouled mount failures) [10:59] *shield [11:00] Begin: Running /scripts/init-bottom ... done. [11:00] [ 1.418683] init: ureadahead-touch main process (462) terminated with status 5 [11:00] [ 2.180823] init: no-cpu-hotplug main process (610) terminated with status 1 [11:00] that's all I get here [11:00] not gettin out of initrd means it is likely neither lightdm or lxc [11:00] right, so most likely udev [11:00] [ 1.025651] initrd: starting adbd for USB debugging [11:00] [ 1.026668] adbd[283]: segfault at c ip 0804cb29 sp bf9aa4b8 error 4 in adbd[8048000+20000] [11:00] pitti: did you remove that other rule I had a while ago? [11:01] meh, no adb, and busybox doesn't really work either (no prompt) [11:01] yeah, it seems adb is busted [11:01] rsalveti: no, that's still there [11:01] but adb crashed before too, that's nothing new (it doesn't seem to work that early) [11:01] yeah [11:01] rsalveti: it's now in /lib/udev/rules.d/61-persistant-storage-android.rules [11:02] right, we dont have any adbd binary that works in initrd anymore currently [11:02] rsalveti: which is easier to maintain than an eternal patch [11:02] oh, perhaps that needs to go into initramfs? [11:02] needs a special build [11:03] rsalveti: if the initramfs need the PARTNAME symlink to boot, that sounds like a very plausible candidate [11:03] yeah [11:04] ogra_, rsalveti: ok, I'll see to hack the .img files to include that rule and try again; it's system.img that I want, right? [11:05] yeah, we're looking for the partname userdata when mounting things around [11:05] so that might indeed be it [11:06] yup, the ubuntu one [11:06] didrocks: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025296.html -> are good semantics that I like. Didn't check the pad yet (need to fetch phone for 2fa) [11:06] rsalveti: hm, system.img doesn't look like the one I want [11:07] no, you want the initrd [11:07] ramdisk.img? [11:07] boot.img? [11:07] * pitti looks through them all [11:08] ok, not ramdisk [11:08] xnox: they are some corner cases with that one (explained later in the thread I guess), but yeah, it's the closest to the best solution [11:08] not boot.img [11:09] ogra_, rsalveti: oh, it's system.img, that contains a system.img, which finally seems to be the fs that I need :) [11:09] most likely boot.img [11:09] oh [11:09] ok [11:09] Inception [11:09] yeah [11:10] meh no -- that boot/ is empty [11:10] where is that darn initramfs? [11:10] didrocks: so reading this thread - i want to start shouting at people "there is no way to upgrade preset" - I hope that comes up in the thread. Ie. if one had "enable sshd.service, disable sshd@.socket" and wants to move to reverse "disable sshd.service, enable sshd@.socket" it cannot be done at upgrade time with preset. [11:10] sure the preset changes, but one cannot run "preset-all" without trumping local user configuration. [11:11] in fact there is no way to specify for the admin, as the "old state" is assumed to be "distro/preset state" when in fact it's a mix of "admin & distro/preset" [11:11] rsalveti: /boot/android-ramdisk.img on system.img? [11:12] nope, that's really android [11:12] pitti: for emulator that is available in your host side [11:12] .local/share/ubuntu-emulator/test_x86/ramdisk.img [11:12] e.g. [11:12] rsalveti: so boot.img and ramdisk.img don't contain anything, system.img is android, and sdcard.img doesn't contain an ubuntu initramfs; /me confused [11:13] rsalveti: oh, ramdisk.img isn't a qemu img, Isee [11:13] rsalveti: ok, that explains the confusion; thanks! [11:13] the previous persistent storage rule is there [11:13] ./lib/udev/rules.d/60-persistent-storage.rules [11:14] yeah, I'll just add my new one [11:14] phone, brb [11:14] xnox: I mentioned it multiple times in the thread :) [11:14] xnox: just be patient :p === _salem is now known as salem_ [11:18] didrocks: and "copy the unit to /etc/ modify Install section to change wants" does not work -> that is .wants/* symlink in /usr/ is still honoured. thus as far as i can tell there is never a way to unwant. [11:21] didrocks: my alternative idea was to make "systemctl enable/disable/mask/unmask" to write out a user preset file in /etc/systemd/system-preset [11:21] not have any symlinks [11:21] make systemd actually load the preset files and parse them in memory, rather than on the filesystem level. === kickinz1 is now known as kickinz1|lunch [11:24] "but I would have thought that presets should only be applied on install-time, and not on upgrade." -> and what should you do on upgrade?! +) and imho he is confusing package install/upgrade with OS install/upgrade. [11:27] dear developers, I would like to have your opinion on bug 1413947 [11:27] bug 1413947 in virtualbox (Ubuntu) "Official kernel.org 3.18.3 (custom config) : virtualbox-dkms 4.3.10-dfsg-1ubuntu1: virtualbox kernel module failed to build" [Undecided,Incomplete] https://launchpad.net/bugs/1413947 [11:30] xnox: keep reading, I don't think we would go to not having symlinks, but yeah ;) [11:31] didrocks: i would be happy if symlinks are user generated only. And system presets are applied in memory without any symlinks anywhere - neither in /usr/ nor /etc nor /run [11:32] xnox: that would be a nice solution [11:32] xnox: we still need the unwants: with this [11:32] or the /dev/null [11:32] "There should be no need to "stick" some of the services as distro choices are only applied at install time, and never on upgrade." -> because RPM upgrade choices are encoded in systemd upstream. [11:33] xnox: well, it's more because they don't enable any service by default [11:33] so you install openssh-server [11:33] didrocks: imho unwants is foo.service.wants/undesired.service -> /dev/null (symlink) [11:33] xnox: agreed [11:33] you don't have it started on install or next reboot [11:33] yes, presets are optimized for fedora/rpm pagadim of upgrades. [11:34] xnox: not sure if you read that yet, but I also talk about the alternatives issue with that (and aliases) [11:34] xnox: like lightdm, kdm, and so on… [11:34] and various flavors [11:38] infinity: could you look at this mysql apt upgrade thing for me please? My test packages are in ppa:mysql-ubuntu/collab. Easy to reproduce - just install mysql-server from vivid, then add the ppa and dist-upgrade. [11:41] didrocks: no matter how one looks at this - current status is optimised for "disabled by default" policy. Since unit file by itself, is never considered to be enabled unless symlinks are generated. If symlinks are in /usr it's a "should not disable" unit, if in /etc -> "it's user enabled, or most-users-enable-this-distro-enabled-it-at-first-installation" [11:43] xnox: yeah, I guess debian/ubuntu are the first distros who wanted enabled by default [11:43] ogra_, rsalveti: so diffing the previous and current udev debs, this is the only significant change, so I uploaded -5ubuntu2 with that fix [11:43] for most of the things [11:44] pitti, cool [11:44] i'll do a vivid re-build once it is in the archive then [11:44] ogra_, rsalveti: I seem to be unable to munge the initramfs manually though, it still fails; I'll keep debugging, but if that's indeed the problem (likely) then we'll at least have a fixed package ASAP [11:44] and if it's something else still, well it's still a valid and necessary bug fix [11:44] didrocks: despite upstream implicit "enable *" without any preset policy [11:44] pitti: yeah, failed for me here as well [11:44] but cool, thanks for that [11:45] rsalveti: the rule said it's also necessary for flash-kernel, so maybe something else depended on that during image build, which I didn't catch with the initramfs tampering? [11:45] ogra_: guess we need to bump initrd and android after that, right? [11:45] oh, right [11:45] hmm [11:45] xnox: I think they are not in the "we can upgrade defaults to your users" mindset [11:45] was it bumped for -5ubuntu1? [11:45] nops [11:45] we didnt bump it between 73 and 74 [11:46] I mean, the upload broke it automatically, it shoudl fix itself automatically? [11:46] xnox: despite my numerous examples in the thread (and I can add more of what we needed to do in ubuntu), they just don't see that as desirable :p [11:46] yes, it should [11:46] nothing in the initrd changed, so it would indeed still be able to boot [11:46] rsalveti, ogra_: anyway, sorry about that! I'll see to it this afternoon if things still go haywire with this [11:46] not sure why it silently fails though [11:46] xnox: the only point I'm unsure is "if you enable manually an unit that is already enabled by default, and then, we disable the unit as per new distro default, should that unit still be enabled?" [11:46] probably because the inird ships an olde udevd ? [11:47] *older [11:47] xnox: they are prons and cons to both, if the answer is "yes", then, we need a reset command… [11:47] there* [11:47] rsalveti: unpackign ramdisk.img shows that this was built with the updated udev rules (i. e. droping the PARTNAME rule), but was missing the new 61-persistent-android file [11:47] ogra_: the udev binary didn't change at all, just the PARTNAME rule moved to a separate file [11:47] hm, we didn't rebuilt the initrd [11:47] ah, k [11:48] (it should eventually live in some touch specific package, not udev, but I kept it there for now) [11:48] rsalveti, does the emulator rebuild it on image creation ? [11:48] shouldn't, and I thought I still had that rule here [11:48] let me extract it again [11:48] rsalveti: oh, you are right [11:49] so the init logic, until it boots upstart, is the same [11:49] didrocks: the answer is yes. At the moment there is no way to tell systemd "i know better" since .wants symlinks / wants dependencies are honoured from lower level directories even if the unit is outright overriden. [11:49] it already is in the original ramdisk.img, which explains why my hand-editing didn't make a difference [11:50] [ 1.418683] init: ureadahead-touch main process (462) terminated with status 5 [11:50] [ 2.180823] init: no-cpu-hotplug main process (610) terminated with status 1 [11:50] that's all I get here [11:50] these messages are not from /init [11:50] yeah, same [11:50] xnox: right, there is no way to support that case for now, I'm unsure about the "should", I tend to answer yes as well, but I can accept counter-arguments :) [11:50] but already from /sbin/init [11:50] so we are past the initrd here [11:51] yeah, already in upstart [11:51] ogra_: oh, we are? ok [11:51] so the PARTNAME thing woudl probably have hit us as soon as we did update the initramfs [11:51] yeah [11:51] so good that we found it, but it's not that one [11:51] right, unlikely to be the actual issue we see here [11:52] do we put the partnames into fstab at fstab creation ? [11:53] so, ironically it does boot further with systemd; that at least proves that it does get out of the initramfs [11:53] right [11:53] it fails to start the container, though [11:53] aha ! [11:53] Starting ifup for lxcbr0... [11:53] [FAILED] Failed to start ifup for lxcbr0. [11:53] well, at least the brige, not sure how crucial that is [11:53] oops, i thought we had that disabled [11:53] or if it's a red herring [11:53] but it doesn't start lightdm either [11:54] right, lightdm only starts after the container is up [11:54] right [11:54] http://paste.ubuntu.com/9833781/ upstart with debug [11:54] the container initialized the graphics drivers atm [11:54] rsalveti: oh nice, how do you do that on the kernel cmd line? I tried "debug", but that's not it [11:54] [ 2.235346] init: lxc-android-boot state changed from waiting to starting [11:55] never gets out of the starting state [11:55] pitti: yeah, adding --debug [11:55] hm, buut thats only the boot jobs [11:56] rsalveti: where? [11:56] pitti: in the kernel cmdline [11:56] oh, how unusual; thanks [11:56] *nnng* want shell [11:57] ubuntu-emulator run test_x86 --memory=1024 --kernel-cmdline="--debug" [11:57] yeah [11:57] [ 2.003008] init: lxc-android-config state changed from post-starting to post-start [11:57] there we go [11:57] it never gets to "started" [11:57] ogra_: you mean "running"? [11:57] right [11:58] (it never emits the started event, so lightdm doesnt fire) [11:58] (or adb) [11:58] there should be some lxc log [11:58] I had a regression with user containers, filed as bug 1413927; maybe that somehow affects that too [11:58] bug 1413927 in lxc (Ubuntu) "lxc_cgmanager_enter: 694 call to cgmanager_move_pid_sync failed: invalid requestUser container fails to start: " [Undecided,New] https://launchpad.net/bugs/1413927 [11:58] ot at least the upstart log for the job [11:59] ogra_: well, they should be written to /var/log/upstart/ in system.img? [11:59] on the sdcard.img qemu? [11:59] in the wriable equivalent, yeah [11:59] yeah, better trying to find the lxc logs [11:59] should be there [12:03] userdata.img is zero bytes, /me looks in sdcard.img [12:06] hm, log for lxc android is 0 bytes [12:07] cat lxc-monitord.log [12:07] lxc-monitord 1422014624.322 NOTICE lxc_monitord - lxc_monitord.c:main:416 - pid:585 monitoring lxcpath /var/lib/lxc [12:07] nothing useful [12:07] hm, I killed my workstation, I think mount /dev/nbd0 hanging forever [12:07] can't reboot, running a snappy test for mvo.. [12:11] pitti: ogra_: http://paste.ubuntu.com/9833964/ [12:11] lxc android with debug [12:11] the kernel misses the network namespace ? [12:12] i'm pretty sure we had switched all networking off for the container in the past [12:13] meh, no upstart log for the lxc container start? [12:13] there should be an lxc-android-config log [12:13] cgmanager: Could not look up /run/cgmanager/fs/freezer/freezer.state [12:13] cgmanager:get_value_main: Pid 506 may not access /run/cgmanager/fs/freezer/freezer.state [12:13] not sure if that's relevant [12:13] nops [12:13] because what seems to be failing is lxc itself [12:13] ogra_: no, there isn't; that's what I meant [12:13] only for apps perhaps :) [12:14] lxc-start 1422015012.041 WARN lxc_confile - confile.c:config_personality:1021 - unsupported personality 'armhf' [12:14] also weird, this is the x86 emulator [12:14] but well, basically the container failed to start [12:15] Jan 23 10:56:11 ubuntu-phablet kernel: [ 5.028352] init: lxc-android-config post-start process (574) terminated with status 1 [12:15] ok, so definitively that, yes [12:17] lxc-start[717]: lxc: cgmanager.c: lxc_cgmanager_escape: 329 [12:17] call to cgmanager_move_pid_abs_sync(blkio) failed: A proxy is required === MacSlow is now known as MacSlow|lunch [12:18] that's the closest error I can fine [12:18] find [12:18] cgproxy failed due to [12:19] cgproxy:get_value_main: Failed reading string from cgmanager: No child processes [12:19] and cgmanager failed due to the above freezer.state thingy [12:19] we should be able to get adb if you change the adb upstart job to not depend on lightdm I guess [12:19] so, no cgmanager -> no cgproxy -> no lxc -> boom [12:19] right [12:20] yeah [12:20] but cgmanager didnt change [12:20] nor did the kernel [12:21] ah, maybe the new lxc makes a new type of request to cgmanager which it hadn't before? [12:24] might be, but then i would have expected stgraber to update them together [12:26] ogra_: pitti: yeah, got rev 74, updated lxc, rebooted, boom [12:27] so i guess we need stgraber === kickinz1|lunch is now known as kickinz1 [12:46] xnox: are you planning on merging php5? Or do you want me to take it over again? [12:53] rbasak: there was something rather upstart job about it. let me check. === MacSlow|lunch is now known as MacSlow [13:18] didrocks: posted my summary of that thread. [13:20] xnox: reading [13:24] didrocks: talking in multiple channels is fun -> i love how nobody replied to your alternatives question. [13:25] xnox: :p yeah… as you can see the thread was going to be not ending, that's why I decided that the hackfest would be better to restart the discussion [13:25] as far as i can tell, rpm distros hate supporting alternatives and the way it's done essentially is that last one wins on packaging level similar to how in debian everything does "conflicts/provides: only-one-service" [13:25] xnox: lennart answered on the alternatives + preset though [13:26] didrocks: where? [13:26] * xnox can't see [13:26] xnox: let me try to fetch it [13:27] -enochan [13:30] xnox: did you find out about php5? [13:31] xnox: starting with http://lists.freedesktop.org/archives/systemd-devel/2014-December/026008.html [13:47] rbasak: yes, please merge php5 there is nothing crazy about it. [13:53] xnox: OK will do, thanks. [14:01] pitti: did lazr.restfulclient fix the bug you saw with python3 launchpadlib? [14:01] pitti: and do you have more bugs? =) [14:02] 0.13.4-3 [14:05] xnox: ah, I didn't get back to that yet, sorry; too much snappy :) === tedg is now known as ted [14:06] pitti: snap louder...?! [14:07] * xnox is not sure of an appropriate cheer up and a pun at the same time [14:10] good morning! [14:21] xnox: hmm, staging doesn't let me log in, seems its 2FA got out of sync [14:22] (I tried the "enter three codes" after "having problems", but it doesn't re-sync) [14:22] pitti: staging has differen 2fa tokens... [14:22] oh, right [14:22] pitti: or rather you should have a different 2fa token for staging. [14:23] pitti: alternative is fake account, or leave 2fa-demo-group [14:23] xnox: I actually do *blush*, just looked at the wrong one in google auth :( [14:23] but i guess you can't leave 2fa-demo-group due to other memberships that include that one. [14:23] so with py2 I saw the "The authorization page:..." message, which doesn't happen with py3 [14:28] xnox: so with py3 and unauth'ed, I get http://paste.ubuntu.com/9835355/ [14:28] xnox: with py2, this leads me to the LP login page, where I login [14:28] once auth'ed, py2 works, and with py3 I now seem to get a py3 incompat in my own code, so that looks promising! [14:29] xnox: but yes, the original bug is definitively fixed, thanks! [14:31] pitti: keep them comming. i cannot run the full test-suite =/ as i've only ported the critical path to runtime, rather than all test-suite deps. [14:31] all test-suite deps dig deep into lazr.* stack and pretty much a lot of launchpad. [14:31] xnox: right, I'll file a proper bug report soon [14:32] xnox: if this works while already being authenticated, that's a huge leap already [14:55] ogra_: do you have version 0.35 of cgmanager on that device? [14:56] ogra_: I've got a meeting in 5min but I'll go grab my nexus4 and see if I can reproduce this [14:56] stgraber, whatever is current in vivid [14:57] its today image build [14:57] *todays [14:58] oh and my nexus4 is on RTM and with my custom debug kernel, so I guess my test wasn't terribly good since it was older cgmanager and a kernel which doesn't require cgproxy [15:01] ah, yeah :) [15:01] now that we have reasonably recent kernels for touch, I should really get the kernel team to include those, it'd be one less daemon running on it and one less source of problems [15:22] stgraber: it reproduces just fine in the emulator, might be easier than bricking your n4 [15:22] stgraber: sudo ubuntu-emulator create --channel=ubuntu-touch/devel-proposed dprop [15:23] pitti: well, I don't use my nexus4 so I don't mind :) [15:24] and it's faster than the emulator [15:25] stgraber: really? [15:25] stgraber: I find the emulator delightfully fast, and one has a serial console for free :) [15:31] ogra_: what's the bug# ? [15:32] i dont think anyone has opened one ... sil2100 ? [15:34] infinity: ok well it went away on its own regardless, without restarting the browser. [15:35] ogra_: I didn't hear about any, sadly [15:36] ok, anyway, I'm about done downloading the rootfs here, so should have a phone with the bug in about 30min [15:36] stgraber: thanks :) [15:36] I'll then work with hallyn to figure out what's going on exactly [15:37] since it looks like it's some odd lxc talking to cgmanager through cgproxy problem [15:37] stgraber, you will need to hack the adb upstart job to get in [15:37] (as we're not seeing the problem at all when talking straight to cgmanager on recent kernels) [15:37]