Bug#1038463: cegui-mk2: Is this library still useful to have in Debian?
Hi, just to add a small bit of information: If cegui-mk2 is no longer useful, we could remove it from the archive to avoid it taking up QA time. A game that still uses the library, although not being shipped with Debian (while in principle, it could), is "The Secret Chronicles of Dr. M." (https://secretchronicles.org/en/). On that note: the current version in Debian is called "0.8.7+git20220615-3". I did assume this is the git version of the master branch on date 20220615 of the main repo https://github.com/cegui/cegui/. However, that cannot be, as changes made in that repo are not present in the Debian package. One example is Editbox.cpp: compare that file in https://github.com/cegui/cegui/tree/master/cegui/src/widgets (2 years old) to the one here: https://salsa.debian.org/games-team/cegui-mk2/-/tree/master/cegui/src/widgets?ref_type=heads (8 years old) That file is special only insofar as TSC currently faces the problem that the version of cegui in Debian is too old to be used with a "current" build against cegui, see https://github.com/Secretchronicles/TSC/issues/708. Frank signature.asc Description: PGP signature
Bug#1016288: pulseaudio-dlna: crashes on start
Package: pulseaudio-dlna Version: 0.5.3+git20200329-0.1 Followup-For: Bug #1016288 Dear Maintainer, A similar situation occurs on stable: Exception in thread zeroconf-ServiceBrowser__googlecast._tcp.local.: Traceback (most recent call last): File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner self.run() File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1557, in run self._service_state_changed.fire( File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1333, in fire h(**kwargs) File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1427, in on_change listener.add_service(*args) File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 65, in add_service self._add_update_service(zconf, typ, name, self.add_callback) File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 123, in _add_update_service callback(uuid, name) File "/usr/lib/python3/dist-packages/pychromecast/__init__.py", line 246, in internal_callback callback( File "/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/__init__.py", line 36, in wrapper device = f(*args, **kwargs) File "/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/chromecast/__init__.py", line 47, in _on_device_added return ChromecastRendererFactory.from_pychromecast(device) File "/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/chromecast/renderer.py", line 183, in from_pychromecast ip=pychromecast.host, AttributeError: 'Chromecast' object has no attribute 'host' Dependencies of pulseaudio-dlna recently changed quite a bit, so updating to the newest version is likely not going to work well (with other system-installed dependencies and other software depending on those). However, I could without problem build release 0.6.3, which works on Debian stable and also officially should work with the libraries present in Debian stable. Versions > 0.5.2 are available from here: https://github.com/Cygn/pulseaudio-dlna . I am reporting this here even though the previous report was for unstable because quite likely versions of dependencies are the problem in both cases and similar fixes/updates could be made in both cases. Without any change, this package is quite unuseable also on Debian stable, so 'grave' seems to be the correct severity. -- System Information: Debian Release: 11.4 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pulseaudio-dlna depends on: ii flac 1.3.3-2+deb11u1 ii lame 1:3.100-dmo2 ii opus-tools0.1.10-1+b1 ii python3 3.9.2-3 ii python3-chardet 4.0.0-1 ii python3-dbus 1.2.16-5 ii python3-distutils 3.9.2-1 ii python3-docopt0.6.2-3 ii python3-gi3.38.0-2 ii python3-lxml 4.6.3+dfsg-0.1+deb11u1 ii python3-netifaces 0.10.9-0.2+b3 ii python3-notify2 0.3-4 ii python3-psutil5.8.0-1 ii python3-pychromecast 7.7.1-2 ii python3-pyroute2 0.5.14-2 ii python3-requests 2.25.1+dfsg-2 ii python3-setproctitle 1.2.1-1+b1 ii sox 14.4.2+git20190427-2 ii vorbis-tools 1.4.0-11+b1 Versions of packages pulseaudio-dlna recommends: ii ffmpeg 10:4.4-dmo4+deb11u5 ii gir1.2-rsvg-2.0 2.50.3+dfsg-1 pn gir1.2-rsvg-3.0 pn libav-tools ii python3-cairo1.16.2-4+b2 pulseaudio-dlna suggests no packages. -- no debconf information
Bug#1002010: find-completion: don't look for -exec etc command if completing before it
Package: bash-completion Version: 1:2.11-2 Hi, the same happens with Debian stable (bash-completion version 2.11-2). The same patch applies, cleanly, to that version too, and fixes the issue there as well. As the fix is that simple and prevents a rather annoying crash, I hope this could be pushed into stable. cheers, Frank Löffler
Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch
On Wed, Dec 16, 2020 at 06:27:21PM +0100, John Paul Adrian Glaubitz wrote: Here's a preliminary package for testing [1]. Let me know if that works for you. Hi, thanks for the package and sorry for the long wait. The new package (I used the one now already in backports) seems to work fine: the GUI starts up and the reader is recognized. thanks, Frank signature.asc Description: PGP signature
Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch
Hi, OK, I'll uploaded a patched 1.20.2 to backports then. I don't find a new version in backports. In case I didn't do something wrong and there is no new version yet: do you have a time estimate when you will be able to do so? I want to emphasize that all I want to know is whether it is better to wait for a new package to come soon anyway, or to try to rebuild it myself. Thanks for your work, especially also for providing a backport-package in the first place! Frank signature.asc Description: PGP signature
Bug#928037: mailcap(5): please document security considerations about %-escapes
Hi, On Fri, Nov 13, 2020 at 02:02:22AM +0100, Marriott NZ wrote: Thanks for your interest in the issue, Frank. Thanks for your interest, too. If run-mailcap is used by some mail program or script for mailcap support, then it's a vector for arbitrary command execution. Perhaps this deserves its own bug report. It very possibly might. Would you be interested in opening one? The information you have given here might be enough. As a consequence, it's impossible to force the use of, say emacs, for all text subtypes without explicitly enumerating them (generated rules can change anytime). This is a violation of the rfc, which states that "The configuration information will be obtained from the FIRST matching entry". Again, it would be nice to report that. In summary, mailcap is harmful. And I won't feel safe until I can get rid of it. I do agree that there are problems but I don't have the time or energy to implement a replacement. However, at least there must be a documented way how things should be implemented to be safe. Only then can we start to successfully file actual security-bugs against packages that don't follow that rule, and with that, open security leaks in their packages, but also others. We tried without documentation, and failed. This is what this bug here is about. Frank signature.asc Description: PGP signature
Bug#928037: resolution
Hi, can I please ping to get this resolved one way or another? At the moment, you either have one group of programs being insecure or another when both use the same mailcap entries, and both are pointing their fingers at the other (see blocked bug #950319), and arguments like "larger user base" start to appear in a security discussion. thanks, Frank Löffler signature.asc Description: PGP signature
Bug#939170: linux: does not suspend completely, locks up
On Sat, Mar 14, 2020 at 02:23:05PM +0100, Daniel M. wrote: On Sun, 26 Jan 2020 18:03:23 +0100 Felix Rublack wrote: Hi everyone, I have the same issue on a ThinkPad T460s (suspend works only half way, reboot and poweroff stop just short before actual shutdown). I bisected the problem to the TPM driver. Blacklisting the module in modprobe.d fixed the problem for me. Sample configuration: /etc/modprobe.d/blacklist-tpm.conf # Prevent TPM from loading. It breaks suspend and power cycle. blacklist tpm blacklist tpm_crb blacklist tpm_tis blacklist tpm_tis_core Greetings Felix Rublack Hi, thanks a lot! I can confirm that this works also on my Thinkpad E460. Since you can probably provide more details, could you forward this to kernel.org? Hi, just to add one tiny bit of confirmation: this helped also in my case (big thanks!): I am on Buster with a Lenovo Thinkpad T460, with kernels 4.19.0.8 and 5.4.0.0.bpo.4 installed. Suspend works fine with 4.19.0.8. The same system fails consistently when booted with 5.4, in the same way reported earlier: the system starts to suspend, but stops somewhere close to the finish line: display is black (don't remember if backlight was off, but I think it was), power-led is blinking, but the led-indicators like mute stay on. I cannot say something about the fan, as it is usually not running for me anyway. Nothing brings the laptop back at this stage other than pressing the power-button for like 10 seconds (complete restart): no shorter press of the power button, no lid action. Both should, and with the 4.19 kernel, do. With above blacklisting, suspend now also works for kernel version 5.4. Big thanks again - and it would be interesting to follow this at the kernel.org-level (to know when to remove the blacklist again). Frank Löffler signature.asc Description: PGP signature
Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command
Hi Rene, On Fri, Jan 31, 2020 at 05:28:58PM +0100, Rene Engelhard wrote: Using mutt, I created a new email, added an attachment with a file name containing spaces (a pptx file, thus libreoffice), and without sending no, MS Office. Which LibreOffice happens to be registered for. I know. What I meant is that this is the reason I submit this to the libreoffice package. Just that mutt is one thing. Maybe mutt does it correct, but unfortunately mutt users are not really the majority, people use thunderbird or evolution or so... For thunderbird I find, e.g.: message/rfc822; /usr/bin/thunderbird %s; test=test -n "$DISPLAY" text/calendar; /usr/bin/thunderbird %s; test=test -n "$DISPLAY" text/x-vcard; /usr/bin/thunderbird %s; test=test -n "$DISPLAY" firefox: text/html; /usr/bin/firefox-esr %s; description=HTML Text; test=test -n "$DISPLAY"; nametemplate=%s.html text/xml; /usr/bin/firefox-esr %s; description=XML Text; test=test -n "$DISPLAY"; nametemplate=%s.xml evolution: text/calendar; evolution -c tasks %s; test=test -n "$DISPLAY" text/x-vcard; evolution -c tasks %s; test=test -n "$DISPLAY" text/directory; evolution -c tasks %s; test=test -n "$DISPLAY" None of these tools use quotes. Searching through my /etc/mapcap, I find the vast majority not using quotes around %s, but some do, including libreoffice. It might be good to submit bugs to all of those, too. However, since I encountered this with libreoffice during regular work and the entries on my system are likely only a subset of the problematic ones, I'll leave it up to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928037 to care about a general solution. Whether another tool assumes the libreoffice mailcap entries containing quotes already would not make a difference though. If, supposedly, another tool does not quote filenames (assuming mailcap does that), then this would still be a security problem. Instead of "file; echo Hello" one would name the file "'file; echo Hello'" or similar. As mentioned, no amount of quoting in the mailcap is able to prevent shell escapes. This is why the replacing program must be the one doing this. Thus, if any tool using mailcap does not quote filenames properly and only relies on mailcap to do it for them, that would be a (security) bug within that tool. On the other hand, using quotes in the entry unfortunately breaks those tools that work the intended way. I agree that this is confusing. I commented on a related bug within mutt first, only later realizing that mutt actually does it the right way. #928037 contains thoughts about this, including links to other threads, that show the problem from a more or less neutral view. This is why #928037 exists: the RFC is rather unhelpful and other documentation does not really show users how those entries should be handled, right now. Greetings, and thanks for your quick response, Frank signature.asc Description: PGP signature
Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command
Package: libreoffice Version: 1:5.2.7-1+deb9u11 Severity: normal Dear Maintainer, * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? Using mutt, I created a new email, added an attachment with a file name containing spaces (a pptx file, thus libreoffice), and without sending the email yet, I tried to open that file from within mutt. * What was the outcome of this action? libreoffice opened, but complained about not finding files with each component of the filename containing spaces. Mutt used /etc/mailcap. I understand those are generated from the files DEBIAN/*.mime. Those lines look like this: application/rtf; soffice --nologo --writer '%s'; edit=soffice --nologo --writer '%s'; test=test -n "$DISPLAY"; description="Rich Text Format"; nametemplate=%s.rtf; priority=3 Note the quotes around the filename placeholder %s. What happened is that, as it should, mutt properly quoted whatever it was replacing %s with, in that case using single quote. So, in effect, the following command was executed: soffice --nologo --writer ''file with spaces'' And since '' is starting and immediately ending the quotation, libreoffice saw three arguments. * What outcome did you expect instead? The filename should have been given as one argument to libreoffice. Following #928037 and references therein, I believe that the correct solution is to not use '%s' in the mime files distributed with the Debian packages: it should just be a simple %s, no quotes. Quoting is the task of the program replacing %s. Also note, that while using quotes is likely due to security concerns, no amount of quoting can actually help here, as this very bug shows. I even believe that this is a security bug and should be fixed in stable and oldstable as well: using properly constructed filenames, commands can be injected when using these commands, due to undoing quotations done by the replacing program. Since these lines are commonly used to, e.g., display email attachments, this can be an easy way to gain access to a system just by having someone open an attachment marked to be handled by libreoffice. While this bug is submitted against oldstable, even current git includes the same definitions, e.g., see: https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/blob/master/libreoffice-writer.mime *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.11 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice depends on: ii dpkg 1.18.25 ii fonts-dejavu 2.37-1 ii libreoffice-avmedia-backend-gstreamer 1:5.2.7-1+deb9u11 ii libreoffice-base 1:5.2.7-1+deb9u11 ii libreoffice-calc 1:5.2.7-1+deb9u11 ii libreoffice-core 1:5.2.7-1+deb9u11 ii libreoffice-draw 1:5.2.7-1+deb9u11 ii libreoffice-impress1:5.2.7-1+deb9u11 ii libreoffice-java-common1:5.2.7-1+deb9u11 ii libreoffice-math 1:5.2.7-1+deb9u11 ii libreoffice-report-builder-bin 1:5.2.7-1+deb9u11 ii libreoffice-writer 1:5.2.7-1+deb9u11 ii python3-uno1:5.2.7-1+deb9u11 Versions of packages libreoffice recommends: ii fonts-crosextra-caladea 20130214-1 ii fonts-crosextra-carlito 20130920-1 ii fonts-linuxlibertine5.3.0-2 ii fonts-sil-gentium-basic 1.1-7 ii libreoffice-librelogo 1:5.2.7-1+deb9u11 ii libreoffice-nlpsolver 0.9+LibO5.2.7-1+deb9u11 ii libreoffice-ogltrans1:5.2.7-1+deb9u11 ii libreoffice-pdfimport 1:5.2.7-1+deb9u11 ii libreoffice-report-builder 1:5.2.7-1+deb9u11 ii libreoffice-script-provider-bsh 1:5.2.7-1+deb9u11 ii libreoffice-script-provider-js 1:5.2.7-1+deb9u11 ii libreoffice-script-provider-python 1:5.2.7-1+deb9u11 ii libreoffice-sdbc-postgresql 1:5.2.7-1+deb9u11 ii libreoffice-wiki-publisher 1.2.0+LibO5.2.7-1+deb9u11 Versions of packages libreoffice suggests: ii cups-bsd 2.2.1-8+deb9u4 ii default-jre [java5-runtime]2:1.8-58+deb9u1 ii gstreamer1.0-libav 1:1.10.4-dmo1 ii gstreamer1.0-plugins-bad 1:1.10.4-dmo2 ii gstreamer1.0-plugins-base 1.10.4-1+deb9u1 ii gstreamer1.0-plugins-good 1.10.4-1 ii gstreamer1.0-plugins-ugly
Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable
Hi, Being hit by this myself now, I am a bit surprised by the reaction can wait a little longer, for an issue that clearly breaks the Fortran interface and seems to be easily fixable. But this aside - is there a plan to get this into _any_ of the future point releases of stable? Frank signature.asc Description: Digital signature
Bug#721931:
Hi, Is it known (ideally by upstream) whether the OpenMP pragmas are correct, i.e. that there are no bugs when OpenMP is enabled? I agree with upstream that disabling OpenMP by not giving the relevant compiler flags is not a problem, but it is still strange to have pragmas but not to use them when compiling. Usually this points to either code in development or some bug in the OpenMP imlementation. In both cases disabling OpenMP via compiler flags is a quick way to avoid problems on user side, but it would be nice to know what upstreams reason to do this really is. Frank signature.asc Description: Digital signature
Bug#685832: xfce4-sensors-plugin: xcfe4-sensors-plugin relies on a setuid hddtemp and recommends to setuid it
Hi, Just to press this issue again: every new user of xfce on wheezy who is using the sensor-plugin gets that annoying message, at every login and whenever she/he opens the viewer. On top of that, the message gives a not recommended advice, thus the security tag. I don't know whether the proposed patch works, or is the best way to remedy this though. Please have a look at this patch. It would be nice to even get this into wheezy, maybe within a point release, later. thanks, Frank signature.asc Description: Digital signature
Bug#705186: [Python-modules-team] Bug#705186: importing numpy triggers RuntimeWarning
On Sat, Apr 13, 2013 at 09:18:36PM +0200, Sandro Tosi wrote: I think you have something broken on your machine, because I've just tested on a clean chroot and numpy imports fine (and if it was not, several other users would have complained so far). Maybe you have a custom installation of numpy or python interpreter? or have you altered in some way your system other than using Debian tools? I am not aware of changing anything by hand. In fact, this is an almost pristine wheezy installation. I could now work around the problem by purging python2.6-minimal (no idea why it was installed in the first place). I cannot check whether reinstalling would make the problem appear again, but should be able to later. Did you have both python-minimal packages installed? thanks, Frank signature.asc Description: Digital signature
Bug#705186: [Python-modules-team] Bug#705186: importing numpy triggers RuntimeWarning
On Sat, Apr 13, 2013 at 09:48:55PM +0200, Sandro Tosi wrote: On Sat, Apr 13, 2013 at 9:41 PM, Frank Loeffler kn...@cct.lsu.edu wrote: Did you have both python-minimal packages installed? Yes I have, both in the chroot and in my machine (which I use for developing) and I can't replicate on any of them. Interesting. I installed python2.6-minimal again. Noting a warning (not sure if related, so I post it here): Setting up python2.6 (2.6.8-1.1) ... Processing triggers for python-support ... /usr/lib/pymodules/python2.6/scitools/pyreport/main.py:268: SyntaxWarning: import * only allowed at module level def __call__(self, name, globals=None, locals=None, fromlist=None, /usr/lib/pymodules/python2.6/scitools/pyreport/main.py:285: SyntaxWarning: import * only allowed at module level def __call__(self, name, globals=None, locals=None, After this I get again: $ python Python 2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. import numpy /usr/lib/pymodules/python2.6/numpy/random/__init__.py:87: RuntimeWarning: compiletime version 2.6 of module 'mtrand' does not match runtime version 2.7 from mtrand import * Deinstalling python2.6-minimal makes this go away again. I attach a list of packages I have installed. What else could I do to help you reproducing this? thanks, Frank package_list.gz Description: Binary data signature.asc Description: Digital signature
Bug#705186: importing numpy triggers RuntimeWarning
Package: python-numpy Version: 1:1.6.2-1.2 Severity: Normal Importing numpy using python 2.7 produces: $ python Python 2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. import numpy /usr/lib/pymodules/python2.6/numpy/random/__init__.py:87: RuntimeWarning: compiletime version 2.6 of module 'mtrand' does not match runtime version 2.7 from mtrand import * I would expect no warning. Doing the same using 'python2.6' doesn't produce this warning. Both python2.6-minimal and python2.7-minimal are installed (Debian wheezy), along with python-numpy which provides mtrand for both python2.6 and python2.7: /usr/lib/pymodules/python2.6/numpy/random/mtrand.so /usr/lib/pymodules/python2.7/numpy/random/mtrand.so /usr/lib/pyshared/python2.6/numpy/random/mtrand.so /usr/lib/pyshared/python2.7/numpy/random/mtrand.so However, it looks to me that even within python2.7 parts of the python2.6 are used despite the corresponding parts for 2.7 being available (but that is a gues of mine). Frank signature.asc Description: Digital signature
Bug#704759: Enable lmetad when building lvm2
Package: lvm2 Version: 2.02.98-1 Severity: wishlist Hi, I have a setup with hot-plug drives with LVM on them and would like to have them automatically activated when plugged in. The way to achieve this, at least according to what I found on the web, is to make lvm aware of hotplug events, and the way to do that is to let it use information from lvmetad using 'use_lvmetad=1' in /etc/lvm/lvm.conf. This option is described even in the package for wheezy, but I didn't find 'lvmetad' in the lvm2 package. Looking at the source package in unstable I didn't find the corresponding '--enable-lvmetad' option to configure, and I found this in the Debian build log: checking whether to build LVMetaD... no I can understand why lvmetad might not be enabled by default. Is there a reason not to build it? (This is not rhetoric; I really like to know whether there is a reason not to build it.) Even if it is now too late to get anything like this into wheezy: it would be nice to have a patch which enables lvmetad so that someone can either build their own package easily or maybe even get it later from backports, should it enter there. thanks, Frank Loeffler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#282928: festival: female voice
Dear Peter, On Fri, Jun 01, 2012 at 02:41:19PM +1000, Peter Drysdale wrote: For Frank and Javier's benefit - I am an uploader for the festival package. Let me take this opportunity to thank you for your for on Debian. Without people like you I wouldn't have a lot of pleasant things I grew so accustomed to: Thanks! For a couple of years now flite in Debian has shipped a CLUSTERGEN voice of the well known slt female voice. Also, thank you for pointing me to flite. I just tried it and it worked like a charm. I will use it instead of festival from now on. I suggest that in this sense the feature required to close this bug has thus been satisfied by Debian for more than one year. I agree. Frank signature.asc Description: Digital signature
Bug#665876: merge - but still affecting squeeze
Hi
This is most likely a cause of #667985, which has been fixed in sid.
However, a similar bug also affects stable and can be fixed using a
similar simple patch:
- m@br'$SEARCH':.*a href=('$PROTO'://.*?)@i
+ m@br'$SEARCH':.*a.*?href=('$PROTO'://.*?)@i
Frank
signature.asc
Description: Digital signature
Bug#665876: not using html as source
Hi, What about parsing http://http.us.debian.org/debian/README.mirrors.txt for information about Debian mirrors instead of the HTML page? Frank signature.asc Description: Digital signature
Bug#610257: RFS: Dropbox
Hi, On Sat, Feb 19, 2011 at 02:24:36AM -0800, Vincent Cheng wrote: - fastpath.so: I have no idea what this library is, or what purpose it serves. The binary contains the string Fast ServerPath object for Dropbox, which indicates that this is some dropbox specific library. Frank (not a DD) pgpvf4EBOG5qd.pgp Description: PGP signature
Bug#444182: Squeeze please?
Hi, According to [1], squeeze will ship with the linux kernel 2.6.32. According to this bug report, this bug is only fixed in 2.6.33. Is there any possibility to get this fixed for squeeze? I am willing to help if somehow possible, just tell me how. I don't like the idea to have to (un-)patch my kernel for yet another Debian release cycle. Please, Frank Loeffler [1] http://lists.debian.org/debian-devel-announce/2010/03/msg5.html pgptRDnrtQtnm.pgp Description: PGP signature
Bug#444182: PATA support broken in ATA_PIIX
Hi, On Wed, Feb 03, 2010 at 03:24:48AM +, Ben Hutchings wrote: Having two drivers for the same PCI device id does not result in a race condition. udev + modprobe will load them both, in unspecified order. If I remember correctly, what people observed was that this order is not only not specified, it can actually change from one boot to another. I can understand why that has then been called 'race condition', in this sense. But it is also correct that this is somewhat milder than the classic race condition. This is what we are going to do for squeeze. Nice to read that. No more kernel patching for _that_ reason. Thanks! Frank Loeffler pgpMn1CYDYucV.pgp Description: PGP signature
Bug#559498: same here
Hi, I see the same on a Lenny box with only the minimal updates to get gtg installed: Replaced python-support 0.8.4lenny1 (using python-support_1.0.6_all.deb) I get the same error message. I found other bug reports mentioning the same error message (but for another packet), which relates this to a missing dependency on gtk+ 2.16: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543751 This would be bad news for Lenny-users however. I am not going to change the system that much for gtg. Is there any chance gtg could also work with gtk+ 2.12? Frank pgpBpEnL1oawV.pgp Description: PGP signature
Bug#555739: new upstream version (190.42, from 2009.10.27)
Package: nvidia-kernel-source Version: 185.18.36-2 Severity: wishlist There is a new upstream version (190.42), adding support for more GPUs and fixing several bugs. Thanks for your work, Frank Löffler pgpKumisq2ekg.pgp Description: PGP signature
Bug#282928: festival: female voice
Hi, On Sat, Oct 03, 2009 at 07:51:51AM +0200, Javier Serrano Polo wrote: El ds 03 de 10 de 2009 a les 09:44 +0530, en/na Kartik Mistry va escriure: Since we have couple of female voices now in Debian for mbrola, can we close this bug now? I thought we were talking about packages for the main category. Anyway, since I'm using a different festival version, I've got nothing to say about the debian packages. I agree to Javier here. It is unfortunate that a lot of voices are non-free, so I feel that the few that are free should be promoted by packaging them. Frank Loeffler pgpdvFOHm6GUW.pgp Description: PGP signature
Bug#542538: unmet dependency after pidgin update
Hi, After a recent security update, pidgin cannot be updated on amd64 because it depends on libstartup-notification0 (= 0.10) [amd64] which is not in lenny. For other architectures it depends on an older version which is in lenny. I write this to debian-secur...@lists.debian.org because of a suggestion [1] in a similar bug report about that pidgin update. I also CCed that other bug report in hope to get attention that way and to document publicly that this has ben reported. Please let me know if I should instead open another bug report. thanks for your work on Debian, Frank [1] http://lists.debian.org/debian-user/2009/08/msg01358.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537085: same problem here ...
Hi, this is to let you know that I seem to have the same problem. I recently updated from the current lenny kernel (2.6.26, self-compiled, but only with changes to one pata-driver), to the current version in sid (2.6.30, with the same change). Communication with my Garmin GPSMap 60csx was no problem with version 2.6.26 (using the lenny version of gpsbabel: 1.3.5-1.1), but it hangs with version 2.6.30. Going back to 2.6.26 solves this problem. Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522796: mixer-applet: uses 100% cpu after removal of soundcard
Package: gnome-applets Version: 2.22.3-3 Severity: normal Hi, when I remove a sound card from the system (usb, logitech webcam, micro) which was alsa device 0, but there is a second sound card (build-in, intel) alsa card 1 in the system, the mixer-applet starts to use 100% cpu. Killing and restarting the applet resolves the issue. After the removal, card 0 is not accessable and not usable, but card 1 still is and the number of usable cards is also still greater than 0, which might be unexpected for some code (just my guess). thanks, Frank -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.20080225 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-applets depends on: ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii gconf2 2.22.0-1 GNOME configuration database syste ii gnome-applets-data 2.22.3-3 Various applets for GNOME 2 panel ii gnome-icon-theme 2.22.0-1 GNOME Desktop icon theme ii gnome-panel2.20.3-5 launcher and docking facility for ii gstreamer0.10-alsa [gs 0.10.19-2 GStreamer plugin for ALSA ii gstreamer0.10-plugins- 0.10.8-4.1~lenny1 GStreamer plugins from the good ii libapm13.2.2-12 Library for interacting with APM d ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libbonoboui2-0 2.22.0-1 The Bonobo UI library ii libc6 2.7-18GNU C Library: Shared libraries ii libcpufreq0004-2 shared library to deal with the cp ii libdbus-1-31.2.1-5 simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1simple interprocess messaging syst ii libgconf2-42.22.0-1 GNOME configuration database syste ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.6-1+lenny1 The GLib library of C routines ii libgnome-desktop-2 2.22.3-2 Utility library for loading .deskt ii libgnome2-02.20.1.1-1The GNOME 2 library - runtime file ii libgnomekbd2 2.22.0-1 GNOME library to manage keyboard c ii libgnomekbdui2 2.22.0-1 User interface library for libgnom ii libgnomeui-0 2.20.1.1-2The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.22.0-5GNOME Virtual File System (runtime ii libgnomevfs2-extra 1:2.22.0-5GNOME Virtual File System (extra m ii libgstreamer-plugins-b 0.10.19-2 GStreamer libraries from the base ii libgstreamer0.10-0 0.10.19-3 Core GStreamer libraries and eleme ii libgtk2.0-02.12.11-4 The GTK+ graphical user interface ii libgtop2-7 2.22.3-1 gtop system monitoring library ii libgucharmap6 1:2.22.3-2Unicode browser widget library (sh ii libgweather1 2.22.3-1 GWeather shared library ii libhal10.5.11-8 Hardware Abstraction Layer - share ii libnotify1 [libnotify1 0.4.4-3 sends desktop notifications to a n ii liboobs-1-42.22.0-2 GObject based interface to system- ii libpanel-applet2-0 2.20.3-5 library for GNOME Panel applets ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libwnck22 2.22.3-1 Window Navigator Construction Kit ii libx11-6 2:1.1.5-2 X11 client-side library ii libxklavier12 3.5-2 X Keyboard Extension high-level AP ii libxml22.6.32.dfsg-5 GNOME XML library ii python 2.5.2-3 An interactive high-level object-o Versions of packages gnome-applets recommends: ii deskbar-applet2.22.3.1-1 universal search and navigation ba ii gnome-media 2.22.0-3 GNOME media utilities ii gnome-netstatus-applet2.12.1-2 Network status applet for GNOME 2 ii gnome-system-monitor 2.22.3-1 Process viewer and system resource ii python-gnome2 2.22.0-1 Python bindings for the GNOME desk Versions of packages gnome-applets suggests: ii acpid 1.0.8-1Utilities for using ACPI power man pn cpufreqd | cpudyn | powernowd none (no description available) pn tomboynone (no description available) -- debconf information: gnome-applets/cpufreq_SUID_bit: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517446: closed by Christian Marillat maril...@debian.org (Bug#517446: fixed in extace 1.9.9-6)
Hi, On Wed, Mar 04, 2009 at 03:51:19PM +, Debian Bug Tracking System wrote: It has been closed by Christian Marillat maril...@debian.org. Thanks :) Would this fix qualify for proposed-updates? Without it, extace is (can be?) pretty much unusable, which might render the bug critical. thanks for your time and work, Frank Loeffler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517999: RFS: gremind -- Simple reminder program for GNOME
Hi, I am not a Debian developer, but I have a comment and a question: On Wed, Mar 04, 2009 at 08:11:44PM +0100, Sebastian Krause wrote: * URL : http://perticone.homelinux.net/~sergio/c++/gremind/ That does not work for me, at least not at the moment. All I get is a timeout. gremind allows you to remind yourself of events and appointments and notifies you a single or several (periodic) times. How is gremind different from tkremind? tkremind is a tk frontend to 'remind'. 'remind' can do all sorts of reminders, holiday skips ect. while tkremind can pop up windows for timed reminders, play a sound and be iconified. Frank Loeffler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517446: extace: cannot connect to esd
Package: extace Version: 1.9.9-4 Severity: important I have esd running, playing music using it and other visualising packages are working using esd (e.g. synaesthesia). When I call 'extace' I get: Error, Cannot connect to input source!! PLease check settings in the options panel. However, the only option I have in the 'Choose Sound Source' of the options is 'esd' which is selected. Frank Loeffler -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.20080225 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages extace depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libesd-alsa0 [libesd0]0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfftw3-33.1.2-3.1 library for computing Fast Fourier ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio extace recommends no packages. extace 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#463833: Bug#419458: ata_piix and piix claim same pci ids
Hi, I am writing to you because you reported bug #419458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419458 cite Package: linux-image-2.6.20-1-686 Version: 2.6.20-1 Severity: grave Upon upgrading to this kernel, about 1/3rd of the time when I boot, the internal drive of my laptop becomes /dev/sda. The rest of the time, it remains /dev/hda. /cite As consequence of this, pata support for the ata_piix driver was disabled in the Debian kernels and still is by means of a patch to the Debian kernel sources. The piix driver is supposed to support that hardware alone in Debian. The problem now is that some hardware does not work with the piix driver or does not provide full functionality (hot swapping): bugs 444182 and 463833, now merged. As consequence of the patch, those users have to either (un)patch the Debian kernel after each package update or use upstream kernels. Both is not ideal and a solution should be found. Before we now all go and dig into the issue it would be interesting to know if the original bug is still present in recent kernels. The bug was reported for 2.6.22-4 and about one and a half year ago. Would it be possible for you to try to reproduce the bug with a recent upstream kernel or a recent Debian kernel which does not contain this patch? As far as I can see, both drivers still claim to support some identical ids. However, that should not be a problem. There are other examples of different drivers for identical hardware. The problem here seemed to be that the rule which driver gets assigned to the hardware (in case both drivers are compiled in) is not deterministic. I CCed the bug report to keep a record of this in the data base. I appologize if something in this email is not correct. Please correct me in that case. I am still in the stage of trying to fully understand the problem. thanks, Frank Loeffler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444182: pata disabled in ata_piix
Severity: important Hi, I was looking into the same hotswap issue and found to my surprise that the debian kernel has the needed support _removed in the kernel sources_. I found why this section was removed in the first place: because of bug #419458 - two drivers claim the same ids and there is a race as to which wins during boot, leading to different naming schemes of the devices. That bug should be fixed, but I think it is really going too far to remove the support of devices from some drivers in the source. The current situation forces Debian users to either patch the Debian kernels everytime there is an update and build their own packages - or to build upstream kernels. This in mind I think the patch might do good things on one side, but does more bad things on another side. Please consider to drop this patch and to allow for pata support in the piix driver. It would be very nice to have this in the next major lenny update, for lenny itself it is long too late now, sadly. I consider the severity of this bug to be important because it has a major effect on the usability of the package (in this case the ability to hotswap my hard drives / dvd drive; that is what the bay in those laptops is for in the first place) without rendering it completely unusable to everyone. thanks, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444182: pata disabled in ata_piix
Hi, On Wed, Feb 04, 2009 at 06:14:56PM +0100, Bastian Blank wrote: I was looking into the same hotswap issue and found to my surprise that the debian kernel has the needed support _removed in the kernel sources_. Supporting and not breaking thousands of machines is more important that supporting one. I agree with your statement. However, I am puzzled that you claim that this only affects one machine. This patch removes quite a lot of IDs, which already makes it a lot of machines, not only one and certainly not only mine. I agree that it would be best if removing this patch again would not cause harm to other users. Could we try to eliminate this problem instead of ignoring it? If I understood correctly, the situation is: - There are two drivers which claim to support the same hardware. This should be fine in general. - They implement this slitely differently (different device names). This should also be fine in general. - The main problem seems to be that the order at which those drivers are assigned to the hardware is not fixed / cannot be specified. (See bug #419458). Do I understand this correctly? If I dont, it would be very nice to give me a hint where I can find information about the reason why this patch is included. Assuming I got it right, the question is, how the assignement of drivers can be specified or at least be fixed (as in not changing), fixing bug #419458 without removing support for PATA from ata_piix. This patch was introduced in 2.6.20. Are you sure that the original problem is still present in 2.6.26 or later kernels? So a bug, but will not be fixed soon. Tagging correctly. Is there anything I could do to get it fixed? I assume upstream or at least other major linux distributions would have had the same problem and must have found a way around it? thanks, Frank Loeffler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502105: IDN
Hi, this message indicates a problem with your from adress. What is it set to? Did you change the error line Bad IDN in from: ...(username)..[at]tin.it in some way, because in the source the format would suggest Bad IDN in \%s\: '%s' Is it possible that, while the email adress is correct, another part of the 'from' has some locale problems? I ask because I stumbled over this report: http://marc.info/?l=mutt-usersm=108808505715260w=2 Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479805: protocol incompatibility
Hi, On Fri, Jul 25, 2008 at 03:24:20PM +0200, Paul Slootman wrote: could you try the 3.0.3-1 version currently in testing; or preferably the 3.0.3-2 version that was uploaded today, although that may not yet be availble for a couple of days (and not in testing for 10 days). I did not try any of the Debian packages, because the 3.0.? version was on the redhat-side, but that side did an update from 3.0.1 to 3.0.2 at some point. I now tried to reproduce the bug with the same Debian version and the same file and command. I did not succeed. From that I would guess that something was broken upstream in version 3.0.1 which got fixed in the redhat version of 3.0.2, which might already include the fix from upstream 3.0.3. thanks, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489389: patch for etch
Hi,
I was bitten by the same problem. I was trying to backport that package
like I did in the past. Maybe nvidia-glx should depend on a version of
xserver-xorg-core, which contains libwfb.so. That would not help in
backporting (on the contrary), but would avaid the late error while
doing so.
Is there no way to support both versions of xserver-xorg-core, like
depending on xerver-xorg-core and depending on its version installing
the lib or not?
On the other hand, I attach a small patch for the current version, which
made it work on etch for me.
Frank
diff -r -u
nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.postrm.in
nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.postrm.in
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.postrm.in
2008-07-23 10:48:26.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.postrm.in
2008-07-23 10:53:40.0 -0500
@@ -29,6 +29,7 @@
dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libglx.so.xlibmesa /usr/lib/xorg/modules/extensions/libglx.so
/dev/null
dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libGL.so.xlibmesa /usr/lib/libGL.so /dev/null
+ dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
rm -f /usr/lib/xorg/modules/extensions/libglx.so.#VERSION# 2 /dev/null
|| true
if [ -d /usr/lib/nvidia ]; then
rmdir /usr/lib/nvidia/ || true;
diff -r -u
nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.preinst
nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.preinst
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.preinst
2008-07-23 10:48:26.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.preinst
2008-07-23 10:51:27.0 -0500
@@ -94,7 +94,7 @@
dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libglx.so.xlibmesa /usr/lib/xorg/modules/extensions/libglx.so
/dev/null
dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libGL.so.xlibmesa /usr/lib/libGL.so /dev/null
-# dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
+ dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
;;
abort-upgrade)
diff -r -u nvidia-graphics-drivers-173.14.09.orig.orig/debian/rules
nvidia-graphics-drivers-173.14.09.orig/debian/rules
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/rules2008-07-23
10:48:25.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/rules 2008-07-23
10:54:24.0 -0500
@@ -184,7 +184,7 @@
install
$(dirname)/usr/X11R6/lib/modules/extensions/libglx.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/extensions/
-# install $(dirname)/usr/X11R6/lib/modules/libnvidia-wfb.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/
+ install $(dirname)/usr/X11R6/lib/modules/libnvidia-wfb.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/
install $(dirname)/usr/bin/tls_test
$(CURDIR)/debian/nvidia-glx/usr/lib/nvidia
install $(dirname)/usr/bin/tls_test_dso.so
$(CURDIR)/debian/nvidia-glx/usr/lib/nvidia
Bug#489389: improved patch for etch
I am sorry, the last patch was missing one change which creates a
symlink. For some reason that symlink was present on my test system
anyway, but it should really be created by the package. Here is the
complete patch.
Frank
diff -ru nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.links.in
nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.links.in
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.links.in
2008-07-23 10:48:26.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.links.in
2008-07-23 14:06:49.0 -0500
@@ -5,3 +5,4 @@
usr/lib/libXvMCNVIDIA.so.#VERSION# usr/lib/libXvMCNVIDIA.so.1
usr/lib/libXvMCNVIDIA.so.#VERSION# usr/lib/libXvMCNVIDIA_dynamic.so.1
usr/lib/libcuda.so.#VERSION# usr/lib/libcuda.so
+usr/lib/xorg/modules/libnvidia-wfb.so.#VERSION# usr/lib/xorg/modules/libwfb.so
diff -ru
nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.postrm.in
nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.postrm.in
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.postrm.in
2008-07-23 10:48:26.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.postrm.in
2008-07-23 14:06:30.0 -0500
@@ -29,6 +29,7 @@
dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libglx.so.xlibmesa /usr/lib/xorg/modules/extensions/libglx.so
/dev/null
dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libGL.so.xlibmesa /usr/lib/libGL.so /dev/null
+ dpkg-divert --remove --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
rm -f /usr/lib/xorg/modules/extensions/libglx.so.#VERSION# 2 /dev/null
|| true
if [ -d /usr/lib/nvidia ]; then
rmdir /usr/lib/nvidia/ || true;
diff -ru nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.preinst
nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.preinst
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/nvidia-glx.preinst
2008-07-23 10:48:26.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/nvidia-glx.preinst
2008-07-23 14:06:30.0 -0500
@@ -94,7 +94,7 @@
dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libglx.so.xlibmesa /usr/lib/xorg/modules/extensions/libglx.so
/dev/null
dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libGL.so.xlibmesa /usr/lib/libGL.so /dev/null
-# dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
+ dpkg-divert --add --rename --package nvidia-glx --divert
/usr/lib/nvidia/libwfb.so.xserver-xorg-core /usr/lib/xorg/modules/libwfb.so
/dev/null
;;
abort-upgrade)
diff -ru nvidia-graphics-drivers-173.14.09.orig.orig/debian/rules
nvidia-graphics-drivers-173.14.09.orig/debian/rules
--- nvidia-graphics-drivers-173.14.09.orig.orig/debian/rules2008-07-23
10:48:25.0 -0500
+++ nvidia-graphics-drivers-173.14.09.orig/debian/rules 2008-07-23
14:06:30.0 -0500
@@ -184,7 +184,7 @@
install
$(dirname)/usr/X11R6/lib/modules/extensions/libglx.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/extensions/
-# install $(dirname)/usr/X11R6/lib/modules/libnvidia-wfb.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/
+ install $(dirname)/usr/X11R6/lib/modules/libnvidia-wfb.so.${version}
$(CURDIR)/debian/nvidia-glx/usr/lib/xorg/modules/
install $(dirname)/usr/bin/tls_test
$(CURDIR)/debian/nvidia-glx/usr/lib/nvidia
install $(dirname)/usr/bin/tls_test_dso.so
$(CURDIR)/debian/nvidia-glx/usr/lib/nvidia
Bug#479805: protocol incompatibility
Package: rsync Version: 2.6.9-2etch2 When trying to copy a file (83GB) I get a protocol error. I also do get that error when I try to force a specific protocol (tried 29, 25 and 20). I am not sure if this is a Debian bug or not, so I file it first here. Please forward it upstream if that would be a better place. More information is below. thanks, Frank The command issued: [EMAIL PROTECTED]:/mnt/crypt/backups$ rsync -Pav numrel07.cct.lsu.edu:/local_data/backups/sissa_disc.tar.bz2 . receiving file list ... 1 file to consider Invalid block length 297848 [sender] rsync error: protocol incompatibility (code 2) at io.c(1367) [sender=3.0.1] rsync: connection unexpectedly closed (97 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(453) [receiver=2.6.9] rsync: connection unexpectedly closed (97 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(453) [generator=2.6.9] On the side executing the command (Debian Etch): [EMAIL PROTECTED]:~$ rsync --version rsync version 2.6.9 protocol version 29 Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others. http://rsync.samba.org/ Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, inplace, IPv6, ACLs, 64-bit system inums, 64-bit internal inums rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. On the remote side (Fedora Core 5): [EMAIL PROTECTED] ~]$ rsync --version rsync version 3.0.1 protocol version 30 Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, no symtimes rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. [EMAIL PROTECTED] ~]$ rpm -aq | grep rsync rsync-2.6.9-2.fc5 The same rsync command as the first, but a lot more verbose: [EMAIL PROTECTED]:/mnt/crypt/backups$ rsync -Pa numrel07.cct.lsu.edu:/local_data/backups/sissa_disc.tar.bz2 . cmd= machine=numrel07.cct.lsu.edu user= path=/local_data/backups/sissa_disc.tar.bz2 cmd[0]=ssh cmd[1]=numrel07.cct.lsu.edu cmd[2]=rsync cmd[3]=--server cmd[4]=--sender cmd[5]=-logDtpr cmd[6]=. cmd[7]=/local_data/backups/sissa_disc.tar.bz2 opening connection using ssh numrel07.cct.lsu.edu rsync --server --sender -logDtpr . /local_data/backups/sissa_disc.tar.bz2 FILE_STRUCT_LEN=24, EXTRA_LEN=4 (Server) Protocol versions: remote=29, negotiated=29 (Client) Protocol versions: remote=30, negotiated=29 note: iconv_open(UTF-8, UTF-8) succeeded. receiving file list ... server_sender starting pid=15277 [sender] change_dir(/local_data/backups) [sender] make_file(sissa_disc.tar.bz2,*,2) recv_file_name(sissa_disc.tar.bz2) received 1 names 1 file to consider uid 1380(knarf) maps to 1000 process has 9 gids: 20 24 25 29 44 46 108 110 1000 gid 1000(internalusers) maps to 1000 [receiver] i=0 1 sissa_disc.tar.bz2 mode=0100644 len=88714954661 gid=1000 flags=0 recv_file_list done get_local_name count=1 . recv_files(1) starting [sender] flist start=0, used=1, low=0, high=0 [sender] i=0 /local_data/backups sissa_disc.tar.bz2 mode=0100644 len=88714954661 uid=1380 gid=1000 flags=201 send_file_list done send_files starting generator starting pid=6683 count=1 delta-transmission enabled recv_generator(sissa_disc.tar.bz2,0) gen mapped sissa_disc.tar.bz2 of size 88714954661 generating and sending sums for 0 count=297854 rem=34317 blength=297848 s2length=5 flength=88714954661 chunk[0] offset=0 len=297848 sum1=e8c1b203 chunk[1] offset=297848 len=297848 sum1=2b8cee9b chunk[2] offset=595696 len=297848 sum1=8a553954 chunk[3] offset=893544 len=297848 sum1=1176e520 chunk[4] offset=1191392 len=297848 sum1=61968216 chunk[5] offset=1489240 len=297848 sum1=4df6e16d chunk[6] offset=1787088 len=297848 sum1=8e5eed84 chunk[7] offset=2084936 len=297848 sum1=05d8ce7c chunk[8] offset=2382784 len=297848 sum1=84e4da72 chunk[9] offset=2680632 len=297848 sum1=1e37bd24 chunk[10] offset=2978480 len=297848 sum1=7cbd8759 chunk[11] offset=3276328 len=297848 sum1=731787a0 chunk[12] offset=3574176 len=297848 sum1=30e587cf chunk[13] offset=3872024 len=297848 sum1=4af6971d chunk[14] offset=4169872 len=297848 sum1=25d71a2e chunk[15] offset=4467720 len=297848 sum1=cc0afba1 chunk[16] offset=4765568 len=297848 sum1=5a9508d3 chunk[17] offset=5063416 len=297848 sum1=ab31e26e chunk[18] offset=5361264 len=297848 sum1=a7ae2d22 chunk[19] offset=5659112 len=297848 sum1=42a6a1c3 chunk[20] offset=5956960 len=297848 sum1=8ac20a01 chunk[21] offset=6254808 len=297848 sum1=803f3aff
Bug#479805: Acknowledgement (protocol incompatibility)
Hi, I just noticed that the rsync version on the remote site is not the one using the rpm package as shown in the original bug report (rsync-2.6.9-2.fc5), but indeed rsync-3.0.1, as shown in the log of the copy process. Sorry for the confusion. Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372499: find: result depends of locales
But shouldn't *.mp3 match to any file ending in .mp3 no matter what the characters in front are and whether they are encoded correctly or not? Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394150: Please mention '--args' in manpage
Package: gdb Version: 6.3-6 Severity: wishlist gdb supports the '--args' option to pass arguments to the to be run program from the command line of 'gdb'. This is a very usefull option and should be mentioned in the man page. thanks, Frank Loeffler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#266779: time for green tea
Well, 450s is ok I think, given that you should throw the first extraction away and only drink the second and maybe third. At least that is how the Chinese people (that I know) are doing it, and I trust them here. On the other hand, they leave the leafes in the cup, so a time for the tea is almost impossible to define. Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291274: sarge
Hi, while this bug may really affect kernel 2.4.29, this kernel version is AFAIK not in sarge, but this bug is preventing openswan from entering sarge. It would be nice to consider to lower the severity for this reason (or tagging 'sid' if that helps). On the other hand this bug does not make the package unusable completely in my view, so the severity might too high anyway. thanks, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
