[01:47] <hyperair> could anyone help with bug #1196828?
[01:48] <hyperair> why would a process be <defunct> yet not get reaped by pid 1?
[01:59] <RAOF> hyperair: Because it's a zombie? (ie
[02:00] <hyperair> RAOF: zombies that have ppid=1 should be reaped immediately
[02:00] <hyperair> RAOF: this one is a zombie that has ppid=1, but hasn't been reaped.
[02:00] <RAOF> Hm.
[02:01] <hyperair> http://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init <-- this one doesn't have a solution either
[02:01] <hyperair> i'm wondering if there's a kernel bug somewhere..
[04:27] <pitti> wgrant: aah, thanks
[04:29] <pitti> dobey: yeah, the s-c test times out (it's just a very ugly error message)
[04:30] <pitti> dobey: as jibel said, if it works for you locally and with run-adt-test, supposedly it's trying to talk to some network server without a proper timeout?
[07:12] <tvoss_> pitti, ping
[07:12] <pitti> hey tvoss_
[07:18] <dholbach> good morning
[08:05] <cjwatson> xnox: Could you merge libkolabxml?  A new upload is needed for the php5.5 transition, and it might as well be a merge (or sync if appropriate).
[08:20] <pitti> jibel: OOI, what was the reason for ubuntuone-client not getting an autopkgtest?
[08:20] <pitti> jibel: (I just got a bunch of failure email which reminded me)
[08:26] <jibel> pitti, I noticed last week that when a package is uploaded with tests for the first time, the test request is not submitted. Then if a dependency of this package changes then the job is created.
[08:26] <jibel> pitti, I have not been able to reproduce the problem and find what causes it yet
[10:04] <jibel> dobey, s-c tests hang on test_dataprovider on both archs, here is the output http://paste.ubuntu.com/5880305/ not much information though.
[10:07] <Laney> jibel: Ah, I meant to disable that one
[10:14] <Laney> dobey: jibel: Wait, none of the ones I disabled are actually disabled in the source
[10:14] <Laney> Looks like the tarball wasn't generated quite right
[10:41] <xnox> jibel: colord auto-pkg-test is a mistery to me, it has always failed (and now blocking my fix to transition). It looks like the tree does get built, but the test do not run from it, as there is no Makefile.
[10:42] <RAOF> xnox: I thought pitti marked that one?
[10:43] <pitti> not me personally, but (I think) infinity did
[10:43] <xnox> .... but i now uploaded a new version, I guess the hint needs a version bump
[10:43] <Laney> yes
[10:43] <xnox> Laney: please bump, version hint on colord.
[10:44] <Laney> ok
[10:44] <Laney> but it's an incentive to look at fixing them
[10:44] <pitti> xnox: I guess you see debian bug 711209
[10:44] <xnox> pitti: jibel: how come it says needs-build, yet the tree the tests are run from is not built.
[10:44] <xnox> ah!
[10:44] <pitti> xnox: I added a cheesy workaround for that in umockdev
[10:44] <pitti> xnox: but it only happens if you do run-adt-test -S file://your..branch, not when running the tests from the archive
[10:44] <xnox> pitti: I like that workaround.
[10:45] <pitti> # work around broken "build-needed" behaviour (Debian #711209)
[10:45] <pitti> RT="$ADTTMP/../../ubtree0-build/real-tree"
[10:45] <pitti> [ -d "$RT" ] && cd "$RT" || true
[10:45] <pitti> xnox: *cough*
[10:46] <Laney> haha
[10:46] <Laney> I thought you'd have done the build yourself
[10:55] <RAOF> xnox: I've fixed the colord autopkgtests here; where are your changes, so I can fold them in?
[10:58] <RAOF> xnox: I'll pull them out of -proposed, I guess?
[10:59] <xnox> RAOF: yeah lp:ubuntu/saucy-proposed/colord is up to date.
[11:54] <infinity> jibel: *pokity poke*
[11:55] <infinity> jibel: WTF does the autopkgtest for linux do, and why does it never seem to end?
[11:55] <infinity> cjwatson: Or is this a binary/source confusion bug?
[11:55] <infinity> cjwatson: (Possibly, since it seems to be testing "linux/3.10.0.3.12", which is actually a metapackage from linux-meta...)
[11:56] <ogra_> infinity, there seem to be jenkins issues, i wonder if that also affects that
[11:56] <infinity> ogra_: This isn't the first time I've seen this, I've just forced it in the past because the kernels were vaguelt urgent.
[11:56] <infinity> vaguely*
[11:56] <ogra_> (serveral machines had power outages over night)
[11:56] <jibel> infinity, "ld: final link failed: No space left on device", I'll adjust the size
[11:57] <ogra_> heh, unrealted then :)
[11:57] <xnox> OMG! https://github.com/mame/quine-relay
[11:57] <infinity> jibel: So, I'm awful at navigating the Jenkins "UI" (and I use that term generously)... How do I find this?
[11:59] <infinity> I'm still not convinced there isn't also a bug here with the source/binary version confusion.
[11:59] <jibel> infinity, line 19926 of https://jenkins.qa.ubuntu.com/job/saucy-adt-linux/ARCH=amd64,label=adt/55/consoleText
[12:00] <infinity> xnox: That's perverse.
[12:03] <infinity> jibel: Ahh, special.
[12:04] <infinity> jibel: Also probably a crap test to be run every time linux-meta is uploaded.  Is there a way to skip some dependency chains?
[12:05] <infinity> jibel: (Given that's a compile test, which we want to run when some other deps are uploaded, but it's pointless to run it when meta is uploaded since we JUST BUILT THE KERNEL) :)
[12:13] <jibel> infinity, there is no such way to skip some dependency chain in autopkgtest.
[12:13] <jibel> In this case the test has been triggered by the upload of linux-signed
[12:14] <infinity> jibel: Yeah, I realised that after I mentioned linux-meta.
[12:14] <infinity> jibel: Though, I'd expect both to trigger it...
[12:45] <smb> I saw this line on a few dist-upgrade runs after config dialogue boxes (just now again on Saucy). I don't think it is a real problem but maybe someone would want to know about it: Undefined subroutine &conffile::abs_path called at /usr/bin/ucfg line 529 <HASH> line 6.
[12:48] <tvoss> pitti, ping
[12:48] <infinity> smb: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709567
[12:48] <infinity> smb: Already in -proposed.
[12:49] <infinity> And would have migrated, if the mailman autopkgtest didn't fail.  Hrm.
[12:49] <smb> infinity, Ah thanks. Maybe I should have searched LP just that I seem not very successful on that
[12:50] <infinity> jibel: Okay, time for me to be annoying again, I have *no* idea how to read the mailman adt failure.
[12:50] <pitti> tvoss: hey
[12:51] <cjwatson> infinity: Is that not a straight test failure?
[12:51] <cjwatson> (https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-mailman/7/ARCH=amd64,label=adt/artifact/results/log)
[12:52] <jibel> infinity, https://jenkins.qa.ubuntu.com/job/saucy-adt-mailman/7/ARCH=amd64,label=adt/artifact/results/dsc0t-mailman-stdout
[12:52] <infinity> Oh, indeed.  Navigating jenkins hurts my head.
[12:52] <cjwatson> I wonder if that's actually a regression from Apache 2.4
[12:52] <jibel> several tests fails with a 404
[12:52] <infinity> I never know if I want random build artifacts or console output, or...
[12:53] <infinity> Anyhow, it shouldn't block ucf, afaict.
[12:53] <cjwatson> (Also, why do the Jenkins autopkgtest runs not show full apt-get output from installing dependencies, while adt-run by hand does?
[12:53] <cjwatson> )
[12:55] <dholbach> barry, did you have a chat with mandel already? :)
[12:56] <barry> dholbach: waiting for a pong ;)
[12:57] <tseliot> pitti: if I wanted to let a Jockey handler install another package in addition to the driver, shall I use backend.install_package() or is there a better way to do it?
[13:01] <pitti> tseliot: that's fine to use
[13:01] <tseliot> pitti: ok, thanks
[13:04] <infinity> chiluk: When doing apt SRUs, it's nice to not generate thousands of lines of cruft by using a different version of autotools...
[13:04] <dobey> Laney: what do you mean "the tarball wasn't generated quite right" exactly?
[13:04] <Laney> dobey: The tests I disabled aren't disabled in there
[13:04] <infinity> chiluk: (Alternately, just apply your patch and build with -nc, so it doesn't regen the autotools bits at all)
[13:04] <dobey> Laney: you submitted a branch after i'd made the tarball. i included the patch in debian/patches/
[13:05] <dobey> Laney: so if they aren't disabled, i guess that patch isn't being applied for some reason in the test run?
[13:06] <Laney> dobey: Oh, well the patch is broken then
[13:07] <Laney> Those [13:07] <dobey> you renamed files?
[13:08] <Laney> yes
[13:08] <dobey> oh
[13:08] <dobey> why did i approve that :(
[13:08] <Laney> hahaha
[13:08] <dobey> i didn't notice that part
[13:09] <Laney> It's how other tests were disabled in there
[13:09] <Laney> so I just copied that
[13:10]  * dobey is inclined to just rm -rf debian/tests and call it a day
[13:11] <Laney> that would be quite extreme
[13:11] <Laney> loads of them still work
[13:36] <dobey> the archive builds for arm all happen on real hardware?
[13:40] <infinity> dobey: Yes.
[14:22] <xnox> though cosmic rays add a splash of surrealism on panda boards.
[14:24] <ogra_> yeah, they have builtin cosmig ray collectors
[14:24] <ogra_> *cosmic
[14:25] <ogra_> its like the opposite of a tinfoli hat
[14:25] <ogra_> want more rays ... wear a pandaboard
[14:50] <dobey> ogra_: i keep trying to collect cosmic rays, but the neutrinos just keep passing through everything I put in front of them.
[14:50] <ogra_> heh
[15:46] <didrocks> jbicha: wrong dput?
[15:46] <didrocks> 7.0.2+13.10.20130715.1-0ubuntu1~ppa1
[15:46] <jbicha> didrocks: ooops
[15:47] <didrocks> jbicha: can you get it blacklisted/removed? this version is untested
[15:47] <didrocks> (70 failures in trunk last tests results, so better to not push the unknown)
[15:48] <didrocks> sil2100: FYI, we'll maybe need to include the dummy changelog as well in trunk ^
[15:48] <jbicha> Laney: can you kill that ^
[15:48] <didrocks> and blocked it in proposed
[15:48] <Laney> I'm guessing an AA could remove it
[15:49] <didrocks> Laney: hum, I'm unaware how to do that though
[15:49] <didrocks> complete removal of a package yes, a specific version…
[15:49] <didrocks> and blocking proposed -> release so that it's not copied by error…
[15:50] <jbicha> I guess I need to look into getting dput-ng to block uploading ~ppa to ubuntu as penance
[15:50] <Laney> didrocks: remove-package -s saucy-proposed?
[15:50] <cjwatson> remove-package has a --version option too
[15:50] <Laney> IANAAA :-)
[15:50] <jbicha> if the package is deleted I assume you won't need to touch trunk's debian/changelog
[15:50] <didrocks> jbicha: I hope so :)
[15:51] <cjwatson> (remove-package is actually remove-publication; it's just called remove-package because the more accurate name is not what most people would reach for)
[15:51] <didrocks> cjwatson: ok, I got puzzled, thanks for the trick
[15:52] <cjwatson> Anyway, you can certainly use -s saucy-proposed and just look at the prompt carefully
[15:52] <didrocks> cjwatson: Laney: jbicha: done
[15:52] <Laney> great
[15:52] <didrocks> yeah, it matches :)
[15:52] <Laney> another yay for proposed
[15:53] <jbicha> I never used to have upload rights for unity
[15:53] <jbicha> with daily landing, I don't particular want those rights either
[15:55] <doko> ScottK, yofel, Riddell: I don't like the additional dependencies in pkg-kde-tools. makes a bootstrap harder. is lintian really needed, or can it be made a recommends?
[15:55] <Laney> jbicha: I guess you could get such a hook included upstream
[15:55] <Laney> please do write it
[15:56] <yofel> doko: well, it is run during the kde builds, so I need some dependency that will pull it on the buildds
[15:56] <yofel> it's not totally required though, we just don't really have any other easy way to run it
[15:56] <doko> yofel, is lintian really run during a package build?
[15:57] <yofel> doko: yes, because that's a lot easier than running it by hand over some ~160 packages
[15:57] <doko> sorry, but this is insane
[15:58] <yofel> I'm open for better ideas
[15:58] <doko> infinity, lamont: is it finally time to run lintian after every build? this kde insanity is worse ...
[15:59] <doko> or wgrant: ^^^
[16:00] <infinity> Could be something done as part of proposed-migration.  I'm not sure it belongs in the soyuz/buildd realm.
[16:00] <cjwatson> We have lintian.ubuntuwire.org
[16:00] <cjwatson> Though somebody needs to update that to saucy, apparently
[16:00] <infinity> Then again, I'm not happy with lintian *blocking* anything, so yeah, ubuntuwire seems sane enough an option.
[16:00] <cjwatson> broder_: ^- IIRC that was your baby?
[16:01] <cjwatson> I'd like to run lintian with something like the Debian ftpmaster profile as part of archive accepts, but not a high priority IMO
[16:02] <yofel> doko: considering we need it mostly for our work-in-progress builds, I'll remove it from the archive package for now and just put a seperate build in our PPA.
[16:02] <doko> yofel, that would be nice, yes
[16:03] <broder_> cjwatson: mmm, yeah, i can get it kicked over to saucy. will try to kick it off today
[16:04] <cjwatson> Ta
[16:04] <doko> cjwatson, should we add updating that to the release opening procedures?
[16:05] <cjwatson> doko: Feel free (NewReleaseCycleProcess)
[16:06] <yofel> doko: lintian removal uploaded
[16:07] <doko> yofel, thanks!
[16:07] <chiluk> infinity, in regards to the apt sru...  sorry about that...
[16:08] <chiluk> I swear I checked my bzr patch/commit, and didn't think that debuild -S would muck with the sources... I'll check my debdiff next time.
[16:09] <Riddell> doko: yofel: could it be made a recommends?
[16:09] <yofel> Riddell: afaik the buildd's use --no-install-recommends
[16:09] <yofel> but maybe I'm wrong
[16:09] <yofel> doko: ^ ?
[16:09] <doko> yofel, yes, recommends would work
[16:09] <doko>  1. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
[16:09] <doko>  1. Notify Evan Broder to update lintian.ubuntuwire.com.
[16:09] <doko>  1. Notify N.N. to update packages.ubuntu.com.
[16:09] <doko> cjwatson, ^^^
[16:10] <Laney> Rhonda
[16:10] <doko> for packages?
[16:10] <Laney> yep
[16:10] <yofel> doko: oh ok, then I'll make that a recommends instead
[16:10] <doko> Gerfried Fuchs?
[16:10] <Laney> correct
[16:10] <Laney> It says that on the index of p.u.c IIRC
[16:12] <Riddell> thanks yofel
[16:15] <infinity> chiluk: Well, perhaps I should reject it and we should re-do it.  It's a pretty painful diff as it stands.
[16:22] <chiluk> infinity, that's fine with me... I'm up for figuring out how to do it better.
[16:24] <chiluk> infinity give me a few, I'll upload a new debdiff shortly.
[16:26] <chiluk> infinity the patch has already been correctly applied to lp:~ubuntu-core-dev/apt/precise .... do you still need a debdiff between the two revs?
[16:27] <doko> yofel, Riddell: one more thing, does qt4-x11 have the b-d on pkg-kde-dev for this convenience, or is it really needed?
[16:28] <yofel> doko: it needs it for the pkgkde_symbolshelper dh addon
[16:31] <doko> yofel, yes, which is a bit problematic, because pkg-kde-dev needs qt to build :-/
[16:31] <doko> so I think, I'll need to define a stage1 build for that to succeed ...
[16:31] <infinity> chiluk: Oh, if it's a small and sane patch in the branch, I can just reupload it without the cruft.  Gimme a sec.
[16:32] <chiluk> yeah ..
[16:32] <chiluk> it's rev 2009
[16:32] <yofel> doko: are we still talking about pkg-kde-tools? that doesn't need qt4 to build
[16:32] <chiluk> at lp:~ubuntu-core-dev/apt/precise
[16:32]  * yofel needs to run
[16:33] <chiluk> infinity I'm still trying to figure out how I could have generated the debdiff such that the cruft didn't get generated.
[16:33] <hallyn> slangasek: would you object to mountall adding nobootwait to the /sys/fs/fuse/connections and /sys/kernel/debug entries in /lib/init/fstab?
[16:34] <chiluk> infinity I bzr cloned the branch ... ran debuild -S... patched ran debuild -S... and ran the debdiff against the resulting .dsc files.
[16:34] <chiluk> are you saying I should have debuild -S -nc in both cases?
[16:34] <slangasek> hallyn: why should they be nobootwait?
[16:34] <infinity> chiluk: -nc would have worked.  Or using the same versions of autotools used in the previous build.
[16:34] <slangasek> hallyn: they're kernel filesystems, they should be available immediately and should not cause boot delays due to mounting
[16:35] <hallyn> slangasek: because they can't be mounted in a non-init user namespace
[16:35] <hallyn> slangasek: well ideally 'optional' would mean ignore failure to mount
[16:35] <hallyn> and i think it used to.  but since quantal it does not
[16:35] <slangasek> hallyn: then 'nobootwait' is definitely the wrong flag for this
[16:35] <hallyn> (in precise it does)
[16:36] <hallyn> the fstab manpage says optional is only optional if the fs is unknown, unfortunately.
[16:36] <hallyn> "fs is known, directory exists, but permission is denied" leads to hang
[16:36] <hallyn> would you feel ok with changing that?
[16:36] <slangasek> hallyn: 'optional' means 'ignore if the filesystem type is unsupported'
[16:36] <hallyn> (like i say, in precise it did not lead to a hang)
[16:37] <chiluk> infinity, are you looking at this debdiff? https://launchpadlibrarian.net/144802808/apt-fix-keep-alive.debdiff   because the only thing I see different is version number increments... my debuild -S was built with the same version of the tools.... sorry for being a noob with debian packagin.
[16:38] <hallyn> slangasek: it also will ignore if the dir does not exist
[16:38] <hallyn> (not according to the manpage, but if i read the code correctly)
[16:38] <slangasek> hallyn: the behavior of treating mount failures as errors is quite deliberate; though it gets dicey when the failure is for a kernel filesystem, because that means you never get to plymouth to bypass the prompt.  Let me check some history on this
[16:39] <slangasek> hallyn: so the right option here would be 'nofail'
[16:39] <infinity> chiluk: I'm looking at the one uploaded.
[16:39] <slangasek> however, see also bug #610869
[16:40] <zul> mterry:  ping
[16:40] <hallyn> slangasek: that doesn't work
[16:40] <infinity> chiluk: http://launchpadlibrarian.net/145039448/apt_0.8.16~exp12ubuntu10.11_0.8.16~exp12ubuntu10.12.diff.gz
[16:40] <mterry> zul, hi
[16:40] <infinity> chiluk: Was that rebuilt by a sponsor, perchance?
[16:40] <infinity> chiluk: Cause your debdiff is fine, I agree.
[16:40] <slangasek> hallyn: it doesn't /work/, but it's the right flag to use ;)
[16:40] <hallyn> ok
[16:40] <slangasek> hallyn: mountall just needs to be fixed so that 'nofail' DTRT
[16:40] <zul> mterry:  quantum and quantumclient got renamed to neutron and neutronclient whats the process for the MIR stuff for a source rename?
[16:40] <hallyn> slangasek: well the manpage says "ignore errors for this device if it does not exist"
[16:41] <chiluk> infinity, yeah bdmurray was likely the sponsor.
[16:41] <hallyn> slangasek: i'm fine using nofail, just saying it doesn't 100% match the manpage
[16:41] <slangasek> hallyn: also, bug #1152274
[16:41] <infinity> chiluk: Ahh, kay.  I'll re-sponsor it sans cruft.
[16:41] <mterry> zul, you could file it and say such and it would be rubber stamped, alternatively maybe just poke an archive admin
[16:41] <slangasek> ah; I think that should be changed in the manpage
[16:42] <zul> mterry: ok cool
[16:42] <slangasek> because with mountall, if the device doesn't exist there's never an error at all
[16:42] <hallyn> slangasek: yeah i could repurpose that bug...
[16:42] <chiluk> alright thanks infinity it's committed cleanly in the repo.
[16:42] <hallyn> slangasek: would you want me to use that bug and provide a patch to use nofail?
[16:43] <hallyn> slangasek: (or had you already started that?)
[16:43] <infinity> zul: It doesn't need an MIR at all, if it's a straight rename.
[16:43] <infinity> zul: Will need a bit of a NEW review for sanity, that's all.
[16:43] <zul> infinity:  sweet
[16:43] <slangasek> hallyn: well, that bug report is specifically about the silence of the hang; I wouldn't repurpose that bug, but if you're digging in this area of the code maybe you want to fix that bug too :)
[16:43] <slangasek> hallyn: I'm happy for you to provide a patch to use nofail for these two mountpoints and to make nofail DTRT
[16:44] <hallyn> slangasek: well, i only mentioned the two - alas /sys/kernel/security is also a problem for me
[16:44] <hallyn> slangasek: alternatively, we could say "if in a container, ignore any kernel fs mount failures"
[16:45] <slangasek> I wouldn't want to say that as a policy
[16:45] <slangasek> however, you *could* override the mount options for these in /etc/fstab
[16:45] <slangasek> that way, the container setup can configure things precisely for the way the container works, and mountall doesn't have to concern itself with the differences (which may change over time)
[16:46] <hallyn> slangasek: well long as we're bastardizing the container I can just do /lib/init/fstab as well - we used to do that in maverick days.  problem is that leads to different rootfs for in or out of a container
[16:46] <slangasek> ah
[16:47] <slangasek> are there any container support packages included in the container root?
[16:47] <chiluk> infinity, make sure to give me credit for the upload  ... I'd like to start applying for ubuntu-contributing dev here soon
[16:47] <hallyn> certainliy nofail makes sense for debug and fuse/connections.  but from a hardware install pov, /sys/kernel/security seems inappropriate to be nofail :)
[16:47] <slangasek> that is, packages which wouldn't be included in a standard system that's not being used as a container
[16:47] <hallyn> slangasek: container creation no longer does any container-specific package install
[16:48] <slangasek> right, making some of these nofail for non-container systems does make me a little anxious ;)
[16:48] <hallyn> stgraber pushed a lot of that back to mountall/upstart etc
[16:48] <hallyn> i suppose 'containernofail' could be added as a mount option :)
[16:48] <slangasek> I'd really prefer not having to make mountall.c know what a container is
[16:48] <hallyn> yeah
[16:49] <hallyn> as an upstream-unacceptable fix we could have the kernel return success for those mounts and do a tmpfs mount :)
[16:49]  * hallyn thinking outside the box like a pro
[16:50] <slangasek> how about making them disappear from /proc/filesystems within the container? ;)
[16:51] <infinity> chiluk: Also, from an "ew, ick" stylistic perspective, there's no readon to have the multi-maintainer header [ Bob Smith ] in an upload where the only change is by Bob Smith, and the uploader is also Bob Smith.
[16:51] <hallyn> note it's not just 'in a container' but in a non-init user namespace.  lemme see how the code loks for that
[16:52] <slangasek> hallyn: I don't understand the distinction there
[16:52] <infinity> chiluk: I think I'll twiddle that before I upload, just because I'm OCD.
[16:52] <chiluk> fine with me.
[16:53] <chiluk> when I wrote the changelog entry, I think I was looking at the earlier changelog entries..
[16:54] <infinity> chiluk: As a general rule, dch will DTRT and only add that header if someone else has done a change in the same version.
[16:54] <chiluk> ah ok...
[16:55] <bdmurray> barry: could you have a look at bug 771404 which is similar to bug 846044 which you worked on?
[16:58] <hallyn> slangasek: if you do clone(CLONE_NEWUSER), the cloned task cannot mount those filesystems
[16:58] <hallyn> now really, so long as all the files will be owned by host root, i suppose we coudl simply enable those mounts
[17:00] <slangasek> hallyn: and why would you run clone(CLONE_NEWUSER) and expect to run mountall under it?
[17:01] <hallyn> slangasek: so as to run a container inside a user namespace
[17:01] <hallyn> why *wouldn't* i? :)
[17:06] <hallyn> yeah lemme try just adding FS_USERNS_MOUNT to those file_system_type defs
[17:11] <Elv1313> Hi, what is the official Contact API if I want to access Contacts from my Ubuntu Phone application?
[17:12] <slangasek> hallyn: so is the point there that this doesn't affect *all* containers, only those using CLONE_NEWUSER?
[17:12] <cjwatson> rbasak: We need another php5 merge to introduce dh-php5, I'm afraid.  Do you want to do that or shall I?
[17:12] <hallyn> slangasek: correct.  normal containers start fine
[17:12] <cjwatson> rbasak: (working through http://people.canonical.com/~ubuntu-archive/transitions/php5.5.html)
[17:12] <rbasak> cjwatson: I can do it tomorrow, before lunchtime, if you like? I'm >EOD now.
[17:13] <cjwatson> Cool, thanks
[17:13] <cjwatson> I'm EOD soon too
[17:13] <slangasek> hallyn: ah, ok.  So ideally we would ignore mount failures *only* when CLONE_NEWUSER is in place.. but I think we don't have a sane way to detect that
[17:13] <cjwatson> rbasak: (I also just merged json-c, so it should be possible to make php-json build soon.)
[17:13] <rbasak> I noticed Debian had updated since I started, but I figured that going from where I was would unblock things and I could catch up again at my leisure. Looks like I was wrong.
[17:14] <cjwatson> rbasak: It unblocked most of it and I was certainly able to move on, just not quite all
[17:14] <hallyn> slangasek: we could detect it with /proc/self/uid_map
[17:14] <hallyn> slangasek: but let me see if just allowing those mounts looks at all problematic
[17:14] <slangasek> hallyn: encoding that in mountall == not sane ;)
[17:14] <hallyn> slangasek: agreed
[17:15] <cjwatson> rbasak: In particular, xcache wants dh-php5
[17:15] <cjwatson> rbasak: The number of interleaved transitions here is ridiculous; I'll be glad to get it out of the way
[17:18] <infinity> chiluk: Re-uploaded.
[17:24] <jibel> barry, dep8 tests have been removed from codespeak-lib during latest sync, is it on purpose?
[17:45] <barry> jibel: no.  i guess they were missing from the debian packaging and i didn't see that.  i'll restore and get them into debian
[17:47] <jibel> barry, Great, thanks!
[17:54] <chiluk> awesome thankyou much infinity
[17:56] <infinity> chiluk: And accepted, since I spent all that time reviewing and nitpicking anyway. :P
[17:58] <chiluk> hah
[18:18] <mdeslaur> ogra_: hey! you can't do this: dump DBUS_SESSION_BUS_ADDRESS into ~/.dbus-session, so we can source it
[18:19] <ogra_> mdeslaur, thast exactly weht we do now and what we need to nort make all autopilot tests fail
[18:19]  * ogra_ cabnt type anymore, way to less sleep this week
[18:21] <ogra_> mdeslaur, i'm open for suggestions to fix it better ... just wont do it today anymore ... we need the dbus address in adb and ssh logins else the app tests cant run
[18:22] <mardy> kenvandine: hi! Did you see that I made that environment inheriting in dbus-test-runner optional? Could you review it?
[18:23] <mdeslaur> ogra_: oh, I see you've actually put it in ~/.cache/upstart and not ~/.dbus-session
[18:23] <mdeslaur> ogra_: that's a bit better...I'll think about it some more
[18:24] <ogra_> mdeslaur, there is a lot awful stuff in bashrc that sources such files, we need to find a sane way for this
[18:37] <kenvandine> mardy, yes... that worries me less
[18:48] <hallyn_> slangasek: that kernel patch works around the mountall hang, so I'll add that to my stash for now and see if I can get Eric to push it
[18:55] <slangasek> hallyn_: oh, there was already a kernel patch that addresses this?
[19:01] <hallyn_> slangasek: no, i wrote one
[19:01] <slangasek> ok
[19:02] <hallyn_> all the files end up owned by user/group -1, so no security issues
[19:11] <vlad_starkov> Question: Having RAID1 on 12.04 I just found out that sdb is failed now. But `ls /dev/ | grep sdb` shows only sdb, but it should show sdb sdb1 sdb2. Anyone know what's going on?
[19:12] <vlad_starkov> I mean, what could be cause of this issue?
[19:13] <slangasek> vlad_starkov: this question would be better placed in a user forum, but a disk failure could prevent the kernel from reading the partition table at all in which case you wouldn't see sdb1 sdb2
[19:16] <vlad_starkov> slangasek: I apologize for posting my question here. But I have almost emergency situation with unexpected disk failure on remote server in production. Just want to make sure that it is hardware failure. I changed these two disks about a month ego, they are new. Is it possible that it is not HDD failure but something else?
[19:18] <vlad_starkov> slangasek: I even can't read SMART. smartctl -a /dev/sdb returns ">> Terminate command early due to bad response to IEC mode page".
[20:47] <xnox> slangasek: don't you think overlayfs mounting /etc kind-of makes sense for cloud-images at boot?
[21:08] <slangasek> xnox: overlayfs mounting /etc> not really; we've always regarded read-only root as requiring a pre-configured /etc
[21:12] <xnox> ok.
[21:21] <lifeless> xnox: please god no, overlayfs is too fragile
[21:22] <lifeless> xnox: We're about to do the work needed to run read-only root on top of ubuntu cloud images, and our plan is to symlink the key files that we need to change, rather than any sort of overlay
[21:23] <slangasek> xnox: do you happen to know if other fscks besides e2fsprogs special-case / wrt fsck-after-mount?
[21:23] <xnox> lifeless: /me helped fixing bugs with upstart/etc-on-overlayfs, i'd also be happier without overlayfs layer there.
[21:24] <xnox> slangasek: not off the top of my head, no. but can keep an eye out for that when doing merges.
[21:25] <slangasek> I guess it wouldn't be obvious in a merge diff :)
[21:28] <xnox> slangasek: but i do reboot & fsck tests ;-)
[21:28] <xnox> so could read a bit of fsck source code.
[21:30] <ogra_> lifeless, tar up /etc ... mount tmpfs to /etc ... untar tarball ... better than having to maintain a growing number of links
[21:31] <xnox> ogra_: i'd think one would want reboot facility =)
[21:33] <ogra_> xnox, so you do the same on shutdown, just backwards
[21:34] <slangasek> I don't always preserve my system configuration across reboots; but when I do, I write it to my network card's EEPROM
[21:34] <ogra_> haha
[21:34] <xnox> slangasek: you must be working for Samsung! =)
[21:41] <dobey> what's the best way to deal with symbols for multiple libraries in a package? separate .symbols file for each? anyway to make dpkg-gensymbols NOT put all the symbols in a single file?
[21:42] <slangasek> separate .symbols files for each binary package
[21:45] <infinity> dobey: dpkg deals with symbols at the package level, not the library level.  If you want them separate, you probably also have a case where you want the libraries in their own packages. :P
[21:45] <infinity> (Given that putting multiple libs in one package is effectively calling that package a stable ABI)
[21:46] <dobey> infinity: the libraries *are* in their own packages. and i passed -p to gensymbols. but it listed all the symbols for all libraries (from debian/tmp/)
[21:46] <lifeless> ogra_: that locks you in a specific version of /etc, makes rebasing to a new release super hard.
[21:46] <dobey> infinity: i guess i don't understand why -p was meaningless :)
[21:47] <infinity> dobey: You might have wanted -p and -P
[21:47] <slangasek> dobey: because dpkg-gensymbols will still act on all the libraries it finds; you need to also pass -P to tell it which directory to scan
[21:48] <dobey> oh
[21:49] <infinity> Surely, some higher level debhelper friendliness gets this vaguely right without having to invole dpkg-gensymbols with voodoo?
[21:49] <infinity> Either way, the dpkg-gensymbols manpage is friendly enough, if a bit verbose.
[21:52] <dobey> infinity: yeah, --help is at least more helpful than the UsingSymbols wiki page
[21:55] <olli_> is there a good way to disable accessiblity in Saucy
[21:55] <olli_> uninstalling at-spi2-core seemed like a lazy way to do it, but the whole desktop depends on it
[22:09] <slangasek> olli_: what do you mean by 'disable accessibility'? stop the daemon from running?
[22:16] <olli_> slangasek, yep
[22:17] <slangasek> ok
[22:17] <slangasek> I don't know how to do that (if it's possible)
[22:17] <olli_> we are seeing one of the mir benchmarks fail with accessibility turned on
[22:18] <infinity> One would think that should be fixed...
[22:18] <olli_> infinity, from what I am told it's an issue in the test, happens on X and mir
[22:18] <olli_> but yes, needs fixing
[22:19] <infinity> Anyhow, an rgrep of /etc suggests you want /etc/xdg/autostart/at-spi-dbus-bus.desktop
[22:20] <infinity> olli_: ^ removing that should do it.
[22:21] <olli_> infinity, thx
[22:22] <TheMuso`> olli_: If the sesion is using upstart user session jobs, you may also want to look at disabling the job in /usr/share/upstart/sessions/.
[22:25] <olli_> TheMuso, we are on Saucy atm, so upstart shouldn't be an issue, should it? (unless I read my ps wrong)
[22:26] <infinity> olli_: saucy being the only release with user sessions? :)
[22:27] <olli_> robotfuel, infinity & TheMuso suggest to disable the init script or /usr/share/upstart/sessions/at-*
[22:27] <olli_> depending on whether the session is using upstart user session jobs
[22:28] <olli_> infinity, not sure I follow
[22:29] <infinity> olli_: I was responding to your "we are on Saucy atm, so upstart shouldn't be an issue", which made little sense, as saucy is the only release that *does* use user sessions.
[22:30] <olli_> infinity, yeah, figured my understanding of upstart user sessions was off
[22:30] <olli_> is off
[22:33] <olli_> robotfuel, having said that, forget the /etc change but use /usr/share/upstart/sessions instead
[22:42] <TheMuso> olli_: robotfuel_, both will need changing, since even if the upstart user session job for at-spi in /usr/share/upstart/sessions is disabled, the .desktop file in /etc/xdg/autostart will still be examined and processed.
[22:42] <TheMuso> The desktop file in the xdg dir existed long before the upstart job.
[22:46] <xnox> TheMuso: those xdg autostart files that are converted to upstart-session jobs, should drop an override file into /usr/share/upstart/xdg/autostart with Hidden=True.
[22:46] <xnox> TheMuso: such that only upstart job needs to be controlled, in an upstart user session.
[22:47] <xnox> TheMuso: olli_: to disable upstart job "echo 'manual' > ~/.config/upstart/at-spi2-registryd.override"
[22:48] <xnox> olli_: the autostart job shouldn't be a problem as long as the org.gnome.desktop.interface toolkit-accessibility is false in gsettings....
[22:58] <olli_> robotfuel_, ^
[22:58] <olli_> xnox, thx
[23:00] <xnox> olli_: in general one can drop override files for upstart user sessions in: /usr/share/upstart/session, /etc/xdg/upstart/, /etc/xdg-ubuntu/upstart (or any other dir in XDG_CONFIG_DIRS), ~/.config/upstart
[23:00] <xnox> olli_: all depends, if it's package level, system level, Desktop Environment level, user level.
[23:03] <olli_> xnox, thx, that's good to know
[23:03] <olli_> need it at system level or below
[23:03] <olli_> robotfuel_, will give it a spin
[23:04] <robotfuel_> xnox: thanks
[23:04] <TheMuso> xnox: Oh right, didn't know that, thanks.
[23:04] <TheMuso> xnox: I was wondering what that dir was for.
[23:06] <xnox> TheMuso: if we are running under upstart-user-session, we add that one in.... XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg to allow overriding parts that conflict or are racy.
[23:12] <TheMuso> xnox: Right, thanks for the heads up.
[23:29] <robotfuel_> most of the systems have passed the gtkperf test without freezing so it looks like sudo -u ubuntu gconftool-2 --set --type bool /desktop/gnome/interface/accessibility false might have disabled accessibility
[23:31] <TheMuso> robotfuel_: Gsettings is used exclusively for accessibility these days, I am surprised that worked.