Hi Martin, hi Community, first of all: thanks for all the fish err GREPs! We need to kick off this discussion. So, this PR is very dear to my heart, because I consider log4cpp to be an especially problematic dependency. And I consider our logging to be subpar considering the size of the code base, user base and the fact that people are using GNU Radio in infrastructure for rather expensive things. So, I took the opportunity (being at 35c3, just to pose around a little bit) and talked to a couple Osmocom folks. Osmocom people, please correct me if I make any mistakes. What they have in osmocore is essentiall logging in both quantized severity and in categories, and logging routing. For them, that's very important, as they use that to supply resilient infrastructure. I hope I'm representing the idea kinda correctly here: They might want to log system events ("SUPERVISOR: INFO system load surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a preamble") on-screen, and critical messages ("gr-digital: FATAL run out of developer coffee") everywhere. I want that too. I want this to be easily integratable into software that uses GNU Radio as library. And if I'm already making wishes here, I want loggers that interface to modern logging systems, be it journald, graylog or SNMP. Something. So, I think that's pretty similar to what UHD does (correct me please, Martin). I think that UHD is a bit more flexible on the logging "categories" than I'd like to be, but that really just means we need to set a convention. So, I'm stuck wondering whether we adopt the self-implemented system that UHD uses, or the self-implemented system that osmocore uses, or implement our own. Familiarity suggests UHD, maturity osmocore. Best regards, Marcus On Thu, 2018-12-27 at 13:49 -0800, Martin Braun wrote: https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md