Hello Paul Gevers. Thanks for your followup.
On Tue, Jun 30, 2015 at 10:14:15PM +0200, Paul Gevers wrote: > Hi Andreas, > > On 29-06-15 23:35, Andreas Henriksson wrote: > > Looks like this issue is very much introduced by dbconfig-common > > not properly handling running from scripts that use 'set -e' > > anymore. > > I am not yet sure that I agree, but... > > > I'm thus reassigning it as instructed... > > That is fine for now. Feel free to reassign back if/when you're confident in dbconfig-common working as expected and think action should be taken on the bandwidthd(-pgsql) side. > > > Quickly looked at the problem and spotted an issue when running > > under 'set -e'. See attached patch. > > If I am not mistaken, things go wrong earlier. For the moment I believe > that the script should fail here if there is an error (there shouldn't > be one). Might be so. I just looked at the old and the new code. The old code seems to deal with that debconf query failing. The new code doesn't. Didn't investigate deeper if it should never fail. Didn't think that mattered. If it should never fail, feel free to debug why it does fail when it shouldn't. ;P > > > With the patch applied to dbconfig-common, the installation > > of bandwidthd-pgsql continues much further until it runs in to yet > > another issue which I've not yet had time to investigate > > (however it doesn't seem to be specific to anything the > > bandwidthd-pgsql package does either): > > Can you help me with understanding what you do in the postinst/config > scripts of bandwidthd? This was all put together a very long time ago but the big picture should be something like this: - fetch network information from the running system and pre-populate the debconf answers (ie. available network interfaces as options, subnet on given interface, database information like hostname for sensor id, etc.) - ask questions (giving user possibility to adjust detected config) - generate a new configuration file based on debconf info. - let ucf install the new configuration file on the system. > E.g. why don't you run dbconfig-common during > config, like in section 3.1.2 of the ch-develguide.html page in the > dbconfig-common package? Also, why is the dbc_go call in the postinst > AFTER the reading of /etc/dbconfig-common/bandwidthd-pgsql.conf ? At > first sight, that doesn't make much sense. The current state is what has worked for many years. It's been working for quite some years now so I haven't touched anything. Before that things where always very fragile. Things constantly broke. I tried debugging dbconfig-common back then and submitted patches to improve it but never got anywhere and there where just too many issues to deal with. I invested way too much time in trying to fix things. The current state might not be accoring to recommended best practises but it has worked in practise (which many of the recommended things has not done in the past according to my experience). If you think there are easy fixes in bandwidthd, then I'm all for applying them.... but I have a sour taste in my mouth after dealing with constant breakage in the past so I'm inclined to just give up on dbconfig-common and drop the pgsql-backed alternative of bandwidthd. Anyway, I thought I'd give you a chance to look at these issues since you seem to be motivated to improve dbconfig-common and see if you spot any issue you want fixed. The new version clearly causes some kind of regression (which might be caused by incorrect usage in bandwidthd-pgsql which happened to work in the past, or maybe newly introduced bugs in dbconfig-common). > > > + RET='10 bandwidthd-pgsql/pgsql/method doesn'\''t exist' > > This should indeed not happen, these templates should be installed > during config. Although I don't see exactly why yet, it may be related > to the item mentioned above, no call from your config to dbc. > > During my (manual) trials, I was not able to trigger the dbconfig-common > questions, but also not the failure. Do you have a recipe to I reproduce > this issue? The problem is reproducible by just doing a clean install of bandwidthd-pgsql in unstable (and likely testing as well). It was originally detected by piuparts after the new version of dbconfig-common hit unstable. The full piuparts log is attached to the original bug report. Do the same thing on a system with the old dbconfig-common (from stable?) and bandwidthd-pgsql installs cleanly. The database-related questions not showing up is something that I remember happening sometimes in the past as well and resulted in tweaks back then. Maybe that problem has come back without me noticing it since I don't use the pgsql-backed version myself (and noone else reported any issues). Anyway, the package doesn't even install cleanly now which it clearly did in the past. I'm inclined to first focus on the package installing at all, then look at if dbconfig-common actually sets up the database configuration. Thanks for your interest in this issue. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
