=== salem_ is now known as _salem === Nisstyre-laptop is now known as Nisstyre [01:37] anybody home ? :P [01:39] 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] 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] NikTh: perhaps 'make config' or 'make oldconfig' wouldn't leave a pile of object files all over your kernel sources tree.. [01:42] 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] sarnold: Now I have ran only "fakeroot /debian/rules editconfigs" and uploaded the package for building. We will see. [01:46] 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] 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] 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] 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] 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] eg. https://wiki.ubuntu.com/PbuilderHowto [01:55] 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] 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] Ok, thanks for help. I have to leave now. [03:30] Good morning [03:47] stgraber: is there a standard way for a process to detect whether it's running in a container? [04:26] pitti / stgraber: Maybe adding an iscontainer to debianutils to accompany ischroot would be handy? [04:27] *nod* I tried to look at /proc/self/root, but that always seems to be / from inside the container [04:27] pitti: Oh, wait. /bin/running-in-container may be the trick. [04:27] oh, nice [04:32] 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] is /proc/1/environ containing "container=lxc" upstreamable? [04:35] pitti: indeed, if container=lxc is set in /proc/1/environ, that's the standard case that container-detect.conf handles [04:35] 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] if (putenv("container=lxc")) { [04:37] SYSERROR("failed to set environment variable"); [04:37] ah, nice [04:37] thanks slangasek [04:38] http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/start.c;h=aefccd6505008dc7681f90d5b271287ebd13f1b5;hb=HEAD#l684 === jono is now known as Guest50232 [05:08] 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] 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] jamespage: "ma" fails as well [06:02] good morning [06:04] yes [06:04] and then I tried running a 'make ios' at the command prompt, but that's presumably the same thing [06:04] er, wrong channel. [06:22] didrocks, ping [06:22] hey tvoss === Sp4rKy_ is now known as Sp4rKy [06:55] cjwatson, ScottK: LP's view of Debian is now up to date === Sweetsha1k is now known as Sweetshark === Trewas666 is now known as Trewas === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === smb` is now known as smb [07:37] wgrant: \o/ [07:57] pitti: The discussions of udev yesterday.. that didn't break udev monitor, via pyudev ? [07:57] 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] cjwatson: yeah, who knows when it'll migrate (yay for uncoordinated transitions). [08:05] Daviey: no, that was unrelated (both disabling udevadm during upgrade and disabling udevd startup in debootstrap) === achiang` is now known as achiang [08:17] pitti: Odd, ok - i'll try a rebuild. Thanks [08:25] 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] (for udevadm trigger disabling during upgrade) [08:26] gavinguo: re: your message to ubuntu-devel@, I have caused an unsubscribe message to be generated. You will need to confirm this === Ursinha is now known as Ursinha-afk [08:30] thanks for the upload cjwatson, I'm doing merges of all kde packages so working through them slowly === Ursinha-afk is now known as Ursinha === ckpringle_ is now known as ckpringle [09:07] xnox: Hey again. I've just discovered Debian #696096 (and #696506) which have an error message very similar to our's [09:07] Debian bug 696096 in src:qt4-x11 "qt4-x11 ia64 FTBFS only on the buildds" [Important,Open] http://bugs.debian.org/696096 [09:08] cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory [09:09] looks like adding "extra_configure_opts += -no-pch" is a workaround (but I don't know how dangerous it is) [09:12] mitya57: it will make the build a lot slower. === ivoks_ is now known as ivoks [09:53] hi to all! :) [10:28] 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. === doko_ is now known as doko === mmrazik is now known as mmrazik|lunch === MacSlow is now known as MacSlow|lunch [11:09] 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 === pete-woods is now known as pete-woods-lunch === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === pete-woods-lunch is now known as pete-woods === mmrazik|lunch is now known as mmrazik === MacSlow|lunch is now known as MacSlow [12:25] mvo: Are you around? [12:46] 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] jdoles: What are the package versions in the two - does Ubuntu have the package that debian has? [12:47] It is Debian bug 620800 [12:47] Debian bug 620800 in rpcbind "reduce startup blather" [Normal,Fixed] http://bugs.debian.org/620800 [12:48] In Ubuntu there are two duplicates for it and a combined heat of around 300. [12:48] Ubuntu bug 947638 [12:48] Ubuntu bug 835833 in rpcbind (Ubuntu) "duplicate for #947638 spurious syslog error message because of use of -w on boot [rpcbind.xdr / portmap.xdr : errno 2 (no such file)]" [Medium,Triaged] https://launchpad.net/bugs/835833 [12:49] wgrant: Thanks. [12:49] jdoles: Well Ubuntu has that debian package (albeit with some change) [12:51] penguin42: Ubuntu does not even have /etc/init.d/rpcbind [12:51] penguin42: likely because it used Upstart. [12:52] does commenting with # works in lightdm.conf? [12:52] penguin42: /etc/init/rpcbind-boot.conf contains nothing of use. [12:52] penguin42: how *does* Ubuntu start rpcbind? [12:54] Found it already. [12:55] penguin42: Ubuntu most definitely applied these changes. [12:55] penguin42: er not applied [12:56] 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)? === _salem is now known as salem_ [13:10] 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] 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 === wedgwood_away is now known as wedgwood [13:29] 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] lool: The less the scope creeps the more likely it is to happen ;-) [13:30] 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] 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] cool. thanks cjwatson [13:32] It's always fun talking to cjwatson because I always get pinged for him anyway [13:38] hmm, it would be interesting to know if cjwatson has also a highlight on cjohnston (due to tab-fail from others) :) [13:38] rsalveti: wooo! http://paste.ubuntu.com/5693714/ [13:38] it's not working outside the ubuntu chroot yet, but I suspect that has more to do with debuggerd running [13:38] thanks for getting the new kernel working [13:39] :-) === gusch is now known as gusch|brb [13:41] that issue is even mentioned in ... xchat changelog! https://launchpad.net/ubuntu/+source/xchat/2.8.8-7ubuntu2 [13:42] Mirv: nice work with Qt 5! [13:42] geser: I do not [13:42] (Qt 4 is broken by me at the moment) [13:49] mitya57: thanks :) [13:49] not for breaking Qt 4 though ;) [13:52] 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] cool. ARM problems are quite slow to debug indeed, except maybe a little nicer with some recent Cortex-A15 quad-core. [13:53] 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. === gusch|brb is now known as gusch [13:54] don't use pch [13:54] doko: ok. [13:55] doko: but will you fix them, please, anyway? =) === Ursinha is now known as Ursinha-afk [13:56] xnox, test case? [13:58] doko: qt4-x11 on armhf/powerpc (that's not a minimal test case though) [13:58] indeed === Ursinha-afk is now known as Ursinha [14:04] mvo: Hi. Are you around? [14:05] 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. === kentb-out is now known as kentb [14:24] jamespage: hi, did you see https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1157421/comments/5 ? [14:24] Launchpad bug 1157421 in blktap-dkms (Ubuntu Precise) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Fix committed] [14:25] I don't know what those errors mean and whether it is verification-done or verification-failed :) [14:25] mitya57, neither do I :-( sorry [14:26] jamespage: do you know someone who does? or who can test it independently? === Ursinha is now known as Ursinha-afk [14:28] * rbasak reads [14:28] I'd say that we need verification that there hasn't been a regression from a 3.2 user === Sweetsha1k is now known as Sweetshark === Ursinha-afk is now known as Ursinha [14:41] ev: cool [14:43] jodh: are you looking into merging json-c from debian? You have the TIL =) [15:06] xnox: we can't update any of upstarts dependencies until lp:~jamesodhunt/upstart/serialise-remaining-objects is reviewed. [15:15] jodh: correct. === mmrazik is now known as mmrazik|afk [15:19] 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/ existance, which causes that the services are not started on install... [15:21] jodh, slangasek: hey, does one of you know why the following appears to confuse mountall? [15:21] UUID=c9f13d56-0dcd-4bac-b913-ee3b81d5deac /home ext4 discard 0 1 [15:21] /home/stgraber/data/vm/lxc/lib /var/lib/lxc none bind 0 0 [15:23] 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] stgraber: can you run mountall with debug enabled and get the logs? [15:24] or if you have them already, paste them. It should build a tree and figure out the dependency.... [15:25] 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] 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] 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] 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] 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] but yeah, it's easy and doesn't inhibit booting. [15:58] stgraber: looks like mountall should indeed wait so we need to see the debug log. [16:02] jodh: ok, I'll reboot in a bit and grab the debug logs === salem_ is now known as _salem [16:18] apw, ogasawara: could you test kernel builds using the binutils from the ubuntu-toolchain-r repository? [16:18] 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:18] bug 1182613 in puppet (Ubuntu) "puppet completely broken on saucy" [High,Triaged] https://launchpad.net/bugs/1182613 [16:20] 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] /win 13 [16:22] 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] I plan to add a dep8 test soon. I did one for facter. Just not got as far as puppet yet. [16:22] rbasak, I did communicate for quantal and raring, nobody did listen [16:23] doko: not seen anything on the mailing list. [16:23] yes, same for mysql-4 [16:23] 5.5 [16:24] cjwatson: so wrt dd-list, were you wanting the list of affected packages by Debian maintainer or Ubuntu maintainer? [16:25] The former [16:25] 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] ok === _salem is now known as salem_ [17:15] TheMuso: can you add a regression potential statement to bug 1163638? [17:16] bug 1163638 in pulseaudio (Ubuntu Quantal) "pulseaudio fails to release card to jack" [Undecided,Fix committed] https://launchpad.net/bugs/1163638 [17:19] 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] 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] dpm, I will try to have a look tomorrow if nobody beats me, sounds like a good friday thing ;-) [17:21] ok, cool, I can wait, no worries. I understand how it works now, thanks! [17:28] Hey guys. [17:30] 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] 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] I know that I must change the name in debian/changelog file, but what characters I must add to avoid this problem ? [17:32] eg: 3.8.0-21.32-new~nikth will do the job or not ? [17:32] 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] you need to change the *binary* package name, either by changing the flavour or by changing the ABI [17:33] * cjwatson -> dinner [17:34] cjwatson : Thanks ! and .. Bon appetite :-) [17:36] 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] Be aware here that I had skipmodule=true and skipabi=true (inside debian/rules) to avoid building problems [18:49] Topic needs a replacement ? (hardy is not supported anymore - EOL) === racarr is now known as racarr|lunch === mmrazik|afk is now known as mmrazik [19:30] 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. === cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === racarr|lunch is now known as racarr [19:49] cjwatson: Thanks. I just changed the ABI version. We will see. :-) [20:31] mdeslaur: so, I feel like I am doing something wrong: http://paste.ubuntu.com/5694963/ [20:31] mdeslaur: I'm combining your patch with ted's upstart-app-launch [20:31] mdeslaur: and gedit is launching, but I don't think it should be based on the man page entry you added [20:31] jdstrand: oh, I definitely don't support wildcards [20:32] wildcards? [20:32] well, $APP_ID [20:32] that should evaluate to 'apparmor switch gedit' [20:32] jdstrand: yeah, I don,t support that [20:32] ok [20:33] well, if I change it to 'apparmor switch foo', the job still starts [20:33] but I didn't think it should, based on the man page [20:33] ok, I'll take a look [20:34] 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] mdeslaur: did you see this working another way? [20:34] abusing? [20:35] using 'apparmor switch $APP_ID' [20:36] well, I'll have to figure out how that's handled elsewhere in upstart if you want to do that [20:36] that's an environment variable? [20:37] mdeslaur: I don't think it's an environment variable... but maybe? [20:37] * jdstrand hasn't looked [20:37] jdstrand: ok, I'll figure it out [20:37] eg, in the modified job of ted's, he has 'env UBUNTU_APPLICATION_ISOLATION=1' [20:38] yeah, APP_ID=foo on the start command line creates an environment variable called APP_ID [20:38] it feels more like a variable declaration in upstart [20:38] ah, I see [20:38] but the apparmor_parser doesn't handle that [20:39] mdeslaur: so, on the one hand, it seems very clean from a job POV to support 'apparmor switch $APP_ID' [20:40] cause you just have one job file for this type of launcher [20:40] (ie, ted's /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec) [20:41] 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] s/on/of/ [20:42] 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] but not doing it means we need to have a different job file for each app [20:43] which may or may not be ok, but is contrary to ted's idea [20:44] mdeslaur: thoughts? ^ [20:45] I don't know, I'll think about it [20:46] mdeslaur: I was initially thinking that upstart would somehow resolve that internally, but now I see that makes no sense [20:47] well, it could [20:47] it's doing it for the instance stanza for example [20:48] ah, yes, true === francisco is now known as Guest84395 [20:52] mdeslaur: so, writing 'exec foo' to '/proc//attr/exec' will change profile to foo for ?r [20:52] no, it will change the profile for the next exec [20:53] ah [20:53] 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] huh, first time I see desktop-exec [20:55] we're not directly launching stuff now? [20:55] if we're going to use an external launcher, why even use upstart for this? [20:56] mdeslaur: this isn't in Ubuntu or anything yet. ted came up with http://gould.cx/ted/blog/Application_Centric_User_Experience [20:56] yeah, but the desktop-exec launcher is new to me, and wasn't part of the initial upstart job he showed me [20:56] mdeslaur: upstart gives certain things for free (see the blog) [20:56] hrm, maybe doing this with upstart is overkill now [20:57] mdeslaur: which this? [20:57] jdstrand: if we're already going to use an external launcher, why use upstart? just for application uniqueness? [20:58] jdstrand: anyway, let me look at why switch isn't working in user sessions to begin [20:58] mdeslaur: uniqueness and management. it's also possible to do the cgroups stuff sometime down the line, aiui [20:58] well, not if we're using an external launcher...that just took all the niceness out of it [20:59] 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] I don't see how it takes the niceness out of it [20:59] desktop-exec doesn't persist or anything [20:59] start and stop all work ok [20:59] * jdstrand doesn't understand the issue [21:01] mdeslaur: desktop-exec is a way to launch a .desktop file via upstart [21:01] it is very simple [21:02] perhaps too simple. 'start aa-app APP_ID=nonexistent' causes a core dump :) [21:04] 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] jdstrand: yes, that's why I said to wait until I fix it [21:05] mdeslaur: I didn't see that you said that, sorry [21:06] jdstrand: np :) [21:06] oh, hrm, a user can't see if apparmor is enabled in the kernel [21:06] /sys/module/apparmor/parameters/enabled is 600 [21:07] jdstrand: ok, I know why it doesn't work, and I'll work on it tomorrow [21:07] k [21:07] * jdstrand tries it with an existing profile [21:12] jdstrand: ok, need an updated kernel with a bug fix from jj [21:23] 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] mdeslaur: thanks [21:35] jdstrand: ok, I know how to make apparmor switch handle variables...I'll fix it and test it tomorrow morning [21:36] mdeslaur: neat :) [21:37] mdeslaur: fyi, the patch you gave me earlier worked fine just now [21:37] cool [21:41] mdeslaur: and yeah, commenting out the apparmor_available() bit makes it work [21:41] (for now) [22:03] bdmurray: Ah crap ok missed that, its not my bug so will have to bug the original reporter/patch filer. [22:06] doko: hey [22:07] hm, i should stop doing this and just write an email [22:10] jdstrand: lightly tested: http://paste.ubuntu.com/5695234/ [22:12] mwhudson, ? [22:13] doko: q about the python3 package [22:13] doko: i notice that it enables the --with-computed-gotos configure option [22:13] yes? [22:14] doko: but in my testing, unless you also disable CSE (-fno-gcse) it has no benefit [22:14] has anyone done testing with/without the flag? [22:14] I did enable this a long time ago ... [22:14] (even with no-gcse it seems a bit marginal on sandy bridge, it definitely helps on cortex-a9 though) [22:15] and after that, I did enable lto and pgo too [22:15] yes, those definitely help :) [22:15] I see that mans did ask to you check this for a single function/file? [22:15] oh yes, i need to reply to that [22:16] 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] doko: anyway, i just wanted to raise this fact: "--with-computed-gotos + default -O3 -> no benefit" [22:18] mwhudson, to make sure, you didn't enable pgo and lto in your tests? [22:18] doko: i've also backported --with-computed-gotos to 2.7 if you're at all insterested [22:19] doko: yes and no [22:19] doko: i've just checked out the v2.7.4 tag and built with various options [22:19] and i've also built debian packages with --with-computed-gotos with default O3 and with O3 & no-gcse [22:20] (and those did lto and pgo) [22:20] on x86, but the last ones not on armhf [22:20] mostly all on armhf [22:21] i've been building amd64 in my ppa but not actually doing a lot with that... [22:23] can we follow-up on that tomorrow/next week? it's late here [22:23] sure [22:23] i'll file a bug i guess [22:23] on python3.3 in ubuntu [22:23] saucy? [22:23] makes sense i guess [22:24] or maybe even debian i suppose... [22:24] well, I would like to start with current 4.8.x [22:25] * mwhudson blinks [22:25] doko: 4.8.x? [22:25] gcc-4.8 [22:25] oh gcc? [22:25] ahh right [22:25] yes makes sense [22:33] doko: https://bugs.launchpad.net/ubuntu/+source/python3.3/+bug/1183600 [22:33] Launchpad bug 1183600 in python3.3 (Ubuntu) "--with-computed-gotos optimizations probably nullified by cse" [Undecided,New] === kentb is now known as kentb-out [22:39] mwhudson: do you have a benchmark? [22:42] I think just disabling it for the one function is probably safer, can be done easily with gcc attributes === salem_ is now known as _salem [23:30] jtaylor: pystone is quite a good benchmark for this === bfiller is now known as bfiller_afk === jono is now known as Guest71790