18:05:15 #startmeeting 18:05:15 Meeting started Tue Jan 14 18:05:15 2014 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:05:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:05:22 hiall 18:05:27 evening :) 18:06:17 * TheSnide is still commuting, but it should be ok. just laggy 18:07:01 #topic 2.2 18:07:30 nothing new, several pull reqs :) 18:08:00 didnt havetime to look at it closely yet 18:11:39 TheSnide: whats your plan regarding this jquery code embeddings? 18:18:19 h01ger: there's a munin data api now, as far as I recall, which may be used by a javascript browser application (jquery is common) to render web pages there. 18:18:57 * ssm wonder if it provides munin data as json 18:19:12 jquery is here to stay, just tell me how to package it proprerly 18:19:31 TheSnide: for the debian packaging, it'll be replaced with a dependency on a jquery package, and a symlink. 18:20:24 it is rather common to vendor these javascript libraries in the release tarballs. 18:21:29 ssm: http://paste.debian.net/76216/ not perfect, but gets a few things right 18:21:38 ssm: i was talking about deb#735236 18:22:03 note that i still need to address the tgz. 18:23:05 ... actually i could just leave that to packagers :D 18:23:24 but i agree, using the .min. version of it is not cool. 18:23:31 TheSnide: what about not shipping compiled crap and instead shipping sources in a source tarball? 18:24:23 TheSnide: minifying can be an optional build step. using the non-minified version will most likely not end up being the performance bottleneck 18:24:24 by compiled, you mean minified ? 18:25:00 for the record, i do *not* like minified JS. 18:25:22 so, it'll be replaced by the _full_ version asap. 18:25:33 me would recommend enabling compression in the web server before rewriting the js to remove whitespace and long variables. :) 18:26:14 ssm: +1 (mod_gizp is usually better compromise) 18:26:22 but for _very_ busy sites, you take your performance wins where you can get them. Munin would probably not be a very busy site 18:26:56 TheSnide: on the other hand mod_deflate (there is no mod_gzip) is very bad in conjunction with mod_cache 18:27:05 #agreed minified JS will be replaced with nonfminified version 18:28:08 helmut: as ssm said, if you have issue with the js in munin, then you have knowledge to tweak it. 18:28:25 ssm: are you aware of a process for submitting lenses? (and if that process requires a github account, can you take care of it?) 18:28:53 helmut: thx, will put lenses for a later topic if you'd like 18:29:07 TheSnide: thanks, helmut: no, and yes 18:30:26 so, i'm planning to work on sql-version @ debconf this we. 18:30:59 i also prepared some slides to present it, if someone is interested. 18:31:24 that'd be good food for munin planet 18:36:04 yup. 18:36:25 i'm also writing some tuto on setting a munin dev env 18:36:39 using the awesome dev_scripts/ 18:36:58 (also planet food) 18:37:03 that'd be _very_ helpful 18:37:50 ssm: i took a while to understand how it worked, but now it feels magical. 18:37:52 :) 18:37:58 and _very_ simple 18:39:01 #topic munin-c 18:39:13 helmut: any news one it ? 18:39:15 :) 18:41:47 no 18:42:00 well, pretec said he'd work on the packaging today. ;-) 18:42:19 Question for munin-c: coverity has free service for open source projects, and can pull code from github for testing and analysis. Would it be a good idea to ask them to analyse it? 18:42:32 (https://scan.coverity.com/) 18:42:43 munin-c is kinda stuck, cause all the low-hanging fruit is harvested 18:43:20 * ssm can register on the coverity site, and add the munin-c github repo. 18:43:29 ssm: since most parts of munin-c are blessed by splint (and splint is kinda strict), I don't expect much of it, but I don't mind reports either 18:43:54 Ok, I'll give it a try. (and then read more about splint) 18:44:32 ssm: splint use source code annotations (e.g. which memory is initialized, what pointers may contain NULL) and verifies them against function annotations 18:44:43 helmut: yes, munin-c is full of splint related commits :) 18:45:58 helmut: note that i'll might do some commits on munin-node, that could be ported to munin-c. 18:46:09 ok. 18:46:19 i'll be experimenting with munin-node, as it _is_ easier :) 18:46:43 is there anything in particular that munin-c should aim for? more plugin coverage? (which?) more node features? (which?) 18:46:52 mostly an async init for massive snmp plugins. 18:47:20 I don't think async is a worthwhile goal for munin-c, because basically munin-c is fast 18:47:23 i have to monitor 3k snmps routers. 18:47:59 as in whenever you have the resources to run slow plugins, you do have the resources to run the perl node 18:49:03 comes the starved nodes in mind. 18:49:48 and the win32 ones. make plugins that do not require cygwin, and a diskstat one. 18:50:24 i'm also experimenting cpu1sec.c to see if it works better on busy nodes. 18:51:14 it doesnt need munin-c node, btw. and that is _good_ :) 18:51:51 well wrt. win32, I won't be doing any work except for reviewing and merging. sorry. not my department. 18:52:45 no pb. 18:52:46 I do agress that relaxing the mainline-first rule for w32 stuff makes sense though 18:52:51 *agree 18:53:18 yep, that's where i'd want to come. what's your take on portability ? 18:53:33 #ifdef or makefile tricks ' 18:53:34 ? 18:54:29 portability is always a tradeoff. common sense required. where reasonable implement portable interfaces in platform specific files. 18:55:11 starting out with #ifdef is not bad in itself. refactoring is possible 18:55:35 +1 to kiss at first. 18:56:12 you see, getting a working patch into shape is often easier than getting a well written patch working. ;-) 18:57:10 anything else about munin-c? 18:58:20 packaging is kinda stuck, cause it doesn't use official tarballs yet 18:59:02 if someone who groks git-bp can set up collab-maint for pristine-tar that'd help a lot. I recently fixed the watch file 18:59:51 ssm: do you know about git-bp ? 19:00:16 helmut: I can add the official tarballs to the pristine-tar branch for collab-maint/munin-c 19:01:19 ssm: great. that should enable me to fix up the rest and upload 19:01:45 ssm: uscan should already verify pgp signatures 19:03:26 ssm, helmut: great thx. having it packaged in at least "deb/exp" makes it real :) 19:03:44 (much more than a random tgz in sf.net) 19:03:53 ok, next ? 19:03:58 ok 19:04:16 #topic lenses 19:05:00 as helmut asked there is no dedicated lenses for munin 19:10:46 http://augeas.net/ augeas 19:13:58 i think it would be great to have dedicated ones, as it would increase visibility of munin, given the increasing notoriety of augeas. 19:14:30 * TheSnide is in PR these days. 19:14:41 #topic misc 19:14:48 anything else ? 19:14:59 About minidebconf ... 19:15:01 #ranttime ! 19:15:04 about FOSDEM :) 19:15:17 ssm: i wont go there :/ 19:15:29 I'll not make it since I was unable to resove the remaining issues 19:17:26 I'll go to FOSDEM 19:17:34 * ssm will be at FOSDEM 19:17:56 who wont be (excluding me ?) 19:17:59 :/ 19:18:08 ssm: lets have a beer (or something) there :) 19:18:23 Jooooin uuussss 19:18:30 pretec: yes :) 19:18:47 i was planning on having the second munin IRC conf somewhere in Feb. 19:19:16 if some are interested. 19:19:48 same as before, 2100-2300 CET, with 2 or 3 talks. 19:20:00 * ssm will think of a topic, if and when… 19:20:17 the date is quite open. 19:20:54 but i was thinking end feb. 19:21:08 TheSnide: end feb should work. If in doubt, try doodle.com to help pick a date for it. 19:21:39 #action TheSnide will doodle an end feb date. 19:21:55 ssm: timing is ok ? (night time) 19:22:13 yes 19:22:26 i think it should suit ppl best, as it is IRC anyway. 19:24:18 I was also thinking about a AMA session. 19:25:15 but, meetings are quite good for that already. 19:25:18 ... 19:25:48 so, /me is very happy with today's. 19:26:01 anytthing else ? 19:27:27 not from me 19:30:08 ok 19:30:12 #endmeeting