[11:33] <Unit193> (Don't do that one.)
[16:40] <Pici> good luck y'all
[16:44] <genii> heh
[16:46] <jess> how's things
[16:49] <Pici> busy!
[16:50] <jess> but under control?
[16:50] <Pici> Some manner of control, sure.
[16:50] <jess> well, you know where to find network staff if you need a hand
[23:33] <Unit193> !+ltsupgrade > lotuspsychje


[04:22] <cjwatson> xnox: I fixed a syntax error in python3.4_all_dev.ben that was breaking the transition tracker (unmatched parenthesis).  Just removing the unmatched paren produced something nonsensical, so I guessed a bit at what it actually was supposed to be from the most recent commit; please review
[04:23] <xnox> cjwatson: looking. but it is actually doko__ who is growing number of underscores in his nick, and requesting that tracker.
[04:24] <cjwatson> xnox: fine, but you were the committer :-)
[04:27] <xnox> =))) touch-it-last strikes again...
[04:35] <cjwatson> if you're doing it on behalf of somebody else then you can always mention their name in the commit message, or use --author, or whatever
[09:58] <mlankhorst> poke, can someone accept all lts packages in NEW?
[10:11] <xnox> doko__: excellent =) now who is going to port unity & nux to glew 1.10? =)
[10:18] <mlankhorst> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
[15:17] <doko> xnox, sorry, didn't know the reason why it was kept back :-/
[15:18] <xnox> doko: nevermind, i did the first round upload & nux/unity turned out to be trivial to fix =)
[15:18] <xnox> doko: as soon as arm64 catches up.... i'll look into finishing it off.
[15:19] <xnox> glew (42%) done as per transition tracker.
[16:15] <infinity> rtg: ^-- Guessing we want that for 12.04.4?
[16:16] <rtg> infinity, nah, its for v3.10+ kernels, e.g., the Trusty backport
[16:16] <apw> rtg, saucy is 3.11
[16:16] <infinity> rtg: Last I checked, saucy was 3.10+
[16:17] <rtg> oh, dyslexia reigns supreme this morning
[16:18] <rtg> infinity, lemme make really sure. I'll get back to you in  a bit.
[16:18]  * infinity goes to find some back to work breakfast.
[16:19] <infinity> rtg: Sure.  If we want it for 3.11, get someone to smoketest that the new files appear kinda sane and work with lts-saucy somehow, and we'll jam it through.
[16:50] <rtg> infinity, ok, I've determined that the iwlwifi 7K and 3K firmware updates will definitely affect the Saucy LTS kernel. The Brocade bits should have no impact on v3.11
[17:26] <zul> how does syncs get processed btw?
[17:36] <infinity> zul: That question needs more context to know what you're actually asking.
[17:37] <zul> infinity:  sorry i was talking about libvirt-python from debian
[17:42] <xnox> zul: like so ^ =)
[17:42] <zul> xnox:  yeah thanks
[17:43] <infinity> zul: To be fair, it all would have happened automatically, if you waited for an autosync.  But yeah, if you sync something NEW explicitly, we need to process it like any other NEW package, except that we don't bother reviewing it if it's obviously a straight Debian sync.
[17:46] <zul> infinity:  coolio
[18:25] <utlemming> has the 13.04 EOL been announced yet?
[18:26] <utlemming> All I've seen is that it is sometime in January, but no date.
[18:32] <infinity> utlemming: D'oh.  I should have sent out an announce during the break, probably.  I'll get to that later today.
[18:35] <mlankhorst> infinity: hey can you accept mesa binaries?
[18:35] <mlankhorst> mesa-lts-saucy in precise
[18:36] <infinity> mlankhorst: I'll look at all the LTS userspace stuff this afternoon if no one beats me to it.  Just dealing with kernels right now.
[18:39] <mlankhorst> infinity: just accept the binaries, after that xorg-server can build and you can tell everything that's left to build :-)
[18:42] <infinity> mlankhorst: Fiiiine.  Just had to make sure it was all destined for main first, etc.


[01:02] <cjwatson> bjf: right, the few builds I did in the middle of the day today were to switch over to the saucy enablement stack and make sure it at least minimally worked
[01:02] <cjwatson> (which it seems to)
[01:03] <cjwatson> so we're definitely into the .4 test cycle now
[01:16] <bjf> cjwatson, awesome


