[01:37] <NikTh> anybody home ? :P
[01:39] <NikTh> it is possible the fault because of that I had run "make xconfig" in current version ? => https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz
[01:41] <sarnold> NikTh: it's been absolute agest since I've compiled a kernel 'by hand', so I may be rusty, but that sounds exactly right
[01:42] <sarnold> NikTh: perhaps 'make config' or 'make oldconfig' wouldn't leave a pile of object files all over your kernel sources tree..
[01:42] <sarnold> NikTh: are you trying to make something that very closely approximates a distro kernel? or would the results of kernel-package's 'make-kpkg' utility do what you need?
[01:44] <NikTh> sarnold: Now I have ran only "fakeroot /debian/rules editconfigs" and uploaded the package for building. We will see.
[01:46] <NikTh> sarnold: I have history in here in the last few days.. LoL. I want to create a custom-ubuntu-kernel. Some patches included such as BFS & BFQ optimization ..etc
[01:48] <NikTh> I can build the kernel locally very easy. sarnold :The problem here is that I don't know and as it seems I cannot understand how the Launchpad virtual builders work. So Failedbuild logs are coming to me.. continuously
[01:49] <sarnold> NikTh: using a tool such as sbuild can help you get closer to a local environment like the buildds.. not perfect, but closer.
[01:52] <NikTh> sarnold: I use debuild as all documents suggest. I don't know the sbuild. I have no other problem now, only that Launchpad builders create FailedtoBuild logs all the time :P
[01:53] <wgrant> NikTh: Launchpad isn't designed as a test build service. You should try building in a clean environment locally using pbuilder or sbuild
[01:53] <wgrant> eg. https://wiki.ubuntu.com/PbuilderHowto
[01:55] <NikTh> wgrant: I always do this. pbuilder returns NO errors. It can build the package successfully.  I know tha launchpad builders are not for tests and that have other more important packages to build.
[01:56] <NikTh> Well this is one of my last times I try to upload my custom-kernel to my PPA. One , perhaps 1 or 2 more attempts and I will give up. :-)
[02:02] <NikTh> Ok, thanks for help. I have to leave now.
[03:30] <pitti> Good morning
[03:47] <pitti> stgraber: is there a standard way for a process to detect whether it's running in a container?
[04:26] <infinity> pitti / stgraber: Maybe adding an iscontainer to debianutils to accompany ischroot would be handy?
[04:27] <pitti> *nod* I tried to look at /proc/self/root, but that always seems to be / from inside the container
[04:27] <infinity> pitti: Oh, wait.  /bin/running-in-container may be the trick.
[04:27] <pitti> oh, nice
[04:32] <pitti> stgraber: ^ is any of this applicable to upstream LXC? it seems /run/container_type is created by /etc/init/container-detect.conf, i. e. is ubuntu specific
[04:33] <pitti> is /proc/1/environ containing "container=lxc" upstreamable?
[04:35] <slangasek> pitti: indeed, if container=lxc is set in /proc/1/environ, that's the standard case that container-detect.conf handles
[04:35] <slangasek> the /run/container_type is Ubuntu-specific, and is just there to avoid everything that cares having to reimplement container-detect.conf on Ubuntu
[04:37] <pitti>         if (putenv("container=lxc")) {
[04:37] <pitti>                 SYSERROR("failed to set environment variable");
[04:37] <pitti> ah, nice
[04:37] <pitti> thanks slangasek
[04:38] <pitti> http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/start.c;h=aefccd6505008dc7681f90d5b271287ebd13f1b5;hb=HEAD#l684
[05:08] <pitti> jamespage: do you know about the openvswitch DEP8 failure? https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-openvswitch/7/ARCH=i386,label=adt/
[05:09] <pitti> jamespage: the dkms test has some stderr output; either dkms should handle the absence of apport silently, or should depend on apport, or your test should pull in python(3?)-apport
[05:09] <pitti> jamespage: "ma" fails as well
[06:02] <dholbach> good morning
[06:04] <geofft> yes
[06:04] <geofft> and then I tried running a 'make ios' at the command prompt, but that's presumably the same thing
[06:04] <geofft> er, wrong channel.
[06:22] <tvoss> didrocks, ping
[06:22] <didrocks> hey tvoss
[06:55] <wgrant> cjwatson, ScottK: LP's view of Debian is now up to date
[07:37] <infinity> wgrant: \o/
[07:57] <Daviey> pitti: The discussions of udev yesterday.. that didn't break udev monitor, via pyudev ?
[07:57] <Daviey> I ask because the tail of this build failure suggests some udev issue, https://launchpad.net/~openstack-ubuntu-testing/+archive/havana/+build/4600555/+files/buildlog_ubuntu-saucy-i386.quantum_1%3A2013.2%2Bgit201305222014~saucy-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:58]  * Daviey pops afk for a bit
[07:58] <debfx> cjwatson: yeah, who knows when it'll migrate (yay for uncoordinated transitions).
[08:05] <pitti> Daviey: no, that was unrelated (both disabling udevadm during upgrade and disabling udevd startup in debootstrap)
[08:17] <Daviey> pitti: Odd, ok - i'll try a rebuild.  Thanks
[08:25] <pitti> slangasek, cjwatson: I added back the scripts, but I don't do an upload just for this. We don't even stop udev in preinst (just restart it in postinst), so there is really no real danger for packages to get this wrong, and no urgency
[08:25] <pitti> (for udevadm trigger disabling during upgrade)
[08:26] <sladen> gavinguo: re: your message to ubuntu-devel@, I have caused an unsubscribe message to be generated.  You will need to confirm this
[08:30] <Riddell> thanks for the upload cjwatson, I'm doing merges of all kde packages so working through them slowly
[09:07] <mitya57> xnox: Hey again. I've just discovered Debian #696096 (and #696506) which have an error message very similar to our's
[09:08] <mitya57> cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
[09:09] <mitya57> looks like adding "extra_configure_opts += -no-pch" is a workaround (but I don't know how dangerous it is)
[09:12] <xnox> mitya57: it will make the build a lot slower.
[09:53] <bl4de> hi to all! :)
[10:28] <cjwatson> infinity: FYI I promoted zziplib to satisfy texlive-bin; shouldn't need an MIR as a copy was previously bundled in the texlive-bin source package.
[11:09] <ev> mpt: are you in the office today?
[11:23]  * NikTh Thanks the awesome f...ing guys in here, who helped him to solve all sorts of problems
[12:25] <ion> mvo: Are you around?
[12:46] <jdoles> Why do I have to find that some bug has been fixed in Debian in 2011 and that this bug in Ubuntu still exists to this very date?
[12:47] <penguin42> jdoles: What are the package versions in the two - does Ubuntu have the package that debian has?
[12:47] <jdoles> It is Debian bug 620800
[12:48] <jdoles> In Ubuntu there are two duplicates for it and a combined heat of around 300.
[12:48] <jdoles> Ubuntu bug 947638
[12:49] <ScottK> wgrant: Thanks.
[12:49] <penguin42> jdoles: Well Ubuntu has that debian package (albeit with some change)
[12:51] <jdoles> penguin42: Ubuntu does not even have /etc/init.d/rpcbind
[12:51] <jdoles> penguin42: likely because it used Upstart.
[12:52] <GridCube> does commenting with # works in lightdm.conf?
[12:52] <jdoles> penguin42: /etc/init/rpcbind-boot.conf contains nothing of use.
[12:52] <jdoles> penguin42: how *does* Ubuntu start rpcbind?
[12:54] <jdoles> Found it already.
[12:55] <jdoles> penguin42: Ubuntu most definitely applied these changes.
[12:55] <jdoles> penguin42: er not applied
[12:56] <jdoles> What's the point of reinventing the wheel (Upstart) if you are not prepared to keep up with even Debian Stable (yes, Debian Stable has these changes)?
[13:10] <lool> cjwatson: on the topic of dev series, would it be known to Launchpad in the web UI and listed series in the API and such, or would just be an archive.u.c symlink?
[13:11] <lool> cjwatson: I'm asking because cjohnston is curious on whether the workitems tracker would have to cope with this and I'm also curious because we'd actually like to experiment with blueprints targeted at a stable series rather than moving across series, but it would like be fine to use something like an ubuntu-blueprints project with a single series there for experimenting
[13:29] <cjwatson> lool: It wouldn't be a separate series in LP.  LP would know about it but I don't think it would be exposed in the UI
[13:29] <cjwatson> lool: The less the scope creeps the more likely it is to happen ;-)
[13:30] <lool> cjwatson: either way is fine, was just wondering how much LP would know about it; I guess you're saying as little as technically possible, which is fine  :-)
[13:31] <cjwatson> Indeed.  Initially I'd just been planning a symlink created by the publisher, though I might have been persuaded to make uploads work too
[13:31] <cjohnston> cool. thanks cjwatson
[13:32] <cjohnston> It's always fun talking to cjwatson because I always get pinged for him anyway
[13:38] <geser> hmm, it would be interesting to know if cjwatson has also a highlight on cjohnston (due to tab-fail from others) :)
[13:38] <ev> rsalveti: wooo! http://paste.ubuntu.com/5693714/
[13:38] <ev> it's not working outside the ubuntu chroot yet, but I suspect that has more to do with debuggerd running
[13:38] <ev> thanks for getting the new kernel working
[13:39] <cjohnston> :-)
[13:41] <mitya57> that issue is even mentioned in ... xchat changelog! https://launchpad.net/ubuntu/+source/xchat/2.8.8-7ubuntu2
[13:42] <mitya57> Mirv: nice work with Qt 5!
[13:42] <cjwatson> geser: I do not
[13:42] <mitya57> (Qt 4 is broken by me at the moment)
[13:49] <Mirv> mitya57: thanks :)
[13:49] <Mirv> not for breaking Qt 4 though ;)
[13:52] <mitya57> Mirv: xnox said he'll look at Qt 4 (I can't because I don't have any ARM hardware capable of building Qt)
[13:53] <Mirv> cool. ARM problems are quite slow to debug indeed, except maybe a little nicer with some recent Cortex-A15 quad-core.
[13:53] <xnox> Mirv: mitya57: well I want doko to look into borked pch. I am suspecting it's the same thing that kills abi-compliance-checker for jodh in upstart.
[13:54] <doko> don't use pch
[13:54] <xnox> doko: ok.
[13:55] <xnox> doko: but will you fix them, please, anyway? =)
[13:56] <doko> xnox, test case?
[13:58] <mitya57> doko: qt4-x11 on armhf/powerpc (that's not a minimal test case though)
[13:58] <doko> indeed
[14:04] <ion> mvo: Hi. Are you around?
[14:05] <xnox> doko: yeah, should get you a more minimal one. But for example abi-comliance-checker -test fails which should be quite minimal. I'll try to get you even a smaller one.
[14:24] <mitya57> jamespage: hi, did you see https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1157421/comments/5 ?
[14:25] <mitya57> I don't know what those errors mean and whether it is verification-done or verification-failed :)
[14:25] <jamespage> mitya57, neither do I :-(  sorry
[14:26] <mitya57> jamespage: do you know someone who does? or who can test it independently?
[14:28]  * rbasak reads
[14:28] <rbasak> I'd say that we need verification that there hasn't been a regression from a 3.2 user
[14:41] <rsalveti> ev: cool
[14:43] <xnox> jodh: are you looking into merging json-c from debian? You have the TIL =)
[15:06] <jodh> xnox: we can't update any of upstarts dependencies until lp:~jamesodhunt/upstart/serialise-remaining-objects is reviewed.
[15:15] <xnox> jodh: correct.
[15:19] <roaksoax> slangasek: howdy!! so I was wondering what should I do with those packages which are not in debian and only have upstart jobs (no init scripts). dh_installinit is still checking for /etc/init.d/<service-symlink> existance, which causes that the services are not started on install...
[15:21] <stgraber> jodh, slangasek: hey, does one of you know why the following appears to confuse mountall?
[15:21] <stgraber> UUID=c9f13d56-0dcd-4bac-b913-ee3b81d5deac /home ext4 discard 0 1
[15:21] <stgraber> /home/stgraber/data/vm/lxc/lib /var/lib/lxc none bind 0 0
[15:23] <stgraber> jodh, slangasek: /home is a partition on encrypted LVM which gets mounted fine (well, usually, there's a race there I need to look into) but then I'd expect mountall to properly figure out that it can't mount the second entry so long as /home isn't mounted
[15:23] <xnox> stgraber: can you run mountall with debug enabled and get the logs?
[15:24] <xnox> or if you have them already, paste them. It should build a tree and figure out the dependency....
[15:25] <stgraber> xnox: I'd have to do quite a few tricks to be able to run mountall in debug mode against that but yeah, I'll do that if nothing obvious jumps at jodh or slangasek. My current feeling is that mountall doesn't understand bind mounts and so doesn't actually build a dependency tree for the source device and only does so for the mount point.
[15:27] <stgraber> and fixing mountall to wait for the source to be mounted may lead to new issues (as some people may want to bind-mount a directory to some other place before mounting something over the source directory...)
[15:28] <xnox> stgraber: hm. on normal systems one just modifies the mountall upstart job to include --debug + reboot and collect log from /var/log/upstart/
[15:29] <stgraber> xnox: ah didn't know that worked, I somehow assumed --debug would conflict with --daemon and so would prevent mountall from daemonizing (blocking the boot in the process)
[15:35] <xnox> stgraber: i had do that once, can't remember if i removed daemon or not (to keep it in the background for upstart to collect the log output) it may ended up in the upstart log and/or bootmessages.
[15:35] <xnox> but yeah, it's easy and doesn't inhibit booting.
[15:58] <jodh> stgraber: looks like mountall should indeed wait so we need to see the debug log.
[16:02] <stgraber> jodh: ok, I'll reboot in a bit and grab the debug logs
[16:18] <doko> apw, ogasawara: could you test kernel builds using the binutils from the ubuntu-toolchain-r repository?
[16:18] <rbasak> doko: it looks like my facter merge will fix bug 1182613. But please could you test your uploads in future? A dep8 test could help with that, too.
[16:20] <doko> rbasak, thanks for checking. please could you add one? puppet is supposed to be maintained by the server team. just trying to get rid of ruby1.8 (which should have happened long time ago)
[16:22] <roaksoax>  /win 13
[16:22] <rbasak> doko: sure - I'd expect the server team to maintain puppet. I had looked into any potential breakages with updating to puppet 3.x and was surprised to see that you bumped a major version without communicating with us.
[16:22] <rbasak> I plan to add a dep8 test soon. I did one for facter. Just not got as far as puppet yet.
[16:22] <doko> rbasak, I did communicate for quantal and raring, nobody did listen
[16:23] <rbasak> doko: not seen anything on the mailing list.
[16:23] <doko> yes, same for mysql-4
[16:23] <doko> 5.5
[16:24] <slangasek> cjwatson: so wrt dd-list, were you wanting the list of affected packages by Debian maintainer or Ubuntu maintainer?
[16:25] <cjwatson> The former
[16:25] <cjwatson> I don't expect the latter will be very useful, but the former would let us deal with things like orphaned packages in Debian quickly
[16:27] <slangasek> ok
[17:15] <bdmurray> TheMuso: can you add a regression potential statement to bug 1163638?
[17:19] <dpm> hey seb128, I'm new to this so I'm not sure I need to ping an archive admin or if it is something that they already do regularly: I've got a package for a personal project (qreator) in saucy's new queue. Would it be possible to get in the archive?
[17:20] <seb128> dpm, hey, no need to ping, queue is worked on on regular basis, it "just" require an archive admin to do a shift (a bit like sponsoring)
[17:20] <seb128> dpm, I will try to have a look tomorrow if nobody beats me, sounds like a good friday thing ;-)
[17:21] <dpm> ok, cool, I can wait, no worries. I understand how it works now, thanks!
[17:28] <NikTh> Hey guys.
[17:30] <NikTh> Question: What is the correct name to avoid the update of existing kernel ? As you can see (and with your help of course) I managed to upload and build correctly my custom-kernel to PPA: https://launchpad.net/~nick-athens30/+archive/custom-kernels
[17:31] <NikTh> The thing that is wrong here, is that it replaces (update) the current ubuntu kernel. I don't want this. Is not safe (IMO). I want a new kernel that the user must install by hand. (manually).
[17:32] <NikTh> I know that I must change the name in debian/changelog file, but what characters I must add to avoid this problem ?
[17:32] <NikTh> eg: 3.8.0-21.32-new~nikth will do the job or not ?
[17:32] <cjwatson> I don't have time to help properly now, but you're on the wrong track there; it has nothing to do with anything in debian/changelog
[17:33] <cjwatson> you need to change the *binary* package name, either by changing the flavour or by changing the ABI
[17:33]  * cjwatson -> dinner
[17:34] <NikTh> cjwatson : Thanks ! and .. Bon appetite :-)
[17:36] <NikTh> But the binary package name does not   depend on debian/changelog file ? Here with dch -i  I can specify the version and the final binary package has the name that I declare there.
[17:38] <NikTh> Be aware here that I had skipmodule=true and skipabi=true (inside debian/rules) to avoid building problems
[18:49] <NikTh> Topic needs a replacement ? (hardy is not supported anymore - EOL)
[19:30] <cjwatson> NikTh: debian/changelog specifies the source package name and the source package version (which is normally, although not always, equal to the binary package version).  Binary package *names* are determined primarily by debian/control, although much of the rest of debian/ goes into that too.
[19:49] <NikTh> cjwatson: Thanks. I just changed the ABI version. We will see. :-)
[20:31] <jdstrand> mdeslaur: so, I feel like I am doing something wrong: http://paste.ubuntu.com/5694963/
[20:31] <jdstrand> mdeslaur: I'm combining your patch with ted's upstart-app-launch
[20:31] <jdstrand> mdeslaur: and gedit is launching, but I don't think it should be based on the man page entry you added
[20:31] <mdeslaur> jdstrand: oh, I definitely don't support wildcards
[20:32] <jdstrand> wildcards?
[20:32] <mdeslaur> well, $APP_ID
[20:32] <jdstrand> that should evaluate to 'apparmor switch gedit'
[20:32] <mdeslaur> jdstrand: yeah, I don,t support that
[20:32] <jdstrand> ok
[20:33] <jdstrand> well, if I change it to 'apparmor switch foo', the job still starts
[20:33] <jdstrand> but I didn't think it should, based on the man page
[20:33] <mdeslaur> ok, I'll take a look
[20:34] <jdstrand> mdeslaur: so, am I abusing the implementation? I just tried to connect the dots between ted's upstart-app-launch and what you had
[20:34] <jdstrand> mdeslaur: did you see this working another way?
[20:34] <mdeslaur> abusing?
[20:35] <jdstrand> using 'apparmor switch $APP_ID'
[20:36] <mdeslaur> well, I'll have to figure out how that's handled elsewhere in upstart if you want to do that
[20:36] <mdeslaur> that's an environment variable?
[20:37] <jdstrand> mdeslaur: I don't think it's an environment variable... but maybe?
[20:37]  * jdstrand hasn't looked
[20:37] <mdeslaur> jdstrand: ok, I'll figure it out
[20:37] <jdstrand> eg, in the modified job of ted's, he has 'env UBUNTU_APPLICATION_ISOLATION=1'
[20:38] <mdeslaur> yeah, APP_ID=foo on the start command line creates an environment variable called APP_ID
[20:38] <jdstrand> it feels more like a variable declaration in upstart
[20:38] <jdstrand> ah, I see
[20:38] <mdeslaur> but the apparmor_parser doesn't handle that
[20:39] <jdstrand> mdeslaur: so, on the one hand, it seems very clean from a job POV to support 'apparmor switch $APP_ID'
[20:40] <jdstrand> cause you just have one job file for this type of launcher
[20:40] <jdstrand> (ie, ted's /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec)
[20:41] <jdstrand> on the other hand, it seems a bit messy in terms on implementation to resolve that env var to give to apparmor_parser
[20:41] <jdstrand> s/on/of/
[20:42] <jdstrand> now that I understand how it works, it would require a change to the parser, and APP_ID is fairly arbitrary, and we would need to do all kinds of input sanitization, etc, etc
[20:43] <jdstrand> but not doing it means we need to have a different job file for each app
[20:43] <jdstrand> which may or may not be ok, but is contrary to ted's idea
[20:44] <jdstrand> mdeslaur: thoughts? ^
[20:45] <mdeslaur> I don't know, I'll think about it
[20:46] <jdstrand> mdeslaur: I was initially thinking that upstart would somehow resolve that internally, but now I see that makes no sense
[20:47] <mdeslaur> well, it could
[20:47] <mdeslaur> it's doing it for the instance stanza for example
[20:48] <jdstrand> ah, yes, true
[20:52] <jdstrand> mdeslaur: so, writing 'exec foo' to '/proc/<pid>/attr/exec' will change profile to foo for <pid>?r
[20:52] <mdeslaur> no, it will change the profile for the next exec
[20:53] <jdstrand> ah
[20:53] <jdstrand> right, so in my job, /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec should be executed under the 'foo' profile
[20:55] <mdeslaur> huh, first time I see desktop-exec
[20:55] <mdeslaur> we're not directly launching stuff now?
[20:55] <mdeslaur> if we're going to use an external launcher, why even use upstart for this?
[20:56] <jdstrand> mdeslaur: this isn't in Ubuntu or anything yet. ted came up with http://gould.cx/ted/blog/Application_Centric_User_Experience
[20:56] <mdeslaur> yeah, but the desktop-exec launcher is new to me, and wasn't part of the initial upstart job he showed me
[20:56] <jdstrand> mdeslaur: upstart gives certain things for free (see the blog)
[20:56] <mdeslaur> hrm, maybe doing this with upstart is overkill now
[20:57] <jdstrand> mdeslaur: which this?
[20:57] <mdeslaur> jdstrand: if we're already going to use an external launcher, why use upstart? just for application uniqueness?
[20:58] <mdeslaur> jdstrand: anyway, let me look at why switch isn't working in user sessions to begin
[20:58] <jdstrand> mdeslaur: uniqueness and management. it's also possible to do the cgroups stuff sometime down the line, aiui
[20:58] <mdeslaur> well, not if we're using an external launcher...that just took all the niceness out of it
[20:59] <jdstrand> mdeslaur: I'm not advocating for desktop-exec btw-- it is just what was out there and I thought that is what you guys discussed :)
[20:59] <jdstrand> I don't see how it takes the niceness out of it
[20:59] <jdstrand> desktop-exec doesn't persist or anything
[20:59] <jdstrand> start and stop all work ok
[20:59]  * jdstrand doesn't understand the issue
[21:01] <jdstrand> mdeslaur: desktop-exec is a way to launch a .desktop file via upstart
[21:01] <jdstrand> it is very simple
[21:02] <jdstrand> perhaps too simple. 'start aa-app APP_ID=nonexistent' causes a core dump :)
[21:04] <jdstrand> mdeslaur: but going all the way back, 'apparmor switch foo' doesn't actually seem to fail like the man page says it will
[21:05] <mdeslaur> jdstrand: yes, that's why I said to wait until I fix it
[21:05] <jdstrand> mdeslaur: I didn't see that you said that, sorry
[21:06] <mdeslaur> jdstrand: np :)
[21:06] <mdeslaur> oh, hrm, a user can't see if apparmor is enabled in the kernel
[21:06] <mdeslaur>  /sys/module/apparmor/parameters/enabled is 600
[21:07] <mdeslaur> jdstrand: ok, I know why it doesn't work, and I'll work on it tomorrow
[21:07] <jdstrand> k
[21:07]  * jdstrand tries it with an existing profile
[21:12] <mdeslaur> jdstrand: ok, need an updated kernel with a bug fix from jj
[21:23] <mdeslaur> jdstrand: you can comment out the "silently fail if apparmor isn't available" check in apparmor.c if you want to try it without jj's updated kernel
[21:27] <jdstrand> mdeslaur: thanks
[21:35] <mdeslaur> jdstrand: ok, I know how to make apparmor switch handle variables...I'll fix it and test it tomorrow morning
[21:36] <jdstrand> mdeslaur: neat :)
[21:37] <jdstrand> mdeslaur: fyi, the patch you gave me earlier worked fine just now
[21:37] <mdeslaur> cool
[21:41] <jdstrand> mdeslaur: and yeah, commenting out the apparmor_available() bit makes it work
[21:41] <jdstrand> (for now)
[22:03] <TheMuso> bdmurray: Ah crap ok missed that, its not my bug so will have to bug the original reporter/patch filer.
[22:06] <mwhudson> doko: hey
[22:07] <mwhudson> hm, i should stop doing this and just write an email
[22:10] <mdeslaur> jdstrand: lightly tested: http://paste.ubuntu.com/5695234/
[22:12] <doko> mwhudson, ?
[22:13] <mwhudson> doko: q about the python3 package
[22:13] <mwhudson> doko: i notice that it enables the --with-computed-gotos configure option
[22:13] <doko> yes?
[22:14] <mwhudson> doko: but in my testing, unless you also disable CSE (-fno-gcse) it has no benefit
[22:14] <mwhudson> has anyone done testing with/without the flag?
[22:14] <doko> I did enable this a long time ago ...
[22:14] <mwhudson> (even with no-gcse it seems a bit marginal on sandy bridge, it definitely helps on cortex-a9 though)
[22:15] <doko> and after that, I did enable lto and pgo too
[22:15] <mwhudson> yes, those definitely help :)
[22:15] <doko> I see that mans did ask to you check this for a single function/file?
[22:15] <mwhudson> oh yes, i need to reply to that
[22:16] <mwhudson> but in my traces pyeval_evalframeex is so dominant in run time that pessimizing everything else to optimize that is still a win i think
[22:18] <mwhudson> doko: anyway, i just wanted to raise this fact: "--with-computed-gotos + default -O3 -> no benefit"
[22:18] <doko> mwhudson, to make sure, you didn't enable pgo and lto in your tests?
[22:18] <mwhudson> doko: i've also backported --with-computed-gotos to 2.7 if you're at all insterested
[22:19] <mwhudson> doko: yes and no
[22:19] <mwhudson> doko: i've just checked out the v2.7.4 tag and built with various options
[22:19] <mwhudson> and i've also built debian packages with --with-computed-gotos with default O3 and with O3 & no-gcse
[22:20] <mwhudson> (and those did lto and pgo)
[22:20] <doko> on x86, but the last ones not on armhf
[22:20] <mwhudson> mostly all on armhf
[22:21] <mwhudson> i've been building amd64 in my ppa but not actually doing a lot with that...
[22:23] <doko> can we follow-up on that tomorrow/next week? it's late here
[22:23] <mwhudson> sure
[22:23] <mwhudson> i'll file a bug i guess
[22:23] <mwhudson> on python3.3 in ubuntu
[22:23] <doko> saucy?
[22:23] <mwhudson> makes sense i guess
[22:24] <mwhudson> or maybe even debian i suppose...
[22:24] <doko> well, I would like to start with current 4.8.x
[22:25]  * mwhudson blinks
[22:25] <mwhudson> doko: 4.8.x?
[22:25] <doko> gcc-4.8
[22:25] <mwhudson> oh gcc?
[22:25] <mwhudson> ahh right
[22:25] <mwhudson> yes makes sense
[22:33] <mwhudson> doko: https://bugs.launchpad.net/ubuntu/+source/python3.3/+bug/1183600
[22:39] <jtaylor> mwhudson: do you have a benchmark?
[22:42] <jtaylor> I think just disabling it for the one function is probably safer, can be done easily with gcc attributes
[23:30] <mwhudson> jtaylor: pystone is quite a good benchmark for this