Bug#1040742: mailman3: Unable to 'dpkg-reconfigure' with MySQL after failed attempt
Package: mailman3 Version: 3.3.3-1 Severity: normal Dear Maintainer, * What led up to the situation? I am attempting to use Mysql as the database backend. I ran `dpkg-reconfigure mailman3` as directed in README.Debian, but encountered an error because it couldn't reach my MySQL instance. I was able to 'abort' which brought me to a shell. I corrected the database problem and tried to `dpkg-configure mailman3` again, but it only stated "Determining localhost credentials from /etc/mysql/debian.cnf: succeeded." without asking any more prompts or finishing the configuration. Even if I use -plow I cannot force it to run the reconfiguration, to even ask whether I want to use SQLite or MySQL much less configure them properly. * What exactly did you do (or not do) that was effective (or ineffective)? As mostly explained above, I used `dpkg-reconfigure mailman3` and `dpkg-reconfigure -plow mailman3`. * What was the outcome of this action? The package was not proper reconfigured. * What outcome did you expect instead? Prompts about which database to use and how to configure it, including prompting me for the password. -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mailman3 depends on: ii dbconfig-mysql 2.0.19 ii dbconfig-sqlite3 2.0.19 ii debconf [debconf-2.0]1.5.77 ii init-system-helpers 1.60 ii logrotate3.18.0-2+deb11u1 ii lsb-base 11.1.0 ii python3 3.9.2-3 ii python3-aiosmtpd 1.2.2-1 ii python3-alembic 1.4.3-1 ii python3-authheaders 0.13.1-1 ii python3-authres 1.2.0-2 ii python3-click7.1.2-1 ii python3-dateutil 2.8.1-6 ii python3-dnspython2.0.0-1 ii python3-falcon 2.0.0-2+b1 ii python3-flufl.bounce 3.0.1-1 ii python3-flufl.i18n 3.0.1-1 ii python3-flufl.lock 5.0.1-1 ii python3-gunicorn 20.1.0-1 ii python3-importlib-resources 5.1.0-1 ii python3-lazr.config 2.2.3-1 ii python3-passlib 1.7.4-1 ii python3-psycopg2 2.8.6-2 ii python3-public 0.5-1.1 ii python3-requests 2.25.1+dfsg-2 ii python3-sqlalchemy 1.3.22+ds1-1 ii python3-zope.component 4.3.0-3 ii python3-zope.configuration 4.4.0-1 ii python3-zope.event 4.4-3 ii python3-zope.interface 5.2.0-1 ii ucf 3.0043 Versions of packages mailman3 recommends: ii exim4-daemon-heavy [mail-transport-agent] 4.94.2-7 Versions of packages mailman3 suggests: pn mailman3-doc ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.19-0+deb11u2 ii w3m [www-browser] 0.5.3+git20210102-6+deb11u1 -- debconf information: mailman3/password-confirm: (password omitted) mailman3/app-password-confirm: (password omitted) * mailman3/db/basepath: /var/lib/mailman3/data mailman3/upgrade-error: abort * mailman3/db/dbname: mailman.db mailman3/init_service_failed: mailman3/install-error: abort mailman3/purge: false mailman3/missing-db-package-error: abort mailman3/internal/skip-preseed: false mailman3/dbconfig-reinstall: false mailman3/dbconfig-upgrade: true mailman3/dbconfig-remove: true * mailman3/config_hyperkitty: true mailman3/passwords-do-not-match: mailman3/remove-error: abort * mailman3/dbconfig-install: true mailman3/upgrade-backup: true mailman3/internal/reconfiguring: false * mailman3/database-type: sqlite3
Bug#849960: mysql-utilities: Python TypeError when using mysqldiskusage
Package: mysql-utilities Version: 1.3.5-2 Severity: normal Dear Maintainer, I attempted to run 'mysqldiskusage' (as root, so as to have access to the datadir). I got the following error: # Source on localhost: ... connected. Traceback (most recent call last): File "/usr/bin/mysqldiskusage", line 154, in diskusage.show_database_usage(servers[0], datadir, args, options) File "/usr/lib/python2.7/dist-packages/mysql/utilities/command/diskusage.py", line 547, in show_database_usage include_empty or do_all) File "/usr/lib/python2.7/dist-packages/mysql/utilities/command/diskusage.py", line 391, in _build_db_list db_total = int(row[1]) + misc_files TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' * What led up to the situation? running 'mysqldiskusage' without any arguments at the root command prompt * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? The error message referenced above * What outcome did you expect instead? The output of the command. Note that it does run as expected as a non-root user, with the warning message: NOTICE: Your user account does not have read access to the datadir. Data sizes will be calculated and actual file sizes may be omitted. Some features may be unavailable. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mysql-utilities depends on: ii python 2.7.9-1 ii python-mysql.connector 1.2.3-2 mysql-utilities recommends no packages. mysql-utilities suggests no packages. -- no debconf information
Bug#690543: id3v2: Unable to stat file when mounted via CIFS
Subject: id3v2: Unable to stat file when mounted via CIFS Package: id3v2 Version: 0.1.12-2 Severity: normal When using id3v2 to read or write tags to files on a CIFS mount, I get an error message unable to stat file. A bit of Googling suggests that this can be solved by export CPPFLAGS=-D_FILE_OFFSET_BITS=64 before configure during compilation. Indeed, testing my own build this seems to be the case. The best information I found is in a bug report for exiv2 at https://bugs.archlinux.org/task/24808?opened=4276status[0]= but the explanation seems to apply equally to id3v2. -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages id3v2 depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8GCC support library ii libid3-3.8.3c2a 3.8.3-13 A library for manipulating ID3v1 a ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime id3v2 recommends no packages. id3v2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690102: exiv2: Failed to open the file error on CIFS mounts
Package: exiv2 Version: 0.20-2 Severity: normal Hi, When using exiv2 to add, display, or edit metadata for a file that resides on an CIFS mount, the program exits with the error message Failed to open the file. This seems to be a known situation which can be resolved by doing an export CPPFLAGS=-D_FILE_OFFSET_BITS=64 before configure during compilation. Indeed that fixed the problem on my system. A bit of technical explination can be found at [1] and additional discussion at [2] and [3]. Regards 1 - https://bugs.archlinux.org/task/24808?opened=4276status[0]= 2 - http://dev.exiv2.org/boards/3/topics/930 3 - http://dev.exiv2.org/boards/3/topics/983 -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages exiv2 depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libexiv2-90.20-2 EXIF/IPTC metadata manipulation li ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 exiv2 recommends no packages. exiv2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684110: [php-maint] Bug#684110: php5-mysql: Doesn't seem to restart Apache as part of configuration process
Hi, and thanks for the extremely quick response. I hope the attached output from script is suitable and answers your question. It looks a bit odd in my editor due to the control codes, but cat makes it look all pretty. Let me know if I can do anything further to help diagnose the problem. Regards, ~isaac On Tue, Aug 7, 2012 at 3:58 AM, Ondřej Surý ond...@debian.org wrote: Hi Isaac, I believe this was fixed in 5.2.11.dfsg.1-1 and should not happen in squeeze. Could you please try to reproduce it and attach the output of terminal to this bug report? O. On Tue, Aug 7, 2012 at 6:03 AM, Isaac Bennetch is...@bennetch.org wrote: Package: php5-mysql Version: 5.3.3-7+squeeze13 Severity: normal Hi, I already had apache2, php5, mysql-server-5.1, etc and then attempted to install php5-mysql. I expected it to gracefully restart apache to force the reloading of the new configuration options, but that doesn't seem to have happened. After aptitude finished configuring, I reloaded the output of my phpinfo() and didn't see the additions from php5-mysql. I manually ran apache2ctl graceful and reloaded the page again; the expected extensions and configuration changes were displayed this time. I expect php5-mysql to automatically tell apache2 to reload the new configurations rather than me having to figure that out on my own. Thanks -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php5-mysql depends on: ii libapache2-mod-php5 [p 5.3.3-7+squeeze13 server-side, HTML-embedded scripti ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libmysqlclient16 5.1.63-0+squeeze1 MySQL database client library ii php5-common5.3.3-7+squeeze13 Common files for packages built fr php5-mysql recommends no packages. php5-mysql suggests no packages. -- no debconf information ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- Ondřej Surý ond...@sury.org php5-mysql.typescript Description: Binary data
Bug#684110: php5-mysql: Doesn't seem to restart Apache as part of configuration process
Package: php5-mysql Version: 5.3.3-7+squeeze13 Severity: normal Hi, I already had apache2, php5, mysql-server-5.1, etc and then attempted to install php5-mysql. I expected it to gracefully restart apache to force the reloading of the new configuration options, but that doesn't seem to have happened. After aptitude finished configuring, I reloaded the output of my phpinfo() and didn't see the additions from php5-mysql. I manually ran apache2ctl graceful and reloaded the page again; the expected extensions and configuration changes were displayed this time. I expect php5-mysql to automatically tell apache2 to reload the new configurations rather than me having to figure that out on my own. Thanks -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php5-mysql depends on: ii libapache2-mod-php5 [p 5.3.3-7+squeeze13 server-side, HTML-embedded scripti ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libmysqlclient16 5.1.63-0+squeeze1 MySQL database client library ii php5-common5.3.3-7+squeeze13 Common files for packages built fr php5-mysql recommends no packages. php5-mysql suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#409286: Re: Bug#409286
Hi Dan, thanks for your comments, also thanks to Thijs for your work with this package. But wait, first split that giant file into chapter files. This has been suggested in the past and the phpMyAdmin developers prefer one large file so that a user can search more easily for their error string or circumstance. Who knows, they may be willing to reconsider if they receive enough feedback on it, but that's historically been the purpose behind one large file. By the way, Documentation.html lacks a section about day to day normal usage. [snip] Obviously there is a missing tutorial. This is true, and currently one of the biggest problems with the releases. If you have any suggestions as to what people need to learn to do or what contents to include in such a tutorial, I'd love to hear them (perhaps off-list since it's not really debian-specific). By the way, there's a book published by the project maintainer which many users will find helpful: http://www.packtpub.com/mastering-phpmyadmin/book/mid/021006bbn4p8 Good luck! ~isaac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387143: phpwiki errors on loading; Driver initialization failed for handler: db4...
Greetings and thank you kindly for your response and ideas. On 9/17/06, Matt Brown [EMAIL PROTECTED] wrote: Did anything change related to PHPwiki on your system during this time (eg, upgrade to a new version, etc)? As far as I can remember, no, however I keep my system quite up to date with aptitude and don't check the list of updates as thoroughly as I should. That is to say, that any upgrade I would have gotten would have been the same anyone else with unstable packages would have gotten recently. Looking at my aptitude logs I can't find anything relevant that's changed since it worked. Did anything related to DB4 or PHP's DB4 bindings change on your system during this time? Again, if it did, it would have been because of a package update, but I can't find anything relevant. I certianly didn't mess with anything manually. The file location (/var/lib/phpwiki/phpwiki_pagedb.db4) is not a standard location configured by the package, as far as I know, have you configured this PHPwiki instance manually? Even stranger, as I did not manually configure it. Are you sure the specified database file is writeable by the webserver? Yes Is the specified database file valid (perhaps the tools from the db4.4-util package can help here)? db4.4_verify returns 0, or no errors found; db4.4_stat -d returns valid output; db4.4_dump gives a very very very long list of digits (with a few charachters thrown in, looks like a hex dump maybe). Given all that, I assume it's valid, though my experience with db4 files is lacking. At this stage, with the information you've provided this looks very much like a configuration error, or a corrupted database, rather than a bug in PHPwiki. Very understandable, and thank you for your tips so far; Is this then something I need to ask the phpwiki project itself about? If you have any further suggestions I'm welcome to them. Please provide some more information that would help to pinpoint and reproduce this problem. Particularly answers to the questions above. Additionally, I have the file 'pagedb.db4' in the /var/lib/phpwiki folder and tried moving phpwiki_pagedb.db4 out of the way and replacing it with the pagedb.db4, and recieved the same error. pagedb.db4 is much smaller and I thought perhaps it's the default file used to set things up or something, regardless of what it actually is I get the same error. I'm still surprised that you feel my files are in a non-standard place, since aptitude should have handled everything automatically, I certainly don't remember moving it and would have no reason to have done so. `dpkg -L phpwiki` lists /var/lib/phpwiki for what that's worth. Any more than that, though, and I'm at a loss. Additionally, I've backed up my phpwiki files, purged the package (and it's dependancies), and reinstalled. It worked. I copied my phpwiki_pagedb.db4 to replace the default, and there was no change (it didn't break, but my wiki didn't appear, either). Finally I copied my config.ini file to replace the default in /etc/phpwiki/, and it broke again -- so it does seem to be my config.ini file, though I hadn't edited it since it was working, so I still don't know what the problem was. Not that it matters much, though, if I'm able to recover my database I'll be happy (and if not, hey, that's what backups are for)... Cheers Thanks, you too ~isaac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387143: phpwiki errors on loading; Driver initialization failed for handler: db4...
In other words, unless I've given you some hint as to what may be the matter, I'll just throw this out as some freak configuration glitch and reload my dumps. Thanks so much! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387143: phpwiki errors on loading; Driver initialization failed for handler: db4...
Package: phpwiki Version: 1.3.12p3-1 Severity: normal Greetings, I have a problem with my phpwiki install. I haven't accessed it in some time (perhaps a week), but now get an error attempting to load any page: lib/DbaDatabase.php:54: Error: dba_open(/var/lib/phpwiki/phpwiki_pagedb.db4,w) [a href='function.dba-open'function.dba-open/a]: Driver initialization failed for handler: db4: Unknown error 139424368 * file: /var/lib/phpwiki/phpwiki_pagedb.db4 * mode: w * handler: db4 This appears twice. Any ideas? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages phpwiki depends on: ii apache [httpd]1.3.34-4 versatile, high-performance HTTP s ii apache-ssl [httpd]1.3.34-4 versatile, high-performance HTTP s ii debconf 1.5.4 Debian configuration management sy ii php-db1.7.6-2PHP PEAR Database Abstraction Laye ii php4 4:4.4.4-1 server-side, HTML-embedded scripti ii php4-pear 4:4.4.4-1 PHP Extension and Application Repo ii php4-sqlite 1.0.2-12 PHP4 bindings to SQLite, a file-ba ii sqlite2.8.16-1 command line interface for SQLite ii ucf 2.0014 Update Configuration File: preserv phpwiki recommends no packages. -- debconf information: * phpwiki/system/accessible: global * phpwiki/system/purgepages: false * phpwiki/system/documentroot: /phpwiki phpwiki/system/localnet: 10.0.0.0/24 * phpwiki/notes/configupgrade: * phpwiki/webservers: apache * phpwiki/notes/introduction: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247999: spelling errors
While it's a relatively minor bug, the typos in the checkinstall man page are nearly two years old. The original reporter was kind enough to include a patchfile, can this be fixed in the package? Thanks!
Bug#300312: missing PNG files found
Greetings, I had the same problem -- on the project details page the
percent complete images don't load. This is because on line 1628 of
details.php:
img
src=\themes/{$flyspray_prefs['theme_style']}/percent-{$task_details'percent_complete']}.png\
$flyspray_prefs['theme_style'] is empty here -- the key them_style
doesn't exist in the flyspray_prefs database. I fixed it by changing
it to $project_prefs['theme_style'] so the new src tag reads:
src=\themes/{$project_prefs['theme_style']}/percent-{$task_details'percent_complete']}.png\
Upstream seems to have either fixed this or never had this because
thier site does properly display the percent complete.
Hope it helps someone.
My appoligies if I messed up submitting this; it's my first time :-)