[00:00] <wallyworld_> ah right, glad we found out how it was happening
[00:01] <StevenK> Let me toss that ec2 and then forage for some breakfast.
[01:04] <RyuGuns> Hey guys.
[01:05] <RyuGuns> I've been in the process of registering a new account...
[01:06] <RyuGuns> But I am not allowed to.,.
[01:06] <RyuGuns> Wait, actually, nevermind.
[01:07] <RyuGuns> How do I merge accounts?
[01:07] <bobweaver> RyuGuns,  https://help.launchpad.net/YourAccount/Merging
[01:07] <bobweaver> :)
[01:08] <RyuGuns> :)
[01:24] <RyuGuns> Funk.
[01:24] <RyuGuns> How do I change my ID?
[01:24] <RyuGuns> Nevermind.
[01:54] <lifeless> RyuGuns: bobweaver: you might prefer #launchpad for customer support
[01:56] <RyuGuns> https://launchpad.net/ubuntu+mobile+phone
[01:56] <RyuGuns> Anyone interested?
[05:16] <StevenK> wgrant: Free to review, or still distracted by *redacted*?
[05:25] <StevenK> And no wallyworld.
[05:25] <StevenK> Maybe bigjools' tech has broken TPG.
[05:25] <wgrant> StevenK: 'sup?
[05:25] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/hack-itemwidget/+merge/104202
[05:26] <wgrant> oh god
[05:26] <wgrant> StevenK: Why are you setting term.name now?
[05:27] <StevenK> wgrant: Because the test in test_itemswidgets requires it
[05:27] <StevenK> And I'd rather just use self.assertRenderItem
[05:30] <wgrant> StevenK: r=me before lp melts again
[05:30] <StevenK> Haha
[06:59] <wallyworld> wgrant: StevenK: have you seen bug emails with the same info twice? eg "** Visibility changed to: Private" is listed twice in the one email
[07:00] <wallyworld> i seem to recall i may have seen this but am not sure
[07:00] <StevenK> I can't recall that one, personally.
[07:01] <StevenK> I a note to track down why information type: Public -> Private turns up twice when you change the information type via JS.
[07:02] <wallyworld> StevenK: that's what i'm seeing also but i'm fairly sure it happened before the info type field was introduced
[07:09] <wgrant> I don't recall seeing that before.
[07:09] <wgrant> I would suspect a regression.
[07:29] <wallyworld> wgrant: i seem to recall it may have happened for eg "** Visibility changed to: Private" which was before disclosure
[07:29] <wallyworld> but i can't be 100% sure
[07:30] <wgrant> That stuff was dangerously refactored a few months ago
[07:30] <wgrant> It may have been a regression then.
[08:14] <czajkowski> aloha
[08:23] <jml> czajkowski: hi
[08:24] <czajkowski> morning
[08:40] <jml> ok.
[08:40] <jml> so I'm going to do some Launchpad hacking.
[08:40] <jml> stand back.
[08:40] <wgrant> Uhoh
[08:40] <jml> does it work in precise yet?
[08:40] <wgrant> We're doomed
[08:40] <wgrant> Um
[08:40] <wgrant> Well
[08:40] <wgrant> Maybe.
[08:41] <wgrant> You'll need python2.6
[08:41] <jml> I have Python 2.6!
[08:41] <wgrant> It might Just Work™, then.
[08:41] <wgrant> I fixed the other issue yesterday.
[08:41] <wgrant> But haven't retried since.
[08:43] <czajkowski> wgrant: was sure that was one of the resonas why gmb was setting up an Ec2 for uds lp clinic was it not working on precise just yet
[08:43] <jml> KeyError: 'STORM_CEXTENSIONS'
[08:44] <wgrant> Doing what?
[08:44] <wgrant> How old is the tree?
[08:44] <jml> I just pulled
[08:44] <jml> but I've forgotten everything I need to do to update
[08:44] <wgrant> make clean build, to be safe
[08:44] <jml> ah, ok.
[08:45]  * wgrant tries.
[08:51] <jml> Error: pg_config executable not found.
[08:51] <jml> I get that in the middle of a 'make build'
[08:53] <wgrant> Do you have launchpad-developer-dependencies installed?
[08:54] <wgrant> I shall return after dinner. Hopefully germanium will give me everything I need while I eat.
[08:56] <jml> wgrant: heh
[08:56] <jml> wgrant: ta
[08:56] <jml> wgrant: no, I don't. It seems to be broken.
[09:03] <jml> ah, you need python2.6-dev
[09:04] <jml> I've just got python2.6 from https://launchpad.net/~fkrull/+archive/deadsnakes
[09:10] <wgrant> jml: Yeah, I'll probably replace it with python-all-dev and co. once I check it functions without 2.6
[09:10] <wgrant> We mostly just use the default version, but some things still point at 2.6, I believe.
[09:12] <wgrant> Everything of note has been updated to just use the default, so it will hopefully work.
[09:13] <jml> coole.
[09:13] <jml> I'll keep hacking in my lxc for the moment.
[09:13] <wgrant> Probably better for your sanity anyway.
[09:21] <jml> yeah.
[09:30] <wgrant> Interesting
[09:30] <wgrant> pg_createcluster now fails if it's run in a nonexistent locale.
[09:30] <wgrant> dpkg doesn't notice.
[09:31] <wgrant> lifeless: Any objections to dropping !precise host support from /Running/LXC?
[09:31] <wgrant> The instructions are like half the size.
[09:32] <lifeless> +1
[09:32]  * wgrant mauls.
[09:54] <wgrant> jml: Just ran various tests successfully without 2.6, so I'll drop it from the deps.
[10:01] <jml> wgrant: yay
[10:28] <jml> wgrant: do you know why TestArchivePrivacySwitching is in LaunchpadZopelessLayer?
[10:28] <wgrant> jml: Probably because whoever wrote it was wrong.
[10:29] <jml> wgrant: heh.
[10:29] <wgrant> jml: It should be ZopelessDatabaseLayer or DatabaseFunctionalLayer, since it probably doesn't need librarian etc.
[10:29] <jml> wgrant: yeah, trying DFL now.
[10:29] <wgrant> The difference between those two is now pretty much just the permission model.
[10:29] <wgrant> Zopeless is still PermissiveSecurityPolicy
[10:30] <jml> ah cool.
[10:31] <jml> wgrant: how much work does "pretty much" hide?
[10:31] <wgrant> jml: Working out what FunctionalTestSetup etc. does that is different.
[10:32] <wgrant> I merged most of it in a large branch series in September, but am yet to obtain the courage to complete the merge.
[10:32] <wgrant> Becauze Zope testing setup stuff is somewhat intimidating.
[10:32] <wgrant> It's also not clear quite how it's best to do it.
[10:33] <jml> yeah.
[10:33] <wgrant> But I suspect an attribute on the test class to specify the security policy might work.
[10:33] <wgrant> s/work/not be as terrible/
[10:33] <jml> that's what I was thinking
[10:33] <jml> and then one by one change the test classes to do something better.
[10:34] <jml> I wonder if there's a better mechanism than attribute (subclassing maybe?)
[10:35] <wgrant> StupidLegacyTestCase? :)
[10:35] <jml> well, we need to separate concerns
[10:35] <jml> StupidLegacyPermissiveTestCase
[10:35] <wgrant> Heh
[10:36] <jml> actually, you could probably do something with testtools's `run_tests_with` thing.
[10:36] <jml>         publisher.prepareBreezyAutotest()
[10:36] <wgrant> That's actually not a terrible idea.
[10:36] <wgrant> Run away
[10:36] <jml> oh yeah, that needs the librarian
[10:36] <wgrant> It does, yeah.
[10:37] <wgrant> Because inserting fake LFAs is hard, I guess.
[10:37] <wgrant> It tries to upload chroots.
[10:39] <wgrant> It could be taught not to participate in such stupidity, though.
[10:40] <wgrant> I'm not sure if our test suite's antics are back to being hilarious rather than depressing yet.
[10:45] <jml> I'm guessing getPubSource has side-effects that belie its name
[10:45] <wgrant> Oh yes
[10:46] <wgrant> makePubSourcePlusSomeOtherBitsActually
[10:46] <wgrant> You can usually get away with the factory's makeSourcePackagePublishingHistory these days
[10:46] <wgrant> SoyuzTestPublisher is deprecated and new usage of it incurs wrath.
[10:49] <jml> oh
[10:49] <jml> that's nice
[10:49] <jml> ISTR the last time I tried this sort of thing the accepted wisdom was "use SoyuzTestPublisher because you'll never be able to get it right any other way"
[10:52] <jml> is there a safe way to use the Librarian in tests without using a layer that provides it?
[10:59] <lifeless> no
[10:59] <lifeless> the layer is a thin shim on the fixture now
[10:59] <wgrant> jml: The appropriateness of STP depends on the test.
[10:59] <lifeless> but you still need all the bits joined together
[10:59] <wgrant> You can sometimes use the FakeLibrarian.
[11:00] <wgrant> Translations uses it for something in like one test.
[11:02] <jml> If there were a safe way, then lots of test runs could be made a bit faster easily. I could, for example, switch this test to ZopelessDatabaseLayer and then just use that safe way to run this test with the librarian.
[11:02] <lifeless> zopeless is no cheaper than zopeful
[11:03] <jml> lifeless: I wasn't contending that point.
[11:03] <jml> ZopelessDatabaseLayer is heaps cheaper than LaunchpadZopelessLayer though.
[11:04] <jml> librarian, memcache and rabbit all take their toll.
[11:09] <cjwatson> I don't seem to have much luck with FakeLibrarian, usually.  Maybe I'm not smart enough.
[11:09] <cjwatson> I tend to get incomprehensible storm tracebacks.
[11:25] <jml> battery threat!
[11:30] <jml> https://code.launchpad.net/~jml/launchpad/narrow-commercial-celebrity/+merge/104236 up for review.
[11:30] <jml> rick_h_: poor chap, you always seem to end up with my sad offerings.
[11:30] <rick_h_> jml: hah, all good
[11:30] <jml> I have to go find electricity. Will be back sooner than you'd like.
[11:30] <czajkowski> and yet he comes back for more
[11:30] <czajkowski> cant be that bad
[11:31] <rick_h_> jml: ok, going to grab some grub, so will take me longer than you'd like :P
[12:00] <jml> ok. I'm back.
[12:02] <jml> rick_h_: are you far into reviewing that branch, because I thought of some cleanups that I can tack on to it.
[12:02] <czajkowski> jml: we have date/times now for the LP clinic at uds https://wiki.ubuntu.com/UDS-Q/LaunchpadClinic
[12:03] <rick_h_> jml: I'm peeking at it, but please go ahead and update and I'll get back to it in 10 then
[12:28] <jml> rick_h_: ok, finally done
[12:28] <rick_h_> jml, ok, working on another review atm, but will get to it shortly
[12:28] <jml> rick_h_: 30s per test run has a surprisingly strong negative effect on speed.
[12:29] <rick_h_> jml: tell me about it :/
[12:30] <wgrant> jml: I'm pretty sure it hasn't become worse since you defected. I guess you've just repressed the tramautic memories :(
[12:31] <jml> wgrant: oh, I'm sure that's the case.
[12:31] <StevenK> The brain does repress bad memories.
[12:31] <jml> otoh, the nice thing with working on LP is there's so much obvious stuff to do
[12:31] <jml> it's very hard to get stuck.
[12:31] <wgrant> Indeed.
[12:31] <wgrant> Indeeeeeeed.
[12:31] <wgrant> So much to delete.
[12:32] <wgrant> Like Translations, Answers, Blueprints.
[12:32] <wgrant> And Soyuz to rip out.
[12:32] <jml> or update, or fix, or refactor.
[12:32] <jml> yeah
[12:32] <jml> ripping out the buildmaster would be fun
[12:32] <jml> step 1, rationalize the transactions
[12:32] <wgrant> It, Soyuz and Translations have no business at all being in LP core.
[12:32] <wgrant> The others might have some justification.
[12:32] <jml> step 2, xmlrpc (or whatever) interface
[12:32] <jml> step 3, yoink!
[12:33] <wgrant> Yep
[12:33] <wgrant> It just turns into a process which bridges the LP and buildd XML-RPC interfaces.
[12:33] <jml> chunks of lp.codehosting could be ripped out pretty easily too.
[12:33] <wgrant> I'm likely to rip out lp.services.sshserver into a separate project in the next few months.
[12:33] <wgrant> As part of destroying poppy.
[12:33] <wgrant> It's mostly self-contained.
[12:33] <jml> wgrant: oh, I made lp:txsshserver once upon a time with roughly that intent
[12:33] <jml> wgrant: maybe you should take over that project when you do it?
[12:34] <wgrant> Maybe indeed.
[12:34] <jml> it has no users.
[12:34] <wgrant> All the better!
[12:34] <jml> hmm. maybe I killed it :\
[12:34] <wgrant> One thing I do like about Code(hosting) is that the architecture isn't entirely stupid, unlike say most of the rest of LP.
[12:34] <wgrant> apart from branchrevision.
[12:35] <jml> wgrant: aww shucks.
[13:03] <jml> is the a graph of LP LoC over time?
, but cjwatson had a better one of the delta
[13:04] <wgrant> I'm not sure how accurate ohloh's is.
[13:05] <rick_h_> heh, wasn't ready to seem my name up there in that
[13:06] <rick_h_> but as a re=me so it's ok :)
[13:07] <rick_h_> jml: so you're not removing the concept of commercial ppas, but this single getCommercialPPA helper then?
[13:07] <jml> rick_h_: that's right.
[13:08] <rick_h_> ok, cool
[13:08] <StevenK> ohloh's one tends to be out-of-date and imprecise
[13:08] <jml> rick_h_: if we remove the commercial concept entirely, well, this is half (hah!) the work
[13:08] <rick_h_> jml: just making sure I'm following, saw the sea of red but some bits left and wanted to make sure I was 'getting' it right
[13:08] <jml> :)
[13:08] <StevenK> jml: The Soyuz's team blood, sweat and tears (mostly tears) went into making IArchive.commercial!
[13:09] <jml> StevenK: sunk cost fallacy.
[13:09] <wgrant> Woah
[13:09] <jml> StevenK: Sorry, I meant to say that we really appreciate it and hope some day we can return the favour.
[13:09] <wgrant> Never seen someone brave enough to invoke that on LP before :)
[13:09] <StevenK> jml: Oh, I know it's a sunk cost, I'm just saying think of our tears. :-)
[13:09] <rick_h_> tears wash away easily with some soap and water...all good
[13:10] <StevenK> wgrant: You mean what I said?
[13:10] <wgrant> No, the sunk cost fallacy.
[13:10] <StevenK> Ah.
[13:10] <wgrant> It could be applied to harmlessly remove 90% of our functionality :)
[13:10] <rick_h_> how dare you use logic and management terminology in here! :)
[13:11]  * StevenK removes 90% of the JS, thereby removing the need for convoy or jsbuild.
[13:11]  * rick_h_ watches the site go boom!
[13:11] <StevenK> It already was earlier today.
[13:12] <rick_h_> phew, glad I missed it then
[13:12] <wgrant> Production thrice, qastaging once.
[13:12] <jml> wgrant: well, there you'd compare cost/benefit of deleting with cost/benefit of user migration
[13:12] <wgrant> Fun day.
[13:12] <rick_h_> ugh, what went kaput?
[13:12] <jml> oh, also, perplexing thing: https://code.launchpad.net/~jml/txsshserver/trunk (200); https://code.launchpad.net/txsshserver (404)
[13:13] <wgrant> jml: Deactivated project, probably.
[13:13] <jml> ah ok
[13:13] <wgrant> "This project is currently inactive"
[13:13] <jml> rick_h_: anyway, I don't have commit so if you approve of that branch please land it for me.
[13:13] <rick_h_> jml: ah ok will do
[13:13] <rick_h_> going to have to footnote you on my ec2 bill :P
[13:14] <jml> rick_h_: I left two LP instances running accidentally, I think to support some pair programming. I have a $300+ bill from last month.
[13:14] <rick_h_> ouch!
[13:14] <jml> wgrant: how come you are so low on ohloh?
[13:14] <wgrant> jml: Hm?
[13:15] <rick_h_> I'm constantly afraid of that. I have two of my own I keep running to have to keep thinking "hmmm, 2 ok, >2 doh!"
[13:15] <sinzui> wallyworld, got a bill for $1,500
[13:15] <sinzui> It ran for 45 days
[13:15] <rick_h_> oooh...45 days?!
[13:15] <wallyworld> sinzui: for ec2?
[13:15] <rick_h_> that must have been pre the large instances?
[13:15] <jml> wgrant: you don't appear on http://www.ohloh.net/p/launchpad/contributors
[13:15] <sinzui> yes
[13:15] <wallyworld> ah, my bill
[13:15] <rick_h_> I'd have thought 45 days would be higher
[13:15] <wgrant> jml: I'm probably on like the third page.
[13:15]  * wgrant hunts.
[13:15] <jml> wgrant: 2nd
[13:16] <rick_h_> when I see these start ups with 100s of ec2 servers I cringe at that monthly bill
[13:16] <wgrant> Ah, not too bad.
[13:16] <wgrant> I am the top committer of the last 12 months, though :)
[13:16] <StevenK> I think I'm on like the 6th page. :-(
[13:16] <sinzui> We can all run starry-eyed into the arms of canonistack
[13:16] <wgrant> Although sinzui is close behind.
[13:16] <jml> hmm.
[13:17] <rick_h_> sinzui: yea, are there instructions for that?
[13:17] <jml> I don't know how to get that report from ohloh
[13:17] <StevenK> sinzui: Sounds good to me. Except no one seems to care.
[13:17] <wgrant> jml: Code Analysis
[13:17] <wgrant> jml: You can click on people in the legend to turn them off.
[13:17] <wgrant> (ie. to dispose of PQM)
[13:17] <wgrant> I'm not quite sure how it picks who to show.
[13:17] <wgrant> Looks vaguely like the top 5 of the last year and then the top 5
[13:18] <wgrant> of all time
[13:18] <sinzui> me? I have done bugger all for 12 months. I am atrifying.
[13:18] <rick_h_> jml: so side curiousity here, is this how people are getting listed in the software center? They have a commercial ppa and that's listed out as apps in software center?
[13:19] <jml> rick_h_: yeah, that's right.
[13:19] <jml> rick_h_: but only for commercial (i.e. they cost money) apps
[13:19] <rick_h_> jml: right, the newish paid apps stuff
[13:19] <jml> yep
[13:20] <rick_h_> ok, just curious, wasn't sure how that stuff worked and this review has the brain thinking
[13:20] <wgrant> jml: Aren't the proprietary free apps also there?
[13:20] <wgrant> eg. Vendetta Online
[13:20] <wgrant> Or whatever that free one is
[13:20] <jml> this work we're doing with LP now is aimed at people being able to upload apps to developer.ubuntu.com and have them packaged and published to a PPA automatically
[13:21] <jml> wgrant: I don't know about proprietary free.
[13:21] <cjwatson> wgrant,jml: http://people.canonical.com/~cjwatson/tmp/loc.png is a currently-up-to-date graph of delta per commit.  But it's kind of hard to read; it looks mostly nice and negative but the net change over that time period is in fact +2755.
[13:21] <jml> wgrant: I know that libre+gratis goes to extras (or the archve)
[13:21] <wgrant> jml: I like to pretend that extras doesn't exist :)
[13:21] <jml> :)
[13:21] <wgrant> cjwatson: :(
[13:22] <jml> cjwatson: do you have a graph of the integral of that?
[13:25] <cjwatson> jml: that's ohloh's graph, isn't it?
[13:25] <cjwatson> I guess you might want zoomed in and zero-based
[13:25] <jml> oh yeah.
[13:25] <jml> I think I'll just hook up bzr & ggplot2 in my own spare time :)
[13:25] <StevenK> Some counter on lpqateam.c.c would be nice.
[13:25] <jml> what I want is a command that tells me my score.
[13:26] <rick_h_> haven't you heard, you need graphite graphs these days to be cool
[13:26] <StevenK> I just want to see if I'm negative.
[13:26] <rick_h_> with hourly commit points and fancy colored moving charts
[13:27] <rick_h_> and we all put them on a display on the wall over our desks
[13:27] <StevenK> rick_h_: Speak for yourself, hipster.
[13:27] <rick_h_> lol
[13:27] <rick_h_> I'm on LP, I think that disqualifies me for any hipster movements
[13:27] <StevenK> Haha
[13:28] <wgrant> Nah
[13:28] <wgrant> GitHub's too mainstream
[13:28] <rick_h_> when we get some BDD JS going then we'll chat about rushing house hipster
[13:28] <jml> StevenK: yeah, if I'm negative that's a good thing to know. But I also want to be able to compete with people
[13:28] <rick_h_> where's jono when you need some new achievement badges
[13:29] <rick_h_> "negative LoC leader for month of May"
[13:29] <StevenK> If we hook the LOC metric into Ubuntu Achievements, someone will get fired.
[13:29] <rick_h_> lol
[13:29] <jml> StevenK: how so?
[13:29] <StevenK> ... or I'll quit in disgust.
[13:30] <StevenK> jml: There's an implied :-P
[13:30] <cjwatson> jml: but, http://people.canonical.com/~cjwatson/tmp/loc-cum.png
[13:30] <jml> StevenK: oh, I just didn't (don't yet) get the joke.
[13:31] <jml> cjwatson: thanks!
[13:31] <StevenK> I'm waiting for my UI work to end on prod.
[13:31] <wgrant> I wonder how it changes if we filter out database/schema
[13:31] <wgrant> Since that's append-only.
[13:32] <StevenK> Then I can rip out 2,000 lines of stuff.
[13:33] <cjwatson> jml: (easy once I remembered 'smooth cumulative'.  gnuplot is ugly as sin but quick to hook trivial stuff up in.)
[13:33] <jml> cjwatson: ah cool.
[13:34] <wgrant> bzrlib + matplotlib ftw
[13:35] <jml> yeah. I've enjoyed the stuff I've done recently with R & ggplot2
[13:35] <wgrant> Enjoying R? I think you're doing it wrong.
[13:35] <jml> webulating graphs is too hard though
[13:35] <jml> i.e. taking a one-off graph made and turning into something that can be hit on the web and is always relatively up-to-date
[13:37] <jml> wgrant: the thing I really like is that it's really easy to use my data analysis again at a later point. Mostly my Python graphing stuff doesn't seem to work out like that.
[13:37] <wgrant> Yeah
[13:37] <jml> Maybe I should try that panda thing GvR posted on G+ about.
[13:37] <jml> also, R is actually pretty good for interactive mucking around with data
[13:38] <jml> even if it's rather poor considered as a language.
[13:39] <jml> distributionmirror_prober: is that a candidate for splitting out?
[13:40] <wgrant> Yes.
[13:40] <wgrant> It should in all probability be a separate database.
[13:40] <wgrant> The interactions with LP internals are minimal.
[13:40] <wgrant> But it should probably be deleted and replaced with an existing third-party solution
[13:41] <jml> ooh
[13:42] <jml> its tests are an affront.
[13:43] <jml> I'd like to fix them, but removing them & the code they test entirely would be much better.
[13:44] <wgrant> Exactly.
[13:45] <wgrant> Lots of Launchpad components like to pretend they're solving a unique problem.
[13:46] <wgrant> So stuff like that happens :)
[13:46] <jml> :)
[13:46] <jml> james_w: hello
[13:46] <james_w> hi
[13:46] <jml> I'm wondering whether I should make a celebrity team for which membership means "you can set commercial"
[13:47] <jml> or whether I should re-purpose the software_center_agent celebrity somehow
[13:47] <wgrant> Or add a field to distribution which permits it.
[13:47] <jml> wgrant: e.g. Distribution.commercial_team
[13:48] <jml> ?
[13:48] <wgrant> nasty_proprietary_software_people, but yeah :)
[13:48] <jml> hmm.
[13:49] <deryck> wgrant, hey.  I saw something in scrollback about lp being down for you guys.  are there incident reports for this?  or anything I can look at.
[13:49] <jml> I need a better name than either of them.
[13:50] <wgrant> deryck: https://wiki.canonical.com/IncidentReports/2012-04-26-LP-release-performance-issues covers the first two of the day's issues, the other one is in the hands of IS, I believe.
[13:50] <jml> 'commercial_admin' would be pretty good if it weren't already a heavily-loaded term
[13:50] <wgrant> Yeah
[13:50] <deryck> wgrant, thanks!
[13:50] <wgrant> deryck: Alternatively we can replace commercial with a shut_up flag that anyone can set, I guess.
[13:51] <wgrant> s/anyone/the archive owner/
[13:51] <wgrant> Bah
[13:51] <wgrant> jml: ^^
[13:51] <deryck> heh.
[13:51]  * deryck votes for shut_up flah, too, FWIW. :)
[13:51] <deryck> flag
[13:51] <wgrant> jml: I thought my team name was pretty catchy, though.
[13:51] <jml> bigjools seemed to dislike the idea
[13:52] <jml> wgrant: sure, it has zing. It could be easily misunderstood though.
[13:52] <rick_h_> abentley: ping, can you take a peek at this for me when you get settled? https://code.launchpad.net/~wallyworld/launchpad/revoke-access-delete-subscriptions-job/+merge/104198
[13:53] <abentley> rick_h_: Yes, I'll have a look at that.
[13:53] <rick_h_> abentley: want to make sure it's all celery approved, not sure about the any special needs/better ways of doing things for that.
[13:53] <rick_h_> thanks!
[13:53] <jml> wgrant: as it would read to me as "all of the propriety uploaders to d.u.c" rather than "the d.u.c bots"
[13:53] <wgrant> True, true.
[13:53] <james_w> jml, I'd lean towards re-using the celebrity, but wouldn't be against a field on distribution I don't think
[13:54] <jml> james_w: one thing about the celeb is that (I think) it's a Person not a Team
[13:54] <wgrant> jml: It can be either.
[13:54] <jml> wgrant: I mean that currently it is a Person.
[13:54] <wgrant> People are teams, war is peace, etc.
[13:54] <wgrant> Ah
[13:54] <jml> wgrant: I don't know what the fallout of changing it would be.
[13:55] <wgrant> It would break.
[13:55] <wgrant> I think.
[13:55] <jml> well, yeah, that's generally what we mean by "fallout of change"
[13:55] <wgrant> Since I believe the XML-RPC API may actually set up an interaction as it.
[13:55] <wgrant> Which won't work if it's a team.
[13:55] <wgrant> But I may be misremembering, and it just passes it in as arguments to horrid methods, in which case it might work.
[13:56] <wgrant> There's one easy way to find out...
[13:56] <jml> I'm more worried about how we use it on our side
[13:56] <jml> that's harder to co-ordinate.
[13:56] <wgrant> Howso?
[13:56] <wgrant> How do you use it on your side?
[13:56] <wgrant> I thought you mostly poked the xmlrpc-private API
[13:57] <jml> I don't know.
[13:57]  * jml looks
[13:58] <wgrant> Ah
[13:58] <wgrant> There's a single xmlrpc-private call, getOrCreateSoftwareCenterCustomer
[13:58] <wgrant> Rest must be through lazr.restful.
[13:58] <jml> yeah
[13:58] <wgrant> So, you could create a team, add the agent to it, then make that team the celeb.
[13:59] <rick_h_> jml: have a bug to tie the MP against please?
[13:59] <rick_h_> well guess there's not a lot of QA for this removed is there :/
[14:01] <jml> rick_h_: https://bugs.launchpad.net/launchpad/+bug/992622
[14:01] <_mup_> Bug #992622: getCommercialPPAs is not needed <tech-debt> <Launchpad itself:New> < https://launchpad.net/bugs/992622 >
[14:01] <jml> rick_h_: as you wish.
[14:02] <rick_h_> jml: yea, that ec2 land wants things to all be setup right, picky little thing. :) thanks. Landing now
[14:02] <jml> rick_h_: thanks! :)
[14:08] <jml> hmm
[14:09] <jml> I have to write this code somehow.
[14:11] <jml> I prefer the 'shut_up' field approach, but suspect that it'll be rejected as Whiggery.
[14:12] <jml> james_w: am probably going to start implementing it as field on Distro
[14:12] <wgrant> My vote goes to shut_up.
[14:12] <wgrant> I don't see a good reason to restrict it.
[14:13] <james_w> shut_up on archive, or subscription?
[14:13] <wgrant> Probably archive.
[14:13] <wgrant> But I'm not quite sure.
[14:13] <james_w> either way I think I prefer that too
[14:14] <james_w> assuming it's roughly similar in implementation time
[14:14] <sinzui> jcsackett, ping
[14:14] <james_w> no need for this to be special
[14:14] <jml> I guess one archive owner could use it to secretly upload evil stuff to a PPA without other owners finding out
[14:14] <jcsackett> sinzui: pong
[14:14] <jml> james_w: I think they are both similar and both fairly small.
[14:14] <wgrant> jml: Hm?
[14:14] <jcsackett> rick_h_: enjoying your first day of full reviewing? :-)
[14:14] <sinzui> jcsackett,  is there a card on the board that interests you?
[14:14] <rick_h_> jcsackett: wheeeeee
[14:14] <wgrant> jml: AIUI the flag would just control subscription notifications.
[14:14] <james_w> if it has to be available in the UI then it will probably be more work to implement, and be quite LOC-positive
[14:14] <jcsackett> sinzui: i was looking at banners without javascript.
[14:15] <wgrant> jml: "subscription" refers to packages from the archive, not upload notifications.
[14:15] <jml> wgrant: ah, not upload notifications.
[14:15] <wgrant> Upload notifications go to the uploaders, which are the owner and anyone with an ArchivePermission
[14:15] <sinzui> jcsackett, do you want to talk about it?
[14:15] <jcsackett> sinzui: yes. hangout?
[14:15] <sinzui> yes
[14:15]  * sinzui looks for headphones
[14:17] <jml> so, it would just be suppress_subscription_notifications or something to that effect.
[14:17] <jml> ok.
[14:18] <jml> I'm going to relocate to somewhere that serves food & has internet.
[14:18] <sinzui> jcsackett, I am in the google messenger  hangout
[14:19] <jcsackett> hm. it's telling me you're offline
[14:19] <sinzui> My head is
[14:19]  * sinzui tries again
[14:54] <rick_h_> abentley: thanks for checking that out, appreciate the assist
[14:54] <abentley> rick_h_: no problem.
[15:17] <jml> I haven't submitted a db patch since we switched to nodowntime stuff. what do I need to know?
[15:20] <jml> https://dev.launchpad.net/Database/LivePatching doesn't seem to mention anything about adding, removing or renaming columns
[15:27] <jml> james_w: so I'm thinking of doing this shut-up patch by re-purposing 'commercial' and then following up with a db patch to rename it.
[15:27] <jml> james_w:  thoughts?
[15:28] <jml> anyone?
[15:34] <rick_h_> jml: looking for the doc
[15:35] <rick_h_> my understanding is you need to have a MP against the devel-db branch and get it ok'd by db peeps (lifeless/etc) and then it has to land first
[15:35] <cjwatson> jml: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[15:36] <rick_h_> there you go and https://dev.launchpad.net/WorkingWithDbDevel
[15:36] <jml> that doc doesn't say anything about removing or renaming columns
[15:36] <cjwatson> adding columns comes under cold patches
[15:36] <jml> nor is there anything I can see that categorizes new columns as either 'hot' or 'cold'
[15:36] <jml> cjwatson: ah
[15:36] <cjwatson> by virtue of not being explicitly under hot patches
[15:37] <jml> right.
[15:37] <cjwatson> so it'll be a fastdowntime thing
[15:37] <jml> thanks.
[15:38] <cjwatson> if you're removing columns, you'll need to make sure that no appservers are using the old columns first via a nodowntime deployment (I don't know if there are stricter requirements beyond that)
[16:30] <jml> just got a weird error trying to run 'ec2 test': http://pastebin.ubuntu.com/960374/
[16:31] <jml> does the erstwhile Launchpad team hang out somewhere else these days?
[16:32] <rick_h_> sorry, no idea there
[16:33] <rick_h_> repeatable error? e.g. not temp bzr connection issue?
[16:33] <jml> I'm trying to repeat it now.
[16:33] <jml> just repeated it.
[16:33] <jml> it happens in the initial connection.
[16:34] <rick_h_> k, sec, pulling that branch ( was going to peek at it for review anyway) and I'll test it
[16:36] <cjwatson> jml: public IP problem again?  what does checkip.amazon.com say?
[16:36] <cjwatson> sorry, checkip.amazonaws.com
[16:36] <jml> heh, it might be because...
[16:37] <jml> cjwatson: yeah, that seems to be it.
[16:37] <cjwatson> when I was landing a branch from Millbank last week I hardcoded Millbank's external address in ec2test/account.py
[16:37] <jml> cjwatson: I'm actually in a pub tethered to my phone
[16:38] <rick_h_> what's the 'public ip problem'?
[16:38] <jml> cjwatson: but checkip says <IP_ADDRESS> and mumak.net (which I'm ssh'd into) says something else
[16:38] <jml> cjwatson: I'm angry enough to patch lp-dev-utils to have an option for that.
[16:38]  * jml hulks out
[16:38] <rick_h_> ruh roh
[16:39] <rick_h_> ok, well running fine here so glad it's something special
[16:42] <jml> rick_h_: thanks.
[16:42] <cjwatson> I have no idea why checkip thinks it's clever to honour X-Forwarded-For.
[16:43] <jml> Well, what is honour, if not an occasional rejection of the pragmatic?
[16:44] <cjwatson> We could use http://whatismyip.akamai.com/ instead
[16:45] <cjwatson> WFM
[16:46] <jml> me to
[16:46] <jml> oo
[16:47] <cjwatson> rick_h_: the problem is that amazon's checkip service is stupid and if you're connecting to it through an HTTP proxy it returns the address that the proxy sees (via the X-Forwarded-For HTTP header)
[16:47] <cjwatson> this is useless if you're trying to find the address amazon will see for you, since proxies are often on private networks
[16:47] <rick_h_> cjwatson: ah ok, and this is setup as the address you can ssh from to the new instance?
[16:47] <cjwatson> right
[16:47] <rick_h_> gotcha
[16:58] <rick_h_> bah, can't edit a review comment after the fact? oh well
[16:58] <rick_h_> jml: small note on my end, but yea the others will be better to go over things.
[16:59] <james_w> jml, +1 on repurposing commercial
[16:59] <james_w> jml, if we strip away the other meanings of it, rename it, and allow anyone to set it if they own the PPA then it works for us, is a pretty minimal change, and IMO reduces the maintainence burden by taking something special-purpose and arcane and makes it pretty obvious
[16:59] <james_w> rick_h_, looks like your comment on https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270 got truncated
[16:59] <jml> james_w: yeah. and we've actually got line count credit on this already from deleting getCommercialPPAs
[16:59] <rick_h_> james_w: well, I was going to say I'll invite people from the permissions/etc squad but then realized they were already up there and missed hitting delete before submitting
[16:59] <rick_h_> and I can't edit it back out, so I fail
[16:59] <james_w> rick_h_, cool
[17:04]  * jml has to go soon :(
[17:07] <jml> ok. this doesn't seem to actually *work*, but it's a start: https://code.launchpad.net/~jml/lp-dev-utils/public-ip/+merge/104273
[17:07] <jml> I have to go.
[19:09] <lifeless> flacoste: hiya
[19:10] <flacoste> hi lifeless
[19:14] <lifeless> flacoste: hows the sprint going ?
[19:24] <lifeless> bwah... deryck: around ? if so, could you put bug 901892 as the external board # on https://canonical.leankitkanban.com/Boards/View/14028616/101173433
[19:24] <_mup_> Bug #901892: bug search cache makes next/prev return old data <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901892 >
[19:26] <deryck> hi lifeless
[19:27] <deryck> lifeless, done
[19:33] <lifeless> deryck: thanks
[19:35] <jelmer> hi deryck, lifeless
[19:35] <deryck> hi jelmer
[19:35] <jelmer> lifeless: I'm wondering if it would make sense to kill the code review notification emails; they just seem to be noise at this point. Do you have any opinions on that?
[19:36] <jelmer> IIRC you brought it up a while ago, but I can find the relevant log at the moment to confirm.
[19:38] <lifeless> code imports ?
[19:39] <lifeless> yes, I proposed removing at minimum all the non-action ones (successes, initial-failures)
[19:39] <lifeless> I have no particular opinion about non-initial failures.
[19:41] <jelmer> It's probably easiest to remove both at the same time
[19:41] <jelmer> I've stopped paying attention to the non-initial failures, and I haven't seen anybody else use them.
[19:58] <lifeless> sure
[19:58] <lifeless> mpt: hoya
[19:58] <mpt> hi lifeless
[19:58] <lifeless> so, what questions are you and ev trying to answer with this mtbf thing ?
[20:12] <mpt> lifeless, for the MTBF specifically, the first question: (1) How reliable is Ubuntu?
[20:13] <mpt> For example: Is it more reliable than it was last week? Is it more reliable than the previous release? And how much of a difference would it make if all Ubuntu users had installed all updates?
[20:25] <sinzui> what is MTBF? mounted tabernacle bee floggers
[20:29] <lifeless> yes
[20:29] <lifeless> mpt: those are good questions
[20:29] <lifeless> mpt: I have one; how do we define reliable, and is it a definition users would agree with ?
[20:30] <mpt> lifeless, that introduces the issue that our definition of reliability will expand over time
[20:31] <mpt> lifeless, in Ubuntu 12.04 it is "programs other than the kernel don't crash"
[20:31] <mpt> In Ubuntu 12.10 it may be something like "programs (including the kernel) don't crash, and don't hang for more than 20 seconds"
[20:33] <mpt> Depending on time and difficulty, it may also include other kinds of errors: package installation failures, debconf prompts, etc
[20:35] <mpt> So, one thing we've discussed is keeping track of when we started recording error type, to fairly answer questions like: "Is Ubuntu 13.04 more or less reliable than Ubuntu 12.10, using the same standards that we were using for Ubuntu 12.10?"
[20:36] <mpt> otherwise each successive release would seem less reliable than the last, even if it's more reliable. :-)
[20:37] <mpt> lifeless, but there will always be swathes of problems that aren't caught in an automated way, e.g. "this program thinks it copied all these files but it didn't".
[20:38] <mpt> And a user might classify that under "reliability".
[20:39] <mpt> If a test suite is the fence at the top of the cliff, Whoopsie and Daisy are the ladies with pens and clipboards standing at the bottom.
[20:44] <lifeless> mpt: I like that image
[20:45] <lifeless> mpt: so, are you factoring in time in your equations? And how?
[20:48] <mpt> lifeless, no, we'd completely overlooked it
[20:49] <mpt> If by "time" you mean "uptime"
[20:49] <mpt> The current formula implicitly assumes that every machine is running 24/7
[21:03] <lifeless> mpt: perhaps the client could report TSLF in each report, or some approximation thereof.
[21:06] <mpt> lifeless, I think it will have to, yes. Which means we run the risk that the system clock changed in the intervening period, but oh well.
[21:06] <lifeless> mpt: that should be rare though
[21:06] <lifeless> mpt: and rare events should be discarded as outliers
[21:07] <mpt> I suppose system clock adjustments will be roughly normally distributed anyway :-)
[21:19] <david0rk> hi all
[21:20] <david0rk> anyone on?
[22:22] <david0rk> nevermind.  I figured out using a bit of common sense and tinkering.   BAZAAR IS AWESOME!
[22:23] <SpamapS> hrm, I want to make sure I understand. bug #915505 means we can't use bzr builder format 0.4, right?
[22:23] <_mup_> Bug #915505: bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split' <launchpad-buildd:Triaged> <Open Sesame: libaccounts-glib:New> < https://launchpad.net/bugs/915505 >
[22:23]  * SpamapS is sad, that would let him automate stable releases building into a PPA
[22:29] <bac> hi lifeless
[22:35] <jelmer> SpamapS: yes
[22:36] <SpamapS> jelmer: and will LP have to be migrated to precise before that works?
[22:36] <jelmer> SpamapS: no, it will just need to be updated to a newer python-debian or we can update bzr-builder to support the older python-debian.
[22:36] <SpamapS> ah
[22:38] <jelmer> SpamapS: the fix for bzr-builder would be trivial, it's mostly the management around it to get it deployed to the builders that's more complicated.
[22:41] <SpamapS> Will probably be easier to just automate my packaging branch to have a new debupstream every time I commit to my stable branch
[22:42] <SpamapS> but, thats a pity, as 'latest-tag' is really cool
[22:43] <lifeless> bac: hi there
[23:04] <aquarius> I have a program, not of my creation, which calls launchpadlib. Launchpadlib, if you've not been authed to use LP, opens up LP in a browser and then blocks, waiting for you to auth the token. Is there some envar or similar I can set so that launchpadlib will just fail that request instead because it's not being run interactively?
[23:07] <cjwatson> aquarius: It uses the webbrowser module in Python's standard library, which honours BROWSER, so you could set that to ... err, something appropriate
[23:07] <aquarius> aha! sneaky :)
[23:08] <cjwatson> Not entirely sure how to make that fail immediately rather than spinning.
[23:08] <StevenK> export BROWSER=/bin/false ?
[23:08] <StevenK> That might be a little mean.
[23:08] <aquarius> I shall see if it works :)
[23:08] <cjwatson> I don't think that will work; webbrowser will notice the non-zero exit code and fall back to its next option, as I read it.
[23:09] <cjwatson> But /bin/true might work.
[23:09] <cjwatson> Hopefully you'll get EndUserDeclinedAuthorization.
[23:10] <cjwatson> I don't see another way to control it in an entirely different process.  If you can modify the program then you can pass in a different authorization_engine.
[23:11] <cjwatson> You might have to write a miniature browser that actually interacts with the URL it's given and presses the Decline button or whatever it's called.
[23:11] <aquarius> doesn't seem to honour BROWSER, afaict :(
[23:11] <wgrant> You won't get a button -- you'll be redirected to the login page.
[23:11] <aquarius> ah, I'll try the /bin/true trick :)
[23:11] <cjwatson> Really?  It's right there in webbrowser.py.
[23:12] <cjwatson> Mm, maybe launchpadlib will just think you haven't got round to logging in and deciding yet. :-(
[23:12] <aquarius> that's what happens
[23:13] <aquarius> no browser opens (no problem there), but then lplib just sits about waiting for me to finish authing.
[23:13] <aquarius> darn.
[23:13] <aquarius> and I can't see how to get out of that code, either
[23:13] <cjwatson> Are you trying to do something headlessly?
[23:13] <aquarius> yep
[23:13] <aquarius> specifically, run the test suite for quickly
[23:14] <cjwatson> That sounds like a bug in the test suite, then.  Surely it shouldn't fail without a Launchpad login.
[23:14] <cjwatson> (Or hang.)
[23:14] <aquarius> it *is* a bug in the test suite
[23:15] <aquarius> but the test suite's a terrifying mass of shell scripts which I do not have time to entirely rewrite from scratch :P
[23:15] <aquarius> so I was hoping for a semi-quick fix to make the tests fail, rather than just hang indefinitely :)
[23:16] <cjwatson> Quickest fix would be to give them a login someho. :-)
[23:16] <cjwatson> *somehow
[23:16] <aquarius> that's approach number 2 if I can't find a way to do this, which is fractionally vanishingly more proper a solution :)
[23:17] <aquarius> and I don't think this is doable, annoyingly enough. Ah well.
[23:17] <cjwatson> I thought bribing didrocks was the traditional answer to quickly problems, anyway
[23:18] <aquarius> s/didrocks/mterry/ in this particular case, and he said "yeah the test suite is weird, feel free to just put in a separate test which is not tied to it" :-)
[23:18] <aquarius> so I have plenty of get-out clauses
[23:19] <aquarius> I just thought I'd try and do things properly (well, sorta) rather than super-hackily for once, and lo! I am thwarted. there is a lesson here :)


