[00:23]  * Laney gave in and restarted
[00:33] <pitti> Laney: oh noes, our test platform!
[00:33] <pitti> Laney: I got myself into the large swamp of cleaning up acpi-support
[00:33] <pitti> *cough* dust *cough*
[00:34] <slangasek> pitti: run away
[00:35] <pitti> slangasek: well, while I am at it I might as well throw out all the other cruft
[00:35] <slangasek> heh
[00:35] <pitti> it's just wasting cycles
[00:35] <slangasek> in acpi-support?
[00:35] <pitti> acpi_fakekey, oh these old times
[00:35] <slangasek> most of the stuff in acpi-support is still used
[00:35] <pitti> I'm dissecting the bits that are broken (like acpi_support), handled by g-s-d/KDE, or by logind and upower
[00:36] <slangasek> but it's used on particular hardware that we don't have, so we can't really check if it's redundant now with the kernel
[00:36] <pitti> well, but we do know that acpi_support doesn't work (and hasn't for years)
[00:36] <pitti> err, acpi_fakekey
[00:36] <slangasek> yes
[00:37] <slangasek> well, actually
[00:37] <pitti> and e. g. upower calls pm-powersave by itself, and logind suspends on lid close, etc.
[00:37] <slangasek> we know that it *usually* doesn't work
[00:37] <slangasek> it does work if the input device it injects the event on permits that keypress based on its mask!
[00:37] <slangasek> which is why I can't say categorically that it doesn't work and dropping the scripts won't regress
[00:37] <slangasek> but I guess we could sweep them up and say we no longer care
[00:38] <pitti> e. g. "sudo acpi_fakekey 113" (KEY_MUTE) doesn't do anything here
[00:38] <pitti> and my actual mute key works
[00:38] <slangasek> not on your hardware, but I'm betting it's not on your hardware that this is triggered
[00:38] <pitti> hm, so you want to keep this?
[00:38] <slangasek> I don't know ;)
[00:38] <slangasek> I'm just explaining my rationalization for why I haven't dropped it already
[00:39] <slangasek> because I'm not *sure* that dropping it is regression-free
[00:39] <slangasek> however, maybe at this point it's better to drop all acpi_fakekey, and deal with the regressions as they come in by finally fixing the kernel drivers as needed
[00:39] <Laney> that command works for me
[00:39] <pitti> (or the udev keymaps)
[00:40]  * slangasek nods
[00:41] <slangasek> pitti: scrapping acpi-support for logind handling of lid close sounds right, yes
[00:41] <pitti> at least udev has keymaps for some Toshiba models
[01:04] <wgrant> ajmitch: Could you do step 36 on https://wiki.ubuntu.com/NewReleaseCycleProcess?
[01:07] <ajmitch> wgrant: let me try & copy one forward
[01:10] <ajmitch> wgrant: can you tell me when the publisher run finishes so I can remove it?
[05:17] <Laney> pitti: /now/ (since I restarted) my laptop doesn't lock any more. :-)
[05:17] <Laney> so it's DE agnostic
[06:30] <TheMuso> wc
[07:48] <ion> Nice. Clicking on a link in release notes in the release upgrade thing opens a browser as root.
[10:29] <Daviey> cjwatson: Hey, could you moderate two emails i just sent to the TB please?
[11:25] <bdrung> whom should i talk to about the canonical partner archive?
[11:26] <bdrung> i found no contact information on the web
[11:31] <Daviey> bdrung: For most things, it's probably good idea to raise here.  slangasek is a good person, but there are other people aswell.
[11:32] <bdrung> the adobe-flashplugin is neither in raring, nor in saucy
[11:42] <davmor2> bdrung: I thought it was added to universe
[11:43] <bdrung> davmor2: flashplugin-installer is in multiverse for ages, but adobe-flashplugin comes from partner
[11:45] <davmor2> bdrung: hmmm maybe but it might of been dropped. As it is nolonger supported on linux, let me check with someone who should know
[11:49] <debfx> adobe still provides security updates for linux npapi flash
[11:50] <davmor2> bdrung: apparently no-one is entirely sure.  Double checking is in place and if it should be it will be as soon as possible.
[11:51] <bdrung> thanks
[12:07] <darkxst> debfx, except mozilla have absotutely no intention of supporting the npapi crap
[12:10] <ion> Err… what?
[12:11] <ion> I think it’s PPAPI that Mozilla doesn’t support.
[12:13] <darkxst> ah yes, got my aconyms mixed up
[12:20] <bdrung> the backport process seems to be complicated. why isn't it similar to the SRU process where every developer can upload a package?
[12:31] <debfx> bdrung: for no-change backports I don't see how the process would be easier when developers upload the package
[12:32] <debfx> launchpad probably doesn't generate meaningful diffs so it might be even more work
[12:33] <bdrung> hm, okay
[12:37] <debfx> is there something in particular you want to get backported?
[12:43] <geser> anyone familiar with autotools knows how to tell libtool to use g++ for linking? I suspect the ftbfs from https://launchpadlibrarian.net/138652517/buildlog_ubuntu-saucy-amd64.librevisa_0.0.20130412-1_FAILEDTOBUILD.txt.gz is due to using gcc instead of g++ for linking?
[12:49] <mlankhorst> geser: I'm guessing autotools is using file extension for linking, so if you want that you would need to make sure one of the extensions is .cc or .cxx somewhere
[12:51] <bdrung> debfx: yes, bug #1175133
[13:26] <cjwatson> Daviey: moderated
[13:29] <Daviey> cjwatson: thanks
[15:07] <bdrung> debfx: thanks. is there an overview page that shows which bugs needs attention from the backporters team (something similar to the sponsoring queue)?
[15:09]  * vibhav stares at gcc
[15:09] <geser> bdrung: is https://bugs.launchpad.net/~ubuntu-backporters good enough?
[15:10] <vibhav> Does anyone know why aufs-tools fails to build here: https://launchpadlibrarian.net/138833414/buildlog_ubuntu-saucy-i386.aufs-tools_1%3A3.0%2B20130111-3ubuntu1_FAILEDTOBUILD.txt.gz ?
[15:11] <vibhav> The build completes perfectly in raring, though
[15:11] <slangasek> when you stare into the compiler, Dennis Ritchie stares back at you
[15:11] <debfx> bdrung: yw. basically every open bug in the *-backports projects needs attention
[15:11] <vibhav> (apparently, the header uapi/linux/aufs_type.h is not found)
[15:11] <slangasek> vibhav: because the kernel has been revved in saucy, and has managed to break installation of a header maybe?
[15:12] <bdrung> how do you differentiate which package needs testing and which needs to get uploaded?
[15:14] <debfx> requests that lack testing should be set to incomplete
[15:15] <vibhav> slangasek: Probably.
[15:17] <bdrung> debfx: btw, what do you think about backporting vlc? see bug #1099003 for the request.
[15:17] <vibhav> slangasek: gcc says the error is somewhere at /usr/include/linux/aufs_type.h:19:34. The header is probably broken, then
[15:18] <jtaylor> it means the header does not exist, which is not unusual for linux headers, it needs to be updated to whatever is the interface now
[15:19]  * vibhav takes a look at the source
[15:21] <vibhav> Alright, the source (ver.c, to be precise) includes <linux/aufs_type.h>
[15:23] <vibhav> Strange, <linux/aufs_type.h> doesn't include anything aquainted with uapi
[15:23] <jtaylor> its best to check with upstream on these things
[15:23] <debfx> bdrung: does this require backporting vlc or opus or both?
[15:24] <bdrung> debfx: both. opus + enabling opus in vlc.
[15:25] <bdrung> it could be stripped down to opus + minimal patch for vlc (instead of taking the quantal version)
[15:27] <vibhav> Maybe I should preprocess the header and see if I can find anything relevant
[15:28] <debfx> bdrung: we still have bug #888665 but this should work as libopus doesn't exist in precise-release (not 100% sure though)
[15:29] <debfx> bdrung: backporting vlc should be fine as long as someone tests the rdepends of libvlc
[15:31] <jtaylor> vibhav: its probably better to just wait for the debian maintainer/upstream to fix it at this stage of saucy development
[15:32] <vibhav> jtaylor: I will try building the debian version of the package and see if it works
[15:32] <jtaylor> it won't
[15:32] <vibhav> The ubuntu delta was to fix an FTBFS caused to warn_unused_result, nothing related to the current FTBFS though
[15:32] <jtaylor> debian will unfreeze in a week or two and update their kernel too, then the debian package will be fixed too
[15:33] <vibhav> ah yes
[15:33]  * vibhav crosses fingers
[15:33] <jtaylor> you can already file a bug to notify the maintainer of the issue if there isn't one already
[15:33] <jtaylor> (if this change is not ubuntu specific)
[15:34] <vibhav> jtaylor: The package doesn't fail in debian
[15:34] <vibhav> Maybe it is the kernel, as slangasek pointed out
[15:35] <vibhav> jtaylor: btw, the last version was uploaded on 2012-06-29, which builds on all platforms
[15:35] <vibhav> It is the kernel
[15:38] <pitti> Laney: that's still gnome-screensaver, isn't it?
[15:41] <jtaylor> vibhav: there is a patch upstream
[15:43] <jtaylor> oh wait no I misinterpreted the error
[15:44] <vibhav> jtaylor: :D
[15:46] <pitti> dobey: actually, I can't upload the pygobject fix for bug 1173249 yet, as software-center hasn't been updated in saucy yet
[15:50] <Laney> pitti: indeed - I was just happy to be immune
[15:50] <Laney> but now I have to be broken along with everyone else :(
[15:54] <xnox> jodh: heya
[15:54] <dobey> pitti: the plan was to get it in raring and have it copied over to saucy
[15:56] <xnox> jodh: dget http://ppa.launchpad.net/xnox/backports/ubuntu/pool/main/u/upstart/upstart_1.8-0ubuntu2.dsc
[16:01] <Laney> dobey: pitti: we should upload the same s-c there
[16:01] <Laney> if it's blocking stuff
[16:04] <dobey> Laney: it hasn't even been accepted into raring-proposed yet, afaict; haven't gotten the "Accepted" e-mail at least, only "Waiting for approval"
[16:05] <Laney> correct
[16:05] <Laney> so what we can do is upload to saucy directly
[16:06] <dobey> but it has to be a different version number, or we'll have to re-upload to raring-proposed with a different version, no?
[16:06] <Laney> right
[16:06] <Laney> or, bug someone to accept the SRU now :-)
[16:07] <pitti> dobey: copying WFM, I can hold back the pygobject upload
[16:07] <pitti> dobey: right, it's in the queue still
[16:07] <dobey> Laney, pitti: since you're all at the sprint, can you all discuss it in person and do what you want with it?
[16:08] <Laney> speaking of the sprint
[16:08] <Laney> xnox: where you at?
[16:09] <dobey> since i am not at the sprint, and all
[16:13] <xnox> Laney: i'm in the kernel/phonedations/foundations room. last on the right "grand ballroom" i think.
[16:15] <geser> are you at some sprint/(non-virtual)UDS?
[16:16] <pitti> geser: yes, in Oakland (same hotel as last May's UDS)
[16:16] <pitti> sprint
[16:16] <geser> have fun then
[16:16] <pitti> thanks!
[16:16] <infinity> We won't. ;)
[16:19] <slangasek> infinity: HAVE. FUN.
[16:19] <vibhav> IMO, the word "sprint" really sounds fun
[16:19] <infinity> slangasek: YOU'RE NOT MY REAL DAD.
[16:19] <slangasek> vibhav: only if you never had them as a phone carrier
[16:20] <vibhav> slangasek: heh
[16:20] <vibhav> Believe me, phone carriers here are worse
[16:22] <dobey> slangasek: the great thing about sprint is, they aren't verizon or at&t.
[16:23] <dobey> actually, they were fine when i had them, aside from the fact that they aren't GSM, and the occasional attempts to sell me wireless data cards to replace my home internet connection with
[16:41] <ogra_> infinity, can you give me a headsup once i should be able to try to roll a saucy rootfs ? (/me wants to try a touch rootfs build today)
[16:42] <infinity> ogra_: Any time.
[16:43] <infinity> ogra_: If you mean locally, debootstrap has been fine for days, if you mean livefs builders, that was sorted this morning.
[16:43] <ogra_> ah, colin said you needed to update the livefs chroots
[16:43] <ogra_> great !
[16:45] <lamont> mountall and my fstabs hate each other it seems, in an iterative fails-to-boot- sort of way... <-- slangasek
[16:45] <lamont> when I have a chroot into which I'm mounting proc and dev/shm and such, what _should_ arg1 be?
[16:46] <slangasek> lamont: erm, give me your fstab and tell me which bits are failing
[16:46] <lamont> proc-buildd-raring caused mountall to get lost back in the lucid(?) timeframe, and apparently "none" is the new way to fail to boot
[16:46] <lamont> none /home/chroots/lamont/chroot-lucid-home/proc proc defaults 0 0
[16:47] <infinity> In my world, that should be 'proc-foo', not 'none', but I'm not sure why that would make mountall sad either.
[16:47] <lamont> under the right circumstances (don't ask for details, because I don't have them), that causes the machine to fail to boot, because mountall heads off into the tall grass to get lost.
[16:47] <lamont> infinity: ISTR somethign to do with $1 begining with an fstypename
[16:48] <lamont> there is a part of me that is considering just labeling it with a uuid
[16:48] <slangasek> lamont: do you get messages from mountall on plymouth?  (must use plymouth splash)
[16:49] <lamont> slangasek: data center machines, I tend not to see any console messages on them, because of distance.
[16:49] <slangasek> meh
[16:49] <slangasek> can you reproduce it in a local context?
[16:49] <lamont> I have not had that fortune.
[16:49] <lamont> -		addmount proc-$chrootname   $chrootdir/proc     proc       defaults 0  0
[16:49] <lamont> +		addmount none  $chrootdir/proc     proc       defaults 0  0
[16:50] <cjwatson> ogra_: I'll give an Ubuntu daily-live build a spin again and see what happens
[16:50] <lamont> was my last change, with the commit message:   mountall does not like the arg1s that we were putting in fstab
[16:50] <ogra_> cjwatson, great
[16:50] <ogra_> i will have to add touch to the livecd-rootfs config first anyway
[16:51] <ogra_> (and probably disable a ton of missing packages in the seeds)
[16:53] <slangasek> lamont: mountall expects that all virtual filesystems to be mounted before it will emit any other events related to other filesystems.  Is /home/chroots/lamont/chroot-lucid-home on the root filesystem?
[16:54] <lamont> in my personal case, generally not (/home is its own partition) on the DC boxes, it tends to be one big happy filesystem
[16:54] <slangasek> ogra_: disabling missing packages in the seeds> nack, we should be building the images using the available ppa
[16:55] <slangasek> lamont: in the case we're trying to debug a failure on?
[16:55] <ogra_> slangasek, that will require hackery to actually make live-build use PPAs
[16:55] <slangasek> ogra_: yes, which needs to be done
[16:55] <lamont> none /home/buildd/build-saucy-live/chroot-saucy/proc proc defaults 0 0
[16:55] <lamont> lrwxrwxrwx 1 root root 9 2012-08-07 15:41 /home -> /srv/home
[16:55] <ogra_> slangasek, i would like to first just get a tarball out, even if there are bits missing ...
[16:55] <lamont> and /srv/ is its own partition
[16:56] <slangasek> ogra_: that's not a useful milestone
[16:56] <ogra_> no, i dint plan to use it (or propose to anyone to use it)
[16:57] <lamont> ogra_: then why produce it.
[16:57] <ogra_> to make sure the right thing comes out at the rear end
[16:57] <lamont> my first question for any delivery is "what can I do with it?"
[16:58] <cjwatson> It isn't hard to make live-build use PPAs
[16:58] <slangasek> ogra_: the "right thing" requires the PPAs
[16:58] <Laney> dobey: software-center> I just test built it on saucy and it failed because of an enumeration in softwarecenter/distro/ubuntu.py
[16:58] <cjwatson> Shouldn't require any hackery
[16:58] <ogra_> we need to add PPA support we have missing packages etc .. i dont want to be held up by that when doing the initial implementation
[16:58] <Laney> ValueError: ("Could not find '%s' in ubuntu distro class please add it to DISTROSERIES", 'saucy')
[16:58] <cjwatson> It's a trivial livecd-rootfs-level change
[16:58] <Laney> seems suboptimal
[16:58] <slangasek> lamont: aha, symlinks in the path - thanks, I think that maps to a bug that's been filed
[16:58] <slangasek> checking
[16:58] <cjwatson> cf. the existing config/archives/ stuff there
[16:59] <ogra_> cjwatson, i know
[16:59] <cjwatson> Hell, tell me what PPA to use and I'll do it
[16:59] <ogra_> still i'd like to verify it wiorks
[16:59] <slangasek> so it's trivial - so do it, don't hack things OUT of seeds
[16:59] <cjwatson> Indeed, you can verify it just as well after the livecd-rootfs change
[17:02] <slangasek> lamont: ... isn't this bug #1096079, which you filed?
[17:02] <lamont> slangasek: not dangling, which was the case when /run came about
[17:02] <slangasek> ok
[17:03] <lamont> slangasek: having said all that, what would you like me to make $1 in those fstabs?
[17:03] <lamont> so that if it breaks I can say "but you told me to!!" ...
[17:03] <slangasek> lamont: I don't believe it has anything to do with the $1 now
[17:03] <slangasek> lamont: what I think you should do is not do chroot submount setup in /etc/fstab ;P
[17:04] <slangasek> lamont: but as I suppose you would like an actual bugfix for mountall so that it properly handles this case, please file a bug report against mountall with the fstab deets... I'm at a sprint right now so can't dedicate time today to look at it
[17:07] <lamont> slangasek: I'll see what I can do.  I'm somewhat hampered by not actually seeing the bug myself.
[17:07] <slangasek> lamont: well, if you can at least give me an /etc/fstab that reproduces it, I can try to find a reduced test case in there
[17:08] <lamont> yeah
[17:12] <ogra_> cjwatson, well, if you want to add the PPAs ... http://paste.ubuntu.com/5623284/ has the list of the ones used on the current raring builds
[17:13] <ogra_> they arent building saucy yet, but serguiens said he would switch them today
[17:14] <cjwatson> ogra_: OK; can you point me to the existing code that adds them?
[17:14] <cjwatson> ogra_: (in the jenkins builds)
[17:14] <cjwatson> Just for reference and in case I can get the sources.list.d file names to match up or whatever
[17:14] <ogra_> yeah, trying to get my hands on it ...
[17:17] <apw> doko, hey, i seem to have a gcc 4.8 bug in 'uninitialised variable' detection that i'd like to pass by you
[17:18] <apw> (to make sure it is actually broken)
[17:19] <slangasek> apw: is that why I have no linux-mako binaries? ;)
[17:19] <apw> slangasek, that is indeed :)  i have it 'worked around' and i am building the next upload as we speak
[17:19] <slangasek> ok
[17:19] <apw> slangasek, for reasons unknown it is .xz ... which is rather slow
[17:20] <slangasek> apw: hmm, but no; from the build log, the linux-mako failure is a signedness mismatch, not uninitialized variables...
[17:20] <apw> slangasek, there are 3 real bugs in there before that
[17:20] <slangasek> ok
[17:20] <slangasek> fwiw I don't see them when looking at the log
[17:20] <doko> apw, I don't see you in the kernel/engine room
[17:21] <apw> slangasek, i have fixed the correctly rejected code, and then got hung up by this final one, which i have incanted at, applied a chicken to it
[17:21] <ogra_> cjwatson, http://bazaar.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet/files/head:/customization/archives/
[17:21] <apw> doko, i'll pop round
[17:21] <slangasek> apw: righto
[17:21] <ogra_> cjwatson, fro https://code.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet obviously
[17:22] <ogra_> *from
[17:22] <cjwatson> ogra_: thanks
[17:23] <ogra_> cjwatson, assuming you do it in livecd-rootfs, http://paste.ubuntu.com/5623319/ has the general enablement for ubuntu-touch
[17:23] <cjwatson> Ah, I was just looking for that :)
[17:24] <ogra_> (we only need a tarball for the start_
[17:24] <ogra_> havent added that side yet
[17:26] <ev> mpt: do you still have that mock up of error reporting on the phone by any chance?
[17:27] <mpt> ev, https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone
[17:27] <mpt> ev, I need to copy that over to ErrorTracker
[17:27] <ev> mpt: you had done one for the actual error itself, if memory serves
[17:28] <mpt> oh, wait, it already is
[17:28] <ev> mpt: actually, you have :)
[17:28] <ev> I'm after the error has occurred mock up
[17:28] <jcastro> ev: hey did phased updates ever land for 13.04?
[17:28] <mpt> ev, we hadn't decided whether it should show a prompt at all
[17:29] <ev> mpt: we being you and I, or the design team? I'm all in favour of it not showing a prompt at all, given Apple and Google don't
[17:29] <ev> plus it makes my job easier and gives us more reports
[17:29] <ev> jcastro: we have the individual pieces, bdmurray is in the process of glueing them together
[17:29] <jcastro> ev: thanks!
[17:29] <mpt> ev, you and I
[17:30] <mpt> but yeah, no prompt seems reasonable
[17:30] <ev> jcastro: https://errors.ubuntu.com/api/1.0/package-version-new-buckets/?package=jockey&previous_version=0.9.7-0ubuntu7.7&new_version=0.9.7-0ubuntu7.8&format=json
[17:30] <ev> as one example
[17:30] <mpt> except in a developer mode or something
[17:30] <ev> mpt: woo, excellent
[17:30] <ev> now all we need is a working kernel
[17:30]  * ev shakes his fist at apw even though its not his fault
[17:31] <mpt> A working kernel? In our operating system? It's less likely than you think.
[17:31] <ev> lol
[17:31] <xnox> Laney: where are you?
[17:31] <Laney> 208
[17:31] <Laney> did you break it?
[17:32] <jcastro> ev: dude that is wicked
[17:33] <ev> jcastro: credit to bdmurray on that one, but yes it is
[17:33] <ev> jcastro: https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates#next is the result of our discussions this week
[17:34] <xnox> Laney: not sure where 208 is. But yeah. Original bug report was that from the indicator-session one clicks shutdown and nothing happens.
[17:35] <xnox> Laney: is indicator-session ported? Does that need an active logind session?
[17:35] <Laney> not in the archive yet
[17:35] <jcastro> ev: cool, someone asked why they weren't getting updates and I was wondering if it was normal -proposed delays or if you guys had flipped the switch.
[17:35] <Laney> but yes
[17:35] <ev> jcastro: *nods*
[17:40] <dobey> Laney: i guess it'll need a patch for that then
[17:40] <Laney> yep
[17:41] <xnox> slangasek: how do I start a pam session by-hand for ubiquity? simply use sudo in /etc/init/ubiquity.conf ?
[17:42] <Laney> dobey: are you aware of python-distro-info?
[17:42] <Laney> might be useful here
[17:45] <dobey> Laney: i didn't write that code, and i don't know how exactly the enumeration is used in the code, so i can't say what the best solution is. i have no idea why it does that :)
[17:46] <Laney> all the fun
[17:46] <dobey> Laney: but i have no issue with you adding a patch to add saucy to that list, to get it building
[17:47] <Laney> will you do it upstream?
[17:47] <dobey> yeah
[17:48] <dobey> in trunk, don't know about sticking it in the 5.6 branch
[17:49] <Laney> dobey: ok then, I'll do it
[17:49] <Laney> I'll just call it ubuntu4 to avoid having to futz around with raring-proposed
[17:50] <ogra_> oh, wow, seems apt-get install ubuntu-touch just works in a saucy chroot (it isnt supposed to) ... thats funny
[17:53] <Laney> pitti: since I'm uploading s-c to fix this FTBFS, you'll be able to go ahead with pygobject
[17:53] <pitti> Laney: ah nice; I'll wait until this is built
[17:53] <cjwatson> ogra_: So, um, ubuntu-build-phablet is already using live-build; is there any reason why I shouldn't just port all this stuff into livecd-rootfs wholesale?
[17:54] <ogra_> cjwatson, not really, its a different live-build version on jenkins though, i havent checked yet if there are discrepancies
[17:54] <cjwatson> ogra_: Merging into the general structure of livecd-rootfs' use of live-build, of course, but it looks like it's basically just option mangling and shipping a bunch of files
[17:54] <cjwatson> I'm happy to keep an eye out for the compatibility problems I know about :)
[17:54] <ogra_> cjwatson, well, there is post processeing needed to roll the update.zip in the end
[17:55] <cjwatson> live-build never really seems to stop being incompatible
[17:55] <ogra_> but i'm about to add that
[17:55] <ogra_> (similar to ac100/nexus7 post processing)
[17:55] <cjwatson> Add it in ubuntu-build-phablet, or in livecd-rootfs?
[17:55] <ogra_> livecd-rootfs
[17:55] <ogra_> in the build script
[17:56] <cjwatson> Right
[17:56] <ogra_> we will need http://bazaar.launchpad.net/~phablet-team/touch-preview-images/phablet-build-scripts/files (ubuntu-data ... which should really rather be "build-update.zip" or so)
[17:57] <ogra_> and treh META-INF dir
[17:57] <ogra_> i plan to add both to livecd-rootfs
[17:57] <ogra_> ubuntu-build-phablet is dead and will be removed ... it was for cross building the anroid trees
[17:59] <cjwatson> Er, ubuntu-build-phablet is a set of live-build configuration with all the stuff we need to put the right PPAs in place
[17:59] <Laney> pitti: dobey: done
[17:59] <cjwatson> I've just gone through all of it and didn't see anything that was related to cross-building Android
[18:00] <cjwatson> Perhaps you mean ubuntu-touch-android.sh?
[18:00] <xnox> stgraber: can you please rerun the cloud-init test against the same ppa? it has an updated package ... take #2 =)
[18:04] <dobey> Laney: thanks
[18:04] <Laney> no probs hombre
[18:05] <ogra_> cjwatson, oh, i thought you referred to ubuntu-touch-android.sh
[18:05] <ogra_> sorry
[18:11] <slangasek> xnox: yes, if you need to start a pam session you could do so calling 'su'.  Why do you need this?
[18:17] <xnox> slangasek: can I just call pam_start()? I am removing consolekit and replacing with logind, I have the option to start a pam session which will thus do things with pam_logind. Or I do similar to what we did with consolekit and calll logind1 dbus api call to CreateSession.
[18:18] <xnox> anyway, it can wait once we have daily-live saucy images.
[18:18] <xnox> to test if it works.
[18:24] <cjwatson> xnox: Can wait until about 25 minutes ago? :)
[18:25] <xnox> haha =)
[18:27] <cjwatson> Just re-enabled the cron jobs
[18:27] <xnox> Laney: saucy can be fetched from http://cdimage.ubuntulinux.org/daily-live/ instead of the fake conference mirror.
[18:27] <pitti> http://cdimage.ubuntu.com/daily-live/current/ still says raring for the most part
[18:27] <cjwatson> I fixed that already
[18:27] <cjwatson> And indeed beware of the conference mirror
[18:27] <pitti> ah, right
[18:28] <pitti> but anyway, great!
[18:28]  * pitti applauds cjwatson
[18:29] <slangasek> xnox: pam_start() doesn't give you a session, no.  You need to call pam_start() + pam_open_session(), and make sure you call pam_close_session() at the end, and you need to implement a pam_conv for your application given that you have no user interaction
[18:29] <slangasek> xnox: however if you're only concerned about this wrt logind, I think you should just make the dbus call directly
[18:29] <xnox> slangasek: hmm.... but i know it's passwordless account.
[18:29] <xnox> slangasek: ack. will look into logind dbus calls.
[18:30] <cjwatson> passwordless> you'd still need a dummy pam_conv to implement that
[18:30] <slangasek> xnox: any pam module is allowed to use pam_conv either to prompt the user or to send them messages
[18:30] <xnox> ah. I see.
[18:30] <slangasek> so you need to implement the pam_conv such that you discard all these appropriately, as I think the fallback behavior might be a segfault ;)
[18:30] <xnox> dbus sounds nicer than this then.
[18:30] <slangasek> anyway - I think pam is the wrong abstraction, es
[18:30] <slangasek> yes
[18:34] <Laney> "These calls should never be invoked directly by clients. Creating/closing sessions is exclusively the job of PAM and its pam_systemd module.
[18:34] <Laney> "
[18:39] <pitti> Laney: so for ubiquity, my gut feeling was that we mostly just need to rip out all the CK bits and make sure that libpam-systemd is installed; so apparenlty that's too simple?
[18:39] <Laney> Nothing creates the pam session
[18:40] <xnox> pitti: ubiquity upstart jobs, pre-empts lightdm / DM and spawns X, dbus, etc by itself / by-hand. Thus there is no session created.
[18:40] <Laney> it currently just calls CK's OpenSessionWithParameters
[18:40] <pitti> ah, so there is no "su -c UbiquityMagicCommand ubuntu" anywhere?
[18:40] <xnox> pitti: the only thing suspected to be broken is indicator-session which may not work to shutdown the machine.
[18:40] <xnox> pitti: there is for the ubiquity window, but not for the spawned indicators.
[18:41] <xnox> as far as I can tell.
[18:41] <pitti> as long as that doesn't rely on /dev ACLs, etc.
[18:46] <pitti> Laney: ah, so you didn't close the s-c bug with the upload; I thought there was some actual change that needs to be applied
[18:47] <Laney> pitti: which bug? the upload should close bug #1173249 when it migrates
[18:48] <pitti> Laney: right, but the s-c in the raring-proposed queue has some postinst change for this
[18:48] <Laney> an attempt to work around the dpkg bug, yes
[18:48] <Laney> the same change is in the saucy upload
[18:49] <pitti> oh, I see; it's two changelog entries
[18:49] <pitti> Laney: you didn't build with -v, so it won't autoclose
[18:49] <Laney> yeah I uploaded with -v
[18:49] <Laney> didn't I?
[18:49] <pitti> thanks for the heads-up
[18:49] <pitti> ah, then https://launchpad.net/ubuntu/+source/software-center/+changelog just doesn't reflect that
[18:49] <pitti> anyway, thanks!
[18:50] <Laney> I can't remember how to find the changesfile from LP's UI
[18:51] <pitti> nevermind
[18:51] <Laney> ah, got it
[18:51] <Laney> just got paranoid and wanted to check :-)
[18:53] <wgrant> pitti: https://bugs.launchpad.net/launchpad/+bug/144620
[18:54] <Laney> so if there's no author it's an indication that the uploader *did* use -V
[18:54] <wgrant> Laney: Yup
[19:00] <ahoneybun> ogra_: hello
[19:03] <ogra_> cjwatson, http://paste.ubuntu.com/5623567/
[19:08] <cjwatson> ogra_: the root cause there is "start: Job failed to start" in dbus - I think that's a matter of having forgotten to do the bits of setup involving creating a policy-rc.d script and diverting initctl before installing anything on top of bare debootstrap output
[19:09] <ogra_> oh, yeah, and i didnt mount /proc either
[19:09] <cjwatson> ogra_: the error that failed the livefs build is something entirely different - "Sorry: IndentationError: unindent does not match any outer indentation level (test_registry.py, line 608)"
[19:09] <ogra_> its a manual build ... mainly to see the deps
[19:09] <ogra_> wow
[19:09] <cjwatson> ogra_: that wouldn't be architecture-independent - I suspect it's yet another instance of the pandas randomly corrupting data
[19:10] <cjwatson> er, wouldn't be architecture-dependent, I mean
[19:10] <ogra_> yeah
[19:13] <slangasek> kenvandine: sho' nuff, it's *your* commit that regressed my window placement :-)
[19:14] <kenvandine> slangasek, you're welcome :)
[19:14] <kenvandine> slangasek, look at the commits to trunk from sam the same day
[19:14] <kenvandine> and the next
[19:16] <slangasek> kenvandine: ack
[19:16] <crhrabal> yeah today's daily build did not boot for me :(
[19:26] <cjwatson> crhrabal: The saucy one?
[19:26] <crhrabal> yeah
[19:26] <cjwatson> crhrabal: Which architecture?
[19:26] <crhrabal> amd64
[19:27] <cjwatson> crhrabal: I'll have a look, thanks.  It's the very first saucy daily build so may need a bit of tweaking
[19:27] <crhrabal> it's bizzare cause i'm currently running saucy and have had no problems and every single daily iso last cycle booted on this machine
[19:27] <cjwatson> I shouldn't expect it's anything too complicated
[19:34] <Laney> might be CK; here the live session boots but only-ubiquity does not
[19:34]  * Laney lunches
[19:34] <cjwatson> Yeah, quite possible, so just what xnox was working on
[19:36] <crhrabal> for me it gets to the plymouth screen that says ubuntu and it continues to load for about two minutes then black screen
[20:23] <lifeless> cjwatson: hey; another t-b message for moderation please ;)
[20:39] <Laney> lifeless: you ought to subscribe :P
[20:47] <cjwatson> lifeless: done
[20:53] <lifeless> cjwatson: thanks
[20:59] <cjwatson> ogra_: did you try a build, or shall I poke it now?
[21:00] <ogra_> cjwatson, i'm just getting the seeds in sync, lets wait until we have a new meta in place
[21:03] <cjwatson> OK
[21:03] <cjwatson> Oh and I guess we need the PPA copies
[21:07] <cjwatson> crhrabal: Having looked, I think Laney's diagnosis is right - the long pause and blank screen is a result of ubiquity-dm crashing early and then upstart eventually falling back to a failsafe job.  I think.
[21:08] <Laney> you could verify by installing consolekit and then restarting ubiquity-dm, assuming there's no useful traceback
[21:11] <pitti> stgraber: can we pick your brain about lxc?
[21:11] <pitti> stgraber: we tried to bind-mount the host's /run/udev into the container, but apparmor denies that; did you change anything in that regard on your machine?
[21:12] <cjwatson> Oh, there's a traceback in /var/log/upstart/ubiquity.log
[21:12] <Laney> cjwatson: yeah, /var/log/upstart/ubiquity-dm.log confirms it is this
[21:12] <Laney> snap
[21:12] <cjwatson> Which is indeed "CK, what CK"
[21:12] <Laney> except you had the filename right
[21:13] <Laney> looked from code inspection like this is what would happen, hence my grabbing of xnox this morning
[21:14] <ogra_> cjwatson, hmm, i doubt the meta will add alll the right bits when running teh update script atm since it doesnt know about the PPAs
[21:14]  * ogra_ just updated meta to saucy and is watching it ...
[21:17] <cjwatson> ogra_: easily fixable
[21:18] <cjwatson> At least I think archive_base/* can be a list or some other similar hack
[21:19] <ogra_> yeah, lets see how it comes out, at leats it finds some of the packages
[21:19] <ogra_> after all we want to get rid of the ppa
[21:19] <ogra_> s
[21:19] <cjwatson> Or you could just manually (or scriptedly) add them for the time being
[21:20] <ogra_> yeah
[21:20] <ogra_> germinate gives me a nice list of missing ones :)
[21:47] <mwhudson> GPU hang back in raring :()
[21:49] <RAOF> mwhudson: The one that should have been fixed by reverting a patch?
[21:49] <mwhudson> well
[21:50] <mwhudson> probably, but let's not jump to conclusions :)
[21:50] <mwhudson> it could be an exciting new bug!
[21:51] <mwhudson> hm, less stuff in syslog for this one
[21:51] <mwhudson> May  2 09:46:56 narsil kernel: [97584.880176] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[21:51] <mwhudson> May  2 09:46:56 narsil kernel: [97584.880181] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[21:51] <mwhudson> and that's it
[21:56] <mlankhorst> RAOF: did you hit any nouveau bugs yet?
[21:57] <RAOF> mlankhorst: In saucy, or in Mir?
[21:57] <RAOF> The answer's the same, though: no.
[21:57] <mlankhorst> lack of trying? :P
[21:57] <mlankhorst> +
[21:58] <mlankhorst> oops
[22:18] <pitti> stgraber: what would be an appropriate place to send patches for ltsp-cluster-accountmanager? (you are in AUTHORS)
[22:21] <ogra_> cjwatson, http://paste.ubuntu.com/5624172/
[22:22] <ogra_> pitti, discovering the wornderful world of LTSP ?
[22:22] <pitti> ogra_: porting it from CK to logind :)
[22:22] <ogra_> heh
[22:23]  * ogra_ wasnt aware anything in LTSP actually uses CK
[22:23] <ogra_> but then my last code contribution is probably 3 years  ago
[22:23] <pitti> ./src/bin/ltsp-cluster-accountmanager asks CK if a particular user has running sessions
[22:24] <ogra_> yeah, the cluster stuff is clearly stephanes child
[22:24] <ogra_> he is sitting on the table in front of me, should i throw mentos ?
[22:24] <pitti> ogra_: nah, it's not that urgent
[22:24] <ogra_> bah ... you are supposed to give me a reason :P
[22:24] <pitti> ogra_: wait -- you guys have Mentos!?
[22:25] <pitti> why don't we?
[22:25] <ogra_> well, these "starlight mint" things
[22:25] <pitti> oh, ok
[22:25] <ogra_> bah, missed him
[22:25] <stgraber> ;)
[22:25] <stgraber> pitti: anyway, yeah, I've got commit rights, so I'm happy to commit that stuff upstream
[22:26] <pitti> stgraber: so if I mail you the patch, is that ok? or is there a bug tracker?
[22:26] <pitti> Homepage: isn't very useful
[22:27] <ogra_> should be on lp
[22:27] <ogra_> (like all LTSP projects)
[22:27] <pitti> oh, convenient
[22:38] <pitti> stgraber: ok, https://code.launchpad.net/~pitti/ltsp-cluster/accountmanager-logind/+merge/161976
[22:39] <pitti> argh, wrong target branch
[22:40]  * Laney slaps sourceforge
[22:40] <Laney> "about 15 days ago we said, Instability on various parts of the site right now (500 errors). We're working on resolving this as soon as we can."
[22:40] <Laney> 15 DAYS!
[22:40] <pitti> stgraber: bug 1175371 (MP attached)
[22:40] <StevenK> Laney: Pft, I've been waiting on RedHat to fix their bugzilla for 5 months now
[22:42] <stgraber> pitti: thanks
[22:43] <Laney> StevenK: I can't browse or fork repos or view bugs when logged in
[22:43]  * Laney cuddles launchpad
[22:44] <StevenK> Watch out for those spiky bugs
[23:00] <GunnarHj> robert_ancell: Hi Robert!
[23:02] <RAOF> Laney, pitti: You don't mind if gnome-do waits until say tomorrow before supporting logind? I want to merge a bunch of branches and do a plugin release, so I might as well do that at the same time.
[23:03] <Laney> fine by me
[23:03]  * Laney is excited to see a new release
[23:03] <Laney> I'm still a user :-)
[23:07] <ogra_> cjwatson, ubuntu-touch with manual hackery uploaded and built ... once it migrated from proposed i guess we could trigger a test build
[23:19] <pitti> RAOF: absolutely, this isn't urgent
[23:20] <ogra_> sergiusens, i get a lot of 404's from the PPAs , seems apart from unity-next all others are not on saucy yet
[23:25] <StevenK> ogra_: PPAs need a package in the series before they grow indices for it
[23:25] <ogra_> StevenK, hmm, binary copy worked for the unity-next one apparently
[23:26] <StevenK> ogra_: Yes. It just needs *something* in saucy for it to have a saucy index
[23:26] <ogra_> ah, so that had it probably
[23:29] <ogra_> sergiusens, can we solve that somehow ?
[23:35] <sergiusens> ogra_: yeah, I'll do a bump for one of those for all those PPAs
[23:35] <sergiusens> I guess I should get didrocks to do it in the daily-build-next ppa
[23:35] <sergiusens> I'll do the others
[23:35] <ogra_> daily-build-next seems fine
[23:36] <sergiusens> ogra_: excellent
[23:36] <ogra_> err, nope, ignore that
[23:36] <ogra_> phablet-team is the one thats fine
[23:37] <sergiusens> ogra_: ack, it's the only one I did the copy to :-)
[23:38] <sergiusens> ogra_: in regaards to the list, you don't need the sdk ppa as it is already in daily-build-next too
[23:38] <ogra_> oh, good