[00:02] <xnox> bdrung: waf upstream was never hostile to packaging waf in distros. they did accept debian-specific patches into upstream which debian maintainer claimed to mean "hostile". And while ftp-masters didn't accept waf into debian, i disagree with their resolution.
[00:04] <xnox> configure, which is generated using out-of-the-archive autoconf & possibly hand crafted aclocal with missing m4 files is a far bigger FTBFS / DFSG / build reproducibility problem them. Then a handful of python files compressed with bzip2 and uuencoded.
[00:05] <xnox> So I would not block packages on having waf in them.
[00:09] <xnox> http://lintian.ubuntuwire.org/quantal/tags/source-contains-waf-binary.html
[00:10]  * xnox goes to ping ubuntuwire about setting up raring lab
[00:13] <geofft> xnox: btw, you got my email about apt-mirror, right? Did you ever play with setting that up?
[00:15] <xnox> geofft: yes, I did. I did play around with it a little. Changing a few things around. But nothing published, nor running publically yet.
[00:15] <xnox> trying to find time for this project =))))
[00:16] <xnox> geofft: thank you though, a lot!
[00:17] <geofft> xnox: Sure (and thank broder, really). Just wanted to make sure I didn't fail to get you something you needed.
[00:24] <Bluefoxicy> hang on, there's been no power drop here
[00:24] <Bluefoxicy> why did my computer reboot
[00:29] <xnox> did you kick it to hard & it wiggled a power cable?
[00:30] <Bluefoxicy> don't know, someone says I timed out.
[00:31] <slangasek> cjwatson: hmm :/ why is -fno-stack-protector still needed?  I didn't find much explanation in the changelog for it, and it wasn't needed for gnu-efi's /own/ build
[00:31] <Bluefoxicy> my bios isn't set to turn power back on if I experience power loss, but I came back to a log-in screen on a fresh reboot.
[00:31] <Bluefoxicy> since I timed out, I assume unclean means of system run termination rather than update-manager deciding I should reboot without my input.
[00:46] <xnox> slangasek: it came up in the context of causing efilinux FTBFS, if gnu-efi is build without -fno-stack-protector. And cjwatson added comments in the gnu-efi explaining this now.
[00:46] <xnox> gnu-efi doesn't need it, but rdeps do =)
[01:40] <bdrung> xnox: a binary blob is not the preferred form of modification (in which the source code should be)
[04:58] <micahg> xnox: why shouldn't waf blobs be problematic in Ubuntu? aside from semantik, all of the packages are from Debian and should be fixed there, I think most are already, but since we don't have a raring lintian lab yet, we can't be sure
[05:05]  * micahg goes and repacks symantik
[05:07] <hyperair> symantik?
[05:08] <hyperair> hmm, mindmapping tool. interesting.
[05:22] <pitti> xnox: err, how so? I'm getting mails to it all the time
[05:22] <pitti> Good morning
[05:24] <pitti> xnox: ah, it's not<EMAIL_ADDRESS>but<EMAIL_ADDRESS>[05:29] <pitti> xnox: https://launchpad.net/~pitti has the correct address, too
[06:15] <gdane> hello
[06:16] <gdane> i am interest in some pxa270 ubuntu project
[06:16] <gdane> is someone work on it?
[06:17] <gdane> where i can find any info about?
[06:23] <sarnold> gdane: I haven't seen anything about that board specifically, but hopefully you'll find something useful here: https://wiki.ubuntu.com/ARM
[06:24] <gdane> Yes i use, thanks
[06:24] <gdane> ive read this
[06:24] <gdane> i mean may be someone worked with it before me
[06:25] <gdane> and did working kernel and rootfs
[06:26] <gdane> i have several debian dootfses and kernels for my pxa270 intel xscale
[06:26] <gdane> so i am wonder if someone did ubuntu project with it
[09:11] <pitti> doko, infinity: :any build deps don't work in Debian yet; do you happen to know when/whether that's planned?
[09:46] <xnox> bdrung: in that case snapshot upstream VCS, as packed waf binary only has some of the plugins & is processed to remove whitespace & uses tabs instead of space and has comments stripped.
[09:47] <xnox> micahg: the point I am trying to say that waf is not a blob but bz2 compressed source code, where as configure is obfuscated pre-generated code, which many packages do not regenerate.
[09:48] <xnox> configure is "plain-text" and is a bigger blob, imho.
[09:48] <xnox> pitti: ha =) my error.
[10:51] <cjwatson> slangasek: right, as xnox said - the problem is that gnu-efi builds a library which is linked into freestanding code in other packages, so ssp blows up at that later stage
[10:52] <infinity> pitti: Not sure, though in most cases, they really shouldn't be needed anyway.
[10:52] <cjwatson> pitti,doko,infinity: I was working just yesterday on sorting out Debian buildds to support :any, as it happens
[10:52] <cjwatson> I'm not quite there yet, since I haven't figured out enough of the relevant bits of wanna-build
[10:52] <cjwatson> I have sbuild working AFAICT
[10:53] <bdrung> xnox: we can regenerate the autotools files and we can manually modify them. i can't modify bz2 compressed stuff without extracting it. a problem arise if i want to patch that bz2 compressed code!
[10:54] <infinity> cjwatson: Until such a time as people think they actually want to allow multiarch buildds (which I'm still wary of as an "official" solution to anything), wouldn't it just be easier to strip :* and let 'er rip?
[10:54] <cjwatson> That's more or less what I plan to do in wanna-build, yes
[10:54] <cjwatson> For sbuild, well, I've already done the work - it was easier to backport the relevant dpkg patches to forked code
[10:55] <xnox> bdrung: autoreconf does not work on many packages. I have been bitten by that many times. /me dislikes how one build system is favoured over the other when exactly the same argument can be applied.
[10:55] <infinity> cjwatson: Oh, for sbuild, it may as well DTRT, sure.
[10:55] <infinity> xnox: Do we have ways to regen the waffy stuff with in-archive source?
[10:56] <infinity> xnox: What form it takes is vaguely irrelevant if we're shipping stuff we can't even pretend to be able to regenerate (and thus modify).
[10:56] <bdrung> xnox: autoreconf is not favoured over waf in point of getting it packaged. we just require to ship the  waf script in extracted form (so we could create patches against it)
[10:56] <xnox> infinity: there is no need to regen anything. but you can set WAFLIB= variable and point it to a dir where you can override any bit, as it will be prepented pythonpath.
[10:57] <infinity> xnox: Err, "no need to" is a meaningless statement when we're talking about software freedom.
[10:57] <diwic> pitti, hi, do you know why there is a "jockey" (and "meta-kde-telepathy") in https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-daily/+packages ?
[10:57] <infinity> xnox: You have no need to modify your kernel either, we'll stop shipping the source.
[10:57] <bdrung> why isn't there one build system that suites all needs?
[10:57]  * cjwatson contemplates a Debian release goal of having every autotoolsy package use dh-autoreconf
[10:58] <pitti> diwic: presumably a wrong manual build
[10:58] <xnox> infinity: waf script is bzip2 compressed python files, if you want to unpack & modify. It's a binary that produces it's own source code. If that's not DFSG-free, I'm not sure what is.
[10:58] <diwic> pitti, ok, I'll remove it then
[10:58] <pitti> diwic: for some reason, the "request build" page on +recipe pages always default to the alphabetically first PPA I can upload to, instead of the one I configured for autobuilds
[10:58] <infinity> Hrm, if this glibc 2.17 builds and passes the testsuite first try after I rebased about 100 patches, I'm going to be very shocked.
[10:58] <pitti> diwic: in most cases I change it, but I guess a manual build slipped through, sorry
[10:58] <diwic> pitti, so we should rename "alsa" to "qalsa" or so :-)
[10:59] <cjwatson> That said I wonder if it's bootstrappily sane for base-passwd to use dh-autoreconf.
[10:59] <infinity> xnox: Is there a reason it needs to be compressed, other than someone thinks that's cool?
[10:59] <diwic> pitti, although that would just put another ppa in the same spot
[10:59] <cjwatson> Maybe I can rationalise heavier build-deps for base packages now that we can cross-build packages sanely
[10:59] <bdrung> xnox: it not a DFSG problem, it's a "preferred form of modification" problem
[10:59] <infinity> cjwatson: I think packages lower down the stack get a pass.  There are still a couple that don't use debhelper at all, and I'm fine with that.
[10:59] <bdrung> s/it/it's/
[11:00] <cjwatson> Yeah, base-passwd doesn't use debhelper at the moment (in fact that was sort of a condition of me taking it over :-) ).  But I wonder if worrying about that for port bootstraps still makes sense given that all this stuff is Architecture: all.
[11:00] <cjwatson> Or at least Multi-Arch: foreign.
[11:01] <xnox> infinity: it's not necessory nor mandatory, is there a reason to decompress & repackage orig tarball, other that someone thinks they may need to modify it sometime in the future?
[11:01] <xnox> infinity: i can see how one thinks waf is similar to tarball-inside-tarball, but it's not.
[11:01] <OdyX> xnox: for Debian it's clear: http://wiki.debian.org/UnpackWaf FTP-masters ruled, sooo
[11:01] <infinity> cjwatson: Well, it still takes us one step further away from being able to do a scorched-earth make world.  Not that Debian has been able to do that for over a decade, but I still think it might be shiny if it was sort of possible.  Some day.
[11:02] <cjwatson> Seeing as dpkg uses debhelper it seems a bit pointless to worry about it
[11:02] <infinity> xnox: Well, there you go.  If Debian ftpmasters ruled, I'm happy to just follow suit.
[11:02] <xnox> OdyX: I respect ftp-masters decision for Debian. That does not mean I agree with it.
[11:02] <infinity> cjwatson: That could be fixed. :P
[11:02] <OdyX> xnox: the core of the issue is that you have to execute an untrusted blob to get the source.
[11:02] <pitti> cjwatson, infinity: :any> I committed doko's glib change to Debian's svn, but reverted the :any bit as current dpkg doesn't seem to like them
[11:02] <infinity> cjwatson: But yeah, I'm not sure it's worth worrying about either.
[11:02] <OdyX> you don't know what this blob could do.
[11:02] <cjwatson> pitti: Current dpkg is fine.  It's sbuild/etc. that breaks.
[11:03] <pitti> hm, /me upgrades his sid chroot then, it's already two days old
[11:03] <cjwatson> pitti: Build-depending on python:any, *specifically*, won't be possible in Debian until python is multiarched there
[11:03] <infinity> pitti: Our dpkg and Debian's don't have any divergence in this area (and haven't for months).
[11:03] <pitti> aah, so I guess that's the reason why dpkg failed
[11:03] <cjwatson> pitti: Build-depending on X:any is only permitted if X is Multi-Arch: allowed.
[11:03] <pitti> not because of :any, but because "python:any" is indeed not installed
[11:04] <pitti> thanks
[11:04] <infinity> pitti: python should be multiarched in experimental, if you want to upload there.
[11:04] <cjwatson> That's defined in MultiarchSpec, and there's a clearer table in MultiarchCross.
[11:04] <infinity> (At least, I think doko landed all of that)
[11:04] <xnox> OdyX: not really, the header of was script is plain text and uses python stdlib bz2 to decompress a stream, which is a folder with python files. I can write a C implementation that does it, if you wish and then further inspect the code.
[11:04] <cjwatson> You could upload but wanna-build will kick it out.
[11:04] <xnox> s/was/waf/
[11:04] <cjwatson> So I still wouldn't recommend it.
[11:04] <infinity> cjwatson: Oh, right. :P
[11:04] <pitti> infinity: indeed I do (experimental), thanks
[11:05] <infinity> xnox: I'm not sure what the point in arguing the point is.
[11:05] <pitti> cjwatson: *nod*, thanks; so I keep it reverted for now
[11:05] <cjwatson> pitti: You can test it locally against experimental with a reasonably current version of sbuild, but not yet upload it.
[11:05] <xnox> infinity: ack. i'll shut up.
[11:05] <pitti> Laney: ^ FYI
[11:05] <infinity> xnox: Our general goal is to always upstream as much of our stuff to Debian as we can, so doing things that Debian ftpmaster specifically doesn't allow is silly.
[11:05] <pitti> Laney: so it seems we won't have to carry that delta for very long at least
[11:06] <Laney> right; we will just need to remember to bump the BD version to get the experimental python
[11:06] <Laney> depending on when the buildd side gets deployed, of course
[11:07]  * cjwatson sends off the first half of the buildd side now
[11:13] <cjwatson> infinity: Hmm.  Having just tried to dh-autoreconf binfmt-support, it feels pretty weird on native packages.  Maybe I should turn that into non-native ...
[11:14] <infinity> cjwatson: It doesn't even make sense on native packages...
[11:14] <cjwatson> Well, it sort of does; you still want to keep current on the generated code
[11:14] <cjwatson> As it stands I reautotool before every upload, but it's a bit manual
[11:14] <infinity> Sure, but that should be in your clean target then, or some other pre-upload task.
[11:15] <cjwatson> I dunno.  I do like the consistency of having all my packages work kind of the same way as far as the autotools are concerned.
[11:15] <cjwatson> And all my non-native packages are now dh-autoreconfed, including the one that was 2.13 only until I beat on it
[11:15] <infinity> Just build-dep on dh-autoreconf and call it in clean with a hard failure if it's not there?
[11:16] <infinity> So it forces it to be called on source package generation? :P
[11:16] <cjwatson> There are some good reasons to call it at build time; it means that you get upstream autotools improvements even if you haven't uploaded for a while
[11:16] <cjwatson> Particularly relevant for config.guess/sub, but it's occasionally useful elsewhere
[11:16] <infinity> Yeah, true.
[11:29] <bdrung> cjwatson: for native package, you could just remove all the auto-generated files.
[11:33] <cjwatson> bdrung: I could.  The reason I decided I was uncomfortable with that for binfmt-support is that it means that anyone using that on other distributions will have to sort out the autotools stuff manually; and the fact that that is a concern for me is a good indication that it shouldn't actually be native in the first place.
[11:35] <infinity> cjwatson: Oh, see, yeah, that argument makes perfect sense.
[11:35] <infinity> (I do wonder if apt and dpkg should go non-native for similar reasons)
[11:41] <bdrung> cjwatson: yes (too many packages are native despite the fact that i could be used elsewhere)
[11:59] <infinity> ricotz: I have a few packaging changes to make to glibc 2.17 as well before I upload, but you should expect it in experimental tomorrow (or later today, I guess, but after I've slept), and raring in a few days, after the test rebuilt dust settles.
[12:05] <ricotz> infinity, alright, i am hoping to see it soon :)
[12:22] <ogra_> jodh`, hmm, just thinking about that serial stuff, what if someone has a serial tty that isnt used for console= at all ?
[12:24] <ogra_> i.e. i dont need kernel and boot messages but want a login via serial
[13:30] <doko> Laney, pitti, only python2.7 is multiarched, not 2.6
[13:30] <pitti> doko: that's fine, python is 2.7 in sid/exp anyway
[13:34] <ebischoff>  Hello people and happy New Year. Is it normal that libselinux1 libsemanage and libsemanage-common got installed on Raring? I thought Ubuntu was using AppArmor. I don't have these packages on Quantal.
[13:35] <cjwatson> ebischoff: Yes, because shadow is compiled with support for them in any case (from Debian).
[13:35] <cjwatson> The libraries in themselves don't hurt.
[13:37] <ebischoff> Sure they don't hurt. They are just losing space on the system and not needed. Couldn't "shadow" be compiled without that dependancy?
[13:37] <cjwatson> It could, but it doesn't seem worth the divergence.
[13:38] <pitti> there's two handfuls of other packages which also depend on libselinux1 anyway
[13:38] <ebischoff> OK. I disagree, but OK. Thanks for the answer and thanks also for all the great work.
[13:39] <cjwatson> (And it would mean that people wouldn't be able to take Ubuntu and drop in a kernel that uses the SE Linux security module instead.)
[13:39] <ebischoff> Good point. Although one could wonder why a kernel would depends on libraries :-).
[13:40] <cjwatson> It doesn't.
[13:40] <cjwatson> Indeed, as pitti says, libselinux1 was already in minimal Ubuntu chroots in Quantal.
[13:40] <jdstrand> actually, selinux is available via kernel boot parameter
[13:40] <cjwatson> You've made a mistake somewhere if you believe that it wasn't there before.
[13:40] <cjwatson> libsemanage1 and libsemanage-common are new.
[13:40] <ebischoff> ah, correct, I compared only libsemanage ones
[13:41] <ebischoff> # dpkg -l | grep libsel
[13:41] <ebischoff> ii  libselinux1:amd64                     2.1.9-5ubuntu1                           amd64        SELinux runtime shared libraries
[13:41] <pitti> Size: 6202 (-common) -> hardly worth the effort again, I guess
[13:41] <ebischoff> I learned something, thanks.
[13:41] <tjaalton> ~150kB all three combined
[13:41] <cjwatson> Given upstream changes in shadow, IIRC, disabling libsemanage in shadow was going to effectively require ripping out selinux support entirely when it was previously present
[13:41] <cjwatson> And I wasn't wild about possible regressions for people in doing that
[13:41] <cjwatson> jdstrand: thanks
[13:42] <jdstrand> fwiw, that is my resollection
[13:42] <jdstrand> recollection
[13:42] <tjaalton> it should be, yes
[13:42] <jdstrand> that had one way of doing selinux in shadow, then ripped it out and did it with libsemanage
[13:42] <ebischoff> OK, thanks for the detailed answer everyone. And thanks again for the great work.
[13:43] <jdstrand> it wouldn't be trivial to revert to the old way
[13:44]  * cjwatson completes the stuff he meant to do yesterday evening and ran out of time for, and now wonders what he was actually going to do today ... sigh
[13:45] <ebischoff> best && goodbye
[13:45] <tjaalton> cjwatson: the change to precise livecd-rootfs to pull xorg backport? :)
[13:49] <cjwatson> tjaalton: mm, yeah, I seem to have been putting that off ...
[13:50] <tjaalton> cjwatson: should I push this to bzr? http://pastebin.com/b3gzhpnf
[13:50] <jdstrand> cjwatson: that is an interesting problem you have :)
[13:50] <tjaalton> don't mind if you do it the way you prefr
[13:50] <tjaalton> +e
[13:50] <cjwatson> tjaalton: that doesn't look right
[13:51] <cjwatson> it'll end up with both stacks
[13:51] <cjwatson> I don't see a reason to put this in the "live" phase
[13:51] <cjwatson> "install" should work better, but needs testing
[13:52] <tjaalton> cjwatson: no, the package will replace the old stack
[13:52] <tjaalton> can't have both installed
[13:52] <cjwatson> tjaalton: But it will go horribly wrong if you do it in the live phase, trust me
[13:52] <tjaalton> ok :)
[13:52] <cjwatson> Ubiquity will get very confused
[13:53] <cjwatson> This is intended to be part of the installed system; it does not belong in the live phase, which is for things that will generally be removed after copying the livefs to the target
[13:53] <tjaalton> but this is for hw enablement..
[13:53] <cjwatson> Why does that mean you'd want it to be removed after copying to the target system? :)
[13:54] <cjwatson> The live phase just makes no sense heree
[13:54] <cjwatson> *here
[13:54] <tjaalton> ok ok
[13:54] <tjaalton> maybe I got it backwards
[13:56] <cjwatson> live contains stuff like the installer, language packs most of which are going to be removed, casper which we don't want on the target system, etc.
[13:56] <mdeslaur> seb128: mind if I merge gnupg2?
[13:58] <seb128> mdeslaur, hey, did I touch that last? please go for it, I hate the TIL concept (more often that not you touch something for a random reason and gets sticky) ;-)
[13:58] <mdeslaur> seb128: yep, you did :) thanks.
[13:58] <cjwatson> tjaalton: you might have been misled by the signed kernel being in live - it's there because there are many systems for which we don't want it installed.  Things that we conditionally install are often easiest to have in live.  But it's there because it's the signed kernel, not because it's an enablement kernel
[13:59] <seb128> mdeslaur, thank *you* ;-)
[13:59] <mdeslaur> seb128: yeah, now I've caught the TIL disease :)
[13:59] <tjaalton> cjwatson: yeah, it's the mention of the backport kernel.. so wrong package to touch?
[14:00] <cjwatson> tjaalton: Wrong package to use as a model for this
[14:01] <cjwatson> tjaalton: I'm testing a build with http://paste.ubuntu.com/1516802/ now - will probably take an hour or two
[14:02] <tjaalton> cjwatson: ah, now I get it :)
[14:02] <tjaalton> sheesh
[14:02] <tjaalton> things you forget in a week
[14:11] <Laney> d
[14:21] <cjwatson> tjaalton: Hmm, nope, this installs xserver-xorg-lts-quantal and then installs xserver-xorg and removes the former ... I thought xorg had been fixed not to do that
[14:21] <cjwatson> Oh, blah, it's probably got something to do with the task
[14:21] <cjwatson> This will be painful
[14:21] <tjaalton> :/
[14:22] <tjaalton> but renames are great! :)
[14:22] <cjwatson> hate you all
[14:22] <tjaalton> hehe
[14:22] <Myrtti> ♥
[14:25] <mlankhorst> :/
[14:25] <cjwatson> I think I will have to expand the task by hand and hope that that doesn't cause anything else to blow up
[14:25] <mlankhorst> wasn't me who decided on the rename route!
[14:26] <mlankhorst> anyhow installing xserver-xorg will remove -lts-quantal, which is correct :-) xserver-xorg-lts-precise is just a convenience alias since otherwise input-all and video-all don't get pulled in
[14:26] <cjwatson> Sure, but it's not what you actually want for this image
[14:27] <cjwatson> I'm not arguing about the correctness of the package metadata heree
[14:27] <cjwatson> Although I still hate you all
[14:31] <mlankhorst> well that's your job, I know you don't mean it :-)
[15:26] <caribou> what is the process to get a package (kdump-tools) in main when its source package (makedumpfile) is already in main ?
[15:26] <caribou> the MIR wiki page says that a MIR is not required for those
[15:28] <seb128> caribou, get something in main to (build-)depends on or recommends it
[15:28] <pitti> caribou: by and large, upload something to main which depends on it
[15:28] <cjwatson> or get a core-dev to seed it somewhere if it should be a top-level item
[15:29] <caribou> seb128: pitti cjwatson thanks for the tips
[15:33] <micahg> caribou: you also want to make sure that it wasn't left out of main for a reason, the original MIR usually mentions these things if that's the case
[15:33] <caribou> micahg: I think it's not in main because it's not systematically being used
[15:33] <caribou> micahg: but thanks for the detail
[16:21] <ogra_> pitti, ev, is anything in whoopsie or apport using gksudo ? bug 1098235 is the third one i see around this issue and i thought everything uses pkexec
[16:45] <pitti> ogra_: I ported apport from gksudo to polkit (pkexec) in quantal
[16:50] <ogra_> pitti, right, i also see the changelog, pkexec doesnt have any issues with onboard (and definitely doesnt blacken the screen), so i'm a bit confused
[16:51] <pitti> ogra_: I don't see a package hook with gksu either (at least not on my amd64 system)
[16:52] <ogra_> we dont have anything like bug buddy anymore, right ? it must be apport they are seeing there
[16:52] <ogra_> i guess i'll just sit down tomorrow and try to reproduce it
[16:55] <pitti> no, no bug buddy; KDE has its own crash handler, and Firefox does
[16:55] <pitti> but neither grab the keyboard
[16:55] <pitti> and even for apport, you rarely will see hooks needing root privs
[16:57] <ogra_> no, the keyboard (well, focus) grabbing is clearly gksu
[16:57] <ogra_> it is known to be broken with onscreen kbd
[16:57] <ogra_> but something seems to trigger it nontheless when "report this problem" is selected
[16:59] <pitti> ogra_: the three things which are still knowingly using it are xdiagnose, update-notifier, and ubuntu-nexus7-installer
[16:59] <ogra_> yeah, i wonder if any hook calls xdiagnose or some such
[17:00] <ogra_> ubuntu-nexus7-installer isnt in the archive
[17:00] <pitti> *mumble* gksu must die *mumble*
[17:00] <ogra_> ++
[17:00] <ogra_> quickly ...
[17:00] <ogra_> well, not die but be shot into the universe
[17:01] <ogra_> i was actually hoping we could do that this release
[17:01] <bdmurray> pitti, ev: bug 1098250
[17:01] <ogra_> anyeway, thaks pitti, i'll go on researching that part
[17:02] <pitti> and with that, bonne nuit tout le monde!
[17:02] <ev> nice spot
[17:02] <bdmurray> ogra_: is there anything in /var/crash?
[17:03] <bdmurray> ev: I sometimes wish whoopsie had a log file...
[17:03] <pitti> hm, what should we use as a dupe signature?
[17:03] <ogra_> bdmurray, no idea, i'll ask the reporter ...
[17:03] <pitti> machine vendor/product or so? but even that isn't guaranteed to be the same problem
[17:04] <ev> hmm
[17:05] <ev> maybe the kernel guys would have a better idea?
[17:05] <ev> my naive thought would be concatenation of the various SMBIOS and PCI IDs that are relevant here
[17:06] <ev> that it would be more useful if it underrepresented the number of systems affected equally than if it lumped every Dell together
[17:06] <pitti> I subscribed apw to the bug with a question
[17:07] <rbasak> barry: re bug 1097783, thanks. That was quick!
[17:07] <ev> bdmurray: doesn't it log to /var/log/upstart/whoopsie.log?
[17:07] <ev> pitti: cheers
[17:09] <apw> pitti, bug # ?
[17:12] <bdmurray> ev: not with communication details
[17:12] <bdmurray> apw: bug 1098250
[17:13] <ev> bdmurray: oh, consider that a bug :)
[17:14] <ev> it's probably sending to stdout instead of stderr, or whichever upstart cares about
[17:16] <apw> ev, what symptoms does the error here actually detect?
[17:18] <smb> apw, Good question. One might guess dmesg....
[17:18] <bdmurray> apw: its /usr/share/apport/apportcheckresume
[17:20] <apw> ok so this is one of those where we suspended and then had to reboot
[17:20] <apw> so there is no stack ... tricky
[17:22] <apw> ev, so we are looking for something to identify the machine, so perhaps the list of devices and machinetype
[17:22] <Laney> ogra_: Pretty sure that bug refers to update-notifier.
[17:22] <Laney>       invoke_with_gksu(CRASHREPORT_REPORT_APP,
[17:22] <Laney>                               _("<span weight=\"bold\" size=\"larger\">Please enter your password to access problem reports of system programs</span>"),
[17:23] <ev> apw: will that not be too wide a match?
[17:23] <ev> that is, can you do anything with "Dell XPS whatever machines failed to suspend 343028 times in Quantal"
[17:24] <apw> ev, right thats why i am saying 'dell XXX with these 10 devices'
[17:24] <ev> ah right
[17:24] <apw> as most likely it has to be related to wahts in the machine
[18:14] <cjwatson> tjaalton: well, this at least builds now, and includes the enablement stack and not the precise one; I still want to do a bit more comparison with a stock image though, as switching to metapackages is a fairly considerable change
[18:19] <dkessel> hello guys. when would you think would be a good time to submit an apport crash report for signon-ui ? i have tried two times now, but apport always refuses/fails to retrace the stacktraces and closes the bugs automatically...
[18:19] <dkessel> i don't want to submit a bug the third time only to see apport retracing fail a third time...
[18:21] <tjaalton> cjwatson: nice :)
[19:16] <bdmurray> mterry: there are 2 uploads of duplicity in the quantal -proposed queue, yours is the newer of the two.  the other upload fixes bug 1013446
[19:17] <mterry> bdmurray, oh, that was SRU'd?  I didn't notice.
[19:18] <mterry> bdmurray, you know what, hold up on mine, and let that one through.  I want to triple-confirm the fix I put in for corruption
[19:18] <bdmurray> mterry: well it hasn't been approved for quantal yet and there seems to be an issue with the precise upload so it could use reuploading
[19:19] <mterry> bdmurray, which one could use re-uploading?
[19:19] <bdmurray> the fix for bug 1013446 to precise
[19:23] <smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/643289 is 'triaged' for precise. my test just now seems to agree with that (it seems not fixed in precise).
[19:23] <smoser> were you planning on fixing that in precise?
[19:30] <bdmurray> mterry: so I'll reject your upload of duplicity to quantal and review / approve the one fixing bug 1013446 and if you upload the new precise debdiff to the queue I'd be happy to look at it too
[19:32] <mterry> bdmurray, OK
[19:40] <slangasek> cjwatson, xnox: ok, thanks for the clarification.  FWIW the gnu-efi in raring is still broken in some manner I haven't yet identified, as it makes shim unusable (but not unbuildable).
[20:04] <cjwatson> slangasek: was that something I broke?
[20:04] <slangasek> cjwatson: no, it's my doing
[20:04] <slangasek> I was vaguely hoping that the -fno-stack-protector issue would fix shim (even though I had already tested reintroducing -fno-stack-protector)
[20:05] <slangasek> I'll get it sorted this week
[20:12] <psusi> smoser: had a chance to try out kpartx -u yet?
[20:12] <smoser> psusi, no. sorry.
[20:12] <smoser> i've not played or thought any more about that.
[20:20] <truexfan81> is this the right place to make a suggestion for a program to be included in ubuntu?
[20:21] <truexfan81> in this case the program is inxi, this would greatly help the guys in the forums and #ubuntu to get the info they need to help people
[20:25] <cjwatson> slangasek: might be worth trying -ffreestanding if that isn't there already ...
[21:34] <Laney> whyever does screen -ls return 1 in all cases?
[22:14] <cody-somerville> Ubuntu package dependency graph is pretty: http://tinyurl.com/a23nzp2
[22:16] <cielak> cody-somerville: any details on that picture? how was it generated, is there a hi-res version available anywhere, can I generate one myself?
[22:18] <sarnold> cielak: http://tech-foo.blogspot.com
[22:19] <cielak> sarnold: thanks!
[22:21] <cody-somerville> sarnold: thanks!
[22:24] <RAOF> cody-somerville: That's pretty awesome!
[22:44] <slangasek> smoser: yes, planning to fix bug #643289 in precise, but the mountall part of it needed to settle first
[22:59] <micahg> cjwatson: maybe one of the causes of the TIL breakdown is the lack of mention of it on the UDD packaging guide


[10:59] <sacarde> hi
[10:59] <sacarde> https://ubuntuforums.org/showthread.php?t=2342399
[15:31] <sacarde> https://ubuntuforums.org/showthread.php?t=2342399
[16:35] <rtg> tseliot, there is a 4.9-rc5 based kernel in -proposed that you ought to have a look at wrt nvidia
[16:37] <tseliot> rtg: right, thanks for letting me know. I'll have a look at it as soon as I'm done with a high priority oem bug (i.e. very soon)
[16:37] <rtg> tseliot, thanks
[16:55] <sacarde> how can I solve this error building kernel 4.8 : kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
[17:10] <smb> sacarde, you could just simply pick the disable-pie patch from the mainline builds (-> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8.8/)
[19:41] <sacarde> smb, thankyou, I folloow your hint
[19:41] <sacarde> now I aply patch, and works
[19:42] <sacarde> thanks
[19:59] <sforshee> tyhicks: could you take a look at bug 1636890? I'm thinking it might be an ecryptfs problem, but I'm not sure.
[19:59] <ubot5`> bug 1636890 in linux (Ubuntu) "invalid file times with overlayroot and encrypted home" [Undecided,Confirmed] https://launchpad.net/bugs/1636890
[20:02] <tyhicks> sforshee: hey - I won't be able to take a look until next week
[20:02] <tyhicks> sforshee: is that ecryptfs mounted on top of overlay mounted on top of ext4?
[20:03] <tyhicks> sforshee: nevermind, I see your breakdown of the mounts in comment #15
[20:11] <sforshee> tyhicks: yeah, it's a weird one. I've been trying to generate the behavior indepentently of overlayroot without success - this doesn't do it: http://paste.ubuntu.com/23492117/
[20:16] <tyhicks> sforshee: bummer, that was going to be my first thing to try
[23:32] <vdavidoff> Hello. Does anyone know what it takes to make a ata_dev_dbg print? I have tried a variety of things and a message I think I should be seeing, I am not. I'm trying to confirm I'm doing the right things to make ata_dev_dbg work before deciding that message just isn't getting triggered.
[23:33] <vdavidoff> I have tried setting the console loglevel to 8 and enabling dyndbg on everything at boot time. Maybe I'm still missing something, though.
[23:34] <vdavidoff> Ultimately I'm trying to determine if a particular device is blacklisted in libata for TRIM in the running kernel. Based on what I think is the right source code, it is, but I'd like to confirm somehow on the running machine.


[12:16] <rick_h> morning
[12:23] <brousch> is it?
[12:30] <rick_h> rumor has it
[12:57] <jrwren> yay morning
[13:03] <snap-l> Good morning
[13:18] <snap-l> http://silktide.com/cookielaw
[13:27] <rick_h> http://design.canonical.com/2012/04/pebble-watch-and-ubuntu/ kind of cool
[13:39] <jrwren> https://google-styleguide.googlecode.com/svn/trunk/pyguide.html
[13:39] <jrwren> google's python style guid
[13:41] <jrwren> i'd rather have a mechanical watch :)
[13:43] <snap-l> That watch is pretty interesting
[13:43] <snap-l> Though I fear it'll be more than I'm willing to spend for a watch I will likely wear infrequently.
[13:44] <rick_h> I'd like a mechanical watch for sure, but ouch $$
[13:44] <rick_h> this is cool though, I love the idea of a watch talking to the phone, app potential is kind of neat
[13:44] <rick_h> things like getting my google voice texts on teh wrist and such is cool and notifications is neat if it vibrates as sometimes I don't notice the phone vibrating in my pocket
[13:45] <rick_h> was my first kickstarter I did heh
[13:45] <snap-l> rick_h: This watch?
[13:46] <jjesse> i am supporting the pebble
[13:46] <jjesse> my 1st kickstarter as well
[13:46] <jrwren> timex is cheap :)
[13:48] <snap-l> Now, if it never had to be set, and was accurate, I'd pony up. :)
[13:48] <rick_h> snap-l: yea
[13:48] <snap-l> Yeah, as in it is, or yeah, as in that would be nice?
[13:49] <rick_h> yea, I did the kickstarter for the watch and yea it was my first kickstarter thing I'd done
[13:57] <rick_h> man, I love my wife but this was a great conversation.
[13:58] <jrwren> well, its bluetooth, as long as it is connected it will get ntp time from the device to which it is connected.
[13:58] <rick_h> "I ordered my contacts" oh, how much did they end up being? "I don't know" so these were those new daily things right? "Yea" did you ask her for a ballpark on the pricing? "umm, no...she didn't have it handy"
[13:59] <jrwren> ONE BAZILLION DOLLARS!
[13:59] <rick_h> no kidding lol
[13:59] <jrwren> like you have never done that? just went and got something you really wanted without caring about price
[13:59] <rick_h> but I had to at least know it
[13:59] <snap-l> "But she did ask for our check routing numbers, and my mother's maiden name"
[14:00] <rick_h> "her eye equipment was all cool and low tech...just shined a flashlight in my eye"
[14:00] <snap-l> "The waiting room was pretty interesting. It was all done up in cardboard and magic marker"
[14:01] <rick_h> "very eco friendly"
[14:01] <jrwren> lol
[14:01] <snap-l> "BANANA PHONE!"
[14:02] <jrwren> snap-l: do you scrobble with your LMS ?
[14:03] <jrwren> oh no way... they aren't using libc to do dns?
[14:03] <jrwren> imma lmao
[14:05] <snap-l> jrwren: No, I deleted my last.fm account
[14:06] <snap-l> Once they started making everything pro account, I lost interest in giving CBS all of my listening habits.
[14:11] <jrwren> snap-l: ever look at the LMS source? it looks like it does its own DNS, but at the same time it looks like it just calls gethostbyname (like it should).
[14:17] <jrwren> rick_h: what was that python impl of some cmopiler you linked recnetly? was it SASS?
[14:17] <rick_h> jrwren: yea, pyscss is what I'm using for sass compiling
[14:18] <jrwren> cool, ty.
[14:36] <brousch> i couldn't get it to work, so i'm using the ruby version for now
[14:38] <rick_h> brousch: no?
[14:38] <rick_h> https://github.com/mitechie/Bookie/blob/develop/Makefile#L251 is what I'm using to build it
[14:39] <rick_h> https://github.com/mitechie/Bookie/blob/develop/Makefile#L294 and for a watcher while I develop
[14:41] <brousch> i just needd a watcher
[14:42] <brousch> i'll try it again
[14:45] <brousch> i think it's working now. i needed to use python2.7 and install the watchdog module
[14:45] <rick_h> ah ok
[14:50] <brousch> hm, i get a no logging handlers found each time it runs
[14:51] <rick_h> yea, I get that as well
[14:51] <rick_h> I need to peek at it
[14:51] <brousch> ok, i didn't see a way around it so i thought i'd ask the master
[14:52] <rick_h> yea, basically logging isn't setup right
[15:37] <rick_h> greg-g: ok what's this knoxville stuff?
[15:51] <jrwren> <3 watchdog.
[15:51] <jrwren> i just found watchdog last night, did you know ruby has no gem that is equiv.
[15:52] <jrwren> and so they have 2 gems for every thing that might use watchdog, e.g. autotest - tehre is autotest-inotify and autotest-wahteverOSXuses
[15:52] <jrwren> so sad :(
[15:52] <jrwren> oh, and no ruby lib for the win32 watchdog api.
[15:52] <jrwren> python watchdog ftw
[15:54] <rick_h> I thought they had some inotify stuff though
[15:54] <rick_h> https://rubygems.org/gems/rb-inotify
[15:58] <brousch> pyscss is not compiling the same as sass
[16:00] <brousch> not palying nicely with semantic.gs
[16:00] <brousch> oh well
[16:01] <rick_h> sucky, file a bug I guess
[16:01] <rick_h> I know it listed a couple of things it didn't support
[16:02] <brousch> imports i think
[16:02] <rick_h> I use imports
[16:02] <brousch> also throws it all on 1 line
[16:02] <rick_h> just have to make sure the -I dir is there
[16:03] <rick_h> yea, I htink that's the minification bits
[16:07] <brousch> ah, it is making my semantic.gs stuff a fixed grid instead of fluid
[16:09] <brousch> http://paste.mitechie.com/show/625/
[16:09] <brousch> turning the %s into fixed pixels
[16:09] <jrwren> yeah, autotest-inotify uses rb-inotify, but there is no uniform api like watchdog :)
[16:09] <rick_h> jrwren: ah, not looked at watchdog much
[16:09] <rick_h> so just figured it was a inotify wrapper
[16:11] <jrwren> it is.
[16:12] <jrwren> but it is also a whatever bsd has, wahtever osx has, and whatever windows has wrapper
[16:12] <jrwren> all into a single API.
[16:12] <jrwren> which makes it excellent.
[16:12] <rick_h> ah, gotcha
[17:41] <jrwren> poll: black bg terminal or white bg terminal or other and why?
[17:42] <brousch> terminal is for dweebs. real men use Eclipse
[17:43] <rick_h> black, can't stand the white, too much light in my face
[17:43] <rick_h> especially at night darkened office
[17:43] <krondor> black bg.  My work environment is overly lit as it is.
[17:43] <rick_h> plus I prefer the color pallette you're required to use overall
[17:44] <jrwren> brousch: if i ever find a nice shell plugin for vim, I must just use it :p
[17:44] <rick_h> conque I think?
[17:44] <rick_h> is supposed to do it ok, but you're basically making vim a tiling WM at that point
[17:44] <rick_h> just tile WM and get over it
[17:45] <jrwren> i moved to white bg in vim and I like it a lot, I'm thinking about moving to white bg in terminal.
[17:45] <jrwren> rick_h: good point, i'm on OSX, and I actually like iTerm here :)
[17:45] <krondor> "But we are hackers and hackers have black terminals with green fonts!"   That's a nice sized playground even if it is only temp.
[17:48] <rick_h> yea
[17:48] <rick_h> lots of folks using it happy with performance in the testing phase
[17:49] <krondor> activated mine today, hope to get some time this weekend logged
[18:16] <jrwren> gonna be hard to get a nice irssi color scheme for a light bg terminal
[18:18] <rick_h> heh
[18:19] <_stink_> yeah, black bg here too.
[18:54] <ColonelPanic001> light background terminal?
[18:54] <ColonelPanic001> you monster
[18:55] <brousch> hm. no animated gifs in my upcoming presentation. this cannot stand!
[18:57] <rick_h> heh, I call progress
[18:57] <brousch> maybe i'll go with lolcats this time
[22:36] <snap-l> http://www.youtube.com/watch?v=ZcFGrWjOX0E#!
[22:38] <snap-l> Click on that video, or lead a poorer life for it.
[23:15] <rick_h> rush, aren't they dead?
[23:15] <rick_h> :P
[23:16] <snap-l> You wish you were that cool