[06:04] <highvoltage>  /join #kubuntu-devel
[06:04] <highvoltage> (oops)
[20:00] <njin> hallo, there's a dev chan for edubuntu ?
[20:01] <stgraber> nope, we use this one
[20:03] <njin> ok, thanks stgraber, I suggest to Giovanni Tornatore this channel, so he can ask here for betters explanations of the bug he encounter testing Edubuntu.
[20:34] <weljor> stgraber
[20:34] <weljor> hello!
[20:34] <stgraber> weljor: hey
[20:36] <weljor> I have installed Edubuntu amd64 on virtualbox. The backports is enabled! is correct
[20:37] <stgraber> backports have been enabled by default on all Ubuntu flavours for the past 2-3 releases. The source is enabled but the system won't install backported packages unless you specifically ask for it (by specifying the version you want)
[20:42] <weljor> stgraber: thanks!
[20:49] <weljor> stgraber: another question>  On the session gnome-fallback with automatic log in, is appeared the bar of launched of unity. With log out this bar has disappeared! this is a bug?
[20:50] <weljor> stgraber: another question>  On the session gnome-fallback with automatic log in, is appeared the bar of launched of unity. With log out this bar has disappeared! this is a bug?
[20:52] <highvoltage> weljor: you get a unity panel on the gnome session?
[20:53] <highvoltage> (it does sound like a bug)
[20:55] <weljor> highvoltage: appeared the bar of the unity with the down bar!
[20:56] <weljor> highvoltage: with log out and log in this bug is not found!
[21:00] <weljor> highvoltage: if it persists, I report this bug  of gnome-session-fallback!
[21:05] <highvoltage> weljor: ok, I'll check it out after a sync too
[21:06] <highvoltage> weljor: and btw welcome to edubuntu :)
[21:08] <weljor> highvoltage: thanks!
[21:11] <weljor> highvoltage: good evening :)


