[02:48] <psusi> anyone know anything about g_udev_device_get_sysfs_attr?  it seems to cache the attribute the first time it is read and never re-reads it
=== lisca is now known as but_why
=== Ursinha-afk is now known as Ursinha
[05:31] <pitti> Good morning
[05:32] <Logan_> hey pitti
=== Ursinha is now known as Ursinha-afk
[05:37] <Logan_> quilt patches that delete files make me (and bar) sad
[05:37] <Logan_> *bzr
[05:39] <mterry> stgraber, the lxc autopkgtests seem to be failing?
[05:41] <stgraber> mterry: they sometimes do that but usually end up passing, if they're now all failing, that's because something somewhere regressed
[05:42] <mterry> stgraber, I don't know about all failing.  I just noticed it holding up a cgmanager update: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  - looks like the unpriv tests failed?
[05:42] <mterry> stgraber, if that's the sort of thing that might pass if retried, I can do tht
[05:43] <stgraber> mterry: hmm, no, retrying won't help with that one, we apparently switched to 3.15 and we need some upstream fix for that. I'll cherry-pick and upload in a bit
[05:44] <mterry> stgraber, oh cool, glad it's a known issue  :)
[05:45] <stgraber> mterry: yeah, the 3.15 kernel now prevents reading some files to non-root users...
=== Ursinha-afk is now known as Ursinha
=== FJKong is now known as FJKong_afk
[07:16] <infinity> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
[07:53] <timchen119> hi, I found lp:ubuntu/python-debian is not sync with lp:python-debian , anyone know how do I help? any wiki page describe this sync process?
[07:54] <timchen119> last commit in lp:python-debian is 2012-10-08, but it still not in Utopic.
=== ted is now known as tedg
[08:27] <zbenjamin> cjwatson: ping, is there any directory i can put a file that i can read from inside confinement? i get permission denied for /tmp
[08:38] <sarnold> zbenjamin: hopefully this can help: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest
[08:40] <cjwatson> zbenjamin: yep, security team for confinement questions :)
=== vrruiz_ is now known as rvr
[08:50] <zbenjamin> sarnold: thx
[08:56] <zbenjamin> sarnold: i'm working on debugging confined apps. What i need to do is run gdbserver inside a click package so i can connect to it
[08:58] <sarnold> zbenjamin: I suspect the ptrace attach will fail; why not run gdb 'outside' the click package?
[08:58] <zbenjamin> sarnold: how should i connect to the application running inside then?
[08:58] <zbenjamin> sarnold: attaching is no option, it would make it impossible to debug the application startup
[08:59] <sarnold> zbenjamin: that's a fine question.
[09:00] <zbenjamin> sarnold: also we need a way to connect to the qmljs debugger which always runs inside the app and opens a port so the IDE can connect to it
[09:00] <zbenjamin> sarnold: i guess we will need a debug policy that allows this stuff
[09:01] <sarnold> zbenjamin: what kind of port? tcp would be currently unmediated, that ought to work fine today.
[09:02] <zbenjamin> sarnold: i think its tcp
[09:02] <zbenjamin> sarnold: thats basically the wrapper script that sets up the stuff inide the confinement : http://pastebin.ubuntu.com/7519903/
[09:02] <sarnold> zbenjamin: ah, good. so that means qmljs ought to work ..
[09:03] <zbenjamin> sarnold: thats how it fails: http://pastebin.ubuntu.com/7519911/
[09:04] <sarnold> zbenjamin: I think that script would work alright from outside confinement though
[09:05] <zbenjamin> sarnold: yeah but i was told we want to debug our apps in confinement because we need to be as close as possible to the real environment a app gets
[09:06] <sarnold> zbenjamin: yeah, I can understand that desire. I'm not sure how well it'll work though.
[09:07] <zbenjamin> sarnold: so gdbserver will listen on a tcp port as well, the only thing that needs to be sorted out is the ptrace call you mentioned. Any idea how we can get there?
[09:07] <zbenjamin> i'm actually not really sure if the failure i see is because of that, i get permission denied but the exception still happens in python.
[09:08] <sarnold> zbenjamin: yeah, that's a simple denied for exec(gdbserver), they'll get worse and scarier once that execute is allowed. :)
[09:10] <zbenjamin> sarnold: can i allow that call somehow?
[09:12] <sarnold> zbenjamin: if you edit the generated apparmor policy (in /var/lib/apparmor/profiles/) and then install that updated policy, you can probably get there
[09:13] <zbenjamin> sarnold: how about providing a debug policy ? The store would need to reject that of course
[09:13] <sarnold> zbenjamin: you -might- get lucky if you add /usr/bin/gdbserver Ux, permissions to your policy
[09:13] <sarnold> zbenjamin: yeah, that's a really good idea
[09:14] <zbenjamin> sarnold: can you help me put one together?
[09:14]  * zbenjamin <-- app armor noob
[09:14] <sarnold> zbenjamin: sure
[09:15] <zbenjamin> for now we "only" need to execute gdbserver and be able to connect with tcp
[09:15] <sarnold> zbenjamin: do you see a file in /var/lib/apparmor/profiles that cooresponds to your app?
[09:15] <zbenjamin> sarnold: no the app is uninstalled after executing it :/ the adk-launcher script is doing that automatically  but i can disable it for now
[09:16] <sarnold> zbenjamin: oh nuts. well, okay...
[09:16] <zbenjamin> now i have that file
[09:18] <zbenjamin> sarnold: best would be if i could just add "debug" to my policy list
[09:18] <sarnold> zbenjamin: sure, that's a nice end goal :) but won't happen today, hehe
[09:19] <sarnold> zbenjamin: if you can stand a bit of hackery in the meantime, try adding "/usr/bin/gdbserver Ux," to the file and reload it with apparmor_parser --replace /path/to/file
[09:19] <sarnold> zbenjamin: -- this step will need to re-executed after package install but before the application is started
[09:20] <zbenjamin> the problem the script does not run as root since we connect with ssh
[09:20] <zbenjamin> and we install to the local click database
[09:21] <sarnold> ahhh.
[09:24] <zbenjamin> sarnold: gdbserver starts now, the app does not seem to come up and the ide does not connect ..
[09:26] <sarnold> zbenjamin: woo, nice, can you grep DENIED /var/log/syslog  and pastebin those? (the pastebinit program can help here)
[09:27] <zbenjamin> sarnold: http://pastebin.ubuntu.com/7520065/
[09:28] <zbenjamin> sarnold: but looking at the timestamps they are not related
[09:29] <sarnold> zbenjamin: some of them, indeed -- we shold probably file a bug or two for that, too
[09:31] <zbenjamin> sarnold: meh the time on the phone is not correct ;)
[09:31] <zbenjamin> sarnold: so they are related
[09:32] <sarnold> zbenjamin: the [ dddd ] bits ar enormally 'seconds after boot'..
[09:32] <zbenjamin> sarnold: i was able to connect from the gdb cli tool on the phone, but when i try to continue i get SIGTRAP'ed and then SIGABORT'ed
[09:32] <sarnold> zbenjamin: did you get any new DENIED lines from that?
[09:33] <zbenjamin> there are a few more http://pastebin.ubuntu.com/7520085/
[09:37] <sarnold> jjohansen: is this one of those LSM calls that happens before the usual kernel security mechanisms? apparmor="DENIED" operation="mknod" ... name="/usr/lib/python3.4/__pycache__/shlex.cpython-34.pyc.3063768112" pid=5862 comm="qtc_device_debu" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[09:42] <jjohansen> sarnold: yes
[09:48] <Laney> bdmurray: could you upload ubuntu-release-upgrader?
[09:49] <Laney> release upgrades are crashing with the bug you fixed in https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2808
[09:50] <bdmurray> Laney: will do
[09:50] <Laney> thanks!
[09:53] <sarnold> zbenjamin: https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+bug/1323233
[09:53] <ubottu> Launchpad bug 1323233 in click-apparmor (Ubuntu) "debug policy group" [Undecided,New]
[09:53] <zbenjamin> sarnold: fyi this is the debug script for the official ubuntu sdk ;)
[09:54] <zbenjamin> sarnold: i'm part of the SDK team
[09:54] <zbenjamin> sarnold: and this is part of RTM so we really need that
[09:55] <zbenjamin> sarnold: because currently we use a bunch of hacks to provide debugging mechanism which fall apart every other day. We really need to replace this with something sane
[09:55] <sarnold> zbenjamin: ah, I hadn't realized that was 'more official' :)
[09:55] <zbenjamin> sarnold: yeah sorry i should have mentioned that ;)
[09:56] <sarnold> zbenjamin: I just thought it was a nice script that'd been hacked together in desperation, hehe
[10:01] <zbenjamin> sarnold: basically it is ;). I wrote it at the last week on the sprint. There is also the sdk launcher now that takes a click package as a argument and installs , executes and uninstalls after the application finishes running
[10:02] <sarnold> zbenjamin: very nice
[10:05] <zbenjamin> sarnold: i can confirm tcp connect works at least for the qmldebugger. Now we "just" need the c++ side ;)
[10:06] <sarnold> zbenjamin: did you have to add anything to the apparmor policy to get the qmldebugger to work?
[10:07] <zbenjamin> sarnold: i just added your gdbserver line
[10:08] <sarnold> zbenjamin: was that necessary for the qmldebugger?
[10:08] <zbenjamin> i can try to remove it
[10:08] <bdmurray> pitti: libc6-dbg did not improve the crash files
[10:09] <pitti> bdmurray: ah, too bad; so the badness is in gdb itself then :/
[10:10] <pitti> xnox: lp:~upstart-devel/upstart/upstart-jobs doesn't yet have the init scripts from your unreviewed branch, but I guess that's expected
[10:11] <slangasek> bdmurray, pitti: are we sure about the integrity of the core files themselves?
[10:12] <pitti> slangasek: certainly not "sure", but I can't believe that we really get stack corruption on pretty much all the crashes, while they mostly work on x86
[10:12] <zbenjamin> sarnold: ok the line is not required. But the connection is slow, but that comes from qtc its waiting for some output from the app which it can not get of course
[10:13] <pitti> many that we looked at have two frames in libc (I suppose the usual "pass NULL pointer to string comparison" etc.), and then nothing else, just the "corrupted stack" error
[10:13] <pitti> slangasek: ^
[10:13] <slangasek> pitti: have we tried native backtracing with gdb on armhf?
[10:14] <slangasek> (to rule out whether it's a gdb vs. gdb-multiarch problem)
[10:15] <pitti> slangasek: that already was native, AFAIUI
[10:15] <pitti> slangasek: i. e. it's gdb running *on* the phone at the time of the crash
[10:15] <slangasek> mmm
[10:15] <pitti> slangasek: so we ruled out foreign arch problems
[10:16] <slangasek> does gdb get a useful backtrace if you attach it to a running process on armhf?
[10:16] <zbenjamin> sarnold: would be nice if you could change the bug report so its clear that this is more official ;)
[10:17] <zbenjamin> sarnold: or should i just  comment on it
[10:17] <sarnold> zbenjamin: I can fix it up some :)
[10:17] <zbenjamin> sarnold: awesome
[10:17] <pitti> slangasek: I don't know right now, that's an interesting test; although it needs to happen on something which is actually busy, otherwise we'll just catch some poll()/select(); bdmurray, did you happen to try that already?
[10:18] <GunnarHj> Hi pitti!
[10:19] <pitti> hey GunnarHj
[10:19] <GunnarHj> pitti: People are asking for langpack updates. Any chance that you can press the button?
[10:19] <GunnarHj> https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006507.html
[10:20] <pitti> GunnarHj: for trusty?
[10:20] <pitti> GunnarHj: I can copy the current PPA to -proposed, yes
[10:20] <GunnarHj> pitti: Yes.
[10:20] <GunnarHj> pitti: Would that be an SRU?
[10:20] <pitti> GunnarHj: yes, they've always been
[10:21] <GunnarHj> pitti: Ok, I keep learning. :)
[10:22] <pitti> GunnarHj: meh, https://launchpad.net/~ubuntu-langpack/+archive/ppa times out
[10:22] <pitti> GunnarHj: does this actually have recent trusty updates?
[10:23] <GunnarHj> pitti: Actually I haven't checked... Just saw the postings.
[10:23] <seb128> pitti,  language-pack-de 	1:14.04+20140522
[10:23] <seb128> one example
[10:24] <seb128> you can try reloading, it didn't timeout here
[10:24] <pitti> https://launchpad.net/~ubuntu-langpack/+archive/ppa?field.series_filter=trusty
[10:24] <pitti> ah, that looks fine
[10:24] <pitti> yeah, I'm fine with uploading that
[10:24] <bdmurray> pitti: no, I have not
[10:25] <pitti> GunnarHj: we need a wiki page where testers mark the tested languages; would you mind setting that up?
[10:25] <pitti> GunnarHj: I think we haven't actually done that (updates) for a long time :/
[10:25] <pitti> GunnarHj: ah, on https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
[10:27] <GunnarHj> pitti: Hmm.. I may take a look, but it will have to take a while.
[10:27] <pitti> GunnarHj: so it's just a new entry on above wiki page and sending a call for testing AFAICS
[10:28] <GunnarHj> pitti: Is the purpose of that page to document tests before SRUing translations?
[10:29] <pitti> GunnarHj: the purpose is that people run these standard tests (desktop comes up, you can run updat-emanager, etc.) for a particular language
[10:29] <pitti> GunnarHj: and after the timeout we release the languages which got tested
[10:30] <GunnarHj> pitti: I see. Have to quit now. Talk to you later.
[10:31] <zbenjamin> sarnold: any chance we can get that in in the next days?
[10:31] <sarnold> zbenjamin: could be, depends how much of jamie's time I can get :)
=== Ursinha is now known as Ursinha-afk
[10:54] <shadeslayer> ev: can usb-creator 0.2.57 be released for trusty too?
=== but_why is now known as lisca
=== _salem is now known as salem_
[11:34] <xnox> pitti: correct. Cause it's not in the archive yet.
=== Ursinha-afk is now known as Ursinha
[11:58] <pitti> xnox: http://paste.ubuntu.com/7520913/
[12:06] <xnox> pitti: ^
[12:07] <slangasek> seb128, pitti: is bug #1289031 assigned to the right component?
[12:07] <ubottu> bug 1289031 in gnome-settings-daemon (Ubuntu) "touchpad re-enables itself after suspend/resume" [Undecided,New] https://launchpad.net/bugs/1289031
[12:08] <seb128> slangasek, could be bug #1283863
[12:08] <ubottu> bug 1283863 in unity-settings-daemon (Ubuntu) "disabling touchpad is not persistent" [High,Confirmed] https://launchpad.net/bugs/1283863
[12:08] <seb128> but if you run unity, unity-settings-daemon is the right component
[12:08] <seb128> (well, assuming the issue is with the settings daemon, and not xorg/synaptic driver)
[12:08] <slangasek> right; I think I filed that bug before u-s-d was a separate thing
[12:10] <seb128> slangasek, if you can reproduce, it would be interesting to see if that happens as well when unity-settings-daemon is not running
[12:10] <slangasek> ok
[12:10] <slangasek> it's intermittently reproducible
[12:10] <seb128> :-/
[12:11] <slangasek> if I killall unity-settings-daemon, does it stay dead?
[12:11] <seb128> it's an upstart job, just stop it
[12:11]  * slangasek nods
[12:13] <dobey> seb128: hey, can you approve or whatever needs to be done to unity-scope-click to get it from u-proposed into the archive? seems it's held for migration as it added a dependency on ubuntu-sdk-libs
[12:18] <seb128> dobey, "unity-scope-click/arm64 unsatisfiable Depends: ubuntu-sdk-libs "
[12:19] <seb128> dobey, you need to make ubuntu-sdk-libs available on arm64, or to make unity-scope-click not build there (or not depends on the libs)
[12:19] <pitti> xnox: bug 1323274
[12:19] <ubottu> bug 1323274 in dovecot (Ubuntu) "Restore Debian's init.d script for insserv compatibility" [Undecided,New] https://launchpad.net/bugs/1323274
[12:20] <dobey> seb128: oh, ugh
[12:25] <tseliot> seb128: what are the plans on unity-settings-daemon? Are we going to rebase our changes on topo of the latest g-s-d? Also, where's the RCS?
[12:25] <tseliot> *top
[12:25] <seb128> tseliot, what is "RCS"?
[12:25] <pitti> revision control system?
[12:25] <tseliot> seb128: revision control system
[12:25] <seb128> oh, VCS?
[12:26] <seb128> lp:unity-settings-daemon
[12:26] <tseliot> yes
[12:26] <tseliot> sorry
[12:26] <tseliot> seb128: or is it a permanent fork that we should develop separately?
[12:26] <seb128> rebase ... we might, depends of how much work it is/the benefits/who has slots to work on that
[12:26] <seb128> it's a fork
[12:27] <seb128> but it doesn't mean we should backport commits that benefit us
[12:27] <seb128> or rebase on newer versions if it makes sense
[12:27] <tseliot> they fixed a lot of use cases for wacom tablets and touch screens
[12:27] <tseliot> that is why I'm asking
[12:27] <seb128> we are likely to update e.g the wacom code, not sure about the other plugins there
[12:27] <xnox> pitti: http://paste.ubuntu.com/7521117/
[12:27] <seb128> wacom needs to be updated in sync with the control center I think
[12:28] <tseliot> seb128: they introduced a new device mapper that requires a fair amount of work to backport and to hook into the plugins
[12:28] <seb128> in what cycle?
[12:28] <tseliot> I had a look at git master
[12:29] <tseliot> those are changes from 2013-2014
[12:32] <tseliot> seb128: g-s-d 3.12 includes all the fixes, except for one
[12:35] <dobey> seb128: can i make a binary dep be used on all archs except for arm64?
[12:35] <seb128> tseliot, I'm not sure we are going to update that this cycle, somebody owning wacom hardware and having slots to work on that working on updating that code would be nice
[12:36] <seb128> dobey, you need to list the archs manually
[12:36] <dobey> ogra_: hi. what's keeping ubuntu-touch-meta from being built on arm64?
[12:36] <dobey> seb128: but i can't do [!arm64] for binary deps?
[12:36] <ogra_>  no idea, doesnt it build ?
[12:37] <seb128> dobey, I don't think so
[12:37] <dobey> ogra_: i guess ubuntu-touch-meta has explicit archs listed. it's only built on i386, amd64, and armhf
[12:38] <dobey> ogra_: i'd expect it will build fine, but maybe all the binary deps don't build fine on arm64?
[12:38] <ogra_> ogra@styx:~/Devel/packages/ubuntu-touch-meta-1.141$ grep amd64 update.cfg
[12:38] <ogra_> architectures: i386 amd64 armhf
[12:38] <ogra_> right
[12:38] <tseliot> bdmurray: hi, can you have a look at LP: #1322212 please?
[12:38] <ubottu> Launchpad bug 1322212 in xorg-server-lts-saucy (Ubuntu) "Switching to the Guest session results in a black screen" [High,In progress] https://launchpad.net/bugs/1322212
[12:38] <ogra_> it is explicitly disabled atm ...
[12:39] <tseliot> seb128: ok, I'll see what I can do...
[12:39] <ogra_> dobey, why do you need it on arm64 ? and 64 bit phones in sight =
[12:39] <ogra_> ?
[12:39] <seb128> thanks
[12:39] <dobey> ogra_: is there a list of what's keeping it from being built elsewehre?
[12:40] <ogra_> dobey, it was never enabled on anything else but the three arches my grep above lists
[12:40] <sarnold> ogra_: apple sells one :)
[12:40] <ogra_> and i assume the seeds are set up similar
[12:40] <dobey> ogra_: because unity-scope-click is architectue: any in the control file, and we just added a binary dep on ubuntu-sdk-libs, because it is what provides the list of frameworks
[12:40] <ogra_> sarnold, oh, you are planning to purt ubuntu-touch to an iphone ?
[12:40] <ogra_> :P
[12:40] <ogra_> *port
[12:41] <sarnold> ogra_: wouldn't that be a fun target? :)
[12:41] <ogra_> doanac, hrm
[12:41] <ogra_> err
[12:41] <ogra_> dobey,
[12:41] <dobey> so right now this makes the scope uninstallable on arm64, though otherwise it builds and installs fine there
[12:42] <sarnold> it'd actually make more sense for us; apple sells content consuming devices. we've aiming for a converged computing device, and I haven't had < 4 gigs of memory on my computer in a very long time..
[12:44] <ogra_> dobey, hmm, i would actually prefer to have an override for the autopkgtest stuff in that case ... i suspect blindly enabling arm64 in the seeds and metapackages will open a big can of worms and cause a lot of extra work
[12:44] <ogra_> dobey, did you ask infinity or cjwatson if we could jet override it for now ?
[12:44] <bdmurray> tseliot: is that supposed to superceed the existing package in precise-proposed?
[12:44] <ogra_> s/jet/just/
[12:45] <dobey> ogra_: and just have an uninstallable unity-scope-click on arm64?
[12:45] <ogra_> dobey, right
[12:45] <ogra_> until we have actually seeds for that arch
[12:45] <dobey> i haven't asked, no.
[12:46] <tseliot> bdmurray: yes. I also included the previous changes in the diff
[12:46] <ogra_> switching the seeds on on this arch will likely mean we need to make the whole of ubuntu-touch ... or at least the whole of the sdk-libs installable in the end
[12:47] <ogra_> (or alternatively make the scope use [!arm64] but thats more ugly imho
[12:47] <dobey> ogra_: a good thing i think, but i do agree it might mean a lot of work. i wonder if there's an easy way we can test it
[12:47] <ogra_> )
[12:47] <dobey> well, it's ugly, but probably less ugly than a built package that can't be installed :)
[12:48] <bdmurray> tseliot: okay, could you add saucy tasks?
[12:48] <bdmurray> tseliot: I mean precise
[12:49] <tseliot> bdmurray: I think xorg-server-lts-saucy is only available in precise, isn't it?
[12:49] <cjwatson> ogra_: that's not autopkgtest
[12:50] <cjwatson> dobey: you can do [!arm64] in debian/control as long as it's not for an Architecture: all package
[12:50] <cjwatson> dobey: though in this context it would be more correct to do [amd64 armhf i386]
[12:51] <bdmurray> tseliot: While that may be true I'm pretty all the sru tools / reports want a task for the relevant release.
[12:51] <dobey> cjwatson: might be better to just not build on arm64 i guess, since unity8 isn't building there currently
[12:51] <cjwatson> well
[12:51] <cjwatson> let me check what rdeps are already there
[12:52] <dobey> well, it's depwait
[12:52] <cjwatson> but it built before?
[12:52] <dobey> i don't know
[12:52] <cjwatson> must've done
[12:52] <cjwatson> otherwise it wouldn't be a proble
[12:52] <cjwatson> m
[12:52] <cjwatson> ok, there are no reverse-dependencies of unity-scope-click/arm64
[12:52] <dobey> it shows depwait on trusty and saucy too
[12:52] <dobey> so i guess it's always been that way
[12:53] <cjwatson> no it doesn't
[12:53] <cjwatson>  unity-scope-click | 0.1+14.04.20140410.1-0ubuntu1 | trusty/universe          | source, amd64, arm64, armhf, i386
[12:53] <cjwatson> dobey: so, I can remove this, but you'll have to actually stop it building
[12:54] <ogra_> great :)
=== charles is now known as Guest9722
[12:56] <dobey> cjwatson: ok, that's great. i'll make a branch to stop it building on arm64. and you'll override it for now to get the current package migrated?
[12:56] <cjwatson> not override, but remove
[12:56] <cjwatson> (done)
[12:58] <cjwatson> I wouldn't just override this because adding uninstallable packages can make proposed-migration take bad decisions
[12:58] <ogra_> ah, i didnt know that
[13:00] <cjwatson> dobey: to be clear, if your branch doesn't land, the next upload will have the same problem :)
[13:00] <dobey> oh ok
[13:00] <dobey> cjwatson: yeah, i will make a branch now(-ish)
[13:01] <cjwatson> ta
[13:27] <tseliot> bdmurray: ok, let me fix that then
[13:28] <tseliot> yay, launchpad failed...
[13:35] <bdmurray> tseliot: hmm it oops'ed for me too. I'll just accept it then.
[13:40] <tseliot> bdmurray: good. I think we can add a task later
[13:46] <mterry_> stgraber, is there a bug for the lxc/kernel issue so I can subscribe?
[13:53] <mterry_> stgraber, ah I see you uploaded a fix.  But it still fails autopkgtest?
[13:56] <mterry_> But only two failures rather than three this time!  :)
[13:59] <tseliot> bdmurray: thanks
[14:04] <stgraber> mterry_: yeah, there's another kernel bug, jjohansen is on it
[14:05] <jjohansen> mterry_: if you revert to the 3.13 kernel from earlier, that should work until the 3.15 kernel with the fix lands
[14:07] <mterry_> jjohansen, I'm not concerned with testing it myself so much, it's just blocking a cgmanager update in utopic
[14:07] <jjohansen> mterry_: ah okay
[14:11] <Laney> woah
[14:11] <Laney> I've never noticed that quilt series colours patches based on applied/top/unapplied
[14:11] <Laney> is that new?
[14:12] <GunnarHj> pitti: still there?
[14:22] <ev> shadeslayer: if you want to go through the paperwork for an SRU, I'm happy to sponsor the upload
[14:22] <shadeslayer> ev: heh
[14:22] <shadeslayer> that's like the most annoying part of it :P
[14:22] <shadeslayer> ev: anyway, I'll file the paperwork
[14:23] <ev> :-P
[14:23] <ev> thanks!
[14:23] <shadeslayer> np
[14:23] <ev> I've got the branch queued up and ready for a bug number to inject
[14:25] <shadeslayer> ev: 1289026
[14:25] <ev> cheers
[14:26] <ev> shadeslayer: is that right? It's a regular bug not following the SRU format: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[14:26] <shadeslayer> ev: yes, I'm fixing that
[14:26] <ev> ah right
[14:26] <ev> I'll feed that into the branch
[14:27] <shadeslayer> ev: done
[14:28] <shadeslayer> ev: it's the bug that errors.ubuntu.com had linked to all the error reports
[14:28] <shadeslayer> thought I'd just repurpose it
[14:29] <ev> uploaded
[14:29] <shadeslayer> cheers
=== Ursinha is now known as Ursinha-afk
[19:32] <n4uah> hello..
[19:32] <n4uah> is anyone can help with the ubuntu touch?
[19:33] <rww> tried #ubuntu-touch?
[19:35] <n4uah> i think some of them works at canonical.
[19:35] <rww> Yep, and they also tend to hang out in #ubuntu-touch, hence me pointing you there. Have you tried it? :)
[19:36] <n4uah> no..
[19:36] <n4uah> now at their..
[19:36] <n4uah> :)
[21:02] <LLKCKfan> Hello
[21:02] <LLKCKfan>  How can someone who is almost 30 and never had a job get one? I have been applying just to be told I am not what they are looking for or they are not hiring.
[21:08] <Noskcaj_> LLKCKfan, I think you're asking in the wrong place
[21:08] <LLKCKfan> then what is the right place
[21:09] <genii> Probably some channel to do with employment
[21:36] <Noskcaj_> pitti, Is it ok if i merge flashplugin-nonfree-extrasound?
[21:37] <LLKCKfan> There are none
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_