[05:26] <pitti> Good morning
[05:26] <pitti> bdmurray: how do you mean? the metapackages will pull in the last version, the blacklist is just for not automatically removing the old version so that you can run pg_upgradecluster
[05:26] <pitti> bdmurray: there is a debconf note, README, etc. which explain how to upgrade
[05:27] <pitti> ogra_: not yesterday, there's only so many hours I can help out with that stuff; but if you upload, please at least revert the addition of the individual files before even more people get them (seems we have no way to fix that on upgrade?)
[05:30] <pitti> awe_: hey Tony, still here?
[06:46] <dholbach> good morning
[06:46] <dholbach> @pilot in
[07:19] <diwic> asac, hi, I want to improve PulseAudio's quality by fixing a bug that causes crashes on desktop. The bug fix is in a module (module-combine-sink) that we do not use on the phone. Can I upload it?
[10:11] <brainwash> why do the logind policy rules for "power-off-multiple-sessions" and "reboot-multiple-sessions" differ? and why does logind think that multiple sessions are running after logging out completely? bug 1226509
[10:12] <dholbach> @pilot off
[10:12] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[10:12] <dholbach> @pilot out
[12:27] <brainwash> why do the logind policy rules for "power-off-multiple-sessions" and "reboot-multiple-sessions" differ? and why does logind think that multiple sessions are running after logging out completely? bug 1226509 (comment #2)
[12:29]  * diwic wonders why installing fluidsynth (and only that package) caused an initramfs update.
[12:41] <Laney> ev: Howdy, got two questions about diagnostics in system-settings. 1. Does whoopsie work there (should we hide the settings?) 2. Do you plan on shipping a pkla to make polkit work there? We've been testing it on the device and that one doesn't work.
[12:49] <mlankhorst> cjwatson: http://people.canonical.com/~ubuntu-archive/NBS/ redirects to /NBS which 404s
[12:50] <cjwatson> mlankhorst: Works for me
[12:50] <cjwatson> Perhaps you mean http://people.canonical.com/~ubuntu-archive/NBS
[12:51] <cjwatson> And the buggy redirection there is a bug in IS' reverse proxy for http://people.canonical.com/~ubuntu-archive/
[12:51] <cjwatson> So please ask them
[12:51] <cjwatson> You probably want http://people.canonical.com/~ubuntu-archive/nbs.html anyway, though
[12:51] <mlankhorst> 404s too ;)
[12:52] <cjwatson> Definitely works for me
[12:52] <mlankhorst> hm weird, fails in firefox, works with wget
[12:53] <cjwatson> WFM in firefox
[12:53] <cjwatson> dodgy proxy?
[12:53] <mlankhorst> if there is a proxy, it would be some transparant one
[12:53] <cjwatson> shift-reload?
[12:54] <smoser> anyone else use xchat-indicator and have it not seem to work in saucy ?
[12:54] <mlankhorst> hm weird stuff
[13:02] <seb128> smoser, indeed, I've pinged larsu about it (he's doing indicator-messages)
[13:03] <seb128> smoser, can you open a bug on https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+filebug ?
[13:03] <smoser> seb128, yes.
[13:04] <seb128> smoser, thanks
[13:04] <seb128> smoser, do you know when it stopped working?
[13:06] <smoser> seb128, its been quite some time.
[13:06] <smoser> maybe a month.
[13:06] <seb128> smoser, ok, thanks
[13:06] <smoser> since i dont log in and out often, i kind of assume things like that might fix themselves on a reboot.
[13:06] <smoser> and then i'm lazy to ask.
[13:06] <smoser> anyway, bug sudo apt-get update
[13:06] <smoser> ooops
[13:07] <smoser> https://bugs.launchpad.net/ubuntu/+source/xchat-indicator/+bug/1231435
[13:07] <smoser> feel free to make it have the right words seb128
[13:18] <apachelogger> infinity: ping, would be really awesome if you could have a look at bug 1212662
[13:21] <cjwatson> pitti: do you have a VCS for the Ubuntu package of systemd?  want to fix bug 1231230
[13:21] <pitti> cjwatson: a local one, yes; haven't yet merged to Debian's git (which is finally there)
[13:21] <pitti> cjwatson: I have two local unreleased commits, but in general, don't block on that; I'm fine with grabbing LP diffs
[13:22] <pitti> cjwatson: if you don't need that uploaded right now, I can commit it, though
[13:23] <cjwatson> pitti: I'd like it today I think, but need to go out now to return some unused hardware, so in a bit.  Thanks
[13:41] <gusch> seb128: hmmm - state handling seems to be pretty broken ...
[13:42] <seb128> gusch, in system settings or in content-hub?
[13:42] <gusch> seb128: content-hub
[13:42] <seb128> gusch, :-(
[13:42] <seb128> gusch, can you get it fixed today?
[13:43] <gusch> seb128: let's see - no promises ...
[13:43] <seb128> gusch, should we think about reverting that update to get back to a working feature?
[13:43] <seb128> didrocks, asac: ^
[13:43] <seb128> how did that content-hub land if it's obviously buggy?
[13:43] <gusch> seb128: when do we need to deside for that?
[13:44] <seb128> gusch, not sure, let's see what asac and didrocks say
[13:44] <gusch> seb128: I looked to the content-hub part only - didin't test with the setting, and for the test it worked fine
[13:47] <didrocks> if gusch can't get a fix in the next hour, let's revert
[13:47] <didrocks> seb128: can you try reverting and ensuring it's working on latest image?
[13:47] <doko> Riddell, are you aware of the ftbfs for qtwebkit-source on armhf?
[13:47] <seb128> didrocks, I did that already, it does
[13:47] <gusch> didrocks: ok - one hour then
[13:47] <seb128> thanks
[13:48] <didrocks> seb128: does this work for you (this one hour + revert if nothing?)? ^
[13:48] <seb128> didrocks, yes, thank you
[13:48] <didrocks> ok, let's see
[13:48] <seb128> gusch, thanks as well, finger crossed you fix it ;-)
[13:48] <didrocks> gusch: keep us up to date, please ;)
[13:49] <doko> seb128, is platform-api expected not to build on powerpc?
[13:49] <doko> pitti, pygobject ftbfs on powerpc
[13:50] <pitti> doko: thanks for the poke, retrying (sounds like test race condition)
[13:50] <seb128> doko, I think popwerpc is not supposed indeed
[13:50] <seb128> sil2100, Mirv, didrocks: ^ can you confirm?
[13:51] <pitti> doko, seb128: I thought basically anythign which uses Qt5 is !powerpc at this point?
[13:51] <Riddell> doko: yeah, shadeslayer had an idea to fix it but don't think he get there yes
[13:51] <Riddell> yet
[13:51] <seb128> pitti, indeed, I'm unsure the platform-api uses qml though
[13:51] <seb128> pitti, it's lower in the stack
[13:52] <didrocks> doko: yeah, no point in having powerpc, I do remember we had issues on platform-api with it
[13:52] <didrocks> don't have the whole story in mind though
[13:52] <seb128> pitti, but it use the location service and other bits that might not work on ppc
[13:56] <sil2100> Same here
[14:16] <psusi> is there a way to get the original core dump that the stack retracer removed from a bug report?  I really need to poke around in there more to find the cause of this crash...
[14:23] <geser> you might be lucky and it's still available through the bug history
[14:25] <psusi> I think there's a permissions thing... once the link is removed from the bug report, launchpadlib disavows it, like it does for private bugs you aren't subscribed to
[14:26] <psusi> in other words, the link shown in the email where it was removed no longer works
[14:32] <gusch> seb128: didrocks not looking good to fix it soon :(
[14:32] <didrocks> ok ok
[14:32] <seb128> gusch, do you see what's wrong? is there any workaround we could use on the settings side (you said your test example worked)
[14:33] <gusch> seb128: I'm not yet sure where the problem really is - still debugging
[14:35] <seb128> gusch, can you confirm the bug at least? (e.g that the settings stopped working)
[14:37] <gusch> seb128: yes - doens't work for me either anymore
[14:38] <seb128> ok, at least it's reproducable
[14:38] <didrocks> ok, reverting then?
[14:39] <seb128> gusch, ^ do you want another 15 min to see if you get to the bottom of it, or just revert now?
[14:40] <psusi> wait a minute... what's going on here?  gparted does not have debug symbols.. it is stripped... and not saved... no -dbg package... no symbol file anywhere... no options given to dh_strip... so how is apport retracer providing full stack trace?
[14:40] <gusch> seb128: I rather guess I will need another hour just to find the point of error
[14:41] <seb128> gusch, ok, let's revert then
[14:41] <seb128> didrocks, ^
[14:41] <gusch> seb128: better, yes :(
[14:41] <seb128> didrocks, how do we revert nowadays? get a mp to back out the changes from trunk?
[14:41] <didrocks> seb128: push it to trunk directly even
[14:42] <didrocks> seb128: if you can avoid doing the same mistake than I did, it will be good ;)
[14:42] <didrocks> like keep the old changelog
[14:42] <didrocks> adding a new one
[14:42] <didrocks> telling "reverting blahblahblah" ;)
[14:42] <didrocks> seems better than reverting the changelog altogether
[14:42] <didrocks> (I did that for ubuntu-keyboard before seeing it was nonsense)
[14:43] <seb128> didrocks, ok, let me try that
[14:43] <didrocks> seb128: then, if you don't mind, once build, can you add the ppa, upgrade (adding the content-hub package) to your phone and just poke with it?
[14:43] <didrocks> seb128: that would be perfect ;)
[14:43] <didrocks> (I can poke you once built)
[14:43] <seb128> didrocks, sure can
[14:43] <seb128> didrocks, thanks
[14:44] <gusch> seb128: but then the seeting change needs to be reverted as well, as that change was incompatible
[14:45] <seb128> gusch, is that in another component?
[14:45] <gusch> seb128: in the seetings application (setting the store there)
[14:45] <seb128> gusch, right, I can do that
[14:46] <didrocks> seb128: ah, so we'll need another settings altogether?
[14:46] <seb128> didrocks, seems so :/
[14:46] <didrocks> sil2100: so maybe wait on that for settings ^
[14:48] <sil2100> ...:D
[14:49]  * sil2100 feels like he's picks up and drops things one after another
[14:49] <sil2100> ;)
[14:49] <sil2100> seb128: could you give me a sign once it's done
[14:49] <sil2100> ?
[14:50] <pitti> psusi: WDYM? http://ddebs.ubuntu.com/pool/main/g/gparted/ has debug symbols, at least for aucy?
[14:50]  * pitti throws in an "s"
[14:51] <pitti> awe_: hey Tony
[14:51] <psusi> oh look at that, we do have a secret repository of debug symbols even when they are supposed to be stripped and not saved
[14:51] <pitti> psusi: ddebs.u.c. is the one and only repo, by far not secret :)
[14:52] <psusi> well, when you ask dh_strip to, you end up with a -dbg package in the main archive
[14:52] <awe_> pitti, hey... just getting going this morning, and trying to read my back-log
[14:52] <pitti> awe_: no worries
[14:52] <pitti> awe_: just a quick status update
[14:52] <awe_> lots to read
[14:52] <pitti> awe_: so I'm creating a dbusmock for ofono, and test that with the ofono scripts; making nice progress
[14:52] <psusi> and when you don't... it's not supposed to go anywhere, but it seems it gets stered to ddebs instead... nifty trick
[14:53] <psusi> now to see if I can pry the original crash dump out of launchpadlib
[14:53] <pitti> psusi: heh, welcome to 2006 :)
[14:53]  * pitti pats https://launchpad.net/ubuntu/+source/pkg-create-dbgsym/0.1
[14:53] <awe_> pitti, I'd like to discuss more but I have a stand-up in ~5m
[14:53] <pitti> awe_: no worries
[14:54] <pitti> awe_: I need to leave soon for today anyway
[14:54] <pitti> awe_: just wanted to say "there's hope" :)
[14:54] <awe_> pitti, one thought though is what advantage does this have vs. using the internal ofono phone emul?
[14:54] <awe_> pitti, there's always hope
[14:54] <awe_> don't you listen to U2?  ;)
[14:54] <pitti> awe_: well, I'm investigating both; I still failed to get the emulator actually working (see my mail)
[14:55] <awe_> OK ( still reading emails... ^^ ); ttyl!
[14:58] <arges> hallyn: ping
[15:02] <doko> hrm, python-werkzeug now shows another test failure
[15:02] <seb128> gusch, didrocks, sil2100: https://code.launchpad.net/~seb128/content-hub/revert-buggy-changes/+merge/187812 ... I can't push directly, I'm not in the right team
[15:03] <didrocks> perfect, let me push it
[15:03] <seb128> gusch, didrocks, sil2100: I verified with a bzr bd --source that the debdiff has only the changelog between the 20 and 26 version
[15:03] <didrocks> seb128: thanks for the extra care!
[15:03] <didrocks> asac: FYI, we are reverting content-hub ^
[15:03] <didrocks> ok pushed
[15:03] <didrocks> now, let's rebuild content-hub
[15:04] <didrocks> seb128: poke me once system-settings is ready, I'll rebuild it as well
[15:04] <asac> didrocks: your call. .ensure the stakeholders are well aware and jason in particular
[15:04] <didrocks> asac: I guess they are ;)
[15:04] <asac> ultimately i am less strict about regressions in apps that have no tests
[15:04] <asac> so in this case i probably wouldnt have backed it out unless the content-hub folks say we should do :)
[15:05] <asac> but your call... both is valid :)
[15:05] <didrocks> asac: gusch says we should do (he's upstream)
[15:05] <didrocks> and ken is on holidays
[15:05] <didrocks> so I guess it's the only way to get to a sane state
[15:05] <doko> yofel, ping about virtuoso-opensource
[15:07] <asac> didrocks: sounds right
[15:07] <asac> ack
[15:09] <hallyn> arges: .
[15:14] <psusi> pitti: when apport retraces a bug and removes the coredump, is it really deleted, or just no public way to find it any more?  and I have a bug that it incorrectly decided was a dup and removed everything useful without doing a full stack trace... but it isn't a dup.  anything to be done about that?
[15:17] <mterry> robru, I poked dbarth_ about the cordova MIR and he says we don't need that either, which means we don't need to stress as much about qtaudioengine
[15:18] <mterry> robru, though if we want to drop it anyway for 14.04, we might as well drop for 13.10 as well.  So question to bzoltan still stands
[15:45] <didrocks> mterry: +1, we don't need it for now
[15:52] <pitti> psusi: /away -all
[15:53] <pitti> sorry, I'm afraid not; I can drop the master bug from the duplicate db, if that's a systematic mis-duplication
[16:20] <pitti> awe_: ok, got the simulator to work
[16:21] <awe_> cool!
[16:22] <pitti> awe_: I also have an initial version of an ofono dbusmock (just took me an hour or so, not much wasted), in case we ever need that in the future
[16:22] <awe_> pitti, also good news!
[16:23] <pitti> awe_: EOD for me now, but I'll start writing some autopilot tests for the dialer tomorrow (also followed up by mail again)
[16:23] <awe_> pitti, ack
[16:24] <awe_> pitti, I will try and dig thru my overflowing inbox and respond at least once before my EOD.
[16:24] <awe_> pitti, one question...  I floated the idea of a hangout to discuss progress, brainstorming, ...
[16:24] <awe_> is 5 UTC too late for you?
[16:24] <pitti> awe_: monday, anything before 1600 UTC
[16:25] <awe_> ack
[16:25] <pitti> awe_: I have taekwondo in the evening; I could miss that in principle, but earlier would be better
[16:25] <awe_> right
[16:27] <awe_> I'm loathe to schedule something early my time Monday morning, would Tue early be OK ( 14 UTC )?
[16:28] <awe_> or as early as 13UTC?
[16:28] <pitti> awe_: works fine for me
[16:28] <awe_> coolio
[16:28] <pitti> awe_: Tuesday I can do anything from 0500 to 1800 UTC
[16:28] <awe_> I will schedule a hangout for that time then ( tue 14utc )
[16:28] <pitti> great
[16:29] <pitti> I'll hopefully have some ap test prototypes by then
[16:29] <awe_> should I invite everyone on the Connection Testing email?  Or should we make it a smaller group?
[16:29] <pitti> awe_: can you please invite fginther, if possible? (for how to run this in CI)
[16:29]  * awe_ notes the To/Cc list is rather large
[16:30] <pitti> awe_: no need to pull gema, thomi, chris etc. into this IMHO; I think it's fine if I'll be there as a representative of QA; someone from CI, and then of course the dialer/messaging app authors
[18:15] <Guest2048> Hi all! I would like to ask something! I have  a fresh 13.10 Beta installed, and would like to remove the wayland libraries, but...
[18:15] <Guest2048> sudo apt-get purge libwayland-client0 libwayland-cursor0 libwayland-server0
[18:15] <Guest2048> Reading package lists... Done
[18:15] <Guest2048> Building dependency tree
[18:15] <Guest2048> Reading state information... Done
[18:15] <Guest2048> Some packages could not be installed. This may mean that you have
[18:15] <Guest2048> requested an impossible situation or if you are using the unstable
[18:15] <Guest2048> distribution that some required packages have not yet been created
[18:15] <Guest2048> or been moved out of Incoming.
[18:15] <Guest2048> The following information may help to resolve the situation:
[18:15] <Guest2048> The following packages have unmet dependencies:
[18:15] <Guest2048>  ubuntu-system-settings : Depends: libtimezonemap1 but it is not going to be installed
[18:15] <Guest2048> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
[18:16] <Guest2048> I dont understand how ubuntu-system-settings come to the picture
[18:16] <Guest2048> Anybody have some idea, how can I remove wayland?
[18:17] <psusi> you have to fix your broken packages ( u-s-s ) before you can do anything else with apt
[18:18] <Guest2048> but I can do anything else, example now I installed xchat
[18:19] <Guest2048> and anyway I dont understand what is broken
[18:19] <Guest2048> should I install ubuntu-system-settings?
[18:19] <psusi> u-s-s is broken becuse it depends on libtimezomemap1, but it isn't installed
[18:20] <Guest2048> sudo apt-get install libtimezonemap1
[18:20] <Guest2048> Reading package lists... Done
[18:20] <Guest2048> Building dependency tree
[18:20] <Guest2048> Reading state information... Done
[18:20] <Guest2048> libtimezonemap1 is already the newest version.
[18:20] <Guest2048> 0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.
[18:20] <Guest2048> now Im installing u-s-s
[18:22] <slangasek> Guest2048: you shouldn't purge the wayland libraries
[18:22] <Guest2048> ups... now i can remove wayland, but unity goes with it
[18:22] <Guest2048> because of unity?
[18:22] <Guest2048> I thouth its in different libraries now (Mir)
[18:25] <Guest2048> Im on my way to build the new wayland... So I think gonna install xfce, then remove wayland
[18:25] <Guest2048> thanks for your help goodbye
[18:28] <slangasek> Guest2048: because the existing mesa libraries are built against wayland for optional support, so removing them breaks the whole system
[18:28] <slangasek> (mesa, and also gtk)
[18:28] <psusi> say, what ever happened to x32?  I still don't see x32 builds in the archive.  Is there a separate archive for that or did it die?
[18:28] <slangasek> it was never alive
[18:29] <Guest2048> So how can i build wayland from git?
[18:29] <psusi> so developmen has stalled or is there ongoing work somewhere?
[18:30] <Guest2048> Should I build it on xubuntu?
[18:32] <Guest2048> I mean not just build, but use it, with weston
[18:32] <Guest2048> I wasnt able to compile weston because of the default wayland libraries
[18:35] <infinity> psusi: There's been no great push to do a full port.  There's toolchain support for building x32 binaries with -mx32
[18:35] <infinity> I wouldn't mind doing an x32 port, but I suspect someone needs to make a good case for it.
[18:36] <infinity> Guest2048: Having old wayland libraries installed shouldn't prevent you from building new ones...
[18:38] <slangasek> Guest2048: not really a question for this channel, though
[18:39] <Guest2048> infinity: yes, I can build it, but how can I use by just replacing the wayland libs?
[18:40] <Guest2048> slangasek: but the not dev ubuntu channel?
[18:41] <slangasek> Guest2048: I imagine you would want a wayland channel; this channel is for development of Ubuntu
[18:42] <Guest2048> slangsek: I was there, and they say, the problem, that the old wayland libs
[18:43] <Guest2048> so I was to remove them, but doesnt understand the problem with ubuntu-system-settings and libtimezonemap1
[18:44] <Guest2048> so reinstalled the system, because I thout I screwed something
[18:44] <Guest2048> but no :)
[18:47] <Guest2048> I will try to install it to a custom location
[18:47] <Guest2048> thanks for your help
[18:49] <Guest2048> ubuntu-devs how doing this? making a new package first then upgrading it with dpkg?
[18:50] <sarnold> Guest2048: if you're still talking wayland you can probably do ./configure --prefix=/opt/guest2048/wayland/  and then continue as directed by their README..
[18:50] <sarnold> no need to get dpkg involved if you're just building things locally.
[19:25] <psusi> so if I wanted to build x32, how do you do that?  dpkg-buildpackage -ax32 doesn't seem to work... it doesn't pass -mx32 to gcc for some reason and so ends up still building for amd64
[19:26] <dobey> x32?
[19:27] <dobey> i386?
[19:28] <psusi> no... x32... amd64 with 32 bit pointers
[19:29] <slangasek> psusi: dpkg-buildpackage -afoo will never use gcc -mbar; you would need an x32-linux-gnu-gcc wrapper
[19:29] <dobey> right if you want to cross-compile something you need a cross-compiler
[19:30] <psusi> well it doesn't even seem to be looking for x32-linux-gnu-gcc
[19:30] <psusi> it's just running regular old gcc
[19:32] <slangasek> then you're trying to build a package that isn't cross-buildable?
[19:36] <psusi> it's parted.. what's it take to be cross buildable?  it seems to go out of its way in the rules file to default DEB_BUILD_ and DEB_HOST_ variables and call dpkg-buildflags to get default flags... doesn't dpkg-buildpakcage -afoo set those varibles?  and I would think when they are set dpkg-buildflags would return the correct -mbar flag
[19:37] <slangasek> yes, it does set them, but does the package pass them in a useful manner to the upstream build system?
[19:41] <slangasek> psusi: so debian/rules certainly seems to dtrt for passing --build= and --host= to configure; do you see this in the build output?
[19:43] <infinity> psusi: So, maybe we're asking the wrong questions here.  Why would you try to build with -amx32?  That would give you an _x32.deb, which would be almost certainly useless to you...
[19:44] <infinity> psusi: Given that we're already pointed out that there isn't an x32 port.
[19:44] <infinity> s/we're/we've/
[19:45] <psusi> yes... aha... configure says it can't find the cross compiler and so I guess it falls back to gcc
[19:45] <psusi> infinity: I figured I'd try making such a port ;)
[19:45] <psusi> good learning excercize at least
[19:46] <infinity> psusi: http://ports.debian.net/debian/pool-x32/
[19:46] <infinity> psusi: I suspect you'll find all the work is already done.
[19:46] <infinity> psusi: It's just neither an official Debian port, nor an Ubuntu port.
[19:47] <psusi> ahh, neat
[19:48] <infinity> I guess http://ftp.debian-ports.org/debian/ is the more canonical URL this decade.
[20:27] <semiosis> slangasek: ping
[20:28] <slangasek> semiosis: hello
[20:28] <semiosis> greetings.  i'm interested in your comment on https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1205075
[20:28] <slangasek> sure :)
[20:29] <slangasek> I guessed that was what I'd done that had brought people hunting for me
[20:29] <semiosis> what can we (the upstream community) do to make gluster work better with mountall?
[20:29] <semiosis> some interface you mentioned?
[20:30] <semiosis> "the expected interfaces required for mount.$fstype helpers"
[20:32] <slangasek> semiosis: right, just responded on the bug for reference - short answer is, "anything that mount(8) lists as a valid commandline for mount itself"
[20:32] <slangasek> there are certain internal options to mount that you don't have to handle... mount -n, mount -f, and of course mount -t
[20:32] <semiosis> ok i understand
[20:33] <slangasek> but at least in testing with the 13.10 version of glusterfs-client (whose usage output differs from the version in the bug report), it seems that mount.glusterfs expects <device> <-o$options> <dir>, which is actually *contrary* to what the mount manpage describes, and is incompatible with other helpers
[20:33] <slangasek> (i.e., mount.nfs)
[20:33] <slangasek> and mountall shouldn't have to guess which order the arguments go in :)
[20:34] <semiosis> got it.  i'll open bugs upstream about this
[20:34] <arges> hallyn: I have a patch for bug 1100843, can you review: http://people.canonical.com/~arges/lp1100843/precise/fix-lp1100843-precise.debdiff . so far my tests pass with this build. thanks
[20:35] <semiosis> slangasek: i've done most of my testing with precise and haven't run into any of these kinds of problems, as far as I know
[20:35] <semiosis> slangasek: has anything changed in raring that might affect this?
[20:35] <semiosis> s/raring/quantal/
[20:38] <slangasek> semiosis: as far as I know, the mount argument handling in mountall has not changed
[20:39] <semiosis> ok.  i was planning on putting some time in on the ubuntu packages tonight, i'll dig into this as well while i'm at it
[20:39] <semiosis> glusterfs ubuntu packages
[20:39] <slangasek> perhaps this was a glusterfs upstream behavior change between 3.2.5 and 3.2.7
[20:39] <slangasek> since 13.04/13.10 have 3.2.7, and 12.04/12.10 have 3.2.5, and the bug is only reported against 13.04
[20:40] <semiosis> right
[20:40] <semiosis> most people use my PPA packages of glusterfs, and I've never heard of anyone having this problem -- with any glusterfs version since 3.1
[20:44] <semiosis> but i'll look into that in any case
[22:22] <doko> barry, could you have a look at the python-werkzeug ftbfs and tell me that the wsgi tests need access to the network?
[22:29] <jtaylor> doko: fails for me with network enabled and disabled
[22:31] <doko> hrm, does succeed here locally
[22:36] <doko> jtaylor, so if you have an idea why ...
[22:37] <jtaylor> uh its a pybuild package
[22:37] <jtaylor> how do I get that verbose
[22:41] <jtaylor> doko: works with LC_ALL=C.UTF-8