Bug#888025: gpgsm: UI asks insane, unanswerable trust questions
I'm using kmail and am getting hit by this. It seems to be someone has sent me an email signed with some weird (internal?) certificate. What can I as a user even do if I *don't* trust the certificate? There is no "No, and please stop asking" option... Best, Brendon
Bug#1053857: cups: CVE-2023-32360 instructions in NEWS have a typo and are unclear
On Thu, 12 Oct 2023 14:22:27 -0400 Jonathan Kamens wrote: > In addition, after reading the NEWS entry and reviewing the contents > of my cupsd.conf file, I'm left completely clueless about whether I > actually need to change anything, or if doing so will break cups. I'm in exactly the same boat. I've found some useful additional information in bug #1052419, and especially Andres Salomon's message gives an actionable procedure to try. That bug was closed with an update to that NEWS message, although I still find that as written it assumes the user already has a grasp of the cupsd.conf file format and content, despite that they may never have touched that file and have no idea what they are being asked to do. Best, Brendon
Bug#1001147: syncthing.service appears to be enabled for all users
Hi, I just noticed the symptoms of this on my own system. Does every installation affected by this bug need manual intervention to undo the automatically-enabled user unit, or should the fixed package do that itself? If the former, for those not familiar (myself included), could you suggest the appropriate incantation to remove the user unit? Thanks, Brendon
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, Thanks for the pointer to the official site. Looks like the OpenPrinting mirror has been corrected by now. Is it normal that hp-plugin tries to download from OpenPrinting instead of the official site? On Tuesday, October 26, 2021 1:52:43 P.M. EDT Brian Potkin wrote: > You are are not the first (nor will you be the last) to have a problem > installing a plugin. This is upstream's responsibility. Oh I've no doubt I'm not the only one; that's why I'm thinking about how the whole situation might be improved. > > 1. Automatic updating of the plugin to the corresponding version - which, > > assuming an environment that uses one of the affected devices, is > > implicitly required by the hplip package for it to be at all useful. > > This is one of my sticking points. Automatic? A user has a device that > requires a non-free plugin for scanning. The user never scans, but is > still obliged to download and install it. Well, no, they wouldn't be. Regarding "automatic", I specifically mean for *updating* the plugin. Initially installing the plugin would still be a manual decision, in that the sysadmin (who, yes, might also be the user) would have to 'apt install hp-plugin-installer'. If they don't need it, they'd have no reason to install it in the first place. Nothing would depend on hp-plugin- installer, except that hplip *might* suggest it. (I thought I already said all that, but perhaps I was unclear.) This is how I'm thinking a hp-plugin-installer package will work: Importantly, it must pre-depend on the current hplip package. When the sysadmin installs it, its postinst script runs 'hp-plugin -i'. Sysadmin has to answer the two prompts to download and accept the license, which they would have to do anyway. Then in future when hplip packages receive an update, hp- plugin-install is also updated; its postinst gets triggered and runs the *updated* hp-plugin, which downloads the updated version of the plugin (with the usual prompts). The implication of this is that the sysadmin is always in control of the installation of the (updated) plugin, and the update always takes place at the same time as other package updates - the sysadmin doesn't have to remember to do it, or else be reminded at a random, possibly inopportune time. > > > There is also the matter of what runs the proposed package. It cannot > > > be from any of the HPLIP packages because, as the Debian Policy Manual > > > > > > says: > > > In addition, the packages in main must not require or recommend > > > a package outside of main for compilation or execution... > > > > hplip could suggest it, though. At any rate, I imagine the sysadmin would > > install hp-plugin-installer (from contrib) themselves. They would only > > need to do that once, and only if they actually had a device that needs > > the plugin to be installed. hp-plugin-installer would be versioned > > alongside hplip and update at the same time, and thereby run hp-plugin to > > grab and install the necessary plugin version at the time (or immediately > > after) the hplip update is installed. > > Any issues with hp-scan would be relected in hp-plugin-installer. Why > not just run hp-scan? I'm not sure why you brought up hp-scan. Did you mean hp-plugin? If that's what you meant, then yes, issues would be reflected, and that's part of the point. With 'hp-plugin-installer' as I propose, the sysadmin would be informed of a problem acquiring the necessary updated plugin, and can take action to correct that, all within moments of the hplip packages themselves being updated. At present, the problem might be hidden for however long until the user tries to print or scan, at which point corrective action by the sysadmin might be inconvenient or not immediately possible. > > > Ultimately, it is the user's responsibility to download a non-free > > > plugin. > > > > Well, to be precise, it's the sysadmin's responsibility to install said > > plugin, rather than the user's (unless they happen to be the sysadmin, but > > then it's a question of which hat they're wearing at any point in time) > > Many users wear both hats. Sure, but that doesn't invalidate my point. There's plenty of situations where it isn't the case - e.g., someone managing a system for a non-technically- literate relative or friend, or the admin of a school computer lab... > BTW, what is your HP device? Color LaserJet Pro MFP M277dw. Best, Brendon
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote: > On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote: > > Hi Brian, > > > > Perhaps I was unclear in my description. You responded: > > > You want to replace hp-plugin > > > > On the contrary, I would think the proposed hplip-plugin-installer package > > would pre-depend on hplip and essentially just run hp-plugin in its > > postinst. It's complementary, not a replacement. > > > > > with something Debian-specific that Debian has to maintain for ever. > > > > Debian-specific, perhaps, though hardly beyond ordinary packaging > > practices. Could be useful for derivatives, too. I would think > > maintenance for such a simple thing would be minimal (barring major > > upstream changes - which users would have to figure out for themselves, > > otherwise). > > > > And as I mentioned, there's plenty of precedent for this approach, and the > > arguments against those are the same. > > It strikes me that an hplip-plugin-installer package would not provide > anything over and above what hp-plugin provides. This checksum issue > reported in Launchpad #1948555 is not uncommon and such a package > would not alleviate it. The usual way to tackle it is download the > plugin and install with 'sh '. Download the plugin from where? I traced its source to the location given in that Launchpad bug, and it's obviously a broken upload at the server - this is a "true negative" checksum failure. (Please try it - it still hasn't been fixed as of writing.) I haven't been able to uncover an alternative download location, so if you know of one I would love to hear it (really!). This negative experience is what inspired me to suggest hp-plugin-installer - because it does provide key usability benefits due to this property: it would run at the same time that the hplip packages are updated. The benefits that come from this are: 1. Automatic updating of the plugin to the corresponding version - which, assuming an environment that uses one of the affected devices, is implicitly required by the hplip package for it to be at all useful. 2. Any failure to download/install the updated plugin can be found and addressed by the system administrator immediately. This is in contrast to the current situation where the system is left in an incomplete, unusable state, for an indefinite period of time, until the user might try to use their device, encounter a problem, and the user (rather than system administrator) is expected to fix that. In my case, the plugin file being broken upstream was my critical failure point. I only encountered this weeks after the hplip packages updated - it seems to me that the plugin file might have been okay back then. (I've since had to downgrade back to stable's version.) But I can imagine other situations which would be helped by hp-plugin-installer, too - perhaps the system is portable and not always connected to the internet, so downloading the plugin at any given time (even if it is good upstream) is not feasible, but downloading it when packages are also downloaded and installed makes much more sense. Or perhaps the user has been granted printing permissions but not root permissions by the system administrator - the sysadmin would absolutely want some kind of automation to install this plugin in such a situation... > There is also the matter of what runs the proposed package. It cannot > be from any of the HPLIP packages because, as the Debian Policy Manual > says: > > In addition, the packages in main must not require or recommend > a package outside of main for compilation or execution... hplip could suggest it, though. At any rate, I imagine the sysadmin would install hp-plugin-installer (from contrib) themselves. They would only need to do that once, and only if they actually had a device that needs the plugin to be installed. hp-plugin-installer would be versioned alongside hplip and update at the same time, and thereby run hp-plugin to grab and install the necessary plugin version at the time (or immediately after) the hplip update is installed. When I get some time I'll try to get a basic patch working. > Ultimately, it is the user's responsibility to download a non-free plugin. Well, to be precise, it's the sysadmin's responsibility to install said plugin, rather than the user's (unless they happen to be the sysadmin, but then it's a question of which hat they're wearing at any point in time). Peace, Brendon
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, Perhaps I was unclear in my description. You responded: > You want to replace hp-plugin On the contrary, I would think the proposed hplip-plugin-installer package would pre-depend on hplip and essentially just run hp-plugin in its postinst. It's complementary, not a replacement. > with something Debian-specific that Debian has to maintain for ever. Debian-specific, perhaps, though hardly beyond ordinary packaging practices. Could be useful for derivatives, too. I would think maintenance for such a simple thing would be minimal (barring major upstream changes - which users would have to figure out for themselves, otherwise). And as I mentioned, there's plenty of precedent for this approach, and the arguments against those are the same. > Patches are welome Cool! Willing to have a go. Where should I start? Best, Brendon
Bug#997795: hplip: Make a hplip-plugin-installer package
Source: hplip Severity: wishlist X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, As I understand it, licensing restrictions mean that the HP plugin, necessary for some printers/scanners (including the MFC I own), cannot be packaged in the ordinary Debian way. Instead, currently, if the Debian hplip packages receive an update, the next time a user attempts to use their printer/scanner they are interrupted until they download and install the latest plugin. This ends up being a nuisance manual process which is asynchronous with the actual change that made it necessary (the package update). Moreover, such an action (choosing to install the plugin package) is arguably not appropriate for the user role, anyway - rather, it is a system administrator question (for which the user may not actually have permission to decide). (It doesn't help that the download is a single point of failure that can be triggered at this later time; see https://bugs.launchpad.net/hplip/+bug/1948555 ...) Why not create a hplip-plugin-installer package (contrib), version-matched to the other hplip packages, which downloads and installs the HP plugin in its postinst? It would solve the primary issue, taking place at the same time as the other hplip packages are updated (and therefore could fail, and be corrected or reverted, all at that time). As a bonus, it would automate most of that nuisance process while allowing the system administrator (rather than random user) to accept (or decline) the installation. Lots of precedent exists for such a package. A cursory search through the contrib section for "download" in the package description brings up many, with notable examples being ttf-mscorefonts-installer, google-android-ndk-installer (and family), the historical (now-defunct) flashplugin-nonfree, and a swarth of firmware blobs. I'm broadly familiar with the Debian packaging process, but not all of the details. Nevertheless, I am technically inclined, and for how many times this nuisance has bitten me I'm willing to help make this suggestion happen however I can. Best, Brendon -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#960593: hplip: Requires login as root instead of as user
On Mon, 22 Mar 2021 17:01:06 +0200 Teemu Ikonen wrote: > Note that this bug can be mitigated by adding the two lines below to > ~/.hplip/hplip.conf: > > -*- > [authentication] > su_sudo=sudo > -*- Good tip, thanks for that. Evidently it only works on a per-user basis - i.e., adding those lines to /etc/hp/hplip.conf does nothing - which isn't perfect, but this is something. For me, hplip insists on going through the plugin install process after each time apt installs an updated package, so this will make that recurring annoyance that much more tolerable. Best, Brendon
Bug#981679: kdevelop: Clang plugin breaks when clang package bumps version
Package: kdevelop Version: 4:5.6.1-1 Severity: normal X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, The Clang plugin seems to be responsible for advanced syntax highlighting and probably other features. I just updated packages on my system and noticed these features no longer work. I saw a few copies of the below in the kdevelop output to console: kdevplatform.shell: Could not load plugin "kdevclangsupport" , it reported the error: "The clang builtin include path \"/usr/lib/llvm-11/lib/clang/11.0.0/include\" is invalid (missing cpuid.h header).\nTry setting the KDEV_CLANG_BUILTIN_DIR environment variable manually to fix this.\nSee also: https://bugs.kde.org/show_bug.cgi?id=393779; Disabling the plugin now. So the path it needs is hard-coded and versioned, for 11.0.0 in the present binary. My latest update pulled in Clang 11.0.1. If I set the KDEV_CLANG_BUILTIN_DIR variable correctly and run kdevelop, then it works. The KDE bug linked above does seem related, but ends with closure despite more run-time checking being a TODO. Until that's implemented, it seems the Clang plugin has a hard-ish version dependency on Clang, and the kdevelop package must be rebuilt when Clang updates, or the user has to employ the environment variable workaround. Peace, Brendon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdevelop depends on: ii kdevelop-data4:5.6.1-1 ii kdevelop56-libs 4:5.6.1-1 ii kinit5.78.0-2 ii kio 5.78.0-2 ii libapr1 1.7.0-6 ii libaprutil1 1.6.1-5 ii libastyle3 3.1-2+b1 ii libc62.31-9 ii libclang1-11 1:11.0.1-2 ii libgcc-s110.2.1-6 ii libgrantlee-templates5 5.2.0-3 ii libkasten4controllers0 5:0.26.4-2 ii libkasten4core0 5:0.26.4-2 ii libkasten4okteta2controllers05:0.26.4-2 ii libkasten4okteta2core0 5:0.26.4-2 ii libkasten4okteta2gui05:0.26.4-2 ii libkf5archive5 5.78.0-2 ii libkf5bookmarks5 5.78.0-2 ii libkf5codecs55.78.0-2 ii libkf5completion55.78.0-3 ii libkf5configcore55.78.0-3 ii libkf5configgui5 5.78.0-3 ii libkf5configwidgets5 5.78.0-2 ii libkf5coreaddons55.78.0-2 ii libkf5crash5 5.78.0-3 ii libkf5declarative5 5.78.0-2 ii libkf5guiaddons5 5.78.0-3 ii libkf5i18n5 5.78.0-2 ii libkf5iconthemes55.78.0-2 ii libkf5itemmodels55.78.0-2 ii libkf5itemviews5 5.78.0-2 ii libkf5jobwidgets55.78.0-2 ii libkf5kiocore5 5.78.0-2 ii libkf5kiofilewidgets55.78.0-2 ii libkf5kiogui55.78.0-2 ii libkf5kiowidgets55.78.0-2 ii libkf5newstuff5 5.78.0-2 ii libkf5parts5 5.78.0-3 ii libkf5purpose-bin5.78.0-2 ii libkf5purpose5 5.78.0-2 ii libkf5service-bin5.78.0-2 ii libkf5service5 5.78.0-2 ii libkf5sonnetui5 5.78.0-2 ii libkf5texteditor55.78.0-3 ii libkf5textwidgets5 5.78.0-2 ii libkf5threadweaver5 5.78.0-2 ii libkf5widgetsaddons5 5.78.0-2 ii libkf5xmlgui55.78.0-2 ii libkomparediff2-54:20.12.0-2 ii libokteta3core0 5:0.26.4-2 ii libokteta3gui0 5:0.26.4-2 ii libprocesscore9 4:5.20.5-1 ii libprocessui94:5.20.5-1 ii libqt5core5a 5.15.2+dfsg-3 ii libqt5dbus5 5.15.2+dfsg-3 ii libqt5gui5 5.15.2+dfsg-3 ii libqt5help5 5.15.2-3 ii libqt5network5 5.15.2+dfsg-3 ii libqt5qml5 5.15.2+dfsg-3 ii libqt5quick5 5.15.2+dfsg-3 ii libqt5quickwidgets5 5.15.2+dfsg-3 ii libqt5widgets5 5.15.2+dfsg-3 ii libqt5xml5 5.15.2+dfsg-3 ii libstdc++6 10.2.1-6 ii libsvn1 1.14.0-3+b2 ii qml-module-qtquick-controls 5.15.2-2 ii
Bug#980945: chromium: Text displayed without subpixel antialiasing
Package: chromium Version: 88.0.4324.96-0.1 Severity: normal X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, On my systems, Chromium draws text with only grayscale antialiasing, and does not use any subpixel (LCD, RGB) antialiasing. I actually found this trying to determine why programs using Qt WebEngine (based on Chromium, as I understand) were not showing subpixel antialiasing in certain content - the common element seems to be something somewhere inside Chromium. The difference between subpixel and grayscale antialiasing can be seen easily with magnifier programs like kmag. Other programs (aside from where some use WebEngine) on my system don't have this issue. I got the portable binary of ungoogled-chromium 87 from the Chromium website for comparison, and found that it does employ subpixel antialiasing. So that seems to rule out some bug in the upstream code itself. I guess it's something in the way both the Chromium package and the Qt WebEngine package are built, or in common dependencies which that portable binary provided built-in. I haven't noticed anything clearly pointing to a dependency being at issue, though, and I'm out of ideas. Peace, Brendon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 88.0.4324.96-0.1 ii libasound2 1.2.4-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libatomic1 10.2.1-6 ii libatspi2.0-02.38.0-2 ii libavcodec58 7:4.3.1-6 ii libavformat587:4.3.1-6 ii libavutil56 7:4.3.1-6 ii libc62.31-9 ii libcairo21.16.0-5 ii libcups2 2.3.3op1-7 ii libdbus-1-3 1.12.20-1 ii libdrm2 2.4.103-2 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat12.2.10-1 ii libflac8 1.3.3-2 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgbm1 20.3.2-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.24-1 ii libharfbuzz0b2.6.7-1 ii libicu67 67.1-6 ii libjpeg62-turbo 1:2.0.5-2 ii libjsoncpp24 1.9.4-4 ii liblcms2-2 2.12~rc1-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.29-1 ii libnss3 2:3.60-1 ii libopenjp2-7 2.3.1-1 ii libopus0 1.3.1-0.1 ii libpango-1.0-0 1.46.2-3 ii libpng16-16 1.6.37-3 ii libpulse014.1-1 ii libre2-9 20201101+dfsg-2 ii libsnappy1v5 1.1.8-1 ii libstdc++6 10.2.1-6 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libx11-6 2:1.7.0-2 ii libxcb1 1.14-2.1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxrandr2 2:1.5.1-1 ii libxslt1.1 1.1.34-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium recommends: ii chromium-sandbox 88.0.4324.96-0.1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.31-9 ii libstdc++6 10.2.1-6 ii libx11-62:1.7.0-2 ii libxext62:1.3.3-1.1 ii x11-utils 7.7+5 ii xdg-utils 1.1.3-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium-common recommends: ii chromium-sandbox88.0.4324.96-0.1 ii fonts-liberation1:1.07.4-11 ii libgl1-mesa-dri 20.3.2-1 ii libu2f-udev 1.1.10-3 ii notification-daemon 3.20.0-4 ii plasma-workspace [notification-daemon] 4:5.20.5-2 ii system-config-printer 1.5.14-1 ii upower 0.99.11-2 Versions of packages chromium-sandbox depends on: ii libc6 2.31-9 -- no debconf information
Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt
On Saturday, December 5, 2020 2:36:35 A.M. EST Rafael Laboissière wrote: > As Michael Miller pointed out, this problem is fixed in version 6.1.0-1 > of the octave package, which is now in experimental. There is an ongoing > transition octave 5 ⇒ 6 (or liboctave 7 ⇒ 8, or octave-abi 53 ⇒ 55) [1]. > Hopefully this will be done before the bullseye freeze. Ah, good to know. Thanks for your efforts! Best, Brendon
Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt
On Friday, November 27, 2020 3:06:12 P.M. EST Rafael Laboissière wrote: > Control: tags -1 + wontfix I'm getting bitten by this bug on my workstation. I also tried it from within a fresh user account: same issue there, so it's not a user configuration mistake. From a user perspective, wontfix is not a particularly satisfying conclusion. I noticed my laptop does not have the issue, but hasn't been updated in a while. So I (painstakingly) upgraded packages piecemeal, and observed Octave GUI's behaviour as I did... The culprit is libreadline8 (and/or readline-common). Octave GUI has no complaints with the prior version 8.0-4, but after upgrading to version 8.1~rc3-1, Octave GUI now complains about "undecodable token: \001b(hex)[? 2004h" and messes-up the command interface, as per the original report. So, does libreadline8 cause this "bracketed paste mode" to be enabled by default, now? Or perhaps something else is going on - like, perhaps /etc/ inputrc should have been updated along with readline-common, in which case we're actually getting bitten by bug #504793? Cheers, Brendon
Bug#975337: kdevelop: Fails to parse gdb 10 version string, won't debug programs
Package: kdevelop Version: 4:5.6.0-3+b1 Severity: normal Tags: upstream X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, Evidently the version string returned from GDB has changed since the major version switch from 9 to 10, and now kdevelop cannot interpret it. When I try to run a project binary in debug mode, I get a red bar across the top of the editor window saying: You need gdb 7.0.0 or higher. You are using: GNU gdb (Debian 10.1-1+b1) 10.1 Obviously 10.1 > 7.0.0, but from what I can gather, kdevelop doesn't seem to be extracting the relevant portion of the "GNU gdb (Debian 10.1-1+b1) 10.1" string. I can only close the notice bar - the debugger function in kdevelop no longer works. Triggered by local gdb package version, but I'm assuming the check logic comes from upstream. Best, Brendon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdevelop depends on: ii kdevelop-data4:5.6.0-3 ii kdevelop56-libs 4:5.6.0-3+b1 ii kinit5.74.0-2 ii kio 5.74.0-2 ii libapr1 1.7.0-3 ii libaprutil1 1.6.1-5 ii libastyle3 3.1-2+b1 ii libc62.31-4 ii libclang1-9 1:9.0.1-15 ii libgcc-s110.2.0-16 ii libgrantlee-templates5 5.2.0-2 ii libkasten4controllers0 5:0.26.4-1 ii libkasten4core0 5:0.26.4-1 ii libkasten4okteta2controllers05:0.26.4-1 ii libkasten4okteta2core0 5:0.26.4-1 ii libkasten4okteta2gui05:0.26.4-1 ii libkf5archive5 5.74.0-2 ii libkf5bookmarks5 5.74.0-2 ii libkf5codecs55.74.0-2 ii libkf5completion55.74.0-2 ii libkf5configcore55.74.0-2 ii libkf5configgui5 5.74.0-2 ii libkf5configwidgets5 5.74.0-2 ii libkf5coreaddons55.74.0-2 ii libkf5crash5 5.74.0-2 ii libkf5declarative5 5.74.0-2 ii libkf5guiaddons5 5.74.0-3 ii libkf5i18n5 5.74.0-3 ii libkf5iconthemes55.74.0-2 ii libkf5itemmodels55.74.0-2 ii libkf5itemviews5 5.74.0-2 ii libkf5jobwidgets55.74.0-2 ii libkf5kiocore5 5.74.0-2 ii libkf5kiofilewidgets55.74.0-2 ii libkf5kiogui55.74.0-2 ii libkf5kiowidgets55.74.0-2 ii libkf5newstuff5 5.74.0-2 ii libkf5parts5 5.74.0-2 ii libkf5purpose-bin5.74.0-2 ii libkf5purpose5 5.74.0-2 ii libkf5service-bin5.74.0-2 ii libkf5service5 5.74.0-2 ii libkf5sonnetui5 5.74.0-3 ii libkf5texteditor55.74.0-3 ii libkf5textwidgets5 5.74.0-2 ii libkf5threadweaver5 5.74.0-2 ii libkf5widgetsaddons5 5.74.0-3 ii libkf5xmlgui55.74.0-2+b1 ii libkomparediff2-54:20.04.3-1 ii libokteta3core0 5:0.26.4-1 ii libokteta3gui0 5:0.26.4-1 ii libprocesscore9 4:5.19.5-4 ii libprocessui94:5.19.5-4 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5dbus5 5.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5help5 5.15.1-2 ii libqt5network5 5.15.1+dfsg-2 ii libqt5qml5 5.15.1+dfsg-3 ii libqt5quick5 5.15.1+dfsg-3 ii libqt5quickwidgets5 5.15.1+dfsg-3 ii libqt5widgets5 5.15.1+dfsg-2 ii libqt5xml5 5.15.1+dfsg-2 ii libstdc++6 10.2.0-16 ii libsvn1 1.14.0-3+b1 ii qml-module-qtquick-controls 5.15.1-2 ii qml-module-qtquick-layouts 5.15.1+dfsg-3 ii qml-module-qtquick-window2 5.15.1+dfsg-3 ii qml-module-qtquick-xmllistmodel 5.15.1-2 ii qml-module-qtquick2 5.15.1+dfsg-3 ii qml-module-qtwebkit 5.212.0~alpha4-7 Versions of packages kdevelop recommends: ii clang-9 1:9.0.1-15 ii g++ 4:10.2.0-1 ii gcc 4:10.2.0-1 ii gdb 10.1-1+b1 ii kapptemplate 4:20.08.2-1 ii kio-extras4:20.08.3-1 ii make 4.3-4
Bug#973567: kmail cannot create Exchange EWS sending account without kmailtransport-akonadi package installed
Package: kmail Version: 4:20.08.2-3 Severity: minor X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, My organization recently migrated to Exchange for email service (oh joy). Long story short, a kmail user can't create a EWS sending account until they install kmailtransport-akonadi - otherwise kmail simply does not list EWS as an option. Nothing depends on this package, so an ordinary user will most likely not have it installed. Nothing seems to mention this, it's certainly not obvious, and caused me some headache to figure out why I could create a EWS receiving account but not a sending one. (Eventually I found some kind person's forum post mentioning the issue.) I think it would help if the kmail package would recommend or at least suggest kmailtransport-akonadi. Adding mention of this "sending EWS" use-case to the kmailtransport-akonadi description might also be a good idea, to aid in user discoverability. Thanks for your efforts and for considering the suggestion. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable- debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmail depends on: ii akonadi-server 4:20.08.2-2 ii kdepim-runtime 4:20.08.2-4 ii kio 5.74.0-2 ii libc62.31-4 ii libgcc-s110.2.0-15 ii libgpgmepp6 1.14.0-1+b1 ii libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.08] 4:20.08.2-2 ii libkf5akonadicontact5 [libkf5akonadicontact5-20.08] 4:20.08.2-2 ii libkf5akonadicore5abi2 [libkf5akonadicore5-20.08]4:20.08.2-2 ii libkf5akonadimime5 [libkf5akonadimime5-20.08]4:20.08.2-2 ii libkf5akonadisearch-bin 4:20.08.2-2 ii libkf5akonadisearch-plugins 4:20.08.2-2 ii libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-20.08] 4:20.08.2-2 ii libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.08] 4:20.08.2-2 ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08] 4:20.08.2-2 ii libkf5bookmarks5 5.74.0-2 ii libkf5calendarcore5abi2 5:5.74.0-2 ii libkf5calendarutils5 [libkf5calendarutils5-20.08]4:20.08.2-2 ii libkf5codecs55.74.0-2 ii libkf5completion55.74.0-2 ii libkf5configcore55.74.0-2 ii libkf5configgui5 5.74.0-2 ii libkf5configwidgets5 5.74.0-2 ii libkf5contacts5 5:5.74.0-2 ii libkf5coreaddons55.74.0-2 ii libkf5crash5 5.74.0-2 ii libkf5dbusaddons55.74.0-2 ii libkf5grantleetheme-plugins 20.08.2-2 ii libkf5gravatar5abi2 [libkf5gravatar5-20.08] 4:20.08.2-2 ii libkf5guiaddons5 5.74.0-3 ii libkf5i18n5 5.74.0-3 ii libkf5iconthemes55.74.0-2 ii libkf5identitymanagement5 [libkf5identitymanagement5-20.08] 20.08.2-2 ii libkf5itemmodels55.74.0-2 ii libkf5itemviews5 5.74.0-2 ii libkf5jobwidgets55.74.0-2 ii libkf5kcmutils5 5.74.0-2 ii libkf5kiocore5 5.74.0-2 ii libkf5kiofilewidgets55.74.0-2 ii libkf5kiogui55.74.0-2 ii libkf5kiowidgets55.74.0-2 ii libkf5kontactinterface5 [libkf5kontactinterface5-20.08] 20.08.2-2 ii libkf5ksieveui5 [libkf5ksieveui5-20.08] 4:20.08.2-2 ii libkf5ldap5abi1 [libkf5ldap5-20.08] 20.08.2-2 ii libkf5libkdepim5 [libkf5libkdepim5-20.08]4:20.08.2-2 ii libkf5libkleo5 [libkf5libkleo5-20.08]
Bug#943585: kwin-x11: kwin (?) causes extreme flickering and tear on login
A followup: Just noticed I had a file in xorg.conf.d called 20- intel.conf. Not sure where this file came from (it's quite possible I made it myself when trying to debug something since forgotten) and it seemed more-or-less empty; it's entire contents are: Section "Device" Identifier "card0" Driver "intel" #Option "AccelMethod" "uxa" EndSection Given those contents, I would've presumed there'd be no difference to the default settings. Yet if I remove that file from xorg.conf.d, the graphical issues that I was experiencing in kwin_x11 are gone! Stefan, I don't suppose you might have something similar going on with your system? Peace, Brendon On Sunday, October 27, 2019 12:06:25 P.M. EST Brendon Higgins wrote: > Hi, > > I've encountered similar behaviour: black/residual/flickering windows > making the desktop unusable after login. I also noticed some minor (white) > flickering in SDDM prior to login, although it was still quite usable at > that point. I'm running a mixed testing/unstable system, and am also using > an Intel display chip (Dell Latitude; only on-board, no discrete graphics > chip). > > I found disabling OpenGL compositing with ALT+SHIFT+F12 worked around > it at first, as did downgrading KDE+QT packages back to testing. I'm just > trying this now with unstable packages again, and running the suggestsed > 'DRI_PRIME=1 kwin_x11 --replace'also seems to work - even as the new > kwin_x11 instance brings OpenGL compositing back with it. > > Peace, > Brendon > > On Sun, 27 Oct 2019 01:15:10 +0200 Stefan Schwarzer > > wrote: > > Package: kwin-x11 > > Version: 4:5.14.5-1+b1 > > Severity: important > > > > Dear Maintainer, > > > > I am following debian unstable, desktop X11/sddm/kde on a Lenovo laptop > > T460p. > > > The nvidia graphics on the laptop is disabled in favor of the chipset > > graphics > > > (Intel). > > > > After the last upgrade (which was from testing to stable on the 25th > > October), > > > I am experiencing a mostly unusable desktop. The login screen (sddm) > > comes up > > > as expected, > > but right after login I get flickering black rectangles on the screen, > > which may > > cover up to 90% of its area. Windows mostly remain black or their content > > suddenly > > becomes visible he task bar remains black and I see other residuals of the > > kde > > > splash > > screen where windows should be drawn or the background wallpaper be > > restored. Swithing to a VT; all seems ok, kwin, the desktop and > > applications are > > running. > > > > So far, my only clue as to what may be going on is a workaroud: if I start > > a terminal > > via keyboard shortcut and issue blindly > > > > DRI_PRIME=1 kwin_x11 --replace > > > > then afterwards things behave mostly normally (Sometimes window > > contaent is > > > still > > not correctly updated). I just picked this line up from older bug reports > > against kwin on the net without understanding what it does. > > > > This is the output of kwin following this command in the hope that it > > helps > > > > OpenGL vendor string: Intel Open Source Technology > > Center > > OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 > > (Skylake GT2) > > OpenGL version string: 4.5 (Core Profile) Mesa 19.2.1 > > OpenGL shading language version string: 4.50 > > Driver: Intel > > GPU class: Unknown > > OpenGL version: 4.5 > > GLSL version: 4.50 > > Mesa version: 19.2.1 > > X server version: 1.20.4 > > Linux kernel version: 5.3 > > Requires strict binding:yes > > GLSL shaders: yes > > Texture NPOT support: yes > > Virtual Machine:no > > > > > > > > -- System Information: > > Debian Release: bullseye/sid > > > > APT prefers unstable > > APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > > 'experimental') > > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386
Bug#943585: kwin-x11: kwin (?) causes extreme flickering and tear on login
Hi, I've encountered similar behaviour: black/residual/flickering windows making the desktop unusable after login. I also noticed some minor (white) flickering in SDDM prior to login, although it was still quite usable at that point. I'm running a mixed testing/unstable system, and am also using an Intel display chip (Dell Latitude; only on-board, no discrete graphics chip). I found disabling OpenGL compositing with ALT+SHIFT+F12 worked around it at first, as did downgrading KDE+QT packages back to testing. I'm just trying this now with unstable packages again, and running the suggestsed 'DRI_PRIME=1 kwin_x11 --replace'also seems to work - even as the new kwin_x11 instance brings OpenGL compositing back with it. Peace, Brendon On Sun, 27 Oct 2019 01:15:10 +0200 Stefan Schwarzer wrote: > Package: kwin-x11 > Version: 4:5.14.5-1+b1 > Severity: important > > Dear Maintainer, > > I am following debian unstable, desktop X11/sddm/kde on a Lenovo laptop T460p. > The nvidia graphics on the laptop is disabled in favor of the chipset graphics > (Intel). > > After the last upgrade (which was from testing to stable on the 25th October), > I am experiencing a mostly unusable desktop. The login screen (sddm) comes up > as expected, > but right after login I get flickering black rectangles on the screen, which > may > cover up to 90% of its area. Windows mostly remain black or their content > suddenly > becomes visible he task bar remains black and I see other residuals of the kde > splash > screen where windows should be drawn or the background wallpaper be > restored. Swithing to a VT; all seems ok, kwin, the desktop and applications > are > running. > > So far, my only clue as to what may be going on is a workaroud: if I start a > terminal > via keyboard shortcut and issue blindly > DRI_PRIME=1 kwin_x11 --replace > then afterwards things behave mostly normally (Sometimes window contaent is > still > not correctly updated). I just picked this line up from older bug reports > against kwin on the net without understanding what it does. > > This is the output of kwin following this command in the hope that it helps > > OpenGL vendor string: Intel Open Source Technology Center > OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 > (Skylake GT2) > OpenGL version string: 4.5 (Core Profile) Mesa 19.2.1 > OpenGL shading language version string: 4.50 > Driver: Intel > GPU class: Unknown > OpenGL version: 4.5 > GLSL version: 4.50 > Mesa version: 19.2.1 > X server version: 1.20.4 > Linux kernel version: 5.3 > Requires strict binding:yes > GLSL shaders: yes > Texture NPOT support: yes > Virtual Machine:no > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386
Bug#575469: texlive-base: dvips fails to include font characters used in eps figure created by PyX
Hi Hilmar,
Wow, this is an old one of mine. I just tried to reproduce it, too, and found
the same result as you. It seems that whatever the problem was, it has
been sorted out at some point in the last 9 years.
(Interestingly, my test case does exhibit some kind of figure positioning
bug in Okular when viewing the DVI file. The "Hello, world!" is about a
centimeter too far left...)
Anyway, this bug can be closed.
Best,
Brendon
On Sunday, August 4, 2019 4:47:58 AM EDT Hilmar Preuße wrote:
> Am 26.03.2010 um 04:15 teilte Brendon Higgins mit:
>
> Hi,
>
> I'm going through some old bugs and checking them for validity.
>
> https://bugs.debian.org/575469
>
> I run your minimal example and could not reproduce your problem.
Could
> you confirm that the issue has been solved?
>
> Hilmar
>
> > The ghost of bug #266718 seems to be haunting me. I can't reproduce
it
> > using the examples given in that original bug, but I am getting
behaviour
> > that sounds basically identical if I generate EPS figures using PyX. The
> > figures themselves look fine, but when I generate PS files using dvips
> > they come out with missing glyphs.
> >
> > A minimum working example
> > #
> > fig.py:
> > from pyx import *
> > c = canvas.canvas()
> > c.text(0, 0, "Hello, world!")
> > c.writeEPSfile("fig.eps")
> >
> > test.tex:
> > \documentclass{article}
> > \usepackage{graphicx}
> > \begin{document}
> > Word.
> > \includegraphics{fig.eps}
> > Another word.
> > \end{document}
> >
> > Run (python fig.py; latex test.tex; dvips test.dvi). When I do this the
> > result is missing several glyphs from "Hello, world!" I could guess that
> > dvips is failing to determine that fig.eps uses any glyphs, but I'm just
> > uneducatedly speculating.
> >
> > I've discovered that can avoid the problem (not sure how this works) by
> > using PyX to output as a PDF rather than EPS, then running pdf2eps.
dvips
> > doesn't seem to have a problem with that, then. That might suggest it
has
> > something to do with the format of EPS PyX produces. (I don't know if
> > this suggests this is a PyX bug, though, as viewers such as Okular,
> > Evince, and even GIMP display the file just fine.)
Bug#825383: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account
On Saturday, 5 January 2019 1:49:47 PM EST Brian Potkin wrote: > On Fri 04 Jan 2019 at 11:58:53 -0500, Brendon Higgins wrote: > > hp-plugin, too. Do you have your upstream bug number handy? I'd like to > > follow progress (if any). > > It is referenced as a duplicate in the forwarded bug report. Ah, yes. Apologies, apparently I was blind that day. XD > Brendon - it is always useful to know which device make and model is > being used. In my case it's an HP Color LaserJet Pro MFP M277dw. Best, Brendon
Bug#825383: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account
On Monday, 29 January 2018 2:46:40 PM EST Brian Potkin wrote: > Without any change to password.py the plugin will install with > > sudo hp-plugin -i > > So what was chrysn referring to? Perhaps my case can serve as an illustrative example: Every time hplip package updates, the next time I go to scan something with my MFC (using gscan2pdf, say), I get a prompt that I need to download the plugin. (Is that itself a bug?) Of course it fails because my system has no root password, only sudo. In principle, the edit-password.py workaround does work, except that the package update also typically means password.py gets overwritten. And the sudo hp-plugin -i approach has issues: * "warning: It is not recommended to run 'hp-plugin' in a root mode." * "error: Unable to recieve key from keyserver" It's a bit frustrating. I have to remember to either edit password.py or run sudo hp-plugin -i every time the package updates. (Come to think of it, an install hook would be nice...) On Monday, 29 January 2018 6:03:19 PM EST Reinhard John wrote: > But as Brian pointed out, this is just a workaround, not a solution. > hp-doctor should be able to accept both types of verification. This is > intended in the file /usr/share/hplip/doctor.py (line 102 to 122) and it > doesn´t work, at least not with debian. And this is undoubtedly a bug. > We will see whether the hplip developers will react to my bug report there. hp-plugin, too. Do you have your upstream bug number handy? I'd like to follow progress (if any). Thanks, Brendon
Bug#901148: severity of 901148 is important
On Wed, 13 Jun 2018 00:42:05 +0200 Mattia Rizzolo wrote: > # definitely not RC, sorry. Forgive my ignorance, but I don't see what reasoning drove reducing this bug's severity. https://release.debian.org/testing/rc_policy.txt says "[A]n issue is release critical if it: [...] * makes unrelated software on the system (or the whole system) break". I was bitten by this bug today (in testing), and from my perspective, the timidity package broke (important, IMO) functionality of a suite of other unrelated packages. That seems to qualify for at least serious (and therefore RC) severity. Am I missing something? Thanks, Brendon
Bug#845346: fixed in qupzilla 2.2.0~dfsg1-1
Thanks for including, but it seems only the dependency change was addressed. My patch also touched two other files, but in 2.2.0-dfsg1-1, those files are the same as before. So, KWallet functionality hasn't yet been enabled... Peace, Brendon On Tuesday, 24 October 2017 9:04:28 PM EDT you wrote: > Source: qupzilla > Source-Version: 2.2.0~dfsg1-1 > > We believe that the bug you reported is fixed in the latest version of > qupzilla, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 845...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Georges Khaznadar <georg...@debian.org> (supplier of updated qupzilla > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > Format: 1.8 > Date: Mon, 23 Oct 2017 17:46:57 +0200 > Source: qupzilla > Binary: qupzilla libqupzilla1 libqupzilla-dev > Architecture: source amd64 > Version: 2.2.0~dfsg1-1 > Distribution: unstable > Urgency: medium > Maintainer: Georges Khaznadar <georg...@debian.org> > Changed-By: Georges Khaznadar <georg...@debian.org> > Description: > libqupzilla-dev - development files for qupzilla's shared library > libqupzilla1 - shared library and header files for qupzilla > qupzilla - lightweight web browser based on libqtwebkit > Closes: 845346 859674 868789 > Changes: > qupzilla (2.2.0~dfsg1-1) unstable; urgency=medium > . > * New upstream release >* changed the build dependency libssl1.0-dev => libssl-dev. > Closes: #859674 >* applied Brendon Higgins' patch. Closes: #845346 >* upgraded Standards-Version to 4.1.1 >* restricted the target Architecture: to amd64 arm64 armhf i386 mipsel > to comply with qt5webkit-dev's restrictions. Closes: #868789 > Checksums-Sha1: > f0fabebab039ec24f8bc430aeb944f619b72815c 2204 qupzilla_2.2.0~dfsg1-1.dsc > 588b9545e023557e1f4d55e5542b6d3d561e92f7 2394004 > qupzilla_2.2.0~dfsg1.orig.tar.xz efe071e962ddeb6f223743cd16b866fd8fc15e1d > 10436 qupzilla_2.2.0~dfsg1-1.debian.tar.xz > 405e54b5289024ea87ede181e86e0e9089575a88 25192 > libqupzilla-dev_2.2.0~dfsg1-1_amd64.deb > fa0951a7763db3cd4a083bf39641e4071cbb2ade 1915620 > libqupzilla1_2.2.0~dfsg1-1_amd64.deb > 9a1916d38487eb9ba9dcdda79b4655bd26fcba87 18242 > qupzilla_2.2.0~dfsg1-1_amd64.buildinfo > 565812b175ac4a77057ec61032b0b9b552ef327e 759836 > qupzilla_2.2.0~dfsg1-1_amd64.deb Checksums-Sha256: > 934201c837d8a44c4eda922b85bb47281af816641e7ebc04edabe63ad6cb99e8 2204 > qupzilla_2.2.0~dfsg1-1.dsc > 6d108eff6085abf36951e012c827d305428ab5d7136a82fa0e025d3db226d919 2394004 > qupzilla_2.2.0~dfsg1.orig.tar.xz > 16038178dc27093aa1749fc1f23c326cbd81879e7a4271e3359f5b41f666acec 10436 > qupzilla_2.2.0~dfsg1-1.debian.tar.xz > 9c41f121e30a186fa16b27490adf599c2c0e942943bf50ef786fa0cbf4f9b267 25192 > libqupzilla-dev_2.2.0~dfsg1-1_amd64.deb > 571d4f40580083fee24883f50ba200a575635f3510ec5462f19d1e3cf0c9b105 1915620 > libqupzilla1_2.2.0~dfsg1-1_amd64.deb > 74df94b670bc65f8e014b5ca03693d253781dcd64ab9d25b2e6d0adc899e1e48 18242 > qupzilla_2.2.0~dfsg1-1_amd64.buildinfo > 2ac4a20920458ff08ce58e78ea2709bc38a3aff261fc09fe7d730568a42a4a05 759836 > qupzilla_2.2.0~dfsg1-1_amd64.deb Files: > 3b47e1d9e86ff5ea28a2e9b3f00e3124 2204 web extra qupzilla_2.2.0~dfsg1-1.dsc > d02944b9765fa26057dd76da49415c6b 2394004 web extra > qupzilla_2.2.0~dfsg1.orig.tar.xz 19063b5a807e3a553de62895a5afb88a 10436 web > extra qupzilla_2.2.0~dfsg1-1.debian.tar.xz 5dff73fad27fcd81a4784440b186b620 > 25192 libdevel extra libqupzilla-dev_2.2.0~dfsg1-1_amd64.deb > 699814aff2e8dc9f8de8e97a7367e615 1915620 libs extra > libqupzilla1_2.2.0~dfsg1-1_amd64.deb ae9e7489a4a35e88c8d04dfe80b8a7fe 18242 > web extra qupzilla_2.2.0~dfsg1-1_amd64.buildinfo > 45a1fa75ee768ebf5e2ce43c1b9bdceb 759836 web extra > qupzilla_2.2.0~dfsg1-1_amd64.deb
Bug#878074: Update virtualbox-guest-* will remove a well running ntp
With the theme that every change breaks someone's workflow*, my workflow has it that I usually run my Debian partition in a real environment, but sometimes I have to run Windows, so when that's the case I run my Debian partition as as VirtualBox guest. I expect this conflict against ntp will mean that my clock will drift on days/weeks where I'm not running Windows. My personal preference would be for a different solution... Peace, Brendon *And, as per https://xkcd.com/1172/ , I await your response of "That's horrifying." :)
Bug#845346: qupzilla: QupZilla is built without kwallet support
Hi, This was bugging me as well, so I made some changes to the Debian package source, and the KWallet plugin seems to be working for me now with KDE 5's KWallet. Patch attached. Hope it's helpful. Peace, Brendon diff -Naur qupzilla-2.0.2~dfsg1.orig/debian/control qupzilla-2.0.2~dfsg1/debian/control --- qupzilla-2.0.2~dfsg1.orig/debian/control 2017-01-11 12:43:00.0 -0500 +++ qupzilla-2.0.2~dfsg1/debian/control 2017-04-14 16:50:37.093046718 -0400 @@ -9,7 +9,7 @@ qtbase5-private-dev, qtscript5-dev, libqt5x11extras5-dev, libx11-dev, - libssl1.0-dev, kdelibs5-dev, libgnome-keyring-dev, + libssl1.0-dev, libkf5wallet-dev, libgnome-keyring-dev, libjs-jquery, libjs-jquery-ui Standards-Version: 3.9.8 Homepage: http://www.qupzilla.com/ diff -Naur qupzilla-2.0.2~dfsg1.orig/debian/patches/kde-integration.patch qupzilla-2.0.2~dfsg1/debian/patches/kde-integration.patch --- qupzilla-2.0.2~dfsg1.orig/debian/patches/kde-integration.patch 1969-12-31 19:00:00.0 -0500 +++ qupzilla-2.0.2~dfsg1/debian/patches/kde-integration.patch 2017-04-14 16:54:05.972901755 -0400 @@ -0,0 +1,17 @@ +Index: qupzilla-2.0.2~dfsg1/src/plugins/plugins.pro +=== +--- qupzilla-2.0.2~dfsg1.orig/src/plugins/plugins.pro qupzilla-2.0.2~dfsg1/src/plugins/plugins.pro +@@ -32,9 +32,10 @@ outOfDirPlugins = $$(QUPZILLA_PLUGINS_SR + # TestPlugin only in debug build + !CONFIG(debug, debug|release): disablePlugin(TestPlugin) + ++## enforced KDE_INTEGRATION + # KWalletPasswords only with KDE_INTEGRATION and KWallet framework +-!contains(DEFINES, KDE_INTEGRATION): disablePlugin(KWalletPasswords) +-!qtHaveModule(KWallet): disablePlugin(KWalletPasswords) ++# !contains(DEFINES, KDE_INTEGRATION): disablePlugin(KWalletPasswords) ++# !qtHaveModule(KWallet): disablePlugin(KWalletPasswords) + + ## enforced GNOME_INTEGRATION + # GnomeKeyringPasswords only with GNOME_INTEGRATION and gnome-keyring pkg-config diff -Naur qupzilla-2.0.2~dfsg1.orig/debian/patches/series qupzilla-2.0.2~dfsg1/debian/patches/series --- qupzilla-2.0.2~dfsg1.orig/debian/patches/series 2015-04-16 17:20:39.0 -0400 +++ qupzilla-2.0.2~dfsg1/debian/patches/series 2017-04-14 16:52:23.148972777 -0400 @@ -1,2 +1,3 @@ hardening.patch gnome-integration.patch +kde-integration.patch
Bug#849352: gimp: Saving overtop existing BZ2 compressesd XCF files does not truncate them
On Monday, December 26, 2016 1:03:49 AM EST Ari Pollak wrote: > Is the undo history saved too, which should contain the original layers? I considered that, too, but the undo history is blank (except for the single "Base Image" item) when I load the file. Also, that wouldn't explain bunzip2 complaining about trialing garbage, nor the fact that the uncompressed .xcf file bunzip2 produces (which, for the record, can itself be correctly opened in gimp) is significantly smaller than the .xcf.bz2 file that gimp had saved. Peace, Brendon
Bug#846389: plasma-workspace: To every moment it cracks the plasmashell.
Does switching to the VT console (e.g. ctrl+alt+f1) and back again (ctrl+alt +f7) unfreeze things? If so, this might be the same bug: https://bugzilla.redhat.com/show_bug.cgi?id=1399396 I'm experiencing this on two different machines, one using the radeon driver and another using the nouveau driver. Peace, Brendon
Bug#766426: Dolphin search displays "Invalid protocol" error.
For the benefit of those, like me, who encounter this problem with a recent install, note that the solution has changed since the transition in Testing to KDE Frameworks 5: don't install baloo4, it won't work with current dolphin. Instead, install baloo-kf5. Maintainers, please consider making plasma-desktop (or some package you think is more appropriate - perhaps dolphin) at least recommend baloo-kf5. From what I can tell, right now, nothing even suggests baloo-kf5, and it's rather opaque to an ordinary user that this package might be necessary for some standard functionality. Peace, Brendon
Bug#793026: kwin-x11: kwin is not started
This doesn't seem to be fixed. I now have three separate machines, all tracking testing with a sprinkle of unstable packages (which includes those for kwin and kde-window-manager), none of which run kwin_x11 at login. They do all have the correct x-window-manager alternative set, and I can manually start kwin_x11 after login. From my investigation, the problem is that ksmserver, which is what starts the window manager, by default attempts to find the kwin binary, but this binary no longer exists. Evidence for this is that I see 'KSMServer::wmProcessChange: Window manager kwin failed to launch' in my .xsession-errors file, and examining the source code (http://api.kde.org/4.x-api/workspace-apidocs/plasma-workspace/html/ksmserver_2startup_8cpp_source.html, lines 233 and 234) suggests this really is the name of the binary ksmserver is looking for. If correct, I should be able to work around the issue by (as root) creating a link /usr/bin/kwin that points to kwin_x11. Indeed, I just checked, and that does appear to work. Peace, Brendon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763281: konqueror: Session management does not work for Konqueror
I'm also experiencing this, on three different computers. For me, upon login, the same number of konqueror windows will appear as there was when I logged out, but they are all blank/show the default page. Problem occurs whether using KHTML or WebKit renderer, so that doesn't seem to be it... Peace, Brendon On Sun, 28 Sep 2014 22:11:25 0200 =?utf-8?q?Patrick_H=C3=A4cker?= pa...@web.de wrote: Package: konqueror Version: 4:4.14.1-1 Severity: normal Dear Maintainer, on two different computers, the session management does not work any longer for Konqueror, i.e. logging out and in again does not restore the opened tabs in Konqueror. Kind regards Patrick -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-proposed- updates'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages konqueror depends on: ii install-info5.2.0.dfsg.1-4 ii kde-baseapps-bin4:4.14.1-1 ii kde-baseapps-data 4:4.14.1-1 ii kde-runtime 4:4.14.1-1 ii libc6 2.19-11 ii libkactivities6 4:4.13.3-1 ii libkcmutils44:4.14.1-1 ii libkde3support4 4:4.14.1-1 ii libkdecore5 4:4.14.1-1 ii libkdesu5 4:4.14.1-1 ii libkdeui5 4:4.14.1-1 ii libkfile4 4:4.14.1-1 ii libkhtml5 4:4.14.1-1 ii libkio5 4:4.14.1-1 ii libkonq5abi14:4.14.1-1 ii libkonqsidebarplugin4a 4:4.14.1-1 ii libkparts4 4:4.14.1-1 ii libqt4-dbus 4:4.8.6 git64-g5dc8b2b dfsg-2 ii libqt4-qt3support 4:4.8.6 git64-g5dc8b2b dfsg-2 ii libqt4-xml 4:4.8.6 git64-g5dc8b2b dfsg-2 ii libqtcore4 4:4.8.6 git64-g5dc8b2b dfsg-2 ii libqtgui4 4:4.8.6 git64-g5dc8b2b dfsg-2 ii libstdc 6 4.9.1-14 ii libx11-62:1.6.2-3 Versions of packages konqueror recommends: ii dolphin 4:4.14.1-1 ii kfind4:4.14.1-1 ii konqueror-nsplugins 4:4.14.1-1 ii kpart-webkit 1.3.4-1 Versions of packages konqueror suggests: ii konq-plugins 4:4.14.1-1 -- 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#743297: plasma-widgets-addons: fuzzy clock should say 'X til T' instead of 'X to T'
This suggestion seems to be very subjective and/or region specific. E.g. I've personally only ever heard it as X to Y, and never X til Y. If it were til I would be at least as justified in filing a similar bug to change it to to - if not more justified, as I suspect to is actually more common usage. Peace, Brendon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727555: python-qt4: Crashes plasma-desktop on startup
I've been running into this crash, also. I'm currently working around it by uninstalling plasma-scriptengine-python, but of course that breaks python- based plasma widgets. In my case, I don't use veromix, but I have a small python plasma widget I wrote myself. So with plasma-scriptengine-python uninstalled, I see Could not create a Python... error message on the desktop where my widget should be. Presumably any python plasma widget will trigger the crash (though veromix seems like it's the only one that is packaged). Peace, Brendon On Thu October 24, 2013 11:05:05 Ralf Jung wrote: Hi again, some more information: * Just upgrading python-sip (and leaving python-qt4 at the old version) also triggers the crash. * Uninstalling veromix fixes the crash. * I attached the backtrace. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577854: ipe: Editing circular arcs can lead to unrestrained memory allocation, eventual crash
Steve M. Robbins wrote (August 30, 2011): Before I report this again, could you kindly verify it still happens with the current ipe in testing/unstable (7.0.14)? I have just tried, and failed, to reproduce the issue. Hi Steve, It does seem that the behavior in the current version has changed. Now ipe seems to prevent the centre point going out to infinity when the other two points are made horizontal. While this solution can result in an arc line that does not connect the two arc points (the line arcs away from one because the centre point is left at the last valid finite coordinate), this is certainly preferable to the previous behavior. So I'd say this is closed. Thanks, Brendon signature.asc Description: This is a digitally signed message part.
Bug#597676: Export options vanish every other time
Hi, (Original reporter here.) I just tried with a clean ~/.lyx, and things seem to behave themselves. So there's something in my .lyx that lyx does not like. It turns out that it's certainly my preferences file. I narrowed it down after comparing the two folders recursively and moving things to the clean .lyx one by one. I had a look at the settings for these formats, and noticed that Document Format is not ticked for them. If I change that for, say, PDF (pdflatex) so that it is ticked, then that particular option shows up in the Export menu all the time, as you ought to expect. Before anyone shouts PEBKAC, while I did change the viewer application option (as you can tell), I don't believe I would have been silly enough to change that tick mark. I reckon, somehow, that property must have been either unchecked or not set by default properly when this property was introduced in an earlier version. (I've been using lyx on this machine since 2006, and would have had similar settings, using kghostview rather than okular.) Anyway, I know how to work around it, now. Though it doesn't explain why LyX should start assuming the formats are document formats after it performs the reconfiguration (without altering the preferences). Peace, Brendon Sven Hoexter wrote (2010-10-05 19:10): Hi, I currently fail to help with debugging this problem any further so maybe someone here has an idea how to proceed. Summary: Export options only appear when reconfigure just ran and LyX got restarted. After a second restart they're missing again. configure.log and lyxrc.defaults seem to be fine. The complete bugreport in the Debian BTS, with all attached files, is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597676 Filled against Lyx 1.6.7. I'm not sure if lyx -dbg has something useful to provide, I just tried -dbg 32 but that's not giving much output about what it found in lyxrc.defaults. Anyone with a good idea how to debug this issue further? I've also attached my preferences file, because it also contains some settings for viewing PDFs. Possible relevant, I'm not sure. Looks sane as far as I can tell. TIA, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597676: [Pkg-lyx-devel] Bug#597676: Bug#597676: [lyx] Export to PDF requires texlive-fonts-extra package
\tex_allows_spaces true \plaintext_roff_command groff -t -Tlatin1 $$FName \chktex_command \bibtex_command bibtex \jbibtex_command bibtex \index_command texindy \jindex_command makeindex -c -q \nomencl_command makeindex -s nomencl.ist \spell_command \print_spool_printerprefix -d \print_spool_command lp \copierfigpython -tt $$s/scripts/fig_copy.py $$i $$o \copierpstex python -tt $$s/scripts/tex_copy.py $$i $$o $$l \copierpdftex python -tt $$s/scripts/tex_copy.py $$i $$o $$l \copierprogrampython -tt $$s/scripts/ext_copy.py $$i $$o \font_encoding T1 # This file is written by LyX, if you want to make your own # modifications you should do them from inside LyX and save # # MISC SECTION ## # # The default papersize to use. \default_papersize a4 \serverpipe /home/brendon/.lyx/lyxpipe \user_name Brendon Higgins \user_email \preview on # # SCREEN FONTS SECTION # \screen_font_roman Times New Roman \screen_font_sans Arial \screen_font_typewriter Courier New # # COLOR SECTION ### # \set_color cursor #00 \set_color background #faf0e6 \set_color foreground #00 \set_color selection #add8e6 \set_color latex #8b \set_color preview #00 \set_color note #00 \set_color notebg #00 \set_color depthbar #cd5c5c \set_color language #ff \set_color command #00 \set_color commandbg #f0 \set_color commandframe #00 \set_color special #4169e1 \set_color graphicsbg #faf0e6 \set_color math #8b \set_color mathbg #faf0e6 \set_color mathmacrobg #faf0e6 \set_color mathframe #ff00ff \set_color mathline #ff \set_color captionframe #8b \set_color collapsable #8b \set_color collapsableframe #cd5c5c \set_color insetframe #cd5c5c \set_color error #ff \set_color eolmarker #a52a2a \set_color added_space #a52a2a \set_color topline #a52a2a \set_color tabularline #00 \set_color tabularonoffline #b0c4de \set_color pagebreak #4169e1 \set_color buttonbg #cc # # PRINTER SECTION ### # # # EXPORT SECTION # # # TEX SECTION ### # # # FILE SECTION ## # # # PLAIN TEXT EXPORT SECTION ## # # # SPELLCHECKER SECTION ## # \spell_command aspell \use_alt_language true \alternate_language en_GB-ise # # LANGUAGE SUPPORT SECTION ## # # # 2nd MISC SUPPORT SECTION ## # \default_language british # # FORMATS SECTION ## # \format dvi dvi DVI D kdvi \format pdf3 pdf PDF (dvipdfm) m okular \format pdf2 pdf PDF (pdflatex) F okular \format pdf pdf PDF (ps2pdf) P okular \format ps ps Postscript t kghostview # # CONVERTERS SECTION ## # # # COPIERS SECTION ## #
Bug#597676: [Pkg-lyx-devel] Bug#597676: [lyx] Export to PDF requires texlive-fonts-extra package
Sven Hoexter wrote (Wednesday 22 September 2010): On Wed, Sep 22, 2010 at 01:04:24PM +1000, Brendon Higgins wrote: Hi. I noticed that you cannot export to PDF file from the File-Export menu unless texlive-fonts-extra is installed. Otherwise, there is no PDF output option listed. You don't need to be writing any special document; a new default article behaves the same. To get the File-Export-PDF (*) options you have to install texlive-fonts-extra, and then tell LyX it exists by doing a Tools-Reconfigure. Hm sounds odd and I can't reproduce it here. Just cleared my .lyx directory and I've only texlive-fonts-recommended installed and everything works fine. I tried several pdf export options dvipdfm, pdflatex and ps2pdf. All work fine here. I've just noticed that after closing and reopening LyX, the PDF export options don't stay. Each time, I can run Reconfigure and the PDF options reappear (as well as DVI and Postscript options). All the files in .lyx are u+rw, though - there doesn't seem to be any reason why it would do this. Strangely, I've now tried purging the fonts-extra package and after I run Reconfigure, the PDF options show in the export menu anyway (but don't stay there after I close LyX). I know I ran Reconfigure, without success, before I tried installing fonts-extra. Well, maybe the package triggers caused regeneration of some files that made LyX happier. :-/ Could you please attach the ~./lyx/configure.log for the setup where the export did not work? Attached. This is when I ran it before installing texlive-fonts-extra. I've checked and it's identical to the configure.log after purging fonts-extra. Also attached is the configure.log when texlive-fonts-extras is installed. Peace, Brendon checking for a Latex2e program... +checking for latex... yes checking for a DVI postprocessing program... +checking for pplatex... no checking for pLaTeX, the Japanese LaTeX... +checking for platex... no checking for a Tgif viewer and editor... +checking for tgif... no checking for a FIG viewer and editor... +checking for xfig... no +checking for jfig3-itext.jar... no +checking for jfig3.jar... no checking for a Dia viewer and editor... +checking for dia... no checking for a Grace viewer and editor... +checking for xmgrace... no checking for a FEN viewer and editor... +checking for xboard... no checking for an SVG viewer and editor... +checking for inkscape... yes checking for a raster image viewer... +checking for xdg-open... yes checking for a raster image editor... +checking for gimp-remote... no +checking for gimp... yes checking for a text editor... +checking for sensible-editor... yes checking for a BibTeX editor... +checking for sensible-editor... yes checking for a Postscript previewer... +checking for xdg-open... yes checking for a PDF previewer... +checking for xdg-open... yes checking for a DVI previewer... +checking for xdg-open... yes checking for an HTML previewer... +checking for xdg-open... yes checking for Noteedit... +checking for noteedit... no checking for an OpenDocument viewer... +checking for xdg-open... yes checking for the pdflatex program... +checking for pdflatex... yes checking for a LaTeX/Noweb - LyX converter... +checking for tex2lyx... yes checking for a Noweb - LaTeX converter... +checking for noweave... no checking for an HTML - LaTeX converter... +checking for html2latex... no +checking for gnuhtml2latex... no +checking for htmltolatex... no +checking for java... yes checking for an MS Word - LaTeX converter... +checking for wvCleanLatex... yes checking for elyxer module... no checking for a LyX - HTML converter... +checking for elyxer.py... no +checking for elyxer... no checking for a LaTeX - HTML converter... +checking for htlatex... no +checking for htlatex.sh... no +checking for /usr/share/tex4ht/htlatex... no +checking for tth... no +checking for latex2html... no +checking for hevea... no checking for a LaTeX - MS Word converter... +checking for htlatex... no +checking for htlatex.sh... no +checking for /usr/share/tex4ht/htlatex... no checking for an OpenOffice.org - LaTeX converter... +checking for w2l... no checking for an OpenDocument - LaTeX converter... +checking for w2l... no checking for a LaTeX - Open Document converter... +checking for oolatex... no +checking for mk4ht... no +checking for oolatex.sh... no +checking for /usr/share/tex4ht/oolatex... no +checking for htlatex... no checking for a LaTeX - RTF converter... +checking for latex2rtf... no +checking for latex2rt... no checking for a RTF - HTML converter... +checking for unrtf... no checking for a PS to PDF converter... +checking for ps2pdf13... yes checking for a PS to TXT converter... +checking for pstotext... no checking for a PS to TXT converter... +checking for ps2ascii... yes checking for a PS to EPS converter... +checking for ps2eps... yes checking
Bug#597676: [lyx] Export to PDF requires texlive-fonts-extra package
Package: lyx Version: 1.6.7-1 Severity: normal --- Please enter the report below this line. --- Hi. I noticed that you cannot export to PDF file from the File-Export menu unless texlive-fonts-extra is installed. Otherwise, there is no PDF output option listed. You don't need to be writing any special document; a new default article behaves the same. To get the File-Export-PDF (*) options you have to install texlive-fonts-extra, and then tell LyX it exists by doing a Tools-Reconfigure. What's a bit weird is that you can still generate the preview PDF by clicking the View PDF toolbar button. This seems to work regardless of whether or not texlive-fonts-extra is installed. (Seems a bit suspicious to me, as if LyX doesn't really need texlive-fonts-extra to export to PDF, but insists on it anyway.) Peace, Brendon --- System information. --- Architecture: amd64 Kernel: Linux 2.6.34-1-amd64 Debian Release: squeeze/sid 990 testing ftp.au.debian.org 99 unstablewww.debian-multimedia.org 99 testing www.debian-multimedia.org 500 unstableftp.au.debian.org 104 experimentalftp.au.debian.org --- Package information. --- Depends (Version) | Installed ==-+- libaiksaurus-1.2-0c2a (= 1.2.1+dev-0.12) | 1.2.1+dev-0.12-6 libboost-regex1.42.0 (= 1.42.0-1) | 1.42.0-4 libboost-signals1.42.0 (= 1.42.0-1) | 1.42.0-4 libc6 (= 2.3) | 2.11.2-6 libenchant1c2a(= 1.6) | 1.6.0-1 libgcc1 (= 1:4.1.1) | 1:4.4.4-8 libqtcore4(= 4:4.6.1) | 4:4.6.3-2 libqtgui4 (= 4:4.6.1) | 4:4.6.3-2 libstdc++6 (= 4.4.0) | 4.4.4-8 zlib1g(= 1:1.1.4) | 1:1.2.3.4.dfsg-3 lyx-common (= 1.6.7-1) | 1.6.7-1 xdg-utils | 1.0.2+cvs20100307-2 mime-support | 3.48-1 Recommends (Version) | Installed -+-=== texlive-latex-recommended| 2009-10 texlive-latex-extra | 2009-9 texlive-science | 2009-9 texlive-fonts-recommended| 2009-10 preview-latex-style | 11.85-1 dvipng | 1.13-1 imagemagick | 8:6.6.0.4-2.2 psutils | 1.17-27 ghostscript | 8.71~dfsg2-6 poppler-utils| 0.12.4-1.1 ttf-lyx | 1.6.7-1 evince | 2.30.3-1 OR pdf-viewer | librsvg2-bin | 2.26.3-1 OR inkscape | 0.47.0-2+b1 Suggests(Version) | Installed =-+-=== rcs | 5.7-25 dvipost | 1.1-4 elyxer| OR tex4ht| 20090611-1.1 OR hevea | OR tth | OR latex2html| 2008-debian1-5 groff | 1.20.1-10 libtiff-tools | 3.9.4-3 gnuhtml2latex | 0.4-1 wv| 1.2.4-2+b1 chktex| 1.6.3-2.1 noweb | menu | 2.1.43 sgmltools-lite| linuxdoc-tools| writer2latex | latex2rtf | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
Alesh Slovak wrote (Mon, 5 Jul 2010):
On 07/05/2010 09:22 AM, Brendon Higgins wrote:
The test -e command is protected by an , so a failure will not
trigger an early exit and all files will be correctly removed.
I guess you're right. But I tried the script with exit 0 added at the
last line and it failed anyway. I added echo blah statements to find
where it was aborting, and it seemed to be at that test statement. When
I changed it to an if ... fi clause, the problem ceased.
That's odd, our testing went just fine.
Something really odd seems to be going on. It works without errors when I try
this:
awk '{print $2}' $STATE_DIR/clean-files \
| while read file; do
echo ha
test -e ${DESTDIR}$file rm -f ${DESTDIR}$file
echo ho
done
However, if I comment out the echo ho line, it fails. It's like the result
of the test on that last line is erroneously propagating as the result of the
loop, or something.
Can you tell me what shell you are using?
/bin/sh links to dash. I just updated to the latest in unstable - problem
remains. Users see bash.
I also noticed that both files listed in clean-files actually exist, both
before
and after I run update-initramfs. But the rm shouldn't return an error, and
even if it does, adding an echo command after it shouldn't fix it. At least, I
don't see why.
Really weird. :-S
Peace,
Brendon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
Alesh Slovak wrote (2010-07-05 09:18): On 07/03/2010 10:24 AM, Brendon Higgins wrote: Hi Alesh, Alesh Slovak wrote (Thursday 01 July 2010): If the very last file that iscan's hook script checks for in DESTDIR doesn't exist, the `test -e` call fails and the script ends with a failed status even though nothing really went wrong. A simple `exit 0` on the last line fixes this. It's actually not that simple. Running the iscan hook script with set -e means that the script will abort with an error status as soon as the test -e fails for any file in the clean-files list. Adding exit 0 at the end of the script won't fix that, because the script will never reach that point anyway. I had thought the same at first, but according to the bash man page, the `-e` option exits immediately if any *untested* command fails. A similar statement exists in the dash man page as well. The test -e command is protected by an , so a failure will not trigger an early exit and all files will be correctly removed. I guess you're right. But I tried the script with exit 0 added at the last line and it failed anyway. I added echo blah statements to find where it was aborting, and it seemed to be at that test statement. When I changed it to an if ... fi clause, the problem ceased. So I don't know why it was doing that. Peace, Brendon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
Hi Alesh,
Alesh Slovak wrote (Thursday 01 July 2010):
If the very last file that iscan's hook script checks for in DESTDIR
doesn't exist, the `test -e` call fails and the script ends with a failed
status even though nothing really went wrong. A simple `exit 0` on the
last line fixes this.
It's actually not that simple. Running the iscan hook script with set -e
means that the script will abort with an error status as soon as the test -e
fails for any file in the clean-files list. Adding exit 0 at the end of the
script won't fix that, because the script will never reach that point anyway.
Additionally, this means that the script does not remove all the existing files
listed in clean-files that come after the first file that doesn't exist.
Probably the easiest solution is to just turn that troublesome test -e line
into an if ... fi clause, e.g.:
if test -e ${DESTDIR}$file; then rm -f ${DESTDIR}$file; fi
or something similar.
You might have realised this already, but I felt that it's better to be safe
than sorry. :-)
Peace,
Brendon
signature.asc
Description: This is a digitally signed message part.
Bug#572837: continued anyway after pressing ESC at a prompt
Package: dar Severity: normal Hi again, This bug is really only half fixed. The wording of the message is a bit clearer now, though it could be improved if the answer was Yes | No, for example, rather than OK | Cancel. Cancel implies cancelling an operation in progress (i.e. the program itself - this was my original interpretation of the message), rather than denying a proposed action. But also, the regex the program is using to detect whether slices of old archives exists catches too many cases. Again I was in the situation where I had an archive titled such as example.large transforming to example. dar_xform has no need to complain about this situation. I can only presume the regex is parsing the .large part of the name as the slice number, rather the real slice number that immediately follows it. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (104, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dar depends on: ii libattr11:2.4.44-1 Extended attribute shared library ii libbz2-1.0 1.0.5-4 high-quality block-sorting file co ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libdar64-4 2.3.10-1 Disk ARchive: Shared library ii libgcc1 1:4.4.2-9GCC support library ii libssl0.9.8 0.9.8n-1 SSL shared libraries ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dar recommends no packages. Versions of packages dar suggests: ii dar-docs 2.3.10-1 Disk ARchive: Backup directory tre pn par2 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577854: ipe: Editing circular arcs can lead to unrestrained memory allocation, eventual crash
Package: ipe Version: 7.0.10-2 Severity: normal Hi, I'd recommend disabling swap before you try this. Steps to reproduce: 1. Enable snapping to the grid. 2. Create a circular arc using the centre and two points tool. Make it so the two points are spaced along a vertical line. 3. Edit the arc (CTRL-E) and move one of the points so that it is horizontal to the other point. The centre will move out and, as soon as the two points are in a horizontal line, ipe will immediately consume all RAM and (if you have it) start thrashing swap space, making the machine quite unusable. I would've reported it upstream, but they do not seem to accept unsolicited communications of any kind (i.e. I'd have to sign up to bugzilla or subscribe to the mailing list), which seem a bit rude to me. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (104, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ipe depends on: ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-3 The Cairo 2D vector graphics libra ii libgcc1 1:4.4.2-9 GCC support library ii libipe7.0.10 7.0.10-2 Ipe library used by ipelets ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro ii libqtcore44:4.5.3-4 Qt 4 core module ii libqtgui4 4:4.5.3-4 Qt 4 GUI module ii libstdc++64.4.2-9The GNU Standard C++ Library v3 ii texlive-latex 2009-8 TeX Live: Basic LaTeX packages Versions of packages ipe recommends: ii lua5.15.1.4-5Simple, extensible, embeddable pro Versions of packages ipe suggests: ii texlive-latex-recommended 2009-8 TeX Live: LaTeX recommended packag -- 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#575469: texlive-base: dvips fails to include font characters used in eps figure created by PyX
Package: texlive-base
Version: 2009-8
Severity: normal
The ghost of bug #266718 seems to be haunting me. I can't reproduce it using
the examples given in that original bug, but I am getting behaviour that sounds
basically identical if I generate EPS figures using PyX. The figures
themselves look fine, but when I generate PS files using dvips they come out
with missing glyphs.
A minimum working example
#
fig.py:
from pyx import *
c = canvas.canvas()
c.text(0, 0, Hello, world!)
c.writeEPSfile(fig.eps)
test.tex:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
Word.
\includegraphics{fig.eps}
Another word.
\end{document}
Run (python fig.py; latex test.tex; dvips test.dvi). When I do this the result
is missing several glyphs from Hello, world! I could guess that dvips is
failing to determine that fig.eps uses any glyphs, but I'm just uneducatedly
speculating.
I've discovered that can avoid the problem (not sure how this works) by using
PyX to output as a PDF rather than EPS, then running pdf2eps. dvips doesn't
seem to have a problem with that, then. That might suggest it has something to
do with the format of EPS PyX produces. (I don't know if this suggests this is
a PyX bug, though, as viewers such as Okular, Evince, and even GIMP display the
file just fine.)
##
List of ls-R files
-rw-r--r-- 1 root root 1303 Mar 19 16:13 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 80 Feb 20 18:44 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Mar 5 14:26 /usr/share/texmf/ls-R -
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 27 Mar 19 15:55 /usr/share/texmf-texlive/ls-R -
/var/lib/texmf/ls-R-TEXLIVE
lrwxrwxrwx 1 root root 27 Mar 19 15:55 /usr/share/texmf-texlive/ls-R -
/var/lib/texmf/ls-R-TEXLIVE
##
Config files
lrwxrwxrwx 1 root root 20 Mar 5 14:26 /usr/share/texmf/web2c/texmf.cnf -
/etc/texmf/texmf.cnf
-rw-r--r-- 1 root root 6357 Mar 19 16:13 /var/lib/texmf/web2c/fmtutil.cnf
-rw-r--r-- 1 root root 12482 Mar 19 16:13 /var/lib/texmf/web2c/updmap.cfg
-rw-r--r-- 1 root root 8072 Mar 19 16:13
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 4
-rw-r--r-- 1 root root 283 Jun 21 2007 mktex.cnf
##
md5sums of texmf.d
3875bf0f4a53a29b7f247399dc9833e2 /etc/texmf/texmf.d/05TeXMF.cnf
6e82a3d4c00ae7e4f86aa8dcf9438cf3 /etc/texmf/texmf.d/15Plain.cnf
c60a084820a0b73e3bfbf2e90bda437c /etc/texmf/texmf.d/45TeXinputs.cnf
ea33127256c6a9f37145ae5b16fdb80c /etc/texmf/texmf.d/55Fonts.cnf
afccf1d3f87057411166a77c58e00bd1 /etc/texmf/texmf.d/65BibTeX.cnf
9da7c1c7b1eaf06f941af91f48a23068 /etc/texmf/texmf.d/75DviPS.cnf
7ae52efac46feb97010986e57877d12e /etc/texmf/texmf.d/80DVIPDFMx.cnf
055e06548bac99958d8ab2dd1248f2b4 /etc/texmf/texmf.d/80tex4ht.cnf
37329819f1109e8a457e64b8b58fecdb /etc/texmf/texmf.d/85Misc.cnf
a8952d594677235951d447665ec46e9c /etc/texmf/texmf.d/90TeXDoc.cnf
bab3b7e578107f999fa1b0768994f6f8 /etc/texmf/texmf.d/95NonPath.cnf
1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages texlive-base depends on:
ii dpkg 1.15.5.6 Debian package management system
ii install-info 4.13a.dfsg.1-5 Manage installed documentation in
ii luatex0.50.0-1 next generation TeX engine
ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap
ii tex-common2.07 common infrastructure for building
ii texlive-binaries 2009-5 Binaries for TeX Live
ii texlive-common2009-8 TeX Live: Base component
ii texlive-doc-base 2009-2 TeX Live: TeX Live documentation
Versions of packages texlive-base recommends:
ii lmodern 2.004.1-3 scalable PostScript and OpenType f
Versions of packages texlive-base suggests:
ii acroread [pdf-viewer] 9.3-0.0 Adobe Acrobat Reader: Portable Doc
ii evince [postscript-viewer] 2.28.2-1 Document (postscript, pdf) viewer
ii ghostscript [postscript-vie 8.71~dfsg-2 The GPL Ghostscript PostScript/PDF
ii gv [postscript-viewer] 1:3.6.8-1PostScript and PDF viewer for X
ii okular [postscript-viewer] 4:4.3.4-1+b1 document viewer for KDE 4
ii perl-tk 1:804.028-6 Perl module providing the Tk graph
Versions of packages tex-common depends on:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii dpkg 1.15.5.6 Debian package management system
ii ucf
Bug#572837: dar_xform continued anyway after pressing ESC at a prompt
Package: dar Version: 2.3.9-2 Severity: normal Hi, I had a dar archive example.1.dar, and moved it to example.large.1.dar. I wanted to use dar_xform to split the archive across multiple files (to fit on an optical medium). When I tried to use dar_xform (as in dar_xform -S 850M -s 1G example.large example) it complained: At least one slice of an old archive with the same basename remains in the directory . , If you do not remove these all first, you will have difficulty identifying the last slice of the archive you are about to create, because it may be hidden in between slices of this older archive. Do we remove the old archive's slices first ? [return = OK | Esc = cancel] I'm sure I have no idea what it's talking about. This is possibly a bug in it's own right - a bad regex picking up the wrong dot, perhaps. Anyway, I pressed ESC, so I could assess the situation. Then dar_xform printed Escaping... and performed the operation anyway! I ended up with the split files I wanted, but dar_xform should've cancelled when I asked it to. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (103, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dar depends on: ii libattr11:2.4.44-1 Extended attribute shared library ii libbz2-1.0 1.0.5-4 high-quality block-sorting file co ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libdar64-4 2.3.9-2 Disk ARchive: Shared library ii libgcc1 1:4.4.2-9GCC support library ii libssl0.9.8 0.9.8k-8 SSL shared libraries ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dar recommends no packages. Versions of packages dar suggests: ii dar-docs 2.3.9-2Disk ARchive: Backup directory tre pn par2 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570169: network-manager-gnome: nm-applet insists on re-enabling wireless networking when resuming from suspend to ram
Package: network-manager-gnome Version: 0.7.999-2 Severity: normal Hi, Before suspending my laptop to ram I manually disable wireless networking using the nm-applet RMB menu. Upon resuming the machine later, nm-applet immediately re-enables wireless networking and proceeds to connect to the wireless network, ignoring the user's intentions. The wireless network should not be enabled automatically if the user has manually disabled it. Currently this is just an annoyance for me (I'm trying to conserve power), but one might imagine this behaviour is possibly dangerous, e.g. by resuming the machine, thus enabling wireless, while on an aircraft in flight. (Unlikely to do much, perhaps, but something to consider.) Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager-gnome depends on: ii dbus-x111.2.20-2 simple interprocess messaging syst ii gconf2 2.28.0-1 GNOME configuration database syste ii gnome-icon-theme2.28.0-1 GNOME Desktop icon theme ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.20-2 simple interprocess messaging syst ii libdbus-glib-1-20.84-1 simple interprocess messaging syst ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.0-1 GNOME configuration database syste ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.22.4-1 The GLib library of C routines ii libgnome-bluetooth7 2.28.6-2 GNOME Bluetooth tools - support li ii libgnome-keyring0 2.28.2-1 GNOME keyring services library ii libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface ii libnm-glib-vpn1 0.7.999-2network management framework (GLib ii libnm-glib2 0.7.999-2network management framework (GLib ii libnm-util1 0.7.999-2network management framework (shar ii libnotify1 [libnotify1- 0.4.5-1 sends desktop notifications to a n ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library ii network-manager 0.7.999-2network management framework daemo ii policykit-1-gnome 0.96-1 GNOME authentication agent for Pol ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages network-manager-gnome recommends: pn gnome-bluetooth none (no description available) ii libpam-gnome-keyring [libpam- 2.28.2-1 PAM module to unlock the GNOME key pn mobile-broadband-provider-inf none (no description available) ii notification-daemon 0.4.0-2a daemon that displays passive pop Versions of packages network-manager-gnome suggests: pn network-manager-openvpn-gnome none (no description available) pn network-manager-pptp-gnomenone (no description available) ii network-manager-vpnc-gnome0.7.999-2 network management framework (VPNC -- 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 Archive: http://lists.debian.org/20100217003046.6500.59562.report...@zeta.tachyon
Bug#551833: psmisc: pstree segfaults when given long options it doesn't recognise (e.g. --help)
Package: psmisc Version: 22.8-1 Severity: normal Hi, I ran pstree --help and was greeted with a friendly segfault. Turns out this happens for any long option that pstree doesn't recognise. (I'd suggest it ought to recognise --help, but anyway...) I've had a poke around the code, and is seems to me that the options struct (lines 866-882) is not terminated correctly. According to the getopt_long documentation, the array should be terminated with an element containing all zeros, which pstree doesn't have. So, of course, getopt_long ends up looking into memory that's none of its business. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-4.dmz.2-liquorix-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages psmisc depends on: ii libc6 2.10.1-1 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand psmisc recommends no packages. psmisc 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#550022: wxmaxima: Should recommend or suggest ttf-jsmath
Package: wxmaxima Version: 0.8.3a-1 Severity: wishlist It seems this version of wxmaxima does something different with fonts. See http://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/3381999 and http://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/3363783 Once I installed ttf-jsmath package Greek letters are displayed. Please consider including that package as a Recommends or Suggests dependeny. :-) Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1.dmz.2-liquorix-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wxmaxima depends on: ii libc62.9-27 GNU C Library: Shared libraries ii libgcc1 1:4.4.1-5 GCC support library ii libstdc++6 4.4.1-5 The GNU Standard C++ Library v3 ii libwxbase2.8-0 2.8.7.1-1.1 wxBase library (runtime) - non-GUI ii libwxgtk2.8-02.8.7.1-1.1 wxWidgets Cross-platform C++ GUI t ii maxima 5.17.1-1A computer algebra system -- base ii maxima-doc 5.17.1-1A computer algebra system -- docum wxmaxima recommends no packages. wxmaxima 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#546271: phonon-backend-xine: Filenames with '#' won't play
Package: phonon-backend-xine Version: 4:4.3.1-4 Severity: normal Seems * Backport a bugfix from upstream to fix encoding issues with filenames. didn't quite catch everything, as I'm experiencing this bug: https://bugs.kde.org/show_bug.cgi?id=194889 I would've expected this was fixed in KDE 4.3.1, unless they forgot to backport it. That, and I am also entirely confused by the KDE Phonon/QT Phonon split. Nevermind, just making sure you're aware. :-) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (103, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages phonon-backend-xine depends on: ii libc6 2.9-26GNU C Library: Shared libraries ii libphonon4 4:4.5.2-2 Qt 4 Phonon module ii libqt4-dbus4:4.5.2-2 Qt 4 D-Bus module ii libqtcore4 4:4.5.2-2 Qt 4 core module ii libqtgui4 4:4.5.2-2 Qt 4 GUI module ii libstdc++6 4.4.1-3 The GNU Standard C++ Library v3 ii libxcb11.4-1 X C Binding ii libxine1 1.1.16.3-1+b2 the xine video/media player librar phonon-backend-xine recommends no packages. phonon-backend-xine 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#533616: occasional ext3 filesystem corruption
Hi, Twice in the space of a week I've seen behaviour identical to what's described in this bug report. I'm using 2.6.30. It might be triggered by sleeping the machine (a MacBook Pro, 2nd gen). No logs as it all happens with root (re)mounted read-only, and I'm afraid to test it much further already. Peace, Brendon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527121: printer-applet: error message client-error-bad-request pops up on every startup
Package: printer-applet Version: 4:4.2.2-1 Severity: normal I'm seeing the same problem every time I log in, only in English. :-) I'm using a UTF-8 locale, AFAICT, so I don't think it's that. I have seen some strange lines in /var/log/cups/error_log: E [30/May/2009:21:11:41 +1000] Bad request line ^V^C^A from localhost! for example (the ^V^C^A appear to be actual escape codes; I had to view the file in less to see what they were). Note that I'm quite sure I've only seen this come up after CUPS in testing upgraded from 1.3.8 to 1.3.10; IIRC there was no problem before that. Of course, it's possible that 1.3.8 just errored silently. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages printer-applet depends on: ii python2.5.4-2An interactive high-level object-o ii python-cups 1.9.31-1 Python bindings for CUPS ii python-kde4 4:4.2.2-3 Python bindings for the KDE 4 libr ii python-qt4-dbus 4.4.4-6DBus Support for PyQt4 Versions of packages printer-applet recommends: ii hal-cups-utils0.6.16-3 Utilities to detect and configure ii system-config-printer 1.0.0-5graphical interface to configure t printer-applet 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#524961: bash-completion: Tab completion of svk command line forgets to escape filenames
Package: bash-completion Version: 1:1.0-2 Severity: normal Hi, Try this: touch filename with spaces svk add filenTAB The completion I get is svk add filename with spaces. Note that the completion does not escape the spaces in the filename. When you try to run the command, svk looks for the files filename, with, and spaces and, of course, fails. You should expect the completion to be svk add filename\ with\ spaces like everything else. Peace, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bash-completion depends on: ii bash 3.2-5 The GNU Bourne Again SHell bash-completion recommends no packages. bash-completion 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#521528: libsane-extras: Please don't remove epkowa.conf if iscan package is installed
Package: libsane-extras Version: 1.0.19.15 Severity: minor Here I am trying to figure out why my scanner doesn't work *again*, and I discover that the recent upgrade of libsane-extras probably (from what I can ascertain from the changelog) removed the epkowa.conf config file that iscan needed to work. *sigh* It's like rubbing salt in the wound. Could you *please* check that another package, i.e. iscan, doesn't already claim epkowa.conf before removing that file, or at least check that iscan isn't installed, first? (Yes, I had to modify the iscan package's control file, removing the conflict, to get it to install. I'm sure I'm not the only one.) Thanks, Brendon -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsane-extras depends on: ii libc62.9-4 GNU C Library: Shared libraries ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library libsane-extras recommends no packages. libsane-extras 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#521528: libsane-extras: Please don't remove epkowa.conf if iscan package is installed
Hi, Julien BLACHE wrote (Saturday 28 March 2009): Brendon Higgins blhigg...@gmail.com wrote: It's like rubbing salt in the wound. Could you *please* check that another package, i.e. iscan, doesn't already claim epkowa.conf before removing that file, or at least check that iscan isn't installed, first? What's the exact package name? Is it just iscan? That's right. (Yes, I had to modify the iscan package's control file, removing the conflict, to get it to install. I'm sure I'm not the only one.) Ah. You should have added a Replaces: libsane-extras, that would have worked better (iscan effectively taking ownership of the epkowa.conf conffile in that case). *reads the docs* Whaddaya know. I thought a Replaces was a whole-package thing, but I guess not. Hopefully we're at the end of the tunnel with this whole mess now, new packages are mostly ready at Avasys. I haven't really followed the reasons, but it's a shame this mess had to happen. Peace, Brendon signature.asc Description: This is a digitally signed message part.
Bug#516537: wacom: X does not automatically translate tablet coords to screen coords in core events
Package: xserver-xorg-input-wacom Version: 0.8.1.6-1 Severity: normal File: wacom Hi, This report is a result of an investigation into weird tablet behaviour using Krita and other Qt tablet software: https://bugs.kde.org/show_bug.cgi?id=184485 I'm running most packages from testing, except wacom packages from unstable, and a whole bunch of KDE 4 stuff from experimental. I've been experiencing the symptoms of this problem for some months, but I think I've finally got a handle on its source. The function xf86WcmDevConvert in xf86Wacom.c should be automatically called by the Xorg server to translate from the device-space coordinates to screen coordinates. There exists workaround code in the wacom driver that is disabled when compiled against recent Xorg versions, as older Xorg versions did not automatically call the conversion function (apparently). However, when I run Xorg with Option CommonDBG 6 it's clear that xf86WcmDevConvert is never called. When I compile the package from source (i.e. dpkg-buildpackage), it's clear that the workaround is not being compiled in, either. This only affects core events, and doesn't effect software which does its own conversion from raw tablet data. Presumably, this is why symptoms only appear when using Qt, just because of the (I guess, unusual) way it disects tablet events. Peace, Brendon -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.2-10 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. Versions of packages xserver-xorg-input-wacom suggests: ii wacom-tools 0.8.1.6-1 utilities for Wacom tablet devices -- 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#512362: runvdr crash handler does not handle the module dependency tree
Package: vdr Version: 1.6.0-8 Severity: normal I came across this while debugging a separate problem (which was being triggered by this) with my dvb modules. The runvdr script attempts to reload the dvb modules in the event that vdr crashes. It does this by using lsmod to determine which modules directly depend on dvb_core, and then attempting to rmmod and modprobe just those modules plus dvb_core. This process does not take into account the fact that multiple other modules may depend on those modules that runvdr attempts to reload. The rmmod calls will fail in this case. Getting this to work right would require traversing the module dependency tree and running rmmod/modprobe for all of those modules. Peace, Brendon -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vdr depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0]1.5.24 Debian configuration management sy ii libc62.7-18 GNU C Library: Shared libraries ii libcap2 2.11-2 support for getting/setting POSIX. ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc1 1:4.3.2-1.1 GCC support library ii libjpeg626b-14 The Independent JPEG Group's JPEG ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii psmisc 22.6-1 Utilities that use the proc filesy Versions of packages vdr recommends: ii lirc 0.8.3-3infra-red remote control support ii ttf-freefont 20080323-3 Freefont Serif, Sans and Mono True vdr suggests no packages. -- debconf information: * vdr/select_dvb_card: Terrestrial * vdr/showinfo: * vdr/create_video_dir: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507956: findimagedupes: Use of glob means folders with whitespace in their names are dropped
Package: findimagedupes Version: 2.11-2 Severity: normal Hi there, Line 365 of findimagedupes perl script makes a call to glob that fails when the path contains whitespace. find -type d -print0 | findimagedupes -0 - will ignore files in those directories because of this. The immediate solution might appear to be to use bsd_glob, but that only solves the problem of folders with whitespace. Folders with other characters that are meaningful to glob/bsd_glob will probably still have issues. Temporary workaround (for my situation, at least) is to use find to generate the full file list. I'd help more but my knowledge of perl is mediocre at best. FWIW, I don't think glob is necessary if an alternative folder content listing function can be used. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages findimagedupes depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libfile-mimeinfo-perl 0.15-1 Perl module to determine file type ii libgraphics-magick-perl 1.1.11-3.2 format-independent image processin ii libinline-perl0.44-5 Write Perl subroutines in other pr ii perl 5.10.0-18 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10.0]5.10.0-18 minimal Perl system findimagedupes recommends no packages. findimagedupes suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497482: okular: Printing a PDF causes the file to be overwritten with a PS conversion, nothing printed
Hi Pino, Pino Toscano wrote (2008-11-07 7:12 am): Confirming that the cause was the Qt 4.4.0 bug. the behaviour is fixed in 4.4.1. (Though now my printer seems to complain about syntax errors in what Okular sends it. I may get to searching for/submitting that bug at some stage.) Now that Qt 4.4.3 is in Lenny, is the problem still there? Printing seems to be fine, now. I can't reproduce any problem I was having. FWIW, I seem to be running Okular 0.7.1-1 (in sid, hasn't hit lenny yet.) Peace, Brendon signature.asc Description: This is a digitally signed message part.
Bug#501006: kdelibs5 requires libpcre3 = 7.8
Package: kdelibs5 Version: 4:4.1.2-1 Severity: normal Hi, Currently kdelibs5 in experimental requires libpcre3 = 7.4, but this is insufficient. One symptom I discovered is that in Konqueror JavaScript /xyzzy/ type regexps all fail with an uninformative error as soon as they are declared. This has a pretty detrimental effect on any number of websites. Upgrading libpcre3 from the version in testing (7.6) to unstable (7.8) fixes such problems. The dependency should probably be changed to = 7.8. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kdelibs5 depends on: ii dbus-x11 1.2.1-3simple interprocess messaging syst ii kdelibs-bin 4:4.1.2-1 executables for all KDE 4 core app ii kdelibs5-data 4:4.1.2-1 core shared data for all KDE 4 app ii libacl1 2.2.47-2 Access control list shared library ii libaspell15 0.60.6-1 GNU Aspell spell-checker runtime l ii libattr1 1:2.4.43-1 Extended attribute shared library ii libbz2-1.01.0.5-1high-quality block-sorting file co ii libc6 2.7-13 GNU C Library: Shared libraries ii libenchant1c2a1.4.2-3.1 a wrapper library for various spel ii libgamin0 [libfam0] 0.1.9-2Client library for the gamin file ii libgcc1 1:4.3.1-9 GCC support library ii libgif4 4.1.6-5library for GIF images (library) ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libilmbase6 1.0.1-2+nmu2 several utility libraries from ILM ii libjasper11.900.1-5 The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libkrb53 1.6.dfsg.4~beta1-4 MIT Kerberos runtime libraries ii libopenexr6 1.6.1-3runtime files for the OpenEXR imag ii libpcre3 7.8-1 Perl 5 Compatible Regular Expressi ii libphonon44:4.2.0-1 Phonon multimedia framework for Qt ii libpng12-01.2.27-1 PNG library - runtime ii libqt4-dbus 4.4.3-1Qt 4 D-Bus module ii libqt4-designer 4.4.3-1Qt 4 designer module ii libqt4-network4.4.3-1Qt 4 network module ii libqt4-qt3support 4.4.3-1Qt 3 compatibility library for Qt ii libqt4-script 4.4.3-1Qt 4 script module ii libqt4-svg4.4.3-1Qt 4 SVG module ii libqt4-xml4.4.3-1Qt 4 XML module ii libqtcore44.4.3-1Qt 4 core module ii libqtgui4 4.4.3-1Qt 4 GUI module ii libsm62:1.0.3-2 X11 Session Management library ii libsoprano4 2.1+dfsg.1-1 libraries for the Soprano RDF fram ii libssl0.9.8 0.9.8g-13 SSL shared libraries ii libstdc++64.3.1-9The GNU Standard C++ Library v3 ii libstreamanalyzer00.5.11-1 streamanalyzer library for Strigi ii libx11-6 2:1.1.5-2 X11 client-side library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxml2 2.6.32.dfsg-4 GNOME XML library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxslt1.11.1.24-2 XSLT processing library - runtime ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii shared-mime-info 0.30-2 FreeDesktop.org shared MIME databa ii xauth 1:1.0.3-2 X authentication utility ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages kdelibs5 recommends: ii ttf-dejavu2.25-3 Metapackage to pull in ttf-dejavu- kdelibs5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494162: Reproducible with nVidia MCP55 HDA, mplayer + stress
Hi, I find this problem completely reproducible by running the stress program (from the stress package). Do this: (1) Open a terminal, run mplayer SOMEaudioFILE.ogg Audio output is typically okay at this point (at least for me). (2) Open another terminal, run stress -c [noOFtotalCPUcores] In my case, that's 2. When you do this, the stuttering begins (and is very, very bad). Not only that, all process (apart from stress) perform very poorly. It seems like the scheduler is (almost completely) ignoring all other processes in favour of the one that is already using 100% CPU. It seems, though, that if the number of stress-spawned processes is not the same as the number of cores, e.g. 1 or 3, then the problem is not nearly as bad, even though the processes are stressing the CPU. For example, when I run stress -c 3, CPU usage on both cores is in total 100%, yet the sound output is much better and other processes are much more responsive, however a stutter can be heard now and then. When you crank the number of stress processes to something ridiculous, say 30, sound output is even better! I might have heard a single stutter during this test, I'm not even sure (while 2 cores are running at 100% total each, I think this is pretty good). UI responsiveness is somewhat worse, though. Maybe this is what is causing the stutter under normal use: Some app spikes in CPU usage for a short period, causing the audio process(es) to be stalled, thus the stuttering. The behaviour affects all process, but audio being what it is, that is where it's readily obvious that something is wrong. I probably should say I was under the impression that under general use the stuttering was a lot worse when I first encountered it (when I first tried 2.6.26) than it is now, so something has improved. If you do any of the above in 2.6.25 there is no problem whatsoever. No stuttering. Even the UI is much more responsive, for any number of processes, than in 2.6.26. I'd go so far as to state that 2.6.25 is more responsive under load than 2.6.26, which sounds a lot like a regression to me. Info: 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) Sep 27 09:33:53 phi kernel: [0.00] Linux version 2.6.26-1-amd64 (Debian 2.6.26-5) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23 )) #1 SMP Wed Sep 10 15:31:12 UTC 2008 as compared to: Sep 27 10:42:02 phi kernel: [0.00] Linux version 2.6.25-2-amd64 (Debian 2.6.25-7) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) ) #1 SMP Mon Jul 14 11:05:23 UTC 2008 Peace, Brendon signature.asc Description: This is a digitally signed message part.
Bug#497482: okular: Printing a PDF causes the file to be overwritten with a PS conversion, nothing printed
Hi again, Confirming that the cause was the Qt 4.4.0 bug. the behaviour is fixed in 4.4.1. (Though now my printer seems to complain about syntax errors in what Okular sends it. I may get to searching for/submitting that bug at some stage.) Peace, Brendon Brendon Higgins wrote (2008-09-03 10:34 am): Hi, Pino Toscano wrote (2008-09-03 1:00 am): Trying to print a PDF document fails. There is no error message, but after clicking Print, Okular spends a bit of time doing some processing, after which no job is sent to the print queue. If you open the print dialog and select your printer, which Description: do you get for it? Is it something like Write PDF file or Write PostScript file? No, nothing like that. The printers listed are the usual list I would expect (lp for the printer in my office, and one for a printer in a nearby office). The Location and Type fields correspond to those printers, there's no other fields, and no indication anywhere that they are set to some write-to-file mode. Interestingly, though, it only lists the printers configured in CUPS, and doesn't have the extra options that KPDF has (like Print to File (PDF), Send to Fax, etc). KPDF has no trouble printing, FWIW. Ah, new info: The file is only overwritten when it lives in the home directory. When the file is anywhere else (including subdirectories) it is not overwritten, however a file of the same name is created in ~. I've just had a poke around at upstream bugtracker. I suspect it might be related to this: https://bugs.kde.org/show_bug.cgi?id=162793 , which I notice you've already noticed. :-) Qt 4.4.1 is still in experimental, though. I could give it a try. Peace, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497482: okular: Printing a PDF causes the file to be overwritten with a PS conversion, nothing printed
Hi, Pino Toscano wrote (2008-09-03 1:00 am): Trying to print a PDF document fails. There is no error message, but after clicking Print, Okular spends a bit of time doing some processing, after which no job is sent to the print queue. If you open the print dialog and select your printer, which Description: do you get for it? Is it something like Write PDF file or Write PostScript file? No, nothing like that. The printers listed are the usual list I would expect (lp for the printer in my office, and one for a printer in a nearby office). The Location and Type fields correspond to those printers, there's no other fields, and no indication anywhere that they are set to some write-to-file mode. Interestingly, though, it only lists the printers configured in CUPS, and doesn't have the extra options that KPDF has (like Print to File (PDF), Send to Fax, etc). KPDF has no trouble printing, FWIW. Ah, new info: The file is only overwritten when it lives in the home directory. When the file is anywhere else (including subdirectories) it is not overwritten, however a file of the same name is created in ~. I've just had a poke around at upstream bugtracker. I suspect it might be related to this: https://bugs.kde.org/show_bug.cgi?id=162793 , which I notice you've already noticed. :-) Qt 4.4.1 is still in experimental, though. I could give it a try. Peace, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494162: linux-image-2.6.26-1-amd64: Sound stuttering in 2.6.26 ruins desktop experience
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-4 Followup-For: Bug #494162 Ah, so this is why Amarok skips and stutters whenever I switch tabs (or do anything, really), today. Sure enough, in 2.6.25 all is fine. Any chance more attention (higher severity?) might be put on this? It's pretty jarring to the user, and does a complete disservice to the perception of ability of Linux on the desktop. It would be very unfortunate (sadly laughable, IMO) if Lenny were released with this bug. Peace, Brendon -- Package-specific info: ** Version: Linux version 2.6.26-1-amd64 (Debian 2.6.26-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Thu Aug 28 11:13:42 UTC 2008 ** Command line: root=/dev/sda2 ro ** Tainted: P (1) ** Kernel log: [ 637.136658] lp: driver loaded but no devices found [ 637.172657] ppdev: user-space parallel port driver [ 641.251572] warning: `vdr-kbd' uses 32-bit capabilities (legacy support in use) [ 643.665742] Clocksource tsc unstable (delta = -64455037 ns) [ 663.376333] NET: Registered protocol family 10 [ 663.376592] lo: Disabled Privacy Extensions [ 667.905023] em8300_audio.o: Analog audio enabled [ 667.944707] em8300: Microcode version 0x29 loaded [ 668.063884] em8300_audio.o: Analog audio enabled [ 673.520942] eth0: no IPv6 routers present [ 673.741577] nvidia: module license 'NVIDIA' taints kernel. [ 674.000331] ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16 [ 674.000331] ACPI: PCI Interrupt :07:00.0[A] - Link [APC6] - GSI 16 (level, low) - IRQ 16 [ 674.000331] PCI: Setting latency timer of device :07:00.0 to 64 [ 674.000331] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 173.14.09 Wed Jun 4 23:40:50 PDT 2008 [16522.763644] Fifo still full, trying stop [16700.139060] Fifo still full, trying stop [17665.971913] Fifo still full, trying stop [24354.029646] Fifo still full, trying stop [24555.619339] Fifo still full, trying stop [24807.278183] Fifo still full, trying stop [25008.840091] Fifo still full, trying stop [25256.361998] Fifo still full, trying stop [25464.478505] Fifo still full, trying stop [25715.716610] Fifo still full, trying stop [25918.938454] Fifo still full, trying stop [26336.103227] Fifo still full, trying stop [26752.448319] Fifo still full, trying stop [27576.644277] Fifo still full, trying stop [27782.249854] Fifo still full, trying stop [28002.450206] Fifo still full, trying stop [28207.518000] Fifo still full, trying stop [28489.782104] Fifo still full, trying stop [28690.962251] Fifo still full, trying stop [29077.534065] Fifo still full, trying stop [29328.228252] Fifo still full, trying stop [36452.417366] gtk-gnash[9009]: segfault at 0 ip 7f21eee495c6 sp 7c63f150 error 4 in libfontconfig.so.1.3.0[7f21eee36000+2e000] [36841.088035] usb 2-10: new high speed USB device using ehci_hcd and address 7 [36841.245466] usb 2-10: configuration #1 chosen from 1 choice [36841.253612] usb 2-10: New USB device found, idVendor=04b8, idProduct=0827 [36841.253617] usb 2-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [36841.253620] usb 2-10: Product: USB2.0 MFP(Hi-Speed) [36841.253621] usb 2-10: Manufacturer: EPSON [36841.253623] usb 2-10: SerialNumber: L41010610150256440 [36841.551211] usblp0: USB Bidirectional printer dev 7 if 1 alt 0 proto 2 vid 0x04B8 pid 0x0827 [36841.551211] usbcore: registered new interface driver usblp [36841.589474] Initializing USB Mass Storage driver... [36841.595211] scsi6 : SCSI emulation for USB Mass Storage devices [36841.595497] usbcore: registered new interface driver usb-storage [36841.595503] USB Mass Storage support registered. [36841.602512] usb-storage: device found at 7 [36841.602518] usb-storage: waiting for device to settle before scanning [36847.221828] usb-storage: device scan complete [36847.228855] scsi 6:0:0:0: Direct-Access EPSONStylus Storage 1.00 PQ: 0 ANSI: 2 [36847.241073] sd 6:0:0:0: [sdc] Attached SCSI removable disk [36881.435534] sd 6:0:0:0: [sdc] 29120 512-byte hardware sectors (15 MB) [36881.455368] sd 6:0:0:0: [sdc] Write Protect is off [36881.455373] sd 6:0:0:0: [sdc] Mode Sense: 2f 00 00 00 [36881.455375] sd 6:0:0:0: [sdc] Assuming drive cache: write through [36881.483366] sd 6:0:0:0: [sdc] 29120 512-byte hardware sectors (15 MB) [36881.500498] sd 6:0:0:0: [sdc] Write Protect is off [36881.500502] sd 6:0:0:0: [sdc] Mode Sense: 2f 00 00 00 [36881.500504] sd 6:0:0:0: [sdc] Assuming drive cache: write through [36881.500510] sdc:3Buffer I/O error on device sdc, logical block 0 [36881.500564] Buffer I/O error on device sdc, logical block 0 [36881.500572] Buffer I/O error on device sdc, logical block 0 [36881.500579] Buffer I/O error on device sdc, logical block 0 [36881.500586] Buffer I/O error on device sdc, logical block 0 [36881.500590] ldm_validate_partition_table(): Disk read failed. [36881.500595] Buffer I/O error on device sdc, logical block 0 [36881.500602] Buffer I/O error on device sdc, logical
Bug#497482: okular: Printing a PDF causes the file to be overwritten with a PS conversion, nothing printed
Package: okular Version: 0.7-2 Severity: normal FWIW, I'm running Okular on a primarily KDE 3 host, so this might be some kind of incompatibility thing. I'm not sure. Trying to print a PDF document fails. There is no error message, but after clicking Print, Okular spends a bit of time doing some processing, after which no job is sent to the print queue. Okular then attempts to reload the document and fails without an error message - just the default big blank grey no document loaded yet panel. What has happened is that something during this process has overwritten the ..pdf file with a postscript conversion. When Okular attempts to reload the file, I guess it runs into #496669, tries the wrong backend, and fails. Overwriting files like this is quite rude of Okular, IMO. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27-rc3.mykernel (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages okular depends on: ii kdebase-runtime4:4.1.0-2 runtime components from the offici ii kdelibs5 4:4.1.0-1 core libraries for all KDE 4 appli ii libc6 2.7-13GNU C Library: Shared libraries ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libokularcore1 0.7-2 libraries for the Okular document ii libpoppler-qt4-3 0.8.4-1.1 PDF rendering library (Qt 4 based ii libqca22.0.0-4 libraries for the Qt Cryptographic ii libqimageblitz41:0.0.4-4 QImageBlitz image effects library ii libqt4-dbus4.4.0-4 Qt 4 D-Bus module ii libqt4-qt3support 4.4.0-4 Qt 3 compatibility library for Qt ii libqt4-xml 4.4.0-4 Qt 4 XML module ii libqtcore4 4.4.0-4 Qt 4 core module ii libqtgui4 4.4.0-4 Qt 4 GUI module ii libspectre10.2.0.ds-1Library for rendering Postscript d ii libstdc++6 4.3.1-9 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime okular recommends no packages. Versions of packages okular suggests: ii okular-extra-backends 0.7-2 additional document format support -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477665: aptitude: --download-only (or -d) not honoured in interactive mode
Package: aptitude Version: 0.4.11.4-1 Followup-For: Bug #477665 I just installed KDE 4 prematurely because of this bug. I did not expect that running 'sudo aptitude -d install -t experimental kde4-minimal', then pressing 'e' to massage some package versions manually in interactive mode, would cause the '-d' to become ignored. (All I wanted was to make efficient use of my internet quota, and maybe try KDE 4 later in the week. *Maybe.* I get to try it ealier, it seems.) IMO, this is not a wishlist, but a bug (of at least normal severity). If nothing else, any sort of warning would have been useful. Peace, Brendon -- Package-specific info: aptitude 0.4.11.4 compiled at Jun 8 2008 01:39:27 Compiler: g++ 4.3.1 20080523 (prerelease) Compiled against: apt version 4.6.0 NCurses version 5.6 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.6.20080308 cwidget version: 0.5.12 Apt version: 4.6.0 linux-vdso.so.1 = (0x7fffeb7fe000) libapt-pkg-libc6.7-6.so.4.6 = /usr/lib/libapt-pkg-libc6.7-6.so.4.6 (0x7febe312b000) libncursesw.so.5 = /lib/libncursesw.so.5 (0x7febe2ee2000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7febe2cdd000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7febe2a0a000) libept.so.0 = /usr/lib/libept.so.0 (0x7febe278e000) libxapian.so.15 = /usr/lib/libxapian.so.15 (0x7febe2406000) libz.so.1 = /usr/lib/libz.so.1 (0x7febe21ef000) libpthread.so.0 = /lib/libpthread.so.0 (0x7febe1fd4000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7febe1cc8000) libm.so.6 = /lib/libm.so.6 (0x7febe1a49000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7febe1832000) libc.so.6 = /lib/libc.so.6 (0x7febe14ea000) libutil.so.1 = /lib/libutil.so.1 (0x7febe12e7000) libdl.so.2 = /lib/libdl.so.2 (0x7febe10e3000) /lib64/ld-linux-x86-64.so.2 (0x7febe33eb000) Terminal: xterm $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.14+b1 Advanced front-end for dpkg ii libc6 2.7-10GNU C Library: Shared libraries ii libcwidget30.5.12-1 high-level terminal interface libr ii libept00.5.17High-level library for managing De ii libgcc11:4.3.1-2 GCC support library ii libncursesw5 5.6+20080308-1Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libxapian151.0.5-1 Search engine library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.11.4-1 English manual for aptitude, a ter ii libparse-debianchangelog-perl 1.1.1-2parse Debian changelogs and output -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491983: koffice: experimental packages attempt to overwrite files in old *-data packages
Package: koffice Version: 1:1.9.96.0~that.is.really.1.9.95.9-1 Severity: normal In the process of installing KDE 4 stuff, I got this: Preparing to replace kivio 1:1.6.3-7 (using .../kivio_1%3a1.9.96.0~that.is.really.1.9.95.9-1_amd64.deb) ... Unpacking replacement kivio ... dpkg: error processing /var/cache/apt/archives/kivio_1%3a1.9.96.0~that.is.really.1.9.95.9-1_amd64.deb (--unpack): trying to overwrite `/usr/share/pixmaps/kivio.xpm', which is also in package kivio-data Preparing to replace kpresenter 1:1.6.3-7 (using .../kpresenter_1%3a1.9.96.0~that.is.really.1.9.95.9-1_amd64.deb) ... Unpacking replacement kpresenter ... dpkg: error processing /var/cache/apt/archives/kpresenter_1%3a1.9.96.0~that.is.really.1.9.95.9-1_amd64.deb (--unpack): trying to overwrite `/usr/share/icons/hicolor/48x48/apps/kpresenter.png', which is also in package kpresenter-data I had to use a force flag in dpkg.conf to get it to install. If I'm not mistaken, kivio should conflict with kivio-data (KDE3 version) and kpresenter conflict with kpresenter-data (KDE3 version), to ensure they are removed before kivio and kpresenter are installed. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages koffice depends on: ii kar 1:1.9.96.0~that.is.really.1.9.95.9-1 a vector graphics application for ii kch 1:1.9.96.0~that.is.really.1.9.95.9-1 a chart drawing program for the KD ii kex 1:1.9.96.0~that.is.really.1.9.95.9-1 integrated database environment fo ii kfo 1:1.9.96.0~that.is.really.1.9.95.9-1 a formula editor for the KDE Offic ii kiv 1:1.9.96.0~that.is.really.1.9.95.9-1 a flowcharting program for the KDE ii kpl 1:1.9.96.0~that.is.really.1.9.95.9-1 an integrated project management a ii kpr 1:1.9.96.0~that.is.really.1.9.95.9-1 a presentation program for the KDE ii kri 1:1.9.96.0~that.is.really.1.9.95.9-1 a pixel-based image manipulation p ii ksp 1:1.9.96.0~that.is.really.1.9.95.9-1 a spreadsheet for the KDE Office S ii kth 1:1.9.96.0~that.is.really.1.9.95.9-1 thesaurus for the KDE Office Suite ii kwo 1:1.9.96.0~that.is.really.1.9.95.9-1 a word processor for the KDE Offic koffice recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489987: kpdf: KPDF refuses to open files that do not have the correct extension
Package: kpdf Version: 4:3.5.9-1+b2 Severity: minor Take any pdf file that already works in KPDF. Rename it to change its extension from .pdf to something else; for example, file.pdf.bak works. Start KPDF and attempt to open the file (the file dialog won't list it, so you have to force it a bit by typing the name manually or entering a different filter). KPDF says Error Could not open ..etc.. Of course, KPDF is lying - it could open the file if it wanted to. It just doesn't want to because the extension is different. (Will not open .. would be a truer statement...) As you might guess, I wanted to view a .pdf.bak file when I found this bug, but it happens on all sorts of extensions. Without extension seems to work okay, though. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kpdf depends on: ii kdelibs4c2a 4:3.5.9.dfsg.1-4 core libraries and binaries for al ii libc6 2.7-10 GNU C Library: Shared libraries ii libfontconfig1 2.6.0-1 generic font configuration library ii libfreetype62.3.6-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.3.1-2GCC support library ii libpaper1 1.1.23+nmu1 library for handling paper charact ii libqt3-mt 3:3.3.8b-5 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libxft2 2.1.12-3 FreeType-based font drawing librar Versions of packages kpdf recommends: ii kghostview 4:3.5.9-1+b2 PostScript viewer for KDE -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475170: #475170: Unuseable on amd64 - Intel chipset vs AMD chipset?
Package: axiom Version: 20050901-10 Followup-For: Bug #475170 Hi, I tried to run axiom and ran into this bug. I've tested it on three machines. The first is an Intel Core2 Duo. The other two are AMD Athlon64s. I found that on the Athlons Axiom starts without any problems, but on the Core2 it fails. Has anyone tried an Athlon chip and had it fail? FWIW, I'm also getting problems trying to build from scratch axiom (segfaults at some point during the build, while it's doing something involving lisp), as well as gcl (hits an error in configure). But building axiom on an AMD chip seems to work. /proc/cpuinfo for two of the CPUs I've tried follows (the two AMD CPUs are almost identical). Peace, Brendon Intel Core 2 Duo: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping: 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 4327.41 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping: 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 4322.62 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: AMD Athlon64 X2: $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping: 1 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips: 2010.78 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping: 1 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips: 2010.78 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps Reporting from one of the Athlon machines: -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages axiom depends on: ii axiom-databases 20050901-10A general purpose computer algebra ii libc6 2.7-10 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libncurses5 5.6+20080308-1 Shared libraries for terminal hand ii libreadline5 5.2-3 GNU readline and history libraries ii libsm6
Bug#480657: python-opengl: Using glutDisplayFunc and glutKeyboardFunc causes Segmentation Fault in glutMainLoop
Good news. After updating the python2.5 package to 2.5.2-6 I can no longer reproduce this problem. It seems something between 2.5.2-1 and 2.5.2-6 fixed whatever was causing this. Peace, Brendon signature.asc Description: This is a digitally signed message part.
Bug#480657: python-opengl: Using glutDisplayFunc and glutKeyboardFunc causes Segmentation Fault in glutMainLoop
Hi,
Some more information I've discovered about this bug:
1) A test on a friend's 32-bit PowerPC machine didn't reproduce it. (Maybe a
64-bit issue?)
2) The following equivalent C code does not reproduce it:
#include GL/glut.h
#include stdio.h
void disFunc() {
printf(disFunc\n);
fflush(stdout);
}
void keyFunc(unsigned char c, int a, int b) {
printf(keyFunc\n);
fflush(stdout);
}
int main(int argc, char** args) {
glutInit(argc, args);
glutInitDisplayMode(GLUT_RGB);
glutInitWindowSize(640, 480);
glutCreateWindow(appname);
glutDisplayFunc(disFunc);
glutKeyboardFunc(keyFunc);
glutMainLoop();
return 0;
}
That suggests that it's something about the OpenGL wrapper itself.
Peace,
Brendon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481994: Uninstalled, purged usplash still displays splash on boot
maximilian attems wrote (2008-05-20 8:59 pm): My uneducated guess is that postinst might have to trigger a rebuild of the initrd image. it does it: [snip] So it does. FYI, I have a clearer idea what was actually happening: Even though linux 2.6.25-2 was installed, I was running 2.6.25-1 because update-grub hadn't been called when 2.6.25-2 was installed. Then, even though update-initramfs was being called, it was working on the latest 2.6.25-2 image (I think), which is why running update-initramfs -u (even manually) seemed to do nothing. Now for me to work out why update-grub doesn't get called... *glares at kernel-img.conf* Peace, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481994: Uninstalled, purged usplash still displays splash on boot
Package: usplash Version: 0.5.19-1 Severity: normal I purged usplash (due to bugs #468735 and #478296), but on next boot the same splash screen came up during the initial boot stage, before going back to text mode to complete the boot process (start services, etc). My uneducated guess is that postinst might have to trigger a rebuild of the initrd image. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages usplash depends on: ii debconf [debconf-2.0] 1.5.21 Debian configuration management sy ii initramfs-tools 0.92a tools for generating an initramfs ii libc6 2.7-10 GNU C Library: Shared libraries pn libusplash0 none (no description available) pn usplash-theme-debian | usplas none (no description available) usplash recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481291: kate: Spellcheck replacing words at the static word wrap limit with longer corrections causes havoc
Package: kate Version: 4:3.5.9.dfsg.1-2+b1 Severity: normal To reproduce: Start kate. Turn on static word wrapping at 80 columns. Duplicate the following line several times (5 or so is sufficient): test test test test test test test test test test test test test test test a tes That line should just touch the static word wrap limit. Perform a spellcheck and replace each instance of tes with a longer suggestion (the default suggestion I'm presented with is Tess). As the spellcheck replaces the first word you should see the static word wrap doing it's job and moving the word to the next line. However, when it comes to the next instance of tes, the context highlighting of the word is missing, and upon replacement a whole bunch of whitespace plus a new Tess is inserted between the first a and the other Tess, and the remaining lines stay unchanged and uncorrected. This occurs similarly for subsequent spellcheck replacements. I've tried to describe it, but it's probably easier to just see for yourself. It's as if there are two buffers of text, one for kate and one for the spellchecker backend, that lose sync when the static word wrap does it's work. Interestingly, it seems to not be a problem if the unrecognised word (tes) is somewhere in the middle of the line. It's only a problem if the word is at the end of the line. I originally discovered this in kile, and since confirmed it also appears in kate, so it's probably an issue with the editor part. I haven't a clue if the KDE 4 apps handle any better. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kate depends on: ii kdelibs4c2a 4:3.5.9.dfsg.1-4 core libraries and binaries for al ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3GCC support library ii libqt3-mt 3:3.3.8b-5 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 Versions of packages kate recommends: ii kregexpeditor 4:3.5.9-1 graphical regular expression edito -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480657: python-opengl: Using glutDisplayFunc and glutKeyboardFunc causes Segmentation Fault in glutMainLoop
Package: python-opengl Version: 3.0.0~b1-2 Severity: normal When the default python version in testing changed to 2.5 I found a program I had written failed with segmentation faults. I've narrowed down the bug. The following is the smallest reasonable piece of code which will cause the segfault: from OpenGL.GLUT import * glutInit([appname]) glutInitDisplayMode(GLUT_RGB) glutInitWindowSize(640, 480); glutCreateWindow(appname) def disFunc(): print disFunc def keyFunc(*args): print keyFunc glutDisplayFunc(disFunc) glutKeyboardFunc(keyFunc) glutMainLoop() Pasting the code into python interactive mode demonstrates the problem as well as using a .py file. Python will segfault as soon as it enters the glutMainLoop function. If either glutDisplayFunc(disFunc) or glutKeyboardFunc(keyFunc) is commented out, there is no problem, and things behave as you would expect them to. Also if I use python2.4, there is no problem. But if I use both keyFunc and disFunc in python2.5: SIGSEGV, every time. I'm not sure if a gdb backtrace is useful, but here it is, anyway: #0 0x2bac5fcc in ?? () #1 0x2b314e83 in ?? () from /usr/lib/libglut.so.3 #2 0x2b318059 in fgEnumWindows () from /usr/lib/libglut.so.3 #3 0x2b31570e in glutMainLoopEvent () from /usr/lib/libglut.so.3 #4 0x2b315b38 in glutMainLoop () from /usr/lib/libglut.so.3 #5 0x2b3dceb76e74 in ffi_call_unix64 () from /usr/lib/python2.5/lib-dynload/_ctypes.so #6 0x2b3dceb768bd in ffi_call () from /usr/lib/python2.5/lib-dynload/_ctypes.so #7 0x2b3dceb7179a in _CallProc () from /usr/lib/python2.5/lib-dynload/_ctypes.so #8 0x2b3dceb6b4ff in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so #9 0x00417c73 in PyObject_Call () #10 0x004854ca in PyEval_EvalFrameEx () #11 0x00489756 in PyEval_EvalCodeEx () #12 0x00489872 in PyEval_EvalCode () #13 0x004ab339 in PyRun_InteractiveOneFlags () #14 0x004ab544 in PyRun_InteractiveLoopFlags () #15 0x004ab64a in PyRun_AnyFileExFlags () #16 0x0041442d in Py_Main () #17 0x2b3dcdf091c4 in __libc_start_main () from /lib/libc.so.6 #18 0x004139a9 in _start () Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-opengl depends on: ii freeglut3 2.4.0-6OpenGL Utility Toolkit ii libgl1-mesa-glx [libgl1] 7.0.3-1A free implementation of the OpenG ii libglu1-mesa [libglu1]7.0.3-1The OpenGL utility library (GLU) ii python2.5.2-1An interactive high-level object-o ii python-central0.6.6 register and build utility for Pyt ii python-ctypes 1.0.2-4Python package to create and manip ii python-pkg-resources 0.6c8-3Package Discovery and Resource Acc python-opengl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479520: qtiplot failure to start is caused by missing dependencies
Package: qtiplot Version: 0.9.3-1 Followup-For: Bug #479520 Hi there, I have also encountered the problem with qtiplot not starting since libqt4-gui was updated. You can fix this problem by installing the libqt4-assistant package. (I also had to install the libqt4-opengl package, same reason.) It appears that libraries that were once in libqt4-gui have moved into their own packages. qtiplot should include them as package dependencies. In the meantime, installing the packages manually seems to make things work. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages qtiplot depends on: ii libc6 2.7-10GNU C Library: Shared libraries ii libgcc11:4.3.0-3 GCC support library ii libgl1-mesa-glx [libgl 7.0.3-1 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.0.3-1 The OpenGL utility library (GLU) ii libgsl0ldbl1.11-2GNU Scientific Library (GSL) -- li ii libmuparser0 1.28-2fast mathematical expressions pars ii liborigin0 20080225-2library for reading OriginLab Orig ii libqt4-core4.4.0~rc1-5 transitional package for Qt 4 core ii libqt4-gui 4.4.0~rc1-5 Qt 4 GUI module ii libqt4-qt3support 4.4.0~rc1-5 Qt 3 compatibility library for Qt ii libqwt5-qt45.0.2-2 Qt4 widgets library for technical ii libqwtplot3d-qt4 0.2.7+svn191-13D plotting library based on Qt4/O ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 ii python-qt4 4.3.3-2 Python bindings for Qt4 ii python2.4 2.4.5-2 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime qtiplot recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476135: xserver-xorg-video-radeonhd: strange screen size calculations
Package: xserver-xorg-video-radeonhd Version: 1.2.0-1 Followup-For: Bug #476135 Hi, I noticed a similar weird DPI result in my Xorg.0.log, and I suspect the Virtual setting (Framebuffer size). My guess is that the driver is assuming the entire framebuffer is viewable on screen, which is not correct. In my case, I've extended the virtual screen to accommodate a second monitor. My hunch is confirmed when I commented-out the Virtual setting in Xorg.conf. Whereas I got this with my manually extended framebuffer: (II) RADEONHD(0): Using 2720x1024 Framebuffer with 2752 pitch (**) RADEONHD(0): Display dimensions: (340, 220) mm (**) RADEONHD(0): DPI set to (203, 118) I got this using the default framebuffer size: (II) RADEONHD(0): Using 1440x1440 Framebuffer with 1472 pitch (**) RADEONHD(0): Display dimensions: (340, 220) mm (**) RADEONHD(0): DPI set to (107, 166) Of course, in both cases the on-screen resolution was 1440x900. I'm not sure what's going on with the physical sizes. Perhaps this DPI thing is a separate bug? Hope that's useful, Brendon -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2007-10-17 15:27 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1831520 2008-04-03 04:46 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 2343 2008-03-17 13:46 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option SHMConfig true Option TapButton10 Option TapButton20 Option TapButton30 Option VertScrollDelta 15 Option HorizScrollDelta 15 Option RTCornerButton3 Option RBCornerButton2 Option MinSpeed 0.5 Option MaxSpeed 1 Option AccelFactor 0.1 Option FingerLow 1 Option FingerHigh2 EndSection Section Device Identifier Generic Video Card # @ 2008-03-17: 3D works, multi-monitor is somewhat dubious (no xrandr) # Driver fglrx # @ 2008-03-17: Multi-monitor mostly works, xrandr not optimal but okay. No 3D. Driver radeonhd BusID PCI:1:0:0 EndSection Section Monitor Identifier Generic Monitor Option DPMS EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Modes 1440x900 1280x800 1024x768 800x600 640x480 Virtual 2720 1024 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Synaptics Touchpad EndSection Xorg X server log files on system: -rw-r--r-- 1 root root 1509 2008-03-04 11:09 /var/log/Xorg.2.log -rw-r--r-- 1 root root 41588 2008-03-04 11:10 /var/log/Xorg.3.log -rw-r--r-- 1 root
Bug#476198: xserver-xorg-video-radeonhd: Cannot turn on a secondary screen without restarting X (xrandr-related problem)
Package: xserver-xorg-video-radeonhd Version: 1.2.0-1 Severity: normal Hi, Not sure if this is a driver issue or a problem with xrandr itself. Please help point it in the right direction. In order to utilise a secondary screen I find that it must be plugged in at the point that the X server starts. If it's plugged in, xrandr can adjust it without problems. If it's not plugged in when the X server starts, but plugged in later, xrandr will fail to turn it on. Additionally, if xrandr is used to turn the screen off (xrandr --display FOO --off), it will fail to turn it back on afterwards. This is what the I see with the monitor plugged in only after X server restart: $ xrandr --output DVI-I_1/analog --right-of PANEL --auto X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 155 (RANDR) Minor opcode of failed request: 21 () Serial number of failed request: 18 Current serial number in output stream: 18 And this is what I see when the monitor is plugged in before X starts: $ xrandr --output DVI-I_1/analog --right-of PANEL --auto (Everything works as expected.) $ xrandr --output DVI-I_1/analog --off (Monitor puts itself into sleep mode, as expected.) $ xrandr --output DVI-I_1/analog --right-of PANEL --auto X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 155 (RANDR) Minor opcode of failed request: 21 () Serial number of failed request: 18 Current serial number in output stream: 18 In both cases after the failed xrandr, the window manager (kwin) handles as if it was successful, extending maximised windows to the full width of the framebuffer, etc. This has been a problem for a while now; at least the previous version also had this problem. I can send the contents of Xorg.0.log at various stages if they may be helpful. (I've had a look at diffs of them myself, though I didn't spot anthing that would obviously be useful.) Peace, Brendon -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2007-10-17 15:27 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1831520 2008-04-03 04:46 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 2343 2008-04-15 11:24 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option SHMConfig true Option TapButton10 Option TapButton20 Option TapButton30 Option VertScrollDelta 15 Option HorizScrollDelta 15 Option RTCornerButton3 Option RBCornerButton2 Option MinSpeed 0.5 Option MaxSpeed 1 Option AccelFactor 0.1 Option FingerLow 1 Option FingerHigh2 EndSection Section Device Identifier Generic Video Card # @ 2008-03-17: 3D works, multi-monitor is somewhat dubious (no xrandr) # Driver fglrx # @ 2008-03-17: Multi-monitor mostly works, xrandr not optimal but okay. No 3D.
Bug#457903: linux-uvc-source: Makefile should really not call depmod
Package: linux-uvc-source Version: 0.1.0.svn193-1 Followup-For: Bug #457903 Makefile is still calling depmod, even in 0.1.0.svn193-1. If it really must call depmod, could it at least be an absolute path /sbin/depmod instead? Normal users don't have this in PATH, so despite fakeroot, m-a fails when it can't find the depmod command. (At least, that's why I think my builds keep failing with that error message. Building as root is unnecessarily icky, although it works.) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-uvc-source depends on: ii debhelper 6.0.5 helper programs for debian/rules ii module-assistant 0.10.11.0 tool to make module package creati linux-uvc-source recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466174: inkscape: Inkscape blocks when launching konqueror to view the manual and other help items
Package: inkscape Version: 0.45.1-1 Severity: normal Hi. My default web browser is set to Konqueror. When I go to the help menu in Inkscape and select, for example, Manual, Inkscape launches Konqueror to display the manual. If I then minimise Konqueror and go back to Inkscape, Inkscape has stopped responding. It doesn't even redraw properly (big black box where the drawing page should be). It's as if it ran konqueror path/to/manual as opposed to konqueror path/to/manual . When I quit Konqueror, Inkscape comes back to life. Don't know if the behaviour is specific to Konqueror or not. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages inkscape depends on: ii libatk1.0-01.20.0-1 The ATK accessibility toolkit ii libc6 2.7-6 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libcairomm-1.0-1 1.4.6-1 C++ wrappers for Cairo (shared lib ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libgc1c2 1:6.8-1.1 conservative garbage collector for ii libgcc11:4.3-20080202-1 GCC support library ii libgconf2-42.20.1-2+b1 GNOME configuration database syste ii libglib2.0-0 2.14.5-2 The GLib library of C routines ii libglibmm-2.4-1c2a 2.14.2-4 C++ wrapper for the GLib toolkit ( ii libgnomevfs2-0 1:2.20.1-1GNOME Virtual File System (runtime ii libgtk2.0-02.12.5-2 The GTK+ graphical user interface ii libgtkmm-2.4-1c2a 1:2.12.3-2C++ wrappers for GTK+ 2.4 (shared ii liblcms1 1.16-8Color management library ii liborbit2 1:2.14.10-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.18.4-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-3PNG library - runtime ii libpopt0 1.10-3lib for parsing cmdline parameters ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libssl0.9.80.9.8g-4 SSL shared libraries ii libstdc++6 4.3-20080202-1The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11:1.1.9-1 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxft22.1.12-2 FreeType-based font drawing librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxml22.6.31.dfsg-1 GNOME XML library ii libxrandr2 2:1.2.2-1 X11 RandR extension library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxslt1.1 1.1.22-1 XSLT processing library - runtime ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime Versions of packages inkscape recommends: ii imagemagick7:6.2.4.5.dfsg1-2 Image manipulation programs ii libwmf-bin 0.2.8.4-6 Windows metafile conversion tools ii perlmagick 7:6.2.4.5.dfsg1-2 A perl interface to the libMagick ii pstoedit 3.45-2PostScript and PDF files to editab -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459344: /etc/cron.daily/apt exits with return code 1, despite being configured to do nothing
Luke, I'm sorry, but I believe you don't fully appreciate what the issue actually is. That is the only explanation I've come up with that might account for the amount of irrelevant verbiage in your last email (assuming you're not a troll - big assumption, considering the rather grand claims you make). Let's establish some facts: apt provides this file: /etc/cron.daily/apt (This is the file I was referring to in my email when I said cron script. Sorry if that confused you.) This file is then run daily by cron (or through anacron, when it gets a chance) as root. So permissions is not an issue. Starting at line 176 of that script we have the following code: # check if we can lock the cache and if the cache is clean if ! apt-get check -q -q 2/dev/null; then echo $0: could not lock the APT cache exit 1 fi Usually when this script is run, apt-get can get the lockfile /var/lib/dpkg/lock, the above code succeeds, the remaining code in the script, by default, does nothing significant, and everyone is happy. However, assume now that the user just happens to be running (as root, or under sudo) an aptitude (or even apt-get) process while this cron job attempts to run. aptitude locks the apt cache while it is running. The apt-get check command will then fail as the cache is already locked. It will print out the following string (which promptly gets sent to the great bit bucket in the sky): E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable) E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it? It's guess is completely correct, of course. Another process does hold the lock. This failure, however, causes the cron.daily/apt script to then exit with status 1 (the same behaviour as /bin/false, which is what Francesco was talking about), and this in turn causes (ana)cron to send an email notification to root (and whichever user that mail forwards to) complaining that the script failed (exit 1) and with the message that it could not lock the APT cache. This is all by default, remember, where no files should be autoupdated anyway. All the user has to do is be running a process like apt-get or aptitude that locks the cache. Now the user is being notified about errors occurring in /etc/cron.daily/apt when 1. they never did anything out of the ordinary, and 2. that script shouldn't be trying to do anything anyway. Why should the user be notified about this? I agree with you that this is a nuisance, not mission critical. However, this is default behaviour of the apt package, and not entirely on the user end, and so it should be addressed like any other packaged nuisance. I suspect the solution involves checking the output of apt-get check -q -q. For example, when there actually *is* a problem with permissions, the resulting message is: E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied) E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? It looks like checking that string (or maybe the return value itself?) might be a possible solution. But I don't know nearly enough about apt's error messages to confidently make that call. I'll leave that up to the developers to think about. Peace, Brendon Lord of, St. Luke Valor wrote (Wed, 16 Jan 2008): Francesco, I read the original message over again and the obvious diagnosis is that somewhere on the host system, permissions are not properly set. Since the days of UNIX it has been proper to establish a wheel, which is a group user ID that owns processes and daemons, and that also has a very low ID with an invisible password. I cannot see whether you have established a password shadow file. I do not know whether your system is on a local area network. Are you running CVS? RCS? Subversion? Do you know how to lock and unlock files? Do you have root access, or at the least superuser privileges? Is sudo available to you? Do you have a sudoers file established? Are you familiar with /etc/passwd and /etc/shadow, respectively, as I believe they are called? I am not sure what your mean with references to /bin/true and /bin/false. Are you referring to files on your filesystem? I am at a terminal in a public library and can only go by memory. I do not know what system administrative techniques are available to you. The problem is not mission critical, it is a simple nuisance. It is contained entirely on the user end. It is not the Debian project's responsibility. I offered a suggestion on the spur of the moment without a Linux system available to me. I am a volunteer. I am encouraging you to find ways to contribute to the group project with solutions to your own problems. That is how all engineering projects are completed. How do I know? I am the original implementor of C++. I wrote *The C++ Programming Language* and *Accelerated C++*. I learned right alongside Bjarne Stroupstrop and published the
Bug#459344: /etc/cron.daily/apt exits with return code 1, despite being configured to do nothing
Hi, It doesn't appear to be the case that the cron script is actually doing any updating by default. I think this bug boils down to this: The apt cron script conflicts with an already running apt (or aptitude) process. If the user is running apt, this situation is not at all an error, the cron script just chose an inconvenient time to be run. If the default behaviour is for the cron script to run, the script should not just blindly report an error and exit 1, as the reports that generates are confusing for users. (Sure made me wonder what the hell was wrong.) And what kind of elitist garbage is it to then tell your legitimately confused users to go read a book and fix the problem-by-default themselves? That's my take on it. Peace, Brendon Lord of, St. Luke Valor wrote (Sat, 12 Jan 2008): It only takes one hand to type. Fix it once, fix it for free, fix it for everyone, fix it forever. Have fun while you're at it. On 1/9/08, Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 8 Jan 2008 12:21:51 -0500 Lord of, St. Luke Valor wrote: I have a suggestion. 1) Find any text you are able on UNIX 2) Read about cron It is possible that cron was implemented in such a way that it must be set to task. If the Anacron message bothers you, I would remove APT from the cron process. It will free up memory. I *can* fix the issue for *my system*, but I would rather see the *Debian package* fixed, so that other users will benefit from the fix... After all, this is what the BTS is about: helping Debian to improve so that users won't need to fix every single system by hand. Right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454568: [Linuxwacom-discuss] Bug#454568: xserver-xorg-input-wacom + ksmserver = X crash
Thank you. I didn't expect that to work (seeing how simple kcminputrc is), but it did! Add another one to the tally. This result is kinda perplexing, though. My first suspicion was that perhaps something adjusting the mouse parameters was the culprit, so I removed the [Mouse] section and tried that. Even with only the [Keyboard] section in the file the problem persists. It seems only when the entire file is gone I can login without hiccup. So this is a workaround. Not perfect since I can't set startup numlock status or mouse acceleration threshold, but these aren't too important. Peace, Brendon Dirk Bierfeld wrote (Fri, 7 Dec 2007): A friend of mine had the same problem that KDE causes an X crash. He figured out that when removing ~/user/.kde/share/config/kcminputrc KDE will start without any problem. Perhaps that will hepl. I either havn't Xorg 7.3 nor KDE so I can't proof it, but it worked for someone else too at least. Dirk Ron schrieb: This one I'm a bit less sure about... unless it's another manifestation of the double unmapping bug (also in XServer and known upstream), you'll probably have to talk this one through on the linux-wacom list. I've forwarded it there for comment. Cheers, Ron On Thu, Dec 06, 2007 at 07:48:01PM +1000, Brendon Higgins wrote: Package: xserver-xorg-input-wacom Version: 0.7.9.3-2 Severity: normal (Wasn't sure whether to report here or to KDE devs. Here goes...) I've got a weird problem. If I have the wacom drivers enabled in Xorg.conf and login to KDE (4:3.5.8.dfsg.1-3) as normal the X server will crash near the end of the KDE splashscreen, and I'm sent back to the KDM login screen. This doesn't happen when I disable the wacom drivers in ServerLayout. What's weirder is that X does *not* crash if I switch to a console VT while KDE is booting, then switch back not long after booting has finished. Then everything seems fine. But if I leave the screen in X while KDE boots, crash happens. By going through the steps in startkde manually I've narrowed it down to some point inside the call to ksmserver. Something ksmserver starts seems to puke with the wacom driver for some reason. I'm not sure how to go about narrowing it down further than that, though I want to. Advice on an approach to take would be appreciated. Xorg.0.log that ends in such a crash is attached, but it doesn't appear to be very informative. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. -- no debconf information X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) Current Operating System: Linux phi 2.6.22-3-amd64 #1 SMP Sun Nov 4 18:18:09 UTC 2007 x86_64 Build Date: 20 November 2007 02:55:16AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 6 18:30:59 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor BenQ (**) | |--Device nVidia 8600GT (**) |--Input Device Generic Keyboard (**) |--Input Device Configured Mouse (**) |--Input Device stylus (**) |--Input Device eraser (**) |--Input Device cursor (**) |--Input Device pad (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x7b2660 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: pcidata (II
Bug#454570: [Linuxwacom-discuss] Bug#454570: xserver-xorg-input-wacom: KeepShape doesn't work properly
Magnus Vigerlöf wrote (Fri, 7 Dec 2007): It seems that you can work around this problem by dropping KeepShape and adding the following option: Option BottomY 6380 Another successful workaround. Thank you! (You guys are quick, too!) Peace, Brendon On Thu, Dec 06, 2007 at 07:50:30PM +1000, Brendon Higgins wrote: Subject: xserver-xorg-input-wacom: KeepShape doesn't work properly Package: xserver-xorg-input-wacom Version: 0.7.9.3-2 Severity: normal I have a largish 16:10 display and a smallish Graphire4 (4x5). I used to use the KeepShape option, however with the new version of the driver it does not work correctly. It seems the driver correctly determines the lower limit of the active area of the tablet, but it does not then scale the coordinates onscreen as it should. What this means is that, instead of cutting some of the bottom off the usuable area of the tablet so that the rest matches the entire area of the screen, the bottom of the usuable area of the tablet is cut, but the pointer on the screen will not go below a similar cutoff point on the screen. I can't click on, for example, the taskbar on the bottom of my screen. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. -- no debconf information -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-i - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Linuxwacom-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454568: xserver-xorg-input-wacom + ksmserver = X crash
Package: xserver-xorg-input-wacom Version: 0.7.9.3-2 Severity: normal (Wasn't sure whether to report here or to KDE devs. Here goes...) I've got a weird problem. If I have the wacom drivers enabled in Xorg.conf and login to KDE (4:3.5.8.dfsg.1-3) as normal the X server will crash near the end of the KDE splashscreen, and I'm sent back to the KDM login screen. This doesn't happen when I disable the wacom drivers in ServerLayout. What's weirder is that X does *not* crash if I switch to a console VT while KDE is booting, then switch back not long after booting has finished. Then everything seems fine. But if I leave the screen in X while KDE boots, crash happens. By going through the steps in startkde manually I've narrowed it down to some point inside the call to ksmserver. Something ksmserver starts seems to puke with the wacom driver for some reason. I'm not sure how to go about narrowing it down further than that, though I want to. Advice on an approach to take would be appreciated. Xorg.0.log that ends in such a crash is attached, but it doesn't appear to be very informative. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. -- no debconf information X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) Current Operating System: Linux phi 2.6.22-3-amd64 #1 SMP Sun Nov 4 18:18:09 UTC 2007 x86_64 Build Date: 20 November 2007 02:55:16AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 6 18:30:59 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor BenQ (**) | |--Device nVidia 8600GT (**) |--Input Device Generic Keyboard (**) |--Input Device Configured Mouse (**) |--Input Device stylus (**) |--Input Device eraser (**) |--Input Device cursor (**) |--Input Device pad (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x7b2660 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: pcidata (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10de,0369 card 1043,8239 rev a1 class 05,00,00 hdr 00 (II) PCI: 00:01:0: chip 10de,0360 card 1043,8239 rev a2 class 06,01,00 hdr 80 (II) PCI: 00:01:1: chip 10de,0368 card 1043,8239 rev a2 class 0c,05,00 hdr 80 (II) PCI: 00:01:2: chip 10de,036a card 1043,8239 rev a2 class 05,00,00 hdr 80 (II) PCI: 00:02:0: chip 10de,036c card 1043,8239 rev a1 class 0c,03,10 hdr 80 (II) PCI: 00:02:1: chip 10de,036d card 1043,8239 rev a2 class 0c,03,20 hdr 80 (II) PCI: 00:04:0: chip 10de,036e card 1043,8239 rev a1 class 01,01,8a hdr 00 (II) PCI: 00:05:0: chip 10de,037f card 1043,8239 rev a2 class 01,01,85 hdr 80 (II) PCI: 00:05:1: chip 10de,037f card 1043,8239 rev a2 class 01,01,85 hdr 80 (II) PCI: 00:05:2: chip 10de,037f card 1043,8239 rev a2 class 01,01,85 hdr 80 (II) PCI: 00:06:0: chip 10de,0370 card , rev a2 class 06,04,01 hdr 81 (II) PCI: 00:06:1: chip 10de,0371 card 1043,81f6 rev a2 class 04,03,00 hdr 80 (II) PCI: 00:08:0: chip 10de,0373 card 1043,8239 rev a2 class 06,80,00 hdr 00 (II) PCI: 00:09:0: chip 10de,0373 card 1043,8239 rev a2 class 06,80,00 hdr 00 (II) PCI: 00:0a:0: chip 10de,0376 card ,
Bug#454570: xserver-xorg-input-wacom: KeepShape doesn't work properly
Package: xserver-xorg-input-wacom Version: 0.7.9.3-2 Severity: normal Subject: xserver-xorg-input-wacom: KeepShape doesn't work properly Package: xserver-xorg-input-wacom Version: 0.7.9.3-2 Severity: normal I have a largish 16:10 display and a smallish Graphire4 (4x5). I used to use the KeepShape option, however with the new version of the driver it does not work correctly. It seems the driver correctly determines the lower limit of the active area of the tablet, but it does not then scale the coordinates onscreen as it should. What this means is that, instead of cutting some of the bottom off the usuable area of the tablet so that the rest matches the entire area of the screen, the bottom of the usuable area of the tablet is cut, but the pointer on the screen will not go below a similar cutoff point on the screen. I can't click on, for example, the taskbar on the bottom of my screen. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. -- no debconf information -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-wacom depends on: ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server xserver-xorg-input-wacom recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444489: dosage_1.5.8-1.diff.gz reverts the .orig.tar.gz to 1.5.7!
Package: dosage Version: 1.5.8-1 Followup-For: Bug #89 Hi. I found the reason that the 1.5.8 package appears to contain 1.5.7 code. dosage_1.5.8.orig.tar.gz is indeed 1.5.8, however dosage_1.5.8-1.diff.gz reverts the entire hierarchy back to 1.5.7. That diff is pretty seriously broken. Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dosage depends on: ii python2.4.4-6An interactive high-level object-o ii python-central0.5.15 register and build utility for Pyt dosage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444489: Package version 1.5.8-1 is still dosage version 1.5.7
Package: dosage Version: 1.5.8-1 Severity: normal Hi, It looks like the version uploaded as 1.5.8-1 is actually dosage version 1.5.7. You can tell by the number in /usr/share/pycentral/dosage/site-packages/dosage/version.py, and also comparing the comics modules to 1.5.8 from upstream (for example, there are clearly many more comic submodules in the KeenSpot module in upstream than in this package). Peace, Brendon -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dosage depends on: ii python2.4.4-6An interactive high-level object-o ii python-central0.5.15 register and build utility for Pyt dosage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook)
Hi there, I'm still having this problem but I noticed something weird today. I haven't had a chance to look into it in much detail yet, and won't for at least another few days, but I thought it'd be worth mentioning now. Occasionally when I put the machine to sleep, then open it up again, the trackpad loses all my settings, and goes back to the defaults: one-touch click (which I hate), etc. If I sleep the machine and open it again it usually remembers the settings again. The strange thing I found today was that when it does lose the settings, *the trackpad properly registers with pbbuttonsd and is able to bring the machine out of the dark-screen state*. When I sleep the machine and open it up again, my trackpad settings come back, but pbbuttons stops responding to it again. I haven't tried staying with defaults when X boots or anything else. Like I said, I haven't gotten a chance yet. Hope this is useful, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400481: mol-source doesn't build modules on current kernels
Hi, mol-source *still* doesn't build on recent kernels. 2.6.21 has entered testing now, necessitating recompilation of mol modules, but also making mol-source unusable. This is hardly acceptable considering a patch has been available for 8 months. Can someone please apply the patch? Peace, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414243: arts: First start resets Treble/Bass settings of the sound card
Package: arts Version: 1.5.5-1 Severity: normal When I switch my machine on for the first time and login to KDE, as soon as arts starts it resets Treble and Bass settings to the default 50/50, no matter what I've set them to before. This only happens the first time arts is started on the machine for each reboot. I've narrowed it down to arts because I can login to the console before logging into KDE and set the Bass setting. Then I examine the output of while true; do amixer get Bass out; ps ax out; sleep 1; done. Conspicuously, arts starts the second before Bass goes from (eg) 40% to 50%. What's weird is the fact that this only happens once each time the machine is started. If I set the Bass setting to something else, kill and restart artsd, it doesn't touch the setting. It's only when artsd is started for the first time that it resets the Bass and Treble. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages arts depends on: ii libarts1c2a 1.5.5-1aRts sound system core components ii libartsc0 1.5.5-1aRts sound system C support librar arts recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410373: kde-style-polyester: Yellow window buttons
Package: kde-style-polyester Version: 1.0~beta1-1 Severity: normal The buttons on the top of windows using the polyester style are bright yellow, except for the icons on the buttons themselves. Example attached. It happens on all windows. Changing the button style in the polyester settings seems to affect the icons, but not the yellow surrounding. This occurs on a PowerPC machine. I'm also running an AMD64 box with a similar setup, and the problem doesn't appear there. So my first guess would be an endianness issue. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages kde-style-polyester depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii kwin 4:3.5.5a.dfsg.1-5 the KDE window manager ii libc6 2.3.6.ds1-10 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 kde-style-polyester recommends no packages. -- no debconf information yellow.png Description: PNG image
Bug#377447: closed by Frank Lichtenheld [EMAIL PROTECTED] (Bug#377447: fixed in pbbuttonsd 0.7.9-1)
Debian Bug Tracking System wrote (Wednesday 04 October 2006 11:03 am): This is an automatic notification regarding your Bug report #377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook), which was filed against the pbbuttonsd package. It has been closed by Frank Lichtenheld [EMAIL PROTECTED]. Sorry, Frank. Please reopen this bug. I've checked with the latest pbbuttonsd and xorg in sid (other packages from testing). When unplugged from the power supply, the screen still goes dark and eventually the machine goes to sleep *regardless* of *any* use of the trackpad. So it would seem the work-around doesn't. Peace, Brendon pgpEDvuUELPhA.pgp Description: PGP signature
Bug#377447: closed by Frank Lichtenheld [EMAIL PROTECTED] (Bug#377447: fixed in pbbuttonsd 0.7.9-1)
Hi, Debian Bug Tracking System wrote (Wednesday 04 October 2006 11:03 am): This is an automatic notification regarding your Bug report #377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook), which was filed against the pbbuttonsd package. It has been closed by Frank Lichtenheld [EMAIL PROTECTED]. I'm sad to say I had luck with the fix. I pulled the new version from unstable and am giving it a whirl, but it still appears that the trackpad is ignored just like before. It might be worth keeping in mind that I haven't managed to update Xorg to the latest version in testing yet, so if the problem is still Xorg in the way I guess that might change. I'll let you know if it does once I finish downloading Xorg. Peace, Brendon pgp7pnjXYhlUS.pgp Description: PGP signature
Bug#377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook)
Hi Matthias, On 31/07/06, Matthias Grimm [EMAIL PROTECTED] wrote: Do you use the XOrg with the synaptics trackpad driver? Yes, I do. This driver has a known problem. It opens the event device for the trackpad exclusively and block it for any other application. In this case pbbuttonsd can't open the event device for the trackpad and therefore won't get events from it. I see. It makes me wonder what the reasoning for doing that is. There is a patch for the synaptics driver out to solve this, but I don't have it at hand. Please file a bugreport to Xorg and the package xserver-xorg-input-synaptics too. Maybe they will fix the problem one day and use a cooperative way to read trackpad events. I will do that. Thanks for your help. Peace, Brendon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380705: xserver-xorg-input-synaptics: opens event device exclusively, blocking other apps
Package: xserver-xorg-input-synaptics Version: 0.14.6-1 Severity: normal This presented itself to me originally as a problem with pbbuttonsd (see bug #377447), as that daemon seemed to not notice when I moved the trackpad, so it would suspend the machine even while I was using it. The maintainer of pbbuttonsd claims this is a known bug in the synaptics driver. The cause (apparently) is that thhe synaptics driver opens the event device exclusively, so pbbuttonsd can't read any events from it. This would certainly cause the problem. Apparently there's a patch floating around, too (no idea where, though. I wouldn't think opening an event device exclusively would be standard behaviour. Peace, Brendon -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages xserver-xorg-input-synaptics depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libx11-6 2:1.0.0-7 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxi61:1.0.0-5 X11 Input extension library ii xserver-xorg-core 1:1.0.2-9 X.Org X server -- core server xserver-xorg-input-synaptics recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377751: aptitude crashes when retrieving packages from multiple DVDs
Package: aptitude Version: 0.4.1-1.1 Followup-For: Bug #377751 I've also seen this, on both of my own machines: a powerpc (iBook) and an amd64. If for example I install libgamin-dev, which lives on DVD3, it depends on libgamin0 and gamin, which live on DVD1. Reading the first DVD and install those goes along fine, then aptitude asks for the next DVD, insert it, click Continue, and a SEGFAULT appears back at the shell. When using aptitude by the command line interface it is apparent that the SEGFAULT occurs in a seperate thread *before* the prompt asking for the other DVD. When apt-get is used in the same manner, no SEGFAULT occurs. I grabbed a core file from one instance of this happening on my powerpc. It's 50MB big, so I'll just attach gdb's backtrace. Hope this helps. Peace, Brendon -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.44.2 Advanced front-end for dpkg ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libncursesw5 5.5-2 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.16-3 type-safe Signal Framework for C++ ii libstdc++64.1.1-5The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) -- no debconf information [EMAIL PROTECTED]:~$ gdb aptitude aptitude.core.3996 GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/libthread_db.so.1. Reading symbols from /usr/lib/libapt-pkg-libc6.3-6.so.3.11...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libapt-pkg-libc6.3-6.so.3.11 Reading symbols from /lib/libncursesw.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncursesw.so.5 Reading symbols from /usr/lib/libsigc-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsigc-2.0.so.0 Reading symbols from /lib/tls/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/ld.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/ld.so.1 Reading symbols from /lib/tls/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_compat.so.2 Reading symbols from /lib/tls/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libnsl.so.1 Reading symbols from /lib/tls/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_nis.so.2 Reading symbols from /lib/tls/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_files.so.2 Failed to read a valid object file image from memory. Core was generated by `aptitude'. Program terminated with signal 11, Segmentation fault. #0 0x0ff590e4 in pkgOrderList::WipeFlags () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 (gdb) backtrace #0 0x0ff590e4 in pkgOrderList::WipeFlags () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 #1 0x0ff5c678 in pkgOrderList::OrderUnpack () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 #2 0x0ff63528 in pkgPackageManager::OrderInstall () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 #3 0x0ff61fd8 in pkgPackageManager::DoInstall () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 #4 0x101cf570 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar* () #5 0x101cfa78 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar* () #6 0x100d6570 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string__gnu_cxx::__normal_iteratorchar
Bug#377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook)
Package: pbbuttonsd Version: 0.7.5-2 Severity: normal *** Please type your report below this line *** This sounds a lot like problems people have had in the past with external mouses. Moving the pointer with the internal trackpad does nothing to stop pbbuttonsd darkening the screen and eventually sending the machine to sleep. Typing prevents this as you would expect. I've heard that iBooks only recently put the trackpad on USB, so I'm thinking that might have something to do with it. I saw autorescan in README.Debian so I went to enable that only to find that it was already enabled. Not sure what else to try. I'm happy to send ls* or logs or whatever might help. A couple are below. Peace, Brendon epsilon:/home/brendon# cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1420.00MHz revision: 0.5 (pvr 8003 0105) bogomips: 73.47 timebase: 18432000 platform: PowerMac machine : PowerBook6,7 motherboard : PowerBook6,7 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 512K unified pmac-generation : NewWorld epsilon:/home/brendon# ls -la /dev/input total 0 drwxr-xr-x 4 root root 360 2006-07-09 10:00 . drwxr-xr-x 15 root root3440 2006-07-09 10:01 .. drwxr-xr-x 2 root root 140 2006-07-09 10:00 by-id drwxr-xr-x 2 root root 160 2006-07-09 10:00 by-path crw-rw 1 root root 13, 64 2006-07-09 10:00 event0 crw-rw 1 root root 13, 65 2006-07-09 10:00 event1 crw-rw 1 root root 13, 66 2006-07-09 10:00 event2 crw-rw 1 root root 13, 67 2006-07-09 10:00 event3 crw-rw 1 root root 13, 68 2006-07-09 10:00 event4 crw-rw 1 root root 13, 69 2006-07-09 10:00 event5 crw-rw 1 root root 13, 70 2006-07-09 10:00 event6 crw-rw 1 root root 13, 63 2006-07-09 10:00 mice crw-rw 1 root root 13, 32 2006-07-09 10:00 mouse0 crw-rw 1 root root 13, 33 2006-07-09 10:00 mouse1 crw-rw 1 root root 13, 34 2006-07-09 10:00 mouse2 crw-rw 1 root root 13, 128 2006-07-09 10:00 ts0 crw-rw 1 root root 13, 129 2006-07-09 10:00 ts1 crw-rw 1 root root 13, 130 2006-07-09 10:00 ts2 epsilon:/home/brendon# lsusb -v Bus 004 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.17-1-powerpc ohci_hcd iProduct2 OHCI Host Controller iSerial 1 0001:10:1b.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x0002 No power switching (usb 1.0) Ganged overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x98 PortPwrCtrlMask0x10 Hub Port Status: Port 1: .0100 power Port 2: .0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 003 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.17-1-powerpc ohci_hcd iProduct2 OHCI Host Controller iSerial 1 0001:10:1b.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface
Bug#311802: #311802: nvidia-kernel-source: had to run depmod manually after reboot
Package: nvidia-kernel-source Version: 1.0.8762-2 Followup-For: Bug #311802 Closely related to this is the fact that newer kernels no longer run depmod on boot. See http://lists.debian.org/debian-devel/2006/06/msg00535.html;. nvidia-kernel packages should run depmod in postinst. Attached is a patch to nvidia-graphics-drivers that implements this. All it does is uncomment the dh_installmodules line. dh_installmodules adds the logic to do the depmod for the right kernel version in postinst. Peace, Brendon -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-amd64-k8-smp Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages nvidia-kernel-source depends on: ii debhelper 5.0.37.2 helper programs for debian/rules ii dpatch2.0.20 patch maintenance system for Debia ii make 3.81-2 The GNU version of the make util ii sed 4.1.5-1The GNU sed stream editor Versions of packages nvidia-kernel-source recommends: ii devscripts2.9.20 Scripts to make the life of a Debi ii kernel-package10.049 A utility for building Linux kerne ii nvidia-glx1.0.8762-2 NVIDIA binary XFree86 4.x driver -- no debconf information diff -Naur nvidia-graphics-drivers-1.0.8762/debian.binary/rules nvidia-graphics-drivers-1.0.8762.new/debian.binary/rules --- nvidia-graphics-drivers-1.0.8762/debian.binary/rules2006-07-05 12:11:56.0 +1000 +++ nvidia-graphics-drivers-1.0.8762.new/debian.binary/rules2006-07-05 12:06:26.0 +1000 @@ -202,7 +202,7 @@ # dh_installexamples # dh_installmanpages # dh_undocumented -# dh_installmodules + dh_installmodules dh_installinit
Bug#373646: compiling em8300 with module-assistant would be nice
Hi Lance, What you have there looks like problems em8300 0.15.1 has with recent kernels, rather than a problem with module-assistant. I think 0.15.1 has problems with anything beyond 2.6.13 linux. (Which is why I'd like to have it updated ASAP. Unfortunately, I'm not a Debian dev, so I'm relying on Nicolas who seems to have been busy elsewhere, as of late.) But looking at the changes I've made updating the em8300 package, it looks like I did have to do something to get m-a doing things properly. Anyway, m-a support is something that has been worked on, and will be in the next revision, along with a bunch of other fixes. Peace, Brendon You wrote (Saturday 17 June 2006 7:05 am): I don't know what any of this means, but here's the buildlog: /usr/bin/make -f debian/rules MODDIR=/lib/modules/2.6.16-2-686/build/.. clean-modules make[1]: Entering directory `/usr/src/modules/em8300' /usr/bin/make -w KERNEL_LOCATION=/lib/modules/2.6.16-2-686/build clean make[2]: Entering directory `/usr/src/modules/em8300' rm -f *.o *.ko *.mod.c .*.cmd .*.o.flags make[2]: Leaving directory `/usr/src/modules/em8300' perl debian/scripts/dh_modulecontrol --module --clean rm -rf /usr/src/modules/em8300/debian/em8300-modules-2.6.16-2-686 if [ -f stamp-debian ]; then rm -f `cat stamp-debian`; fi rm -f stamp-debian make[1]: Leaving directory `/usr/src/modules/em8300' /usr/bin/make -f debian/rules MODDIR=/lib/modules/2.6.16-2-686/build/.. binary-modules make[1]: Entering directory `/usr/src/modules/em8300' /usr/bin/make -w KERNEL_LOCATION=/lib/modules/2.6.16-2-686/build clean make[2]: Entering directory `/usr/src/modules/em8300' rm -f *.o *.ko *.mod.c .*.cmd .*.o.flags make[2]: Leaving directory `/usr/src/modules/em8300' perl debian/scripts/dh_modulecontrol --module --clean rm -rf /usr/src/modules/em8300/debian/em8300-modules-2.6.16-2-686 if [ -f stamp-debian ]; then rm -f `cat stamp-debian`; fi rm -f stamp-debian /usr/bin/make -w KERNEL_LOCATION=/lib/modules/2.6.16-2-686/build make[2]: Entering directory `/usr/src/modules/em8300' /usr/bin/make -C /lib/modules/2.6.16-2-686/build SUBDIRS=/usr/src/modules/em8300 modules make[3]: Entering directory `/usr/src/linux-headers-2.6.16-2-686' CC [M] /usr/src/modules/em8300/adv717x.o /usr/src/modules/em8300/adv717x.c:123: error: unknown field 'owner' specified in initializer /usr/src/modules/em8300/adv717x.c:123: warning: initialization makes integer from pointer without a cast /usr/src/modules/em8300/adv717x.c:125: error: unknown field 'name' specified in initializer /usr/src/modules/em8300/adv717x.c:125: warning: initialization makes integer from pointer without a cast /usr/src/modules/em8300/adv717x.c:127: error: unknown field 'flags' specified in initializer /usr/src/modules/em8300/adv717x.c:127: error: 'I2C_DF_NOTIFY' undeclared here (not in a function) /usr/src/modules/em8300/adv717x.c: In function 'adv717x_detect': /usr/src/modules/em8300/adv717x.c:458: error: 'struct i2c_algorithm' has no member named 'id' /usr/src/modules/em8300/adv717x.c:458: error: 'I2C_ALGO_ISA' undeclared (first use in this function) /usr/src/modules/em8300/adv717x.c:458: error: (Each undeclared identifier is reported only once /usr/src/modules/em8300/adv717x.c:458: error: for each function it appears in.) make[4]: *** [/usr/src/modules/em8300/adv717x.o] Error 1 make[3]: *** [_module_/usr/src/modules/em8300] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.16-2-686' make[2]: *** [build] Error 2 make[2]: Leaving directory `/usr/src/modules/em8300' make[1]: *** [build-modules] Error 2 make[1]: Leaving directory `/usr/src/modules/em8300' make: *** [kdist_image] Error 2 pgpvZlRO4YaJW.pgp Description: PGP signature
Bug#373646: compiling em8300 with module-assistant would be nice
Hi! I'm helping the maintainer Nicolas update of this package. (I ought to prod him about it again, actually ;-) ) Lance Simmons wrote (Thursday 15 June 2006 5:14 am): I've noticed that more and more modules can be compiled using module-assistant. It would be great if em8300 were one of them. I've no idea how much of a pain it would be for the maintainer to arrange that, but from the end-user's perspective, module-assistant is a great thing. Indeed it is. I've been using module-assistant to compile it for a while, and I don't recall doing anything special to get that working. IIRC, it was just already in the list. Have you actually tried using m-a to compile it? What was the result? Peace, Brendon pgpbxBKRXb0ln.pgp Description: PGP signature
Bug#373141: pinball: 0.3.1-5+b1 uninstallable
Package: pinball Version: 0.3.1-5 Severity: grave Justification: renders package unusable pinball has a source-versioned depends on pinball data. Thus, pinball 0.3.1-5+b1 depends on pinball-data 0.3.1-5+b1, which doesn't exist (wasn't rebuilt along with pinball, apparently), thus rendering pinball unable to satisfy its dependencies and so uninstallable. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8-smp Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages pinball depends on: ii libaa1 1.4p5-30 ascii art library ii libartsc0 1.5.3-1 aRts sound system C support librar ii libasound2 1.0.11-3 ALSA library ii libaudio2 1.7-9 The Network Audio System (NAS). (s ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libc6 2.3.6-13 GNU C Library: Shared libraries ii libesd-alsa0 [libe 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libgcc11:4.1.0-4 GCC support library ii libgl1-mesa-glx [l 6.4.2-1 A free implementation of the OpenG ii libglib2.0-0 2.10.2-1 The GLib library of C routines ii libglu1-mesa [libg 6.4.2-1 The OpenGL utility library (GLU) ii libice61:1.0.0-3 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libncurses55.5-2 Shared libraries for terminal hand ii libogg01.1.3-2 Ogg Bitstream Library ii libpng12-0 1.2.8rel-5.1 PNG library - runtime ii libsdl-image1.21.2.4-1 image loading library for Simple D ii libsdl-mixer1.21.2.6-1.1 mixer library for Simple DirectMed ii libsdl1.2debian1.2.9-5+b1Simple DirectMedia Layer ii libslang2 2.0.6-2 The S-Lang programming library - r ii libsm6 1:1.0.0-4 X11 Session Management library ii libsmpeg0 [libsmpe 0.4.5+cvs20030824-1.8 SDL MPEG Player Library - shared l ii libstdc++6 4.1.0-4 The GNU Standard C++ Library v3 ii libtiff4 3.8.2-4 Tag Image File Format (TIFF) libra ii libvorbis0a1.1.2-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.1.2-1 The Vorbis General Audio Compressi ii libx11-6 2:1.0.0-6 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxt6 1:1.0.0-5 X11 toolkit intrinsics library ii pinball-data 0.3.1-5 Data files for the Emilia Pinball ii xlibs 6.9.0.dfsg.1-6X Window System client libraries m ii zlib1g 1:1.2.3-11compression library - runtime pinball recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367447: kpdf: Crashes on Springer Handbook of Nanotechnology PDFs
Howdy, Something interesting happened. I was reading another unrelated PDF in KPDF, then tried loading one of my bad PDFs in KPDF after forgetting that it crashes. KPDF didn't crash. The bad PDF worked fine. The contents list seems to work, though when clicking on a topic not in the current file, KPDF closes the file and then complains that it couldn't load the new one. (It would probably be a good idea to check first. I had to load the file again.) KPDF doesn't work if I start it and *then* open the bad PDF - it crashes. KPDF doesn't work if I start by clicking on a bad PDF in konqueror, or by specifying it on the command line - crashes. KPDF *does* work if I've successfully loaded another PDF (good or bad) beforehand. Peace, Brendon pgpgEdzn1XqRI.pgp Description: PGP signature
Bug#338537: #338537: mffm-fftw: file conflict between mffm-fftw1c2 and mffm-fftw1
Package: mffm-fftw1c2 Version: 1.6-1 Followup-For: Bug #338537 I just upgraded wsola, which now depends on mffm-fftw1c2. Breakage ensues. The right way to fix it is probably the same way the other c2 packages fixed this sort of thing; with a Conflict: mffm-fftw1 in mffm-fftw1c2 control. Peace, Brendon -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8-smp Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
