[00:00] <cjwatson> (It's still got the vestigial 'g' from the ELF transition.  A SONAME transition doesn't seem likely.)
[00:02] <infinity> cjwatson: An SONAME transition seems incredibly unlikely, but I've been itching to rename it "libz1" for a decade.
[00:04] <infinity> cjwatson: It just rubs me the wrong way that a library in the base system flies in the face of proper package naming policy. :P
[00:04] <infinity> (Though, entertainingly, it Provides: libz1)
[00:10] <smoser> ok. its that time again... smoser questions
[00:10] <smoser> previously i used debconf to prsed some data to cloud-init.
[00:11] <smoser> that allowed you to drive cloud-init configuration via preseeding
[00:11] <smoser> then http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709773 bug was opened, claiming i was using debconf as a registry
[00:11] <smoser> which, i guess iw as.
[00:11] <smoser> so i reverted that behavior.
[00:11] <smoser> but how, i can't do: chroot some-root < some-preseed && chroot some-root dpkg-reconfigure cloud-init
[00:12] <smoser> as the configured values get read over the ones in debconf.
[00:12] <smoser> which is i ugess the point.
[00:12] <cjwatson> Yes, the defined intention of debconf is that the filesystem wins
[00:13] <cjwatson> You'll have to adjust the configuration files, or clear the configuration such that the questions get reasked by cloud-init's postinst
[00:13] <smoser> ok. i can do that. thanks, cjwatson.
[00:17] <smoser> cjwatson, is there a standard way for "clear the configuration"?
[00:17] <smoser> what does ubilquity do for any thing that it collects that would change values of an already installed package?
[00:17] <smoser> or are there just no such things.
[00:18] <smoser> basically i'm wanting to let someone spit debconf-selections into a cloud-image and then re-set the settings of installed packages from those settings.
[00:18] <smoser> and let anything to-be-installed just happen at that point
[00:18] <cjwatson> ubiquity has a few "nuke config file from orbit and reconfigure" bits.
[00:19] <cjwatson> It's not standardised.
[00:19] <cjwatson> http://paste.ubuntu.com/6152484/
[00:19] <cjwatson> that kind of thing
[00:19] <smoser> you rock. thanks.
[00:19] <cjwatson> usually it's nice if removing the config file does the trick
[00:25] <leo_33> in your opinion are the jews responsible for most of the evil in the world?
[00:26] <infinity> That was a quick response.
[03:39] <mwhudson> um
[03:39] <mwhudson> warning: the debug information found in "/usr/lib/debug//usr/bin/memcached" does not match "/usr/bin/memcached" (CRC mismatch).
[03:39] <mwhudson> i have memcached and memcached-dbgsym (of the same versions) installed
[03:39] <mwhudson> and get that ^
[03:40] <mwhudson> (on armhf)
[03:40] <mwhudson> problem at my end or in the archive?
[04:07] <sarnold> mwhudson: my pandaboard rarely gives me the same data off disk twice. heh. can you check debsums?
[04:56] <int_ua> 1. The link to channels is kind-of wrong on http://www.ubuntu.com/support/community/chat It should lead to https://wiki.ubuntu.com/IRC/ChannelList
[04:57] <int_ua> 2. https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1170487 Is fixed upstream but needs a release. It prevents _all_hooks from running and the resulting bug reports end up missing crucial files.
[05:00] <int_ua> anyone home?
[05:00] <sarnold> int_ua: probably "fix committed" is the wrong status; that means the fixed _package_ has been checked in and waiting to be released ...
[05:00] <int_ua> sarnold, changed
[05:03] <sarnold> int_ua: aha, here we go, the best place to report #1: https://bugs.launchpad.net/ubuntu-website-content/+filebug
[05:04] <int_ua> sarnold, thanks, In Progress :)
[05:05] <sarnold> int_ua: woot, thanks :)
[05:06] <int_ua> sarnold, https://bugs.launchpad.net/ubuntu-website-content/+bug/1230072
[05:07] <sarnold> int_ua: very nice, thanks
[05:16] <pitti> Good morning
[05:18] <pitti> Laney: so we need to modify whatever builds those images to include the directory, and declare it writable?
[05:33] <pitti> wgrant, StevenK: hmm, still no new -base export at https://translations.launchpad.net/ubuntu/saucy/+language-packs ?
[05:33] <pitti> I requested one last week for final beta, but I guess it's too late now
[05:37] <wgrant> pitti: Might have failed during some of the DB maintenance last week.
[07:01] <dholbach> good morning
[07:48] <xnox> doko_: re: libvigraimpex, ok will look at it.
[08:03] <Laney> pitti: Yeah, I guess livecd-rootfs for the former (as stgraber said; ogra_ is the master of that package) and lxc-android-config etc/system-image/writable-paths for the latter
[08:04] <Laney> for testing you can edit writable-paths on your system
[08:05] <ogra_> LOL
[08:05] <ogra_> i'm surely not the master :)
[08:05]  * Laney looks at the changelog :P
[08:05] <ogra_> i just change it more often than others i guess
[08:06]  * ogra_ tries to find out what this is about after all :)
[08:07] <ogra_> pitti, make merge proposals for both packages /or bugs with debdiff or whatever) ... then ping me so i can add a request to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 (unless you can edit yourself, then just add it on "landing asks" and assign me)
[08:10] <alberts> xnox: hi! could you please look at these merge proposals - https://code.launchpad.net/~attente/ubuntu-themes/lp1228809/+merge/186967 and https://code.launchpad.net/~attente/ubuntu-themes/lp1228814/+merge/187024?
[08:12] <xnox> alberts: approved. They should get auto-merged, if not I'll merge them myself.
[08:12] <alberts> xnox: thanks!
[08:17] <pmjdebru1jn> hi folks
[08:18] <pmjdebru1jn> I noticed saucy's libc is built with gcc 4.7.x while most of the rest is built with 4.8.x, anybody a clue why?
[08:18] <pmjdebru1jn> I aware it shouldn't matter much technically... but I found it rather peculiar
[08:44] <pitti> Laney, ogra_, stgraber: I tried to understand the details and followed up on bug 1227520; there's one thing which isn't clear to me yet
[08:49] <cjwatson> pmjdebru1jn: 18:24 <infinity> cjwatson: I wouldn't stress it too much, I'm not moving eglibc to 4.8 in this cycle.  Shows testsuite regressions I don't have the time to fix before release.
[08:49] <cjwatson> pmjdebru1jn: A few particularly sensitive packages need to be upgraded to new compiler versions rather carefully.  Boot loaders are often in that category too.
[08:54] <Laney> pitti: replied
[08:55] <pitti> Laney: thanks; and yes, /etc/writable/zoneinfo == /etc/writable/localtime
[08:55]  * Laney nods
[09:01] <pmjdebru1jn> cjwatson: ok fair enough
[09:01] <pmjdebru1jn> cjwatson: so I guess saucy will be half-way to the next LTS can be full 4.8 I guess?
[09:01] <pmjdebru1jn> /to/so/
[09:02] <cjwatson> pmjdebru1jn: I don't know that I'd put it that way.  Firstly, we're a lot more than halfway; secondly, we're in a more or less continual process of upgrading to newer versions of things like this.
[09:03] <pmjdebru1jn> oh? there no attempt to get this stuff in a consistent state?
[09:04] <pmjdebru1jn> it's not the end of the world of course, particularly for C
[09:05] <cjwatson> pmjdebru1jn: We try to avoid having to support more compiler versions than we need to, but consistency in itself isn't always the highest goal
[09:05] <pmjdebru1jn> right
[09:06] <pmjdebru1jn> just out of curiousity are there thing in gcc 4.8, that make it important to move to it as quickly as possible?
[09:06] <pmjdebru1jn> besides getting stuff done ahead of the next LTS
[09:07] <cjwatson> There are always improvements, but I don't think there was anything earth-shatteringly out of the ordinary
[09:07] <cjwatson> http://gcc.gnu.org/gcc-4.8/changes.html if you're interested
[09:07] <cjwatson> Of course, most packages just use the default compiler version to build.
[09:09] <pmjdebru1jn> ah I see lots of C++ related improvements
[09:09] <pmjdebru1jn> right
[09:09] <pmjdebru1jn> ok, thanks
[09:22] <ogra_> pitti, hmm, i'll better leave that to stgraber, thats actully his domain
[09:23] <alberts> xnox: that two merge proposals for ubuntu-themes still shows status - needs review
[09:24] <xnox> alberts: yeah, I'm expecting for the upstream bot to merge. If that doesn't happen by the end of the day, I'll merge them by hand.
[09:27] <Laney> they won't merge if they're at needs review
[09:27] <Laney> you need to change the top status
[09:27] <Laney> xnox:
[09:27] <xnox> ... to what?
[09:27] <Laney> Approved
[09:27] <xnox> hm, ok. let me do that.
[09:39] <pitti> ogra_, Laney: hm, seems once /etc/timezone and friends ever went into writable-paths, they stay writable even if I drop them and reboot (with r/o)
[09:40] <ogra_> pitti, yeah, there should be bind mounts into the writable space
[09:40] <pitti> so I guess to truly test this we need to get these two changes into a new image so that /etc/timezone really stays r/o
[09:40] <pitti> ogra_: that's the thing, there aren't any more
[09:41] <pitti> actually, it's more general
[09:41] <pitti> I can even create /foo now
[09:41] <pitti> so it seems even after removing /userdata/.writable_image and rebooting, the image still stays writable
[09:41] <Laney> hm, that worked to make it ro for me
[09:42] <ogra_> pitti, if you made any changes it will
[09:43] <ogra_> (in the readonly space)
[09:43] <pitti> ogra_: ah, is there a trick to make it r/o again?
[09:43] <ogra_> afaik it is  not possible
[09:43] <pitti> ogra_: ok, then I suggest we get these two changes in ASAP?
[09:43] <ogra_> pitti, so the last changes dont help because ?
[09:44] <pitti> in the meantime I'll work on timedated and just watch strace to make sure it doesn't try and touch /etc/* directly
[09:44]  * ogra_ just uploaded a change for exactly these files on mon or tue
[09:44] <pitti> ogra_: they do help, it just seems hard to apply them manually
[09:44] <pitti> ogra_: I meant the changes I just psuhed to the branches, but not uploaded yet (see bug)
[09:44] <ogra_> well, i think cwayne had a plan to work around debconf and stuff
[09:45] <pitti> ogra_: nope, making /etc/timezone and friends bind mounts doesn't work
[09:45] <ogra_> from the timezone settings
[09:45] <ogra_> well, he tested it before requesting inclusion
[09:45] <ogra_> at least he claimed to
[09:45] <pitti> ogra_: well, they become writable, but that's not the point
[09:45] <pitti> the point is with mounts it's impossible to atomically change a file
[09:45] <ogra_> they become writable and get contet changes via the new settings app is what i was told
[09:46] <pitti> and hence that "mount points over files" approach is an utter hack which we shouldn't use for many files
[09:46] <ogra_> by copying the timzone data in
[09:46] <pitti> ogra_: yes, but I am not going to do that in timedated
[09:46] <pitti> ogra_: Laney and stgraber discussed a better approach in the bug with symlinks
[09:46] <ogra_> could you coordinate with cwayne ?
[09:47] <ogra_> i kknow there are people tryning to implement it differently atm
[09:47] <pitti> ogra_: system-settings is fine, it just talks to timedated; and I got the task assigned from Laney to update that
[09:47] <Laney> I was talking with cwayne when we discovered the problem
[09:47] <pitti> ogra_: but yes, I can ping him this afternoon about this
[09:48] <pitti> subscribed him to bug 1227520, too
[09:49] <ogra_> pitti, https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone was merged for it already ...
[09:49] <ogra_> there was a second one i'm just trying to find
[09:49] <pitti> ogra_: yes, I reverted that and pushed the new approach
[09:50] <ogra_> how did you revert it ? i dont see it on the landing requests
[09:50] <pitti> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/revision/102
[09:50] <pitti> goes together with http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/848
[09:50] <ogra_> https://code.launchpad.net/~cwayne18/phablet-tools/phablet-timezone-setup/+merge/186891 is the second one
[09:50] <pitti> (I didn't upload these yet, as I asked for eyeballing on the bug)
[09:51] <ogra_> pitti, please coordinate through the spreadsheet else we have a mess ...
[09:51] <cjwatson> ogra_: https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone isn't recorded as merged, and my comments on it weren't entirely addressed so it shouldn't have been ...
[09:51] <ogra_> we cant land anything without asac approval though the new process
[09:51] <cjwatson> (my comments line up with what pitti is working on)
[09:51] <pitti> ogra_: I can't change the spreadsheet
[09:52] <ogra_> cjwatson, it says Merged at the top ... and i'm sure there is an entry for it on the spreadsheet
[09:52] <pitti> ogra_: from my POV, I got that bug assigned, and all info is there now
[09:52] <ogra_> (line 81 on landing asks)
[09:52] <cjwatson> ogra_: No, https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone/+merge/186953 says "Needs review" at the top
[09:52] <Laney> it sure did get merged
[09:53] <cjwatson> Sigh
[09:53] <ogra_> pitti, right, either reqest write access from asac in #ubuntu-ci-eng or go through your manager
[09:53] <cjwatson> Why do I bother with review comments, I wonder
[09:53] <Laney> not uploaded though? does it need to be?
[09:53] <cjwatson> Since one of my review comments was explicitly that this was a bad idea to merge because it would create upgrade trouble
[09:53] <Laney> oh, no, it was uploaded :(
[09:53] <ogra_> cjwatson, it landed (with typo fix) on tuesday i think, no reason we cant roll it back indeed
[09:54] <cjwatson> ogra_: My understanding is that persistent mounts can't be undone without wiping user data
[09:54] <ogra_> cjwatson, yeah ... we dont really have transitioning of that yet on upgrades
[09:54] <cjwatson> But I am pretty annoyed if this was landed despite our comments saying it shouldn't be
[09:55] <cjwatson> If all our tremendous complexity around touch landings doesn't avoid landings that have had negative reviews, what good is it?
[09:55] <ogra_> there was no such comment  when i reviewed it, and the people asking for it claimed they had run all tests with the new implementation which was the merge criteria
[09:56] <ogra_> cjwatson, it all only revolves around the tests ...
[09:56] <pitti> well, obviously they didn't, as timedated (which system-settings seems to use) is unable to atomically update these files
[09:56] <cjwatson> ogra_: I commented on that MP almost as soon as cwayne posted it, and he made the typo correction in response to my review
[09:56] <cjwatson> ogra_: So I don't believe you :-)
[09:56] <ogra_> pitti, they use it at flashing time, see the second commit to phablet-tools above
[09:56] <Laney> pitti: I guess cwayne was thinking in terms of his script and not u-s-s
[09:57] <cjwatson> If the upload includes the typo correction, as you said above that it did, then it was strictly after my review
[09:57] <pitti> well, as long as adb push resolves symlinks on write, so that it will actualy write /etc/writable/timezone (and friends), it should be okay
[09:57] <ogra_> cjwatson, there were no comments at all when i merged it ... whats intresting though is that the MP was never set to Merged even though the branch landed
[09:58] <ogra_> (i probably didnt reload the MP before merging though)
[09:58] <cjwatson> ogra_: There was also extensive and noisy discussion on #ubuntu-touch at the time :-(
[09:59] <cjwatson> I'm sorry, I think our merge criteria aren't fit for purpose if they don't notice this kind of thing.
[10:00] <ogra_> "at that time" can you specify that ?
[10:00] <ogra_> https://launchpad.net/ubuntu/saucy/+source/lxc-android-config/0.101
[10:00] <ogra_> the upload happened on monday
[10:00] <ogra_> and i think the discussions happened a lot later
[10:01] <Laney> it was Monday late afternoon UK time
[10:01] <cjwatson> ogra_: It was strictly before that upload
[10:01] <cjwatson> http://irclogs.ubuntu.com/2013/09/23/%23ubuntu-touch.html#t15:32 e.g.
[10:01]  * ogra_ must have missed it then
[10:02] <Laney> I think that I told cwayne during the discussion to make that change though, before my understanding had fully developed
[10:02] <Laney> And then never explicitly revisited it
[10:03] <ogra_> well, it is in and we will just roll it back ...
[10:03] <ogra_> its a three line change
[10:03] <ogra_> (or uppdate it to something else)
[10:03] <pitti> the update I pushed removes those and adds /etc/writable/
[10:04] <pitti> which is supposed to be that place where we can do double symlinks or just files which we need to atomically rename
[10:04] <pitti> (probably won't work with conffiles, so we sohuldn't use it for those)
[10:04] <ogra_> right, i would like to hear from stgraber about that first though
[10:04] <ogra_> (and its not on the landing plan at all)
[10:05] <pitti> ogra_: stgraber responded yesterday in teh bug how to do these changes
[10:05] <ogra_> pitti, conffiles ? why to dou care ?
[10:06] <ogra_> we dont officially support apt updates
[10:06] <pitti> ogra_: I'm not sure dpkg would DTRT with conffiles which have been set up as symlinks
[10:06] <pitti> still, I would ban conffiles from that approach for now
[10:06] <ogra_> at image build time you mean ?
[10:06] <pitti> ogra_: for symlinking/moving to /etc/writable/
[10:07] <pitti> I'm fairly sure that dpkg will update conffiles atomically as well, so we cannot currently handle them anyway
[10:07] <ogra_> ??
[10:07] <cjwatson> Yes, best avoided since many of our testing tools still use apt even on writable images
[10:07] <ogra_> we dont allow dpkg
[10:07] <cjwatson> Er, even on RO images
[10:07] <pitti> but my hope is still that all those hackery will go away with a proper overlayfs
[10:07] <cjwatson> (after mounting RW, obviously)
[10:07] <ogra_> pitti, wonr happen
[10:08] <ogra_> *wont
[10:08] <pitti> ogra_: well, like this a converged image won't happen :)
[10:08] <ogra_> yeah, converged might be different
[10:09] <ogra_> but converged isnt on topic before 14.10 i was told
[10:09] <pitti> sure, I didn't say "tomorrow"
[10:09] <ogra_> and i dont think we want to maintian tons of patches for tons of different android kernels
[10:09] <pitti> anyway, so what are the next steps now?
[10:09] <ogra_> adding it to the spreadsheet
[10:10] <pitti> so apparently someone needs to update that gdocs to include these two commits, and ack getting them in?
[10:10] <pitti> I'll work on timedated in the meantime
[10:10] <ogra_> both changes should be fine for bypassing the beta freeze, only touch related changes/packages involved
[10:11] <ogra_> pitti, the comment from stgraber on the bog doesnt sound like agreement to me
[10:12] <pitti> well, I haven't heard any other solution yet
[10:12] <pitti> (and I mean "solution", not "let's knowingly introduce race conditions and crashes")
[10:13] <Laney> having this feature working is something that people constantly ask for, so we need to not be infinitely blocking it
[10:14] <ogra_> Laney, no, but stgraber is respponsible for the rw stuff, i would like to see him agree to the change
[10:15] <Laney> http://irclogs.ubuntu.com/2013/09/24/#ubuntu-devel.html#t14:35
[10:17] <Laney> Anyway, review is fine but I think everyone is agreed on the approach being sound
[10:17] <Laney> modulo whatever now happens on upgrades due to that borked upload
[10:18] <pitti> I suppose upgrades will continue to have a mounted /etc/localtime
[10:18] <pitti> and thus won't be able to change the tz
[10:18] <pitti> so you need to phablet-flash ubuntu-system -b, I suppose
[10:18] <Laney> was it in a 'blessed' image?
[10:18] <pitti> (-b works, I just re-flashed after my first experiments)
[10:19] <pitti> Laney: yes, I think so; I didn't chose anything exprerimental, and my flash from this morning got it
[10:19] <Laney> bah, ok
[10:23] <ogra_> you wont need -b
[10:23] <ogra_> -b only flashes the recovery partition separately ...
[10:24] <ogra_> pitti, phablet-flash always wipes the device regardless ... it just backs up some files before and restores them after flaching (namely /home and a few pre-configred config files (like wlan settings)
[10:24] <pitti> ah, good to know
[10:25] <ogra_> if you want to wipe that too --no-backup ...
[10:28] <ogra_> pitti, i assume https://code.launchpad.net/~cwayne18/phablet-tools/phablet-timezone-setup/+merge/186891shouldnt land then ?
[10:28] <ogra_> (or needs to be rolled back or whatnot)
[10:29] <pitti> ogra_: pitti | well, as long as adb push resolves symlinks on write, so that it will actualy write /etc/writable/timezone (and friends), it should be okay
[10:30] <ogra_> ok
[10:30] <pitti> ogra_: we can/should test that once above changes land; adb push to /etc/timezone should then actually update /etc/writable/timezone
[10:30] <ogra_> (adb shell just uses bash on the device side)
[10:30] <pitti> ogra_: and that script ought to work; if it doesn't, we need to update it to push directly to /etc/writable/ instead
[10:30] <ogra_> yeah
[10:31] <pitti> bah, it doesn't
[10:32] <pitti> adb push replaces a symlink with the new file
[10:32] <ogra_> lovely
[10:32]  * ogra_ is eager to get rid of adb 
[10:32] <ogra_> (and replace it qith usb networking and ssh)
[10:34] <doko> yolanda, hi, did you ever touch graphviz when working on the ruby1.8 demotion?
[10:34] <yolanda> doko, no, i didn't
[10:52] <ogra_> pitti, line 100 on "landing asks" https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 ... tell me if i got anything wrong
[10:52] <xnox> cyphermox: i'm root and talking over dbus to NetworkManager, yet it's returning me "org.freedesktp.DBus.GLib.UnmappedError.NmManagerError.Code4: Not authorized to control networking." Can I force bypass that somehow?
[10:53] <ogra_> xnox, you can
[10:53] <xnox> ogra_: oh, please, please, tell me how =)
[10:54] <pitti> ogra_: livefs-rootfs has a question mark, it does need an update (it's already pushed, but not uploaded)
[10:54] <ogra_> cat /etc/polkit-1/localauthority/50-local.d/org.freedesktop.NetworkManager.pkla
[10:54] <ogra_> [indicator-network-service]
[10:54] <ogra_> Identity=unix-group:sudo
[10:54] <ogra_> Action=org.freedesktop.NetworkManager.*
[10:54] <ogra_> ResultAny=yes
[10:54] <ogra_> ResultInactive=no
[10:54] <ogra_> ResultActive=yes
[10:54] <ogra_> xnox, ^^^ with something like that
[10:55] <xnox> ogra_: right, let me ship that in ubiquity, as at the moment NM hates ubiquity =)
[10:55] <ogra_> (you can also explicitly use "unix-user" there)
[10:55] <Laney> xnox: even with logind?
[10:55] <pitti> I don't think the ubiquity session uses PAM
[10:55] <xnox> Laney: yeap, cause logind session is established for user "ubuntu" and not for "root".
[10:55] <ogra_> pitti, yeah, i wasnt sure, removing the question mark then
[10:55] <xnox> pitti: I have just added that =)
[10:55] <ogra_> pitti, it uses lightdm iirc
[10:55] <ogra_> or doesnt it
[10:56] <xnox> ogra_: nope, ubiquity undermines and starts on starting lightdm, so it comes up just before lightdm.
[10:56] <ogra_> oh, right
[10:56] <ogra_> ubiquity-dm ... /me remembers
[10:56] <xnox> Laney: and I don't want to drop priviliges from root -> ubuntu with the logind session to use NM. Although, let me try to establish session for root and check if that helps.
[10:58] <ogra_> sed -i 's/<policy user="root">/<policy group="sudo">\n\t\t\t\t<allow send_destination="org.freedesktop.NetworkManager"\/>\n\t\t\t\t<allow send_interface="org.freedesktop.NetworkManager"\/>\n\t\t\t\t<allow send_interface="org.freedesktop.NetworkManager.SecretAgent"\/>\n\t\t<\/policy>\n\t\t<policy user="root">/g' /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf
[10:58] <ogra_> xnox, ^^^
[10:58] <ogra_> that should work too (though make sure that doesnt end up in the install :) )
[10:59] <xnox> ogra_: i think ubiquity already ships some polkit files, i'll see if I can add it there.
[10:59] <ogra_> the sed line isnt for polkit
[10:59] <ogra_> that one actually opens dbus for the sudo group directly
[11:13]  * doko curses a 3 1/2 year graphviz version
[11:18] <pitti> Laney, ogra_, stgraber: tested systemd debdiff attached
[11:19] <Laney> pitti: yay!
[11:19] <Laney> the dbus method works?
[11:19] <pitti> Laney: well, I tested with timedatectl, but that just uses dbus
[11:19] <Laney> cool
[11:20] <pitti> Laney: I reproduced the /etc setup on my workstation; I can't really fully test this on the phone until we land lxc-android-config and livecd-rootfs
[11:20] <pitti> but I made sure it doesn't touch the files in /etc/
[11:21] <pitti> Laney, ogra_: so should we wait for stgraber for the final ack of this, and upload this afternoon?
[11:21] <Laney> SGTM
[11:22] <Laney> Managed to beat lightdm/polkit :-)
[11:24] <seb128> speaking about lightdm, what's the status?
[11:24] <seb128> is it on the current image?
[11:24]  * Laney sniggers at the Forwarded:
[11:26] <Laney> seb128: I think it got pulled
[11:26] <Laney> ogra_:
[11:26] <ogra_> pitti, we need the spreadsheet ack anyway
[11:27] <ogra_> seb128, it trashed the maguro images, got fixed and now sits in proposed waiting for the beta freeze to end
[11:27] <ogra_> seb128, unlikely that you will see it land before late thu. evening
[11:27] <seb128> ogra_, can I still get an image with it? or just take the current one and install from proposed?
[11:28] <ogra_> seb128, the latter, but the session isnt switched to lightdm
[11:28] <seb128> ogra_, jasoncwarner asked me to test system settings with it to see if that makes things work better
[11:28] <ogra_> you also need to rebuild session-manager-touch with mtertys commit that is held back until it has been proven to not regress any tests
[11:29] <rickspencer3> seb128, ogra_ I think the idea was that seb128 could grab mako 59 and test the settings to confirm that they "just work" as expected
[11:29] <ogra_> the prob with that landing is that polkit suddenly working breaks a bunch of stuff talking through dbus, missing pkla files etc
[11:29] <rickspencer3> since 59 worked on mako with the new light dem
[11:29] <ogra_> rickspencer3, kind of
[11:30] <ogra_> we still need to make sure that all apps using dbus can still reach their backends etc
[11:30] <ogra_> but due to the beta freeze we have 1.5 days time at least
[11:30] <ogra_> since lightdm is held by the desktop freeze atm
[11:30] <rickspencer3> oh geez
[11:39] <xnox> Laney: pitti: so a logind session got created, but it didn't get a seat.
[11:40] <xnox> and python3-pam is missing misc_setenv call, via which I could set the seat0 before opening pam session.
[11:41] <xnox> wait, putenv is available and should do the same thing.
[11:45] <cjwatson> watch out for slightly different semantics if it's the same as C setenv/putenv
[11:48] <xnox> cjwatson: well the manpage for C api tells me that I need to free the passed string, but I'm using python, so I hope that slangasek made sure it's properly freed/garbage collected. As there doesn't even seem to be a way to call pam_close on the python PAM object =/
[11:48] <xnox> in other news.....
[11:49] <xnox> cjwatson: Laney: seat0 logind session is properly established, can connect to WiFi from within ubiquity & the a11y sound plays \o/
[11:50] <Laney> yay
[11:53] <alberts> Does anyone knows why there is no network indicator icon in gnome-session-flashback? https://bugs.launchpad.net/indicator-network/+bug/1229294
[11:55] <cjwatson> xnox: phew.  do you think that's landable for beta?  we're short on time ...
[11:56] <xnox> cjwatson: yes, I hope it is. I'll do a merge proposal now, but would want a quick review on how sane my pam_* usage is.
[11:57] <xnox> cjwatson: it will pull in python3-pam binary into main and on to all ubiquity ISOs =/
[11:58] <xnox> not sure who/where/how python-pam is used, as it's also on all ubiquity ISOs.
[11:58] <cjwatson> xnox: We could presumably also take lp:~larsu/ubiquity/lp1207890 if you're happy with it
[11:58] <cjwatson> xnox: An extra Python 3 module isn't the end of the world, I'd have thought
[11:58] <xnox> oh, larsu fixed the panels?! =)
[11:58] <cjwatson> It's tiny
[11:58] <xnox> cjwatson: https://code.launchpad.net/~xnox/ubiquity/pam-logind/+merge/187496
[12:00] <cjwatson> more idiomatic is probably "for query, type in query_list:" since you don't need the index
[12:00] <xnox> cjwatson: true, I copy&pasted the example from python-pam docs, and hacked it until it worked for me =)
[12:01] <xnox> so.... expect style/idiom inconsistency =)
[12:01] <cjwatson> xnox: would be nice to pick up the VT number from self.active_vt() or whatever it is
[12:02] <xnox> true, let me see.
[12:02] <cjwatson> xnox: we don't need XDG_SESSION_ID any more?
[12:04] <xnox> cjwatson: pam_systemd creates XDG_SESSION_ID, and sets in in the pam env, which I inject into os.environ with update call using everything pam returns in getenvlist()
[12:05] <xnox> cjwatson: the CLASS/SEAT/VTNR are set before pam_open_session() to hint pam_systemd which session we want to create, otherwise it does auto-detection which doesn't do the right thing for ubiquity.
[12:06] <xnox> which is documented on the logind wiki page for greeter/display-manager integration with logind
[12:06] <xnox> =/
[12:06] <cjwatson> xnox: Ah, got it
[12:07] <cjwatson> xnox: Not sure you need the build-dep on python3-pam since I doubt ubiquity-dm is run during build, but it doesn't hurt
[12:07] <xnox> cjwatson: Hm, shouldn't the XDG_VTNR=7 be derived from the self.vt, rather than active_vt? cause XDG_VTNR should match the VT X will be spawned on for the /user-session/
[12:07] <cjwatson> xnox: I thought self.vt was derived from active_vt
[12:07] <cjwatson> xnox: But anyway, I hadn't quite worked out exactly which it should be hence "or whatever it is" :-)
[12:08] <xnox> cjwatson: hm, it looks like /etc/init/ubiquity.conf passes it to ubiquity-dm as a command-line arg =) active_vt call seems to try to stop plymouth sensibly, on whichever vt that is.
[12:08] <xnox> ok =)
[12:09] <xnox> oh, you are correct, later self.vt might be overriden by active_vt.
[12:09] <cjwatson> It was just a knee-jerk allergy to hardcoding the VT number
[12:09] <cjwatson> But it's not a blocker
[12:09] <xnox> right, so at the time pam_session is opened self.vt should have the right one in it.
[12:10] <cjwatson> but has a "vt" prefix
[12:10] <xnox> yeah int(self.vt[-1]) ?
[12:10] <cjwatson> vt10
[12:10] <cjwatson> I'd do vt[2:] instead
[12:11] <cjwatson> with a comment
[12:11] <xnox> ok, I need a string and not an 'int' anyway for putenv call =)
[12:20] <xnox> cjwatson: ok, updated with the fix-ups & retested them as well.
[12:21] <cjwatson> xnox: yep, LGTM, go ahead and merge
[12:35] <mapreri> can someone tell me why crtools is still visible in https://merges.ubuntu.com/universe.html even if it doesn't exist anymore in debian?
[12:35] <xnox> cjwatson: merged larsu fix as well. Release & upload ubiquity?!
[12:38] <cjwatson> xnox: We ought to figure out bug 1229432, but I bet that's more complex
[12:38] <cjwatson> xnox: So go for it
[12:39] <xnox> ok.
[13:09] <cyphermox> xnox: you shouldn't have to modify the policykit rules for NM ... what we ship on desktop should still be working on ubiquity, just like it used to, seeing as you could connect to a wifi network and stuff.
[13:21] <stgraber> hey pitti
[13:21] <pitti> stgraber: bonjour
[13:21] <ogra_> stgraber, !
[13:21] <stgraber> so just saw all the highlights but haven't got to my LP bug notifications, anything I should be looking at? :)
[13:22] <pitti> stgraber: if you have a few minutes, I prepared three patches for bug 1227520
[13:22] <ogra_> stgraber, i would like an explicit confirmation for all these changes before i land the,
[13:22] <ogra_> *them
[13:22] <pitti> stgraber: and it would be nice if you could eyeball and ack them (i. e. that the /etc/writable/ approach works for you)
[13:22] <ogra_> since they change how we do readonly mode
[13:24] <stgraber> so the changes look fine, I'm just not happy with /etc/writable
[13:25] <stgraber> because we won't be able to add files to it after that upload, so it's not something we can easily re-use for other files after that
[13:25] <pitti> stgraber: why not?
[13:26] <pitti> stgraber: is there no upgrade way at all to reset/change stuff in /etc/system-image/writable-files?
[13:26] <stgraber> pitti: the initrd will only copy stuff from /etc/writable to /userdata/system-data/etc/writable if /userdata/system-data/etc/writable doesn't exist
[13:26] <stgraber> so typically only on the first boot
[13:26] <pitti> stgraber: we'd actually need that to revert the addition of /etc/localtime and friends
[13:26] <stgraber> that's to allow users to remove files within writable directories
[13:26] <pitti> that unfortunately got landed, and so we need to clean those up somehow
[13:27] <stgraber> (and not have them show up again at every boot)
[13:27] <pitti> stgraber: so on upgrade we can't do something like rm -r /userdata/system-data/etc/{adjtime,timezone,localtime} ?
[13:27] <pitti> (to clean up after the previous livecd-rootfs change)
[13:28] <pitti> stgraber: so that means for each writable file we'd need a new directory to put a symlink under it? or should that rather use something in /userdata/system-data/ directly?
[13:28] <pitti> but in the end that woudl amount to pretty much the same thing as just keeping /etc/ writable
[13:29] <pitti> except without having to patch umpteen packages to deal with r/o etc
[13:29] <xnox> cyphermox: yeah, afterall it was a bug in how I was setting up logind session. so all good now =)
[13:30] <stgraber> pitti: so I suppose we could add an extra mode to writable-paths, that's "persistent and add new stuff" which would prevent removals but will copy any new file from the rootfs to the writable path
[13:30] <cyphermox> xnox: alright, glad it's sorted out :)
[13:30] <stgraber> pitti: then /etc/writable would be something reasonable (so long as everyone understands that none of those files will be removable by the user as removing a file will just make it be copied again from the rootfs on the next boot)
[13:30] <pitti> stgraber: OOI, what was the reason to make /etc/ not writable in the first place?
[13:31] <pitti> stgraber: it's actually an use case to remove /etc/adjtime
[13:31] <pitti> although not an important one (having 0.0 in there works just as well)
[13:32] <stgraber> pitti: making /etc writable with a read-only / and no overlays would mean copying the whole of /etc to writable storage and then you end up in the case I described above where you can't know whether a file was intentionaly removed by the user from writable storage or if it's a new file that showed up in the rootfs and needs to be copied over
[13:33] <pitti> ah, ok
[13:34] <stgraber> that's why if we discard the file removal use case, we can then add an extra mode that lets you have a writable path that's "in sync" with the rootfs, in the sense that any file introduced in the rootfs will be copied over to writable storage
[13:35] <pitti> stgraber: ok, so that would be something to keep in mind for adding new files to /e/writable (can't delete them as user)
[13:35] <stgraber> I'd still prefer not to use that for /etc as a whole and just use that on a path like /etc/writable as using it over the whole of /etc will eventually lead to a bunch of files in writable storage that no longer exist in the rootfs and just use space
[13:35] <pitti> stgraber: or we would need to put the extra cp from root fs into the upgrade
[13:35] <pitti> (or rm)
[13:36] <pitti> stgraber: as we've just seen with the botched livecd-rootfs upload, we'll eventually need some kind of "upgrade postinst" script to clean up anyway
[13:36] <stgraber> pitti: yeah, if we need to cleanup stuff we could use the (not implemented yet) boot hooks infrastructure to do the cleanup
[13:36] <pitti> stgraber: well, that shouldn't happen on (every) boot, just after an upgrade?
[13:36] <stgraber> yeah, the boot-hooks stuff will let you trigger only after upgrade if you want
[13:39] <stgraber> pitti: so as a summary, I'd agree with the change if you change from "persistent" to "synced" (better names are welcome) and also propose an initramfs-tools-ubuntu-touch change to introduce that new "synced" mode (the code will need to recursively iterate through the source directory and only copy files and directories that don't already exist in the target)
[13:40] <pitti> meh
[13:41] <stgraber> and you'll have to check that none of those patched services attempts to unlink a file (or if they do, that they don't mind the original one being back after a reboot)
[13:41] <pitti> stgraber: they do unlink files in some cases, although they are rather hard to produce with CLI tools, and it doesn't matter if they come back
[13:42] <stgraber> pitti: right, I guess we should just make sure that whatever is in the rootfs matches what you'd get after an unlink, that way it doesn't matter
[13:45] <doko> yolanda, ping about https://launchpadlibrarian.net/150506882/buildlog_ubuntu-saucy-amd64.rubyluabridge_0.7.0-2ubuntu1_FAILEDTOBUILD.txt.gz
[13:45] <yolanda> hi doko
[13:46] <yolanda> i did an update for it, trying to force new version of ruby, locally it builds because grabs ruby 1.9, but in launchpad it seems to grab ruby 1.8
[13:46] <pitti> stgraber: how do we make /etc/adjtime and friends not mounts any more on upgrades? or do we just call those installs broken and people have to reinstall?
[13:46] <stgraber> pitti: just drop them from writable-paths and they no longer will be bind-mounts
[13:47] <pitti> stgraber: that's what I did, but it seems they somehow still were
[13:47] <pitti> stgraber: perhaps because they still were in /userdata/ ?
[13:47] <yolanda> doko, but i see that it still fails, how can we force ruby 1.9 there?
[13:47] <pitti> or it's because one cannot really apply these kinds of changes in-place
[13:47] <stgraber> pitti: that shouldn't be possible, are you sure they aren't listed in /etc/system-image/writable-paths?
[13:47] <pitti> (e. g. I can never go back to a r/o partition after making changes)
[13:48] <pitti> stgraber: well, I might certainly have done something wrong; I'm not claiming to understand the whole magic yet
[13:48] <stgraber> pitti: the way things work is that the initrd reads /etc/system-image/writable-paths and generates a fstab from there, so if an entry disappears from it, no fstab entry will be generated and the file will be back to normal (well, with a leftover in /userdata but that's not a big issue for now)
[13:49] <doko> yolanda, ahh, rubygems pulls in ruby1.8
[13:50] <yolanda> doko, but why locally, using sbuild, is working?
[13:56] <doko> yolanda, add a b-d on ruby1.9.1, it is not install on the buildd
[13:57] <yolanda> doko, actually, it's there: http://bazaar.launchpad.net/~yolanda.robla/ubuntu/saucy/rubyluabridge/lua5.2/view/head:/debian/control
[13:59] <doko> yolanda, is this newer than the package in -proposed?
[14:00] <yolanda> doko, looking at my mp, it says "Merged" but i don't see the changes in lp:ubuntu/rubyluabridge
[14:00] <yolanda> i did the changes on 17/09
[14:01] <doko> yolanda, well, the changelog in -proposed is the same
[14:01] <doko> maybe you could prepare a -2ubuntu2?
[14:02] <ogra_> pitti, stgraber, so did you two come to any consensus ? should i hold back the landing of the code ?
[14:02] <ogra_> or can it go in
[14:05] <yolanda> doko, so what happened? changelog is updated, but not debian/control file
[14:05] <yolanda> do i just create a new entry re-adding that bd?
[14:05] <doko> yolanda, would be best
[14:06] <doko> if this is all what is missing
[14:06] <yolanda> doko, i'll compare all the diffs with my local version, if something more is missing i'll readd it
[14:07] <stgraber> ogra_: current code can't go in
[14:07] <ogra_> stgraber, ok
[14:08] <ogra_> stgraber, btw, do you know that /userdata is really annoying ? i can tab complete /us<tab> anymore with it in place !
[14:09] <stgraber> ogra_: you know that /us<tab> is just as long as /usr, right? :)
[14:09] <ogra_> tell that to my finger memory :P
[14:09] <ogra_> oh, and its actually shorter, it gives me the trailing slash
[14:09] <ogra_> :)
[14:14] <wookey> xnox: I just clicked on a link on https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1122120 and it (surprisingly) set the status from 'Fix committed' to 'wont-fix'. If I try to change it back it tells me I'm not allowed to. This is most unhelpful.
[14:14] <wookey> Anyway you might want to set that back how it should be
[14:15] <cjwatson> wookey: I've restored it
[14:15] <wookey> cheers
[14:16] <cjwatson> it's deliberate that only bug supervisors get to transition away from wontfix
[14:16] <cjwatson> though it's a little surprising that you get to transition *to* wontfix
[14:16] <wookey> yeah I can see the sense in that. I was mostly surprised that just clicknig on that link changed it at all
[14:17] <cjwatson> cf. bug 294846
[14:19] <cjwatson> Oh.  You get to transition away from fixreleased if you are the bug reporter, so that you can always reopen.
[14:19] <wookey> yeah. I'd fogotten I started that bug :-)
[14:24] <cjwatson> wookey: I've filed bug 1230303.
[14:24] <yolanda> doko, i pushed MP again, updating changelog: https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/rubyluabridge/lua5.2/+merge/187522
[14:41] <slangasek> pitti: a friend of mine has pointed out that the postgresql metapackage in saucy is at version 9.3+146really9.1+148, whereas testing/unstable has 9.3+149.  Do you know if the server team want 9.1 for saucy, or if that should maybe be bumped?
[14:43] <pitti> slangasek: 9.3 has arrived after FF; most of the packaged extensions have been ported now
[14:43] <pitti> slangasek: it would be a rather intrusive change, but if the server team wants it it should boil down to three handful of syncs
[14:44] <pitti> rbasak: ^ do you care much about which psql version is in saucy? (I had thought not, given that the non-LTSes are not a very attractive server platform anyway)
[14:44] <slangasek> xnox: I think I only touched python-pam to do a straight python3 port... so I assume that I faithfully transcribed any memory leaks
[14:44] <slangasek> pitti: ok, no worries, just thought I'd ask :)
[14:45] <xnox> slangasek: did it work in python3 for you? i had to recompile it such that dh_python3 renames the module from PAMModule.so => PAM.so.$(python3-abi-tag), cause before $ python3 -c "import PAM" was failing.
[14:45] <slangasek> xnox: hmm, failing how?  I don't remember what level of testing I did at the time
[14:45] <slangasek> I /assume/ I did an import test, but don't remember for sure
[14:46] <xnox> slangasek: maybe things changed in how multiarched abi tags are done in python3 + impecable timing in upload to get /wront/old/bitrotted/ compile.
[14:46] <xnox> anyway, all fixed now =)
[14:46] <slangasek> ok
[14:46] <slangasek> are you actually using this module for something?
[14:47] <xnox> slangasek: ubiquity is now using it to establish a pam session => to get a proper & correct logind session => to unbreak a11y & networking.
[14:49] <slangasek> xnox: ah, hmm.  given that the code was abandonware that had to be forward-ported to use modern python *2* C extension conventions, that does worry me a little, but I guess there aren't any other options
[14:51] <xnox> slangasek: the other option is a wrapper binary / shim that will do the same (start, putenv, authenticate, open_session, exec(ubiquity-dm), close_session, stop)
[14:51] <xnox> at the moment it's nice to do that from ubiquity-dm & at the right time.
[14:52] <slangasek> right, any other /sane/ options. ;)
[14:52] <xnox> oh, yeah =) sorry..... ;-)
[14:54] <cjwatson> zul: Where is python-prb intended to come from to satisfy the dependency of python-tempest (stuck in -proposed due to this)?
[14:55] <zul> cjwatson:  crud ill fix it up
[14:55] <cjwatson> Ta
[15:06] <bdmurray> pitti: give the blacklist for postgresql- in the release upgrader (bug 871893) how are people supposed to upgrade?
[15:19] <doko> yolanda, could you just prepare  a dsc/diff.gz and put it on chinstrap/people?  doesn't apply to -2 nor -2ubuntu1
[15:19] <yolanda> sure
[15:26] <doko> cjwatson, mir needed for python-pylibmc, dep of python-werkzeug
[15:28] <cjwatson> doko: Yeah, I was trying to clean up breakage introduced by Daviey by syncing flask, but it turns out to be a deeper rabbit-hole than I thought
[15:28] <cjwatson> doko: Also redis
[15:34] <ogra_> pitti, so do you plan to work on the lxc-android-config changes further today ? else i need to back them out from trunk since i have other MPs waiting for upload
[15:38] <doko> dbarth_, ping 1217008, could you subscribe the team to the ubuntu package too?
[15:43] <doko> dbarth_, ahh, ahh, already subscribed
[15:45] <dbarth_> hang on
[15:49] <dbarth_> doko: i suppose we're good for this MIR, right?
[16:04] <slangasek> dbarth_: what is the purpose of bug #1219889?  "include the ubuntu-html5-theme in the upcoming 13.10 release" doesn't make sense, the package is already in the archive
[16:08] <dbarth_> slangasek: it is; there has been some confusion as whether SDK runtimes should go in 'main'
[16:08] <dbarth_> and that's what this MIR was about
[16:09] <slangasek> dbarth_: that's an FFe, not an MIR
[16:09] <slangasek> and I don't know what you're asking for a feature freeze exception on
[16:10] <slangasek> what's the "feature"? "put this package in main" isn't a feature
[16:12] <dbarth_> well, since the MIR was late, I thought an FFE was required as well
[16:12] <dbarth_> all in all, i think you can put that aside; i understand that SDK runtime packages do not need to go in main for the phone
[16:12] <dbarth_> should i comment and mark invalid?
[16:19] <dbarth_> done
[16:36] <infinity> chrisccoulson: Was it intentional for {firefox,thunderbird}-globalmenu to fall out of main?
[16:36] <slangasek> dbarth_: right, thanks :)
[16:37] <infinity> chrisccoulson: Oh, I see, it's a transitional package.  Probably want to explicitly seed it until post-14.04.  I'll do that.
[18:10] <infinity> sarnold: How goes glamor-egl?
[18:11] <sarnold> infinity: pretty well, I'm liking this code base :)
[18:11] <infinity> sarnold: That's a good sign.
[18:11] <sarnold> infinity: yeah, so far so good. :)
[19:40] <smoser> cjwatson, will 'dpkg-reconfigure grub-pc' always run update-grub ?
[19:45] <infinity>     if test -e /boot/grub/grub.cfg && ! running_in_container; then
[19:45] <infinity>       update-grub 3>&-
[19:45] <infinity>     fi
[19:45] <infinity> smoser: ^
[19:48] <smoser> yeah. so looks like yes.
[19:48] <smoser> well, mostly yes
[21:06] <roaksoax> infinity: howdy! so I dropped the build-dep on libopenais-dev for ocfs2-tools. I have not yet the same for asterisk, since we would be dropping functionality. However, this new functionality is no longer used by new upstream releases as they use the "replacement" for openais it seems. So we could either demote it to universe, or simply drop the use of openais in asterisk
[21:07] <roaksoax> infinity: as far as pacemaker-mgmt, i need a new upstream release of it, that I'm currently trying to fix because it FTBFS
[21:13] <infinity> roaksoax: Demoting to universe doesn't help if it's not rebuildable.
[21:14] <roaksoax> infinity: i agree, i don't mind dropping the use of it in asterisk,
[21:14] <roaksoax> so we can drop it from the archive
[21:14] <roaksoax> either way it is deprecated.. no longer supported nor maintained
[21:16] <infinity> roaksoax: Dropping openais from ocfs2-tools meant it didn't build one of its binaries too.  Is that an issue?
[21:16] <infinity> roaksoax: Anyhow, if there's a replacement for openais, why have we not packaged it?
[21:17] <infinity> (Or, we could fix openais to work with the new corosync...?)
[21:18] <roaksoax> infinity: no issue whatsoever, i had previously dropped other stuff in ocfs2-tools (related to clustering) and openais was just a left over dependency
[21:18] <roaksoax> infinity: the replacement is corosync, at it is packaged
[21:19] <roaksoax> infinity: ocfs2-tools upstream have not done anything to support the new cluster stack (which uses corosync 2.X and pacemaker 1.1.11+)
[21:19] <infinity> roaksoax: Well, you mentioned a "replacement" in terms of asterisk.
[21:19] <roaksoax> infinity: the "replacement" in terms of asterisk is to use a newer upstream release that supports corosync instead of openais
[21:19] <infinity> Ahh.
[21:19] <roaksoax> https://wiki.asterisk.org/wiki/display/AST/Corosync
[21:19] <infinity> Can any of that be sanely backported?
[21:21] <roaksoax> infinity: i would need to have a deeper look at asterisk
[21:21] <infinity> roaksoax: Anyhow, whatever you feel is lowest impact and vaguely supportable, but obviously having a non-buildable openais isn't going to work.
[21:23] <roaksoax> infinity: yeah In my opinion it is fair to drop the use of openais in asterisk, since it really is old stuff 3+ years
[21:23] <infinity> roaksoax: And get us a shiny new asterisk for 14.04 that has corosync support?
[21:24] <infinity> (Since the idea of anyone running an asterisk network on a 9-month-supported releases seems unlikely anyway)
[21:24] <roaksoax> infinity: i would say so. Release versioning in asterisk is weird, (we currently have 1.8, and the next LTS support in asterisk is 11.x ... so 1.8 -> 11.x weirdness)
[21:25] <roaksoax> https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
[21:25] <roaksoax> yeah I would say we should go for a 11.x version of asterisk for 14.04
[21:27] <roaksoax> infinity: i'll go ahead with that then
[21:27] <mwhudson> barry: https://wiki.archlinux.org/index.php/OfflineIMAP#SSL_fingerprint_does_not_match
[21:28] <barry> mwhudson: thx
[21:28] <mwhudson> (backchannels ftw)
[22:36] <mwhudson> hi, it seems that the memcached ddeb is somehow out of sync with the memcached deb (for armhf)
[22:37] <mwhudson> can i prod someone into fixing this somehow?
[22:37] <mwhudson> infinity, wgrant: you seem like the sort of people who might know about this
[22:55] <infinity> mwhudson: pitti is the person to poke, so long as ddebs come from magic land.
[22:55] <mwhudson> heh ok
[22:56] <mwhudson> file a bug on the affected package and subscribe him i guess?
[22:56] <infinity> mwhudson: They look in sync to me though.
[22:56] <mwhudson> infinity: the version numbers are the same, but gdb refuses to consult the debug info
[22:56] <mwhudson> complains about a crc mismatch
[22:56] <mwhudson> and the build ids reported by file(1) are different
[22:57] <infinity> mwhudson: Oh.  That's curious.  And not something pitti can do anything about.
[22:57] <infinity> mwhudson: Which release is this on?
[22:57] <mwhudson> infinity: raring
[22:57] <infinity> http://ddebs.ubuntu.com/pool/main/m/memcached/
[22:58] <infinity> So, note the suspicious timestamps there.
[22:58] <infinity> I *bet* someone rebuilt memcached/armhf in a devirt PPA and pitti's scripts picked up the new ddeb. :/
[22:58] <infinity> Or something like that.
[22:59] <infinity> There's pretty much nothing we can do about this until we get ddebs in soyuz.
[22:59] <mwhudson> er
[22:59] <mwhudson> yeah, that's odd
[22:59] <mwhudson> luckily memcached builds really quickly :)
[22:59] <infinity> The whole system is incredibly fragile, sadly.
[23:00] <infinity> We have all the fixes for this lined up, but we're waiting on a go-ahead from IS to flip the switch, basically.
[23:00] <mwhudson> it's the "disk is cheap and other lies" thing, right?
[23:00] <infinity> Pretty much.