Bug#916060: tuxmath: Starts and immediately closes
This patch fixes issue with deprecated rsvg_handle_get_desc now return
NULL value.
Tuxmath now runs fine for me.
diff -Nru t4kcommon-0.1.1/debian/changelog t4kcommon-0.1.1/debian/changelog
--- t4kcommon-0.1.1/debian/changelog 2018-05-31 22:16:05.0 +1000
+++ t4kcommon-0.1.1/debian/changelog 2019-01-05 23:19:03.0 +1100
@@ -1,3 +1,10 @@
+t4kcommon (0.1.1-4.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix loading each frame from SVG sprites (Closes: #916060)
+
+ -- Chris Donoghue Sat, 05 Jan 2019 23:19:03 +1100
+
t4kcommon (0.1.1-4) unstable; urgency=medium
* d/control:
diff -Nru t4kcommon-0.1.1/debian/patches/loadsvgsprite_numframe_load t4kcommon-0.1.1/debian/patches/loadsvgsprite_numframe_load
--- t4kcommon-0.1.1/debian/patches/loadsvgsprite_numframe_load 1970-01-01 10:00:00.0 +1000
+++ t4kcommon-0.1.1/debian/patches/loadsvgsprite_numframe_load 2019-01-05 23:19:03.0 +1100
@@ -0,0 +1,32 @@
+Description: fix loading each frame from SVG sprites
+ rsvg_handle_get_desc returns null so next sscanf segfaults. Use instead iterating
+ up from zero for id frame%d
+Author: cdono...@gmail.com
+Origin: other
+Forwarded: no
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/t4k_loaders.c
b/src/t4k_loaders.c
+@@ -213,14 +213,13 @@
+ new_sprite = malloc(sizeof(sprite));
+ new_sprite->default_img = render_svg_from_handle(file_handle, width, height, "#default");
+
+- /* get number of frames from description */
+- sscanf(rsvg_handle_get_desc(file_handle), "%d", _sprite->num_frames);
+- DEBUGMSG(debug_loaders, "load_svg_sprite(): loading %d frames\n", new_sprite->num_frames);
+-
+- for(i = 0; i < new_sprite->num_frames; i++)
+- {
+-sprintf(lay_name, "#frame%d", i);
+-new_sprite->frame[i] = render_svg_from_handle(file_handle, width, height, lay_name);
++ /* get number of frames directly. End when #frame doesn't exist */
++ new_sprite->num_frames = 0;
++ while(1) {
++sprintf(lay_name, "#frame%d", new_sprite->num_frames);
++if ( ! (rsvg_handle_has_sub(file_handle, lay_name)) ) break;
++new_sprite->frame[new_sprite->num_frames] = render_svg_from_handle(file_handle, width, height, lay_name);
++new_sprite->num_frames++;
+ }
+
+ g_object_unref(file_handle);
diff -Nru t4kcommon-0.1.1/debian/patches/series t4kcommon-0.1.1/debian/patches/series
--- t4kcommon-0.1.1/debian/patches/series 2018-05-31 22:14:02.0 +1000
+++ t4kcommon-0.1.1/debian/patches/series 2019-01-05 23:05:28.0 +1100
@@ -1 +1,2 @@
libpng16.patch
+loadsvgsprite_numframe_load
Bug#901366: activemq fails to start
Package: activemq Version: 5.15.4-1 Severity: important Dear Maintainer, ActiveMQ failed to start. A quick search on the latest release page and I found https://issues.apache.org/jira/browse/AMQ-6930 Meaning that ACTIVEMQ_OUT variable is now requred when using bin/activemq start Currently every start of activemq results in $ systemctl status activemq ● activemq.service - LSB: ActiveMQ instance Loaded: loaded (/etc/init.d/activemq; generated) Active: active (exited) since Tue 2018-06-12 14:21:44 AEST; 1s ago Docs: man:systemd-sysv-generator(8) Process: 25865 ExecStop=/etc/init.d/activemq stop (code=exited, status=0/SUCCESS) Process: 27015 ExecStart=/etc/init.d/activemq start (code=exited, status=0/SUCCESS) Jun 12 14:21:39 homerl systemd[1]: Starting LSB: ActiveMQ instance... Jun 12 14:21:44 homerl activemq[27015]: Starting ActiveMQ instance : activemq main (failed?). Jun 12 14:21:44 homerl systemd[1]: Started LSB: ActiveMQ instance. Apending into /usr/share/activemq/activemq-options file the following: ACTIVEMQ_OUT="/dev/null" activemq now starts without issue.
Bug#884771: jetty9 doesn't start anymore
Package: jetty9 Version: 9.2.22-3 Followup-For: Bug #884771 Dear Maintainer, I did a diff between 9.2.22-3 and 9.2.22-2 extracted deb files and many don't there is missing version strings in the 9.2.22-3 debian package. Perhaps issue lays there. File list diff below astached --- jetty9-2.list 2018-01-05 20:33:19.718186565 +1100 +++ jetty9-3.list 2018-01-05 20:33:25.134286663 +1100 @@ -70,7 +70,7 @@ ./usr/share/jetty9/lib/annotations/org.objectweb.asm.jar ./usr/share/jetty9/lib/apache-jsp ./usr/share/jetty9/lib/apache-jsp/jdt-core.jar -./usr/share/jetty9/lib/apache-jsp/jetty-apache-jsp-9.2.22.v20170531.jar +./usr/share/jetty9/lib/apache-jsp/jetty-apache-jsp-.jar ./usr/share/jetty9/lib/apache-jsp/org.apache.taglibs.taglibs-standard-impl.jar ./usr/share/jetty9/lib/apache-jsp/org.apache.taglibs.taglibs-standard-spec.jar ./usr/share/jetty9/lib/apache-jsp/tomcat-api.jar @@ -83,50 +83,50 @@ ./usr/share/jetty9/lib/apache-jsp/tomcat-util.jar ./usr/share/jetty9/lib/ext ./usr/share/jetty9/lib/fcgi -./usr/share/jetty9/lib/fcgi/fcgi-client-9.2.22.v20170531.jar -./usr/share/jetty9/lib/fcgi/fcgi-server-9.2.22.v20170531.jar +./usr/share/jetty9/lib/fcgi/fcgi-client-.jar +./usr/share/jetty9/lib/fcgi/fcgi-server-.jar ./usr/share/jetty9/lib/jaspi ./usr/share/jetty9/lib/jaspi/javax.security.auth.message.jar -./usr/share/jetty9/lib/jetty-alpn-client-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-alpn-server-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-annotations-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-cdi-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-client-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-continuation-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-deploy-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-http-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-io-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-jaas-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-jaspi-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-jmx-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-jndi-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-plus-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-proxy-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-quickstart-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-rewrite-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-security-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-server-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-servlet-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-servlets-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-util-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-webapp-9.2.22.v20170531.jar -./usr/share/jetty9/lib/jetty-xml-9.2.22.v20170531.jar +./usr/share/jetty9/lib/jetty-alpn-client-.jar +./usr/share/jetty9/lib/jetty-alpn-server-.jar +./usr/share/jetty9/lib/jetty-annotations-.jar +./usr/share/jetty9/lib/jetty-cdi-.jar +./usr/share/jetty9/lib/jetty-client-.jar +./usr/share/jetty9/lib/jetty-continuation-.jar +./usr/share/jetty9/lib/jetty-deploy-.jar +./usr/share/jetty9/lib/jetty-http-.jar +./usr/share/jetty9/lib/jetty-io-.jar +./usr/share/jetty9/lib/jetty-jaas-.jar +./usr/share/jetty9/lib/jetty-jaspi-.jar +./usr/share/jetty9/lib/jetty-jmx-.jar +./usr/share/jetty9/lib/jetty-jndi-.jar +./usr/share/jetty9/lib/jetty-plus-.jar +./usr/share/jetty9/lib/jetty-proxy-.jar +./usr/share/jetty9/lib/jetty-quickstart-.jar +./usr/share/jetty9/lib/jetty-rewrite-.jar +./usr/share/jetty9/lib/jetty-security-.jar +./usr/share/jetty9/lib/jetty-server-.jar +./usr/share/jetty9/lib/jetty-servlet-.jar +./usr/share/jetty9/lib/jetty-servlets-.jar +./usr/share/jetty9/lib/jetty-util-.jar +./usr/share/jetty9/lib/jetty-webapp-.jar +./usr/share/jetty9/lib/jetty-xml-.jar ./usr/share/jetty9/lib/jndi ./usr/share/jetty9/lib/jndi/javax.mail.jar ./usr/share/jetty9/lib/monitor -./usr/share/jetty9/lib/monitor/jetty-monitor-9.2.22.v20170531.jar +./usr/share/jetty9/lib/monitor/jetty-monitor-.jar ./usr/share/jetty9/lib/servlet-api-3.1.jar ./usr/share/jetty9/lib/spring -./usr/share/jetty9/lib/spring/jetty-spring-9.2.22.v20170531.jar +./usr/share/jetty9/lib/spring/jetty-spring-.jar ./usr/share/jetty9/lib/websocket -./usr/share/jetty9/lib/websocket/javax-websocket-client-impl-9.2.22.v20170531.jar -./usr/share/jetty9/lib/websocket/javax-websocket-server-impl-9.2.22.v20170531.jar +./usr/share/jetty9/lib/websocket/javax-websocket-client-impl-.jar +./usr/share/jetty9/lib/websocket/javax-websocket-server-impl-.jar ./usr/share/jetty9/lib/websocket/javax.websocket-api-1.0.jar -./usr/share/jetty9/lib/websocket/websocket-api-9.2.22.v20170531.jar -./usr/share/jetty9/lib/websocket/websocket-client-9.2.22.v20170531.jar -./usr/share/jetty9/lib/websocket/websocket-common-9.2.22.v20170531.jar -./usr/share/jetty9/lib/websocket/websocket-server-9.2.22.v20170531.jar -./usr/share/jetty9/lib/websocket/websocket-servlet-9.2.22.v20170531.jar +./usr/share/jetty9/lib/websocket/websocket-api-.jar
Bug#678262: mdadm: fails to honour INITRDSTART='none' in /etc/default/mdadm
Package: mdadm Version: 3.2.5-1 Severity: critical Justification: breaks the whole system Dear Maintainer, It looks like the /usr/share/initramfs-tools/hooks/mdadm fails to honour the setting of INITRDSTART='none' in /etc/default/mdadm which led to an unbootable system. The initramfs panic'ed from the script in /usr/share/initramfs-tools/scripts/local-top/mdadm. It does continue on when the exiting out of the initrd dropped to shell. With none setting that above files are put in the initrd $ lsinitramfs /boot/initrd.img-3.2.0-2-amd64 | grep mdadm etc/mdadm etc/mdadm/mdadm.conf sbin/mdadm scripts/local-top/mdadm Which aren't required at all in mdadm isn't required to be started at initrd time. I added at line 80 of /usr/share/initramfs-tools/hooks/mdadm [ $INITRDSTART = none ] exit 0 which allowed my system to boot through fine. But these still leaves me with $ lsinitramfs /boot/initrd.img-3.2.0-2-amd64 | grep mdadm sbin/mdadm scripts/local-top/mdadm Which aren't needed due to no requirement of mdadm in initrd. Thanks Chris -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mdadm depends on: ii debconf 1.5.44 ii initscripts 2.88dsf-27 ii libc62.13-33 ii lsb-base 4.1+Debian7 ii makedev 2.3.1-91 ii udev 175-3.1 Versions of packages mdadm recommends: ii module-init-tools 8-2 ii qmail-run [mail-transport-agent] 2.0.2.0 mdadm suggests no packages. -- debconf information: * mdadm/autostart: true * mdadm/initrdstart: all mdadm/initrdstart_notinconf: false mdadm/initrdstart_msg_errexist: mdadm/initrdstart_msg_intro: mdadm/initrdstart_msg_errblock: * mdadm/start_daemon: true * mdadm/mail_to: root mdadm/initrdstart_msg_errmd: mdadm/initrdstart_msg_errconf: * mdadm/autocheck: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592315: firefox/chromium fails with libnss3-1d from unstable
Package: libnss3-1d Version: 3.12.7-1 Severity: normal Tags: sid This fails on chromium and firefox on certain https sites. e.g. going to https://www.citylink.com.au gives error --- This webpage is not available. The webpage at https://www.citylink.com.au/ might be temporarily down or it may have moved permanently to a new web address. More information on this error Below is the original error message Error 2 (net::ERR_FAILED): Unknown error. --- The site also fails in iceweasel with error --- Secure Connection Failed An error occurred during a connection to www.citylink.com.au. SSL received a malformed Server Key Exchange handshake message. (Error code: ssl_error_rx_malformed_server_key_exch) * The page you are trying to view can not be shown because the authenticity of the received data could not be verified. * Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site. --- Installing back version 3.12.6-3 makes things work again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592315: firefox/chromium fails with libnss3-1d from unstable
On Mon, Aug 09, 2010 at 10:27:20AM +0200, Mike Hommey wrote: Long story short: the server is insecure (see the upstream bug below). A workaround for iceweasel is given here: https://bugzilla.mozilla.org/show_bug.cgi?id=583337#c6 As I use chromium the workaround provided of setting ssl3.dhe to false isn't going to work. Probably modutils from NSS security tools but I didn't get much time for reading or playing with that. So, I thought I'd try the suggestion as given in this bug report in particular: --- I suggest that Mozilla ask portal-plumprod.cgc.enbridge.com to fix this server configuration problem. The simplest fix is probably to disable all DHE cipher suites. --- I wrote to Citylink contact us myself and thought that as I'm a really valued customer it might be worth a shot to let then know to improve their very weak security. Although I'm already thinking it's going to be a very long shot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
Following up: Upgrading worked fine when i did this on my other computer just today. I don't know what happened or what was different on my other computer that it didn't work previously. The first instance was from the util-linux problem and that I hadn't updated but as that's all fine. As upgrading in exactly the same way on another computer was fine for me then this should be closed. Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
A follow-up on this: After deleting entries from /etc/udev/rules.d that are in /lib/udev/rules.d this issue is completely solved. One version of the debian packages installs files /etc/udev/rules.d/* but in later versions these files are no longer used and only the /lib/udev/rules.d entries are installed and contained within the package. These /etc/udev/rules.d files have not been modified at all from when contained within the debian package and installed. When upgrading to a package where these files are no longer part of the package they remain on disk. First I tried dpkg --force-all --purge udev when the 146 debian package was installed but the /etc/udev/rules.d files remained so it requied a manual deletion of these files. As 146 had changed to using blkid instead of vol_id for uuid entries my boot was broken as the remaining /etc/udev/rules.d files were an older udev rules version using vol_id program. Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
This is hard to believe since preinst deletes the files if they are
unmodified (and you are the only one who is experiencing this).
Though, according to the preinst script, shouldn't the file be renamed if it
was modified? This also didn't occur on my system. True that, so far, I'm the
only bug reporter experiencing this.
Anyway, I also have a laptop which is installed debian testing. udev is
installed as version 125-7 as I put it on hold a while back and I forgotten
why. But, I only update this laptop every one or two months.
On the laptop:
$ md5sum /etc/udev/rules.d/60-persistent-storage.rules
1f478f185e658dc887f196147ef3857b /etc/udev/rules.d/60-persistent-storage.rules
And (as per preinst script):
$ dpkg-query -W -f='${Conffiles}' udev | grep 60-persistent-storage
/etc/udev/rules.d/60-persistent-storage.rules 1f478f185e658dc887f196147ef3857b
/etc/udev/rules.d/60-persistent-storage-tape.rules
db3a5c1e5075450c3aeb4e283f8fa109
So, this one should be deleted according the the preinst script.
I'm going to upgrade this within the next day or so and forcefully the udev
package that is on hold.
I'll follow up how that goes.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
Please also report the output of: ls -l /lib/udev/rules.d/ /etc/udev/rules.d/ /dev/disk/*/ After being able to see a root filesystem and boot with 146 my system does map correctly my dmraid entries. But this works fine with 141 udev. When my /dev/mapper entry can't be mounted with 146 udev I'm dropped to a maintenance shell. The first attachment is before I have run dmraid -a y from the maintenence shell and the second is when after dmraid -a. I then do a mount -a to mount all partitions and exit the shell to successfully boot. The listing generated there is exactly the same as the second listing. The first results have no by-label and no by-uuid entries. After the dmraid call I then get the single uuid entry being the raid. after a boot (with 146, if you downgraded udev then your system may be broken). My current grub entry uses root=/dev/disk/by-id/entry to boot when having udev 146 installed. After logging on and then dpkg -i udev 141 both the UUID grub entry and the /dev/disk/by-id entries work fine. It's a bit weird as the raid also doesn't start up now. I hadn't noticed the dmraid failure as after doing a manual edit of the grub upon the first failure I installed the old udev package only and updated grub to have the by-id entry also as a boot listing. The system boots without a single problem with the old udev installed. /dev/disk/by-id/: total 0 lrwxrwxrwx 1 root root 9 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0 - ../../sdc lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part1 - ../../sdc1 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part2 - ../../sdc2 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part3 - ../../sdc3 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part5 - ../../sdc5 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part6 - ../../sdc6 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part7 - ../../sdc7 lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-ST3200822AS_5LJ0V7P0-part8 - ../../sdc8 lrwxrwxrwx 1 root root 9 Oct 14 17:50 ata-WDC_WD10EACS-00D6B1_WD-WCAU43716050 - ../../sdb lrwxrwxrwx 1 root root 9 Oct 14 17:50 ata-WDC_WD10EACS-00D6B1_WD-WCAU43746852 - ../../sda lrwxrwxrwx 1 root root 10 Oct 14 17:50 ata-WDC_WD10EACS-00D6B1_WD-WCAU43746852-part1 - ../../sda1 lrwxrwxrwx 1 root root 9 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0 - ../../sdc lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part1 - ../../sdc1 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part2 - ../../sdc2 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part3 - ../../sdc3 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part5 - ../../sdc5 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part6 - ../../sdc6 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part7 - ../../sdc7 lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_ST3200822AS_5LJ0V7P0-part8 - ../../sdc8 lrwxrwxrwx 1 root root 9 Oct 14 17:50 scsi-1ATA_WDC_WD10EACS-00D6B1_WD-WCAU43716050 - ../../sdb lrwxrwxrwx 1 root root 9 Oct 14 17:50 scsi-1ATA_WDC_WD10EACS-00D6B1_WD-WCAU43746852 - ../../sda lrwxrwxrwx 1 root root 10 Oct 14 17:50 scsi-1ATA_WDC_WD10EACS-00D6B1_WD-WCAU43746852-part1 - ../../sda1 /dev/disk/by-path/: total 0 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-0:0:0:0 - ../../scd0 lrwxrwxrwx 1 root root 9 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0 - ../../sdc lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part1 - ../../sdc1 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part2 - ../../sdc2 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part3 - ../../sdc3 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part5 - ../../sdc5 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part6 - ../../sdc6 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part7 - ../../sdc7 lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:00:0a.0-scsi-1:0:0:0-part8 - ../../sdc8 lrwxrwxrwx 1 root root 9 Oct 14 17:50 pci-:02:0c.0-scsi-0:0:0:0 - ../../sda lrwxrwxrwx 1 root root 10 Oct 14 17:50 pci-:02:0c.0-scsi-0:0:0:0-part1 - ../../sda1 lrwxrwxrwx 1 root root 9 Oct 14 17:50 pci-:02:0c.0-scsi-1:0:0:0 - ../../sdb /etc/udev/rules.d/: total 156 lrwxrwxrwx 1 root root19 Jul 1 12:46 025_libgphoto2.rules - ../libgphoto2.rules -rw-r--r-- 1 root root 1908 Mar 19 2009 11-hplj10xx.rules -rw-r--r-- 1 root root 3586 Apr 1 2009 50-udev.rules -rw-r--r-- 1 root root 495 May 21 09:10 56-hpmud_support.rules -rw-r--r-- 1 root root 1543 Apr 1 2009 60-persistent-input.rules -rw-r--r-- 1 root root 1582 Apr 1 2009 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 4554 Apr 1 2009 60-persistent-storage.rules -rw-r--r-- 1 root root 523 Apr 1 2009
Bug#550792: udev: /dev/disk/by-uuid problem
Upon reading from the source of udev and finding the information in the NEWS file about uuids I thought perhaps that the problem lay from changes in udev being now included in util-linux as was sort of indicated. I hadn't looked into it further myself so what I gave was purely informational and to be used as a pointer as here's what I had found to use as you will. It was not any jumped to conclusion and as purely informational if it were wrong it could have quite easily just been ignored. In my emails I had stated twice and the subject indicates that links in /dev/disk/by-uuid are not created during boot-up presumubly by the initramfs as after a delay and a message that the root system can't be found I am dropped into the initrd shell. So, therein lies the problem and seemingly this problem lays within udev and the version (and it's data) that is put into the created initramfs via the initramfs hooks when run from the initramfs at boot up. using a boot option of linux ... root=UUID=my_uuid ... within my grub.cfg file fails for every debian packages 146 version but works fine with version 141. When dropped to the initrd shell ls /dev/disk gives me no entry at all of /dev/disk/by-uuid when using version 146 udev but for version 141 these entries exists as does the the uuid of my root drive within this directory. So, I suspect that is why my system is unable to boot as this entry doesn't exist. As grub install setup defaults to using uuids this could potentially lead to all systems using grub to fail to boot when used with the current version of udev 146 as 141 works fine. On Tue, Oct 13, 2009 at 04:32:46AM +0200, Marco d'Itri wrote: On Oct 13, Chris Donoghue cdono...@gmail.com wrote: So that means that vol_id does exist but now it's not in udev but in util-linux instead. It's easy to be confused by all that. Since you appear to be so easily confused then I suggest you stop jumping to conclusions and answer my questions instead. vol_id has been replaced by blkid, and you still have not explained what exactly is wrong with your initramfs. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
vol_id has been replaced by blkid, and you still have not explained what exactly is wrong with your initramfs. If you mean here that blkid is in the initramfs then this isn't so. I think it should be from the file /usr/share/initramfs-tools/hooks/util-linux which has line copy_exec /sbin/blkid. Running update-initramfs -u -v I get the following: Available versions: 2.6.30-2-amd64 Keeping /boot/initrd.img-2.6.30-2-amd64.dpkg-bak update-initramfs: Generating /boot/initrd.img-2.6.30-2-amd64 /usr/share/initramfs-tools/hooks/util-linux ignored: not alphanumeric or '_' file Adding module /lib/modules/2.6.30-2-amd64/kernel/drivers/usb/host/ehci-hcd.ko For some reason it does like the - in the file. Changing from /usr/share/initramfs-tools/hooks/util-linux to /usr/share/initramfs-tools/hooks/utillinux instead and running update-initramfs -u -v I get the following (a long way down in the results): Calling hook utillinux Adding binary /sbin/blkid blkid is now in my initrd. This above problem isn't a udev problem but util-linux hook script fix up. I'll submit a util-linux bug report sometime tomorrow if there isn't a similar one already on this. I still have booting problem so this still seems it is a udev issue as yet. In the initrd phase the links in /dev/disk/by-uuid aren't created as indicated should happen in the 60-persistent-storage.rules file from udev and it did when using the vol_id program call from udev 141 package. Similarly, any /dev/disk/by-label links are also not created from this rule file. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
On Tue, Oct 13, 2009 at 02:18:08PM +0200, Julien Cristau wrote: That's #544669, fixed days ago. Great. I hadn't got around to starting a bugreport at all on that yet. I'd stopped upgrading due to being unable to boot into the system with the udev problem so still had that issue in util-linux. Upgrading now and will see if I can boot with uuid entries after that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
Package: udev Version: 146-5 Severity: critical Justification: breaks the whole system This is in all versions of 146 udev debian packages. The initramfs hook file extra/initramfs.hook included in debian udev packages needs fixing. 0.141 versions contains at the bottom: for program in /lib/udev/*_id; do copy_exec $program /lib/udev done 146 version contains: for program in ata_id edd_id path_id scsi_id usb_id; do copy_exec /lib/udev/$program /lib/udev done This list needs to at least include vol_id (or revert to the 0.141 version of this hook) as this obtains uuid entries for present disks in which udev then creates /dev/disk/by-uuid links. I raise this as critial as grub version two defaults to using UUIDs as root disks so without vol_id included no uuid entries can be found so any grub2 installed system will completely unbootable. I feel uuids make more sense and my fstab uses /dev/disk/by-uuid so that my hard-drive no matter the system I boot my hard-drive from and no matter if i use the drive as a PATA or SATA or even as a USB device which is especially useful especially for boot anywhere debian installs. Thanks Chris Donoghue -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550792: udev: /dev/disk/by-uuid problem
Hi Marco, udev is always one of those system killers From the 146 udev sources in the NEWS file: udev 142 Bugfixes. The program vol_id and the library libvolume_id are removed from the repository. Libvolume_id is merged with libblkid from the util-linux-ng package. Persistent disk links for label and uuid depend on the util-linux-ng version (2.15) of blkid now. Older versions of blkid can not be used with udev. So that means that vol_id does exist but now it's not in udev but in util-linux instead. It's easy to be confused by all that. This will need to be reassigned also to the util-linux maintainers then. util-linux needs to have vol_id and libvolume_id built. udev uses this to create uuid names and links in /dev/by-uuid. Perhaps this will mean a new libvolume package or others? The hook to still copy in /lib/udev/vol_id into the initrd will still be required for use by udev as otherwise uuid names fail hence grub (version 2 using default configs) will fail resulting in a unbootable system. That could possibly mean the util_linux source created package build containing /lib/udev/vol_id may need to be a pre-depends for udev and the hook in udev to still include the vol_id I mentioned. Also there is still /lib/udev/cdrom_id that isn't included in initrd hook in the udev package. That could possibly be needed also. Thanks Chris On Tue, Oct 13, 2009 at 02:22:21AM +0200, Marco d'Itri wrote: On Oct 13, Chris Donoghue cdono...@gmail.com wrote: This list needs to at least include vol_id (or revert to the 0.141 version of this hook) as this obtains uuid entries for present disks in which udev then creates /dev/disk/by-uuid links. You are obviously confused, since vol_id does not exist anymore. What is missing from your initramfs, exactly? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481224: Skype cannot find libQtDBus.so.4 after upgrade
Hi, Version 2.4 did not fix the problem with skype. Now the following error occurs: skype: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory I see the changelog of libqt-x11 version 4.4.0-1 * Rename libqt4-gui to libqtgui4 (new package). So libqtgui4 may also need to be included. Thanks Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447535: centerim-utf8: Segfaults instead of connecting to Yahoo!
Perhaps this is fine on i386 version and not amd64.
I had the following backtrace on amd64:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b2488ece270 (LWP 10505)]
0x2b248748f4f0 in strcmp () from /lib/libc.so.6
(gdb) backtrace
#0 0x2b248748f4f0 in strcmp () from /lib/libc.so.6
#1 0x00671ee4 in _yahoo_assign_server_settings (ap=0x7fff26115a00)
at libyahoo2.c:296
#2 0x0067b097 in yahoo_init_with_attributes (
username=0xb47c88 , password=0xb48188 ) at libyahoo2.c:3408
#3 0x0052e262 in yahoohook::connect (this=0x98a100)
at yahoohook.cc:148
#4 0x0052c40d in yahoohook::setautostatus (this=0x98a100,
st=available) at yahoohook.cc:455
#5 0x00514df2 in abstracthook::setstatus (this=0x98a100,
st=available) at abstracthook.cc:75
#6 0x00412d51 in centerim::changestatus (this=0x9876e0)
at centerim.cc:476
#7 0x004132c1 in centerim::mainloop (this=0x9876e0)
at centerim.cc:191
#8 0x00415bf6 in centerim::exec (this=0x9876e0)
at centerim.cc:106
#9 0x004b1f84 in main (argc=3, argv=0x7fff261172c8)
at centermain.cc:61
(gdb)
The check on key variable is for NULL to indicate the end of the
va_list as passed a few calls back. It seems the NULL isn't coming through
as a NULL. According to the man page:
If there is no next argument, or if type is not compatible with the
type of the actual next argument (as promoted according to the
default argument promotions), random errors will occur.
On line 3416 of libyahoo2/libyahoo.c file
return yahoo_init_with_attributes(username, password, NULL);
Probably this NULL doesn't come through as an expected char * type in
_yahoo_assign_server_settings function. I believe that when NULL is
passed it is thought of as an int but we want a char * in later calls.
This would explain an amd64 error and not a i386 one if such was the
case. Also, this error was never there before but is now. I think this
might be becuase GCC is now version 4.2.2 whereas previously compiled
versions of centerim was with 4.2.1. (So va_arg handling has changed in
the newer gcc 4.2.2?)
To fix I simply replace that line
return yahoo_init_with_attributes(username, password, (char *) NULL);
Similarly in the file src/hooks/yahoohook.cc on line 146
cid = yahoo_init_with_attributes(acc.nickname.c_str(),
acc.password.c_str(),
pager_host, acc.server.c_str(),
pager_port, acc.port, NULL);
Should be
cid = yahoo_init_with_attributes(acc.nickname.c_str(),
acc.password.c_str(),
pager_host, acc.server.c_str(),
pager_port, acc.port, (char *) NULL);
I've attached patches.
It all built fine here and works without crashes for me now.
A good Friday night spent at the computer. :)
Also perhaps this needs to be changed in the libyahoo2 sources also (and
upstream? if that could be forwarded on)
Thanks
Chris Donoghue
diff -Naur centerim-4.22.1.old/libyahoo2/libyahoo2.c centerim-4.22.1/libyahoo2/libyahoo2.c
--- centerim-4.22.1.old/libyahoo2/libyahoo2.c 2007-10-04 07:42:12.0 +1000
+++ centerim-4.22.1/libyahoo2/libyahoo2.c 2007-10-26 21:20:52.832436381 +1000
@@ -3413,7 +3413,7 @@
int yahoo_init(const char *username, const char *password)
{
- return yahoo_init_with_attributes(username, password, NULL);
+ return yahoo_init_with_attributes(username, password, (char *) NULL);
}
struct connect_callback_data {
diff -Naur centerim-4.22.1.old/src/hooks/yahoohook.cc centerim-4.22.1/src/hooks/yahoohook.cc
--- centerim-4.22.1.old/src/hooks/yahoohook.cc 2007-10-04 07:42:12.0 +1000
+++ centerim-4.22.1/src/hooks/yahoohook.cc 2007-10-26 21:20:31.588836054 +1000
@@ -145,7 +145,7 @@
cid = yahoo_init_with_attributes(acc.nickname.c_str(), acc.password.c_str(),
pager_host, acc.server.c_str(),
- pager_port, acc.port, 0);
+ pager_port, acc.port, (char *) NULL);
yahoo_login(cid, stat2int[manualstatus]);
Bug#369627: fglrx-driver: More build-depends are required
Package: fglrx-driver Version: 8.24.8-1 Severity: important Justification: fails to build from source I was unable to build the source package fglrx-driver. It had a segfault when building the manpages. Once I installed docbook-xsl the build worked perfectly so I'm assuming this is a additionally required build-depends. Thanks Chris -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363242: Dependancy problems in sarge efax package
Package: efax Severity: normal In SARGE sarge the depends on efax are libpaperg | libpaper-utils But libpaper1 provides libpaperg. The actual libpaperg dummy package depends on both libpaper-utils and libpaper1. efax is not usuable if libpaper1 is installed first as this the dependancy is fulfilled but is wrong. It must be that libpaper-utils is a definite dependancy as fax fails without it with the following error # fax view mypage /usr/bin/fax: line 1: paperconf: command not found Error: PAGE= not valid. i.e. proper dependancy requirement would be just the libpaper-utils where the paperconf command is found. Thanks Chris -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362068: wmctrl: -l option is broken on amd64
Package: wmctrl Version: 1.07-5 Severity: important Tags: patch This might also reopen #344080: wmctrl: -d option is broken on amd64 From the following mail archive with subject Re: 64 bit implementation See: http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00067.html In partilar the section: When the X window system was ported to 64-bit architectures, a rather peculiar design decision was made. 32-bit quantities such as Window IDs, atoms, etc, were kept as longs in the client side APIs, even when long was changed to 64 bits. So all 32-bit returns are of 64 bits in size. I believe this would render recasting as CARD32 useless on big-endian machines. The patch applied to main.c file needs to be undone and I have supplied a patch that works for me (tested on x86_64 and x86). The notes I also decribed above are in the patch :) Thanks Chris Donoghue -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages wmctrl depends on: ii libc6 2.3.6-5GNU C Library: Shared libraries an ii libglib2.0-0 2.10.1-2 The GLib library of C routines ii libice6 6.9.0.dfsg.1-6 Inter-Client Exchange library ii libsm66.9.0.dfsg.1-6 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li ii libxmu6 6.9.0.dfsg.1-6 X Window System miscellaneous util wmctrl recommends no packages. -- debconf-show failed main.patch.gz Description: Binary data
Bug#353711: vnc4server: AMD64 patch to enable build and working binary
Package: vnc4server Version: 4.1.1+X4.3.0-3 Followup-For: Bug #353711 Here is a patch to apply to a already debian patched source tree. Version 4.1.1+X4.3.0-3. This built a working AMD64 binary for the server and view on my AMD64. It needs tidying up as some files that are patched probably don't need it (I saw one that had a patch applied and in the line above it was already there..) This was taken from the Fedora source rpm patches that I applied rather quickly to the debian patched source tree just so I could get a working server and viewer binary. Hopefully this is found to be usefull. Thanks Chris -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages vnc4server depends on: ii libc6 2.3.6-1GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-9 GCC support library ii libice6 6.9.0.dfsg.1-4 Inter-Client Exchange library ii libsm66.9.0.dfsg.1-4 X Window System Session Management ii libstdc++64.0.2-9The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxtst6 6.9.0.dfsg.1-4 X Window System event recording an ii vnc-common3.3.7-8Virtual network computing server s ii vnc4-common [vnc-common] 4.1.1+X4.3.0-1 Virtual network computing server s ii xbase-clients 6.9.0.dfsg.1-4 miscellaneous X clients ii xserver-common6.9.0.dfsg.1-4 files and utilities common to all ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages vnc4server recommends: ii xfonts-base 6.9.0.dfsg.1-4 standard fonts for X -- no debconf information PATCH_vnc4-4.1.1+X4.3.0-3.diff.gz Description: Binary data
Bug#321644: mozilla-browser: mozilla 1.7.10 version crashes almost immediately and all other browsers that use the mozilla core crash with similar frequency
Subject: mozilla-browser: mozilla 1.7.10 version crashes almost immediately and all other browsers that use the mozilla core crash with similar frequency Package: mozilla-browser Version: 2:1.7.10-1 Severity: normal The architecture-dependant build environments that are meant to be set up in debian/rules file are not actually set up. DEB_BUILD_ARCH variable is not anywhere in this file. This is causing Mozilla, Galeon, Epiphany-browser (and most likely all other that use the mozilla core) to crash with very high frequency (gcc has buggy AMD64 -O2 optimisation on gcc4.0?). This would effect all architectures built (except i386?). Adding this and rebuilding fixes the constant crash problems on all above-stated browsers on AMD64. Thanks Chris Donoghue -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages mozilla-browser depends on: ii debconf 1.4.56 Debian configuration management sy ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.1-3 GCC support library ii libglib2.0-0 2.6.6-1The GLib library of C routines ii libgtk2.0-0 2.6.9-1The GTK+ graphical user interface ii libnspr4 2:1.7.10-1 Netscape Portable Runtime Library ii libpango1.0-0 1.8.2-1Layout and rendering of internatio ii libstdc++64.0.1-3The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-4 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-4 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxp66.8.2.dfsg.1-4 X Window System printing extension ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-4 X Toolkit Intrinsics ii psmisc21.6-1 Utilities that use the proc filesy ii xlibs 6.8.2.dfsg.1-4 X Window System client libraries m ii zlib1g1:1.2.3-1 compression library - runtime Versions of packages mozilla-browser recommends: ii mozilla-psm 2:1.7.10-1 The Mozilla Internet application s ii myspell-bg [myspell-dictionar 3.0-4 The Bulgarian dictionary for myspe ii myspell-en-us [myspell-dictio 20030813-3 English (US) dictionary for myspel -- debconf information: * mozilla/dsp: esddsp mozilla/locale_auto: true * mozilla/prefs_note: Send instant messages to your online friends http://au.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318357: centericq-utf8: Segfault on yahoo login for 4.20.0-7
Hi Julien, Ok did as you asked and installed three of the four packages built centericq_4.20.0-7_amd64.deb, centericq-common_4.20.0-7_amd64.deb, and centericq-utf8_4.20.0-7_amd64.deb Run it. And... it worked perfectly! Putting back the old packages as downloaded (i was having a bad day so I thought maybe my computer was also having the exact same problem and would work fine now :) ) dpkg -i /var/cache/apt/archives/centericq_4.20.0-7_amd64.deb /var/cache/apt/archives/centericq-common_4.20.0-7_amd64.deb /var/cache/apt/archives/centericq-utf8_4.20.0-7_amd64.deb Running in gdb: Program received signal SIGSEGV, Segmentation fault. 0x0065f5f0 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string__gnu_cxx::__normal_iteratorchar*, std::string The useless backtrace here: #0 0x0065f5f0 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string__gnu_cxx::__normal_iteratorchar*, std::string () #1 0x005548c7 in std::operator+char, std::char_traitschar, std::allocatorchar () #2 0x004b2a22 in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x004b3eb7 in std::operator+char, std::char_traitschar, std::allocatorchar () ... With a lot of other useless non-debugging information. I then rebuilt from the source without applying the debug stripping patch and all is fine. I have no idea what might be the problem in this case. Just the the binary packages as i downloaded do not work. Strange I have nothing left to say except, again ... Strange. Thanks Chris Send instant messages to your online friends http://au.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318357: centericq-utf8: Segfault on yahoo login for 4.20.0-7
Hi Julien No problem. Here is what was printed. g++ (GCC) 4.0.1 (Debian 4.0.1-2) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It is version 4. Like you thought. Thanks Chris Hum this seems to be a transition to g++ 4.0 problem. Can you run g++ --version on your system ? Send instant messages to your online friends http://au.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318357: centericq-utf8: Segfault on yahoo login for 4.20.0-7
Package: centericq-utf8 Version: 4.20.0-7 Severity: normal Debian packages version 4.20.0-7 seem to always segfault on yahoo login only (MSN, icq seem to work fine, I didn't check others). Package version 4.20.0-6 worked fine. This is for both centericq-utf8 and centericq packages. Sorry, no back-trace at the moment. I can sent one later if you require. It just seems the latest patch applied to this version may have broken yahoo login. Thanks Chris -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-amd64-2 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages centericq-utf8 depends on: ii centericq-common4.20.0-7 A text-mode multi-protocol instant ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcurl37.14.0-2 Multi-protocol file transfer libra ii libgcc1 1:4.0.1-2GCC support library ii libgnutls11 1.0.16-13.1 GNU TLS library - runtime library ii libgpg-error0 1.0-1library for common error values an ii libgpgme11 1.0.2-1 GPGME - GnuPG Made Easy ii libidn110.5.13-1.0 GNU libidn library, implementation ii libncursesw55.4-8Shared libraries for terminal hand ii libssl0.9.7 0.9.7g-1 SSL shared libraries ii libstdc++6 4.0.1-2 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.2-8compression library - runtime Versions of packages centericq-utf8 recommends: ii amaya [www-browser] 8.5-1Web Browser, HTML Editor and Testb ii dillo [www-browser] 0.8.3-1 GTK-based web browser ii epiphany-browser [www-brows 1.6.4-1 Intuitive GNOME web browser ii galeon [www-browser]1.3.21-6 GNOME web browser for advanced use ii konqueror [www-browser] 4:3.3.2-1KDE's advanced File Manager, Web B ii lynx [www-browser] 2.8.5-2 Text-mode WWW Browser ii mozilla-browser [www-browse 2:1.7.8-1The Mozilla Internet application s ii mozilla-firefox [www-browse 1.0.4-3 lightweight web browser based on M ii sox 12.17.7-2A universal sound sample translato ii w3m [www-browser] 0.5.1-3 WWW browsable pager with excellent ii w3mmee [www-browser]0.3.p24.20-2 WWW browsable pager with excellent -- no debconf information Send instant messages to your online friends http://au.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300831: mueller7accent-dict: Phonetic Transcription to display correct UTF8 for mueller dict packages
Subject: mueller7accent-dict: Phonetic Transcription to display correct UTF8
for mueller dict packages
Package: mueller7accent-dict
Version: 2002.02.27-3.2
Severity: normal
Tags: patch
*** Please type your report below this line ***
This could also be considered as extension of bug #92351 and is probably
just a wishlist.
The phonetic transcription of some words do not display correctly.
e.g.
dog
[dg]
1. _n.
1: , ; Greater (lesser) Dog ..
Should display:
dog
[dg]
1. _n.
1: , ; Greater (lesser) Dog ..
In fact even some trascriptions are deleted in the to-dict.sh script.
e.g.
bread
1. _n.
1: ; _.
Whereas keeping the phonetic transcription would display (by simply
removing the --no-trans section from the debian/rules file)
bread
[bred]
1. _n.
1: ; _.
Included is a patch to go against the debian patched source.
Added is a perl script that Fixes the phonetic transcriptions by
modifying the incorrect UTF8 bytes and rewriting them as their
(hopefully) correct IPA UTF8 counterpart.
This is more a completeness issue so that transcriptions
are in fact displayed correctly.
Not sure if keeping the transcriptions will break any required dict
format. Also there will be the additional requirement of needing perl
to build successfully. It should work for any perl version 5.6 and up.
Hopefully someone might find this useful.
Thanks
Chris Donoghue
diff -Naur mueller.orig/debian/rules mueller/debian/rules
--- mueller.orig/debian/rules 2005-03-18 20:32:37.0 +1100
+++ mueller/debian/rules2005-03-22 12:19:50.0 +1100
@@ -21,17 +21,22 @@
# patch does not set executable flag
chmod a+x debian/scripts/to-dict.sh
+ chmod a+x debian/scripts/upgrade_trans.pl
- debian/scripts/to-dict.sh --no-trans Mueller7accentGPL.koi
mueller7accent.notr
- debian/scripts/to-dict.sh --src-data mueller7accent.notr
mueller7accent.data
+ # Keep the phonetic transcription. Most stayed anyway, so let's just
keep them all. The phonetic transription is upgraded to correct UTF8 encoding
in the to-dict.sh using perl program
+ # debian/scripts/to-dict.sh --no-trans Mueller7accentGPL.koi
mueller7accent.notr
+ # debian/scripts/to-dict.sh --src-data mueller7accent.notr
mueller7accent.data
+ debian/scripts/to-dict.sh --src-data Mueller7accentGPL.koi
mueller7accent.data
debian/scripts/to-dict.sh --data-dict mueller7accent.data mueller7accent
-rm -f mueller7.data mueller7.notr
debian/scripts/to-dict.sh --expand-index mueller7accent.index
mueller7accent.index.exp
sort -k 1,1 mueller7accent.index.exp mueller7accent.index
-rm -f mueller7accent.index.exp
- debian/scripts/to-dict.sh --no-trans Mueller7GPL.koi mueller7.notr
- debian/scripts/to-dict.sh --src-data mueller7.notr mueller7.data
+ # Keep the phonetic transcription. Most stayed anyway, so let's just
keep them all. The phonetic transription is upgraded to correct UTF8 encoding
in the to-dict.sh using perl program
+ # debian/scripts/to-dict.sh --no-trans Mueller7GPL.koi mueller7.notr
+ # debian/scripts/to-dict.sh --src-data mueller7.notr mueller7.data
+ debian/scripts/to-dict.sh --src-data Mueller7GPL.koi mueller7.data
debian/scripts/to-dict.sh --data-dict mueller7.data mueller7
-rm -f mueller7.data mueller7.notr
debian/scripts/to-dict.sh --expand-index mueller7.index
mueller7.index.exp
diff -Naur mueller.orig/debian/scripts/to-dict.sh
mueller/debian/scripts/to-dict.sh
--- mueller.orig/debian/scripts/to-dict.sh 2005-03-18 20:32:37.0
+1100
+++ mueller/debian/scripts/to-dict.sh 2005-03-22 12:19:50.0 +1100
@@ -13,6 +13,9 @@
DICTFMT=`which dictfmt`
DICTZIP=`which dictzip`
+# and upgrade phonetics transcription perl script
+UPGTRANS=`dirname $0`/upgrade_trans.pl
+
INFO () {
echo
to-dict, version $version ($versiondate).
@@ -166,6 +169,7 @@
# -s $TITLE $3 $2 || exit 1
recode -f KOI8-RU..UTF-8 $2 |\
+LC_ALL=C $UPGTRANS |\
LOCPATH=locale dictfmt -p --allchars --locale ru_RU.utf-8\
-u http://www.chat.ru/~mueller_dic; -s $TITLE $3
diff -Naur mueller.orig/debian/scripts/upgrade_trans.pl
mueller/debian/scripts/upgrade_trans.pl
--- mueller.orig/debian/scripts/upgrade_trans.pl1970-01-01
10:00:00.0 +1000
+++ mueller/debian/scripts/upgrade_trans.pl 2005-03-22 14:31:39.0
+1100
@@ -0,0 +1,34 @@
+#!/usr/bin/perl
+
+while(STDIN)
+{
+ $linemod=$_;
+ $linemod=~s/\[(.*?)\]/pronmod($)/eg;
+ print $linemod;
+
+}
+
+sub pronmod
+{
+$phword=$_[0]; $word=$phword;
+$chf=chr(0x51); $cht=chr(0xc3).chr(0xa6); $phword=~s/$chf/$cht/g;
+$chf=chr(0x41); $cht=chr(0xc9).chr(0x91); $phword=~s/$chf/$cht/g;
+$chf=chr(0xd0).chr(0xab); $cht=chr(0xcb).chr(0x90); $phword=~s/$chf/$cht/g;
+$chf=chr(0xe2
