19:29:39 <TheSnide> #startmeeting
19:29:39 <MeetBot> Meeting started Tue Sep 16 19:29:39 2014 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:29:39 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:29:44 * h01ger waves
19:29:45 <TheSnide> Hi folks !
19:30:00 <dipohl> hi
19:30:18 <TheSnide> #info TheSnide is sorry for last week.
19:32:20 <TheSnide> so, what's up here, i noticed a fair amount of activity just before
19:32:29 * TheSnide is still reading backlog
19:33:52 <TheSnide> oh. Joerg == Ganneff
19:35:13 * dipohl was away the last 2 days and knows nothing about the last activities here
19:35:39 <TheSnide> h01ger: deb#761841 seems very likely for 2022
19:35:58 * h01ger is busy with other stuff but notes we have 30 more days to get fixes into jessie easily
19:36:29 <h01ger> i wish i had time for a sprint, aka a weekend concentrating on fixing munin bugs
19:36:35 <TheSnide> h01ger: yeap. I should have some free time when I'll be on night-watch-duty :)
19:36:37 <h01ger> but then we should have done this 3 months ago
19:38:03 <TheSnide> I lacked time quite badely these past months, but it should recover soon.
19:39:24 <TheSnide> I'll review the gigantic bug list from trac, please notify me if you have a pet issue in you favorite distro bugtracker.
19:41:35 <TheSnide> I also have to find a more efficient way to fight SPAM on our wiki. Can i suggest to fully more the issue handling to github ?
19:41:41 <TheSnide> /more/move/
19:42:22 <TheSnide> (i know that some have issues with that, but i don't want to spend much time on non-productive tasks)
19:43:18 <dipohl> you mean stop using the trac as bug tracker?
19:43:38 <TheSnide> dipohl: yeap. I'm also thinking about migrating issues
19:43:52 <TheSnide> but _not_ automatically.
19:44:35 <TheSnide> I mean, i agree that wiping history isn't good. but having bugs that are 10y+ long doesn't help our PR :)
19:44:40 <dipohl> is it possible to configure the ticket module as read only in Trac?
19:45:51 <TheSnide> Also, i'd like to disable user registration completely in trac. Only manual account adding.
19:46:37 <TheSnide> the split-brain documentation doesn't help. having outdated pages on the wiki neither.
19:47:44 * TheSnide wants to increase our contributor numbers. As when i'm not active, almost noone is (as dipohl felt quite alone imho)
19:48:38 <TheSnide> So, i don't have any magic wand to increase them, but at least having a not-decayish-looking project might help.
19:49:12 <dipohl> TheSnide: Thanks for your answer on Munin ML btw
19:49:48 <TheSnide> Also, I'm planning to work much more on the PR part. I'll be more active on the ML, as the IRC is very nice, but is very epheremeral.
19:50:13 * TheSnide learns to manage an OSS project the hard way...
19:50:23 <TheSnide> (by making mistakes)
19:51:54 <TheSnide> dipohl: you're welcome
19:53:26 <dipohl> Shall we create the tmp Files also in Plug-State directory?
19:56:11 <TheSnide> reverting to a secure mktmpdir from the OS should be enough
19:56:46 <dipohl> there is no platform specific code in plugin.sh since now
19:57:15 <TheSnide> i also like to keep it that way. platform specific code should stay in the node
19:58:14 <dipohl> so plugin.sh is not the right place to add the function mktempfile
19:58:16 <TheSnide> that's the purpose of the env variable. For older node, with new plugins, let's ask user to configure it via configuration file
19:59:13 <dipohl> where in the repo can I find the input for CONFDIR/plugin-conf.d/munin-node ?
20:00:16 <dipohl> So should I create a bug report at Epel to fix the issue?
20:00:17 <TheSnide> oh, interesting question!
20:00:21 * TheSnide looks.
20:01:46 <TheSnide> It seems it is distrib specific.
20:02:08 <dipohl> I thought so, it is plausible
20:02:15 <TheSnide> for the tgz install it is in dists/tarball/plugins.conf
20:06:25 <dipohl> here I read that this dir is obsolete
20:06:26 <dipohl> https://github.com/munin-monitoring/munin/tree/devel/dists
20:06:45 <dipohl> What tree are you talking about?
20:26:11 <TheSnide> devel
20:26:31 <TheSnide> it is (obsolete). for distribs.
20:27:02 <TheSnide> but it happens to be still used.
20:36:56 <dipohl> in this dir there are no files
20:43:29 <TheSnide> ha ,
20:43:30 <TheSnide> ?
20:43:50 <TheSnide> oh, my bad. I looked at stable-2.0 branch
20:48:57 <TheSnide> Ganneff: a huge multigraph plugin _IS_ an issue to 2.0 munin-update. And still in 2.1.9. But I'm working on that as I'll have some gigantic plugins that have to work :-)
20:49:21 <TheSnide> (hint: a new generic JMX one)
20:50:44 <Ganneff> TheSnide: yeah. im as sure as i can be that it is nowhere on the network or on the munin-node side, but plain in munin-update.
20:51:56 <Ganneff> TheSnide: i wonder how hard it is to speed this up
20:55:18 <TheSnide> Ganneff: dunno yet. All I look is that the code has a very not-scalable algo that is at least O(n^3), which is... bad.
20:55:47 <TheSnide> --> some parts are almost O(n!)
20:56:56 <TheSnide> I was planning to break it down completely, and write directly in the SQL, as most of the algo is to parse the datastructure again and again, to cram it into the correct format.
20:58:24 <TheSnide> That said, for huge-diskstat-enabled nodes, i just worked around the issue by sharding the disks in several diskstats plugins
20:59:40 <TheSnide> btw, i think the meeting can be stopped. Anyone anything ?
20:59:45 <Ganneff> i do have a problem in not knowing beforehand which disks are there, thats why i dont want the diskstat_ plugin. the thing is dynamic (but usually long living enough to take stats of them)
21:00:19 <TheSnide> #stopmeeting
21:00:23 <Ganneff> oh wups,. meeting. didnt notice, sorry.
21:00:29 <Ganneff> #endmeeting, i think
21:00:34 <TheSnide> #endmeeting