[01:22] <lug|52> thoughts on the new release? I burned it to a usb drive then left it in a pocket and sent it through the washing machine!


[22:47] <minasota> Quote for the day/night... "You don't need a parachute to skydive. You need a parachute to skydive, twice."


[04:50] <RAOF> I know everyone's either Sundaying or enroute to London, but have I accidentally broken cross-compile-chroot.sh?
[09:50] <dandrader> anpok, hey alan_g just told me that you plan to work on item 5 of https://docs.google.com/a/canonical.com/document/d/12aVPbX5qzr2GqF8yBcc17ZWsD9Z1kQfoSaYi2yMm1rE/edit#heading=h.17wq5abcr8cb
[09:50] <dandrader> anpok, is that so?
[09:52] <ogra_> W/Adreno-ES20( 2074): <core_glReadPixels:212>: GL_INVALID_OPERATION
[09:52] <ogra_> W/Adreno-EGLSUB( 2074): <CacheInvalidateHandle:243>: PMEM_INV_CACHES undefined
[09:52] <ogra_> i see a lot of this lately in the logcat output on a mako (N4) ^^^
[10:06] <anpok> dandrader: yes
[10:06] <anpok> there is just some recuring distraction around the split greeter work
[10:43] <kgunn_> camako: hello
[10:43] <alan_g> camako: welcome
[13:34] <mterry> Are there any known problems with mir/devel?  I've tried it on my mako, but the unity8 session never appears on screen (seems to be running fine).  What's the easiest way to debug this?  Get a display report, I'm guessing.  Any other reports that might be useful?
[13:39] <alf__> mterry: to use mir/devel you need some changes in platform-api, unity-mir and unity-system-compositor
[13:41] <mterry> alf__, yup, I built those branches
[13:42] <alf__> mterry: oh, the latest compatibility branches need mir/devel + lp:~alan-griffiths/mir/scene-grabs-Session-and-SessionListener (yes it's a mess)
[13:43] <mterry> alf__, ah...  I don't have that one
[13:43]  * mterry builds more branches
[13:46] <alf__> greyback: How can I get the latest Qt (the one that exhibits the blocking problem) to try on the phone?
[13:47] <greyback> alf__: it's already on your phone
[13:47] <greyback> Qt5.2 has the issue
[13:48] <alf__> greyback: ok, how can I trigger it?
[13:49] <alan_g> mterry: I couldn't reproduce the problem you reported as bug 1302689 (but I wrote a test case) - maybe you can provide more details.
[13:50] <mterry> alan_g, hmm OK.  Well that's good in a way.  Maybe I'm just misusing API or some such in USC.  But I have a new problem when I tried to use a newer mir revision where unity8 sessions don't want to appear at all.  Working on that (see scrollback)
[13:52] <alan_g> alf__: there are compatibility branches without (as well as with) scene-grabs-Session-and-SessionListener. The ones without "proposed" in them match devel
[13:52] <greyback> alf__: handiest is to grab the QML code in https://bugreports.qt-project.org/browse/QTBUG-37677, save it to a file on the device as test.qml. Then as phablet user run "qmlscene test.qml --desktop_file_hint=/usr/share/application/<something>.desktop"
[13:52] <greyback> alf__: that file prints the time every second to your console
[13:53] <alan_g> (yes it's a mess)
[13:53] <greyback> alf__: actually let me check something...
[13:53] <greyback> alf__: yeah that's fine
[13:54] <alf__> greyback: thanks
[13:54] <greyback> alf__: ok, now with that program running, hit the power key, and watch the console - the time stops printing after a few seconds
[13:54] <greyback> alf__: we want it so that the time does not stop printing to the console
[13:58] <alf__> greyback: thanks, reproduced
[13:58] <greyback> alf__: np, lemme know if you need a volunteer to test
[13:59] <mterry> alan_g, ah OK.  Then maybe I was using right compatibility branches anyway...  But no matter.  I'll try with all the proposed branches
[14:03] <alan_g> mterry: the related changes are largely moves & renames - so if it compiles you've got a consistent set.
[14:04] <mterry> alan_g, that's what I figured / have
[14:04] <mterry> alan_g, so mir/devel is working OK for you in tests?  Have you tried with a full stack with unity8 and such?
[14:06] <alan_g> mterry: not recently enough
[14:07] <mterry> alan_g, well.  It wasn't working great for me.  If you have time, I'd appreciate a sanity check on those results.  (specifically, I'm seeing no frames on screen, but no errors in logs)
[14:08] <mterry> alan_g, and this is without my split branch nonsense
[14:08] <alan_g> mterry: greyback has been using it
[14:09] <greyback> mterry: things were working on Thursday
[14:10] <mterry> greyback, would you mind retesting with tip?  I updated on Friday and things got worse for me.  But I'm not sure exactly what revision I had before
[14:12] <greyback> mterry: okay
[14:51] <alf__> greyback: could you please test the latest version of lp:~afrantzis/mir/non-blocking-swap-buffers-spike
[14:51] <alf__> greyback: (merged with the version of mir/devel + Alan's branches you are using, of course)
[15:11] <alf__> greyback: ^^^ also don't forget that you need the change in USC too
[15:14] <greyback> alf__: working on that now
[15:14] <alf__> greyback: thanks
[16:28] <alan_g> alf__: happy with the new names: https://code.launchpad.net/~alan-griffiths/mir/scene-grabs-Session-and-SessionListener/+merge/214275
[16:41] <greyback> alan_g: could you take https://code.launchpad.net/~alan-griffiths/unity-mir/compatibility-with-mir-changes/+merge/213079 , branch it at rev 209, and push as 0.1.8 compatible branch
[16:41] <greyback> it compiles for me against 0.1.8 anyway :)
[16:42] <alan_g> greyback: your wish will be granted (as soon as I get some CPU cycles on my laptop)
[16:43]  * duflu warms hands on greyback's laptop vent
[16:56] <greyback> alf__: slow going, but finally tested: bad news though, it's still blocking
[16:57] <greyback> alf__: to confirm, I built your spike branch, platform-api, unity-mir and USC
[16:58] <greyback> after about 3-4 seconds, the small qml test app stops printing to screen (I disabled the process suspend/resume just in case, no difference)
[16:58] <greyback> alf__: it's interesting, as when I unlock the screen, the greeter is visible, but as soon as I tap the screen, the test app appears and starts rendering once again
[17:00] <greyback> s/tap the screen/tap the right edge of the screen/
[19:23] <mterry> Saviq, so I lost my latest silo.  Is there a silo crunch right now or could I get a new one?  I've got a plan for avoiding the Mir nonsense I've dealt with recently
[21:31] <kdub> is it just me, or is khronos.org down today?
[21:43] <bschaefer> down for me


[20:47] <EtherMan> Hi. I'm trying to get netplan working for a static IP setup on my vm in Oracle cloud. But I keep getting a new file written in /run/netplan that isn't at all based on my /etc/netplan/01-enp0s3.yaml and it interferes with the config, but I can't figure out where this file is coming from. I've told cloud-init to not do networking with /etc/cloud/cloud.cfg.d/99-custom-networking.cfg so it shouldn't be that. Is there any way to find out where this
[20:47] <EtherMan> file is coming from or to tell netplan to ignore the /run/netplan dir?
[20:51] <judah> oh my lord there is an entire channel for this


[01:24] <StevenK> lifeless: So, sinzui told me about another table that I had forgotten about on the call this morning.
[01:24] <StevenK> launchpad_dogfood=> SELECT sourcepackagename from distributionsourcepackage as dsp join sourcepackagename as spn on dsp.sourcepackagename = spn.id where dsp.distribution = 1 and spn.name like '%linux%';
[01:24] <StevenK> Time: 37.420 ms
[01:24] <lifeless> is that populated now ?
[01:24] <StevenK> Seems to be
[01:24] <StevenK> 30k rows, a whole bunch for Ubuntu and Debian
[01:25] <StevenK> lifeless: Try that query on staging for me?
[01:25] <lifeless> 53ms
[01:25] <lifeless> 136 rows
[01:25] <lifeless> which suggests it includes stale packages.
[01:26] <lifeless> is linux 2.6.8 still valid, for instance ?
[01:26] <lifeless> StevenK: spn was never a problem anyhow ;)
[01:27] <StevenK> It's a published source package, at least
[01:27] <StevenK> lifeless: Well, no, but if we can fetch a good list of spns in 50 ms, it gives us a bit more time for the binary side
[01:29] <wgrant> StevenK: You can't use DSP.
[01:29] <StevenK> :-(
[01:29] <wgrant> StevenK: It's used for storing bug reporting guidelines.
[01:29] <wgrant> That is its only meaning.
[01:29] <wgrant> Some uploads and gina create them.
[01:29] <wgrant> But you cannot derive any meaning from them.
[01:30] <StevenK> Curtis was of the opinion that it was used for upstream linking too
[01:30] <lifeless> it is
[01:30] <lifeless> it could be used, if you extend it to know active/inactive
[01:31] <lifeless> and make sure its kept up to date
[01:31] <StevenK> TBH, if wgrant says the data in it is not trustworthy I'm inclined to not use it
[01:31] <lifeless> StevenK: oh, and for the vocab, don't forget to also look for published source package branches with no SPR
[01:32] <StevenK> lifeless: Right, and that 26 minute query can take even longer :-P
[01:33] <lifeless> StevenK: there is a escalated bug for ensemble requesting this
[01:33] <StevenK> lifeless: Curtis and I have discussed it a few times. I want to get to the vocab working and then work on extending it
[01:33] <lifeless> sure
[01:36] <wgrant> Aha!
[01:36] <wgrant> Unity has taken minimalism a step further.
[01:36] <wgrant> It is now Nautilus.
[01:37] <wgrant> The launcher and dash and indicators are gone... all there is is the Nautilus root window and its menu bar.
[01:50] <wallyworld_> does anyone know how to create a project or distro with an icon for testing purposes?
[01:51] <lifeless> set the branding
[01:51] <lifeless> click on 'edit details' scroll to the bottom then 'edit branding', I think
[01:51] <lifeless> its a very clunky bit of ui
[01:51] <wallyworld_> lifeless: i mean in code
[01:52] <lifeless> not offhand - does the factory have an option ?
[01:52] <wallyworld_> not that i can see :-(
[01:52] <StevenK> factory.makeDistribution() and then you probably have to twiddle something in it
[01:52] <StevenK> Let's see
[01:52] <lifeless> look for tests for branding to see how
[01:53] <wallyworld_> ok, thanks. my other searches have failed to find anything
[01:53] <StevenK> wallyworld_: Create an LFA and then set IDistribution.icon to it
[01:53] <StevenK> You also have IDistribution.logo
[01:53] <wallyworld_> LFA?
[01:53] <StevenK> LibraryFileAlias
[01:54] <wallyworld_> ok, there is a factory or something for that?
[01:54] <StevenK> factory.makeLibraryFileAlias(content=<foo>) ; transaction.commit()
[01:54] <wallyworld_> excellent, thanks
[02:59] <wallyworld_> wgrant: StevenK: want a small review (one line change plus tests)? https://code.launchpad.net/~wallyworld/launchpad/person-affiliation-breakage-823644/+merge/70981
[03:00] <StevenK> wallyworld_: It will cost you. What do you have?
[03:00] <StevenK> Oh, right. You're married with kids, so nothing.
[03:00] <wallyworld_> my eternal gratitude?
[03:00] <wallyworld_> hah
[03:00] <wallyworld_> i keep photos in my wallet where my money used to be :-/
[03:02] <j-johan-edwards> > from lazr.restful.interfaces import IRepresentationCache
[03:02] <j-johan-edwards> ImportError: cannot import name IRepresentationCache
[03:03] <j-johan-edwards> Any idea what might be going on? (I have lucid's python-lazr.restful installed)
[03:04] <StevenK> wallyworld_: r=me with a comment
[03:04] <wallyworld_> StevenK: thanks
[03:06] <wallyworld_> StevenK: with the commit, there's a number of other usages of LFA in tests without a commit. modt of them seem to not have one
[03:07] <StevenK> j-johan-edwards: The version of python-lazr.restful in lucid is about 18 months old
[03:07] <StevenK> wallyworld_: Right, so I'm not saying thou must add thy commit, or no +1 from me
[03:08] <StevenK> wallyworld_: I'm just saying it's something to watch for
[03:08] <wallyworld_> StevenK: np. thanks
[03:08] <j-johan-edwards> StevenK: Ah. The wiki Running page said Lucid was the only support version
[03:08] <StevenK> j-johan-edwards: What are you trying to do with lazr.restful?
[03:10] <j-johan-edwards> Trying to make heads or tails of the source tree. Imported lp.soyuz.model.binarypackagerelease, which asks for that module.
[03:11] <StevenK> j-johan-edwards: I would strongly suggest you use rocketfuel-setup to check out LP's tree
[03:11] <j-johan-edwards> I did. It claimed everything was okay, so I ran `make schema`, which also worked
[03:11] <j-johan-edwards> `make run` also works, oddly
[03:12] <j-johan-edwards> I actually tried building on Natty too, but had a similar import error for lazr.config
[03:12] <StevenK> Oh! Are you running 'python' and trying to import stuff?
[03:13] <j-johan-edwards> Yup
[03:13] <StevenK> Yes, that won't work
[03:13] <StevenK> Use 'bin/py' in the source tree, or 'make iharness'
[03:14] <j-johan-edwards> Thanks a ton! Just tried it again, and that works great.
[03:22] <wgrant> j-johan-edwards: LP uses lots of dependencies that aren't in Lucid. You can find them in eggs/ within the LP branch.
[03:24] <lifeless> nesting project groups would be mega useful.
[03:25] <wgrant> lifeless: No.
[03:25] <wgrant> lifeless: Nesting projects :)
[03:30] <lifeless> wgrant: well, if project groups died, sure
[03:30] <wgrant> They are going to die before they get any significant changes.
[03:57] <LPCIBot> Project devel build #960: FAILURE in 5 hr 42 min: https://lpci.wedontsleep.org/job/devel/960/
[04:18] <lifeless> is it intentional that LP shows a /!\ in the involvement portlet when you select 'N/A' for translations ?
[04:19] <StevenK> It's probably supposed to be an icon
[04:20] <lifeless> well it is an icon
[04:20] <lifeless> I'm just confused
[04:20] <lifeless> if you say 'unknown', a warning with 'lp needs to know' is sensible
[04:20] <lifeless> but its set to N/A
[04:20] <lifeless> shouldn't that just hide the line ?
[04:29] <j-johan-edwards> Hello, sorry to come crying for help again so soon
[04:29] <j-johan-edwards> Every getUtility(Iwhatever) call I make results in a zope.component.interfaces.ComponentLookupError
[04:30] <wgrant> j-johan-edwards: bin/py doesn't set up utilities -- use bin/harness for that.
[04:30] <j-johan-edwards> thanks!
[04:32] <j-johan-edwards> Is there some piece of documentation I'm missing on the wiki? Or are some sections of the Hacking page (eg #Storm) just incomplete?
[04:32]  * j-johan-edwards ignores the possibility he simply fails to grasp the obvious
[04:32] <lifeless> j-johan-edwards: theres a vast learning curve around lp development
[04:32] <lifeless> we want to improve that
[04:32] <lifeless> (by lowering the curve, not documenting the curve :P)
[04:33] <wgrant> j-johan-edwards: Well, Hacking doesn't say it should be run in bin/py.
[04:33] <StevenK> It isn't a curve, it's a bleeding cliff!
[04:34] <j-johan-edwards> haha
[04:35] <lifeless> j-johan-edwards: so what are you hacking on ?
[04:37] <j-johan-edwards> lp:archive-index (I might give up if I can't hack in though)
[04:38] <lifeless> j-johan-edwards: integration with LP ?
[04:38] <j-johan-edwards> lifeless: yeah, for the past few months I've been working on an archive crawler for mvo
[04:39] <j-johan-edwards> but it's becoming obvious it won't scale, so an automated solution is important
[04:39] <lifeless> what sort of data does it extract?
[04:39] <j-johan-edwards> app-install-data-ubuntu, basically
[04:40] <StevenK> Right, so it's as I feared. You'd like an easier way to get at contents rather than parsing Contents-<arch>.gz?
[04:41] <j-johan-edwards> Yup, I saw your populate-bprc branch, which boosted my hopes of making that possible
[04:41]  * StevenK had no idea he had a stalker ... :-P
[04:42] <j-johan-edwards> haha, lifeless actually directed me to you, so you've got two
[04:42] <StevenK> lifeless just stalks all LP devs, so that's nothing new
[04:43] <lifeless> StevenK: and now its my job!
[04:43]  * StevenK waits for "And I'm watching you ..."
[04:44] <stub> StevenK: that will arrive by a postcard slipped under your door.
[04:45] <StevenK> Haha
[04:45] <wgrant> No, he'll find it in his pocket.
[04:45] <lifeless> ... of his pyjamas
[04:45] <StevenK> Along with a video called "The Branch" ?
[04:46] <StevenK> j-johan-edwards: Keep in mind the BPRC work is in my spare time, and I'm not really pushing it with any priority
[04:46] <nigelb> StevenK: "It isn't a curve, it's a bleeding cliff!" +!
[04:46] <nigelb> +1
[04:46] <wgrant> It's not that bad!
[04:47] <wgrant> I submitted my first branch after like a day.
[04:47] <StevenK> wgrant: Yes, but 1) You're insane. 2) You already knew Zope.
[04:47] <wgrant> And it even changed tests.
[04:47] <nigelb> haha
[04:47] <nigelb> I wsa about tos ay that.
[04:47] <nigelb> I wrote a one line patch.
[04:47] <nigelb> Then I realized I had to write 25 lines of tests :)
[04:48] <nigelb> so, for someone starting out, you open the code. and you need to grep to find what you're looking for. Then you a *lot* xml files.
[04:49] <StevenK> My first branch for LP changed 2 lines. Sadly, it then broke 200 tests
[04:49] <nigelb> fun!
[04:49] <nigelb> I redid a branch 2 times I think.
[04:50] <StevenK> nigelb: Why? You can get away with ignoring the ZCML
[04:50] <StevenK> And bzr grep is *love*
[04:50] <nigelb> StevenK: of course you can. but its scary to see a lot of xml :)
[04:50] <StevenK> nigelb: Lots of XML is solved by shovelling more XML at the problem
[04:51] <StevenK> After a while you forget what you were trying to solve.
[04:52] <nigelb> is that like regular expresssions?
[04:52] <nigelb> ;)
[04:52] <StevenK> Oh hey, I wrote one of those yesterday
[04:52]  * ajmitch is suddenly scared
[04:52] <StevenK> And then ran it over devel ...
[04:52] <nigelb> "if you have a problem and you use regular expressions to solve it, then you have 2 problems"
[04:53] <StevenK> % bzr di -r submit: | wc -l
[04:53] <StevenK> Using submit branch /home/steven/launchpad/lp-branches/devel
[04:53] <StevenK> 6501
[04:54] <nigelb> also of note, now I'm more comfortable with lp.
[04:55] <StevenK> nigelb: You need to submit more branches!
[04:55] <nigelb> StevenK: working on one, need more hours in a day.
[04:55] <StevenK> Make a branch for that too?
[04:56] <nigelb> against what project?
[04:56] <StevenK> lp:universe
[04:57] <nigelb> aha
[05:00]  * StevenK ponders how to write a db patch, given this whole FDT thing
[05:00] <nigelb> I'm going through rtfd that jml set up some time back.
[05:01] <nigelb> I wonder if lp will ever get a feature like rtfd/github pages
[05:01] <lifeless> if someone does it well, sure
[05:02] <lifeless> though there is merit in just integrating with rtfd well, particularly if that site is open source (is it?)
[05:02] <nigelb> it is
[05:02] <nigelb> its django based
[05:02] <lifeless> nigelb: and its source is available ?
[05:02] <nigelb> https://github.com/rtfd/readthedocs.org
[05:03] <lifeless> cool
[05:03] <lifeless> now just need to get them hosted on an open site
[05:04] <nigelb> so, out of the box, rtfd already can scan bzr branches.
[05:04] <StevenK> That is one thing that annoys me. How much flak did LP cop for not being open, and you don't see people complaining about github
[05:04] <nigelb> heh
[05:04] <wgrant> Nobody is going to clamour for GitHub to be open, because GitHub is not crap.
[05:04] <lifeless> that seems spurious :)
[05:04] <wgrant> Oh?
[05:05] <wgrant> People wanted LP to be open partly because LP was a piece of shit :)
[05:05] <lifeless> I would expect the reverse correlatio
[05:05] <lifeless> more good -> more desire for it to be open
[05:05] <nigelb> everyone seems to have a github.
[05:05] <wgrant_> jtv: QA!
[05:06] <nigelb> haha
[05:06] <wgrant> That was a real WTF moment for a while there.
[05:06] <jtv> wgrant: FO!
[05:06] <nigelb> lol
[05:06] <nigelb> WIN
[05:06] <nigelb> StevenK: That was awesome.
[05:06] <wgrant> I must need to crank up the protection on wgrant_...
[05:07] <StevenK> Now to look up my Nickserv password again
[05:07] <nigelb> can't protect it for these less that 30 sec bursts.
[05:07] <nigelb> unless you're signed into it.
[05:07] <nigelb> in which case, StevenK can still d wgrant__
[05:07] <nigelb> or wgrant`
[05:08] <StevenK> It was for comedic value only
[05:08] <nigelb> and it was sucessfull run!
[05:08] <wgrant> Yeah, I only have wgrant and wgrant_, and ENFORCE only works after a certain time.
[05:08] <wgrant> Sad.
[05:08] <StevenK> I told jtv he had QA to do and he told me I could have been better at impersonating wgrant.
[05:08] <StevenK> So I was.
[05:23] <nigelb> So, hacking on Lp can still be counted as rest when I'm sick right? :)
[05:23] <wgrant> I hope so, or I'm a bad person.
[05:23] <lifeless> if it counts as rest, thats proof you are sick ?
[05:24] <nigelb> hah
[05:30] <lifeless> pop quiz
[05:31]  * wgrant blames python-oops.
[05:31] <lifeless> Would defining an oops report as a 'dict suitable for bson serialisation' be problematic ?
[05:31] <lifeless> wgrant: :P
[05:31] <wgrant> lifeless: That's what has always made a lot of sense to me.
[05:35] <j-johan-edwards> I just retrieved a record from a table
[05:35] <j-johan-edwards> Most beautiful moment of my life...
[05:37]  * wallyworld__ doing qa, and finds an interesting user on qas:
[05:37] <wallyworld__> Cost Of Viagra - Online Pharmacy - No Prescription Drugs, Health and Beauty, plus more in Launchpad in Launchpad (dalefyoboardinghouse)
[05:37] <wallyworld__> <email address hidden>
[05:37] <wallyworld__> Member since 2009-12-17
[05:37] <wgrant> Hah.
[05:37] <nigelb> lol
[05:38] <wallyworld__> i'm too young for viagra
[05:38] <wgrant> We get a lot of them, sadly.
[05:38] <wallyworld__> just
[05:38] <wallyworld__> do we have permission to deactivate such users ourselves?
[05:39] <wgrant> Administer account
[05:39] <wgrant> Set status to suspended.
[05:39] <wgrant> Declare victory.
[05:39] <wgrant> There are instructions on the wiki.
[05:39] <wgrant> On dealing with spam.
[05:39] <wallyworld__> np. was just wondering out loud if we had permission to do that
[06:02] <lifeless> oh wow
[06:02] <lifeless> this is going to break LP :P
[06:02] <lifeless> we've been parsing iso8601 timestamps as TZ unaware.
[06:02] <wgrant> Python's good at that.
[06:04] <lifeless> ah well, extracted code can be good.
[06:04] <lifeless> LP can deal.
[06:05] <lifeless> woot
[06:05] <nigelb> extracted? abstracted?
[06:06] <lifeless> extracted
[06:06] <nigelb> what does that mean?
[06:09] <lifeless> to take out of
[06:09] <lifeless> well, 'taken out of' 'removed'
[06:10] <nigelb> ah
[06:10] <lifeless> lp:python-oops
[06:19] <lifeless> can has review? https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/70993
[06:21] <StevenK> Suppose
[06:22] <lifeless> original code is in lib/canonical/launchpad/webapp/errorlog (and tests/test_errorlog)
[06:45] <lifeless> StevenK: thanks!
[06:51] <lifeless> stub: how long does the 'ALTER TABLE BugMessage ALTER COLUMN owner SET NOT NULL;' take to apply ?
[06:52] <lifeless> stub: (I'm wondering if an index could do it instead, and be done CONCURRENTLY
[06:58] <nigelb> who's the postgres expert?
[06:58]  * nigelb points them to https://schemaverse.com
[07:01] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/70995
[07:01] <lifeless> nigelb: thats evil
[07:04] <nigelb> heh
[07:05] <rvba> lifeless: Hi, I'd be happy to move all the js files used to ~lpqateam but I'm afraid you will have to tell me how to do that (if I can do it myself) because I don't seem to have the right permissions.
[07:06] <lifeless> I can probably do that later tonight; or losa could;
[07:06] <lifeless> or francis or the qa team :)
[07:11] <rvba> lifeless: ok thanks, if you don't have to do it before you EOD, I'll grab a losa later today then.
[07:13] <jtv> Thanks for the review, StevenK
[07:15] <rvba> don't have *time* even
[07:17] <jtv> StevenK: The extra check you're asking for is not under the purview of the method that the test is for; it's DSD.update's job and presumably you tested for it!
[07:17] <jtv> The fact that update() is called on the DSD is also already tested.
[07:39] <adeuring> good morning
[07:39] <stub> lifeless: as long as it takes to do a full table scan of bugmessage
[07:39] <stub> lifeless: You can't duplicate that constraint with an index.
[07:40] <stub> lifeless: it might use the index on the column to avoid the scan, but I wouldn't count on it. Staging timing is what we want to see.
[07:41] <stub> full scan is < 10 secs
[07:51] <lifeless> stub: cool
[07:52] <lifeless> stub: we're going to need to think up ways to handle big tables ;)
[08:06] <stub> lifeless: Apart from bypassing PG's protections and attacking the data dictionary directly, you can't. Theoretically CONCURRENTLY could be added to this stuff, but I doubt anyone will bother.
[08:06] <stub> lifeless: Best way of handling big tables is to not have them :-)
[08:06] <allenap> Thanks for the review StevenK :)
[08:06] <lifeless> heh :P
[08:07] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/70995
[08:07] <stub> lifeless: Not totally joking. Archiving old data, partitioning
[08:07] <lifeless> stub: yeah, I know
[08:09] <stub> lifeless: reviewed
[08:09] <lifeless> thanks!
[08:10] <StevenK> allenap: I'm not so happy with JS-only reviews, but it looked pretty good.
[08:11] <allenap> StevenK: Didn't you hear? The SOA is going to be based on node.js.
[08:12] <lifeless> allenap: you can troll so much better if you want to
[08:14] <allenap> StevenK: Didn't you hear? The SOA is going to be based on Drupal.
[08:15] <StevenK> allenap: Are you just working down a list? Is PHP the next item? :-P
[08:15] <wgrant> Drupal *is* PHP.
[08:15] <allenap> StevenK: I thought I'd gone past PHP with Drupal.
[08:18] <lifeless> stub: so poking at the internals and reindexing seems plausible as a future recipe
[08:20] <stub> lifeless: I'd consider not adding the constraint before considering internal hacking. That could screw us, and we not know for quite a while.
[08:20] <lifeless> sure
[08:20] <lifeless> not something to do lightly
[08:22] <stub> Yay standardization.  And all the staging stuff worked out of the box like you said - thought I would have to rewrite parts of the automation but looks unnecessary!
[08:38] <wgrant> stub: Yeah, I was a bit wary about trying it when I did, thinking I was going down a bit of a rabbit hole... but nope.
[08:38] <wgrant> All worked.
[08:41] <wgrant> Python exceptions are slow :(
[08:43] <jtv> Yes.
[08:46] <wgrant> For dicts, it seems that these relations hold: LBYL with 'in' < get() < catching KeyError
[08:46] <wgrant> I would not have expected get() to be slower than a manual check.
[08:46] <lifeless> mmm
[08:47] <lifeless> 'in' + get will be slower than just get, if you know you want the item
[08:47] <lifeless> in itself is fast, yes
[08:47] <wgrant> Nope.
[08:47] <lifeless> really?
[08:47] <lifeless> !cite
[08:48] <wgrant> Well, if there are lots of misses then checking 'in' first is faster.
[08:48] <wgrant> Saves 50ms in privilege delta generation.
[08:48] <wgrant> Not significant, but rather odd.
[08:52] <lifeless> strange:
[08:52] <lifeless> http://paste.ubuntu.com/662462/
[08:52] <wgrant> Odd.
[08:53] <lifeless> get on hit or miss is ~constant
[08:53] <lifeless> in is also approx constant, and 1/3 a get
[08:54] <jtv> how sensitive are they to what's in the dict?
[08:54] <lifeless> the hash() call on the object is crucial
[08:55] <jtv> This is a pretty big difference already.
[08:55] <lifeless> beyond that, its dict size - and they scale very well
[08:56] <jtv> btree, right?
[08:56] <jtv> Just curious about irregularities w.r.t. how deep in the tree the element is, and how branch prediction factors in.
[08:58] <lifeless> its a hash
[08:58] <jtv> Open or closed?
[08:58] <lifeless> open
[08:59] <lifeless> http://permalink.gmane.org/gmane.comp.python.devel/29960
[09:00] <lifeless> mrevell: hey
[09:00] <lifeless> mrevell: I'd like to catch up with you sometime; when would be good?
[09:01] <jtv> No linear probing?  I would've expected that to work pretty well with good access predictors.
[09:01] <mrevell> lifeless, Howdy. How does after the TL call sound?
[09:02] <lifeless> mrevell: sweet
[09:35] <wgrant> stub: So, I have table privilege resetting down from 5.5s to 60ms.
[09:35] <wgrant> Which should shave 40s off the production outage time.
[09:35] <wgrant> Which is possibly handy.
[09:36] <stub> wgrant: \o/
[09:36] <wgrant> The whole thing still takes 450ms per DB, but the first 400ms is as-yet unoptimised and probably small enough that we don't care too much.
[09:38] <LPCIBot> Project db-devel build #797: STILL FAILING in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/797/
[09:38] <stub> wgrant: Yup. We are in the good enough zone for now. We need to test this on staging first of course - if we land it now on db-devel it should get a run before the first possible fastdowntime deploy.
[09:39] <stub> wgrant: or we can leave it until after and have synced db-devel->devel etc.
[09:39] <rvba> matsubara: Hi Diogo, may I bother you with a small "moving files around" problem? I'd like your help to put a few files in https://devpad.canonical.com/~lpqateam/.
[09:39] <rvba> matsubara: Here is the whole story https://code.launchpad.net/~rvb/launchpad/trace-report/+merge/70839
[09:39] <matsubara> hi rvba. sure thing. let me take a look
[09:42] <matsubara> rvba, I need to figure out how the ppr is deployed. I'll do that today and let you know what's needed
[09:45] <rvba> matsubara: Ok great. (It's just a matter of moving the 3 or 4 Javascript file that are needed by reports like https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-pageids.html but I'll obviously have to change the paths in the python code that generates the reports once you've decided where to put them)
[09:46] <rvba> files*
[10:05] <allenap> Okay, who removed check-db-revision.py?!
[10:06] <StevenK> allenap: "Come on, own up! I can wait all night ..."
[10:07] <matsubara> rvba, I put all the js files here: https://devpad.canonical.com/~lpqateam/ppr/js/
[10:07] <matsubara> would that work for you?
[10:07] <rvba> matsubara: absolutely. Thanks a lot. I'll modify the script.
[10:08] <matsubara> rvba, cool. you're welcome. let me know when that lands so I can update the launchpad branch on devpad
[10:10] <rvba> matsubara: I'll make the changes right away and throw that at ec2.
[10:26] <danilos> allenap, re check-db-revision, could it be related to our hot/cold db patches stuff? iow, 2208-*-0 patches are checked, and all the others aren't (at least that's how I understood it)
[10:28] <wgrant> danilos, allenap`: We needed a way to have optional patches.
[10:28] <wgrant> danilos, allenap`: And it was decided to just remove the checks entirely.
[10:28] <allenap> wgrant: The problem is that check_schema in Makefile is broken. I wondered if anyone had noticed. If not, I'll kill it.
[10:30] <wgrant> Hm, why didn't that hit anyone earlier, I wonder.
[10:30] <wgrant> Anyway, yeah, should be killed.
[10:36] <jml> is there a syntax highlighting mode for build failures, or something?
[10:39] <wgrant> jml: For binary package builds? No.
[10:39] <wgrant> Given that they are in whatever format the package chooses, that would be... non-trivial.
[10:39] <jml> well
[10:40] <jml> I guess I don't really know enough about what canonical.buildd does, but I could imagine it inserting some kind of markup to make failures easier to read.
[10:40] <jml> or, you know, *find*
[10:42] <wgrant> jml: We have no control over the output between the lines starting 'dpkg-buildpackage: ' and the '************************************************' right before the 'FAILED [dpkg-buildpackage died]'
[10:43] <wgrant> We like to treat everything between 'RUN: /usr/share/launchpad-buildd/slavebin/sbuild-package' and 'RUN: /usr/share/launchpad-buildd/slavebin/scan-for-processes' as not ours, too, since that would bring us further away from real sbuild, when we hope to use the package soon.
[10:44] <jml> for my build failure, those are lines 524-597 out of 720
[10:44] <jml> which is a pretty small fraction
[10:44]  * jml looks again
[10:45] <jml> and would probably be interesting to call out in some way
[10:45] <jml> starting from sbuild-package expands it quite a lot.
[10:46] <jml> wgrant: are there plans to switch to real sbuild?
[10:46] <wgrant> jml: There's even a branch.
[10:46] <jml> zowie
[10:46] <wgrant> But it's not quite landable.
[10:46] <wgrant> It's been dormant for around a year.
[10:46] <wgrant> May get to it when I'm on maintenance again.
[10:46] <wgrant> But it needs to be done this year some time.
[10:46] <wgrant> Or Ubuntu will explode.
[10:46] <jml> well more advanced than 'stop using commercial admin' plans
[10:46] <jml> ubuntu has already exploded a little
[10:46] <wgrant> Heh.
[10:47] <jml> apt-file doesn't work any more. Debian has its Contents files in different places now.
[10:48] <wgrant> They seem to be in the same place as usual...
[10:48] <wgrant> http://ftp.debian.org/debian/dists/sid/Contents-i386.gz
[10:48] <wgrant> Huh.
[10:49] <wgrant> launchpad_main holds only DELETE on packagebuild.
[10:49] <wgrant> Not SELECT or anything.
[10:50] <jml> wgrant: apt-file is looking for them under the component dirs.
[10:50] <jml> e.g. http://ftp.debian.org/debian/dists/sid/main/
[10:51] <wgrant> jml: They're there too (Ubuntu doesn't have component-specific ones, though)
[10:51] <jml> yeah, so apt-file is broken on Ubuntu.
[10:51] <wgrant> Ohh, I see what you mean.
[10:51] <wgrant> Right.
[10:52] <wgrant> I thought you meant our apt-file was broken for Debian.
[10:52] <wgrant> Right.
[10:52] <wgrant> We'll be writing out Contents files natively soon (StevenK has a branch for big bits of that), so it will be easier.
[10:53] <wgrant> We still use apt-ftparchive to do it, which Debian stopped doing a year or so ago.
[10:53] <jml> what does Debian use now?
[10:54] <wgrant> They write it out directly from dak's DB.
[10:55] <elmo> wait what?
[10:55] <elmo> they put package file listings into the DB?
[10:55] <wgrant> Yes.
[10:55] <elmo> wow, that's insane
[10:55] <wgrant> Howso?
[10:55] <wgrant> a-f is not precisely fast.
[10:55] <elmo> the answer is not to bloat out the DB with something that's you don't use in any sort of relational way
[10:56] <elmo> I mean if it works for Debian, all power to them
[10:56] <elmo> but for us, it would be crazy
[10:56] <wgrant> It should ideally be in some separate database, yes.
[10:56] <elmo> it's a cache, not a DB
[10:57] <wgrant> A DB cache.
[10:57] <elmo> *shrug* sure - putting that into launchpad_prod would be, IMNSHO, worse than silly
[10:57] <elmo> (and that's me trying very hard to be polite)
[10:59] <wgrant> The hottest part of the table would be ~300MB that is accessed hourly, or possibly only once a day.
[10:59] <wgrant> It's not *that* terrible.
[11:00] <elmo> a single Contents file for a single architecture/series is 300Mb
[11:00] <elmo> so I question your maths
[11:00] <wgrant> You have a good point there.
[11:00] <elmo> and quite frankly, even if it only ends up adding tens of gigabytes, it's still completely the wrong thing to do
[11:00] <wgrant> I'd forgotten about the whole multiple archs thing there for a moment.
[11:01] <wgrant> Maybe in a few years we'll have multiple DBs.
[11:01] <elmo> and until then we'll keep adding stuff to the single one we have that we don't need to?
[12:35] <allenap> danilos: Do you fancy reviewing a 1910 line diff? 90% of it is mechanical change that you can skip. https://code.launchpad.net/~allenap/launchpad/lazr-anim-stuff/+merge/71016
[12:36] <danilos> allenap, "fancy" is the wrong word, but sure :)
[12:36] <allenap> danilos: Thanks :)
[12:47] <danilos> allenap, ok, mostly good, I wonder if a check Y.Lang.isValue(to) would work better for the "to" variable (line 248 of the diff)
[12:48] <allenap> danilos: Yeah, that would keep in spirit with the rest of the changes.
[12:48] <danilos> allenap, right, that's all I could find to complain about, so r=me :)
[12:49] <allenap> danilos: Thanks!
[13:00] <deryck> Morning, all.
[13:01] <allenap> Morning deryck :)
[13:03]  * danilos -> food
[13:45] <allenap> danilos: Got time for a *much* shorter JavaScript branch? https://code.launchpad.net/~allenap/launchpad/phantom-overlay-bug-820828/+merge/71044
[13:49] <danilos> allenap, you've got a bunch of conflicts there
[13:51] <danilos> allenap, though, that seems to be from the anim branch
[13:52] <allenap> danilos: Yeah. I'm working on them now.
[13:52] <danilos> allenap, r=me, but I wonder about the var declaration and assignment split-up: is there a reason to prefer one over the other? or is that just your coding style that you hope becomes LP JS style?
[13:54] <allenap> danilos: Ah, that's to silence lint as much as anything. It complains that PersonPicker is not fully defined in PersonPicker.
[13:55] <allenap> I have no preference for that style, but I don't mind it either.
[13:55] <bac> matsubara: great job on the dashboard!
[13:55] <allenap> danilos: Thanks for the review :)
[13:59] <matsubara> thanks bac :-)
[15:07] <gary_poster> abentley, are you up for answering an importd question from spm, or should I try to get an answer from thumper or mwhudson?  https://answers.launchpad.net/launchpad/+question/167471
[15:08] <abentley> gary_poster: best to ask thumper or mwhudson.
[15:08] <gary_poster> abentley, ack will do thanks
[15:09] <gary_poster> bigjools, would you be willing to field https://answers.launchpad.net/launchpad/+question/167457?  If I had to guess, I would guess that this is a "convert question to bug and mark WONTFIX" but it's really well out of my league.
[15:10] <bigjools> gary_poster: I'l answer it.
[15:10] <gary_poster> Thank you bigjools
[15:16] <bigjools> gary_poster: answered.  He probably won't like it... I hope you grok what I said
[15:17] <gary_poster> bigjools, I read it and understood, thank you (other than not being familiar specifically with quilt).
[15:17] <bigjools> gary_poster: I am not that familiar with it either :)
[15:18] <gary_poster> heh ok :-)
[15:26] <LPCIBot> Yippie, build fixed!
[15:26] <LPCIBot> Project devel build #961: FIXED in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/961/
[15:48] <allenap> abentley: Hi there, got time for a little bug fix in browser code? https://code.launchpad.net/~allenap/launchpad/dsd-batch-position-reset-bug-822781/+merge/71069
[15:48] <abentley> allenap: sure.
[15:48] <allenap> Thanks.
[15:49] <abentley> allenap: what is the full_url for?
[15:51] <abentley> allenap: I think "The forms should post to themselves, including GET params" is internally inconsistent.
[15:54] <allenap> abentley: The full_url is to show that the URL is not just for the action, which it was before. It's just a naming exercise to show that the action_url and next_url are both essentially the URL with query parameters.
[15:54] <allenap> abentley: I'll fix the docstring, oops.
[15:59] <abentley> allenap: It would be nice if  BasicLaunchpadRequest.get_url could produce URLs that included the query string.
[15:59] <abentley> s/get_url/getURL/
[16:00] <abentley> allenap: r=me.
[16:02] <allenap> abentley: I could add a getFullURL or getURLWithQuery method to LaunchpadBrowserRequestMixin, which would then sort out LaunchpadTestRequest at the same time as BasicLaunchpadRequest.
[16:02] <abentley> allenap: Or getURL(include_query=False).  Any of those would be nice.
[16:03] <allenap> abentley: Okay, I'll do that, shouldn't take long... <days later>...
[16:03] <abentley> allenap: -)
[16:23] <sinzui> jcsackett, do you have time to mumble?
[16:24] <jcsackett> sinzui: sure.
[17:03] <allenap> abentley-lunch: I've made that change to getURL. Would you be able to take another look at the mp? It's still reasonably short. The only problem is that I have to go now, but I can check back in ~2 hours.
[17:03] <abentley-lunch> allenap: sure.
[17:03] <allenap> Thanks!
[17:07] <abentley> allenap: is it actually true that the form is POSTed to a URL with GET parameters?
[17:24] <abentley> allenap: it is pretty unusual to post to a URL with a query string, although I'm not clear whether it violates the spec.
[17:26] <henninge> abentley: Hi! Can you please review my branch? https://code.launchpad.net/~henninge/launchpad/bug-823164-remove-translations-by/+merge/70961
[17:27] <abentley> henninge: sure.
[17:27] <henninge> abentley: cool, thanks
[17:41] <abentley> henninge: r=me
[17:44] <henninge> abentley: thank you! ;-)
[18:46] <lifeless> morning
[18:48] <nigelb> Good morning.
[19:13] <allenap> abentley: I don't think there is anything against POSTing to a URL with a query string. I think the earlier docstring was misleading: a query string is part of the URL, but we've become accustomed to thinking of them as GET parameters.
[19:15] <abentley> allenap: I guess that makes sense.
[19:16] <abentley> allenap: thanks for making the change.
[19:17] <allenap> abentley: It was a good idea.
[19:20] <sixstring> I'm digging into the canonical-identity-provider code. I know I'm going to need some help plugging my stuff into it. Is this the right IRC channel for asking for help with canonical-identity-provider?
[19:22] <sixstring> bots?
[19:28] <allenap> sixstring: I don't think many of us hack on the central SSO parts, but I can't find a better place for it. sinzui, do you know any more?
[19:31] <allenap> sixstring: Email https://launchpad.net/~stuartmetcalfe; if anyone will know where the best place to hang out for c-i-p is, it's him.
[19:33] <sixstring> allenap: Thanks. Will do.
[19:35] <allenap> abentley: I forgot to say, thanks for the (double) review.
[19:35] <abentley> allenap: no problem.
[19:39] <sinzui> sixstring, allenap SSO is 100% ISD. We did not write any of the code
[19:39] <sixstring> ISD?
[19:39] <sixstring> Sorry, I don't know that abbrev, sinzui.
[19:40] <sinzui> sixstring, https://launchpad.net/canonical-identity-provider The team that maintain the app
[19:41] <sixstring> OK, sinzui. That makes sense now.
[19:41]  * sixstring is still figuring out how Canonical works.
[19:55] <nigelb> sinzui: hey
[20:00] <sixstring> sinzui, allenap: stuart pointed me to #canonical-isd.
[20:04] <nigelb> sinzui: was my post unclear that sso is a separate service?
[20:05] <sinzui> nigelb, I did not see your post. I know very well it is a separate service
[20:05] <nigelb> hm, wonder who commented then.
[20:05] <sinzui> I advocate turning of login.launchpad.net to stop confusing people about what Lp knows about users
[20:06] <nigelb> well, except there are other comlications.
[20:06] <nigelb> login.u.c is more stricter in config than login.l.c
[20:06] <nigelb> and there's some slight schema change
[20:06] <nigelb> but, yeah. Eventually, we'll all switch.
[20:07] <bdmurray> gary_poster: do you have any plans to follow up with the reporter of bug 823367?
[20:07] <_mup_> Bug #823367: Natty installation failed <installer-crash> <natty> <ubiquity-2.6.10> <ubiquity (Ubuntu):New> < https://launchpad.net/bugs/823367 >
[20:12] <gary_poster> bdmurray, I did not, but I can if desired.  I think I can get her email again
[20:14] <bdmurray> gary_poster: well its a common error if installing behind a proxy server with a specific behavior so working around it may be complicated for her.  I'll just set to invalid rather than finding the master bug.
[20:14] <gary_poster> bdmurray, ok.  If you had a page that might help her, I'd certainly be happy to pass it along.
[20:17] <bdmurray> gary_poster: I don't think we have a really good workaround documented
[20:17] <gary_poster> fair enough bdmurray.  OK thanks for heads up.
[21:09] <LPCIBot> Yippie, build fixed!
[21:09] <LPCIBot> Project db-devel build #798: FIXED in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/798/
[22:54] <wgrant> nigelb: There are no schema differences (they're the same DB), and I believe both are equally unstrict now.
[22:54] <nigelb> oh. WIN.
[22:57] <wgrant> lifeless: Bug #820796 didn't make it to coco, did it?
[22:57] <_mup_> Bug #820796: Lock before publishing <derivation> <qa-ok> <Launchpad itself:Fix Released by jtv> < https://launchpad.net/bugs/820796 >
[22:58] <lifeless> wgrant: blah
[22:58] <lifeless> deploy request is still up for it
[22:58] <wgrant> The logical response is to create a new Fix Release Requested status.'
[22:59] <lifeless> wgrant: !cite
[22:59] <wgrant> :(
[22:59] <lifeless> or we could have different code bases for different services
[23:00] <lifeless> I know thats heretical and all
[23:00] <wgrant> You are a horrible person.
[23:03] <lifeless> I'm shocked!
[23:03] <lifeless> here, let me delete more code from LP for us.
[23:03] <wgrant> You used ... though.
[23:04] <wgrant> That increases your evil rank significantly.
[23:04] <lifeless> where? oh in the bug ?
[23:05] <wgrant> from ...oops import
[23:06] <lifeless> oh yeah
[23:07] <lifeless> well, thats cause of absolute imports needing __future__
[23:07] <wgrant> Yeah.
[23:07] <wgrant> Not sure why implicit relative imports ever existed.
[23:08] <lifeless> python1
[23:13] <wgrant> Before my time.
[23:14] <lifeless> yeah
[23:14] <lifeless> python started without packages :)
[23:16] <sinzui> wallyworld, http://pastebin.ubuntu.com/663028/
[23:17] <wallyworld> sinzui: awesome. thank you!
[23:17] <sinzui> sorry about the surprise in there
[23:17] <wallyworld> yea, np :-(
[23:24] <lifeless> wgrant: I thought bug 824227 wasn't needed with the rendering improvements ?
[23:24] <_mup_> Bug #824227: Prevent changing bugtask pillars to/from a distribution with series tasks <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/824227 >
[23:29] <wgrant> lifeless: For project it's fine... for distributions it renders fine, but everything past that is more complicated.
[23:29] <wgrant> lifeless: If you approve a new distroseries nomination, all distribution/distributionsourcepackage tasks get a new task.
[23:30] <wgrant> If you then create a new distribution/distributionsourcepackage task, it also creates a task for all approved nominations.
[23:30] <wgrant> This gets amusing if you retarget to/from a DSP task, as you'll have partial sets of tasks which are unable to be fixed.
[23:30] <lifeless> those seem like bugs
[23:30] <wgrant> It requires entirely reworking how distroseries nominations work.
[23:31] <lifeless> which reminds me
[23:31] <lifeless> I was going to mail -users and u-devel about that
[23:31] <lifeless> I'd like to drop the table
[23:31] <wgrant> Oh?
[23:31] <lifeless> replace with a 'nominated' status
[23:32] <wgrant> Yeah, probably.
[23:32] <lifeless> use 'invalid' for rejected; the separate issue with making invalid be hidden would take care of hiding rejected ones
[23:32] <wgrant> Particularly since nominations are restricted now, they're pretty pointless.
[23:32] <lifeless> well, they have the same scope as tasks
[23:32] <lifeless> (once all the known bugs are fixed I mean)
[23:33] <lifeless> I also need to write up a perf tuesday this week; I'm thinking concurrency/taskswitching modelling.
[23:33] <wgrant> Oh?
[23:34] <lifeless> which line are you ohing?
[23:34] <wgrant> Where does concurrency/taskswitching come in?
[23:35] <lifeless> couple of places
[23:35] <lifeless> some other canonical projects are having significant perf issues, and running hundreds of concurrent queries on single pg instances
[23:36] <lifeless> not deliberately - starts with thousands of clients, mostly idle, and then stats kicks in when a spike comes through the system
[23:37] <wgrant> Erm.
[23:37] <wgrant> https://code.launchpad.net/~gary/launchpad/bug724025/+merge/71076
[23:38] <wgrant> Doesn't that make large bugs just about uneditable?
[23:38] <wgrant> Rather than simply non-AJAX.
[23:39] <lifeless> heh, yes. So perhaps not good enough


[12:50] <ubotu> New bug: #136669 in launchpad-answers "Not being able to link to a FAQ, not being able to find it" [Undecided,New]  https://launchpad.net/bugs/136669
[12:55] <blueyed> Hi. Does it make sense to link "Help translate" on https://launchpad.net/ubuntu/ to the feisty templates?
[12:55] <blueyed> Do they get merged for Gutsy?
[01:05] <_gpg_> Open launchpad source, the world will be better :)
[01:05] <_gpg_> good night
[02:05] <ubotu> New bug: #136679 in malone "Versioned package pages should display/link to changelog" [Undecided,New]  https://launchpad.net/bugs/136679
[02:24] <blueyed> Anyone around?
[03:35] <thumper> blueyed: not really, it's the weekend :)
[04:03] <blueyed> thumper: which is nice :)
[04:03] <blueyed> How can I get a "Feisty" "sub-bug" for https://bugs.launchpad.net/ubuntu/+source/postfix-policyd/+bug/132088 ?
[04:03] <ubotu> Launchpad bug 132088 in postfix-policyd "[Sync request]  Sync postfix-policyd (1.80-2.2) from Debian unstable (main)" [Wishlist,Fix released]
[04:04] <mpt> blueyed, you already have
[04:04] <blueyed> mpt: but it's "fixed released", isn't it?
[04:07] <blueyed> Should I file a new bug to get the security issue fixed for Feisty?
[04:08] <mpt> I don't know, sorry
[04:08] <mpt> Ask in the Ubuntu QA channel
[04:08] <blueyed> mpt: #ubuntu-bugs ?
[04:09] <mpt> yes
[04:10] <blueyed> But I believe there was a possibility to file a bug separately against a target/branch?!
[04:10] <blueyed> With phrases like "the bug is tracked in Gutsy", if there is a Feisty sub-bug, too.
[04:45] <ubotu> New bug: #136689 in malone "OOPS trying to view CVE-2007-3791" [Undecided,New]  https://launchpad.net/bugs/136689
[07:43] <Hobbsee> wow, bzr is *much* faster!
[07:57] <Hobbsee> uh oh, OOPS-610EZ2 when searching for bugs
[09:39] <tonyyarusso> Hobbsee: err, is PPA _still_ beta-testers-only?
[09:39] <tonyyarusso> When will that change?
[09:40] <Hobbsee> tonyyarusso: *shrug*
[09:40] <Hobbsee> tonyyarusso: "when it's ready"
[09:40] <Hobbsee> it's a sunday.
[09:40] <tonyyarusso> I was told it would be August 22nd.
[09:48] <Fujitsu> tonyyarusso: It was moving to production on the 22nd, but that ended up only happening a couple of days ago. It's still in beta, just on the main server.
[09:52] <tonyyarusso> Fujitsu: Not quite sure I understand that process, but okay.  Is there any way to anticipate when I might be able to use it without being a member of the beta testers group?
[09:53] <Fujitsu> Not sure. Probably another release or two.
[09:57] <tonyyarusso> How far apart are releases?
[09:58] <Hobbsee> a month
[09:58] <Hobbsee> damned timeouts
[09:59] <Hobbsee> OOPS-610EZ3
[10:00] <tonyyarusso> phooey - I heard the 22nd date and was planning on being able to use it then
[10:00] <Hobbsee> it'll all get deleted when it moves to production, btw
[10:00] <Fujitsu> Hobbsee: We moved to production 3 days ago...
[10:01] <Hobbsee> Fujitsu: i was meaning production as in "on the production server, and listed as production"
[10:02] <Fujitsu> Things won't be deleted, AFAIK... the only deletion was dogfood->production.
[10:03] <Hobbsee> oh, so it already has been.  right
[10:03] <Fujitsu> Yeah.
[10:44] <yml> hello launchpadders
[10:45] <yml> after sometimes on google I finally find out that the only way to delete a branch is to ask one of the lanchpad maintainer. Coul you please tell me is this statement is correct?
[10:49] <Hobbsee> good question.  no idea.  i thought you could do a bzr uncommit.  or mark the branch as abandoned, so it doesnt show up on the defaut list
[10:49] <Fujitsu> yml: I believe you'll have the ability to do it yourself after Launhcpad 1.1.9 is released.
[10:49] <Fujitsu> *Launchpad
[10:50] <yml> Fujitsu  do you know when that will be?
[10:51] <Fujitsu> 20070919, AFAICR.
[10:54] <yml> I would prefer not to wait that long because I have done some mistake when I have selected the file I want to push
[10:54] <Fujitsu> uncommit, then.
[10:56] <yml> ok I will try that path
[10:56] <yml> Is it possble to uncommit several revisions?
[10:57] <Fujitsu> I think you can repeatedly uncommit, yes.
[10:59] <yml> thank you
[11:05] <beuno> yml, or revert, add a -r to the revision you would like to revert
[11:05] <Fujitsu> beuno: That won't remove them from the history...
[11:05] <yml> hello beuno
[11:06] <beuno> Fujitsu, ah, that's right, it won't
[11:06] <beuno> hey yml :D
[11:06] <yml> Am I going to build a second monument for you?   :-)
[11:07] <beuno> yml, hahaha, I don't think so, Fujitsu is right on this one!
[11:08] <yml> Tha will let me more time to finish the first one. right under the eiffel tower  :cool:
[11:08] <beuno> yml, hahaah, it might be a bit much, but you did help squash a bug in bzr, the patch is already in  :D
[11:11] <beuno> anyway, I'm off to bed, glad to see you're active!   g'night
[11:17] <yml> goodnight
[11:38] <stgraber> any LP admin around ? I'd like the isotesting-tracker project to be renamed to qa-tracker as it'll be used to test packages and hardware as well
[12:00] <ubotu> New bug: #136732 in launchpad "Please show component on build details page" [Undecided,New]  https://launchpad.net/bugs/136732
[01:00] <ubotu> New bug: #136742 in launchpad "dogfood.launchpad.net should not be indexed by search engines" [Undecided,New]  https://launchpad.net/bugs/136742
[03:17] <zzorn> Are there plans for RSS feeds of changes to bugs and blueprints and questions etc. in launchpad?
[03:17] <zzorn> It would be neat to stream them directly to the project IRC channel through a RSS to IRC bot
[04:15] <ubotu> New bug: #136780 in launchpad "Rosetta still breaks many KDE plural forms" [Undecided,New]  https://launchpad.net/bugs/136780
[04:56] <ryanakca> how can I remove an upstream bug link?
[05:04] <Fujitsu> ryanakca: You pray that there will be a lot of HDD crashes and backup failures.
[05:05] <Hobbsee> heh
[05:08] <ryanakca> hehe
[09:05] <mayeco> where I can find a translations for launchpad?
[09:06] <mischa> there is none?
[09:23] <salty-horse> I'm trying to sort the list in https://blueprints.launchpad.net/ubuntu/+specs - it seems that after sorting, clicking "next" gives me the next page according to a different sorting - does sorting work only for the currently viewed portion of the table?
[10:05] <mdke> mischa: no, Launchpad is in English
[10:06] <mischa> yeah, that's what I meant
[10:12] <BrianB04> Afternoon all.
[10:14] <BrianB04> I'm having an odd issue with launchpad, and wondering if I am doing something wrong. I have a hosted repository there, and did a push to it via sftp. Now, if I do a bzr log sftp:// it shows the full log, but not only does Launchpad say it can't mirror it because it's not a branch, but I can't grab it using the http address as it gives the same error.
[10:27] <yml> hello launchpaders, I am trying to publish some change from a remote host to launchpad.net with bzr. The problem is that on that host I do not have access to /home/me so I had to put my ssh key directly on www/.ssh. Unfortunatly when I try to push I get the following error message:
[10:28] <yml> here it is the message : http://dpaste.com/18451/
[10:30] <yml> It looks like bzr is looking at the wrong place do you know if there is a way to explicitely specify the path.
[10:30] <yml> ?
[10:37] <beuno> yml, you should add a -i /path/to/key
[10:39] <yml> beuno where should I add this?
[10:39] <beuno> yml, when you do the sftp:// command
[10:40] <yml> on #bzr people are recommending to change the HOME
[10:40] <yml> this sound realy nice
[10:41] <yml> beuno: bzr -i /path/to/key push<EMAIL_ADDRESS>[10:41] <yml> is that what you  mean?
[10:43] <beuno> yml, I think it should be something more like: bzr push<EMAIL_ADDRESS>-i /path/to/key"
[10:45] <yml> ok I am going to try it right know . /path/to/key  should point to id_rsa, is that correct?
[10:45] <beuno> yml, yeap
[10:46] <yml> beuno I am going to shoot
[10:46] <beuno> yml, don't hurt anyone  ;)
[10:47] <yml> whatch your eyes  :-)
[10:47] <yml> all this for this  => bzr: ERROR: no such option: -i
[10:47] <yml> :(
[10:48] <beuno> yml, then I would go for the HOME= approach they recommended in #bzr
[10:49] <yml> thanks for your suggestion
[10:49] <yml> I am going to try the set HOME=bla/bla approach
[10:56] <thumper> BrianB04: when did you do the initial push?
[10:56] <thumper> BrianB04: and can you point me to your branch?
[10:57] <BrianB04> The initial push was probably 50-60 minutes. I just redid the push, and it's: http://bazaar.launchpad.net/~bbommarito/rbnews/trunk
[10:57] <yml> the HOME was already pointing to the right place
[10:58] <thumper> BrianB04: unfortunately there is a race condition on the initial push at the moment
[10:59] <thumper> BrianB04: there is a fix committed but won't be released until 1.1.9
[10:59] <BrianB04> And what does it mean to have a race condition?
[10:59] <thumper> BrianB04: the branch will be re-mirrored in around 5 hours
[10:59] <mpt> Goooooooooooooooooood morning Launchpadders!
[10:59] <BrianB04> Oh, alright.
[10:59] <thumper> BrianB04: it means that it tried to do something to your branch before your push had finished
[10:59] <thumper> BrianB04: so bzr said it wasn't a real branch (as it hadn't finished pushing)
[11:00] <thumper> morning mpt
[11:00] <BrianB04> But, the push completed correctly regardless?
[11:00] <thumper> if you could do a bzr log of the remote branch, then yes the push finished
[11:00] <thumper> and completed properly
[11:01] <thumper> sorry for the delay in you seeing your work
[11:02] <BrianB04> Oh, as long as it went up there alright, that's fine.
[11:02] <BrianB04> Is that a client glitch?
[11:02] <thumper> BrianB04: no, a server glitch
[11:02] <BrianB04> Oh, alright.
[11:03] <thumper> BrianB04: and should no longer be a problem once the fix is rolled out
[11:03] <BrianB04> When is 1.1.9 slated for rollout, or is that up in the air?
[11:04] <thumper> 19th of September
[11:05] <BrianB04> Now, after this pushes won't have a problem?
[11:05] <BrianB04> Like pushes to the same repo.
[11:05] <thumper> shouldn't be
[12:31] <ubotu> New bug: #136862 in malone "Navigation and tabs are broken on CVE page" [Undecided,New]  https://launchpad.net/bugs/136862
[12:31] <eric_haslehurst> hello, quick question about bug reporting on launchpad
[12:45] <ubotu> New bug: #136868 in malone "Navigation and tabs are broken on /bugs/cve page" [Undecided,New]  https://launchpad.net/bugs/136868


[00:58] <xnox> ev: CI Train Bot<EMAIL_ADDRESS>=)))) lol
[00:58] <xnox> no idea where to report this.
[00:58] <xnox> https://code.launchpad.net/~phablet-team/location-service/trunk
[00:59] <xnox> also no idea where to contribute to location service now.
[09:39] <mitya57> that<EMAIL_ADDRESS>shows up in many branches
[12:03] <mitya57> Mirv, hi, can you please subscribe ~ubuntu-qt-packagers to qtwebsockets and qtenginio (and add them to the package list in team description)?
[21:23] <Mirv> mitya57: done
[23:30] <rlaager> Any idea why the PPA build bots can't find libmessaging-menu-dev? https://launchpadlibrarian.net/194570994/buildlog_ubuntu-trusty-amd64.pidgin_1%3A2.10.11-1ubuntu0%2Bpidgin1.14.04_FAILEDTOBUILD.txt.gz
[23:36] <cjwatson> rlaager: That's not the error message you're getting.
[23:37] <rlaager> cjwatson: Hmm. I swear it was in one of my builds. But yeah, I see your point.
[23:37] <cjwatson> "missing" there just means "not installed yet".  The relevant bit is from "The following packages have unmet dependencies:" on, which indicates that there's some problem with installing libgadu-dev (possibly only in combination with other packages there).
[23:37] <cjwatson> Could be that for trusty you need libgadu-dev to be built against gnutls26 rather than gnutls28.
[23:37] <cjwatson> (I forget the details.  Maybe libgnutls-dev.)
[23:38] <cjwatson> There've been various gnutls26->gnutls28 transitions along the way and they need to be at least partially coordinated.
[23:44] <rlaager> Well, I'm only building on trusty because I couldn't get utopic to go. Utopic is not failing because of a gnutls issue. It gets to ./configure stage if I remove libmessaging-menu-dev from the Build-Depends.
[23:50] <rlaager> I think it's building now, so maybe I'm just confused. I should've kept the old buildlogs.
[23:59] <rlaager> cjwatson: I have an up-to-date Trusty system here. If I run the apt-get install line from the buildlog, it is perfectly willing to install libgnutls28-dev.


[06:49] <LocutusOfBorg> pitti, ping, please autopkgtest for ignition-transport/1.3.0-4: amd64: Regression ♻ , armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
[06:50] <LocutusOfBorg> ignition-transport has a autpkgtestuite that runs well with protobuf3, and this is the last protobuf blocker for migration
[06:50] <LocutusOfBorg> doko_, ^^^
[06:50] <LocutusOfBorg> for your happiness :)
[06:51] <LocutusOfBorg> protobuf should be run against ignition proposed, and vice-verssa
[06:51]  * LocutusOfBorg exit
[06:52] <pitti> Logan: done
[06:55] <pitti> Logan: sorry, tab failure
[07:01] <flocculant> pitti: you know anything about images and archive sync lock? or will that be someone else later in the day
[07:06] <pitti> flocculant: I'm afraid I don't
[07:07] <flocculant> okey doke :)
[07:36] <LocutusOfBorg> please accept mia from new, the rdeps are already in place thanks
[07:41] <LocutusOfBorg> thanks pitti and thanks irclogs service :)
[07:49] <LocutusOfBorg> mmm pitti I'm not sure it worked retrying against -proposed...
[07:56] <pitti> LocutusOfBorg: well, it's still in the queue
[07:56] <pitti> http://autopkgtest.ubuntu.com/running#queue-ubuntu-yakkety-amd64
[08:01] <LocutusOfBorg> oh thanks, I though the queue wasn't visible with the new service
[08:02] <LocutusOfBorg> lets see if protobuf can migrate today
[08:51] <apw> LocutusOfBorg, it was awol for a while (queues) and are now back with us
[09:02] -queuebot:#ubuntu-release- Unapproved: init-system-helpers (xenial-proposed/main) [1.29ubuntu2 => 1.29ubuntu3] (core)
[09:45] -queuebot:#ubuntu-release- Packageset: Added libmatemixer to ubuntu-mate in yakkety
[11:21] <LocutusOfBorg> cjwatson, FYI, when a build goes ENOSPACE seems to be stuck forever https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-3ubuntu1/+build/10712957
[11:23] <cjwatson> Yeah, known
[11:24] <cjwatson> Just cancel it, at some point I'll get round to working out how to test my fix for that in launchpad-buildd
[11:27] <LocutusOfBorg> thanks
[11:27] <LocutusOfBorg> if you need a tester, I'm here :)
[11:33] <cjwatson> LocutusOfBorg: No, I don't mean manual testing.
[11:33] <LocutusOfBorg> ok thanks
[11:33] <LocutusOfBorg> btw, many packages started failing for ENOMEM or some other similar issues
[11:34] <LocutusOfBorg> I usually "fix" them by reducing parallellism in ubuntu, or by retrying them e.g. https://launchpad.net/ubuntu/+source/mia/2.4.3-2ubuntu1
[11:34] <LocutusOfBorg> arm64 built after three retries
[11:34] <LocutusOfBorg> I don't want such delta from Debian, but seems the infra has some issues :(
[11:50] <flocculant> anyone about who's got the power to fix the iso's and tracker, nothing landed for anyone since the 10th :)
[11:50] <cjwatson> Depends.  What's broken?
[11:51] <flocculant> cjwatson: for those I've looked at > lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-archive-sync" Couldn't acquire archive sync lock!
[11:51] <cjwatson> Oh, reboot damage
[11:51] <flocculant> at least Xubuntu and Ubuntu are like that currently, gnome and lubuntu were yesterday
[11:51] <cjwatson> Should be fixed now
[11:52] <flocculant> cjwatson: thanks :) - Xubuntu is probably stuck re-building from Saturday (manually) I assume that'll sort itself when the next one builds?
[11:53] <cjwatson> Should do
[11:53] <flocculant> k - thanks again :)
[12:35] <LocutusOfBorg> bye protobuf! /cc doko_
[12:39] <LocutusOfBorg> still some rebuilds are missing, but fcl migrated
[13:24] <LocutusOfBorg> but should we really rebuild stuff such as dialer-app address-book-app camera-app to have protobuf3 migrate?
[13:54]  * LocutusOfBorg fixes libphonenumber, that seems a blocker for the transition to end
[14:08] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-367 [source] (xenial-proposed) [367.44-0ubuntu<IP_ADDRESS>]
[15:43] <sergiusens> infinity what are my options to get snapcraft-2.17 allowed into xenial-proposed?
[16:12] <apw> sergiusens, i see the yakkety version is failing its self-tests ?
[16:35] <sergiusens> apw yes, because snapd in yakkety is older than in xenial
[16:35] <apw> sergiusens, erp ... that isn't menat to happen
[16:36] <sergiusens> apw our xenial tests pass just fine fwiw https://github.com/snapcore/snapcraft/pull/787 (View Details there)
[16:36] <sergiusens> apw and right, that's why I ask, what are my options :-)
[16:37] <apw> sergiusens, i've asked (i hope) for a test of the yakkety one with the proposed snapd, which might clear that regression out
[16:37] <sergiusens> apw oh, is that possible from my end?
[16:38] <sergiusens> I "hope" it works, I am not sure, cjwatson do you know? ^
[16:39] <cjwatson> sergiusens: Well, apw said he's already triggered it.  It's not possible from your end
[16:40] <cjwatson> But archive admins can request that kind of thing
[16:40] <cjwatson> Assuming apw is talking about autopkgtests
[16:41] <sergiusens> cjwatson right, I was thinking of the key work you've done on snapd, I've been told that gpg transistions was one of the cultprits
[16:41] <sergiusens> cjwatson yeah, he is, well yeah, I assume as much
[16:41] <cjwatson> sergiusens: I don't see gpg failures in the log?
[16:42] <cjwatson> sergiusens: There was a lot of noise about the gpg transition, but it shouldn't actually break anything in snapd
[16:42] <apw> i am talking about adt indeed, though in the new world it is hard to tell if it has worked
[16:42] <apw> yep the failure i see in yakkety is using snap --force-something which is not present in the one in -release
[16:43] <sergiusens> good to know Colin (avoiding over pinging triggers now)
[16:43] <sergiusens> yeah, --force-dangerous was an unexpected surprise for us
[16:45] <ogra_> sergiusens, like ...everything ... related .... to ... snaps  ?
[16:47] <ogra_> (like having "grade: " added to snap.yaml in the ubuntu-core snap on release day ... and the store choking on it :P )
[16:48] <ogra_> the wonderful inter-team communication in snappy is resulting in a constant flow of suprises :)
[16:51] <cjwatson> Also everything is a huge rush and communication is the first thing to go
[16:52] <ogra_> yeah, sadly ... and it usually bites
[16:56] <sergiusens> ogra_ funny thing about grade was that it was a store folk contribution ;-)
[16:56] <ogra_> heh, yeah
[16:58] <ogra_> i still dont know what it is suppposed to do :)
[17:36] <sergiusens> cjwatson btw, why did it work at all given the dependency on snapd (>= 2.14.2~)? Maybe that is a pitti question
[17:37] <cjwatson> sergiusens: That dependency is only on integrationtest, and I think it's snapstest that failed
[17:38] <cjwatson> Er, integrationtests / snapstests respectively
[17:38] <sergiusens> yeah, I got it
[17:38] <sergiusens> thanks
[17:38] <cjwatson> snapstest has a tighter dep now
[17:38] <cjwatson> But maybe that wasn't in that release?
[17:38] <cjwatson> Haven't looked very closely
[17:53] <apw> sergiusens, ok there is now a yakkety ADT run which appears to have the yakkety-proposed version of snapd, but the tests appear to fail still
[17:53] <apw> Get:44 http://ftpmaster.internal/ubuntu yakkety-proposed/main amd64 snapd amd64 2.14.2+gitcc9d039-0ubuntu5 [7,665 kB]
[17:59] <sergiusens> apw where are those logs?
[18:01] <apw> sergiusens, http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64
[18:01] <apw> sergiusens, note the one at the top with twin triggers
[18:11] <sergiusens> apw great, snapd 2.14 in xenial has `--force-dangerous` while snapd in yakkety has just `--dangerous` :-(
[18:11]  * sergiusens blames ogra_
[18:12] <ogra_> haha+
[18:12] <ogra_> sergiusens, xenial-proposed should have --dangerous too
[18:12] <ogra_> yay for stable APIs
[18:13] <apw> ogra_, there is no snapd in xenial-proposed
[18:13] <ogra_> well, there will be :)
[18:13] <sergiusens> ogra_ 2.14 in xenial does NOT have `--dangerous`
[18:14] <ogra_> (i havent invented that option btw)
[18:14] <ogra_> complain to gustavo
[18:14] <sergiusens> ogra_ 2.14 is in xenial-updates!
[18:14] <ogra_> i know that trunk has --dangerous
[18:14] <ogra_> and that it is supposed to land ASAP
[18:15] <ogra_> (if it doesnt get renamed inbetween :P )
[18:16] <apw> ogra_, without backwards compatibility ?
[18:16] <apw> sergiusens, it sounds like we need to work out what is meant to be where here
[18:16] <ogra_> apw, really ask sommeone who is in charge ... i'm suffering the same way as you do
[18:17] <ogra_> afaik it is a gustavo thing
[18:17] <ogra_> though perhaps he is also just the messenger
[18:23] <sergiusens> apw I have no words
[18:23]  * sergiusens is jus upset
[18:23] <sergiusens> just*
[18:29] <apw> sergiusens, just trying to help
[18:34] <sergiusens> apw and I appreciate that :-) I am not upset at you, just the situtation really
[18:51] <sergiusens> apw if I upload tests that use --dangerous instead of --force-dangerous to yakkety will you trigger that magic to use snapd from proposed?
[18:55] <apw> sergiusens, can do
[19:47] -queuebot:#ubuntu-release- New binary: wireshark [ppc64el] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[19:49] -queuebot:#ubuntu-release- New binary: wireshark [s390x] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[19:51] -queuebot:#ubuntu-release- New binary: wireshark [i386] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[19:55] -queuebot:#ubuntu-release- New binary: wireshark [powerpc] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[19:56] -queuebot:#ubuntu-release- New binary: wireshark [amd64] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[20:10] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.7~bzr1256-0ubuntu1~16.04.1 => 0.7.7-31-g65ace7b-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:11] -queuebot:#ubuntu-release- New binary: wireshark [armhf] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[20:11] <elopio> sergiusens: ah, I remember why I wasn't in this channel. queuebot triggers a notification for me on every message.
[20:18] -queuebot:#ubuntu-release- New binary: clblas [amd64] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:18] -queuebot:#ubuntu-release- New binary: clblas [ppc64el] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:18] -queuebot:#ubuntu-release- New binary: clfft [i386] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:18] -queuebot:#ubuntu-release- New binary: clblas [i386] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:18] -queuebot:#ubuntu-release- New binary: clfft [ppc64el] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:18] -queuebot:#ubuntu-release- New binary: clfft [amd64] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:21] -queuebot:#ubuntu-release- New binary: clfft [armhf] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:21] -queuebot:#ubuntu-release- New binary: clfft [s390x] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:22] -queuebot:#ubuntu-release- New binary: clblas [arm64] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:22] -queuebot:#ubuntu-release- New binary: clfft [powerpc] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:22] -queuebot:#ubuntu-release- New binary: clblas [s390x] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:25] -queuebot:#ubuntu-release- New binary: clblas [powerpc] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:26] -queuebot:#ubuntu-release- New binary: wireshark [arm64] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
[20:30] -queuebot:#ubuntu-release- New binary: clblas [armhf] (yakkety-proposed/universe) [2.10-4] (no packageset)
[20:31] -queuebot:#ubuntu-release- New binary: clfft [arm64] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
[20:42] <sergiusens> apw if you don't mind, the latest snapcraft is already published in yakkety-proposed
[20:47] -queuebot:#ubuntu-release- New sync: libcmrt (yakkety-proposed/primary) [1.0.6+dfsg1-1]
[20:47] -queuebot:#ubuntu-release- New binary: winff [amd64] (yakkety-proposed/universe) [1.5.3-7ubuntu1] (no packageset)
[21:06] -queuebot:#ubuntu-release- Unapproved: rejected init-system-helpers [source] (xenial-proposed) [1.29ubuntu3]
[21:07] -queuebot:#ubuntu-release- Unapproved: init-system-helpers (xenial-proposed/main) [1.29ubuntu2 => 1.29ubuntu3] (core)
[22:36] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.4]


[01:17] <fredhami> I wondering does anyone know how to install and set web content setting on dansguardian?
[08:18] <Penguin> My ubuntu is effected with one of the virus. CalmAV doesn't do anything. Any other recommendations.
[10:26] <Bachstelze> Penguin: how do you know?


[00:13] <tormod> jcristau: yes that's me, but I don't know why you get the mail
[00:13] <tormod> maybe because I just uploaded without changing the changelog
[00:13] <tormod> I signed it myself though
[00:13] <jcristau> yeah well
[00:14] <tormod> it fails to build glxdri.c anyway :(
[00:14] <jcristau> it's not building against mesa 7.0.x
[00:14] <jcristau> so yeah, that won't work
[00:15] <tormod> I have mesa git in that ppa :)
[00:15] <tormod> I guess my mesa is too new
[00:16] <jcristau> thankfully it seems that's being sorted out upstream so we won't need mesa source to build the server
[00:16] <tormod> hey wait you say 1.4.1 does not build with 7.0.x, but that's what you have in unstable, right?
[00:17] <jcristau> i'm saying the buildds for your ppa are not using mesa 7.0.x
[00:18] <tormod> ah sorry, I misinterpreted "it's not building" into it will not build :)
[00:19] <tormod> hmm this is a nightmare. I guess the 1.4.99 would need all kind of deps
[00:21] <tormod> I guess there is no intermediate version that would build with git mesa and still not need all other things changed :(
[00:21] <jcristau> 1.4.99 needs rebuilt drivers, mainly
[00:22] <tormod> all drivers, video input everything I guess?
[00:22] <jcristau> yes
[00:27] <tormod> there are not so many input drivers... do you think they just need a rebuild, or updates?
[00:27] <tormod> well you have all that in experimental, right?
[00:29] <tormod> no there's no -mouse nor -kbd in experimental, so is 1.4.99 installable?
[00:31] <jcristau> it's not :)
[00:32] <jcristau> there are packages at http://pkg-xorg.alioth.debian.org/7.4/ though
[00:33] <tormod> aha. oh thanks! so that's the real experimental repo...
[00:36] <tormod> so I could grab all your sources there and stuff them into the ppa...
[00:36] <tormod> or can I just install them as-is together with git mesa?
[00:37] <tormod> does the Packages.gz file mean I can use it as a repo?
[00:40] <jcristau> yes, that should work
[00:40] <jcristau> the server is built with --disable-glx --disable-dri --disable-dri2, though, because i don't have a snapshot mesa :)
[00:42] <tormod> so the server doesn't have DRI? that would be pointless for me since my main motivation is the R500 3D in mesa git.
[00:43] <tormod> but if I rebuild the server in my ppa (with mesa snapshot) can I then just install the rest - I guess the video drivers must be rebuild but that's fine.
[00:45] <jcristau> that should be ok, yes. i'm uploading <IP_ADDRESS>2 now, so you can take that, change debian/rules to enable dri and glx, and build against your mesa snapshot
[00:45] <jcristau> then rebuild the ati driver against that, and profit
[00:47] <tormod> cool thanks! I will need to sleep on this, and see if I find time in the weekend. night!
[00:47] <jcristau> night
[11:08] <tseliot> tjaalton: if you're in the hotel I would like to have a word with you