20:17:59 <sumpfralle> #startmeeting
20:17:59 <MeetBot> Meeting started Wed Jan 30 20:17:59 2019 UTC.  The chair is sumpfralle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:17:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:18:07 <sumpfralle> #chair TheSnide sumpfralle
20:18:07 <MeetBot> Current chairs: TheSnide sumpfralle
20:18:17 <sumpfralle> Do you have a topic?
20:19:06 <TheSnide> not really
20:19:44 <TheSnide> i did look at munin-c quickly, as there where some PR
20:19:56 <sumpfralle> Sounds good!
20:20:02 <TheSnide> yep.
20:20:15 <TheSnide> Also, the win32 port is in a sorry state.
20:20:24 <sumpfralle> There is munin-node-c packaged for Debian. Does it need an update before Buster?
20:20:26 <TheSnide> So, i have to see if I could port the munin-c ther
20:20:41 <TheSnide> ah, yes, that would be very lovely
20:20:41 <sumpfralle> A windows port would be great!
20:21:07 <TheSnide> when is the deadline for buster ?
20:21:24 <TheSnide> I can make a new package tomorrow.
20:21:28 <sumpfralle> 12th of March is the start of the freeze.
20:21:49 <sumpfralle> Thus if you do a release, then I can take a look at the packaging and communicate with the maintainer.
20:21:51 <TheSnide> ok, so, let's aim for "prior to next meeting" to have it uploaded
20:21:56 <sumpfralle> Or would you want to do that?
20:22:05 <sumpfralle> yes, that would be great
20:22:11 <TheSnide> well.. the maintainer is ... lost ;)
20:22:11 <sumpfralle> Maintainer: Matthias Schmitz
20:22:46 <TheSnide> He disappeared from my radar.
20:23:02 <sumpfralle> I will send him a mail right now - in order to get his opinon (or absence) early ...
20:23:10 <TheSnide> +1
20:23:31 <TheSnide> that said, would it be possible for you to use it?
20:23:52 <TheSnide> As http://demo.munin-monitoring.org/munin-monitoring.org/pi.munin-monitoring.org/ is currently using it.
20:23:54 <sumpfralle> yes, I will try it on some hosts.
20:24:10 <sumpfralle> Will your new release be 1:1 compatible with the older package?
20:24:26 <TheSnide> munin-c ?
20:24:27 <TheSnide> yes
20:24:33 <sumpfralle> (i.e. should I start with the current package and then upgrade - or just install the new release)
20:24:38 <sumpfralle> ok - upgrade
20:24:56 <TheSnide> Then we should provide some systemd config
20:25:05 <TheSnide> as, for now the package is using xinted
20:25:25 <sumpfralle> OK - I will manage that.
20:25:30 <TheSnide> ... which doesn't make sense if you have systemd and embedded stuff
20:26:00 * TheSnide will push the systemd conf as sample in the package itself
20:26:01 <sumpfralle> Yes, probably I will install it on other machines (partly systemd and sysv)
20:26:06 <sumpfralle> cool
20:26:21 <TheSnide> munin-node-c doesn't daemonize.
20:26:38 <TheSnide> It's designed to be run by either systemd or inetd
20:26:47 * kjetilho ♥ systemd
20:27:02 <sumpfralle> Even though being invented before systemd :)
20:27:19 <TheSnide> what munin-c ?
20:27:26 <sumpfralle> yes
20:27:26 <sumpfralle> or not?
20:27:30 <TheSnide> i don't think so.
20:27:37 <TheSnide> as systemd is pretty old
20:28:01 <kjetilho> the inetd mechanism is older than most of us
20:28:52 <TheSnide> and, i really aimed at inetd, more than systemd as kjetilho noticed
20:29:57 <sumpfralle> ok - two years younger (2010 < 2012). I thought munin-node-c was older ...
20:30:17 <TheSnide> so, munin-plugins-c are from 2008, and munin-node-c is from 2013
20:30:58 <sumpfralle> Another topic: there is still the postgres_...ALL issue lurking around in the dark. I would like to see this in the next release (for Buster).
20:31:34 <TheSnide> i'd say "just apply the patch from the debian BTS" if that works out
20:31:56 <sumpfralle> that patch is just my commit being reversed :)
20:32:09 <TheSnide> then so be it :-p
20:32:19 <sumpfralle> but there was a purpose! :)
20:32:32 <sumpfralle> ok - I see your lack of emotional attachment - I will take a look ...
20:32:33 <TheSnide> well... then fixit!
20:33:03 <TheSnide> yep. I don't have much feelings on this one.
20:33:15 <sumpfralle> it is an abstract framework thingie and I am not really keen on digging into it. That's why I wanted to push this task to the one who has seen more of it ...
20:33:33 <sumpfralle> (at least your comment sounded like you had an opinion)
20:33:33 <TheSnide> And, I lost my voice on the matter the moment I didn't say anything for almost a year
20:33:46 <sumpfralle> only four months :)
20:33:49 <sumpfralle> ok
20:34:20 <sumpfralle> Another thing: the C/C.UTF-8 discussion: did you read my small proposal from midnight two days ago?
20:35:28 <sumpfralle> Basically: since it seems to be unclear, whether C.UTF-8 is available on every exotic system, I proposed that we could instead specify the python-specific environment variable specifying the output encoding. This would be python-only, but is guaranteed to have no side-effects.
20:36:33 <kjetilho> sumpfralle: C.UTF-8 is Debian specific?
20:36:53 <sumpfralle> "python-specific"
20:37:01 <sumpfralle> sorry - ignore please
20:37:20 <kjetilho> C.UTF-8 it is not in Fedora nor Solaris
20:37:32 <sumpfralle> someone brought up the issue, that C.UTF-8 is not available on every system (I forgot, which one). In Debian it is part of libc-bin.
20:37:46 <sumpfralle> kjetilho: it surely is there - you just did not see it.
20:37:47 <kjetilho> it is probably only present on exotic systems like Debian
20:37:56 <sumpfralle> locale -a
20:38:03 <sumpfralle> surprise me!
20:38:30 <kjetilho> LC_ALL=C.UTF-8 perl -e '' → perl: warning: Setting locale failed.
20:38:46 <sumpfralle> what system is that?
20:38:52 <kjetilho> that was Solaris
20:39:10 <kjetilho> ok, my Fedora has C.utf8
20:39:15 <sumpfralle> how old?
20:39:20 <sumpfralle> (you picked the hardest target! :)
20:39:35 <kjetilho> Solaris is the industry standard! :)
20:39:56 <kjetilho> but why C.utf8?
20:39:56 <sumpfralle> yeah - I almost forgot! :)
20:40:14 <kjetilho> I don't see the point.  surely en_US.UTF-8 is much more likely to exist
20:40:26 <sumpfralle> it was used for forcing the output encoding for python3 (i.e. plugins written in python3 or programs called indirectly in plugins).
20:40:46 <sumpfralle> We shall not repeat that overlong discussion - above you will find many pages ...
20:42:26 <sumpfralle> Right now we switched from C to C.UTF-8 in munin-node (only a few commits ago - not released, yet). Due to the absence of C.UTF-8 on the industry standard OS, I would pick the python-specific environment variable, instead. This only fixes python-related issues, but it is progress.
20:43:15 <sumpfralle> I really did not expect people to be so passionate about encodings :)
20:44:05 <kjetilho> I am not passionate about encodings, I am passionate about not introducing Debian specific code
20:44:40 <sumpfralle> It is surely not Debian-specific. And I would also like to avoid that.
20:50:13 <kjetilho> I didn't see anything in the previous discussion about why not en_US.UTF-8
20:51:00 <TheSnide> for the locale, my take would be :
20:51:24 <sumpfralle> en_US: I only have en_GB ...
20:51:31 <TheSnide> C.UTF-8 is not set to C. Or can be user-overritable.
20:52:24 <kjetilho> sumpfralle: hahaha, I really don't understand that locale.gen stuff in Debian.  such a waste of time for everyone concerned
20:53:24 <kjetilho> can it be chosen at build-time?
20:54:02 <sumpfralle> hehe - we want to keep it simple and proper - maybe the very long discussion distracted you :)
20:54:31 <sumpfralle> My approach in simple words: revert f31cc13620 and add the new PYTHONIOENCODING environment variable.
20:54:56 <sumpfralle> This will only affect python-related plugins or indirectly executed programs. No further changes should be visible.
20:55:20 <kjetilho> locale -a | egrep '^(C|POSIX|en)' | while read loc; do if [ $(LC_ALL=$loc locale charmap) = "UTF-8" ]; then echo $loc; break; fi; done
20:55:47 <kjetilho> to be run in configure to replace @LOCALE@
20:56:13 <kjetilho> not perfect, but mostly it will be packaged on a system similar to where it will be installed
20:56:13 <sumpfralle> I do not think, that the build system should decide about the locale of the target.
20:56:39 <sumpfralle> Really: there is only one problem to be solved: let python-related programs use UTF-8 by default. Nothing else.
20:57:12 <kjetilho> good.
20:57:46 <sumpfralle> The newest python release (3.7) is clever enough to do it on its own. Only python 3.x (before 3.7) needs a bit of assistance.
20:57:59 <sumpfralle> We do not want to change so much - it is all nicely stable :)
20:58:38 <sumpfralle> (sorry for being rude - the long discussions over the last two days exhausted me a bit)
20:59:19 <kjetilho> no, I am sorry for missing the point where you explicitly said you *didn't* want to use C.UTF-8 ...
20:59:56 <sumpfralle> languages is a hard problem for all of us :)
21:00:37 <sumpfralle> ok - I think, we covered all interesting details for the next release.
21:00:48 <sumpfralle> Or are there any other interesting topics?
21:05:27 <sumpfralle> #endmeeting