19:01:17 <lamby> #startmeeting
19:01:17 <MeetBot> Meeting started Mon Oct 17 19:01:17 2016 UTC.  The chair is lamby. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:27 <lamby> Great, let's start
19:01:33 <lamby> First up
19:01:51 <lamby> Can everyone present say hi? :)
19:01:56 <deki> hi
19:01:58 <danielsh> hi
19:02:01 <lamby> Brief introduction if you like :)
19:02:06 <neverpanic> hi
19:02:10 <StevenC99_> hallo
19:02:11 <anthraxx> hihi
19:02:15 <devrandom> hi all, I'm the creator of https://github.com/devrandom/gitian-builder -
19:02:17 <vagrantc> hi
19:02:18 <spectranaut> hello
19:02:23 <dkg> hi
19:02:24 <teh__> hi, I'm contributing to nixos)
19:02:33 <jbisch> hi - I occasionally contribute to gitian-builder
19:02:36 <lynxis> hi devrandom, we starting in a second the meeting. glad to have you here. let's talk later.
19:02:50 <ossguy> this is Denver from Software Freedom Conservancy, interested in reproducible builds for making GPL compliance easier
19:02:51 <devrandom> lynxis: I'm here for the meeting
19:02:59 <lamby> devrandom: neat :)
19:03:17 <mapreri> hi
19:03:22 <dkg> ossguy: interesting, if we don't cover that topic in this meeting, i'd be happy to talk more about it with you later.
19:03:26 <neverpanic> ossguy: interesting, let's talk about that later.
19:03:26 <lamby> Great to see so many folks.
19:03:34 <ossguy> sounds good :)
19:04:17 <lamby> I hope to crack through the topics as quick as possible so we are all done by the hour; we can always revisit things later / at the end / offline, etc. so don't feel your issue is being pushed "away" - it's just the meeting is being pushed "along" :)
19:04:34 <dkg> lamby: thanks for keeping it moving, i'm sure everyone here has other things to do too :)
19:04:57 <lamby> Next up; h01ger sends apologies- he cannot make this meeting time. We will find some solution to this but, alas, not this week.
19:05:46 <lamby> Next; the blog post schedule. Last time we talked about the blog posts wrt not enough time to review, etc. We left it so that there would be at least 24h review time with mail announcements.
19:05:50 <lamby> How was that for everyone?
19:06:02 <vagrantc> lamby: also, to formalize topic changes i think using #topic helps with meetbot formulating a summary of the meeting
19:06:34 <lamby> thanks
19:06:35 <ng0> hi, sorry i just cmae in. i contribute to guix, gnunet, and secushare and will probably just listen/read :)
19:06:37 <lamby> #topic Blog post schedule
19:06:52 <lamby> http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20161010/007256.html was an example of an announcement
19:07:09 <vagrantc> the 24 hour + email worked well for me ... i managed to make some minor changes and additions
19:07:10 <lamby> hi ng0, no problem, no problem. Great to see you.
19:07:32 <lamby> no infinity0 here, alas, so we can't ask whether that writing schedule worked for him.
19:07:38 <infinity0> sorry i'm here
19:07:41 <infinity0> just replying to that docutils guy
19:07:51 <infinity0> what's the topic?
19:07:59 <lamby> please read last 15 lines of scrollback
19:08:14 <StevenC99_> or, the topic :p
19:08:14 <vagrantc> or /topic :)
19:08:49 <lamby> Just on the write→review→publish angle, not the "which day it actually gets published" angle. (yet)
19:09:30 <lamby> It worked for me, so if it works for you without big problems, we can just continue with that for another fortnight or so.
19:09:57 <dkg> fwiw, i think the write, review, publish sequence is the only sensible one (though i failed to get in on the 24h review window myself)
19:10:09 <lamby> ie. you would like a longer window
19:10:13 <dkg> no!
19:10:18 <dkg> i would like to be offline more :)
19:10:22 <lamby> oh haha
19:10:48 <lamby> infinity0: I'm going to move the topic on, lots of things. Lets revisit at the end if time; it seems you are busy with docutils atm. :)
19:10:50 <dkg> if it's a predictable window, i can (usually) schedule time to do a review
19:10:59 <dkg> and if i miss that, it's my own fault
19:10:59 <lamby> #topic IRC meeting schedule review
19:11:18 <lamby> So, I chose the time based on the poll I sent, picking the "best" time from the responses.
19:11:20 <infinity0> yo finished, wassup
19:11:31 <infinity0> i also wrote the blog post, i will post a mail about that or you can get it from git now
19:11:33 <lamby> infinity0: please read scrollback.
19:11:40 <infinity0> ah ok
19:12:34 <lamby> It's a little pointless to ask how this IRC time is for people /present/, so this does not seem very actionable.
19:12:44 <lamby> Unless people have any general concerns?
19:12:56 <lamby> I see ("business hours Europe") in the agenda; can anyone speak to that?
19:13:11 <vagrantc> i know holger requested european business hours or some such, which is reasonable, though i suspect that will be hard for me
19:13:27 <danielsh> lamby, h01ger suggested to do a new poll with more options.
19:13:44 <lamby> Happy to do that
19:13:44 <danielsh> Not just evening Europe/UTC time but also other parts of the 24hr cycle.
19:13:59 <vagrantc> yeah, a wider range of options would maybe give a more full picture
19:14:01 <danielsh> As you say though, we need to take this to the list so people who are absent can discuss.
19:14:19 <lamby> of course, a poll would be sent to the list… obviously :)
19:14:20 <lamby> #action lamby to create another IRC poll with more options
19:15:06 <danielsh> (Is the bot supposed to ack that command?)
19:15:06 <lamby> The result could be something "like" this one, so that seems the simplest and easiest way forward.
19:15:17 <vagrantc> i wonder if a broad-strokes approach would be good to get a general meeting time?
19:15:27 <lamby> danielsh: Dunno, it will be in scrollback/log if not so no harm
19:15:27 <vagrantc> e.g. ranges of 2-3 hours rather than hour by hour
19:15:46 <dkg> vagrantc: doodle polls with every hour of every day offered are pretty miserable
19:15:53 <vagrantc> dkg: exactly
19:16:16 <vagrantc> this poll was pretty intimidating, and didn't even really hit a very broad range of hours
19:16:17 <lamby> Miserable to enter, but the data is nicer. I'll look for a nicer interface at the very least, but getting hour-data is kinda useful.
19:16:28 <infinity0> we could do it at different times each week, regularly of course
19:16:41 <infinity0> so e.g. 1 week at 9am and 1 week at 5pm, etc etc
19:16:44 <dkg> irreproducible meetings for reproducible builds ;)
19:16:50 <infinity0> it's reproducible :)
19:16:55 <dkg> i know, i know :)
19:17:03 <lamby> Let's fallback to that; I'd rather it be kept as simple as possible. We clearly have enogh schedule problemas at it is.
19:17:25 <lamby> Right 25% of the way in and it's been all meta nonsense, let's move on with that action item unless there is big disagreement? ^
19:17:34 <danielsh> May be easier to ask people to write in their preferred options (as an open question).  At least as an initial step.
19:17:37 <danielsh> +1 move on
19:17:39 <vagrantc> lamby: sounds good to me
19:17:47 <mapreri> [07:15:10 PM] <danielsh> (Is the bot supposed to ack that command?)
19:17:50 <mapreri> no, it doesn't
19:17:52 <dkg> i think making it clear that the IRC channel is always open, and that meetings are minuted might help get people past fear of missing meetings
19:18:00 <lamby> danielsh: Hah, yeah just asking. Or, screw it, they reply with text and I do the manual labour. :3
19:18:04 <neverpanic> As a suggestion: It may be helpful to minimize the number of unavailable people rather than maximize the number of available people
19:18:06 <lamby> dkg: great point.
19:18:15 <lamby> neverpanic: Interesting…
19:18:16 <neverpanic> (Of course that only makes a difference for two different appointments)
19:18:18 <lamby> Right
19:18:23 <lamby> #topic IRC notifications review
19:18:25 <lamby> background is:
19:18:54 <lamby> We moved a bunch of ""noisy"" IRC messages from test framework bots from #debian-reproducible to #debian-reproducible-changes
19:19:12 <lamby> This was requested as it was "getting in the way of conversation" etc.
19:19:26 <lamby> (It's about ~1000 lines per day or something)
19:19:39 <lamby> How did people feel about this change?
19:19:58 <deki> the channel feels quieter now :)
19:19:59 <vagrantc> works for me
19:20:10 <lamby> Personally, I like how it makes both #debian-reproducible more useful /and/ it makes #debian-reproducible-changes a really useful resource for /lastlog etc.
19:20:14 <mapreri> great for me too.
19:20:25 <infinity0> +1 me
19:20:34 * dkg likes
19:20:48 <lamby> deki: A real criticism? I mean, philosophically-speaking robots shouting aren't really making "noise" :)
19:20:54 <mapreri> btw, h01ger later also removed the automatic package scheduling from IRC and only via email to qa-jenkins-scm (which nobody but me and him are in).
19:21:12 <lamby> deki: genuinely curious, despite my joke there
19:21:14 <mapreri> do anybody feel the loss?
19:21:14 <deki> lamby: i didn't mind the notifications, but i can see that other people are annoyed
19:21:28 <lamby> getcha
19:21:39 <lamby> mapreri: No.
19:21:50 <lamby> I like the manual notifications staying on #debian-reproducible
19:21:51 <mapreri> dkg: you're not even in the channel, how could you say? ;)
19:22:00 <lamby> …as it's human generated
19:22:10 <mapreri> lamby: I think nobody is proposing/thinking of moving/removing them.
19:22:10 <danielsh> lamby, +1
19:22:24 <lamby> mapreri: Yap, just adding my thoughts re. getting the balance right
19:22:35 <lamby> Okay, I'm going action we keep doing what we are doing until the next meeting
19:22:37 <vagrantc> lamby: yeah, manual seems reasonable
19:22:57 <lamby> #action keep IRC notifications as they are but briefly review at next meeting
19:23:17 <lamby> (ie. #debian-reproducible → human generated stuff,  #debian-reproducible-changes → computer generated stuff)
19:23:20 <lamby> right
19:23:29 <lamby> #topic reproducible-tracker.json
19:23:53 <lamby> Anyone want to run this item? I only half understand it.
19:24:21 <lamby> mapreri: was this one of yours? (Sorry, I know you are juggling plates atm!)
19:24:26 <mapreri> nope
19:24:33 <mapreri> except that I know it's broken.
19:25:12 <lamby> ISTR some commits a few days ago, I assume its still broken.
19:25:17 <mapreri> basically the problem is that h01ger wanted to have it shown testing data as unstable data is borked by too many build-path variations
19:25:22 <lamby> ah.
19:25:25 <mapreri> ddpo didn't like the change
19:25:43 <lamby> DDPO the code or DDPO the people?
19:25:58 <mapreri> one solution would be to revert it and only filter out packages with a note saying it's unreproducible due to build-path, but it need a bit of code
19:26:01 <lamby> Doesn't the rest of DDPO essentially imply unstable?
19:26:08 <mapreri> exactly.
19:26:14 <lamby> Hm.
19:26:23 <lamby> I don't like the idea of filtering certain issues either.
19:26:33 <lamby> We should "just" fix build-path. :3
19:26:37 <danielsh> It would make sense to filter out infrastructure issues, perhaps?
19:26:45 <mapreri> danielsh: we already do that.
19:26:55 <danielsh> status: { OK | non-reproducible due to dependencies | non-reproducible due to itself }
19:27:04 <mapreri> (e.g. blacklisted packages are not in reproducible-tracker.json)
19:27:22 <mapreri> that's impossible to detect automatically and I wouldn't dare to do manually
19:27:26 <danielsh> mapreri, captures_build_path is sometimes an infrastructure issue and sometimes a local problem,
19:27:38 <lamby> It starts to get a bit too complicated - dashboards like DDPO are meant to be consumable at a glance; ie you know exactly what it means from Just Looking.
19:27:43 <danielsh> Of course not automatically.
19:28:11 <danielsh> But we have some sub-issues of captures_build_path now, so we can classify _those_ as "infrastructure" or "specific to the package".
19:28:32 <mapreri> lamby: h01ger wanted to avoid having it shown data that meant nothing to maitnainers, as it would be mostly not actionable
19:28:54 <lamby> (To clarify, because build-path is not actionable by maintainers?)
19:29:13 <lamby> background here for lurkers is that in unstable only we vary the build-path when testing reproducibility of packages.
19:29:19 <vagrantc> individual maintainers fixing it in individual packages may not be the best use of maintainer time
19:29:22 <danielsh> For example, golang_compiler_captures_build_path_in_binary is an infrastructure issue
19:29:23 <mapreri> I guess mostly because it's a issue that we want to fix in gcc?
19:29:25 <lamby> ^ this makes a lot of packages unreproducible
19:29:39 <mapreri> gcc or whatever other compiler
19:29:48 <lamby> ^ and the dashboard is saying "your package sucks", when it's not really their fault
19:30:03 <mapreri> that is the idea
19:30:32 <vagrantc> it does run the risk of maintainers starting to ignore those annoying noisy reporudiclbe builds things if there's really not much they can do
19:30:45 <lamby> I'm not really sold on this; it seems like a lot of categorisation required, both on the package side /and/ in the categorisation of the issues…
19:31:43 * vagrantc nods
19:31:45 <infinity0> it's useful if someone wants to put in the effort for sure
19:31:51 <infinity0> however i would wait until after my GCC patch lands
19:32:04 <infinity0> hopefully it will drop it from 2k to a few hundred, and there's no need to categorise all the gcc stuff
19:32:14 <lamby> Mmm. It also /encourages/ that GCC patch to land, if you see what I mean. :)
19:32:21 <lamby> How can we move forward here? I feel like without h01ger we cannot have a concrete action item beyond "do nothing"
19:32:31 <mapreri> agree
19:32:34 <infinity0> do what sorry? categorise vs not categorise?
19:32:47 <vagrantc> exclude them from reproducible-tracker.json?
19:32:52 <mapreri> lamby: I'd be open to a ML thread, if anybody wants to start and lead it.
19:33:13 <lamby> mapreri: Can I action you for that? Just to start it.  (great idea)
19:33:24 <mapreri> not really, if I could avoid it…
19:33:32 <lamby> Just copy-paste some of the above :)
19:33:53 <mapreri> pfff, ok, you bought me.
19:33:58 <lamby> Neat
19:34:02 <lamby> #action mapreri to start ML thread regarding reproducible-tracker.json
19:34:09 <lamby> thanks
19:34:10 <lamby> hi civodul !
19:34:21 <lamby> #topic meeting logs archive
19:34:21 * mapreri learned: never propose so clearly something you don't want to do.
19:34:30 <lamby> (this will be done via meetbot. enough meta stuff!)
19:34:30 <infinity0> lol
19:34:37 <lamby> #topic Summit
19:34:39 <civodul> hi lamby :-)
19:34:47 <lamby> * December 13-15 2016 (9 AM to 5 PM)
19:34:50 <infinity0> https://hack.rs/wv.jpg :)
19:35:05 <lamby> * Berlin, Germany
19:35:08 <lamby> * Holzmarkt
19:35:17 <vagrantc> #info December 13-15 2016 (9 AM to 5 PM)
19:35:26 <lamby> Please book your travel/accomodation ASAP to save money
19:35:31 <vagrantc> #info Berlin, Germany, Holzmarkt
19:35:38 <vagrantc> lamby: done!
19:35:40 <lamby> Personal announcement mails with more details coming Real Soon Now
19:36:06 <vagrantc> er, hrm. still need to figure out accomodation
19:36:08 <lamby> You will also be subscribed to a low-volume mailing list. Should be opportunity to share accomodation via that list.
19:36:44 <lamby> Ideally you should arrive on the Monday evening (and leave no earlier than the 5pm)
19:37:09 <lamby> Any questions on the summit? Anything blocking people pressing "go" on flights, for example?
19:39:11 <lamby> Cool!
19:39:24 <lamby> #topic Issue tracker for reproducible-builds
19:39:54 <lamby> So, the general problem is that we have a bunch of tasks that aren't strictly Debian-related and we don't want to put them in the Debian BTS
19:40:05 <lamby> … because we are a cross-distribution initiative.
19:40:31 <lamby> But, then again, we don't want to have /another/ issue tracker in our lives.
19:40:35 <lamby> Any thoughts?
19:40:42 <infinity0> there is something called ditz that lets you track issues in a git repo
19:40:45 <danielsh> Create a git repository with one file per issue?
19:40:50 <lamby> These are for things like the reproducible-builds.org website issue
19:40:51 <infinity0> but i think it is discontinued these days. we could look for another similar one though
19:40:54 <danielsh> Until we outgrow that, anyway.
19:41:07 <lamby> Yeah, some kind of git thing could work, certainly at the scale we are talking about.
19:41:16 <lamby> Even if just Plain Text!
19:41:25 <mapreri> also I would oppose to use the qa.debian.org pseudopackage in the BTS, cause that's already quite crowded with a shitload of subprojects and things would get messy, and also annoy the lot of peopel in debian-qa@ that are not interested in partecipating in our stuff.
19:41:46 <mapreri> saying this because I read h01ger saying something about this earlier today, don't remember the context.
19:41:56 <mapreri> but I'd love a git thinghy, yes \o/
19:42:10 <infinity0> http://ditz.rubyforge.org/ they use themselves for tracking issues about themselves, heh
19:42:19 <infinity0> no updates since 2011 tho :( i always thought it was a cool idea
19:42:45 <lamby> I think there are a bunch of similar things.
19:42:53 <danielsh> There's fossil (distributed SCM/issue tracker from sqlite)
19:42:59 <neverpanic> just wanted to mention fossil
19:43:05 <lamby> Does anyone want to look into that, or should we just try with plain text and see what our needs actually are?
19:43:14 <lamby> Currently there would only be, like, 10 issues anyway.
19:43:33 <infinity0> i think with plain text we would quickly get into bikeshedding about preferred ways to format text etc
19:43:46 <infinity0> i can do some research over the next few days
19:43:58 <vagrantc> well, we're already issue a particular yaml format for tracking reproducibility issues
19:44:10 <mapreri> danielsh, neverpanic: fossil looks like a full blown SCM?  I'm not eager to learn another scm thinghy.
19:44:20 <ng0> fossil can be.. tricky
19:44:23 <lamby> infinity0: Thanks!
19:44:34 <danielsh> mapreri, Yes it's a full blown SCM.  I never used it though, don't know how separable the issue tracking is.
19:44:45 <danielsh> I still vote for just plain text
19:44:56 <lamby> #action infinity0 to look into a git-based issue tracker for reproducible-builds
19:44:57 <danielsh> We're all adults enough to not get into bikesheds...
19:44:59 <deki> i also think plain text is sufficient for now
19:45:05 <lamby> danielsh: hahaha
19:45:06 <mapreri> I wonder if something like taskwarrior could be used in shared mode.
19:45:12 <mapreri> danielsh: LOL
19:45:29 <lamby> I like this danielsh guy. He's funny. :)
19:45:35 <danielsh> mapreri, taskwarrior has some of "synchronize" mode...
19:45:44 <danielsh> I assume one could set up a server with one client per user
19:45:50 <lamby> Let's roll with that and see how we get on. We can always move; hardly going to be a big migration :)
19:45:58 <mapreri> danielsh: yes, but what about sharing that db, would that blow up?
19:46:02 <lamby> #topic libreplanet
19:46:05 <infinity0> ok i'll take a look at taskwarrior too. serverless would be ideal thouh
19:46:08 <mapreri> 15 minutes to go!
19:46:14 <lamby> indeed mapreri
19:46:24 <lamby> Anyone add this item?
19:46:26 <danielsh> mapreri, No idea.  Not familiar with taskwarrior sync features.
19:46:33 <lamby> (libreplanet call for proposals)
19:46:55 <lamby> spectranaut: You are in that neck of the woods; are you planning on submitting?
19:47:12 <lamby> * LibrePlanet
19:47:17 <mapreri> "neck of the woods"?
19:47:18 <mapreri> :)
19:47:19 <spectranaut> I wasn't planning on submitting.. it's next spring?
19:47:31 <lamby> yes. The deadline is november 14th
19:47:35 <deki> i think vagrantc mentioned something about it?
19:47:42 <vagrantc> yeah
19:47:48 <ng0> spectranaut: beginning of february
19:47:52 <lamby> hence some co-ordination on the submission (no obvious dupes at the very least) would be a good idea!
19:47:55 <spectranaut> oh vagrantc -- come!
19:47:55 <vagrantc> i'm hoping to go ...
19:48:03 <spectranaut> you should submit
19:48:10 <vagrantc> i have another even the weekend before or after it, so two reasons to go
19:48:15 <vagrantc> event
19:48:37 <lamby> We can submit multiple things, just need to co-ordinate (some) lack of crossover IME.
19:48:43 <vagrantc> exactly
19:48:55 <lamby> Can I action you both to talk about that offline and send a followup to the ML?
19:49:03 <vagrantc> works for me
19:49:09 <spectranaut> sure :)
19:49:20 <lamby> I'm thinking of the case where neither of you end up submitting (for good reasons) and then nobody else does!
19:49:51 <lamby> #action vagrant and spectranaut to liase re. CfP for LibrePlanet (deadline nov 14th)
19:49:56 <lamby> thanks :)
19:50:11 <lamby> mapreri: Apologies, too many englishisms sometimes…
19:50:13 <vagrantc> march 24th/25th, fwiw
19:50:20 <lamby> … hopefully they are understood
19:50:22 <vagrantc> er, 25th/26th
19:51:05 <lamby> #topic Next IRC meeting time
19:51:15 <lamby> ^ will be clarified after poll, just adding here for completeness
19:51:20 <lamby> #topic any other business
19:51:26 <lamby> Particularly from lurkers, etc. :)
19:51:54 <neverpanic> Here's a patch to add Berlin 2016 to the website: https://p.dnnr.de/pS2cOjE9tj2dHbIM
19:51:58 <neverpanic> Where would I put that?
19:52:32 <mapreri> in the rb-general@ ML for review, I'd say.
19:52:40 <lamby> neverpanic: \o/
19:52:41 <mapreri> so it can be reviewed before putting it live
19:52:50 <mapreri> oh
19:52:52 <teh__> just two quick questions: 1/ what's capture_build_path and 2/ what's the gcc patch that would fix a lot?
19:52:52 <neverpanic> #action neverpanic to send patch putting Berlin 2016 on the website to rb-general@
19:53:05 <mapreri> neverpanic: that's not linked in the events page, right?
19:53:11 <neverpanic> mapreri: it will be automatically
19:53:13 <mapreri> or is there some jekill magic?
19:53:19 <mapreri> magic will be, then :)
19:53:24 <lamby> teh__:  "capture_build_path" the idea or "capture_build_path" the presumably-special underscored named?
19:53:25 <danielsh> teh__, Packages that hardcode the absolute path of the source directory in the compiled artifact
19:53:53 <infinity0> teh__: GCC patch is this (WIP) https://wiki.debian.org/ReproducibleBuilds/BuildPathProposal and this (also WIP) https://gist.github.com/infinity0/72aba22411a2e8baaae4649329f96643
19:53:55 <teh__> the idea I guess :) - thanks danielsh
19:54:06 <lamby> For more backgroundd, we categorise all the issues we know about here:
19:54:09 <lamby> https://anonscm.debian.org/git/reproducible/notes.git/plain/packages.yml
19:54:36 <lamby> So "capture_build_path" is our enum for that particular issue.
19:54:51 <lamby> https://tests.reproducible-builds.org/debian/index_issues.html  it's quite "popular"
19:54:55 <teh__> thanks!
19:55:24 <infinity0> ouch, 3.4k now
19:55:56 <mapreri> another business: I grow quite accustomed to listadmin, so if there is still need of a ML admin for the MLs at lists.r-b.o I can take them over.  do you know something about this?
19:56:03 <mapreri> grown*
19:56:17 <infinity0> same, +1 for listadmin such a time saver
19:56:37 <infinity0> https://packages.debian.org/sid/listadmin in case anyone is wondering
19:56:37 <lamby> I have access to that. It is not much admining, or at least I don't get many notifications for action required.
19:57:13 <mapreri> if it's not needed I'll just be happy with the number of MLs I have already
19:57:33 <lamby> Cool.
19:57:35 <mapreri> infinity0: I would love if all mailman servers had spamassasin installato.
19:57:42 <mapreri> installed* -.- (sorry)
19:57:52 <lamby> Any other questions? Nothing "too silly", etc.
19:57:54 <lamby> :)
19:57:55 <infinity0> bro with listadmin you just hit enter enter enter i do dat in my sleep
19:58:21 <mapreri> yeah, but it's so boring to hit return like 50 times per day :(
19:59:27 <vagrantc> lamby: don't forget to #endmeeting :)
19:59:41 <mapreri> time's not yet up!
19:59:44 * vagrantc nods
19:59:47 <mapreri> 10 secs
19:59:55 <lamby> Thanks all for a great meeting. I'll send the poll out soon.
19:59:57 <lamby> #endmeeting