[00:23] * Laney gave in and restarted [00:33] Laney: oh noes, our test platform! [00:33] Laney: I got myself into the large swamp of cleaning up acpi-support [00:33] *cough* dust *cough* [00:34] pitti: run away [00:35] slangasek: well, while I am at it I might as well throw out all the other cruft [00:35] heh [00:35] it's just wasting cycles [00:35] in acpi-support? [00:35] acpi_fakekey, oh these old times [00:35] most of the stuff in acpi-support is still used [00:35] I'm dissecting the bits that are broken (like acpi_support), handled by g-s-d/KDE, or by logind and upower [00:36] 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] well, but we do know that acpi_support doesn't work (and hasn't for years) [00:36] err, acpi_fakekey [00:36] yes [00:37] well, actually [00:37] and e. g. upower calls pm-powersave by itself, and logind suspends on lid close, etc. [00:37] we know that it *usually* doesn't work [00:37] it does work if the input device it injects the event on permits that keypress based on its mask! [00:37] which is why I can't say categorically that it doesn't work and dropping the scripts won't regress [00:37] but I guess we could sweep them up and say we no longer care [00:38] e. g. "sudo acpi_fakekey 113" (KEY_MUTE) doesn't do anything here [00:38] and my actual mute key works [00:38] not on your hardware, but I'm betting it's not on your hardware that this is triggered [00:38] hm, so you want to keep this? [00:38] I don't know ;) [00:38] I'm just explaining my rationalization for why I haven't dropped it already [00:39] because I'm not *sure* that dropping it is regression-free [00:39] 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] that command works for me [00:39] (or the udev keymaps) [00:40] * slangasek nods [00:41] pitti: scrapping acpi-support for logind handling of lid close sounds right, yes [00:41] at least udev has keymaps for some Toshiba models [01:04] ajmitch: Could you do step 36 on https://wiki.ubuntu.com/NewReleaseCycleProcess? [01:07] wgrant: let me try & copy one forward [01:10] wgrant: can you tell me when the publisher run finishes so I can remove it? === _salem is now known as salem_ === salem_ is now known as _salem === mhall119 is now known as mhall119|away === udienz_ is now known as udienz === Guest20326 is now known as vibhav === vibhav is now known as Guest73906 === Guest73906 is now known as vibhav_ [05:17] pitti: /now/ (since I restarted) my laptop doesn't lock any more. :-) [05:17] so it's DE agnostic [06:30] wc === vibhav_ is now known as vibhav [07:48] Nice. Clicking on a link in release notes in the release upgrade thing opens a browser as root. [10:29] cjwatson: Hey, could you moderate two emails i just sent to the TB please? [11:25] whom should i talk to about the canonical partner archive? [11:26] i found no contact information on the web [11:31] 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] the adobe-flashplugin is neither in raring, nor in saucy [11:42] bdrung: I thought it was added to universe [11:43] davmor2: flashplugin-installer is in multiverse for ages, but adobe-flashplugin comes from partner [11:45] 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] adobe still provides security updates for linux npapi flash [11:50] 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] thanks [12:07] debfx, except mozilla have absotutely no intention of supporting the npapi crap [12:10] Err… what? [12:11] I think it’s PPAPI that Mozilla doesn’t support. [12:13] ah yes, got my aconyms mixed up [12:20] the backport process seems to be complicated. why isn't it similar to the SRU process where every developer can upload a package? === tkamppeter_ is now known as tkamppeter [12:31] bdrung: for no-change backports I don't see how the process would be easier when developers upload the package [12:32] launchpad probably doesn't generate meaningful diffs so it might be even more work [12:33] hm, okay [12:37] is there something in particular you want to get backported? [12:43] 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] 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] debfx: yes, bug #1175133 [12:51] bug 1175133 in raring-backports "Please backport nemo 1.7.2-1 (universe) from saucy" [Undecided,New] https://launchpad.net/bugs/1175133 [13:26] Daviey: moderated [13:29] cjwatson: thanks === wedgwood_away is now known as wedgwood === kentb-out is now known as kentb === bladernr` is now known as bladernr === dosaboy_ is now known as dosaboy [15:07] debfx: thanks. is there an overview page that shows which bugs needs attention from the backporters team (something similar to the sponsoring queue)? === Ursinha is now known as Ursinha-afk [15:09] * vibhav stares at gcc [15:09] bdrung: is https://bugs.launchpad.net/~ubuntu-backporters good enough? [15:10] 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] The build completes perfectly in raring, though [15:11] when you stare into the compiler, Dennis Ritchie stares back at you [15:11] bdrung: yw. basically every open bug in the *-backports projects needs attention [15:11] (apparently, the header uapi/linux/aufs_type.h is not found) [15:11] vibhav: because the kernel has been revved in saucy, and has managed to break installation of a header maybe? [15:12] how do you differentiate which package needs testing and which needs to get uploaded? [15:14] requests that lack testing should be set to incomplete [15:15] slangasek: Probably. [15:17] debfx: btw, what do you think about backporting vlc? see bug #1099003 for the request. [15:17] bug 1099003 in vlc (Ubuntu) "VLC 2.0.5 won't work with Opus. Please include libopus0 from n-muench PPA" [Undecided,Won't fix] https://launchpad.net/bugs/1099003 [15:17] slangasek: gcc says the error is somewhere at /usr/include/linux/aufs_type.h:19:34. The header is probably broken, then [15:18] 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] Alright, the source (ver.c, to be precise) includes [15:23] Strange, doesn't include anything aquainted with uapi [15:23] its best to check with upstream on these things [15:23] bdrung: does this require backporting vlc or opus or both? [15:24] debfx: both. opus + enabling opus in vlc. [15:25] it could be stripped down to opus + minimal patch for vlc (instead of taking the quantal version) [15:27] Maybe I should preprocess the header and see if I can find anything relevant [15:28] bdrung: we still have bug #888665 but this should work as libopus doesn't exist in precise-release (not 100% sure though) [15:28] bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] https://launchpad.net/bugs/888665 [15:29] bdrung: backporting vlc should be fine as long as someone tests the rdepends of libvlc [15:31] vibhav: its probably better to just wait for the debian maintainer/upstream to fix it at this stage of saucy development [15:32] jtaylor: I will try building the debian version of the package and see if it works [15:32] it won't [15:32] The ubuntu delta was to fix an FTBFS caused to warn_unused_result, nothing related to the current FTBFS though [15:32] debian will unfreeze in a week or two and update their kernel too, then the debian package will be fixed too [15:33] ah yes [15:33] * vibhav crosses fingers [15:33] you can already file a bug to notify the maintainer of the issue if there isn't one already [15:33] (if this change is not ubuntu specific) [15:34] jtaylor: The package doesn't fail in debian [15:34] Maybe it is the kernel, as slangasek pointed out [15:35] jtaylor: btw, the last version was uploaded on 2012-06-29, which builds on all platforms [15:35] It is the kernel === Ursinha-afk is now known as Ursinha [15:38] Laney: that's still gnome-screensaver, isn't it? [15:41] vibhav: there is a patch upstream [15:43] oh wait no I misinterpreted the error [15:44] jtaylor: :D [15:46] dobey: actually, I can't upload the pygobject fix for bug 1173249 yet, as software-center hasn't been updated in saucy yet [15:46] bug 1173249 in pygobject (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Undecided,In progress] https://launchpad.net/bugs/1173249 [15:50] pitti: indeed - I was just happy to be immune [15:50] but now I have to be broken along with everyone else :( [15:54] jodh: heya [15:54] pitti: the plan was to get it in raring and have it copied over to saucy [15:56] jodh: dget http://ppa.launchpad.net/xnox/backports/ubuntu/pool/main/u/upstart/upstart_1.8-0ubuntu2.dsc [16:01] dobey: pitti: we should upload the same s-c there [16:01] if it's blocking stuff [16:04] 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] correct [16:05] so what we can do is upload to saucy directly [16:06] 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] right [16:06] or, bug someone to accept the SRU now :-) [16:07] dobey: copying WFM, I can hold back the pygobject upload [16:07] dobey: right, it's in the queue still [16:07] 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] speaking of the sprint [16:08] xnox: where you at? [16:09] since i am not at the sprint, and all [16:13] Laney: i'm in the kernel/phonedations/foundations room. last on the right "grand ballroom" i think. [16:15] are you at some sprint/(non-virtual)UDS? [16:16] geser: yes, in Oakland (same hotel as last May's UDS) [16:16] sprint [16:16] have fun then [16:16] thanks! [16:16] We won't. ;) [16:19] infinity: HAVE. FUN. [16:19] IMO, the word "sprint" really sounds fun [16:19] slangasek: YOU'RE NOT MY REAL DAD. [16:19] vibhav: only if you never had them as a phone carrier [16:20] slangasek: heh [16:20] Believe me, phone carriers here are worse [16:22] slangasek: the great thing about sprint is, they aren't verizon or at&t. [16:23] 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 === deryck is now known as deryck[lunch] [16:41] 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] ogra_: Any time. [16:43] ogra_: If you mean locally, debootstrap has been fine for days, if you mean livefs builders, that was sorted this morning. [16:43] ah, colin said you needed to update the livefs chroots [16:43] great ! [16:45] mountall and my fstabs hate each other it seems, in an iterative fails-to-boot- sort of way... <-- slangasek [16:45] when I have a chroot into which I'm mounting proc and dev/shm and such, what _should_ arg1 be? [16:46] lamont: erm, give me your fstab and tell me which bits are failing [16:46] 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] none /home/chroots/lamont/chroot-lucid-home/proc proc defaults 0 0 [16:47] In my world, that should be 'proc-foo', not 'none', but I'm not sure why that would make mountall sad either. [16:47] 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] infinity: ISTR somethign to do with $1 begining with an fstypename [16:48] there is a part of me that is considering just labeling it with a uuid [16:48] lamont: do you get messages from mountall on plymouth? (must use plymouth splash) [16:49] slangasek: data center machines, I tend not to see any console messages on them, because of distance. [16:49] meh [16:49] can you reproduce it in a local context? [16:49] I have not had that fortune. [16:49] - addmount proc-$chrootname $chrootdir/proc proc defaults 0 0 [16:49] + addmount none $chrootdir/proc proc defaults 0 0 [16:50] ogra_: I'll give an Ubuntu daily-live build a spin again and see what happens [16:50] was my last change, with the commit message: mountall does not like the arg1s that we were putting in fstab [16:50] cjwatson, great [16:50] i will have to add touch to the livecd-rootfs config first anyway [16:51] (and probably disable a ton of missing packages in the seeds) [16:53] 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] 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] ogra_: disabling missing packages in the seeds> nack, we should be building the images using the available ppa [16:55] lamont: in the case we're trying to debug a failure on? [16:55] slangasek, that will require hackery to actually make live-build use PPAs [16:55] ogra_: yes, which needs to be done [16:55] none /home/buildd/build-saucy-live/chroot-saucy/proc proc defaults 0 0 [16:55] lrwxrwxrwx 1 root root 9 2012-08-07 15:41 /home -> /srv/home [16:55] slangasek, i would like to first just get a tarball out, even if there are bits missing ... [16:55] and /srv/ is its own partition [16:56] ogra_: that's not a useful milestone [16:56] no, i dint plan to use it (or propose to anyone to use it) [16:57] ogra_: then why produce it. [16:57] to make sure the right thing comes out at the rear end [16:57] my first question for any delivery is "what can I do with it?" [16:58] It isn't hard to make live-build use PPAs [16:58] ogra_: the "right thing" requires the PPAs [16:58] dobey: software-center> I just test built it on saucy and it failed because of an enumeration in softwarecenter/distro/ubuntu.py [16:58] Shouldn't require any hackery [16:58] 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] ValueError: ("Could not find '%s' in ubuntu distro class please add it to DISTROSERIES", 'saucy') [16:58] It's a trivial livecd-rootfs-level change [16:58] seems suboptimal [16:58] lamont: aha, symlinks in the path - thanks, I think that maps to a bug that's been filed [16:58] checking [16:58] cf. the existing config/archives/ stuff there [16:59] cjwatson, i know [16:59] Hell, tell me what PPA to use and I'll do it [16:59] still i'd like to verify it wiorks [16:59] so it's trivial - so do it, don't hack things OUT of seeds [16:59] Indeed, you can verify it just as well after the livecd-rootfs change [17:02] lamont: ... isn't this bug #1096079, which you filed? [17:02] bug 1096079 in mountall (Ubuntu) "boot fails when a mount is a dangling symlink" [Low,New] https://launchpad.net/bugs/1096079 [17:02] slangasek: not dangling, which was the case when /run came about [17:02] ok [17:03] slangasek: having said all that, what would you like me to make $1 in those fstabs? [17:03] so that if it breaks I can say "but you told me to!!" ... [17:03] lamont: I don't believe it has anything to do with the $1 now [17:03] lamont: what I think you should do is not do chroot submount setup in /etc/fstab ;P [17:04] 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] slangasek: I'll see what I can do. I'm somewhat hampered by not actually seeing the bug myself. [17:07] 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] yeah [17:12] 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] they arent building saucy yet, but serguiens said he would switch them today [17:14] ogra_: OK; can you point me to the existing code that adds them? [17:14] ogra_: (in the jenkins builds) [17:14] Just for reference and in case I can get the sources.list.d file names to match up or whatever [17:14] yeah, trying to get my hands on it ... [17:17] 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] (to make sure it is actually broken) [17:19] apw: is that why I have no linux-mako binaries? ;) [17:19] slangasek, that is indeed :) i have it 'worked around' and i am building the next upload as we speak [17:19] ok [17:19] slangasek, for reasons unknown it is .xz ... which is rather slow [17:20] apw: hmm, but no; from the build log, the linux-mako failure is a signedness mismatch, not uninitialized variables... [17:20] slangasek, there are 3 real bugs in there before that [17:20] ok [17:20] fwiw I don't see them when looking at the log [17:20] apw, I don't see you in the kernel/engine room [17:21] 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] cjwatson, http://bazaar.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet/files/head:/customization/archives/ [17:21] doko, i'll pop round [17:21] apw: righto [17:21] cjwatson, fro https://code.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet obviously [17:22] *from [17:22] ogra_: thanks [17:23] cjwatson, assuming you do it in livecd-rootfs, http://paste.ubuntu.com/5623319/ has the general enablement for ubuntu-touch [17:23] Ah, I was just looking for that :) [17:24] (we only need a tarball for the start_ [17:24] havent added that side yet [17:26] mpt: do you still have that mock up of error reporting on the phone by any chance? [17:27] ev, https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone [17:27] ev, I need to copy that over to ErrorTracker [17:27] mpt: you had done one for the actual error itself, if memory serves [17:28] oh, wait, it already is [17:28] mpt: actually, you have :) [17:28] I'm after the error has occurred mock up [17:28] ev: hey did phased updates ever land for 13.04? [17:28] ev, we hadn't decided whether it should show a prompt at all [17:29] 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] plus it makes my job easier and gives us more reports [17:29] jcastro: we have the individual pieces, bdmurray is in the process of glueing them together [17:29] ev: thanks! [17:29] ev, you and I [17:30] but yeah, no prompt seems reasonable [17:30] 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] as one example [17:30] except in a developer mode or something [17:30] mpt: woo, excellent [17:30] now all we need is a working kernel [17:30] * ev shakes his fist at apw even though its not his fault [17:31] A working kernel? In our operating system? It's less likely than you think. [17:31] lol [17:31] Laney: where are you? [17:31] 208 [17:31] did you break it? [17:32] ev: dude that is wicked [17:33] jcastro: credit to bdmurray on that one, but yes it is [17:33] jcastro: https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates#next is the result of our discussions this week [17:34] 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] Laney: is indicator-session ported? Does that need an active logind session? [17:35] not in the archive yet [17:35] 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] but yes [17:35] jcastro: *nods* [17:40] Laney: i guess it'll need a patch for that then [17:40] yep [17:41] slangasek: how do I start a pam session by-hand for ubiquity? simply use sudo in /etc/init/ubiquity.conf ? [17:42] dobey: are you aware of python-distro-info? [17:42] might be useful here [17:45] 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] all the fun [17:46] Laney: but i have no issue with you adding a patch to add saucy to that list, to get it building [17:47] will you do it upstream? [17:47] yeah [17:48] in trunk, don't know about sticking it in the 5.6 branch [17:49] dobey: ok then, I'll do it [17:49] I'll just call it ubuntu4 to avoid having to futz around with raring-proposed [17:50] oh, wow, seems apt-get install ubuntu-touch just works in a saucy chroot (it isnt supposed to) ... thats funny [17:53] pitti: since I'm uploading s-c to fix this FTBFS, you'll be able to go ahead with pygobject === mchro- is now known as mchro [17:53] Laney: ah nice; I'll wait until this is built [17:53] 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] cjwatson, not really, its a different live-build version on jenkins though, i havent checked yet if there are discrepancies [17:54] 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 === iulian is now known as Guest55999 [17:54] I'm happy to keep an eye out for the compatibility problems I know about :) [17:54] cjwatson, well, there is post processeing needed to roll the update.zip in the end [17:55] live-build never really seems to stop being incompatible [17:55] but i'm about to add that [17:55] (similar to ac100/nexus7 post processing) [17:55] Add it in ubuntu-build-phablet, or in livecd-rootfs? [17:55] livecd-rootfs [17:55] in the build script [17:56] Right [17:56] 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] and treh META-INF dir [17:57] i plan to add both to livecd-rootfs [17:57] ubuntu-build-phablet is dead and will be removed ... it was for cross building the anroid trees [17:59] 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] pitti: dobey: done [17:59] I've just gone through all of it and didn't see anything that was related to cross-building Android [18:00] Perhaps you mean ubuntu-touch-android.sh? [18:00] stgraber: can you please rerun the cloud-init test against the same ppa? it has an updated package ... take #2 =) === deryck[lunch] is now known as deryck [18:04] Laney: thanks [18:04] no probs hombre [18:05] cjwatson, oh, i thought you referred to ubuntu-touch-android.sh [18:05] sorry === Guest55999 is now known as iulian [18:11] xnox: yes, if you need to start a pam session you could do so calling 'su'. Why do you need this? [18:17] 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] anyway, it can wait once we have daily-live saucy images. [18:18] to test if it works. [18:24] xnox: Can wait until about 25 minutes ago? :) [18:25] haha =) [18:27] Just re-enabled the cron jobs [18:27] Laney: saucy can be fetched from http://cdimage.ubuntulinux.org/daily-live/ instead of the fake conference mirror. [18:27] http://cdimage.ubuntu.com/daily-live/current/ still says raring for the most part [18:27] I fixed that already [18:27] And indeed beware of the conference mirror [18:27] ah, right [18:28] but anyway, great! [18:28] * pitti applauds cjwatson [18:29] 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] xnox: however if you're only concerned about this wrt logind, I think you should just make the dbus call directly [18:29] slangasek: hmm.... but i know it's passwordless account. [18:29] slangasek: ack. will look into logind dbus calls. [18:30] passwordless> you'd still need a dummy pam_conv to implement that [18:30] xnox: any pam module is allowed to use pam_conv either to prompt the user or to send them messages [18:30] ah. I see. [18:30] 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] dbus sounds nicer than this then. [18:30] anyway - I think pam is the wrong abstraction, es [18:30] yes [18:34] "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] " [18:39] 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] Nothing creates the pam session [18:40] 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] it currently just calls CK's OpenSessionWithParameters [18:40] ah, so there is no "su -c UbiquityMagicCommand ubuntu" anywhere? [18:40] pitti: the only thing suspected to be broken is indicator-session which may not work to shutdown the machine. [18:40] pitti: there is for the ubiquity window, but not for the spawned indicators. [18:41] as far as I can tell. [18:41] as long as that doesn't rely on /dev ACLs, etc. [18:46] 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] pitti: which bug? the upload should close bug #1173249 when it migrates [18:47] bug 1173249 in pygobject (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Undecided,In progress] https://launchpad.net/bugs/1173249 [18:48] Laney: right, but the s-c in the raring-proposed queue has some postinst change for this [18:48] an attempt to work around the dpkg bug, yes [18:48] the same change is in the saucy upload [18:49] oh, I see; it's two changelog entries [18:49] Laney: you didn't build with -v, so it won't autoclose [18:49] yeah I uploaded with -v [18:49] didn't I? [18:49] thanks for the heads-up [18:49] ah, then https://launchpad.net/ubuntu/+source/software-center/+changelog just doesn't reflect that [18:49] anyway, thanks! [18:50] I can't remember how to find the changesfile from LP's UI [18:51] nevermind [18:51] ah, got it [18:51] just got paranoid and wanted to check :-) [18:53] pitti: https://bugs.launchpad.net/launchpad/+bug/144620 [18:53] Launchpad bug 144620 in Launchpad itself "Some displayed sourcepackagerelease changes files don't have attribution" [High,Triaged] [18:54] so if there's no author it's an indication that the uploader *did* use -V [18:54] Laney: Yup [19:00] ogra_: hello [19:03] cjwatson, http://paste.ubuntu.com/5623567/ === sforshee` is now known as sforshee [19:08] 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] oh, yeah, and i didnt mount /proc either [19:09] 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] its a manual build ... mainly to see the deps [19:09] wow [19:09] ogra_: that wouldn't be architecture-independent - I suspect it's yet another instance of the pandas randomly corrupting data [19:10] er, wouldn't be architecture-dependent, I mean [19:10] yeah [19:13] kenvandine: sho' nuff, it's *your* commit that regressed my window placement :-) [19:14] slangasek, you're welcome :) [19:14] slangasek, look at the commits to trunk from sam the same day [19:14] and the next [19:16] kenvandine: ack [19:16] yeah today's daily build did not boot for me :( [19:26] crhrabal: The saucy one? [19:26] yeah [19:26] crhrabal: Which architecture? [19:26] amd64 [19:27] crhrabal: I'll have a look, thanks. It's the very first saucy daily build so may need a bit of tweaking [19:27] 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] I shouldn't expect it's anything too complicated [19:34] might be CK; here the live session boots but only-ubiquity does not [19:34] * Laney lunches [19:34] Yeah, quite possible, so just what xnox was working on [19:36] for me it gets to the plymouth screen that says ubuntu and it continues to load for about two minutes then black screen === Ursinha is now known as Ursinha-afk === popey_ is now known as popey [20:23] cjwatson: hey; another t-b message for moderation please ;) [20:39]