Bug#692022: fortunes: Paulus Silentarius → Paulus Silentiarius
Package: fortunes Version: 1:1.99.1-4 Severity: minor Tags: patch Today, fortune delivered: For I swore I would stay a year away from her; out and alas! but with break of day I went to make supplication. -- Paulus Silentarius, c. 540 A.D. Actually, the guys name is Paulus Silentiarius. Best regards, Alexander -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fortunes depends on: ii fortunes-min 1:1.99.1-4 Data files containing fortune cook Versions of packages fortunes recommends: ii fortune-mod 1:1.99.1-4 provides fortune cookies on demand fortunes suggests no packages. -- no debconf information --- men-women.old 2012-11-01 12:41:50.148155254 +0100 +++ men-women.new 2012-11-01 12:42:41.184158485 +0100 @@ -702,7 +702,7 @@ % For I swore I would stay a year away from her; out and alas! but with break of day I went to make supplication. - -- Paulus Silentarius, c. 540 A.D. + -- Paulus Silentiarius, c. 540 A.D. % For thirty years a certain man went to spend every evening with Mme. ___. When his wife died his friends believed he would marry her, and urged
Bug#683069: fortune-mod: Marcus Procius Cato → Marcus Porcius Cato
Package: fortune-mod Version: 1:1.99.1-4 Severity: minor Tags: patch Today, fortune delivered: I would much rather have men ask why I have no statue, than why I have one. -- Marcus Procius Cato The guy's name is actuall Marcus Porcius Cato. Best regards, Alexander -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fortune-mod depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii librecode03.6-17 Shared library on which recode is Versions of packages fortune-mod recommends: ii fortunes [fortune-cookie-db] 1:1.99.1-4 Data files containing fortune cook ii fortunes-bofh-excuses [fortun 1.2-2 BOFH excuses for fortune ii fortunes-de [fortune-cookie-d 0.27-1 German data files for fortune ii fortunes-min [fortune-cookie- 1:1.99.1-4 Data files containing fortune cook ii fortunes-off [fortune-cookie- 1:1.99.1-4 Data files containing offensive fo Versions of packages fortune-mod suggests: ii bsdmainutils 8.0.13 collection of more utilities from ii fortunes 1:1.99.1-4 Data files containing fortune cook ii x11-utils 7.5+4 X11 utilities -- no debconf information --- politics.old2012-07-28 13:29:53.690505428 +0200 +++ politics.new2012-07-28 13:31:23.178504773 +0200 @@ -876,7 +876,7 @@ -- William F. Buckley % I would much rather have men ask why I have no statue, than why I have one. - -- Marcus Procius Cato + -- Marcus Porcius Cato % I would rather be a serf in a poor man's house and be above ground than reign among the dead.
Bug#565737: get-iana: RESERVED_IPS warning fails to go away if IPv4 address space does not change
Package: firehol Version: 1.256-4 Severity: minor When /etc/firehol/RESERVED_IPS is more than 90 days old, the user receives a suggestion to run /usr/sbin/get-iana to update the file. However, if the IPv4 address space has not changed since the last update, the RESERVED_IPS file is left untouched, causing the warning to appear again on next reboot. I would have expected the get-iana script to at least update the timestamp of RESERVED_IPS to reflect the successful null update. Best regards, Alexander -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages firehol depends on: ii bash 3.2-4 The GNU Bourne Again SHell ii iproute 20080725-2 networking and traffic control too ii iptables 1.4.2-6administration tools for packet fi ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii net-tools 1.60-22The NET-3 networking toolkit Versions of packages firehol recommends: ii aggregate1.6-4 ipv4 cidr prefix aggregator ii curl 7.18.2-8lenny3 Get a file from an HTTP, HTTPS or ii module-init-tools3.4-1 tools for managing Linux kernel mo ii wget 1.11.4-2+lenny1 retrieves files from the web firehol suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497035: Unable to purge phpbb3
Package: phpbb3 Version: 3.0.2-1 Severity: normal I marked phpbb3 for purge (key _) in aptitude in order to uninstall phpbb3 and destroy its databases. Dbconfig-common which was auto-installed together with phpbb3 I also marked for purging. I answered Yes to the Deconfigure with dbconfig-common question, and Yes to Purge phpbb3 DB. I was then asked a strange question: -|Configuring phpbb3|- What is the password for the administrative account with which this package should create its MySQL database and user? Thinking the maintainer probably meant drop instead of create, I provided the phpbb3 database password, leading to an error message (Access denied for [EMAIL PROTECTED]). OK, so I should have given MySQL password for root. I then selected retry and the same error message occurred again. Among the choices now were retry and retry (skip questions), both with the same result: the same error message, and no questions asked, i.e. no chance of supplying the correct password. So I chose abort and tried again: no avail. I then reinstalled phpbb3 (and thus dbconfig-common) and tried the whole process again, this time using the correct password. I then got lots of table already exists error messages. Finally, reinstalling phpbb3 again, and purging phpbb3 without purging dbconfig-common successfully rid my system of phpbb3. When I tried to reproduce this bug, I could successfully generate the wrong password behaviour described above, but not the table already exists behaviour. Best regards, Alexander -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages phpbb3 depends on: ii apache2 2.2.9-7Apache HTTP Server metapackage ii apache2-mpm-prefork [httpd] 2.2.9-7Apache HTTP Server - traditional n ii dbconfig-common 1.8.39 common framework for packaging dat ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libapache2-mod-php5 5.2.6-2+b1 server-side, HTML-embedded scripti ii mysql-client 5.0.51a-12 MySQL database client (metapackage ii mysql-client-5.0 [mysql-clien 5.0.51a-12 MySQL database client binaries ii php5 5.2.6-2server-side, HTML-embedded scripti ii php5-mysql5.2.6-2+b1 MySQL module for php5 ii php5-pgsql5.2.6-2+b1 PostgreSQL module for php5 Versions of packages phpbb3 recommends: ii exim4 4.69-6 metapackage to ease Exim MTA (v4) ii exim4-daemon-light [mail-tran 4.69-6 lightweight Exim MTA (v4) daemon pn php5-gd | php4-gd none (no description available) pn php5-imagick | php4-imagick none (no description available) Versions of packages phpbb3 suggests: ii mysql-server 5.0.51a-12 MySQL database server (metapackage ii mysql-server-5.0 [mysql-serve 5.0.51a-12 MySQL database server binaries -- debconf information: phpbb3/db/basepath: phpbb3/db/app-user: phpbb3 phpbb3/dbconfig-reinstall: false phpbb3/db/dbname: phpbb3 phpbb3/install-error: abort phpbb3/upgrade-backup: true * phpbb3/dbconfig-install: true phpbb3/mysql/method: unix socket phpbb3/remote/newhost: phpbb3/pgsql/manualconf: phpbb3/dbconfig-remove: phpbb3/internal/reconfiguring: false phpbb3/pgsql/authmethod-user: phpbb3/upgrade-error: abort phpbb3/pgsql/authmethod-admin: ident phpbb3/pgsql/method: unix socket * phpbb3/database-type: mysql phpbb3/mysql/admin-user: root phpbb3/remote/host: * phpbb3/httpd: apache2 phpbb3/remove-error: retry phpbb3/dbconfig-upgrade: true phpbb3/purge: true phpbb3/missing-db-package-error: abort phpbb3/pgsql/changeconf: false phpbb3/internal/skip-preseed: false phpbb3/pgsql/admin-user: postgres phpbb3/remote/port: phpbb3/pgsql/no-empty-passwords: phpbb3/passwords-do-not-match: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Olivier Berger: I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? aptitude chose to remove it (instead of upgrading), presumably because otherwise some packages would have been broken. I then selected the calendar and manual modules only, missing the core package. As it is with the testing release, the initial breakage may have been caused by who knows what. Anyway, all this rant may not have been the cause for the rights problem with the sessions directory... I was just puzzled by the status of the package in your report. I'll try and investigate the rights problem and see what's the real cause. Thanks! Also thanks for your previous email, explaining things. I dug around in my system and found an aptitude log: Aptitude 0.4.10: log report Mon, Apr 14 2008 10:18:30 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 163 packages, and remove 17 packages. 7057kB of disk space will be freed === [REMOVE, NOT USED] lapack3 [REMOVE, NOT USED] libc-client2007 [REMOVE, NOT USED] libneon27-gnutls [REMOVE, NOT USED] libsndfile1 [REMOVE, NOT USED] libsuitesparse [REMOVE, NOT USED] mlock [REMOVE, NOT USED] openoffice.org-style-hicontrast [REMOVE, NOT USED] openoffice.org-style-industrial [REMOVE, NOT USED] php5-imap [REMOVE, NOT USED] phpgroupware [INSTALL, DEPENDENCIES] libblas3gf [INSTALL, DEPENDENCIES] libcurl3 [INSTALL, DEPENDENCIES] libgfortran3 [INSTALL, DEPENDENCIES] liblapack3gf [INSTALL, DEPENDENCIES] libssh2-1 [INSTALL, DEPENDENCIES] libstlport4.6ldbl [INSTALL, DEPENDENCIES] libsuitesparse-3.1.0 [INSTALL, DEPENDENCIES] libtotem-plparser10 [INSTALL, DEPENDENCIES] openoffice.org-writer2latex [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-admin [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-core-base [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-phpgwapi [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-preferences [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-setup [REMOVE, DEPENDENCIES] libstlport4.6c2 [REMOVE, DEPENDENCIES] phpgroupware-admin [REMOVE, DEPENDENCIES] phpgroupware-calendar [REMOVE, DEPENDENCIES] phpgroupware-manual [REMOVE, DEPENDENCIES] phpgroupware-phpgwapi [REMOVE, DEPENDENCIES] phpgroupware-preferences [REMOVE, DEPENDENCIES] phpgroupware-setup [INSTALL] phpgroupware-0.9.16-calendar [INSTALL] phpgroupware-0.9.16-doc [INSTALL] phpgroupware-0.9.16-manual [UPGRADE] aspell 0.60.5-2 - 0.60.5-2.1 ... snip lotsa unrelated upgrades ... [UPGRADE] wwwconfig-common 0.0.48 - 0.1.0 === Log complete. I'm not entirely fluent with aptitude's dependency stuff, but what might have happened is this: 1. Once upon a time, I decided to install phpgroupware-calendar (among some other modules, but for simplicity let's pretend it's only the calendar). 2. aptitude resolved the dependencies and selected the phpgroupware package for installation, marking it automatic. 3. Then April 14th came: I pressed u, then U for complete system upgrade and a lot of phpgroupware dependencies were broken, so aptitude decided to select calendar for removal in order to preserve an unbroken system state. 4. Seeing that all installed packages which depend on phpgroupware were selected for removal, aptitude also selected phpgroupware for removal because it was marked automatic. 5. Me, seeing phpgroupware is about to be removed, selects phpgroupware-0.9.16-calendar. However, phpgroupware-0.9.16 is not selected, as it's not in the dependency list (this is what's not intended in this situation, but difficult to fix, right?). How, in this situation, it came to be that the permissions were broken, I cannot tell. I hope this info helps you a little anyway. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: closed by Olivier Berger [EMAIL PROTECTED] (It seems it's fixed for some time in stable)
Olivier Berger: Now that the session.save_path is back to /var/lib/phpgroupware/sessions for PHP5 (since #472668 fix) instead of /var/lib/php5, it exhibits the problem. We'll try and make sure there's a permission check on that dir in a new update of the phpgroupware-0.9.16-core-base package, hopefully in time for lenny. OK, thanks. So the reason why the problem was visible only after a reboot was probably apache loading the new php module for the first time. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Hi, Olivier Berger: Can you elaborate a little bit on what's happening exactly (logs, permissions of files/dirs) ? sure. The machine is running lenny, Debian kernel 2.6.24-1-686, no frills. On Monday (i.e. two days ago) I upgraded, installing the new phpgroupware: # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1web based groupware system written in PHP ii phpgroupware-0.9.16-admin1:0.9.16.012+dfsg-2 phpGroupWare administration module ii phpgroupware-0.9.16-calendar 1:0.9.16.012+dfsg-2 phpGroupWare calendar management module ii phpgroupware-0.9.16-core-base1:0.9.16.012+dfsg-2 Base components of the phpGroupware applica ii phpgroupware-0.9.16-doc 1:0.9.16.012+dfsg-2 Documentation of phpGroupware 0.9.16 ii phpgroupware-0.9.16-manual 1:0.9.16.012+dfsg-2 phpGroupWare on-line manual module ii phpgroupware-0.9.16-phpgwapi 1:0.9.16.012+dfsg-2 library of common phpGroupWare functions ii phpgroupware-0.9.16-preferences 1:0.9.16.012+dfsg-2 phpGroupWare preferences management module ii phpgroupware-0.9.16-setup1:0.9.16.012+dfsg-2 phpGroupWare setup III module (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. Today, a colleague restarted the machine and phpgroupware stopped working: when trying to log in, the error message Your session could not be verified appeared. The corresponding apache2 error log messages looked like [Wed Apr 16 14:55:35 2008] [error] [client X.X.X.X] PHP Warning: session_start() [a href='function.session-start'function.session-start/a]: open(/var/lib/phpgroupware/sessions/sess_a919fffee984f34236ae320f3bc67123, O_RDWR) failed: Permission denied (13) in /usr/share/phpgroupware/phpgwapi/inc/class.sessions_php4.inc.php on line 44, referer: https://our.phpgroupware.host/phpgroupware/login.php [Wed Apr 16 14:55:35 2008] [error] [client X.X.X.X] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/phpgroupware/sessions) in Unknown on line 0, referer: https://our.phpgroupware.host/phpgroupware/login.php I checked the BTS and found #327249. Doing a chmod -R www-data.www-data /var/lib/phpgroupware immediately solved the problem, so I marked the bug as found. Previous permissions were root.root. HTH regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Olivier Berger: Please keep [EMAIL PROTECTED] in CC: of further exchanges, (sending to [EMAIL PROTECTED] only, as BTS says it's forwarding these messages to you.) Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit : # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1 web based groupware system written in PHP Strange... it seems the phpgroupware package isn't installed... as an epoch 1 package. Correct. The phpgroupware version 0.9.16.012+dfsg-1 (non-epoch) package was installed for quite some time, and then marked as to-be-removed by aptitude for unsatisfied dependencies two days ago (this happens sometimes, as new packages appear in lenny and their dependencies change); the current version of the phpgroupware binary package is only transitional anyway, it being replaced by phpgroupware-0.9.16. So I selected phpgroupware-0.9.16-calendar, phpgroupware-0.9.16-manual and phpgroupware-0.9.16-doc for installation. All the other packages were selected by aptitude to satisfy dependencies. phpgroupware-0.9.16 was NOT among them. Maybe a missing dependency in the package? Installing this package would pull in the phpgroupware-0.9.16-core package, which in turn would pull in a lot of other phpgroupware modules through Recommends. I'd expect to see phpgroupware (1:0.9.16.012+dfsg-2) there (see http://packages.debian.org/lenny/phpgroupware) ... Maybe that explains the issue that you had ? I think you mean phpgroupware-0.9.16, not phpgroupware. Well, maybe yes, but then phpgroupware-0.9.16-calendar etc. should Depends on phpgroupware-0.9.16 somewhere down the chain. I'm not exactly sure what rc means... removed+unconfigured ? Package removed, configuration files still installed. (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. So I'd say the bug may be fixed then. It worked just fine until the reboot. I cannot rule out that I inadvertently tested the old installation (or parts of it) somehow before the reboot. In any case, aptitude had finished the installation, of course, before I began testing. Do you have an idea of what happened during the upgrade (which apt frontend used, also) ? aptitude, see above. Maybe you should reinstall the phpgroupware package (version 1:0.9.16.012+dfsg-2), and maybe remove it once it's installed OK, just for the sake of a clean system ? I'm quite content that it works now. From what you told me above, my guess is a Depends or a Replaces was missing somewhere. If it's an issue of the phpgroupware - phpgroupware-0.9.16 transition only, this bug may be quite irrelevant in testing, but please make sure the etch-lenny transition works flawlessly, once lenny becomes stable. Thank you! Best regards, Alexander
Bug#470879: firehol: get-iana broken
Package: firehol Version: 1.256-3 Severity: important The get-iana command does not work (this may be related to #455754 and #455752). --- snip --- # get-iana Fetching IANA IPv4 Address Space, from: http://www.iana.org/assignments/ipv4-address-space --10:11:57-- http://www.iana.org/assignments/ipv4-address-space = `-' Resolving www.iana.org... aggregate: maximum prefix length permitted will be 32 208.77.188.193, 2620:0:2d0:1::193 Connecting to www.iana.org|208.77.188.193|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 28,065 (27K) [text/plain] 100%[] 28,06550.41K/s 10:11:58 (50.29 KB/s) - `-' saved [28065/28065] aggregate: no prefixes supplied FOUND THE FOLLOWING RESERVED IP RANGES: RESERVED_IPS= Failed to find reserved IPs. Possibly the file format has been changed, or I cannot fetch the URL. --- snip --- Thanks for looking into this. Best regards, Alexander -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages firehol depends on: ii bash3.1dfsg-9The GNU Bourne Again SHell ii iproute 20080108-1 Professional tools to control the ii iptables1.3.8.0debian1-1 administration tools for packet fi ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip ii net-tools 1.60-19 The NET-3 networking toolkit Versions of packages firehol recommends: ii aggregate1.6-3 ipv4 cidr prefix aggregator ii curl 7.18.0-1Get a file from an HTTP, HTTPS or ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo ii wget 1.10.2-3retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433666: tex-mode complains about mismatched parentheses when using inline-math
Package: emacs22-common Version: 22.1+1-1 Severity: minor --- Please enter the report below this line. --- 1. Start a new text file with: emacs test.tex tex-mode should start automatically. 2. Type a dollar sign ($) into the edit window 3. emacs immediately complains about mismatched parentheses. Older versions did not show this behaviour. --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-2-686 Debian Release: lenny/sid 500 testing www.debian-multimedia.org 500 testing ftp.gwdg.de 500 testing ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+- emacsen-common (= 1.4.10) | 1.4.17 dpkg(= 1.9.0) | 1.14.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410887: acknowledged by developer (#410887 no longer present in 4:3.5.6.dfsg.2-1)
Hi, I just closed this bug because the problem is no longer present and now I got this reply: Debian Bug Tracking System: It has been marked as closed by one of the developers, namely Alexander Klauer [EMAIL PROTECTED]. Er, I'm not a developer. I only reported this bug. Was it wrong to close it? If so, please accept my apologies and reopen it. If not, I probably should file a bug against the bug tracking system. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420137: bugs.debian.org: Confusing response when closing a bug report
Package: bugs.debian.org Severity: minor Hi, submitters of bug reports are encouraged to close a bug report when the bug is no longer present. I did this with #410887 and the BTS reply contained: It has been marked as closed by one of the developers, namely Alexander Klauer [EMAIL PROTECTED]. Well, I'm not one of the developers. Upon this reply, I first thought, closing the bug report was a mistake, but http://www.debian.org/Bugs/Developer#closing clearly states I was right. I therefore suggest to change the reply to read: It has been marked as closed by the submitter or one of the developers, namely ... or even It has been marked as closed by the submitter or one of the developers (for exceptions, see http://www.debian.org/Bugs/Developer#closing), namely ... where the last one is probably a bit clumsy. Thank you. Best regards, Alexander Klauer -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.19-rc5-mm1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410887: About bug #410887 konsole deletes first line in buffer once buffer exceeds window height in Debian BTS
Hi Olivier, Olivier Vitrat: I've been unable to reproduce this with the latest version of Konsole. Do you have any special configuration for this application, such as window size, decoration, font, or WM theme ? Can you test this with a newer version of konsole ? I still have 4:3.5.5a.dfsg.1-6 here (and the problem remains, of course); I'll keep you posted once the newer version hits unstable. For reference, here's my configuration: Window size: 80x24 (834x523 pixels) Decoration: Web/Normal with tooltips for window buttons Font: FreeMono Normal/13 WM-Theme: HighContrastLight-big Here's my konsolerc: [$Version] update_info=konsole.upd:kde2.2/r1,konsole.upd:kde3.0/r1 [Desktop Entry] ActiveSession=0 AutoResizeTabs=false DefaultSession=shell.desktop DynamicTabHide=false EncodingName=Standard Fullscreen=false Height 1024=493 Height 768=452 TabColor=0,0,0 TabViewMode=0 Width 1024=666 Width 1280=826 bellmode=0 class=konsole-mainwindow#1 defaultfont=FreeMono,13,-1,5,50,0,0,0,0,0 font=6 history=1000 historyenabled=true keytab=default schema=BlackOnWhite.schema scrollbar=2 tabbar=2 [TipOfDay] RunOnStart=false TipLastShown=2005,11,28,8,49,11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406470: patch for openafs FIFO problem
Hello Thomas, Thomas Braun: [...] attached is a patch which should stop kile from making bullshit if there are no FIFOs. It would be nice if you could try the patch, because I don't have an openafs filesystem here. Or if I could get access to an openafs filesystem I can try it myself. I've patched and rebuilt the package (kile_1.9.3-1_i386.deb); it works both for me and the user who reported the problem to me: when the option is checked, kile no longer consumes all CPU time and an error message is printed to the konsole from which kile is started. Thank you very much. Unfortunately I can't give you AFS access, only the people from our university computing centre can do that. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406470: not reproducible here
Hi Thomas, (no reply-to was set; do you need CC:'s in the future?) Thomas Braun: - Do you have this behjavour always (or only after a start and stop cycle of kile)? What do you mean by start and stop cycle? Anyway, when I check the option, kile immediately starts hogging, when I uncheck it, kile immediately behaves normally again. With start stop cycle I meant, quitting kile and then restarting kile. I see. Nope, a start-stop cycle is not required. - Do you have your home on a local device, or some remote stuff (nfs, openafs, smb, or similiar) The home dirs are in OpenAFS. I think we found the culprit :) Kile is using a fifo to be able to insert tags from lyx-compliant apps (This means e.g. gbib writes a bibtex reference to .lyxpipe.in and then kile gets notified and inserts the reference). But according to http://www.dementia.org/twiki/bin/view/AFSLore/UsageFAQ#2_13_Can_I_create_a _fifo_aka_nam Fifos are not supported by OpenAFS :( Currently I don't know a solution but I will ask some other kile devs for help. Well, that explains things. If I may make two suggestions: 1. Kile tries to create a FIFO and when this fails, it creates a regular file instead: [pid 4968] 09:58:11.419907 mknod(/afs/.../home/xxx/.lyxpipe.in, S_IFIFO| 0644) = -1 EPERM (Operation not permitted) [pid 4968] 09:58:11.419981 dup(2) = 13 [pid 4968] 09:58:11.420047 fcntl64(13, F_GETFL) = 0x8001 (flags O_WRONLY| O_LARGEFILE) [pid 4968] 09:58:11.420102 close(13) = 0 [pid 4968] 09:58:11.420138 write(2, Could not create pipe : Operatio..., 48Could not create pipe : Operation not permitted) = 48 [pid 4968] 09:58:11.420257 open(/afs/.../home/xxx/.lyxpipe.in, O_RDWR| O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 4968] 09:58:11.420326 open(/afs/.../home/xxx/.lyxpipe.in, O_RDWR| O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 13 The regular file messes up the usual select/pipe semantics. It would be better (as a short term solution) to show the user a clean error message instead, something like Sorry, but this functionality is unavailable because the file system of your home directory does not support FIFOs. 2. (long-term solution) Place the FIFO somewhere where they are supported for sure, e.g. in /tmp/kde-username/. Thank you, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406470: not reproducible here
Hi Thomas, sorry for answering so late. I haven't received your answer by mail, only just saw it in the BTS. copy paste: I would need some further information: - Do you have this behjavour always (or only after a start and stop cycle of kile)? What do you mean by start and stop cycle? Anyway, when I check the option, kile immediately starts hogging, when I uncheck it, kile immediately behaves normally again. - Or only after having other programs used this feature? What feature? The user in question does not use LyX or latex directly. - Can you give the output of ls -la .lyx .lyxpipe.* in your home directory of the user issuing kile.ls -la .lyx .lyxpipe.* In my home dir: $ ls: .lyxpipe.*: No such file or directory .lyx: total 10 drwxr--r-- 2 xxx xxx 2048 2007-02-26 11:38 . drwxr-xr-x 82 xxx xxx 8192 2007-02-26 11:38 .. In the user's home dir: $ ls -la .lyx .lyxpipe.* ls: .lyxpipe.*: No such file or directory .lyx: total 77 drwxr-xr-x 15 xxx xxx 2048 2007-01-11 17:47 . drwxrwxr-x 61 xxx xxx 6144 2007-02-23 16:15 .. drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 bind -rw-r--r-- 1 xxx xxx 2960 2006-01-09 12:45 bstFiles.lst drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 clipart -rw-r--r-- 1 xxx xxx 2310 2006-01-09 12:45 clsFiles.lst drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:46 doc drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 examples drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 help drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 images drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 kbd -rw-r--r-- 1 xxx xxx35 2006-10-10 16:01 lastfiles drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 layouts drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 reLyX drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 scripts -rw-r--r-- 1 xxx xxx 36262 2006-01-09 12:45 styFiles.lst drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 templates drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:43 ui drwxr-xr-x 2 xxx xxx 2048 2006-01-09 12:46 xfonts (Note that the problem is reproducible for both me and the user.) - Do you have your home on a local device, or some remote stuff (nfs, openafs, smb, or similiar) The home dirs are in OpenAFS. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406470: kile strace
Hi Thomas,
I ran a kile strace to see what kile is actually wasting so much CPU time
with. It turned out to be the following sequence of syscalls repeated ad
nauseam:
[pid 12988] 12:47:28.601883 select(18, [4 5 6 8 10 11 12 13 14 15 17], [], [],
{0, 630717}) = 2 (in [13 15], left {0, 630717})
[pid 12988] 12:47:28.601937 read(13, , 255) = 0
[pid 12988] 12:47:28.601971 read(15, , 255) = 0
[pid 12988] 12:47:28.601998 gettimeofday({1172490448, 602009}, NULL) = 0
[pid 12988] 12:47:28.602030 ioctl(4, FIONREAD, [0]) = 0
So connections 13 and 15 are shut down (if this interpretation is applicable
to pipes), but kile fails to remove them from the select() set, causing
select() to always return immediately. Descriptor 13 belongs to the
file .lyxpipe.in and descriptor 15 belongs to the file .lyx/lyxpipe.in.
Descriptor 4 is a PF_FILE socket connected to /tmp/.X11-unix/X0.
Hope this helps.
Best regards,
Alexander
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411849: rdiff-backup: OSError raised when transgressing unreadable directory on *destination*
Package: rdiff-backup Version: 1.1.5-4 Severity: normal The following error occurred during today's rdiff-backup (running with euid localbackup, command was rdiff-backup [EMAIL PROTECTED]::/cygdrive/. /var/local/backups/ls2buero/.) from a Cygwin box (source) to a Debian box (destination). snip Exception '[Errno 13] Permission denied: '/var/local/backups/ls2buero/c/WINNT/$hf_mig$/KB915865/update'' raised of class 'exceptions.OSError': File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 295, in error_check_Main try: Main(arglist) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 315, in Main take_action(rps) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 271, in take_action elif action == backup: Backup(rps[0], rps[1]) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 334, in Backup backup.Mirror_and_increment(rpin, rpout, incdir) File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 51, in Mirror_and_increment DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath) File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 231, in patch_and_increment cls.CCPP.close() File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 475, in close dir_rp.chmod(perms) File /var/lib/python-support/python2.4/rdiff_backup/rpath.py, line 826, in chmod self.conn.os.chmod(self.path, permissions Globals.permission_mask) Traceback (most recent call last): File /usr/bin/rdiff-backup, line 23, in ? rdiff_backup.Main.error_check_Main(sys.argv[1:]) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 295, in error_check_Main try: Main(arglist) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 315, in Main take_action(rps) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 271, in take_action elif action == backup: Backup(rps[0], rps[1]) File /var/lib/python-support/python2.4/rdiff_backup/Main.py, line 334, in Backup backup.Mirror_and_increment(rpin, rpout, incdir) File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 51, in Mirror_and_increment DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath) File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 231, in patch_and_increment cls.CCPP.close() File /var/lib/python-support/python2.4/rdiff_backup/backup.py, line 475, in close dir_rp.chmod(perms) File /var/lib/python-support/python2.4/rdiff_backup/rpath.py, line 826, in chmod self.conn.os.chmod(self.path, permissions Globals.permission_mask) OSError: [Errno 13] Permission denied: '/var/local/backups/ls2buero/c/WINNT/$hf_mig$/KB915865/update' Fatal Error: Lost connection to the remote system /snip Indeed, the directory /var/local/backups/ls2buero/c/WINNT/$hf_mig$/ has the pathological permissions d- 88 localbackup localbackup It was created during yesterday's backup, mirroring the permissions of the source directory on the Cygwin box. Today, rdiff-backup crashed with the above error message when transgressing said directory on the destination box. I would have expected rdiff-backup to do one of the following things: 1. Refuse to backup the unreadable directory in the first place writing an error message to the log. 2. Backup the unreadable directory and then use chmod on the backup target to check for changes/store increments during subsequent backups. Judging from the error message it seems that rdiff-backup was actually trying to do 2. (calling chmod) but made a mistake somehow. - System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc5-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages rdiff-backup depends on: ii libc6 2.3.6.ds1-12 GNU C Library: Shared libraries ii librsync1 0.9.7-1 Library which implements the rsync ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6automated rebuilding support for p Versions of packages rdiff-backup recommends: ii python-pylibacl 0.2.2-1module for manipulating POSIX.1e A ii python-pyxattr0.2.1-1.1 module for manipulating filesystem -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410887: konsole deletes first line in buffer once buffer exceeds window height
Package: konsole Version: 4:3.5.5a.dfsg.1-6 Severity: normal Open a new konsole (or a new command window) and type, e.g. ls -l in a directory such that the number of output lines exceeds the number of lines the window can display (usually 24). Scroll up. The typed command ls -l will be replaced by a blank line. This seems to happen whenever the number of lines in the buffer exceed the number of lines the window can display. For example, open a new konsole, press ENTER long/often, scroll up and again, the first line will be blank. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc5-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages konsole depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-6 core libraries and binaries for al ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxtst6 1:1.0.1-5 X11 Testing -- Resource extension konsole recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406612: textarea: unexpected cursor behaviour during arrow key navigation
Package: iceweasel Version: 2.0.0.1+dfsg-1 Severity: normal https://bugzilla.mozilla.org/show_bug.cgi?id=366796 The cursor column position is reset to the begining of line when arrow up/down keys are used, provided that current cursor column position is smaller than the length of the line below (arrow down) resp. above (arrow up) the current line. For example, go to http://en.wikisource.org/w/index.php?title=A_Treatise_on_Electricity_and_Magnetism/Part_I/Chapter_Vaction=edit and place your cursor between one of closing curly bracket pairs }}. If you move the cursor up or down now, it appears at the *beginning* of the previous or next line instead of the same column position. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc5-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages iceweasel depends on: ii debianutils 2.17.4 Miscellaneous utilities specific t ii fontconfig2.4.2-1generic font configuration library ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.2-1generic font configuration library ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-21 GCC support library ii libglib2.0-0 2.12.6-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii psmisc22.3-1 Utilities that use the proc filesy ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages iceweasel recommends: ii myspell-de-de [myspell-dic 20051113-6German dictionary for myspell ii myspell-en-us [myspell-dic 1:2.0.4~rc1-3 English_american dictionary for my -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406470: kile becomes CPU hog when Let Kile process LyX... is checked in config
Package: kile Version: 1:1.9.3-1 Severity: normal Select Settings-Configure Kile from the main menu, then the Kile-General configuration dialogue. When the last option, Let Kile process LyX commands sent by bibliography editors/viewers is checked, the program consumes all available CPU time on one processor. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc5-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kile depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii konsole4:3.5.5a.dfsg.1-5 X terminal emulator for KDE ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libqt3-mt 3:3.3.7-2 Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii tetex-bin 3.0-29The teTeX programs Versions of packages kile recommends: ii kdvi4:3.5.5-2dvi viewer for KDE ii kghostview 4:3.5.5-2PostScript viewer for KDE ii tetex-doc 3.0.dfsg.3-5 The documentation component of the ii tetex-extra 3.0.dfsg.3-5 Additional TeX input files of teTe -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399992: adduser: misleading warning message
Package: adduser Version: 3.99 Severity: minor When calling e.g. adduser --no-create-home --home /afs/path/to/home --uid 40003 johndoe adduser gives me the warning message: Warning: The home dir you specified does not exist. This is wrong in my case. The specified directory DOES exists, but the root user does not have access to its parent dir, as opposed to normal users with sufficient AFS access permissions. I suggest to add a check to adduser whether it can access the parent dir, and if not, output a different warning message, such as Warning: Unable to access parent directory of specified home dir. Thank you! Best regards, Alexander -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc5-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages adduser depends on: ii debconf [debconf-2.0] 1.5.9Debian configuration management sy ii passwd 1:4.0.18.1-5 change and administer password and ii perl-base 5.8.8-6.1The Pathologically Eclectic Rubbis adduser recommends no packages. -- debconf information: * adduser/homedir-permission: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399992: [Adduser-devel] Bug#399992: adduser: misleading warning message
Hi Marc, Am Donnerstag 23 November 2006 11:48 schrieb Marc Haber: I'd prefer changing the error message to Warning: The home dir you specified cannot be accessed, with dir does not exist being a special case (a not existing directory is inaccessible). Fine. Thank you! Greetings from Käfertal :) Have a nice day! Alexander
Bug#341893: typo in package description
Package: wngerman Version: 20030222-8 Severity: minor The package description says: It is based on the famous hkgerman dictionary (using the old German orthography, which is available as wgerman), with many corrections and additions. ^^^ wgerman, however, seems to be obsolete and is replaced by wogerman. Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313152: Wrong path for squid.conf example in debian/po/de.po
Package: squid Version: 2.5.10 Severity: minor In the file debian/po/de.po in the source tree, on three occasions /etc/share/doc/squid/examples/squid.conf should be replaced with /usr/share/doc/squid/examples/squid.conf Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296483: Misleading error message due to xstrvprintf in gdb/util.c
Package: gdb
Version: 6.3-5
Severity: minor
Tags: patch
Consider the following gdb session:
gdb session
$ gdb
GNU gdb 6.3-debian
[...]
(gdb) printf %lld\n,1
1
(gdb) printf %yd\n,1
%yd
(gdb) printf %qd\n,1
/nevyn/local/gdb/gdb-6.3/gdb/utils.c:1013: internal-error:
virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
end of gdb session
The input to this session is precicely the one used to trigger
bug #186037. The error message (virtual memory exhausted),
however, has become different since gdb version 5.3 due to a bug
in the function xstrvprintf() at gdb/utils.c:1120 which is
unrelated to bug #186037 (in particular, other bugs may be
affected as well).
The function xstrvprintf() (gdb/utils.c:1120) looks as follows:
--- snip ---
char *
xstrvprintf (const char *format, va_list ap)
{
char *ret = NULL;
int status = vasprintf (ret, format, ap);
/* NULL is returned when there was a memory allocation
problem. */
if (ret == NULL)
nomem (0);
/* A negative status (the printed length) with a non-NULL
buffer should never happen, but just to be sure. */
if (status 0)
internal_error (__FILE__, __LINE__,
vasprintf call failed (errno %d), errno);
return ret;
}
--- snap ---
According to the libc info file however, the correct way to
check if a call to vasprintf failed is to simply check for a
negative return value. Furthermore, vasprintf does not seem to
set errno. This leads to the wrong error message above.
I therefore propose to remove the ret==NULL check and the
reference to errno (see attached patch).
Of course this does not fix #186037, but restores it to its
former behaviour.
Regards,
Alexander
--- utils.c 2005-02-22 13:28:48.0 +
+++ utils.c.new 2005-02-22 18:09:53.0 +
@@ -1120,16 +1120,12 @@
char *
xstrvprintf (const char *format, va_list ap)
{
- char *ret = NULL;
+ char *ret;
int status = vasprintf (ret, format, ap);
- /* NULL is returned when there was a memory allocation problem. */
- if (ret == NULL)
-nomem (0);
- /* A negative status (the printed length) with a non-NULL buffer
- should never happen, but just to be sure. */
+ /* Negative status indicates error */
if (status 0)
internal_error (__FILE__, __LINE__,
- vasprintf call failed (errno %d), errno);
+ vasprintf call failed);
return ret;
}
Bug#231162: Being careful about format strings
Hi, (I'm CCing bug #231162 because the issues are probably related.) (Note that currently (gdb version 6.3-5) both #186037 and #231162 are obscured by #296483.) The patch I created for #186037 is not adequate for it solves only a small part of the problem. Looking again at printf_command at gdb/printcmd.c:1729, it seems to me that gdb is overall too sloppy about format string checking (this may be the case elsewhere in the source, too; I haven't checked), passing format strings to printf_filtered() which possibly trigger undefined behaviour in the subsequent call to vasprintf (libc info says unpredictable things will happen). Admitted, a gdb user should know how format strings are constructed, but what may be a simple typo shouldn't crash an entire debugging session. Maybe it is possible to no longer consider a failing vasprintf a gdb internal error and simply print a warning message. If this is not possible, printf_command() (and possibly other functions) might have to be expanded to check user supplied format strings thoroughly. In any case I'm going to remove the patch tag from #186037 and elevate its severity to normal. Maybe someone feeling confident with merging bugs could merge #186037 and #231162 if appropriate? Thanks best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
