[01:47] <wallyworld_> rockstar: ping?
[01:47] <rockstar> wallyworld_, hi.
[01:48] <wallyworld_> hey, with merge queues, i had started to do personproduct listings as a next step for person listings. is that something you still need me to do?
[01:48] <wallyworld_> and i guess product listings
[01:50] <wallyworld_> btw, i missed getting the person listings landed before the cut off. the branch passed ec2 ages ago but i was never lucky enough to find a non-testfix window to get the thing landed
[01:51] <rockstar> wallyworld_, I'm not sure why we'd need personproduct listings.
[01:51] <rockstar> Oh, product listings.
[01:51] <rockstar> Um, I'm not sure we do, but thumper might have an opinion.
[01:51] <rockstar> We have this idea that we need listings of everything, and I don't necessarily agree with that.
[01:52] <wallyworld_> ok. wrt not getting the branch landed - it was done in devel to pick up the db changes but after the rollout, thise db changes will be in prod
[01:52] <rockstar> wallyworld_, so, one thing that would be helpful with merge queues would be to take the JSON constraint out of the config.  You were right, we shouldn't force JSON on users.
[01:53] <wallyworld_> should i merge the stuff i did in db-devel into devel and land that after rollout? to get the person listing stuff in?
[01:53] <wallyworld_> ok. you want me to remove the json constraint?
[01:58] <rockstar> wallyworld_, yeah, if you could.
[01:59] <wallyworld_> ack
[01:59] <rockstar> wallyworld_, it's still (currently) only editable through the API anyway.
[01:59] <rockstar> wallyworld_, I think landing on devel once the devel rev has been tagged is okay, no need to merge (provided there are no conflicts)
[02:00] <wallyworld_> ok. i'll do that, so that you can pick up what i've done
[02:01] <wallyworld_> rockstar: is there a bug filed already for the json issue?
[02:02] <rockstar> wallyworld_, no, I don't think so.
[02:02] <wallyworld_> ok
[02:02] <rockstar> wallyworld_, the duplication of bug and kanban task prevented me from ever being organized enough.
[02:02] <wallyworld_> :-)
[02:03] <rockstar> wallyworld_, the only other backend thing that really needs to get done immediately is queuing a merge proposal, which I'm working on right now.
[02:03] <wallyworld_> ok
[02:03] <rockstar> Launchpad still has to be in a chroot though, because you can't develop ubuntuone and launchpad together on the same system.
[02:04] <wallyworld_> that's too bad
[02:05] <wgrant> buildout mess?
[02:05] <wgrant> Not fixable with virtualenv?
[02:06] <rockstar> wgrant, well, first, Launchpad eats postgres. All of it.
[02:06] <wgrant> It only does that once.
[02:06] <wgrant> After that it leaves it alone.
[02:13] <abentley> lifeless: Can you recommend a commandline testrunner compatible with testrepository?
[02:17] <spiv> abentley: I'd guess trial --reporter=subunit
[02:18] <abentley> spiv: I don't have a dependency on Twisted.  Doesn't trial depend on it?
[02:19] <spiv> yes
[02:20] <spiv> (but your tests don't have to depend on Twisted or Trial, if that makes a difference)
[02:22] <spiv> There are probably subunit plugins for other tools like nose, but that seems no different to me than using trial.
[02:22] <lifeless> abentley: python -m subunit.run
[02:23] <lifeless> abentley: or as spiv says trial --reporter=subunit
[02:23] <spiv> lifeless: oh, subunit has a runner?  Cute!
[02:23] <abentley> lifeless: cool.
[02:24] <lifeless> there is a nose subunit plugin floating around but its not really all that polished AIUI
[02:25] <elmo> rockstar: u1 have a very good system of spinning up a non-system postgres for their test suite, you should be able to mix and match
[02:27] <rockstar> elmo, yeah, and at some point, I'll sort that out.
[02:27] <rockstar> (Probably not on my first day with the u1 team)
[02:27] <lifeless> abentley: oh, and bzr selftest --subunit
[02:27] <lifeless> [02:27] <lifeless>     Hard / Soft  Page ID
[02:27] <lifeless>      180 /   53  Person:+commentedbugs
[02:27] <lifeless>       78 /  268  BugTask:+index
[02:27] <lifeless>       46 / 2908  Archive:+index
[02:27] <lifeless>       19 /  331  Distribution:+bugtarget-portlet-bugfilters-stats
[02:27] <lifeless>       14 /  312  Distribution:+bugs
[02:27] <lifeless>       10 /   12  Person:+bugs
[02:28] <lifeless>        8 /  100  MaloneApplication:+bugs
[02:28] <lifeless>        8 /    5  DistroSeries:+queue
[02:28] <lifeless>        5 /   15  DistroSeriesLanguage:+index
[02:28] <lifeless>        5 /    6  ProjectGroup:+milestones
[02:28] <abentley> lifeless: sure.  And the Launchpad test runner too.  But this is a separate project.
[02:28] <lifeless> sinzui: ^ Person:+commentedbugs has a fix in lp from stub
[02:28] <wgrant> Hmm... Archive:+index is still broken?
[02:28] <lifeless> abentley: righto, was just enumerating as things occured to me ;)
[02:28] <lifeless> wgrant: broken - not. Not all it can be - yes.
[02:30] <wgrant> lifeless: Hard timeouts == broken.
[02:31] <lifeless> wgrant: sure
[02:31] <lifeless> 46 is tolerable while we're recovering from 8.4
[02:31] <lifeless> wgrant: compared to hundreds per day
[02:31] <lifeless> wgrant: also note - no XMLRPC ones ;)
[02:31] <wgrant> Indeed.
[02:31] <wgrant> A bit disturbing that that was all just an overloaded appserver.
[02:33] <james_w> I'm a bit surprised that +branches pages don't show up on that list, it suggests to me that branch listings are rarely used, which is concerning in itself
[02:33] <wgrant> Is +branches linked from anywhere?
[02:33] <james_w> sorry, I was being overly precise
[02:33] <wgrant> +code-index?
[02:33] <james_w> whatever you get when you go to the "Code" tab
[02:34] <james_w> particularly person and person+pillar listings give me timeouts
[02:35]  * james_w causes a few OOPS for those pages to try and get lifeless to fix them :-)
[02:37] <lifeless> james_w: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-pageids.html
[02:43] <lifeless> thumper: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1781G129
[03:04] <abentley> lifeless: what would test_id_option be for subunit.run ?
[03:18] <lifeless> abentley: subunit.run doesn't support filtering at the moment
[03:18] <lifeless> cat .testr.conf
[03:18] <lifeless> [DEFAULT]
[03:18] <lifeless> test_command=PYTHONPATH=. python -m subunit.run foo.tests.test_suite
[03:18] <lifeless> abentley: ^ something like that is all you'd need
[03:19] <abentley> lifeless: but I wouldn't be able to use testr run --failing?
[03:19] <lifeless> it will work, but it would't filter
[03:20] <lifeless> I really should add filtering to subunit.run
[03:21] <abentley> lifeless: Yes, I think that would be very helpful.
[03:22] <spiv> Trial can filter :P
[03:23] <abentley> spiv: indeed, and I guess that makes it the best tool for the job, at the moment.
[03:24] <spiv> *nod*
[03:24] <abentley> spiv: err, how do I make it filter?
[03:25] <spiv> abentley: you can pass it test names
[03:25] <spiv> (or test class names, or test module names)
[03:26] <abentley> spiv: So what do I specify for test_id_option ?
[03:27] <spiv> e.g. if there's a test called package.tests.module.Class.method, trial will run it with any of "trial package", "trial package.tests", "trial.tests.module", "trial.tests.module.Class", "trial.tests.module.Class.method" (although obviously all but the latter are likely to find more tests than just that one)
[03:27] <spiv> heh, I typoed some of those badly
[03:28] <spiv> Basically "trial $python_dotted_name" will run all the tests contained in that dotted name
[03:28] <spiv> It'll probably fail to work nicely if you have test ids that don't correspond to python dotted names (e.g. if you have test multiplication via testscenarios or something)
[03:29] <abentley> spiv: I can't use something like that.  I need something that allows me to specify a file with test ids.
[03:29] <spiv> trial `cat $file` ?
[03:30] <abentley> spiv: testrepository does not appear to support that.
[03:30] <spiv> sh -c "trial `cat $file`" ?  ;)
[03:30] <spiv> Hmm, what a shame.
[03:30] <spiv> So close and yet so far!
[03:31] <abentley> spiv: testrepository expects that there is an option you can supply to the elsewhere-specified command that will make it read a file listing the test ids to run.
[03:31] <abentley> spiv: So I can't change the command, only append an argument.
[03:31] <spiv> abentley: sounds like a job for a shell script until one of these tools gets better :(
[03:32] <abentley> spiv: Yeah, seems like.
[06:44] <wgrant> spm: Around?
[06:45] <wgrant> I think germanium is pretty upset.
[06:46] <wgrant> No uploads accepted or packages published for nearly half an hour.
[07:03] <wgrant> losa ping: ^^
[07:32] <poolie> jml: up yet?
[08:04] <wgrant> Could someone prod ISD about the issue in #launchpad?
[08:06] <nigelb> SSO isn't LP per se is it?
[08:06] <wgrant> Exactly.
[08:06] <wgrant> Needs ISD.
[08:06] <wgrant> And they like to hide.
[08:08] <nigelb> wgrant: :/
[08:08] <nigelb> I remember seeing a sort of rant mail about it in launchpad-dev
[08:08] <wgrant> It's not an awfully wonderful situation.
[08:10] <poolie> i will try
[08:10] <wgrant> Thanks poolie.
[08:10] <poolie> what is the issue, in one sentence?
[08:10] <poolie> and how critical?
[08:10] <wgrant> Another email address that SSO won't send mail to.
[08:10] <wgrant> Two support cases have been opened about it.
[08:10] <wgrant> But both have been ignored.
[08:10] <poolie> :/
[08:10] <wgrant> ixokai in #launchpad
[08:11] <poolie> and the thing with germanium is separate?
[08:11] <wgrant> Yes.
[08:11] <wgrant> That doesn't need ISD, fortunately.
[08:11] <wgrant> It just needs a LOSA, hopefully.
[08:11] <poolie> ah, spm is away today
[08:12] <wgrant> Ahh.
[08:12] <mthaddon> o/
[08:13] <poolie> mthaddon, meet wgrant :-)
[08:13] <mthaddon> yeah, just catching up on backscroll in #launchpad
[08:14] <wgrant> mthaddon: The main issue is that germanium's publisher is somehow unhappy.
[08:15] <mthaddon> wgrant: any clues as to where to look?
[08:16] <wgrant> mthaddon: The logs for cron.publish-ppa might have something interesting.
[08:16] <wgrant> I don't yet know where they live.
[08:16] <mthaddon> yeah, looking at that now
[08:17] <mthaddon> can't see anything untoward in there
[08:17] <wgrant> Is there anything not untoward there?
[08:18] <mthaddon> looks like there was issues with claiming the lockfile for a while, but seemed to clear itself up a few mins ago
[08:19] <mthaddon> definitely seeing stuff processing now - you sure it's still an issue?
[08:19] <wgrant> Ah, so it is.
[08:19] <wgrant> It's happening now.
[08:19] <wgrant> Not quite done, but getting there.
[08:19] <wgrant> I wonder why it was broken.
[08:19] <mthaddon> k
[08:19] <wgrant> Thanks.
[08:40] <adeuring> good morning
[09:01] <wgrant> Morning bigjools.
[09:02] <bigjools> morning
[09:02] <wgrant> The PPA publisher was MIA for ~2 hours earlier, but mysteriously recovered once mthaddon started poking around.
[09:03] <bigjools> :/
[09:03] <bigjools> that happened the other day too
[09:03] <bigjools>  the librarian went awol
[09:03] <wgrant> Ah, interesting.
[09:04] <bigjools> no librarian = sad soyuz
[09:05] <stub> Are we running Librarian with tokens now?
[09:05] <bigjools> no idea
[09:05] <stub> Not sure what has changed with the Librarian apart from that the last few years. Or Apache stuff could be wonky I guess.
[09:05] <wgrant> We're not.
[09:05] <stub> Or Squid
[09:05] <wgrant> It's still webapp proxying.
[09:10] <mrevell> Bonjour
[09:34] <jml> poolie: am now
[09:36] <jml> File "/srv/launchpad.net/production/launchpad-rev-11926/lib/lp/registry/interfaces/person.py", line 172, in validate_person_common obj, getattr(obj, 'name', None))) PrivatePersonLinkageError: Cannot link person (name=canonical, visibility=PRIVATE) to (name=None)
[09:36] <jml> I get this when I try to make ~canonical a member of ~canonical-data-science.
[09:36] <jml> What's the deal?
[09:38] <stub> http://docs.fabfile.org/0.9.3/tutorial.html
[10:44] <bigjools> jml: did you have any comments about the buildd-manager changes?
[12:04] <jml> bigjools: none from my skim. glad that BuilderSlave has a multi-file fetch method.
[12:04]  * jml skims again
[12:05] <bigjools> jml: and shockingly easy to implement
[12:05] <jml> bigjools: yeah
[12:05] <jml> bigjools: I found that once I got the hang of Twisted, a lot of stuff like that just falls into place.
[12:05] <bigjools> jml: it's starting to click for me now
[12:06] <bigjools> I need to read up on all the protocol stuff though
[12:08] <jml> *nod*
[12:08] <jml> bigjools: I don't think you need files_downloaded  (in packagebuild.py)
[12:08] <jml> you could also do:
[12:08] <jml>   d = slave.getFiles(filenames_to_download)
[12:09] <jml>   d.addCallback(lambda x: self.storeBuildInfo(self, librarian, slave_status))
[12:09] <jml>   d.addCallback(build_info_stored)
[12:09] <jml>   return d
[12:09] <bigjools> possibly, I'll take a look.  I went through many iterations writing that code and I expect there's some cruft
[12:10] <jml> spot the lie: http://paste.ubuntu.com/532951/
[12:10] <bigjools> no lie :/
[12:10] <bigjools> well, maybe a half-truth
[12:11] <jml> when was the "next Paris summit"?
[12:11] <jml> :)
[12:11] <bigjools> yeah :)
[12:12]  * jml is looking forward to finishing the damn testtools-experiment branch.
[12:13] <bigjools> thank you again for your tutelage jml
[12:13] <jml> np.
[12:38] <jtv> danilos, henninge: I can't find any remaining call sites for migrate_kde_potemplates.py…  am I missing one?  Or can I just drop it?
[12:39] <henninge> jtv: no idea but that sounds dropable ;)
[12:41] <danilos> jtv, I think we had it killed already
[12:41] <jtv> danilos: yes, I think we did—and this is just a remaining piece.
[12:42] <jtv> Then there's message-sharing-populate.py.
[12:42] <danilos> jtv, do away with it then... that too
[12:42] <danilos> jtv, there was another one, remove-obsolete-translations I think
[12:42] <jtv> Oh!  And here I just updated that one.  :)
[12:43] <jtv> That's in something called KNOWN_BROKEN.
[12:44] <jml> I'm offline to get some more writing, diagramming and strategizing done. (so leet). Available on mobile, back in time for standup.
[13:01] <lifeless> gmb: hey
[13:01] <lifeless> gmb: so I wanted to chat with you & deryck about bug subscriptions
[13:02] <lifeless> gmb: we seem to be a little confused about them. Perhaps a LEP - not about the 'subscribe-to-search' bit - but about subscriptions /per se/ would clarify things?
[13:02] <lifeless> gmb: I mean, the 'we email dup subscribers' is deeply embedded in the code - we've unpleasant queries that exist just to answer that question.
[13:09] <gmb> lifeless: I think a LEP to clarify what we actually want to do with subscriptions themselves is a very good idea.
[13:47] <lifeless> danilos: hi
[13:47] <lifeless> danilos: I'm replying now, but would love more data about the use case!
[13:48] <danilos> lifeless, which one? (I am kinda mentioning both :)
[13:48] <lifeless> danilos: these guys recommend  model by 'what queries do you want to do'
[13:48] <lifeless> gimme 2 minutes, I'll get this reply to you.
[13:48] <danilos> lifeless, sure thing
[13:48] <danilos> lifeless, I have a vague feeling that it wouldn't really work for us at all, but it's worth asking the questions while you are there :)
[14:05] <lifeless> danilos: hi
[14:05] <lifeless> danilos: sorry about that, had to move to the training room :)
[14:05] <danilos> lifeless: training is good for your health :)
[14:06] <lifeless> :)
[14:27] <lifeless> danilos: anyhow, does my reply help? Should we discuss it some more?
[14:30] <danilos> lifeless: sorry, got distracted myself
[14:31] <bigjools> sinzui: hi - from your bug comment are you volunteering to fix bug 654476?
[14:33] <danilos> lifeless: paraphrasing for the second use case seems about right
[14:34] <sinzui> bigjools, I thought I had volunteered a few weeks ago
[14:35] <bigjools> sinzui: really?  I didn't know we'd narrowed it down to the issue I last mentioned on the bug
[14:36] <sinzui> bigjools, well, we scheduled the team membership policy fix for this release. I think add a check for PPA as well as other teams takes but a few minutes of work
[14:36] <bigjools> sinzui: indeed, ok thanks.  I'll re-assign the bug to your team.
[14:36] <sinzui> okay
[15:00] <lifeless> bigjools: I'm really happy that the builddmanager is coming along so nicely
[15:00] <bigjools> lifeless: you are by no means the only one!
[15:00] <bigjools> lifeless: I have one more scalability issue to talk to you about though
[15:02] <bigjools> when you've got some free time it would be good to chat in more deptch
[15:03] <lifeless> bigjools: shoot
[15:03] <bigjools> oh, free now?
[15:04] <lifeless> We're doing some simple stuff right now
[15:04] <lifeless> I can track IRC well enough to get bootstrapped on your issue
[15:04] <bigjools> lifeless: ok, so, the main issue is that every time we add a new builder, it makes the b-m issue "the" query is issued at regular intervals.  That does not scale.
[15:05] <bigjools> partly because the b-m is using the master store
[15:05] <lifeless> what does this query do (in english)
[15:05] <bigjools> figures out what to dispatch next
[15:06] <bigjools> *cough* a bit like a queueing system one might say *cough*
[15:06] <lifeless> do we model the queue directly, or do we model imputs and assemble the queue every time?
[15:07] <bigjools> there is no queue as such, it issues the query every 15 seconds (was 5 but I slowed it) to see if there's a candidate
[15:07] <bigjools> so more like the latter
[15:07] <lifeless> so long term I think we need to overhaul the entire queueing model for buildds
[15:07] <bigjools> the buildqueue used to model a "queue" but things got quite complicated in the last year ;)
[15:07] <lifeless> as I think I've said before
[15:08] <lifeless> to reduce starvation and so forth
[15:08] <bigjools> it's what everyone has said before I think :)
[15:08] <lifeless> in the short term
[15:08] <bigjools> it's not a short-term problem
[15:08] <bigjools> but when we get those 200 extra builders ...
[15:08] <lifeless> what about leaving the builder idle until the next 15 second poll
[15:08] <bigjools> I don't understand what you mean by that
[15:09] <lifeless> ok
[15:09] <lifeless> so lets say we had the 200 builders all attached
[15:09] <lifeless> and nothing to build
[15:09] <lifeless> they are presumably in some state where we can dispatch a build whenever we want
[15:09] <bigjools> yes
[15:10] <lifeless> and then if I upload a build, after processsing etc, your 15 second frequency queue sampling operation will find a build and dispatch it.
[15:10] <lifeless> bigjools: I'm assuming your query is something like this - psuedo code:
[15:10] <lifeless> needed_build_requests = len(builder for builder in builders if builder.is_idle)
[15:11] <lifeless> build_requests = issue_THE_query(needed_build_requests)
[15:11] <bigjools> no
[15:11] <lifeless> so that if there are no idle builders you don't issue the query at all
[15:11] <bigjools> there is a separate query for each builder
[15:11] <lifeless> bigjools: is it grouped by equivalent builders?
[15:11] <bigjools> no
[15:11] <lifeless> like, surely all virtualised i386 builders could be queried at aonce
[15:12] <bigjools> yes that would be eminently sensible
[15:12] <lifeless> anyhow, what I meant was
[15:12] <bigjools> but since forever it has always issued one query per builder
[15:12] <lifeless> put the builder in whatever state a builder waiting for a build is
[15:12] <jml> sinzui: hi
[15:12] <sinzui> hi jml
[15:12] <lifeless> and let the next lookup after 15 seconds sort it out
[15:12] <jml> sinzui: thanks for deduping my bug
[15:12] <jml> sinzui: I was wondering if you know of a work around?
[15:13] <lifeless> bigjools: but if you're going to do one-per-builder anyway...
[15:13] <sinzui> jml: maybe make canonical the owner of the team?
[15:13] <jml> sinzui: even though I can't add canonical to the team?
[15:13] <lifeless> bigjools: then I think making the modelling be able to answer the query instantly is probably the key thing.
[15:13] <bigjools> lifeless: so we could mitigate things a lot by remodelling to issue one query per (arch,virt)
[15:13] <bigjools> the query is already fairly quick to be fair
[15:14] <bigjools> it's just issued *a lot* :)
[15:14] <lifeless> bigjools: and add a limit for the number of available builders ?
[15:14] <jml> sinzui: "The person/team named 'canonical' is not a valid owner for Canonical Data Science CoP."
[15:14] <lifeless> bigjools: (such that you can short circuit when limit=0)
[15:14] <bigjools> yes, we'd need to track state carefully - but this is a major, major change to the b-m operation
[15:14] <lifeless> bigjools: the idea being that that would let you drop it down to checking every 1-2 seconds, for instance.
[15:15] <bigjools> lifeless: I think that this is a good direction to head.  It's an almost total rewrite of the b-m to do it though :(
[15:16] <sinzui> jml: yes that is correct, it will not be valid because it will cause a membership change. I think OEM/ISD has employed scripts to add members from one team to another
[15:17] <jml> sinzui: so, effectively there is no practical work-around to the problem beyond manually adding every member of ~canonical to the new team?
[15:17] <sinzui> jml: I really do not think there is an acceptable work around. This bug has been a super pain for 18 months
[15:17] <jml> or scriptedly
[15:17] <jml> sinzui: ok.
[15:18] <jml> sinzui: we are going to fix this with the new privacy model, right?
[15:19] <sinzui> Our pleas for help were largely ignored last year. So while I want to fix this. I cannot say it will make everyone happy.
[15:19] <sinzui> restating the problem as a membership policy issue, not visibility issue was a break-through for us two months ago
[15:20] <jml> sinzui: making everyone happy is not a requirement. covering this use case (make a team that's visible to members of another team) is.
[15:21] <jml> multi-tasking is melting my brain.
[15:21] <sinzui> The need for team hierarchy will be lessened when users and teams can be permitted to observe without being members. And explaining that members need to guard their messages on mailing lists and contact-this-team emails may suffice
[15:22] <sinzui> jml: This is a super hard problem. Lots of people have worked on this and it has befuddled everyone.
[15:22] <lifeless> bigjools: the long term one would be 'be able to answer a single nodes needs very very efficient'y
[15:23] <lifeless> bigjools: though I do think querying for a set of buuilders needs at once is sensible regardless.
[15:23] <sinzui> bac checked the TP leaks a few months ago and reported that they were quite bad.
[15:23] <bigjools> lifeless: totally.  In fact when we start using a real queueing solution we just have one queue per (arch,virt) and be done with it.
[15:24] <bigjools> lifeless: one of the complications right now is that stuff can be in the queue but we have rules that stop it getting dispatched
[15:24] <lifeless> oh?
[15:24] <lifeless> is there lots of that? or just a few jobs at a time?
[15:24] <bigjools> lifeless: there's two: 1., private sources need to be published, 2. we don't allow PPAs to issue too many concurrent builds
[15:25] <lifeless> jam: cassandra is basically bzr's store ;)
[15:27] <deryck> gmb, hi.  In the continuing saga of lazr-js upgrade, I have a clean test run!  hurrahs heard round the world!
[15:28] <gmb> deryck: Let joy be unconfined.
[15:29] <lifeless> gmb: so you'll do a LEP then?
[15:31] <jam> lifeless: well, pack files, but certainly different indexing at the top level, and it isn't multi-writer safe :)
[15:32] <gmb> lifeless: Yes. I'll start drafting one on Thursday (I'm away tomorrow)
[15:33] <lifeless> gmb: awesome, thanks!
[15:33] <lifeless> jam: the indexing is a little different, but not all that much ;)
[15:33] <jam> lifeless: the in-memory-only hash map is pretty different
[15:33] <lifeless> jam: its (rowkey, columnname) tuples for the indices AFAICT.
[16:49] <jcsackett> so, back from vacation and i'm trying to get the branch-lander working again per matsubara's email, but all i get when trying to authorize is a redirect circle between the login page and "confirm sharing these details" page. anyone run into this when the change landed last week?
[16:50] <matsubara> jcsackett, what's the URL for that page?
[16:52] <jcsackett> matsubara: login.launchpad.net
[16:52] <jcsackett> auto-taken there when i run land.
[16:53] <matsubara> jcsackett, sounds like you're having problem with sso authentication. do other LP pages work for you?
[16:56] <jcsackett> matsubura: i had thought they were, but you're right, i can't login period right now on this machine (oddly on another one i'm having no problems). i'll fidget with it a bit more.
[16:56] <jcsackett> thanks.
[17:06] <jcsackett> ah, botched my ssl configuration.
[17:10] <bigjools> jml: was there some sort of bug in Trial to do with leaving a dirty reactor sometimes?
[17:11] <jml> bigjools: it's not a bug in trial, it's a bug in the tests that cause it.
[17:11] <jml> (or the code that the tests call)
[17:11] <bigjools> jml: I know that, but I was wondering if there was something in Trial too.  I have a test that's randomly leaving a dirty reactor :/
[17:12] <bigjools> so far only happens on a full test run
[17:12] <jml> bigjools: it's almost certainly not a bug in trial.
[17:12] <bigjools> ok, good to confirm if nothing else
[17:12] <jml> bigjools: a very common class of test that leaves junk in the reactor does so intermittently
[17:12] <jml> bigjools: point me at the test and the error. I might be able to spot the problem.
[17:13] <bigjools> jml: test_binarypackagebuild/test_date_finished_set
[17:14] <jml> bigjools: in which branch?
[17:14] <bigjools> jml: the one you reviewed
[17:15] <bigjools> jml: lp:~julian-edwards/launchpad/async-file-uploads-bug-662631
[17:16] <jml> bigjools: ta
[17:16]  * bigjools wishes the dev wiki would redirect back to the page you were on after logging in
[17:17] <deryck> mars, ping.
[17:17] <mars> Hi deryck, what's up?
[17:17] <deryck> Hi mars.  I got my lazr-js upgrade branch passing ec2 now, but I still have horribly long run times....
[17:18] <deryck> mars, can I send you a log and some notes this morning and see if you have any idea what's going on?
[17:18] <mars> deryck, do you still see thread trash lying around?
[17:18] <jml> bigjools: which subclass? (specifically, what is self.build set to?)
[17:18] <deryck> mars, yes
[17:18] <bigjools> jml: TestHandleStatusForBinaryPackageBuild
[17:19] <bigjools> it seems to work for the recipe one
[17:19] <mars> deryck, I can look, certainly.  Fire the mail over.  I can reply with a HTTP on-the-wire technique I successfully piloted the last time we did this, it should sniff out the off-site accesses, if any are around.
[17:19] <jml> bigjools: ta
[17:19] <deryck> mars, ah, ok.  That would be useful to try.
[17:21] <jml> bigjools: what's the left-over?
[17:22] <bigjools> jml: http://pastebin.ubuntu.com/533122/
[17:22] <jml> wow. that's a lot.
[17:22] <bigjools> I would guess at a timeout
[17:23] <deryck> mars, thanks for the help!  Two emails fwd'ed to you.
[17:23] <bigjools> jml: it's probably the getFiles() - it sets up a lot of callbacks
[17:23] <jml> bigjools: self.buildqueue_record.builder.cleanSlave() returns a Deferred but the code doesn't handle it.
[17:23]  * bigjools looks
[17:23] <jml> bigjools: maybe not the bug here, but it's a start.
[17:24] <jml> bigjools: in _handleStatus_OK
[17:24] <bigjools> I didn't change any of that
[17:24] <bigjools> so it was there before
[17:25] <jml> bigjools: but you've moved more tests to run under trial with the stricter checking
[17:25] <bigjools> jml: and that same calls is repeated in a few places
[17:25] <bigjools> and that code is in production right now
[17:26] <jml> bigjools: perhaps it doesn't matter when the slave gets cleaned, as long as it's eventually
[17:26] <bigjools> I think it's luck that it's not breaking
[17:27] <bigjools> the polling loop will wait until it's clean
[17:27] <bigjools> this is probably the test problem though
[17:27] <jml> bigjools: I'm inclined to support the luck theory
[17:27] <bigjools> but why is it intermittent
[17:27] <jml> bigjools: it's the most obvious part.
[17:27] <jml> bigjools: because sometimes it finishes before the test does?
[17:28] <bigjools> ah
[17:28] <jml> and sometimes it finishes after
[17:28] <bigjools> mebbe
[17:28] <bigjools> fun
[17:28] <jml> yeah
[17:28] <jml> can't guarantee order of execution without deferreds.
[18:12] <deryck> mars, I *just* found more combo loading attempts going on.
[18:12] <jml> ugh.
[18:12] <mars> deryck, where?
[18:13] <mars> deryck, outside your search-and-replace sweep?
[18:13] <deryck> mars, vocab picker uses YUI().use
[18:13] <jml> 10 personal emails to answer. My friends, family and contributors to my free software projects must hate me :(
[18:13] <deryck> mars, yeah, missed it somehow.
[18:13] <deryck> no one hates jml :-)
[18:13] <jml> :)
[18:15] <deryck> mars, found a bunch with a more liberal grep now.  Oh, well.  Easy sed fix and maybe this will be finished.
[19:04] <jml> I think I might declare tomorrow to be LEP day
[19:05] <jml> in any case, g'night all
[19:05] <mars> good night jml
[20:13] <LPCIBot> Yippie, build fixed!
[20:13] <LPCIBot> Project devel build (225): FIXED in 4 hr 3 min: https://hudson.wedontsleep.org/job/devel/225/
[20:33] <poolie> hello all
[20:36] <wallyworld> thumper: standup now?
[20:37] <thumper> wallyworld: hi
[20:37]  * thumper plugs in
[20:49] <jcsackett> sinzui: did you ever find that branch regarding lpstats you talked about this morning?
[20:55] <maxb> matsubara-afk: Were you specifically wanting another lucid build of bzr-pqm, or did you just misclick whilst requesting the maverick one?
[20:57] <bryceh> Anyone recognize this error?  "Error: Couldn't find a distribution for 'zope.pagetemplate==3.5.0-p1'." http://pastebin.ubuntu.com/533225/
[20:57] <bryceh> just started seeing it yesterday after merging current db-devel.  not seeing it with the same branch on ec2 though
[20:58] <mwhudson> bryceh: is your download-cache up to date?
[20:59] <jcsackett> EdwinGrubbs: do you know anything about the lpstats thing sinzui mentioned this morning? bug 675596
[20:59] <_mup_> Bug #675596: lpstats queries need to be updated to use usage enums <Launchpad Registry:Triaged> <https://launchpad.net/bugs/675596>
[21:00] <bryceh> mwhudson, perhaps not (been away for past week)
[21:00] <sinzui> jcsackett, I am looking from the trunk. I do not know the project name :(
[21:01] <sinzui> I do not even know who owns it
[21:01] <jcsackett> sinzui: dig. so it's not just launchpadusagestatistics.py or something, is it?
[21:01] <bryceh> mwhudson, do I simply delete download-cache/* or is there a command to refresh it?
[21:01] <EdwinGrubbs> jcsackett: https://lpstats.canonical.com/graphs/
[21:01] <sinzui> jcsackett, You have never seen the source code
[21:02] <jcsackett> sinzui: that was what i had assumed (but now what i was hoping. :-P)
[21:03] <mwhudson> bryceh: bzr up download-cache
[21:04] <sinzui> jcsackett, https://code.launchpad.net/pgmetrics
[21:05] <sinzui> jcsackett, I think I am wrong
[21:07] <jcsackett> sinzui: yeah, this code doesn't look like it could produce that site.
[21:28] <wgrant> jcsackett, sinzui: Isn't it tuolumne?
[21:29] <sinzui> wgrant, yes, which is a brilliant name for code that can run on many machines
[21:30] <jcsackett> sinzui: what's the name mean?
[21:31] <lifeless> wgrant: pgmegrics is probably the glue for tuolumne for postgresql that we use.
[21:32] <lifeless> jcsackett: the source code is tuolumne
[21:32] <lifeless> but I don't remember offhand which  branch we use. flacoste will know.
[21:33] <jcsackett> lifeless: right, given sinzui's comment i was just curious if the name itself had some meaning. google only reveals a county with the same name.
[21:33] <mwhudson> jcsackett: that's where the name comes from
[21:33] <jcsackett> ah.
[21:33] <mwhudson> the project was created by mthaddon, who was living in california and visiting yosemite at the time
[21:33] <flacoste> yeah, it's a climber ref
[21:34] <jcsackett> dig.
[21:34] <flacoste> jcsackett: you want to read https://wiki.canonical.com/Launchpad/PolicyandProcess/AddLPStatsGraph
[21:35] <jcsackett> flacoste: already reading. :-P
[21:35] <flacoste> all you need sohuld be there
[21:35] <flacoste> if anything is missing or unclear, please help by asking questions and feeding it back into that page
[21:35] <jcsackett> not quite all--i'm making sure graphs don't break as we migrate the official_* booleans to the *_usage enums.
[21:35] <jcsackett> rather than adding a graph.
[21:35] <flacoste> jcsackett: right, but it's the same process
[21:36]  * jcsackett nods.
[21:36] <flacoste> and you won't need to add a graph
[21:36] <flacoste> only update the metrics
[21:37] <jcsackett> flacoste: yup. sinzui has shown me a branch dealing with similar reqs.
[21:37] <jcsackett> or a revision, rather.
[21:38] <wgrant> gmb: You're not still around, are you?
[21:39] <gary_poster> Hey thumper .  crowberry doesn't need access to memcache, right?
[21:40] <thumper> gary_poster: what are we putting in memcache?
[21:41] <gary_poster> thumper: AFAIK it's just used for template snippets right now.
[21:41] <gary_poster> but I'm asking to make sure :-)
[21:42] <gary_poster> memcache is blocked from crowberry now, thumper, so this is a "is the status quo OK" question
[21:42] <gary_poster> (not asking about a change)
[21:43] <thumper> I think that's fine
[21:43] <gary_poster> ok thanks thumper
[21:44] <lifeless> whats on crowberry that is *trying* ?
[21:47] <wgrant> Could someone EC2 https://code.launchpad.net/~wgrant/launchpad/bug-654372-optimise-domination/+merge/40854?
[21:56] <lifeless> flacoste: hi
[21:56] <flacoste> hi lifeless
[21:56] <lifeless> flacoste: rt 42199 and 40480 should have reversed priorities
[21:56] <lifeless> flacoste: so that we have more insurance and can switch around without downtime.
[21:57] <lifeless> oh, bah mea culpa.
[21:57] <lifeless> flacoste: ignore me, tis fine.
[21:57] <flacoste> ok
[21:57] <flacoste> i will
[21:57] <lifeless> I misread as production ;)
[22:58] <lifeless> night
[23:02] <thumper> wallyworld: can you check the code team oopses for yesterday, the TypeError ones for +check-links
[23:02] <thumper> wallyworld: has this been fixed?
[23:02] <wallyworld> thumper: will check
[23:06] <wallyworld> thumper: there's a few from 15th but trying those urls right now results in no oops
[23:07] <wallyworld> thumper: the stack trace in the oops shows the branch which fixes it wasn't deployed yet
[23:07] <wallyworld> on the 15th
[23:37] <thumper> wallyworld: I'd like you to take a look at this: https://bugs.edge.launchpad.net/launchpad-code/+bug/675517 once you've finished the current page you're looking at
[23:37] <_mup_> Bug #675517: Certain error tracebacks can leak through codehosting <oops> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/675517>
[23:38] <wallyworld> thumper: ok


[13:36] <hazmat> do we release updated charms for both trusty and precise?
[13:36] <hazmat> re gui
[13:36] <rick_h_> hazmat: we have been yes
[13:36] <hazmat> cool
[13:37] <rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/100 1.2.2 GUI
[14:49] <hatch> man the gui is stable
[14:49] <hatch> I haven't come across a single unknown bug
[14:50] <hatch> (unknown being the key word there)
[14:50] <hatch> ;)
[14:51] <hatch> although Makyo I still from time-to-time get the services bouncing all over on deploy - it appears to be related to dragging at a specific point during the deploy cycle but I can't reproduce it reliably
[14:52] <rick_h_> kadams54: hatch how we doing for releasing today? I looked at kadam's branch but the card is in coding still?
[14:52] <kadams54> I'm prepping an update on that PR that will take it out of WIP status.
[14:53] <rick_h_> kadams54: ok cool
[14:58] <hatch> yeah we should probably do a follow-up bug fix release after this one for some of those known bugs
[16:08] <kadams54> hatch, rick_h_: https://github.com/juju/juju-gui/pull/631
[16:08] <kadams54> *finally*
[16:11] <rick_h_> kadams54: ty looking in a min
[16:11] <hatch> kadams54: on it
[16:24] <hatch> kadams54: ok reviews done- mind taking a look
[16:27] <kadams54> Yeah, I looked through them. I've got a 12:30 lunch appointment here, but I'll reply in the PR.
[16:33] <rick_h_> kadams54: review done
[16:33] <rick_h_> hatch: you've got the steps then to integrate enough to QA?
[16:34] <hatch> rick_h_: yeah I'll take this work to make sure my branch works as expected - I've made a bunch of comments but it should work as expected as is then we can revisit these changes later if needed
[16:35] <rick_h_> hatch: ok cool
[16:35] <rick_h_> hatch: let me know if you need a hand
[16:37] <hatch> I just need to find all the rules again
[16:37] <hatch> heh the interactions are complex lol
[16:38] <hatch> I replied to the angular thread :) Wrote the email at like 2am forgot to send it
[16:38] <rick_h_> hatch: :)
[16:39] <rick_h_> hatch: don't see it yet booo
[16:40] <hatch> it's long.....real long
[16:40] <hatch> might take time go through the internets
[16:40] <rick_h_> lol
[16:40] <rick_h_> ouch
[16:40] <rick_h_> I'll read it over lunch then :)
[16:41] <hatch> well how do you systematically destroy angular in a short email....like c'mon
[16:41] <hatch> :P
[16:42] <hatch> holy crap it works
[16:43] <hatch> well the mv is broken....but holy crap the canvas stuff works
[16:43]  * hatch needs a moment
[16:47] <hatch> ok yeah the qa is not good wrt the mv stuff and one bug on the canvas stuff which might be related to the data being sent from this branch
[16:55] <hatch> ok I found one pre-existing bug
[16:55] <hatch> I'll hop on that
[17:00] <rick_h_> hatch: cool ty
[17:00] <rick_h_> and yay
[17:01] <hatch> I've added the qa issues to the PR
[17:01] <hatch> and created a card for the bug I'm on
[17:28] <hatch> kadams54: thanks for the replies - I replied to the one about defaults
[18:21] <hatch> lunching
[18:37] <kadams54> hatch: ping me when you're back, I have a question.
[18:44] <kadams54> guihelp: anyone know what's going on here? I set an attribute on a ModelList, but when I ask for the same attribute back, it's not set as expected. http://pastie.org/private/2npre7yetltxg4hvrtalw
[18:44] <rick_h_> kadams54: looking
[18:49] <rick_h_> kadams54: I'm not sure that's supposed to work tbh
[18:49] <rick_h_> kadams54: on using set and it reaching into the models in the list?
[18:49] <rick_h_> kadams54: I mean a model can have attrs so not sure how that would work
[18:50] <kadams54> Yeah… that's what hatch seemed to suggest in the PR.
[18:51] <kadams54> modelList.set('foo', 'bar') would be equivalent to looping through and doing model.set('foo', 'bar')
[18:52] <rick_h_> kadams54: yea, but looking at http://yuilibrary.com/yui/docs/api/classes/ModelList.html#method_set I don't see it. I'd punt on that
[18:52] <rick_h_> kadams54: and see if you can figure out the QA issue?
[18:52] <kadams54> Yeah, getting to that.
[18:53] <rick_h_> kadams54: and then when hatch gets back I'd like you guys to pair over a hangout and get the bits pulled in together. I'd like to try to have a qa'able branch I can qa at the coffee shop tonioght so tomorrow can be release
[19:04] <tvansteenburgh> rick_h_: is this is the canonical precise juju-gui -> ~juju-gui-charmers/charms/precise/juju-gui/trunk ?
[19:04] <tvansteenburgh> that's the only one i can find
[19:09] <rick_h_> tvansteenburgh: yes
[19:09] <tvansteenburgh> ty
[19:10] <rick_h_> tvansteenburgh: there's a ~juju-gui which is out dev one
[19:11] <rick_h_> doh, which has this change from adam but we hadn't done a release yet so you didn't see it
[19:11] <rick_h_> tvansteenburgh: so never mind
[19:11] <rick_h_> http://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/revision/209 tvansteenburgh
[19:12] <rick_h_> tvansteenburgh: we're doing a release this week with the new feature and so hadn't put out the updates from adam, sorry that caused you to dupe them
[19:12] <tvansteenburgh> actually that one is not quite right
[19:12] <tvansteenburgh> so i'll send you a merge anyway
[19:12] <rick_h_> oh, well then carry on :)
[19:12] <tvansteenburgh> :D
[19:21] <hatch> kadams54: yo
[19:22] <kadams54> hatch: Hey, digging into your QA issues right now.
[19:23] <kadams54> Pushed changes that addressed all your review feedback if you want to look those over.
[19:23] <hatch> sure will do
[19:30] <hatch> kadams54: looks good - was my memory wrong wrt the .set() on a ML?
[19:31] <rick_h_> hatch: looks like it just sets attrs on the ML object
[19:31] <rick_h_> hatch: checked out the api but didn't see anything that would do it
[19:31] <hatch> hmm darn - wonder what I'm thinking of then
[19:32] <hatch> sure seems like something like that should be possible
[19:32] <rick_h_> you can .each and .some of a list
[19:32] <rick_h_> but I think you're thinking nodelist vs modellist
[19:32] <hatch> ahhhhh that's it
[19:32] <hatch> yes sorry my bad
[19:45] <hatch> kadams54: so did you want to pair on that qa debugging?
[19:55] <rick_h_> kadams54: hatch you guys settled?
[19:57] <hatch> I'm just hammering out a test for my branch - haven't heard back from kadams54 yet
[19:57] <hatch> should have this up shortly
[19:58] <rick_h_> kadams54: around?
[20:02] <kadams54> rick_h_, hatch: yup, sorry.
[20:03] <rick_h_> kadams54: cool, please get together with hatch to sync up your branches/qa issues and get things pulled together hopefully by EOD if at all possible
[20:04] <kadams54> hatch: we have two QA issues. I'm looking at the first. You want to dig into the second?
[20:05] <hatch> jujugui looking for a review on a small bug fix https://github.com/juju/juju-gui/pull/632
[20:05] <hatch> kadams54: can do - if you don't think they are related?
[20:06] <kadams54> No, but don't quote me on that.
[20:06] <hatch> heh ok I'll take a look with your most recent updates
[20:06] <rick_h_> hatch: kadams54 I'd like you guys to work together please. get a hangout together, and keep in sync so if we need to hatch can carry to his EOD when kadams54 EOD's and such
[20:06] <hatch> ok can do
[20:08] <kadams54> hatch: standup hangout?
[20:08] <hatch> rick_h_: #632 is pretty small and easy to qa if you have time
[20:08] <hatch> kadams54: yup will join shortly
[20:08] <rick_h_> hatch: lookihng
[20:08] <rick_h_> looking
[21:12] <rick_h_> hatch: kadams54 going afk until coffee shop time tonight. Please make sure to drop me a note on where we're at for tomorrow at EOD please
[21:13] <hatch> rick_h_: hop in standup?
[21:14] <hatch> ok hopped out
[21:29] <hatch> jujugui anyone around able to do another easy review? https://github.com/juju/juju-gui/pull/632
[21:30] <Makyo> hatch, on it
[21:31] <Makyo> :+1:
[21:32] <hatch> thanks
[22:46] <rick_h_> hatch: what's up?
[22:46] <hatch> :/
[22:46] <hatch> so many rules!
[22:46] <hatch> I'm trying to fix one last rule
[22:47] <rick_h_> hatch: k
[22:47] <hatch> the mv and service view have such different rules that post release this should be refactored a bit
[22:47] <hatch> I didn't realize how different they are
[22:58] <rick_h_> hatch: did you see the highlight icons from luca as well?
[22:59] <hatch> I didn't
[22:59] <hatch> atm I'm just focused on getting this case fixed
[22:59] <hatch> which is going to require some model updates
[23:01] <rick_h_> hatch: :/ what's so different on it?
[23:01] <hatch> ermahgerd - well in the service view 'related' services matter
[23:01] <rick_h_> hatch: I thought that's what this sync'ing of the state to the service/unit models was for. So that we could show/hide/highlight properly with the model as the single source of truth?
[23:01] <hatch> and we update the service model and unit model accordingly
[23:01] <hatch> unfortunately the mv doesn't care if anything is related
[23:02] <rick_h_> right, but the unit models don't need updating on the service view details
[23:02] <hatch> but the container column AND service view do
[23:02] <hatch> er not service view
[23:02] <hatch> sorry
[23:02] <hatch> just the container column
[23:02] <hatch> but the machine column needs the machine models to be set separately
[23:02] <rick_h_> ok, but that can just be rendering differences based on the same model dta?
[23:02] <rick_h_> ugh, we can't just handle machine show/hide at render time?
[23:03] <rick_h_> if the render() call finds that none of the units are visible, it just never draws?
[23:03] <hatch> problem is that the units use the 'related services' code to mark hidden/visible because that's what it needs for the container column
[23:04] <hatch> so we can't rely on that for the machine column
[23:04] <hatch> so the machines need their own flag
[23:05] <hatch> rick_h_: so I'm going to take a little break now, play some Destiny :) then come back later with a fresh head and get this done
[23:05] <rick_h_> hatch: ok, let me know if I can help
[23:09] <rick_h_> hatch: just thinking about that, it sounds like what we need is a triple state there. I've been hidden, I'm related to a hidden, and then false
[23:09] <rick_h_> hatch: so you can just check that field for more than a true/false and be ok
[23:09] <rick_h_> hatch: vs adding new model stuff to machines
[23:10] <rick_h_> in a way it's 6 of one, half dozen of another, but wonder if it's a bit simpler that the 'state' is in a single bit of data vs another one


[01:48] <Keybuk> today I feel like I have a handle of the event expression atomicity issues
[02:45] <Keybuk> Interesting question
[02:45] <Keybuk> when upstart kills a process, should it just kill that process, or should it kill everything in that process's group?
[02:53] <shawarma> Keybuk: Good question. What about the session?
[02:54] <Keybuk> the session?
[02:54] <shawarma> Yup.
[02:54] <shawarma> getsid()
[02:55] <Keybuk> you can't kill a session
[02:55] <shawarma> If you SIGHUP the session leader, it trickles down to the other processes in the session.
[02:56] <Keybuk> actually, it's more complicated than that
[02:56] <shawarma> If you SIGTERM the session leader, it doesn't kill the rest of the processes, afair.
[02:56] <Keybuk> you don't mean session leader
[02:56] <Keybuk> you mean process group leader
[02:56] <shawarma> No, I'm quite sure I mean session leader.
[02:57] <Keybuk> and the SIGHUP thing only applies to the foreground process group with a controlling terminal
[02:57] <Keybuk> iirc.
[02:57] <shawarma> That's the session leader.
[02:57] <shawarma> Gah.. getsid has no man page. Gimme a sec.
[02:57] <Keybuk> the session leader is the first process in the session?
[02:57] <Keybuk> the one where the sid == pid
[02:57] <shawarma> Right.
[02:57] <Keybuk> setsid() gives you a process where pid == pgrp == sid
[02:58] <shawarma> Right.
[02:58] <Keybuk> ie. it's the session leader and a process group leader
[02:58] <Keybuk> process groups can exist without their leader
[02:59] <Keybuk> sessions contain one or more process groups
[03:00] <Keybuk> sessions can have a controlling terminal
[03:00] <shawarma> Right.
[03:01] <Keybuk> one of the process groups can be the foreground process group
[03:01] <Keybuk> all of the others are the background process groups
[03:01] <Keybuk> Control-C on the terminal will send SIGINT to all processes in the session's foreground process group
[03:01] <Keybuk> if the terminal is hung-up, SIGHUP is sent only to the session leader
[03:02] <shawarma> What causes the other processes in the session to die, then?
[03:03] <Keybuk> Control-Z sends SIGTSTP to all processes in the foreground process gruop
[03:03] <Keybuk> Control-\ sends SIGQUIT to all processes in the foreground process group
[03:04] <Keybuk> reading from standard input while you are not in the foreground process group will send SIGTTIN back to you
[03:04] <shawarma> ABout SIGHUP: "This signal is also generated if the session leader terminates. In this case the signal is sent to each process in the foreground process group". Hmm.. Is it the kernel doing that?
[03:04] <Keybuk> writing to a terminal while you are not in the foreground process group may either succeed or send SIGTTOU back to you
[03:05] <shawarma> (from APUE)
[03:05] <Keybuk> shawarma: dunno, not got that far yet (I'm in APUE too :p)
[03:05] <shawarma> *G*
[03:05] <shawarma> I cheated and skipped ahead. :)
[03:07] <Keybuk> children in a process group that are stopped are sent SIGHUP followed by SIGCONT if the process group they are in becomes orphaned
[03:07] <Keybuk> (ie. the parents of all processes in that process group are in different sessions)
[03:08] <Keybuk> SIGHUP is only sent if there is a controlling terminal
[03:09] <Keybuk> if the session leader terminates, SIGHUP is sent to the foreground process group (apparently)
[03:12] <shawarma> By whom?
[03:12] <shawarma> Must be the kernel..
[03:17] <Keybuk> -- entering new session
[03:17] <Keybuk> pid: 9171
[03:17] <Keybuk> pgrp: 9171
[03:17] <Keybuk> sid: 9171
[03:17] <Keybuk> -- execing shell script
[03:17] <Keybuk> --shell
[03:17] <Keybuk> pid: 9172
[03:17] <Keybuk> pgrp: 9171
[03:17] <Keybuk> sid: 9171
[03:17] <Keybuk> --end shell
[03:17] <Keybuk> ok
[03:17] <Keybuk> so that's a session leader that execs a shell, which runs a single command
[03:17] <Keybuk> the shell is 9171
[03:17] <Keybuk> the process group and session of the simple command is also 9171
[03:17] <Keybuk> but the pid of the thing run in it is 9172
[03:17] <Keybuk> which makes sense
[03:24] <Keybuk> doesn't get SIGHUP here
[03:26] <Keybuk> aha
[03:26] <Keybuk> does if it has a terminal
[03:26] <Keybuk> -- entering new session
[03:26] <Keybuk> -- taking control of terminal
[03:26] <Keybuk> pid: 9618
[03:26] <Keybuk> pgrp: 9618
[03:26] <Keybuk> sid: 9618
[03:26] <Keybuk> -- execing shell script
[03:26] <Keybuk> -- shell 9618
[03:26] <Keybuk> pid: 9619
[03:27] <Keybuk> ppid: 9618
[03:27] <Keybuk> pgrp: 9618
[03:27] <Keybuk> sid: 9618
[03:27] <Keybuk> -- end shell
[03:27] <Keybuk> 9619 got SIGHUP
[03:27] <Keybuk> -- exit
[03:27] <Keybuk> right
[03:27] <Keybuk> SIGHUP comes from the terminal control driver only
[03:36] <Keybuk> that makes sense
[03:36] <Keybuk> so the question is still valid
[03:37] <shawarma> I forgot the question :)
[03:37] <Keybuk> when upstart wants to kill a job, should it just send TERM to dash (which won't kill anything else since there's no terminal) or to the entire process group?
[03:38] <Keybuk> and how will this affect services with multiple processes, since they'll all get TERM, rather than just the top one?
[03:38] <shawarma> How does that work, actually? You iterate throguh the process space looking for things with the same pgid?
[03:38] <Keybuk> killpg :p
[03:38] <Keybuk> thom: how would apache cope with that?
[03:40] <shawarma> I think each request each child is handling would be dropped and the top process would clean up the mess..
[03:44] <Keybuk> yeah
[03:44] <Keybuk> I think killpg is reasonable here
[03:45] <Keybuk> (it's also what sysvinit does ... I never noticed that)
[03:47] <Keybuk> *giggle*
[03:47] <Keybuk> well, that change royally buggered up my test suite
[06:01] <Keybuk> yay
[06:01] <Keybuk> job->cause is gone
[06:02] <AlexExtreme> whoo
[06:03] <Keybuk> though I now have a stack of issues with the new code ;o)
[06:03] <Keybuk> in particular
[06:03] <Keybuk>   start on foo and bar
[06:03] <Keybuk>   stop on frodo and bilbo
[06:03] <Keybuk> ...
[06:03] <Keybuk> if you stop that, and then foo happens quickly afterwards, it will start again
[06:03] <Keybuk> because the event tree still has the true values, and it's still enough to touch it
[06:03] <Keybuk> but if it happens after it has properly stopped, you need both foo and bar to happen again
[06:03] <Keybuk> (likewise for the stop on bit)
[06:04] <Keybuk> the way to solve that, I think, is to reference an "Event Expression" not just the root "Event Operator"
[06:04] <Keybuk> Event Expression would be the root Event Operator, and also an Event State
[06:05] <Keybuk> if the root operator becomes TRUE, the matching events from the tree are copied into the Event State, and then the operator tree is reset
[06:05] <Keybuk> the job would respond to the expression, so it retains the state while requiring the match to happen all over again


[03:35] <cjohnston> is "Error: unable to find the ip address of the LXC container" the same as bug #1019181
[03:35] <_mup_> Bug #1019181: lpsetup expects lp-lxc-ip to be in /usr/bin; setup.py install it in /usr/local/bin <lpsetup:In Progress by gmb> < https://launchpad.net/bugs/1019181 >
[04:07] <rick_h_> cjohnston: not sure. what are you doing/running to get the error about the ip address?
[04:41] <cjohnston> rick_h_: I installed lpsetup, then the very first commandthat you run
[04:41] <cjohnston> I'm onmy phone now so I don't engender what it was
[11:23] <cjohnston> I an lp-setup install-lxc
[11:23] <cjohnston> s/an/ran
[23:33] <StevenK> Hmmmm, \d output lies.
[23:33] <StevenK> psycopg2.ProgrammingError: syntax error at or near "::"
[23:33] <StevenK> LINE 10:     USING gin (searchable_names::tsvector)
[23:36] <wgrant> Indeed
[23:36] <wgrant> You need an extra set of parens
[23:36] <wgrant> IIRC
[23:37] <StevenK> Not to mention a ';'
[23:38] <StevenK> wgrant: http://pastebin.ubuntu.com/1444243/
[23:38] <wgrant> wtf comments
[23:39] <StevenK> wgrant: They will die, they're still hanging around in case I need them
[23:39] <wgrant> Ah
[23:39] <wgrant> I thought their purpose was to make the diff completely unreadable, particularly when there's a commented line in the middle of a statement :)
[23:40] <StevenK> Not exactly, no ...
[23:40] <wgrant> But that looks reasonable otherwise
[23:40] <StevenK> wgrant: I was going to check that qas/staging/prod are done and then propose my garbo killing branch
[23:40] <StevenK> Then I can put up this one
[23:55] <StevenK> sqlvalues of u"'" doesn't escape :_(
[23:57] <wgrant> Doesn't escape hwhat?
[23:58] <StevenK> ProgrammingError: syntax error in tsquery: "'"
[23:58] <StevenK> LINE 1: ...chive IN (16) AND ((searchable_names::tsvector @@ '''')) ORD...
[23:58] <wgrant> Confused
[23:58] <wgrant> That is escaped
[23:58] <wgrant> It's just not valid tsquery syntax


[11:15] <s-fox> Hello.
[12:58] <duanedesign> hello malev
[12:59] <duanedesign> malev: hope you have been good. Up to anyhthing exciting or interesting lately?
[12:59] <malev> hello duanedesign!!
[13:00] <malev> I'm still with pomodoro-indicator, I could not create the deb file, it's quite frustrating
[13:01] <duanedesign> malev: ugh. yes packaging a project is either easy or hard. No inbetween :)
[13:02] <malev> ye sbut I had problems with the packing tools ubuntu's provide, for instance is lacking on ppa-create-something (don't remember)
[13:02] <duanedesign> malev: have you tried CLI companion lately?  It has some neat new features.
[13:02] <malev> no I haven't but I'll check it soon
[13:02] <duanedesign> one neat feature is integration with commandlinefu
[13:03] <duanedesign> malev: let me know what you think
[13:03] <malev> oks!
[13:03] <malev> and how are things at work?
[13:04] <duanedesign> malev: hmm. I need to look at the pomodoro technique
[13:05] <duanedesign> I have been trying out lots of time managment tools lately. Evernote, toodeldo, Remember The milk, etc. I have been using a system similar to 'Getting Things Done'.
[13:06] <duanedesign> malev: Work is going good. Stayinh busy. have not had as much time as i wish to do more coding
[13:06] <duanedesign> Staying*
[13:11] <malev> duanedesign: as a todo list I use: wunderlist
[13:12] <malev> for syncing notes I'm not using anything, I don't like evernote at all.
[13:14] <duanedesign> malev: i use Google Calendar a lot so using google Tasks has the advantage of being in the same interface, though it is a bit simple. I have been liking Remember The Milk...so far.
[13:14] <duanedesign> I will check out Wunderlist
[13:15] <duanedesign> malev: also I want to check out pomodoro-indicator. Reading about the pomodoro technique I think their are some things I can integrate into my system
[13:17] <malev> haha I like pomodoro and I wish pomodoro-indicator could be packaged :)


[10:56] <tumbleweed> Laney: ^ the bug isn't included, do you want it?
[16:17] <ScottK> All the KDE upgrade NBS is resolved/gone.
[18:54] <ScottK> infinity: Is there someone around you can poke to get this killed off: https://launchpad.net/ubuntu/+source/kile/4:2.1.3-2ubuntu1/+build/4757534
[20:52] <Laney> tumbleweed: Not excessively bothered, but would be nice to have in future. Ta


[00:23] <wgrant> 'make lint' is now giving warnings that it can't import lp.whatever for just about every import.
[22:03] <adiroiban> hi. can someone put this into a public pastebin  https://lpbuildbot.canonical.com/builders/lp/builds/648 ?
[22:21] <wgrant> It looks to me like lib/lp/buildmaster/tests/queuebuilder.txt won't be run
[22:21] <wgrant> Since it's not in doc/.
[22:21] <wgrant> Can anybody confirm?
[22:23] <adiroiban> wgrant: do you want me to run bin/test -t queuebuilder.txt on my system ?
[22:23] <wgrant> adiroiban: I know that doesn't catch it, but I'm wondering if something else does.
[22:24] <wgrant> Since it still passes.
[22:24] <wgrant> So it has probably been run recently.
[23:28] <adiroiban> wgrant: http://paste.ubuntu.com/389926/
[23:29] <adiroiban> it looks like queuebuilder.txt is not included in the search
[23:30] <wgrant> adiroiban: That's what I thought, but it might somehow be included under another name.
[23:31] <wgrant> I've moved it into doc/ for now anyway, since that's where it belongs and works.


 Sup
[03:47] <leftist> how do you change the keyboard i'm having difficulties logging in on the keyboard and am being forced to use the on screen display.
[06:05] <lordievader> Good morning
[06:18] <crydotsnake-M> Good morning ! :)
[09:21] <jubo2> Dragnslcr: Thanks 'Settings -> Desktop Behavior -> Screen Locking' is the one
[09:32] <tux_> hello, i usually do not use kubuntu, but its the only distribution which works on my laptop. does the do-release-upgrade, when a new version is released, work without problems or is it better to install kubuntu completely new?
[09:34] <crydotsnake-M> You dont need to install Kubuntu completely new. You can Upgrade the Kubuntu to the newest Version.
[09:37] <tux_> crydotsnake-M: with do-relesae-upgrade?
[09:39] <crydotsnake-M> I think yes. I never try it.
[09:40] <tux_> crydotsnake-M: how did you upgrade kubuntu to the newest release, with the discover application?
[09:40] <crydotsnake-M> I'm using KDE Neon.
[09:45] <tux_> ok, then on 17.october i will try do-release-upgrade -d
[09:49] <tux_> or -m desktop
[10:05] <tux_> thank you crydotsnake-M
[10:32] <BluesKaj> Howdy folks
[10:39] <timplaz> Why cam I install any distro (ubuntu, Arch,Kali...ect) and use any DE (XFCE,MATE,Budgie...ect) and be able to change resolution but when I try KDE I am stuck with 800x600 only?
[10:40] <timplaz> Also running in virtualbox on windows 10 host system
[10:46] <lordievader> Did you install the extensions?
[11:40] <TimPlaz> nebie here.....why can I not change my resolution? Stuck at 800x600 only.
[11:40] <TimPlaz> Can change it in Ubuntu and others.
[11:42] <TimPlaz> Running in virtualbox on windows 10 host.
[11:43] <BluesKaj> TimPlaz, doesn't VB have a res setting for the guest OS?
[11:44] <TimPlaz> Blueskaj, checking to see if I can find that now...
[11:48] <TimPlaz> Blueskaj, Don*t see anything while runniing the VM. What's weird is I can run any distro of linux and I can change the resolution in all of them no matter what DE I use except KDE.
[11:50] <BluesKaj> make sure you have the correct gpu driver installed on kubuntu
[12:26] <crydotsnake-M> No Problem tux_
[12:43] <markit> hi, is it me or kubuntu 19.04 (kde backports ppa) and 19.10 , ALT+TAB opens the windows switcher but then you can't move through the list anymore?
[12:44] <markit> I do use ALT+TAB a lot to go back and forth to the last 'n' programs, now I'm limited to previous :(
[15:19] <kapitain> hello_world
[15:20] <crydotsnake-M> Hello
[18:25] <CrazyTux> how is kubuntu different from kde neon?
[18:27] <OerHeks> neon aims at newer packages? what does the wiki say?
[18:28] <CrazyTux> which one is better?
[18:29] <CrazyTux> for a newbie and non technical end user like me?
[18:30] <OerHeks> no, you are not a newbie
[18:30] <CrazyTux> ok.
[18:31] <CrazyTux> I am a non technical end user.
[18:31] <CrazyTux> I have never used KDE Plasma.
[18:31] <CrazyTux> so I am new to KDE Plasma.
[18:36] <OerHeks> good, have fun with plasma, neon is not supported here , #kde-neon
[18:37] <CrazyTux> OerHeks: what about kubuntu?
[18:37] <OerHeks> what about kubuntu?
[18:37] <CrazyTux> btw, how much ram and cpu does kubuntu based on the latest lts version use at startup?
[18:37] <CrazyTux> or when idle.
[18:38] <OerHeks> all depends on your hardware and installed services
[18:38] <OerHeks> so, you tell us?
[18:39] <CrazyTux> my laptop runs on intel core i3 2.0 GHz quad core cpu and 4 GBs of RAM.
[18:39] <CrazyTux> OerHeks: on your computer, how much does it use?
[19:44] <gianni> ciao
[19:45] <gianni> !list


[03:53] <commander32> Is there a compatibility check?
[03:54] <commander32> For the realtime kernel
[04:17] <tomreyn> yes, but you missed it.
[04:17] <tomreyn> :-P
[04:18] <tomreyn> commander32: what do you mean by compatibility check, what would it check, or what makes you think there can be one?
[04:26] <OvenWerks> there is no ubuntu real time kernel an yway.
[04:27] <OvenWerks> Ubuntu has the generic kernel and the lowlatency kernel, both of which support the same things. That is, whatever works in the generic kernel (grafics cards etc) should also work in the lowlatency kernel.
[06:38] <commander32> Mostly soundcard
[06:41] <OvenWerks> which sound card? Alsa is Alsa, the kernel will make no difference in that
[06:41] <commander32> tomreyn: drivers fully function for raw writing sound io
[06:42] <OvenWerks> If it is a USB 2.0 (or 1.1) they should just work. All the old PCI cards seem to work too
[06:42] <commander32> And realtime audio monitoring
[06:43] <commander32> Can we get on par with winXp yet direct x 6
[06:43] <OvenWerks> commander32: the line "drivers fully function for raw writing sound io" does not make sense, rt audio monitoring can mean a number of things but I would assume low latency is what you are interested in.
[06:44] <OvenWerks> on par? I always thought win... anyway was slower than mac or linux.
[06:44] <OvenWerks> (longer latency)
[06:45] <OvenWerks> That seems to be the attitude of the audio interface manufactures
[06:45] <commander32> It has realtime kernal io, linux is latent
[06:45] <OvenWerks> Everything is latent. The question is how much.
[06:46] <OvenWerks> I have run sound at .7mslatency in linux with no difficulty
[06:46] <OvenWerks> Anyway, I need to pick up my wife from work. Then bed. Talk later
[06:47] <commander32> With Ubuntu sound didnt seem to monitor (loopbck) any
[06:48] <commander32> My guess why: it is the loopback monitor And the audio is rigged
[06:49] <commander32> Raw data goes straight to spyware
[06:50] <commander32> Lucid studio worked
[06:50] <commander32> After lucid everytying went trash
[06:52] <commander32> Xen
[06:53] <commander32> It all went to xen or something
[06:54] <commander32> Xen with fakeroot
[06:55] <commander32> Maybe a spyware backend and most usefulnes broke
[19:16] <frank> Hallo, I have trouble starting ubuntu-studio controls. Can somebody help?
[20:17] <studiobot> Karel M. was removed by: Karel M.
[23:34] <studiobot> dEE001 was removed by: dEE001


[07:37] <siji> hi all
[07:39] <persia> Hey siji.  You7ve been looking for me when I haven't been around.
[07:39] <siji> persia, hi
[07:39] <siji> yes
[07:40] <siji> i have finished the xbmc build on natty
[07:40] <siji> but it's giving some runtime error
[07:40] <siji> python: can't open file '/usr/local/share/xbmc/FEH.py': [Errno 2] No such file or directory
[07:41] <persia> Is there some FEH.py file somewhere?
[07:41] <siji> frm xbmc IRC , they were telling that something wrong with build
[07:41] <siji> yes it's there
[07:41] <persia> Also, for questions like that, it's better to just ask the question, and whoever is around will answer.
[07:41] <persia> It's there, and in that location?
[07:41] <siji> yes I asked .. but no respond :(
[07:42] <siji> ya, but according to xmbc irc the build will never look for such file
[07:42] <siji> for starting xbmc
[07:42] <persia> Very strange.
[07:43] <siji> so i guess smthing is wrong in my conf. parameter
[07:43] <persia> It sometimes happens that things work differently, but usually that's intentional.  If upstream says the file should never be used, I'd recommend repeating the process of making it happen, documenting each step along the way, and submitting that as a bug upstream.
[07:43] <siji> persia, sure will do
[07:44] <persia> They might tell you something in Ubuntu is broken, but they'll probably tell you what is broken, and we can make sure that gets fixed.
[07:45] <siji> persia, just want to confirm my build process is also proper
[07:45] <persia> Alternately, they may find something broken in the configuration, or be surprised by some strange build process thing that only shows up if certain things are done.
[07:45] <siji> ya am trying to get some help frm xbmc developers
[07:45] <siji> regd.build process
[07:46] <siji> I have generated natty image using rootstock
[07:46] <siji> then frm the host PC chroot 'ed to that image and built xbmc there
[07:47] <siji> and make install  prefix folder copied to my beagleboard natty
[07:47] <siji> Hope this method will work
[07:48] <persia> It might.  I would have just built it on the beagleboard directly.  Fussing with some other computer can only complicate things.
[07:48] <siji> ok
[07:49] <siji> btw, will it possible to increase the natty image size
[07:49] <siji> in rootstock i have defined 1.2GB , now it's telling no space left
[07:49] <persia> Yeah, but.
[07:49] <siji> (anyway, i have started the rootstock with 8GB)
[07:50] <persia> You'd need to create a new image file, format it with a new filesystem, and move the files.
[07:50] <siji> persia, i think better to create new rootstock image right
[07:50] <persia> Certainly easier :)
[07:50] <siji> ok
[07:51] <siji> another doubt is about vdpau
[07:52] <siji> I have defined --disable vdapu , while building XBMC
[07:52] <siji> since it was giving some error which is related to this
[07:52] <siji> So this video decoder is necessary for omap ?
[07:52] <siji> or it's need only for nvidia
[07:54] <siji> cores/VideoRenderers/RenderManager.h: In member function ‘void CXBMCRenderManager::AddProcessor(CVDPAU*)’:
[07:54] <siji> cores/VideoRenderers/RenderManager.h:114:20: error: ‘class CLinuxRendererGLES’ has no member named ‘AddProcessor’
[07:54] <persia> No idea :)  I like to pretend all hardware is identical (although I'm not always successful)
[07:54] <siji> ok
[07:54] <siji> fine
[07:54] <persia> That looks like a more general error, that probably needs investigation.
[07:55] <siji> ok, it resolved by adding --disable-vdpau
[07:55] <persia> Maybe some issue with templates generation in preprocessing.  Maybe some ifdef that isn't clean on ARM.  But *something*, because that's the class of error that should make xbmc not work at all.
[07:56] <siji> persia, ok
[07:56] <persia> Well, it was hidden with --disable-vdpau.  Hidden and solved are different (although hidden is fine for most folk)
[07:56] <siji> ok :)
[08:07] <siji> persia, something off topic
[08:07] <siji> have you aware of exfat filesysem
[08:07] <siji> Which is patented my MicroSoft
[08:08] <siji> I read somewhere that samsung is paying 15$ per each phone to Microsoft , because of this filesystem
[08:12] <brendand> as far as i know the only thing special about it is that it's 64-bit
[08:13] <persia> I've never heard about it.
[08:13] <siji> oh I missed some point, this exfat is used by android I think
[09:05] <malfet> hi all
[09:05] <malfet> can somebody help me understand logic behind arm assembly sequence
[09:15] <janimo> malfet, which sequence in particular?
[09:16] <malfet> janimo, "mov     r2, sp; bic     r4, r2, #8128;  bic     r4, r4, #63; "
[09:16] <malfet> Why there are two bic instructions?
[09:17] <malfet> (code snippet about is from objdumped kernel_init)
[09:17] <janimo> malfet, the immediate values that can be put in bic (and other ARM intructions that accept such constants) are restricted
[09:17] <janimo> so they can be expressed in a limited number of bits
[09:18] <janimo> so if you want a value that is not expressible as a sum of power of twos you may need to use more than one instructions
[09:18] <malfet> oh, so bic is encoded as #BIC_OP|#REGA|#REGB|#IMM|#IMM_SHIFT?
[09:19] <janimo> malfet, do not know off the top of my head but since you are limited to 32 (or 16 for thumb) bits for an instruction you cannot fit a full 32 bit constant there as you need space for the opcode and other metadata
[09:19] <janimo> malfet, the ARM docs described this in much detail
[09:20] <janimo> so 8128 can be put there easily as it is exactly 2^13
[09:20] <janimo> well not exactly actually
[09:21] <malfet> janimo, got it. thanks a lot for explanaiton
[09:21] <janimo> malfet, was a bit vague but this is the general idea :)
[09:21] <malfet> forgot that all ARM instructions are conditional, so there is not enough space for 16-bit imm (like on ppc/mips)
[09:24] <janimo> malfet, right, after refreshing my memory, 12 bit values, but only those obtainable by a 8 bit value plus an up to 4 bit rotate
[09:25] <malfet> another newbie questions: r1-r3 doesn't have to be preserved across function calls?
[09:25] <malfet> or is it true only for aapcs abi?
[09:25] <janimo> malfet, are registers used for arguments, not preserved AFAIK. r0 is return value
[09:26] <janimo> this is what I know from the ABIs I used and from the asm code I saw
[09:26] <malfet> ok
[09:26] <janimo> I am not even sure anything is preserved automatically across calls. One needs to store load explicitly if needed
[09:27] <dmart> malfet, janimo: In Thumb-2 (i.e., on ARMv7) you can have most of the same immediate constants that you can have in ARM
[09:29] <malfet> looks like ABI mandates r4-r11 to be preserved across the calls
[09:29] <dmart> In Thumb-2, you can have constants of the form 000000xy 00xy00xy xy00xy00 and xyxyxyxy, as well as an 8-bit value shifted to any bit position.  However, Thumb-2 doesn't allow constants where the value is rotated across the end of the word (i.e,. 0xC000000E is allowed in ARM, but not in Thumb-2)
[09:30] <malfet> interesting
[09:30] <dmart> malfet: You can find docs describing the procedure call standard on infocenter.arm.com
[09:31] <malfet> reading thru it now
[09:31] <malfet> thanks
[09:32] <dmart> malfet: Your understanding sounds correct though -- across a function call, r4-r11,sp must be preserved; r0-r3,r12,lr can be clobbered; r0-r3 are used for arguments, r0 for the return (r0-r1 for 64-bit values).  Extra arguments are passed on the stack if needed
[13:26] <YuLin> Is there any existed directfb-ubuntu distro release?
[14:02] <ScottK> persia: I was wondering if you had any suggestions about how to pursue fixing https://launchpadlibrarian.net/75437592/buildlog_ubuntu-oneiric-armel.vlc_1.1.11-1ubuntu1_FAILEDTOBUILD.txt.gz
[15:38] <slangasek> rsalveti: hmm!  happy to follow, but I hadn't received any notice of the qemu-linaro release
[15:42] <rsalveti> slangasek: at linaro-announce, posted yesterday :-)
[15:42] <rsalveti> fresh news
[15:44] <slangasek> ah... not on that list, Peter has notified me directly in the past


[15:50] <Staloggi> Hello
[15:50] <holstein> o/
[15:50] <Staloggi> Can someone help me
[15:50] <holstein> Staloggi: you'll have to ask
[15:52] <Staloggi> Not tech wavy at all but can you download ubuntu studio directly from the website or do you have to load it on a disk and set it up to start when you turn your computer on.
[15:53] <holstein> !Install
[15:53] <holstein> Staloggi: it can be challenging
[15:53] <holstein> Staloggi: what are you using right now? XP?
[15:53] <Staloggi> No I'm using ubuntu 12.04
[15:53] <holstein> Staloggi: you can add studio pacakges to ubuntu 12.04
[15:54] <holstein> Staloggi: you can download ubuntustuduio and install it beside 12.04.. dualboot
[15:54] <Staloggi> But it is a split os so I also have windows 7 which I'd like to get rid of
[15:54] <holstein> Staloggi: sure.. i suggest makind *good* backups.. since, all hard drives fail, this is a good practice
[15:54] <holstein> be prepared for total failure, and you'll be fine :)
[15:55] <holstein> then, decide what you want, and make it happen
[15:55] <holstein> if you want dual boot ubuntu 12.04 and ubuntustuduio 14.04 or whatever
[15:55] <holstein> ubuntustuduio *is* ubuntu, so you dont need to get ubuntstudio to have it, if you already have ubuntu
[15:56] <Staloggi> What is supposed to fail exactly?
[15:57] <Staloggi> Why is my hard drive going to fail
[15:57] <holstein> Staloggi: ?
[15:57] <holstein> Staloggi: because they all do
[15:58] <holstein> Staloggi: all hard drives fail
[15:58] <Staloggi> Ok
[15:58] <holstein> Staloggi: so, planning for that inevitable event *now* will not only give you peace of mind going forward through whatever installation process you are going to do, but, give you a necessary and important backup
[16:00] <Staloggi> Ok so I need to backup my computer, now if I don't what will happen? Will I just loose all of the information on the computer or will my computer completely stop working?
[16:01] <holstein> Staloggi: *when* your hard drive fails, you lose anything you need from it
[16:01] <holstein> Staloggi: this is quite regardless of anything related to any OS
[16:01] <holstein> Staloggi: you leave here today, and do absolutely nothing.. dont install ubuntustudio or anything.. that drive *is* going to fail, at some point
[16:01] <holstein> they all do
[16:01] <holstein> Staloggi: you need not believe, or trust me on this.. just search the internet, or the source of your choice. or call the professional of your choice
[16:02] <holstein> Staloggi: this is fact
[16:02] <holstein> Staloggi: your computer uses the hard drive to store information.. so, your computer will not be effected. only the hard drive, and the information you store on it
[16:02] <holstein> Staloggi: to a casual user, this would appear as though the computer has "stopped working".. but, this is just one part of it
[16:03] <Staloggi> Well then I already have ubuntu so is there a way to get windows off of my computer then because it a dual boot
[16:03] <holstein> Staloggi: like, if your vehicle has a flat tire.. you would not say "my car is ruined, and doest work any longer"
[16:03] <holstein> Staloggi: its just a part.. the hard drive. with a life expectancy.. and it fails. and when it does, it doesnt provide its functionality to the machine any longer
[16:04] <holstein> Staloggi: you can use whatever tools you like to remove what you like
[16:04] <holstein> Staloggi: i suggest having backups before doing *any* partition management
[16:04] <Staloggi> But I'm not sure how to remove the window operating system through ubuntu
[16:05] <holstein> Staloggi: you can (and should) use a live CD, such as a gparted live cd, or an ubuntu installation cd, and remove what you like
[16:05] <holstein> Staloggi: you can remove the ntfs partition, and grow the ext linux partiton over that space
[16:05] <holstein> Staloggi: its not trivial, and you can break things
[16:06] <holstein> Staloggi: i suggest, getting a 14.04 live CD, and installing fresh to the entire disk, after backing up important data
[16:06] <Staloggi> So back up all my files then burn a copy of ubuntu and download ubuntu from the disk and if it fails then I have the backup disks to go back to
[16:06] <holstein> Staloggi: no.. *when* your disk fails, you have backups
[16:06] <holstein> Staloggi: this is regardless of if you do anything to your machine
[16:07] <holstein> Staloggi: gparted is the tool i use to manage partitions http://gparted.org/
[16:07] <holstein> Staloggi: its available from ubuntu live CD"s
[16:08] <Staloggi> Ok
[17:57] <Staloggi> Is there a website that will teach me how to use linux and utilize terminal completely
[17:58] <Staloggi> ?
[17:59] <Staloggi> Hello?


[07:28] <mup> Bug #1786967 changed: Cannot target zone constraints in juju deploy bundle with MAAS provider <juju:Incomplete> <https://launchpad.net/bugs/1786967>


[06:03] <jibel> duflu, the broken combo bug could be a regression of bug 1822075
[06:05] <duflu> jibel, yes, or just similar
[06:06] <duflu> jibel, I guess using Wayland might work around it?
[06:06] <jibel> IDK I cannot test right now
[06:14] <oSoMoN> good morning desktoppers
[06:19] <duflu> Hi oSoMoN
[06:21] <Laney> hey
[06:22] <duflu> Hey hey Laney
[06:22] <duflu> Where be you?
[06:22] <Laney> moin duflu
[06:22] <Laney> I'm in the conference accommodation
[06:22] <Laney> most other people have gone to the beach or to museums
[06:22] <Laney> but my flight is soon
[06:23] <duflu> Win some and lose some
[06:23] <duflu> That's odd. The new Yaru theme is making the temporal dithering in my monitor more visible
[06:24] <duflu> Kind of annoying
[06:24] <duflu> Because it's fading a white menu over a light blue background. The colours are so close you notice the in-between colours
[06:30] <oSoMoN> good morning duflu, Laney
[06:34] <Laney> hey oSoMoN
[06:34] <Laney> are you well?
[06:41] <Laney> duflu: are you sure that the duplicating of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1841661 was right or did you mean a different bug maybe?
[06:41] <duflu> Laney, it looks like the right bug since the behaviour is apparently the same and they are related generations of CPU
[06:42] <Laney> Jonas told me that one is a regression in 5.1/5.2 and the reporter of the one you duped to was on 4.15
[06:42] <duflu> Laney, feel free to separate it
[06:42] <Laney> IOW it is a regression in eoan
[06:43] <Laney> OK, thanks
[06:43] <duflu> That doesn't mean they're really separate bugs but I'm not bothered either way
[06:43] <duflu> Don't care to find out right now
[06:44] <Laney> Sure, but I'd like to not accidentally fix one bug and leave the other one existing because we thought they were the same when they weren't
[06:44] <Laney> if that makes sense
[06:44] <duflu> Laney, well that happens and it doesn't hurt generally. Just un-duplicate after verifying that
[06:48] <oSoMoN> Laney, I'm good, how are you yourself?
[06:49] <Laney> nice, but we just had our last Eklektik breakfast :(
[06:49] <oSoMoN> that place is awesome
[07:03] <didrocks> good morning
[07:07] <Laney> hey didrocks
[07:08] <Laney> you good?
[07:08] <duflu> Morning didrocks
[07:09] <oSoMoN> good morning didrocks
[07:10] <didrocks> hey Laney, I'm fine, thanks, you?  Sad the top performance fix in 3.34 got reverted because of bugs in the Wayland backend. But I understand because I haven't yet offered a complete fix for that
[07:34] <duflu> How are you seb128?
[07:35] <seb128> it did? :(
[07:35] <seb128> I'm good
[07:35] <seb128> they didn't want to wait for a fix?
[07:36] <oSoMoN> salut seb128
[07:36] <duflu> No. I understand though. It's the stable solution
[07:37] <seb128> they might commit it back if a fix comes in time?
[07:38] <duflu> seb128, I'm looking into it. Unfortunately it mostly involves rewriting that 1.5 years of work that was discarded in mutter!73
[07:38] <duflu> So I really need to find a solution that avoids that
[07:38] <seb128> :(
[07:38] <duflu> Or rewrite that (which will be less than 1.5 years the second time)
[07:39] <duflu> I also have myself to blame for not finishing that. Although my excuse is that we deprioritised Wayland
[07:39] <duflu> But now that's hurting Xorg
[07:41] <seb128> we could perhaps distro patch that back?
[07:43] <duflu> seb128, no forget that -- I stopped working on it because Jonas rewrote everything and the conflicts became overwhelming
[07:43] <duflu> It also would not be mature if I had a replacement soon
[07:43] <seb128> I meant the commit they reverted
[07:43] <duflu> seb128, it hurts Wayland too much right now, which still affects some of our users
[07:44] <duflu> -hurts +crashes
[07:44] <seb128> ah, crash :/
[07:44] <seb128> k then
[07:45] <duflu> seb128, that email I sent today is unrelated to all this. We can go ahead with that
[07:47] <seb128> right
[08:06] <seb128> brb, changing location
[08:10] <willcooke> Morning all
[08:11] <lis> good morning :)
[08:11] <didrocks> hey willcooke
[08:11] <didrocks> morning lis
[08:12] <lis> hey didrocks :)
[08:12] <lis> did you go to guadec?
[08:12] <didrocks> lis: I didn't, was on holidays also avoiding travelling right now (planes)
[08:12] <didrocks> you?
[08:13] <lis> no :(
[08:13] <lis> had a family vacation in the middle of the main part.  thought about coming for the couple of days of bofs, but decided not to
[08:29] <oSoMoN> good morning willcooke, lis
[08:30] <duflu> Morning willcooke and lis
[08:34] <seb128> hey oSoMoN willcooke, how are you?
[08:36] <oSoMoN> seb128, I'm good, how are you?
[08:37] <oSoMoN> you made it home safely?
[08:37] <seb128> yeah, easy trip
[08:38] <seb128> the bus stressed me a bit, I installed that GUADEC recommended map which told me to take 28B at :23
[08:38] <seb128> but another bus arrived at :20
[08:38] <seb128> with a plane sign on the screen, so I walked in
[08:39] <seb128> but couldn't read any of the greek signs at all then
[08:39] <seb128> so I was unsure for a while if I was on the right bus
[08:39] <seb128> then the rest was easy :)
[09:08] <popey> Hello desktoppers!
[09:08] <popey> Where is the source for ubuntu firstrun application used in 18.04.3?
[09:09] <Laney> gnome-initial-setup
[09:09] <popey> thanks
[09:10] <Laney> some desktop and ex-desktop things in https://lists.ubuntu.com/archives/ubuntu-devel/2019-August/040787.html
[09:11] <popey> That doesn't look like the source for the Ubuntu firstrun thing.
[09:12] <popey> Is there some plugin we use or something that does all the livepatch and "You're ready to go" recommended software?
[09:13] <Laney> it is
[09:13] <Laney> laney@nightingale> grep "You're ready to go" **/*.ui                                                                                ~/temp/gnome-initial-setup-3.28.0
[09:13] <Laney> gnome-initial-setup/pages/apps/gis-apps-page.ui:            <property name="label" translatable="yes">You're ready to go!</property>
[09:13] <popey> oh, i cloned master
[09:14] <Laney> the Ubuntu modifications are done via distro patches, so you'll need to get the source from the fork on Gitlab or from the archive
[09:14] <Laney> s/patches/changes/? not sure if they are actual debian/patches
[09:15] <popey> https://gitlab.gnome.org/Community/Ubuntu/gnome-initial-setup
[09:15] <popey> ?
[09:15] <Laney> https://gitlab.gnome.org/Community/Ubuntu/gnome-initial-setup/tree/ubuntu-welcome-bionic this one I think for bionic
[09:15] <Laney> ICBW
[09:15] <popey> ta
[09:15] <Laney> got to go through a passport gate now, be back if I get the chance
[09:15] <popey> o/
[09:15]  * Laney mutters about schengen
[09:15] <seb128> popey, hey, what are you trying to change there?
[09:15] <popey> Not change, investigate.
[09:15] <seb128> Laney, good luck :)
[09:16] <popey> I watched a video where someone did an install, and the final page which shows software, showed the wrong applications (IMO)
[09:16] <Laney> nosy128 :P
[09:16] <seb128> haha
[09:16] <popey> It showed the current featured list, not the firstrun featured list specifcally made for the firstrun wizard
[09:16] <willcooke> popey, remember that it hides apps you already have installed
[09:17] <popey> not what I'm concerned about willcooke
[09:17] <popey> https://usercontent.irccloud-cdn.com/file/zZAPIIXa/This%20list%20is%20wrong
[09:17] <popey> It's a clean install so it won't be hiding anything
[09:17] <seb128> popey, https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-initial-setup/tree/debian/patches/0001-Add-Ubuntu-mode-with-special-pages.patch#n909
[09:17] <willcooke> got ya
[09:18] <seb128> popey, that's the call it's doing
[09:18] <popey> so it's looking for the ubuntu-firstrun section in the store
[09:18] <seb128> yes
[09:18] <popey> https://www.irccloud.com/pastebin/viSLoQGQ/
[09:19] <seb128> store changed without telling us?
[09:19] <popey> perhaps
[09:19] <popey> I'll poke them
[09:19] <popey> thanks!
[09:19] <seb128> thx, let us know
[09:19] <popey> (not your bug by the look of it) :D
[09:19] <seb128> :-)
[11:42] <popey> seb128: started a thread on the forum, looks like snapd or snapd-glib to blame, maybe? https://forum.snapcraft.io/t/ubuntu-firstrun-hidden-section-not-showing-in-ubuntu-initial-setup/12966
[11:56] <seb128> popey, thx, probably one for robert_ancell but he might not be much around in the next days, travelling back from GUADEC
[11:56] <popey> I thought so. It's not a catastrophe, but just a weird bug I guess.
[12:01] <seb128> popey, trying maybe sending Robert an email to make sure he doesn't miss it
[12:01] <popey> will do
[12:12] <duflu> Phew. seb128 I just reproposed the optimization, with built-in fixes for those side-effects.
[12:12] <duflu> And now good night
[12:12] <seb128> duflu, woot, well done
[12:12] <seb128> night!
[12:15] <seb128> tjaalton, there is a newer libinput point release, do you want to do the update or should I? ;)
[12:41] <GunnarHj> cyphermox: Can you please take a look at what I did here:
[12:41] <GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/usb-modeswitch/+packages
[12:41] <GunnarHj> It depends on tcl8.6, which is in main, and the dispatcher is a shell script run via tclsh8.6.
[12:58] <tjaalton> seb128: I'll push it to debian
[13:01] <seb128> tjaalton, thx
[13:01] <seb128> GunnarHj, hey, do you still plan to look at the gnome-getting-started-docs and gnome-user-docs updates?
[13:09] <GunnarHj> seb128: Yes.. But they are still on 3.33.90, and since they are not affecting anything else, I feel I'd better wait for 3.34.0 (at least). Am I missing anything by thinking so?
[13:11] <seb128> GunnarHj, we updated all the other GNOME components, and technical it's a new serie and we missed feature freeze and need a ffe now (though maybe less true for documentation)
[13:11] <seb128> GunnarHj, I would expect it to go with the rest of GNOME
[13:13] <GunnarHj> seb128: Doing it in Ubuntu is easy, and I could do that later today, if you like. Updating Debian's repos is more work, and it would be good to only need to do that once IMO.
[13:13] <seb128> GunnarHj, if you could update for Ubuntu for now that would be nice
[13:14] <seb128> we can do Debian once 3.34 is out
[13:15] <GunnarHj> seb128: Ok, will do. Btw, as regards Debian, would it be possible that you give me write access to those repos? Would be a bit inconvenient to handle new upstream via merge requests.
[13:16] <seb128> GunnarHj, I don't think I can ask, maybe check L_aney (he's travelling today though) if he remembers what is needed to be added
[13:18] <seb128> tjaalton, also do you think we could update libxkbcommon through Debian?
[13:19] <GunnarHj> seb128: Sure, I can ask him. I just created an own repo, and noticed that there is a setting for inviting additional members.
[13:21] <seb128> tjaalton, also libx11?
[13:48] <cyphermox> GunnarHj: no; this is exactly what we don't want (a tcl script in the boot path)
[13:49] <cyphermox> tcl8.6 isn't currently part of the boot path, nothing needs it, so loading yet another interpreter to run a single script is really not great for boot speed and performance
[13:49] <GunnarHj> cyphermox: That's what I feared you should say, so I'm about to fix the patch instead. ;)
[13:50] <cyphermox> GunnarHj: if you think this is no longer an issue, best would be to pitch it to vorlon; he was the original requester for fixing usb-modeswitch :)
[13:50] <cyphermox> tbh, I understand the concerns, but I'm not sure how much of an effect it has on boot speed, compared to the sustained effort of maintaining that patch
[13:51] <cyphermox> otoh, by now usb-modeswitch strikes me as pretty much a dead thing, used less and less
[13:51] <GunnarHj> cyphermox: I'm not skilled enough to argue with any of you on that topic.
[13:51] <cyphermox> GunnarHj: please don't think like that, that's just not true
[13:51] <GunnarHj> cyphermox: And yes, not much happens upstream with usb-modeswitch nowadays.
[13:52] <cyphermox> we all start from somewhere, I expect fixing the patch is also weirdish
[13:52] <GunnarHj> cyphermox: It is, but it's done now. :)
[13:52] <cyphermox> it was a very crude patch using just C and as few things as possible
[13:52] <cyphermox> oh, cool
[13:53] <cyphermox> GunnarHj: if you noticed, it's like a third-grader did a word-for-word translation of some bad essay from one language to another ;)
[13:54] <GunnarHj> cyphermox: Haha, TBH i haven't looked much at the code. The OP pointed to the problem, so I just removed a trailing newline from a string.
[13:54] <cyphermox> ah, cool
[14:04] <tjaalton> seb128: eventually es
[14:04] <tjaalton> yes
[14:05] <tjaalton> there's bunch of janitorial things to finish acrosse the whole stack
[14:05] <tjaalton> -e
[14:05] <seb128> tjaalton, sorry for the nags, I'm still trying to get on top of https://people.canonical.com/~platform/desktop/desktop-packages.html, we are getting there :)
[14:05] <seb128> tjaalton, unsure if you saw but I updated a good stack of the xthings which were a minor behind for eoan
[14:05] <tjaalton> there hasn't been anyone else doing updates in the past 6mo or so
[14:06] <tjaalton> on debian side
[14:06] <seb128> is the stack in lowNMU? ;)
[14:07] <tjaalton> dunno
[14:07] <seb128> I can maybe upload those to Debian at the start of the next Ubuntu cycle if they still haven't got updated
[14:07] <tjaalton> should land in git too
[14:07] <seb128> right
[17:12] <willcooke> night all
[17:17] <k_alam> Laney: Hi, u there ?
[17:21] <k_alam> Laney: There is some issue with recent gnome-session update, if I try to update, it tries to uninstall unity-session ?


