Bug#329413: mozilla-firefox-webdeveloper: postinst is broken (update-mozilla-firefox-chrome: command not found)
Package: mozilla-firefox-webdeveloper Version: 0.9.3-4 Severity: grave Justification: renders package unusable During aptitude upgrade: Setting up mozilla-firefox-webdeveloper (0.9.3-4) ... /var/lib/dpkg/info/mozilla-firefox-webdeveloper.postinst: line 8: update-mozilla-firefox-chrome: command not found dpkg: error processing mozilla-firefox-webdeveloper (--configure): subprocess post-installation script returned error exit status 127 Errors were encountered while processing: mozilla-firefox-webdeveloper E: Sub-process /usr/bin/dpkg returned an error code (1) Ack! Something bad happened while installing packages. Trying to recover: Setting up mozilla-firefox-webdeveloper (0.9.3-4) ... /var/lib/dpkg/info/mozilla-firefox-webdeveloper.postinst: line 8: update-mozilla-firefox-chrome: command not found dpkg: error processing mozilla-firefox-webdeveloper (--configure): subprocess post-installation script returned error exit status 127 Suggested solutions: 1) Depend on mozilla-firefox ( 1.4.99) 2) Find out how Deer Park wants to update the chrome and fix postinst. 3) Forward this bug to mozilla-firefox and make them put them install some shell script for update-mozilla-firefox-chrome. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mozilla-firefox-webdeveloper depends on: ii mozilla-firefox1.4.99+1.5beta1-1 lightweight web browser based on M mozilla-firefox-webdeveloper recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#502972: gkrellm-xkb: neither notices changes to the keyboard layout nor permits to change the layout
Package: gkrellm-xkb Version: 1.05-5 Severity: grave Justification: renders package unusable On changing the layout using setxkbmap the plugin simply does nothing. Only toggling caps or num lock triggers an update. Also left-clicking on the plugin area results in a menu that when closed gets redrawed to the correct flag (so the old flag is partly overwritten with the new one). Furthermore the menu only includes the current layout and nothing else. The plugin has no configuration or whatsoever, so it is impossible to use the plugin for changing layouts. I conclude that the plugin does almost nothing that could be expected from the description except for maybe showing caps and num lock states. Helmut -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages gkrellm-xkb depends on: ii gkrellm 2.3.1-7The GNU Krell Monitors ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-15 GNU C Library: Shared libraries ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio gkrellm-xkb recommends no packages. gkrellm-xkb suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504000: chrony: init script hangs forever breaks upgrade
Package: chrony Version: 1.23-3 Severity: grave Justification: renders package unusable # /etc/init.d/chrony start Starting /usr/sbin/chronyd... Now it will wait forever. $ ps aux OT | grep /chrony root 8811 0.0 0.1 2572 1088 pts/1S+ 12:42 0:00 /bin/sh /etc/init.d/chrony start root 8814 0.0 0.0 2172 892 ?S12:42 0:00 /usr/sbin/chronyd root 8821 0.0 0.1 2560 1056 pts/1S+ 12:42 0:00 /bin/sh /etc/ppp/ip-up.d/chrony root 8825 0.0 0.0 2396 748 pts/1S+ 12:42 0:00 /usr/bin/chronyc helmut9022 0.0 0.0 3880 592 pts/0S+ 12:47 0:00 grep /chrony $ The init script started chronyd and then invoked ip-up.d/chrony waiting for it now. ip-up.d/chrony waits for chronyc and chronyc waits forver upon receiving any command. My chrony.conf only differs from the default in the set of servers used (i.e. only lines starting with server are changed and only the second field is changed). Helmut -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.3 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages chrony depends on: ii libc6 2.7-15 GNU C Library: Shared libraries ii libreadline5 5.2-3 GNU readline and history libraries ii ucf 3.0010 Update Configuration File: preserv chrony recommends no packages. chrony suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504000: Works for me
It does. This may be related to a known upstream problem with some motherboards. Please try commenting out the rtcfile directive in /etc/chrony/chrony.conf. After commenting out rtcfile upgrading the package again works, so that might at least be a work around. Still I think that this regression should be possible to fix, because 1.21z-5 is not hit. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504000: chrony: init script hangs for a while might break
All of the boxes in my company are. Too bad I can't test on more systems. That's quite different from ???a single system???. And it's not like amd64 is an obscure architecture, last time I checked. Did you notice that the bug was reported on i386 initially? So it is even a bit cross-architecture. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504000: Works for me
I had problems with /dev/rtc before, sometimes related to HPET which in combination with chrony even froze my system. This kernel bug has been fixed recently. Also I had problems when using the wrong module. Are you sure you use the right one? Does hwclock work for you? I don't really know about rtc stuff, but I found out that /dev/rtc is driven by the module rtc_cmos on my system, because the usage count of that module increases on opening the device. hwclock works. I tried reading and writing. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504700: does not rotate logfile /var/log/mailman/mischief
Package: mailman Version: 1:2.1.9-7 Severity: serious Justification: Policy 10.8 The stable (etch) version of mailman does not rotate the logfile /var/log/mailman/mischief. It is used to record login failures and similar things from the cgi scripts mailman provides. As the log file is not rotated it may fill the disk which violates policy section 10.8. I hope that this is already fixed in lenny and if not it really should. Also this bug is easy to fix as you only have to provide a simple logrotate config with tons of examples in /etc/logrotate.d/mailman already available (don't forget that mischief is group=www-data). Helmut -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages mailman depends on: ii adduser3.102 Add and remove users and groups ii apache22.2.3-4+etch6 Next generation, scalable, extenda ii apache2-mpm-prefork [h 2.2.3-4+etch6 Traditional model for Apache HTTPD ii cron 3.0pl1-100management of regular background p ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii exim4 4.63-17 metapackage to ease exim MTA (v4) ii exim4-daemon-light [ma 4.63-17 lightweight exim MTA (v4) daemon ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii logrotate 3.7.1-3 Log rotation utility ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii pwgen 2.05-1Automatic Password generation ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6 automated rebuilding support for p ii ucf2.0020Update Configuration File: preserv mailman recommends no packages. -- debconf information: mailman/queue_files_present: * mailman/default_server_language: en mailman/gate_news: false * mailman/site_languages: en * mailman/used_languages: * mailman/create_site_list: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360950: moreinfo?
tags 360950 -moreinfo thanks Hi, the bug is marked as moreinfo. As I fail to see what further information you request on the report I remove the tag. Please add it again along with a question if you like. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462651: please fix or respond
Hi Martin, this is a maintainer ping mail. Please respond in any way. If you don't respond within a week, I'll ask d-mentors to sponsor my proposed patch as nmu. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475733: acon: local root exploit
Package: acon Version: 1.0.5-5 Severity: critical Tags: security Justification: root security hole The package has a setuid binary acon. The binary never drops setuid. The source code contains the following lines: (acon.c) char tmp[300]; ... if((env=getenv(HOME))) sprintf(tmp,%s/.acon.conf,env); This can be easily exploited by a long $HOME. Helmut -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475736: tss: local root exploit
Package: tss Version: 0.8.1-3 Severity: critical Tags: security Justification: root security hole tss has a setuid binary. The source code is src/main.c: sprintf(glob_string, %s/.tss/*, getenv(HOME)); (before dropping setuid, needless to say) Helmut -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages tss depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libncurses5 5.6+20080405-1 Shared libraries for terminal hand tss recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475733: acon: local root exploit
From the source code:
35 int main(int argc,char **argv)
36 {
37 int i,tty,useunicode=0;
38 char *fontf=0,*translationf=0,*keymapf=0;
39
40 get_ids();
41 set_user_id();
...
301 int user_id;
302 int acon_id;
303
304 void get_ids(void)
305 {
306 user_id=getuid();
307 acon_id=geteuid();
308 }
309 void set_user_id(void)
310 {
311 seteuid(user_id);
312 }
So why do you think it does not drop setuid root, the code does?
You are right in that it drops seteuid. Given arbitrary code execution
(which looks possible by trashing the return address of main) one can
still seteuid back to root.
Helmut
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462651: please fix or respond
thank you for your patch; I will upload a fixed package tomorrow. Sorry for the long delay; i've been on work and was not able to access my gpg key nor did I find time to answer. NMU uploaded to delayed/4 by Sune Vuorela. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475733: acon: local root exploit
So why do you think it does not drop setuid root, the code does?
$ cat debian/patches/05_setuid.diff
Index: acon-1.0.5/acon.c
Commented a statement that returns the user id to non-root. That made
some control keys to not work.
===
diff -ur acon/acon.c acon-1.0.5/acon.c
--- acon/acon.c 2003-07-18 22:09:06.0 +0300
+++ acon-1.0.5/acon.c 2007-02-23 08:16:32.0 +0200
@@ -308,7 +308,7 @@
}
void set_user_id(void)
{
- seteuid(user_id);
+ //seteuid(user_id); // aelmahmoudy
}
void set_acon_id(void)
{
$
Helmut
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475733: closed by ???????? ???????????????? (Ahmed El-Mahmoudy) [EMAIL PROTECTED] (Bug#475733: fixed in acon 1.0.5-6)
found 475733 1.0.5-6 thanks * Dropped 05_setuid.diff as it can cause a root exploit. (Closes: #475733) This is not enough, because it still has seved set userid and is exploitable: The package has a setuid binary acon. The binary never drops setuid. The source code contains the following lines: (acon.c) char tmp[300]; ... if((env=getenv(HOME))) sprintf(tmp,%s/.acon.conf,env); This can be easily exploited by a long $HOME. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491867: closed by Jonas Meurer [EMAIL PROTECTED] (Bug#491867: fixed in cryptsetup 2:1.0.6-4)
severity 491867 minor thanks So this will run mkswap on the resume device. AFAIK, this mkswap operation is run by /etc/init.d/cryptsetup-early which in turn is run by /sbin/init. Thus, this operation is only during a regular boot. It is not run during resume, since resume does not actually run init scripts. With only reading I come to the same conclusion. In particular, I could find no copy of the crypttab file in the initrd.img which hands over to the unfrozen system. Still this information has to be somewhere in the initrd, because otherwise the initrd would have no way to know what to decrypt. I guess the file is parsed and stored somewhere in conf/. What gives more evidence is that neither /usr/share/initramfs-tools mentions mkswap nor the initrd contains a copy. Has this fix actually caused a problem with any system? Actually no, I did not trash my system. I only verified that the swap signature does change and that the luks header is not properly destroyed. I then concluded under the false assumption that cryptsetup behaves consistent. So let me propose changing other things: * First of all it would be great if we could change man crypttab to reflect this behaviour like Run mkswap on the created device, but not before /sbin/init is run. or Run mkswap on the created device unless it is used for resuming. * Secondly in README.initramfs.gz according to my understanding step 6 should be useless, because step 4 already formated the device. A imho better approach would be to keep step 6 and never let cryptsetup invoke mkswap by removing that swap option if this change does not break the sequence in another way. I'd also be glad if README.initramfs.gz could be extended with more explanations on why and how this works, because the documentation of cryptsetup often made me read the source. Thanks for investigating this Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502263: mailman: policy violation (9.1.1): writes to /usr when config changes
Package: mailman Version: 1:2.1.9-7 Severity: serious Justification: Policy 9.1.1 Policy section 9.1.1 says that FHS must be complied and FHS Chapter 4 says that /usr must not be written to. However after changing the configuration file /usr/lib/mailman/Mailman/mm_cfg.pyc is updated on restarting mailman which is a violation of the policy. It should be non-fatal when /usr is read-only, because python will then simply not write out the .pyc file. However using tools like tripwire may cause problems. Please lower the severity of this issue if you think a lower severity is more appropriate. I only filed it as serious because it technically is serious (a policy violation). Helmut -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages mailman depends on: ii adduser3.102 Add and remove users and groups ii apache22.2.3-4+etch5 Next generation, scalable, extenda ii apache2-mpm-prefork [h 2.2.3-4+etch5 Traditional model for Apache HTTPD ii cron 3.0pl1-100management of regular background p ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii exim4 4.63-17 metapackage to ease exim MTA (v4) ii exim4-daemon-light [ma 4.63-17 lightweight exim MTA (v4) daemon ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii logrotate 3.7.1-3 Log rotation utility ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii pwgen 2.05-1Automatic Password generation ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6 automated rebuilding support for p ii ucf2.0020Update Configuration File: preserv mailman recommends no packages. -- debconf information: mailman/queue_files_present: * mailman/default_server_language: en mailman/gate_news: false * mailman/site_languages: en * mailman/used_languages: * mailman/create_site_list: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502263: [Pkg-mailman-hackers] Bug#502263: mailman: policy violation (9.1.1): writes to /usr when config changes
I welcome input on this issue from people with more deep knowledge than myself about these Python cached files, and how we could best address it in this case. If there's a straightforward solution I think we can apply it for lenny. The simplest solution might actually be to take the approach python-support uses. 1) The .py files stay where they are. 2) They are symlinked to a directory hierarchy within /var/lib. (This means directories are copied and files are symlinked.) 3) The .pyc files will get created on /var. 4) The module path has to be adapted from /usr/lib/mailman to something on /var. Therefore /usr/lib/mailman/bin/paths.py should be adapted. However I indeed don't think this should be release critical, as you say, it doesn't break when writing fails. It is an inconvenience with e.g. tripwire, but that is resolvable within the context of that application. So I would classify it as an 'important' issue myself. ACK. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502620: includes bad libncurses5.md5sums or debsums verification failed
Package: libncurses5 Version: 5.6+20081004-1 Severity: serious Justification: Policy 12.7 Quote from 12.7: | Packages that are not Debian-native must contain a compressed copy of | the debian/changelog file from the Debian source tree in | /usr/share/doc/package with the name changelog.Debian.gz. Violation: A debian/changelog with a different version is installed. It is probably caused by hardlinks between changelogs that are not enforced to have the same version. I discovered it this way: $ debsums libncurses5 /usr/share/doc/libncurses5/README.Debian OK /usr/share/doc/libncurses5/changelog.gz FAILED /usr/share/doc/libncurses5/copyright OK /usr/share/doc/libncurses5/FAQOK /usr/share/doc/libncurses5/changelog.Debian.gzFAILED /usr/share/doc/libncurses5/TODO.DebianOK /usr/lib/libmenu.so.5.6 OK /usr/lib/libform.so.5.6 OK /usr/lib/libpanel.so.5.6 OK /lib/libncurses.so.5.6OK /lib/libtic.so.5.6OK $ dpkg -l libncurses5 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libncurses55.6+20081004-1 shared libraries for terminal handling $ mkdir tmp $ dpkg-deb -X /var/cache/apt/archives/libncurses5_5.6+20081004-1_amd64.deb tmp/ ./ ./usr/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/libncurses5/ ./usr/share/doc/libncurses5/README.Debian ./usr/share/doc/libncurses5/changelog.gz ./usr/share/doc/libncurses5/copyright ./usr/share/doc/libncurses5/FAQ ./usr/share/doc/libncurses5/changelog.Debian.gz ./usr/share/doc/libncurses5/TODO.Debian ./usr/lib/ ./usr/lib/libmenu.so.5.6 ./usr/lib/libform.so.5.6 ./usr/lib/libpanel.so.5.6 ./lib/ ./lib/libncurses.so.5.6 ./lib/libtic.so.5.6 ./usr/lib/libform.so.5 ./usr/lib/libmenu.so.5 ./usr/lib/libpanel.so.5 ./lib/libtic.so.5 ./lib/libncurses.so.5 $ zdiff -ruN tmp/usr/share/doc/libncurses5/changelog.gz /usr/share/doc/libncurses5/changelog.gz --- /dev/fd/5 2008-10-18 14:25:09.971995422 +0200 +++ - 2008-10-18 14:25:09.976556741 +0200 @@ -25,7 +25,7 @@ -- sale, use or other dealings in this Software without prior written-- -- authorization.-- --- --- $Id: NEWS,v 1.1304 2008/10/04 23:01:08 tom Exp $ +-- $Id: NEWS,v 1.1309 2008/10/11 21:42:24 tom Exp $ --- This is a log of changes that ncurses has gone through since Zeyd started @@ -45,6 +45,17 @@ Changes through 1.9.9e did not credit all contributions; it is not possible to add this information. +20081011 + + update html documentation. + + add -m and -s options to test/keynames.c and test/key_names.c to test + the meta() function with keyname() or key_name(), respectively. + + correct return value of key_name() on error; it is null. + + document some unresolved issues for rpath and pthreads in TO-DO. + + fix a missing prototype for ioctl() on OpenBSD in tset.c + + add configure option --disable-tic-depends to make explicit whether + tic library depends on ncurses/ncursesw library, amends change from + 20080823 (prompted by Debian #501421). + 20081004 + some build-fixes for configure --disable-ext-funcs (incomplete, but works for C/C++ parts). $ zdiff -ruN tmp/usr/share/doc/libncurses5/changelog.Debian.gz /usr/share/doc/libncurses5/changelog.Debian.gz --- /dev/fd/5 2008-10-18 14:26:21.056979638 +0200 +++ - 2008-10-18 14:26:21.061947166 +0200 @@ -1,3 +1,10 @@ +ncurses (5.6+20081011-1) unstable; urgency=low + + * Merging upstream version 5.6+20081011. + * Building with --disable-tic-depends. + + -- Daniel Baumann [EMAIL PROTECTED] Thu, 16 Oct 2008 20:55:00 +0200 + ncurses (5.6+20081004-1) unstable; urgency=low * Merging upstream version 5.6+20081004. $ ls -lai /usr/share/doc/*ncurses*/changelog* | sort -g 262216 -rw-r--r-- 1 root root 145732 Oct 16 20:55 /usr/share/doc/libncurses5/changelog.gz 262216 -rw-r--r-- 1 root root 145732 Oct 16 20:55 /usr/share/doc/ncurses-base/changelog.gz 262216 -rw-r--r-- 1 root root 145732 Oct 16 20:55 /usr/share/doc/ncurses-bin/changelog.gz 262216 -rw-r--r-- 1 root root 145732 Oct 16 20:55
Bug#391538: python-zopeinterface fails to install: raise PyCentralError, package has no field Python-Version
Package: python-zopeinterface Version: 3.3.0-2 Severity: grave Justification: renders package unusable Fails to configure with: Setting up python-zopeinterface (3.3.0-2) ... Traceback (most recent call last): File /usr/bin/pycentral, line 1336, in ? main() File /usr/bin/pycentral, line 1330, in main rv = action.run(global_options) File /usr/bin/pycentral, line 865, in run pkg.read_version_info() File /usr/bin/pycentral, line 535, in read_version_info raise PyCentralError, package has no field Python-Version __main__.PyCentralError: package has no field Python-Version dpkg: error processing python-zopeinterface (--configure): subprocess post-installation script returned error exit status 1 As other packages using python-central seem to work on my system I don't think this to be a python-central bug. It seems like the package just hasn't been tested with a recent python-central version. Helmut Grohne -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python-zopeinterface depends on: ii python-central0.5.6 register and build utility for Pyt python-zopeinterface recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#412502: libcgicc1-dev: fails to compile most programs because constructors are implemented in #pragma interface headers
Package: libcgicc1-dev
Version: 3.2.3-3
Severity: grave
Justification: renders package unusable
Tag: patch
Almost all headers contain
#pragma interface
and at the same time implement constructors like
inline CgiInput() {}
which just doesn't fit together. Trying to compile things with g++ will
result in g++ ignoring these implementations which will result in a
linker failure. As cgicc::Cgicc also has such a case this will render
the package almost unusable.
A quick-fix to this problem is discarding all #pragma interface lines.
Helmut
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages libcgicc1-dev depends on:
ii libcgicc1 3.2.3-3A C++ class library for writing CG
Versions of interesting packages:
ii g++ 4.1.1-15 The GNU C++ compiler
libcgicc1-dev recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#462651: gidentd: does not rotate logfiles and therefore fills /var/log
Package: gidentd
Version: 0.4.5-7.3
Severity: serious
Justification: Policy 10.8
Tags: patch
gidentd does not rotate logfiles (neither etch nor sid). However the
policy requires this (and my /var/log fills ...):
Policy 10.8 says:
Log files must be rotated occasionally so that they don't grow
indefinitely; ...
A NMU diff is attached.
While investigating your package I also found following bugs:
At least the stable package does not remove logfiles when being purged
(policy says this should [!= must] happen).
Furthermore the package does not build with MAKEFLAGS=-j2.
Helmut
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
diff -ruN gidentd-0.4.5+dfsg1/debian/changelog gidentd-0.4.5+dfsg1-0.2/debian/changelog
--- gidentd-0.4.5+dfsg1/debian/changelog 2008-01-26 15:10:57.0 +0100
+++ gidentd-0.4.5+dfsg1-0.2/debian/changelog 2008-01-26 15:17:36.0 +0100
@@ -1,3 +1,10 @@
+gidentd (0.4.5+dfsg1-0.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix missing logrotate (policy 10.8, Closes: #nnn).
+
+ -- Helmut Grohne [EMAIL PROTECTED] Sat, 26 Jan 2008 14:52:08 +0100
+
gidentd (0.4.5+dfsg1-0.1) unstable; urgency=low
* Non-maintainer upload.
diff -ruN gidentd-0.4.5+dfsg1/debian/control gidentd-0.4.5+dfsg1-0.2/debian/control
--- gidentd-0.4.5+dfsg1/debian/control 2008-01-26 15:10:57.0 +0100
+++ gidentd-0.4.5+dfsg1-0.2/debian/control 2008-01-26 15:14:38.0 +0100
@@ -9,7 +9,7 @@
Architecture: any
Replaces: ident-server
Provides: ident-server
-Depends: ${shlibs:Depends}, update-inetd
+Depends: ${shlibs:Depends}, update-inetd, logrotate
Conflicts: ident-server
Description: RFC1413 compliant IPv4/IPv6 ident daemon
gidentd is a fully functional, RFC1413 compliant ident daemon,
diff -ruN gidentd-0.4.5+dfsg1/debian/gidentd.logrotate gidentd-0.4.5+dfsg1-0.2/debian/gidentd.logrotate
--- gidentd-0.4.5+dfsg1/debian/gidentd.logrotate 1970-01-01 01:00:00.0 +0100
+++ gidentd-0.4.5+dfsg1-0.2/debian/gidentd.logrotate 2008-01-26 15:12:23.0 +0100
@@ -0,0 +1,10 @@
+/var/log/gidentd.log {
+ rotate 12
+ weekly
+ compress
+ # Is this necessary? It doesn't hurt though:
+ delaycompress
+ postrotate
+ /etc/init.d/gidentd force-reload
+ endscript
+}
diff -ruN gidentd-0.4.5+dfsg1/debian/rules gidentd-0.4.5+dfsg1-0.2/debian/rules
--- gidentd-0.4.5+dfsg1/debian/rules 2008-01-26 15:10:57.0 +0100
+++ gidentd-0.4.5+dfsg1-0.2/debian/rules 2008-01-26 15:14:11.0 +0100
@@ -49,6 +49,7 @@
dh_installman debian/gidentd.8
dh_installchangelogs ChangeLog
+ dh_installlogrotate
dh_link
dh_strip
Bug#416211: sunbird: FTBFS on amd64
Package: sunbird Version: 0.2.99+0.3alpha1 Severity: serious Justification: Policy 4.2 ftbfs on amd64 using pbuilder c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: nsCOMPtr.o: relocation R_X86_64_PC32 against `nsGetServiceByContractIDWithError::operator()(nsID const, void**) const' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[5]: *** [libxpcom_core.so] Error 1 make[5]: Leaving directory `/tmp/buildd/sunbird-0.2.99+0.3alpha1/build-dir/mozilla/xpcom/build' Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) signature.asc Description: Digital signature
Bug#541174: FTBFS with GCC 4.4: dereferencing pointer 'sa' does break strict-aliasing rules
tags 541174 +unreproducible severity 541174 normal thanks Hi, On Tue, Aug 11, 2009 at 09:30:54PM -1000, Martin Michlmayr wrote: libtool --mode=compile gcc -Wall -g -O2 -Wall -Wextra -Wl,--as-needed -Werror -I. -c libexplain/fildes_to_address_family.c -o libexplain/fildes_to_address_family.lo libtool: compile: gcc -Wall -g -O2 -Wall -Wextra -Wl,--as-needed -Werror -I. -c libexplain/fildes_to_address_family.c -fPIC -DPIC -o libexplain/.libs/fildes_to_address_family.o cc1: warnings being treated as errors libexplain/fildes_to_address_family.c: In function 'explain_fildes_to_address_family': libexplain/fildes_to_address_family.c:36: error: dereferencing pointer 'sa' does break strict-aliasing rules libexplain/fildes_to_address_family.c:32: note: initialized from here I tried to reproduce this using gcc-4.4 4.4.2-9 on amd64 and failed. No matter how hard I give gcc -Wstrict-aliasing=3 or any optimization options it will not reproduce this warning on both amd64 and i386. I suggest to close the bug. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553135: sendmail-base: maintainer-script-calls-init-script-directly prerm:67 than using invoke-rc.d. The use of invoke-rc.d to invoke the /etc/init.d/* initscripts instead of calling them directly
Hi, thanks to Manoj for pointing this out and Richard for explaining it. Unfortunately this rc bug is still open after two months. Short summary: sendmail-base.prerm invokes an init script without invoke-rc.d which technically is forbidden by the Debian policy. (report from Manoj) The part that is invoked is not a standard command (clean) and would that way produce a warning. (pointed out by Richard) Let me outline possible solutions: 1) Tag it as wontfix and decrease severity. The reason for using invoke-rc.d is that it can prevent starting and stopping daemons when this is not desired. Cleaning the queue does not interfere with this. 2) Use invoke-rc.d --force. (suggested by Richard) 3) Move the queue cleaning script somewhere else and call it from the init script. Please decide about a solution and solve this issue. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553135: sendmail-base: maintainer-script-calls-init-script-directly prerm:67 than using invoke-rc.d. The use of invoke-rc.d to invoke the /etc/init.d/* initscripts instead of calling them directly
severity 553135 normal thanks On Fri, Jan 22, 2010 at 01:50:40PM -0800, Russ Allbery wrote: That being said, this is clearly not the problem that either Policy or the Lintian tag were designed to catch, and you should feel free to decrease the severity and add an override. Also, please feel free to report a bug Thanks for your input. I just downgrade the severity for now, so others don't try to fix it as an rc bug. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555036: upgrading severity
severity 542093 important block 555036 by 542093 thanks Thanks to Julien Valroff for pointing out a lack of documentation in this package. In fact it contains no documentation at all which makes it unusable. I ran into this bug while trying to squash #555036. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546528: [maintainer ping] Re: [PATCH] make dash's preinst a C binary
Hi Gerrit, as you can see David Riebenbauer provided a patch to convert dash.preinst to something not depending on /bin/sh. As far as I can tell applying this patch would not worsen the situation in any way, but it would make it easier to work on the bash package. Could you somehow answer to this bugreport? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567096: dns2tcpd does not answer NS queries
Package: dns2tcp Version: 0.4.dfsg-5.1 Severity: grave Does anyone actually use this package? Either it is heavily broken or I am doing something wrong. I set up dns2tcpd and a NS record as described in the documentation. However calling dig -t NS on the subdomain times out for the vast majority of name servers I tried. A timeout also indicates that it is not a caching problem. So I went on to see what's happening and installed tcpdump. It seems like many nameservers want to verify NS records by querying the target server (dns2tcpd). Unfortunately dns2tcpd has no handling for these requests, so it simply drops them. The asking nameserver then believes that dns2tcpd is unreachable and does not forward queries. Working out a patch for this shouldn't be difficult (famous last words), as it is only like handling a new packet type and answering it with information provided in the configuration file. During my research I actually found a (one) public dns server that does not do this kind of NS checking. In most use cases of dns2tcp one will not be able to choose a dns server though. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561089: ispell: segfaults on checking any file
Package: ispell Version: 3.1.20.0-7 Severity: grave Justification: renders package unusable When I try to spell check any file ispell simply segfaults. When I invoke it without arguments it prints the help text. To find out whether this was a recent regression I downgraded the package, but that did not help. This indicates that the cause may be unrelated to ispell. I also ran gdb on a core file from ispell, but the traceback did not reveal anything useful. Running strace in ispell shows that it uses curses to set up the terminal and then segfaults right after reading the file to be checked. Is there anything else I can do to help diagnose this? Helmut -- System Information: Architecture: amd64 (x86_64) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ispell depends on: ii dictionaries-common 1.4.0 Common utilities for spelling dict ii dpkg 1.15.5.4 Debian package management system ii ingerman [ispell-dictiona 20091006-2 New German orthography dictionary ii install-info 4.13a.dfsg.1-5 Manage installed documentation in ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand Versions of packages ispell recommends: ii wamerican [wordlist] 6-3American English dictionary words ii wngerman [wordlist] 20091006-2 New German orthography wordlist -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567096: Acknowledgement (dns2tcpd does not answer NS queries)
tags 567096 + patch
thanks
I created a patch for this issue and verified that it does answer NS
request in a manner dig can understand. Unfortunately I was not able to
test it in a real use case yet.
Helmut
diff --git a/common/includes/dns.h b/common/includes/dns.h
index 435c57f..eebc4f4 100644
--- a/common/includes/dns.h
+++ b/common/includes/dns.h
@@ -128,6 +128,7 @@ struct req_hdr {
struct rr_hdr {
uint16_t type;
+#define TYPE_NS 2
#define TYPE_TXT 16
#define TYPE_KEY 25
uint16_t klass;
diff --git a/server/requests.c b/server/requests.c
index 45570d5..86a3ecf 100644
--- a/server/requests.c
+++ b/server/requests.c
@@ -167,6 +167,72 @@ static int get_ressources(t_conf *conf,void *req,
return (0);
}
+static int answer_ns(t_conf *conf,void *req,
+ int in_len, struct sockaddr_in *sa)
+{
+ int out_len = -1;
+ struct dns_hdr *hdr;
+ struct rr_hdr *rr;
+ char *data;
+ int token_length;
+ const char*mydata;
+
+ hdr = req;
+ hdr-ra = 1; /* */
+ hdr-qr = 1; /* response */
+ PUT_16(hdr-ancount, 1); /* one answer */
+ data = JUMP_DNS_HDR(req);
+ mydata = conf-my_domain;
+ /* data should point to our name */
+ while(*data)
+{
+ token_length = *(unsigned char*)data;
+ ++data;
+ if(strlen(mydata) token_length)
+return (-1);
+ if(memcmp(data, mydata, token_length))
+return (-1);
+ data += token_length;
+ mydata += token_length;
+ if(*mydata == '.')
+++mydata;
+}
+ if(*mydata)
+return (-1);
+ ++data;
+ /* followed by query type TYPE_NS */
+ if(GET_16(data) != TYPE_NS)
+return (-1);
+ data += 2;
+ /* followed by class IN */
+ if(GET_16(data) != CLASS_IN)
+return (-1);
+ data += 2;
+ if(((void*)data - req) + 12 + strlen(conf-my_ip) + 2 = MAX_REQ_LEN)
+return (-1);
+ /* name: compressed, point to JUMP_DNS_HDR(req) */
+ PUT_16(data, COMPRESS_FLAG | DNS_HDR_SIZE);
+ data += 2;
+ rr = (void*)data;
+ PUT_16(rr-type, TYPE_NS);
+ PUT_16(rr-klass, CLASS_IN);
+ rr-ttl = htonl(24*60*60);
+ data += 10;
+ strcpy(data, conf-my_ip);
+ dns_encode(data);
+ PUT_16(rr-rdlength, strlen(data)+1);
+ data += strlen(data)+1;
+ out_len = (void*)data - req;
+
+ if (sendto(conf-sd_udp, req, out_len, 0, (struct sockaddr *)sa,
+ sizeof(struct sockaddr)) == -1)
+{
+ MYERROR(send error\n);
+ return (-1);
+}
+ return 0;
+}
+
int get_incoming_request(t_conf *conf)
{
struct sockaddr_in sa_other;
@@ -185,6 +251,8 @@ static int get_ressources(t_conf *conf,void *req,
return (get_ressources(conf,buffer, len, sa_other));
if (type == TYPE_TXT)
return (queue_put_data(conf,buffer, len, sa_other));
+ if (type == TYPE_NS)
+ return (answer_ns(conf,buffer, len, sa_other));
return (0);
}
Bug#567096: Acknowledgement (dns2tcpd does not answer NS queries)
found 567096 0.4.dfsg-5 thanks This affects stable, btw. Rhonda can fix it now. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568741: ingerman: upgrade failure
Package: ingerman Version: 20091006-4 Severity: grave Justification: renders package unusable Hi, I was upgrading my unstable system and saw the following message. | Problems rebuilding an ispell hash file (ingerman.hash) | | | | ** Error: Could not find affix file /usr/lib/ispell/ingerman.aff | | | | This error was caused by package providing 'ingerman.hash', although it can be made evident during other | | package postinst. Please complain to the maintainer of package providing 'ingerman.hash'.| | | | Until this problem is fixed you will not be able to use ispell with 'ingerman.hash'. | I don't really understand much about ispell, only that it is currently broken. Do you need any other information? Helmut -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ingerman depends on: ii cdebconf [debconf-2.0]0.146 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii dictionaries-common 1.4.0 Common utilities for spelling dict ii ispell3.1.20.0-7 International Ispell (an interacti ingerman recommends no packages. Versions of packages ingerman suggests: pn wngerman none (no description available) -- debconf information: shared/packages-ispell: ingerman/languages: deutsch (New German 8 bit), deutsch (New German -tex mode-) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568741: ingerman: upgrade failure
Thanks for your quick reply.
On Tue, Feb 09, 2010 at 03:32:27PM +0100, Agustin Martin wrote:
What are the contents of /var/lib/ispell?
$ ls -la /var/lib/ispell/
total 3840
drwxr-xr-x 2 root root4096 Feb 7 13:51 .
drwxr-xr-x 64 root root4096 Feb 7 13:43 ..
-rw-r--r-- 1 root root 1 Dec 14 14:11 ingerman.compat
-rw-r--r-- 1 root root 7 Feb 7 14:00 ngerman.compat
-rw-r--r-- 1 root root 3910560 Feb 7 14:00 ngerman.hash
$ md5sum /var/lib/ispell/*
cfcd208495d565ef66e7dff9f98764da /var/lib/ispell/ingerman.compat
63d5aa8eab6985cdff2839bcaee759d5 /var/lib/ispell/ngerman.compat
9b32846bd5cae6583cd2391b6a8273c1 /var/lib/ispell/ngerman.hash
$
ingerman should use ngerman.aff to build ngerman.hash, not ingerman.{aff,hash}
I'm sorry, but I don't know that much about dictionaries. I simply use
ispell without understanding how it works.
(See 'dpkg -L ingerman' output).
I assume that you want the command output:
$ dpkg -L ingerman
/.
/var
/var/lib
/var/lib/dictionaries-common
/var/lib/dictionaries-common/ispell
/var/lib/dictionaries-common/ispell/ingerman
/var/lib/ispell
/var/lib/ispell/ngerman.hash
/var/lib/ispell/ngerman.compat
/usr
/usr/share
/usr/share/doc
/usr/share/doc/ingerman
/usr/share/doc/ingerman/changelog.Debian.gz
/usr/share/doc/ingerman/RSR.gz
/usr/share/doc/ingerman/changelog.gz
/usr/share/doc/ingerman/TODO
/usr/share/doc/ingerman/Disabled.words
/usr/share/doc/ingerman/README
/usr/share/doc/ingerman/copyright
/usr/share/doc/ingerman/Credits
/usr/share/doc/ingerman/README.Debian
/usr/share/doc/ingerman/BUGS
/usr/share/ispell
/usr/share/ispell/ngerman.mwl.gz
/usr/lib
/usr/lib/ispell
/usr/lib/ispell/ngerman.aff
/usr/lib/ispell/ndeutsch.aff
/usr/lib/ispell/ngerman.hash
/usr/lib/ispell/ndeutsch.hash
$
I'd like to note that #500618 still applies to my system.
Is there anything else you need?
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
Package: ncurses-base Version: 5.7+20090803-2 Severity: critical Justification: breaks unrelated software ctrl-c does no longer cause SIGINT. Debugging this issue: When I create a new xterm (or rxvt) as a fork from my windowmanager (awesome) the terminal shows the broken behaviour. I have still some xterms that are not affected open. Those were started in 2009. Using strace on both working and a broken xterm show that both send \3 to the terminal fd when I press ctrl-c. stty on a working xterm looks like: speed 38400 baud; line = 0; On a broken xterm it looks like: speed 38400 baud; line = 0; -brkint -imaxbel Using stty brkint imaxbel or stty sane does not solve the issue. Also stty intr ^C does not help. Starting a xterm from an working xterm results in a working xterm. Starting a xterm from a broken xterm results in a broken xterm. Starting a xterm, starting vim within it and then doing :!xtermCR produces a working xterm. Saving the environment of a working xterm, loading it in a broken xterm and then starting a new xterm results in a broken xterm. Do you have any other ideas for debugging the issue? If you feel that I have assigned the bug report to the wrong package, please reassign it to the correct package. Helmut -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.3 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ncurses-base depends on: ii libncurses5 5.7+20090803-2 shared libraries for terminal hand Other packages of interest: ii bash 4.1-1 The GNU Bourne Again SHell ii rxvt 1:2.6.4-14 VT102 terminal emulator for the X Window System ii xterm 253-1 X terminal emulator ncurses-base recommends no packages. ncurses-base suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
Hi Sven, thanks for your very quick reply. On Wed, Feb 10, 2010 at 11:26:07PM +0100, Sven Joachim wrote: I have still some xterms that are not affected open. Those were started in 2009. Before or after you upgraded ncurses-base? That package has not been touched for more than five months. Unfortunately I don't have any idea when I started the last working xterm. But I probably restarted some xterm within the past four months, so we can assume that ncurses-base is not the causing package. On a broken xterm it looks like: speed 38400 baud; line = 0; -brkint -imaxbel Here it looks exactly the same as in your broken xterm, and ^C works fine anyway. Ok. This information is of no help then. Using stty brkint imaxbel or stty sane does not solve the issue. Also stty intr ^C does not help. stty sane should remove the -brkint -imaxbel. Does it? It does. Do you have any other ideas for debugging the issue? Not really, but you could send the output of 'env' and Uhm. I don't really like to show my complete environment. I therefore give a diff from working to broken: -SHLVL=5 +SHLVL=20 -WINDOWID=20971535 +WINDOWID=12582927 -XTERM_LOCALE=de_DE +XTERM_LOCALE=C Here are some variables that might be of interest: LANG=C LANGUAGE=C LC_CTYPE=de_DE (no other LC_* is set) TERM=xterm WINDOWPATH=7 XTERM_SHELL=/bin/bash XTERM_VERSION=XTerm(253) 'xrdb -query | grep -i xterm'. Do you see any differences between working and broken xterms? The xrdb -query | grep -i xterm command has no output at all for me. If you feel that I have assigned the bug report to the wrong package, please reassign it to the correct package. I feel it is assigned to the wrong package, but I have no idea what the right package could be. Actually I didn't feel it was the right package either. However packages like xterm, rxvt or bash seemed even more wrong. Kernel: Linux 2.6.24.3 Ever thought of upgrading this two years old, totally unsupported kernel? Yes, it is on my todo list for about a year. Unfortunately I really rely on that system (well I shouldn't be running testing then ;-). Additionally I experience bugs that cause data loss on reboots, so I avoid the latter as hard as possible. Helmut PS: I will be unable to read mail for the extended weekend starting in 14 hours. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577822: cpufreqd: causes hardware damage by ignoring sensor lines after removing libsenors3
Package: cpufreqd Version: 2.4.1-1 Severity: critical Tags: patch Justification: causes hardware damage Since no package on my system depends on libsensors3 I removed it. With it the file /etc/sensors.conf went away. This is a file cpufreqd requires to use for the sensors plugin. Without that file it will not trigger on temperature changes and possibly cause your hardware to overheat. A quick solution is to depend on libsensors3 as it provides the required file. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507487: does not rotate logfile /var/log/nagios2/nagios.log
Package: nagios2 Version: 2.6-2+etch1 Severity: serious Justification: Policy 10.8 nagios2 does not rotate /var/log/nagios2/nagios.log and that way fills up the disk. Helmut -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages nagios2 depends on: ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii libgd2-noxpm 2.0.33-5.2etch1 GD Graphics Library version 2 (wit ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libperl5.8 5.8.8-7etch3 Shared Perl library ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii nagios2-common 2.6-2+etch1 support files for nagios2 ii perl 5.8.8-7etch3 Larry Wall's Practical Extraction ii zlib1g 1:1.2.3-13compression library - runtime nagios2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508298: chronyd unreachable and does not work (clock drifts)
Package: chrony Version: 1.23-5 Severity: grave Justification: renders package unusable Hi. There we are again. chrony does no longer break the system using an init script that never finishes, but still chronyd does not work. My clock drifts and when I start chronyc any command that would contact chronyd will make chronyc wait forever (example: sourcestats). As we have discussed before this affects quite a lot i386 and amd64 machines around, so grave is justified. This bug just *is* release-critical. Helmut -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.3 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages chrony depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libreadline5 5.2-3 GNU readline and history libraries ii timelimit 1.1-3 Simple utility to limit a process' ii ucf 3.0010 Update Configuration File: preserv Versions of packages chrony recommends: ii udev 0.125-7/dev/ and hotplug management daemo chrony suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508298: chronyd unreachable and does not work (clock drifts)
Hi John, hanks for investigating the problem and sorry for being unresponsive: An illness disrupted almost everything. Please do this as root (with rtcfile uncommented in /etc/chrony/chrony.conf) and send me the output: strace -eioctl chronyd -d The complete output is: ioctl(4, FIONREAD, [301]) = 0 ioctl(4, FIONREAD, [301]) = 0 ioctl(4, FIONREAD, [301]) = 0 ioctl(4, FIONREAD, [301]) = 0 sys_linux.c:649:(get_version_specific_details)[13-22:19:01] Initial txc.tick=1 txc.freq=0 (0.) txc.offset=0 = hz=100 shift_hz=7 sys_linux.c:665:(get_version_specific_details)[13-22:19:01] set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.2800 nominal_tick=1 slew_delta_tick=833 max_tick_bias=1000 sys_linux.c:703:(get_version_specific_details)[13-22:19:01] Linux kernel major=2 minor=6 patch=24 sys_linux.c:787:(get_version_specific_details)[13-22:19:01] calculated_freq_scale=0.99902439 freq_scale=0.99902439 ioctl(8, RTC_UIE_ON, 0) = 0 The program keeps running, but doesn't print anything, so I terminated it after a while. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538822: dash: fails to install overwriting files from bash
Package: dash Version: 0.5.5.1-2 Severity: grave Justification: renders package unusable Upgrading dash fails: (Reading database ... 181192 files and directories currently installed.) Preparing to replace dash 0.5.5.1-2 (using .../dash_0.5.5.1-2.2_amd64.deb) ... Adding `diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by dash' Unpacking replacement dash ... dpkg: error processing /var/cache/apt/archives/dash_0.5.5.1-2.2_amd64.deb (--unpack): trying to overwrite `/bin/sh', which is also in package bash Removing `diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by dash' Processing triggers for man-db ... Processing triggers for menu ... Errors were encountered while processing: /var/cache/apt/archives/dash_0.5.5.1-2.2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: If I understand this correctly bash should release the files and dash should conflict with the current version of bash. In any case this is not a smooth upgrade. Helmut -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages dash depends on: ii libc6 2.9-20 GNU C Library: Shared libraries dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: false -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538822: dash: fails to install overwriting files from bash
Hi, On Tue, Jul 28, 2009 at 01:14:26AM +0200, Raphael Geissert wrote: Could you please provide the output of $ dpkg-divert --list /bin/sh, and readlink -f /bin/sh? $ dpkg-divert --list /bin/sh local diversion of /bin/sh to /bin/sh.distrib $ readlink -f /bin/sh /bin/dash $ We tested many scenarios and we didn't find any failure, so this must be something that should not be common. I'm one of those users who started early with using dash as /bin/sh. Maybe it is connected to early code making dash available as /bin/sh? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538822: dash: fails to install overwriting files from bash
Hi Raphael, On Tue, Jul 28, 2009 at 01:41:01AM +0200, Raphael Geissert wrote: And /bin/sh.distrib points to dash? :-/ No: $ readlink -f /bin/sh.distrib /bin/bash $ You probably also want to know my bash version. It is 3.2-6. I'm not quite sure, I'll take a look at this tomorrow. But unless dash used to use something other than dpkg-divert to modify the link, I can't immediately think of an scenario where that would happen. Of course, it might be that I'm just too sleepy and am missing something :) Thanks for investigating. If you need anything else, please ask. Unfortunately I haven't actively worked with diversions yet. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538822: dash: fails to install overwriting files from bash
Hi Raphael, On Tue, Jul 28, 2009 at 02:09:36AM +0200, Raphael Geissert wrote: Ah, right; I really need to get some sleep, the diversion looks fine. Although either you added it manually (did you?) or dash used to use local diversions (instead of setting the package name on the call to dpkg-divert). I'm quite sure I did not manually change diversions for /bin/sh. If I remember correctly I once had to change it back using dpkg-reconfigure dash after something set it to bash. Do you remember more or less since when you started using dash as /bin/sh? Not really. I seem to have installed dash 0.5.4-12 on Aug 26 2008, but I have probably been using it longer. It's just long ago. I think it was some rumors about dash speeding up the boot process that made me switch. Could it be that this was some debconf talk? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512381: xpdf: segfault on displaying PLRM.pdf
Package: xpdf-reader Version: 3.02-1.4 Severity: grave Justification: security $ wget http://www.adobe.com/products/postscript/pdfs/PLRM.pdf ... $ sha256sum PLRM.pdf 6b29e79e4ab64aaa61a3fb27a0f36838c01f2530362873ac316bdb493a1bab6b PLRM.pdf $ xpdf PLRM.pdf ... (scoll down a few pages) Segmentation fault (core dumped) $ gdb /usr/bin/xpdf.bin core ... Core was generated by `xpdf PLRM.pdf'. Program terminated with signal 11, Segmentation fault. [New process 3773] #0 0x2baa8263045a in XPutImage () from /usr/lib/libX11.so.6 (gdb) bt #0 0x2baa8263045a in XPutImage () from /usr/lib/libX11.so.6 #1 0x0049acaa in ?? () #2 0x00465686 in ?? () #3 0x004686a0 in ?? () #4 0x0049cbb8 in ?? () #5 0x0046451c in ?? () #6 0x004a630d in ?? () #7 0x004a68a2 in ?? () #8 0x0049b8a0 in ?? () #9 0x2baa81958a1f in XtCallCallbackList () from /usr/lib/libXt.so.6 #10 0x2baa81653bc5 in _XmDrawingAreaInput () from /usr/lib/libXm.so.2 #11 0x2baa8198dabe in ?? () from /usr/lib/libXt.so.6 #12 0x2baa8198ded9 in ?? () from /usr/lib/libXt.so.6 #13 0x2baa8198e5df in _XtTranslateEvent () from /usr/lib/libXt.so.6 #14 0x2baa8196632a in XtDispatchEventToWidget () from /usr/lib/libXt.so.6 #15 0x2baa819669f6 in ?? () from /usr/lib/libXt.so.6 #16 0x2baa81965b3b in XtDispatchEvent () from /usr/lib/libXt.so.6 #17 0x2baa81965ca3 in XtAppMainLoop () from /usr/lib/libXt.so.6 #18 0x004aa0e6 in ?? () #19 0x2baa832c91a6 in __libc_start_main () from /lib/libc.so.6 #20 0x00406329 in ?? () #21 0x7fff29be5178 in ?? () #22 0x001c in ?? () #23 0x0002 in ?? () #24 0x7fff29be5812 in ?? () #25 0x7fff29be5817 in ?? () #26 0x in ?? () (gdb) quit $ I do not know whether this has a security impact[1], so I go the safe way and report this as a security issue. If it turns out to be harmless, please downgrade the severity. Helmut [1] xpdf is often automatically launched by webbrowsers or even mozplugger. So if this is exploitable it allows user assisted code execution. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages xpdf depends on: ii xpdf-common 3.02-1.4 Portable Document Format (PDF) sui ii xpdf-reader 3.02-1.4 Portable Document Format (PDF) sui ii xpdf-utils3.02-1.4 Portable Document Format (PDF) sui xpdf recommends no packages. xpdf suggests no packages. Versions of packages xpdf-reader depends on: ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii lesstif2 1:0.95.0-2.1 OSF/Motif 2.1 implementation relea ii libc6 2.7-18 GNU C Library: Shared libraries ii libfreetype6 2.3.7-2FreeType 2 font engine, shared lib ii libgcc1 1:4.3.2-3 GCC support library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpaper1 1.1.23+nmu1library for handling paper charact ii libsm62:1.0.3-2 X11 Session Management library ii libstdc++64.3.2-3The GNU Standard C++ Library v3 ii libt1-5 5.1.2-3Type 1 font rasterizer library - r ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxp61:1.0.0.xsf1-2 X Printing Extension (Xprint) clie ii libxpm4 1:3.5.7-1 X11 pixmap library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii xpdf-common 3.02-1.4 Portable Document Format (PDF) sui -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514742: texlive-generic-extra: non-commercial license for barr/diagram.tex
Package: texlive-generic-extra Version: 2007.dfsg.15-1 Severity: serious Justification: Policy 2.3 $ head -n18 /usr/share/texmf-texlive/tex/latex/barr/diagram.tex % This should appear in a file named diagram.tex % Copyright 1988,1989 Michael Barr % Department of Mathematics and Statistics % McGill University % 805 Sherbrooke St., W % Montreal, Quebec, Canada % H3P 1S4 % % b...@triples.math.mcgill.ca % % All commercial rights reserved. May be freely distributed % and used with the following exceptions: % 1. No commercial use without explicit permission. % 2. It may not be used by any employee of a telephone % company. % 3. It may not be distributed without this notice. % % Last revised 91-05-04 $ dpkg -S /usr/share/texmf-texlive/tex/latex/barr/diagram.tex texlive-generic-extra: /usr/share/texmf-texlive/tex/latex/barr/diagram.tex $ apt-cache show texlive-generic-extra | grep ^Filename Filename: pool/main/t/texlive-extra/texlive-generic-extra_2007.dfsg.15-1_all.deb $ This file must not be distributed in main. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515074: FTBFS: builddepends db4.6, but links against db4.2 - unresolved symbols
Package: bind9 Version: 9.5.1.dfsg.P1-1 Severity: serious Justification: no longer builds from source gcc -fno-strict-aliasing -DDIG_SIGCHASE -O2 -I/usr/include/libxml2 -o .libs/named .libs/builtin.o .libs/client.o .libs/config.o .libs/control.o .libs/controlconf.o .libs/interfacemgr.o .libs/listenlist.o .libs/log.o .libs/logconf.o .libs/main.o .libs/notify.o .libs/query.o .libs/server.o .libs/sortlist.o .libs/statschannel.o .libs/tkeyconf.o .libs/tsigconf.o .libs/update.o .libs/xfrout.o .libs/zoneconf.o .libs/lwaddr.o .libs/lwresd.o .libs/lwdclient.o .libs/lwderror.o .libs/lwdgabn.o .libs/lwdgnba.o .libs/lwdgrbn.o .libs/lwdnoop.o .libs/lwsearch.o .libs/dlz_drivers.o .libs/sdlz_helper.o .libs/dlz_bdb_driver.o .libs/dlz_bdbhpt_driver.o .libs/dlz_filesystem_driver.o .libs/dlz_ldap_driver.o .libs/dlz_stub_driver.o unix/.libs/os.o ../../lib/lwres/.libs/liblwres.so ../../lib/dns/.libs/libdns.so -L/usr/lib -lgssapi_krb5 -lcrypto ../../lib/bind9/.libs/libbind9.so ../../lib/isccfg/.libs/libisccfg.so ../../lib/isccc/.libs/libisccc.so ../../lib/isc/.libs/libisc.so -ldb-4.2 -lldap -llber -lcap -lnsl -lpthread /usr/lib/libxml2.so .libs/dlz_bdb_driver.o: In function `bdb_opendb': dlz_bdb_driver.c:(.text+0x335): undefined reference to `db_create' dlz_bdb_driver.c:(.text+0x340): undefined reference to `db_strerror' dlz_bdb_driver.c:(.text+0x3bd): undefined reference to `db_strerror' dlz_bdb_driver.c:(.text+0x407): undefined reference to `db_strerror' .libs/dlz_bdb_driver.o: In function `bdb_create': dlz_bdb_driver.c:(.text+0x52b): undefined reference to `db_env_create' dlz_bdb_driver.c:(.text+0x53b): undefined reference to `db_strerror' dlz_bdb_driver.c:(.text+0x67d): undefined reference to `db_strerror' dlz_bdb_driver.c:(.text+0x6e0): undefined reference to `db_strerror' dlz_bdb_driver.c:(.text+0x799): undefined reference to `db_strerror' .libs/dlz_bdbhpt_driver.o: In function `bdbhpt_opendb': dlz_bdbhpt_driver.c:(.text+0x325): undefined reference to `db_create' dlz_bdbhpt_driver.c:(.text+0x330): undefined reference to `db_strerror' dlz_bdbhpt_driver.c:(.text+0x3ad): undefined reference to `db_strerror' dlz_bdbhpt_driver.c:(.text+0x3f7): undefined reference to `db_strerror' .libs/dlz_bdbhpt_driver.o: In function `bdbhpt_create': dlz_bdbhpt_driver.c:(.text+0x5ad): undefined reference to `db_env_create' dlz_bdbhpt_driver.c:(.text+0x5c1): undefined reference to `db_strerror' dlz_bdbhpt_driver.c:(.text+0x669): undefined reference to `db_strerror' collect2: ld returned 1 exit status make[3]: *** [named] Error 1 As can be seen there is -ldb-4.2 present. However libdb-dev is in build-depends, which depends on libdb4.6-dev. This would explain unresolved symbols. Hope this helps. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515086: texlive-generic-extra: non-commercial license for dvips/aurora/aurora.pro
Package: texlive-generic-extra Version: 2007.dfsg.16-1 Severity: serious Justification: Policy 2.3 Sorry, I found another one. :-( $ head -n9 /usr/share/texmf-texlive/dvips/aurora/aurora.pro %! % Aurora: Colour Separation for Level 1 PostScript. % Copyright: Graham Freeman, 1994. % gfree...@cs.adfa.oz.au % All Rights Reserved. % This program may not be used for commercial purposes without % the consent of the author. It may be freely transmitted % provided this authorship and copyright notice is retained % unmodified. $ dpkg -S /usr/share/texmf-texlive/dvips/aurora/aurora.pro texlive-generic-extra: /usr/share/texmf-texlive/dvips/aurora/aurora.pro $ apt-cache show texlive-generic-extra | grep ^Filename Filename: pool/main/t/texlive-extra/texlive-generic-extra_2007.dfsg.16-1_all.deb $ This again looks like a non-commercial license in main. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507487: does not rotate logfile /var/log/nagios2/nagios.log
If you want the original submitter to see your reply, you have to include nnn-submit...@bugs.debian.org in the list of recipients. Otherwise your mail will not be seen until a submitter wonders whether anyone noticed the report and lurks in to the website. Yes, debbugs is strange in this respect, but that way actually is sensible. does chown nagios:adm /var/log/nagios2/archives help? by default the user nagios does not have permission to write in /var/log/nagios2/archives That was my workaround and yes it works. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535805: console-setup must Pre-Depend on sharutils
Package: console-setup Version: 1.38 Severity: serious Justification: 3.9.1 console-setup uses uudecode in preinst or config, so it has to Pre-Depend on sharutils. This is my output for aptitude install console-setup: Preconfiguring packages ... /tmp/console-setup.config.229961: 5390: uudecode: not found gzip: stdin: unexpected end of file /tmp/console-setup.config.229961: 5391: uudecode: not found gzip: stdin: unexpected end of file /tmp/console-setup.config.229961: 5392: uudecode: not found gzip: stdin: unexpected end of file /tmp/console-setup.config.229961: 5393: uudecode: not found gzip: stdin: unexpected end of file /tmp/console-setup.config.229961: 5394: uudecode: not found gzip: stdin: unexpected end of file Selecting previously deselected package sharutils. (Reading database ... 178405 files and directories currently installed.) Unpacking sharutils (from .../sharutils_1%3a4.6.3-1_amd64.deb) ... Preparing to replace console-setup 1.36 (using .../console-setup_1.38_all.deb) ... Unpacking replacement console-setup ... Processing triggers for install-info ... install-info: warning: no info dir entry in `/usr/share/info/ispell.info.gz' install-info: warning: no info dir entry in `/usr/share/info/menu.info.gz' install-info: warning: no info dir entry in `/usr/share/info/enfuse.info.gz' install-info: warning: no info dir entry in `/usr/share/info/enblend.info.gz' Processing triggers for man-db ... Setting up sharutils (1:4.6.3-1) ... Setting up console-setup (1.38) ... Helmut -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages console-setup depends on: ii cdebconf [debconf-2.0]0.142 Debian Configuration Management Sy ii console-terminus 4.28-1 Fixed-width fonts for fast reading ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii sharutils 1:4.6.3-1 shar, unshar, uuencode, uudecode ii xkb-data 1.6-1 X Keyboard Extension (XKB) configu Versions of packages console-setup recommends: ii console-tools1:0.2.3dbs-65.1 Linux console and font utilities Versions of packages console-setup suggests: ii locales 2.9-18 GNU C Library: National Language ( ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538822: dash and local diversions
Hi, I am the submitter of the original dash upgrade bug. On Mon, Dec 27, 2010 at 09:27:29PM +, Adam D. Barratt wrote: diff --git a/en/issues.dbk b/en/issues.dbk index 9498399..83f1408 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -244,6 +244,34 @@ works for literalroot/literal. /para /section +section id=shell-diversions + titlePotential issues with diversions of /bin/sh/title + para +If you have previously added a local diversion for literal/bin/sh/literal, +or modified the literal/bin/sh/literal symlink to point to somewhere +other than literal/bin/bash/literal, then you may encounter problems +when upgrading the systemitem role=packagedash/systemitem or +systemitem role=packagebash/systemitem packages. +Note that this includes changes made by allowing other packages (for example +systemitem role=packagemksh/systemitem) to become the default system +shell by taking over literal/bin/sh/literal. + /para + para +If you encounter any such issues, please remove the local diversion and +ensure that the symlinks for both literal/bin/sh/literal and its +manual page point to the files provided by the systemitem role=package +bash/systemitem package and then +commanddpkg-reconfigure --force dash/command. + /para + programlisting +dpkg-divert --remove /bin/sh +dpkg-divert --remove /usr/share/man/man1/sh.1.gz + +ln -sf bash /bin/sh +ln -sf bash.1.gz /usr/share/man/man1/sh.1.gz + /programlisting +/section + /section section id=upgrade-to-2.6 condition=fixme I verified that the steps you proposed solved the issue on my system. Thank you very much for finally (after one and a half year) addressing the issue. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613666: openvpn-auth-radius: missing shared library dependencies on non-i386
Package: openvpn-auth-radius Version: 2.1-2 Severity: serious Justification: policy violation The binary packages built for architectures other than i386 lack all shared library dependencies. Compare for example: http://packages.debian.org/sid/amd64/openvpn-auth-radius (lists only openvpn) http://packages.debian.org/sid/i386/openvpn-auth-radius (lists libc6 for instance) This is obviously wrong. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613666: binary-arch target missing in rules file
tag 613666 pending thanks diff -u openvpn-auth-radius-2.1/debian/rules openvpn-auth-radius-2.1/debian/rules --- openvpn-auth-radius-2.1/debian/rules +++ openvpn-auth-radius-2.1/debian/rules @@ -22,7 +22,7 @@ build:patch-stamp dh $@ -binary: +binary binary-arch: dh $@ --until dh_auto_install install -m755 radiusplugin.so $(CURDIR)/debian/openvpn-auth-radius/usr/lib/openvpn/radiusplugin.so dh $@ --after dh_auto_install --until dh_fixperms diff -u openvpn-auth-radius-2.1/debian/changelog openvpn-auth-radius-2.1/debian/changelog --- openvpn-auth-radius-2.1/debian/changelog +++ openvpn-auth-radius-2.1/debian/changelog @@ -1,3 +1,9 @@ +openvpn-auth-radius (2.1-3) unstable; urgency=low + + * Fix binary-arch target. (Closes: #613666) + + -- Helmut Grohne h.gro...@cygnusnetworks.de Wed, 16 Feb 2011 15:34:49 +0100 + openvpn-auth-radius (2.1-2) unstable; urgency=low * Use quilt. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589549: fetch-crl: cronjob fails everytime
Package: fetch-crl Version: 2.8.5-1 Severity: grave Justification: renders package unusable # cat /etc/cron.d/fetch-crl # Cron job running by default every 6 hours. # The lock file can be enabled or disabled via a # service fetch-crl-cron start # chkconfig fetch-crl-cron on # Note the lock file not existing is success hence the the slightly odd logic # below. 22 */6 * * *root[ ! -f /var/lock/fetch-crl-cron ] || /usr/sbin/fetch-crl -r 20 -a 24 --quiet # /usr/sbin/fetch-crl -r 20 -a 24 --quiet; echo $? fetch-crl[17688]: 20100718T184545+0200 '/etc/grid-security/certificates' is not a directory or cannot be written 2 # Of course this crap gets delivered four times a day as email. Helmut -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33.2 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages fetch-crl depends on: ii openssl 0.9.8o-1 Secure Socket Layer (SSL) binary a ii wget 1.12-2 retrieves files from the web fetch-crl recommends no packages. fetch-crl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589550: fetch-crl: package fails to install
Package: fetch-crl Version: 2.8.5-1 Severity: grave Justification: renders package unusable $ aptitude install fetch-crl ... Setting up fetch-crl (2.8.5-1) ... update-rc.d: error: expected runlevel [0-9S] (did you forget . ?) usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing fetch-crl (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fetch-crl $ Helmut -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33.2 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages fetch-crl depends on: ii openssl 0.9.8o-1 Secure Socket Layer (SSL) binary a ii wget 1.12-2 retrieves files from the web fetch-crl recommends no packages. fetch-crl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589550: fetch-crl: package fails to install
On Sun, Jul 18, 2010 at 06:43:49PM +0200, Helmut Grohne wrote: Package: fetch-crl Version: 2.8.5-1 Severity: grave Justification: renders package unusable $ aptitude install fetch-crl ... Setting up fetch-crl (2.8.5-1) ... update-rc.d: error: expected runlevel [0-9S] (did you forget . ?) usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing fetch-crl (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fetch-crl $ This bug seems to only affect installations that are not yet converted to dependency based init. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589550: fetch-crl: package fails to install
Hi Mattias, On Tue, Jul 20, 2010 at 12:11:45PM +0200, Mattias Ellert wrote: sön 2010-07-18 klockan 18:43 +0200 skrev Helmut Grohne: Package: fetch-crl Version: 2.8.5-1 Are you sure about the version. I know this bug was present in the 2.8.4-1 package, but as far as I know it is fixed in 2.8.5-1. I am. This is the post install script in 2.8.5-1. Note the period at the end of the update-rc.d command: Same for me. Offending line is this one: update-rc.d fetch-crl-boot start 20 . stop 20 0 1 2 3 4 5 6 . /dev/null Notice that *no* runlevels are given for start. It looks like update-rc.d cannot handle this situation. # touch /etc/init.d/foo # update-rc.d foo start 99 . update-rc.d: warning: /etc/init.d/foo missing LSB information update-rc.d: see http://wiki.debian.org/LSBInitScripts update-rc.d: error: expected runlevel [0-9S] (did you forget . ?) usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. # The error from the fetch-crl postinst looks very similar. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589549: fetch-crl: cronjob fails everytime
Hi Mattias, On Tue, Jul 20, 2010 at 01:14:11PM +0200, Mattias Ellert wrote: The developers considers this to be an error rather than a warning. Do you not consider this to be a valid error message? Would you rather see it fail silently? I consider this to be a valid error message and it is good otherwise I would not have known that the package does not work at all. Could you please explain why you consider the output of an error message to render the package unusable? The package simply does nothing except for generating this error message four times a day. Especially it does not update any crls. I should probably have been more precise about this. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589550: fetch-crl: package fails to install
Hi Mattias and sysvinit maintainers, On Tue, Jul 20, 2010 at 02:41:39PM +0200, Mattias Ellert wrote: Would this do the right thing? update-rc.d fetch-crl-boot stop 20 0 1 2 3 4 5 6 . /dev/null The first thing I can tell is that this line does not fail, so it would definitely lower the severity or close the bug. On the other hand I do not know whether this is what you intend. This way update-rc.d does not touch startup links for fetch-crl-boot. So if a user messed them up, the update-rc.d will not fix it. I would not exclude the possibility of a bug in update-rc.d either. Maybe nobody tried to add a script that is only stopped but never started, but update-rc.d could be supporting the syntax you (or some dh script?) used. I therefore pulled in the sysvinit maintainers. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589549: fetch-crl: cronjob fails everytime
severity 589549 normal thanks On Wed, Jul 21, 2010 at 08:49:50AM +0200, Mattias Ellert wrote: The package works fine if the /etc/grid-security/certificates directory exists and contains *.crl_url files. So saying it doesn't work at all is not right. It works fine for me doing what it was designed to do. But maybe you expected it to work differently? Maybe the package could contain a little bit of documentation explaining this. The package description merely says that some CRLs would be fetched periodically. To me it indeed looked like the package would come with sane defaults. Indeed having a package which - after installation - would just keep ssl revocations recent for web browsers would be a great addition. Such a package should imho be recommended by ca-certificates. As far as I understand it now fetch-crl aims to be something slightly different. Yes, If there are no *.crl_url files in the directory configured in /etc/fetch-crl.conf (by default /etc/grid-security/certificates), there is nothing for the cronjob to do and hence it does nothing as expected. This is not a bug, but the intended behaviour. Uhm, so if the package does not work without prior configuration, the cron job should be disabled by default. Since it does nothing useful prior to being configured, it should simply not be run. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591748: kdelibs-data: upgrade tries to overwrite files from kdelibs5-data
Package: kdelibs-data Version: 4:3.5.10.dfsg.1-4 Severity: grave Justification: renders package unusable ... Unpacking replacement kdelibs-data ... dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-4_all.deb (--unpack): trying to overwrite '/usr/share/doc/kde/HTML/en/common/6.png', which is also in package kdelibs5-data 4:4.4.5-1 dpkg-deb: subprocess paste killed by signal (Broken pipe) ... $ dpkg -l kdelibs-data kdelibs5-data ... ii kdelibs-data4:3.5.10.dfsg.1-3 core shared data for all KDE applications ii kdelibs5-data 4:4.4.5-1 core shared data for all KDE Applications $ Maybe a missing conflict? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591748: Processed (with 1 errors): oops report already exists
forcemerge 591609 591748 thanks Can someone else merge the other bug? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591748: oops report already exists
forcemerge 591609 591719 591748 thanks But big WTF: Why did apt-listbugs not display the other bugs?! Why did reportbug forget to ask me to check for duplicates?! Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
Package: libgssapi-krb5-2 Version: 1.8.3+dfsg-2 Severity: grave File: /usr/lib/libgssapi_krb5.so.2 My system uses kerberos to authenticate users to ssh. After upgrading a server to squeeze logging in is no longer possible (this could satisfy critical severity). Unfortunately debugging this turned out to be harder than expected, because gssapi is not very precise about what the problem really is. All I can do is post the logs. Logging in from a (lenny) client that could log in to the same system before the upgrade: $ ssh -vvv somemachine ... debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Unspecified GSS failure. Minor code may provide more information Generic error (see e-text) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method ... Of course I also turned on debugging on the server: ... Nov 25 13:43:46 someserver sshd[5661]: Set /proc/self/oom_adj to 0 Nov 25 13:43:46 someserver sshd[5661]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Nov 25 13:43:46 someserver sshd[5661]: debug1: inetd sockets after dupping: 3, 3 Nov 25 13:43:46 someserver sshd[5661]: Connection from 10.0.82.2 port 36317 Nov 25 13:43:46 someserver sshd[5661]: debug1: Client protocol version 2.0; client software version OpenSSH_5.1p1 Debian-5 Nov 25 13:43:46 someserver sshd[5661]: debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH* Nov 25 13:43:46 someserver sshd[5661]: debug1: Enabling compatibility mode for protocol 2.0 Nov 25 13:43:46 someserver sshd[5661]: debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-5+b1 Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: initializing for root Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: setting PAM_RHOST to reverse.dns.of.somemachine Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: setting PAM_TTY to ssh Nov 25 13:43:46 someserver sshd[5661]: Failed none for root from 10.0.82.2 port 36317 ssh2 Nov 25 13:43:46 someserver sshd[5661]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo such file or directory\n Nov 25 13:43:46 someserver sshd[5661]: debug1: Got no client credentials ... The origin of the Unspecified GSS failure. message is src/lib/gssapi/mechglue/g_dsp_status.c which is a generic error handler. The Got no client credentials message originates from sshd itself gss-serv.c in ssh_gssapi_accept_ctx after finding that an error occured. Any other information needed? Do you have any ideas for debugging? Helmut -- System Information: Debian Release: squeeze/sid APT prefers squeeze-volatile APT policy: (500, 'squeeze-volatile'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgssapi-krb5-2 depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libk5crypto31.8.3+dfsg-2 MIT Kerberos runtime libraries - C ii libkeyutils11.4-1Linux Key Management Utilities (li ii libkrb5-3 1.8.3+dfsg-2 MIT Kerberos runtime libraries ii libkrb5support0 1.8.3+dfsg-2 MIT Kerberos runtime libraries - S libgssapi-krb5-2 recommends no packages. Versions of packages libgssapi-krb5-2 suggests: pn krb5-docnone (no description available) ii krb5-user 1.8.3+dfsg-2 Basic programs to authenticate usi -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: krb5.conf
I was asked to show a krb5.conf for the ssh server. See it below.
Helmut
$ cat /etc/krb.conf
[libdefaults]
default_realm = REALM.DOMAIN.EXAMPLE
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
REALM.DOMAIN.EXAMPLE = {
kdc = kdchost.domain.example:88
admin_server = kdchost.domain.example:749
default_domain = domain.example
}
[domain_realm]
.domain.example = REALM.DOMAIN.EXAMPLE
domain.example = REALM.DOMAIN.EXAMPLE
[login]
krb4_convert = true
krb4_get_tickets = false
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: No such file or directory: /usr/lib/krb5/plugins/authdata
Running strace on ssh revealed the almost immediately before emiting the Unspecified GSS failure. Minor code may provide more information\nNo such file or directory\n it tries to open a directory /usr/lib/krb5/plugins/authdata which does not exist on my system (and is not contained in any package). Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: No such file or directory: /usr/lib/krb5/plugins/authdata
On Thu, Nov 25, 2010 at 02:56:46PM +0100, Helmut Grohne wrote: Running strace on ssh revealed the almost immediately before emiting the Unspecified GSS failure. Minor code may provide more information\nNo such file or directory\n it tries to open a directory /usr/lib/krb5/plugins/authdata which does not exist on my system (and is not contained in any package). Actually this seems unrelated. When I create the missing directory (as empty directory) the visible behaviour is not changed in any way. So the No such file or directory message does not seem to originate from some system call, but from some userspace deciding that this is the right message. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: ITP: openvpn-auth-radius -- OpenVPN RADIUS authentication module
retitle 556460 ITP: openvpn-auth-radius -- OpenVPN RADIUS authentication module owner 556460 ! thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604925: closed by Sam Hartman hartm...@debian.org (Bug#604925: fixed in krb5 1.9+dfsg~beta2-1)
On Sat, Dec 11, 2010 at 01:33:05AM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the libgssapi-krb5-2 package: #604925: Squeeze krb5 fails to work with Open Directory KDC tickets It has been closed by Sam Hartman hartm...@debian.org. I'd like to confirm that the solution indeed solves my issue. After installing the new experimental packages on sequeeze authentication works again. Thank you very much for all the help to work out this issue and especially for finally fixing it. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650524: insserv: please include +pdnsd in $named in /etc/insserv.conf
reassign 650524 pdnsd 1.2.7-par-1.2 found 650524 1.2.8-par-2 severity 650524 serious user initscripts-ng-de...@lists.alioth.debian.org usertags 650524 incorrect-dependency thanks Thanks for your quick and insightful answer! On Wed, Nov 30, 2011 at 07:02:41PM +0100, Petter Reinholdtsen wrote: Actually, the cause is that the pdns package fail to list its virtual facilities in /etc/insserv.conf.d/. The central register in /etc/insserv.conf is not scalable, and thus the responsibility to update the virtual facilities have been moved to the individual package maintainers. See URL: http://wiki.debian.org/LSBInitScripts/DebianVirtualFacilities for some information on this mechanism. I totally agree. As of this writing a total of 14 packages actually use /etc/insserv.conf.d. What a shame. Interestingly unbound is one of them, so you can remove unbound from $named, right? So what about the others? * bind9: not using insserv.conf.d, no bug report * dnsmasq: not using insserv.conf.d, no bug report * lwresd: not using insserv.conf.d, no bug report Do you want me to file wishlist bugs for those packages? The bug report for powerdns is URL: http://bugs.debian.org/585966 and it should be fixed in testing and unstable. Thanks for pointing out. If this fix is insufficient, I suggest reassigning this bug to pdns and follow up on the problem there. If the fix is already in place, I suggest we just close it as fixed. Sure. I reassigned the bug report. I also verified that unstable (1.2.8-par-2) is still affected. For the pdnsd maintainer: pdnsd should ship a file /etc/insserv.conf.d/pdnsd containing the line $named pdnsd. (Thanks to Petter Reinholdtsen for explaining this to me.) Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650544: onak: does not rotate /var/log/onak.log
Package: onak Version: 0.3.8-1 Severity: serious Justification: Policy 10.8 The onak package creates /var/log/onak.log, but this file is never rotated. Instead it grows indefinitely. Rotation is a must according to policy section 10.8. The policy also lists an example logrotate config file. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650544: onak: does not rotate /var/log/onak.log
On Wed, Nov 30, 2011 at 11:55:19AM -0800, Jonathan McDowell wrote: The version of onak in testing/unstable is 0.4.0-1 and already has a logrotate config file in /etc/logrotate.d/onak. Thanks for your quick reply. I will take that logrotate file then. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644121: dovecot-core: destroys user configuration from dovecot-common
tags 644121 +unreproducible thanks Hi Ian, On Sun, Oct 02, 2011 at 06:59:46PM -0700, Ian Zimmerman wrote: I was upgrading via aptitude: [REMOVE, NOT USED] dovecot-common [INSTALL, DEPENDENCIES] dovecot-core [UPGRADE] dovecot-imapd 1:2.0.13-1.1 - 1:2.0.15-1 This resulted in all my local configuration in /etc/dovecot/ being trashed, and overwritten with the shipped dovecot-core versions. I attempted to reproduce your problem. These are the steps I used to reproduce: 1) pbuilder --login 2) replace sources.list with the following line: deb http://snapshot.debian.org/archive/debian/20110623T151535Z/ sid main 3) update and install dovecot-imapd 4) modify /etc/dovecot/dovecot.conf 5) replace sources.list with the original 6) aptitude update aptitude safe-upgrade 7) notice that my changes are preserved. This procedure was done using precisely the same versions (1:2.0.13-1.1 and 1:2.0.15-1). Apparently ucf doesn't handle this situation well (a package being renamed), so some manual hacks in the postinst are in order to prevent this from happening. You are correct in that ucf does not handle this situation well. However the package maintainer has foreseen this and has added his own hooks for precisely this situation. Can you give any other hint on how to reproduce the problem? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#411019: pidentd does not work with /var/run mounted as a tmpfs file system
On Thu, Feb 15, 2007 at 07:44:57PM +1100, John Zaitseff wrote: The solution is to include a simple /etc/init.d/pidentd script, as included below, and to link to it as /etc/rcS.d/S20pidentd (although a different number may be more appropriate). The script: #!/bin/sh [ -x /usr/sbin/identd ] || exit 0 mkdir -p /var/run/identd chown identd:nogroup /var/run/identd chmod 755 /var/run/identd The script needs to be a bit longer. NMU attached. Helmut diff -u pidentd-3.0.19.ds1/debian/changelog pidentd-3.0.19.ds1/debian/changelog --- pidentd-3.0.19.ds1/debian/changelog +++ pidentd-3.0.19.ds1/debian/changelog @@ -1,3 +1,12 @@ +pidentd (3.0.19.ds1-5.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix pidentd does not work with /var/run mounted as a tmpfs file +system apply the solution proposed by John Zaitseff adding an init +script (Closes: #411019) + + -- Helmut Grohne hel...@subdivi.de Fri, 02 Dec 2011 19:13:18 +0100 + pidentd (3.0.19.ds1-5) unstable; urgency=low * Priority is optional; closes: #416570, #492060 diff -u pidentd-3.0.19.ds1/debian/rules pidentd-3.0.19.ds1/debian/rules --- pidentd-3.0.19.ds1/debian/rules +++ pidentd-3.0.19.ds1/debian/rules @@ -89,6 +89,7 @@ dh_installexamples dh_installmenu dh_installman + dh_installinit ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) dh_strip endif only in patch2: unchanged: --- pidentd-3.0.19.ds1.orig/debian/pidentd.init +++ pidentd-3.0.19.ds1/debian/pidentd.init @@ -0,0 +1,20 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: pidentd-run-dir +# Required-Start:$local_fs +# Required-Stop: $local_fs +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# Short-Description: setup for pidentd +# Description: create /var/run/identd for pidentd +### END INIT INFO + +[ -x /usr/sbin/identd ] || exit 0 + +case $1 in + start) + mkdir -p /var/run/identd + chown identd:nogroup /var/run/identd + chmod 755 /var/run/identd + ;; +esac
Bug#411019: pidentd does not work with /var/run mounted as a tmpfs file system
On Fri, Dec 02, 2011 at 09:28:02PM +0100, Helmut Grohne wrote: The script needs to be a bit longer. NMU attached. As it turns out even that was too simple. Thanks to Jan Luebbe for the pointers. Updated NMU diff. Helmut diff -u pidentd-3.0.19.ds1/debian/changelog pidentd-3.0.19.ds1/debian/changelog --- pidentd-3.0.19.ds1/debian/changelog +++ pidentd-3.0.19.ds1/debian/changelog @@ -1,3 +1,12 @@ +pidentd (3.0.19.ds1-5.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix pidentd does not work with /var/run mounted as a tmpfs file +system apply the solution proposed by John Zaitseff adding an init +script (Closes: #411019) + + -- Helmut Grohne hel...@subdivi.de Fri, 02 Dec 2011 19:13:18 +0100 + pidentd (3.0.19.ds1-5) unstable; urgency=low * Priority is optional; closes: #416570, #492060 diff -u pidentd-3.0.19.ds1/debian/rules pidentd-3.0.19.ds1/debian/rules --- pidentd-3.0.19.ds1/debian/rules +++ pidentd-3.0.19.ds1/debian/rules @@ -89,6 +89,7 @@ dh_installexamples dh_installmenu dh_installman + dh_installinit ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) dh_strip endif only in patch2: unchanged: --- pidentd-3.0.19.ds1.orig/debian/pidentd.init +++ pidentd-3.0.19.ds1/debian/pidentd.init @@ -0,0 +1,26 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: pidentd-run-dir +# Required-Start:$remote_fs +# Required-Stop: $remote_fs +# Default-Start: S +# Default-Stop: +# Short-Description: setup for pidentd +# Description: create /var/run/identd for pidentd +### END INIT INFO + +[ -x /usr/sbin/identd ] || exit 0 + +case $1 in + start|restart|reload|force-reload) + mkdir -p /var/run/identd + chown identd:nogroup /var/run/identd + chmod 755 /var/run/identd + ;; + stop) + ;; + status) + test -d /var/run/identd || exit 4 + exit 0 + ;; +esac
Bug#411019: pidentd does not work with /var/run mounted as a tmpfs file system
On Fri, Dec 02, 2011 at 10:28:00PM +0100, Helmut Grohne wrote: As it turns out even that was too simple. Thanks to Jan Luebbe for the pointers. Updated NMU diff. Also silence that warning about update-rc.d for legacy systems. See http://piuparts.debian.org/sid/initdscript_lsb_header_issue.html. Thanks to jan Luebbe. Updated NMU diff. Helmut diff -u pidentd-3.0.19.ds1/debian/changelog pidentd-3.0.19.ds1/debian/changelog --- pidentd-3.0.19.ds1/debian/changelog +++ pidentd-3.0.19.ds1/debian/changelog @@ -1,3 +1,12 @@ +pidentd (3.0.19.ds1-5.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix pidentd does not work with /var/run mounted as a tmpfs file +system apply the solution proposed by John Zaitseff adding an init +script (Closes: #411019) + + -- Helmut Grohne hel...@subdivi.de Fri, 02 Dec 2011 19:13:18 +0100 + pidentd (3.0.19.ds1-5) unstable; urgency=low * Priority is optional; closes: #416570, #492060 diff -u pidentd-3.0.19.ds1/debian/rules pidentd-3.0.19.ds1/debian/rules --- pidentd-3.0.19.ds1/debian/rules +++ pidentd-3.0.19.ds1/debian/rules @@ -89,6 +89,7 @@ dh_installexamples dh_installmenu dh_installman + dh_installinit -- start 20 S . stop 20 . ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) dh_strip endif only in patch2: unchanged: --- pidentd-3.0.19.ds1.orig/debian/pidentd.init +++ pidentd-3.0.19.ds1/debian/pidentd.init @@ -0,0 +1,26 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: pidentd-run-dir +# Required-Start:$remote_fs +# Required-Stop: $remote_fs +# Default-Start: S +# Default-Stop: +# Short-Description: setup for pidentd +# Description: create /var/run/identd for pidentd +### END INIT INFO + +[ -x /usr/sbin/identd ] || exit 0 + +case $1 in + start|restart|reload|force-reload) + mkdir -p /var/run/identd + chown identd:nogroup /var/run/identd + chmod 755 /var/run/identd + ;; + stop) + ;; + status) + test -d /var/run/identd || exit 4 + exit 0 + ;; +esac
Bug#633433: slidentd: FTBFS after package change of libowfat
On Sun, Jul 10, 2011 at 11:49:50AM +0200, Roland Stigge wrote: Build-Depends: libowfat-dietlibc-dev Build-Conflicts: libowfat-dev Thanks for the fix. Tested. NMU attached. Also solves #634416. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633433: slidentd: FTBFS after package change of libowfat
On Sat, Dec 03, 2011 at 10:42:08AM +0100, Helmut Grohne wrote: Thanks for the fix. Tested. NMU attached. Also solves #634416. Now with th patch. %-) Helmut diff -u slidentd-1.0.0/debian/control slidentd-1.0.0/debian/control --- slidentd-1.0.0/debian/control +++ slidentd-1.0.0/debian/control @@ -2,7 +2,8 @@ Section: net Priority: extra Maintainer: David D. Smith davidsm...@acm.org -Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dev +Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dietlibc-dev +Build-Conflicts: libowfat-dev Standards-Version: 3.7.2 Package: slidentd diff -u slidentd-1.0.0/debian/changelog slidentd-1.0.0/debian/changelog --- slidentd-1.0.0/debian/changelog +++ slidentd-1.0.0/debian/changelog @@ -1,3 +1,11 @@ +slidentd (1.0.0-6.2) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS after package change of libowfat changed build depends. Thanks +to Roland Stigge (Closes: #633433) + + -- Helmut Grohne hel...@subdivi.de Sat, 03 Dec 2011 10:31:13 +0100 + slidentd (1.0.0-6.1) unstable; urgency=medium * Non-maintainer upload.
Bug#650798: /var/run is now on tmpfs
Package: slidentd Version: 1.0.0-6.1 Severity: serious Justification: 9.3.2 Exactly the same thing as http://bugs.debian.org/411019 Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633433: slidentd: FTBFS after package change of libowfat
Extended NMU for #650798 as well. Helmut diff -u slidentd-1.0.0/debian/control slidentd-1.0.0/debian/control --- slidentd-1.0.0/debian/control +++ slidentd-1.0.0/debian/control @@ -2,7 +2,8 @@ Section: net Priority: extra Maintainer: David D. Smith davidsm...@acm.org -Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dev +Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dietlibc-dev +Build-Conflicts: libowfat-dev Standards-Version: 3.7.2 Package: slidentd diff -u slidentd-1.0.0/debian/changelog slidentd-1.0.0/debian/changelog --- slidentd-1.0.0/debian/changelog +++ slidentd-1.0.0/debian/changelog @@ -1,3 +1,14 @@ +slidentd (1.0.0-6.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS after package change of libowfat changed build depends. Thanks +to Roland Stigge (Closes: #633433) + * Fix FTBFS: (.text+0x15): undefined reference to `__ctype_b_loc' +unreproducible after previous fix (Closes: #634416) + * Fix: /var/run is now on tmpfs add init script (Closes: #650798) + + -- Helmut Grohne hel...@subdivi.de Sat, 03 Dec 2011 11:16:33 +0100 + slidentd (1.0.0-6.1) unstable; urgency=medium * Non-maintainer upload. diff -u slidentd-1.0.0/debian/rules slidentd-1.0.0/debian/rules --- slidentd-1.0.0/debian/rules +++ slidentd-1.0.0/debian/rules @@ -54,6 +54,7 @@ dh_testroot dh_installchangelogs CHANGES dh_installdocs + dh_installinit -- start 20 S . stop 20 . dh_install dh_link dh_strip only in patch2: unchanged: --- slidentd-1.0.0.orig/debian/slidentd.init +++ slidentd-1.0.0/debian/slidentd.init @@ -0,0 +1,24 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: slidentd-run-dir +# Required-Start:$remote_fs +# Required-Stop: $remote_fs +# Default-Start: S +# Default-Stop: +# Short-Description: setup for slidentd +# Description: create /var/run/slidentd for slidentd +### END INIT INFO + +[ -x /usr/sbin/slidentd ] || exit 0 + +case $1 in + start|restart|reload|force-reload) + mkdir -p /var/run/slidentd + ;; + stop) + ;; + status) + test -d /var/run/slidentd || exit 4 + exit 0 + ;; +esac
Bug#650808: frown: OOM on compiling any remotely valid grammer
Package: frown
Version: 0.6.1-11
Severity: grave
Justification: renders package unusable
I noticed that frown would no longer translate my projects, because it
would eat too much memory. So I tried to come up with smaller grammers.
I arrived at
$ cat test.lg
%{
}
$
Now this didn't eat any less memory, but maybe 1G is too little.
Thankfully Tolimar volunteered to test this with 8G and suprisingly it
ate those 8G as well. I can only conclude that frown is no longer able
to compile any grammer in any reasonable amount of memory. This renders
the package unusable for any normal user.
Helmut
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Versions of packages frown depends on:
ii libc6 2.13-21
ii libffi5 3.0.10-3
ii libgmp10 2:5.0.2+dfsg-2
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650815: src:xtrs: FTBFS (sparc): debug.c:695:11: error: lvalue required as left operand of assignment
Package: src:xtrs Version: 4.9c-3.3 Severity: serious Justification: FTBFS Excerpt from build log: | debian/rules build | html2text -nobs -style pretty cpmutil.html cpmutil.txt | html2text -nobs -style pretty dskspec.html dskspec.txt | html2text -nobs -style pretty debian/trs80faq.html debian/trs80faq.txt | dh_testdir | for F in \ | fakerom.hex \ | xtrsrom4p.hex \ | ; do \ | touch $F; \ | done | /usr/bin/make DEBUG=-Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT PREFIX=/usr \ | ENDIAN=-Dbig_endian | make[1]: Entering directory `/build/buildd-xtrs_4.9c-3.3-sparc-ZlP4tI/xtrs-4.9c' | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o z80.o z80.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o main.o main.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o load_cmd.o load_cmd.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o load_hex.o load_hex.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o trs_memory.o trs_memory.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o trs_keyboard.o trs_keyboard.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o error.o error.c | cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT -Dbig_endian -DDEFAULT_ROM='/usr/local/lib/xtrs/level2rom.hex' -DDEFAULT_ROM3='/usr/local/lib/xtrs/romimage.m3' -DDEFAULT_ROM4P='/usr/local/lib/xtrs/romimage.m4p' -DREADLINE -DDISKDIR='.' -I/usr/include/X11 -DAPPDEFAULTS='/usr/X11/lib/X11/app-defaults' -DKBWAIT -DHAVE_SIGIO -c -o debug.o debug.c | debug.c: In function 'debug_shell': | debug.c:695:11: error: lvalue required as left operand of assignment | make[1]: *** [debug.o] Error 1 | make: *** [build-stamp] Error 2 See https://buildd.debian.org/status/fetch.php?pkg=xtrsarch=sparcver=4.9c-3.3stamp=1316939781 for full log. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623623: upgrade 623623
severity 623623 serious thanks pbuilder cannot be used without pbuilder --create and pbuilder --create uses dpkg-architecture which is contained in dpkg-dev. So this is a missing dependency which should be serious according to policy 7.2: | The Depends field should be used if the depended-on package is required | for the depending package to provide a significant amount of | functionality. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi,
On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote:
This same issue also happens with cp(1) from coreutils.
I verified that this statement is wrong.
1) The coreutils actually check the return value of close which can be
seen on copy.c. It has precisely two calls to close and both are
checked.
2) I created a simple LD_PRELOAD library to make close fail (attached).
Running cp foo bar with this library preloaded (i.e. failing any close
with EIO) I get the following output and return value 1:
cp: closing `foo': Input/output error
This is correct behaviour. Since scp invokes cp for local copies, the
test originally submitted testcase
Michal Suchanek wrote earlier:
$ scp /scratch/junk . ; echo $?
0
$ rm junk
is wrong as well. This command would output a similar error message to
the one above. However this does not invalidate the bug immediately. To
be sure, remote transfers need to be checked as well.
A quick grep of the openssh source indicates that checking close is
overrated. Who needs errors anyway? I want that it works!!1!eleven
Helmut
CFLAGS ?= -Wall -Wextra -W -pedantic -fPIC -rdynamic
LIBS=-lc -ldl
%.o:%.c
${CC} ${CFLAGS} -c $ -o $@
closefail.so:closefail.o
${CC} ${CFLAGS} -shared -o $@ $^ ${LIBS}
closefail.o:closefail.c
#include unistd.h
#include errno.h
#include string.h
#include stdlib.h
int close(int fd) {
/* just leak the fd */
static int failcount=0;
if(failcount == 0) {
const char *p;
p = getenv(CLOSEFAIL);
if(p != NULL)
failcount = atoi(p);
}
failcount -= 1;
if(failcount == 1) {
errno = EIO;
return -1;
}
if(failcount 1)
failcount = 1;
return 0;
}
Bug#609851: summary
This is a summary for those attempting to squash rc bugs. As of 4.2.2-1 /sbin/dhclient-script implements a set_hostname function that unconditionally updates the host name if request host-name is set in /etc/dhcp/dhclient.conf which is the default. This means that in a default setup of dhcp any dhcp server can change the hostname. It is known that this break (among other things) X11. It also contradicts the documentation (man dhcp-options) This option is only honored by dhclient-script(8) if the hostname for the client machine is not set. In my experience many packages assume that the hostname is stable. The most prominent example is X11. It is imho not reasonable to change this assumption without at this point. The default for a newly installed isc-dhcp-client should be not to update the hostname from a dhcp server sent host-name. In order to not break current setup this requires a change in the implementation that obeys the documentation quoted above. The following patch will implement the documented behaviour: --- debian/dhclient-script.linux2011-12-03 23:53:36.0 +0100 +++ debian/dhclient-script.linux.new2011-12-03 23:56:34.0 +0100 @@ -90,12 +90,11 @@ if [ -n $new_host_name ]; then current_hostname=$(hostname) -# current host name is empty, '(none)' or 'localhost' or differs from new one from DHCP +# current host name is empty, '(none)' or 'localhost' if [ -z $current_hostname ] || [ $current_hostname = '(none)' ] || - [ $current_hostname = 'localhost' ] || - [ $new_host_name != $current_hostname ]; then -hostname $new_host_name + [ $current_hostname = 'localhost' ]; then + hostname $new_host_name fi fi } Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477751: tackling this bug
tags 477751 +patch
thanks
Hi,
I finally took the opportunity to work on this bug. As Joey Hess pointed
out the first thing to change is update-catalog. On the other hand
surely the debhelper snipped *will* have to change, because it
unconditionally removes a file in /etc. So let us have a look at the
current snippet:
$ cat /usr/share/debhelper/autoscripts/postinst-sgmlcatalog
if [ $1 = configure ]; then
rm -f #CENTRALCAT#
for ordcat in #ORDCATS#; do
update-catalog --quiet --add #CENTRALCAT# ${ordcat}
done
update-catalog --quiet --add --super #CENTRALCAT#
fi
$
So there are two places where we do not preserve user changes.
1) Changes to the root catalog. This is due to the update-catalog --quiet --add
--super. It is actually easy to solve, because it is a no-op if the catalog is
already added. Thus it should only be invoked when installing the package. It
should not be invoked when upgrading the package. A simple check on $2 being
empty solves this issue.
2) Changes to the central catalog of the package. This is more tricky
and requires changes to update-catalog. There needs to be some way to
remember what catalogs the user disabled. To achieve this I changed the
behaviour of --remove (see attached debdiff). It will now comment out
catalogs to be removed. Now removing that catalog is no longer a good
thing to do. Instead updatew-catalog needs to do something more clever.
This is where update-catalog --update #CENTRALCAT# #ORDCATS# comes in.
It will walk over the central catalog removing any (disabled or not)
entries not found in the passed #ORDCATS#. It will not touch entries
already present, but add new ones. So this should solve the issue.
The new snipped would look like this:
$ cat postinst-sgmlcatalog.new
if [ $1 = configure ]; then
update-catalog --quiet --update #CENTRALCAT# #ORDCATS#
if [ -z $2 ]; then
update-catalog --quiet --add --super #CENTRALCAT#
fi
fi
$
So what are your thoughts on this?
Helmut
diff -Nru sgml-base-1.26+nmu1/debian/changelog
sgml-base-1.26+nmu2/debian/changelog
--- sgml-base-1.26+nmu1/debian/changelog2010-07-18 14:39:38.0
+0200
+++ sgml-base-1.26+nmu2/debian/changelog2011-12-04 12:50:15.0
+0100
@@ -1,3 +1,10 @@
+sgml-base (1.26+nmu2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Rework update-catalog in a way that empowers debhelper to fix #477751.
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 04 Dec 2011 12:49:07 +0100
+
sgml-base (1.26+nmu1) unstable; urgency=low
* Non-maintainer upload
diff -Nru sgml-base-1.26+nmu1/tools/update-catalog
sgml-base-1.26+nmu2/tools/update-catalog
--- sgml-base-1.26+nmu1/tools/update-catalog2004-06-21 00:04:49.0
+0200
+++ sgml-base-1.26+nmu2/tools/update-catalog2011-12-04 12:41:06.0
+0100
@@ -30,6 +30,7 @@
use vars qw( $super );
use vars qw( $template );
use vars qw( $type );
+use vars qw( $update );
## --
while ( $ARGV[0] =~ m/^--/ )
@@ -44,6 +45,10 @@
{
$remove = 1;
}
+elsif ( $_ eq '--update' )
+{
+ $update = 1;
+}
elsif ( $_ eq '--quiet' )
{
$quiet = 1;
@@ -83,10 +88,14 @@
}
## --
-if ( $add || $remove )
+if ( $add || $remove || $update )
{
if ( $super )
{
+ if ( $update ) {
+ print Updating the super catalog is not supported.\n;
+ exit 1;
+ }
$catalog = '/etc/sgml/catalog';
}
else
@@ -104,6 +113,21 @@
}
## --
+if ( $add + $remove + $update != 1)
+{
+print Huh? You have to use precisely one out of --add --remove and
--update.\n;
+exit 1;
+}
+if ( $update )
+{
+print Updating $catalog...\n
+ unless $quiet;
+read_catalog_updating_argv;
+write_catalog;
+exit 0;
+}
+
+## --
$entry = shift( @ARGV );
## --
@@ -115,13 +139,6 @@
}
## --
-if ( $add == $remove )
-{
-print Huh? You have to use --add or --remove (not both).\n;
-exit 1;
-}
-
-## --
print STDERR $name: test mode - catalog file will not be updated\n
if $debug ! $quiet;
@@ -131,8 +148,7 @@
print Adding entry $entry to catalog $catalog...\n
unless $quiet;
-read_catalog_without_entry;
-add_entry;
+read_catalog_enabling_entry;
write_catalog;
}
elsif ( $remove )
@@ -140,7 +156,7 @@
print Removing entry $entry from catalog $catalog...\n
unless $quiet;
-read_catalog_without_entry
Bug#477751: tackling this bug
Hi Joey, thanks for your quick answer. On Sun, Dec 04, 2011 at 05:25:42PM -0400, Joey Hess wrote: I haven't considered all the implications... Will the new sgml-base work ok with the old postinst? With mixtures of the new and old postinsts? Good question! Let's look at them individually. The old postinst just uses --add which is idempotent (old and new). So this should all work out. The old postrm just does rm and the old prerm does --remove on the root catalog. This should work as well (even though it now leaves a comment). The prerm however needs updating as well, as it should no longer --remove on upgrade (as we can no longer --add on upgrade). I'm happy moving ahead with the debhelper changes as soon as sgml-base is in unstable. Good. This would also necessitate a versioned dependency on sgml-base. Do you want a diff for debhelper? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi Michal, On Mon, Dec 05, 2011 at 12:41:21AM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Sat Dec 03 17:33:04 +0100 2011: Hi, On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote: This same issue also happens with cp(1) from coreutils. I verified that this statement is wrong. It is not. This probably depends on the point of view. From the current context it is not clear what this issue is. Please read the analysis in the latter message. I think we should split this up in two issues: 1) Not checking the return value of close(). This is a very real bug in openssh, but not in coreutils (seem my analysis). 2) Not fsyncing the files before closeing them. It is not the job of cp nor scp to guarantee that any file has reached the disk. So this bug will not be fixed. If it was their job, tools like sync(1) would not exist in the first place. If it was, you could file this bug report against every single package handling files in the archive (except for a handful). Since that would be insane, I simply dropped this request in my previous reply. I should have made this more explicit. Can we now ignore 2) and concentrate on 1)? A quick grep of the openssh source indicates that checking close is overrated. Who needs errors anyway? I want that it works!!1!eleven And for it to work it needs to report errors when they happen. I guess I should have used explicit irony tags here. Unfortunately fixing ssh will not be a small patch. It might be best to simply document the issue in man 1 scp. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477751: tackling this bug
Hi Daniel, On Mon, Dec 05, 2011 at 12:05:26AM +0100, Daniel Leidert wrote: My thoughts on this are pretty easy. There are IMO three mechanisms to use: (1) Register the catalog, if it exists (and unregister any registered catalog, if it doesn't exist anymore). So users can remove the package catalog file. (2) Register the catalog only during installation, but not during upgrade. Usually we only add a catalog reference to the super catalog. This is what I proposed. It can be done today with a simple change to debhelper and no changes to sgml-base. (3) Catalog files should be written at build time not during installation. Instead of creating /etc/sgml/package.cat during installation, this should be created during package build. So the user can edit /etc/sgml/package.cat and /etc/sgml/catalog and we preserve these changes. Initially I thought about this as well. The problem with this is that currently /etc/sgml/package.cat is not owned by any package. So by switching a package to this model, each installation would prompt the user for those files. If the user now changes /etc/sgml/package.cat and we need to ship an updated file, he should usually be asked, if he wishes to update the file during installation. IMO we don't need to check, what has been disabled or not. Or does this have any advantages IYO? It works without asking the user questions during upgrade. This applies both to a transitioning period and to the long term when a package.cat changes. I don't really care whether the user is asked on package upgrades after he changes those files. But installations where no user changed those files should definitely not ask the user. So I propose that either you come up with a method to cleanly take over ownership of those configuration files or we use my approach. In any case this bug should be fixed some way or another. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi Michal, On Mon, Dec 05, 2011 at 05:03:25PM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Mon Dec 05 15:54:19 +0100 2011: Can we now ignore 2) and concentrate on 1)? No. If I wanted this semantics I could use shred(1). Please report a separate bug about not using fsync then. (or clone this bug) They can be fixed independently. I want my files saved. Honestly. You seem to have a rather different view on this issue than the rest of the world (otherwise it would have been reported way earlier). As for me I really do *not* want fsync here. For instance when I use a slow usb storage device, I really want cp to finish before the copied stuff is written to permanent storage. So even I would assume that the fsync issue is just wontfix (even though I am not the openssh maintainer). Note that this same issue has been found and fixed in dpkg. This is good and all. But in general tools simply do not provide fsync semantics and people actually expect that now. When firefox tried to introduce fsync, it was disabled for performance reasons again. If you need it, go sync after you copy. (Or write patches.) Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650808: frown: OOM on compiling any remotely valid grammer
tags 650808 +patch thanks Thanks to Joachim Breitner for taking some time to look at this with me. A likely cause was some mistake in the n+k removal patch. Indeed I found the precise culprit and verified that with the attached fix frown is able to translate grammers again. Helmut diff -Nru frown-0.6.1/debian/changelog frown-0.6.1/debian/changelog --- frown-0.6.1/debian/changelog2011-06-02 20:33:57.0 +0200 +++ frown-0.6.1/debian/changelog2011-12-07 17:36:24.0 +0100 @@ -1,3 +1,11 @@ +frown (0.6.1-11.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix OOM on compiling any remotely valid grammer fix logic error in +debian/patches/07_no-n-plus-k-pattern (Closes: #650808) + + -- Helmut Grohne hel...@subdivi.de Wed, 07 Dec 2011 17:35:30 +0100 + frown (0.6.1-11) unstable; urgency=low [ Marco Silva ] diff -Nru frown-0.6.1/debian/patches/07_no-n-plus-k-pattern frown-0.6.1/debian/patches/07_no-n-plus-k-pattern --- frown-0.6.1/debian/patches/07_no-n-plus-k-pattern 2011-06-02 20:32:03.0 +0200 +++ frown-0.6.1/debian/patches/07_no-n-plus-k-pattern 2011-12-07 17:34:55.0 +0100 @@ -9,7 +9,7 @@ - build (n + 1) x = (Node l a v r, z) - where m = n `div` 2 + build n x = (Node l a v r, z) -+ where m = n-1 `div` 2 ++ where m = (n-1) `div` 2 (l, (a, v) : y) = build m x - (r, z) = build (n - m) y + (r, z) = build (n - 1 - m) y
Bug#607267: /usr/bin/scp: fails to notice close() errors
severity 607267 important thanks On Thu, Dec 08, 2011 at 02:33:00PM +0100, Michal Suchanek wrote: FWIW this is unreproducible as of kernel 3.2 rc2 so I guess this is squeeze only for cifs shares (as can be verified by running the test on a squeeze live CD). Thanks for reporting. Given the small amount of systems being able to reproduce this issue I am downgrading the severity. You need an old (or stable) kernel and a filesystem like cifs. This doesn't seem to be a frequently encountered combination. However, the close() man page clearly states that only doing fsync() you can be sure your file was closed successfully. This is slightly incorrect. If close() returns 0, the file is closed successfully, so unfortunately your immediate conclusion is wrong again. The truth is that close() does not ensure that any data has reached a disk. Also note that using fsync() would not be enough either. It would just force the file to disk, but not necessarily its entry in a directory. After a power failure your file would be on the disk, but there would be no visible reference from your directory tree. You'd have to call fsync on the directory as well. After all it doesn't seem that obvious given that you got it wrong. ;-) I still wonder where it says that cp would guarantee that data would reach a disk. Can you find a reference? Same question for scp. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633433: slidentd: FTBFS after package change of libowfat
Hi, On Sat, Dec 03, 2011 at 11:18:30AM +0100, Helmut Grohne wrote: Extended NMU for #650798 as well. Apparently I still didn't get this right. In a similar NMU I prepared a user reported a problem with my invocation of dh_installinit (#651031). It only occurs when you use legacy boot ordering, so I didn't spot this issue during my tests. This problem is also present in this NMU, so I attached an updated debdiff which also fixes this problem. @Jan, could you sponsor it again? Helmut diff -u slidentd-1.0.0/debian/control slidentd-1.0.0/debian/control --- slidentd-1.0.0/debian/control +++ slidentd-1.0.0/debian/control @@ -2,7 +2,8 @@ Section: net Priority: extra Maintainer: David D. Smith davidsm...@acm.org -Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dev +Build-Depends: debhelper (= 5), dpatch, dietlibc-dev, libowfat-dietlibc-dev +Build-Conflicts: libowfat-dev Standards-Version: 3.7.2 Package: slidentd diff -u slidentd-1.0.0/debian/changelog slidentd-1.0.0/debian/changelog --- slidentd-1.0.0/debian/changelog +++ slidentd-1.0.0/debian/changelog @@ -1,3 +1,22 @@ +slidentd (1.0.0-6.3) unstable; urgency=medium + + * Non-maintainer upload. + * Fix error with invocation of dh_installinit in previous NMU. +See #651031 for a similar problem. + + -- Helmut Grohne hel...@subdivi.de Sun, 11 Dec 2011 13:32:35 +0100 + +slidentd (1.0.0-6.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS after package change of libowfat changed build depends. Thanks +to Roland Stigge (Closes: #633433) + * Fix FTBFS: (.text+0x15): undefined reference to `__ctype_b_loc' +unreproducible after previous fix (Closes: #634416) + * Fix: /var/run is now on tmpfs add init script (Closes: #650798) + + -- Helmut Grohne hel...@subdivi.de Sat, 03 Dec 2011 11:16:33 +0100 + slidentd (1.0.0-6.1) unstable; urgency=medium * Non-maintainer upload. diff -u slidentd-1.0.0/debian/rules slidentd-1.0.0/debian/rules --- slidentd-1.0.0/debian/rules +++ slidentd-1.0.0/debian/rules @@ -54,6 +54,7 @@ dh_testroot dh_installchangelogs CHANGES dh_installdocs + dh_installinit -- start 20 S . dh_install dh_link dh_strip only in patch2: unchanged: --- slidentd-1.0.0.orig/debian/slidentd.init +++ slidentd-1.0.0/debian/slidentd.init @@ -0,0 +1,24 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: slidentd-run-dir +# Required-Start:$remote_fs +# Required-Stop: $remote_fs +# Default-Start: S +# Default-Stop: +# Short-Description: setup for slidentd +# Description: create /var/run/slidentd for slidentd +### END INIT INFO + +[ -x /usr/sbin/slidentd ] || exit 0 + +case $1 in + start|restart|reload|force-reload) + mkdir -p /var/run/slidentd + ;; + stop) + ;; + status) + test -d /var/run/slidentd || exit 4 + exit 0 + ;; +esac
Bug#637209: sks install is broken in 2 ways
tags 637209 +moreinfo thanks On Tue, Aug 09, 2011 at 02:26:10PM +0100, sentimental.br...@gmail.com wrote: Flaws with installation: Incorrect ownership of /var/log/sks/db.log Please always state precisely what is wrong. Otherwise a maintainer can only guess what might be wrong. (See below for my guess.) sks executable located in /usr/sbin/sks So where is the flaw with putting a daemon in /usr/sbin? I would call that complying with FHS. Solutions: Correct permissions: chown -r debian-sks:root /var/log/sks/* According to postinst the original permission for /var/log/sks should be debian-sks:adm 2750. Does this represent the state of your system? Since sks is started as debian-sks the owner for new files inside that directory should be debian-sks. Also since the directory is setgid adm, the group of contained files should be adm as well. Has this been the case prior to invoking your solution? If yes, why do you believe that the group should be root instead of adm? Add correct path for debial-sks account: cat END /etc/profile.d/sks if [ `id -un` == debian-sks ]; then PATH=/usr/sbin:$PATH fi export PATH END From your solution I can guess that the some script tries to invoke sks as user debian-sks without specifying its full path. However I was unable to find a matching invocation. For instance build_sks.sh is patched to use absolute paths. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477751: tackling this bug
/debian/changelog 2011-12-09 18:53:42.0 +0100
+++ debhelper-8.9.13+nmu1/debian/changelog 2011-12-12 14:22:58.0
+0100
@@ -1,3 +1,11 @@
+debhelper (8.9.13+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Turn /etc/sgml/$package.cat into conffiles and do not touch
+/etc/sgml/catalog during upgrads. Closes: #88010
+
+ -- Helmut Grohne hel...@subdivi.de Mon, 12 Dec 2011 14:21:36 +0100
+
debhelper (8.9.13) unstable; urgency=low
* Pass CPPFLAGS to qmake. Closes: #646129 Thanks, Felix Geyert
diff -Nru debhelper-8.9.13/dh_installcatalogs
debhelper-8.9.13+nmu1/dh_installcatalogs
--- debhelper-8.9.13/dh_installcatalogs 2011-09-12 18:01:19.0 +0200
+++ debhelper-8.9.13+nmu1/dh_installcatalogs2011-12-12 14:05:49.0
+0100
@@ -96,11 +96,19 @@
doit(install,-d,-m755,$tmpdir/etc/sgml);
}
+ my $centralcat = /etc/sgml/$package.cat;
+
+ open(CENTRALCAT, , $tmpdir$centralcat) || error(failed to
write to $tmpdir$centralcat);
+ foreach my $sgmldest (@sgmlinstalled) {
+ print CENTRALCAT CATALOG . $sgmldest . \n;
+ }
+ close CENTRALCAT;
+
if (! $dh{NOSCRIPTS}) {
- my $ordcats = join( , @sgmlinstalled);
- my $centralcat = /etc/sgml/$package.cat;
+ autoscript($package, preinst, preinst-sgmlcatalog,
+ s%#CENTRALCAT#%$centralcat%g;);
autoscript($package, postinst, postinst-sgmlcatalog,
- s%#CENTRALCAT#%$centralcat%g;
s%#ORDCATS#%$ordcats%g;);
+ s%#CENTRALCAT#%$centralcat%g;);
autoscript($package, prerm, prerm-sgmlcatalog,
s%#CENTRALCAT#%$centralcat%g;);
autoscript($package, postrm, postrm-sgmlcatalog,
Bug#637209: sks install is broken in 2 ways
clone 637209 -1 retitle -1 /etc/init.d/sks redirects error messages from sks to /dev/null severity -1 wishlist submitter -1 ! tags -1 - moreinfo summary -1 0 thanks Thanks for your quick reply. On Mon, Dec 12, 2011 at 12:47:12PM +, Bryan Hunt wrote: On Mon, 12 Dec 2011 11:51:36 +0100, Helmut Grohne hel...@subdivi.de wrote: Incorrect ownership of /var/log/sks/db.log Please always state precisely what is wrong. Otherwise a maintainer can only guess what might be wrong. (See below for my guess.) Freshly installed system, no log output generated, or server fails to start. The daemon does not start by default: | Starting sks daemons: Not starting sks (as configured in /etc/default/sks) However if you enable it in /etc/default/sks and have it badly configured, it will write its error messages to /dev/null. This is because it is started using start-stop-daemon --background. Not on the path, the init script fails. Silently. Nothing starts up. My understanding is that /usr/sbin is only added to root's path. Regular, non-root programs will not have it added to their path. The init script starts $DAEMON which is an absolute path. So $PATH is not even used here. Solutions: Correct permissions: chown -r debian-sks:root /var/log/sks/* ls -la /var/log/sks/db.log -rw--- 1 debian-sks root 516 Dec 12 12:05 /var/log/sks/db.log This likely is due to your chown command. The original permission on a freshly installed sks are 600 debian-sks adm. This bug was submitted several months ago. I lost a bunch of docs, about a month later. All I now know - is that sks or one of it's helpers (on a fresh install) fails without that path, that the failure was silent, and that it took me 2 days to figure out the problem, which was why I submitted (my naive) fixes. Unfortunately you have only presented workarounds for yet unknown problems so far. The only real problem I could discover from your mails is that the init script hides the error messages and exit code returned from sks. I have cloned this issued (see above). Maybe you can try to reproduce the issues you ran into and document all the steps? Otherwise I see little value in adding your solutions to the package. To me the chown seems just wrong and I fail to see which aspect th $PATH change improves. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623623: upgrade 623623
tags 623623 + patch
thanks
On Sat, Dec 03, 2011 at 02:48:30PM +0100, Helmut Grohne wrote:
pbuilder cannot be used without pbuilder --create and pbuilder --create
uses dpkg-architecture which is contained in dpkg-dev. So this is a
missing dependency which should be serious according to policy 7.2:
debdiff attached. Built. Tested with pbuilder --login then apt-get
remove dpkg-dev; dpkg -i pbuilder_0.204+nmu1_all.deb; apt-get -f
install; pbuilder --create.
Helmut
diff -Nru pbuilder-0.204/debian/changelog pbuilder-0.204+nmu1/debian/changelog
--- pbuilder-0.204/debian/changelog 2011-12-04 14:43:21.0 +0100
+++ pbuilder-0.204+nmu1/debian/changelog2011-12-13 11:31:23.0
+0100
@@ -1,3 +1,11 @@
+pbuilder (0.204+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix fails to start, depends on dpkg-architecture (dpkg-dev)
+add missing runtime dependency (Closes: #623623)
+
+ -- Helmut Grohne hel...@subdivi.de Tue, 13 Dec 2011 11:30:55 +0100
+
pbuilder (0.204) unstable; urgency=low
[ Slavko ]
diff -Nru pbuilder-0.204/debian/control pbuilder-0.204+nmu1/debian/control
--- pbuilder-0.204/debian/control 2010-01-03 03:38:09.0 +0100
+++ pbuilder-0.204+nmu1/debian/control 2011-12-13 11:30:29.0 +0100
@@ -24,6 +24,7 @@
wget,
debianutils (= 1.13.1),
coreutils (= 4.5.8-1),
+ dpkg-dev,
${misc:Depends}
Recommends: fakeroot,
sudo,
Bug#624991: logkeys: FTBFS: logkeys.cc:473:13: error: 'umask' was not declared in this scope
tags 624991 + patch thanks On Mon, May 02, 2011 at 02:35:02PM +0200, Lucas Nussbaum wrote: Relevant part: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O3 -c -o logkeys.o logkeys.cc logkeys.cc: In function 'int main(int, char**)': logkeys.cc:473:13: error: 'umask' was not declared in this scope make[3]: *** [logkeys.o] Error 1 Adding the includes mentioned in man 2 umask solves this issue. The package builds successfully with the attached debdiff in pbuilder. Helmut diff -Nru logkeys-0.1.0/debian/changelog logkeys-0.1.0/debian/changelog --- logkeys-0.1.0/debian/changelog 2010-02-07 01:25:32.0 +0100 +++ logkeys-0.1.0/debian/changelog 2011-12-13 12:11:28.0 +0100 @@ -1,3 +1,11 @@ +logkeys (0.1.0-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS: logkeys.cc:473:13: error: 'umask' was not declared in +this scope add missing includes (Closes: #624991) + + -- Helmut Grohne hel...@subdivi.de Tue, 13 Dec 2011 12:11:17 +0100 + logkeys (0.1.0-1) unstable; urgency=low * Initial release (Closes: #567414) diff -Nru logkeys-0.1.0/debian/patches/series logkeys-0.1.0/debian/patches/series --- logkeys-0.1.0/debian/patches/series 2010-02-23 22:57:08.0 +0100 +++ logkeys-0.1.0/debian/patches/series 2011-12-13 12:04:54.0 +0100 @@ -1,3 +1,4 @@ disable-install-exec-hook.patch # don't suid disable-dev-input-checks.patch # no /dev/input in pbuilder move_pidfile_to_var_run.patch +umask_undeclared.patch diff -Nru logkeys-0.1.0/debian/patches/umask_undeclared.patch logkeys-0.1.0/debian/patches/umask_undeclared.patch --- logkeys-0.1.0/debian/patches/umask_undeclared.patch 1970-01-01 01:00:00.0 +0100 +++ logkeys-0.1.0/debian/patches/umask_undeclared.patch 2011-12-13 12:05:39.0 +0100 @@ -0,0 +1,13 @@ +Index: logkeys-0.1.0/src/logkeys.cc +=== +--- logkeys-0.1.0.orig/src/logkeys.cc 2011-12-13 11:58:50.0 +0100 logkeys-0.1.0/src/logkeys.cc 2011-12-13 12:05:35.0 +0100 +@@ -16,6 +16,8 @@ + #include getopt.h + #include sys/file.h + #include linux/input.h ++#include sys/types.h ++#include sys/stat.h + + #include config.h // config produced from ./configure +
Bug#609215: embedding PDF readers in chromium steals mouse pointer and lock X session
Package: mozplugger Version: 1.14.3-6 Followup-For: Bug #609215 I can confirm this bug. Like all other reporters I am running awesome (3.4.11-1), but unlike others I can reproduce it with iceweasel (8.0.-3+b1). Also when I kill the pdf viewer (xpdf 3.02-21) from a linux vt, the grabbing of input events stops. Hope this helps Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: status of this bug?
Hi, First of all let me give a summary (corrections welcome): /etc/apt/trusted.gpg is a binary gpg keyring that by default contains the keys used to verify the release files. It is changed by apt-key during upgrades of either apt or debian-archive-keyring. This change may overwrite user changes (removal of keys) and is thus technically a policy violation (either direct or via FHS). It is not agreed upon whether such a user change is to be supported. However the current implementation and documentation of apt-key do support removal of keys. The resulting behaviour may confuse a user and can be interpreted as a security issue. Since the original report things have changed a bit. apt has gained a /etc/apt/trusted.gpg.d which can be maintained in a strictly policy compliant manner (using binary conffiles). However the feature could not be employed in squeeze to support upgrades from lenny. The bug was thus tagged squeeze-ignore. Upgrade issues have now vanished since slipping releases is not considered supported. Possible solution? According to my understanding of the issue debian-archive-keyring could be changed to provide conffiles in /etc/apt/trusted.gpg.d. This way of doing things would completely obsolete apt-key and thus close this bug. There are a few options to implement those conffiles. 1 binary regular files 1.1 one file per key 1.2 one file per suite 1.2 one big file (i.e. copy debian-archive-keyring.gpg) 2 symbolic links 2.1 one link per key 2.2 one link per suite 2.2 one link to debian-archive-keyring.gpg Using regular files might be easier to implement, because shipping those files in /etc makes them conffiles. Using symbolic links may be a cleaner solution. Using more files provides more (or easier) flexibility to the user and therefore seems preferable even though it causes more work. In order to support the current apt-key the debian-archive-removed-keys.gpg would need to include all present keys (and thus clean trusted.gpg). The change would again loose user configuration, but this seems unavoidable to me. After letting a further release pass, apt-key could simply be dropped from apt. This bug would need to be tagged wheezy-ignore. Is this solution doable? If yes, I would clone this bug, reassign it to debian-archive-keyring and block the original bug. If not, what are the current options? Is there anyone else working on this issue? Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
