Bug#1041508: tex-common: Installation fails if system is missing the set locale
On Sat, Sep 02, 2023 at 06:39:07PM +0100, Samuel Henrique wrote: > > This has happened now, every testing user is getting the following error: > """ > Building format(s) --all. > This may take some time... > fmtutil failed. Output has been stored in > /tmp/fmtutil.isqbK6Rx > Please include this file if you report a bug. Confirmed. I am seeing this on my testing boxes. ael
Bug#997933: offlineimap3: 'int' object is not subscriptable when connecting to outlook.office365.com
Package: offlineimap3 Version: 0.0~git20211018.e64c254+dfsg-1 Severity: serious Justification: 4 In the last week or so, offlineimap is usually (but not always) failing to connect to outlook.office365.com reporting: $ offlineimap -a x OfflineIMAP 8.0.0 Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception) imaplib2 v3.05, Python v3.9.7, OpenSSL 1.1.1l 24 Aug 2021 Account sync x: *** Processing account x Establishing connection to outlook.office365.com:993 (oRemote) ERROR: While attempting to sync account 'x' 'int' object is not subscriptable *** Finished account 'x' in 0:00 ERROR: Exceptions occurred during the run! ERROR: While attempting to sync account 'x' 'int' object is not subscriptable Traceback: File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in syncrunner self.__sync() File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync remoterepos.getfolders() File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 681, in getfolders imapobj = self.imapserver.acquireconnection() File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 683, in acquireconnection e.args[0][:35] == 'IMAP4 protocol error: socket error:': - I suspect perhaps a change in some python package? When this first showed up, it was nondeterministic: it looked like some sort of time out of, presumably some state somewhere. But now it seems to be pretty solid. Of course, MS maybe have messed up their IMAP server. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages offlineimap3 depends on: ii ca-certificates 20210119 ii python3 3.9.2-3 ii python3-distro1.6.0-2 ii python3-imaplib2 2.57-5.2 offlineimap3 recommends no packages. Versions of packages offlineimap3 suggests: pn python3-gssapi -- no debconf information Here is the relevant part of offlineimap.rc: --- [general] accounts = one,two,three,... #fsync false to conserve flash write cycles fsync = false [Account x] localrepository = sLocal remoterepository = sRemote [Repository sRemote] type = IMAP ssl = yes ssl_version = tls1 sslcacertfile = /etc/ssl/certs/ca-certificates.crt remoteprt = 993 remotehost = outlook.office365.com remoteuser = xx@somewhere.something folderfilter = lambda foldername: foldername in ['INBOX', 'Junk Email', 'Sent Items'] [Repository sLocal] type = Maildir localfolders = ~/Mail/x sep = / # Next again to help flash conservation & because noatime set restoreatime = yes -
Bug#993350: [sane-devel] Epson Perfection1640: Operation not supported
On Tue, Oct 05, 2021 at 03:26:22PM +0200, Wolfram Sang wrote: > > > I tried this but I still have xsane Version: 0.999-12 so there was no > > change. I couldn't find a newer version of xsane, even in Ubuntu. > > Indeed in the Ubuntu pool that I checked, the xsane directory was empty. > > You need a newer version of libsane than debian testing. Probably > packages "libsane-common" and friends. The xsane version can stay the > same. But a quick look tells me that Ubuntu repos won't be useful for > you because they also don't have the patch you need. Maybe your best bet > is to push Debian maintainers to include the patch I mentioned. They > should have it anyhow. Fedora already includes it. Well, I have been copying most of this thread to a debian bug, so I trust the Debian maintainer will pick it up soon. I once knew a little about packaging and built a few deb packages for my own purposes, so I could probably manage to get this working with enough time. Needless to say, I don't have that time now :-) As I needed a working scanner immediately, I have now scanned my documents using an older version of xsane which was already installed on devuan live image. Thanks for the help. I will keep watching this thread. ael
Bug#993350: [sane-devel] Epson Perfection1640: Operation not supported
On Tue, Oct 05, 2021 at 10:27:58AM +0100, ael via sane-devel wrote: > On Mon, Oct 04, 2021 at 08:39:58PM +0100, ael via sane-devel wrote: > > On Mon, Oct 04, 2021 at 05:32:29PM +0200, Wolfram Sang wrote: > > > There is a PPA with the latest development version here if you want to > > > test right away: > > > > > > https://launchpad.net/~sane-project/+archive/ubuntu/sane-git > > Meanwhile, I will get my scanner out and retest: despite the broken > packages, I think there is a chance that it might now work. > I tried this but I still have xsane Version: 0.999-12 so there was no change. I couldn't find a newer version of xsane, even in Ubuntu. Indeed in the Ubuntu pool that I checked, the xsane directory was empty. xscanimage also seg faulted as before. ael
Bug#993350: [sane-devel] Epson Perfection1640: Operation not supported
On Mon, Oct 04, 2021 at 08:39:58PM +0100, ael via sane-devel wrote: > On Mon, Oct 04, 2021 at 05:32:29PM +0200, Wolfram Sang wrote: > > There is a PPA with the latest development version here if you want to > > test right away: > > > > https://launchpad.net/~sane-project/+archive/ubuntu/sane-git > > > > I have tried using the ubuntu debs, but hit > dpkg: dependency problems prevent configuration of sane-utils: > sane-utils depends on libjpeg8 (>= 8c); however: > Package libjpeg8 is not installed. Just to report further: I tried to install the ubuntu libjpeg8 libjpeg8_8c-2ubuntu8_amd64.deb, but then hit further problems: libjpeg8:amd64 depends on libjpeg-turbo8 I then added libjpeg-turbo8_2.0.6-0ubuntu2_amd64.deb but then: error processing archive libjpeg-turbo8_2.0.6-0ubuntu2_amd64.deb (--install): conflicting packages - not installing libjpeg-turbo8:amd64 It seems that debian has instead: libturbojpeg0 So Ubuntu and debian seem to be using different package names. I could probably sort all this out if I had the time to refresh my memory about packaging. But is does not seem to be straight forward to use the Ubuntu packages in Debian. Meanwhile, I will get my scanner out and retest: despite the broken packages, I think there is a chance that it might now work. ael
Bug#993350: [sane-devel] Epson Perfection1640: Operation not supported
On Mon, Oct 04, 2021 at 05:32:29PM +0200, Wolfram Sang wrote: > There is a PPA with the latest development version here if you want to > test right away: > > https://launchpad.net/~sane-project/+archive/ubuntu/sane-git > I have tried using the ubuntu debs, but hit dpkg: dependency problems prevent configuration of sane-utils: sane-utils depends on libjpeg8 (>= 8c); however: Package libjpeg8 is not installed. libjpeg8 doesn't seem to be in debian... ael
Bug#993350: The new 1.0.33 version is needed
I have have contacted upstream and it seems that debian is not upto date with the latest version. Wolfram Sang said that ... "the new 1.0.33 version which is already in code-freeze state. Or the current version needs to include this patch from upstream: https://gitlab.com/sane-project/backends/-/commit/580c278dcafe4159213406b4307ee8598fe08f e7 " This is on the sane-devel list: sane-de...@alioth-lists.debian.net ael
Bug#993350: Also broken on Perfection 1640
I too am seeing this problem on my Perfection 1640SU. Pressing the acquire preview gives the message "Failed to start scanner: Operation not supported". This on Debian testing. Now on the Advanced Options window, there is an Autofocus button. I have deactivated it. I am pretty certain that this model has no autofocus mechanism. There is also a Focus position bar. Again, I don't think this model has any way to implement that. So I suspect that the "Operation not supported" is to adjust the focus. The old xsane (I probably mean the epson backend) just showed two settings: "Focus on glass" or "Focus on film". That is from memory, but something close to that. SO perhaps this old model had just a binary switch for two focus positions, and the epson backend has been broken by assuming that this model has more focus facilities. So far this is pure speculation on my part. ael
Bug#949780: maptool: Maptool segfaults
On Sat, Jan 25, 2020 at 06:26:35PM -0800, Joseph Herlant wrote: > Hi, > > > You mention in the bug there that you were able to run your pbf by > compiling maptool from the git repo. What compilation flags did you > use? I just realised that I answered the wrong question :-) I used the simplest defaults I think. In my history I just have cmake ../navit/ make maptool Does that tell you what you need to know? ael
Bug#949780: maptool: Maptool segfaults
On Sat, Jan 25, 2020 at 06:26:35PM -0800, Joseph Herlant wrote: > Hi, > > Taking the england-latest.osm.pbf from > https://download.geofabrik.de/europe/great-britain.html it does fail > with 0.5.4 after several minutes of processing with (not a segfault > per say but still failing): First, I suspect that (geofabrik) is where I found the original file. > > PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0 > tiles 7:17 181 MB > PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0 > tiles 7:47 181 MB > PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0 > tiles 8:17 181 MB > worker 3 exit > PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0 > tiles 8:18 181 MB > PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 0 relations 0 tiles > 8:18 181 MB > process_multipolygons:process (thread 0) > process_multipolygons:finish (thread 0) > maptool: /build/navit-vwCTlu/navit-0.5.4+dfsg.1/navit/maptool/itembin.c:93: > item_bin_copy_attr: Assertion `attr == attr_osm_wayid' failed. > > You mention in the bug there that you were able to run your pbf by > compiling maptool from the git repo. What compilation flags did you > use? I used ./maptool --protobuf -i /ssdback1/ael/mapping/mkgmap/great-britain-latest.osm.pbf test.bin inside my local navit_build directory where I compiled maptool. Many warnings and such scrolled past on the screen which were too fast to read, but I think were just reporting inconsistent or expected tagging in places. I did not bother to pipe through less to check all of that so maybe the could have been assertion failures if they did not prevent final completion. It looks as if the last commit on git when I last pulled was b24b3ed0d76d3cb4886fc821b0c5fb8dad553f15 which I now realise was you on Mon Jan 20 12:03:47 2020 -0800
Bug#949780: maptool: Maptool segfaults
On Sat, Jan 25, 2020 at 05:44:47PM -0800, Joseph Herlant wrote: > Hi, > > On Fri, Jan 24, 2020 at 2:00 PM ael wrote: > > Package: maptool > > Version: 0.5.3+dfsg.1-2+b1 > > Please try with the 0.5.4 version currently in unstable as here have > been a lot of changes to maptool since 0.5.3. I hope to do that as soon as I have time. Just now sorting out wince problems on navit. > > > This was encountered while looking at the issues with navit on wince: > > see https://github.com/navit-gps/navit/issues/953#issuecomment-578313710 > > Are you using the debian binaries on wince? ? Er, Um, different instruction sets! So no. But I was using the Debian maptool to produce a map for use on wince. > > > Search down that page to see the problem with the Debian testing > > maptool: > > > > maptool --protobuf -i > > /ssdback1/ael/mapping/mkgmap/great-britain-latest.osm.pbf test.bin > > > > but that SEGFAULTED almost immediately after writing some empty *.tmp > > > Could you provide the link to the .pbf or the proto and the way you > build it so we can reproduce it please? It's hard to debug without > more information. Well, I downloaded that pbf file a few weeks ago before I knew about the wince problem - I used it with mkgmap to successfully produce a Garmin map. So I had no reason to record where I found it. But I may be able to work out from whence it came. > > I see that there is a new version in unstable but I have not tried that > > as yet. > > Please try with the new version. There's been a lot of changes in > maptool between 0.5.3 and 0.5.4. As I noted above, I am planning to try that when I have time which will be after I have the navit/wince problem resolved. I hope not more than a day or two. If the new version works - which I expect to be OK if it is just a version from the git repository - maybe there is no reason to spend much time diagnosing the old version. This bug report should be enough to alert anyone who hits tha same bug to upgrade. Thanks for the reply, ael
Bug#949780: maptool: Maptool segfaults
Package: maptool Version: 0.5.3+dfsg.1-2+b1 Severity: grave Justification: renders package unusable Trying to use maptool with a .pbf file gave a segfault almost immediately. Compiling my own maptool directly from the navit git gave a working version. This was encountered while looking at the issues with navit on wince: see https://github.com/navit-gps/navit/issues/953#issuecomment-578313710 Search down that page to see the problem with the Debian testing maptool: maptool --protobuf -i /ssdback1/ael/mapping/mkgmap/great-britain-latest.osm.pbf test.bin but that SEGFAULTED almost immediately after writing some empty *.tmp files. gdb shows Program terminated with signal SIGSEGV, Segmentation fault. #0 0x55c63a68cf30 in osmpbf.blob_header.init () Backtrace showed: (gdb) bt #0 0x55c63a68cf30 in osmpbf.blob_header.init () #1 0x55c63a6917da in protobuf_c_message_unpack () #2 0x55c63a68a7ec in ?? () #3 0x55c63a68abb8 in map_collect_data_osm_protobuf () #4 0x55c63a679e73 in main () I see that there is a new version in unstable but I have not tried that version as yet. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages maptool depends on: ii libc6 2.29-9 ii libglib2.0-0 2.62.4-1 ii zlib1g1:1.2.11.dfsg-1+b1 maptool recommends no packages. Versions of packages maptool suggests: pn navit -- no debconf information
Bug#897348: synaptic still broken
I have had this same problem for months. It would be nice to be able to use synaptics again. Have I missed the response to this bug? The problem is launching from CLI root terminal which used to work. I *can* launch from a GUI menu, but that is overcomplicated for simple things. Running current debian testing. 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux Package: synaptic Status: install ok installed Priority: optional Section: admin Installed-Size: 7810 Maintainer: Michael Vogt Architecture: amd64 Version: 0.84.5 ael
Bug#891766: nfsv4: Unknown symbol __x86_indirect_thunk_r*
Package: nfs-common Version: 1:1.3.4-2.2 Severity: grave Justification: renders package unusable Dear Maintainer, Since upgrading testing today ( 1:1.3.4-2.2 ) mount.nfs fails to mount at least two other filesystems on other debian machines, also running testing, and also upgraded today. dmesg reports many unknown symbols: [12995.092576] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.093725] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.094258] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.098091] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.098789] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.099563] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.106045] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.106814] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12995.123108] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.129793] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.130336] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.131534] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.135815] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.136606] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.137113] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.137865] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12995.144654] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.145588] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.152488] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.153577] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.154159] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.158831] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.161160] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.161841] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12996.548940] nfsv3: Unknown symbol __x86_indirect_thunk_rax (err 0) -- [snip] -- [13062.548743] nfsd: last server has exited, flushing export cache [13063.900550] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [13063.921390] NFSD: starting 90-second grace period (net b38d4b80) [13089.924328] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [13089.925123] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [13089.925452] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [13089.926327] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [13089.926788] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [13089.927319] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [13089.927670] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [13089.928425] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [13089.934883] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [13089.935672] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [13089.936046] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [13089.937190] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [13089.937722] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [13089.938280] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [13089.938632] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [13089.939176] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [13089.945661] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) -- [snip] -- A typical mount failure:- # mount.nfs -v shelf: /mnt/shelf/ mount.nfs: timeout set for Wed Feb 28 15:55:38 2018 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.1,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.0,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.0.8' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.0.8 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.0.8 prog 15 vers 3 prot UDP port 34299 mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 3910022 tcp836 sgi_fam 1000241 udp 47937 status 1000241 tcp 39807 status 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 133 udp 2049 nfs 1002273 udp 2049
Bug#861474: Removing slim fixes the problem
Removing the slim package solves the problem, so slim seems to be the culprit.
Bug#861474: slim: Session restarts in a loop renedering whole system useless.
Package: slim Version: 1.3.6-5 Severity: critical Justification: breaks the whole system I am not sure that this is a slim problem, but as the system is almost unusable, I cannot investigate. After an apt-get upgrade earlier today, the system presents a new slim login page. Logging in works, but then the whole system restarts X (presumably) and the sylim login prompt appear again. This ahhpens in what seems to be an infinite loop, roughly every minute or so. I am only able to compose this message outside X using a pseudo terminal. The restarts interrupt the terminal and represents the slim login page. Fortunately the terminal context is retained so I can switch back to the terminal. I have not yet tried removing slim which I hope I may be able to do despite the constant restarts. I suspect slim because it seems to be the only likely candidate in the set of upgrades earlier today, and it is the slim login screen which keeps looping. Presumably others will report this problem as well. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages slim depends on: ii dbus 1.10.18-1 ii debconf [debconf-2.0] 1.5.60 ii libc6 2.24-10 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libgcc11:6.3.0-14 ii libjpeg62-turbo1:1.5.1-2 ii libpam0g 1.1.8-3.5 ii libpng16-161.6.28-1 ii libstdc++6 6.3.0-14 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxft22.3.2-1+b2 ii libxmu62:1.1.2-2 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages slim recommends: ii xterm 327-2 Versions of packages slim suggests: pn scrot ii xauth 1:1.0.9-1+b2 -- debconf information: * shared/default-x-display-manager: slim slim/daemon_name: /usr/bin/slim
Bug#794264: systemd: System will no longer boot
On Fri, Jul 31, 2015 at 11:15:06PM +0200, Michael Biebl wrote: Control: tags -1 moreinfo Am 31.07.2015 um 20:57 schrieb ael: Package: systemd Version: 221-1 Severity: critical Justification: breaks the whole system I had to select the sysvinit option from the grub menu in order to achieve a boot. The standard menu entry got as far as (probably) trying to spawn X, and then hung. But it had no business doing that because the default target was set to default.target - /lib/systemd/system/multi-user.target in /etc/systemd/systemd/ If X hangs, what makes you sure systemd is at fault? X runs when booted via sysvinit. I have subsequently discovered that I cannot shutdown that machine. It reports something like the shutdown.service did not complete (with timeout). I think I know why that happened, *but* to refuse to umount the filesystem and stop all processes to allow a safe manual power off is a major flaw. I had to just cut power after manually unmounting the few mounts that it would permit. That whole machine is now is a complete mess, and I am not sure that I will be able to recover to try to provide the reports you request without a lot of time and effort. I will be away from the machine for about 1 month in a day or so, so such a report may be delayed. Another (amd64) machine has also stopped booting properly after the latest updates. At least it gets as far as emergency mode. That too seems to be a systemd problem. Back to the i386 machine, the target in this report: when I tried to apt-get upgrade in case the bug had been fixed, it hung on systemd because udev could not be upgraded. The udev refusal to upgrade came with a message from dpkg about a group 'Input' already existing. This from memory: so the details may not be correct. As I say that system is messed up so I can't easily check those details for now. Thanks for the reply. Please provide a verbose debug log of systemd. Add systemd.log_level=debug systemd.debug-shell to the kernel command line. You should get a debug shell on tty9, which you can use to inspect the system. Please attach the output of journalctl -alb systemd-analyze dump systemctl status [1] http://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794264: systemd: System will no longer boot
Package: systemd Version: 221-1 Severity: critical Justification: breaks the whole system I had to select the sysvinit option from the grub menu in order to achieve a boot. The standard menu entry got as far as (probably) trying to spawn X, and then hung. But it had no business doing that because the default target was set to default.target - /lib/systemd/system/multi-user.target in /etc/systemd/systemd/ --- -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Init: unable to detect Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4.2-1 ii libblkid1 2.26.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-9 ii libcap2-bin 1:2.24-9 ii libcryptsetup4 2:1.6.6-5 ii libgcc1 1:5.1.1-12 ii libgcrypt20 1.6.3-2 ii libkmod220-1 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.26.2-6 ii libpam0g1.1.8-3.1 ii libseccomp2 2.2.1-2 ii libselinux1 2.3-2+b1 ii libsystemd0 221-1 ii mount 2.26.2-6 ii sysv-rc 2.88dsf-59.2 ii udev221-1 ii util-linux 2.26.2-6 Versions of packages systemd recommends: ii dbus1.8.18-1 ii libpam-systemd 221-1 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information [REDIRECTED] /etc/systemd/system/default.target - /lib/systemd/system/default.target [EXTENDED] /lib/systemd/system/systemd-timesyncd.service - /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [EXTENDED] /lib/systemd/system/rc-local.service - /lib/systemd/system/rc-local.service.d/debian.conf [OVERRIDDEN] /etc/systemd/system/vsftpd.service - /lib/systemd/system/vsftpd.service --- /lib/systemd/system/vsftpd.service 2014-07-27 10:42:53.0 +0100 +++ /etc/systemd/system/vsftpd.service 2013-03-10 21:03:53.0 + @@ -1,6 +1,6 @@ [Unit] Description=vsftpd FTP server -After=network.target +After=syslog.target network.target [Service] Type=simple 4 overridden configuration files found. == /var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also == /etc/systemd/system/multi-user.target.wants/cron.service == /var/lib/systemd/deb-systemd-helper-enabled/hibernate.target.wants/anacron-resume.service == == /var/lib/systemd/deb-systemd-helper-enabled/dm-event.service.dsh-also == /etc/systemd/system/sysinit.target.wants/dm-event.service == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.ModemManager1.service == == /var/lib/systemd/deb-systemd-helper-enabled/ssh.socket.dsh-also == /etc/systemd/system/sockets.target.wants/ssh.socket == /var/lib/systemd/deb-systemd-helper-enabled/ssh.service.dsh-also == /etc/systemd/system/multi-user.target.wants/ssh.service /etc/systemd/system/sshd.service == /var/lib/systemd/deb-systemd-helper-enabled/shutdown.target.wants/unattended-upgrades.service == == /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-dispatcher.service.dsh-also == /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service == /var/lib/systemd/deb-systemd-helper-enabled/sshd.service == == /var/lib/systemd/deb-systemd-helper-enabled/display-manager.service == == /var/lib/systemd/deb-systemd-helper-enabled/inetd.service.dsh-also == /etc/systemd/system/multi-user.target.wants/inetd.service == /var/lib/systemd/deb-systemd-helper-enabled/uuidd.service.dsh-also == /etc/systemd/system/sockets.target.wants/uuidd.socket == /var/lib/systemd/deb-systemd-helper-enabled/graphical.target.wants/slim.service == == /var/lib/systemd/deb-systemd-helper-enabled/anacron-resume.service.dsh-also == /etc/systemd/system/suspend.target.wants/anacron-resume.service /etc/systemd/system/hibernate.target.wants/anacron-resume.service /etc/systemd/system/hybrid-sleep.target.wants/anacron-resume.service == /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also == /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/dm-event.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/lvm2-lvmetad.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/gpsd.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/uuidd.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/cups.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/avahi-daemon.socket ==
Bug#651601: josm broken under xfce
Package: josm Version: 0.0.svn4487+dfsg2-2 Severity: grave Tags: upstream Justification: renders package unusable Please see josm.openstreetmap.de tickets #5833 and #7066. josm is no longer usable under xfce4. Window decoration missing, child windows misbehave and make data entry almost impossible. One worked round, data seems not to be handled correctly. I think josm-latest was last working in mid October. ael - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages josm depends on: ii libcommons-codec-java1.5-1 ii libgdata-java1.30.0-2 ii libgettext-commons-java 0.9.6-2 ii libmetadata-extractor-java 2.3.1+dfsg-2 ii liboauth-signpost-java 1.2.1.1-1 ii libsvgsalamander-java0~svn95-1 ii openstreetmap-map-icons-classic 1:0.0.svn26700-1 ii sun-java6-jre6.26-3 Versions of packages josm recommends: ii josm-plugins 0.0.svn26626+ds1-2 ii webkit-image-gtk 0.0.svn25399-2+b1 josm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644205: gdb backtrace
I was unable to build from source with nopt and nostrip to help
with gdb.
However, using just cups-dbg, I have this gdb session:-
--
# gdb lpinfo
...
(gdb) break httpStatus
Function httpStatus not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (httpStatus) pending.
(gdb) run -m
Starting program: /usr/sbin/lpinfo -m
[Thread debugging using libthread_db enabled]
Breakpoint 1, httpStatus (status=HTTP_ERROR) at http-support.c:1258
1258{
(gdb) bt
#0 httpStatus (status=HTTP_ERROR) at http-support.c:1258
#1 0xb7fa2acc in _cupsSetHTTPError (status=HTTP_ERROR) at request.c:1085
#2 0xb7fa2de4 in cupsGetResponse (http=optimized out,
resource=0xb7fff745 /) at request.c:488
#3 0xb7fa3138 in cupsDoIORequest (http=0xb800f250, request=0xb8002918,
resource=0xb7fff745 /, infile=-1, outfile=-1) at request.c:270
#4 0xb7fa33ab in cupsDoRequest (http=0x0, request=0xb8002918,
resource=0xb7fff745 /) at request.c:337
#5 0xb7ffeb80 in show_models (exclude_schemes=0x0, include_schemes=0x0,
product=0x0, make_model=0x0, language=0x0, device_id=0x0, long_status=0)
at lpinfo.c:399
#6 main (argc=2, argv=0xbd74) at lpinfo.c:116
(gdb)
--
It seems then that the switch statement in httpStatus in http-support.c
needs at least one extra branch for HTTP_ERROR.
I suppose that I need to examine request.c next to try to understand
how the error arises.
ael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644205: http-support.c httpStatus problem...
I decided to try to understand what is wrong with:
# lpinfo -m
lpinfo: Unknown
as it looked as if it might be simpler to debug. In particular, I
needed to know where this useless message Unknown originated.
To that end, I installed source and greped, found the likely
candidate, modified the string and recompiled.
Thus I confirm that the message comes from http-support.c, line 1340
which is the default clause in a switch statement:
httpStatus(http_status_t status)/* I - HTTP status code */
{
const char*s;g */
_cups_globals_t *cg = _cupsGlobals();/* Global data */
cg-lang_default = cupsLangDefault();
switch (status)
{
...
ael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644205: Severity increased. Reinstallation compounds problem..
I have changed the severity to grave since this problem completely disables printing via cups. I tried purging and then reinstalling the packages: cups-drivers-gutenprint cups cups-bsd cups-client cups-common ghostscript-cups and cups-ppdc. Using the localhost web admin page, there are no printers installed as expected. Trying to create a printer, cups reports that it can find no printer drivers! This despite cups-drivers-gutenprint being installed and claiming to support the Brother-HL-1250 which was the target. ISTR that before I could select my printer model from a list. Now it looks as if that is somehow autodetected (which is presumably failing), unless the abscence of the list is just another manifestation of the bug or bugs. lpinfo -m is most unhelpful: # lpinfo -m lpinfo: Unknown I have attached a file of the output of lpinfo -m running under strace r.txt.gz Description: Binary data
Bug#571941: 1.10.0-1 from unstable corrects problem
gnumeric 1.10.0-1 from unstable fixes this problem, so perhaps this bug can be closed. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571941: libgoffice-0.8.so.7: cannot open shared object file
Package: gnumeric Version: 1.9.17-1 Severity: grave Justification: renders package unusable == $gnumeric xxx.gnumeric gnumeric: error while loading shared libraries: libgoffice-0.8.so.7: cannot open shared object file: No such file or directory # ls -l /usr/lib/libgoffice-* lrwxrwxrwx 1 root root 23 2010-02-26 12:38 /usr/lib/libgoffice-0.8.so.8 - libgoffice-0.8.so.8.0.0 -rw-r--r-- 1 root root 1124636 2010-02-15 12:59 /usr/lib/libgoffice-0.8.so.8.0.0 # dpkg -s gnumeric Depends: libatk1.0-0 (= 1.20.0), libc6 (= 2.7), libcairo2 (= 1.2.4), libglade2-0 (= 1:2.6.1), libglib2.0-0 (= 2.18.0), libgoffice-0-8 (= 0.7.17), . So this seems to be a dependency problem = - System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.33 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnumeric depends on: ii debconf [debc 1.5.28 Debian configuration management sy ii gconf22.28.0-1 GNOME configuration database syste ii gnumeric-comm 1.9.17-1 spreadsheet application for GNOME ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.8-2The Cairo 2D vector graphics libra ii libglade2-0 1:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.22.4-1 The GLib library of C routines ii libgoffice-0- 0.8.0-1Document centric objects library - ii libgsf-1-114 1.14.17-1 Structured File Library - runtime ii libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libxml2 2.7.6.dfsg-2+b1GNOME XML library ii procps1:3.2.8-7 /proc file system utilities ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnumeric recommends: ii evince2.28.2-1 Document (postscript, pdf) viewer ii lp-solve 5.5.0.13-7 Solve (mixed integer) linear progr Versions of packages gnumeric suggests: pn epiphany-browser none(no description available) ii gnumeric-doc 1.9.17-1 spreadsheet application for GNOME pn gnumeric-plugins-extra none(no description available) ii ttf-liberation 1.05.2.20091019-4 Fonts with the same metrics as Tim -- debconf information: gnumeric/existing-process: false -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567003: firestarter does not install properly?
Package: firestarter Version: 1.0.3-8 Severity: grave Justification: renders package unusable - Installing firefighter from aptitude:- === Unpacking firestarter (from .../firestarter_1.0.3-8_i386.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Processing triggers for desktop-file-utils ... Setting up firestarter (1.0.3-8) ... update-rc.d: warning: firestarter start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5) update-rc.d: warning: firestarter stop runlevel arguments (none) do not match LSB Default-Stop values (0 1 6) Processing triggers for menu ... Press return to continue. I am not sure if those warnings above from update-rc.d are relevant to the bug. Attempting to run firestarter (from a root terminal) for the first time: gave:- --- # firestarter (firestarter:3425): GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. -- Next I tried # /etc/init.d/firestarter # /etc/init.d/firestarter help # /etc/init.d/firestarter status # /etc/init.d/firestarter start In each case, nothing happened. So I inspected the script and found FS_CONTROL=/etc/firestarter/firestarter.sh [ -x /usr/sbin/firestarter ] || exit 0 [ -x $FS_CONTROL ] || exit 0 so I looked :- ~# ls -l /etc/firestarter/firestarter.sh ls: cannot access /etc/firestarter/firestarter.sh: No such file or directory So /etc/firestarter/firestarter.sh was not present. Nor was it listed under dpkg -L firestarter. Also # ls -l /etc/firestarter/ total 4 -rw-r--r-- 1 root root 567 2009-08-15 13:08 non-routables Is there not supposed to be a configuration file there as well? But perhaps not until the first run? Anyway, as my first attempt to install firestarter, it fails completely. In passing, I am using xfce, but I understand that firestarter should run Ok in this environment. -- -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages firestarter depends on: ii gconf2 2.28.0-1 GNOME configuration database syste ii gksu2.0.2-2+b1 graphical frontend to su ii iptables1.4.6-2 administration tools for packet fi ii libart-2.0-22.3.20-2 Library of functions for 2D graphi ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libbonobo2-02.24.2-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.24.2-1 The Bonobo UI library ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.0-1 GNOME configuration database syste ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.22.4-1 The GLib library of C routines ii libgnome2-0 2.28.0-1 The GNOME library - runtime files ii libgnomecanvas2-0 2.26.0-1 A powerful object-oriented display ii libgnomeui-02.24.2-1 The GNOME libraries (User Interfac ii libgnomevfs2-0 1:2.24.2-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.18.3-1 The GTK+ graphical user interface ii libice6 2:1.0.6-1X11 Inter-Client Exchange library ii liborbit2 1:2.14.17-2 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libpopt01.15-1 lib for parsing cmdline parameters ii libsm6 2:1.1.1-1X11 Session Management library ii libx11-62:1.3.2-1X11 client-side library ii libxml2 2.7.6.dfsg-1 GNOME XML library ii lsb-base3.2-23 Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime firestarter recommends no packages. Versions of packages firestarter suggests: pn dhcp3-server none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to
Bug#549312: Looks as if this only occurs with more than 1 dvd
This bug is still present on all my machines including on a netbook with a freshly installed squeeze. However, I am fairly sure that it only occurs when multiple dvds need to be mounted (necessarily sequentially, since there is only a single mount point). It is as if the path to the deb on the earlier dvds is cached somewhere: the dvd is changed, and when that cached path is used later, it is, of course, no longer valid. This bug would seem to make debian installation from multiple DVDs nearly impossible: so pretty serious for those without high bandwidth connections. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
For the record, after replacing drives *and* cables, the problem persists. I can only assume that it is the controller after all :-( I think I will live without a floppy on that particular box. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
For what it is worth, here are the results from my debian testing box under 2.6.32_exact-55846-gf405425 $ lsmod |grep floppy floppy 45327 0 # setfdprm /dev/fd0 HD # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1 # floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd seek 0 1 0: 20 1: 1 no disk change # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: Could you try the same with a higher repetition count: fdrawcmd readid 0 repeat=40 Just to make sure that eventually all sectors show up Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0? Have to go out for an hour or more, so can't report immediately. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*? repeat=40
Alain Knaff wrote: Could you try the same with a higher repetition count: On same floppy (medium) as before: # fdrawcmd readid 0 repeat=40 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change # fdrawcmd readid 0 repeat=40 21 |grep ^5: 5: 9 5: a 5: b 5: e 5: f 5: 10 5: 12 5: 1 5: 4 5: 5 5: 6 5: 7 5: 8 5: 9 5: a 5: c 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 4 5: 5 5: 6 5: 7 5: 9 5: c 5: d 5: e 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 6 5: 7 5: 9 5: a ??? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Mark Hounschell wrote: On 12/15/2009 10:08 AM, Alain Knaff wrote: I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's. So I think when the cause is found, it will be a single cause. Uninitialised variable? gcc version bugs? I know that doesn't really help in tracking things down... :-( About to run with repeat=40. I have only just downloaded the data sheet and have only skimmed small portions, so I have some catching up to do... ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: ael wrote: Mark Hounschell wrote: On 12/15/2009 10:08 AM, Alain Knaff wrote: I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's. So I think when the cause is found, it will be a single cause. Uninitialised variable? gcc version bugs? [..snip..] Weird. If you suspect a compiler bug, No, not really. I was just grasping at straws trying to think what could vary among distributions if they are all using the same source code. I guess almost anything non-deterministic *might* show in different distributions. On the other hand, one of my machines seems to have mended itself - at least it worked on a single test 2 days ago - so that might fit again with some non determinism around timing. Anyhow, I wasting time because this sort of speculation isn't likely to help find the bug ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0? # fdrawcmd seek 0 0 0: 20 1: 0 no disk change # fdrawcmd readid 0 repeat=40 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change # fdrawcmd readid 0 repeat=40 21 |grep ^5: 5: 8 5: 9 5: a 5: b 5: c 5: d 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 5 5: 6 5: 7 5: 8 5: 9 5: a 5: b 5: d 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 4 5: 8 5: 9 5: a 5: b 5: c 5: d 5: e 5: f 5: 10 Is that what you wanted? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
A.E.Lawrence wrote: # fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 /dev/null remaining= 17920 0: 40 == So this is Abnormal termination? 1: 20 == CRC error? (id or data) 2: 20 == CRC error? (data) Did I decode them correctly? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: A.E.Lawrence wrote: Alain Knaff wrote: ael wrote: Is that what you wanted? ael Yes. All sectors are there, ... so I wonder why you are getting errors. So, next round of tests: trying to read these sectors: fdrawcmd recalibrate 0 fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 /dev/null # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 /dev/null remaining= 17920 0: 40 1: 20 2: 20 3: 0 4: 0 5: 1 6: 2 no disk change A CRC error both in the header (1: 20) and in the data of the sector (2: 20) It begins to look more and more like a hardware problem, at least in your case... I am pretty confident that I had ruled out hardware. I haven't tried the formatting floppies in my amd64 debian testing box for a while, but that was showing exactly the same problem. Maybe if I can test that again tomorrow if necessary. But the Mark said he was seeing something very similar: we can't both have the same hardware problems on multiple machines? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote:
fdrawcmd read 0 0 0 1 2 18 1 1 length=512 /dev/null
fdrawcmd read 0 0 0 2 2 18 1 1 length=512 /dev/null
fdrawcmd read 0 0 0 3 2 18 1 1 length=512 /dev/null
...
fdrawcmd read 0 0 0 18 2 18 1 1 length=512 /dev/null
fdrawcmd read 4 0 1 1 2 18 1 1 length=512 /dev/null
fdrawcmd read 4 0 1 2 2 18 1 1 length=512 /dev/null
...
fdrawcmd read 4 0 1 18 2 18 1 1 length=512 /dev/null
# for s in {1..18} ; do echo sector= $s; fdrawcmd read 0 0 0 $s 2 18 1
1 length=512 /dev/null ; done
sector= 1
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 1
6: 2
no disk change
sector= 2
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 2
6: 2
no disk change
sector= 3
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 3
6: 2
no disk change
sector= 4
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 4
6: 2
no disk change
sector= 5
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 5
6: 2
no disk change
sector= 6
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 6
6: 2
no disk change
sector= 7
remaining= 0
0: 0
1: 0
2: 0
3: 0
4: 0
5: 8
6: 2
no disk change
sector= 8
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 8
6: 2
no disk change
sector= 9
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 9
6: 2
no disk change
sector= 10
remaining= 0
0: 0
1: 0
2: 0
3: 0
4: 0
5: b
6: 2
no disk change
sector= 11
remaining= 0
0: 0
1: 0
2: 0
3: 0
4: 0
5: c
6: 2
no disk change
sector= 12
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: c
6: 2
no disk change
sector= 13
remaining= 512
0: 40
1: 4
2: 0
3: 0
4: 0
5: d
6: 2
no disk change
sector= 14
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: e
6: 2
no disk change
sector= 15
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: f
6: 2
no disk change
sector= 16
remaining= 0
0: 40
1: 20
2: 20
3: 0
4: 0
5: 10
6: 2
no disk change
sector= 17
remaining= 0
0: 0
1: 0
2: 0
3: 0
4: 0
5: 12
6: 2
no disk change
sector= 18
remaining= 512
0: 40
1: 4
2: 0
3: 0
4: 0
5: 12
6: 2
no disk change
---
# for s in {1..18} ; do echo sector= $s; fdrawcmd read 4 0 1 $s 2 18 1
1 length=512 /dev/null ; done
sector= 1
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 1
6: 2
no disk change
sector= 2
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 2
6: 2
no disk change
sector= 3
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 3
6: 2
no disk change
sector= 4
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 4
6: 2
no disk change
sector= 5
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 5
6: 2
no disk change
sector= 6
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 6
6: 2
no disk change
sector= 7
remaining= 512
0: 44
1: 4
2: 0
3: 0
4: 1
5: 7
6: 2
no disk change
sector= 8
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 8
6: 2
no disk change
sector= 9
remaining= 0
0: 4
1: 0
2: 0
3: 0
4: 1
5: a
6: 2
no disk change
sector= 10
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: a
6: 2
no disk change
sector= 11
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: b
6: 2
no disk change
sector= 12
remaining= 0
0: 4
1: 0
2: 0
3: 0
4: 1
5: d
6: 2
no disk change
sector= 13
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: d
6: 2
no disk change
sector= 14
remaining= 0
0: 4
1: 0
2: 0
3: 0
4: 1
5: f
6: 2
no disk change
sector= 15
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: f
6: 2
no disk change
sector= 16
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 10
6: 2
no disk change
sector= 17
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 11
6: 2
no disk change
sector= 18
remaining= 0
0: 44
1: 20
2: 20
3: 0
4: 1
5: 12
6: 2
no disk change
ael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: Mark Hounschell wrote: [...] All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT. 2.6.28 was when support for sector bases other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the stretch parameter. Could it be that on some distributions, something is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base). Could you try to: The first thing I have to report is that I started by checking fdformat on /dev/fd0 in the usual way to confirm that the bug was still present. This is on debian testing updated daily so many packages are updated freqently. To my surprise, fdformat worked without problems on one i386 machine, but failed in the usual way on another. My next message will report the results of Alain's test on the failing machine. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: Mark Hounschell wrote: [...] All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT. 2.6.28 was when support for sector bases other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the stretch parameter. Could it be that on some distributions, something is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base). Could you try to: fdformat /dev/fd0u1440 in case you don't have /dev/fd0u1440, you can create it using the following command line: mknod /dev/fd0u1440 b 2 28 then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0) You should get: 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c The fifth byte (0 here) is the stretch byte. If it contains anything other than 0, this might explain it. Another test would be to perform: fdrawcmd readid 0 repeat=18 Here are my results to complement Mark's. Unfortunately fdrawcmd would not run here, perhaps because I have different a different floppy controller. Or maybe I have a different version and am not giving it the right parameters. # dpkg -s fdutils Package: fdutils Status: install ok installed Priority: optional Section: utils Installed-Size: 924 Maintainer: Anibal Monsalve Salazar ani...@debian.org Architecture: i386 Version: 5.5-20060227-3 # mknod /dev/fd0u1440 b 2 28 # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1 # getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c # fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument # fdrawcmd drive=0 rate=0 readid 0 raw cmd: Invalid argument # hexdump /dev/fd0 hexdump: /dev/fd0: Input/output error /sys/devices/platform/floppy.0/block/fd0# ls -l total 0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 alignment_offset lrwxrwxrwx 1 root root0 2009-12-14 11:18 bdi - ../../../../virtual/bdi/2:0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 capability -r--r--r-- 1 root root 4096 2009-12-14 10:28 dev lrwxrwxrwx 1 root root0 2009-12-14 10:28 device - ../../../floppy.0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 discard_alignment -r--r--r-- 1 root root 4096 2009-12-14 11:18 ext_range drwxr-xr-x 2 root root0 2009-12-14 10:51 holders -r--r--r-- 1 root root 4096 2009-12-14 11:18 inflight drwxr-xr-x 2 root root0 2009-12-14 11:18 power drwxr-xr-x 3 root root0 2009-12-14 10:51 queue -r--r--r-- 1 root root 4096 2009-12-14 10:28 range -r--r--r-- 1 root root 4096 2009-12-14 10:28 removable -r--r--r-- 1 root root 4096 2009-12-14 11:18 ro -r--r--r-- 1 root root 4096 2009-12-14 11:18 size drwxr-xr-x 2 root root0 2009-12-14 10:51 slaves -r--r--r-- 1 root root 4096 2009-12-14 11:18 stat lrwxrwxrwx 1 root root0 2009-12-14 10:28 subsystem - ../../../../../class/block -rw-r--r-- 1 root root 4096 2009-12-14 10:28 uevent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
ael wrote: Alain Knaff wrote: then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0) I should have mentioned that my tests were done under the current git kernel: # uname -a Linux exact 2.6.32_exact-55846-gf405425 #194 Sun Dec 13 16:30:46 GMT 2009 i686 GNU/Linux ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: On 14/12/09 12:27, ael wrote: # getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c # fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument ... and if you try with /dev/fd0 instead? Yes. I tried all the obvious things. The man/info page for fdrawcmd wasn't very clear on exactly what was accepted, so I tried several options. All with the same result. And now Mark has just the same under 2.6.28 vanilla. I guess all these are further clues... Any point in running under strace? Or gdb (not sure whether I have a debug version around...)? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: On 14/12/09 15:58, ael wrote: Any point in running under strace? Yes, this would be useful, especially for analyzing the Invalid argument issue. Ok, Will try and fit it in later today. Meanwhile, what exactly is the command line that should work? The one you suggested didn't match the man page - which is probably incomplete or out of date? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote:
On 14/12/09 15:58, ael wrote:
Any point in running under strace?
Yes, this would be useful, especially for analyzing the Invalid argument
issue.
Looks as if that was something to do with my command line. Below is the
strace giving the IO error which probably isn't much help :-)
# strace fdrawcmd readid 0 repeat=18 21 |tee fdrawcmd.dump|less
--fdrawcmd.dumpexecve(/usr/bin/fdrawcmd,
[fdrawcmd, readid, 0, repeat=18], [/* 34 vars */]) = 0
brk(0) = 0x804b000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb777d000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=94365, ...}) = 0
mmap2(NULL, 94365, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7765000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260l\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1331684, ...}) = 0
mmap2(NULL, 1337704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb761e000
mmap2(0xb775f000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141) = 0xb775f000
mmap2(0xb7762000, 10600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7762000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb761d000
set_thread_area({entry_number:-1 - 6, base_addr:0xb761d6c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb775f000, 8192, PROT_READ) = 0
mprotect(0xb779b000, 4096, PROT_READ) = 0
munmap(0xb7765000, 94365) = 0
open(/dev/fd0, O_ACCMODE|O_NONBLOCK) = 3
gettimeofday({1260803901, 152148}, NULL) = 0
ioctl(3, FDRAWCMD, 0xbf8ce620) = -1 EIO (Input/output error)
dup(2) = 4
fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY)
close(4)= 0
write(2, raw cmd: Input/output error\n, 28raw cmd: Input/output error
) = 28
exit_group(1) = ?
--
Do I need to give strace some flags?
ael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?
Alain Knaff wrote: On 14/12/09 16:24, ael wrote: Alain Knaff wrote: On 14/12/09 15:58, ael wrote: Any point in running under strace? Yes, this would be useful, especially for analyzing the Invalid argument issue. Looks as if that was something to do with my command line. Below is the strace giving the IO error which probably isn't much help :-) # strace fdrawcmd readid 0 repeat=18 21 |tee fdrawcmd.dump|less [...] ioctl(3, FDRAWCMD, 0xbf8ce620) = -1 EIO (Input/output error) Well, at least we now that it is indeed the rawcmd ioctl that gets the error (rather than some other system call), and this is interesting information. Could you also check whether anything interesting got output by the kernel (dmesg) during the fdrawcmd attempt? No. I checked that. Nothing in any of the logs in /var/log/ ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: Also reported in Suse
Just a note for anyone who comes across this report: it seems that the problem is also occurs on SuSE, 10.3-11.2 - Any kernel at or above 2.6.28 fails to fdformat a floppy. That has been reported on the fdutils list and now there is a thread on the kernel mailing list. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: superformat (hd)
I should probably add # superformat /dev/fd0 hd Measuring drive 0's raw capacity In order to avoid this time consuming measurement in the future, add the following line to /etc/driveprm: drive0: deviation=71992 CAUTION: The line is drive and controller specific, so it should be removed before installing a new drive 0 or floppy controller. Not enough raw space on this disk for this format ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: superformat result
I just retested fdformat and superformat on one of the machines with current testing and kernel 2.6.32 . fdformat fails in usual way as previously reported. superformat also fails, but maybe this result gives a clue:- # superformat /dev/fd0 Measuring drive 0's raw capacity In order to avoid this time consuming measurement in the future, add the following line to /etc/driveprm: drive0: deviation=81832 CAUTION: The line is drive and controller specific, so it should be removed before installing a new drive 0 or floppy controller. Not enough raw space on this disk for this format # cat /etc/fdprm /dev/fd0 hd - These tests were done on an already formatted floppy: formatted by fdformat under an old redhat system. Thereis, of course, an strace on superformat above, although that run was a while ago, and produced slightly different results. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: ftutils so util-linux?
I tested both fdformat and superformat (from fdutils 5.5-20060227-3, and then also from 20081027) with kernel 2.6.32-rc6 and on Kubuntu 9.04, and both worked fine. Could it be a bad drive or a bad disk? No. I have used several known good discs and on several (4 actually) machines with known good drives. And I can format the same discs on an old redhat machine. So I am convinced that it isn't hardware: media or drive. Also I can read and write onto previously formatted discs (with file systems), so again that make drive problems unlikely. I said (but forgot later) in one of my first reports that a member of my local LUG had tested on Gentoo and had no problems with the same kernel. It seems to be something specific to Debian which is extremely odd, given you have tested on ubuntu. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: ftutils so util-linux?
Alain Knaff wrote: On 10/11/09 17:42, ael wrote: I tried setting the density to dd instead of hd -- something that I had also tried on fdformat without success. gfloppy managed to Sorry. I think I should have posted more about that, but the report was so long already that I held back. I subsequently discovered that gfloppy was lying. It turned out that the format had not succeeded after all. It was just that gfloppy did not not always report the error. Thereafter it was possible to build a file system, ext2 IIRC, but when it was used CRC errors appeared. This is indeed very useful information, sorry to have not spotted this earlier. Double density disks cannot be formatted as high density. Not only because of the higher surface quality of HD disks, but more importantly because the presence or not of the density select hole switches the _drive_ into the appropriate mode. Yes, I realise that, although I had forgotten the details. The discs are quite certainly HD with the holes open. As I say, I can read and write on to previously formatted discs, so I think that shows that the hole and leds in the drives are all working correctly. Agreed? My experiments with dd and the like was just to see what would happen If both disagree, formatting will fail. I wonder if somehow the formatting software is always going into dd mode? [..snip..] verify to around track 73. This now is probably due to poor quality of disk (maybe due to age?). It's mostly the higher tracks that fail, because on them the spatial density is highest (these are the innermost tracks, thus shorter, but they still contain the same amount of data = more bits crammed into less surface). I have tried maybe 4 different discs, one brand new. I think all of the other discs were previously working. My initial suspicions were all around the media, and I did a lot of experiments on different machines with different media before deciding it had to be software. Just to make absolutely certain, I have just booted up the old redhat machine and successfully formatted and verified one of the failing discs. (fdformat.) So, no, I don't think media problems exist. Thanks for the reply. I am still mystified. Could I somehow, somewhere, in 3 debian testing machines have some common configuration file wrong? Weird, very weird. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: ftutils so util-linux?
Alain Knaff wrote: Btw, did you get around to check the /etc/driveprm (or /usr/local/etc/driveprm file) to make sure nothing fishy is in there? Neither file exists on this machine which I am using for mail ATM - and which has the problem. (Or did when I last tried - must try again given testing has evolved.) I was also explicit about the disk parameters in most of the tests. Of course, if debian has mapped HD to the wrong values, that might explain everything. At the time, I couldn't find the lower level values to check. It did have tracks/sectors right, but there is much more involved in formatting, I know. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: libudev0 version
# dpkg -s libudev0 Package: libudev0 Status: install ok installed Priority: optional Section: libs Installed-Size: 172 Maintainer: Marco d'Itri m...@linux.it Architecture: i386 Source: udev Version: 146-5 Depends: libc6 (= 2.4) Description: libudev shared library It looks as if this version was installed on 29-10-09. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: ftutils so util-linux?
I tried to format one of the floppies using gfloppy. This also failed to verify, but managed to get past several tracks, unlike fdformat. I tried setting the density to dd instead of hd -- something that I had also tried on fdformat without success. gfloppy managed to verify to around track 73. I tried installing a dos filesystem despite the verification errors, and it seemed to work. I then tried fdformat, having used setfdprm to set hd. This time it worked and passed verification. Badblocks also ran without error. I am not sure what to make of all of this, but I wonder if my initial attempts to format with fdformat without checking that the density was set to hd may have written some dense data to the floppy (well, several floppies) which caused problems later. Whatever the case, it does suggest that the problem may be with fdformat with is in util-linux rather than fdutils. So perhaps this report should be re-assigned? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548434: superformat also fails
I tried gfloppy on another machine, but this time without success.
I also tried fdformat many time with various densities, again without
success.
Finally, I tried superformat:-
# setfdprm /dev/fd0 hd
# superformat /dev/fd0 hd
Measuring drive 0's raw capacity
warmup cycle: 0 11168 11168
Fatal error while measuring raw capacity
0: 40
1: 80
2: 40
3: 00
4: 00
5: 01
6: 08
#
I also ran superformat under strace:-
-
execve(/usr/bin/superformat, [superformat, /dev/fd0, hd], [/* 35 vars
*/]) = 0
brk(0) = 0x8059000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77c8000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=96042, ...}) = 0
mmap2(NULL, 96042, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77b
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220l\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1331652, ...}) = 0
mmap2(NULL, 1341768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7668000
mprotect(0xb77a9000, 4096, PROT_NONE) = 0
mmap2(0xb77aa000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141) = 0xb77aa000
mmap2(0xb77ad000, 10568, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77ad000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7667000
set_thread_area({entry_number:-1 - 6, base_addr:0xb76676c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb77aa000, 8192, PROT_READ) = 0
mprotect(0xb77e6000, 4096, PROT_READ) = 0
munmap(0xb77b, 96042) = 0
brk(0) = 0x8059000
brk(0x807a000) = 0x807a000
open(/dev/fd0, O_RDWR|O_EXCL|O_NONBLOCK) = 3
fstat64(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
ioctl(3, FDRESET, 0x1) = 0
ioctl(3, FDGETDRVPRM, 0xbfe2cdf0) = 0
open(/etc/driveprm, O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, Measuring drive 0's raw capacity..., 33Measuring drive 0's raw
capacity
) = 33
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
write(2, warmup cycle: 1 199728 8224\r, 32warmup cycle: 1 199728 8224
) = 32
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
ioctl(3, FDRAWCMD, 0xbfe29c8c) = 0
write(2, \nFatal error while measuring raw..., 42
Fatal error while measuring raw capacity
) = 42
write(2, 0: 40\n, 60: 40
) = 6
write(2, 1: 01\n, 61: 01
) = 6
write(2, 2: 00\n, 62: 00
) = 6
write(2, 3: 00\n, 63: 00
) = 6
write(2, 4: 00\n, 64: 00
) = 6
write(2, 5: 01\n, 65: 01
) = 6
write(2, 6: 08\n, 66: 08
) = 6
exit_group(1) = ?
Thus it appears the superformat is also broken, so fdutils is involved after
all.
This under kernel 2.6.32-rc6. Has the floppy API been changed, perhaps?
ael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555388: xserver-xorg-input-joystick: X segfaults when no joystick connected
Package: xserver-xorg-input-joystick Version: 1:1.4.1-1 Severity: grave Justification: renders package unusable Log file covers everything, I think:- X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30-2-amd64 x86_64 Debian Current Operating System: Linux conquest2 2.6.32-rc6_c2 #39 Fri Nov 6 21:10:55 GMT 2009 x86_64 Build Date: 13 October 2009 09:39:10AM xorg-server 2:1.6.5-1 (jcris...@debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Nov 9 13:15:03 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Conquest2 Layout (**) |--Screen Default Screen (0) (**) | |--Monitor CTX EX710F (**) | |--Device asus en6600 (**) |--Input Device Generic Keyboard (**) |--Input Device Configured Mouse (**) |--Input Device Joystick (**) Option BlankTime 7 (**) Option StandbyTime 15 (**) Option SuspendTime 20 (**) Option OffTime 25 (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/X11R6/lib/X11/fonts/75dpi does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID. Entry deleted from font path. (Run 'mkfontdir' on /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID). (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (**) FontPath set to: unix/:7100, /usr/share/fonts/X11/misc, /usr/X11R6/lib/X11/fonts/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Generic Keyboard (WW) Disabling Configured Mouse (II) Loader magic: 0x3b40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 7 (--) PCI:*(0:1:0:0) 10de:0141:1043:819a nVidia Corporation NV43 [GeForce 6600] rev 162, Mem @ 0xd000/67108864, 0xc000/268435456, 0xd400/16777216, BIOS @ 0x/131072 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) MX[B] [5] -1 0 0x000f - 0x000f (0x1) MX[B] [6] -1 0 0x000c - 0x000e (0x3) MX[B] [7] -1 0 0x - 0x0009 (0xa) MX[B] [8] -1 0 0x - 0x (0x1) MX[B] [9] -1 0 0x000f - 0x000f (0x1) MX[B] [10] -1 0 0x000c - 0x000e (0x3) MX[B] [11] -1 0 0x - 0x0009 (0xa) MX[B] [12] -1 0 0x - 0x (0x1) MX[B] [13] -1 0 0x000f - 0x000f (0x1) MX[B] [14] -1 0 0x000c - 0x000e (0x3) MX[B] [15] -1 0 0x - 0x0009 (0xa) MX[B] [16] -1 0 0x - 0x (0x1) IX[B] [17] -1 0 0x - 0x (0x1) IX[B] [18] -1 0 0x - 0x (0x1) IX[B] [19] -1 0 0x - 0x (0x1) IX[B] [20] -1 0 0x - 0x (0x1) IX[B] [21] -1 0 0x - 0x (0x1) IX[B] [22] -1 0 0x - 0x (0x1) IX[B] [23] -1 0 0x - 0x (0x1) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also
Bug#549312: synaptic has no problem
synaptic installs packages from dvds without problems. Perhaps this bug should be re-assigned back to aptitude? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: Update: synaptic also has problem
I spoke too soon - in my last report. The same problem (sometimes) happens in synaptic. I guess means that the problem lies at a lower level than either synaptic or aptitude. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: aptitude 0.4.11.11 does not build
In my continuing attempts to pin this bug, I have rebuilt dpkg and apt from sources with nostrip, but aptitude-0.4.11.11 does not rebuild on current testing. I guess I could try 0.6.1-1 from sid or maybe aptitude-dbg. It seems as if apt-get no longer has problems installing from /dvd - I haven't done enough testing to be sure - so I speculate that it may be some synchronisation problem between aptitude, the cdrom method and dpkg. Hence my attempt to get an aptitude with symbols running under gdb. Any advice from the people who know the code? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: Running aptitude under gdb
Running aptitude (aptitude-dbg installed) under gdb gives no error: the files from /dvd are read correctly. Which suggests a race? The test run was using both apt and dpkg locally built with nostrip noopt. Source: aptitude (0.4.11.11-1) Version: 0.4.11.11-1+b2 Package: aptitude-dbg Version: 0.4.11.11-1+b2 Package: apt Version: 0.7.23.1 Package: dpkg Version: 1.15.4.1 Summary: There remains a bug on several machines here which prevents aptitude from installing from /dvd, whether loop mounted iso images or real dvds. It is unclear which program is responsible but smells (to me) like some sort of race/synchronisation problem between the processes involved. Problem evaporates when running under gdb. The original segfault may or may not have been related, but has not occured for several weeks. Inspection of the /var/log/dpkg.logs shows that several of the relevant packages have been upgraded at least once since the segfaults appeared. These machines are normally updated to current testing daily. The dvds are updated to current jigo images every week or two, but as testing jigdos are often broken or missing, they are not always current. Hence there can be long periods when the dvds are not used, so it is not easy to correlate the last segfault with any particular package update. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: apt 0.7.21
=false) at acquire-method.cc:389 #6 0x0804b340 in main () at cdrom.cc:201 (gdb) continue Continuing. Program exited normally. (gdb) q === So 0.7.21 seems not to give the segfault, but still has problems. Or it is in another package ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: Correction: 0.7.23.1 - 0.7.21
Just realised that my last report was run on 0.7.23.1 instead of 0.7.21 :-) Working too long on this :-( Will try again tomorrow on he right version... ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: run with apt 0.7.23.1
the files, so it isn't dpkg itself failing, at least not in a simple way. Are other people seeing this problem, or is it unusual to get files from /dvd rather directly from the network? I will update my machine back to current testing for the moment before my dependencies get into a nasty twist! ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: apt cdrom method problem
An update. I have installed the apt source and rebuilt with debugging symbols. I looked at apt_0.7.23.1/methods/cdrom.cc and saw Debug::Acquire::cdrom, so tried setting Debug::Acquire::cdrom true ; in a file under /etc/apt/apt.conf.d/ I also tried running /usr/lib/apt/methods/cdrom under gdb but was unclear whether arguments (I tried full-upgrade) were needed and how the return was handled. So far I have not managed to triger the segfault, although I am still seeing errors from aptitude when it uses cdrom to read dvds. Also I have not seen any extra errors reported via Debug::Acquire::cdrom - I am not sure where they should appear. Just to stderr, and/or somewhere in /var/log/? I see references to Udev in the source code and note that the recent udev rules do not always identify cdroms and dvds correctly (bug reported). But I think the apt dvd segfault predates that change, so perhaps no connection, although even then a segfault obviously isn't exactly desirable :-( ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: segfault from apt cdrom method
I have now built apt-0.7.23.1 from source with symbols (DEB_BUILD_OPTIONS=nostrip noopt) on another i386 machine which was segfaulting. I installed the resulting apt_0.7.23.1_i386.deb (which involved a downgrade on this testing machine). Debug::Acquire::cdrom true; was turned on. I then ran aptitude with an /etc/apt/sources.list with just the dvd entries and installed some octave packages. I attached to the /usr/lib/apt/cdrom process with gdb before inserting the dvd's requested. No segfaults, and gdb reported no problems although it (gdb) did not report termination, even after the cdrom method was no longer shown on htop (a variant of top): (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0xe424 in __kernel_vsyscall () (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0xb7439fad in select () from /lib/i686/cmov/libc.so.6 #2 0xb76716a6 in WaitFd (Fd=0, write=false, timeout=0) at contrib/fileutl.cc:362 #3 0xb769fd2f in pkgAcqMethod::Run (this=0xbfa3c3f4, Single=false) at acquire-method.cc:341 #4 0x0804c31a in main () at cdrom.cc:280 -- So no apparent bugs in cdrom. *However* aptitude did report problems, as for example:- dpkg: error processing /dvd//pool/main/s/suitesparse/libamd2.2.0_3.4.0-1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/libi/libibverbs/libibverbs1_1.1.2-1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/o/openmpi/libopenmpi1.3_1.3.3-1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/a/arpack/libarpack2_2.1+parpack96.dfsg-2+b1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/s/suitesparse/libcamd2.2.0_3.4.0-1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/s/suitesparse/libccolamd2.7.1_3.4.0-1_i386.deb (--unpack): cannot access archive: No such file or directory dpkg: error processing /dvd//pool/main/s/suitesparse/libcholmod1.7.1_3.4.0-1_i386.deb (--unpack): which seem to be coming from dpkg. (I see similar failures on other machines). The mystery deepens. I have not seen segfaults recently (last in logs on Oct 18) but the apt/aptitude/dpkg system still has problems accessing the dvd (whether a real dvd drive or an iso image loop mounted on /dvd). Obviously the iso images have been checked. I have never seen problems with dpkg -i /dev/pool/blah/whatever/* when I have manually mounted the disc or loopmounted-file on /dvd. All small clues to a bug hiding somewhere in there. I could try building the source without noopt, but it doesn't look like that will bring back the segfault. I always have great problems working out when my packages were updated which makes it hard to see what changed when that might have a bearing on these problems. (One thing rpm gets right...) I just look at /var/log/aptitude | ../apt/ logs: is there a better way? Summary: looks like the bug is still present, but has manifested in a surprisingly different form probably with an package update yet to be identified. The fact the cdrom-method segfaulted is clearly an issue although it looks like it will be harder to reproduce than I had hoped. And there is another presumbly related bug present as well ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: Version 0.7.21.
Sorry, had overlooked the request to try 0.7.21. but I think apt 0.7.23.1 was installed during the segfaults. Will try soon. ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: apt-0.7.21
I collected apt-0.7.21 from http://bzr.debian.org/apt/debian-sid/ and built the package with nostrip noopts and installed (dpkg -i apt_0.7.21_i386.deb). But now I have unmet dependencies apt-utils: Depends: libapt-pkg-libc6.9-6-4.8 aptitude: Depends: libapt-pkg-libc6.9-6-4.8 which stops me running aptitude or apt-get. It will take me a while to work out how to get those things installed, I suspect... ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: Bug present in Version: 0.7.24
Tried unstable version of apt: Package: apt, Version: 0.7.24. Problem still present: kernel: cdrom[12053]: segfault at 200 ip b786771d sp bfda3c10 error 4 in ld-2.9.so[b7854000+1c000] Oct 9 12:54:04 conquest3 kernel: cdrom[12061]: segfault at 200 ip b780a71d sp bfe3c510 error 4 in ld-2.9.so[b77f7000+1c000] Oct 9 12:54:22 conquest3 kernel: cdrom[12074]: segfault at 200 ip b777971d sp bf99dc40 error 4 in ld-2.9.so[b7766000+1c000] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: aptitude: cdrom segfaults on several machines and architectures when reading DVDs
Daniel Burrows wrote: # ps -C cdrom PID TTY TIME CMD 5845 pts/000:00:00 cdrom conquest3:~# gdb aptitude 5845 You'll probably have better luck if you debug /usr/lib/cdrom instead of aptitude. :) I don't know if that'll help much, though; it doesn't have debugging symbols built in. I guess that will be /usr/lib/apt/methods/cdrom : $ ls -l /usr/lib/cdrom ls: cannot access /usr/lib/cdrom: No such file or directory I suppose that all I can do is get the source and see if I can rebuild with symbols. Just need the time :-( Why has no one else seen this when it has been happening on all my machines for some time? Maybe use of DVDs is rare these days: I use jigdo to avoid multiple downloads with added advantage of backup/reinstall/new install media always to hand. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: aptitude: cdrom segfaults on several machines and architectures when reading DVDs
Package: aptitude Version: 0.4.11.11-1+b2 Severity: grave Justification: renders package unusable For over a month now (presumably since the last aptitude upgrade on testing) I have been seeing segfaults recorded in /var/log/messages on two i386 boxes and on an amd64, all running testing. I have not reported earlier because I hoped to get some useful info using gdb. My first attempts with gdb have failed to catch the segfault whether using aptitude, aptitude-dbg or directly attaching to the cdrom process spawned by aptitude. 1) An entry in /var/log/messages: Oct 2 10:48:44 conquest3 kernel: cdrom[4987]: segfault at 200 ip b807b71d sp bf a34890 error 4 in ld-2.9.so[b8068000+1c000] Oct 2 10:48:56 conquest3 kernel: cdrom[5028]: segfault at 200 ip b7ff871d sp bf cee290 error 4 in ld-2.9.so[b7fe5000+1c000] Oct 2 10:56:42 conquest3 kernel: cdrom[5031]: segfault at 200 ip b7f9571d sp bf 8e9850 error 4 in ld-2.9.so[b7f82000+1c000] Oct 2 10:56:49 conquest3 kernel: cdrom[5033]: segfault at 200 ip b806971d sp bf a96ac0 error 4 in ld-2.9.so[b8056000+1c000] 2) These are written somewhere around when aptitude prompts for a DVD one is inserted as in Media Change: Please insert the disc labeled 'Debian GNU/Linux testing _Squeeze_ - Official Snapshot i386 DVD Binary-1 20090921-05:51' in the drive '/dvd/' and press [Enter]. 3) aptitude will typically read many of the files from the dvd correctly, but then report an error on at least one of the package files. 4) Obviously I have checked the DVDs and associated hardware. In any case it is happening on several machines with different drives and media. The best I have managed with gdb so far is this sort of thing:- --- # pstree|grep cdrom | |-xterm---su---bash---aptitude-+-cdrom # ps -C cdrom PID TTY TIME CMD 5845 pts/000:00:00 cdrom conquest3:~# gdb aptitude 5845 GNU gdb (GDB) 6.8.50.20090628-cvs-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Attaching to program: /usr/bin/aptitude, process 5845 0xe424 in __kernel_vsyscall () (gdb) handle 11 stop SignalStop Print Pass to program Description SIGSEGV Yes Yes Yes Segmentation fault (gdb) info forks No forks. (gdb) info threads * 1 process 5845 0xe424 in __kernel_vsyscall () (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0xb7c9cfad in ?? () #2 0xb7ec591d in ?? () #3 0x0804b2d3 in ?? () #4 0xb7ec51b7 in ?? () #5 0x0804c8e6 in ?? () #6 0xb7bd97a5 in ?? () #7 0x08049ae1 in ?? () (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) n Program not restarted. (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb7f6371d in ?? () from /lib/ld-linux.so.2 (gdb) bt #0 0xb7f6371d in ?? () from /lib/ld-linux.so.2 #1 0xb7e64ca4 in ?? () #2 0xb7f5deb6 in ?? () from /lib/ld-linux.so.2 #3 0xb7e6503c in ?? () #4 0xb7e64cda in ?? () #5 0xb7ee9feb in ?? () #6 0x0804c8fe in ?? () #7 0xb7bd97a5 in ?? () #8 0x08049ae1 in ?? () (gdb) which is not much help. -- Package-specific info: aptitude 0.4.11.11 compiled at Aug 3 2009 17:14:11 Compiler: g++ 4.3.3 Compiled against: apt version 4.8.0 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.7.20090803 cwidget version: 0.5.13 Apt version: 4.8.1 linux-gate.so.1 = (0xe000) libapt-pkg-libc6.9-6.so.4.8 = /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0xb7f69000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7f25000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7f1f000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7e5c000) libept.so.0 = /usr/lib/libept.so.0 (0xb7de1000) libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb7c9) libz.so.1 = /usr/lib/libz.so.1 (0xb7c7b000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7c62000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7b7) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7b4a000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb7b1f000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb79bf000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb79bb000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb79b7000) /lib/ld-linux.so.2 (0xb8051000) Terminal: xterm $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian
Bug#548434: fdformat fails completely with current kernel
Subject: fdutils: fdformat fails under current kernel(s) Package: fdutils Version: 5.5-20060227-3 Justification: renders package unusable Severity: grave *** Please type your report below this line *** fdformat fails completely on current kernels. example: (retyped by hand ,so typos possible...) # setfdprm /dev/fd0 hd # getfdprm /dev/hd0 DS HD sector=18 # fdformat /dev/fd0 Double sided, 80 tracks, 18 sector/track. Total capacity 1440 kB. Formating ... done. Verifying ... Read: : Input/Output error Problem reading cyclinder 0, expected 18432, read -1 /var/log/messages reports data CRC errors:- Sep 26 11:31:03 exact kernel: [ 108.727707] floppy0: data CRC error: track 0, head 0, sector 3, size 2 Sep 26 11:32:30 exact kernel: [ 195.912529] floppy0: data CRC error: track 0, head 0, sector 1, size 2 Sep 26 11:32:30 exact kernel: [ 196.112518] floppy0: data CRC error: track 0, head 0, sector 1, size 2 Sep 26 11:32:31 exact kernel: [ 197.010847] floppy0: data CRC error: track 0, head 0, sector 10, size 2 Sep 26 11:32:32 exact kernel: [ 197.232729] floppy0: data CRC error: track 0, head 0, sector 12, size 2 Sep 26 11:32:32 exact kernel: [ 197.854571] floppy0: data CRC error: track 0, head 0, sector 14, size 2 Sep 26 11:32:34 exact kernel: [ 199.367041] floppy0: data CRC error: track 0, head 1, sector 3, size 2 Sep 26 11:32:34 exact kernel: [ 199.567047] floppy0: data CRC error: track 0, head 1, sector 3, size 2 Sep 26 11:32:34 exact kernel: [ 200.010748] floppy0: data CRC error: track 0, head 1, sector 7, size 2 Sep 26 11:32:35 exact kernel: [ 200.243533] floppy0: data CRC error: track 0, head 1, sector 10, size 2 Sep 26 11:32:36 exact kernel: [ 201.265301] floppy0: data CRC error: track 0, head 1, sector 12, size 2 Sep 26 11:32:36 exact kernel: [ 201.476236] floppy0: data CRC error: track 0, head 1, sector 13, size 2 Sep 26 11:32:37 exact kernel: [ 203.123078] floppy0: data CRC error: track 0, head 1, sector 17, size 2 Sep 26 11:32:39 exact kernel: [ 204.232240] floppy0: data CRC error: track 1, head 0, sector 3, size 2 Sep 26 11:32:40 exact kernel: [ 205.475930] floppy0: data CRC error: track 1, head 0, sector 7, size 2 Sep 26 11:32:40 exact kernel: [ 205.686864] floppy0: data CRC error: track 1, head 0, sector 8, size 2 Sep 26 11:32:41 exact kernel: [ 207.133744] floppy0: data CRC error: track 1, head 0, sector 12, size 2 Sep 26 11:32:43 exact kernel: [ 208.344612] floppy0: data CRC error: track 1, head 0, sector 13, size 2 Sep 26 11:32:43 exact kernel: [ 208.544608] floppy0: data CRC error: track 1, head 0, sector 13, size 2 Sep 26 11:32:46 exact kernel: [ 211.588163] floppy0: data CRC error: track 1, head 1, sector 14, size 2 Sep 26 11:32:46 exact kernel: [ 211.799070] floppy0: data CRC error: track 1, head 1, sector 15, size 2 Sep 26 11:32:47 exact kernel: [ 212.399073] floppy0: data CRC error: track 1, head 1, sector 15, size 2 Sep 26 11:32:47 exact kernel: [ 212.599053] floppy0: data CRC error: track 1, head 1, sector 15, size 2 Sep 26 11:32:48 exact kernel: [ 213.577045] floppy0: data CRC error: track 2, head 0, sector 7, size 2 Sep 26 11:32:49 exact kernel: [ 214.587854] floppy0: data CRC error: track 2, head 0, sector 8, size 2 Sep 26 11:32:49 exact kernel: [ 214.787839] floppy0: data CRC error: track 2, head 0, sector 8, size 2 Sep 26 11:32:50 exact kernel: [ 215.409653] floppy0: data CRC error: track 2, head 0, sector 10, size 2 Sep 26 11:32:50 exact kernel: [ 216.009596] floppy0: data CRC error: track 2, head 0, sector 10, size 2 Sep 26 11:32:51 exact kernel: [ 216.209592] floppy0: data CRC error: track 2, head 0, sector 10, size 2 Sep 26 11:32:51 exact kernel: [ 216.943967] floppy0: data CRC error: track 2, head 1, sector 1, size 2 Sep 26 11:32:51 exact kernel: [ 217.143920] floppy0: data CRC error: track 2, head 1, sector 1, size 2 Sep 26 11:32:53 exact kernel: [ 218.242258] floppy0: data CRC error: track 2, head 1, sector 10, size 2 Sep 26 11:32:53 exact kernel: [ 218.442166] floppy0: data CRC error: track 2, head 1, sector 10, size 2 Sep 26 11:32:54 exact kernel: [ 219.809271] floppy0: data CRC error: track 3, head 0, sector 1, size 2 Sep 26 11:32:54 exact kernel: [ 220.009281] floppy0: data CRC error: track 3, head 0, sector 1, size 2 Sep 26 11:32:56 exact kernel: [ 221.274683] floppy0: data CRC error: track 3, head 0, sector 7, size 2 Sep 26 11:32:56 exact kernel: [ 221.474769] floppy0: data CRC error: track 3, head 0, sector 7, size 2 Sep 26 11:32:57 exact kernel: [ 222.998180] floppy0: data CRC error: track 3, head 0, sector 18, size 2 Sep 26 11:32:59 exact kernel: [ 224.976404] floppy0: data CRC error: track 0, head 0, sector 7, size 2 Sep 26 11:33:00 exact kernel: [ 225.198254] floppy0: data CRC error: track 0, head 0, sector 9, size 2 This has been tried on two different systems with 3 different known good floppies. So different
Bug#548320: grub-rescue-pc: grub-rescue-floppy.img is too large for a standard floppy!
Package: grub-rescue-pc Version: 1.97~beta3-1 Severity: critical Justification: breaks the whole system $ ls -lh /usr/lib/grub-rescue/grub-rescue-floppy.img -rw-r--r-- 1 root root 1.5M 2009-09-12 17:07 /usr/lib/grub-rescue/grub-rescue-floppy.img A standard floppy is 1.44M, so grub-rescue-floppy.img is too large to fit. If one nevertheless follows README.Debian and uses dd if=/usr/lib/grub-rescue/grub-rescue-floppy.img of=/dev/fd0 bs=32k the resulting floppy fails to boot with the message: GRUB loadingRead Error - -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.31 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages grub-rescue-pc depends on: ii base-files5.0.0 Debian base system miscellaneous f grub-rescue-pc recommends no packages. grub-rescue-pc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538738: ekiga: Can not register (timeout) on 3.2.1~git20090515.9d0263-1
Eugen Dedu wrote: This is a known issue: http://bugzilla.gnome.org/show_bug.cgi?id=579938 Ok. Maybe this bug is now just a reference to that one. In ekiga v3 you can contact people in your network (LAN), through avahi. Ok. That explains the reserved 192.168.*.* local address. According to my limited ekiga knowledge, ekiga v3 starts registration on all the interfaces. However, the SIP server should have retained only one (again, I might be wrong, I do not know much of SIP). I *think* sipgate are using asterisk, maybe modified, but I am not sure. As far as I can tell, sipgate calls are working (echo tests ok), so maybe it is harmless. So what is bug now? Is it that upon changing version, ekiga should be started twice? As above, I think it is just a reference to the upstream bug. Perhaps it should stay open until the upstream bug is closed? ael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538738: ekiga: Can not register (timeout) on 3.2.1~git20090515.9d0263-1
Package: ekiga Version: 3.2.1~git20090515.9d0263-1 Severity: grave Justification: renders package unusable Ekiga 3.2.1 cannot register with my several sip providers. The accounts window shows: Could not register (Timeout) Using another machine running ekiga 2.0.11 IIRC on the same network and so behind the same router/firewall, all is well. Previous versions of ekiga on the machine now running 3.2.1 also worked properly. The sip servers failing are ekiga, sipgate and voip. All of this seems to strongly suggest a 3.2.1 problem. Here is an extract from a -d4 debug output: --- REGISTER sip:ekiga.net SIP/2.0 Route: sip:ekiga.net:5060;lr CSeq: 1 REGISTER Via: SIP/2.0/UDP 86.3.134.70:17469;branch=z9hG4bK980cab20-6e78-de11-8a76-00a0ccd01e96;rport User-Agent: Ekiga/3.2.1 From: sip:anonm...@ekiga.net;tag=66597c20-6e78-de11-8a76-00a0ccd01e96 Call-ID: 4ee06c20-6e78-de11-8a76-00a0ccd01...@conquest3 To: sip:anonm...@ekiga.net Contact: sip:anonm...@86.3.134.70:17469;q=1, sip:anonm...@86.3.134.70:5062;q=0.667, sip:anonm...@192.168.0.3:5062;q=0.334 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/07/26 17:22:06.391 0:10.373 Housekeeper:0xb5551b90 OpalUDP Setting interface to 192.168.0.3%eth0 2009/07/26 17:22:06.414 0:10.397subscriber:0xb1b08b90 OpalMan Listener interfaces: associated transport=udp$86.3.134.70:17469 udp$86.3.134.70:17469,udp$86.3.134.70:5062,udp$192.168.0.3:5062 2009/07/26 17:22:06.445 0:10.427subscriber:0xb1b08b90 SIP Transaction created. 2009/07/26 17:22:06.541 0:10.523subscriber:0xb1b08b90 SIP No SRV lookup as has explicit port number. 2009/07/26 17:22:06.556 0:10.538subscriber:0xb1b08b90 SIP Transaction remote address is udp$sip.voipuser.org:5060 2009/07/26 17:22:06.559 0:10.541subscriber:0xb1b08b90 SIP Sending PDU (640 bytes) to: rem=udp$194.0.210.251:5060,local=udp$86.3.134.70:17469,if=192.168.0.3%eth0 REGISTER sip:sip.voipuser.org SIP/2.0 Route: sip:sip.voipuser.org:5060;lr CSeq: 3 REGISTER Via: SIP/2.0/UDP 86.3.134.70:17469;branch=z9hG4bK124c2321-6e78-de11-8a76-00a0ccd01e96;rport User-Agent: Ekiga/3.2.1 From: sip:an...@sip.voipuser.org;tag=98bbfb20-6e78-de11-8a76-00a0ccd01e96 Call-ID: 0e81f220-6e78-de11-8a76-00a0ccd01...@conquest3 To: sip:an...@sip.voipuser.org Contact: sip:an...@86.3.134.70:17469;q=1, sip:an...@86.3.134.70:5062;q=0.667, sip:an...@192.168.0.3:5062;q=0.334 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/07/26 17:22:06.584 0:10.566subscriber:0xb1b08b90 OpalUDP Setting interface to 192.168.0.3%eth0 2009/07/26 17:22:06.592 0:10.574subscriber:0xb1b08b90 SIP Transaction timers set: retry=0.500, completion=6.000 2009/07/26 17:22:06.716 0:10.698 Housekeeper:0xb5551b90 SIP Transaction 2 REGISTER timeout, making retry 1 2009/07/26 17:22:06.719 0:10.701 Housekeeper:0xb5551b90 SIP Sending PDU (633 bytes) to: rem=udp$217.10.79.23:5060,local=udp$86.3.134.70:17469,if=192.168.0.3%eth0 REGISTER sip:sipgate.co.uk SIP/2.0 Route: sip:sipgate.co.uk:5060;lr CSeq: 2 REGISTER Via: SIP/2.0/UDP 86.3.134.70:17469;branch=z9hG4bKcc58e420-6e78-de11-8a76-00a0ccd01e96;rport User-Agent: Ekiga/3.2.1 From: sip:1049...@sipgate.co.uk;tag=e0d3c820-6e78-de11-8a76-00a0ccd01e96 Call-ID: c29ebc20-6e78-de11-8a76-00a0ccd01...@conquest3 To: sip:1049...@sipgate.co.uk Contact: sip:1049...@86.3.134.70:17469;q=1, sip:1049...@86.3.134.70:5062;q=0.667, sip:1049...@192.168.0.3:5062;q=0.334 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/07/26 17:22:06.723 0:10.705 Housekeeper:0xb5551b90 OpalUDP Setting interface to 192.168.0.3%eth0 2009/07/26 17:22:07.104 0:11.086 Housekeeper:0xb5551b90 SIP Transaction 3 REGISTER timeout, making retry 1 2009/07/26 17:22:07.107 0:11.089 Housekeeper:0xb5551b90 SIP Sending PDU (640 bytes) to: rem=udp$194.0.210.251:5060,local=udp$86.3.134.70:17469,if=192.168.0.3%eth0 REGISTER sip:sip.voipuser.org SIP/2.0 Route: sip:sip.voipuser.org:5060;lr CSeq: 3 REGISTER Via: SIP/2.0/UDP 86.3.134.70:17469;branch=z9hG4bK124c2321-6e78-de11-8a76-00a0ccd01e96;rport User-Agent: Ekiga/3.2.1 From: sip:an...@sip.voipuser.org;tag=98bbfb20-6e78-de11-8a76-00a0ccd01e96 Call-ID: 0e81f220-6e78-de11-8a76-00a0ccd01...@conquest3 To: sip:an...@sip.voipuser.org Contact: sip:an...@86.3.134.70:17469;q=1, sip:an...@86.3.134.70:5062;q=0.667, sip:an...@192.168.0.3:5062;q=0.334 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/07/26 17:22:07.112 0:11.094 Housekeeper:0xb5551b90 OpalUDP Setting interface to 192.168.0.3%eth0 2009/07/26
Bug#535000: policykit-gnome: polkit-gnome-authorization seg faults
Package: policykit-gnome Version: 0.9.2-2 Severity: grave Justification: renders package unusable Very like bug #523646 with a seg fault: $ polkit-gnome-authorization [WARN 12025] polkit-error.c:143:polkit_error_get_error_message(): error != NULL Not built with -rdynamic so unable to print a backtrace ** (polkit-gnome-authorization:12025): WARNING **: Failed to initialize PolicyKit context: (null) [WARN 12025] polkit-error.c:156:polkit_error_free(): error != NULL Not built with -rdynamic so unable to print a backtrace Segmentation fault yy Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages policykit-gnome depends on: ii dbus-x11 1.2.12-1simple interprocess messaging syst ii libc62.9-12 GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdbus-glib-1-2 0.80-4 simple interprocess messaging syst ii libgconf2-4 2.26.2-1GNOME configuration database syste ii libglib2.0-0 2.20.1-2The GLib library of C routines ii libgtk2.0-0 2.16.1-2The GTK+ graphical user interface ii libpango1.0-01.24.0-3+b1 Layout and rendering of internatio ii libpolkit-dbus2 0.9-3 library for accessing PolicyKit vi ii libpolkit-gnome0 0.9.2-2 PolicyKit-gnome library ii libpolkit-grant2 0.9-3 library for obtaining privileges v ii libpolkit2 0.9-3 library for accessing PolicyKit ii policykit0.9-3 framework for managing administrat policykit-gnome recommends no packages. policykit-gnome suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
