Bernhard Schmidt schrieb am Freitag, den 22. Juni 2012: > > >>cb13c56 Imported Upstream version 1.2.0p1 5389660 update defaults > >>for check-mk 1.2.0p1 13ff0f6 update .install files for new > >>location, install smart plugin (really fixes #649677) 561badc Run > >>automation calls as root to fix interaction with systemd 8f173d9 > >>poor-man's-job to convert to quilt instead of dpatch (NOT > >>3.0(quilt) source format) > > > >does that patchset include the possibility to autoconvert all hr_fs > >filesystem rrds from single to multiple? i know that this only > >happens when you are using check_mk with pnp4nagios but since > >upstream puts pnp4nagios into its design picture, i think it's worth > > a thought. > > > >see my notes here > >https://wiki.icinga.org/display/howtos/check_mk+upgrade#check_mkupgrade-PerfdataFilesystemTrends > > > > > > > I think this default should be changed in pnp4nagios and migration be > assisted in that package. check-mk should probably get a NEWS.Debian > pointing to instructions. > > >probably this is more of a check_mk with pnp4nagios problem, but feel > >free to share your thoughts on that transition as well. > > check-mk has historically been a pain in the ass for new releases, and I > don't think this can all be solved in packaging. So I think the only > thing we can do (safe of pnp4nagios automigrating everything to > MULTIPLE) is to warn the user and document the known issues, i.e. on a > wiki page like yours. > > >we ran into the mentioned perfdata changes in combination with > >pnp4nagios, but also other compatibility breaking changes which were > >partly resolvable by proper packages and partly needed man days of > >manual investigation. hearing from check_mk devs, i quote, " > >dnsmichi: normal users have support contracts", is pretty "awesome" > >for calling their releases "stable" *sigh* > > Totally agreed, but that will not get better by sticking at earlier > releases :-) > > >since the wheezy freeze is NOW in progress, i don't think you should > >hurry putting that into the current wheezy release target. i would > >rather go with sanity and help make the wheezy-backports package > >ready, and point users over there. even make rrd transition work - > >that can be scripted if needed. if you happen to have packages within > >the next months for that, i'd be happy to help test and fix possible > >regressions on my test boxes (icinga only ofc) to keep my production > >boxes safe when i do a d-u. > > I disagree here. 1.1.12p7 is outdated now, and we haven't even begun > freezing. From my POV, apart from the changed perfdata which is a > problem with almost every RRD upgrading a standard 1.1.12p7 to > 1.2.0p1 should be relatively straightforward. The pain starts when > you try to start using the new features of the WebGUI, but that's > not a packaging issue. It's in the twisted logic of the applicaton. Given my available time until freeze, its already fucking cold.
Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org