Bug#638208: [Pkg-fglrx-devel] Bug#638208: iceweasel crashes, X-server crashes also
Hello Patrick, On Sat, 04 Aug 2012 19:21:03 +0200 Patrick Matthäi pmatth...@debian.org wrote: Am 17.03.2012 14:48, schrieb Jörg Schütter: Hello Michael, On Fri, 16 Mar 2012 17:18:21 -0400 Michael Gilbert michael.s.gilb...@gmail.com wrote: The backtrace looks an awful lot like the one from the xv extension crash, which was fixed in 12-2. I wonder if your iceweasel is attempting to load that somehow? If so, this would be fixed by the current release that's already made it to testing. With 12-2 the result is the same. Could you please give us a feedback with the fglrx-driver 1:12-6+point-1 release? Using 1:12-6+point-1 resulted in a stable environment, no crash experienced (running kernel 2.4). Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638208: iceweasel crashes, X-server crashes also
Hello Michael, On Fri, 16 Mar 2012 17:18:21 -0400 Michael Gilbert michael.s.gilb...@gmail.com wrote: The backtrace looks an awful lot like the one from the xv extension crash, which was fixed in 12-2. I wonder if your iceweasel is attempting to load that somehow? If so, this would be fixed by the current release that's already made it to testing. With 12-2 the result is the same. regards Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599731: libpam-systemd: su sessions end with su: System error
Hello Michael On Mon, 06 Feb 2012 17:27:19 +0100 Michael Biebl bi...@debian.org wrote: I can no longer reproduce this issue. Could you please test with the latest version and report back. The same here, unable to reproduce (no error reported in the logfiles). Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654680: python-html2text: 3.200.1-1 breaks parsing of feeds within rss2email
Hello Stefano, On Fri, 6 Jan 2012 15:02:33 +0200 Stefano Rivera stefa...@debian.org wrote: tag 654680 + patch thanks Hi Joerg (2012.01.05_10:39:33_+0200) after python-html2text was upgraded to 3.200.1-1 the feeds read by rss2email can't be parsed anymore ... Joerg / Lindsey: The attached patch for rss2email should do the trick for supporting 3.200. Applying this patch together with python-html2text 3.200 made r2e consume the complete memory of my system (3.5G). Best regards Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638334: iceweasel crashes
Hello Mike, On Thu, 18 Aug 2011 19:53:56 +0200 Mike Hommey m...@glandium.org wrote: On Thu, Aug 18, 2011 at 07:49:59PM +0200, Joerg wrote: Package: iceweasel Version: 6.0-1 Severity: normal On the hunt for bug#638208 another crash was produced. glxinfo | egrep version\|renderer\|vendor X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 135 (GLX) Minor opcode of failed request: 19 (X_GLXQueryServerString) Serial number of failed request: 12 Current serial number in output stream: 12 Is that glxinfo with the fglrx driver ? No, that's the one when using driver radeon. Did I mix both bugs? Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632130: [Pkg-fglrx-devel] Bug#632130: fglrx-driver: Xorg ends with black screen (singal 11 in logfile)
Hello Patrick To have a working version I downgraded to 1:11-4-2. A few days later unattended-upgrades kicked in and re-installed 1:11-6-2 and some other libs/packets. Now it's working fine. Here's the list of further packages which were installed on the same day: Setting up accountsservice (0.6.12-4) ... Setting up apt (0.8.15.1) ... Setting up apt-utils (0.8.15.1) ... Setting up fglrx-atieventsd (1:11-6-2) ... Setting up fglrx-control (1:11-6-2) ... Setting up fglrx-driver (1:11-6-2) ... Setting up fglrx-glx (1:11-6-2) ... Setting up fglrx-modules-dkms (1:11-6-2) ... Setting up glx-alternative-fglrx (0.1.3) ... Setting up glx-alternative-mesa (0.1.3) ... Setting up glx-diversions (0.1.3) ... Setting up gnash-common (0.8.10~git20110618-3) ... Setting up gpac (0.4.6~svn20110626-0.1) ... Setting up gtk-vector-screenshot (0.2-2) ... Setting up libaccountsservice0 (0.6.12-4) ... Setting up libavahi-client3 (0.6.30-4) ... Setting up libavahi-common3 (0.6.30-4) ... Setting up libavahi-common-data (0.6.30-4) ... Setting up libavahi-glib1 (0.6.30-4) ... Setting up libavahi-gobject0 (0.6.30-4) ... Setting up libc6 (2.13-8) ... Setting up libc6-dev (2.13-8) ... Setting up libc-bin (2.13-8) ... Setting up libc-dev-bin (2.13-8) ... Setting up libgpac0.4.6 (0.4.6~svn20110626-0.1) ... Setting up libgudev-1.0-0 (171-2) ... Setting up libjaxp1.3-java (1.3.05-1) ... Setting up libmatroska4 (1.2.0-1) ... Setting up libmpg123-0 (1.12.1-3.2) ... Setting up libperl5.12 (5.12.4-1) ... Setting up libreoffice (1:3.3.3-2) ... Setting up libreoffice-base (1:3.3.3-2) ... Setting up libreoffice-base-core (1:3.3.3-2) ... Setting up libreoffice-calc (1:3.3.3-2) ... Setting up libreoffice-common (1:3.3.3-2) ... Setting up libreoffice-core (1:3.3.3-2) ... Setting up libreoffice-draw (1:3.3.3-2) ... Setting up libreoffice-filter-mobiledev (1:3.3.3-2) ... Setting up libreoffice-gnome (1:3.3.3-2) ... Setting up libreoffice-gtk (1:3.3.3-2) ... Setting up libreoffice-help-en-us (1:3.3.3-2) ... Setting up libreoffice-impress (1:3.3.3-2) ... Setting up libreoffice-java-common (1:3.3.3-2) ... Setting up libreoffice-l10n-de (1:3.3.3-2) ... Setting up libreoffice-math (1:3.3.3-2) ... Setting up libreoffice-ogltrans (1:3.3.3-2) ... Setting up libreoffice-pdfimport (1.0.3+LibO3.3.3-2) ... Setting up libreoffice-presenter-console (1.1.0+LibO3.3.3-2) ... Setting up libreoffice-report-builder-bin (1:3.3.3-2) ... Setting up libreoffice-style-tango (1:3.3.3-2) ... Setting up libreoffice-writer (1:3.3.3-2) ... Setting up libupnp3 (1:1.6.6-5.1) ... Setting up libvlc5 (1.1.10-1+b1) ... Setting up libvlccore4 (1.1.10-1+b1) ... Setting up libxalan2-java (2.7.1-5) ... Setting up libxcursor1 (1:1.1.12-1) ... Setting up libxerces2-java (2.9.1-4.1) ... Setting up libxrandr2 (2:1.3.2-2) ... Setting up locales (2.13-8) ... Setting up locales-all (2.13-8) ... Setting up mirage (0.9.5.1-1.1) ... Setting up module-assistant (0.11.4) ... Setting up mozilla-libreoffice (1:3.3.3-2) ... Setting up mozilla-plugin-vlc (1.1.10-1+b1) ... Setting up multiarch-support (2.13-8) ... Setting up perl (5.12.4-1) ... Setting up perl-base (5.12.4-1) ... Setting up perl-modules (5.12.4-1) ... Setting up popularity-contest (1.53) ... Setting up qemu-kvm (0.14.1+dfsg-2) ... Setting up ttf-liberation (1.07.0-1) ... Setting up ttf-opensymbol (2:2.4.3+LibO3.3.3-2) ... Setting up udisks (1.0.3-1) ... Setting up uno-libs3 (1.7.0+LibO3.3.3-2) ... Setting up ure (1.7.0+LibO3.3.3-2) ... Setting up vlc (1.1.10-1+b1) ... Setting up vlc-nox (1.1.10-1+b1) ... Setting up vlc-plugin-notify (1.1.10-1+b1) ... Setting up vlc-plugin-pulse (1.1.10-1+b1) ... Setting up x11-session-utils (7.6+2) ... Setting up x11-utils (7.6+3) ... Setting up xfonts-utils (1:7.6+1) ... Cheers Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629932: linux-image-2.6.39-2-amd64: adding physical interface to bridge crashes the kernel
Hello Ben,
On Fri, 10 Jun 2011 03:29:19 +0100
Ben Hutchings b...@decadent.org.uk wrote:
On Thu, 2011-06-09 at 19:44 +0200, Joerg wrote:
Package: linux-2.6
Version: 2.6.39-2
Severity: normal
Adding a tap-interface to a bridge works fine. But adding eth0 to the bridge
brctl addif br0 eth0
causes the system to crash.
Works for me. You must provide the 'oops' message.
here is the data from kernel.log.
Adding eth1 to the bridge worked fine, only eth0 causes this
error (different cards).
kernel:[0.877653] r8169 :02:00.0: eth0: RTL8168c/8111c at
0xc961a000, 00:1f:d0:8f:38:c7, XID 1c4000c0 IRQ 41 {info}
kernel:[0.958228] 8139too :03:06.0: eth1: RealTek RTL8139 at
0xc9648000, 00:00:cb:62:d1:b4, IRQ 20 {info}
kernel:[ 10.652325] r8169 :02:00.0: eth0: link down {info}
kernel:[ 10.652333] r8169 :02:00.0: eth0: link down {info}
kernel:[ 10.653002] ADDRCONF(NETDEV_UP): eth0: link is not ready {info}
kernel:[ 12.308206] r8169 :02:00.0: eth0: link up {info}
kernel:[ 12.308822] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready {info}
...
kernel:[ 64.395835] Bridge firewalling registered {notice}
kernel:[ 70.084207] device eth1 entered promiscuous mode {info}
kernel:[ 83.316593] BUG: unable to handle kernel NULL pointer dereference at
(null) {alert}
kernel:[ 83.316754] IP: [ (null)] (null) {alert}
kernel:[ 83.316948] Oops: 0010 [#1] SMP {emerg}
kernel:[ 83.317015] last sysfs file: /sys/devices/virtual/net/lo/operstate
{emerg}
kernel:[ 83.320277] Stack: {emerg}
kernel:[ 83.320277] Call Trace: {emerg}
kernel:[ 83.316350] device eth0 entered promiscuous mode {info}
kernel:[ 83.316853] PGD 1266ef067 PUD 128457067 PMD 0 {warning}
kernel:[ 83.317126] CPU 0 {warning}
kernel:[ 83.317163] Modules linked in: bridge stp bnep rfcomm bluetooth
rfkill powernow_k8 mperf cpufreq_conservative cpufreq_userspace cpufreq_stats
uinput cpufreq_powersave ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 nf_defrag_ipv6
ip6t_rt ip6table_filter ip6_tables ipt_REJECT ipt_LOG xt_tcpudp
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_comment
iptable_filter ip_tables x_tables fuse ext4 jbd2 crc16 snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep
ir_lirc_codec snd_mixer_oss lirc_dev snd_seq_midi snd_rawmidi snd_pcm
snd_seq_midi_event ir_sony_decoder snd_seq snd_timer snd_seq_device stv0299
ir_jvc_decoder ir_rc6_decoder rc_hauppauge ir_rc5_decoder ir_nec_decoder snd
budget_ci budget_core processor shpchp dvb_core saa7146 ttpci_eeprom rc_core
thermal_sys pci_hotplug soundcore wmi i2c_piix4 edac_core snd_page_alloc
i2c_core edac_mce_amd kvm_amd kvm psmouse evdev pcspkr serio_raw k8temp it87
hwmon_vid button loop autofs4 ext
3 jbd mbcache {warning}
kernel: sg sd_mod sr_mod cdrom crc_t10dif ata_generic pata_atiixp ahci ohci_hcd
8139too libahci libata ehci_hcd scsi_mod usbcore 8139cp r8169 mii [last
unloaded: scsi_wait_scan] {info}
kernel:[ 83.319435] {warning}
kernel:[ 83.319468] Pid: 2024, comm: brctl Not tainted 2.6.39-2-amd64 #1
Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H {warning}
kernel:[ 83.319675] RIP: 0010:[] [ (null)]
(null) {warning}
kernel:[ 83.319811] RSP: 0018:880126e3fd20 EFLAGS: 00010202 {warning}
kernel:[ 83.319904] RAX: 05ae RBX: 05ae RCX:
880126f54748 {warning}
kernel:[ 83.320277] RDX: a0509900 RSI: a0507471 RDI:
880126f54f78 {warning}
kernel:[ 83.320277] RBP: 880126f54000 R08: R09:
0020 {warning}
kernel:[ 83.320277] R10: 880126f54740 R11: 8801290481c0 R12:
880126f54740 {warning}
kernel:[ 83.320277] R13: 8801265a8538 R14: R15:
{warning}
kernel:[ 83.320277] FS: 7fa143ce5700() GS:88012fc0()
knlGS: {warning}
kernel:[ 83.320277] CS: 0010 DS: ES: CR0: 8005003b
{warning}
kernel:[ 83.320277] CR2: CR3: 000125f19000 CR4:
06f0 {warning}
kernel:[ 83.320277] DR0: DR1: DR2:
{warning}
kernel:[ 83.320277] DR3: DR6: 0ff0 DR7:
0400 {warning}
kernel:[ 83.320277] Process brctl (pid: 2024, threadinfo 880126e3e000,
task 880125fa6b20) {warning}
kernel:[ 83.320277] a04fd1e7 880126f54000 88012698a000
880126f54740 {warning}
kernel:[ 83.320277] 81279c96 8801265a8400 a04feaf3
880126f54740 {warning}
kernel:[ 83.320277] 89a2 817fbf40 880126e3fde8
{warning}
kernel:[ 83.320277] [a04fd1e7] ? br_change_mtu+0x50/0x6f [bridge]
{warning}
kernel:[ 83.320277] [81279c96] ? dev_set_mtu+0x35/0x5b {warning}
kernel:[ 83.320277] [a04feaf3] ?
Bug#626787: gcp: timestamp is not always copied exact
Hello Thomas, On Mon, 23 May 2011 13:26:57 +0200 Thomas Preud'homme robo...@celest.fr wrote: Le lundi 23 mai 2011 07:36:07, Jörg Schütter a écrit : Hello Thomas, Hello Jörg, [SNIP] More tests (using the big file): -rw-r--r-- 1 joerg joerg 1619558400 2011-04-13 18:01:29.0 +0200 /home/joerg/gps/Legend_MapData/geoclub/gmapsupp.img Copy it to the same ext4 partition -- same timestamp Copy it to an ext2 partition (USB) -- same timestamp Copy it to a vfat partition (USB) -- same timestamp Copy it to a vfat partition (USB) on Garmin GPS -- different timestamp How big is the difference in the latter case? exact 1 second (2011-04-13 18:01:29.0 vs. 2011-04-13 18:01:28.0) I guess the cause is located deeper in the system: In case of time-diff the used USB mode was ohci_hcd. The other USB connections (with correct timestamp) used ehci_hcd. This Garmin GPS is the only legacy system I own which uses ohci_hcd. That might be the case indeed, but still I'd appreciate if you could try the attached patch and tell me if it solves the issue when copying to the Garmin GPS. All copied files had the same timestamp up to the millisecond. Now the file which triggerd this bug report has the same timestamp as the source file. Thanks for your help. -- Cheers Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626787: gcp: timestamp is not always copied exact
Hello Thomas,
On Thu, 19 May 2011 23:37:48 +0200
Thomas Preud'homme robo...@celest.fr wrote:
Le jeudi 19 mai 2011 22:21:16, Jörg Schütter a écrit :
Hello Thomas,
Hello Jörg,
[SNIP]
Looks like it also happens with small files. Since it doesn't
take so long to copy them, I never detected this.
[SNIP]
This is very valuable information, thanks. So I checked and I can say python
(at least python 2.6) return modification and access time precised at the
second, not more. This is true even if stat_float_times returns true (which
is
the default on python = 2.5).
So for me the bug is in python. I will try to submit (if no bug report
already
exist) a bug report on this issue and in the mean time I will add a note in
the man that resolution of access/modification time is the second.
Note that the differents OS could be treated separately and use real system
call (via subprocess or the like) to get the time as given by the OS but it
would be bad for portability and rather overkill for just gaining nanosecond
precision. Also, it would benefit much more people to solve this in python.
Does this solution sounds fine to you (more documentation + bug forwarding)?
More tests today (in combination with test FILE1 -nt FILE2)
showed that a file is not newer if it's less than 1 second newer.
If it's exactly 1 second newer, the test -nt returns true. So
cutting the milliseconds off is ok (at least for this test tool).
Example:
if [ -f ${source} -a ${source} -nt ${destination} ]; then ...
More tests (using the big file):
-rw-r--r-- 1 joerg joerg 1619558400 2011-04-13 18:01:29.0 +0200
/home/joerg/gps/Legend_MapData/geoclub/gmapsupp.img
Copy it to the same ext4 partition -- same timestamp
Copy it to an ext2 partition (USB) -- same timestamp
Copy it to a vfat partition (USB) -- same timestamp
Copy it to a vfat partition (USB) on Garmin GPS -- different timestamp
I guess the cause is located deeper in the system:
In case of time-diff the used USB mode was ohci_hcd.
The other USB connections (with correct timestamp) used ehci_hcd.
This Garmin GPS is the only legacy system I own which uses ohci_hcd.
Cheers
Joerg
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626787: gcp: timestamp is not always copied exact
Hello Thomas, On Wed, 18 May 2011 21:50:50 +0200 Thomas Preud'homme robo...@celest.fr wrote: Le mercredi 18 mai 2011 21:30:31, Thomas Preud'homme a écrit : Le mercredi 18 mai 2011 21:25:54, Jörg Schütter a écrit : Hello Thomas On Mon, 16 May 2011 16:05:39 +0200 Thomas Preud'homme robo...@celest.fr wrote: Le dimanche 15 mai 2011 11:53:19, vous avez écrit : Package: gcp Version: 0.1.1-2 Severity: normal You mean gcp --preserve=timestamps, right? Ok, that's my fault. Since copying files without any additional flag showed the same timestamp (cp uses current time) I never thought this flag may be necessary. Using the flag --preserve=timestamps solved my issue, thanks. Cheers Joerg No problem. But about the behaviour without flag, do you mean that without it, the current time is not used? If true, maybe this could be fixed. Best regards. Sorry, I replied to quickly. By default gcp is configured to use -- preserve=mode,ownership,timestamps. So --preserve=timestamps will just remove the mode and ownership preservation. Is the bug you experience fully reproducible? In other words, does it happen all the time for file 1GB? Looks like it also happens with small files. Since it doesn't take so long to copy them, I never detected this. Original file -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.443949038 +0200 BIG_FILE use cp -rw-r--r-- 1 joerg joerg 4222414848 2011-05-19 22:01:50.614892869 +0200 BIG_FILE_cp use cp -p -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.443949038 +0200 BIG_FILE_cp_p use gcp -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.0 +0200 BIG_FILE_gcp use gcp --preserver=timestamps -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.0 +0200 BIG_FILE_gcp_preserve_timestamps Original file -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.098747179 +0200 SMALL_FILE use cp -rw-r--r-- 1 joerg joerg 296 2011-05-19 22:05:57.214409519 +0200 SMALL_FILE_cp use cp -p -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.098747179 +0200 SMALL_FILE_cp_p use gcp -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.0 +0200 SMALL_FILE_gcp use gcp --preserver=timestamps -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.0 +0200 SMALL_FILE_gcp_preserve_timestamps Regards Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626787: gcp: timestamp is not always copied exact
Hello Thomas On Mon, 16 May 2011 16:05:39 +0200 Thomas Preud'homme robo...@celest.fr wrote: Le dimanche 15 mai 2011 11:53:19, vous avez écrit : Package: gcp Version: 0.1.1-2 Severity: normal You mean gcp --preserve=timestamps, right? Ok, that's my fault. Since copying files without any additional flag showed the same timestamp (cp uses current time) I never thought this flag may be necessary. Using the flag --preserve=timestamps solved my issue, thanks. Cheers Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618003: version 0.7.13-2 seems to close the bug
The issue is solved on my machine after upgrading to version 0.7.13-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607917: [Pkg-fglrx-devel] Bug#607917: fglrx-glx: more details
Hello On Mon, 27 Dec 2010 18:22:58 +0100 Patrick Matthäi pmatth...@debian.org wrote: Am 25.12.2010 10:08, schrieb Joerg: Package: fglrx-glx Version: 1:10-12-1 Severity: normal Hello You are right, I have compiz enabled. If I disable it, all I see is a black screen (only the mouse pointer is visible). Okay could you please try out following: 1) Commenting out in your xorg.conf: Option Composite on Option AccelMethod EXA 2) Retest it with compiz enabled Same result as before (translucent window) 3) Try it again without compiz, but don't start any other X11 session When using matecity as window manager, everything is fine. (from the log I can see, that your session was started on VT9) I think this was caused by restarting gdm3 4) @ 2 3, have a look at fglrxinfo The output is the same in both situations: display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Radeon HD 3200 Graphics OpenGL version string: 1.4 (3.3.10362 Compatibility Profile Context) Would it help to upgrade gnome-shell (and the other related packages) to their experimental version? This upgrades mutter from 2.29.0-3 to 2.91.3-3. Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602684: bootchart2: Please support custom init (e.g. /bin/systemd)
Hello David, On Sun, 7 Nov 2010 08:40:06 +0100 David Paleino da...@debian.org wrote: Hello Joerg, On Sun, 07 Nov 2010 08:24:11 +0100, Joerg wrote: Bootchart2 uses /sbin/init as the init script. Can you please add a parameter which makes it possible to select a custom init script. With bootchart I was able to do this with the kernel parameter bootchart_init=/bin/systemd It should already work like this. Have you tried it? I replaced bootchart with bootchart2 and changed the kernel options according to the README (leaving the other parameters unchanged). This is the result of grep '\binit\b' header taskstats.log within bootchart.tgz: header:system.kernel.options = BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=e5e00df4-c24f-48b0-8062-4406762d9257 ro quiet vga=0x314 nf_conntrack.acct=1 initcall_debug printk.time=y init=/sbin/bootchartd bootchart_init=/bin/systemd quiet taskstats.log:1 0 init 456028500 374277731 0 taskstats.log:1 0 init 456028500 380208931 0 taskstats.log:524 1 init 4000250 0 0 taskstats.log:525 524 init 0 9530401 0 taskstats.log:525 524 init 0 26280714 0 taskstats.log:525 524 init 0 51994808 0 taskstats.log:984 982 module-init-too 0 34799603 0 taskstats.log:1008 984 module-init-too 0 0 0 taskstats.log:1008 984 module-init-too 4000250 0 0 taskstats.log:1052 1008 module-init-too 0 0 0 taskstats.log:1 0 init 460028750 407257199 0 Do I need to change the kernel option? best regards Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539275: 3.5.2-1 seems to be free of this bug
The new version of iceweasel (3.5.2-1) seems to be free of this bug. With the 3.5.2-1 I haven't seen this color-issue anymore. Since the error only appears with some images I'm not 100% sure it is gone. Can someone please verify this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535347: Error is caused by packages listed in Unattended-Upgrade::Package-Blacklist, not by on hold
After doing some more tests I found that it is not triggered by packages set on hold. It is triggered by packages added to the black list Unattended-Upgrade::Package-Blacklist. The error still appears after removing the hold parameter from the package. best regards Joerg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#413245: iceweasel: new instance opens a new tab in existing window
I have the same situation here, but by using a different command I can circumvent it. iceweasel -new-tab http://www.debian.org opens two tabs, but iceweasel -remote openurl(http://www.debian.org,new-tab) just opens one (as expected). Jörg -- Jörg Schütter http://www.schuetter.org/joerg [EMAIL PROTECTED]http://the-brights.net/ http://badvista.fsf.org/
Bug#334200: Acknowledgement (vim-common: syntax highlighting seems to be broken)
Oh I'm so stuip. I forgot to update the runtimepath variable in /etc/vim/vimrc after the upgrade. Now it points to .../vim64 instead of .../vim63 Jörg -- Jörg Schütter http://www.schuetter.org/joerg [EMAIL PROTECTED]http://www.lug-untermain.de/
Bug#320919: mysql-common: Upgrade to 5.0.7beta-1 disabled the service
Hello Christian, On Tue, 2 Aug 2005 09:35:20 +0200 Christian Hammers [EMAIL PROTECTED] wrote: Hello Joerg On 2005-08-02 Joerg Schuetter wrote: After upgrading to mysql-common (4.0.24-10 = 5.0.7beta-1) I wasn't able to start the mysql service again (booted due to a new kernel). /var/log/syslog Aug 2 08:42:19 pluto /etc/init.d/mysql[7294]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' Can you send me the output that was a few lines above your first quoted one? I.e. why mysqld stopped immediately? Is it the old_passwords=1 option that it does not like (someone else reported that today)? you are right. I missed these lines: Aug 2 08:42:13 pluto mysqld_safe[7203]: started Aug 2 08:42:13 pluto mysqld[7207]: 050802 8:42:13 /usr/sbin/mysqld: unknown variable 'old_passwords=1' Aug 2 08:42:13 pluto mysqld[7207]: Aug 2 08:42:13 pluto mysqld_safe[7209]: ended BTW, which Kernel do you run it on. I use 2.6.x but I hope it does not make any (thread related?) problems with the 2.4 kernel... I'm running 2.6.12-mm2 Jörg P.S. Is it ok to send this mail to bugs.debian.org and also to you? -- Jörg Schütter http://www.schuetter.org/joerg [EMAIL PROTECTED]http://www.lug-untermain.de/