[00:03] <mlankhorst> a system stuck between libdrm and libdrm-lts-quantal isn't pretty to repair..
[00:04] <mlankhorst> x stack itself is a lot easier, worst case you remove the entire xorg-server-core package and all drivers and install 'xorg' again
[00:09] <RAOF> Yeah.
[00:10] <RAOF> It shouldn't be *too* hard to ensure it doesn't get wedged half-way between, though.
[00:57] <osiris> bjsnider, i think thats the driver i have running now. that is the default that comes with installation, correct ?
[00:59] <bjsnider> osiris, yes
[00:59] <osiris> then yes, it is working that way, sans HW accel
[01:02] <bjsnider> if you install libgl1-mesa-dri-experimental you will get hw accel
[01:03] <bjsnider> and you can get vsync with Option "GLXVBlank" "on" in xorg.conf device section
[07:12] <tjaalton> mlankhorst: i see you updated xserver for precise, thanks :)
[07:14] <tjaalton> bjsnider: that package is basically empty iirc, the nouveau dri drivers are included in the main package
[09:27] <mlankhorst> RAOF: speaking of which can you upload the new xorg-server package to proposed?
[15:52] <Sarvatt> RAOF: everyone complaining is on sandybridge and newer intel and an 0529 mesa checkout works fine, just a heads up in case you see complaints about the system compositor ppa not showing icons or alt+tab thumbnails in unity :)
[16:05] <mlankhorst> ok now lets see if this patch will boot or not \o/
[16:08] <mlankhorst> scarily, it does
[16:41] <mlankhorst> glxgears uses 10% cpu, Xorg 20%
[16:41] <mlankhorst> 35042 frames in 5.0 seconds = 7008.062 FPS