Bug#934068: start-stop-daemon issuing warning about non-root pidfile
Package: postgrey Version: 1.36-5.1 After upgrading to Buster, I started getting the following error when issuing "/etc/init.d/postgrey reload" (I am using sysvinit): start-stop-daemon: matching only on non-root pidfile /var/run/postgrey.pid is insecure After a little searching, I found related/similar bugs 921016 and 921557. Based upon the resolution of those bugs, I've created the attached patch that applies the same logic to the postgrey init.d script to fix the error. -- Justin Pasher --- postgrey.org 2014-10-24 17:39:13.0 -0500 +++ postgrey 2019-08-06 11:59:19.688154906 -0500 @@ -94,7 +94,7 @@ # restarting (for example, when it is sent a SIGHUP), # then implement that here. # - start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE + start-stop-daemon --user $DAEMON_USER --stop --signal 1 --quiet --pidfile $PIDFILE return 0 }
Bug#933142: /etc/init.d/cryptdisks force-start no longer ignores noauto
Just a quick follow-up. I found bug #505779 from 2008 where the force-start option was specifically added to support starting disks with the noauto option. -- Justin Pasher
Bug#933142: /etc/init.d/cryptdisks force-start no longer ignores noauto
Package: cryptsetup
Version: 2:2.1.0-5
Upon upgrading from Stretch to Buster, I've noticed that the SysV init
script for starting LUKS encrypted partitions (/etc/init.d/cryptdisks)
can no longer be forced to start disks that have the "noauto" option
set, even when using the force-start command. I'm using sysvinit-core
and not systemd.
For example, /etc/crypttab has this:
encdata /dev/xvdb none luks,noearly,noauto
I'm purposely using the noauto option to keep the boot up process from
automatically trying to unlock the partition and waiting for a password.
In Stretch, if I manually run "/etc/init.d/cryptdisks force-start", it
would bypass the noauto option and (as the command implies) force
cryptsetup to attempt to unlock the partition. In Buster, when using the
force-start option, it won't attempt to unlock the partition if it has
the noauto option set.
I've looked at the two key files used by the init script
(/lib/cryptsetup/cryptdisks-functions and /lib/cryptsetup/functions),
and based upon what I can see, the FORCE_START option that's set by the
init script basically becomes useless with the way the logic is
currently defined. The only thing it seems to do is decide whether the
word "ignored" is displayed; it doesn't change the logic flow. The lines
in question are below (I included the logic for the noearly, since it
suffers the same problem):
--
if [ -n "${CRYPTTAB_OPTION_noearly+x}" ] && [ "$INITSTATE" = "early" ]; then
[ -z "${FORCE_START-}" ] || device_msg "ignored"
return 0
fi
if [ -n "${CRYPTTAB_OPTION_noauto+x}" ] && [ "$INITSTATE" != "manual" ];
then
[ -z "${FORCE_START-}" ] || device_msg "ignored"
return 0
fi
--
These are the only code blocks that reference FORCE_START, and as you
can see, all it does is change the displayed message. Unless I'm missing
something, how it decides to display the message seems backwards to me
too (it does "show this message when FORCE_START is set", versus "show
this message when the script is executed normally and we find noauto or
noearly").
When trying to understand how $INITSTATE is ever anything but "early" or
"remaining" (as set by the init scripts), I found the
/sbin/cryptdisks_start script. Running that script allows you to unlock
a specific encrypted partition, but not all (without some manual
scripting to read through /etc/crypttab).
Basically, I see two possible solutions:
* Running "/etc/init.d/cryptstart force-start" should ALWAYS try to
unlock a partition, even if it has noearly or noauto set (like it did in
Stretch).
* /sbin/cryptdisks_start must be used when trying to unlock partitions
that use noauto or noearly and I have to write a script to loop through
all encrypted partitions to pass as a parameter.
The first option seems most logical to me, as that's what "force-start"
means to me. That's the way it worked in Stretch (and maybe even
Jessie). Otherwise, what's the point of having force-start?
--
Justin Pasher
Bug#932379: apt-mirror doesn't grab *.xz i18n Translation files
Package: apt-mirror
Version: 0.5.4-1
As I'm testing Buster upgrades, I discovered that apt-mirror (which
doesn't change between Stretch and Buster) was not grabbing the i18n
Translation file for the buster-backports distro. A little investigation
showed that it's because the script is only programmed to grab the *.bz2
translation file references in the Release file. Since buster-backports
only includes *.xz translations (not sure if that's intentional or not),
they are never grabbed. A trivial patch that adds *.xz files to the list
and works for me is below:
--- apt-mirror 2019-07-18 09:59:07.904604283 -0500
+++ apt-mirror.new 2019-07-18 09:55:11.0 -0500
@@ -520,7 +520,7 @@
if ( @parts == 3 )
{
my ( $sha1, $size, $filename ) = @parts;
- if ( $filename =~
m{^$component/i18n/Translation-[^./]*\.bz2$} )
+ if ( $filename =~
m{^$component/i18n/Translation-[^./]*\.(bz2|xz)$} )
{
add_url_to_download( $dist_uri . $filename,
$size );
}
--
Justin Pasher
Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid
- Original Message - > From: Cyril Brulebois > Date: Friday, July 12, 2019 06:45:08 PM CDT > Subject: Re: Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid > To: Axel Beckert , 911604 <911...@bugs.debian.org> > CC: Gert , Dean Hamstead , Justin Pasher > Everyone: please deploy -8 (just uploaded) to your buster and/or unstable systems and report back. I've tested this on a stretch system that's running with systemd, using the daemon directly, or a hacked up init script to make sure I was evading the initscript→systemd machinery through LSB functions; and everything looks good with the patch. But I'd be very happy to have success reports from sysvinit users before considering backporting this to buster. Cheers, Hello, I use sysvinit. I've installed the 1.9.1-8 version of the package, and it seems to work properly for me. For reference, I did the following test: 1. Blank out /etc/apparmor.d/local/usr.sbin.haveged to remove my added line 2. /etc/init.d/haveged stop 3. aa-enforce /usr/sbin/haveged 4. /etc/init.d/haveged start -- It failed to start (as expected) 5. Update to haveged=1.9.1-8 6. Verify haveged has started (the post install scripts take care of apparmor and starting the process) 7. Verify /etc/apparmor.d/local/usr.sbin.haveged is still blank 8. Reboot and verify haveged still starts up properly Thanks for the quick turn around! Justin Pasher
Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid
The fix below worked for me too. However, this means the error is still present in the buster version of the haveged package. I think it's a little more important to get this fixed, as the Buster release notes explicitly suggest using haveged as a possible means of improving the RNG entropy on first boot to avoid unnecessary boot delays. Without it, people will install haveged and either not notice that it fails to start, wonder why it refuses to start, or wonder why they are still getting boot delays. It seems like a pretty trivial patch without any adverse side effects. Justin Pasher On Mon, 22 Oct 2018 16:01:51 +0200 Axel Beckert wrote: > Package: haveged > Version: 1.9.1-6 > Severity: important > Tags: patch > > Hi, > > haveged silently fails to start on one of my machines, seemingly due > to apparmor. From /var/log/syslog after unsucessfully trying to start > haveged: > > Oct 22 15:40:26 someone haveged: haveged starting up > Oct 22 15:40:26 someone kernel: [24678702.682596] audit: type=1400 audit(1540215626.982:65757): apparmor="DENIED" operation="mknod" profile="/usr/sbin/haveged" name="/run/haveged.pid" pid=7421 comm="haveged" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 > > What helped was adding the line > > /run/haveged.pid w, > > to /etc/apparmor.d/local/usr.sbin.haveged, so you should probably add > that line to /etc/apparmor.d/usr.sbin.haveged.
Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late
Package: sysvinit-utils Version: 2.93-8 I started testing the upgrade from Debian Stretch to Buster, and I've encountered a problem that affects the snmpd package's init.d script. It looks like it has been changed to utilize /lib/init/init-d-script for its core functionality. However, by doing so, the SNMPDOPTS value is ignored from the init config file at /etc/default/snmpd. This is because of the following lines in /etc/init.d/snmpd: == DEFAULT_SNMPDOPTS="-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf" [ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS == Because the /lib/init/init-d-script script sources /etc/init.d/snmpd BEFORE it sources /etc/default/snmpd, none of the values in /etc/default/snmpd are visible to /etc/init.d/snmpd. This results in SNMPDOPTS always being set to the default arguments. One could view this as a bug in either snmpd or sysvinit-utils, depending on your viewpoint. However, it seems more appropriate for a fix to be applied to /lib/init/init-d-script within sysvinit-utils, as other scripts may try (or even be trying already) to use this method within the init.d script to set defaults. The /etc/init.d/snmpd script could manually force an inclusion of /etc/defaults/snmpd, but it seems a little redundant when /lib/init/init-d-script is supposed to do that work. The line in question in /lib/init/init-d-script is below: == # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME == Moving it above the following block would ensure it's sourced first: == SCRIPTNAME="$__init_d_script_name" scriptbasename="$(basename "$__init_d_script_name")" if [ "$scriptbasename" != "init-d-script" ] ; then . "$__init_d_script_name" else exit 0 fi == I checked the latest experimental version (2.95) and it doesn't have any changes like this (although it does fix the snmpd package install bug as referenced in #926390). Without knowing all the ins and outs of how /lib/init/init-d-script is used throughout Debian, I can't say if this change would be considered safe or not. Perhaps there are instances where the /etc/default/* config file tries to do more than just set some shell variables and it would cause some bizarre side effects. Thanks. -- Justin Pasher
Bug#906992: Any update? Still present in 4.9.110-3+deb9u6
Any update to this bug? This is still occurring in the latest x86 PAE kernel (4.9.110-3+deb9u6). The previously linked LKML post seems to provide the fix (although I haven't tested). I too am running the OS in a virtual environment (XenServer), so I wonder if that's a factor. Justin Pasher
Bug#872158: logrotate config file overrides global options for other log files
Package: freeradius
Version: 3.0.12+dfsg-5+deb9u1
The logrotate config file that ships with freeradius sets global options
in its file (/etc/logrotate.d/freeradius). These options do not just
apply to the freeradius log files, but to all log files that logrotate
encounters after processing /etc/logrotate.d/freeradius (e.g. other logs
defined in /etc/logrotate.d with a filename that come later
alphabetically). You can verify this by making a modification tothe
global options in/etc/logrotate.d/freeradius(such as adding"maxsize
1k"), then running logrotate in debug mode:
logrotate -d /etc/logrotate.conf
If you look at the output, you'll notice that all logs files encountered
after the freeradius log files now have the"maxsize 1k" applied to them
even if they didn't define it themselves. The global options set within
/etc/logrotate.d/freeradius are not just global options for the log
files defined in that file; they are system wide. To avoid conflicting
with other log file definitions, the options need to be duplicated for
each log file. You could also just group together everything but
radius.log if you wanted to avoid a bunch of duplication.
/var/log/freeradius/radius.log {
daily
rotate 52
missingok
compress
delaycompress
notifempty
copytruncate
}
/var/log/freeradius/checkrad.log /var/log/freeradius/radwatch.log
/var/log/freeradius/radutmp /var/log/freeradius/radwtmp
/var/log/freeradius/sqllog.sql
/var/log/freeradius/radacct/*/detail {
daily
rotate 52
missingok
compress
delaycompress
notifempty
nocreate
}
--
Justin Pasher
Bug#792239: sessionclean does not support tiered session directory structure)
Still no update? Justin Pasher
Bug#813413: Upgrade from mysql-server-5.5 can break configurations that use the conf.d directory
It's understandablehow this could be desirable in different use cases. My concern is that this could catch quite a few people with an unexpected config change. In my case, the problem was very obvious, as remote connection no longer worked. However, it's possible that some people might be using it to override common MySQL settings on a per-server basis (such as settings related to memory usage, temp table sizes, buffer sizes, etc). In those cases, the server would probably continue running as if nothing was wrong, but they could experience a sudden performance hit when the daemon is suddenly not utilizing as much memory for caching and the like. Just to confirm, the implied behavior in MySQL 5.5 was that options set within conf.d/ would override the global defaults under /etc/mysql/my.cnf (since the conf.d/ directory was included at the end of my.cnf). Now the default behavior in MySQL 5.6 is that the global config file (now in /etc/mysql/mysql.conf.d/mysqld.cnf) overrides the settings withing conf.d/ files. This is the main gotcha that concerned me, since it wasn't something I was expecting. I didn't really see anything in the Debian changelog that would warn of this, aside from "Switch to new /etc/mysql/my.cnf management scheme" for 5.6.25-2. As far as a way to solve it for both needs, I'm not sure what would be the best way. It does seem like the upgrade from 5.5 to 5.6 would be the best time to hammer it out though, since someone will be consciously performing this upgrade. Maybe it's better to move any existing custom files under conf.d/ into the mysql.conf.d/ directory (is that even tracked)? They could be named in a way to ensure they are included after the other mysql*.cnf files. I'm not familiar with all of the upgrade paths people might be following (for me it was just a "routine" MySQL server upgrade), so I don't know how feasible this is. I would think at least at a minimum some sort of warning that this is happening so it wouldn't catch people completely off-guard. Thanks. Justin Pasher
Bug#813413: Upgrade from mysql-server-5.5 can break configurations that use the conf.d directory
Package: mysql-server-5.6 Version: 5.6.27-2 When upgrading from MySQL 5.5 to MySQL 5.6, the configuration structure in /etc/mysql was changed to support the alternatives system. This also resulted in moving the bulkof the default configuration options into /etc/mysql/mysql.conf.d/mysqld.cnf. The /etc/mysql/mysql.cnf file (a target file of the alternatives system) was replaced with a simple stub file that includes the subdirectories holding config files. - /etc/mysql/mysql.cnf - !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mysql.conf.d/ - /etc/mysql/mysql.cnf - The conf.d/ directory previously already existed in MySQL 5.5 as a way to apply config snippets to override the defaults under /etc/mysql/my.cnf. However, in MySQL 5.6, the order in which the directories are included makes any custom options that were defined in files located in /etc/mysql/conf.d/ get overridden by the default options under /etc/mysql/mysql.conf.d/. In my opinion, the directories should be reversed so that the conf.d/ directory is included last so it will properly override the defaults like before. Obviously, it's easy to fix this locally in my mysql.cnf file, but this ended up as a surprise on my home machine because I override the bind-address option in a file under conf.d/ to allow remote connections.
Bug#792239: sessionclean does not support tiered session directory structure
Any update on this issue? The change is very benign in the provided patch and it still works for the previous use cases. -- Justin Pasher
Bug#792239: sessionclean does not support tiered session directory structure
Package: php5
Version: 5.6.9+dfsg-0+deb8u1
The new session cleanup script in Jessie (/usr/lib/php5/sessionclean)
has a few limitations in it.
1. It does not support a tiered directory structure (e.g.
session.save_path=2;/var/lib/php5)
2. It does not support a symlinked session directory
3. (not a limitation, but parameter warning) The find command uses the
-ignore_readdir_race option after a non-option argument
I've attached a patch to fix all of these.
1. Adjust sed to remove the N; or N;MODE; prefix from session.save_path
2. Add a / to the end of $save_path to look inside the symlinked
directory. It should still work with regular directories.
3. Move the -ignore_readdir_race parameter
Changed lines:
14: save_path=$(echo $session_config | sed -ne
's/^session\.save_path=\(.*;\)\?\(.*\)$/\2/p')
29: find -O3 $save_path/ -depth -ignore_readdir_race -mindepth 1 -name
'sess_*' -type f -cmin +$gc_maxlifetime -delete
--- sessionclean.org2015-07-12 22:09:59.104104600 -0500
+++ sessionclean2015-07-12 20:56:30.909853124 -0500
@@ -11,7 +11,7 @@
# Get all session variables once so we don't need to start PHP to get
each config option
session_config=$(php5 -c /etc/php5/${conf_dir}/php.ini -d
error_reporting='~E_ALL' -r 'foreach(ini_get_all(session) as $k = $v) echo
$k=.$v[local_value].\n;')
save_handler=$(echo $session_config | sed -ne
's/^session\.save_handler=\(.*\)$/\1/p')
-save_path=$(echo $session_config | sed -ne
's/^session\.save_path=\(.*\)$/\1/p')
+save_path=$(echo $session_config | sed -ne
's/^session\.save_path=\(.*;\)\?\(.*\)$/\2/p')
gc_maxlifetime=$(($(echo $session_config | sed -ne
's/^session\.gc_maxlifetime=\(.*\)$/\1/p')/60))
if [ $save_handler = files -a -d $save_path ]; then
@@ -26,7 +26,7 @@
done
) | sort -rn -t: -k2,2 | sort -u -t: -k 1,1 | while IFS=: read -r save_path
gc_maxlifetime; do
# find all files older then maxlifetime and delete them
-find -O3 $save_path -depth -mindepth 1 -name 'sess_*'
-ignore_readdir_race -type f -cmin +$gc_maxlifetime -delete
+find -O3 $save_path/ -depth -ignore_readdir_race -mindepth 1 -name
'sess_*' -type f -cmin +$gc_maxlifetime -delete
done
exit 0
Bug#787394: Same problem with init.d script
I just experienced the same problem (basically) when I upgraded a box from Wheezy to Jessie. I opted to stay with sysvinit instead of systemd, and the problem is also present in the /etc/init.d/drbd script. On line 160 it makes this call: $DRBDADM adjust-with-progress all Changing the first parameter to adjust as suggested allows the DRBD devices to start up. There is also an issue when running /etc/init.d/drbd stop, although I'm not sure if it's related to me staying on the Wheezy 3.2.68 kernel or not (due to an older version of XenServer). When it calls the command $DRBDSETUP show all at line 205, it spits out this error: all: Failure: (127) Device minor not allocated It has to do with passing the all parameter to drbdadm show. If I replace the entire command with |$DRBDADM||sh-resources|, drop the sed, and change the $DRBDSETUP down command to use drbdadm, it works. for res in $($DRBDADM sh-resources); do $DRBDADM down $res done -- Justin Pasher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712800: svnserve SASL auth (LDAP) broken in Wheezy
Package: subversion Version: 1.6.17dfsg-4+deb7u3 After upgrading a server from Squeeze to Wheezy, the SASL authentication for svnserve using saslauthd and LDAP is no longer working. I've tried connecting with both a Squeeze (1.6.12dfsg-6) subversion client and a Wheezy (1.6.17dfsg-4+deb7u3) subversion client with the same results (it just prompts for the username/password over and over). For testing, I ran the saslauthd daemon in debug mode and used the testsaslauthd program to test it. This appears to authenticate (and deny) correctly. # testsaslauthd -u user1 -p password 0: OK Success. # testsaslauthd -u user1 -p badpassword 0: NO authentication failed saslauthd output: saslauthd[27403] :rel_accept_lock : released accept lock saslauthd[27403] :cache_get_rlock : attempting a read lock on slot: 95 saslauthd[27404] :get_accept_lock : acquired accept lock saslauthd[27403] :cache_lookup: [login=user1] [service=] [realm=imap]: not found, update pending saslauthd[27403] :cache_un_lock : attempting to release lock on slot: 95 saslauthd[27403] :cache_get_wlock : attempting a write lock on slot: 95 saslauthd[27403] :cache_commit: lookup committed saslauthd[27403] :cache_un_lock : attempting to release lock on slot: 95 saslauthd[27403] :do_auth : auth success: [user=user1] [service=imap] [realm=] [mech=ldap] saslauthd[27403] :do_request : response: OK saslauthd[27404] :rel_accept_lock : released accept lock saslauthd[27404] :cache_get_rlock : attempting a read lock on slot: 95 saslauthd[27404] :cache_lookup: [login=user1] [service=] [realm=imap]: found with invalid passwd, update pending saslauthd[27405] :get_accept_lock : acquired accept lock saslauthd[27404] :cache_un_lock : attempting to release lock on slot: 95 saslauthd[27404] :do_auth : auth failure: [user=user1] [service=imap] [realm=] [mech=ldap] [reason=Unknown] saslauthd[27404] :do_request : response: NO When I run the svnserve daemon in debug mode and test using the svn client, I don't get any additional information as to why it failed. I also don't see ANY additional output from saslauthd, so it seems like svnserve is not even trying to authenticate using saslauthd. Debug command (with no output): /usr/bin/svnserve -d -r /var/lib/svn --foreground I do see the following entries in /var/log/auth.log: Jun 19 10:48:04 server1 svnserve: DIGEST-MD5 common mech free Jun 19 10:48:41 server1 svnserve: DIGEST-MD5 common mech free It's almost like it's not allowing the auth mechanisms that saslauthd requires (PLAIN and LOGIN). I never saw any log entries for svnserve under Squeeze. Here are the config file contents using the most simplified setup I can come up with (no extra library layers like SSL): /var/lib/svn/conf/svnserve.conf [general] anon-access = none realm = Subversion Repository [sasl] use-sasl = true /etc/saslauthd.conf ldap_servers: ldap://ldap.example.com ldap_default_domain: example.com ldap_search_base: dc=example,dc=com ldap_bind_dn: cn=readonly,dc=example,dc=com ldap_bind_pw: PW_HERE ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: uid=%u ldap_password_attr: userPassword ldap_timeout: 5 ldap_cache_ttl: 30 ldap_cache_mem: 32768 /usr/lib/sasl2/svn.conf pwcheck_method: saslauthd auxprop_plugin: ldap mech_list: PLAIN LOGIN # this is used just to prevent a warning in the logs. The # real settings are in /etc/saslauthd.conf ldapdb_uri: ldap://ldap.example.com /etc/default/saslauthd START=yes DESC=SASL Authentication Daemon NAME=saslauthd MECHANISMS=ldap MECH_OPTIONS= THREADS=5 OPTIONS=-c -m /var/run/saslauthd Thanks. -- Justin Pasher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712059: CVE-2012-0553 and CVE-2013-1492 unresolved
Package: mysql-5.1 Version: 5.1.66-0+squeeze1 According to the Debian security tracker, these two CVEs are still unresolved in the MySQL package that is a part of Debian Squeeze. I cannot find any related bug report in the Debian bug tracker, so I'm submitting a new report. Any idea when this can be updated and fixed? It is setting off notices when using internal vulnerability scanning software (e.g. OpenVAS behind a firewall). -- Justin Pasher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708175: Converting libkrb53 into transitional package instead of conflicting with libkrb5-3
It's actually not a local package (it's the PHP 5.2 package from Lenny that I'm trying to keep around), but that's not really of concern to most other people. I haven't been able to get the package to rebuild in a Squeeze environment so I can change the package requirement, but I'm sure a lot of that is due to my limited experience in rebuilding packages (especially one as intricate as PHP). At any rate, I guess there's not much I can do about it. I had though about rebuilding the krb5 packages, but like you said, I then have to worry about updating it for security patches. I'm also not crazy about custom building such a key package. Thanks. Justin Pasher - Original Message - From: Sam Hartman hartm...@debian.org Date: Tue, 14 May 2013 22:32:44 -0400 Subject: Re: Bug#708175: Converting libkrb53 into transitional package instead of conflicting with libkrb5-3 To: Justin Pasher just...@distribion.com CC: 708...@bugs.debian.org, sub...@bugs.debian.org I don't think there's a way to make any changes for this issue in wheezy. I understand that you are disappointed because you'd like to use your local packages. Debian's policy is to support transitions for one release. That's why libkrb53 is a dummy package in squeeze; it does nothing there. The issue is that without a breaks or conflicts, the package will never get cleaned up or removed; it's fairly standard for transitions to conflict after a release so that the cruft gets cleaned up. I think that there's value in cleaning up the old package, and to the larger community that value is probably greater than supporting local packages that cannot be built against wheezy. According to policy/practice, this is not a bug in wheezy. I'd have no problem dropping all references to libkrb53 from jessie and sid because the transition through wheezy will get the old package to be cleaned up. You could rebuild such a krb5 package on wheezy. However you need to rebuild for security updates etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708175: Converting libkrb53 into transitional package instead of conflicting with libkrb5-3
Package: libkrb5-3 Version: 1.10.1+dfsg-5 Is there any chance that the Breaks changes can be reverted or tweaked that were made in this changelog? krb5 (1.10+dfsg~alpha1-5) unstable; urgency=low * Add texinfo back to build depends: policy has been subverted by the evil forces of wishful thinking and forward progress * Conflict: with libkrb53 again. The transition is over and we no longer need that package. -- Sam Hartman hartm...@debian.org Wed, 30 Nov 2011 09:09:55 -0500 We have some older Debian packages that we cannot get to rebuild properly that depend on libkrb53, and since the Wheezy version of libkrb5-3 now conflicts with libkrb53 (even though all the same functionality is still available), we can no longer use those packages. Since libkrb5-3 is such an integral package for other common servers (like sshd), I can't simply hold that package back to the Squeeze version. A change was made to the Ubuntu packages to make the transition a little less heavy handed by changing libkrb53 into a transitional package. https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1007314 A previous bug reports relating to the transition: #596678 Thanks. -- Justin Pasher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629151: keepass2 package needs dependency on libmono-i18n2.0-cil package
Package: keepass2 Version: 2.15+dfsg-2 Severity: normal When I run the program, create a new database, and try to click on the sample password in the default database, I receive the following error on the console: System.NotSupportedException: CodePage 1252 not supported at System.Text.Encoding.GetEncoding (Int32 codepage) [0x0] in filename unknown:0 (the rest of the stack trace has been snipped). It appears that keepass2 needs to depend on the libmono-i18n2.0-cil package in order to ensure the proper codepage definitions are installed. After I installed this package, I no longer receive the crash. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (790, 'stable'), (750, 'oldstable'), (650, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages keepass2 depends on: ii libmono-corlib2.0-cil 2.6.7-5Mono core library (for CLI 2.0) ii libmono-system-runtime2.0-cil 2.6.7-5Mono System.Runtime Library (for C ii libmono-system2.0-cil 2.6.7-5Mono System libraries (for CLI 2.0 ii libmono-winforms2.0-cil 2.6.7-5Mono System.Windows.Forms library ii mono-runtime 2.6.7-5Mono runtime keepass2 recommends no packages. Versions of packages keepass2 suggests: pn xdotool none (no description available) -- 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#567237: udev: Same problem, slightly different solution
I would like to add that I recently updated the udev packages from 151-32
to 151-3, and it actually broke my existing Logitech diNovo Edge bluetooth
connection. It suddenly wasn't able to pair with the USB bluetooth dongle.
The dongle would show up under hcitool dev, and I could even see the
keyboard if I put it in connect mode and ran hcitool scan. They just
wouldn't pair with each other. When I rebooted, I was able to pair the
devices before the OS loaded (so I was able to select a kernel in GRUB),
but once the OS finished loading, they would be disconnected.
I too was able to get it working again by replacing the line in
70-hid2hci.rules. My complete rule looks like this (assuming word wrap
doesn't mess it up):
KERNEL==hiddev*, ATTRS{idVendor}==046d,
ATTRS{idProduct}==c70[345abce]|c71[34bc], \
RUN+=hid2hci --method=logitech --mode=hid --devpath=%p
HOWEVER, once I replaced the lines, restarted udev, unplugged, then
replugged the dongle in, the devices no longer show up under hcitool
(since they are running in HID mode now). I don't really understand the
whole difference between running in HID mode versus HCI mode, but maybe
the Logitech diNovo Edge and bluetooth dongle can't do this. I've never
noticed any lack of functionality with my keyboard or the integrated
touchpad.
I can provide a dump of udevadm output for the device if that actually
helps at all.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525705: libsdl1.2debian-all: Detecting too many buttons for joystick
Package: libsdl1.2debian-all Version: 1.2.13-4+b1 Severity: normal When I upgraded the libsdl1.2debian-all package from stable (1.2.13-2) to testing (1.2.13-4+b1), the joystick detection appears to have been broken (at least for my gamepad). It detects way too many buttons, and it randomly changes how many buttons it detects. When I run the testjoystick program from the original libsdl source tree, it demonstrates the problem. Because the number of buttons is constantly changing, any program that depends on SDL joystick input (such as Mednafen or ZSNES) will not be able to consistantly use the joystick because the keycodes change upon each execution. Additionally, when rolling from one direction to another on the digital pad (for example, rolling from pressing left to pressing down), the input does not properly change from generating the keycode for left to the keycode for down. This makes things like controlling a character in a game not work smoothly, since you have to let go of the direction pad completely to press a new direction. However, this could just be a side effect caused by the incorrect button detection. Here are the testjoystick results when running the stable branch package (1.2.13-2) [jpas...@marvin ~/SDL-1.2.13/test]$ ./testjoystick There are 1 joysticks attached Joystick 0: Logitech Logitech Cordless RumblePad 2 axes: 6 balls: 0 hats: 0 buttons: 12 -- Here are the testjoystick results when running the testing branch package (1.2.13-4+b1) [jpas...@marvin ~/SDL-1.2.13/test]$ ./testjoystick There are 1 joysticks attached Joystick 0: Logitech Logitech Cordless RumblePad 2 axes: 4 balls: 0 hats: 1 buttons: 106 [jpas...@marvin ~/SDL-1.2.13/test]$ ./testjoystick There are 1 joysticks attached Joystick 0: Logitech Logitech Cordless RumblePad 2 axes: 4 balls: 0 hats: 1 buttons: 103 [jpas...@marvin ~/SDL-1.2.13/test]$ ./testjoystick There are 1 joysticks attached Joystick 0: Logitech Logitech Cordless RumblePad 2 axes: 4 balls: 0 hats: 1 buttons: 102 -- -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686-bigmem (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsdl1.2debian-all depends on: ii libaa1 1.4p5-38 ascii art library ii libartsc0 1.5.9-2+b1aRts sound system C support librar ii libasound2 1.0.19-1 shared library for ALSA applicatio ii libaudio2 1.9.1-5 Network Audio System - shared libr ii libc6 2.9-4 GNU C Library: Shared libraries ii libcaca0 0.99.beta16-1 colour ASCII art library ii libdirectfb-1.2-0 1.2.7-2 direct frame buffer graphics - sha ii libesd00.2.41-3 Enlightened Sound Daemon - Shared ii libpulse0 0.9.14-2 PulseAudio client libraries ii libsvga1 1:1.4.3-27console SVGA display libraries ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library libsdl1.2debian-all recommends no packages. libsdl1.2debian-all suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519048: cacti-spine: Package overwrites settings in /etc/cacti/spine.conf
Package: cacti-spine Version: 0.8.7a-2.3 Severity: normal When I recently upgraded the cacti-spine package to Debian Lenny from Debian etch, it overwrote my configuration settings in /etc/cacti/spine.conf without even prompting me with a file diff. To test further, I updated the settings in the config file, removed cacti-spine (apt-get remove cacti-spine), then reinstalled (apt-get install cacti-spine). I was never prompted for anything during installation, and once again, my settings in /etc/cacti/spine.conf were overritten with default (blank) values. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.9-NMG (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cacti-spine depends on: ii cacti 0.8.7b-2.1Frontend to rrdtool for monitoring ii dbconfig-common1.8.39common framework for packaging dat ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii libc6 2.7-18GNU C Library: Shared libraries ii libmysqlclient15off5.0.51a-24MySQL database client library ii libsnmp15 5.4.1~dfsg-12 SNMP (Simple Network Management Pr ii libssl0.9.80.9.8g-15 SSL shared libraries ii ucf3.0016Update Configuration File: preserv ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime cacti-spine recommends no packages. cacti-spine suggests no packages. -- debconf information: * cacti-spine/configuring_cacti: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
