[00:52] <Sarvatt> robclark: so you're hitting utouch issues, it's a deep rabbit hole. things are dependent on the implementation in 1.10 in ubuntu at the moment but it should be fixed in precise very soon if it isn't already (not sure if you're using oneiric or precise)
[00:52] <Sarvatt> oh heck he's gone already
[00:54] <RAOF> :)
[00:58] <Sarvatt> multimonitor fix for unity making each display use a different fbo was mark fix released so im assuming chases fix is in precise now, im still on oneiric all around
[00:59] <Sarvatt> guess i better upgrade before going to budapest
[01:00] <Sarvatt> we just got done enabling one oem's ivybridge systems on oneiric and have a new one to do now so still gotta care about oneiric
[01:00] <Sarvatt> time to upgrade just in time to hit upstart breakage in precise, yay
[01:01] <RAOF> Oh, yu mean that I get to undo the gnome-settings-daemon thingy now? :)
[01:02] <bryce> Sarvatt, do you plan to do work on precise?  If not, may as well just hold off until after you get back.  Although, so far precise has been pretty stable.
[01:03] <Sarvatt> "work on precise"?
[01:03] <Sarvatt> i've been updating crap every now and then
[01:04] <Sarvatt> well just libdrm and intel updates so far
[01:05] <RAOF> There'll be the opportunity for mesa 7.12/8.0 packaging in Budapest, too.
[01:05] <bryce> RAOF, speaking of which how's xserver?
[01:05] <RAOF> xserver is bonza.
[01:06] <RAOF> The remaining blocker is synaptics being a pile of infuriating.
[01:06] <Sarvatt> budapest is all gonna be precise, im planning on ditching the hwe room to be in the desktop room to get crap done
[01:06] <bryce> Sarvatt, \o/
[01:06] <Sarvatt> they'll probably put hwe in the left side of the place with 4 rooms instead of the right side of the conference center with 15+ rooms again
[01:07] <Sarvatt> no cert going this time we got put with so who  knows
[01:07] <bryce> Sarvatt, yeah to sprints I usually bring two systems, one with devel so I can test stuff, one with stable so I can get work done.  This time both will have precise loaded
[01:07] <RAOF> All the touchpads I've got access to teleport the cursor to (0,0) at not-apparently-deterministinc intertvals, and it's not clear to me what level of the stack is blowing up (but my guess is input backport).  Chase is aware of it, and is doing synaptics work, so I'm waiting for that.
[01:07] <Sarvatt> hmm thats a good point
[01:07] <Sarvatt> i was just planning on bringing the macbook air
[01:08] <Sarvatt> better off bringing another
[01:08]  * RAOF seems to be running out of hardware that works enough to bother to bring to sprints.
[01:09] <Sarvatt> all my discrete gpu systems are too huge to bring though, hmm
[01:10] <Sarvatt> 8+lbs each
[01:10] <Sarvatt> asus g73, dell m4600
[01:10] <RAOF> This ati/intel hybrid will be making an appearance, as the only non-netbook I have that contains entirely functional hardware :)
[01:10] <bryce> yeah, I'm going with the thin arrandale and a little netbook.
[01:11] <bryce> the arrandale's wireless is borked at the moment though
[01:11] <Sarvatt> cert/oem guys arent going this time so there wont be a plethora of unreleased systems we could nab :(
[01:11] <RAOF> Oh, balls.
[01:11] <RAOF> Yes.
[01:11] <bryce> fortunately I'll probably just be doing libxrandrutils hacking, don't need any special hardware for that
[01:12] <Sarvatt> my goals are mesa 8.0 in precise, vmwgfx packaging, xserver 1.12 in edgers
[01:12] <Sarvatt> and of course the xserver 1.11 stuff
[01:13] <Sarvatt> frankenserver is going to be most of the week
[01:13] <RAOF> As Sarvatt suggested, we might also want to consider plain xserver 1.12 while we're all in the neighbourhood.
[01:13] <Sarvatt> i only suggested that to you in PM
[01:13] <Sarvatt> it has lots of drawbacks
[01:14] <RAOF> Sarvatt: What other work is necessary on the frankenserver.
[01:14] <RAOF> ?
[01:14] <Sarvatt> like, we've distributed to OEMS that we're shipping 1.11, and they are asking intel for 1.11 support for cedarview
[01:14] <Sarvatt> intel is only shipping xserver 1.9 support in the initial cdv driver
[01:14] <Sarvatt> xserver 1.9 and mesa 7.9
[01:14] <Sarvatt> and kernel 3.0
[01:14] <Sarvatt> such a nightmare
[01:14] <bryce> yeah we can talk about versions of things.  I've been procrastinating sending out that email about what versions of things we'll be shipping, since it's felt a bit uncertain
[01:15] <Sarvatt> basically whatever chromeos ships
[01:15] <RAOF> Heh.  Ok.  Or, we could have a simpler conversation here; it sounds like our previous statements have a larger inertia than I thought :)
[01:16] <Sarvatt> intel has no plans to support 1.11 for cdv, its all pie in the sky things so we can flip flop still if 1.12 is better :)
[01:16] <Sarvatt> this was literally last week
[01:16] <Sarvatt> intel UMG is a nightmare to deal with, poulsbo..
[01:17] <bryce> Just Say No
[01:17]  * bryce cracks an egg on a hot frying pan
[01:17] <Sarvatt> i have been for over a year
[01:17] <bryce> that's your brain on poulsbo
[01:17] <Sarvatt> they finally got it last week after detailing in a huge doc about what we've experienced wdealing with them about this
[01:17] <Sarvatt> opengl support? not happening
[01:18] <RAOF> That sounds like a *particularly* appealing netbook :)
[01:18] <Sarvatt> recompile clutter using gles instead, which will require a new architecture like lpia basically
[01:18] <RAOF> Oh.  I thought linaro already had basically the same problems, and solved them?
[01:18] <bryce> Sarvatt, you mentioned the oem's were spun up on 1.11; aside from cedarview is there anything else that would impact them if a different version was shipped?
[01:19] <Sarvatt> "yeah we experienced problems with GL apps too, what we did in meego was recompiled clutter using gles instead of gl (compile time option that requires everything recompiled against the different clutter) for mutter to work in meego"
[01:19] <Sarvatt> anything using GL hangs the system within 10 seconds
[01:19] <Sarvatt> nah its only cedarview thats a hot ticket item
[01:20] <Sarvatt> i'm more worried about breaking fglrx for DX
[01:20] <RAOF> I *think* linaro have the pluggable clutter gl/gles stuff licked.
[01:20] <Sarvatt> RAOF: the problem is its a compile time option, clutter using gles is incompatible with clutter compiled using gl
[01:20] <RAOF> But it occurs to me that you may well be in a better position to know that :)
[01:20]  * RAOF was pretty sure there was work to make that a run-time option, and that work had landed.
[01:21] <RAOF> Maybe I'm misremembering my blog postings :)
[01:21] <Sarvatt> arm doesn't care because they can target gles on that architecture because all the drivers ship gles and gl is an afterthought
[01:21] <Sarvatt> nope, look at debian/rules in clutter source
[01:21] <RAOF> Eh.
[01:22] <Sarvatt> are you thinking of cairo?
[01:22] <Sarvatt> thats what alf was doing
[01:22] <Sarvatt> for linaro
[01:22] <RAOF> That could be it.
[01:23] <Sarvatt> unity will have gles support in 12.04, but then someone is going to buy a netbook and try to install a game like openarena
[01:23] <RAOF> Hm.  I might *also* be thinking of run-time switchable wayland/X backends.
[01:23] <Sarvatt> and the system is going to lock up within 10 seconds
[01:23] <RAOF> No; they'll get terrible performance with llvmpipe, but we'll just disable GL.
[01:23] <RAOF> BY HOOK OR BY CROOK!
[01:24] <Sarvatt> yeah as long as we disable any kind of accelerated 3D support which is perfectly doable
[01:24] <RAOF> We can't selectively disable OpenGL?
[01:24] <Sarvatt> then they cat a 10k /var/log/Xorg.0.log in gnome-terminal and it takes 45 seconds to show in the terminal because the 2D "acceleration" is so slow
[01:26] <Sarvatt> its really bad, thats what i've been dealing with for the past month, sorry to complain :)
[01:26] <RAOF> What is IRC for if not for venting at hardware madness?
[01:27]  * RAOF wonders who hardware engineers vent at.
[01:27] <broder> their fabs
[01:28] <Sarvatt> the bongs they hit 24/7 for getting clogged up
[01:28] <bryce> heh
[01:33] <Sarvatt> i think i'm pulling a ROAF this time
[01:33] <Sarvatt> havent even packed for budapest yet
[01:34] <Sarvatt> tseliot isn't coming again btw
[01:34] <Sarvatt> yet another X team dinner missing someone :)
[01:34] <bryce> shucks
[01:36] <Sarvatt> RAOF: what synaptics problem were you hitting?
[01:36]  * bryce eyes bug 903859
[01:36] <ubot4> Launchpad bug 903859 in xorg (Ubuntu) "wireless connection is not hooking up after i upgraded to version 12 (affects: 1) (dups: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/903859
[01:36] <Sarvatt> i just realized, i have no machines that use synaptics
[01:36] <Sarvatt> dell has been all alps for over a year
[01:36] <RAOF> Sarvatt: The DDX?  Really?
[01:37] <Sarvatt> hmm i can use synaptics on the mba and lose all gestures if i really wanted to try it out apparently
[01:37] <RAOF> Sarvatt: I thought basically all touchpad-like hardware went through xserver-xorg-input-synaptics; my Apple Wireless Trackpad certainly does.
[01:38] <Sarvatt> RAOF: thats a udev rule change to make it happen
[01:38] <Sarvatt> evdev should be used
[01:38] <RAOF> That was true for... 11.04?  But synaptics definitely grew gesture support.
[01:38] <Sarvatt> hmm
[01:39] <RAOF> We were having a discussion with Chase for that extent - to what extent are gestures worth a really terrible touchpad experience.
[01:39] <RAOF> Because evdev makes for a rubbish touchpad DDX.
[01:39] <Sarvatt> you lose tap to click doing that dont you
[01:39] <Sarvatt> which is pretty major
[01:39] <Sarvatt> oh wait thats when you use evdev instead of synaptics
[01:39] <Sarvatt> and probably why it defaults to synaptics now
[01:40] <RAOF> Tap to click, two and 3 finger tap, two finger scroll, a bunch of filtering, and proper acceleration.
[01:40] <RAOF> You can *really* tell when you're using evdev rather than synaptics - your touchpad will feel like it's been posessed by the devil.
[01:41] <RAOF> Or, with the frankenserver, you can tell when you *are* using synaptics, because your pointer will teleport to (0,0) all the time for no obvious reason.
[01:41] <RAOF> :)
[01:43] <Sarvatt> hey someone said that happened even on 1.12
[01:43] <Sarvatt> i think it was ricotz
[01:44] <RAOF> That could well be the case.
[01:47] <RAOF> In all other respects the frankenserver seems to be a perfectly functional backport of the new input stack, so it wouldn't surprise me to find that bugs in the frankenserver are backported from 1.12.
[01:56] <bryce> we should bring lag bolts to tape on the side of our laptops
[01:56] <RAOF> What is a lag bolt?
[01:57] <bryce> http://www.boltdepot.com/Lag_bolts.aspx
[01:57] <bryce> well obviously any old bolt would do.  "lag bolt" sounds more frankensteiny though.
[02:09] <bryce> RAOF, hey did you get your OLCP box up and running with ubuntu?
[02:10] <bryce> I just received mine right before xmas, still haven't even opened it up to install the serial port wires
[02:10] <RAOF> I've got all the prerequisites, but I haven't actually spend the hour or so required to make it bootable.
[02:12] <Sarvatt> dont those use marvell?
[02:12] <Sarvatt> aka dont work post jaunty in ubuntu
[02:12] <Sarvatt> armv5
[02:12] <bryce> yeah arm hw
[02:12] <Sarvatt> we went armv6+ only in karmic
[02:13] <bryce> dunno if it's armv5 or 6
[02:13] <Sarvatt> debian armel will work at least
[02:14] <Sarvatt> i might be wrong but i thought they used the same hardware as sheevaplugs and stuff, marvell cpus that were armv5
[02:15] <bryce> CPU: Marvell Sheeva ARM (PJ4);
[02:15] <bryce> ARMv7 architecture compatible;
[02:15] <Sarvatt> oh cool
[02:15] <Sarvatt> not sure if theres a compatible kernel though
[02:16] <bryce> Linux Kernel: recent Linux 2.6.xx; Fedora base environment.
[02:16] <bryce>     The OLPC specific bits of the kernel are pulled from the olpc-2.6 GIT tree on dev.laptop.org: (http://dev.laptop.org/git/olpc-2.6)
[02:16] <Sarvatt> but at least userspace supports it if its v6+
[02:17] <bryce> anyway something to tinker with when I'm bored
[02:17] <bryce> might have to enlist Dutch in doing some QA work on it ;-)
[02:17] <Sarvatt> lol
[02:19] <Sarvatt> i have the perfect system for dutch, if only it was pinetrail and not cedartrail
[02:23] <bryce> he loved playing with the babysitter's iphone.  wish I still had that xt2 touchscreen laptop
[02:23] <Sarvatt> well its for elementary schoolers, probably a bit too much for him still :)
[02:23] <Sarvatt> i keep forgetting how young he really is, he's a big kid :)
[02:28] <Sarvatt> http://www.cceinfo.com.br/produtos/governo/proj-secre-educ-pe/TabletPC%20-%20EC10IS2
[02:28] <Sarvatt> one of those, its got a handle and made to take a beating from kids
[02:29] <bryce> yeah, tho he's coming along.  He can recite the entire alphabet accurately now, names the letters correctly about 50/50, and can count to 20 only missing a few numbers along the way
[02:29] <bryce> he also has USB plugging in skillz now
[02:30] <Sarvatt> bryce: so it takes him 3 times to plug it in right, the same as us?
[02:30] <bryce> Sarvatt, that's right
[02:30] <Sarvatt> awesome :)
[19:54] <Prf_Jakob> Sarvatt, bryce, RAOF: How nervous do you guys get if we wait untill middle of next week to cut the branch?
[19:55] <Prf_Jakob> We are so close of getting GL3 support into softpipe.
[19:55] <Sarvatt> Prf_Jakob: feb 16th is just the date that makes us nervous :)
[19:55] <Prf_Jakob> Ok
[19:56] <Prf_Jakob> Next week it is, lets see if I can pause this release in time.
[19:57] <Sarvatt> at most it'll take a week to prepare and stage and put out a call for testing before putting it in the archive, can probably skip that last part but its a big change and mesa updates always break something for someone (hi KDE)
[19:58] <Sarvatt> i wonder if kwin still relies on hardcoded gl version strings that need updating every mesa release still
[19:59] <bryce> Prf_Jakob, next week would be fine with me
[19:59] <bryce> I suspect we're going to be too busy with sprint stuff to worry too much about much else
[20:00] <Prf_Jakob> okay
[20:00] <Prf_Jakob> Doing it now doesn't give us anything else?
[20:03] <bryce> Prf_Jakob, it would enable us to potentially do the packaging/testing work at the sprint, which would mean we could get this out to users pretty quick
[20:04] <bryce> but to be honest there's so many frequent interruptions during sprints that it's hard to do intensive packaging work, at least not without making a lot of errors
[20:16] <Prf_Jakob> bryce: ok, I think the release will be better of with better GL3 support.
[20:16] <Prf_Jakob> Is the sprint all week?
[20:16] <bryce> yes
[20:18] <bryce> Prf_Jakob, would there be much chance if adding the GL3 support might add regressions?
[20:18] <Sarvatt> we most likely wont have GL3 support in the archive for precise though, it'd need to go through legal and almost guaranteed that can't happen in this time frame. floating point textures and all
[20:18] <Prf_Jakob> Sarvatt: oh that crap...
[20:19] <bryce> (knowing how sometimes many bugs in a software release come from whatever feature got added right before release ;-) )
[20:20] <Prf_Jakob> bryce: we are getting a lot better at regression testing with piglit, and we are really really close so there isn't much to do.
[20:20] <Prf_Jakob> I think most of the common code is already there.
[20:22] <bryce> ok cool
[20:32] <Prf_Jakob> bryce, Sarvatt: http://lists.freedesktop.org/archives/mesa-dev/2012-January/017026.html
[20:36] <bryce> *nod*
[22:10] <FernandoMiguel> evening


 Hey folks, did you see the email from Michael about Kubuntu Laptops ?
 I replied.
