On 6/25/2012 7:55 PM, Holger Levsen wrote: > Hi Stan, > > first: thanks for explaining and filing a bug in the first place. I should > have said so in the first place... :-) +anyway: > > On Montag, 25. Juni 2012, Stan Hoeppner wrote: >> You misread my report, and closed this prematurely. > > well... I'm not sure about that ;) and more importantly, I still don't see a > specific bug I can identify, track and fix. And at least 5 others read this > (and actually everybody can reopen bugs. And I'd be happy to reopen "yours", > but I don't (yet?) see how.)
I appreciate that. Something definitely went wrong in the upgrade process. As I'm neither a dev nor a maintainer I can't say where it went wrong or what code is responsible. If the problem is not with something you maintain, maybe you can get the information to the right people. >> Note that I simply >> kept my original config files during safe-upgrade. When munin didn't >> work, I replaced them withe the new 2.0 files provided by the upgrade >> process. Munin still didn't work. I followed the instructions you >> linked, including the lighttpd configuration here: >> http://munin-monitoring.org/wiki/CgiHowto2 > > note that lighttpd is not supposed to work out of the box. apache2 is > supposed > to work. But it WAS with 1.4.x. Thus, safe-upgrade shouldn't have installed the backport automatically. >> and it still doesn't work. The cgi and html processes launch but hang. >> According to this: >> >> >> The FastCGI processes will log to "/var/log/munin/munin-cgi-graph.log" >> and "/var/log/munin/munin-cgi-html.log". >> >> Note that these run with the web server's permissions, unless specified >> otherwise. If the web server does not have write access to the specific >> log files (or access to the directory they are in), the cgi processes >> will hang, and not produce any output. > > yes, you will need to fix the perms. >> >> they should only hang when write access isn't present. But there are >> entries in these log files, though it seems they're not complete, so >> maybe one process can write them but no all the processes that need to: >> >> [root@greer]/var/log/munin$ cat munin-cgi-graph.log >> 2012/06/25 11:23:34 Opened log file >> 2012/06/25 11:23:34 Opened log file >> 2012/06/25 11:23:34 Opened log file >> 2012/06/25 11:23:35 Opened log file >> [root@greer]/var/log/munin$ cat munin-cgi-html.log >> 2012/06/25 11:23:32 Opened log file >> 2012/06/25 11:23:33 Opened log file >> 2012/06/25 11:23:33 Opened log file >> 2012/06/25 11:23:33 Opened log file >> >> If indeed it's a permissions issue, why doesn't the installer script set >> the correct permissions on these files automatically like most/all other >> packages do? > > because the package only supports apache2. This reason you give doesn't make sense. The log files are in /var/log/munin/ which has nothing to do with the httpd. >> When I installed munin 1.4.x I had zero problems getting it working. >> Why are so many contortions required to get the 2.0 upgrade working? > > because graphing used to be done every 5min from cron, now it's done on > demand > by a cgi script. cgi was the default in 1.4.x but one had the option to use cron. I chose cron because the particular machine isn't speedy. >> The upgrade installer is simply broken. This isn't the Debian Stable I >> know and love. > > backports is not Debian stable. They are supposed to work well, but they are > much less tested than Debian stable. I've been using Debian since 2001 and backports since long before it was folded into official Debian. I know full well what it is and is not. I thought I already made this clear. >> My big complaint is that an 'aptitude safe-upgrade' shouldn't install a >> package upgrade that is so completely broken and does not work without >> major surgery. The backports repo is supposed to contain stable working >> packages backported from testing, or so I thought. And frankly I'm >> surprised a safe-upgrade pulls packages from backports. I was under the >> impression it only pulls from the stable repo. And, no, I've never >> modified any apt preferences or whatever to cause it to pull packages >> from backports. I don't even know how this would be done. This is >> something that happened automatically. > > no. I don't know which backports repo you are refering to, but if you simply > add the sources mentioned on backports.debian.org to your sources.list of a > debian Stable system, I'm quite sure "aptitude safe-upgrade" won't install > munin 2.0 from backports unless you have done something. "apt-get dist- > upgrade" (and upgrade as well) certainly wouldn't (install any package from > backports.org for that matter). Did this happen because I was previously running a munin backport? 1.4.6-1~bpo60+1 So safe-upgrade automatically installed the 2.0.0.1 backport? If so, then please explain to me again why/how this broken upgrade to 2.x is my fault, a point you continue to attempt to drive home, when you developers knew the 2.0.0.1 backport doesn't work with lighttpd, according to you. BTW, the package information doesn't mention that Apache2 is required, nor that Lighttpd won't work. It simply says "recommends httpd": Package: munin State: installed Automatically installed: no Version: 2.0.0-1~bpo60+1 Priority: optional Section: net Maintainer: Munin Debian Maintainers <packag...@munin-monitoring.org> Uncompressed Size: 852 k Architecture: all Compressed Size: 194 k Filename: pool/main/m/munin/munin_2.0.0-1~bpo60+1_all.deb MD5sum: 7a8efcb730807acab7d8fa0affe6f5a2 Archive: squeeze-backports, now Depends: perl, perl-modules | libparse-recdescent-perl, librrds-perl (>= 1.2), libhtml-template-perl, libdigest-md5-perl, libtime-hires-perl, libstorable-perl, rrdtool, adduser, liblog-log4perl-perl (>= 1.18), ttf-dejavu, munin-common (>= 2.0.0-1~bpo60+1), cron, libdate-manip-perl, libcgi-fast-perl, libfile-copy-recursive-perl, liburi-perl, libio-socket-inet6-perl Recommends: munin-node, munin-doc Suggests: www-browser, httpd, libnet-ssleay-perl My safe-upgrade info: [root@greer]/var/log/apt$ cat /etc/apt/sources.list deb http://mirrors.kernel.org/debian/ squeeze main contrib non-free deb http://ftp.utexas.edu/debian/ squeeze main contrib non-free deb http://security.debian.org/debian-security/ squeeze/updates main contrib non-free deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free #deb http://mirror.anl.gov/debian/ squeeze main contrib non-free /root/.bash_history ... aptitude update cat /etc/debian_version aptitude safe-upgrade vi /etc/postfix/main.cf vi /etc/postfix/main.cf ifconfig top postfix reload top tml /etc/postfix restart /etc/init.d/postfix restart tml top exit *************************************************************** ***** Realized munin was broken, started troubleshooting ***** *************************************************************** cat /var/log/apt cd /var/log/apt la cat history.log aptitude show munin-plugins-core aptitude install munin-plugins-core /etc/init.d/munin restart ... /etc/apt/history.log Start-Date: 2012-06-23 13:20:54 Install: libcgi-fast-perl:i386 (5.10.1-17squeeze3, automatic), libfcgi-perl:i386 (0.71-1+squeeze1, automatic) Upgrade: libswscale0:i386 (0.5.6-3, 0.5.9-1), libc-bin:i386 (2.11.3-2, 2.11.3-3), munin-common:i386 (1.4.6-1~bpo60+1, 2.0.0-1~bpo60+1), libavutil49:i386 (0.5.6-3, 0.5.9-1), base-files:i386 (6.0squeeze4, 6.0squeeze5), munin:i386 (1.4.6-1~bpo60+1, 2.0.0-1~bpo60+1), bind9-host:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), procps:i386 (3.2.8-9, 3.2.8-9squeeze1), smbclient:i386 (3.5.6~dfsg-3squeeze6, 3.5.6~dfsg-3squeeze8), postfix:i386 (2.8.3-1~bpo60+1, 2.9.1-2~bpo60+1), dnsutils:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), php5:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), libc-dev-bin:i386 (2.11.3-2, 2.11.3-3), libdns69:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), php5-sqlite:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), munin-node:i386 (1.4.6-1~bpo60+1, 2.0.0-1~bpo60+1), at:i386 (3.1.12-1, 3.1.12-1+squeeze1), libpostproc51:i386 (0.5.6-3, 0.5.9-1), mysql-common:i386 (5.1.49-3, 5.1.63-0+squeeze1), libgnutls26:i386 (2.8.6-1+squeeze1, 2.8.6-1+squeeze2), linux-libc-dev:i386 (2.6.32-41, 2.6.32-45), libcurl3-gnutls:i386 (7.21.0-2.1+squeeze1, 7.21.0-2.1+squeeze2), libtasn1-3:i386 (2.7-1, 2.7-1+squeeze+1), php5-gd:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), python-minimal:i386 (2.6.6-3+squeeze6, 2.6.6-3+squeeze7), libavformat52:i386 (0.5.6-3, 0.5.9-1), libisccc60:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), openssh-client:i386 (5.5p1-6+squeeze1, 5.5p1-6+squeeze2), libc6-i686:i386 (2.11.3-2, 2.11.3-3), php-pear:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), samba-common-bin:i386 (3.5.6~dfsg-3squeeze6, 3.5.6~dfsg-3squeeze8), liblwres60:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), libcurl3:i386 (7.21.0-2.1+squeeze1, 7.21.0-2.1+squeeze2), python:i386 (2.6.6-3+squeeze6, 2.6.6-3+squeeze7), php5-pspell:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), postfix-pcre:i386 (2.8.3-1~bpo60+1, 2.9.1-2~bpo60+1), libxml2:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze4), libbind9-60:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), ffmpeg:i386 (0.5.6-3, 0.5.9-1), curl:i386 (7.21.0-2.1+squeeze1, 7.21.0-2.1+squeeze2), libavfilter0:i386 (0.5.6-3, 0.5.9-1), file:i386 (5.04-5, 5.04-5+squeeze2), samba:i386 (3.5.6~dfsg-3squeeze6, 3.5.6~dfsg-3squeeze8), libmagickcore3:i386 (6.6.0.4-3, 6.6.0.4-3+squeeze3), munin-plugins-extra:i386 (1.4.6-1~bpo60+1, 2.0.0-1~bpo60+1), libwbclient0:i386 (3.5.6~dfsg-3squeeze6, 3.5.6~dfsg-3squeeze8), ssh:i386 (5.5p1-6+squeeze1, 5.5p1-6+squeeze2), php5-mcrypt:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), postfix-doc:i386 (2.8.3-1~bpo60+1, 2.9.1-2~bpo60+1), libtiff4:i386 (3.9.4-5+squeeze3, 3.9.4-5+squeeze4), libpng12-0:i386 (1.2.44-1+squeeze2, 1.2.44-1+squeeze4), php5-imap:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), sysvinit-utils:i386 (2.88dsf-13.1, 2.88dsf-13.1+squeeze1), libmysqlclient16:i386 (5.1.49-3, 5.1.63-0+squeeze1), libmagickwand3:i386 (6.6.0.4-3, 6.6.0.4-3+squeeze3), libfreetype6:i386 (2.4.2-2.1+squeeze3, 2.4.2-2.1+squeeze4), libisccfg62:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), libmagickcore3-extra:i386 (6.6.0.4-3, 6.6.0.4-3+squeeze3), libc6-dev:i386 (2.11.3-2, 2.11.3-3), tzdata:i386 (2011n-0squeeze1, 2012c-0squeeze1), libavcodec52:i386 (0.5.6-3, 0.5.9-1), libssl0.9.8:i386 (0.9.8o-4squeeze7, 0.9.8o-4squeeze13), libpq5:i386 (8.4.10-0squeeze1, 8.4.12-0squeeze1), imagemagick:i386 (6.6.0.4-3, 6.6.0.4-3+squeeze3), openssl:i386 (0.9.8o-4squeeze7, 0.9.8o-4squeeze13), samba-common:i386 (3.5.6~dfsg-3squeeze6, 3.5.6~dfsg-3squeeze8), php5-cgi:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), host:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), php5-cli:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), sysv-rc:i386 (2.88dsf-13.1, 2.88dsf-13.1+squeeze1), libisc62:i386 (9.7.3.dfsg-1~squeeze4, 9.7.3.dfsg-1~squeeze5), libxi6:i386 (1.3-6, 1.3-7), libc6:i386 (2.11.3-2, 2.11.3-3), perlmagick:i386 (6.6.0.4-3, 6.6.0.4-3+squeeze3), openssh-server:i386 (5.5p1-6+squeeze1, 5.5p1-6+squeeze2), initscripts:i386 (2.88dsf-13.1, 2.88dsf-13.1+squeeze1), php5-common:i386 (5.3.3-7+squeeze8, 5.3.3-7+squeeze13), libnss3-1d:i386 (3.12.8-1+squeeze4, 3.12.8-1+squeeze5), sysvinit:i386 (2.88dsf-13.1, 2.88dsf-13.1+squeeze1), libmagic1:i386 (5.04-5, 5.04-5+squeeze2), libavdevice52:i386 (0.5.6-3, 0.5.9-1) End-Date: 2012-06-23 13:28:23 > for that you either need to explicitly say "apt-get install -t backports This is what I though as well, and has been my experience--if I wanted a backport package, I had to individually install with '-t' and the name of the repo. Did someone change the behavior of aptitude in this regard? It sure appears so. > munin" or reconfigure apt/aptitude to grab packages from backports by > default, > which is not sensible. As demonstrated by the evidence above, I did neither of these two things. >> So what do I do now? Can 2.0 be made to work on my system? > > sure. easily with apache2 and with some work with lighttpd. Can you point me to a set of instructions? The ones for lighty I followed didn't hit the mark. Or maybe there's something else I'm missing that wasn't in those docs. >> Or is it >> simply completely hosed? Should I file a bug report against the upgrade >> script? If so, how do I do that? What's the package name for it? > > aptitude, but see above. Given the information I presented above, which suggests munin was upgraded to the 2.0.0.1 backport due to the currently installed version being a backport, is the problem with aptitude, or with the information contained in the munin backport package itself? I.e. should the backport 2.0.0.1 have included a "reverse dependency" such that aptitude would not install 2.0.0.1 given that Lighttpd was the installed hpptd? >> I, the user, did nothing to break my munin. Fault lay with the >> developers. An upgrade shouldn't completely totally break a program so >> that it simply won't run at all, which is what has happened here. This >> is very frustrating to say the least. >> >> If this is not a bug, and a bug report isn't the proper place to receive >> troubleshooting assistance to get this working, where do you recommend I >> go for assistance? Please don't say "debian-users". I've been a >> subscriber for over 3 years. Munin is never discussed and there's >> likely no other munin users there who could help. > > the only munin bug I see here is "please add support for automatic > configuration with lighttpd" No, that's not the bug. That would be a feature request. Manual configuration is fine with me had a warning been given BEFORE the auto upgrade, and a link to docs that would yield a correctly running munin 2.0.0.1 on Lighty. The bug here is the automatic install of 2.0.0.1 onto a system with a configuration, according to you, KNOWN to not work with 2.0.0.1 automatically. I'm fine with manual configuration as long as I'm told up front that it's required, and provided exact instructions. The bug, therefore, is that the installer didn't check the current configuration for compatibility before proceeding. If munin 2.0 only works out of the box with Apache2, the aptitude should not have installed the backport on my my Lighty system. Do you disagree with these assertions? > and for that I'd prefer a patch or at least help, > as I'm not a lighttpd user myself. And for that I'd prefer a new bug to not > have this as irrelevant history to a simply request :-) What do you think? Irrelevant history eh? What do I think? Honestly? I think you should eliminate your arrogance, stop making incorrect assumptions at every turn, stop assuming people submitting bug reports are morons, and stop talking down to submitters, especially when you're not even attempting to understand the core issue of the report. You closed the report before you even had a chance to digest the issue, instead of requesting additional information. That is the epitome of developer arrogance. Your job isn't to dismiss bug reports as fast as possible. Your job is to fix problems. You made a couple of incorrect assumptions right off the bat and never changed course when additional information was provided proving your assumptions incorrect. Whether you are paid for your work on Debian, or are strictly a volunteer, you work for the Debian user base nonetheless, not yourself. Your attitude in this report demonstrates complete arrogance and disregard for the user. If you're not willing, and eager, to assist users who find problems, instantly assuming the problem isn't within your realm of responsibility and closing the reports, then you shouldn't be managing packages, and should step aside. Honestly. Your performance in this report has been absolutely horrible. :-) What do you think? Holger? -- Stan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