[08:00] <Oriyon>  is it normal for transmission client  to use 37+ mb ram  in sleep mode?  i installed qbittorrentand its usage is 86+ mb .    OS is ubuntu-mate 18.04
[08:01] <Oriyon> https://i.imgur.com/bMUzr23.png
[08:01] <Oriyon> screenshot
[08:20] <gnugr> Oriyon: can you test it with GTK interface client?
[08:21] <Oriyon> yes
[08:21] <gnugr> apt-cache search bittorrent
[08:22] <gnugr> will show you all clients
[08:22] <Oriyon> ok
[08:24] <Oriyon> yeah..
[08:24] <Oriyon> i see the whole list
[08:25] <gnugr> bittorrent-gtk
[08:26] <Oriyon> yeah.
[08:26] <Oriyon> there is another too..
[08:26] <gnugr> install it and test the RAM
[08:27] <Oriyon> ok..doing it now
[08:27] <gnugr> any other also must be better
[08:27] <gnugr> better than qbittorrent
[08:27] <Oriyon> yeah
[08:36] <Oriyon> yeah..its lighter and clean.. working fine..
[08:43] <Oriyon> UM 18.04  is fast despite higher in ram usage than previous version.. i think new latest mate is more functional and polished
[08:46] <alkisg> Try purging snapd to save ram :)
[08:50] <Oriyon> cool..
[12:56]  * karnemelk growls at systemd-udevd
[21:41] <Lantizia> Hey, is it meant to be a simple job installing ubuntu mate 18.04 on a MacBook Pro?
[21:42] <Lantizia> Because I tried with 16.04 back in jan/feb and found when you boot the usb pen (e.g. writing the amd64 iso to it) - you get a desktop/installer which doesn't seem to want to recognise the trackpad/keyboard
[21:42] <Lantizia> And now with 18.04 it is exactly the same
[21:43] <amaranth13> I was hoping someone could help me with an 'unknown monitor' issue, I'm not completely new to Ubuntu but this is over my head.
[22:12] <sixwheeledbeast^> ask away someone may know
[22:13] <jnewt> how do i change my de to cinnamon?   i had it working on 16.04, but after upgrading to 18.04 i'm now back to mate.  i've reinstalled cinnamon, but it goes directly to mate on boot, with no option to select anything different.
[22:15] <amaranth13> I have a radeon 2400 (I know super old) and "lspci -nnk | grep -i vga -A3" tells me I'm running radeon drivers. But the 'Display' settings says I'm running an unknown VGA-0 and will only let me do 1024 x 768
[22:19] <Guest74978> Hi, I have a problem with my update of Ubuntu, the message is the next: time
[22:24] <Guest74978> E:The repository 'http://ftp.tecnoera.com/ubuntu bionic Release' does not have a Release file., W:Updating from such a repository can't be done securely, and is therefore disabled by default., W:See apt-secure(8) manpage for repository creation and user configuration details., E:The repository 'http://ftp.tecnoera.com/ubuntu bionic-updates Release' does not have a Release file., W:Updating from such a repository can't be done
[22:24] <Guest74978> securely, and is therefore disabled by default., W:See apt-secure(8) manpage for repository creation and user configuration details., E:The repository 'http://ftp.tecnoera.com/ubuntu bionic-backports Release' does not have a Release file., W:Updating from such a repository can't be done securely, and is therefore disabled by default., W:See apt-secure(8) manpage for repository creation and user configuration details., E:The
[22:24] <Guest74978> repository 'http://ftp.tecnoera.com/ubuntu bionic-security Release' does not have a Release file.