14:02:21 <Stskeeps> #startmeeting Mer bug triage 9/1/2011
14:02:21 <MerBot> Meeting started Mon Jan  9 14:02:21 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
14:02:21 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:32 <Stskeeps> #info From next week, we have this meeting at 12:00 UTC instead
14:02:49 <Stskeeps> we'll be going through this bugzilla search: https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailtype1=substring
14:03:15 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=76 - Bug 76 - Update zypper to latest upstream version
14:03:34 <Stskeeps> lbt, will you do the honors of setting the bug flags etc as we go?
14:03:46 <lbt> hehe .... was just typing that
14:04:00 <Stskeeps> i think this one should be a task, with high priority
14:05:08 <Stskeeps> any objections?
14:05:17 <lbt> nope ... any takers yet?
14:05:31 <lbt> "not-taken" then
14:05:54 <lbt> as per http://wiki.merproject.org/wiki/Bug_Lifecycle#Triage  ?
14:05:57 <Stskeeps> right
14:06:09 <lbt> done
14:06:31 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=91 - Bug 91 - Mer build/versioning policy needs clarification
14:06:43 <Stskeeps> medium, we'll discuss a bit direction of it in release management meeting tomorrow?
14:06:46 <Stskeeps> and should be a task
14:07:14 <lbt> I'll take, cc you
14:07:18 <lbt> Sage: cc you too?
14:07:40 <lbt> (yes)
14:08:14 <lbt> err... done
14:08:27 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=95 - Bug 95 - Mer package signing is not implemented
14:08:50 <Stskeeps> same, task, medium, -> "Implement Mer package signing in release process"?
14:09:04 <Stskeeps> discuss tomorrow
14:09:10 <lbt> OK, that works
14:09:15 <lbt> medium or high
14:09:37 <Sage> lbt: sure
14:10:07 <Sage> Stskeeps: :nod:
14:10:22 <Stskeeps> medium, i guess, since it needs to be done correctly and thought about, not a high prio rush job :)
14:10:56 <lbt> mmm ... high means "start soon", not "finish soon"
14:11:11 <Stskeeps> mm, true
14:11:12 <lbt> and "stop procrastinating about it"
14:11:16 <Stskeeps> ok, high then
14:11:37 <lbt> *totally* agree on thinking it through... it's why I've never set one up :)
14:11:48 <Stskeeps> ok, moving on to not-taken bugs
14:11:50 <lbt> not-taken for a bit
14:11:52 <Stskeeps> #topic not-taken bugs:
14:12:05 <Stskeeps> https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken&emailtype1=substring
14:12:47 <lbt> mm
14:12:55 <lbt> maybe we should do this first next time :)
14:13:04 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=34 - Bug 34 - python randomly fails to build
14:13:14 <Stskeeps> nah, some of them are pretty important to get taken :P
14:13:36 <Stskeeps> this one, we need someone to investigate what graminit.c is initialized from - it looks autogenerated or it wouldn't crash each time
14:13:57 <Stskeeps> there are multiple potential reasons why it randomly breaks: make -j too high, or sort ordering in file system somehow being off at times
14:14:09 <Stskeeps> any takers to look into what causes it?
14:14:49 <vgrade> \o
14:14:55 <Stskeeps> alright
14:15:00 <Stskeeps> #info assign to vgrade
14:15:12 <Stskeeps> vgrade: if you have any questions with it, feel free to prod me naturally
14:15:16 <Stskeeps> it is difficult to chase
14:15:39 <vgrade> thanks
14:15:46 <lbt> assigned
14:16:10 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=73 - Bug 73 - ofonod segfaults at boot on N900
14:16:34 <Stskeeps> we have backtraces now
14:16:57 <Stskeeps> #1  0x00074364 in ofono_dbus_signal_property_changed (conn=0xea1220, path=<value optimized out>, interface=0xccd88 "org.ofono.NetworkOperator",  name=0x0, type=115, value=0xbe8525f4) at src/dbus.c:193 seems wrong
14:17:12 <Stskeeps> (see the 0x0?)
14:18:08 <Stskeeps> any takers?
14:19:48 <Stskeeps> alright, since no takers for the bug we'll leave it at not-taken@
14:20:08 <lbt> prio change?
14:20:22 <Stskeeps> seems correct to me
14:20:32 <Stskeeps> maybe critical since it's a crash
14:20:51 <lbt> critical prevents device from booting iirc
14:21:05 <Stskeeps> mm
14:21:09 <lbt> "major 	major loss of function"
14:21:12 <lbt> I guess
14:21:15 <Stskeeps> ok, major then
14:21:31 <lbt> I assume the rest of the device stays up :)
14:21:55 <lbt> (just making sure we use the values as per definition - or change the definition)
14:22:01 <Stskeeps> right, that's the end of the list for today
14:22:18 <Stskeeps> i think we should possibly have another meeting to help prioritize unprioritized tasks
14:22:23 <Stskeeps> https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=task&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=need-triage&emailtype1=substring
14:22:40 <lbt> that should be a one-off shouldn't it
14:23:00 <Stskeeps> hmm?
14:23:19 <lbt> all tasks should be given a prio in triage
14:23:34 <lbt> so sure, we need to do this... but only once (hopefully)
14:23:53 <Stskeeps> think it's a continous evaluation of tasks
14:23:56 <lbt> (btw.... most of them need re-assigning to not-taken)
14:23:59 <Stskeeps> yes
14:24:29 <lbt> all I'm saying is that that search will be empty most of the time
14:24:40 <Stskeeps> true
14:24:51 <lbt> but I was going to add that we should be looking to review prio of not-taken regularly
14:25:00 <Stskeeps> yes
14:25:01 <lbt> which may be the same goal :)
14:25:31 <lbt> is now good?
14:26:20 <Stskeeps> i vote to switch to not-taken@ all of them and then review them, i guess
14:26:25 <lbt> OK
14:26:43 <Stskeeps> i'll do that..
14:26:48 <lbt> nah
14:26:50 <lbt> wait
14:27:04 <Stskeeps> (there's a change multiple bugs functionality)
14:27:08 <lbt> it's processing
14:27:12 <lbt> yes, using that
14:27:24 <lbt> done
14:27:26 <Stskeeps> k
14:27:38 <lbt> *g* shows how slow our bz is
14:28:14 <Stskeeps> ok, https://bugs.merproject.org/buglist.cgi?priority=High&priority=Normal&priority=Low&priority=Undecided&emailassigned_to1=1&query_format=advanced&bug_severity=task&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken&emailtype1=substring then
14:29:07 <Stskeeps> #topic Task priority triage
14:29:27 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=15 - Bug 15 - Switch from libjpeg to libjpeg-turbo
14:29:38 <Stskeeps> i'd say high priority, as there is significant performance benefits in this
14:29:41 <Stskeeps> especially on ARM systems
14:29:44 <Stskeeps> and on SSSE3 systems
14:29:49 <lbt> sec... that's only 'tasks'
14:29:50 <lbt> https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken&emailtype1=substring
14:31:02 <Stskeeps> mmkay
14:31:15 <Stskeeps> any objections to high?
14:31:35 <Stskeeps> or takers (anyone who wants to do it), for that matter?
14:32:20 <lbt> (FYI I'm not going to take until my list is smaller)
14:32:29 <Stskeeps> ok, if anyone wants to take a task, just raise a hand as we go :)
14:32:32 <Stskeeps> #info high
14:33:05 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=19 - Drop GL support from Mer Core
14:33:06 <lbt> I'm adding a note to the bug - feedback to OP that there is activity
14:33:34 <Stskeeps> low priority, it's not really harming anyone at the moment, but it's a nice thing to do to make packaging story simpler
14:33:39 <Stskeeps> and APIs in use
14:34:34 <lbt> done
14:34:35 <Stskeeps> #info low
14:34:47 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=26 - Evaluate dash as /bin/sh vs /bin/bash, disk/memory footprint/boot time/impact
14:35:08 <Stskeeps> medium, as it's a bit of a cost vs benefit thing, would be useful to see what we would actually gain on it
14:35:15 <Stskeeps> architectual backlog, FWIW
14:35:36 <Sage> btw, that Drop GL is need info. Solution exists if decision is made.
14:35:40 <Stskeeps> i'm also pondering if we can support dual stack Mer, one with gnu utilities, one with busybox
14:35:43 <Stskeeps> ok
14:36:00 <lbt> how do you want to mark architectural backlog ?
14:36:09 <Stskeeps> project-core severity=task is architectual backlog
14:36:24 <Stskeeps> just letting you know it's in that category
14:36:41 * lbt reaches for the wiki
14:37:04 <Stskeeps> #info medium - cost/benefit thing, useful to check what we can gain on it
14:37:13 <Stskeeps> #info drop GL is in NEEDINFO, solutions exist but need info to proceed
14:37:37 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=27 -  Evaluate benefits eglibc vs glibc, in terms of packaging, cross compilation and footprint/impact
14:37:58 <Stskeeps> i propose medium priority - it's best for all of us if we stay close to linaro gcc and their setup, which is eglibc
14:38:05 <Stskeeps> as we can get help for compiler errors
14:38:48 <Stskeeps> the fedora glibc packaging is a tad awkward, so
14:40:08 <lbt> done?
14:40:28 <Stskeeps> #info medium priority - it's best for all of us if we stay close to linaro gcc and their setup, which includes eglibc
14:40:48 <Stskeeps> #topic Bug 28 - Drop gamin dependancy - https://bugs.merproject.org/show_bug.cgi?id=28
14:41:11 <Stskeeps> #info this is in glib2 and a oneliner - we can drop the gcc atomics patch for armv6 now as well while someone's at it anyway
14:41:35 <Stskeeps> low prio - sage, perhaps you can take it as you touched it last?
14:42:59 <Sage> I can take this sure
14:43:04 <Stskeeps> #info low, sage takes
14:43:18 <lbt> done
14:43:24 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=29 - Drop gamin from core
14:43:34 <Stskeeps> low, this can be assigned to me when gamin dep is removed
14:43:39 <Stskeeps> #info low, this can be assigned to me when gamin dep is removed
14:44:09 <lbt> done
14:44:17 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=30 - bash should link against system readline, not against it's own copy
14:44:21 <Stskeeps> nice junior job
14:44:37 <Stskeeps> low priority, not terribly important, but nice to clean out memory a little bit
14:44:51 <lbt> I'll take it - I need to run through some process checks
14:44:58 <Stskeeps> k
14:45:12 <Stskeeps> #info low, not terribly important, but nice to clean out memory a little bit, lbt assignee
14:45:58 <Stskeeps> #topic Move ntpdc and ntpq to ntp-utils package to save footprint - Bug 31 - https://bugs.merproject.org/show_bug.cgi?id=31
14:46:14 <Stskeeps> this is also a junior job, the reasoning is that we then can drop libedit from image
14:46:21 <Stskeeps> connman uses ntp directly, not through command line tools
14:46:31 <Stskeeps> low priority?
14:46:39 <lbt> yes
14:46:53 <Stskeeps> #info low, junior job, the reasoning is that we then can drop libedit from image
14:47:00 <Stskeeps> #info connman uses ntp directly, not through command line tools
14:47:35 <Stskeeps> #topic pixman should be upgraded to 0.24 - https://bugs.merproject.org/show_bug.cgi?id=35
14:47:57 <Stskeeps> #info medium, is probably related to overall performance improvements
14:48:26 <Stskeeps> #link http://gitweb.merproject.org/gitweb?p=mer-core/pixman.git;a=tree
14:48:40 <lbt> aside: do we need an upstream-new-release-tracking process ?
14:48:47 <Stskeeps> it would be useful to have something
14:49:42 <lbt> it's almost like we need a package database...
14:49:52 <Stskeeps> packages.xml ;)
14:49:59 <Stskeeps> i'm going to skip 38-51 as they are the bashism ones and already low priority
14:50:39 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=52 - Switch from DWARF-3 to DWARF-4 in order to save debuginfo space
14:50:45 <Stskeeps> #info assign to stskeeps, medium
14:50:56 <Stskeeps> i already have a patch waiting for this, so
14:52:30 <Stskeeps> #topic Switch db4 to libdb, 5.2.36 and switch RPM to it  - https://bugs.merproject.org/show_bug.cgi?id=53
14:52:49 <Stskeeps> this is a bit more complex, integrating a new package and switching RPM to be using this instead of db4
14:53:05 <Stskeeps> i'd say medium prio as it can be benefits in package performance/solidity
14:53:48 <lbt> any info for potential takers?
14:54:33 <Stskeeps> sec
14:55:27 <Stskeeps> http://pkgs.fedoraproject.org/gitweb/?p=rpm.git;a=blob;f=rpm.spec;h=323ee6af83ac6e422e0ff07258f899c3b4defb14;hb=HEAD , http://pkgs.fedoraproject.org/gitweb/?p=libdb.git;a=tree
14:55:36 <Stskeeps> we don't need to care about db1.85
14:56:22 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=54 - Bug 54 - Include package build logs to the releases
14:56:26 <Stskeeps> triage in tomorrow's meeting?
14:57:10 <Stskeeps> medium prio, i think
14:57:20 <Sage> or even low
14:57:28 <Sage> it is not so important for general usage
14:57:38 <Sage> more like nice to have if someone has time to do it
14:57:39 <lbt> it's part of what vendors need
14:58:02 <Sage> well, that is true.
14:58:03 <lbt> how about NEEDINFO
14:58:17 <lbt> and putting some thought into what/when/how ?
14:58:26 <Stskeeps> mmk
14:58:45 <Stskeeps> #info handle in RM discussions
14:58:46 <lbt> This is part of Mer's information systems
14:59:02 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=57 - dbus-glib is now merged to glib upstream so we should remove it
14:59:06 <lbt> and should be part of our deliverables - nice clear info
14:59:14 <lbt> OK... moving on then...
14:59:40 <Stskeeps> this is still in use by upower and ConsoleKit
14:59:46 <Stskeeps> and gconf
15:00:05 <Stskeeps> and dbus-python(?)
15:00:17 <Stskeeps> so low priority for now?
15:00:57 <Sage> Sounds good to me.
15:01:04 <Sage> ConsoleKit can be removed but need to check rest
15:01:40 <Stskeeps> #info low, still in use by upower and ConsoleKit and gconf and dbus-python
15:01:53 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=58 - nss should be upgraded to NSS_3_13_1_RTM
15:02:12 <Stskeeps> high, as this may include security fixes, and is one of our central security libraries
15:03:22 <Stskeeps> #info high
15:04:51 <lbt> done
15:05:05 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=59 - nspr should be upgraded to 4.8.9
15:05:14 <Stskeeps> probably is a requirement of NSS anyway
15:06:06 <lbt> blocks?
15:06:14 <Stskeeps> think so
15:06:19 <Stskeeps> a 'weak' blocks, at least
15:06:39 <Stskeeps> so medium prio
15:06:50 <lbt> blocks a high
15:06:53 <Stskeeps> yeah, ok
15:06:56 <Stskeeps> high then?
15:06:59 <Stskeeps> #topic PAM should use system db4, not it's own - https://bugs.merproject.org/show_bug.cgi?id=69
15:07:37 <Stskeeps> you'd be surprised how many copies of sqlite and db4 there's around
15:07:47 <lbt> :)
15:07:50 <Stskeeps> low priority too though
15:07:52 <lbt> yes
15:08:02 * Sage thinks that he can take some of those
15:08:26 <Stskeeps> just assign them to yourself then
15:08:30 <Stskeeps> #topic e2fsprogs should be upgraded to 1.42
15:08:31 <lbt> Sage: time to teach people how to fish I think....
15:08:51 <Stskeeps> medium, junior job, always good to follow basic system utilities
15:09:23 <Sage> lbt: ? :)
15:09:42 <Sage> Stskeeps: You probably will announce list of stuff people can take if interested?
15:09:45 <Stskeeps> yes, i will
15:09:54 <lbt> give a man a fish/bug, feed him for a day.... teach a man to fish/debug... feed him for life
15:10:04 <Stskeeps> so leave some free ;)
15:10:14 <lbt> Stskeeps: I was thinking we could do a blog/tweet
15:10:18 <Stskeeps> next one is ofonod bug, we'll skip that
15:10:20 <Stskeeps> lbt: mailing list atm
15:10:25 <Sage> Stskeeps: hehe, ok :)
15:10:37 <lbt> yeah, or email ...
15:10:47 <Stskeeps> bug 76 we already prioritized
15:11:09 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=78 - Bug 78 - Releases should have delta RPMs
15:11:31 <Stskeeps> medium, useful to have, discuss tomorrow in RM?
15:12:09 <Sage> sure, I don't see this very high prio as it doesn't block anything afaik, just increases the speed of update
15:12:20 <Stskeeps> :nod:
15:12:23 <lbt> not low?
15:12:30 <Stskeeps> low then
15:12:43 <lbt> this is 'today's prio' ... we get to do this ... monthly ?
15:12:49 <Stskeeps> 14 days or so
15:13:13 <lbt> better
15:13:54 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=84 -  Package eglinfo and glestest for easy EGL testing
15:14:02 <Stskeeps> junior job, low, but very useful for hardware adaptations
15:14:15 <Sage> imporance high :)
15:14:23 <lbt> yes
15:14:39 <Stskeeps> ok, high..
15:14:39 <Stskeeps> :P
15:14:49 <Sage> pain in the *** when doing new adaptation :)
15:14:54 <lbt> package name?
15:15:18 <Sage> was it in mesa or something?
15:15:32 <lbt> there are links to the source
15:15:34 <Stskeeps> this is just some non-mesa ones since mesa usually drags in odd windowing system stuff
15:15:37 <lbt> so I assume a new pkg
15:15:37 <Stskeeps> works just fine
15:16:03 <Stskeeps> #topic Bug 85 - Investigate variables for deciding if a %post/RPM scriptlet happens during build, image install or on active device - https://bugs.merproject.org/show_bug.cgi?id=85
15:16:23 <Stskeeps> this is a bit of a feature request/thing that came up in discussion, in order to differ in %post and %pre between those scenarios
15:16:40 <lbt> sec
15:16:52 <lbt> 84 : Will need a new standalone package, git repo etc. ?
15:16:59 <Stskeeps> yes
15:17:02 <lbt> done
15:17:19 <lbt> hmm
15:17:28 <Stskeeps> i'd say medium priority because i'm just sure we'll hear than in actual product programmes too.. discuss fully in RM meetings tomorrow?
15:17:29 <lbt> I'm looking into this kind of thing
15:17:39 <Stskeeps> than=that
15:17:44 <lbt> with the lua/rpm
15:18:24 <Stskeeps> :nod:
15:18:40 <Stskeeps> #topic Switch to using %if's for test suites for QEMU issues instead of %ifarch  - https://bugs.merproject.org/show_bug.cgi?id=86
15:19:01 <Stskeeps> this is a bit of a project-wide thing, that we can tell if we're building with a qemu or an actual device
15:19:08 <Stskeeps> because eventually, we will want to run testcases on actual devices
15:19:23 <Stskeeps> i'd say medium priority
15:20:13 <Stskeeps> right now we do %ifarch %{arm} mipsel etc
15:20:16 <Stskeeps> which isn't cool
15:20:16 <Stskeeps> :P
15:21:16 <lbt> I think make this blocked by an "rpm/variable usage policy"
15:21:29 <lbt> which I'm kinda working on with the kernel pkg
15:21:45 <Stskeeps> ok
15:22:00 <lbt> nb... when we do policy stuff ... we should validate it
15:22:02 <lbt> automatically
15:22:08 <Stskeeps> yess
15:22:18 <Stskeeps> #topic  Mer should contain a package that contains default kernel settings - https://bugs.merproject.org/show_bug.cgi?id=90
15:22:22 <Stskeeps> high?
15:22:22 <Stskeeps> :P
15:22:36 <lbt> I'm not sure it's a package
15:22:53 <Stskeeps> i think it should be, else we can't deploy changes easily
15:23:01 <lbt> a .config?
15:23:02 <Stskeeps> CONFIG_'s for systemd, that kind of stuff
15:23:08 <Stskeeps> yes, it's a .config, but we need to spread it somehow
15:23:15 <Stskeeps> and ideally through automatic rebuilds
15:23:20 <Stskeeps> either way high, RM meeting?
15:23:26 <lbt> OK... that's different then
15:23:38 <Stskeeps> just basically what the userland expects
15:23:47 <Sage> hmm...
15:23:48 <lbt> it should be part of the default HA kernel packaging
15:24:04 <Stskeeps> yes, but that packaging will stall ;)
15:24:05 <lbt> ie 'validate needed Mer CONFIG_' check
15:24:10 <Sage> http://wiki.merproject.org/wiki/Adaptation_Guide#Kernel <- ?
15:24:20 <lbt> Sage: yes .. I like that
15:24:30 <lbt> but Stskeeps is right... needs to be auto and updated
15:24:42 <Stskeeps> we had config-generic in meego and it was a nightmare
15:24:47 <Stskeeps> as everyone had their own copy
15:24:50 <Sage> yes
15:24:51 <lbt> so the kernel HA package depends on this Mer core as a BR
15:25:11 <Stskeeps> #topic Bug 92 - Include --with-linker-hash-type=gnu, may improve app launch performance - https://bugs.merproject.org/show_bug.cgi?id=92
15:25:18 <Stskeeps> high prio, assign to me (i'm working on it atm)
15:25:23 <lbt> so mer core provides 'minimal' CONFIG_ list which is used by HA
15:25:35 <Stskeeps> right
15:26:09 <Sage> and script that checks that user has them when building?
15:26:32 <Sage> however, it is uses responsibility to call it
15:26:38 <Sage> s/uses/users/
15:26:58 <lbt> Sage: I'd make it part of the kernel packaging
15:27:31 <lbt> Warning: Your kernel does not provide all Mer CONFIG_ settings. See.... http://..."
15:27:48 * lbt takes it
15:28:09 <Stskeeps> bug 95 we already went through
15:28:14 <Stskeeps> so we're done for today
15:28:32 <vgrade> lbt, we also need 'your kernel provides xxx but must not for Mer'
15:28:45 <lbt> vgrade: good point
15:29:09 <vgrade> PARANIOD_ANDRIOD etc
15:29:11 <Sage> vgrade: if you have known valueas could you list them to the wiki page so we dont' forget?
15:29:28 <vgrade> yes
15:29:45 <Stskeeps> okay, thank you all for coming
15:30:00 <Stskeeps> #endmeeting