Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
On 2012-06-26T00:44:12-0500, Stan Hoeppner s...@hardwarefreak.com wrote: On 6/25/2012 7:55 PM, Holger Levsen wrote: On Montag, 25. Juni 2012, Stan Hoeppner wrote: 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. CGI graphing was not the default in munin 1.4. So, for most installations, munin 2.0 is a significant change in this respect. 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. I think you misunderstand what aptitude safe-upgrade means. No, it doesn't mean it only pulls from a certain repository. It doesn't mean that the packages are safe or tested or non-broken. It just has to do with how aptitude resolves dependencies and decides whether to upgrade packages or not. See the aptitude documentation. 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? Yes, if you have a bpo package installed, and there is a newer version available, by default, the newer version will be selected for upgrade. I find apt-cache policy very handy to see what APT thinks about a particular package's versioning situation. 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: As you know from your 11 years of Debian experience, none of the developers can test every situation. Indeed, this package came from the testing distribution, and has not been in the stable distribution yet. So, thanks for being a tester and pointing out some areas of potential improvement. 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. This behavior has not changed. You had a backport package installed, so it was simply upgraded to a newer backport package. You must have manually installed the 1.4.6 backport. If you use any other bpo packages, you should see them receiving upgrades in your aptitude logs. 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. Several munin developers and users use munin with lighttpd, so you might find help in the #munin channel on oftc.net IRC. In the process, with your help, we could improve the documentation and packaging of munin and its integration with lighttpd. 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
Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
... Hoping onto the thread. On Tue, Jun 26, 2012 at 9:40 AM, Kenyon Ralph ken...@kenyonralph.com wrote: CGI graphing was not the default in munin 1.4. So, for most installations, munin 2.0 is a significant change in this respect. 1.4 defaults to cron. 2.0 is mostly CGI-only. I'm working on bringing back cron graphing in 2.0, since several users reported issues with CGI setup. Should land on 2.0.2. 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? A bug report is a perfect place to trace down things. So thanks to have opened it. That said, for proper/fast resolution, see below. Several munin developers and users use munin with lighttpd, so you might find help in the #munin channel on oftc.net IRC. That's currently your best bet (IRC), as I do also use lighttpd. Since I'm using a fairly dodgy setup on my dev box and I lack time to write proper doc, well... In the process, with your help, we could improve the documentation and packaging of munin and its integration with lighttpd. That's also in the process. As kenyon suggested, if you even take part of it, many would be more than glad to spend some time with you debugging. Then once the doc is adequate on the matter, packaging integration will happen quite quickly, for everyone's benefit. So, sorry for the inconvenience, but a hop on IRC will show you that we're not in our ivory tower. Just that we are unfortunately quite busy... -- Steve Schnepp http://blog.pwkf.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
On 6/26/2012 2:40 AM, Kenyon Ralph wrote: On 2012-06-26T00:44:12-0500, Stan Hoeppner s...@hardwarefreak.com wrote: On 6/25/2012 7:55 PM, Holger Levsen wrote: On Montag, 25. Juni 2012, Stan Hoeppner wrote: 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. CGI graphing was not the default in munin 1.4. So, for most installations, munin 2.0 is a significant change in this respect. 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. I think you misunderstand what aptitude safe-upgrade means. No, it doesn't mean it only pulls from a certain repository. It doesn't mean that the packages are safe or tested or non-broken. It just has to do with how aptitude resolves dependencies and decides whether to upgrade packages or not. See the aptitude documentation. I have no such misunderstanding of safe-upgrade. I just didn't realize aptitude would upgrade bpo's automatically. I'd have preferred to discover this fact under different circumstances. Some lessons are best learned when the pain factor is high I guess. :( 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? Yes, if you have a bpo package installed, and there is a newer version available, by default, the newer version will be selected for upgrade. I find apt-cache policy very handy to see what APT thinks about a particular package's versioning situation. Thank you for this pointer. I've never had to use this before, but it will surely come in handy now. 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: As you know from your 11 years of Debian experience, none of the developers can test every situation. Of course not. And devs obviously aren't going to be using the backports system, so they wouldn't think to test such a scenario. Indeed, this package came from the testing distribution, and has not been in the stable distribution yet. So, thanks for being a tester and pointing out some areas of potential improvement. More like unwitting guinea pig. ;) But seriously, I'd be glad to assist further in any way I can. 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. This behavior has not changed. You had a backport package installed, so it was simply upgraded to a newer backport package. You must have manually installed the 1.4.6 backport. If you use any other bpo packages, you should see them receiving upgrades in your aptitude logs. Yes, I did manually install 1.4.6 bpo. I'll check, but I'm pretty sure this is the first time this has happened. I was running a Postfix bpo and munin bpo, maybe another. The former both got upgraded this time with the newer bpo. Prior to now, I don't believe any newer bpo's were ever available when I upgraded, which caused me to have a false assumption about this upgrade behavior. munin or reconfigure apt/aptitude to grab packages from backports by default, which is not sensible.
Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
On 6/26/2012 10:50 AM, Steve Schnepp wrote: ... Hoping onto the thread. On Tue, Jun 26, 2012 at 9:40 AM, Kenyon Ralph ken...@kenyonralph.com wrote: CGI graphing was not the default in munin 1.4. So, for most installations, munin 2.0 is a significant change in this respect. 1.4 defaults to cron. 2.0 is mostly CGI-only. I'm working on bringing back cron graphing in 2.0, since several users reported issues with CGI setup. Should land on 2.0.2. I may end up being such a user. The machine on which I run the munin front end is an ancient dual CPU 550MHz Pentium II box. The cron graphing mode worked great. I fear the real time HTML and CGI graphing will be painfully slow, especially if the intentionally single threaded comment I read means it will only use one CPU for graph generation. With this machine, obviously, both CPUs need to be in play as often as possible given the low clock. Hopefully I'll get 2.0 running soon and can give feedback. 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? A bug report is a perfect place to trace down things. So thanks to have opened it. You're welcome. Sorry that my original report wasn't concise and slowed the process down. I simply didn't know the exact nature/cause at the time, simply that something went horribly wrong in the upgrade. That said, for proper/fast resolution, see below. Several munin developers and users use munin with lighttpd, so you might find help in the #munin channel on oftc.net IRC. That's currently your best bet (IRC), as I do also use lighttpd. Since I'm using a fairly dodgy setup on my dev box and I lack time to write proper doc, well... If multiple/many munin devs use lighty, then ... need I ask the obvious? In the process, with your help, we could improve the documentation and packaging of munin and its integration with lighttpd. That's also in the process. As kenyon suggested, if you even take part of it, many would be more than glad to spend some time with you debugging. Sure. I' was going to try to revert back to 1.4.6. But I can live without my graph data for a little while if I can help get 2.0 + lighty working better for all users. Then once the doc is adequate on the matter, packaging integration will happen quite quickly, for everyone's benefit. So, sorry for the inconvenience, but a hop on IRC will show you that we're not in our ivory tower. Just that we are unfortunately quite busy... What's best time of day for IRC? I'm Central US. I ask as some projects have many participants in far flung time zones. -- Stan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
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.) 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. 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. 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. 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. 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). for that you either need to explicitly say apt-get install -t backports munin or reconfigure apt/aptitude to grab packages from backports by default, which is not sensible. 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. 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. 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 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
Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)
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
