Bug#989140: roundcube-core: Error displayed during upgrade if manually installed plugins are in use in /var/lib/roundcube
Package: roundcube Version: 1.4.11+dfsg.1-4 Severity: minor During an upgrade of roundcube-core, if there are any manually installed plugins in /var, then an error is shown: Setting up roundcube-mysql (1.4.11+dfsg.1-4) ... Setting up libx11-xcb1:amd64 (2:1.7.1-1) ... Setting up roundcube-core (1.4.11+dfsg.1-4) ... Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf dbconfig-common: flushing administrative password ERROR: Failed to load plugin file /usr/share/roundcube/plugins/show_gravatar/show_gravatar.php Setting up roundcube-plugins (1.4.11+dfsg.1-4) ... Setting up roundcube (1.4.11+dfsg.1-4) ... Processing triggers for libc-bin (2.31-12) ... Processing triggers for man-db (2.9.4-2) ... Something is either looking at the roundcube configuration, or iterating through all the plugins in /var/lib/roundcube/plugins and wanting to associate them with the package-supplied plugins which are in /usr/lib/roundcube/plugins. However, only plugins supplied by the package /should rightfully exist in /usr/lib/roundcube/plugins. The script can assume that all plugins in /usr/lib/roundcube/plugins/* exist as a link to /var/lib/roundcube/plugins/*, but the reverse cannot be assumed. Why the upgrade script for roundcube-core was looking at the plugins, and why it made the assumption that the /var plugins must also all exist in /usr is unknown. It may be a disply-only error with no actual ramifications. That being said, the assumption of a reverse correlation shouldn't be made. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.75 ii dpkg1.20.9 ii libjs-bootstrap44.5.2+dfsg1-6 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-cli 2:7.4+76 ii php-common 2:76 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp1.9.0-1 ii php-net-socket 1.2.2-2 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii php7.4-intl [php-intl] 7.4.15-5+deb11u1 ii php7.4-json [php-json] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-4 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii lighttpd [httpd-cgi]1.4.59-1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 ii php-pspell 2:7.4+76 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1 ii spawn-fcgi 1.6.4-2 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ii roundcube-plugins 1.4.11+dfsg.1-4 Versions of packages roundcube depends on: ii dpkg 1.20.9 -- Configuration Files: /etc/roundcube/lighttpd.conf changed [not included] -- debconf information excluded
Bug#985866: roundcube-core: Missing dependency
Package: roundcube Version: 1.4.11+dfsg.1-3 Followup-For: Bug #985866 This is actually a simple missing dependency. The package libjs-less needs to be a dependency of roundcube to correct the broken symlink. The libjs-less package is a CSS meta-language. From what I can tell, the only time it is used in roundcube is if it is set to devel-mode. I would suggest that it's not worth the bother to put in the dependency for a devel mode that you'd have to dig into the source to even know was there. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.75 ii dpkg1.20.9 ii libjs-bootstrap44.5.2+dfsg1-6 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-cli 2:7.4+76 ii php-common 2:76 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp1.9.0-1 ii php-net-socket 1.2.2-2 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii php7.4-intl [php-intl] 7.4.15-5+deb11u1 ii php7.4-json [php-json] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-3 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii lighttpd [httpd-cgi]1.4.59-1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 ii php-pspell 2:7.4+76 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1 ii spawn-fcgi 1.6.4-2 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ii roundcube-plugins 1.4.11+dfsg.1-3 Versions of packages roundcube depends on: ii dpkg 1.20.9 -- Configuration Files: /etc/roundcube/lighttpd.conf changed [not included] -- debconf information excluded
Bug#706061: Please revisit and create /etc/opendkim/
I think this bug/request and its solution could use a revisit. I'm not sure about the state of the art in 2013, but in 2021 configuring OpenDKIM almost any virtual mail server requires a lot more configuration files. The new two-part signing system does not lend itself well to just a keys directory and opendkim.conf directly in /etc. The usual practice is a directory structure as shown: etc ├── opendkim | ├── opendkim.conf | ├── KeyTable | ├── SigningTable | ├── TrustedHosts | ├── Keys | | ├── domain1.ca | | | ├── mail.private | | | ├── mail.txt | | ├── domain2.ca | | | ├── mail.private | | | ├── mail.txt | | ├── ... | | | The original request back in 2013 was to create /etc/opendkim and to place the config file inside it. This is the standard practice for most anything that is non-trivial to configure. I would like to request that this be adopted. Backwards compatibility with the old method can be maintained by making /etc/opendkim.conf a softlink to /etc/opendkim/opendkim.conf. It is telling that I can find no howto or tutorial for OpenDKIM on Debian that doesn't instruct the user to create /etc/opendkim for further use: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy https://allysmith.uk/using-dkim-with-postfix-on-debian https://meumobi.github.io/sendmail/2015/09/18/install-configure-dkim-sendmail-debian.html It would be a benefit if OpenDKIM's out-of-the box configuration structure could match what current practices are in the wild.
Bug#988236: Likely the best solution
For what it's worth, I concur with this solution. The lighty-enable-mod and -disable-mod helpers are an abstraction layer that certainly originated with Debian and may still be unique to Debian (et al). They came into being sometime in 2005-ish. While, as an abstraction, its purpose is to hide the underlying config file mechanics, I can't see the underlying mechanism changing any time soon if it hasn't in the last 16 years. Upstream lighty has never adopted this abstraction, so I can't see it worth the trouble to expand on it now. I think you've lighted (hah) upon the best solution here.
Bug#988327: dovecot-sieve: Request package create /var/lib/dovecot/sieve and /var/lib/dovecot/sieve/sieve.d directories
Package: dovecot-sieve Version: 1:2.3.13+dfsg1-1 Severity: wishlist Dear Maintainer, Background: Dovecot's sieve plugin allows for server-side mail filtering scripts. These are typically stored on a per-user basis. It also allows for a server default script to be run if there are no user scripts for that user, and also both "before" and "after" directories where a series of scripts will be run before and after the user script is run. Debian's dovecot-sieve package does not create the directory where the server default script lives. By (ug) default, this location is: /usr/lib/dovecot/sieve And the file to be put in that location would be default.sieve and then compiled. Debian also does not create the before or after directories. There is no default location for them, but the first suggested location for it given in /etc/dovecot/90-sieve.conf is: #sieve_before = /var/lib/dovecot/sieve.d Request: 1) I propose that the dovecot-sieve package create the default directory that holds default.sieve. 2) I propose a sample default.sieve script be stored in the above directory. Less as an actual sample, and more as a marker for "this is where it goes" 3) I propose that the first suggested location for the "sieve_before" directory be changed to be a subdirectory of the above: #sieve_before = /var/lib/dovecot/sieve/sieve.d 4) I propose a short readme be placed in 3)'s directory. Again, mostly just as a marker for "this is where the before scripts go" Thus the directory structure I propose is: /var/lib/dovecot/sieve/ ├── default.sieve.sample └── sieve.d/ └── readme.before I would be happy to provide the files proposed in #2 and #4. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dovecot-sieve depends on: ii dovecot-core 1:2.3.13+dfsg1-1 ii libc6 2.31-11 ii ucf 3.0043 dovecot-sieve recommends no packages. dovecot-sieve suggests no packages. Versions of packages dovecot-sieve is related to: ii dovecot-core [dovecot-common] 1:2.3.13+dfsg1-1 pn dovecot-dev pn dovecot-gssapi ii dovecot-imapd 1:2.3.13+dfsg1-1 pn dovecot-ldap ii dovecot-lmtpd 1:2.3.13+dfsg1-1 ii dovecot-managesieved 1:2.3.13+dfsg1-1 ii dovecot-mysql 1:2.3.13+dfsg1-1 pn dovecot-pgsql ii dovecot-pop3d 1:2.3.13+dfsg1-1 ii dovecot-sieve 1:2.3.13+dfsg1-1 pn dovecot-sqlite -- no debconf information
Bug#988323: fail2ban: Debian's custom roundcube log location not reflected in fail2ban's debian paths
Package: fail2ban Version: 0.11.2-1 Severity: normal Tags: patch Dear Maintainer, When the Debian roundcube packages are used, Debian places its error log in /var/log/roundcube/errors.log While fail2ban's default paths has it at: /var/log/roundcube/errors This means that activating fail2ban's built-in roundcube rules will cause fail2ban to be unable to start. Since Debian moved the log from its common location, the omission of the path in paths-debian.conf is a bug as it makes the built-in rule fail. Attached is a patch to correct this. It simply adds the correct path to path-debian.conf. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fail2ban depends on: ii lsb-base 11.1.0 ii python3 3.9.2-3 Versions of packages fail2ban recommends: ii iptables 1.8.7-1 ii python3-pyinotify 0.9.6-1.3 ii python3-systemd234-3+b4 ii whois 5.5.9 Versions of packages fail2ban suggests: ii bsd-mailx [mailx]8.1.2-0.20180807cvs-2 pn monit ii rsyslog [system-log-daemon] 8.2102.0-2 pn sqlite3 -- no debconf information *** /home/kfitzner/fail2ban_debian_roundcube.diff --- paths-debian.conf 2020-11-23 16:43:03.0 -0400 +++ paths-debian.conf.fixed 2021-05-10 09:48:41.193223094 -0300 @@ -24,5 +24,7 @@ exim_main_log = /var/log/exim4/mainlog # was in debian squeezy but not in wheezy # /etc/proftpd/proftpd.conf (SystemLog) proftpd_log = /var/log/proftpd/proftpd.log + +roundcube_errors_log = /var/log/roundcube/errors.log --- paths-debian.conf 2020-11-23 16:43:03.0 -0400 +++ paths-debian.conf.fixed 2021-05-10 09:48:41.193223094 -0300 @@ -24,5 +24,7 @@ exim_main_log = /var/log/exim4/mainlog # was in debian squeezy but not in wheezy # /etc/proftpd/proftpd.conf (SystemLog) proftpd_log = /var/log/proftpd/proftpd.log + +roundcube_errors_log = /var/log/roundcube/errors.log
Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script
If you're not convinced try to... You are correct. It is indeed very difficult to get the client to even use TCP/IP on a local machine any more, which I could only do by setting the host to 127.0.0.1. The word "localhost" now seems to exclusively mean unix socket for mysql. Thank-you, that not only turns this into a non-bug, but it means I can relax a bit on my configurations for mysql/mariadb in the future and not worry about ensuring they are explicitly set to unix sockets across the board.
Bug#988282: roundcube-core: Uninstall fails in lighttpd environment
Package: roundcube-core Version: 1.4.11+dfsg.1-3 Severity: normal In a lighttpd environment, roundcube-core fails to uninstall/purge. Comments to follow apt's output: # apt-get purge roundcube roundcube-plugins roundcube-plugins-extra roundcube-core roundcube-mysql Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: fonts-glyphicons-halflings libjs-bootstrap libjs-jquery-minicolors libjs-jstimezonedetect php-auth-sasl php-intl php-mail-mime php-masterminds-html5 php-net-sieve php-net-smtp php-net-socket php-pspell php7.4-intl php7.4-pspell Use 'apt autoremove' to remove them. The following packages will be REMOVED: roundcube* roundcube-core* roundcube-mysql* roundcube-plugins* roundcube-plugins-extra* 0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded. After this operation, 25.6 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 70765 files and directories currently installed.) Removing roundcube (1.4.11+dfsg.1-3) ... Removing roundcube-plugins-extra (1.4.10+1-3) ... Removing roundcube-plugins (1.4.11+dfsg.1-3) ... Removing roundcube-core (1.4.11+dfsg.1-3) ... Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. dbconfig-common: dumping mysql database roundcube to /var/tmp/roundcube.roundcube.2021-05-09-12.53.mysql.BQZjK8. dbconfig-common: dropping mysql database roundcube. dropping database roundcube: success. verifying database roundcube was dropped: success. dbconfig-common: revoking privileges for user roundcube on roundcube. revoking access to database roundcube from roundcube@localhost: success. Ignoring unknown module: roundcube Run "service lighttpd force-reload" to enable changes dpkg: error processing package roundcube-core (--remove): installed roundcube-core package post-removal script subprocess returned error exit status 2 dpkg: too many errors, stopping Errors were encountered while processing: roundcube-core Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) It is failing on disabling roundcube's lighttpd config. This appears to be happening because the softlink /etc/lighttpd/conf-available/50-roundcube.conf to /etc/roundcube/lighttpd.conf is being removed before lighttpd-disable-mod is being run. For lighttpd-disable-mod to succeed, apparently the file must occur in both conf-enabled and conf-available. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.75 ii dpkg1.20.9 ii libjs-bootstrap44.5.2+dfsg1-6 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-cli 2:7.4+76 ii php-common 2:76 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp1.9.0-1 ii php-net-socket 1.2.2-2 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii php7.4-intl [php-intl] 7.4.15-5+deb11u1 ii php7.4-json [php-json] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-3 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii lighttpd [httpd-cgi]1.4.59-1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 ii php-pspell 2:7.4+76 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1 ii spawn-fcgi 1.6.4-2 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ic roundcube-plugins 1.4.11+dfsg.1-3 -- debconf information excluded
Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script
After running dpkg-reconfigure roundcube-core I find that /etc/dbconfig-common/roundcube.conf remains unchanged, with the relevant bits as follows: # dbc_dbserver: database host. #leave unset to use localhost (or a more efficient local method #if it exists). dbc_dbserver='localhost' # dbc_dbport: remote database port #leave unset to use the default. only applicable if you are #using a remote database. dbc_dbport='3306' Procedure: $ apt-get purge roundcube roundcube-core roundcube-mysql $ apt-get --purge autoremove $ apt-get install roundcube Installer asks if I want to configure the database with dbconfig-common, answer yes Installer asks for me to set a password, to which I do $ dpkg-reconfigure roundcube-core Asked for IMAP server (stores answer in config.inc.php) Asked for default language, set to en-CA (stores answer in config.inc.php) Asked if I want to reinstall the database, select YES Asked for connection method, select UNIX SOCKET (no apparent effect) Asked for authentication plugin, select default Asked for database name, select roundcube Asked for username, select roundcube Asked for password, set it (x 2) Asked for configuration account, set to root Asked for what http servers to configure, select lighttpd Asked if I want to restart lighttpd, select no Expected behavior: Both debian-db.php and /etc/dbconfig-common/roundcube.conf should reflect the selected Unix Socket method of connection. Actual behavior: Both files retain "localhost" as the server and "3306" as the port. I have tried this several times with the same result every time. I even tried using a different password for the roundcube user in the reconfigure that I did during the initial install. The new password makes it through to dbconfig-common. The updated connection method setting does not.
Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script
Package: roundcube Version: 1.4.11+dfsg.1-3 Severity: normal Background: When roundcube is installed, the configuration script at that time only asks what password you want for the roundcube mysql database user. This then causes a default database connection settings file to be created as /etc/roundcube/debian-db.php through dbconfig-common. The "correct" ways to alter the connection settings are then given (through comments in the above file and in /etc/roundcobe/config.inc.php) as to either use dpkg-reconfigure or to edit /etc/dbconfig-common/roundcube.conf and regenerate. Both ways fail. Problem 1: If you manually run dpkg-reconfigure roundcube-core, then the full installation script is run and you are asked to specify the connection method. The default method purports to be by unix socket (though you can also select tcp/ip). Setting this to unix socket, though, has no effect anywhere. It does not make any changes to either /etc/dbconfig-common/roundcube.conf or /etc/roundcube/debian-db.php. Problem 2: The next "correct" way given in the comments to make changes to debian-db.php is to manually edit /etc/dbconfig-common/roundcube.conf. If you do edit it manually, the way to speficy unix sockets is below: # dbc_dbserver: database host. # leave unset to use localhost (or a more efficient local method # if it exists). #dbc_dbserver='localhost' dbc_dbserver='unix(/var/run/mysqld/mysqld.sock)' If you use the above setting you can then generate a config file with: $ /usr/sbin/dbconfig-generate-include /etc/dbconfig-common/roundcube.conf The generated connection settings from this will cause roundcube to correctly log in with unix sockets. However, if dpkg-reconfigure is subsequently run: $ dpkg-reconfigure roiundcube-core then it will itself fail with a connection error when it tries to connect to mysql. The above setting for dbc_dbserver was crafted to give a correct connection string when it is parsed by /etc/roundcube/debian-db-roundcube.php. So the issue is, there is no way with the given tools to make persistent configuration files that will employ unix sockets. The automated way does nothing and the manual way either creates a connection string that dbconfig can use, or that /etc/roundcube/debian-db-roundcube.php can use, but not one that will work in both. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.75 ii dpkg1.20.9 ii libjs-bootstrap44.5.2+dfsg1-6 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-cli 2:7.4+76 ii php-common 2:76 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp1.9.0-1 ii php-net-socket 1.2.2-2 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii php7.4-intl [php-intl] 7.4.15-5+deb11u1 ii php7.4-json [php-json] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-3 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii lighttpd [httpd-cgi]1.4.59-1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 ii php-pspell 2:7.4+76 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1 ii spawn-fcgi 1.6.4-2 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ic roundcube-plugins 1.4.11+dfsg.1-3 -- debconf information excluded
Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active
Package: roundcube Version: 1.4.11+dfsg.1-3 Severity: important Dear Maintainer, If roundcube is installed on a system with lighttpd, then the installer attempts to activate lighttpd's php module fastcgi-php. However, If the module fastcgi-php-fpm is already active, then having them both active breaks lighttpd and the subsequent force-reload that the installer attemmpts on lighttpd causes it to fail. On systems with lighttpd, the installer should detect if fastcgi-php-fpm is already active and if so, should not subsequently activate fastcgi-php. I'm not sure this shouldn't have a higher severity, but I'll let you judge. Thanks, Kurt Fitzner -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.75 ii dpkg1.20.9 ii libjs-bootstrap44.5.2+dfsg1-6 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-cli 2:7.4+76 ii php-common 2:76 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp1.9.0-1 ii php-net-socket 1.2.2-2 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii php7.4-intl [php-intl] 7.4.15-5+deb11u1 ii php7.4-json [php-json] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-3 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii lighttpd [httpd-cgi]1.4.59-1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 ii php-pspell 2:7.4+76 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1 ii spawn-fcgi 1.6.4-2 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ii roundcube-plugins 1.4.11+dfsg.1-3 Versions of packages roundcube depends on: ii dpkg 1.20.9 -- debconf information: roundcube/upgrade-error: abort roundcube/install-error: abort roundcube/dbconfig-remove: true roundcube/remote/newhost: roundcube/remove-error: abort roundcube/mysql/method: Unix socket roundcube/purge: false roundcube/remote/host: localhost roundcube/passwords-do-not-match: roundcube/language: en_CA roundcube/internal/skip-preseed: false * roundcube/database-type: mysql roundcube/dbconfig-reinstall: false roundcube/restart-webserver: true roundcube/remote/port: roundcube/hosts: * roundcube/mysql/admin-user: root roundcube/reconfigure-webserver: apache2, lighttpd roundcube/db/app-user: roundcube@localhost roundcube/upgrade-backup: true roundcube/internal/reconfiguring: false roundcube/mysql/authplugin: default roundcube/db/dbname: roundcube roundcube/missing-db-package-error: abort * roundcube/dbconfig-install: true roundcube/dbconfig-upgrade: true
Bug#922815: What is the current workaround?
Installing rcconf also installs sysv-rc, insserv, and startpar. Installing initscripts also installs sysv-rc, insserv, and startpar . If neither of those scenarios make sense without sysvinit installed, then yes, it clearly should be dependency somewhere. If insserv is not relevant on a systemd system, then please put in a conflicts. As far as how it is even useful, honestly, I am not an expert on systemd (who is?). I had previously understood that rcconf on modern Debian systems interfaced with systemd through some sort of compatibility layer. The way that "sudo service lighttpd start" and "sudo systemctl start lighttpd" both do the same thing. This seems not to be the case. I don't know what all is involved under the hood for rcconf or Debian's init systems, nor should I have to. I should know what tools are available and expect that they will work. And if tool A is not compatible with initsystem B, then it's not unreasonable to expect that trying to install A when B is there will run into a conflict somewhere. So yes, if this is a nonsensical combination, please do put in the dependencies and conflicts that will enforce that for whatever packages you maintain. Thank-you. On 2021-05-05 00:20, Thorsten Glaser wrote: > On Tue, 4 May 2021, Kurt Fitzner wrote: > >> I just tried to install rcconf on a Debian testing sytem. Since rcconf > > How is rcconf even useful on a nōn-sysvinit+sysv-rc system? > > Maybe rcconf should depend on that or conflict with all others? > > bye, > //mirabilos
Bug#988094: Patch redux
It appears the patch didn't survive some of the editing I did in
reportbug. Here it is:
--- chkservice-master/src/chk-systemd.cpp 2020-01-16 01:13:08.0
-0400
+++ chkservice-patched/src/chk-systemd.cpp 2020-01-16 10:21:25.0
-0400
@@ -517,20 +517,27 @@
}
char *names[ids->size()];
for (auto id : (*ids)) {
-names[i] = (char *) id.c_str();
+const char *name = id.c_str();
+char *copy = new char[strlen(name)+ 1];
+strcpy(copy, name);
+names[i] =copy;
i++;
}
names[i] = NULL;
try {
applyUnitState("EnableUnitFiles", names, STATE_FLAGS_ENABLE);
} catch (std::string ) {
+for (i; i < 0; --i)
+ delete names[i];
throw err;
}
+ for (i; i < 0; --i)
+ delete names[i];
}
void ChkBus::disableUnits(std::set *ids) {
int i = 0;
@@ -539,21 +546,28 @@
}
char *names[ids->size()];
for (auto id : (*ids)) {
-names[i] = (char *) id.c_str();
+const char *name = id.c_str();
+char *copy = new char[strlen(name)+ 1];
+strcpy(copy, name);
+names[i] =copy;
i++;
}
names[i] = NULL;
try {
applyUnitState("DisableUnitFiles", names, STATE_FLAGS_DISABLE);
} catch (std::string ) {
+for (i; i < 0; --i)
+ delete names[i];
throw err;
}
+ for (i; i < 0; --i)
+ delete names[i];
}
void ChkBus::enableUnit(const char *name) {
try {
std::set id;
Bug#988094: reportbug: chkservice fails to control certain services
Package: chkservice Version: 0.3-1 Severity: important Tags: patch upstream The chkservice systemd TUI is intended to be able to start, stop, enable, and disable services as a front-end for systemctl. On certain services, it fails to be able to enable or disable them, showing the errors: Failed: Invalid argument or Failed: Connection reset by peer Notably, one service that chkservice fails to be able to enable or disable on my Debian Testing (bullseye) system is lighttpd This appears to be a known upstream bug as reported here: https://github.com/linuxenko/chkservice/issues/12 There also appears to be a forked version with a correction here: https://github.com/nufeng74/chkservice I've tested the patch and is appears to work. Recommend adopting this patch into Debian. It appears to be minor enough to justify a change for testing to get into Debian 11. The problem appears to be caused by c_str temporary pointers. I'm not 100% sure there aren't security implications to this. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chkservice depends on: ii libc62.31-11 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libncurses6 6.2+20201114-2 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-5 ii libtinfo66.2+20201114-2 chkservice recommends no packages. chkservice suggests no packages. -- no debconf information
Bug#922815: What is the current workaround?
I just tried to install rcconf on a Debian testing sytem. Since rcconf requires insserv, it was installed first. During the insserv install I got: insserv: FATAL: service mountkernfs has to exist for service udev insserv: FATAL: service urandom has to exist for service networking I am curious, what is the current state of this bug? There is talk about first installing initscripts as a workaround for this. But the initscripts package also depends on insserv, so I still get the above errors. The only way I seem to be able to avoid the above fatal error messages is if I install initscripts (which tries to install insserv), and then reinstall insserv. This seems rather circular.
Bug#944490: Three different reported bugs
This is actually three different bugs. Each of which have been reported: #857791 postfixadmin & dbconfig-common: mysql/mysqli mismatch #926253 Required smart cache directory not being created #965075 postfixadmin: wrong alias in postfixadmin conf-available for apache2 I am cloning this bug and then merging the clones with the above.
Bug#965075: Needs to be fixed in testing also
This bug happened because upstream changed their directory structure and the web server config files needed to be aliased to the new directory where postfixadmin's web interface lives. Thus, the same change that was done to the apache config file should also have been done to the lighttpd configuration file. It's too bad it was fixed only in apache before the fact that lighttpd's config file was suffering from the same issue was noted in the bug report. Now I am caught between either adding lighttpd to this bug and marking the whole thing notfixed, or reporting the lighttpd issue as a separate bug. The former is really more technically correct, since they are both really the same bug, but that is the more invasive os the choices so I chose to report the lighttpd config file issue as a separate bug. It is now opened as #987998. Collectively, #965075 and #987998 should be marked as grave since the bug they represent precludes the package from functioning on nearly all systems. I have marked #965075 as such because while it is currently fixed in unstable, the version in testing is not fixed and it needs to be before postfixadmin is considered for release in Debian 11. I have not also marked #987998 as grave, but please do not backport the fix for this to testing without also fixing #987998.
Bug#926253: Missing templates_c directory
The missing templates_c directory precludes the package from functioning. The original reporter's proposed workaround doesn't properly Debianize the solution, it leaves a directory inside /usr/share that an unprivileged user can write to. It properly belongs in /var/lib/postfixadmin/templates_c. I have changed the severity to grave since this bug "makes the package in question unusable" as installed, and its unusability is a missing piece and not related to its normal configuration. This should be fixed prior to Debian 11's release or the package removed. Retaining the package will only encourage more users to use improper workarounds that may complicate things when the bug is finally and properly fixed and the user upgrades to the fixed version.
Bug#987998: postfixadmin: wrong alias in postfixadmin conf-available for lighttpd
Package: postfixadmin Version: 3.3.5-1 Followup-For: Bug #987998 This also applies to release 3.3.5-1, currently in testing
Bug#987998: postfixadmin: wrong alias in postfixadmin conf-available for lighttpd
Package: postfixadmin Version: 3.3.7-1 Severity: important Dear Maintainer, Bug #965075 also applies to the lighttpd configuration file: /etc/lighttpd/conf-available/90-postfixadmin.conf Configuration file contains: # Alias for Postfixadmin alias.url += ( "/postfixadmin" => "/usr/share/postfixadmin", ) The alias needs to point instead to /usr/share/postfixadmin/public -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postfixadmin depends on: ii dbconfig-common 2.0.19 ii debconf 1.5.75 ii lighttpd [httpd]1.4.59-1 ii mariadb-client 1:10.5.9-1 ii php 2:7.4+76 ii php-fpm 2:7.4+76 ii php-imap2:7.4+76 ii php-mbstring2:7.4+76 ii php-mysql 2:7.4+76 ii php7.4 [php]7.4.15-5+deb11u1 ii php7.4-cgi [php-cgi]7.4.15-5+deb11u1 ii php7.4-fpm [php-fpm]7.4.15-5+deb11u1 ii php7.4-imap [php-imap] 7.4.15-5+deb11u1 ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1 ii php7.4-mysql [php-mysqlnd] 7.4.15-5+deb11u1 ii wwwconfig-common0.3.0+nmu1 Versions of packages postfixadmin recommends: ii dovecot-core1:2.3.13+dfsg1-1 ii mariadb-server 1:10.5.9-1 ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.9-1 ii php-cli 2:7.4+76 ii php7.4-cli [php-cli]7.4.15-5+deb11u1 ii postfix-mysql 3.5.6-1 pn zendframework postfixadmin suggests no packages. -- debconf information excluded
Bug#987121: wordpress: lighttpd not satisfying httpd dependency for installation
Package: wordpress Version: 5.6.1+dfsg1-1 Severity: normal Dear Maintainer, Wordpress depends, among other things on apache2 or httpd. The httpd package is, of course, a virtual one that is provided by twelve other packages, including apache2 and lighttpd. This is supposed to mean that any package in the httpd list will satisfy the dependency, and only if no package from that list is installed on the system will apache2 be installed with it. Unfortunately, lighttpd is not satisfying the dependency. Even when lighttpd is installed on the system, apt will try and install apache2 along with wordpress. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wordpress depends on: ii ca-certificates 20210119 pn libapache2-mod-php | php pn libjs-cropper ii libjs-underscore1.9.1~dfsg-3 ii lighttpd [httpd]1.4.59-1 ii mariadb-client-10.5 [virtual-mysql-client] 1:10.5.9-1 ii php-gd 2:7.4+76 pn php-getid3 ii php-mysql 2:7.4+76 ii php7.4-gd [php-gd] 7.4.15-5+deb11u1 ii php7.4-mysql [php-mysqlnd] 7.4.15-5+deb11u1 Versions of packages wordpress recommends: pn wordpress-l10n pn wordpress-theme-twentytwentyone Versions of packages wordpress suggests: ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.9-1 pn php-ssh2
Bug#987061: Further information
Further digging shows this error to be caused by phpMyAdmin's default connection collation being set to "utfmb4_unicode_ci". Every new user that logs in to phpMyAdmin will have its connection collation set to "utfmb4_unicode_ci" by default. Unfortunately, that collation is incompatible with Debian's MariaDB server default collation of "utfmb4_general_ci". You cannot mix unicode and general collations in queries and views. To correct this problem this package's default connection collation needs to be set to "utfmb4_general_ci", or the Debian's Maria DB server package's default server collation needs to be changed to the more appropriate "utfmb4_unicode_ci".
Bug#987061: phpmyadmin: Error "Illegal mix of collations" when clicking on Priviliges tab after default installation
Package: phpmyadmin
Version: 4:5.0.4+dfsg2-2
Severity: important
Tags: l10n
Dear Maintainer,
A rather important component of phpmyadmin is the ability to change and set
privileges on tables and columns.
This feature if brokon on a current default install of phpmyadmin when used
with a default install of MariaDB
on Debian 11/Testing.
Clicking on the "privileges" tab reders the following error:
#1267 - Illegal mix of collations (utf8mb4_general_ci,COERCIBLE) and
(utf8mb4_unicode_ci,COERCIBLE) for operation '<>'
The database installation is completely default. No changes have been made to
default collations after the installation
of mariadb-server.
Reproduction involves installing, logging in, and clicking. Namely from a
vanilla Debian 11 (testing) environment...
- Install and configure your web server of choice with tls (lighttpd in my
case)
- Install mariadb-server and phpmyadmin with all required dependencies
- Work around the current phpmyadmin bugs with respect to php-cgi-cfm if using
lighttpd
(Bugs #979380 and #979421)
- Add a mariadb login user to use with phpmyadmin
- Log in to phpmyadmin, click on any database and then the "privileges" tab.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages phpmyadmin depends on:
ii dbconfig-common 2.0.19
ii dbconfig-mysql2.0.19
ii debconf [debconf-2.0] 1.5.75
ii libjs-bootstrap4 4.5.2+dfsg1-6
ii libjs-codemirror 5.59.2+~cs0.23.109-1
ii libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii libjs-jquery-mousewheel 1:3.1.13-2
ii libjs-jquery-timepicker 1.6.3-1
ii libjs-jquery-ui 1.12.1+dfsg-8
ii libjs-openlayers 2.13.1+ds2-8
ii libjs-sphinxdoc 3.4.3-2
ii php-cli 2:7.4+76
ii php-common2:76
ii php-google-recaptcha 1.2.4-3
ii php-mariadb-mysql-kbs 1.2.12-1
ii php-mbstring 2:7.4+76
ii php-mysql 2:7.4+76
ii php-phpmyadmin-motranslator 5.2.0-1
ii php-phpmyadmin-shapefile 2.1-5
ii php-phpmyadmin-sql-parser 5.4.1-1
ii php-phpseclib 2.0.30-1
ii php-symfony-config4.4.19+dfsg-1
ii php-symfony-dependency-injection 4.4.19+dfsg-1
ii php-symfony-expression-language 4.4.19+dfsg-1
ii php-symfony-yaml 4.4.19+dfsg-1
ii php-twig 2.14.3-1
ii php-twig-i18n-extension 3.0.0-2
ii php-xml 2:7.4+76
ii php7.4-cli [php-cli] 7.4.15-5+deb11u1
ii php7.4-json [php-json]7.4.15-5+deb11u1
ii php7.4-mbstring [php-mbstring]7.4.15-5+deb11u1
ii php7.4-xml [php-xml] 7.4.15-5+deb11u1
ii sensible-utils0.0.14
ii ucf 3.0043
Versions of packages phpmyadmin recommends:
ii lighttpd [httpd]1.4.59-1
ii php-bz2 2:7.4+76
ii php-curl2:7.4+76
ii php-gd 2:7.4+76
ii php-tcpdf 6.3.5+dfsg1-1
ii php-zip 2:7.4+76
ii php7.4-bz2 [php-bz2]7.4.15-5+deb11u1
ii php7.4-curl [php-curl] 7.4.15-5+deb11u1
ii php7.4-gd [php-gd] 7.4.15-5+deb11u1
ii php7.4-zip [php-zip]7.4.15-5+deb11u1
Versions of packages phpmyadmin suggests:
ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.9-1
pn php-gd2
pn php-pragmarx-google2fa-qrcode
pn php-recode
pn php-samyoul-u2f-php-server
ii php7.4-opcache [php-opcache]7.4.15-5+deb11u1
pn www-browser
-- Configuration Files:
/etc/phpmyadmin/lighttpd.conf changed:
alias.url += (
"/phpmyadmin" => "/usr/share/phpmyadmin",
)
$HTTP["url"] =~ "^/phpmyadmin/" {
$HTTP["remoteip"] !~ "^(127.0.0.1)$" {
url.redirect-code=404
url.redirect = ( ".*" => "http://va1der.ca; )
#url.access-deny = ( "" )
}
}
-- debconf information:
phpmyadmin/remote/host: localhost
* phpmyadmin/reconfigure-webserver: lighttpd
phpmyadmin/db/dbname: phpmyadmin
* phpmyadmin/dbconfig-install: true
phpmyadmin/internal/reconfiguring: false
phpmyadmin/remove-error: abort
phpmyadmin/upgrade-backup: true
phpmyadmin/install-error: abort
phpmyadmin/upgrade-error: abort
phpmyadmin/missing-db-package-error: abort
phpmyadmin/remote/newhost:
phpmyadmin/dbconfig-upgrade: true
*
Bug#979421: Suggest higher priority than "normal"
While the workaround for this bug is fairly straightforward (apt-get install php-fpm), this doesn't negate the fact that this bug makes "apt-get install mysqladmin" cause lighttpd to fail and refuse to start up. It also caused the initial install to fail and left the package in a partially installed state. When installing one package causes another, a major subsystem at that, to fail, I would recommend the severity be at least "serious".
Bug#905674: parallel citation-begging issue
Hi Rogerio, I am writing in support of the recent patch to remove the citation message from Debian's version of GNU Parallel. This citation solicitation is actually quite troubling from an academic perspective, not just from a licensing standpoint. The assertion of Mr. Tange, the upstream author, that "[a]cademic tradition requires you to cite works you base your article on" is true, however the active words here are "works" and "base". In this case, when writing an article, the nature of the "work" I would base my article on would be another article. An academic article (in general) is not inherently based on the work of the programmer who wrote some of the software infrastructure used to create or analyze the data. Mr. Tange's assertion that mere use of GNU Parallel constitutes a moral obligation to cite an entry-level self-help tutorial on how to use that software is an egregious mischaracterization of the academic tradition Mr. Tange relies on. Especially, in this case, where the software in question has nothing to do with data analysis or production, but is a middleware parallelization job scheduler. If the article in question is itself on middleware parallelization job schedulers, that's one thing. In virtually every other case the notice is just fishing for something that is highly inappropriate. The correct way of mentioning the software involved is in a footnote, or perhaps in an appendix, when describing how to replicate the results and analysis. You include scripts involved, and the "evidence chain" of the data in such a way. This is problematic for Mr. Tange, however, because footnotes are not tracked. Citations are. Which is clearly why he is fishing for them. Now, the above isn't Debian's problem. This is academia's problem. What is Debian's problem is what will happen if Mr. Tange convinces Debian leadership that the citation-begging notice has to be allowed back in. Because this will open the flood gates to everyone who wants the prestige of being cited in an academic journal. All you have to do is have a minor article on a piece software, it doesn't have to be an academic article - just a how to use it will do, published literally anywhere that is citable, for any software in the processing-chain commonly used in academia. Use a shell script, be prepared to have the Bash authors start putting in citation-begging notices. Arguably those that wrote the actual Linux task schedulers and SMP code are just as worthy of notice as the authors of GNU Parallel. Or GCC, or PERL, or Python. Or how about grep? If this citation-begging notice gets back in to Debian, it will become a far larger issue than just whether or not Mr. Tange is skating on the right side of the GPL/DFSG legalities. Debian is going to have to ask the question on whether advertising in a STDERR message is appropriate at all. I would ask you, if and when this comes up for review with the leadership at Debian, to bring up these issues. It is my hope that Debian will see that it is in their best interest to look at a policy that will exclude this kind of behaviour, before it spreads. Thank-you Regards, Kurt Fitzner
Bug#785333: broken contextmenu due to jquery
On 03/06/2015 2:36 AM, Vincent Bernat wrote: Unfortunately, Debian has a strong policy against embedding dependencies. Therefore, we cannot embed jquery and we cannot embed tinymce. Obviously it's not as strong as one might think, since Wordpress manages to embed tinymce in its packages. As for jquery, we must also be able to build it from the sources. We cannot just ship the minified version. And building jQuery from sources within Debian is hard due to the needed dependencies, which seems the reason that the version in Debian is old. Waitaminnit... what do you mean build??? jquery.min.js, the file in question, is JavaScript. One simply includes the javascript source in RoundCube, as it is provided. It's not an applet. There is no building, there are no sources or binaries. It is just plain JavaScript. It's a text file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785333: broken contextmenu due to jquery
On 03/06/2015 9:20 PM, Holger Levsen wrote: minified javascript is (clearly) not the prefered form of modification, Wow. Just wow. Un-pretty-printing a script makes it a binary. That's a whole new level of, I'll call it dedication, to the letter of the law. I applaud the committee that came up with that little gem. Full stop. cheers, Holger Ok, roger out, deep breath, I'm mostly calm now. So this bug is lingering because of how difficult a build process the minification of javascript is? Honestly? I'm being punked, right? Ok, well, here are a few solutions: 1) Ship the unminified source (I can't believe I'm catering to this minified javascript isn't source madness... calm calm) in a source package. 2) Don't minify jquery for RoundCube. It's client-side JavaScript, so it doesn't give a performance hit for the server. The performance hit scales across every client. It's like crowd-sourcing the solution to Debian's madness. perspectiveThe extra few timer ticks of computing time that running the unminified script will cost every computer that will ever run it put together will be less than the computing time already consumed by us talking about it./perspective 3) Do both. Except without the source package. Simply ship the actual unminified version right alongside the minified version in RC's packages. You can even make it an install-time decision whether to soft link in the minified or unminified version. Not even Stallman's Beard Trolls could find fault with this approach. The problem that lead me to this bug was with a RoundCube plugin. When I figured out it was a jquery issue due to the linked in system version having replaced the shipped version, the response from the author was oh ya Debian. How about we just the the right thing™ and fix the issue by shipping RoundCube the way its authors of it intended. And by that I mean functional. The last step (and I pray to Ian, Debby, Turing and the Great Stallman's Beard together that everyone who reads this bug report in perpetuity does this) is to send a total nastygram to the non-ovo-lacto-GPL-vegans who are coming up with rules that have long left out of touch in the rearview mirror. This level of anal retentitude does nobody any good. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785333: broken contextmenu due to jquery
The old jquery linked to in RoundCube also breaks plugins like contextmenu. The better fix for Debian's RoundCube is not to update the jquery package to its new upstream, but to include with RoundCube the appropriate version of jquery supplied from its own upstream. jquery, like tinymce, is simply not appropriate as a shared resource. Web applications of various ages depend on mutually incompatible versions. Far too much thought is being put into a very simple problem. Namely that too many of the included files from the upstream RoundCube distribution are being removed from the distribution in favour of inappropriately trying to link against a common system version. There is no advantage to the current approach and it is keeping Debian's RoundCube packages broken for far too long. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784351: Recommend removing dependency on tinymce package
I would highly recommend that the dependency on the Debian tinymce package be removed and that roundcube simply ship with the version of tinymce that it was designed for. Trying to turn tinymce into a shared library was ill advised to begin with. This is now the only Roundcube package available to Jessie without reaching back to Wheezy backports, and this bug is a show stopper. It could be fixed today, in about fifteen seconds, by repackaging with the upstream tinymce as it should have been. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786427: wordpress: setup-mysql.gz references missing TODO.Debian file
Package: wordpress Version: 4.2.1+dfsg-1 Severity: minor Dear Maintainer, The setup script /usr/share/doc/wordpress/examples/setup-mysql.gz says at the bottom of the usage: BUGS: See ../TODO.Debian There is no TODO.Debian. The way it's written infers that for Debian there are extra configuration steps or gotchas that are itemized somewhere else. While I suspect this is just a cosmetic issue, it doesn't give warm fuzzies. Is this intended to read See ../README.Debian ? -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (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 Init: systemd (via /run/systemd/system) Versions of packages wordpress depends on: ii ca-certificates 20141019 ii libjs-cropper1.2.2-1 ii libjs-mediaelement 2.15.1+dfsg-1 ii libphp-phpmailer 5.2.9+dfsg-2 ii lighttpd [httpd] 1.4.35-4 ii mysql-client 5.5.43-0+deb8u1 ii mysql-client-5.5 [mysql-client] 5.5.43-0+deb8u1 ii php-getid3 1.9.8-3 ii php5 5.6.7+dfsg-1 ii php5-gd 5.6.7+dfsg-1 ii php5-mysql 5.6.7+dfsg-1 ii wordpress-theme-twentyfifteen4.1+dfsg-1+deb8u1 Versions of packages wordpress recommends: ii wordpress-l10n 4.2.1+dfsg-1 Versions of packages wordpress suggests: ii mysql-server 5.5.43-0+deb8u1 pn php5-ssh2 none -- 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#784355: postfixadmin: Installing postfixadmin on lighttpd system fails to create lighttpd config file
Package: postfixadmin Version: 2.3.7-1 Severity: important Dear Maintainer, Installing postfixadmin on Debian Jessie with lighttpd previously installed fails to create a lighttpd configuration file in /etc/postfixadmin, or the symlink to it in /etc/lighttpd/conf-available. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (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 Init: unable to detect Versions of packages postfixadmin depends on: ii dbconfig-common 1.8.47+nmu3 ii debconf 1.5.56 ii lighttpd [httpd] 1.4.35-4 ii mysql-client 5.5.43-0+deb8u1 ii mysql-client-5.5 [mysql-client] 5.5.43-0+deb8u1 ii php5 5.6.7+dfsg-1 ii php5-imap5.6.7+dfsg-1 ii php5-mysql 5.6.7+dfsg-1 ii wwwconfig-common 0.2.2 Versions of packages postfixadmin recommends: ii dovecot-core 1:2.2.13-11 ii mysql-server 5.5.43-0+deb8u1 ii postfix-mysql 2.11.3-1 ii zendframework 1.12.9+dfsg-2 postfixadmin suggests no packages. -- debconf information: postfixadmin/dbconfig-reinstall: false postfixadmin/pgsql/changeconf: false postfixadmin/database-type: postfixadmin/pgsql/authmethod-user: postfixadmin/mysql/admin-user: root postfixadmin/dbconfig-upgrade: true postfixadmin/internal/skip-preseed: true postfixadmin/pgsql/manualconf: postfixadmin/remote/port: postfixadmin/remote/newhost: postfixadmin/upgrade-backup: true postfixadmin/pgsql/method: unix socket postfixadmin/remove-error: abort postfixadmin/pgsql/authmethod-admin: ident * postfixadmin/dbconfig-install: false postfixadmin/internal/reconfiguring: false postfixadmin/pgsql/admin-user: postgres postfixadmin/mysql/method: unix socket postfixadmin/upgrade-error: abort postfixadmin/db/app-user: postfixadmin/db/basepath: postfixadmin/pgsql/no-empty-passwords: postfixadmin/db/dbname: postfixadmin/install-error: abort postfixadmin/remote/host: postfixadmin/missing-db-package-error: abort postfixadmin/purge: false postfixadmin/dbconfig-remove: postfixadmin/passwords-do-not-match: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508045: Problems with Etch-Lenny upgrade
Sorry to take so long to get back to you. Kyle McMartin wrote: What was the starting kernel version? The latest stable etch kernel? Yes. I performed a dist-upgrade while it was still on etch before I altered sources.list to lenny. I suspect the fault for this lies in glibc trickery, though I'm not sure off-hand. I don't recall any changes in the kernel to these syscalls in the gap of versions between etch and lenny. I did some searches when I was in the middle of trying to get the upgrade to work. Other people who have experienced the problem with df were advised to check their /proc. Everything relevant to df in my /proc seemed to be ok, so I wondered if maybe coreutils switched from parsing files in /proc to syscalls in the upgrade? That's just a shot in the dark, though. Kurt. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508045: coreutils: df stops working during etch-lenny upgrade causing upgrade failure
Package: coreutils Version: 6.10-6 Severity: important During an etch-lenny upgrade, between the time that coreutils is upgraded and the kernel is upgraded and booted, 'df' fails to operate. This causes all installations that depend on a working df to fail (mysql is one). The whole upgrade process aborts at that point leaving the system in a partially upgraded state. The output of df during the failure period is: df: /': Function not implemented df: /lib/init/rw': Function not implemented df: /sys': Function not implemented df: /dev': Function not implemented df: /dev/shm': Function not implemented df: /dev/pts': Function not implemented df: /boot': Function not implemented df: /proc/fs/nfsd': Function not implemented df: /var/lib/nfs/rpc_pipefs': Function not implemented df: no file systems processed To jump-start the upgrade, I was forced to write a simple script that simply echo'ed out a faked df output. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: hppa (parisc) Kernel: Linux 2.6.26-1-parisc Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl1 2.2.47-2 Access control list shared library ii libc6 2.7-16 GNU C Library: Shared libraries ii libselinux1 2.0.65-5 SELinux shared libraries coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401439: linux-image-2.6.17-2-parisc: XFS module will not load
2.6.18 (as packaged in linux-image-2.6.18-3-parisc_2.6.18-6_hppa.deb) has the same problem on my machine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390465: reportbug: This occurs when xterm mouse reporting enabled
Package: reportbug Version: 3.31 Followup-For: Bug #390465 The pasting crash only seems to happen when xterm mouse reporting is enabled on the terminal used to interface with reportbug. If mouse reporting is turned off, pasting will of course work as it only involves inserting normal text characters into the keyboard queue for the terminal. This seems to indicate that urwid interface needs to simply turn off its reporting that it is mouse aware. -- Package-specific info: ** Environment settings: INTERFACE=urwid ** /home/kfitzner/.reportbugrc: reportbug_version 3.31 mode standard ui urwid -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: hppa (parisc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-parisc Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages reportbug depends on: ii python2.4.3-11 An interactive high-level object-o ii python-central0.5.12 register and build utility for Pyt Versions of packages reportbug recommends: pn python-cjkcodecs | python-ico none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401439: linux-image-2.6.17-2-parisc: XFS module will not load
Package: linux-image-2.6.17-2-parisc Version: 2.6.17-9 Severity: critical Justification: breaks the whole system The following error is returned when attemtping to load the xfs module: FATAL: Error inserting xfs (/lib/modules/2.6.17-2-parisc/kernel/fs/xfs/xfs.ko): Invalid module format dmesg reveals this: module xfs relocation of symbol xfs_iext_destroy is out of range (0x3ffeffeb in 17 bits) This error occured on a PARISC HP 9000 C160 workstation. It is unknown whether it occurs on other PARISC systems. This makes selecing xfs during install impossible. It will, of course, render an existing system unbootable if it uses xfs and upgrades to this kernel. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: hppa (parisc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-parisc Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.17-2-parisc depends on: ii initramfs-tools [linux-initra 0.85b tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo linux-image-2.6.17-2-parisc recommends no packages. -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.17-2-parisc/preinst/failed-to-move-modules-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/preinst/initrd-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/postinst/bootloader-error-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/preinst/elilo-initrd-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/preinst/abort-install-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/postinst/create-kimage-link-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/postinst/old-initrd-link-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/prerm/would-invalidate-boot-loader-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/preinst/bootloader-initrd-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/preinst/already-running-this-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/postinst/old-system-map-link-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/postinst/kimage-is-a-directory: linux-image-2.6.17-2-parisc/prerm/removing-running-kernel-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/preinst/overwriting-modules-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/postinst/depmod-error-initrd-2.6.17-2-parisc: false linux-image-2.6.17-2-parisc/preinst/lilo-has-ramdisk: linux-image-2.6.17-2-parisc/preinst/abort-overwrite-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/postinst/depmod-error-2.6.17-2-parisc: false linux-image-2.6.17-2-parisc/postinst/bootloader-test-error-2.6.17-2-parisc: linux-image-2.6.17-2-parisc/postinst/old-dir-initrd-link-2.6.17-2-parisc: true linux-image-2.6.17-2-parisc/preinst/lilo-initrd-2.6.17-2-parisc: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401229: installation-reports
Package: installation-reports Boot method: CD Image version: Debian ETCH daily built @ http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/hppa/iso-cd/debian-testing-hppa-netinst.iso Date: 30 Nov 2006, 10pm MST (1 Dec 2006, 5am GMT) Machine: HP Visualize 9000 C160 workstation Processor: PA-8000 Memory: 640MB Partitions: Device Start End Blocks Id System /dev/sda1 1 4 32098+ f0 Linux/PA-RISC boot /dev/sda2 5 12 64260 83 Linux /dev/sda3 13 43 249007+ 82 Linux swap / Solaris /dev/sda4 44 522 3847567+ 83 Linux Output of lspci -nn and lspci -vnn: no PCI devices Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: A necessary device driver for my system (zalon7xx) was on the install CD, but not included in the supplied kernel. Thus, my system was unable to boot after the install. I have tried RC1 and yesterday's daily build. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