[23:10] <valorie> I did and don't know what to think about it so I forwarded to the KC
[23:10] <valorie> dunno why he write to me and Rohan
[23:11] <valorie> old news I guess?


[02:06] <mwhudson> argh
[02:07] <mwhudson> is there some way i can easily hack about in a revision controlled dir (bzr or git i don't mind) and turn my local commits into patches in debian/patches?
[02:07] <mwhudson> (only the parts of my local commits that don't touch debian/ obv.)
[02:09] <sarnold> mwhudson: it's not what you asked for, but 'quilt shell' may come close to giving you something that works
[02:09] <mwhudson> erm
[02:09] <mwhudson> i guess so
[02:43] <darkxst> mwhudson, you can use gbp-pq to create a branch with all debian patches applied as commits
[04:31] <hallyn> sarnold: are you by chance an apport guru?
[05:30] <jakesyl> hey guys i've been looking to help out with ubuntu dev and already know a considerable amount of python, but what other languages should i learn? x86?
[05:31] <RAOF> jakesyl: If by “x86” you mean “x86 assembler”, then that's a pretty low-return investment of learning :)
[05:32] <RAOF> jakesyl: The answer, as with everything open-source is: what do you want to do? ☺
[05:32] <jakesyl> i learn for the sake of learning, and of course applying my learning to a worthy cause, so what can i learn to be of most assistance RAOF
[05:33] <RAOF> Because that will determine what you'll need to know. Want to hack on GNOME Do? You'll need to know (or learn) C#. Lots of the Ubuntu tools are written in Python, so you could help there already; Ubuntu Touch uses QML / Qt, for which a dialect of C++ can be useful.
[05:34] <RAOF> It's sort of like going up to a science department and saying “I'd like to help in science; what can I learn to be most useful” :)
[05:34] <StevenK> RAOF: Install a power-mad AI and get her to do the science, obviously.
[05:35] <RAOF> Generally the best way to help is to find something that doesn't work the way you want, or is broken in some way, and fix it :)
[05:36] <jakesyl> eh RAOF, hypothetically if i wanted to build an ubuntu like os from scratch, what would i need to know
[05:36] <rww> StevenK: I vaguely recall popular culture telling me that this ends badly with cake and lies and such.
[05:37] <StevenK> rww: :-)
[05:37] <jakesyl> big hypothetical
[05:37] <RAOF> jakesyl: Depends on what you mean by both “from scratch” and “Ubuntu-like OS”.
[05:38] <jakesyl> RAOF, i mean completely from scratch, as in an ubuntu iso
[05:38] <jakesyl> and general linux
[05:38] <RAOF> Well, we've got tools to do that :)
[05:38] <RAOF> But from the raw upstream source you'd need to know a whole bunch of system administration, because you're going to be running a build farm.
[05:38] <jakesyl> what languages?
[05:39] <RAOF> That's kindof the wrong question :)
[05:40] <jakesyl> hmm why?
[05:40] <RAOF> But you'll be dealing with everything from raw assembly of whichever architectures you're interested in to compilers for the same, to C, C++, python, ruby, perl, C#, Java...
[05:41] <jakesyl> RAOF, perhaps a little context, i'm 15 i've been writing perl since i was 8 finally decided it was a dead language, i still wrote python wrappers in perl, and i'm just now realizing i should move on
[05:43] <RAOF> jakesyl: The most useful way to learn is to find a (coding) project that needs help (which is basically everything!) and work on it. Which project you help determines what you need to learn.
[05:43] <RAOF> (Although the chances of needing to learn x86 assembler are very low ☺)
[05:44] <jakesyl> so what would i need x86 for
[05:45] <RAOF> Work on compilers or runtimes, mainly.
[05:47] <jakesyl> RAOF, the reason i ask is ever mentor i've ever had brags about memorizing hex tables
[05:48] <jakesyl> hmm RAOF, if i wanted to do a ui/ux overhaul and just make it look cleaner, what would i need to learn?
[05:49] <RAOF> Those sound like some sucky mentors :(
[05:49] <RAOF> So, choices!
[05:49] <jakesyl> well either that or a universal package manager
[05:49] <RAOF> If you want to work on the actual UI toolkits - that'd be Qt and GTK - you'll be wanting C++ and C(ish)/Vala, respectively.
[05:50] <RAOF> To work on applications, you get to pick an application and find out what it uses :)
[05:50] <jakesyl> but there's no uni package manager is there?
[05:50] <rww> there are too many universal package managers. someone is going to end up making a universal universal package manager
[05:51] <jakesyl> rww, i've never seen a seamless one tho, now i'm not an apple fanboy, i'm on ubuntu, but the seamless integration is what i want, click on the package it opens, is there anything like that?
[05:51] <RAOF> Yes; gdebi
[05:52] <RAOF> Or do you not want to install things?
[05:52] <jakesyl> why doesn't it come pre installed?
[05:52] <RAOF> It does.
[05:52] <RAOF> (I think?)
[05:52] <jakesyl> so how come when i click an application it doesnt just open
[05:52] <rww> RAOF: it's in universe, so I assume not
[05:53] <RAOF> Oh, of course. Software Centre does that now.
[05:53] <RAOF> jakesyl: What do you mean by ‘an application’? :)
[05:53] <Mirv> if a core dev is around, unity8 CI Train release would need a packaging ack for their debian/ changes https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_8.00+14.10.20140814.1-0ubuntu1.diff
[05:53] <RAOF> We *don't* have application bundles ala OS X, but that's not a technical problem.
[05:53] <geofft> I think the click-packages stuff is also relevant here?
[05:54]  * RAOF looks at that packaging diff
[05:54] <jakesyl> metasploit is a great example, i download metasploit i hit the package it should auto install and i understand how to do it but it should be seamless should it not?
[05:55] <RAOF> If you download an Ubuntu package and double click on it it *will* install (or, rather, it'll come up in the Software Centre asking if you want to install it)
[05:55] <jakesyl> okay so i guess i'll focus on ux
[05:59] <RAOF> Mirv: That looks fine.
[05:59] <Mirv> RAOF: thanks!
[06:07] <sarnold> hallyn: sorry, I don't know much about apport
[06:22] <dholbach> good morning
[06:26] <dholbach> does anyone of the Canonical folks know if there's an arm64 porter box?
[06:32] <slangasek> dholbach: there is not; there's an open RT for one
[06:32] <dholbach> all right, thanks
[06:32] <slangasek> (there are physical boxes but they're not yet provisioned as a porter box)
[07:12] <LocutusOfBorg1> hi dholbach, were you looking for the arm64 porter because of wxwidgets3.0?
[07:12] <LocutusOfBorg1> (the build has been successful)
[07:12] <LocutusOfBorg1> thanks ;)
[07:12] <dholbach> LocutusOfBorg1, indeed I was - in the end I trusted your build log and knew I could find you if things exploded :)
[07:12] <LocutusOfBorg1> oh yes ;)
[07:13] <LocutusOfBorg1> feel free to mail me, or to find me there, and the fix was quite trivial anyway (disable the precompiled headers), fortunately the bug has been fixed in gcc
[07:14] <dholbach> cool
[07:15] <LocutusOfBorg1> BTW I never been able to reproduce in pbuilder/arm64 so I guess the old buildd lp system was just buggy, again a great thanks to cjwatson :D
[07:23] <tjaalton> is there a way to force dch to not append the ubuntu version?
[07:23] <tjaalton> in a conffile
[07:26] <LocutusOfBorg1> tjaalton, the man says probably DEBCHANGE_VENDOR
[07:29] <LocutusOfBorg1> "dch --vendor debian"
[07:30] <tjaalton> hm indeed
[07:30] <tjaalton> just need an alias then
[07:31] <LocutusOfBorg1> I think so and I think I'll need it too ;)
[07:31] <LocutusOfBorg1> it is annoying sometimes :)
[07:31] <tjaalton> especially when you later notice that debcommit pushed it to $vcs.. to a debian branch
[07:35] <LocutusOfBorg1> argh
[07:50] <LocutusOfBorg1> dholbach, I opened two bugs for you ;) sorry
[07:53] <dholbach> LocutusOfBorg1, not necessarily just for me, right? :)
[08:07] <LocutusOfBorg1> no dholbach :) but you rock in merging/syncing lol
[08:08] <dholbach> haha
[08:08] <dholbach> I need to take care of a few other things first - if nobody beats me to it, I might have a look later on
[08:08] <LocutusOfBorg1> wonderful!!!
[08:08] <LocutusOfBorg1> I really would like to fix the wx2.8 and wxpython3.0 stuff
[09:35] <doko> dobey, ubuntu-sso-client finally \o/
[09:40] <Laney> doko: any objection to taking pcre3 8.35?
[09:40] <doko> Laney, not at all
[09:42] <Laney> cool
[09:42] <Laney> infinity: your merge, can I steal it?
[09:44] <infinity> Laney: My merge of what?
[09:45] <infinity> Laney: Oh, pcre3?  Go nuts.
[09:45] <Laney> Tah
[10:10] <rbasak> xnox: bug 1355992 claims the last samba merge inadvertently dropped an upstream cherry-pick. Please could you take a look?
[10:32] <halfie> sudo aa-genprof /usr/bin/vim results in "TypeError: 'bool' object does not support item assignment"
[10:32] <halfie> the AppArmor user space seems to be in a terrible state
[10:33] <rbasak> I think the genprof issue is known about
[10:33] <rbasak> AIUI, it's limited to genprof.
[10:34] <rbasak> jjohansen: ^^
[10:35] <halfie> I thought that AppArmor was like a bullet-proof production ready thing ;(
[10:35] <halfie> I guess I will have to go with SELinux (on Ubuntu!)
[11:10] <lullis> Hi, all. I have a few questions regarding (I think) lightdm customization. Basically, I am working on a system that needs to provide remote authentication. And to do that, the user needs to be able to (1) set up the network connection and (2) be able to also "register" directly on the greeter screen.
[11:11] <lullis> My questions would be: regarding (1), can I add the NM applet to top bar of any the (gtk/unity) greeters?
[11:19] <lullis> regarding (1) and (2), I have a python/GTK application that handles the setting up a new account on the remote server. How hard would it be to change the C greeters to add a handler that starts my python code?
[11:19] <doko> jpds, strongswan ftbfs on armhf and powerpc. any reason not to use libgcrypt20?
[11:20] <lullis> And also, is any better place to ask these questions?
[11:22] <rbasak> halfie: AppArmor is production ready, and has been used in production for many years. I wasn't aware you were talking of a production release. No idea about that, but genprof is a helper and not a production piece.
[11:22] <rbasak> halfie: try #ubuntu-hardened for apparmor discussion. The security folks listen in in there.
[11:48] <jpds> doko: Upstream still has to figure it out: https://wiki.strongswan.org/issues/674
[12:07] <doko> jpds, please can you try building with -O2 on ppc64el?
[12:07] <jpds> doko: Ah, upstream just pinged me and we were doing a git bisect on a porter box.
[12:08] <doko> jpds, but up to now, all test failures seen with -O3 did point to invalid source code ...
[12:10] <jpds> doko: Upstream says -O2 is the default in the configure script.
[12:11] <doko> jpds, and?
[12:12] <doko> ppc64el is built with -O3 as the default
[14:55] <halfie> hi, I am trying to download all utopic package and the debug information packages for some offline analysis. how do I go about it? Currently I am using debmirror.
[15:00] <rbasak> halfie: debug packages are at ddebs.ubuntu.com. The rest is as your sources.list says for utopic.
[15:01] <halfie> rbasak, ah, I see. is there a way to mirror the debug packages for utopic only? I guess I could try using debmirror for it?
[15:02] <rbasak> halfie: just mirror ddebs.ubuntu.com I guess?
[15:02] <halfie> rbasak, it will be too large :)
[15:03] <rbasak> halfie: well, the rest is up to your mirroring tool. debmirror can filter as needed.
[15:03] <halfie> ok, giving it a shot now
[15:06] <tedg> ev, Would you be opposed to us not filtering fields on recoverable errors in Whoopsie?
[15:13] <lamont`> has anyone run into grub_isprint not found (and the subsequent bail into grub rescue) on a machine upgraded from saucy to trusty? (did this last night, not so wonderfull)
[15:13] <lamont`> didn't find anything in launchpad on the subject
[15:24] <lamont`> nm.
[15:26] <ev> tedg: very much opposed, given that people shove entire log files into these fields and cassandra does not do blob storage
[15:26] <ev> what's the motivation?
[15:27] <tedg> ev, Well for instance I have UAL have a recoverable error for "bad AppID" and then it has a custom field with the appid that was bad. Not getting that custom field.
[15:27] <tedg> ev, https://errors.ubuntu.com/bucket/?id=ubuntu-app-launch-invalid-appid
[15:28] <tedg> ev, Can we switch to Mongo? I hear it has all the features.
[15:29] <tedg> ev, Seems like we could filter by size instead of a white list?
[15:35] <ev> suggest mongo again and I'll come find you
[15:35] <ev> tedg: sometimes we have big fields we want to carefully split
[15:35] <ev> like Stacktrace :)
[15:36] <tedg> ev, Sure, so let the whitelist be to avoid the size limits not to be in/out.
[15:36] <tedg> ev, So, < 1KB or in whitelist
[15:36] <ev> so any field below a certain size plus these big ones we care about?
[15:36] <ev> yeah
[15:36] <ev> works for me
[15:36] <ev> I'll +1 that MP
[15:36] <ev> but remind me I said this :)
[15:36] <tedg> ev, K, I'll work on that MP
[15:37] <tedg> ev, I'll remind you daily :-)
[15:37] <ev> lol
[15:37] <tedg> ev, I don't know cassandra, is 1KB reasonable?
[15:39] <ev> yeah, I think the barrier (for Thrift) is 16 MB, but the other thing I'm trying to avoid is quickly growing the database when the IS team responsible for getting us out of the ENOSPC hole has been moved onto other top secret projects
[15:39] <ev> so we can start at 1K and increase from there
[15:40] <ev> tedg: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Increasing-thrift-framed-transport-size-in-mb-td6825655.html
[15:41] <tedg> ev, Oooh, secret projects. 1KB I think works for my usecases.
[15:41] <ev> note that we're on cassandra 1.0.lulz, so anything you read about 1.2, 2.0 or whatever is a pipe dream at this point
[15:44]  * tedg wonders what else would break if an appid was 1KB in length
[16:54] <dpm> hi sarnold, would you mind doing a final review to the File Manager security checks MP? We've got the AP tests working now, and Arto did a couple of tweaks to the code. You gave your +1 already, but it'd be good to have a final sanity check after the last few changes
[16:54] <dpm> https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/require-screenlock-password/+merge/230058
[17:50] <tjaalton> shouldn't sbuild/schroot clean up stuff from /tmp too after exiting the chroot?
[18:13] <Unit193> cjwatson: Hello!  Not sure if you're back from VAC, but just a bump on tasksel refresh?
[18:46] <mdeslaur> doko: mind if I merge subversion?
[18:47] <doko> mdeslaur, not at all. can you apply the patch from 1353142 and revert to -O3?
[18:47] <mdeslaur> doko: sure
[18:51] <jtaylor> doko: mind if I do numpy?
[18:53] <doko> jtaylor, sure. did you see may scipy workaround?
[18:53] <jtaylor> no?
[18:53] <jtaylor> I wanted to check that out this weekend
[18:53] <jtaylor> also needs another fix for statsmodels
[18:54] <doko> are you at debconf?
[18:54] <jtaylor> no
[18:54] <doko> http://launchpadlibrarian.net/182175661/python-scipy_0.14.0-1_0.14.0-1ubuntu1.diff.gz
[18:55] <jtaylor> I wonder why that is failing, I did test i386 for the 0.14 upload
[18:57] <jtaylor> also seems to work in debian
[18:57] <jtaylor> maybe gcc-4.9?
[18:58] <jtaylor> I'll look at it later
[18:59] <doko> yep, but it's i386, and I didn't care too much, therefore the ignore
[19:00] <jtaylor> yes i386 fails numeric tests all the time
[19:04] <jtaylor> doko: I filed a bug about gcc dropping -ltsan https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105
[19:04] <jtaylor> not much useful information yet but possibly we have to add --no-as-needed in the ubuntu package
[19:05] <doko> jtaylor, maybe, but since today we can use --push-state and --pop-state
[19:05] <doko> see the ld docs
[19:05] <jtaylor> uh thats neat
[19:29] <jtaylor> doko: in case you want to sponsor, bug 1357044
[20:37] <mwhudson> darkxst: hm, thanks
[20:38] <mwhudson> i found gbp completely confusing last time i looked at it, but gbp pq seems sensible on a very quick look...
[20:41] <doko> jtaylor, merged
[20:47] <jtaylor> thx
[22:45] <hallyn> so, i have /usr/share/apport/package-hooks/source_qemu.py , but it doesn't get called when qemu-system-x86 crashes (that is, i kill it manually with kill -11).  Am I supposed to do something else?  Register it somehow?


[06:19] <TheMue> goooooood morning
[06:36] <davecheney> helllo
[07:58] <rogpeppe> TheMue, davecheney: mornin'
[07:59] <TheMue> rogpeppe: heya
[08:00] <fwereade> yay, I has internets again, I hope
[08:00] <fwereade> mornings :)
[08:09] <TheMue> fwereade: internet makes stupid (topic of a German TV show yesterday)
[08:27] <rogpeppe> just rebooting
[09:22] <Aram> yo.
[09:34] <wrtp> Aram: hiya
[09:41] <TheMue> Aram: hi
[09:42] <TheMue> Aram: jfi, i'm working on mstate/unit
[10:24] <TheMue> lunchtime
[12:14] <wrtp> niemeyer: yo
[12:14] <wrtp> !
[12:16] <niemeyer> wrtp: Buenas!
[12:16] <wrtp> niemeyer: do you know of any way of doing an "unmerge"?
[12:17] <wrtp> niemeyer: i.e. i've got a branch that merged another one some time ago, and i want to back out from all the changes that that merge introduced
[12:18] <niemeyer> wrtp: The only reasonable path for that is to apply a reversed diff
[12:18] <niemeyer> wrtp: It's not free of side effects, unfortunately
[12:19] <wrtp> niemeyer: thanks.
[12:19] <niemeyer> wrtp: The old branch won't merge properly anymore, so it'll need to be recreated  by branching and applying the forward diff again
[12:19] <wrtp> niemeyer: i'll probably just build the branch from scratch again.
[12:32] <wrtp> lunch
[12:37] <niemeyer> wrtp: Enjoy
[12:45] <wrtp> pwd
[12:57] <niemeyer> :)
[13:18] <TheMue> Aram: after unit, as said, i'm now starting with relation units (first step w/o presence and watcher)
[13:45] <niemeyer> I have a scheduled visit to the doctor.. back soon
[14:20] <wrtp> TheMue, Aram: a fairly small cleanup of the juju.Conn interface: https://codereview.appspot.com/6488077
[14:20] <wrtp> niemeyer: ^
[14:28] <TheMue> wrtp: you've got a review
[14:28] <wrtp> TheMue: thanks
[14:28] <TheMue> wrtp: yw
[14:29] <wrtp> TheMue: about that comment - you're probably right, but i think i'll leave it be for the time being, as it's an unrelated change.
[14:30] <TheMue> ok
[14:54]  * niemeyer waves
[15:16] <wrtp> niemeyer: hiya
[16:07] <niemeyer> wrtp: Review sent
[16:07] <wrtp> niemeyer: ooh you're a lovely man
[16:07] <niemeyer> Lunch time, biab
[16:07] <niemeyer> wrtp: :-)
[16:36] <TheMue> so, sports is calling, cu tomorrow
[16:57]  * niemeyer is back
[16:57] <niemeyer> and heading to a meeting
[16:57] <niemeyer> I suppose
[17:30] <wrtp> niemeyer: is that CL LGTY with the suggested change?
[17:31] <niemeyer> wrtp: Yeah, it does look reasonable
[17:31] <wrtp> niemeyer: thanks
[17:32] <wrtp> niemeyer: done. will submit.
[17:33] <niemeyer> wrtp: Thanks!
[17:33] <wrtp> niemeyer: good to get one more dependency out of the way!
[17:33] <niemeyer> wrtp: Yeah, feels good doesn't it :)
[17:33] <niemeyer> wrtp: Progress!
[17:33] <wrtp> niemeyer: yeah.
[17:33] <wrtp> niemeyer: upgrade-juju is done; just writing the tests.
[17:34] <wrtp> niemeyer: i have an idea for the provisioner agent stuff - i'll see if it works out.
[17:34] <niemeyer> wrtp: Woohay
[17:34] <wrtp> niemeyer: if i'm right (and you think it's ok) it could save lots of time and code. we'll see.
[17:35] <niemeyer> wrtp: Sweet
[17:35] <niemeyer> wrtp: I'm just finishing the presence stuff with docs and whatnot
[17:37] <wrtp> niemeyer: right, that's me for the day. good to finish with a submit...
[17:37] <niemeyer> wrtp: +1
[17:37] <wrtp> niemeyer: have a good rest-of-day!
[17:37] <niemeyer> wrtp: Have a good evening
[17:38] <niemeyer> wrtp: thanks!
[17:38] <wrtp> niemeyer: will do
[23:32] <davecheney> heads up, while i'm waiting on a few things stabalise I'm doing juju ssh
[23:33] <davecheney> i'll do scp at the same time as it is very similar
[23:34] <niemeyer> davecheney: Cheers
[23:36] <davecheney> niemeyer: could you have a read of the email I sent to you and Aram yesterday about mstate.Open/Dial
[23:37] <davecheney> when you have a chance
[23:37] <niemeyer> davecheney: It does support TLS
[23:38] <niemeyer> davecheney: But I think we can chew one thing at a time
[23:38] <niemeyer> davecheney: We'll have to define a new protocol to establish the connection
[23:45] <davecheney> niemeyer: this is mainly for juju.Conn, what will replace the current UseSSH flag on state.Info ?
[23:45] <davecheney> I guess I can do UseTLS and the define mstate.Dial/DialTLS
[23:45] <niemeyer> davecheney: I think we should make mstate work entirely before we shift that over
[23:45] <niemeyer> davecheney: Because otherwise we'll have new issues
[23:45] <davecheney> of course
[23:46] <davecheney> i'm not trying to put the cart before the horse
[23:46] <niemeyer> davecheney: How to validate the certificate, how to provide the initial password, etc
[23:46] <davecheney> yeeesh
[23:46] <davecheney> all that :(
[23:46] <davecheney> so, do you want mongo tunneled over ssh ?
[23:47] <niemeyer> davecheney: UseSSH should at least so we can take the blocker out of everybody's plate
[23:47] <davecheney> understood
[23:47] <niemeyer> davecheney: Yeah, same thing we're doing now with ZooKeeper
[23:47] <niemeyer> davecheney: After we get everything else working, we can fix that
[23:47] <davecheney> sounds like a good plan to me
[23:48] <davecheney> i'm all booked for lisbo, gonna get there on time this time :)
[23:48] <davecheney> lisbon
[23:49] <niemeyer> davecheney: That's great to hear. We'll have a good time there
[23:50] <niemeyer> I'll get some dinner and bbiab
[23:59] <davecheney> niemeyer: we have unit.AssignedMachineId()
[23:59] <davecheney> would I be able to add
[23:59] <davecheney> (or replace it with)
[23:59] <davecheney> unit.AssignedMachine
[23:59] <davecheney> as most of the other machine related methods on unit take a *Machine, not an id


[03:32] <nhandler> pleia2: Very nice blog post. Remember, we have<EMAIL_ADDRESS>forwarding to the @gmail.com version
[03:42] <pleia2> thanks, and yeah I did remember about the ubuntu address but opted for the non-forward one
[09:27] <alourie> good morning