Bug#748366: 2048-qt: Segfaults on startup
Package: 2048-qt Followup-For: Bug #748366 Since that 5 years old bug report was for Jessie when it was still in Debian unstable, and for an early version that never was shipped in Jessie/stable, I suggest to close that bug repport as it is unlikely to still be relevant in Debian oldstable (if the bug really was in 2048-qt at all). Have a nice day. Simon Valiquette -- System Information: Debian Release: 9.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages 2048-qt depends on: ii libc62.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libqt5core5a 5.7.1+dfsg-3+deb9u1 ii libqt5gui5 5.7.1+dfsg-3+deb9u1 ii libqt5network5 5.7.1+dfsg-3+deb9u1 ii libqt5qml5 5.7.1-2+b2 ii libqt5quick5 5.7.1-2+b2 ii libqt5widgets5 5.7.1+dfsg-3+deb9u1 ii libstdc++6 6.3.0-18+deb9u1 ii qml-module-qtquick-controls 5.7.1~20161021-2 ii qml-module-qtquick-dialogs 5.7.1~20161021-2 2048-qt recommends no packages. 2048-qt suggests no packages. -- debconf-show failed
Bug#913604: Please downgrade [Lack of login storage API]
Package: firefox-esr Version: 60.3.0esr-1~deb9u1 Followup-For: Bug #913604 Bernie Elbourn wrote: > Hello, > > I am not maintainer. Just regular "Joe" trying to get to grips with why > firefox updates have stopped due to apt-listbugs. > > I have sympathy with the sentiment .. > > "By implementing the nsiLoginStorage API, this lets the users choose a > single password manager they want to use and integrate it with Firefox." > >.. may I gently suggest it is not really a serious Debian bug. These are: While I understand your point, my understanding is that it is a regression after Debian Stable (Stretch) was released and that is worked at least in Firefox 56. A feature regression within Debian Stable usually shouldn't be marked only as 'wishlist' or 'minor', especially if no workaround is provided. Unless of course it was already broken when Debian Stable was released, in which case 'serious' is way too high, but I don't think so. It would be interesting to know in which version exactly it stoped working, as if it only stopped from version 60.3.0esr-1~deb9u1, then it should definitely be tagged as a security-upgrade regression. At least the current bug level will make it noticed for Buster and give an opportunity to provide at least another way to provide a similar feature, an perhaps even an upgrade path from Debian-oldstable (Jessie). That said, I wouldn't be against downgrading it to important, especially as this regression don't seems to be written in the changelog (as required in the Debian Policy if done on purpose or knowingly). But having it at an higher level than 'normal' is necessary IMHO if it is a Debian-stable regression (a problem that was far less common when maintaining of the original version was still possible). Have a nice day, Simon Valiquette -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.5 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#908623: ieee-data: URL to download updated IEEE OUI data is not available anymore.
Package: ieee-data Version: 20160613.1 Severity: normal Hello, update-ieee-data tries to download the newest version of the Organizationally Unique Identifier (OUI) from: http://standards.ieee.org/regauth/oui/oui.txt while it has moved to the following URL (I included the other ones): http://standards-oui.ieee.org/oui/oui.txt http://standards-oui.ieee.org/oui28/mam.txt http://standards-oui.ieee.org/oui36/oui36.txt http://standards-oui.ieee.org/iab/iab.txt Likewise, the URL in the package description is also broken: http://standards.ieee.org/regauth/oui/index.shtml I am not sure if it is the appropriate one, but that link seems a reasonable choice both for the man page and the package description: https://standards.ieee.org/products-services/regauth/index.html The URL in the man page also need to be updated. Have a nice day, Simon Valiquette -- System Information: Debian Release: 9.5 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-7-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ieee-data depends on: ii curl 7.52.1-5+deb9u6 ii libwww-perl 6.15-1 ii wget 1.18-5+deb9u2 ieee-data recommends no packages. ieee-data suggests no packages. -- debconf-show failed
Bug#881000: uuid command fail to use the real MAC address
Package: uuid Followup-For: Bug #881000 Control: tags -1 + moreinfo Hello, I was reading your bugreport about uuid, and wondered if it wasn't simply that you didn't notice that in your example, the MAC address was actually used and was at the end of the UUID, as expected. If so, then please close this bug report as this is the expected behavior AFAIK. If you do the following command many times, you will notice that the end of the UUID is always indeed a MAC address and not a random value: $ uuid -v 1 Now, if the MAC address at the end of the UUID isn't the same as any of your network interface, then there would indeed be a problem. I can't check as you didn't provide the output of /sbin/ifconfig, and also didn't also provide the UUID you expected to see, but I doubt that there is any bug here and that you simply misunderstood something. Have a nice day, Simon Valiquette
Bug#861856: oping: CSV output uses locale decimal separator
Package: oping Followup-For: Bug #861856 > When running noping -O foo.csv 127.0.0.1, I get file output like: > > 1493922621,709,"127.0.0.1",11,28 > > This is somewhat unfortunate, since it's not really comma separated > values any more. > >(My locale has «,» as its decimal separator.) I am not sure what exactly you consider to be a bug, as you didn't show an example of what you expected instead. If it is about the IP, I must remind you that this is NOT a decimal number, and thus dots are always used (I am not aware of any language that enforce a different typographical convention that would be here technicaly wrong). AFAIK, it is fully compliant with RFC-4180 and others. https://tools.ietf.org/html/rfc4180 My 2nd guess is that you were not aware that you can enclose with a '"' character the start and the end of any field, even when not strictly required. But doing so here is a good idea, as I can imagine securities issues in some extreme case, perhaps with some unicode domain names or bogus ones (passed fake domains names that include comas or \n) so as to exploit scripts that didn't properly sanitized their parameters. I think I will mark this as WONTFIX, as "fixing" it is likely to break many scripts that expect those quotes to always be included, and the current behaviour make sure that scripts are aware that they could have to handle special strings and characters (it is also much easier that way). And so I suggest that you or the maintainer simply close this bug. Have a nice day, Simon Valiquette -- System Information: Debian Release: 9.5 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-6-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages oping depends on: ii libc6 2.24-11+deb9u3 ii libncursesw5 6.0+20161126-1+deb9u2 ii liboping0 1.9.0-1+b1 ii libtinfo5 6.0+20161126-1+deb9u2 oping recommends no packages. oping suggests no packages. -- debconf-show failed
Bug#504768: lv: grandchild lv breaks terminal emulator when terminated
Package: lv Version: 4.51-3 Followup-For: Bug #504768 Sorry if a previous garbage message is accepted: I tried to make reportbug send an archived message in /tmp/, but that didn't worked as expected (possibly because it was encoded in base64). So, this bug seems to still be in Debian stable and probably is more likely to happens when /etc/alternatives/pager is linked to /usr/bin/lv What is very annoying and confusing, is that at first there is no clear reason why the string "(END):" appears instead of the prompt line, and that you also don't see what you are typing even if commands does work. So almost all line start with this: (END): This prompt disappear once you kill the pager process (and then everything seems to goes back to normal). For example, killing sh (whose parent terminated and is now init) won't change anything, same for sensible-pager, but "kill 21151" (the lv pager) makes everything goes back to normal: ~> pstree -pl | fgrep sensible-pager |-sh(21149)---sensible-pager(21150)---pager(21151) Note that the parent of process 21149 is now the process 1, which happens in some situation when the calling app abnormaly terminated (ironically, it my case it was querybts and then reportbug that crashed). For clarity in reporducing it, here are my settings for the default pager: ~> update-alternatives --config pager [5:42:05pm] Il existe 6 choix pour l'alternative pager (qui fournit /usr/bin/pager). SélectionChemin Priorité État 0/bin/less77mode automatique 1/bin/less77mode manuel 2/bin/more50mode manuel * 3/usr/bin/lv 55mode manuel 4/usr/bin/most60mode manuel 5/usr/bin/pg 10mode manuel 6/usr/bin/w3m 25mode manuel My understanding is that lv should have terminated on its own, and that there is some signals that are not always properly handled by "pager" (which really is /usr/bin/lv), as when it happens "pager" often start to use almost all the CPU. I can get the same behaviour from bash or tcsh, so at first I tough it didn't matter at all, but when trying with dash as reported, the terminal indeed get way more confused for some reason, and killing lv is not enough and is needed so as to be able to use the terminal again. Have a nice day, Simon Valiquette -- System Information: Debian Release: 9.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-6-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lv depends on: ii libc6 2.24-11+deb9u3 ii libtinfo5 6.0+20161126-1+deb9u2 Versions of packages lv recommends: ii bzip2 1.0.6-8.1 ii xz-utils 5.2.2-1.2+b1 lv suggests no packages.
Bug#504768: lv: grandchild lv breaks terminal emulator when terminated
Package: lv Version: 4.51-3 Followup-For: Bug #504768 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: Simon Valiquette To: Debian Bug Tracking System <504...@bugs.debian.org> Subject: Re: lv: grandchild lv breaks terminal emulator when terminated Bcc: Simon Valiquette UGFja2FnZTogbHYKVmVyc2lvbjogNC41MS0zCkZvbGxvd3VwLUZvcjogQnVnICM1MDQ3NjgKCkp1 c3Qgc2F5aW5nIHRoYXQgdGhpcyBidWcgc2VlbXMgdG8gc3RpbGwgYmUgaW4gRGViaWFuIHN0YWJs ZSBhbmQgaXMgbW9yZQpsaWtlbHkgdG8gaGFwcGVucyB3aGVuIC9ldGMvYWx0ZXJuYXRpdmVzL3Bh Z2VyIGlzIGxpbmtlZCB0byAvdXNyL2Jpbi9sdgoKV2hhdCBpcyB2ZXJ5IGFubm95aW5nIGFuZCBj b25mdXNpbmcsIGlzIHRoYXQgYXMgcmVwb3J0ZWQgeW91IGRvbid0IHNlZQp3aGF0IHlvdSBhcmUg dHlwaW5nLCBtb3N0IGxpbmVzIHN0YXJ0IHdpdGggdGhpczoKCihFTkQpOgoKVGhpcyBwcm9tcHQg b25seSBkaXNhcHBlYXIgb25jZSB5b3Uga2lsbCB0aGUgcGFnZXIgcHJvY2VzcyAoYW5kIHRoZW4K ZXZlcnl0aGluZyBzZWVtcyB0byBnb2VzIGJhY2sgdG8gbm9ybWFsKS4KCkZvciBleGFtcGxlIChv dXRwdXQgZnJvbSBwc3RyZWUgLXBsKSwga2lsbGluZyBzaCAod2hvc2UgcGFyZW50IGlzIG5vdyBp bml0KQp3b24ndCBjaGFuZ2UgYW55dGhpbmcsIHNhbWUgZm9yIHNlbnNpYmxlLXBhZ2VyLCBidXQg ImtpbGwgMjExNTEiIG1ha2UKZXZlcnl0aGluZyBnb2VzIGJhY2sgdG8gbm9ybWFsOgoKfj4gcHN0 cmVlIC1wbCB8IGZncmVwIHNlbnNpYmxlLXBhZ2VyCiAgIHwtc2goMjExNDkpLS0tc2Vuc2libGUt cGFnZXIoMjExNTApLS0tcGFnZXIoMjExNTEpCgoKTm90ZSB0aGF0IHRoZSBwYXJlbnQgb2YgcHJv Y2VzcyAyMTE0OSBpcyBub3cgdGhlIHByb2Nlc3MgMSwgd2hpY2ggaGFwcGVucwppbiBzb21lIHNp dHVhdGlvbiB3aGVuIHRoZSBjYWxsaW5nIGFwcCBhYm5vcm1hbHkgdGVybWluYXRlZCAoaXJvbmlj YWxseQpoZXJlIGl0IHdhcyBxdWVyeWJ0cyBhbmQgcmVwb3J0YnVnLgoKRm9yIGNsYXJpdHkgaW4g cmVwb3JkdWNpbmcgaXQsIGhlcmUgYXJlIG15IHNldHRpbmdzIGZvciB0aGUgZGVmYXVsdCBwYWdl cjoKCn4+IHVwZGF0ZS1hbHRlcm5hdGl2ZXMgLS1jb25maWcgcGFnZXIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzU6NDI6 MDVwbV0KSWwgZXhpc3RlIDYgY2hvaXggcG91ciBsJ2FsdGVybmF0aXZlIHBhZ2VyIChxdWkgZm91 cm5pdCAvdXNyL2Jpbi9wYWdlcikuCgogIFPDqWxlY3Rpb24gICAgQ2hlbWluICAgICAgICAgIFBy aW9yaXTDqSAgIMOJdGF0Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQogIDAgICAgICAgICAgICAvYmluL2xlc3MgICAgICAgIDc3ICAg ICAgICBtb2RlIGF1dG9tYXRpcXVlCiAgMSAgICAgICAgICAgIC9iaW4vbGVzcyAgICAgICAgNzcg ICAgICAgIG1vZGUgbWFudWVsCiAgMiAgICAgICAgICAgIC9iaW4vbW9yZSAgICAgICAgNTAgICAg ICAgIG1vZGUgbWFudWVsCiogMyAgICAgICAgICAgIC91c3IvYmluL2x2ICAgICAgNTUgICAgICAg IG1vZGUgbWFudWVsCiAgNCAgICAgICAgICAgIC91c3IvYmluL21vc3QgICAgNjAgICAgICAgIG1v ZGUgbWFudWVsCiAgNSAgICAgICAgICAgIC91c3IvYmluL3BnICAgICAgMTAgICAgICAgIG1vZGUg bWFudWVsCiAgNiAgICAgICAgICAgIC91c3IvYmluL3czbSAgICAgMjUgICAgICAgIG1vZGUgbWFu dWVsCgoKTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGx2IHNob3VsZCBoYXZlIHRlcm1pbmF0ZWQg b24gaXRzIG93biwgYW5kIHRoYXQKdGhlcmUgaXMgc29tZSBzaWduYWxzIHRoYXQgYXJlIG5vdCBh bHdheXMgcHJvcGVybHkgaGFuZGxlZCBieSAicGFnZXIiCih3aGljaCByZWFsbHkgaXMgL3Vzci9i aW4vbHYpLCBhcyB3aGVuIGl0IGhhcHBlbnMgaXQgb2Z0ZW4gc3RhcnQgdG8KdXNlIGFsbW9zdCBh bGwgdGhlIENQVS4KCkkgY2FuIGdldCB0aGUgc2FtZSBiZWhhdmlvdXIgZnJvbSBiYXNoIG9yIHRj c2gsIHNvIHRoYXQgY2VydGFpbmx5IGRvbid0Cm1hdHRlciBhdCBhbGwgKHRvdWdoIEkgZGlkbid0 IHRyeSB0byByZXByb2R1Y2UgZGlyZWN0bHkgZnJvbSBkYXNoKS4KCkhhdmUgYSBuaWNlIGRheSwK ClNpbW9uIFZhbGlxdWV0dGUKCgoKLS0gU3lzdGVtIEluZm9ybWF0aW9uOgpEZWJpYW4gUmVsZWFz ZTogOS40CiAgQVBUIHByZWZlcnMgc3RhYmxlLWRlYnVnCiAgQVBUIHBvbGljeTogKDUwMCwgJ3N0 YWJsZS1kZWJ1ZycpLCAoNTAwLCAnc3RhYmxlJykKQXJjaGl0ZWN0dXJlOiBpMzg2IChpNjg2KQoK S2VybmVsOiBMaW51eCA0LjkuMC02LTY4Ni1wYWUgKFNNUCB3LzIgQ1BVIGNvcmVzKQpMb2NhbGU6 IExBTkc9ZnJfQ0EsIExDX0NUWVBFPWZyX0NBIChjaGFybWFwPUlTTy04ODU5LTEpLCBMQU5HVUFH RT1mcl9DQSAoY2hhcm1hcD1JU08tODg1OS0xKQpTaGVsbDogL2Jpbi9zaCBsaW5rZWQgdG8gL2Jp bi9kYXNoCkluaXQ6IHN5c3Zpbml0ICh2aWEgL3NiaW4vaW5pdCkKClZlcnNpb25zIG9mIHBhY2th Z2VzIGx2IGRlcGVuZHMgb246CmlpICBsaWJjNiAgICAgIDIuMjQtMTErZGViOXUzCmlpICBsaWJ0 aW5mbzUgIDYuMCsyMDE2MTEyNi0xK2RlYjl1MgoKVmVyc2lvbnMgb2YgcGFja2FnZXMgbHYgcmVj b21tZW5kczoKaWkgIGJ6aXAyICAgICAxLjAuNi04LjEKaWkgIHh6LXV0aWxzICA1LjIuMi0xLjIr YjEKCmx2IHN1Z2dlc3RzIG5vIHBhY2thZ2VzLgo= -- System Information: Debian Release: 9.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-6-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lv depends on: ii libc6 2.24-11+deb9u3 ii libtinfo5 6.0+20161126-1+deb9u2 Versions of packages lv recommends: ii bzip2 1.0.6-8.1 ii xz-utils 5.2.2-1.2+b1 lv suggests no packages. -- debconf-show failed
Bug#793186: freeipmi-ipmiseld: missing '/var/cache/ipmiseld/' directory in package freeipmi-ipmiseld
Package: freeipmi-ipmiseld
Version: 1.4.5-3
Severity: normal
Tags: patch
Hello,
Apparently the installation script for freeipmi-ipmiseld doesn't create the
/var/cache/ipmiseld directory and the daemon then give this error:
/usr/sbin/ipmiseld[24740]: Error creating SDR cache
'/var/cache/ipmiseld//ipmiseldsdrcache.localhost': filename invalid
I fixed it by manually creating /var/cache/ipmiseld, the default location
specified in the man page, but I think that it is a Debian Policy violation not
to create it at package installation.
Also notice the double // in the error message. I am not sure if it is
linked, but there is many similar situations in many man pages like
freeipmi.conf freeipmi_interpret_sensor.conf ipmi-sensors ipmi-sel or
ipmiseld.conf where we see things like this:
/etc/freeipmi//freeipmi_interpret_sensor.conf
I included a patch that should fix the error (I didn't tested it) but not the
man pages (it is certainly something just as trivial).
Thank you and have a nice day.
Simon Valiquette
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages freeipmi-ipmiseld depends on:
ii dpkg 1.17.25
ii freeipmi-common 1.4.5-3
ii libc62.19-18
ii libfreeipmi161.4.5-3
ii libgcrypt20 1.6.3-2
ii sysvinit-utils 2.88dsf-59
freeipmi-ipmiseld recommends no packages.
freeipmi-ipmiseld suggests no packages.
-- no debconf information
diff -ru freeipmi-1.4.5.orig/config/ac_ipmiseld_cache_dir.m4 freeipmi-1.4.5/config/ac_ipmiseld_cache_dir.m4
--- freeipmi-1.4.5.orig/config/ac_ipmiseld_cache_dir.m4 2012-07-10 19:30:57.0 -0400
+++ freeipmi-1.4.5/config/ac_ipmiseld_cache_dir.m4 2015-07-22 01:15:36.765621835 -0400
@@ -5,7 +5,7 @@
AC_DEFUN([AC_IPMISELD_CACHE_DIRECTORY],
[
# Must expand nested unquoting
- IPMISELD_CACHE_DIRECTORY_TMP1=`eval echo ${localstatedir}/cache/ipmiseld/`
+ IPMISELD_CACHE_DIRECTORY_TMP1=`eval echo ${localstatedir}/cache/ipmiseld`
IPMISELD_CACHE_DIRECTORY_TMP2=`echo $IPMISELD_CACHE_DIRECTORY_TMP1 | sed 's/^NONE/$ac_default_prefix/'`
IPMISELD_CACHE_DIRECTORY=`eval echo $IPMISELD_CACHE_DIRECTORY_TMP2`
diff -ru freeipmi-1.4.5.orig/configure freeipmi-1.4.5/configure
--- freeipmi-1.4.5.orig/configure 2014-07-28 13:52:12.0 -0400
+++ freeipmi-1.4.5/configure 2015-07-22 01:55:16.750606800 -0400
@@ -19080,7 +19080,7 @@
# Must expand nested unquoting
- IPMISELD_CACHE_DIRECTORY_TMP1=`eval echo ${localstatedir}/cache/ipmiseld/`
+ IPMISELD_CACHE_DIRECTORY_TMP1=`eval echo ${localstatedir}/cache/ipmiseld`
IPMISELD_CACHE_DIRECTORY_TMP2=`echo $IPMISELD_CACHE_DIRECTORY_TMP1 | sed 's/^NONE/$ac_default_prefix/'`
IPMISELD_CACHE_DIRECTORY=`eval echo $IPMISELD_CACHE_DIRECTORY_TMP2`
diff -ru freeipmi-1.4.5.orig/debian/freeipmi-ipmiseld.install freeipmi-1.4.5/debian/freeipmi-ipmiseld.install
--- freeipmi-1.4.5.orig/debian/freeipmi-ipmiseld.install 2014-10-08 10:15:52.0 -0400
+++ freeipmi-1.4.5/debian/freeipmi-ipmiseld.install 2015-07-22 02:38:23.498457812 -0400
@@ -1,4 +1,5 @@
usr/sbin/ipmiseld
+var/cache/ipmiseld
usr/share/man/man5/ipmiseld.conf.5
usr/share/man/man8/ipmiseld.8
etc/freeipmi/ipmiseld.conf
Bug#676674: gconf-editor: Crash when searching a key
Package: gconf-editor
Version: 3.0.1-1
Followup-For: Bug #676674
I don't know why it haven't been fixed yet, but Ubuntu fixed this bug
many months ago and upstream seems to have fixed it as described here:
https://bugzilla.gnome.org/show_bug.cgi?id=670586
I have applied the following patch from upstream to the Debian source
paquage and I can't make gconf-editor crash anymore.
Simon Valiquette.
From f82dcfe99dafc9b6eac331bcf22662c9254f8a40 Mon Sep 17 00:00:00 2001
From: Edward Sheldrake ejsheldr...@gmail.com
Date: Wed, 11 Apr 2012 08:27:16 +0100
Subject: [PATCH] Fix assertion failed crash
Fix assertion failed: (last_slash != NULL) crash while navigating the
left tree view, fixed by having the model for the right list view emit
all the row deleted signals before deleting any of its data.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=670586
---
src/gconf-list-model.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gconf-list-model.c b/src/gconf-list-model.c
index 27e1af6..4fc60f8 100644
--- a/src/gconf-list-model.c
+++ b/src/gconf-list-model.c
@@ -133,11 +133,14 @@ gconf_list_model_set_root_path (GConfListModel *model,
const gchar *root_path)
if (model-root_path != NULL) {
for (list = model-values; list; list = list-next) {
+ model-stamp++;
+ gtk_tree_model_row_deleted (GTK_TREE_MODEL (model),
path);
+ }
+
+ for (list = model-values; list; list = list-next) {
GConfEntry *entry = list-data;
g_hash_table_remove (model-key_hash,
gconf_entry_get_key (entry));
- model-stamp++;
- gtk_tree_model_row_deleted (GTK_TREE_MODEL (model),
path);
gconf_entry_unref (entry);
}
--
1.7.9.6
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages gconf-editor depends on:
ii gconf-defaults-service 3.2.5-1+build1
ii gconf2 3.2.5-1+build1
ii libc6 2.13-35
ii libgconf2-4 3.2.5-1+build1
ii libglib2.0-02.32.3-1
ii libgtk-3-0 3.4.2-3
ii libpango1.0-0 1.30.0-1
ii policykit-1-gnome 0.105-2
gconf-editor recommends no packages.
gconf-editor 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#676674: gconf-editor: Crash when searching a key
tags 676674 + patch quit I am not sure why reportbug didn't included the 'patch' tag even if I told it to add it. Anyway, I am adding it manually here. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688025: roxterm-gtk3: Double-clicking a URI should override Select-by-word setting
Tony Houghton un jour écrivit: The double-click handler doesn't have any special code to recognise URLs. It uses the Select-by-word profile option, so you could add : to that, but you may need to add further characters for some other URLs. To get proper URL recognition you have to either ctrl-single-click to open it in a browser or right-click and use the Open... or Copy... menu items. I know, and I appreciate this feature. But when I select an URL from one console to paste it in vim, it is not as fast and as convenient as with gnome-terminal, and I use vim a lot. I think it would be a good idea to have double-click select the whole URL in a future version though, so I'll keep this bug open but change the priority. OK. At least this difference in behaviour is now documented somewhere. By the way, gnome-terminal already do this, so you may wish to look at how they did it. On the other hand, gnome-terminal is GPL-3 while roxterm is mostly GPL-2, in case you wish to keep roxterm under GPL-2 as much as you can. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688025: roxterm-gtk3: When copying an URL with the mouse, just some parts of the URL get selected.
Package: roxterm-gtk3 Version: 2.6.5-1 Severity: normal For example, if I double-clic the following text: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=roxterm Only the following will get selected (and pasted): //bugs.debian.org/cgi-bin/pkgreport.cgi?pkg As you can see, only the part of the URL between the 'http:' and the '=' are kept. I also noticed that when the mouse is over the server name, only http://bugs.debian.org; is underlined and if the mouse is over the right part of the URL, the full URL is properly underlined. It is fine for me if it is the intended behaviour, as long that what gets underlined is also what would get selected after a double-clic. Have a nice day, Simon Valiquette -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages roxterm-gtk3 depends on: ii libc6 2.13-35 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-20.100-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgtk-3-0 3.4.2-3 ii libice6 2:1.0.8-2 ii libpango1.0-0 1.30.0-1 ii librsvg2-common 2.36.1-1 ii libsm6 2:1.2.1-2 ii libvte-2.90-9 1:0.32.2-1 ii libx11-62:1.5.0-1 ii roxterm-common 2.6.5-1 roxterm-gtk3 recommends no packages. roxterm-gtk3 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#585448: Leaves files open as it scans, resulting in too many open files
Package: ruby-debian Followup-For: Bug #585448 I recently upgraded from Squeeze and also got hit by this bug. Since this bug usually only show up when upgrading to Wheezy and normaly doesn't affect Squeeze, should I reopen it against Wheezy? I believe that this bug really should be considered as release-critical for Wheezy, as it prevent upgrading. I've upgraded using 'apt-get upgrade' followed by 'apt-get dist-upgrade', and the only way to complete the installation was to either remove apt-listbugs or apply by hand the proposed patch. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=43;filename=dpkg-ruby.patch;att=1;bug=585448 I've done the latter and the patch worked fine for me. The patch is trivial and fix a real bug, and more importantly it is necessary to allow upgrading to Wheezy, so I think it should be included in a point-release *before* the release of Wheezy. Thank you for your time. Simon Valiquette -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure fails on cm-super
Package: cm-super Version: 0.3.4-3 Severity: important I can install and remove this package without problem, but if I run dpkg-reconfigure -a, it stops at cm-super-minimal unless I uninstall it and reinstall it only once dpkg-reconfigure have completed, thus the reason behind the severity. Here an example: sudo dpkg-reconfigure -p low cm-super cm-super-minimal Creating fonts. This may take some time... done. Running mktexlsr. This may take some time... done. dpkg-trigger: « dpkg-trigger » doit être appelé depuis un script de mainteneur ( ou avec l'option « --by-package ») Running mktexlsr. This may take some time... done. dpkg-trigger: « dpkg-trigger » doit être appelé depuis un script de mainteneur ( ou avec l'option « --by-package ») Translation: dpkg-trigger must be called from a maintainer script or with the option --by-package I don't know why the reconfiguration fails while the installation is successful, but perhaps you will have some idea. Notice that I have the exact same problem with cm-super-minimal, which is to be expected since they use the same scripts. Simon Valiquette -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686-bigmem (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages cm-super depends on: ii cm-super-minimal 0.3.4-3 TeX font package (minimal version) ii dpkg 1.15.5.3 Debian package management system ii pfb2t1c2pfb0.3-6 convert pfb into more compressible ii tex-common 1.20 common infrastructure for building ii texlive-latex-recommended 2007.dfsg.2-4 TeX Live: LaTeX recommended packag -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure fails on cm-super
Norbert Preining un jour écrivit: reassign 560317 tex-common retitle 560317 update-texmf-config calls dpkg-trigger even outside maintainer scripts thanks Thanks for the report, besides the problme that is real (although I don't see *WHY* dpkg complains, it is called from postinst script which is called ...), why do you reconfigure cm-super? I was just lazy after making many major upgrades and wanted to review the configuration of every packages with dpkg-reconfigure -a -p low Because it stopped in the middle of it, I investigated a bit the issue and found out that it stopped at cm-super. Reconfiguring cm-super was just an easy way to show and reproduce the problem. I don't know why the reconfiguration fails while the installation is successful, but perhaps you will have some idea. Notice that I I have no idea why dpkg-trigger complains, but I will inquire about it. Same for me, but AFAIK it complains only with dh_installtex, so I tough it was probably not dpkg fault. have the exact same problem with cm-super-minimal, which is to be expected since they use the same scripts. And with any other package that uses dh_installtex from tex-common and ships fonts. Ah, good. I very superficialy looked at the cm-super source package, and didn't saw anything obviously wrong. But I tough you would figure out much faster than me where the problem could be. Again, thanks for reporting. I am very glad of having been useful. Have a nice day. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#460338: apt gets stuck with 'waiting for headers' while interacting with apt-proxy
23:05:48-0500 [Channel,61,192.168.201.205] Top 10: 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205]275 WeakKeyDictionary 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 52 HttpRequestClient 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 39 Ephemeral 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 35 Deferred 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 34 Channel 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 32 CacheEntry 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 31 Logger 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 25 TimeoutProtocol 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 24 HttpFetcher 2009-12-04 23:05:48-0500 [Channel,61,192.168.201.205] 22 Protocol And nothing more as apt-get now finaly gave up. Here are the final messages from apt-get. I didn't bother to translate them, as it is quite trivial to figure out what they are in english. 99% [Attente des fichiers d'en-tête] Err http://apt-proxy lenny/non-free Packages Échec de la connexion Err http://apt-proxy lenny/contrib Packages Échec de la connexion 3734o réceptionnés en 1h21m57s (1o/s) Impossible de récupérer http://apt-proxy:/security/dists/etch/updates/contrib/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/security/dists/etch/updates/non-free/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/security/dists/lenny/updates/contrib/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/security/dists/lenny/updates/non-free/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/etch/main/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/etch/non-free/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/etch/contrib/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/lenny/main/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/lenny/non-free/binary-i386/Packages.gz Échec de la connexion Impossible de récupérer http://apt-proxy:/debian/dists/lenny/contrib/binary-i386/Packages.gz Échec de la connexion Lecture des listes de paquets... Fait E: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place. amos:~/backup Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523516: Upgrading to roundup 1.4.4-4+lenny1 breaks pagination entirely
Package: roundup Version: 1.4.4-4+lenny1 Followup-For: Bug #523516 -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Shouldn't this also be fixed for stable? It was a serious regression introduced by a security patch. I also think so, and expected it to be fixed in the previous point release. I can report that I applied the provided patch many weeks ago in Lenny and didn't noticed any problem since. So please, include the fix at least in the next point release, as it is a really annoying bug for the users that didn't have hand patched their system or that will eventualy upgrade from Etch. Simon Valiquette - -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-2-vserver-powerpc (SMP w/1 CPU core) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkrXpmsACgkQJPE+P+aMAJKgzACg8qB4aHoi02wDy4Hy7BYUxM9A OicAoNksJonqXadLpcOd7lTkVYOymii5 =QDXw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544018: ssmtp.conf ignore the AuthPass parameter if the password contain a '#' character.
Package: ssmtp Version: 2.62-3 Severity: normal If the '#' character appear anywhere in your password, and that you put it in the /etc/ssmtp/ssmtp.conf file using the AuthPass option, an empty password will be sent instead and the authentication will fails with a message such as: 535 5.7.0 Error: authentication failed: authentication failure sendmail: Authorization failed (535 5.7.0 Error: authentication failed: authentication failure) But if you pass the exact same password using directly sendmail -v -ap my#password, then it will works as expected. At first, I tought that maybe I had to escape it like this: \#, but after some more investigations I realized that whenever a password contain a '#', only 2 bytes are returned to the mailhub. Those 2 bytes are likely a carriage return, but I was too lazy to check. My guess is that if a '#' character appear anywhere on a line, then the full line is considered as a comment. To test this idea, I used a username such as AuthUser=some#User and as expected, the username is never sent to the mailhub. This affect both Lenny and Etch, and the latest version in Squeeze (2.63-1) is probably affected as well. Here is basically the config file I used: # /etc/ssmtp/ssmtp.conf root=postmaster mailhub=your.smtp.server.tld hostname=whatever.tld UseTLS=YES UseSTARTTLS=YES FromLineOverride=YES AuthUser=someUser AuthPass=my#password Thank you, Simon Valiquette -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444237: snowballz: crashes with X error
Package: snowballz Version: 0.9.5.1-2 Followup-For: Bug #444237 I also have pretty much the same problem than what was previously reported, and I also use the i810 driver in X, so probably it is the same problem. It also crash in my PowerPC, but with a completely different error message, so I will soon send another email with this system. Here follows the error messages I get on my x86 system, which is very similar but not exactly the same. Simon Valiquette http://gulus.USherbrooke.ca snowballz /usr/share/games/snowballz/font.py:3: UserWarning: *** The rabbyt.fonts module is deprecated and will be removed in a future version of rabbyt. I recommend using pyglet for font rendering. If you still want to use pygame fonts, check out the ``pygame_font.py`` example included with rabbyt. *** import rabbyt.fonts /usr/share/games/snowballz/font.py:3: UserWarning: The rabbyt.vertexarrays module is deprecated and will be removed in a future version of rabbyt. import rabbyt.fonts X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 134 (XFree86-VidModeExtension) Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) Value in failed request: 0x66 Serial number of failed request: 123 Current serial number in output stream: 125 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-vserver-686-bigmem (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages snowballz depends on: ii python 2.5.2-3 An interactive high-level object-o ii python-imaging 1.1.6-3 Python Imaging Library ii python-numpy1:1.1.0-3Numerical Python adds a fast array ii python-opengl 3.0.0~b6-3 Python bindings to OpenGL ii python-pygame 1.7.1release-4.2 SDL bindings for games development ii python-rabbyt 0.8.1-1 sprite library for Python with gam ii ttf-tamil-fonts 1:0.5.4 Free TrueType fonts for the Tamil snowballz recommends no packages. snowballz 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#444237: snowballz: crashes with X error
Package: snowballz Version: 0.9.5.1-2 Followup-For: Bug #444237 As promised, here are my second email for PowerPC. Well, finally the problem on my PowerPC system was not related with the snowballz package at all and was simply resolved by reinstalling python-pygame (I have no idea what has gone wrong, but anyway). At least it explains why the error message was different. Still, I get some minor error, so since I am already posting I repport them here just in case it could be useful: ~ snowballz /usr/share/games/snowballz/font.py:3: UserWarning: *** The rabbyt.fonts module is deprecated and will be removed in a future version of rabbyt. I recommend using pyglet for font rendering. If you still want to use pygame fonts, check out the ``pygame_font.py`` example included with rabbyt. *** import rabbyt.fonts /usr/share/games/snowballz/font.py:3: UserWarning: The rabbyt.vertexarrays module is deprecated and will be removed in a future version of rabbyt. import rabbyt.fonts there is no soundcard I have no idea why it said that I have no sound card, but the sound does work properly in the game on PPC. Anyway, this seems harmless and this problem apparently doesn't appears on PowerPC. Simon Valiquette -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.28-1-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages snowballz depends on: ii python 2.5.2-3 An interactive high-level object-o ii python-imaging 1.1.6-3 Python Imaging Library ii python-numpy1:1.1.0-3Numerical Python adds a fast array ii python-opengl 3.0.0~b6-3 Python bindings to OpenGL ii python-pygame 1.7.1release-4.2 SDL bindings for games development ii python-rabbyt 0.8.1-1 sprite library for Python with gam ii ttf-tamil-fonts 1:0.5.4 Free TrueType fonts for the Tamil snowballz recommends no packages. snowballz 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#465278: Appletouch failure upon resume after suspend2ram
Severity: grave I am increasing the gravity of this bug, because it makes the apple iBook G4 laptop pretty much unusable without an external mouse, and because people seems to just ignore this PowerPC specific bug. A very easy way to systematicaly reproduce this bug is to close the lid (or make it to sleep somehow), and then touch continously the mousepad during the wakeup. If you don't touch the trackpad, it might wakeup properly (maybe 1 chance on 3 to still have a working mouse). I also tried the same with the 2.6.18 kernel, and got similar results but with a significant difference: with the 2.6.18 kernel, I can make the mouse working again by simply doing rmmod appletouch and then modprobe -a appletouch. If I use the 2.6.26 kernel instead, I get the already reported following errors and the only way I know to make the mouse working again is rebooting. [45692.025239] appletouch: Could not do mode read request from device (Geyser Raw mode) [45692.025289] appletouch: probe of 1-2:1.0 failed with error -5 [45692.025347] usbcore: registered new interface driver appletouch Please note that xserver-xorg-input-synaptics is not even installed, and that the bug is reproducible in runlevel 1 with just enough things running to be able to put the laptop in sleep mode. My guess is that there is 2 bugs involved: a new bug in the appletouch driver in the kernel = 2.6.24 (maybe before) that prevent removing and adding again the driver properly in some conditions, and another possibly old bug that, for some reasons, showup systematically in Lenny while it was seldom appearing in Etch. In Etch, you could sometime lost the mouse after a wakeup, but it happened maybe just once a month, and since you could just remove and add again the driver, it was mostly just a nuisance. This bug is really annoying, reducing enough the usability of the iBook to make me seriously considering downgrading to Etch or looking at another distribution if it fix my problem. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465278: Appletouch failure upon resume after suspend2ram
Severity 465278 grave By searching a little on mailing lists, I saw that someone reported that the problems might be related with this patch, or at least related with this part of the code, but nobody seems to have seriously looked at it: http://www.linuxhq.com/kernel/v2.6/24/drivers/input/mouse/appletouch.c http://www.mail-archive.com/debian-powe...@lists.debian.org/msg59480.html From the Debian PowerPC mailing list, I deduce that the problem appeared in Debian Sid with the kernel 2.6.24. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513087: bcm43xx-fwcutter not replaced by b43-fwcutter when upgrading
Package: b43-fwcutter Version: 1:011-5 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 When upgrading from Etch to Lenny, b43-fwcutter is not automatically installed even if bcm43xx-fwcutter was previously installed. This obviously make the wireless card to stop working (at least on the iBook G4) once the kernel get upgraded from 2.6.18 to 2.6.26, so we have a lost of functionality when upgrading to Lenny. That in itself is not too bad, as it can easily be fixed by manually installing b43-fwcutter. Well, at least if the GUI and XOrg is still working properly after upgrading. If not, you have a problem because the text terminal is barely usable, thanks to khelper who continously call ifplugd and cause it to print the following 4 lines every second on the terminal: input: b43-phy0 as /class/input/input208 firmware: requesting b43/ucode5.fw b43-phy0 ERROR: Firmware file b43/ucode5.fw not found or load failed. b43-phy0 ERROR: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). The only thing needed to be able to upgrade directly from Etch to Lenny is a virtual package named bcm43xx-fwcutter that would install b43-fwcutter (and maybe also remove the old bcm43xx-fwcutter and bcm43xx-source packages). Since it is very easy to do, and that it give a much better user experience when upgrading from Etch, I don't see a reasons for not doing this in Lenny. Thank you in advance, Simon Valiquette http://gulus.USherbrooke.ca - -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-vserver-powerpc (SMP w/1 CPU core) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash - -- debconf information: b43-fwcutter/cut_firmware: true -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkl9eTgACgkQJPE+P+aMAJKfwACdGPg4amyJ8nG+5rdk0k2ulQZu 5CYAn2xTurbSdLL5Jdm9AMff80GrcH2N =H0OD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513087: bcm43xx-fwcutter not replaced by b43-fwcutter when upgrading
Rene Engelhard un jour écrivit: Hi, Simon Valiquette wrote: When upgrading from Etch to Lenny, b43-fwcutter is not automatically installed even if bcm43xx-fwcutter was previously installed. That's intended. This obviously make the wireless card to stop working (at least on the iBook G4) once the kernel get upgraded from 2.6.18 to 2.6.26, so we have a lost of functionality when upgrading to Lenny. And we should beep bcm43xx-fwcutter for kernel 2.6.18, in case you need to boot it again for whatever reason. OK fine, but would that be possible to find a way to automatically install b43-fwcutter by default when upgrading to Lenny if bcm43xx-fwcutter was already installed? That would be very convenient, as I don't see why someone that have installed bcm43xx-fwcutter in Etch would not want to have b43-fwcutter in Lenny. Or do there is some technical difficulties to do that in a clean way? Besides that, b43-fwcutter does not even know which kernel you run. True, but we know that most people that have already installed bcm43xx-fwcutter will want to install b43-fwcutter as well when upgrading to a kernel = 2.6.24 (more exactly, I think this is 2.6.20). Since it is very easy to do, and that it give a much better user experience when upgrading from Etch, I don't see a reasons for not doing this in Lenny. I don't think it'd make sense, given you want to keep bcm43xx-fwcutter for the old kernel. But if someone overruled me The best compromise is probably to find a way to have both package installed after upgrading to Lenny, and still be able to individually uninstall them if we want to. But I am not sure of the best way to achieve that though. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512366: eboard hangs up and use 100%CPU on PowerPC
Patrik Fimml un jour écrivit: Okay, I think I found the real culprit. In various places, network.cc limits output to non-control characters by comparing with 0x20. On x86, char is signed and 0xFF will be (-1), thus being treated as control character. On ppc, chars are unsigned AFAIK, and 0xFF will be (255), and passed on to the rest of the code. Ah, I should have tough about it. Yes, I confirm that char are unsigned for PowerPC, because managing signed char takes few more instructions on PowerPC than unsigned one (though the diffirence shouldn't be mesurable in our case). It means that other architectures are also broken and will need to be recompiled (ARM came to my mind). 154 if (buffer.front()=32) 219 if (c=0x20) 294 if (c=0x20) My fix for the time being would be to duplicate behaviour as on x86, using signed chars everywhere (as I suspect that other bugs might arise otherwise). A patch to the source package is attached, would you please try if that fixes the problem? I think you should simply cast c to a signed byte just to make more obvious how silly this hack is :o) More seriously, It seems to works now, thank you. The only weird thing I noticed is when playing offline against a computer, when the computer sometime played illegal moves (at least it is what eboard claimed before letting me play twice in a row) and sometime the computer being allowed to play 2 moves in a row. If I believe the quality of the code we examined, they are probably just some other unrelated bugs that also affect x86 systems. Also, I saw many very bad mistakes in the French translation, including one case for Bughouse where partner was translated as opponent, and one big grammar error in the sub menu + many typo. Since you are going to upload a new version anyway, I think it would be important to take it as an opportunity to improve the translation as well. I have completed the translation of every string in the .po file except for Helper program not found that I am still not sure of how I should translate it to French. I'll ask for a review on the debian french translation mailing list, and send to you directly the new .po file (and a copy for the actual French translator for eboard). If you don't want to wait, I'll send you right away what I have, which can't be worst that the past translation. I also spoted an error in the Japanese version. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512366: eboard hangs up and use 100%CPU on PowerPC
Patrik Fimml un jour écrivit:
Okay, I found out that it was looping inside NText::formatLine exactly
between the following lines in the file ntext.cc:
320 while(k-j 0) {
321 fit = false;
322
323 // try full-fit for for unwrapped of last chunk of wrapping
324
325 if (j==0 sl-Width = 0) {
326 w = sl-Width;
327 } else {
328 if (!g_utf8_validate(tp+j,k-j,NULL)) continue;
Obviously, g_utf8_validate() always returns false so the execution
flow always move back to the start of the while loop.
Here the backtrace in case you would still want to see it. On Etch,
there was also 2 stranges (but innocent looking) caracters appearing just
after login. I can't remember for sure if it was ÿû exactly, but I do
remember that it was some accented letters.
Do you know where they appeared? After your login name, or after the
password: prompt, or anywhere inbetween?
They didn't appeared until I pressed enter for the password. They appeared
on a separate line, probably just after the password line, but I am not
100% sure for the exact line.
My guess is that the characters used to make a terminal not display its
input (i.e. if you were entering your password over a telnet FICS
session) are upsetting eboard.
That would makes sense, since on a x86 computer the caracters are
replaced by bigs round dots in the gui and that there is no output in the
text console.
Actually, the guide I linked has got it wrong, you need to set
DEB_BUILD_OPTS=nostrip noopt, separated by a space, not a comma.
Please re-compile eboard without optimizations for further debugging,
and get a detailed backtrace (bt full).
Since my default shell is tcsh, the syntax for me is:
setenv DEB_BUILD_OPTIONS 'nostrip noopt'
I am a little surprised that it did not strip the symboles, but just
ignored the rest of the line without complaining (or I missed it).
Please dump the raw byte contents of the trouble-causing buffer. Assuming
you break in g_utf8_validate again, you could do:
(gdb) p /x *...@10
That gives me this, with 0xff and 0xfc being ÿ and ü:
{0xff, 0xfc, 0x0, 0xd8, 0x10, 0x25, 0x99, 0x10, 0x10, 0x39}
I also give you a little more. I guess that sl-Width=-1 means that
the length is unknown?
(gdb) p /x *sl
$13 = {_vptr.NLine = 0x10120b18, Text = 0x10390bd0, NBytes = 0x2, Color =
0xff, Width = 0x,
Timestamp = 0x4978ab46}
(gdb) p /x *fl
$15 = {NLine = {_vptr.NLine = 0xbfd23950, Text = 0x100a4064, NBytes =
0x101da800, Color = 0x28, Width = 0xbfd23980,
Timestamp = 0x101daa18}, Src = 0xfb3b810, Off = 0x0, X = 0xbfd23970,
Y = 0x100a4124, H = 0x101da808, valid = 0xbf,
stamp = {0xd2, 0x39, 0x80, 0x10, 0x1c, 0xc, 0x28, 0x10, 0x1d, 0xa8,
0x0, 0xf}}
And here, I give you the full backtrace before entering the function.
328 if (!g_utf8_validate(tp+j,k-j,NULL)) continue;
(gdb) bt full
#0 NText::formatLine (this=0x101da800, i=40) at ntext.cc:328
j = 0
k = 2
l = -1076741840
w = -1076741856
color = 16777215
fit = false
sl = (NLine *) 0x10395c68
fl = (FLine *) 0xbfd23930
tp = 0x10390bd0 ÿü
elw = 705
#1 0x100a3678 in NText::append (this=0x101da800, text=0xbfd23f34 ÿü,
len=2, color=16777215) at ntext.cc:262
i = -1076741760
nl = (NLine *) 0x10395c68
p = 0x0
#2 0x100f60d4 in Text::append (this=0x101da800, msg=0xbfd23f34 ÿü,
color=16777215, imp=IM_NORMAL) at text.cc:132
No locals.
#3 0x100f3728 in TextSet::append (this=0x101d9ca8, msg=0xbfd23f34 ÿü,
color=16777215, imp=IM_NORMAL) at text.cc:181
ti = {_M_node = 0x101df748}
#4 0x100c4f34 in FicsProtocol::doOutput (this=0x10259880, msg=0xbfd23f34
ÿü, channel=-1, personal=false,
msgcolor=16777215) at proto_fics.cc:824
No locals.
#5 0x100c767c in FicsProtocol::parser2 (this=0x10259880, T=0xbfd23f34
ÿü) at proto_fics.cc:346
No locals.
#6 0x100c79fc in FicsProtocol::parser1 (this=0x10259880, T=0xbfd23f34
ÿü) at proto_fics.cc:312
pstring =
¿Ò0\000\000\000\002¿Òp\017Ï\031пÒp\020\0301°\020\035¹ð\020\035µè\017³¸\020\020\035º\220¿Ò;\020\017ª8ô\017úë
\020\035º\220¿Ò;0\017Ã\001\204\000\001f\000\000\000\000\000\017Ã\001°¿Ò;x\017úÐL\000\000\000\000¿Ò;P\017¾L\000\000\020\000\020\0301°¿Ò;x\017Ã\001°\017úë
\020\0301°¿Ò;p\017Ã\021\200\0206\020P\000\000V\000\020\030é\200\020\035¹ð\017úë
\020\0301°¿Ò; \017Ã2\220\020\0301°\020\035¹ð¿Ò; ¿Ò0\017\214\200\\¿Ò0¿Ò;
¿Ò0\017ûp\017Ã1À...
Here, I wondered if the caracters I previously saw in Etch were not
úë instead of ÿü, but maybe they always have been ÿü.
#7 0x100c7a54 in FicsProtocol::receiveString (this=0x10259880,
netstring=0xbfd23f34 ÿü) at proto_fics.cc:247
No locals.
#8 0x10088020 in MainWindow::readAvailable (this=0x10187470, handle=7) at
mainwindow.cc:1687
net = (class NetConnection *) 0x1035e718
line = ÿü, '\0' repeats 2045 times
gotinput = 1
loopc = 0
#9 0x1008ee30 in
Bug#465278: Appletouch failure upon resume after suspend2ram
Package: linux-image-2.6-vserver-powerpc Version: 2.6.26-13 Followup-For: Bug #465278 After upgrading from Etch to Lenny, I started to get exactly the same problem than what Cyril Brulebois experienced. The laptop I am using is the latest iBook G4. The error message I get when I try to add again the appletouch module is almost identical to this: | Feb 11 17:04:52 evy kernel: drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser Raw mode) | Feb 11 17:04:52 evy kernel: appletouch: probe of 1-2:1.0 failed with error -12 | Feb 11 17:04:52 evy kernel: usbcore: registered new interface driver appletouch except that in my case, I get the error -5 instead of -12: [45692.025239] appletouch: Could not do mode read request from device (Geyser Raw mode) [45692.025289] appletouch: probe of 1-2:1.0 failed with error -5 [45692.025347] usbcore: registered new interface driver appletouch Just to make things very clear, I don't think that this bug is the same than the one where removing and adding again the appletouch module is enough to make the mouse working again. The later bug appears quite infrequently, and usually the mouse is still able to move (even if in an unusable fashion). Also, from memory the error messages were very different. In the current bug, the mouse don't react anymore even in the text console and seems to happens systematically once the laptop goes to suspend mode. Also, it seems that the only way to make it working again is by rebooting the laptop. Some people have mentioned that the problem could be in the package xserver-xorg-input-synaptics and not in the kernel. Unless he was talking about the other mouse bug, I am sceptical about it and will try to reproduce the bug without running the X server at all during the boot process and report the result once I have time. Simon Valiquette http://gulus.USherbrooke.ca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512366: eboard hangs up and use 100%CPU on PowerPC
Patrik Fimml un jour écrivit:
More exactly, it start as usual, but when connecting to a chess server,
it hangs and consume 100% CPU once the user have entered a user name.
[...]
If I press 'return here, the screen draw an additionnal '' on the next
line, and the window hangs (it cannot be closed except by pressing CTRL-C
twice in a console or by killing it).
Are you using a custom login script (~/.eboard/scripts/autofics.pl) that
does weird stuff, maybe? If yes, please try without the script.
No. Also, before sending the bug report, I uninstalled and purged the
package, rename the ~/.eboard/ folder and reinstalled eboard and tested it
again just to make sure it was not something like that.
If you need any more information or want me to try a patch, just ask me.
Please try to get a backtrace with debugging symbols after the freeze
occurs and you hit CTRL-C.
Okay, I found out that it was looping inside NText::formatLine exactly
between the following lines in the file ntext.cc:
320 while(k-j 0) {
321 fit = false;
322
323 // try full-fit for for unwrapped of last chunk of wrapping
324
325 if (j==0 sl-Width = 0) {
326 w = sl-Width;
327 } else {
328 if (!g_utf8_validate(tp+j,k-j,NULL)) continue;
Obviously, g_utf8_validate() always returns false so the execution
flow always move back to the start of the while loop.
Is it just me that is very tired, or will it always test exactly the
same string?
The only sane explanation that came to my mind is that on x86, unless
there is something wrong, the data are almost always valid Unicode on the
first try (which seems reasonnable).
It looks like a cutpaste error because just after, there is a for
loop with almost exaclty the same code, except that the code makes more
sense and don't always test the same data.
It would also means that on big endian systems, there is maybe another
bug somewhere that made this bug show up.
Here the backtrace in case you would still want to see it. On Etch,
there was also 2 stranges (but innocent looking) caracters appearing just
after login. I can't remember for sure if it was ÿû exactly, but I do
remember that it was some accented letters.
(gdb) bt
#0 0x0f7ab194 in IA__g_utf8_validate (str=0x102b4048 ÿû, max_len=2,
end=0x0)
at /build/buildd/glib2.0-2.16.6/glib/gutf8.c:1754
#1 0x1005a4c4 in NText::formatLine (this=0x1016ca10, i=34) at ntext.cc:328
#2 0x1005c4b0 in NText::append (this=0x1016ca10, text=0xbff95f48 ÿû,
len=2, color=16777215) at ntext.cc:262
#3 0x1008d15c in Text::append (this=0x1016ca10, msg=0xbff95f48 ÿû,
color=16777215, imp=IM_NORMAL) at text.cc:132
#4 0x1008bc64 in TextSet::append (this=value optimized out,
msg=0xbff95f48 ÿû, color=16777215, imp=IM_NORMAL)
at text.cc:181
#5 0x1006c78c in FicsProtocol::doOutput (this=value optimized out,
msg=0xbff95f48 ÿû, channel=value optimized out,
personal=value optimized out, msgcolor=value optimized out) at
proto_fics.cc:824
#6 0x10073aa0 in FicsProtocol::parser1 (this=0x1025b3c0, T=0xbff95f48
ÿû) at proto_fics.cc:312
#7 0x100493b8 in MainWindow::readAvailable (this=value optimized out,
handle=value optimized out) at mainwindow.cc:1694
#8 0x1004fce8 in netconn_read_notify (data=value optimized out,
source=value optimized out, cond=value optimized out)
at network.cc:133
#9 0x0faa351c in gdk_io_invoke (source=value optimized out,
condition=value optimized out, data=value optimized out)
at /build/buildd/gtk+2.0-2.12.11/gdk/gdkevents.c:986
#10 0x0f7b2e68 in g_io_unix_dispatch (source=0x102b0df8,
callback=0xfaa34a0 gdk_io_invoke, user_data=0x101c88f8)
at /build/buildd/glib2.0-2.16.6/glib/giounix.c:162
#11 0x0f76c72c in IA__g_main_context_dispatch (context=0x1010d330) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2012
#12 0x0f770ec8 in g_main_context_iterate (context=0x1010d330, block=1,
dispatch=1, self=value optimized out)
at /build/buildd/glib2.0-2.16.6/glib/gmain.c:2645
#13 0x0f771604 in IA__g_main_loop_run (loop=0x10213440) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2853
#14 0x0fce9bc4 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.12.11/gtk/gtkmain.c:1163
#15 0x10045d44 in main (argc=1, argv=0xbff96be4) at main.cc:108
Can anybody else reproduce this on PPC?
I used to have a Sparc computer. That would actually have been very
handy to test my theory about endianness and confirm the bug, but
unfortunately I don't have it anymore.
I am also a little surprised that nobody reported it before.
Simon Valiquette
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465278: Appletouch failure upon resume after suspend2ram
Simon Valiquette un jour écrivit: Some people have mentioned that the problem could be in the package xserver-xorg-input-synaptics and not in the kernel. Unless he was talking about the other mouse bug, I am sceptical about it and will try to reproduce the bug without running the X server at all during the boot process and report the result once I have time. I can now confirm that this bug have nothing to do with xserver-xorg-input-synaptics, or xorg for that matter. I booted in single user mode and basically have done the following: /bin/mount -a /etc/init/udev start /etc/init/bootmisc.sh start /etc/init/pmud restart /etc/init/hibernate restart /etc/init/gpm start # to have a working mouse in the console /usr/sbin/pm-suspend And that was more than enough to reliably reproduce this old bug with very few running programs. Simon Valiquette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512366: eboard hangs up and use 100%CPU on PowerPC
Package: eboard Version: 1.1.1-2 Severity: grave -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 After upgrading from Etch to Lenny, eboard stopped working on PowerPC. Since it works fine on x86, my guess is that there is maybe an endianness issue somewhere in the networking code of eboard. More exactly, it start as usual, but when connecting to a chess server, it hangs and consume 100% CPU once the user have entered a user name. Here an example of what I get: |Server location: freechess.org Server version : 1.25.17 | | If you are not a registered player, enter guest or a unique ID. | (If your return key does not work, use cntrl-J) | |login: | guest | |Logging you in as GuestDJMT; you may use this name to play unrated games. |(After logging in, do help register for more info on how to register.) | |Press return to enter the server as GuestDJMT: If I press 'return here, the screen draw an additionnal '' on the next line, and the window hangs (it cannot be closed except by pressing CTRL-C twice in a console or by killing it). Note that using xkill will close the window but the process will still be consuming 100% CPU in the background. I tried to run eboard with the options -log and -debug, but It didn't gave much more information except confirming that it hangs somewhere between when the username is asked and when the password is asked. If you need any more information or want me to try a patch, just ask me. Thank you, Simon Valiquette - -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-vserver-powerpc (SMP w/1 CPU core) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages eboard depends on: ii libatk1.0-0 1.22.0-1The ATK accessibility toolkit ii libc62.7-18 GNU C Library: Shared libraries ii libcairo21.6.4-7 The Cairo 2D vector graphics libra ii libgcc1 1:4.3.2-1.1 GCC support library ii libglib2.0-0 2.16.6-1The GLib library of C routines ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libpango1.0-01.20.5-3Layout and rendering of internatio ii libpng12-0 1.2.27-2PNG library - runtime ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 Versions of packages eboard recommends: ii sox 14.0.1-2+b1 Swiss army knife of sound processi ii xfonts-75dpi 1:1.0.0-4 75 dpi fonts for X Versions of packages eboard suggests: ii crafty19.15-1State-of-the-art chess engine, com ii eboard-extras-pack1 2-2additional piece sets and sounds f ii gnuchess 5.07-4.1 Plays a game of chess, either agai - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkl1exkACgkQJPE+P+aMAJJ8XgCgmARG+bpVMurkqFFHp24YQnUQ wKQAnRSZ+oQ4OdybWaLL8frhf+CMNglM =yQEM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509083: lilo: LILO is not run after upgrading to kernel 2.6.26
Package: lilo Version: 1:22.8-7 Severity: important Hello, When upgrading a 2.6.26 kernel, LILO is not run anymore, so the computer won't reboot properly if we forget to manually run LILO. It was working fine when upgrading 2.6.25 kernels, and LILO stopped being executed automatically only once I upgraded to the 2.6.26 kernel. Maybe it is a release candidate bug, because while it is easy to manually execute lilo after upgrading the kernel, forgeting to do so may lead to important problems with remote servers. At least, I think it should be a release goal if it is not already the case. I am not sure if this bug is in the LILO package itself, but if not you will certainly know very well to which package to reasign it. Thank you in advance, Simon Valiquette http://gulus.USherbrooke.ca -- Installed kernels: ii linux-image-2.6-686 2.6.26+17 ii linux-image-2.6.25-2-686 2.6.25-7 ii linux-image-2.6.25-2-686-bigmem 2.6.25-7 ii linux-image-2.6.25-2-vserver-686 2.6.25-7 ii linux-image-2.6.26-1-686 2.6.26-11 ii linux-image-2.6.26-1-vserver-686 2.6.26-11 ii linux-image-2.6.26-1-vserver-686-bigmem 2.6.26-11 ii linux-image-686 2.6.26+17 ii linux-image-vserver-686 2.6.26+17 ii linux-image-vserver-686-bigmem 2.6.26+17 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-vserver-686-bigmem (SMP w/2 CPU cores) Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages lilo depends on: ii debconf [debconf-2.0]1.5.24 Debian configuration management sy ii libc62.7-16 GNU C Library: Shared libraries ii libdevmapper1.02.1 2:1.02.27-4 The Linux Kernel Device Mapper use ii mbr 1.1.10-1Master Boot Record for IBM-PC comp lilo recommends no packages. Versions of packages lilo suggests: ii lilo-doc 1:22.8-7 Documentation for LILO (LInux LOad -- debconf information: liloconfig/fstab_broken: * liloconfig/banner: liloconfig/liloconf_incompatible: lilo/bad_bitmap: liloconfig/use_lba32: true lilo/upgrade: * liloconfig/liloconf_exists: liloconfig/configuring_base: liloconfig/use_current_lilo: false * lilo/runme: true liloconfig/wipe_old_liloconf: true * liloconfig/instruction: liloconfig/activate_error: * liloconfig/select_bitmap: /boot/debianlilo.bmp liloconfig/lilo_error: * lilo/new-config: liloconfig/odd_fstab: * liloconfig/install_from_root_device: true * liloconfig/make_active_partition: true liloconfig/maintitle: liloconfig/mbr_error: * liloconfig/lilo_warning: * liloconfig/install_mbr: true liloconfig/no_changes: * lilo/add_large_memory: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502364: dhclient still running after uninstalling dhcp3-client
Package: dhcp3-client Version: 3.1.1-4 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I reconfigured a Lenny box with a static IP address and then removed dhcp3-common. Everything worked like a charm, but then about a week later I was surprised when the IP address changed, which caused some problems. I then realized that dhclient was still running even tough I uninstalled it a week before. I think that dhclient should be killed when dhcp3-client is uninstalled, but without releasing the leased IP and without touching the actual routing configuration (to avoid losing the network and in case it would have been manually reconfigured just before uninstalling the package). If there is some reasons for the current behaviour, then at least please explain and document it in the man page and in /usr/share/doc/dhcp3-client/ Thank you, Simon Valiquette http://gulus.USherbrooke.ca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI9oDuJPE+P+aMAJIRA4NqAKDwtqtoOva5ouPcbon5SKmty4oYaQCfSgsp l059bnbCTEOciG9N8LfoN9M= =Z+8x -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496942: No default key configured to give thrust
Package: thrust Version: 0.89c-3.4 Severity: minor As the title suggest, there is no key configured to give thrust to the spaceship. Combined with the still existent bug #91959 (user defined command keys not saved after restarting the game), It is a little annoying since you have to reset this necessary key each time. It is certainly very easy to fix both problems for anyone with a basic understanding of the source code. Simon Valiquette -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496942: No default key configured to give thrust
Peter Rosin un jour écrivit: Hi Simon! Bug #91959 has been fixed upstreams. I like the right ctrl key as the default for thrusting, but realize that not all keyboards have such a key (and that it is an unusual key, which might not always work...). That's true. For example, on my iBook G4, there is a right-command key and an alternate enter, but no right-ctrl key. Maybe a dot . would be a good alternative, since It is almost always located at the bottom-right. And if you have a keypad, It is conveniently placed close to the alternate enter key. For the few cases where the dot won't be a good candidate (for example, the Dvorak keyboard), the others key will also be badly placed anyway. If that's not proper for Debian, that will have to be patched by Debian. Well, since most people will have a PC keyboard, that would still be better than no default at all. But fix the real problem here, start by updating from upstream! Ok, I see. This is basically the same package since Sarge with no updates since the release of Debian Etch. 0.89d contains a little more than just bug fixes, and since Lenny have been frozen, I am not sure if an update would be accepted. Still, the changes seems very minors, 0.89e and 0.89f only fix bugs, and the package would ideally need to be rebuild anyway to fix some minors issues, so maybe It could pass over the freeze. For reference to myself, here the source code: ftp://ftp.lysator.liu.se/pub/games/thrust/ If I feel like remaking the package, I may submit a new source package Monday. But before, there is a bug I would like to fix in encfs, which is obviously way more important than the thrust package, so don't wait for me. Simon Valiquette http://gulus.USherbrooke.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311772: Fwd: Password leaks are security holes
Nico Golde un jour écrivit: Hi Johan, * Johan Walles [EMAIL PROTECTED] [2008-08-28 13:14]: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: [...] So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. How would you determine valid and invalid ones? A user name that is considered valid could still be a password. If that is the case, then It is most likely a very bad password that someone could guess anyway, so that is a non-issue (except for the fact that the password should obviously be changed for a better one). Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311772: Password leaks are security holes
A. Dreyer un jour écrivit: On Thu, 28 Aug 2008, Johan Walles wrote: Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) That's obviously true, but that doesn't cover the case when logs are copied to a second system with sysadmins that doesn't have access to the first server. And if someone use the standard 514 syslog port instead of using an SSL tunnel or the newer syslog-tls on port 601, well you get cleartext password on the wire (yes, people sometime make stupid mistakes). Personally, I would prefer never to see password stored in clear text anywhere, whatever the file permissions are. And If I really want to still see them, I certainly won't complain if all I have to do is make a small change to the default configuration file, telling the system that I know what I am doing. That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? I think that everybody agrees that the default behaviour should be the most secure for most people, unless we have a very good reason to do otherwise. What some doesn't agree on is what is the most secure behaviour. I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. And you do you figure out if you are under attack? Many failed connections, usually from the same IP with a few existing account in the lot, usually completelly unrelated account names (so easy to differentiate from someone that forgot the exact spelling of his/her account name). Realistically, there is very few cases were seeing the non existent account names is essential to detect an attack, and even when that happens, I am not sure that you would always realize that you are attacked. The very few companies that follows well enought their logs to be able to detect more attacks by allowing logging what is potentially a password are probably willing to change their configuration anyway. For most people, writting unknown account is a better security practice. When I see that someone is obviously trying default system usernames I know there is an attack going on, if I only see that there have been 10 invalid login requests this could also be the CEO coming back from his 2 month vacation... Would he types in 10 times in a row his password instead of his username? I don't believe It. If he just try to remember his password, then you will see 10 failed login attempt to his account before succeding or requesting a new password. If he tries to remember his username, then It is usually very easy to differentiate that from a real attack, even without seeing the username. Common sense: If you have accidentally typed in your password on the login prompt, login immediately and change the password! We shouldn't encourage people to continue using possibly compromised passwords. If they compromise it, they are responsible to change it immediately or to get the account locked!! They usually don't even understand that their password is potentially compromised. And if the password is not put in a log files, and that nobody saw their screen, they are actually right, which is good. And even if they know, most will hate to have to learn a new password, and avoid changing It if they can. This should be in your (computer use) company policy. A company policy that most people won't follows anyway. Just like asking people to use different password for each account. And if you configure the system to prevent them from using similar password for each account, or one similar to a past password, or if they are forced to change their password too often (possibly because they sometime put their password in the user field) then they start writting down the password somewhere they think nobody will find It, even if It is forbiden by policy. Policy won't change human nature, sorry. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482155: fixed in vserver-debiantools 0.6.2
Package: vserver-debiantools Followup-For: Bug #482155 -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I installed version 0.6.2 of the package in Lenny, and I report that It fixed the problem that I also still experienced with 0.6.1 I guess that you will be able to close #486128, which is in fact just a duplicate of this bug. Thx for the fix. Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIVe1aJPE+P+aMAJIRA6GgAKDbtUpiwUtPCP7oZzFsjySUXk2fCQCZAQQr EmOGqRotvL+bL/RZ0nW6jzU= =cSVq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450561: Memory leak in Slony 1.2.1
Hello, Maybe I wasn't clear enough, but I know that the version in Lenny is not supposed to be affected. I forgot to tag It as Etch specific (I tough reportbug would do It for me, but I missed that It didn't). If you don't want to fix this bug, then at least mark It as wontfix with the reason, but not closed. And no, people with production systems won't move to Lenny before It is released as Debian Stable. I've one system where Slony seams to eats a bit over 100MB of ram per month per instance of the daemon. I've noticed when the DB started to use the swap, while there was normally almost one GB of free RAM. I wasn't curious enough to wait for the OOM killer to quick-in and see what would happens. I think I should increase the priority of the bug to at least important, because if we ever reach OOM conditions, lots of bad things could happens. The simple fact that people use Slony is a good hint that they really care about their DB staying available. As I said, It might not be serious enough to release a patch just for this bug, but I believe the bug needs to be kept open and patched at the same time if there is a security update to It. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450561: Memory leak in Slony 1.2.1
Package: slony1-bin Version: 1.2.1-1 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I my case, this bug cause problems and eventually makes slon use more than 128MB of ram per instance. So I had to patch the source to avoid needing to restart periodically slon and postgres daemons. While It is not a critical bug, It would be nice if you could fix It at the same time if there is ever a need for a security update on this package. Meantime, affected fellow Debian users can easily apply the following patch. It has been fixed upstream in 1.2.2. Simon Valiquette http://gulus.USherbrooke.ca diff -Lsrc/slon/remote_worker.c -Lsrc/slon/remote_worker.c -u -w -r1.128 - -r1.129 - --- src/slon/remote_worker.c +++ src/slon/remote_worker.c @@ -4847,6 +4847,7 @@ * Good job! */ dstring_free(query); + dstring_free(lsquery); gettimeofday(tv_now, NULL); slon_log(SLON_DEBUG2, remoteWorkerThread_%d: SYNC INT64_FORMAT done in %.3f seconds\n, - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-5-vserver-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHMoHnJPE+P+aMAJIRA9O/AKDHlWZFtjmoeHRhJ0wC7vI3Eca8EgCgmv1J /4GfCMJ3QKjDjr1K9uNmYZc= =kVQx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428765: Segfault on page with sound if you return to the page
Simon Valiquette un jour écrivit: #315979 have many similarities, but It claim that I doesn't crash in Mozilla/iceape, only in Firefox. I will check if It crash in Firefox as reported in #315979, or if It crash as I reported with Iceape (on the second visit). I just wanted to confirm that mozilla-plugin-vlc crash as I reported with both Firefox and Mozilla. I also tried to reproduce It on an Intel PC with Etch (instead of PowerPC), and It still crash almost exactly as reported, so It is not a bug specific to PPC as I first thought. The only difference I saw than on PPC, is that the memcpy module used is not the same (which is obviously normal). I can send the full output, but It is very easy to reproduce this bug. Simon Valiquette
Bug#428754: Consume all available memory while opening an XML file
Mike Hommey un jour écrivit: If you open this xml file with iceape (localy or from the web), iceape will start to use all available memory at over 1MB/s until It crash. http://download.wikipedia.org/images/archive/etwiktionary/20060912/etwiktionary-20060912-abstract.xml Note that java and javascript are disabled in my browser, so you won't have to search for that. It would be useful if someone with some free time could trim this XML file and find a minimal subset that still crash iceape. I would say the minimal subset is what is enough for the DOM structures for this xml file to fill up all your memory. The crash may occur because of the OOM killer. I wasn't clear enough, but yes, It is the OOM killer that kill iceape, not iceape that crash after using all available memory. If I have time Sunday, I will try to find the minimal subset of this file that is enought to make Iceape take all the memory. Another possibility is that the file is just very big and the intermediate processing is taking way too much memory, and that with enough memory It would works (I have 512MB, which is supposed to be more than enough with Blackbox). Anyway, I will get this answer very quickly while trimming parts of this XML file. Simon Valiquette
Bug#428765: Segfault on page with sound if you return to the page
Mike Hommey un jour écrivit: reassign 428765 mozilla-plugin-vlc thanks On Wed, Jun 13, 2007 at 07:21:38PM -0400, Simon Valiquette [EMAIL PROTECTED] wrote: Package: iceape-browser Version: 1.0.9-0etch1 Severity: important If you go to this page, leave It and return later to this page, iceape will reliably crash each time on Etch PPC. http://www.redgreen.com/index.cfm?app=carta=menu Looks like you are using the vlc plugin... and that the problem is there. Yes, you are right. I uninstalled mozilla-plugin-vlc and iceape stopped crashing, even without restarting iceape (It used totem instead). So I confirm that It is in fact a mozilla-plugin-vlc bug. I checked in case it would be a duplicate of another already reported bug, but I didn't find anything obviously the same. And since my bug involve no video (only a .wav), It might be easier to find the problem. It could be a duplicate of #405112, but there is no informations on how to reproduce It. #315979 have many similarities, but It claim that I doesn't crash in Mozilla/iceape, only in Firefox. I will check if It crash in Firefox as reported in #315979, or if It crash as I reported with Iceape (on the second visit). Simon Valiquette
Bug#428754: Consume all available memory while opening an XML file
Package: iceape-browser Version: 1.0.9-0etch1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 If you open this xml file with iceape (localy or from the web), iceape will start to use all available memory at over 1MB/s until It crash. http://download.wikipedia.org/images/archive/etwiktionary/20060912/etwiktionary-20060912-abstract.xml Note that java and javascript are disabled in my browser, so you won't have to search for that. It would be useful if someone with some free time could trim this XML file and find a minimal subset that still crash iceape. To be sure It wasn't just a unicode related problem, I modified the XML file with the following command and got exactly the same result: iconv -c --from-code UTF-8 --to-code ISO_8859-1 \ /tmp/etwiktionary-20060912-abstract.xml \ -o /tmp/etwiktionary-20060912-abstract2.xml Thank you for your time, Simon Valiquette http://gulus.USherbrooke.ca - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Versions of packages iceape-browser depends on: ii libatk1.0-0 1.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.2-1.2 generic font configuration library ii libgcc1 1:4.1.1-21 GCC support library ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-7 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor1 1.1.7-4X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxrandr22:1.1.0.2-5X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages iceape-browser recommends: pn iceape-gnome-support none (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGcGxnJPE+P+aMAJIRA6meAKD2dR3e7sqGRTOBqlqXEp6CCYoeIQCfdFyi BW6gktXW4CF6pn19kwYmnVI= =TufU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428765: Segfault on page with sound if you return to the page
output debug: mixer 'fl32' 22050 Hz Mono frame=1 samples/4 bytes [0330] main audio output debug: no need for any filter [0330] main audio output debug: looking for audio mixer module: 3 candidates [0330] main audio output debug: using audio mixer module trivial_mixer [0330] main audio output debug: input 'u8 ' 22050 Hz Mono frame=1 samples/1 bytes [0330] main audio output debug: filter(s) 'u8 '-'fl32' 22050 Hz-22050 Hz Mono-Mono [0333] main private debug: looking for audio filter module: 24 candidates [0333] main private debug: using audio filter module u8tofloat32 [0330] main audio output debug: found a filter for the whole conversion [0330] main audio output debug: filter(s) 'fl32'-'fl32' 24255 Hz-22050 Hz Mono-Mono [0361] main private debug: looking for audio filter module: 24 candidates [0361] main private debug: using audio filter module bandlimited_resampler [0330] main audio output debug: found a filter for the whole conversion [0289] main input debug: EOF reached [0289] main input debug: waiting decoder fifos to empty [0289] main input debug: closing input [0300] main demuxer debug: removing module wav [0293] main access debug: removing module access_file [0311] main decoder debug: removing module araw [0311] main decoder debug: thread 908068064 joined (input/decoder.c:191) [0311] main decoder debug: killing decoder fourcc `araw', 0 PES in FIFO [0333] main private debug: removing module u8tofloat32 [0361] main private debug: removing module bandlimited_resampler [0330] main audio output debug: thread 916653280 joined (alsa.c:714) [0330] main audio output debug: removing module alsa [0330] main audio output debug: removing module trivial_mixer [0289] main input debug: thread 887092448 joined (input/input.c:413) [0283] main playlist: nothing to play Seems all good, all fine. Now I type www.debian.org and got those messages: [0001] main private debug: removing all interfaces [0287] main interface debug: thread 878703840 joined (interface/interface.c:258) [0287] main interface debug: removing module screensaver [0285] main interface debug: thread 870315232 joined (interface/interface.c:258) [0285] main interface debug: removing module hotkeys [0001] main private debug: removing playlist handler [0284] main private debug: thread 861926624 joined (playlist/playlist.c:247) [0283] main playlist debug: thread 853538016 joined (playlist/playlist.c:248) [0283] main playlist: stopping playback [0283] main playlist debug: deleting playlist item `http://www.redgreen.com/files/layout/ifthewomen.wav' [0001] main private debug: removing all video outputs [0001] main private debug: removing all audio outputs [0001] main private debug: removing module memcpyaltivec [0001] main private debug: saving plugins cache file /home/test/.vlc/cache/plugins-0404be.dat I have the feeling that the module memcpyaltivec should not have been removed here. Or at least there is something interesting here. So now, if I return back to the previous URL http://www.redgreen.com/index.cfm?app=carta=menu I get this messages just before Iceape crash, which is exactly the same as the first lines you get when viewing the page the 1st time. argn=src, argv=files/layout/ifthewomen.wav argn=loop, argv=false argn=autostart, argv=true argn=mastersound, argv= argn=hidden, argv=true argn=height, argv=0 argn=width, argv=0 My feeling is that too much things got freed, and that Iceape try to request a ressource that don't exist anymore. My guess is that the module memcpyaltivec should not have been removed, and that on the 2nd time you visit a page that makes Iceape try to use memcpyaltivec, It does even if the module is not loaded anymore. Note that even if altivec is a PowerPC thing, this bug might (or not) also show up on Intel based processor with MMX. We will get an answer to this very quickly I guess. If I am right, then Iceape probably does the following just before crashing, and don't have the time to print those last debug messages: [0001] main private debug: CPU has capabilities AltiVec FPU [0001] main private debug: looking for memcpy module: 2 candidates [0001] main private debug: using memcpy module memcpyaltivec Simon Valiquette -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Versions of packages iceape-browser depends on: ii libatk1.0-0 1.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.2-1.2 generic font configuration library ii
Bug#416695: Wrong URI in rarp man page
Package: net-tools
Version: 1.60-17
Severity: minor
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In /usr/share/man/man8/rarp.8.gz there is a link to:
ftp://ftp.dementia.org/pub/net-tools/
If I believe archive.org, the following URL should have been used
a very long time ago:
ftp://alycia.dementia.org/pub/net-tools/
I searched with the following command and didn't found any other
instance of ftp.dementia.org:
~ find /usr/share/{doc,man*}/ | xargs zfgrep -in dementia.org
Simon Valiquette
http://gulus.USherbrooke.ca
- -- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-4-powerpc
Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGDB13JPE+P+aMAJIRA/piAJ9K7X/KOcvH5a0DFqpjBgRRzXatIgCg6Qy/
XOLh+NJPRHIU4Vv1yuj87F8=
=89fh
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415707: old testing version
It is still on the public servers, so you can simply download It directly from here: http://gulus.USherbrooke.ca/debian/pool/main/p/postfix/ Then, simply installing the package manually with dpkg should downgrade It automaticaly (add --force-downgrade if It doesn't). Thanks guys for quickly reporting the bug. apt-listbugs saved me many troubles and allowed me to refuse the upgrade based on your comments. Simon Valiquette http://gulus.USherbrooke.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412457: mirrors: syncproxy.wna.debian.org out of sync since many days
Simon Valiquette un jour écrivit: Josip Rodin un jour écrivit: It should be fixed now, Ryan Murray replied to my mail to debian-admin saying he fixed it yesterday (not sure which time zone is that, but anyway). Can you please confirm? In any case, if osuosl don't have started the resynchronization at 3AM EST, we can be pretty sure that It is not fixed yet. Well, obviously, syncproxy.wna.debian.org is now pushed, but It doesn't seems to push the other mirrors. The few that are updated are probably those that still do a daily update even if they are supposed to be pushed (a good practice IMHO). http://debian.planetmirror.com/debian/project/trace/ http://debian.osuosl.org/debian/project/trace/ I sent a support ticket to osuosl Friday at 2PM EST, at the same time that I informed the mirrors mailing list. But still no answer. I also realize that I missed ftp.au.debian.org (well, I reported it indirectly as debian.planetmirror.com). About half of the primary master I reported as affected on the mailing list are now no more than 24 hours offsync. I guess I cannot do much more, not having the sysadmin email addresses. Simon Valiquette http://gulus.USherbrooke.ca
Bug#412457: mirrors: syncproxy.wna.debian.org out of sync since many days
Josip Rodin un jour écrivit: On Mon, Feb 26, 2007 at 12:09:01AM -0500, Simon Valiquette wrote: Package: mirrors Severity: important This proxy for ftp-master.debian.org seems not to be syncing anymore since the 20th of February. It should be fixed now, Ryan Murray replied to my mail to debian-admin saying he fixed it yesterday (not sure which time zone is that, but anyway). Can you please confirm? I can't, because I don't have direct access to syncproxy.wna.debian.org and that I never found a North-American mirror willing to push me (I tried many time over the years, and even offered to be the canadian master). I was using rsync://rsync.osuosl.org/debian but changed Friday. All I can do is check here: http://debian.osuosl.org/debian/project/trace/ So, if It was fixed before 2PM EST (7PM UTC), then the problem is not resolved because osuosl is still not updated. In any case, if osuosl don't have started the resynchronization at 3AM EST, we can be pretty sure that It is not fixed yet. Simon Valiquette http://gulus.USherbrooke.ca
Bug#412457: mirrors: syncproxy.wna.debian.org out of sync since many days
Package: mirrors Severity: important This proxy for ftp-master.debian.org seems not to be syncing anymore since the 20th of February. I have reported It on debian-mirrors@lists.debian.org few days ago, but there is still no answer. Since there is about 40 official mirrors affected, I consider It as a very important problem. I contacted directly debian.osuosl.org Friday at 2PM (EDT), because over 30 mirrors are syncing from them, but I guess they won't react before Monday PM. ike.egr.msu.edu is also out of sync, which might be related with this problem. ftp.us.debian.org is also affected, just in case you still have some doubt about how serious is the problem. Just after reporting the problem, I fixed my mirror, so I really report It here for you and other Debian users. Simon Valiquette http://gulus.USherbrooke.ca -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-vserver-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407496: setup-mysql -h minor usage summary error + should be executable
Package: wordpress Version: 2.0.6-1 Severity: minor If you execute: $ bash setup-mysql -h You will get a small help suggesting you to sudo sh setup-mysql -n wordpress blog.example.com But if dash is installed, it won't works as it would be interpreted as an sh script (while setup-mysql really is a bash script). So you should either replace this help line by: sudo bash setup-mysql -n wordpress blog.example.com Much better would be to makes setup-mysql executable (as it really should be) and use this line in the usage() section: sudo setup-mysql -n wordpress blog.example.com Simon Valiquette -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages wordpress depends on: ii apache [httpd]1.3.34-4 versatile, high-performance HTTP s ii apache-ssl [httpd]1.3.34-4 versatile, high-performance HTTP s ii apache2-mpm-prefork [httpd] 2.2.3-3.2 Traditional model for Apache HTTPD ii mysql-client-5.0 [virtual-mys 5.0.30-3 mysql database client binaries ii php5 5.2.0-8server-side, HTML-embedded scripti ii php5-mysql5.2.0-8MySQL module for php5 wordpress recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407501: Wrongly try to create a symlink from /srv/www/$DOMAIN
Package: wordpress Version: 2.0.6-1 Severity: minor The setup-mysql script try to create a symlink in /srv/www/$DOMAIN pointing to /usr/share/wordpress Am I wrong, or it should have been created in /var/www/ ? Since /srv/www/ don't exist by default on Debian Etch, it is harmless as most people already create their own symlink Maybe it is too late to change how it behave in Etch, so I propose to simply comment the 2 offending lines (to remove the warnings) and eventually fix it in Lenny. Here the 2 offending lines (including the rm): grep -nC1 srv /usr/share/doc/wordpress/examples/setup-mysql 74-EOF 75:ln -s /usr/share/wordpress /srv/www/$DOMAIN 76-echo Goto http://$DOMAIN to setup Wordpress -- 97-rm $CONFIG_FILE 98:rm /srv/www/$DOMAIN 99-} Simon Valiquette -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages wordpress depends on: ii apache [httpd]1.3.34-4 versatile, high-performance HTTP s ii apache-ssl [httpd]1.3.34-4 versatile, high-performance HTTP s ii apache2-mpm-prefork [httpd] 2.2.3-3.2 Traditional model for Apache HTTPD ii mysql-client-5.0 [virtual-mys 5.0.30-3 mysql database client binaries ii php5 5.2.0-8server-side, HTML-embedded scripti ii php5-mysql5.2.0-8MySQL module for php5 wordpress recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329837: mirrors: New ftp.ca.debian.org offer
Package: mirrors Followup-For: Bug #329837 -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello, I would be willing to manage ftp.ca.debian.org from my mirror. If Rafal Rzeczkowski is still willing to manage that domain, it would be great to be two canadian mirrors managing it (for increased availability). Site: gulus.USherbrooke.ca Type: leaf (would like to be pushed from the master) Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ Mirrors-from: rsync.osuosl.org Maintainer: Gulus (http://www.gulus.org) Contact address: [EMAIL PROTECTED] Country: CA Canada Location: Montréal Sponsor: Université de Sherbrooke (http://www.USherbrooke.ca), RISQ (http://www.risq.qc.ca) Bandwidth: 1000 mbps Comment: mirror all I also host many Debian related repository like backports.org, multimedia, volatile, etc. The only thing I don't host is the CD/DVD because of space issues (but I do offer all the businesscard and netinstall CD). You can quickly see what I offer by looking to the real physical URL: http://gulus.USherbrooke.ca/pub/distro/debian/ Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Linux PPC) iD8DBQFFYE3xJPE+P+aMAJIRA14pAKCEG5FmkO0t2+AJd+SSWMnnf+YJsACgq4jM SE/C7T4KAXLw90LpjjlxAQE= =dilI -END PGP SIGNATURE-
Bug#387202: cdimage.debian.org: Missing md5sum for Sarge 3.1_r3 NetInstall CD
Package: cdimage.debian.org Severity: normal The MD5SUM for the NetInstall CD and business card CD are missing, at least for the x86 architecture (the other arch I checked had it, including the 3.1_r2 x86 version). http://cdimage.debian.org/debian-cd/3.1_r3/i386/iso-cd/ It would be good to have them so that we can at least check that we downloaded the ISO properly. I am surprised it was not reported before. I sometime like to validate that the ISO on my mirror are good ones. I would suggest that you also provide a signed SHA-1 hash instead of just a MD5 hash. Finding a collision with MD5 is now very fast (less than a minute), so signing an MD5 hash just give a false sense of security in my opinion. Simon Valiquette http://www.gulus.org http://gulus.USherbrooke.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382956: mozilla: Shipping secure Mozilla in Etch would require unreasonable maintainance
Alexander Sack - Debian Bugmail un jour écriva: On Tue, Aug 29, 2006 at 04:59:04AM -0400, Simon Valiquette wrote: Maybe I worry too much for nothing, and that Mozilla 1.8 (SeaMonkey) will allow migration without any problems, but I wanted to express my concerns about it. Also, many user will never forgive you if you just blindly remove Mozilla. Thanks for pointing out your concerns. I understand it ... and we are working on it as much as possible. I would guess that migrating to seamonkey should not cause any pain. With the years, I was able to migrate my emails from a PC with Netscape to Solaris (on Sparc), then from Netscape to Mozilla (on Solaris), then to SuSE (on a PC) then later on PowerPC. But I have done so manualy, and sometime with some efforts. I also don't think it will be a problem, but I don't want to take a chance, or force the other Mozilla users to take a chance. We will have to be sure it can be done automaticaly and safely. Probably the installation program should offer the user the possibility to keep a backup copy somewhere. You can of course help by testing the package as soon as it becomes available. Sure, send me an email when it is done. I am subscribed to debian-powerpc@lists.debian.org and some other debian mailing lists, but not debian-devel, so I will not automatically know when it will become available. Because the SeaMonkey package dont exist yet, I can't follow it using the Package Tracking System. I have another G4 system I use mostly for testing purpose, so I can install experimental packages with Sid and/or Etch and also try migrating from Sarge or Woody with some old backup of my mails. Simon Valiquette http://gulus.USherbrooke.ca
Bug#382956: mozilla: Shipping secure Mozilla in Etch would require unreasonable maintainance
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Thanks for the information about Takuo. seamonkey was already uploaded, but was rejected by ftp-master. I'm reassigning to ftp.d.o. ftp-master may choose to wait some time before proceeding, which could let seamonkey become an upgrade path. Otherwise, I think that removing Mozilla now won't break unstable too badly. The main problem is eclipse (#364368), which isn't in testing since a long time anyway. Note that there should be serious bugs against all source packages in testing depending on mozilla-browser, except for about 10 mozilla-locale packages. Please provide a transition package for mozilla-browser from seamonkey, as soon as (but no earlier than) seamonkey is an adequate replacement in Debian. Mozilla is a major package with over 35% installed base in popcon. It shouldn't just be removed and leaving users without an upgrade path. I am using Mozilla and Netscape for ages (well, since I stopped surfing on Goopher web sites). For different reasons, I always disliked Firefox/Thunderbird and preferred a better integrated interface (memory is cheap anyway). Whatever, I have tons of archived email inside Mozilla, and you need to be sure Mozilla will migrate properly to SeaMonkey before removing Mozilla. Unless Etch get significantly delayed, I am not sure that you will have time for testing everything properly. Will the French version of SeaMonkey for PowerPC always migrate properly from Mozilla while updating from Sarge or Etch? Probably, but I am not a gambler. Just removing Mozilla from Etch without anything to migrate from is a major NO-GO for many people like me. I hope it is obvious for everyone here. I am actually running Etch, and if I just see the package disappearing, or if I have any doubt about the safety to migrate to SeaMonkey, I will prefer to move to Ubuntu or Slackintosh. Maybe I worry too much for nothing, and that Mozilla 1.8 (SeaMonkey) will allow migration without any problems, but I wanted to express my concerns about it. Also, many user will never forgive you if you just blindly remove Mozilla. Simon Valiquette http://gulus.USherbrooke.ca http://www.gulus.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Linux PPC) iD8DBQFE9AGqJPE+P+aMAJIRAywEAJ4p+r0Wjp0KUNOT8yBWWebbZ1QAGQCfYeuU f2QiqMBGKyjRW2wqJa0SEmI= =XQgQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292120: packagesearch segfault if debtags have never been run
Package: packagesearch Version: 1.0 Severity: normal After installing the package, when I run packagesearch in the console, I see a window warning me that I should run debtags update. After pressing the ok button, the normal search window appear. Then, if I type anyting in the search box, after a few seconds the application crash with a segfault. Once I executed sudo debtags update, the program behaved normally. Now the weird part. If after I do: apt-get remove --purge debtags Then packagesearch does'nt restart to crash. It still show the warning window, but after it terminate normally as it should (without ever going to the search window). I suspect that either --purge did'nt removed everything installed by debtags, or more probably that running debtags update changed or fixed some file readed by packagesearch. I only have PowerPC, so I will check another day if I can reproduce it on a PC or if the problem also exist on version 1.0.1 (Sid) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Versions of packages packagesearch depends on: ii apt [libapt-pkg-libc6.3- 0.5.28.1Advanced front-end for dpkg ii kdelibs4 4:3.3.2-1 KDE core libraries ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libdebtags0 0.9.8 Unified access to Debtags and APT ii libgcc1 1:3.4.3-6 GCC support library ii libqt3c102-mt3:3.3.3-7 Qt GUI Library (Threaded runtime v ii libstdc++5 1:3.3.5-5 The GNU Standard C++ Library v3 ii libtagcoll0 0.99.1-1Functions used to manipulate tagge ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
