[00:00] <poolie> hm
[00:00] <poolie> if i change buildrecipe into an importable module so that i can test it...
[00:00] <poolie> that seems to have a fair risk of breaking something during deployment
[00:18] <lifeless> yes
[00:18] <lifeless> its also an entirely separate project
[00:18] <poolie> well
[00:19] <poolie> i would like to add automatic tests for my changes
[00:19] <lifeless> just something to be aware of
[00:19] <poolie> i guess i could add a separate landing to just make it testable
[00:19] <poolie> it seems like a high risk change so perhaps i'll just do without
[00:25] <wgrant> lifeless: Thanks.
[00:25] <wgrant> Still extremely slow, but it works.
[00:25] <wgrant> lifeless: What's the production rabbit status?
[00:25] <wgrant> lifeless: And are we going to persist with rsync-based fallback, or have a disk2amqp daemon?
[00:26] <wgrant> s/daemon/cronjob/, if you like.
[00:33] <lifeless> wgrant: cron job
[00:33] <lifeless> wgrant: plumbing written, just need a glue project to pull it all together (datedir repo on one hand, amqp on the other)
[00:33] <lifeless> wgrant: see oops-datedir-repo 0.0.10
[00:33] <wgrant> We should also ensure that the config name and tree base and script name are in the OOPSes, and then nuke all our OOPS configs :)
[00:34] <wgrant> Ah, excellent!
[00:34] <lifeless> prod rabbit is pending firewalls and tuolumne and nagios etc
[00:34] <lifeless> I've an rt up for migration to this including moving to a shared local-oops dir for all servers
[00:34] <wgrant> Great.
[00:35] <lifeless> beuno is champing at the bit to get this for u1 ;)
[00:35] <spm> i think the firewall's been done. was some chatter around that recently.
[00:36] <beuno> YES
[00:36] <lifeless> looks like it
[00:36] <wgrant> We also need a better way to handle rabbit passwords.
[00:36] <wgrant> Currently they're in the LP configs, which won't really do.
[00:36] <lifeless> so yes, we're ready to receive prod oopses over rabbit when the rest of the bits come together
[00:36] <wgrant> We probably need to read them from some other file.
[00:36] <lifeless> whats the issue ?
[00:37] <wgrant> Configs are widely accessible, and the rabbitmq instance is accessible from more than just production LP servers.
[00:37] <lifeless> you mean 'someone could connect and either consume or inject inappropriate messages' ?
[00:37] <wgrant> yes.
[00:38] <lifeless> so, moving oops-tools to its own box will help there
[00:38] <wgrant> Indeed.
[00:38] <lifeless> also we need to make sure the lp rabbit user has narrow perms
[00:38] <wgrant> But we should be treating our message queue like we treat our DB, I think.
[00:38] <lifeless> I haven't checked on that
[00:38] <wgrant> Good luck with that...
[00:38] <wgrant> How do you propose to do that?
[00:39] <wgrant> It basically needs to be able to write to everything.
[00:39] <lifeless> not at all
[00:39] <wgrant> And eventually read lots of things too, probably.
[00:39] <lifeless> write to oopses, create and write to longpoll.*, read from nothing, admin nothing.
[00:39] <lifeless> (today)
[00:39] <lifeless> thats pretty narrow
[00:39] <wgrant> Today.
[00:39] <lifeless> and as it changes, we can change it.
[00:39] <lifeless> bbs
[00:42] <poolie> lifeless, i commented on https://code.launchpad.net/~mbp/launchpad/bug-width/+merge/80161
[00:45] <poolie> wgrant: do you have any idea how buildrecipe gets installed, or where it gets renamed to buildrecipe.py?
[00:45] <StevenK> It's probably contained in lp-buildd
[00:45] <StevenK> So the build machinery of lp-buildd likely renames it
[00:46] <poolie> and that's not in the lp tree?
[00:46] <poolie> apparently not public ?
[00:46] <StevenK> It is, lib/canonical/buildd
[00:46] <wgrant> poolie: I don't think it actually does get renamed.
[00:47] <wgrant> [sourcepackagerecipemanager]
[00:47] <wgrant> buildrecipepath = /usr/share/launchpad-buildd/slavebin/buildrecipe
[00:47] <poolie> StevenK: i don't see anything in there that renames it
[00:47] <wgrant> argv[0] might be buildrecipe.py, but I think it's a lie.
[00:48] <poolie> yes!
[00:48] <poolie> just realized the same thing
[00:48] <poolie> :/
[01:11] <poolie> StevenK: hi
[01:12] <poolie> you don't need to write a lep for my sake
[01:12] <poolie> just a 'i'm planning to do X' on the bug would be ince in general though
[01:27] <poolie> short review on https://code.launchpad.net/~mbp/launchpad/884997-rusage/+merge/80971please anyone?
[01:57] <wgrant> lifeless: Did you change the uppercasing rule part-way through yesterday?
[01:57] <wgrant> Some of the hashes are allcaps, some are not.
[01:58] <lifeless> in the db ?
[01:58] <lifeless> or as reported to users? the latter is hashlib variations
[01:58] <wgrant> DB, I assume.
[01:58] <wgrant> It's in the reports.
[01:58] <lifeless> hmm, odd. Possibly dboopsloader needs a fix too.
[01:58] <lifeless> I shall check.
[01:59] <wgrant> Ah
[01:59] <wgrant> Could be.
[02:01] <lifeless> yeah, from_pathname needs a fix
[02:02] <lifeless> cowboyed
[02:02] <lifeless> [02:02] <lifeless> --- src/oopstools/oops/models.py        2011-10-31 02:07:24 +0000
[02:02] <lifeless> +++ src/oopstools/oops/models.py        2011-11-02 02:02:03 +0000
[02:02] <lifeless> @@ -476,6 +476,7 @@
[02:02] <lifeless>          oopsid = parsed_oops.get('id')
[02:02] <lifeless>          if oopsid is None:
[02:02] <lifeless>              raise OopsReadError('Not a valid OOPS report')
[02:02] <lifeless> +        parsed_oops['id'] = parsed_oops['id'].upper()
[02:05] <wgrant> Thanks.
[02:08] <wgrant> lifeless:        1 https%3A//launchpad.net/ubuntu/%2Bsource/oops/1.5.23.cvs-5.1/%2Bbuild/390896/%2Bindex (BinaryPackageBuild:+index)
[02:08] <wgrant>         OOPS-48d0191b7ac2d3136e4bd47d385fceb7
[02:08] <wgrant>        1 https://launchpad.net/ubuntu/+source/oops/1.5.23.cvs-5.1/+build/390896/+index (BinaryPackageBuild:+index)
[02:08] <wgrant>         OOPS-2131AU23
[02:08] <wgrant> New URLs are excessively URL-encoded.
[02:17] <lifeless> I was afrait of that
[02:17] <lifeless> I think I mentioned it
[02:18] <lifeless> probably need an LP change - I suspect its emitting them as unicode
[02:52] <poolie> is this pqm rejection lp's way of telling me you're only taking rc fixes?
[02:52] <poolie> no
[03:01] <wgrant> poolie: It's because we're in testfix.
[03:01] <poolie> and is that advertised anywhere?
[03:01] <StevenK> No, because PQM sucks.
[03:02] <poolie> i thought people used to put it in the topic here or something
[03:02] <poolie> anyhow, np, just glad it's not my branch
[03:27] <wgrant> lifeless: Around?
[03:29] <lifeless> yas
[03:30] <wgrant> lifeless:   File "/srv/lp-oops.canonical.com/cgi-bin/lpoops/src/oopstools/oops/models.py", line 309, in _get_oops_tuple
[03:30] <wgrant>     for key, value in req_vars:
[03:30] <wgrant> ValueError: need more than 1 value to unpack
[03:30] <wgrant> Broken by a ['field.blob']
[03:30] <wgrant> Without a value.
[03:30] <wgrant> Assume ''?
[03:31] <lifeless> ugh
[03:31] <lifeless> also win
[03:31] <lifeless> so that needs two bugs
[03:32] <lifeless> a) yes we should handle that
[03:32] <StevenK> I thought that was already done
[03:32] <lifeless> and b) we shouldn't be generating that
[03:32] <lifeless> also c) req_vars should be a dict
[03:32] <StevenK> I remember reviewing something that did that
[03:32] <lifeless> but there is a bug on that lready
[03:32] <lifeless> StevenK: urls
[03:32] <lifeless> StevenK: / encodings
[03:32] <StevenK> Not everything has a URL
[03:33] <StevenK> What do you do for script OOPS
[03:36] <wgrant> lifeless: Are you fixing the immediate issue, or should I?
[03:45] <lifeless> StevenK: I know
[03:46] <lifeless> wgrant: please do
[03:47] <wgrant> It even works.
[04:14] <StevenK> OOPS summaries twice in one day?
[04:14] <wgrant> Yes, the old ones were wrong.
[04:14] <wgrant> And today's are of particular interest.
[04:17] <wgrant> lifeless: Is there a branch for your cowboy?
[04:17] <lifeless> not yet
[04:18] <lifeless> if you're doing one, roll this in
[04:18] <wgrant> Was about to ask you to do the same :)
[04:18] <lifeless> I can later
[04:19] <wgrant> Also tempting to upper() the oopsids that were imported badly.
[04:19] <lifeless> it would make them accessible
[04:19] <lifeless> the oops table is a bit big to do it without date constraints
[04:19] <wgrant> I planned to restrict to the last few days.
[04:26] <wgrant> All seems happy now.
[04:43] <poolie> is lp out of testfix?
[04:43]  * StevenK becks
[04:43]  * StevenK grumbles at his keyboard
[04:44] <wgrant> spm: Can you check if pigeonpea and pilinut need cleaning?
[04:44] <spm> yup
[04:45] <wgrant> lifeless: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1517/steps/shell_6/logs/summary looks possibly relevant to you
[04:46] <spm> there's a bunch of oldish rabbits still running
[04:46] <spm> only on pilinut tho
[04:46] <spm> pigeonpea looks clean
[04:46] <wgrant> Does pigeonpea have any old pid files in /var/tmp?
[04:47] <lifeless> no old appserver processes ?
[04:47] <spm> buildbot@pigeonpea:~$ ls /var/tmp/*.pid | wc -l
[04:47] <spm> 111
[04:47] <spm> maybe....
[04:48] <spm> nothing running as BB, just the slave itself. no old processes running.
[04:48] <spm> ^^ pigeonpea; all that applies to.
[04:50] <spm> should I assume those pids should be rm'd?
[04:50] <lifeless> pleas
[04:50] <lifeless> e
[04:50] <wgrant> Yup.
[04:50] <spm> ugh. pilinut is just as dirty
[04:51] <spm> any objections if I shutdown BB on pilinut and clear out the running rabbits
[04:51] <StevenK> Do eet
[04:51] <wgrant> No need to shut it down, but sure.
[04:51] <wgrant> No build, so shutting it down is fine.
[04:52] <spm> just to make it easy to clear out everything
[04:52] <wgrant> What, kill all processes owned by the user?
[04:52] <spm> yup
[04:52] <spm> well. more making sure I don't clobber the BB process itself hard.
[04:53] <StevenK> It deserves it, kill it anyway
[04:53] <spm> huh. there's 3 pgbouncers in there as well
[04:53] <spm> was
[04:53] <spm> pilinut cleaned; pigeonpea cleaned
[04:54]  * StevenK forces a devel builkd
[04:54] <StevenK> s/k//
[04:55] <wgrant> Thanks spm.
[04:55] <spm> np
[05:02] <StevenK> poolie: Your branch should be fine to land now
[05:02] <poolie> thanks
[05:07]  * StevenK sets lp-oops on fire.
[05:07] <StevenK> Perhaps SSO is to blame.
[05:07] <wgrant> StevenK: What's up?
[05:09] <StevenK> Forgetting the query string when logging in.
[05:09] <wgrant> That's apache-openid
[05:09] <wgrant> We should work around it by not using the query string.
[05:09] <wgrant> This isn't 1990 :)
[05:15] <jtv> wgrant: kindly refrain from ridiculing as ancient history a year that I used to look forward to as the wondrous future.
[05:16] <wgrant> Bah
[05:16] <wgrant> It predates me by a year, therefore it is ancient history :)
[05:16] <StevenK> Bwaha
[05:16] <jtv> Insolent whippersnapper.
[05:16] <jtv> This does illustrate why my quiz team lost that crucial point a few weeks back.
[05:16] <jtv> The question: name the four horsemen of the Apocalypse.
[05:17] <jtv> I shouted “Ronnie, Paul” etc. but whispered the real names to the teammate who was doing the writing.
[05:17] <jtv> He dutifully, but not altogether correctly, noted down:
[05:17] <jtv> Hunger
[05:17] <jtv> War
[05:17] <jtv> Dath
[05:17] <jtv> *Death
[05:18] <jtv> Insolence
[05:18] <jtv> I took him to task about it afterwards, after we'd lost by 1 point.  His defense: “I'm British.  To us, Insolence *is* a horseman of the apocalypse!”
[05:19]  * StevenK is trying to remember the four horsemen as according to Good Omens
[05:19] <jtv> Hunger, War, Pestilence, Death, and Ronnie who left before they became famous.
[05:21] <jtv> (Let's not give away the rest; there may be people here who haven't read it yet :)
[05:22] <StevenK> No, it's Pollution, since Pestilence retired in 1963 following the discovery of pencillin.
[05:24] <jtv> Damn you, Sir Alexander Fleming!
[05:25] <jtv> (Why do I remember the name?  Because the anniversary of his death was a few weeks ago, on quiz night.  It pays to look these things up.)
[05:28] <jtv> This just in: IPCC announces the floods in Thailand were caused by Global Warming, _not_ as a naïve reader would deduct from looking at the actual numbers, from the reservoirs failing to run off excess water throughout the rain season.
[05:29] <jtv> To understand these announcements better, replace “Science” with “God” and variants of “Climate Change” with “Satan.”
[05:30] <nigelb> I'm apparently expiring from 3 teams almost at the same time :/
[05:30] <nigelb> Yay launchpad spam
[05:30] <jtv> Shouldn't have joined them all in the same week.  :)
[05:31] <nigelb> Yeah, regrets.
[05:32] <jtv> Funny really: apparently team memberships expire, but when we wonder if untended membership _requests_ should expire, everyone's up in arms!
[05:33] <nigelb> heh.
[05:36] <nigelb> I want to change the lies in the expiry warning email.
[05:36] <nigelb> Or a way to say "Hey, I dont care, let me expire
[05:36] <nigelb> "
[05:37] <nigelb> If anyone else does it, I'll buy them a drink :)
[05:40] <jtv> nigelb: I must warn you about one subtlety in Launchpad, and one in the real world.
[05:40] <wgrant> jtv: Well, team memberships expire when the team admins want them too.
[05:41] <wgrant> s/too/to/
[05:41] <jtv> In Launchpad, where we say “person,” that person can also be a team.
[05:41] <jtv> And in the real world, champagne qualifies as a drink.
[05:41] <jtv> wgrant: that explains, thanks.
[05:42] <wgrant> We don't just expire them by default, so you can't use that as an argument for expiring requests :)
[05:42] <wgrant> by default
[05:45] <poolie> jtv, you're feisty today
[05:45] <jtv> hi poolie!
[05:52] <jtv> night StevenK
[05:56] <nigelb> jtv: hah.
[05:59] <jtv> nigelb: soooo… you just committed yourself to something that can be stretched to buying the entire team champagne.  On the bright side, that might make the search for a volunteer a little easier.  :)
[05:59]  * nigelb whistles
[06:30] <wgrant> Our tests are crap :(
[06:36] <spm> wgrant: so. write a test to test the crapness of our tests. problem solved. /me cross arms. nods.
[06:38] <wgrant> Also, bugtasks are the bane of my existence.
[06:54] <nigelb> wgrant: I'd argue its not bugtasks, but launchpad itself :P
[06:55] <wgrant> Nah, most Launchpad stuff is fixable without incredible migration costs.
[06:56] <wgrant> The existence of bugtasks is not.
[07:09] <poolie> ok, good night all
[07:09] <wgrant> Night poolie.
[08:17] <jtv> Reviewer needed for small & simple change!  https://code.launchpad.net/~jtv/launchpad/orderingcheck-unicode/+merge/80987
[08:18] <rvba> jtv: I can do it ;)
[08:18] <jtv> So you can!  Thanks.  :)
[08:19]  * rvba likes Unicode stuff; yummy.
[08:20] <stub> Spoken like a man with an umlaut
[08:30] <wgrant> Evening stub.
[08:31] <stub> Yo
[08:32] <jtv> Hi there stub — did you go back home?
[08:34] <jtv> Also, AFAIK Raphaël does not have an Umlaut; it's a different diacritical mark that happens to look the same (unless you're Hungarian I believe, in which case you use both for their respective purposes).
[08:34] <jtv> Ah: diaeresis, that's the word.
[08:34] <jtv> I think.
[08:35] <rvba> True, Umlaut != Diaeresis.
[08:36] <nigelb> All you pedantics :P
[08:36] <jtv> An Umlaut transforms one vowel into another (a bit like the vowel changes in English, actually); this one separates two consecutive vowels, to show that they are in separate syllables.
[08:37] <jtv> Nobody bothers with them now, but a few decades ago you'd still find the same mark in English: “coöperate”
[08:37] <jtv> (To show that it's co-op-er-ate, not coop-er-ate)
[08:38] <wgrant> stub: We ran into some slightly disturbing query speed issues yesterday. On qastaging, https://pastebin.canonical.com/55125/ takes <10ms to EXPLAIN ANALYZE, but 300-700ms to actually execute. On DF, it executes in <10ms too. It evaluates to [(1,)], so it's presumably not just terrible output formatting speed...
[08:38] <jtv> wgrant: too late.  I chased him off.
[08:38] <wgrant> Curses.
[08:38] <jtv> (This suggests he probably didn't go back home.    Thanks rvba
[08:40] <rvba> np
[08:44] <nigelb> jtv: scarce resources?
[08:44] <jtv> Clean water, food, etc.
[08:45] <jtv> Even in areas that aren't affected, shops have found it difficult to keep stocks up.
[08:45] <nigelb> oh.
[08:50] <bigjools> morning
[08:51] <nigelb> Morning bigjools!
[08:52] <adeuring> good morning
[08:54] <jelmer> g'morning
[08:56] <lifeless> 'lo
[09:11] <lifeless>  4 / 1081  RootObject:+login
[10:28] <jelmer> hmm, this is odd. one of my pending builds has an estimated start and finish time in the past. is that possible?
[10:33] <jtv> Any reviewers out there?  I need to leave soon but I have a largish branch up for review: https://code.launchpad.net/~jtv/launchpad/bug-884649-branch-1/+merge/80988
[10:36] <bigjools> jtv: I'll take it
[10:36] <jtv> Thanks!
[10:40] <bigjools> jtv: why all the new tests?
[10:41] <jtv> bigjools: so we won't need to iterate through all the possibilities in the integration tests.
[10:41] <jtv> This is stuff that couldn't be tested in isolation before.
[10:41] <bigjools> ok
[10:43] <bigjools> jtv: approved
[10:45] <jtv> Thanks.  That was fast!
[11:34] <bigjools> can I bug someone for a review please? https://code.launchpad.net/~julian-edwards/launchpad/cancel-build-bug-173018-ui-part4/+merge/80997
[11:47] <jtv> bigjools: least I can do.
[11:49] <jtv> bigjools: I guess the “Cancel build” link takes you to a confirmation form (at +cancel)?
[11:52] <bigjools> jtv: correct
[11:53] <jtv> I swear I don't remember a thing about menu links.  I thought a link wouldn't show up in menu.links if its "enabled" condition said it was disabled.
[11:57] <bigjools> jtv: menu.links is just the list defined at the top of the class
[11:57] <jtv> Ah
[12:00] <jtv> bigjools: done
[12:00] <bigjools> thanks
[12:01] <jtv> I don't suppose python has a built-in equivalent to “lambda x: not x”?
[12:01] <jtv> Actually, no, that's not what I need.  What I need is partial application of operator.not_
[12:02] <jtv> Or something.
[12:02] <stub> __builtins__.not_ = lambda x: not x
[12:03] <jtv> I was hoping to combine it with an attrgetter: filter(negate(attrgetter('my_bool_attr')), my_list)
[12:03] <jtv> For some value of negater.
[12:04] <benji> jtv: operator.not_
[12:05] <jtv> The problem is combining it with the attrgetter.  :)
[12:05] <benji> ah; lambda is your friend
[12:05] <jtv> Or reduce maybe
[12:06] <jtv> No
[12:06] <jtv> So back to partial
[12:47] <gary_poster> hey stub.  We are getting a lot of activity on pgkillactive.py.  This may be old news; I was out last week and am consumed by interviewing.  But the logs are telling us stuff like this:
[12:47] <gary_poster> Killing lpnet127 (15802), 2011-11-01 11:20:17.341629+00:00, 2011-11-02 06:57:42.661591+00:00
[12:47] <gary_poster> Locks found:
[12:47] <gary_poster> relname, transactionid, mode, granted, current_query, query_start, age, procpid
[12:47] <gary_poster> It's on lpnet 127, 129 and 130.
[12:47] <gary_poster> Does that suggest an action item?  If so, has it already been taken?
[12:49] <stub> gary_poster: I spent last week in a small village 100km from the Laos border and am now encircled by flood waters. I know less than you :-)
[12:49] <gary_poster> stub, heh, ok
[12:49] <gary_poster> are things getting better or worse, stub?
[12:49] <gary_poster> for your physical environment I mean :-P
[12:50] <stub> gary_poster: I'm still dry, and if it floods in my area I'll be fine upstairs. Official news is crap though so hard to follow.
[12:50] <gary_poster> gotcha stub.  good luck.
[12:51] <wgrant> gary_poster: That was several hours ago?
[12:51] <wgrant> Yes.
[12:51] <gary_poster> wgrant, yes
[12:51] <wgrant> That was soybean wandering off into lala land.
[12:51] <wgrant> It was powerstabbed and recovered.
[12:51] <wgrant> We still don't really know what happened, but it wasn't an LP thing.
[12:52] <gary_poster> ok thanks wgrant
[13:01] <mrevell> Guten morgen alles.
[13:02] <nigelb> Bonjour mrevell
[13:02] <timrc> is the Launchpad web service going to get a 2.0 release for Precise?
[13:05] <deryck> Morning, all.
[13:05] <abentley> deryck: morning.
[13:11] <abentley> timrc: I'm not aware of any plans to do another stable API.  However, the devel API is improving over time.
[13:18] <timrc> abentley, okay... I wasn't sure what LTS would mean (if anything) to the web service
[13:20] <abentley> timrc: you might want to ask lifeless for his thoughts.  He's usually around in 6-7 hours.  I have the impression that the devel service is much more popular than the 1.0 service, so stable versions may not be worth the extra effort they require.
[13:27] <Ursinha> bug 879589
[13:27] <Ursinha> where's the bot
[13:28]  * nigelb pokes _mup_
[13:33] <cjohnston> One of the blueprints for a session during UDS was deleted.. do any of the devs have the ability to figure out when it was deleted
[13:42] <jtv> cjohnston: I'm not too familiar with blueprints (that'd be sinzui) but I'm not sure we normally delete blueprints at all.
[13:43] <jtv> We have various statuses along the line of "obsolete" and "declined," and if that's what happened we may be able to learn more.
[13:43] <cjohnston> its 404'ed
[13:43] <cjohnston> we figured out the issue.. so its all good
[13:43] <mwhudson> cjohnston: it's probably been renamed
[13:43] <jtv> Ah.
[13:44] <cjohnston> that could be too
[13:44] <mwhudson> or retargeted
[13:44] <cjohnston> would it be possible to create some sort of forward for a while when they are retargeted?
[13:45] <mwhudson> if you don't mind changing launchpad, sure!
[13:45] <cjohnston> lol
[13:45] <nigelb> He already has patches
[13:45] <nigelb> ;)
[13:45] <cjohnston> ive already made changes
[13:45] <nigelb> 6 landings I think?
[13:45] <cjohnston> something like that
[13:46] <jtv> And yet none of them fixed your problem?  Patch harder!
[13:46] <jtv> Meanwhile, any reviewers for tiny tiny leetle branch?  https://code.launchpad.net/~jtv/launchpad/getBinariesForDomination-bulk/+merge/81020
[13:47] <cjohnston> yup.. its a branch
[13:53] <cjohnston> jtv / mwhudson.. for sprints (ie the current UDS) when a track lead is set as an approver.. do they get a notification and or a reminder about a  blueprint that needs to be approved
[13:54] <mwhudson> cjohnston: don't know, sorry
[13:54] <jtv> Same here.
[13:55] <cjohnston> anyone else know by chance?
[13:56] <nigelb> cjohnston: *cough* "Use the source, Like" *cough*
[13:56] <cjohnston> too much work
[13:57] <nigelb> Blueprints is probably the easiest to understand.
[14:01] <allenap> Does anyone know why I'd get a NotABranch error from merge-proposal-jobs.py in qastaging? https://lp-oops.canonical.com/?oopsid=OOPS-d39c8d786a4c80ed1f17e9943d2f51ae
[14:01] <allenap> s/NotABranch/NotBranchError/
[14:01] <rvba> jtv: I've reviewed your tiny tiny branch ;)
[14:01] <jtv> Thanks!
[14:02] <jtv> allenap: not scanned yet?
[14:04] <allenap> jtv: I pushed it yesterday, and revisions are appearing in the UI <https://code.qastaging.launchpad.net/~allenap/scriptify/test1>
[14:04] <jtv> Oh, wait.  This is qastaging.
[14:04] <jtv> Does it have its own codehosting server?
[14:04] <allenap> jtv: It's running on gandwana as bzrsyncd.
[14:05] <allenap> Which is the same host as used for staging.
[14:05] <jtv> So much for that then.
[14:06] <allenap> jtv: The error mentioned lp-internal:///~allenap/scriptify/test1... there's no mention of qastaging there, or is it, as it implied, a purely internal identifier.
[14:07] <nigelb> danhg: Do you know if the launchpad session will have audio?
[14:08] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1 --use-existing-dir
[14:08] <allenap> bzr: ERROR: Server sent an unexpected error: ('error', 'NotBranchError', 'Not a branch: "lp-83227408:///+branch-id/360039".')
[14:11] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1
[14:11] <allenap> This transport does not update the working tree of: bzr+ssh://bazaar.qastaging.launchpad.net/~allenap/scriptify/test1/. See 'bzr help working-trees' for more information.
[14:11] <allenap> Created new branch.
[14:11] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1
[14:11] <allenap> No new revisions to push.
[14:11] <allenap> Now I can see a .bzr directory in the right place (with hitchhiker).
[14:13] <deryck> abentley, hey, shall we mumble a bit now?
[14:13] <abentley> deryck: sure
[14:13] <deryck> hi coffeedude
[14:13] <rvba> jtv: I was thinking about BPPH.binarypackagename but I'm not sure that's helpful for you.
[14:14] <jtv> rvba: not really — it's still one-by-one.
[14:14] <jtv> But I'm not too worried about it; I think it'll be a secondary issue at worst.
[14:14] <rvba> Okay.
[14:14] <jtv> Oh wait, _now_ I get what you mean!
[14:15] <coffeedude> hey deryck
[14:15] <jtv> The column that's been recently added to the table.  Has that been fully initialized yet?
[14:15] <rvba> jtv: exactly
[14:15] <jtv> Has initialization completed yet?
[14:15] <rvba> jtv: I think it has.
[14:15] <jtv> If so then yes, it would be useful!
[14:15] <jtv> Thanks for pointing that out.
[14:15] <rvba> Glad to help ;)
[14:16] <jtv> It means we can avoid loading the BPN anywhere.
[14:16] <jtv> Maybe even the BPR… worth thinking about.
[14:24] <cjohnston> jtv: fwiw, the answer is yes, they do get emails, but sometimes get lost in rules and what not
[14:25]  * jtv wishes software could go back to being stupid and predictable, and leave the interesting stuff to us meatbags
[14:25] <cjohnston> heh
[14:26] <mrevell> nigelb, What's your Skype id?
[14:26] <nigelb> mrevell: heh, I was kidding originally :)
[14:26] <nigelb> mrevell: nigelbabu
[14:34] <abentley> deryck: you changed the listing to be a wide listing, but to me it looks too wide now.  Too much space between bug title and bug heat, especially if maximized.  Can we revisit that?
[14:36] <deryck> abentley, I'm just following the mockups.  I think we need to raise it with huw and mrevell if we want to change it.  FWIW, I like it wide. :)
[14:36] <deryck> but then I don't have a huge monitor.
[14:37] <deryck> also, it seems quite bare now, but when there are a lot of fields, it will fill up.  So there will always be some tension here.
[14:37] <abentley> deryck: On my monitor, the space between the title and the heat is often as wide as the title itself.  That makes the listings hard to read, because there's not a strong visual connection.
[14:38] <deryck> abentley, yeah, I can understand that.
[14:38] <deryck> abentley, I wonder if heat should drop down to the second row and fall directly inline with everything else.
[14:39] <deryck> or else directly to the right of the title.
[14:39] <abentley> deryck: the mockups actually show the title's column being ~ the same width as the longest title, which was how I had it.
[14:41] <deryck> abentley, all the mockups I see have it flush with the sidebar too.  so it's not clear which was meant -- i.e. follow with the title, or follow to the sidebar.
[14:41] <deryck> mrevell, care to weigh in on the intent here ^^ ?
[14:42] <deryck> abentley, what does the side bar do on a large display if the listings are narrow?
[14:42] <deryck> if you recall.
[14:42] <abentley> deryck: I don't recall.
[14:42] <deryck> ok, np.
[14:43] <deryck> abentley, are you wanting to fix it yourself in a branch your working on, or just raising the issue?
[14:43] <abentley> deryck: just raising the issue.
[14:44] <abentley> deryck: while it's still fresh.
[14:44] <deryck> abentley, ok.  let's chat with mrevell and huw when they have more availability, and I'll play with some options in css to see what possibilities we have.  fair enough?
[14:44] <abentley> deryck: sounds good.
[14:45] <deryck> abentley, cool.  I added a Kanban misc card to remind me to follow up on it. :)
[14:45] <allenap> jtv, rvba: Fwiw, the problem was that the *trunk* branch of the scriptify project was not pushed. The NotBranchError I got when pushing the test1 branch referred to an attempt to find the default stacking branch.
[14:46] <jtv> ouch
[14:46] <jtv> Bug.
[14:46] <allenap> jtv: Indeed, but the good news is that long-polling for merge proposals works in staging and qastaging (restricted to ~launchpad for now).
[14:46] <allenap> rvba: ^
[14:47] <jtv> Nice!
[14:47] <nigelb> allenap: <3
[14:47] <nigelb> Will it be rolled to production for launchpad only at least? :)
[14:48] <nigelb> Oh wait. ~launchpad. Not ~launchpad-dev :(
[14:48] <allenap> nigelb: The LOSAs are going to figure out how to deploy the new service effectively (it's a bit of a cowboy right now) then, yes, it'll get rolled out :)
[14:48] <nigelb> \o/
[14:48] <allenap> nigelb: I think it'll be safe to make it available to ~launchpad-dev.
[14:49] <nigelb> Yay!
[14:49] <nigelb> mrevell: Thanks for skyping me in!
[14:49] <mrevell> nigelb, Pleasure!
[14:56] <abentley> deryck: css class "bugtitile" appears mispeled.
[14:56] <deryck> heh
[14:57] <deryck> I had to look a couple times to spot the typo.
[14:57] <deryck> that's how I pronounce it in my accent. ;)
[14:57] <deryck> tie-tile :)
[14:57] <deryck> abentley, I'll fix in my branch.  Thanks!
[14:58] <abentley> deryck: lol.  Cool.
[15:12] <allenap> nigelb: Merge proposal long-poll stuff is enabled for ~launchpad-dev in staging and qastaging.
[15:12] <nigelb> allenap: Thanks!
[15:14] <allenap> nigelb: No worries. Please break it :)
[15:15] <allenap> abentley: Up for a review? https://code.launchpad.net/~allenap/launchpad/participation-keyerror-bug-810114/+merge/81012
[15:15] <abentley> allenap: sure.
[15:15] <bigjools> allenap: It still says "reload to see changes", right?
[15:15] <allenap> bigjools: Yes, it does.
[15:15] <allenap> abentley: Thanks.
[15:16] <bigjools> mrevell: is there an LP session on?
[15:16] <abentley> allenap: module docstring is a placeholder.
[15:16] <mrevell> bigjools, Not right now.
[15:16] <mrevell> bigjools, We're doing a check-point, though.
[15:16] <bigjools> cool
[15:16] <allenap> abentley: Oops. I'll fix that, and all the functions too.
[15:17] <abentley> allenap: yeah, the functions have comments rather than docstrings.
[15:17] <deryck> abentley, so you think bugnumber CSS class should become bugid (or some such)?  Or do you think it doesn't matter for class names so much?
[15:17] <abentley> deryck: I think we should standardize everything on bugnumber.
[15:18] <deryck> abentley, ah, ok.  The class I use for sorting is sort-id because each of them get a "sort-X" class where X is the actual orderby phrase.
[15:18] <deryck> abentley, so we can't actually change that to bugnumber.  but otherwise we can standardize.
[15:19] <abentley> deryck: makes sense.
[15:19] <deryck> ok, cool.
[15:19] <bigjools> allenap: it isn't working for me on staging
[15:20] <allenap> PEBKAC probably ;)
[15:20] <allenap> bigjools: Whassup?
[15:21] <bigjools> allenap: hoho!  yellow box still there, if I reload in a new tab, it's not there, but neither is the diff
[15:21] <allenap> bigjools: Can you point me to the branch?
[15:21] <bigjools> allenap: https://code.staging.launchpad.net/~julian-edwards/txlongpollfixture/FIRST/+merge/76676
[15:21] <bigjools> I merged one that was already on staging
[15:22] <abentley> allenap: transaction.abort in check_teamparticipation_consistency worries me a bit, because it doesn't seem to guarantee that any pending DB writes got written.
[15:23] <allenap> abentley: There are no pending db writes, and there shouldn't be.
[15:23] <gnuoy> allenap, Not a branch
[15:23] <gnuoy> OOPS-21e6aba1bf48244072ebdc537396b722
[15:23] <abentley> allenap: A function doesn't know who its caller is.
[15:24] <abentley> allenap: I guess you can keep it if you document it.  Otherwise, I'd prefer a commit.
[15:25] <allenap> abentley: Fair. Okay, I can do a store.rollback(), or even a store.close().
[15:25] <allenap> abentley: Okay, commit is fine actually.
[15:25] <abentley> allenap: cool.
[15:26] <gnuoy> allenap, I think bigjools is hitting the same problem you were
[15:26] <allenap> bigjools, gnuoy: It's because lp:txlongpollfixture is not a branch; branch content is not synced during a refresh. I've pushed it now, so try again.
[15:26] <bigjools> ahhh
[15:26] <allenap> bigjools: gnuoy and I spent a long time figuring out that little gem earlier.
[15:27] <abentley> allenap: check_teamparticipation_consistency has a lot of inner functions.  Have you considered structuring it as a class?
[15:28] <abentley> allenap: well, maybe "a lot" is a bit strong.  Some.
[15:28] <allenap> abentley: Yes, but I think it would get longer and less readable, imo. I have considered splitting it into two - a slurping part and a checking part - but haven't done it yet. I am working on a follow-up so I might do it there.
[15:29] <allenap> abentley: Also, the slurped data will use about ~200MB of memory so it's quite useful that this will be reclaimed as soon as the function returns.
[15:30] <abentley> allenap: "len(out) > 0" might be clearer and faster as out != ""
[15:33] <allenap> abentley: Okay.
[15:35] <abentley> allenap: r=me with the docstring updates.
[15:35] <allenap> abentley: Thanks!
[15:37] <rvba> abentley: could you please have a look at this (tiny) MP? https://code.launchpad.net/~rvb/launchpad/branches-timeout-bug-827935-always-display/+merge/81022
[15:37] <gnuoy> nigelb, bigjools, I need to quickly restart txlongpoll in staging and qastaging
[15:37] <abentley> rvba: sure.
[15:37] <rvba> ta
[15:37] <bigjools> gnuoy: fine
[15:38] <nigelb> I'm not testing yet.
[15:38] <nigelb> UDS :)
[15:38] <abentley> rvba: r=me
[15:38] <rvba> abentley: Thank you!
[15:39] <abentley> rvba: np
[15:41] <gnuoy> nigelb, bigjools. thanks and done
[15:48] <deryck> abentley, for your change you had to revert, you landed display-cleanup, reverted in another branch, and then fixed inside display-cleanup and landed that same branch again....
[15:48] <deryck> abentley, is that right?
[15:49] <abentley> deryck: that's right.
[15:49] <deryck> abentley, the "fake merge" commit you had is needed to get in sync with devel after the revert?
[15:50] <abentley> deryck: right.
[15:50] <deryck> abentley, how exactly did you fake merge?
[15:51] <abentley> deryck: bzr merge devel; bzr revert .; bzr commit
[15:51] <deryck> ah ha.  right, that makes sense.
[15:51] <deryck> abentley, thanks!
[15:52] <abentley> "revert ." reverts all file changes, but keeps the merge marker.
[16:35] <deryck> abentley, hey.  sorry to keep pestering you....
[16:35] <abentley> deryck: no worries.  What's up?
[16:36] <deryck> abentley, you have your object like this:  var navigator = Y.lp.bugs.buglisting.ListingNavigator.from_page();
[16:36] <deryck> abentley, and I work from that when I create my OrderByBar.  I'm going to feature flag all of that, I think.
[16:36] <deryck> abentley, there's no need for the navigator to be outside the flag, right?
[16:38] <abentley> deryck: The only thing is testability.  It's easier to test how Navigator behaves when the flag is disabled than to test whether the page has no navigator when the flag is disabled.
[16:39] <abentley> deryck: But I guess it's not that hard to test either way.
[16:39] <deryck> ah
[16:39] <deryck> abentley, so if I change it, tests will break?
[16:40] <abentley> deryck: No, but you should delete the code they're testing and the tests themselves.
[16:42] <abentley> deryck: test_render_no_client_listing, test_from_page_no_client
[16:43] <deryck> abentley, I'm confused, sorry.  Why would I want to delete tests?  We don't want to lose that coverage, do we?
[16:44] <abentley> deryck: We should have only one strategy for dealing with the feature flag.  So if you change the strategy, you should delete the old code.  And that would make the tests fail.
[16:44] <deryck> abentley, ah, now I see what you mean.  Thanks.
[16:45] <abentley> deryck: np.
[17:18] <deryck> abentley, so this is the sort of thing, I'm thinking:  http://pastebin.ubuntu.com/726516/
[17:18] <deryck> abentley, just putting our scripts behind a flag.
[17:21] <deryck> abentley, and as far as I can tell has no impact on your current approach or testing, though I don't mind deleting the empty return and tests if you feel it's unneeded.
[17:22] <deryck> oh, lunch now, sorry.  chat more when I'm back.
[18:25] <deryck> abentley, did you see what I wrote in the scrollback?
[18:26] <abentley> deryck: I did.  I do feel deleting the empty return and the check in render makes sense, because your change makes it dead code, and dead code should be deleted.
[18:27] <deryck> abentley, fair enough.  I'll kill it then.
[18:27] <abentley> deryck: cool.
[18:33] <deryck> abentley, http://pastebin.ubuntu.com/726581/  cool?
[18:34] <abentley> deryck: You've missed the check in render:     "if (! Y.Lang.isValue(this.target)){"
[18:36] <deryck> abentley, updated then: http://pastebin.ubuntu.com/726584/  cool now?
[18:36] <abentley> deryck: yes, thanks.
[18:36] <deryck> abentley, np.
[18:46] <abentley> Our linter has spelling errors: "To few newlines before selectors."
[18:48] <jtv> abentley: it could be a toast.
[18:48] <jtv> Here's to few newlines before selectors!  <ting> <slurp>
[18:49] <abentley> jtv: Toasts are usually written as exclamations, so then it would be a grammar error :-)
[18:50] <jtv> abentley: toasts must be considered in the context of the number, size, and alcohol content of preceding drinks.
[18:51] <jtv> But I admit your interpretation has merit.
[19:08] <abentley> deryck: could you please merge r14231 or later into custom-bug-listings and push?  My branch has conflicts that it's inheriting from custom-bug-listings.
[19:09] <deryck> abentley, sure.  the css-polish branch?
[19:09] <abentley> deryck: right.
[19:09] <deryck> ok.
[19:17] <deryck> abentley, done.  push includes the recent fixes we discussed in the scrollback too.
[19:17] <abentley> deryck: cool, thanks.
[19:17] <deryck> np
[19:26] <abentley> deryck: test_update_from_model_caches is broken in custom-bug-listings-css-polish.    I think I broke the build then.  I could have sworn this test passed locally.
[19:31] <deryck> abentley, so fix the test or put the short circuits back?
[19:32] <abentley> deryck: Yep.  I'd fix the test, since there's only one, and we're already creating a custom object for it.
[19:32] <deryck> abentley, ok, I'll work on a fix now.
[19:33] <abentley> deryck: no rush.
[19:33] <deryck> well, not until the build breaks :)
[20:01] <deryck> abentley, this gets it working for me:  http://pastebin.ubuntu.com/726648/.   Look sane?
[20:02] <abentley> deryck: yes.
[20:02] <deryck> abentley, excellent.  I'll put up an MP.
[20:19] <lifeless> wgrant: that field.blob - what OOPS id was it on
[20:19] <lifeless> wgrant: I want to track the emitter down
[20:27] <deryck> abentley, care to review that testfix?  https://code.launchpad.net/~deryck/launchpad/testfix-buglisting-js-test/+merge/81073
[20:28] <abentley> deryck: r=me
[20:28] <deryck> abentley, thanks!
[20:29] <lifeless> abentley: could I please have a review of https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81075 ? diff coming in a minute
[20:29] <abentley> lifeless: sure.
[20:30] <lifeless> also, its so nice working on a code base with <20sec test runs :P
[20:30] <lifeless> abentley: thanks!
[20:33] <abentley> lifeless: to me, ValueError is vague enough that I'd rather check the length.
[20:34] <lifeless> abentley: its pretty precise:
[20:34] <lifeless> >>> foo, bar = 1
[20:34] <lifeless> TypeError: 'int' object is not iterable
[20:34] <lifeless> >>> foo, bar = [1]
[20:34] <lifeless> ValueError: need more than 1 value to unpack
[20:34] <lifeless> >>> foo, bar = [1,2,3]
[20:34] <lifeless> ValueError: too many values to unpack
[20:34] <lifeless> abentley: if its not iterable, you get TypeError
[20:34] <lifeless> abentley: if it is but the wrong length you get ValueError
[20:35] <lifeless> abentley: we haven't seen any corruption of the third form
[20:35] <lifeless> abentley: and I plan to make this be an actual dict soon, which will eliminate the corruption entirely once the producers are upgraded
[20:36] <abentley> lifeless: Yes, but that's not the only way ValueError is used.
[20:36] <lifeless> abentley: thats true, but its the only way its used for the short expression given
[20:36] <lifeless> abentley: we know that req_vars is a basic datatype because its just been deserialised
[20:36] <lifeless> e.g. no special objects implementing their own __iter__
[20:37] <abentley> lifeless: let's not go overboard about this.  I said I'd rather check the length, didn't mean that you had to.
[20:37] <lifeless> abentley: sorry, didn't mean to get contentious
[20:38] <lifeless> I was just about to say I'll change it if you want, was merely explaining why I did it the way I did
[20:38] <abentley> lifeless: Is line 46 tested?
[20:38] <lifeless> nope
[20:39] <lifeless> its probably testable, though its a bit awkward
[20:39] <lifeless> its in the factory-function that reads from disk files
[20:40] <abentley> lifeless: I think since it fixes a bug, that we should test it.
[20:40] <lifeless> if I change one of the sample oopses to have a lower case id
[20:41] <lifeless> that will cause other test to fail if the line is not present
[20:41] <lifeless> I think this is the simplest way to ensure its presence is needed
[20:41] <lifeless> how does that sound?
[20:41] <abentley> lifeless: that sounds fine to me.
[20:41] <abentley> lifeless: So with testing, r=me.
[20:42] <lifeless> thank you
[20:42] <abentley> lifeless: np
[20:42] <lifeless> ok, I get failures with the line removed
[20:43] <lifeless> and not with it present
[20:43] <lifeless> heh, spoke to soon
[20:43] <lifeless> something else blew out :P
[20:45] <lifeless> abentley: \o/ other oopses already exercised that failure mode. So, I'll have a slightly longer diff for you, showing the impact.
[20:48] <lifeless> hah
[20:48] <lifeless> abentley: I misanalyzed the cause of our issues around that line.
[20:49] <lifeless> abentley: I'm going to drop it from the diff and do a different patch for that part of it
[20:49] <abentley> lifeless: Okay.
[20:49] <lifeless> src/oopstools/oops/views.py index() is the issue
[20:49] <lifeless> it treats oopses starting with OOPS specially, which is why the u1 lowercase oopses work and the LP lowercase ones didn't.
[20:50] <lifeless> abentley: I may end up including the line in the final fix, just want to decouple things to get more time to look at it.
[21:03] <deryck> Later on, everyone.
[21:36] <lifeless> abentley: https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81083 if you have time
[21:51] <lifeless> bac: thanks!
[21:51] <lifeless> bac: I was just about to start a branch to fix up my booboo
[21:52] <bac> lifeless: actually, i haven't gotten too far with it.  if you'd like to add some thoughts to the bug that might be helpful.
[21:52] <lifeless> bac: I just did
[21:52] <bac> lifeless: i did see that the report created has no 'type', at least when created via the tests.
[21:53] <lifeless> bac: tests for this need to be asynchronous tests
[21:53] <bac> not have a type entry causes the filters to explode
[21:53] <lifeless> bac: using the custom runner, and returning a deferred from the test to have that executed by twisted
[21:53] <lifeless> bac: that may be a separate defect (but worth addressing too) - changing from
[21:54] <lifeless> report['type'] to report.get('type', 'No exception type')
[21:54] <lifeless> report['value'] to report.get('value', 'No exception value')
[21:54] <lifeless> should do that
[21:54] <bac> lifeless: yep, i'd done something similar
[21:54] <lifeless> I think python-oops-twisted made that change; this is kindof code duplication, because its twisted code logging to to non-twisted logging module.
[21:55] <lifeless> (also made that change)
[22:02] <mrevell> hey huwshimi, got time to talk in the next 20 minutes? We need to try something new for the manage-disclosure mock-ups
[22:03] <mrevell> huwshimi, Good morning, btw :)
[22:03] <huwshimi> mrevell: Morning
[22:03] <huwshimi> mrevell: 2 mins
[22:03] <mrevell> huwshimi, I'll be popping offline but back shortly. No need to talk immediately.
[22:03] <mrevell> huwshimi, But I'd love to hijack your day... :)
[22:03] <huwshimi> mrevell: Now's fine with me
[22:04] <mrevell> huwshimi, Oh, I'm going onto another call just now. I'll ping you in an hour or so.
[22:04] <huwshimi> mrevell: Ah ok, no problems
[22:05] <lifeless> flacoste: anytime..
[22:11] <lifeless> abentley: actually, nevermind, there is a code hcange neeed; next reviewer up can cop it :)
[22:24] <poolie> hi huwshimi, lifeless
[22:24] <huwshimi> poolie: Morning
[23:15] <poolie> huwshimi: i replied about wrapping; we can talk about that later if you like
[23:15] <huwshimi> poolie: Sure
[23:15] <poolie> otp now
[23:27] <huwshimi> wallyworld_: Do you know anything about adding a security view to the +manage-disclosure page?
[23:28] <huwshimi> wallyworld_: Also, hello
[23:28] <wallyworld_> huwshimi: hi. i'm not exactly sure what any security view needs
[23:28] <wallyworld_> is this a user request?
[23:29] <lifeless> can I have a review of https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81083 please? its simple.
[23:29] <huwshimi> wallyworld_: No, from Matthew
[23:29] <wallyworld_> huwshimi: the accessibility of project artifacts is basedon policies
[23:29] <lifeless> huwshimi: what do you mean by security view?
[23:29] <lifeless> :)
[23:30] <wallyworld_> huwshimi:  security is orthogonal to that
[23:30] <wgrant> I assume it's the policy stuff that I discussed on the call this morning.
[23:30] <lifeless> huwshimi: as in, do you mean the red banner ?
[23:30] <huwshimi> lifeless: I have no clue, that's what I'd trying to find out :)
[23:30] <lifeless> wgrant: wallyworld_: I'm OCR today, so I need someone else :P
[23:31] <wgrant> lifeless: Looking.l
[23:31] <wallyworld_> huwshimi: i think we need to talk to matthew to clarify
[23:31] <lifeless> wgrant: thanks
[23:31] <wallyworld_> lifeless: sorry, was going to look after conversation finished
[23:31] <lifeless> wallyworld_: no worries
[23:31] <huwshimi> wallyworld_: Yeah that's fine, he's just away for a bit and I think he was hoping for some mockups today
[23:31] <lifeless> wgrant: my commit message and description are now stale.
[23:31] <lifeless>  Fixing
[23:32] <lifeless> Fixed.
[23:32] <wallyworld_> huwshimi: i think there's confusion/disconnect about policy based access and security etc
[23:32] <wallyworld_> huwshimi: so at some point i think we all need to get on a call to clarify
[23:32] <huwshimi> wallyworld_: Ah ok
[23:33] <wgrant> Might have to be late in our evening.
[23:33] <wgrant> Unless we catch Matt while he's at UDS.
[23:33] <wallyworld_> huwshimi: matthew is at uds? perhaps we can get together later today our time
[23:34] <huwshimi> wallyworld_, wgrant: He's gone out for dinner and I think he will try and call when he gets back
[23:34] <wgrant> Hopefully we can obtain a Curtis as well.
[23:34] <wallyworld_> huwshimi: ok. let's try and have a call then
[23:34] <wgrant> Otherwise I know mostly what's going on here.
[23:34] <huwshimi> wallyworld_: Great
[23:35] <wallyworld_> it would be good for curtis to be there so he can take what's discussed to folks at uds etc
[23:37] <lifeless> wgrant: got a thumbnail sketch for me ?
[23:37] <wgrant> lifeless: Of?
[23:37] <lifeless> 12:30 < wgrant> I assume it's the policy stuff that I discussed on the call this morning.
[23:38] <wgrant> lifeless: Pretty much what Curtis, you and I discussed a few weeks back.
[23:38] <wgrant> That others seem to be largely unaware of.
[23:38] <lifeless> wgrant: a little more context please
[23:40] <wgrant> lifeless: The policy-based disclosure approach, to avoid all the hideous security/apport special casing. Private artifacts have an associated policy, with observers for that policy, optionally specific to an artifact.
[23:40] <lifeless> righto
[23:40] <lifeless> do you mean db backed policies ?
[23:40] <wgrant> Yes.
[23:41] <lifeless> k, thanks
[23:41] <wgrant> Rather than the "security is magical lalalala" that was initially proposed.
[23:43] <lifeless> great, so distraction over you can go back to my review ;)
[23:43] <wgrant> Indeed.
[23:43] <lifeless> also I may have made oops lookup a brazillion times faster in some cases
[23:45] <wgrant> lifeless: + oopsids.add(with_oops.lower())
[23:45] <wgrant> lifeless: Isn't that going to lower the OOPS- too?
[23:45] <wgrant> Which is probably wrong.
[23:46] <lifeless> well, depends on where you consider the abstraction barrier
[23:46] <lifeless> but yes, I can see that being an issue.
[23:47] <lifeless> will make it a .update(map(lambda x:'OOPS-' + x, oopsids)) instead
[23:47] <wgrant> Thanks.
[23:53] <poolie> jelmer: http://twitter.com/#!/mumak/status/131875802630471680


[00:00] <bob2> as in branch a subtree of an existing branch?  you can try "split", but I don't think it's production-y yet
[00:05] <mathrick> okay, so the correct fix is to s/map.//
[00:05]  * mathrick hugs bzr blame
[00:07] <gregcoit> bob2: the option is to copy the dir to another place and init is as a new bzr branch, right?
[00:08] <bob2> yeah, but that loses history
[00:08] <bob2> you could also branch the whole thing, delete everything else and then move the files in this one dir to the root
[00:08] <gregcoit> bob2: oh, that works too - thanks!
[00:43] <mathrick> is there some trick to get bzr blame to find where a particular line has disappeared?
[00:46] <lifeless> use gannotate and click around versions
[00:46] <lifeless> is what most people seem to do
[00:51] <mathrick> aha
[00:55] <mathrick> http://bazaar.pastebin.com/GaJP7cRb
[00:55] <mathrick> any idea what's wrong?
[01:27] <dOxxx> yarr
[01:33] <poolie> mathrick: this looks like an already fixed bug, are you up to date?
[01:33] <mathrick> poolie: 2.1.0
[01:34] <poolie> and also in bzr-git?
[01:36] <mathrick> bzr git is r721
[01:37] <poolie> sorry
[01:37] <poolie> suggest you file or look for a bzr-git bug then
[01:37] <mathrick> ok
[01:47] <keithy> when I do bzr cat <remote url> it changes my remote directory setting how do I stop it?
[01:48] <lifeless> what do you mean?
[01:50] <keithy> I think I misunderstood the error
[01:51] <keithy> I got a "permanently redirected" report
[01:51] <keithy> << is tired
[01:51] <keithy> btw if you are interested in how I am using bzr for squeak/cuis http://smalltalkers.pbworks.com
[02:07] <poolie> thanks keithy
[02:08] <poolie> how are things working out?
[02:08] <keithy> in what respect?
[02:08] <poolie> just with bzr and lp
[02:08] <keithy> I am suffering form spiderman syndrome...."with great power comes great responsibility"
[02:09] <keithy> very well indeed
[02:09] <keithy> some quibbles with the squeak licence
[02:10] <keithy> I dont think people in the OSI community realise how much trouble they caused
[02:11] <poolie> i heard about some of that
[02:11] <keithy> it has taken something like 10 years to relicence squeak, all because of two paragraphs in the licence that arent relevant any more
[02:11] <keithy> for example
[02:11] <keithy> the licence says, you cant distribute apples fonts
[02:12] <keithy> but readers of the licence dont think to ask if there are any apple fonts in the product to distribute
[02:12] <keithy> the last remnant was removed 6 years ago
[02:13] <keithy> Apart from that
[02:13] <poolie> right
[02:13] <keithy> In a week or so
[02:13] <poolie> i see your point about the difficulty of updating things that predate OSI
[02:13] <keithy> exactly, it was very disingenious of them
[02:13] <keithy> especially when squeak was a pioneer of OS for commercial purposes
[02:14] <keithy> the SqueakL was actually designed to enable reuse for commercial purposes
[02:14] <bob2> who is 'them'?
[02:14] <keithy> unlinke Gnu etc
[02:14] <keithy> squeak was developed by a team in the Apple Technology Group
[02:14] <keithy> this team was originally at Zero parc
[02:14] <keithy> xerox
[02:14] <keithy> parc
[02:15] <poolie> ok
[02:15] <keithy> The system was released by xerox to the public by publishing the full spec in a book, the famous blue book
[02:15] <poolie> so, i hope we work something out
[02:15] <poolie> rebooting, biab
[02:15] <poolie> i know, i read it years ago
[02:15] <poolie> it's pretty cool that it's out there
[02:15] <keithy> its on the net now
[02:16] <poolie> rebooting, biab
[02:30] <poolie> i'm thinking about just removing the attempted fix for bug 456077 from 2.0 because of the fallout it caused
[02:34] <poolie> lifeless: ping, teddybear wanted on this
[02:34] <lifeless> poolie: voice?
[02:35] <poolie> irc will do
[02:35] <poolie> just about whether to revert the cross-format fetch warning in 2.0
[02:35] <lifeless> what was the fallout
[02:36] <poolie> warnings during upgrade
[02:36] <poolie> and the message is not always very clear, eg bug 513157
[02:36] <lifeless> right
[02:36] <lifeless> uhm, I think the upgrade one is easy enough; squelch the warning before starting upgrade.
[02:37] <lifeless> the clarity one, seems like polishon the format %s that spiv worked on in france
[02:37] <lifeless> so, I would attempt to finish it off rather than revert it, myself.
[02:37] <poolie> i guess the fallout is not so severe that it needs to be immediately pulled
[02:37] <poolie> yeah
[02:37] <poolie> ok
[02:37] <poolie> thanks
[02:45] <lifeless> poolie: no probs
[03:13] <lifeless> poolie: are you doing  https://bugs.edge.launchpad.net/bzr/+bug/515356 too?
[03:13] <poolie> yes
[03:13] <lifeless> cool; was wondering as its not assigne
[03:15] <poolie> i'm not doing it right now
[03:15] <poolie> i'm going to fix the underlying fetch thing first
[03:19] <poolie> is bug 388269 a dupe of bug 435048?
[03:20] <lifeless> I think so
[03:20] <lifeless> if not a dupe then remarkably similar
[04:40] <parthm> Hello, based on the discussion on bug 503670 'bzr grep', I have created a bzr-grep plugin explained here https://bugs.launchpad.net/bzr/+bug/503670/comments/11
[04:41] <parthm> I would appreciate any review comments this as I am still new to bzrlib API. Whats a good launchpad mechanism for this? Probably the comments can be left on the bug listing?
[04:42] <parthm> Another question, I am planning to work on the test cases, any pointers would be much appreciated.
[04:45] <poolie> parthm: there wasn't a bzr-grep already?
[04:45] <parthm> I could find anything. I saw bzr-search and ~vila/bzr/grep which was unix only.
[04:46] <poolie> ok
[04:46] <poolie> so i don't think there's any particular way to say please review this from scratch
[04:46] <poolie> other than making an empty trunk branch
[04:46] <poolie> then proposing a merge of all your code into that
[04:46] <poolie> which would work ok
[04:47] <parthm> Sounds ok. So for the purpose of review, I would just branch the trunk and put in the grep folder so the comments can be tracked.
[04:49] <parthm> What would be a good way to create tests? Basically, I need to create a working tree, add files and file content. then run "bzr grep" on it pattern matching on output.
[04:53] <Kilroo> ...I think I just figured out a set of process I can use to let my team treat our non-versioned ftp servers at work as if they are under version control with all the people who use raw ftp as a sort of "ghost committer."
[04:55] <Kilroo> I'm not sure though. Gotta think about that. It may require either more steps to follow when committing, or finding somewhere I can put a bzr smart server and getting rather creative with hooks.
[05:59] <GaryvdM> Hi vila
[06:02] <poolie> hi GaryvdM, vila
[06:03] <GaryvdM> Hi poolie
[06:08] <wgrant> Where is the bzr documentation?
[06:08] <wgrant> The "Get Help" link on the website doesn't seem to lead there.
[06:09] <GaryvdM> http://doc.bazaar.canonical.com/en/
[06:09] <wgrant> Thanks. How does a normal user get there?
[06:09] <poolie> which website?
[06:09] <wgrant> http://bazaar.canonical.com/
[06:10] <bob2> "Documentation" link at the top left
[06:10] <bob2> or at the bottom
[06:10] <wgrant> Ah, so to get help I don't actually use the "Get Help" link.
[06:10] <poolie> easily fixed
[06:10] <bob2> if you say so
[06:11] <poolie> with sudo_sarcasm
[06:13] <poolie> wgrant: howzat
[06:16] <wgrant> poolie: Looks good. Thanks!
[06:20]  * wgrant wonders if 90000 users is really a stat that wants to be widely advertised.
[06:39] <GaryvdM> wgrant: a often quoted figger for world wide developers is 9 mil. Based on that, bazaar is used by 1%
[06:39] <GaryvdM> Hmm, dose not sound to good.
[06:39] <poolie> it's very hard to estimate usage of open source
[06:40] <wgrant> So it's probably a bad idea to try.
[06:44] <poolie> is that on our homepage now, or elsewhere?
[06:44] <GaryvdM> vila: I wanted to talk to you about releasing bzr-gtk. I pop back later.
[06:46] <wgrant> poolie: It's on the homepage.
[06:47] <wgrant> Otherwise the website is pretty nice now.
[06:47] <wgrant> Particularly with the compelling linked logos at the bottom.
[06:48] <poolie> thanks
[06:49] <poolie> wgrant: how about the project count
[06:49] <poolie> and the link to the popcon page?
[06:49] <wgrant> Popcon needs to die, not be linked to from anywhere :/
[06:50] <poolie>     Bazaar is used by thousands of people around the world on both open
[06:50] <poolie>     and closed projects, including

[06:50] <wgrant> +1
[06:50] <poolie> gary?
[06:50] <poolie> maybe s/thousands of//
[06:50] <wgrant> I considered that. It's hard to say.
[06:51] <poolie>     Bazaar is used by thousands of projects, both open and closed,
[06:51] <poolie>     including

[06:51] <wgrant> That works.
[06:51] <wgrant> And is far more likely to be accurate.
[06:52] <wgrant> And cannot easily be interpreted as being a very low number.
[06:54] <poolie> k
[06:54] <poolie> cron will update it in a bit
[06:54] <wgrant> Thanks.
[06:54] <poolie> not at all, thanks for the review
[07:01] <vila> hi all
[07:18] <wgrant> poolie: Oh, I see that the number wasn't actually pulled out of nowhere.
[07:19] <wgrant> poolie: But popcon is completely the wrong order of magnitude to use.
[07:19] <poolie> cause it undercounts?
[07:19] <wgrant> BzrPopularity oddly states the numbers as facts.
[07:19] <wgrant> poolie: It's not enabled by default, and the option is well hidden.
[07:19] <wgrant> I don't know anybody who has it on.
[07:19] <poolie> well, it's a fact (i presume) that's what it reports
[07:19] <poolie> right
[07:19] <poolie> me :)
[07:19] <poolie> but feel free to update the wiki page
[07:20] <wgrant> Ah, it is a wiki page. I see.
[07:21] <wgrant> See, the most popular popcon package has only 1.4 million installations. We have quite a few more users than that.
[07:22] <poolie> sure, you're quite right
[11:28] <etenil> Hi all
[11:30] <etenil> I made the mistake to branch manually (copy-paste of directory). And I have commited some changes in both branches now. How can I make the branch aware that it diverged from the trunk?
[11:31] <bob2> copying branches is fine
[11:31] <etenil> yeah, but merging them will be a problem
[11:31] <bob2> why?
[11:31] <bob2> bzr merge /the/other/one
[11:31] <etenil> well, they don't know where they diverged no?
[11:31] <bob2> sure they do
[11:31] <etenil> ah
[11:32] <etenil> does bzr compare the history or something?
[11:32] <bob2> yes
[11:32] <etenil> oh I see
[11:32] <bob2> branch doesn't do anything inherently magic
[11:32] <etenil> there was no need to worry then
[11:32] <bob2> you can use 'cp -a' if you prefer
[11:32] <etenil> ok
[11:32] <etenil> I was afraid to have done something dumb :)
[11:32] <etenil> thank you for your help bob2
[11:32] <bob2> well, back them both up first if you're worried :)
[11:33] <etenil> ok
[11:33] <etenil> thanks a lot
[13:37] <bialix> jaьЖ рш
[13:38] <bialix> jam: hi
[13:38] <bialix> jam: about next windows installer: please use qbzr 0.18.1 for it, not 0.18.2
[14:11] <jam> bialix: why is that?
[14:14] <jam> ah, found your email
[14:14] <jam> bug #524483
[15:01] <bialix> офьЖ https://bugs.launchpad.net/bugs/526933
[15:01] <bialix> jam: https://bugs.launchpad.net/bugs/526933
[15:01] <bialix> sorry
[16:12] <aquarius> yo, bzr people. Imagine, hypothetically, that I'd got a branch merged into the trunk of my project and everyone hated me for it, so I now want to submit a new branch which removes the changes that the previous one made. What's the easiest way to create this new branch?
[16:13] <aquarius> do I just branch trunk, do bzr diff -r -5..-6 > patchfile (or whatever revision my branch landed in), then patch -p0 < patchfile and bzr commit?
[16:13] <aquarius> that seems a bit long-winded
[16:14] <james_w> aquarius: branch trunk
[16:14] <james_w> bzr merge -r -6..-5 .
[16:15] <james_w> bzr commit
[16:15] <james_w> bzr push lp:...
[16:15] <aquarius> haha! you can merge from yourself?
[16:15] <james_w> propose merge
[16:15] <aquarius> smart. I didn't know you could do that :)
[16:15] <james_w> yep
[16:15] <aquarius> I knew you'd know a better way than making a patch file. Cheers, pal :P
[16:15] <james_w> and doing the revision range backwards applies the reverse diff
[16:21] <IslandUsurper> wait. -5..-6 *is* the backwards diff
[16:23] <james_w> aquarius: err yeah, what IslandUsurper said :-)
[16:23] <aquarius> james_w, I knew what you meant. negative numbers. It's the opposite of the opposite of what you think :)
[16:23] <aquarius> vds, ^ :-)
[16:23] <vds> aquarius: yup
[16:38] <CaMason> how can I show which files were edited at a specific revision
[16:39] <Peng> CaMason: bzr st -c 123
[16:39] <Peng> CaMason: Probably
[16:40] <rubbs> CaMason: try bzr annotate filename
[16:40] <rubbs> er...
[16:40] <rubbs> yeah I miss understood your question
[16:40] <rubbs> peng's answer might be better.
[16:40] <Peng> My answer is the best! :D Probably.
[16:40] <rubbs> heh
[16:42] <CaMason> thx :)
[17:46] <stefanlsd> Hi, is it possible to remove a tag?
[17:47] <stefanlsd> oh ok. tag --delete works. i was using -d and it wasnt
[18:12] <mathrick> stefanlsd: -d means --directory
[19:27] <bialix> channel trolls? really>
[19:27]  * bialix summons garyvdm
[19:28] <Peng> Eh? Trolls? Where?
[19:29] <bialix> banner said: [freenode-info] channel trolls and no channel staff around to help?
[19:30] <bialix> only channel staff has weapon?
[19:30] <bialix> evening Peng, btw
[19:31] <Peng> Hi. :)
[19:37] <bialix> anybody seen new Joel Spolsky's project? http://hginit.com/index.html   Looks like very nice tutorial
[19:38] <Peng> Hehe, "Mercurial tutorial" rhymes.
[19:41] <bialix> I wonder why people started bashing svn
[19:42] <Peng> Because it's terrible, like Boxbot.
[19:43] <fullermd> It's ugly, and its mother dresses it funny.
[19:47] <bialix> Peng, Boxbot is http://gunnerkrigg.wikia.com/wiki/Boxbot ?
[19:47] <Peng> bialix: Yes.
[19:47] <bialix> nobody likes boxbot
[19:48] <bialix> but Martin Fowler does rate svn highly
[19:48] <bialix> and he don't like a Feature Branches
[19:48] <bialix> is not it's funny?
[19:50] <gregcoit> i'd like to make a co a branch from launchpad, then branch that co, make changes to the new branch, and push the changes to a new branch on launchpad (without effecting the original branch on launchpad).  Is that sane/o-able?
[19:50] <gregcoit> er, do-able
[19:51] <bialix> gregcoit: almost
[19:52] <gregcoit> well, almost if close.  :)  what am I missing?
[19:52] <fullermd> Sure, though within the confines of that the co isn't doing anything.
[19:54] <bialix> gregcoit: it's a bit hard to read your slang
[19:54] <gregcoit> bialix: yeah, i'm new to bzr terminology
[19:55] <bialix> gregcoit: you can omit the step of co
[19:55] <gregcoit> bialix: what I'm trying to do is take a part of a branch and make it into a new branch with history preserved while keeping the original branch unaffected
[19:55] <bialix> co wo nt he lp yo
[19:56] <gregcoit> kk - I can see that
[19:56] <fullermd> Hey!  No Swahili in #bzr!
[19:57] <bialix> I hear you the white master
[19:57] <fullermd> When you run 'branch', you're creating a new independent branch.  Things done to it don't affect the original, unless you do things like 'push' that are designed to doing things inter-branch.
[19:57] <bialix> gregcoit: to extract part of the tree and preserve history.. it's not very easy
[19:58] <gregcoit> bialix: well, copy might be a betterterm than extract - I don't want to affect the orginal branch contents
[19:59] <bialix> every branch is separate copy
[20:00] <gregcoit> bialix: ahh, ok, perfect
[20:00] <gregcoit> bialix: thanks for talking me through this
[20:01] <bialix> may I advice you to read tutorial?
[20:01] <bialix> I'm not really sure I understand your intent
[20:06] <gregcoit> not a bad idea....
[20:15] <bialix> hmmm, Kiln is really attempting to be launchpad competitor
[21:13] <maxb> Except Launchpad doesn't even attempt to enter the "here it is, you can run it on your own server if you like" market
[21:20] <lifeless> moin
[21:35] <poolie> hi jam?
[21:35] <jam> morning poolie
[21:35] <poolie> how are things?
[21:36] <jam> going pretty well
[22:57] <poolie> hi all
[23:04] <ctrlsoft> 'morning poolie
[23:10] <spiv> Morning.
[23:15] <lifeless> vila: ping
[23:23] <poolie> hi ctrlsoft
[23:28] <ctrlsoft> poolie: fwiw I managed to get colocated branches in a git repo partially working, I can now list and access them using the patch I proposed to bzr.dev and an additional small change to bzr.dev
[23:29] <RAOF> ctrlsoft: YOU ARE MY HERO
[23:30] <ctrlsoft> RAOF: :-) Please note the "in a git repo", this doesn't work in a native Bazaar branch yet and it's still a prototype at this point.
[23:31] <RAOF> The *only* reason I want colocated branches is so that I can switch to bzr as my full-time git client.
[23:31] <RAOF> Which means being able to pull & push non-master branches.
[23:31]  * RAOF imagines a world where reading “git help add” doesn't happen quite so often
[23:41] <poolie> that's great
[23:44] <lifeless> jelmer: nice
[23:45] <lifeless> Peng: was Peng taken on twitteR?
[23:47] <RickCogley> hi - I'm a newbie at version control and at bazaar, and have bzr set up from the latest package on an os x server. Can I ask: when I set up a central repository, what are people doing? Setting up a single repository (e.g. organization name "acme") and putting projects under that, or, are people setting up multiple repositories... ?
[23:48] <lifeless> RickCogley: repositories are just for storage optimisation: when making a new branch in a repository from another branch in the same repository no data needs to be copied around
[23:48] <lifeless> RickCogley: this has several implications: many repositories are the norm - every user usually has a repository on their machine
[23:48] <lifeless> secondly, you don't need to worry about them until you are up and running, they are an optional facility.
[23:49] <lifeless> lastly, whether you make one for all your projects, or one per project, is totally up to you.
[23:49] <maxb> Although for performance and disk-space reasons they rapidly become less optional if your project is large
[23:50] <RickCogley> Thanks lifeless and maxb. We are thinking we'd like to have a single central repository so that we can back it up, but I can see that perhaps if you were doing dev for clients, you might want multiple ones to make sure things are kept separate.
[23:50] <lifeless> maxb: yes, but that users having to get it 'right' at the start leads to analysis paralysis
[23:51] <RickCogley> lifeless, ok, so it's kind of "ready, fire, aim" ?
[23:51] <lifeless> RickCogley: the use or not of repositories won't affect backups (except for the size of data: as a new user that is unlikely to worry you for a while)
[23:51] <lifeless> RickCogley: yup. My advice: *completely ignore* repositories for at least a week
[23:51] <lifeless> get used to branching, pushing, pulling, merging
[23:52] <maxb> I'd agree with that for a user. I think a server admin setting up a central server might want to have a think about them up front
[23:52] <lifeless> maxb: ONLY if the admin is already fluent with bzr.
 The *only* reason I want colocated branches is so that I can switch to bzr as my full-time git client. <-- oooooh
[23:52] <lifeless> maxb: otherwise they don't have the context to make the right decisions.
[23:53] <RickCogley> I guess the idea is to just get used to it and you can merge things into a repository later... ?
[23:53] <lifeless> maxb: and as repositories are just storage optimisation, its easy to add them in later, or remove them.
[23:53] <mathrick> and yes, git help whatever takes up way too big a chunk of my time spent interacting with git
[23:53] <RickCogley> lifeless, ok, I see.
[23:54] <lifeless> RickCogley: 'repository' is just a database. If you don't make one, bzr makes one when you run any of 'init' 'branch' 'checkout' 'push'
[23:54] <lifeless> RickCogley: let bzr do that while you learn the user facing concepts and concerns.
[23:54] <lifeless> RickCogley: /none/ of the every day bzr commands manipulate repositories. They all work with 'branches' and 'trees'.
[23:56] <RickCogley> lifeless, so in other words, you make a branch anyway when you check it out of a repository (not yet sure how to do that but...) and then the commands just work on your local copy. ?
[23:56] <lifeless> you can't check out of a repository; its just a database
[23:56] <lifeless> you check out of a branch
[23:56] <lifeless> delete the work repository from your vocab; its not needed.
[23:56] <lifeless> s/work/word/
[23:56] <bialix> mathrick: but do you will miss index?
[23:56] <mathrick> not at all
[23:57] <mathrick> index just gets in my way
[23:57] <mathrick> I use git when I have to, not by choice
[23:57] <RAOF> bialix: For me, the index is an incovenient version of “bzr shelve”
[23:57] <bialix> it seems there are 2 kinds of people: who loves index and who's not
[23:57] <RickCogley> *check out of a branch* *check out of a branch* *check out of a branch* :-)
[23:57] <lifeless> RickCogley: yup :)
[23:57] <bialix> RAOF: is not it's reverse thing?
[23:58] <RAOF> bialix: Which is one of the reasons it's inconvenient :).  Mostly I want to commit my changes.
[23:58] <RAOF> That's the default case.
[23:58] <mathrick> bialix: index is used so rarely it doesn't make sense to make it the central element of everything
[23:58] <bialix> ok ok
[23:58] <RAOF> If I want to take some of my changes out, I'll *explicitly* do so, using a (more powerful) explicit command.
[23:59] <bialix> just too many people around me buzzing how's cool index
[23:59] <mathrick> actually I use the interactive plugin to do most of my change management
[23:59] <mathrick> so I just go bzr ci and pick logical sets of changes until I have zero left
[23:59] <lifeless> poolie: pig
[23:59] <lifeless> sorry!
[23:59] <lifeless> poolie: ping
[23:59] <RickCogley> lifeless, may I ask: what is the strategy if you want to let visitors to a site download the latest version of a script, like a perl or shell script?
[23:59] <bialix> lifeless: !


[12:08] <somerville32> Just finishing my get home routine
[12:09] <somerville32> (ie. check, read, and response to e-mail, check in with people, feed dogs and cats, walk dog, changes into casual clothing, etc. etc.)
[12:10] <jenda> And I'm the 'feed cat' section?
[12:10] <jenda> :)
[12:12] <somerville32> hehe
[03:27] <poningru> anyone know who is working on the install.exe?
[03:29] <somerville32> poningru, Is the channel's stats down?
[03:29] <poningru> stats?
[03:29] <somerville32> Stats, yes
[03:29] <poningru> we have stats?
[03:30] <poningru> where?
[03:30] <somerville32> Aren't you the one who runs the stats page?
[03:33] <poningru> nope
[03:33] <poningru> tonyyarusso: iirc
[03:33] <poningru> at tonyyserver iirc
[03:33] <tonyyarusso> Not any more.
[03:33] <tonyyarusso> I did, but someone else took over.
[03:33] <tonyyarusso> Freenode nick is gouki
[03:33] <tonyyarusso> !stats-#ubuntu-offtopic
[03:33] <ubotu> http://ubuntustats.homelinux.org/ubuntu-offtopic/
[03:34] <crimsun> there was a blurb in UWN 29 about that, no?
[03:34] <somerville32> Right right, gouki
[03:34] <somerville32> You can see how I can confuse that with ponigru, right?
[03:35] <crimsun> oh of course! The 'p' is so similar to a 'g' ;)
[03:36] <poningru> ...
[03:37] <tonyyarusso> they both have an o
[03:41] <somerville32> poningru, Your box is down
[03:42] <poningru> my box?
[03:42] <poningru> blargh
[03:42] <poningru> somerville32, tonyyarusso, jenda do you guys wanna put down a set time for working on UWN?
[03:43] <tonyyarusso> poningru: It would probably be better for UWN, but not necessarily better for me.
[03:43] <poningru> like couple of hours on wednesday, and then couple of hours on saturday
[03:43] <poningru> no we can have it structured so that we dont have to worry about time zone
[03:44] <somerville32> I say tonyyarusso should just write the whole thing for us a week in advance
[03:44] <somerville32> That way we don't have to worry about it
[03:44] <tonyyarusso> uh, no
[03:44] <poningru> as in 6 hours on wednesday broken into like 3, 2hour sessions
[03:44] <poningru> same for saturday
[03:45] <somerville32> My schedule changes weekly
[03:45] <somerville32> I know it seems like I'm always on but still
[03:45] <somerville32> I do do other stuff ;]
[03:45] <crimsun> (as does mine, but I'm quite a small fish)
[03:45] <somerville32> crimsun: Pfft. You make Ubuntu *happen*
[03:45] <crimsun> only when everyone else is sleeping.
[03:46] <poningru> rofl
[03:47] <poningru> see but thats the thing we can just have sessions at particular times so that people can join in if they are busy at the other times
[08:26] <jenda> juliux: ping
[08:26] <jenda> juliux: I've got a winner for that DVD
[08:26] <juliux> jenda, pong
[08:27] <juliux> jenda, great
[08:27] <jenda> juliux: is it dapper or edgy?
[08:27] <juliux> edgy
[08:29] <jenda> shweet.
[08:29] <juliux> did you have the address where to send the dvd?
[08:29] <jenda> not yet
[08:29] <jenda> he's considering donating it to the UK team.
[08:29] <juliux> hehe
[08:31] <jenda> nope, not donating there...
[08:31] <jenda> ...seems it'll be the next quiz's prize, as well.
[08:31] <juliux> hmpf
[08:31] <juliux> jenda, ask him for his address, we have more then 700 edgy dvds here
[08:31] <jenda> hehe :)
[08:32] <jenda> he obviously doesn't either want it, or doesn't want to give his addy to a random IRC guy :)
[08:32] <juliux> lol
[08:34] <jenda> I guess I'll get back to you on this, juliux.
[08:34] <juliux> jenda, ok
[08:34] <jenda> juliux: when's the deadline on the stickers?
[08:34] <juliux> jenda, 14.2
[08:34] <jenda> I think I can guarantee they'll get there by February 9
[08:34] <jenda> cool
[08:34] <jenda> that's my birthday ;)
[08:34] <jenda> wait, not 9 - 11, more like.
[08:34] <juliux> i need them one the weekend of 17/18 february
[08:34] <jenda> cool.
[08:35] <jenda> They'll be there on the 14, for sure.
[08:35] <juliux> thxs
[08:35] <jenda> probably a few days before.
[08:36] <juliux> great
[09:37] <jenda> woo hoo ;)
[09:37] <jenda> welocme.
[09:37] <Vorian> hola!
[09:39] <jenda> muhehe
[10:17] <alefteris> hi everyone! anyone can though some ideas about promoting ubuntu online?
[10:17] <alefteris> any wiki about this?
[10:22] <tonyyarusso> Some, yeah.
[10:22] <tonyyarusso> This has a lot of stuff for offline actually, but http://diy.devubuntu.com/ is cool.
[10:24] <jenda> hehe :)
[10:24] <jenda> it's incomplete, unfortunately.
[10:24] <jenda> alefteris: have a look at wiki.ubuntu.com/DIYMarketing
[10:24] <jenda> it's outdated, though :)
[10:25] <jenda> one incomplete, one outdated...
[10:27] <alefteris> looking more for idea actually of promoting the loco team an dubuntu in our country (online at this stage}
[10:32] <Vorian> wb jenda :)
[10:34] <jenda> thx
[10:34] <jenda> damn ISP
[10:34] <jenda> how long have I been gone?
[10:34] <jenda> (what's the last thing I said?
[10:34] <jenda> )
 looking more for idea actually of promoting the loco team an dubuntu in our country (online at this stage}
[10:35] <Vorian> thats all you missed :)
[10:35] <Vorian> alefteris, what loco team?
[10:36] <alefteris> the greek loco team
[10:36] <Vorian> ah...
[10:36] <alefteris> all we came up is by doing posts in forums
[10:37] <alefteris> and maybe by getting some time in podcasts
[10:37] <jenda> yes - but what did I say last? :)
[10:37] <Vorian> sorry jenda
 one incomplete, one outdated...
[10:38] <jenda> ah, cool
[10:38] <jenda> I actually said all I wanted in this channel :)
[10:39] <jenda> I blabbered for 5 minutes in other channels, thinking i was connected :)
[10:39] <alefteris> :) ok i'll go through alla the website you send me.. thanks jenda


[07:39] <lordievader> Good morning
[10:38] <user|80208> doesn't work sudo apt-get update. It returns errors and ignores
 How are you doing?
[11:45] <BluesKaj> Hiyas all
[21:44] <R13ose> My bluetooth headphones is pairing but no audio is coming out when I play videos.  How do I fix that?


[11:25] <Scary_Guy> morning, how was the gig?
[12:00] <cmaloney> Went well. We had about 35 folks last night
[12:00] <cmaloney> will be cool to see if any return. :)
[13:43] <waldo323> slides (Thanks cmaloney)and video appear to be up: http://www.mug.org/2018/08/august-14th-2018-regular-mug-meeting/
[13:44] <waldo323> video: https://youtu.be/FVPhQYHP_Dc
[13:44] <waldo323> slides: http://www.mug.org/wp-content/uploads/2018/08/hsm.pdf
[14:10] <cmaloney> np. :)
[15:48] <brousch> cmaloney: Did you know zareason is in Detroit?
[17:09] <cmaloney> ?
[17:10] <cmaloney> Headquarters: 333 N. Washington St., Lapeer, MI 48446
[17:11] <cmaloney> I didn't know they were a MI-based company
[17:11] <rick_h_> oooh, lapeer. been there done that
[17:12] <cmaloney> Not sure I'd call Lapeer "Detroit"
[17:12] <cmaloney> unless we're calling Toledo "Detroit" too. ;)
[17:12] <cmaloney> But cool nonetheless
[17:13] <jrwren> lapeer is detroit like flint is detroit. maybe they used to have the same water system?
[17:14] <jrwren> What is zareason
[17:16] <cmaloney> They load Linux on laptops / desktops and sell them
[17:16] <cmaloney> 6. Governing Law. This Agreement and any sales hereunder shall be governed by the laws of the state of California, without regard to conflicts of laws principles, and excluding the United Nations Convention on the International Sale of Goods.
[17:16] <cmaloney> that's interesting
[18:00] <mrgoodcat> lapeer is close enough that lots of people work in detroit
[18:00] <mrgoodcat> does that count?
[18:00] <mrgoodcat> meeting people from flint that work in detroit is not unheard of but also uncommon
[18:00] <jrwren> the foolishness of over-commuters doesn't count for anything more than it is.
[18:01] <cmaloney> hear hear
[18:04] <cmaloney> it always seems like someone wants a reward for their dedication
[18:06] <jrwren> oh it was Marlon last night? last time I came to Mug was years ago when he talked about FB infrastructure.
[18:08] <cmaloney> Yeah
[18:09] <cmaloney> it was his two year return to MI. ;)
[18:10] <jrwren> it was 4 yrs ago that I was there. :)
[18:12] <waldo323> maybe zareason could sponsor us through the use of a machine for recording our meetings more reliably
[18:13] <cmaloney> heh
[18:15] <waldo323> I'd be okay with system76 doing that too
[18:16] <waldo323> I think system76 has more options
[18:18] <cmaloney> Or Purism.
[19:00] <mrgoodcat> zareason sounds like a pizza place
[19:16] <Scary_Guy> "What's Zareason it tastes so good?" "It's in the sauce, man!"
[19:20] <Scary_Guy> https://www.youtube.com/watch?v=EAG7pye0V1g
[19:51] <brousch> The thumb is detroit
[19:51] <brousch> flint is detroit. sagnasty is detroit
[19:52] <brousch> ypsi is detroit, but ann arbor is not. We've been over this
[19:52] <jrwren> lol
[19:52] <brousch> Anyways, yeah, I thought zareason would be a good hook-up for mug
[19:54] <brousch> Yeah, lets call Toledo detroit too. I'm OK with that
[19:55] <jrwren> both toledo and detroit have their own zoos. that is how I know they can't be the same. :p
[20:48] <rick_h_> michigan role okemos with canonical kind of different https://boards.greenhouse.io/canonical/jobs/1076278
[20:50] <jrwren> wow, can you share who is the customer?
[20:50] <jrwren> gotta be TechSmith
[20:51] <rick_h_> I'm not sure tbh. I just got asked by our hiring person if there's any specific MI contacts she can reach out to around that
[21:50] <cmaloney> Okemos?
[21:50] <cmaloney> Whatever it is it's near Lansing
[21:50] <cmaloney> so either govt or Michigan State
[21:58] <brousch> This is the only Okemos company I've encountered. They used to come to the Open Source Group in Lansing many years ago. https://www.covenanteyes.com/
[21:58] <brousch> NVM, it's owosso
[22:04] <jrwren> you all haven't heard of TechSmith? they make really cool software.
[22:04]  * rick_h_ has camtasia on this mac
[22:06] <waldo323> techsmith is from okemos as well right?
[22:07] <waldo323> i should read further up heh
[22:08] <waldo323> last company used their software and I think I got camtasia in a humble bundle not too long ago
[22:59] <cmaloney> jrwren: I don't use Windows or Mac so I don't keep up with that sort of software. ;)


[02:10] <willdeberry> what tool would yall recommend for pulling down latest ubuntu sources, to merge say, into a version of the deb package I am maintaining locally?
[02:36] <tsimonq2> willdeberry: pull-lp-source PACKAGENAME RELEASE
[02:36] <tsimonq2> willdeberry: Example: pull-lp-source vc zesty
[02:37] <tsimonq2> willdeberry: It just has to be the source package, not the binary package from what I remember
[02:37] <willdeberry> ok kewl
[02:37] <willdeberry> and that pulls just raw source, no applied patches or anything?
[02:39] <tsimonq2> Nope, applies the quilt patches
[02:40] <willdeberry> doesn't applying the quilt patches like that break the build process if I were to build the deb from those sources?
[02:42] <tsimonq2> Nope.
[02:43] <willdeberry> so if i am storing in source control, would you recommend keeping the patches applied or undo first? I would assume without the quilt patches applied makes for easier merging
[02:48] <tsimonq2> Unapplied.
[02:56] <willdeberry> tsimonq2: question about https://merges.ubuntu.com/p/procinfo/REPORT
[02:57] <tsimonq2> willdeberry: yeah
[02:57] <willdeberry> i am trying to resolve that issue and am finding that the changes to Makefile.in are still required to resolve build issues. but what i am being stumped on is, shouln't those changes be in a patch file and not to the Makefile.in directly?
[02:57] <willdeberry> was originally addressed: https://bugs.launchpad.net/ubuntu/+source/procinfo/+bug/771106
[02:57] <tsimonq2> What's the output of debian/source/format?
[02:57] <tsimonq2> If it's anything but "3.0 (quilt)" then no
[02:57] <willdeberry> 3.0 quilt
[02:58] <tsimonq2> But if it's that, then yeah...
[02:58] <tsimonq2> hmmm
[02:58] <willdeberry> reason i bring this up is that when i run merge-buildpackage, it complains about local changes
[02:58] <tsimonq2> Yeah, that's interesting...
[02:58] <willdeberry> and i've always been under the impression that you don't touch anything outside the debian directory for quilt packages
[02:58] <tsimonq2> huh
[02:58]  * tsimonq2 gets the package locally instead of speculating :P
[02:58] <willdeberry> lol
[02:59] <Unit193> dpkg-source: info: upstream files that have been modified:  procinfo-2.0.304/Makefile.in
[02:59] <willdeberry> i cam migrate the change to upstream to be a proper quily patch, just wanting to make sure i am not missing somethign
[02:59] <Unit193> No source/format, so yeah.
[03:00] <tsimonq2> Ahhhhhh ok ic
[03:00] <Unit193> (Implied 1.0)
[03:00] <tsimonq2> We followed Debian by having a non-quilt source
[03:00] <tsimonq2> Debian didn't have changes but we did
[03:00] <tsimonq2> So when we apply Debian's change to quilt, we need to put our changes in a patch
[03:01] <tsimonq2> willdeberry: If that makes sense?
[03:01] <willdeberry> so basically move the changes to a patch file and add the new patch to the series file right?
[03:02] <tsimonq2> Yep.
[03:02] <willdeberry> kewl, easy enough
[22:09] <willdeberry> ok, so i am stumped at fixing the merge for procinfo. no matter if i just adjust debian's previous patch file or add a new one and add to series file, i get errors about local changes: https://pastebin.com/spFyzpZf
[22:10] <willdeberry> i can fix the MoM conflict and just use the debian side and everything works fine with i run merge-buildpackage
[22:59] <teward> willdeberry: which package/patch/bug?
[23:01] <teward> *grabs MoM*
[23:03] <Unit193> willdeberry: Does the patch match that of the tmpfile?  It could also be that the patch is applied, it doesn't think so, thus changes.
[23:06] <teward> Unit193: what's the default package type, native or quilt?
[23:06] <teward> because I didn't see a quilt format directive in the package
[23:06] <Unit193> teward: 1.0
[23:10] <teward> mmm
[23:11] <Unit193> Ubuntu's 1.0 is slightly different than Debian's, though both should actually be fine with local changes..
[23:11] <teward> Unit193: i have a quilt patch that 'works' - there's no quilt patches in this package by default, so that's my guess as why it's exploding
[23:11] <teward> Unit193: i've always been told to use quilt :P
[23:11] <Unit193> teward: Well yes, of course.  3.0 (quilt) is what you *should* be using.
[23:16] <teward> how hard is it to convert, just create a quilt patch, and go?
[23:16] <teward> i don't see a format file so hence my asking
[23:20] <willdeberry> teward: sry, was grabbing dinner. this is for procinfo
[23:21] <willdeberry> and after i run grab-merge, i do see a debian/source/format with 3.0 (quilt)
[23:21] <willdeberry> i assume that is Ubuntu delta since it doesn't seem to be in the debian source
[23:23] <willdeberry> Unit193: the tmpfile is actually the opposite of the quilt patch
[23:24] <Unit193> willdeberry: Right, so patch -p1 -R -i /tmp/proc*  and try to build, you'll see the patch you have in the output as 'applying foo.patch'.
[23:25] <Unit193> The paste you gave doesn't contain applying the patch, as you see.
[23:26] <Unit193> So, 1. The state is wrong and it thinks the patch is applied when it isn't.  2.


 :D
[05:25] <zaki> wb RemonShai
[05:25] <RemonShai> ty zaki vai....
[05:26] <zaki> how are you doing?
[05:26] <RemonShai> nothing...
[05:27] <zaki> got your icon?
[05:27] <RemonShai> yea.... its very easy...
[05:28] <zaki> wow. nice
[05:29] <zaki> can i copy them?
[05:29] <zaki> RemonShai: ^
[05:29] <RemonShai> yea, why not??? you also copy image attachment.
[05:30] <zaki> thats your image. ha ha :D
[05:30] <RemonShai> hahahha ... i tell structure...
[05:31] <zaki> oky np
[05:36] <RemonShai> in my wiki, i saw an error. that, when I put cursor on  "RemonShai" (chat client) it show "wiki.ubuntu.com/RemonShai" but now my wiki page "wiki.ubuntu.com/remon"
[05:41] <zaki> unlink that name.
[05:41] <zaki> that is your irc nick. so you dont have to link it with your wiki page.
[05:43] <RemonShai> i do.. but problem is "wiki.ubuntu.com/RemonShai">>> "wiki.ubuntu.com/remon"
[05:43] <zaki> and you used ubuntu logo in top right corner of your phone no. thats not necessery
[05:45] <RemonShai> i noticed, next time it'll give up. (just try, i wanted to sure)
[05:46] <RemonShai> I wanted to unlink irc nick but it must stay there.
[05:51] <RemonShai> zaki, I wanted to unlink just like>> https://wiki.ubuntu.com/tanjim
[05:52] <zaki> oky, hold on,
[05:52] <zaki> see what can i do.
[05:55] <RemonShai> ok bro.... I may go now...
[05:55] <zaki> oky
[06:52] <zaki> wb AudaciousTUX
[06:52] <AudaciousTUX> hello
[06:53] <zaki> how are you doing?
[06:56] <AudaciousTUX> backpain in this age :3
[06:57] <zaki> i have that sometime . :3
[07:04] <AudaciousTUX> :'(
[07:32] <zaki> hei Kilos
[07:32] <zaki> how are you?
[09:08] <zaki> bbl
[09:27] <Kilos> hi zaok ty and you, just cold again
[15:53] <pavlushka> Greetings every one :)
[16:03] <Nahiyan> yo
[16:05] <pavlushka> Nahiyan: yo yo :)
[16:06] <pavlushka> brb
[17:09] <pavlushka> welcome Tanzeem  :)
[17:09] <pavlushka> yea...
[17:09] <Tanzeem> thanks
[17:20] <pavlushka> Tanzeem: if you need any help any time , we are here, otherwise, help us :p
[17:21] <Tanzeem> what you mean by help?
[17:22] <pavlushka> mostly GNU/Linux related :p
[17:23] <pavlushka> you know like Ubuntu :)
[17:23] <Tanzeem> GNU? Linux?
[17:23] <Tanzeem> no
[17:23] <Tanzeem> what is this?
[17:25] <pavlushka> These are free and open OS unlike other proprietary OS :)
[17:26] <Tanzeem> ok
[17:27] <pavlushka> Tanzeem: what system you use in your PC?
[17:27] <Tanzeem> laptop
[17:27] <Tanzeem> why?
[17:28] <pavlushka> Tanzeem: just like to know, I use Xubuntu mostly :)
[17:28] <Tanzeem> Xubuntu mean?
[17:37] <pavlushka> Tanzeem: Ubuntu derivative which uses xfce desktop environment :)
[17:38] <pavlushka> It comprises like X-Ubuntu or Xubuntu :)
[17:39] <Tanzeem> i dont know about these softwares
[18:07] <pavlushka-> He ha he ha
[18:07] <pavlushka-> See ya guys :p
[20:06] <zaki> hello
[20:07] <zaki> hi pavlushka
[20:07] <pavlushka> zaki: oh my, how come you be this late?
[20:16] <zaki> pavlushka: missed your last reply
[20:17] <pavlushka> zaki: oh my, how come you be this late?
[20:17] <zaki> and also got your memo. how do you find him!
[20:17] <zaki> just arrived home 50 mnt ago
[20:21] <zaki> :|
[20:22] <zaki> pavlushka:
[20:22] <pavlushka> zaki: yes :)
[20:22] <zaki> now habing problem with my pc.
[20:24] <zaki> behaving weird
[20:30] <pavlushka> zaki: sorry I am feeling very sleepy, we can see it tomorrow :)
[20:30] <pavlushka> Night night :)
[20:30] <zaki> oky than.