[08:40] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.5-0ubuntu2]
[08:41] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.3]
[08:44] -queuebot:#ubuntu-release- Unapproved: accepted syslog-ng-incubator [source] (xenial-proposed) [0.3.3-2ubuntu1]
[09:07] <Trevinho> sil2100: hey, could you instead have a look on those SRUs from LP I've mentioned last friday?
[09:08] <Trevinho> from LP => from bileto
[09:52] <apw> Trevinho, if they have a bionic component then it is hard to get things out if they are main because of the point release freez
[10:01] <Trevinho> apw: uff... They were waiting for weeks, and they have to be in .1 or some installs will break...
[10:02] <apw> infinity, ^
[10:02] <Trevinho> I had to ping again maybe, but I asked already few times
[10:04] <apw> and it is helpful if you could point at the silo and/or the packages
[10:09] <Trevinho> Nux and xorg
[10:54] -queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.0-0ubuntu1 => 2.9.2-0ubuntu<IP_ADDRESS>] (ubuntu-server)
[11:14] -queuebot:#ubuntu-release- New binary: intel-mkl [s390x] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: intel-mkl [ppc64el] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: python-certbot-dns-gehirn [amd64] (cosmic-proposed/universe) [0.26.1-1] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: python-certbot-dns-sakuracloud [amd64] (cosmic-proposed/universe) [0.26.1-1] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: python-certbot-dns-linode [amd64] (cosmic-proposed/universe) [0.26.0-1] (no packageset)
[11:23] -queuebot:#ubuntu-release- New: accepted python-certbot-dns-gehirn [amd64] (cosmic-proposed) [0.26.1-1]
[11:23] -queuebot:#ubuntu-release- New: accepted python-certbot-dns-sakuracloud [amd64] (cosmic-proposed) [0.26.1-1]
[11:23] -queuebot:#ubuntu-release- New: accepted python-certbot-dns-linode [amd64] (cosmic-proposed) [0.26.0-1]
[11:31] -queuebot:#ubuntu-release- New binary: intel-mkl [i386] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:33] <ginggs> ^^^^ intel-mkl (libmkl-local) on s390x and pcc64el makes no sense, so please don't accept these binaries, if that's an option - the next upload will fix this
[11:35] -queuebot:#ubuntu-release- New binary: intel-mkl [amd64] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:37] -queuebot:#ubuntu-release- New binary: intel-mkl [arm64] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:38] -queuebot:#ubuntu-release- New binary: intel-mkl [armhf] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [amd64] (cosmic-proposed) [2018.3.222-1]
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [armhf] (cosmic-proposed) [2018.3.222-1]
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [ppc64el] (cosmic-proposed) [2018.3.222-1]
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [arm64] (cosmic-proposed) [2018.3.222-1]
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [s390x] (cosmic-proposed) [2018.3.222-1]
[11:41] -queuebot:#ubuntu-release- New: accepted intel-mkl [i386] (cosmic-proposed) [2018.3.222-1]
[11:57] <LocutusOfBorg> apw, force-badtest php-horde-http/2.1.7-1
[11:57] <LocutusOfBorg> can you please update it to 2.1.7-3?
[11:57] <LocutusOfBorg> it is under pitti file
[12:01] <apw> LocutusOfBorg, done
[12:10] <ginggs> apw: would you bump the r-cran-curl/3.2-2build1/arm64 in vorlon's hints please?
[12:12] <LocutusOfBorg> thanks!
[12:20] <rbasak> LocutusOfBorg: are you looking at PHP stuff in general?
[12:20] <rbasak> LocutusOfBorg: I intend to give it some attention if needed
[12:21] <LocutusOfBorg> rbasak, I want to make phpunit I boostrapped migrate, and then forget about all this stuff
[12:21] <LocutusOfBorg> :)
[12:23] <LocutusOfBorg> php-mockery php-net-ldap2 needs fixes, otherwise I'll ask to kick them to proposed and then block-proposed with a bug
[12:35] <LocutusOfBorg> rbalint, also php-horde-http needs fixes for testsuite, I made the "obvious" patch, but we are now to the old error https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/9276312/+listing-archive-extra
[12:35] <LocutusOfBorg> and no, I wont' upload a partial testsuite fix, because we have hints
[12:37] <LocutusOfBorg> apw, proposal: kick php-mockery and php-net-ldap2 to proposed, until they are fixed in Debian (they are both RC buggy, no upstream fixes, they do have broken testsuite, leaf packages, out from buster too)
[12:37] <LocutusOfBorg> so we can move forward with phpunit, the whole phpstack, and pcre3
[12:38] <LocutusOfBorg> I don't think we should have a bug with "block-proposed" hint, because they are safe to migrate once fixed automatically
[12:40] <LocutusOfBorg> also imagemagick is blocked by that php
[12:41] -queuebot:#ubuntu-release- Unapproved: linux-meta-hwe (xenial-security/main) [<IP_ADDRESS>.51 => <IP_ADDRESS>.51] (kernel) (sync)
[12:42] <apw> LocutusOfBorg, a tollerable plan i suspect, but php-net-ldap2 looks to have rdeps
[12:44] <LocutusOfBorg> simpleid-ldap and php-net-ldap3 are both rc buggy, out of buster
[12:50] <LocutusOfBorg> apw, ^^ does this sound plausible too?
[12:53] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-hwe [sync] (xenial-security) [<IP_ADDRESS>.51]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-perl2 [source] (xenial-proposed) [2.0.9-4ubuntu1.1]
[13:12] <seb128> apw, unsure how the SRUs are being handled but something is buggy, the xorg SRU has been in the queue waiting for a month and is an important fix since the issue is that upgraders that remove unity without purging it are using software rendering
[13:16] <apw> seb128, it is a sync, which is much harder to review, so it doesn't get hit in peoples drive-bys i am sure
[13:18] <rbasak> I tend to assume there's something special going on. Special reviews sometimes take half or a whole day of SRU session, so I don't do them very frequently :-/
[13:19] <seb128> apw, oh come on "much harder", it's 2 clicks away to get to the diff, https://launchpadlibrarian.net/375418303/xorg_1%3A7.7+19ubuntu7_1%3A7.7+19ubuntu7.1.diff.gz
[13:19] <seb128> the queue has a link to the ppa which has the diff
[13:19] <rbasak> seb128: breaks the review tooling
[13:20] <apw> seb128, only if you know that _that_ sync is special from a place that has the extra info
[13:20] <apw> and it is a manual process, and yes it should have been done
[13:20] <seb128> apw, at this end it's just an upload, worth case if you don't know anything it's dget and debdiff
[13:20] <seb128> don't tell me it's that hard
[13:21] <rbasak> I don't think he's saying it's hard so he's not doing it.
[13:21] <apw> as rbasak points out, it is out of process, so it gets shoved 'later'
[13:21] <rbasak> He's saying it looks hard without further investigation and that may explain why it wasn't looked at before.
[13:21] <apw> anyhow, it sounds like something one would want in the point release
[13:22] <seb128> those have been part of our reality for years, it sounds like a lame excuse to let an important LTS issue unreviewed/unfixed for .1 to me
[13:22] <rbasak> AFAIK, the SRU team in general don't make a commitment to process SRUs FIFO or anything like that.
[13:22] <rbasak> Informally we've relied on being poked for important things.
[13:22] <seb128> yeah, that's part of the issue
[13:22] <apw> seb128, right they have, and all the time i have hated on them :)
[13:22] <infinity> The PPA doesn't have the diff.
[13:23] <rbasak> That's not to say that I object to the process being changed or anything.
[13:23] <seb128> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3298/+packages has a "
[13:23] <seb128>     diff from 1:7.7+19ubuntu7 (in Ubuntu) to 1:7.7+19ubuntu7.1 (1.2 KiB)
[13:23] <seb128> " line
[13:23] <infinity> seb128: The PPA has the xorg diff, but not the nux diff, and as soon as someone gets that far, they may decide they have better things to do. :P
[13:23] <rbasak> I'm just explaining the current situation.
[13:23] <infinity> Anyhow, we should get it in today, and it can be released with .1
[13:23] <seb128> infinity, I think the bottom line is that the process is unprofessional
[13:23] <seb128> nobody commits to get important fixes reviewed
[13:23] <infinity> It doesn't need to be on the media, since it's an upgrade issue.
[13:23] <seb128> and people just hand wave that it's not done because the SRU team is "best effort" and "not commiting to anything"
[13:23] <infinity> seb128: Who defines what's "important"?
[13:24] <seb128> well, I guess I'm arguing that from the Canonical side we should have a process to nominate bugs
[13:24] <seb128> and have people commiting to have those fixes reviewed
[13:24] <rbasak> seb128: I agree with that bit.
[13:24] <apw> you do, you come ask for them here
[13:24] <seb128> apw, nagging people is something some consider rude and don't like doing
[13:25] <rbasak> seb128: AIUI, the way it works inside Canonical is that if an SRU isn't getting addressed the managers nominate an SRU team member who is a Canonical employee to sort it out.
[13:25] <seb128> it's also not documented nor fair
[13:25] <apw> which was done yesterday to my knowledge, and we were already in freeze, so it needed the release-team member doing the work to ok it
[13:25] <seb128> we shouldn't end up in that situation in the first place
[13:25] <seb128> if sync are an issue and are not processed it should be documented
[13:25] <rbasak> The trouble is that there are a large number of SRUs that are hell to properly review.
[13:26] <infinity> It's been mentioned many times that syncs are a pain.
[13:26] <rbasak> I prefer to favour traditional bugfixes coming from volunteers since I want to encourage more of those.
[13:26] <infinity> Like, for years.
[13:26] <infinity> Anyway.  Can we maybe refrain from having a two hour debate about it?
[13:26] <infinity> apw: Can you review xorg/nux?
[13:26] <apw> infinity, sure
[13:26] <seb128> if we don't have a debate it's going to come back as an issue again
[13:26] <infinity> apw: Ta.
[13:27] <infinity> seb128: If we do have a debate, it'll also come back as an issue again.
[13:27] <infinity> seb128: If we resolve the debate with useful action, maybe not, but that's less likely to happen in the middle of a release week.
[13:27] <seb128> unless we take steps to address the problem
[13:27] <LocutusOfBorg> apw, do you need any paperwork for the 4 php packages to kick out from release?
[13:27] <seb128> k, fair enough
[13:27] <rbasak> seb128: IMHO, it's something you need to resolve internally with Canonical's Foundations team. Other SRU team members are essentially volunteers.
[13:27] <rbasak> (and you can't force volunteers to do some particular review)
[13:27] <seb128> rbasak, right
[13:28] <seb128> rbasak, but if the team position about sync is "we can't be bothered reviewing them because dget & debdiff is too difficult" that should at least be documented
[13:28] <apw> seb128, i would say, that though there are diffs, they are only advisory, so one has to redo them, which is where the pain comes from
[13:28] <rbasak> You can document what makes SRUs more painful to review, sure.
[13:29] <seb128> apw, it's dget && debdiff, not exactly rocket science either...
[13:29] <rbasak> And that volunteers will tend to do things that seem less painful :)
[13:29] <rbasak> See my recent post to ubuntu-release@ about making diff review easier with git ubuntu :)
[13:29] <apw> seb128, compared to looking at a pregenerated diff in the officially tooling, it is
[13:30] <rbasak> (plug: it works with syncs!)
[13:30] <seb128> k, well I guess I made my point, thx for listening :)
[13:30] <seb128> (and for reviewing)
[13:31] <rbasak> seb128: it's a valid concern, but honestly, I think the right place to raise it is with your manager (to talk to the Canonical Foundations manager, etc)
[13:32] <rbasak> Separately if someone who doesn't have internal access to SRU team members needs to get an urgent SRU through, I think this channel is the right place to request review still.
[13:33] <seb128> rbasak, you are right
[13:34] <seb128> it's a bit annoying how SRUs/point release are being handled nowadays, but that's mostly from a Canonical perspective yes
[13:34] <seb128> like there is no communication on the project list about now being tme for getting fixes in, freeze starting, etc
[13:35] <seb128> rbasak, and yeah, I've no issue asking here or pinging people for reviews but others feel like nagging is rude and don't do it
[13:35] <seb128> it's a cultural thing and not easy to fix :/
[13:36] <rbasak> It's unfortunate, but wearing my Ubuntu hat, if you have volunteers reviewing for other volunteers then review work can't really be enforced at all. The only ways I see around it are polite requests or if a volunteer wants to commit to always reviewing everything.
[13:37] <seb128> yeah
[13:40] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (xenial-proposed) [7.2.3+real-1~16.04.1]
[13:51] <LocutusOfBorg> rbasak, php-imagick  is a sad thing now :/ blocking imagemagick transition, and I don't want to look at the failure
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.7]
[14:20] -queuebot:#ubuntu-release- Unapproved: accepted python-wadllib [source] (bionic-proposed) [1.3.2-3ubuntu<IP_ADDRESS>]
[14:26] <infinity> seb128: While we're complaining about people's responsibilities WRT SRUs, the nux upload fixing the conffile was accepted to xenial and artful over a month ago and never verified.
[14:26] <infinity> seb128: Which means artful EOLed without the fix being promoted to updates.
[14:27] <infinity> seb128: And xenial still doesn't have the fix.
[14:38] <cjwatson> Just a note about python-wadllib to whoever reviewed it - the xenial diff is all but identical so should be easy to review at the same time
[14:38] <cjwatson> (and thanks)
[14:39] <cjwatson> sil2100: ^- aha, that was you
[14:39] <LocutusOfBorg> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1340250
[14:40] <LocutusOfBorg> this is what is breaking libunistring and libidn
[14:40] <sil2100> cjwatson: in progress!
[14:40] <sil2100> :)
[14:40] <LocutusOfBorg> why is this an ubuntu only bug?
[14:40] <sil2100> (got distracted)
[14:40] <cjwatson> sil2100: \o/
[14:41] <sil2100> (wanted to have it in xenial for the .5)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted python-wadllib [source] (xenial-proposed) [1.3.2-3ubuntu<IP_ADDRESS>]
[14:43] <doko> LocutusOfBorg: no updates for these packages since 2014?
[14:47] <LocutusOfBorg> but the example code returns correctly 0 in debian, and 2 in ubuntu
[14:47] <LocutusOfBorg> so I presume this is a real bug, and I'm trying to understand what else changed in the meanwhile
[14:48] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages I already reverted glibc and glib2.0 uploads
[14:48] <LocutusOfBorg> this is a real bug, a nochange rebuild in bionic fails now
[14:48] <doko> try with -Wl--no-as-needed
[14:48] <LocutusOfBorg> do you have some archive rebuilds of the months before bionic release so we can bisect what changed?
[14:49] <doko> on qa.ubuntuwire.org
[14:49] <LocutusOfBorg> 2018-03-26 libidn was good
[14:51] <LocutusOfBorg> sadly no rebuilds after 20180408
[14:51] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/15160733
[14:52] <LocutusOfBorg> interestingly, forcing that weak stuff to disable works
[14:52] <LocutusOfBorg> now checking the as-needed
[14:55] <LocutusOfBorg> doko, do you have build logs for the rebuilds?
[14:57] <LocutusOfBorg> found them nvm
[14:57] <doko> could be a change in binutils 2.31 as well
[15:00] <LocutusOfBorg> let me try with released packages, no updates pocket
[15:03] <LocutusOfBorg> +-  /* Don't generate dynamic GOT relocation against undefined weak
[15:03] <LocutusOfBorg> +-     symbol in executable.  */
[15:03] <LocutusOfBorg> ++  /* Don't generate dynamic GOT relocation against resolved undefined weak
[15:03] <LocutusOfBorg> ++     symbols in an executable.  */
[15:03] <LocutusOfBorg> mmmm
[15:10] <seb128> could somebody skip the udisks2/s390x autopkgtest, it's buggy and it's not new (or better, update the hint's version)?
[15:44] -queuebot:#ubuntu-release- Unapproved: accepted xl2tpd [source] (bionic-proposed) [1.3.10-1ubuntu1]
[15:46] -queuebot:#ubuntu-release- Unapproved: accepted xl2tpd [source] (xenial-proposed) [1.3.6+dfsg-4ubuntu<IP_ADDRESS>]
[15:46] <sil2100> Trevinho: hey! I'll try taking a look at those again now
[16:02] <LocutusOfBorg> doko_, wl-asneeded didn't work
[16:04] <LocutusOfBorg> ./vorlon:force-badtest abi-compliance-checker/2.2-2ubuntu1/arm64
[16:04] <LocutusOfBorg> apw, ^^ bump please?
[16:04] <LocutusOfBorg> to avoid bothering, please bump directly to version  2.3-1
[16:04] <LocutusOfBorg> it is in debian deferred queue
[16:13] <slangasek> LocutusOfBorg: done
[16:14] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.2 => 2.525.3] (desktop-core)
[16:14] <infinity> sil2100: ^-- livecd-rootfs review svp.  Try not to vomit.
[16:17] <LocutusOfBorg> thanks!
[16:18] <LocutusOfBorg> wow double hint! so now I don't need anymore the --proposed pocket for the kde retries, nice thanks!
[16:18] <sil2100> infinity: ACK
[16:22] <sil2100> infinity: do we know if having it as the first snap in the list is also a valid fix?
[16:22] <infinity> sil2100: mvo said yes.
[16:22] <sil2100> Ah, we did
[16:23] <sil2100> Ok, I've seen worse hacks around
[16:23] <Trevinho> sil2100: great, thanks
[16:23] <sil2100> ;)
[16:23] <infinity> sil2100: I've written worse hacks, doesn't mean I'm proud of this one existing. :P
[16:24] <infinity> sil2100: And, for the record, as far as SRU rules go, I refuse to "fix" this in cosmic, as I think the glaring bug needs to continue to exist to force people to fix it properly.
[16:24] <infinity> Cause WTF.
[16:24] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.3]
[16:24] <infinity> "We are designing a new package format that doesn't require dependencies, but also, it has untracked dependencies."
[16:24] <infinity> Well job.
[16:24] <sil2100> infinity: that's fine in this case, cosmic is still rolling on dailies only and it only affects images, so as long as it's fixed before release I think it's ok
[16:28] -queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (bionic-proposed) [4.0.8+18.04.20180622.2-0ubuntu1]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted xorg [sync] (bionic-proposed) [1:7.7+19ubuntu7.1]
[16:32] <sil2100> Trevinho: so for nux in xenial there's the previous part of the fix still in xenial-proposed
[16:33] <sil2100> Trevinho: since it's the same bug, I'll just approve it
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (xenial-proposed) [4.0.8+16.04.20180622.2-0ubuntu1]
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted xorg [sync] (xenial-proposed) [1:7.7+13ubuntu3.1]
[16:39] <Trevinho> sil2100: yeah, I will get someone to approve both. Thanks
[17:13] -queuebot:#ubuntu-release- New binary: libhinawa [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: libhinawa [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: libhinawa [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: python-lzo [s390x] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: libvirt-dbus [s390x] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: libhinawa [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: python-lzo [ppc64el] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: libvirt-dbus [ppc64el] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: libvirt-dbus [i386] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: python-lzo [amd64] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: expeyes [amd64] (cosmic-proposed/universe) [4.4.3+dfsg-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: python-lzo [i386] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: graphviz-dot-mode [amd64] (cosmic-proposed/universe) [0.4+41+gc456a2b-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: ruby-marcel [amd64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: libvirt-dbus [amd64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: libhinawa [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: libhinawa [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:31] -queuebot:#ubuntu-release- New binary: octavia [amd64] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
[17:32] <infinity> bdmurray: Can you verify that vte2.91/bionic SRU ASAP?
[17:32] -queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (bionic-proposed) [0.52.2-1ubuntu1~18.04.2]
[17:33] -queuebot:#ubuntu-release- New binary: python-lzo [arm64] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:35] -queuebot:#ubuntu-release- New binary: python-lzo [armhf] (cosmic-proposed/universe) [1.12-2] (no packageset)
[17:38] <bdmurray> infinity: Sure, but it only affects upgrades from bionic to cosmic.
[17:39] -queuebot:#ubuntu-release- New binary: libvirt-dbus [arm64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: libvirt-dbus [armhf] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
[17:48] <infinity> bdmurray: Ahh, okay.  I misread that, then.
[17:48] <infinity> bdmurray: Still nice to verify, but indeed, not point-release-critical.
[18:10] -queuebot:#ubuntu-release- New: accepted expeyes [amd64] (cosmic-proposed) [4.4.3+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libhinawa [amd64] (cosmic-proposed) [1.0.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libhinawa [armhf] (cosmic-proposed) [1.0.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libhinawa [ppc64el] (cosmic-proposed) [1.0.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [amd64] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [armhf] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [ppc64el] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted octavia [amd64] (cosmic-proposed) [2.0.1-1]
[18:10] -queuebot:#ubuntu-release- New: accepted python-lzo [arm64] (cosmic-proposed) [1.12-2]
[18:10] -queuebot:#ubuntu-release- New: accepted python-lzo [i386] (cosmic-proposed) [1.12-2]
[18:10] -queuebot:#ubuntu-release- New: accepted graphviz-dot-mode [amd64] (cosmic-proposed) [0.4+41+gc456a2b-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libhinawa [i386] (cosmic-proposed) [1.0.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [arm64] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [s390x] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted python-lzo [armhf] (cosmic-proposed) [1.12-2]
[18:10] -queuebot:#ubuntu-release- New: accepted python-lzo [s390x] (cosmic-proposed) [1.12-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libhinawa [arm64] (cosmic-proposed) [1.0.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libvirt-dbus [i386] (cosmic-proposed) [1.2.0-1]
[18:10] -queuebot:#ubuntu-release- New: accepted python-lzo [ppc64el] (cosmic-proposed) [1.12-2]
[18:11] -queuebot:#ubuntu-release- New: accepted libhinawa [s390x] (cosmic-proposed) [1.0.0-1]
[18:11] -queuebot:#ubuntu-release- New: accepted ruby-marcel [amd64] (cosmic-proposed) [0.3.2-1]
[18:11] -queuebot:#ubuntu-release- New: accepted python-lzo [amd64] (cosmic-proposed) [1.12-2]
[19:13] -queuebot:#ubuntu-release- Unapproved: aodh (bionic-proposed/main) [6.0.1-0ubuntu1 => 6.0.1-0ubuntu1.1] (openstack, ubuntu-server)
[19:15] <doko_> LocutusOfBorg: I said:  -Wl--no-as-needed
[19:18] <infinity> -Wl,--no-as-needed even.
[19:19] <doko_> ohh, while you are here, do we have an update of the buildd chroots?
[19:20] <infinity> doko_: Colin and I have been working on making them all fancy and automated.  That probably needs another round of review before we get around to using them, though, so I can do one more manual refresh.
[19:21] <doko_> infinity: ok, then maybe wait for gcc-8.2.0 next weekend
[19:21] <infinity> doko_: Next weekend, you can bug me in person instead. :P
[19:35] -queuebot:#ubuntu-release- Unapproved: aodh (xenial-proposed/universe) [2.0.6-0ubuntu1 => 5.1.0-0ubuntu1~cloud1] (openstack)
[19:46] -queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2 => 10.1ubuntu2.1] (core)
[19:49] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.1]
[19:52] -queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (xenial-proposed) [5.1.0-0ubuntu1~cloud1]
[20:05] <LocutusOfBorg> doko_, I said, -Wl,--no-as-needed nothing changes...
[20:13] <LocutusOfBorg> doko_, of course I did bad copy-pasting... -no-as-needed worked...
[20:13] <LocutusOfBorg> is this a real fix?
[20:16] <LocutusOfBorg> oh... I forgot to mention you in changelog, bad me :(
[22:11] <infinity> LocutusOfBorg: FWIW, when no-as-needed "fixes" a binary at runtime, that generally means the build system is broken and the binary is being underlinked.
[22:11] <infinity> LocutusOfBorg: And it's just random luck that the underlinking is papered over by some other random linkage accidentally fixing it in passing. :P


[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


[20:02] <MichealH> I have KDE installing
[20:03] <MichealH> Lets get a QT version out by Natty
[20:03] <MichealH> Maybe
[20:03] <MichealH> Im learning raw qt programming