Bug#728840: munin-plugins-extra: ipmi_sensor_ doesn't properly "import os"
Package: munin-plugins-extra Version: 2.0.6-4+deb7u1 Severity: normal with version 2.0.6-4 of munin-plugins-extra, I get the following stack trace when running the ipmi_sensor_ script: munin-run ipmi_sensor_u_degrees_c Traceback (most recent call last): File "/etc/munin/plugins/ipmi_sensor_u_degrees_c", line 73, in CACHEDIR = os.environ['MUNIN_PLUGSTATE'] NameError: name 'os' is not defined it would seem the script imports different things for the os library with "from os import xyz" but does not import the library directly. so near the beginning when it tries to get a variable from then environment, if crashes. simple fix would be to add a line "import os" before line 73 like this: - >8 - --- /usr/share/munin/plugins/ipmi_sensor_ 2013-06-09 11:41:52.0 -0400 +++ ipmi_sensor_2013-11-06 00:04:15.689850272 -0500 @@ -63,6 +63,7 @@ from subprocess import Popen, PIPE +import os from os import stat, access, R_OK, F_OK from os.path import join from stat import ST_MTIME -- 8< -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages munin-plugins-extra depends on: ii munin-common 2.0.6-4+deb7u1 ii perl 5.14.2-21+deb7u1 munin-plugins-extra recommends no packages. Versions of packages munin-plugins-extra suggests: pn libnet-netmask-perl pn libnet-telnet-perl ii python 2.7.3-4+deb7u1 -- 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#728840: munin-plugins-extra: ipmi_sensor_ doesn't properly "import os"
On 06/11/13 03:06 PM, Steve Schnepp wrote: > tags 728840 + upstream fixed-upstream > done thanks for the quick response! > On Wed, Nov 6, 2013 at 6:06 AM, Gabriel Filion wrote: >> simple fix would be to add a line "import os" before line 73 like this: > > Thx. > > Note that I just fixed [1] the offending call instead in > e9e9f6b63c08d6e8c98ed8d518fdfab5320c. > > [1] http://mm0.eu/e9e9f6 that's quite okay to fix it that way. however, please note that "environ" was not imported from os before, so I would expect this to fail as well: 66 from os import stat, access, R_OK, F_OK 67 from os.path import join 68 from stat import ST_MTIME 69 from time import time 70 import sys 71 import re 72 73 CACHEDIR = environ['MUNIN_PLUGSTATE'] -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#708865: spamassassin reload gives error msg about no Perl found
Hey there, I'm seeing this error too with package 3.3.2-5 in wheezy 7.2 also, since the daily cronjob in /etc/cron.daily/spamassassin calls "invoke-rc.d spamassassin reload", I get an error message every night about the reload returning an error code. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#658896: Still an issue
Hi there, I just stumbled upon this bug as well. We're +/- one year after the wheezy release and this is still an issue. It seems as though one patch was able to fix the problem, and even though we're considering a change of librairies for jessie, it would be really helpful to fix this in wheezy. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#741969: postfixadmin: please package version 2.3.7
Package: postfixadmin Version: 2.3.5-2 Severity: normal Hi there, version 2.3.7 was released on 2014-02-20 according to the project download page[1]. [1]: http://sourceforge.net/projects/postfixadmin/files/postfixadmin/ version 2.3.5 is now two years old. while there haven't been all that much changes upstream in two years, there were some fixes, among which there is a security fix in 2.3.7. thanks for maintaining this package! -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-042stab084.14 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages postfixadmin depends on: ii apache2-mpm-prefork [httpd] 2.2.22-13+deb7u1 ii dbconfig-common 1.8.47+nmu1 ii debconf 1.5.49 ii libapache2-mod-php5 5.4.4-14+deb7u8 ii mysql-client 5.5.35+dfsg-0+wheezy1 ii mysql-client-5.5 [mysql-client] 5.5.35+dfsg-0+wheezy1 ii nginx-full [httpd] 1.2.1-2.2+wheezy2 ii php5 5.4.4-14+deb7u8 ii php5-cgi 5.4.4-14+deb7u8 ii php5-imap5.4.4-14+deb7u8 ii php5-mysql 5.4.4-14+deb7u8 ii wwwconfig-common 0.2.2 Versions of packages postfixadmin recommends: ii mysql-server 5.5.35+dfsg-0+wheezy1 ii postfix-mysql 2.9.6-2 Versions of packages postfixadmin suggests: ii dovecot-core [dovecot-common] 1:2.1.7-7 -- debconf information: postfixadmin/remote/newhost: postfixadmin/pgsql/method: unix socket postfixadmin/db/app-user: postfixadmin postfixadmin/purge: false * postfixadmin/reconfigure-webserver: postfixadmin/remote/port: postfixadmin/pgsql/changeconf: false * postfixadmin/dbconfig-install: true * postfixadmin/database-type: mysql postfixadmin/internal/reconfiguring: false postfixadmin/remote/host: postfixadmin/upgrade-error: abort postfixadmin/missing-db-package-error: abort postfixadmin/upgrade-backup: true postfixadmin/pgsql/authmethod-user: postfixadmin/mysql/admin-user: root postfixadmin/dbconfig-remove: postfixadmin/remove-error: abort postfixadmin/db/basepath: postfixadmin/passwords-do-not-match: postfixadmin/db/dbname: postfixadmin postfixadmin/install-error: abort postfixadmin/pgsql/no-empty-passwords: postfixadmin/dbconfig-reinstall: false postfixadmin/internal/skip-preseed: false postfixadmin/pgsql/admin-user: postgres postfixadmin/pgsql/authmethod-admin: ident postfixadmin/dbconfig-upgrade: true postfixadmin/mysql/method: unix socket postfixadmin/pgsql/manualconf: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643691: not reproducible on latest sid version
tried to reproduce in wheezy, so same package version as sid. In order for apache to start without a "Syntax error" about a missing symbol for a library, I had to keep the package's default /etc/apache2/mods-available/proxy_html.load file. After change, apache restart doesn't segfault and doesn't eat the cpu. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665487: dovecot-managesieved: Error upgrading dovecot with managesieved
This bug concerns a somewhat old version (current version in both squeeze-backports and wheezy is 1:2.1.7-2). Also, the package dovecot-managesieved doesn't exist in the squeeze archive. So I can't install the same version as in the original report. Finally, the provided patch does not apply to the current dovecot-managesieved.postrm file, so I marked it as unreproducible. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665487: dovecot-managesieved: Error upgrading dovecot with managesieved
On 2012-09-30 00:46, Jaldhar H. Vyas wrote: > On Sun, 30 Sep 2012, Gabriel Filion wrote: > >> This bug concerns a somewhat old version (current version in both >> squeeze-backports and wheezy is 1:2.1.7-2). >> >> Also, the package dovecot-managesieved doesn't exist in the squeeze >> archive. So I can't install the same version as in the original report. >> >> Finally, the provided patch does not apply to the current >> dovecot-managesieved.postrm file, so I marked it as unreproducible. >> > > Thanks for looking into this. However the bug reporter was right about > the underlying problem which is that dovecot restarts prematurely. This > is still a concern in the current version. So in 1:2.1.7-3 which I am > about to release soon, I aim to solve that problem with dpkg triggers. great! :) if you need help in testing the new package, I can try and upgrade to it to confirm that the problem was solved. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476544: Bug#475302: vz starts to early in boot process
Hello, This is still visible in squeeze and wheezy. I'm using Xen and drbd always gets loaded after xendomains is started. I'm very not sure if it's a good idea, but maybe it would be good to add drbd to the $remote_fs definition in /etc/insserv.conf so that services that depend on this (like xendomains) can use DRBD devices. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659331: nagios3: service restart should fail when there is a configuration error
Package: nagios3 Version: 3.2.1-2 Severity: normal The current behaviour of the init script is to quietly succeed a service restart when there is a configuration error, but without restarting the service. While this prevents the service from randomly stopping, it doesn't tell users that there is actually a problem. The init script should prevent nagios from being restarted when there is a config error (as it is now), but it should output the error and exit with an error status. One use case for this: when restarting the service through Puppet, it believes the service restart was successful, even though nothing really happened and there was an error in the configuration. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-xen-686 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages nagios3 depends on: ii nagios3-cgi 3.2.1-2cgi files for nagios3 ii nagios3-core 3.2.1-2A host/service/network monitoring nagios3 recommends no packages. Versions of packages nagios3 suggests: ii nagios-nrpe-plugin2.12-4 Nagios Remote Plugin Executor Plug -- 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#580294: [Pkg-nagios-devel] Bug#580294: nagios3: fails to install when partial (bad) configuration exists
I must say I disagree with Tollef's point of view. A broken configuration shouldn't prevent a package from installing.. sure, it will prevent the service from starting up, but that will most certainly be made visible at least with errors in log files. So I don't see the point of having a configuration error preventing installation completion. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#639941: Xen "line 118: sigerr: command not found" error for unassigned network interfaces
I'm also seeing this error in a very similar setup $ cat /etc/xen/scripts/network-dualbridge #!/bin/sh dir=$(dirname "$0") $dir/network-bridge "$@" vifnum=0 netdev=eth0 bridge=xenbr0 $dir/network-bridge "$@" vifnum=1 netdev=eth1 bridge=xenbr1 but in my case, each interface that is setup with a bridge already has an IP assigned to it via /etc/network/interfaces but regardless of the error, the networking setup actually works. it's just annoying to have to wait so long for the command to complete during the boot process. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614320: [debian-mysql] Bug#614320: Error when installing
I'm seeing the exact same behaviour in a brand new Xen domU installed with xen-create-image. I installed mysql with 'apt-get install mysql-server' I tried purging mysql-server* and wiping out database files with "rm -rf /var/lib/mysql", but the install after that didn't do much better. syslog shows exactly the same contents as was reported by Flavio. so, there's something about a syntax error before 'ALTER TABLE ...', then IP bind problems, and then an error about a "plugin" table already existing, and then 'mysqladmin ... ping' fails. ii libdbd-mysql-perl 4.016-1 Perl5 database interface to the MySQL database ii libmysqlclient16 5.1.49-3 MySQL database client library ii mysql-client 5.1.49-3 MySQL database client (metapackage depending on the latest version) ii mysql-client-5.1 5.1.49-3 MySQL database client binaries ii mysql-common 5.1.49-3 MySQL database common files, e.g. /etc/mysql/my.cnf iU mysql-server 5.1.49-3 MySQL database server (metapackage depending on the latest version) iF mysql-server-5.1 5.1.49-3 MySQL database server binaries and system database setup ii mysql-server-core-5.1 5.1.49-3 MySQL database server binaries -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614320: Info received ([debian-mysql] Bug#614320: Error when installing)
I got the install to complete! I shutdown the domU, started it again, and SSH'ed in. Now 'apt-get -f install' did complete successfully (it didn't before rebooting). Now that's a weird problem resolution.. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659331: nagios3: service restart should fail when there is a configuration error
I just found out about bug report #680615 This looks like the root cause of this issue. I'll answer to that other issue, so you can close this one here. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680615: nagios3: init script confusion between 'check' and 'status'
oh, well this looks like the root cause of bug #659331 thanks to have found this, Stephan. I tried renaming the second function definition to check() and the script is now back to normal behaviour: root@nagios0:~# /etc/init.d/nagios3 check /etc/init.d/nagios3: 247: check: not found root@nagios0:~# sed -i '209s/status/check/' /etc/init.d/nagios3 root@nagios0:~# /etc/init.d/nagios3 status checking /usr/sbin/nagios3...done (running). root@nagios0:~# /etc/init.d/nagios3 check [... nagios -v output] -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695617: iotop crashes when locale not found on system
Package: iotop
Version: 0.4-2+squeeze1
Severity: normal
When invoked on a server that does not share my locale settings, iotop
simply refuses to launch until I force the locale to something that exists
on the system.
Traceback (most recent call last):
File "/usr/bin/iotop", line 16, in
main()
File "/usr/lib/pymodules/python2.6/iotop/ui.py", line 506, in main
locale.setlocale(locale.LC_ALL, '')
File "/usr/lib/python2.6/locale.py", line 513, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
letting the application crash because of unknown locale should not be a good
default.
instead it should default to C
I believe this behaviour is related to python's locale module's behaviour,
and the locale.Error exception should be catched when calling _setlocale so that
iotop can default to the "C" locale when it is not able to set the correct one.
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages iotop depends on:
ii python [python-ctypes] 2.6.6-3+squeeze7 interactive high-level object-orie
ii python-support 1.0.10 automated rebuilding support for P
iotop recommends no packages.
iotop suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "en_US.utf8",
LC_TIME = "fr_CA.UTF-8",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706115: lighttpd bind to port 80 even though it's configured not to
Package: lighttpd Version: 1.4.28-2+squeeze1.3 Severity: important lighttpd on my setup is currently not configured to bind on port 80, but still does it. as a result, if something else started before it that has already bound to port 80, lighttpd simply refuses to start. in my case, I have varnish listening on port 80 and lighttpd on 8080 for serving a fallback html page when web nodes are down. if I start varnish before lighttpd, then lighttpd won't start. starting lighttpd, and then varnish will get things working. lighttpd is still bound to port 80 on IPv6 even though it's not supposed to do it: tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 31368/varnishd tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN 31338/lighttpd tcp6 0 0 :::80 :::* LISTEN 31338/lighttpd I've found that this is due to the following line, which is included in the default configuration file: include_shell "/usr/share/lighttpd/use-ipv6.pl" since it prevents lighttpd to co-exist with any other application that binds to port 80 on a semi-random fashion (because of non-deterministic order caused by parallelized boot process), I consider this default configuration to be an important problem. -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages lighttpd depends on: ii libattr1 1:2.4.44-2Extended attribute shared library ii libbz2-1.0 1.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libfam02.7.0-17 Client library to control the FAM ii libldap-2.4-2 2.4.23-7.3OpenLDAP libraries ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expressi ii libssl0.9.80.9.8o-4squeeze14 SSL shared libraries ii libterm-readline-perl- 1.0303-1 Perl implementation of Readline li ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mime-support 3.48-1MIME files 'mime.types' & 'mailcap ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages lighttpd recommends: ii spawn-fcgi1.6.3-1A fastcgi process spawner Versions of packages lighttpd suggests: pn apache2-utils (no description available) ii openssl0.9.8o-4squeeze14 Secure Socket Layer (SSL) binary a pn rrdtool(no description available) -- Configuration Files: /etc/lighttpd/lighttpd.conf: server.modules = ( "mod_access", "mod_alias", "mod_compress", "mod_redirect", # "mod_rewrite", ) server.document-root= "/var/www" server.upload-dirs = ( "/var/cache/lighttpd/uploads" ) server.errorlog = "/var/log/lighttpd/error.log" server.pid-file = "/var/run/lighttpd.pid" server.username = "www-data" server.groupname= "www-data" index-file.names= ( "index.php", "index.html", "index.htm", "default.htm", " index.lighttpd.html" ) url.access-deny = ( "~", ".inc" ) static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" ) include_shell "/usr/share/lighttpd/use-ipv6.pl" dir-listing.encoding= "utf-8" server.dir-listing = "enable" compress.cache-dir = "/var/cache/lighttpd/compress/" compress.filetype = ( "application/x-javascript", "text/css", "text/html", "text/plain" ) include_shell "/usr/share/lighttpd/create-mime.assign.pl" include_shell "/usr/share/lighttpd/include-conf-enabled.pl" /etc/lighttpd/conf-enabled/port.conf: server.port = 8080 -- 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#701744: [xen] Update to hypervisor 4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes networking (VIF) failures
I'm seeing this on debian wheezy, too like Johnny Strom reported. # uname -a Linux minerve 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux # dpkg -l | grep hypervisor ii xen-hypervisor-4.1-amd644.1.4-3+deb7u1 amd64Xen Hypervisor on AMD64 The network is configured without "(network-script network-bridge)" in xend-config.sxp and in /etc/network/interfaces, we have no entry for eth0 and this (replaced the real values by stars): auto br0 iface br0 inet static address * netmask * broadcast * gateway * bridge_ports eth0 on the dom0, we can see this in kern.log: May 28 19:09:30 minerve kernel: [613987.529752] vif vif-11-0: vif11.0: Frag is bigger than frame. May 28 19:09:30 minerve kernel: [613987.539463] vif vif-11-0: vif11.0: fatal error; disabling device May 28 19:09:30 minerve kernel: [613987.550091] br0: port 2(vif11.0) entering forwarding state on the console for the VM, I could see this multiple times: [233721.357648] device eth0 left promiscuous mode [233721.424093] device eth0 entered promiscuous mode I don't have further access to this VM. On other VMs where this happened, I could see this in the logs: [2601471.852025] TCP: Peer 74.94.211.209:31059/80 unexpectedly shrunk window 4233113998:4233124218 (repaired) [2601479.916025] TCP: Peer 74.94.211.209:31059/80 unexpectedly shrunk window 4233113998:4233124218 (repaired) -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#724006: Impossible to send out the email via MTA with some ISPs
Package: monkeysign Version: 1.0-23-g3f4a626 (current master) Hey there, Some ISPs are destroying net neutrality and blocking port 25. This makes it impossible to use the local (and possibly remote) MTA for sending out monkeysign's email. To really solve the issue, we'd have to force ISPs to do their job correctly but that won't happen soon unfortunately :( A workaround could be to add an option in monkeysign to save the email to a file, or dump it to a file in a directory (subtility: specify a filename or a dirname as an argument). another means could be to make it possible to use port 587. or maybe just a documentation update to tell users how to use --no-mail and to pipe that into something that'd get the mail in the user's MUA. it gets complicated to document all the options, though. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#724007: gitignore misses some products of setup.py
Package: monkeysign Version: 1.0 current .gitignore file does not ignore the man and build directories. since these two are products from the build process with setup.py, they should be ignored. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#632797: Suppress information message about I/O scheduling class with -q
Hello, Just chipping in here for showing support for this issue: This has been discussed in bug #598957 which is now closed due to a package being pushed to testing/sid to fix this. It would be really nice to see this fix get in squeeze. -- Gabriel Filion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651704: puppet: hasstatus breaks dependency of named service resource
Package: puppet Version: 2.6.2-5+squeeze3 Severity: normal Using hasstatus with a service resource that "redefines" the name parameter makes puppet agent refuse to run with an error similar to: Could not find init script for 'nagios3' This issue has been taken care of by upstream and was merged in puppet 2.6.7. See the following URL for upstream bug report: http://projects.puppetlabs.com/issues/5610 Could we backport that patch to the 2.6.2 package? -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages puppet depends on: ii adduser 3.112+nmu2 add and remove users and groups ii facter 1.5.7-3 a library for retrieving facts fro pn libopenssl-ruby(no description available) ii libruby [libxmlrpc-r 4.5 Libraries necessary to run Ruby 1. ii libshadow-ruby1.81.4.1-8 Interface of shadow password for R ii lsb-base 3.2-23.2squeeze1Linux Standard Base 3.2 init scrip ii puppet-common2.6.2-5+squeeze3Centralized configuration manageme ii ruby1.8 1.8.7.302-2squeeze1 Interpreter of object-oriented scr Versions of packages puppet recommends: ii libaugeas-ruby1.8 0.3.0-1.1 Augeas bindings for the Ruby langu ii ruby [rdoc] 4.5An interpreter of object-oriented Versions of packages puppet suggests: pn libselinux-ruby1.8 (no description available) pn puppet-el (no description available) ii vim-puppet 2.6.2-5+squeeze3 syntax highlighting for puppet man -- 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#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
Hi all, intrigeri: > Gabriel Filion: >> but yeah I could disable the force (, luke) and see if I can reproduce >> the bug again with the newer package versions. > >> I'll see if I can do that on sunday > > Ping? sorry it took me so much time. I upgraded xserver-xorg-core to 2:1.19.3-1 (in sid) and removed the /etc/X11/xorg.conf file that was forcing xorg to load the intel driver. I then restarted the X display and was able to reproduce the visual flashes (or rather visible screen refresh) and hard crash followed by an automatic shutdown about 10s later. signature.asc Description: OpenPGP digital signature
Bug#857444: [debian-mysql] Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Lars Tangvald:
>
> - gabs...@lelutin.ca wrote:
>
>> Ugh, I fail at reportbug again :(
>>
>> real sorry about the initial report.
>>
>> here's the real description of the problem:
>>
>>
>> when upgrading from jessie to stretch, the upgrade goes through
>> without
>> an error but the end result is that mysql-server-5.5 gets removed and
>> mysql is not running anymore.
>>
>> stretch is supposed to push ppl towards mariadb according to the
>> (still
>> work in progress) release notes, however mariadb doesn't get
>> installed.
>>
>> There is no mysql-server, mysql-server-* or mysql-client-* packages
>> in
>> stretch so I believe this to be the source of the issue.
>>
>> One can fix the problem either by adding default-mysql-server before
>> upgrading or after. however this poses a problem:
>>
>> * before the upgrade, the default-mysql-server package is only
>> available in jessie-backports
>> * after the upgrade, you've gotten no notice at all about what's
>> happening and why the mysql server is not running and not upgraded.
>>
>> One way to make this an easier transition would be to have a
>> mysql-server package in stretch that's a dummy package that depends
>> on
>> default-mysql-server, and that has an upgrade notice about the
>> transition to mariadb that is happening.
>>
>>
> The mysql package names should be reserved for actual mysql packages
> (default-mysql, virtual-mysql etc. are named so because there isn't a better
> term for "mysql-ish"). While the current situation with mysql being
> half-uninstalled is pretty odd, we shouldn't automatically replace
> mysql-server with mariadb-server, as it can cause problems for users who want
> to keep using mysql, while those who are fine with either just need to
> install mariadb after the upgrade.
This sounds reasonable, but there are currently lots of mysql-* packages
missing from stretch.
I can currently only see mysql-common, mysql-sandbox, mysql-utilities,
mysql-workbench{,-data}, mysqltcl, mysqltuner.
there are neither packages for client nor server.
signature.asc
Description: OpenPGP digital signature
Bug#857444: [debian-mysql] Bug#857444: Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Otto Kekäläinen: >>> One way to make this an easier transition would be to have a >>> mysql-server package in stretch that's a dummy package that depends >>> on >>> default-mysql-server, and that has an upgrade notice about the >>> transition to mariadb that is happening. > > The transition is supposed to be automatic already. that would be awesome if it was. > Apparently it > didn't quite work in your setup. Can you please describe your setup in > details so that I can try to reproduce your upgrade and see how the > packages interact? What packages did you have installed in Jessie? > What repositories did you have enabled in Jessie? How did you upgrade, > what repositories where enabled during the upgrade when you ran > apt-get upgrade or apt-get dist-upgrade? How do you know if mysql was > or was not running after the upgrade, did you check with ps if you > have any mysqld processes at all? Was there some errors in syslog or > /var/log/mysql ? I was testing the upgrade in an almost vanilla jessie VM that I had created with vagrant. I installed "mysql-server", and then proceeded with the install. I didn't install "default-mysql-server" before the upgrade since I wasn't tracking jessie-backports. I was following this procedure (sorry it's a weird mixture of english and french but you can probably make out most of it by looking at what commands are there): https://wiki.koumbit.net/StretchUpgrade it's somewhat based on minimal downtime procedure here with added convoluted steps to keep from upgrading the puppet client since our master is not yet upgraded: http://www.debian.org/releases/stretch/amd64/release-notes/ch-upgrading.en.html#services-downtime so after both the upgrade and dist-upgrade, I tried connecting with the client and the server wasn't there. I unfortunately lost the package list that I sent in my first failed attempt at opening this bug. but I could reproduce and give you more info if you'd like. from what I can remember, only the mysql-server-5.5 package was marked as uninstalled. signature.asc Description: OpenPGP digital signature
Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
Hi there, bertagaz: > Uwe reported that with a newest release of xserver-xorg-core, the > bug disappeared. [1] > > There has been new uploads recently in Stretch and Sid, which now have > 2:1.19.2-1 and 2:1.19.3-1 respectively. > > Is one of this versions the one supposed to have "fixed" the bug? > > Could be helpfull if someone (lelutin?) gives a try back with the newest > modsetting driver so that we know if it eventually works. > > bert. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=98742#c14 > I've been using the intel driver by forcing it as was suggested to me some time ago and haven't had any crash since then. but yeah I could disable the force (, luke) and see if I can reproduce the bug again with the newer package versions. I'll see if I can do that on sunday signature.asc Description: OpenPGP digital signature
Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Package: mysql-server-5.5 Version: 5.5.54-0+deb8u1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** blah -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Ugh, I fail at reportbug again :( real sorry about the initial report. here's the real description of the problem: when upgrading from jessie to stretch, the upgrade goes through without an error but the end result is that mysql-server-5.5 gets removed and mysql is not running anymore. stretch is supposed to push ppl towards mariadb according to the (still work in progress) release notes, however mariadb doesn't get installed. There is no mysql-server, mysql-server-* or mysql-client-* packages in stretch so I believe this to be the source of the issue. One can fix the problem either by adding default-mysql-server before upgrading or after. however this poses a problem: * before the upgrade, the default-mysql-server package is only available in jessie-backports * after the upgrade, you've gotten no notice at all about what's happening and why the mysql server is not running and not upgraded. One way to make this an easier transition would be to have a mysql-server package in stretch that's a dummy package that depends on default-mysql-server, and that has an upgrade notice about the transition to mariadb that is happening. signature.asc Description: OpenPGP digital signature
Bug#330885: postfix: default configuration should enable use of TLS for stmp as default
I, too, would like to see this added to the default main.cf file distributed by the postfix package. With this simple change, more servers would be using server-to-server encryption. Those whose setup require them to disable such opportunistic encryption can always change the value for smtp_tls_security_level. (sorry to revive this old issue, but it's such a simple change and it hasn't recieved any love for so long) -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#811542: [Pkg-mailman-hackers] Bug#811542: mailman: Update configuration for Apache 2.4
> On Tue, January 19, 2016 18:37, David Magda wrote: > > Package: mailman > > Version: 1:2.1.18-2 > > Severity: important > > > > The current copy of /etc/mailman/apache.conf in the mailmain package > > has configuration items that are for Apache 2.2. For example: > > Thanks. This has been fixed already in 1:2.1.20-1. Hi this is great news. Could there be a backport of this config fix to the jessie package? jessie ships with apache 2.4 now so it would make sense to get that fix in there. there is a workaround, though: enabling mod_access_compat would get the default mailman apache config working. signature.asc Description: OpenPGP digital signature
Bug#596668: mailman: newlist crashes
wow this has been laying around for sooo long. current jessie version is 2.1.18 and that same line that was bugging is now #739 however, I've tried to reproduce the issue in jessie with the same list@domain and with different ones and I couldn't. I don't know if it could be linked to locale or other environment variables like this, though. in the context of that code, hostname would be initialized with this: hostname = ((mm_cfg.DEFAULT_URL and urlparse.urlparse(mm_cfg.DEFAULT_URL)[1]) or mm_cfg.DEFAULT_URL_HOST) the reported error would imply that no default URL can be found in the configuration. signature.asc Description: OpenPGP digital signature
Bug#770348: munin-node: no means of disabling cron job
Package: munin-node Version: 2.0.6-4+deb7u2 Severity: normal There is currently no means of disabling the munin-node cronjob, which runs apt-get update every hardcoded X amount of time. For ppl who don't want to use the apt* plugins it is undesirable to run the cronjob at all. -- System Information: Debian Release: 7.7 APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages munin-node depends on: ii adduser 3.113+nmu3 ii gawk1:4.0.1+dfsg-2.1 ii libnet-server-perl 2.006-1+deb7u1 ii lsb-base4.1+Debian8+deb7u1 ii munin-common2.0.6-4+deb7u2 ii munin-plugins-core 2.0.6-4+deb7u2 ii perl5.14.2-21+deb7u2 ii procps 1:3.3.3-3 Versions of packages munin-node recommends: ii libnet-snmp-perl 6.0.1-2 ii munin-plugins-extra 2.0.6-4+deb7u2 Versions of packages munin-node suggests: ii acpi 1.6-1 pn ethtool ii hdparm9.39-1+b1 pn libcache-cache-perl pn libcrypt-ssleay-perl ii libdbd-mysql-perl 4.021-1+b1 pn libdbd-pg-perl ii liblwp-useragent-determined-perl 1.06-1 pn libnet-irc-perl pn libtext-csv-xs-perl ii libwww-perl 6.04-1 pn libxml-simple-perl ii lm-sensors1:3.3.2-2+deb7u1 ii logtail 1.3.15 pn munin pn munin-plugins-java ii mysql-client 5.5.40-0+wheezy1 ii mysql-client-5.5 [mysql-client] 5.5.40-0+wheezy1 ii net-tools 1.60-24.2 ii python2.7.3-4+deb7u1 ii ruby 1:1.9.3 ii ruby1.8 [ruby]1.8.7.358-7.1+deb7u1 ii smartmontools 5.41+svn3365-1 -- Configuration Files: /etc/cron.d/munin-node [Errno 2] No such file or directory: u'/etc/cron.d/munin-node' /etc/munin/munin-node.conf changed [not included] /etc/munin/plugin-conf.d/munin-node changed [not included] -- 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#770348: closed by Holger Levsen (Re: [Packaging] Bug#770348: munin-node: no means of disabling cron job)
On 20/11/14 11:57 AM, ow...@bugs.debian.org (Debian Bug Tracking System) wrote: > On Donnerstag, 20. November 2014, Gabriel Filion wrote: >> > There is currently no means of disabling the munin-node cronjob, >> > which runs apt-get update every hardcoded X amount of time. >> > >> > For ppl who don't want to use the apt* plugins it is undesirable to >> > run the cronjob at all. > "rm $cronjob_file" works just fine. Or commenting out the lines... sure, but won't the package just reinstall that file on the next upgrade? -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#725113: monkeysign: please support monkeysign --version
Hey there,
in the source code under monkeysign/__init__.py I found those two lines
which are pretty interesting for this:
3 __version_info__ = ('1', '1')
4 __version__ = '.'.join(__version_info__)
now in the 2.x branch the __version_info__ variable hasn't been bumped
to something meaningful, but it could easily be done.
and with this info already in place, implementing --version is just a
matter of printing __version__ ;)
--
Gabriel Filion
signature.asc
Description: OpenPGP digital signature
Bug#725113: [PATCH] Implement --version option
On 30/07/14 01:37 AM, gabs...@lelutin.ca wrote: > From: Gabriel Filion > > The version information is actually already available, so we just need > to add the proper option to display it. oh, sorry I forgot to mention that this patch was based on current 2.x, e.g. commit 311671e6045ccb458d03d763c9dfe5e787744aaf -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#720050: monkeysign: -u should take full fingerprint
On Mon, 19 Aug 2013 10:32:35 -0400 micah wrote: > Antoine Beaupré writes: > > On 2013-08-17 18:16:59, Micah Anderson wrote: > >> You can pass the full fingerprint, including spaces, to monkeysign for > >> the key to be signed. However, if you try to do this for -u, then it > >> gets rather confused and only takes the first 4 characters and then > >> assumes the remainder is a key that should be signed (an invalid key > >> that it will fail to find). > > > > This is a limitation of the "optparse" library - the number of arguments > > to an option is hardcoded, I believe. Logically, the commandline parser > > needs to know how many arguments after `-u` it needs to "eat" and pass > > to that option, and since we want to accept single uids, it seems to me > > we can't accept space-separated fingerprints there. > > > > I know it's inconsistent, but it's a limitation with the commandline > > parser built into python. The new "argparse" library supports variable > > length arguments, but that requires porting: > > Thanks for the explanation! usually arguments in the unix world will only have one value that may have a special format to bring in more information. > > http://docs.python.org/2/library/argparse.html#nargs > > > > So for now, use a single userid or (non-space-separated) fingerprint. > > > > (Or is monkeysign -u choking on (non-space-separated) fingerprints?) > > Nope, it is just choking on the space-separated ones. have you tried quoting your fingerprint so that it's taken as "one blob" for the -u option? like this: monkeysign -u "1234 5678 9ABC ..." --other-options the above seems to be working for me with the 2.x branch. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#756540: monkeysign: no debugging info from smtp connection
Package: monkeysign
Version: 2.x
Severity: normal
Hi there,
I've been using monkeysign 2.x (from git repos) and by making a user
error, I've actually hit some real uglyness from python's smtplib that
crackles up all the way to the user:
if you give some string that smtplib doesn't like as the value to
--smtpserver (or -s) you end up getting a stack trace that says
"socket.gaierror: [Errno -2] Name or service not known" (does not
specify what host:port tuple was used for establishing a connection).
Now even though it's a bit ugly and unsettling for normal users, it's
still a bit useful to developers.
however, turning on debug for monkeysphere doesn't actually turn on
debugging in smtplib until the smtp connection was established. so we
can't get more help there.
that's because of how badly the interface of smtplib is designed:
* constructor forces an SMTP connection right away if host string is
provided, but
* constructor does not accept a debug level to set it while
instantiating.
So ppl trying to find out what is happening are at a loss.
I believe the correct workaround would be to change the smtplib.SMTP
class instantiation to something like the following:
server = smtplib.SMTP() # DONT pass in host string here
server.set_debuglevel(self.options.debug)
# to be nicer to users, we could catch socket.error exceptions from
# server.connect() here and display a meaningful message to stderr.
(code, msg) = server.connect(self.options.smtpserver)
if code != 220:
self.warn(_("Connection to SMTP server '%s' was unsuccessful: %s
%s" (self.options.smtpserver, code, msg)))
# quit somehow at this point.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757170: fail2ban: sasl jail misbehaves and does not match most of the time
Package: fail2ban
Version: 0.8.6-3wheezy2
Severity: normal
Hello,
I've configured a "sasl" jail to catch annoying ppl who abuse of SMTP auth. It
uses the sasl filter provided with the package.
However, it doesn't seem to be matching anything.. I tested the regexp from the
jail on the configured log file (syslog) and it says that it's matching 3k+
entries, so it should be working fine.
I tried lowering maxretry to make it catch IPs faster, but it didn't help.
Also, weirdly at some point I made a manual change to jail.local (bumped
maxretry down from 7 to 5 for the sasl jail), then restarted the service, and I
saw it match hosts and ban them. But if I try this experience again, I don't
get any results anymore.
So I'm at a loss, I don't really know how to debug what's happening.
Here are the config files that don't contain the same thing as what the package
installs. (replaced last 2 parts of ignored IPs)
/etc/fail2ban/jail.conf:
# Fail2Ban configuration file.
#
# This file was composed for Debian systems from the original one
# provided now under /usr/share/doc/fail2ban/examples/jail.conf
# for additional examples.
#
# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local
#
# Author: Yaroslav O. Halchenko
#
# $Revision$
#
# The DEFAULT allows a global definition of the options. They can be overridden
# in each jail afterwards.
[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 199.58.xx.yy 199.58.xx.yy 216.46.xx.yy
bantime = 600
maxretry = 3
# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto".
# yoh: For some reason Debian shipped python-gamin didn't work as expected
# This issue left ToDo, so polling is default backend for now
backend = polling
#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost
#
# ACTIONS
#
# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = iptables-multiport
# email action. Since 0.8.1 upstream fail2ban uses sendmail
# MTA for the mailing. Change mta configuration parameter to mail
# if you want to revert to conventional 'mail'.
mta = sendmail
# Default protocol
protocol = tcp
# Specify chain where jumps would need to be added in iptables-* actions
chain = INPUT
#
# Action shortcuts. To be used to define action parameter
# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s",
protocol="%(protocol)s", chain="%(chain)s"]
# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s",
protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s",
protocol="%(protocol)s", chain="%(chain)s"]
# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s",
protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s",
logpath=%(logpath)s, chain="%(chain)s"]
# Choose default action. To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl,
etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s
/etc/fail2ban/jail.local:
#
# JAILS
#
# Next jails corresponds to the standard configuration in Fail2ban 0.6 which
# was shipped in Debian. Enable any defined here jail by including
#
# [SECTION_NAME]
# enabled = true
#
# in /etc/fail2ban/jail.local.
#
# Optionally you may override any other parameter (e.g. banaction,
# action, port, logpath, etc) in that section within jail.local
[dovecot]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = dovecot
logpath = /var/log/mail.log
maxretry = 7
findtime = 120
ignoreip = 127.0.0.1 199.58.xx.yy 216.46.xx.yy 199.58.xx.yy
[postfix]
enabled = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log
maxretry = 7
ignoreip = 127.0.0.1 199.58.xx.yy 216.46.xx.yy 199.58.xx.yy
[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl
logpath = /var/log/syslog
maxretry = 5
ignoreip = 127.0.0.1 199.58.xx.yy 216.46.xx.yy 199.58.xx.yy
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
ignoreip = 127.0.0.1 199.58.xx.yy 216.46.xx.yy 199.58.xx.yy
-- System Information:
Debian Release: 7.5
APT prefers stable
APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of pa
Bug#768005: Please support xl xen management command
This would've been great to have for the jessie release. The lack of completion for xl makes using this command quite annoying. Since most of the commands are the same as with xm, we could start with cloning the completion file for xm and work out the differences from there. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#774643: verify_active_connections is not present in ruby-activerecord 4.1.8
Hey there, Sorry if I'm jumping in late, but I'd like to weigh in the importance of storedconfigs. Even though it's an optional feature, the biggest majority of users need to use it in order to have a functional setup. For comparison, releasing without it would be like releasing apache without one of the crucial modules, like mod_rewrite. We really do need to find a solution to this issue before jessie is released (or in the worst case, at first point release). -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#639698: reportbug: STARTTLS failure - continue without TLS
That sounds like a terrible idea.. unless you meant to make reportbug try STARTTLS in that case and then fail if this doesn't work. But if the user asked for an encrypted communication, the app should not fall back to sending it in clear text. That's the basis of all the nastiness of downgrade attacks that could happen with STARTTLS and other protocols that permit this kind of fallback. The best option here should be to have a clear error message of what didn't work. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#782169: mosh: bash_completion script does not complete hosts from known_hosts
Package: mosh
Version: 1.2.4a-1+b2
Severity: normal
Tags: patch
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gabriel Filion
To: Debian Bug Tracking System
Subject: mosh: script for bash_completion does not find hosts in known_hosts
Message-ID: <20150408195653.4718.63600.report...@boohn.lelutin.ca>
X-Mailer: reportbug 6.6.3
Date: Wed, 08 Apr 2015 15:56:53 -0400
Package: mosh
Version: 1.2.4a-1+b2
Severity: normal
Tags: patch
Hello,
The script for bash_completion included in the mosh package does not complete
hosts from ssh's known_hosts. This is annoying since that's the most frequent
source of hostnames for machines to ssh to.
Also, according to the comment on the _known_hosts function in
/usr/share/bash-completion/bash_completion, the _known_hosts function is
deprecated and _known_hosts_all should be used instead. This latter function
needs a minimum of setup.
Here's a patch for the /etc/bash_completion.d/mosh file that implements lookup
for known_hosts:
--8<
$ diff -burN /etc/bash_completion.d/mosh{.old,}
--- /etc/bash_completion.d/mosh.old 2015-04-08 15:54:11.122373833 -0400
+++ /etc/bash_completion.d/mosh 2015-04-08 15:54:15.414322372 -0400
@@ -1 +1,9 @@
-complete -F _known_hosts mosh
+_mosh () {
+local cur prev
+
+_init_completion || return
+
+_known_hosts_real -a "$cur"
+}
+
+complete -F _mosh mosh
->8-
Note that this does not take into account any arguments to the mosh executable,
so it's probably not the best possible formulation for a bash_completion
script, but it fixes the lack of known_hosts completion and can be built upon
for adding the other options.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mosh depends on:
ii libc6 2.19-17
ii libgcc1 1:4.9.2-10
ii libprotobuf92.6.1-1
ii libssl1.0.0 1.0.1k-3
ii libstdc++6 4.9.2-10
ii libtinfo5 5.9+20140913-1+b1
ii libutempter01.1.5-4
ii openssh-client 1:6.7p1-5
ii zlib1g 1:1.2.8.dfsg-2+b1
mosh recommends no packages.
mosh suggests no packages.
-- Configuration Files:
/etc/bash_completion.d/mosh changed [not included]
-- no debconf information
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mosh depends on:
ii libc6 2.19-17
ii libgcc1 1:4.9.2-10
ii libprotobuf92.6.1-1
ii libssl1.0.0 1.0.1k-3
ii libstdc++6 4.9.2-10
ii libtinfo5 5.9+20140913-1+b1
ii libutempter01.1.5-4
ii openssh-client 1:6.7p1-5
ii zlib1g 1:1.2.8.dfsg-2+b1
mosh recommends no packages.
mosh suggests no packages.
-- Configuration Files:
/etc/bash_completion.d/mosh changed [not included]
-- 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#782169: mosh: bash_completion script does not complete hosts from known_hosts
On 08/04/15 04:28 PM, Gabriel Filion wrote: > Package: mosh > Version: 1.2.4a-1+b2 > Severity: normal > Tags: patch > > Dear Maintainer, > [...] argh, sorry about that content duplication. I was having issues with configuring reportbug correctly so I saved the former report trial as a file. and I'm still trying to get a hang of all the (many!) quirks of reportbug.. seems like the --body-file option didn't do what I expected. Also, I've included the command line used for diffing, which does make the "cut-here" part of my original message not applicable as-is: you need to remove the first line. my objective with that was to ensure that you know what the formatting of the patch corresponds to. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#749315: Same issue with main screen temporarily
Hey there, I've just experienced the same issue as described here on my laptop after upgrading to 3.18.1-1. The issue was visible on my laptop screen with no external screen attached. I've resolved the issue by going in the displays configuration panel, opening up the only screen available and clicking on "Apply". For some reason gnome was confused about the screen being the main one, and it got fixed by applying configuration. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#803386: icedove: segfaults in MessageChannel.cpp
Package: icedove Version: 42.0~b1-1 Severity: important Hello, I'm experiencing random segfaults in icedove and it doesn't seem to correspond to the other ones that were reported. So far the only useful information I have is from syslog just before and during the crash: Oct 29 09:36:07 boohn icedove.desktop[2410]: 2015-10-29 09:36:07#011autosyncActivities#011ERROR#011OnDownloadError: RT-Support of gabr...@koumbit.org Oct 29 09:41:17 boohn icedove.desktop[2410]: (process:6623): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Oct 29 09:46:37 boohn icedove.desktop[2410]: (process:6649): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Oct 29 09:52:55 boohn icedove.desktop[2410]: (plugin-container:6706): Gdk-WARNING **: The GDK_NATIVE_WINDOWS environment variable is not supported in GTK3. Oct 29 09:52:55 boohn icedove.desktop[2410]: See the documentation for gdk_window_ensure_native() on how to get native windows. Oct 29 09:52:55 boohn icedove.desktop[2410]: Vector smash protection is enabled. Oct 29 09:52:56 boohn icedove.desktop[2410]: #007[NPAPI 6706] ###!!! ABORT: Aborting on channel error.: file /build/icedove-RFEbAP/icedove-42.0~b1/mozilla/ipc/glue/MessageChannel.cpp, line 1768 Oct 29 09:52:56 boohn icedove.desktop[2410]: [NPAPI 6706] ###!!! ABORT: Aborting on channel error.: file /build/icedove-RFEbAP/icedove-42.0~b1/mozilla/ipc/glue/MessageChannel.cpp, line 1768 Oct 29 09:52:56 boohn kernel: [44738.694873] Chrome_ChildThr[6709]: segfault at 0 ip 004083fa sp 7fd7b88fe3f0 error 6 in plugin-container[40+3c000] I'm running sid with icedove and iceweasel from experimental. I don't really know what triggers those segfaults so it's a bit hard to reproduce them consistently. However, the happen every other day or once per 3 days or so. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.5.1 ii fontconfig2.11.0-6.3 ii libasound21.0.29-1 ii libatk1.0-0 2.18.0-1 ii libc6 2.19-22 ii libcairo-gobject2 1.14.2-2 ii libcairo2 1.14.2-2 ii libdbus-1-3 1.10.2-1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-2 ii libffi6 3.2.1-3 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.6-2 ii libgcc1 1:5.2.1-22 ii libgdk-pixbuf2.0-02.32.1-1 ii libglib2.0-0 2.46.1-1 ii libgtk-3-03.18.2-1 ii libhunspell-1.3-0 1.3.3-3+b1 ii libicu55 55.1-5 ii libnspr4 2:4.10.9-2 ii libnss3 2:3.20-1 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpangoft2-1.0-0 1.38.1-1 ii libpixman-1-0 0.33.2-2 ii libsqlite3-0 3.9.1-2 ii libstartup-notification0 0.12-4 ii libstdc++65.2.1-22 ii libvpx2 1.4.0-4 ii libx11-6 2:1.6.3-1 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxrender1 1:0.9.8-1+b1 ii libxt61:1.1.4-1+b1 ii psmisc22.21-2.1 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii iceowl-extension 42.0~b1-1 Versions of packages icedove suggests: ii fonts-lyx 2.1.4-2 ii libgssapi-krb5-2 1.13.2+dfsg-3 -- no debconf information
Bug#803386: icedove: segfaults in MessageChannel.cpp
On 29/10/15 10:35 AM, Carsten Schoenert wrote: > On Thu, Oct 29, 2015 at 10:21:22AM -0400, Gabriel Filion wrote: >> I'm experiencing random segfaults in icedove and it doesn't seem to >> correspond >> to the other ones that were reported. >> >> So far the only useful information I have is from syslog just before and >> during the crash: >> >> Oct 29 09:36:07 boohn icedove.desktop[2410]: 2015-10-29 >> 09:36:07#011autosyncActivities#011ERROR#011OnDownloadError: RT-Support of >> gabr...@koumbit.org >> Oct 29 09:41:17 boohn icedove.desktop[2410]: (process:6623): GLib-CRITICAL >> **: g_slice_set_config: assertion 'sys_page_size == 0' failed >> Oct 29 09:46:37 boohn icedove.desktop[2410]: (process:6649): GLib-CRITICAL >> **: g_slice_set_config: assertion 'sys_page_size == 0' failed >> Oct 29 09:52:55 boohn icedove.desktop[2410]: (plugin-container:6706): >> Gdk-WARNING **: The GDK_NATIVE_WINDOWS environment variable is not supported >> in GTK3. >> Oct 29 09:52:55 boohn icedove.desktop[2410]: See the documentation for >> gdk_window_ensure_native() on how to get native windows. >> Oct 29 09:52:55 boohn icedove.desktop[2410]: Vector smash protection is >> enabled. >> Oct 29 09:52:56 boohn icedove.desktop[2410]: #007[NPAPI 6706] ###!!! ABORT: >> Aborting on channel error.: file >> /build/icedove-RFEbAP/icedove-42.0~b1/mozilla/ipc/glue/MessageChannel.cpp, >> line 1768 >> Oct 29 09:52:56 boohn icedove.desktop[2410]: [NPAPI 6706] ###!!! ABORT: >> Aborting on channel error.: file >> /build/icedove-RFEbAP/icedove-42.0~b1/mozilla/ipc/glue/MessageChannel.cpp, >> line 1768 >> Oct 29 09:52:56 boohn kernel: [44738.694873] Chrome_ChildThr[6709]: segfault >> at 0 ip 004083fa sp 7fd7b88fe3f0 error 6 in >> plugin-container[40+3c000] >> >> I'm running sid with icedove and iceweasel from experimental. >> >> I don't really know what triggers those segfaults so it's a bit hard to >> reproduce them consistently. However, the happen every other day or once per >> 3 >> days or so. > > please try to make a gdb log. Without further informations it's nearly > impossible to catch the reason for the crash. > > https://wiki.debian.org/Icedove#Starting_Debugging youch ok. since I don't know what triggers the segfaults, I might need to run icedove in gdb for hours or days :\ is there a way to make it dump a coredump when it crashes instead of having to run it all the time in gdb? -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#801425: dbus: upgrade from dbus 1.10.0-2 to 1.10.0-3 breaks policykit
Package: dbus Version: 1.10.0-3 Severity: grave Justification: renders package unusable Hi, I'm running sid and this morning I performed an apt-get upgrade and a dist-upgrade. This pulled in dbus 1.10.0-3. Upon restart, systemd was hanging for a bunch of time with messages like the following: Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Then it would move on with other sartup jobs, and finally end up trying to start gdm3 which looped and failed continuously. I was able to switch to tty1 and login but was continuously dragged back to tty7 because of gdm3 loop-failing every 10 seconds. Also, login on tty1 took approximately 30 seconds to succeed. I'm marking the bug as "grave" since it renders computers mostly unsusable. policykit-1 was not upgraded during the upgrade/dist-upgrade run. I've added versions of policykit-1* in the list of package versions below. Downgrading dbus and libdbus-1-3 to 1.10.0-2 fixed the issue, so it is clearly a regression in the -3 version. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dbus depends on: ii adduser 3.113+nmu3 ii libapparmor1 2.10-2+b1 ii libaudit1 1:2.4.4-4 ii libc6 2.19-22 ii libcap-ng00.7.7-1 ii libdbus-1-3 1.10.0-2 ii libexpat1 2.1.0-7 ii libselinux1 2.3-2+b1 ii libsystemd0 227-1 ii lsb-base 9.20150917 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 1.10.0-3 Versions of packages dbus is related to: ii dbus-x11 1.10.0-3 ii systemd 227-1 ii systemd-sysv 227-1 Versions of policykit: ii policykit-10.113-1 ii policykit-1-gnome 0.105-2 -- no debconf information
Bug#801425: dbus: upgrade from dbus 1.10.0-2 to 1.10.0-3 breaks policykit
Hi there, On 10/10/15 06:59 PM, Simon McVittie wrote: > On 10/10/15 17:38, Gabriel Filion wrote: > It would be really useful to see any systemd, policykit-1 (polkit) > and/or dbus warnings/errors from 2015-10-09, from your syslog. If you > would prefer not to send that day's syslog to the BTS or spend time > censoring it, you can send it to me by private email (compressed if it's > large), and I'll make sure to only quote the relevant debug details on > the bug. gah I'm terribly sorry but I was extremely busy all week long and couldn't get to replying to your message. and now logs for oct 9th just got rotated out into oblivion so I can't send the details I had. real sorry for that! fwiw, dbus was upgraded again to 1.10.0-3 and later I downgraded policykit-1 to 0.105-12, the version from sid. And I haven't seen the same kind of error reproducing. I've had one more issue with gdm that wouldn't start but that day I wasn't seeing the same error lines as initially reported, and rebooting fixed the situation. If I see the issue reappearing I'll make a sign here. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#801425: dbus: upgrade from dbus 1.10.0-2 to 1.10.0-3 breaks policykit
On 16/10/15 03:45 PM, Simon McVittie wrote: > Control: tags 801425 + unreproducible > Control: block 801425 by 801354 > > On 16/10/15 20:03, Gabriel Filion wrote: >> fwiw, dbus was upgraded again to 1.10.0-3 and later I downgraded >> policykit-1 to 0.105-12, the version from sid. And I haven't seen the >> same kind of error reproducing. > > Did you upgrade systemd to 227-2 during that time? The systemd > maintainers wondered whether this might be > https://bugs.debian.org/801354 which had similar symptoms. The root > cause hasn't been found, but 227-2 reverts a commit which works around it. I'm still using systemd 227-1 at the moment. > You started to have this problem with systemd 227-1, which is the > version that regressed, so I suspect you might have had #801354. I'll upgrade to 227-2 and see if I still get occasional problems -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#772222: bup: bashism in /bin/sh script
Hi there, I've just submitted a patch to the upstream mailing list in order to fix this bug. hopefully it can get merged relatively soon. https://groups.google.com/d/msg/bup-list/E_vFEF_12zo/CuwMH3kQiCIJ -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#683469: xserver-xorg-video-intel: Graphical distortion and text / font corruption in X
Hi there, I can confirm this bug. It wasn't appearing too often before, but it seems like it's happening frustratingly more often ever since I upgraded to 2.99.917 (running sid) I can see no tangible error in syslog or xorg.log, maybe except for some lines that don't seem to be too precise about the nature of the issue: Jun 23 16:54:53 boohn gnome-session[1664]: ** (gnome-shell:1793): CRITICAL **: remove_mnemonics: assertion 'label != NULL' failed Jun 23 16:55:06 boohn gnome-session[1664]: (gnome-shell:1793): mutter-WARNING **: STACK_OP_ADD: window 0x1800368 already in stack I'm running a thinkpad x201. I can send more info about my setup if this can help. -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#760717: monkeysign chokes when gpg wants user to run with --check-trustdb
Package: monkeysign
Version: 2.x
Severity: normal
with current master (commit 5a8d12914a8d4388c6543056098276f6e756e483)
when I try to sign a key, gpg emits an error message about needing to
run with --check-trustdb, and apparently monkeysign is choking on this
output with the following debug info:
Sign all identities? [y/N] y
Really sign key? [y/N] y
command: ['gpg', '--command-fd', '0', '--with-fingerprint',
'--list-options',
'show-sig-subpackets,show-uid-validity,show-unusable-uids,show-unusable-subkeys,show-keyring,show-sig-expire',
'--status-fd', '2', '--quiet', '--batch', '--fixed-list-mode',
'--no-tty', '--with-colons', '--use-agent', '--secret-keyring',
'/home/me/.gnupg/secring.gpg', '--homedir', '/tmp/pygpg-dPlODL',
'--sign-key', 'somefingerprinthere']
SKIPPED: gpg: please do a --check-trustdb
Traceback (most recent call last):
File "/usr/local/bin/monkeysign", line 4, in
__import__('pkg_resources').run_script('monkeysign==2.0-dev',
'monkeysign')
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 534, in
run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1445,
in run_script
exec(script_code, namespace, namespace)
File
"/usr/local/lib/python2.7/dist-packages/monkeysign-2.0_dev-py2.7.egg/EGG-INFO/scripts/monkeysign",
line 41, in
File "build/bdist.linux-x86_64/egg/monkeysign/cli.py", line 69, in
main
File "build/bdist.linux-x86_64/egg/monkeysign/ui.py", line 296, in
sign_key
File "build/bdist.linux-x86_64/egg/monkeysign/gpg.py", line 464, in
sign_key
monkeysign.gpg.GpgRuntimeError: [Errno 0] cannot sign: gpg: please do a
--check-trustdb
"
when run interactively, gpg is able to proceed with creating the
signature. but if the uninteractive nature of the interaction with gpg
via monkeysphere restricts us from actually signing keys, then maybe
just handling the exception better around line 464 in sign_key would be
enough.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages monkeysign depends on:
ii gnupg 1.4.18-2
ii python2.7.8-1
ii python-pkg-resources 5.5.1-1
Versions of packages monkeysign recommends:
ii python-gtk2 2.24.0-4
ii python-qrencode 1.01-4
ii python-zbar 0.10+doc-9+b2
ii python-zbarpygtk 0.10+doc-9+b2
monkeysign suggests no packages.
signature.asc
Description: OpenPGP digital signature
Bug#767659: evince 3.14.1-1 gets undefined symbol with libpoppler46:i386 earlier than 0.26.5-2
I can confirm this issue and its resolution. I got the same segfault about the same undefined symbol when I last upgraded evince: ii libpoppler-glib8:amd640.26.5-2 amd64PDF rendering library (GLib-based shared library) ii libpoppler46:amd640.26.5-1 amd64PDF rendering library ii poppler-data 0.4.7-1 all encoding data for the poppler PDF rendering library ii poppler-utils 0.26.5-2 amd64PDF utilities (based on Poppler) ii evince3.14.1-1 amd64Document (PostScript, PDF) viewer ii evince-common 3.14.1-1 all Document (PostScript, PDF) viewer - common files ii gir1.2-evince-3.0 3.14.1-1 amd64GObject introspection data for the evince libraries The error message: (evince:1962): EvinceDocument-WARNING **: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8: undefined symbol: _ZN7GfxFont16getAlternateNameEPKc Segmentation fault also, manually upgrading libpoppler46 to the -2 version fixed the issue. since the problem seems to be coming from the version difference between libpoppler46 and libpoppler-glib8, this bug report might be more suited to the library libpoppler-glib8, since that's the package that's depending on libpoppler46 -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#756540: monkeysign: no debugging info from smtp connection
I've tested the patch and found a bug with it. The "msg" argument gets
overridden by the new error handling code and provokes a traceback.
You'll find a patch attached to fix said issue.
--
Gabriel Filion
From f0962aa6b8b539b04497bd3d3a71983a5ff67097 Mon Sep 17 00:00:00 2001
From: Gabriel Filion
Date: Mon, 22 Sep 2014 17:18:01 -0400
Subject: [PATCH] smtp reports a stack trace
commit 1dbc8ce4faf3591d7885a9c86fb09d4ec54cd5b4 broke smtp: the msg
variable to the function gets overridden by the return value of the smtp
connection.
---
monkeysign/ui.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/monkeysign/ui.py b/monkeysign/ui.py
index 8c7bcba..41f68fb 100644
--- a/monkeysign/ui.py
+++ b/monkeysign/ui.py
@@ -343,11 +343,11 @@ expects an EmailFactory email, but will not mail if nomail is set"""
# to be nicer to users, we could catch socket.error exceptions from
# server.connect() here and display a meaningful message to stderr.
try:
-(code, msg) = server.connect(self.options.smtpserver)
+(code, srvmsg) = server.connect(self.options.smtpserver)
except (socket.error, socket.timeout) as e:
self.abort(_('Error connecting to SMTP server %s: %s') % (self.options.smtpserver, e))
if code != 220:
-self.abort(_('Unexpected SMTP server error while talking to %s, code: %s (%s)') % (self.options.smtpserver, code, msg))
+self.abort(_('Unexpected SMTP server error while talking to %s, code: %s (%s)') % (self.options.smtpserver, code, srvmsg))
try:
server.starttls()
except SMTPException:
--
2.1.0
signature.asc
Description: OpenPGP digital signature
Bug#756540: [PATCH] catching error from non-imported module
commit 1dbc8ce added more error handling around smtp connections but forgot to import the module "socket" to be able to catch exceptions defined in that module. --- monkeysign/ui.py | 1 + 1 file changed, 1 insertion(+) diff --git a/monkeysign/ui.py b/monkeysign/ui.py index 41f68fb..d51b319 100644 --- a/monkeysign/ui.py +++ b/monkeysign/ui.py @@ -37,6 +37,7 @@ import sys import re import os import shutil +import socket class MonkeysignUi(object): """User interface abstraction for monkeysign. -- 2.1.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756540: one more patch and testing
Hello,
I've tested the code with the patch I just submitted, by trying with
"-d" to connect to a closed port:
stderr:
connect: ('mail.lelutin.ca', 466)
connect: ('mail.lelutin.ca', 466)
Error connecting to SMTP server mail.lelutin.ca:466: [Errno 111]
Connection refused
the above is a sample of the output. we can see the debugging output
from smtplib followed by the output from the error handling.
with debugging turned off, I see only the error message about the
connection being refused.
so I guess we can say this is a mission complete :)
--
Gabriel Filion
signature.asc
Description: OpenPGP digital signature
Bug#761985: Master.csv rotation
Hello there, I personally don't see a difference between a text file with lines that track web site visits and a text file with lines that track calls being made and received. The Master.csv file is enabled by default and never rotated. This means that ppl who don't know too much about how asterisk works and how it is configured by default will end up with a humongous log file of all calls ever made. No rotation of logs is a really bad policy and can actually mean trouble for some ppl who didn't want to keep that info on disk in the first place. I'd advocate for disabling Master.csv by default and requiring ppl to knowingly enable it. The debian package could even have a notice to remember ppl to rotate that file at some point if they decide to enable call logging. Otherwise if maintainers feel that disabling this would be too much of a big change, then the package would definitely need log rotation keeping only a reasonably small period of log data, like 14 days. Regards signature.asc Description: OpenPGP digital signature
Bug#819218: postfixadmin: A newer version, 2.93 should be packaged
Package: postfixadmin Version: 2.3.7-1 Severity: normal Dear Maintainer, A newer version of PostfixAdmin has been available for some time. The software author, Christian Boltz said recently[0] on the upstream mailing list that this version is considered stable. [0]: https://sourceforge.net/p/postfixadmin/mailman/message/34961689/ The newer version has the advantage of offering better hashing methods: the current version can only offer salted MD5, whereas 2.93 lets you use hashes like salted SHA256 or salted SHA512. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postfixadmin depends on: ii dbconfig-common 1.8.47+nmu3+deb8u1 ii debconf 1.5.56 ii mysql-client-5.5 [mysql-client] 5.5.47-0+deb8u1 ii nginx-full [httpd] 1.6.2-5+deb8u1 ii php5-cgi 5.6.17+dfsg-0+deb8u1 ii php5-imap5.6.17+dfsg-0+deb8u1 ii php5-mysql 5.6.17+dfsg-0+deb8u1 ii wwwconfig-common 0.2.2 Versions of packages postfixadmin recommends: ii dovecot-core 1:2.2.13-12~deb8u1 ii mysql-server 5.5.47-0+deb8u1 ii postfix-mysql 2.11.3-1 ii zendframework 1.12.9+dfsg-2+deb8u5 postfixadmin suggests no packages. -- debconf information excluded
Bug#778794: postfixadmin: Please change the dependencies/recommendations
The dependencies currently have mysql-server as a recommends only, so you can avoid installing it by using --no-install-recommends. the same would hold for dovecot-* There is however a dependency on mysql-client which would prevent one from using mariadb-client (and would cause a conflict with the server part since mariadb-server-10.0 depends on mariadb-client-10.0, which conflicts with mysql-client-5.5) if this can be helpful for the package maintainers, both mysql and mariadb packages have a Provides line that could let users have either mysql or mariadb: Provides: virtual-mysql-client and for the server counterpart: Provides: virtual-mysql-server signature.asc Description: OpenPGP digital signature
Bug#470417: new upstream version out with ipv6 support
Hello, Just wanted to send a ping to this bug report. apparently 0.10.0 has finally been released with IPv6 support just a couple of days ago: https://github.com/fail2ban/fail2ban/releases/tag/0.10.0 maybe 0.10.0 should go to unstable? signature.asc Description: OpenPGP digital signature
Bug#865820: vim-common: Change of behaviour for default value of mouse is annoying
Package: vim-common Version: 2:8.0.0197-3 Severity: wishlist Hello, The default value for the mouse global variable has been changed from empty string to "a" starting from stretch. This is annoying and does not respect what is documented as the upstream default value: 'mouse' string (default "", "a" for GUI, MS-DOS and Win32, set to "a" in defaults.vim) Can we bring back this variable to default to empty string? -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vim-common depends on: ii xxd 2:8.0.0197-3 Versions of packages vim-common recommends: ii vim-nox [vim] 2:8.0.0197-3 ii vim-tiny 2:8.0.0197-3 vim-common suggests no packages. -- no debconf information
Bug#861691: postfixadmin 3.0 not compatible with php 7
I've hit errors now on a fresh install of postfixadmin on stretch with php 7.0. The error says "MySQL 3.x / 4.0 functions not available! (php5-mysql installed?)" although php-mysql *is* installed. I've looked up in the source code what triggers that error and it's a test to ensure that function "mysql_connect" is present. As this page [0] suggests that function was deprecated in php 5.5 and completely removed in php 7, so that means that the postfixadmin codebase is not even compatible with PHP 7. [0]:http://php.net/manual/en/function.mysql-connect.php So either we need patches to make postfixadmin work with php7, or it should be marked as completely broken and possibly removed. (I'd prefer the former if possible, but I don't know the state of the upstream code) signature.asc Description: OpenPGP digital signature
Bug#861691: postfixadmin 3.0 not compatible with php 7
Gabriel Filion: > As this page [0] suggests that function was deprecated in php 5.5 and > completely removed in php 7, so that means that the postfixadmin > codebase is not even compatible with PHP 7. please disregard this comment.. apparently the issue is caused by the post-install script creating a dbconfig.inc.php file that configures the database type as "mysql" instead of "mysqli", which triggers the error that I've seen. The installation is however not complete because of this issue since dbconfig-common is unable to create the necessary tables for postfixadmin and the database is left empty. signature.asc Description: OpenPGP digital signature
Bug#858005: postfixadmin: upgrade.php fails at various places because of too long indexes
Hi there! I've replicated the issue when running setup.php right after an installation of postfixadmin. Then I've applied the patch linked to by Jascha and I can confirm that it does solve the issue. With the patch applied, the setup.php script calls upgrade.php and successfully creates the database. signature.asc Description: OpenPGP digital signature
Bug#857444: [debian-mysql] Bug#857444: Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Hi there, I've traced inter-package links (depends, conflicts et al) and I think I found the reason why the server gets removed. stretch still has a mysql-common package that has a "Replaces:" for mysql-server-5.5. during a dist-upgrade mysql-common will get upgraded to the stretch version, which in turn will remove the server package. to test this hypothesis, I ran "apt-mark hold mysql-common" right before doing a dist-upgrade from jessie to stretch and both mysql-server and mysql-server-5.5 then don't get removed by apt/dpkg. signature.asc Description: OpenPGP digital signature
Bug#860337: php7.0: No transition path from php5 to php7.0 when upgrading to stretch
Hello, for a little bit of additional information, the mysql to mariadb transition decided to use a meta-package called default-mysql-server to provide a path for the transition during the upgrade. Since php5 and php7 have a good number of differences, it might be desirable to have some kind of similar "opt-in" upgrade path so that one could install some package in jessie before performing the upgrade to stretch and have php packages get automatically upgraded to 7.0 one other detail that would be nice would be to add a note about this upgrade path in the release notes: https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html signature.asc Description: OpenPGP digital signature
Bug#816399: pass: Pass does not locate gpg secret key
Paul, When I migrated to gpg 2.1, I've had issues with "secret key not found" errors. This was caused by the fact that pass had installed gnupg2 as a dependency long ago but I was still using gpg 1.4 for a good while before migrating, so there were indeed keys missing. If this sounds like your current situation, you might want to try to reimport your keys to gnupg2 with: gpg --import ~/.gnupg/secring.gpg before doing that, you can list files in ~/.gnupg/private-keys-v1.d/ . each file is named after a "keygrip". You can show keygrips with: gpg -k --with-keygrip y...@uid.tld If that solves your issue, the bug was not with pass but rather an incomplete migration to gnugp2. then you might want to get more information about this migration and what you need to adjust in your configuration to use gpg 2. hope that helps! p.s.: Thadeu: your issue seems rather quite different than the one reported first. If your issue is still persisting you might want to report it in a seperate bug report. signature.asc Description: OpenPGP digital signature
Bug#860353: pass: extraneous reencryptions
Package: pass Version: 1.6.5-4 Severity: normal Hello, Version 1.6.5 suffers from a small but irritating bug: some commands like init, mv are calling a check for whether or not a file needs to be reencrypted. That check has a bug that makes it always reencrypt files in certain circumstances. The issue was already fixed upstream right before 1.7.1 was released this week. I haven't looked at why the 1.7 package is marked as buggy in experimental, but my concern is more for jessie and stretch which have versions 1.6.3 and 1.6.5, respectively. Both are affected by this bug. If I'm not mistaken 1.6.x is not maintained by upstream as a separate branch so in order to fix the issue I guess we'd have to backport the patch ourselves. Luckily it's an easy one-liner: commit a09d6685e609f9a11fa2b9b5904d39ef8966b3b7 in upstream repos. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pass depends on: ii gnupg 2.1.18-6 ii gnupg2 2.1.18-6 ii pwgen 2.07-1.1+b1 ii tree1.7.0-5 Versions of packages pass recommends: ii git 1:2.11.0-2 ii gnupg2 2.1.18-6 ii xclip 0.12+svn84-4+b1 Versions of packages pass suggests: ii libxml-simple-perl 2.22-1 ii perl5.24.1-2 ii ruby1:2.3.3 -- no debconf information
Bug#860362: release-notes: [stretch] wrong versions for OpenSSH in "what's new"
Package: release-notes Severity: normal Hello, The versions currently listed in the "What's new" section for OpenSSH do not correspond to reality. Please find attached a patch to correct the version numbers for OpenSSH in that section. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Index: en/whats-new.dbk === --- en/whats-new.dbk(revision 11431) +++ en/whats-new.dbk(working copy) @@ -333,8 +333,8 @@ OpenSSHOpenSSH - 6.3p1 6.7p1 + 7.4p1 PerlPerl
Bug#860817: kedpm: Information leak via the command history file
Source: kedpm Version: 1.0 Severity: grave Tags: upstream security Justification: user security hole Hello, I've discovered an information leak that can give some hints about what ppl search and read in the password manager. kedpm is creating a history file in ~/.kedpm/history that is written in clear text. All of the commands that are done in the password manager are writted there. This also means that if someone uses the "password" command with the password as an argument to change the database's master password, the new password gets leaked in plaintext to that file! The issue was already reported upstream[0]. However, the upstream project seems to be unmoving since a couple of years already. [0]: https://sourceforge.net/p/kedpm/bugs/6/ I've discovered the bug in wheezy, so in 0.5.0 but the same problem applies to later releases. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#847991: initramfs-tools: upgrade to stretch in kvm image fails when trying to copy 70-persistent-net.rules
Package: initramfs-tools Version: 0.120+deb8u2 Severity: important Hi there, I've tried upgrading a VM from jessie to stretch and I'm having an issue with initramfs-tools. The upgrade is from 0.120+deb8u2 to 0.125. The system is a KVM image of debian jessie (vanilla debian install with only mysql-server installed on top) During the upgrade I got the following error message: update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.120+deb8u2) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 cp: omitting directory ‘/etc/udev/rules.d/70-persistent-net.rules’ E: /usr/share/initramfs-tools/hooks/udev failed with return 1. update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 1. dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) after that, I've tried running apt -f install and got: Processing triggers for initramfs-tools (0.120+deb8u2) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 cp: cannot stat ‘/etc/modprobe.d/*’: No such file or directory cp: omitting directory ‘/etc/udev/rules.d/70-persistent-net.rules’ E: /usr/share/initramfs-tools/hooks/udev failed with return 1. update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 1. dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for libc-bin (2.24-7) ... Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) which seems to be blocking on the same error, just with one more warning. FWIW, 70-persistent-net.rules is a directory but is emtpy. I've set priority to "important" since it seems to be blocking upgrade, but I don't know if this applies to more architectures. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 16M Dec 12 21:01 /boot/initrd.img-3.16.0-4-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/jessie--vg-root ro debian-installer=en_US quiet -- resume RESUME=/dev/mapper/jessie--vg-swap_1 -- /proc/filesystems ext3 ext2 ext4 -- lsmod Module Size Used by nfsv3 37551 1 nfsd 262938 2 auth_rpcgss51209 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl12511 2 nfsd,nfsv3 nfs 192232 4 nfsv3 lockd 83389 3 nfs,nfsd,nfsv3 fscache45542 1 nfs sunrpc237364 24 nfs,nfsd,auth_rpcgss,lockd,nfsv3,nfs_acl crc32_pclmul 12915 0 ppdev 16782 0 aesni_intel 151423 0 aes_x86_64 16719 1 aesni_intel lrw12757 1 aesni_intel gf128mul 12970 1 lrw glue_helper12695 1 aesni_intel ablk_helper12572 1 aesni_intel cryptd 14516 2 aesni_intel,ablk_helper evdev 17445 3 pcspkr 12595 0 serio_raw 12849 0 virtio_balloon 13047 0 ttm77862 0 parport_pc 26300 0 drm_kms_helper 49210 0 parport35749 2 ppdev,parport_pc drm 249998 2 ttm,drm_kms_helper i2c_piix4 20864 0 i2c_core 46012 3 drm,i2c_piix4,drm_kms_helper processor 28221 0 thermal_sys27642 1 processor button 12944 0 autofs435529 2 ext4 477942 2 crc16 12343 1 ext4 mbcache17171 1 ext4 jbd2 82514 1 ext4 dm_mod 89405 6 ata_generic12490 0 virtio_blk 17345 3 virtio_net 26553 0 crct10dif_pclmul 13387 0 crct10dif_common 12356 1 crct10dif_pclmul crc32c_intel 21809 0 psmouse99249 0 ata_piix 33592 0 floppy 65068 0 uhci_hcd 43499 0 ehci_hcd 69837 0 virtio_pci 17389 0 virtio_ring17513 4 virtio_blk,virtio_net,virtio_pci,virtio_balloon virtio 13058 4 virtio_blk,virtio_net,virtio_pci,virtio_balloon usbcore 195468 2 uhci_hcd,ehci_hcd usb_common 12440 1 usbcore libata177508 2 ata_generic,ata_piix scsi_mod 191405 1 libata -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initr
Bug#847992: mysql-server-core-5.6 upgrade to stretch fails with file conflict on innochecksum.1.gz
Package: mysql-server Version: 5.5.53-0+deb8u1 Severity: important Hello, I'm trying to upgrade from jessie to stretch and I'm getting blocked on the mysql upgrade from 5.5 to 5.6 During the upgrade I get this error message: dpkg: mysql-client-5.5: dependency problems, but removing anyway as you requested: mysql-server-5.5 depends on mysql-client-5.5 (>= 5.5.53-0+deb8u1). (Reading database ... 50345 files and directories currently installed.) Removing mysql-client-5.5 (5.5.53-0+deb8u1) ... Selecting previously unselected package mysql-client-core-5.6. (Reading database ... 50290 files and directories currently installed.) Preparing to unpack .../0-mysql-client-core-5.6_5.6.30-1_amd64.deb ... Unpacking mysql-client-core-5.6 (5.6.30-1) ... Selecting previously unselected package mysql-client-5.6. Preparing to unpack .../1-mysql-client-5.6_5.6.30-1_amd64.deb ... Unpacking mysql-client-5.6 (5.6.30-1) ... dpkg: mysql-server-core-5.5: dependency problems, but removing anyway as you requested: mysql-server-5.5 depends on mysql-server-core-5.5 (>= 5.5.53-0+deb8u1); however: Package mysql-server-core-5.5 is to be removed. (Reading database ... 50351 files and directories currently installed.) Removing mysql-server-core-5.5 (5.5.53-0+deb8u1) ... Selecting previously unselected package mysql-server-core-5.6. (Reading database ... 50262 files and directories currently installed.) Preparing to unpack .../mysql-server-core-5.6_5.6.30-1_amd64.deb ... Unpacking mysql-server-core-5.6 (5.6.30-1) ... dpkg: error processing archive /var/cache/apt/archives/mysql-server-core-5.6_5.6.30-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/innochecksum.1.gz', which is also in package mysql-server-5.5 5.5.53-0+deb8u1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/mysql-server-core-5.6_5.6.30-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Because of the previous error messages, there seems to be either a dependency/breaks issue or something that's not happening right during removal of mysql-server-core-5.5 A workaround is to apt remove mysql-server-5.5, then apt install mysql-server-5.6 I've set this to priority Important since the upgrade path from jessie to stretch is broken because of this. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mysql-server depends on: ii mysql-server-5.5 5.5.53-0+deb8u1 mysql-server recommends no packages. mysql-server suggests no packages. -- no debconf information
Bug#848492: broken tomcat6 package on wheezy
I am experiencing the same thing here. downgrading to deb7u3 does bring the service back online. I'm also seeing the same log messages than what's described in the mailing list discussion pointed out by brainpower. signature.asc Description: OpenPGP digital signature
Bug#845278: libxtables12: can't be installed
Hello, I've just exerienced the same during an upgrade of sid packages. The only way to break out of this mess is to force the upgrade of the package with: dpkg --force-overwrite -i /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb then it becomes possible to continue with the rest of the upgrade. libxtables12 seems like it should have a "breaks: libxtables11", or replaces: (I'm not sure if the latter is actually appropriate in this situation) signature.asc Description: OpenPGP digital signature
Bug#845278: libxtables12: can't be installed
Gabriel Filion: > I've just exerienced the same during an upgrade of sid packages. > > The only way to break out of this mess is to force the upgrade of the > package with: > > dpkg --force-overwrite -i > /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb > > then it becomes possible to continue with the rest of the upgrade. > > libxtables12 seems like it should have a "breaks: libxtables11", or > replaces: (I'm not sure if the latter is actually appropriate in this > situation) Seems like this is not the only thing missing. nftables is still depending on libxtables11. if I try to apt remove libxtables11 after running the dpkg command above, I get: The following packages will be REMOVED: libxtables11 nftables so the upgrade to libxtables12 would be breaking nftables with the correct dependency to break libxtables11 signature.asc Description: OpenPGP digital signature
Bug#836266: dirmngr: Please disable "use-tor" by default.
Hi there, For what it's worth I've been experiencing the same issue up to now: impossible to search or get keys with "use-tor" enabled, which was forced into the config file seemingly by parcimonie. However it's just been resolved by an upgrade of gnupg/dirmngr to the latest version in sid, 2.1.16-2. I believe the fix to use-tor issues was added in 2.1.15-9 by using adns for better DNS resolution. signature.asc Description: OpenPGP digital signature
Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
Hello, intrigeri: > Gabriel Filion: > >> […] and found out that xserver-xorg-core version 1.18.3-2 was >> introducing this issue. Downgrading to 1.18.3-1 makes the visual flashes and >> hard crashes go away. > > /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz reads: > > xorg-server (2:1.18.3-2) unstable; urgency=medium > > X now defaults to using built-in modesetting video driver on Intel > hardware which is "4th gen GMA" and newer, so roughly speaking on hardware > from 2007 and up. If this triggers new bugs on your hw, please file them > against the xserver. > > Continuing to use the -intel driver is possible by dropping the template > xorg.conf to /etc/X11: > > # cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11 > > -- Timo Aaltonen Tue, 19 Jul 2016 04:28:05 +0300 > > So perhaps the modesetting video driver breaks things on your system. > Can you please try switching back to the -intel driver with 2:1.18.3-2 > or newer? I'm sorry for this big delay, but I've finally taken the time to test this out. I can confirm that the visual glitches and crashes are still present in the latest version of the package, 2:1.19.0-2. Also, when using the above-mentioned technique for forcing the driver to "intel" (I've confirmed that it loaded by looking at ~/.local/share/xorg/Xorg.log.0), I don't see visual flashes anymore. signature.asc Description: OpenPGP digital signature
Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
intrigeri: >> Also, when using the above-mentioned technique for forcing the driver to >> "intel" (I've confirmed that it loaded by looking at >> ~/.local/share/xorg/Xorg.log.0), I don't see visual flashes anymore. > … and no crashes either? right, no crashes either. I've been running with newest package and intel driver since I wrote my last email and there weren't any crashes. signature.asc Description: OpenPGP digital signature
Bug#838533: [vagrant] vagrant cannot connect via ssh to the virtual machine
Hi there, I'm still experiencing this issue with a centos 7 box. I believe the fix was released in upstream version 1.9.0. bumping code version in package would probably fix this. signature.asc Description: OpenPGP digital signature
Bug#836984: parcimonie unable to call "gpg2" since sid switch to using gpg2 as main "gpg" command
Package: parcimonie Version: 0.10.2-1 Severity: grave Justification: renders package unusable Hi there, Ever since gnupg 2.1 was set to be the main "gpg" command in sid, parcimonie has been unable to do its bidding. >From the process list, we can see the following: gabster 6219 0.1 1.2 129352 48700 pts/1S+ 15:07 0:00 \_ /usr/bin/perl /usr/bin/parcimonie --with-dbus gabster 6220 0.0 0.0 0 0 pts/1Z+ 15:07 0:00 \_ [gpg] and it just hangs there. If I call the command manually I get the following output: $ /usr/bin/parcimonie --with-dbus gpgconf: warning: can not open list file /home/gabster/.gnupg/dirmngr_ldapservers.conf: No such file or directory dirmngr:Key Acquirer:/usr/bin/dirmngr:1:1: Can't exec "gpg2": No such file or directory at /usr/share/perl5/GnuPG/Interface.pm line 301. exec() error: No such file or directory at /usr/share/perl5/GnuPG/Interface.pm line 301. No public key was found. at /usr/share/perl5/App/Parcimonie/Daemon.pm line 420. So apparently it's trying to call a gpg2 binary which doesn't exist anymore: $ find /usr/bin/ -name gpg\* /usr/bin/gpgconf /usr/bin/gpgsplit /usr/bin/gpgsm /usr/bin/gpg /usr/bin/gpg-connect-agent /usr/bin/gpg-agent /usr/bin/gpgparsemail /usr/bin/gpg-zip /usr/bin/gpgv /usr/bin/gpg1 So I guess we either need to call "gpg" directly or somehow get the "gpg2" alias to come back. Or maybe there's an even better solution that I'm not thinking about since I don't know much about the code base and used libraries. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages parcimonie depends on: ii libclone-perl0.38-2 ii libconfig-general-perl 2.63-1 ii libfile-homedir-perl 1.00-1 ii libfile-which-perl 1.21-1 ii libgnupg-interface-perl 0.52-3 ii libipc-system-simple-perl1.25-3 ii liblist-moreutils-perl 0.416-1 ii libmoo-perl 2.002004-1 ii libmoox-late-perl0.015-2 ii libmoox-options-perl 4.022-2 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.094-1 ii libtime-duration-parse-perl 0.13-1 ii libtry-tiny-perl 0.27-1 ii libtype-tiny-perl1.05-1 ii libtypes-path-tiny-perl 0.005-1 ii perl 5.22.2-4 ii torsocks 2.1.0-2 Versions of packages parcimonie recommends: ii gnupg-curl 1.4.20-6 ii libglib-perl3:1.321-1 ii libgtk3-perl0.028-1 ii liblocale-gettext-perl 1.07-3 ii libnet-dbus-glib-perl 0.33.0-2 ii libnet-dbus-perl1.1.0-4 ii libpango-perl 1.227-1 ii libtime-duration-perl 1.20-1 ii tor 0.2.8.7-1 parcimonie suggests no packages. -- no debconf information
Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
Package: xserver-xorg-core Version: 2:1.18.4-2 Severity: important Hi there, I've been having weird crashes that happen only when I interact with my keyboard. It also happens with a keyboard plugged in to USB port. I didn't know where exactly to look, so I "bisected" packages with the help of snapshot.debian.org and found out that xserver-xorg-core version 1.18.3-2 was introducing this issue. Downgrading to 1.18.3-1 makes the visual flashes and hard crashes go away. I'm still seeing those crashes in 1.18.4-2 What happens is when I type on the keyboard, at some random point X crashes (happens always exactly when I type a letter on the keyboard - if I let the computer open without touching it, it doesn't crash). Crash in this case means the screen goes black, sometimes there's a 1 pixel-wide vertical line on the left where color zizags randomly. The black screen and left vertical column stay there for about 10 seconds before the computer shuts down by itself. I have seen because of ssh connections that the last letter I typed which caused the crash usually makes it through to the ssh connection, but nothing after that goes through. Also, before the crash happens, I saw that with gnome-terminal, if I switch window or tab and start typing in the new window, I'll see a visual flash like a quick blackout. If I repeat those flashes a number of time I end up reproducing the crash. Unfortunately, nothing in syslog or X.log ever shows up after a crash. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 28 2013 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Sep 6 09:09 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 20160803 (Debian 5.4.1-1) ) #1 SMP Debian 4.7.2-1 (2016-08-28) Xorg X server log files on system: -- -rw-r--r-- 1 rootroot21530 Sep 15 2015 /var/log/Xorg.2.log -rw-r--r-- 1 rootroot23021 Oct 28 2015 /var/log/Xorg.0.log -rw-r--r-- 1 rootroot22171 Oct 28 2015 /var/log/Xorg.1.log -rw-r--r-- 1 gabster gabster 29264 Sep 11 13:38 /home/gabster/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/gabster/.local/share/xorg/Xorg.0.log): [35.253] (--) Log file renamed from "/home/gabster/.local/share/xorg/Xorg.pid-2040.log" to "/home/gabster/.local/share/xorg/Xorg.0.log" [35.254] X.Org X Server 1.18.4 Release Date: 2016-07-19 [35.254] X Protocol Version 11, Revision 0 [35.254] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [35.254] Current Operating System: Linux boohn 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) x86_64 [35.254] Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64 root=UUID=c638294f-3066-4dfc-85ae-6601096a4134 ro quiet [35.254] Build Date: 06 September 2016 01:32:44PM [35.254] xorg-server 2:1.18.4-2 (https://www.debian.org/support) [35.254] Current version of pixman: 0.33.6 [35.254]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [35.254] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [35.254] (==) Log file: "/home/gabster/.local/share/xorg/Xorg.0.log", Time: Sun Sep 11 13:38:44 2016 [35.255] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [35.257] (==) No Layout section. Using the first Screen section. [35.257] (==) No screen section available. Using defaults. [35.257] (**) |-->Screen "Default Screen Section" (0) [35.257] (**) | |-->Monitor "" [35.258] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [35.258] (==) Automatically adding devices [35.258] (==) Automatically enabling devices [35.258] (==) Automatically adding GPU devices [35.258] (==) Max clients allowed: 256, resource mask: 0x1f [35.258] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [35.258]Entry deleted from font path. [35.258] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi,
Bug#778695: wheezy -> jessie: no gdm3 prompt, dependency loops and broken initrd
Hello, I've worked a little bit on this in the same setup as Anarcat used, here at koumbit. I've figured out why the users were not listed in gdm3. It was a line in /etc/pam.d/common-session that was missing: session optionalpam_systemd.so with this line users are listed. This problem was caused by our puppetmaster crushing the file's contents, so it's not an issue with the upgrade process itself. I've also had issues with dependencies during dist-upgrade but I don't have good info to show here and I think the issues were with different packages. I'll try to get more info on this on the next upgrade. However I couldn't reproduce the initrd issue. The desktop rebooted in the new kernel as expected after both short and full upgrades. Maybe the difference was that I did not reboot between short and full upgrades and rebooted only once at the end of the whole process. Cheers signature.asc Description: OpenPGP digital signature
Bug#1076760: libsequoia-octopus-librnp: version 1.8.1-4 does not work with thunderbird 115.13.0
Package: libsequoia-octopus-librnp Version: 1.8.1-4 Severity: important Hello, I run sid and yesterday I did a run of upgrades. Before the upgrades I was using thunderbird 115.12.0 and things were working great. However during the upgrade run, thunderbird was upgraded to 115.13.0 and now thunderbird won't find my private key or any of the public keys in my keyring. So this package has become completely unusable in sid and presumably also testing. A colleague told me that they were having the exact same issues with the same combination of versions, and also that once they compiled 1.9.0 and started using it, things started working again. Could I ask you to send version 1.9.0 to the debian archive in the hopes that it will start working again? Thanks in advance! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsequoia-octopus-librnp depends on: ii libbz2-1.0 1.0.8-5.1 ii libc6 2.39-4 ii libgcc-s1 14.1.0-5 ii libgmp102:6.3.0+dfsg-2+b1 ii libhogweed6t64 3.10-1 ii libnettle8t64 3.10-1 ii libsqlite3-03.46.0-1 ii libssl3t64 3.2.2-1 Versions of packages libsequoia-octopus-librnp recommends: ii zenity 4.0.2-1 Versions of packages libsequoia-octopus-librnp suggests: ii thunderbird 1:115.13.0-1 -- no debconf information
Bug#1077987: undertime: example config file not shipped by debian package
Package: undertime Version: 4.0.0 Severity: wishlist Hello, Thanks for maintaining undertime in debian (and maintaining it upstream too :) ) The manpage for undertime(1) mentions toward the end of the document that there should be an example configuration file in /usr/share/doc/undertime/examples/undertime.yml However, I don't see this file in that directory. It's probably just an oversight that's easy to fix. Also, there's a config file in /etc/undertime.yml so it's rather a minor issue that the example file is not present since we can always take the system-wide file as an example.. Cheers! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages undertime depends on: ii python3 [python3-supported-min] 3.12.4-1 ii python3-dateparser 1.2.0-3 ii python3-ephem4.1.5-1+b2 ii python3-importlib-metadata 8.2.0-1 ii python3-tabulate 0.9.0-1 ii python3-termcolor2.4.0-1 ii python3-tz 2024.1-2 ii python3-tzlocal 5.2-1.1 ii python3-yaml 6.0.1-2+b1 undertime recommends no packages. Versions of packages undertime suggests: pn tzdata-legacy -- no debconf information
Bug#1077990: reportbug: text ui: when sending report by SMTP, if password was mistyped, can't enter a new one
Package: reportbug
Version: 13.0.1
Severity: normal
Hello,
When using the text UI, when it comes time to send via SMTP and I need to
connect to an MTA in order to send the email as an authenticated user, if I
happen to mistype the password I get an error back from the server about the
failed login.
However, in that situation it's not possible to tell reportbug to prompt me
again for a new password. The only options I have is to resend with the same
credentials without asking, save and quit or abort entirely. So
currently, the
only way to fix my typo for the password is to save the report and then
relaunch again.
It would be nice in this situation to have another option that says
"send again
with new credentials" or something along those lines.
what I see currently:
Submit this report on undertime (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|?]? y
Connecting to mail.lelutin.ca via SMTP...
Enter SMTP password for gabs...@lelutin.ca@mail.lelutin.ca: SMTP send
failure: {'sub...@bugs.debian.org': (554, b'5.7.1 :
Helo command rejected: Access denied'), 'gabs...@lelutin.ca': (554, b'5.7.1
: Helo command rejected: Access denied')}. You can
retry, or save the report and exit. Do you want to retry [Y|n|q|?]? ?
Y - (default) Yes, please retry.
n - No, save and exit.
q - Quit.
? - Display this help.
What I think the menu should look like to give users the option to fix their
mistake (the new line can all be redifined to something that works
better. this
is just an example to better illustrate what I mean):
Y - (default) Yes, please retry.
p - Yes, please retry, but prompt again for the password.
n - No, save and exit.
q - Quit.
? - Display this help.
Cheers!
-- Package-specific info:
** Environment settings:
DEBEMAIL="gabs...@lelutin.ca"
DEBFULLNAME="Gabriel Filion"
INTERFACE="text"
** /home/gabster/.reportbugrc:
reportbug_version "6.4.3"
mode standard
ui text
realname "Gabriel Filion"
email "gabs...@lelutin.ca"
smtphost mail.lelutin.ca:587
smtpuser gabs...@lelutin.ca
smtptls
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_CA.utf8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reportbug depends on:
ii apt2.9.7
ii python33.12.4-1
ii python3-reportbug 13.0.1
ii sensible-utils 0.0.24
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
ii debconf 1.5.87
pn debsums
pn dlocate
pn emacs-bin-common
ii file1:5.45-3
ii gnupg 2.2.43-8
ii postfix [mail-transport-agent] 3.9.0-3
ii python3-urwid 2.6.15-1
pn reportbug-gtk
ii xdg-utils 1.1.3-4.1
Versions of packages python3-reportbug depends on:
ii apt2.9.7
ii file 1:5.45-3
ii python33.12.4-1
ii python3-apt2.9.0+b1
ii python3-debian 0.1.49
ii python3-debianbts 4.1.1
ii python3-requests 2.32.3+dfsg-1
ii sensible-utils 0.0.24
python3-reportbug suggests no packages.
-- no debconf information
Bug#942285: smokeping: buster fresh install Master-Slave not working
Hello, I believe that this issue concerns a nowadays old release of debian, and also from what I found there was an item in the NEWS file for version 2.3.5-1 that explained the changes required in the config with regards to the new config split, specifically it was mentioning to make sure to migrate over the 'precreateperms' option to accompany the 'dyndir' option. So I think there is nothing to be done at packaging level, unless we can reproduce on a more recent release. Cheers!
Bug#743666: smokeping: slave connecting to an https server : certificate verify failed
Hello xavier, I'm working on doing a bit of cleanup in the bug reports for smokeping and yours has not been addressed for the last 10 years, which is sad. Do you still use smokeping on debian? and if so, are you still experiencing the same issue? If you're still having the issue, could you give a bit more information about the certificate used on the "master" server? was it self-signed or a certificate issued by one of the vendors in the SSL cert cartel, or maybe by Let's Encrypt? Also, do you have special configuration in smokeping to use ssl between the hosts? I'm rather unfamiliar with this setup and from what I can find in a quick search, there aren't very concrete examples for how to set that up, so it's hard for me to try and reproduce your bug. Cheers!
Bug#1050122: smokeping: CGI script hogs CPU and OOMs on fping graphs with pings=2000
Hello Marcin, I've tried to reproduce this behavior in the current testing version of smokeping and I wasn't able to do it. with the following contents for config.d/Probes, and all other files with defaults from the package (so just one target for localhost that uses the fping probe) plus the file /var/lib/smokeping/Local/LocalMachine.rrd deleted before restarting smokeping, I would see the process "smokeping [FPing]" get started but the rrd file was not being recreated. and so I just couldn't get any graph produced. as soon as I commented out the two lines, the rrd file was created and an empty graph was now being generated. Do you mind to share you configuration here, specifically for Probes and maybe General ? The way I tried it in Probes: *** Probes *** + FPing binary = /usr/bin/fping pings = 2000 step = 2100
Bug#1068248: ruff: New upstream release
Hello, Upstream has produced more releases and is now at 0.4.8 on pypi In addition to The changes mentioned by Michael, the newer versions also have some additional CLI options that enable features that some users may need. For exemple "ruff format --diff" is currently used by coc-pyright for triggering code formatting, but the option "--diff" does not exist in version 0.0.291 Cheers!
Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged
Hi Alexey, On 2022-09-17 15 h 44, Alexey Vazhnov wrote: I've tested Smokeping 2.8.2 in `Devuan GNU/Linux 5 (daedalus/ceres)` (based on Debian testing 12 bookworm), it works without errors. How to: I created a .deb package in `Debian GNU/Linux 11 (bullseye)` by commands like these: ``` sudo apt-get -V --no-install-recommends install devscripts git-buildpackage equivs gbp clone 'https://salsa.debian.org/debian/smokeping.git' cd ./smokeping mk-build-deps --install --root-cmd sudo --remove git status # Remove new untracked files: rm smokeping-build-deps_2.8.2-1_amd64.buildinfo smokeping-build-deps_2.8.2-1_amd64.changes gbp buildpackage ``` > > No `libobject-result-perl` installed, but Smokeping works! Very nice, thanks for the test! also TIL mk-build-deps :) and installed `smokeping_2.8.2-1_all.deb` together with Nginx, I took configuration from https://gitlab.com/vazhnov/smokeping_nginx ah, we don't have an example configuration for nginx in the package, which is a shame. maybe we should add one from there if it works directly with debian? the best.conf file looks like a good example candidate. what do you think?
Bug#1000209: Not able to build the package: multiple patches fail to apply
Hi, I've just taken a look at this issue together with someone else during the Montreal BSP and we think that the init script is possibly the source of the problem: the stop action fails if it is called when the service is not running, which is the case when you install the package on a new system. the init script should rather exit cleanly if start-stop-daemon --stop reports that it failed because the daemon is not running, e.g. ignore exit code 1 from start-stop-daemon. however, when we tried to apply a modification to the init script, we tried to build the package to verify that our solution works but we were unable to even build it. there are multiple patches in debian/patches/ that currently do not apply cleanly. e.g. $ dpkg-buildpackage dpkg-buildpackage: info: source package timidity dpkg-buildpackage: info: source version 2.14.0-9 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Bastien Roucariès dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 0001-don-t-url_unexpand_home_dir-when-opening-a-file.patch dpkg-source: info: applying 0002-improve-error-message.patch patching file timidity/timidity.c Reversed (or previously applied) patch detected! Skipping patch. 1 out of 1 hunk ignored dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch '0002-improve-error-message.patch' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: info: if the file is present in the unpacked source, make sure it is also present in the orig tarball dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/0002-improve-error-message.patch/ --reject-file=- < timidity/debian/patches/0002-improve-error-message.patch subprocess returned exit status 1 dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 2
Bug#1028398: snapd: both Telegram-desktop and Skype cannot load and save files
Hi there, This could be happening for many reasons. Just to investigate one possiblity: in your syslog do you see messages from apparmor when you try to load a file?
Bug#1028743: python-bottle: FTBFS: AssertionError: b'OK' != "URLError(ConnectionRefusedError(111, 'Connection refused'))"
Hello! Just wanted to chime in to confirm that James' patch does make the package compile.
Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged
Hi Micheal, On 2022-09-13 01 h 50, Michael Prokop wrote: * Gabriel Filion [Mon Jan 24, 2022 at 10:53:27AM -0500]: Upstream has released a new version of smokeping, 2.8.2 and it would be helpful to upgrade the debian package to this version since it contains a number of fixes, some of which would remove patches in the package. I've received two emails directly requesting the new version so I'm creating this bug report to reflect their wish to have this version. Friendly ping, that v2.8.2 was released on 2021-08-13 and the freeze for Debian/bookworm is coming closer. :) Would be great to have the new smokeping version in the upcoming Debian stable release. Thanks for maintaining smokeping! thanks for the ping! I've been concentrated on another project recently but you're totally right, I should make the last efforts required to get that version into testing soon! The current state of things is that the new lib dependency to version 2.8.2, libobject-result-perl, is created and I've received some feedback from the perl team: https://lists.debian.org/debian-perl/2022/09/msg5.html I should fix the license text and maybe open a bug report upstream for the typo. In the mean time, I'm wondering if you're willing to help out a bit with reviewing my work on smokeping, that way we could move faster once the perl lib is in unstable. Upstream version 2.8.2 was merged onto the "master" branch. IIRC it's currently awaiting the dependency and then should be ready for review/sponsorship (but there might still be lintian issues that I haven't looked at because of the new library) https://salsa.debian.org/debian/smokeping cheers!
Bug#1079396: ganeti: Man pages are symlinked out of /usr/share/man/ which breaks debiman
Package: ganeti Version: 3.0.2-3 Severity: wishlist Hello! I've recently tried to read the ganeti man pages on manpages.debian.org but found out that all of the man pages give out a 404 error there. According to https://github.com/Debian/debiman/issues/177 this problem happens in debiman specifically for the ganeti package because the files inside /usr/share/man/man[1-9]/ are symlinks to other files. The links end up following a pretty convoluted strings of symlinks through /etc/ganeti and back to /usr/share/ganeti/$version/, which are in the ganeti-$version package. If I understand the situation correctly, the manpages are organized this way so that it's possible to have documentation for multiple versions of ganeti installed simultaneously, especially during version upgrades. I wonder if there could be a way to organize things in a way that would better accomodate debiman? It seems that the crux of the issue is that the symlinks pass through /etc/ganeti/share which is not apart of the ganeti-$version pacakge. I don't know if this is an interesting technique for this specific package, but I took a quick peek at how php achieves having different versions of man pages and from what I can see, they use the alternatives system for this, so for example /usr/share/man/man1/php.1.gz is a symlink to /etc/alternatives/php.1.gz and in turn that links to the current version of the file. Could that be a useful trick for ganeti? Cheers! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.10.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ganeti depends on: ii adduser3.137 pn ganeti-3.0 pn ganeti-haskell-3.0 pn ganeti-htools-3.0 ii init-system-helpers1.66 ii python33.12.5-1 ii sysvinit-utils [lsb-base] 3.10-1 Versions of packages ganeti recommends: pn drbd-utils | drbd8-utils ii fdisk2.40.2-6 pn ganeti-instance-debootstrap pn ndisc6 ii qemu-system-x86 [qemu-kvm] 1:9.0.2+ds-4 Versions of packages ganeti suggests: pn blktap-dkms pn ganeti-doc pn molly-guard
Bug#1064686: vagrant-librarian-puppet: FTBFS
The build issue was fixed with the tag 0.9.2-3 but the changelog did not mark this issues as being closed by the correction. Closing the issue now
Bug#1078426: bts: fails to send email with SMTP connection is already in SSL mode
Package: devscripts Version: 2.23.7 Severity: normal Hello, I've been trying to send update a bug report with bts but right after I supply my email password, bts crashes with the following error: SMTP connection is already in SSL mode at /usr/share/perl/5.38/Net/SMTP.pm line 621, line 2. note: additionally to BTS_SMTP_HOST (as seen below), I've also set BTS_STMP_USER. strangely, from what I can see from the bts script's code, it should be matching the "sstmp://" part of the variable and automatically set port to 465 and SSL=1 in the instantiation of the smtp client, so things should be doing what I expect. but the error message seems to come from calling the starttls method afterwards also, the mail server is not advertising starttls on port 465 after the client helo is received. so I don't understand what would trigger the library to call the starttls method. -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- BTS_SMTP_HOST=ssmtp://mail.lelutin.ca -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.22.11 ii file 1:5.45-3 ii gnupg 2.2.43-8 ii gpgv 2.2.43-8 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl0.12-2 ii libfile-which-perl1.27-2 ii libipc-run-perl 20231003.0-2 ii libmoo-perl 2.005005-1 ii libwww-perl 6.77-1 ii patchutils0.4.2-1 ii perl 5.38.2-5 ii python3 3.12.4-1 ii sensible-utils0.0.24 ii wdiff 1.2.2-6 Versions of packages devscripts recommends: ii apt 2.9.7 ii curl8.9.1-1 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2024.06.24 ii dput1.2.2 ii equivs 2.3.1 ii libdistro-info-perl 1.7 ii libdpkg-perl1.22.11 ii libencode-locale-perl 1.05-3 ii libgit-wrapper-perl 0.048-2 ii libgitlab-api-v4-perl 0.27-1 ii libjson-perl4.1-1 ii liblist-compare-perl0.55-2 ii liblwp-protocol-https-perl 6.14-1 ii libsoap-lite-perl 1.27-3 ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl0.31-2 ii liburi-perl 5.28-1 ii licensecheck3.3.9-1 ii lintian 2.118.0 ii man-db 2.12.1-3 ii patch 2.7.6-7 ii pristine-tar1.50+nmu2 ii python3-apt 2.9.0+b1 ii python3-debian 0.1.49 ii python3-magic 2:0.4.27-3 ii python3-requests2.32.3+dfsg-1 ii python3-unidiff 0.7.5-2 ii python3-xdg 0.28-2 ii strace 6.8-2 ii unzip 6.0-28 ii wget1.24.5-2+b1 ii xz-utils5.6.2-2 Versions of packages devscripts suggests: pn adequate pn at ii autopkgtest 5.38 pn bls-standalone pn bsd-mailx | mailx ii build-essential 12.10 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.16 pn diffoscope pn disorderfs pn dose-extra pn duck pn elpa-devscripts pn faketime pn gnuplot pn how-can-i-help ii libauthen-sasl-perl 2.1700-1 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-3 pn libterm-size-perl ii libtimedate-perl 2.3300-2 pn libyaml-syck-perl pn mmdebstrap ii mutt 2.2.13-1 ii openssh-client [ssh-client] 1:9.8p1-3 pn piuparts ii postgresql-client 16+261 ii postgresql-client-15 [postgresql-client] 15.4-3 ii postgresql-client-16 [postgresql-client] 16.3-1+b1 pn pristine-lfs
Bug#1078248: "sequoia-octopus: rnp_identifier_iterator_create: parameter "ctx" is null" with thunderbird 115.13.0-1
Hello, The upstream bug report was closed with a new release 1.10 Apparently there was already a fix committed upstream and now it's part of a new release. Could we bump the version (again) to 1.10.0 in the hope that this error gets fixed? Thanks!
Bug#1077990: reportbug: text ui: when sending report by SMTP, if password was mistyped, can't enter a new one
Hello Nis, On 2024-08-10 16:03, Nis Martensen wrote: Hi Gabriel, On 05.08.2024 17.00, Gabriel Filion wrote: When using the text UI, when it comes time to send via SMTP and I need to connect to an MTA in order to send the email as an authenticated user, if I happen to mistype the password I get an error back from the server about the failed login. However, in that situation it's not possible to tell reportbug to prompt me again for a new password. The only options I have is to resend with the same credentials without asking, save and quit or abort entirely. So currently, the only way to fix my typo for the password is to save the report and then relaunch again. If the reason is a mistyped password then reportbug should automatically ask for the password again on the next try. Reportbug tries to recognize this based on the error raised by smtplib. The code is here: https://sources.debian.org/src/reportbug/13.0.1/reportbug/submit.py/#L486 oh! ok good to know that authentication errors do trigger a new password prompt then! If reportbug does not ask for the password again, then the error raised by smtplib is not an SMTPAuthenticationError. It seems like in your example the problem was an SMTPHeloError. Can you please check if the real reason in your case was something else than a wrong password? gah indeed, the issue was with my setup / reportbug config. I ended up figuring out what was happening and I'm now able to send emails with reportbug. sorry for the noise. we can close this bug report
