Bug#1055825: (no subject)
< bob.dyb...@gmail.com > wrote: > There was no change in the packaging of pw 0.3.84 forcing the removal of > pulseaudio. # apt-get install pipewire-audio Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: pipewire-alsa The following packages will be REMOVED: <<== pulseaudio* The following NEW packages will be installed: pipewire-alsa pipewire-audio 0 upgraded, 2 newly installed, 1 to remove and 4 not upgraded. Need to get 0 B/74.4 kB of archives. After this operation, 6378 kB disk space will be freed. Do you want to continue? [Y/n] There certainly seems to be some conflict between them, as above. > No issue here with pw 0.3.85 to switch between laptop speakers and hdmi > speakers. It appears that I may have mis-characterized the problem. Now testing with pipewire v0.3.85 — if the TV is on BEFORE the desktop session starts, then HDMI audio works, and "pavucontrol" can be used to switch an audio stream back and forth between analog speakers and HDMI. However, if the TV is turned on AFTER the desktop session starts, "pavucontrol" still finds the HDMI device, and will offer to switch the stream to it, but nothing comes out of the TV speakers. There are new problems with pipewire v0.3.85 — the "pavucontrol" UI is extremely sluggish, for some reason, and the amplitude indicator is either nonfunctional, or sometimes does not appear at all.
Bug#1055825: pipewire v0.3.84 breaks HDMI audio
Package: pipewire Version: 0.3.84-1 Severity: important hardware: # lspci | grep -i -e audio -e vga 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40) 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti HDMI Audio [Radeon HD 7870 XT / 7950/7970] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] analog speakers connected to 3.5mm audio jack on AMD-chipset motherboard 1920*1080 LCD monitor connected to DVI-D interface on R9-280 video card 1920*1080 LCD TV connected to HDMI interface on R9-280 video card Until pipewire v0.3.83, I had some mixture of pipewire and pulseaudio installed; it was then possible to switch the output of a playing audio stream between the external speakers and the TV, with the "pavucontrol" utility. pipewire v0.3.84 broke that. It forced the removal of pulseaudio (except some libraries), and disabled HDMI audio completely. HDMI output can still be selected in "pavucontrol", and the amplitude indicator wiggles appropriately, but absolutely nothing comes out of the TV speakers. Switching the stream back to the analog speakers works properly; switching to HDMI produces silence. I have now downgraded pipewire to v0.3.65/stable, and everything works properly again. A playing stream can be switched back and forth repeatedly between speakers and TV, with no problems. pipewire v0.3.83 is no longer available in the archive for testing, but something between v0.3.65 and v0.3.84 broke HDMI audio completely, at least with this hardware configuration, which doesn't seem particularly unusual. Here are the relevant package versions (for working configuration); everything else, including Linux kernel, is current Debian-testing. # dpkg -l | grep pulse ii gstreamer1.0-pulseaudio:amd641.22.6-1+b1 amd64 GStreamer plugin for PulseAudio (transitional package) ii libpulse-mainloop-glib0:amd6416.1+dfsg1-2+b1 amd64 PulseAudio client libraries (glib support) ii libpulse0:amd64 16.1+dfsg1-2+b1 amd64 PulseAudio client libraries ii libsox-fmt-pulse:amd64 14.4.2+git20190427-3.5amd64SoX PulseAudio format I/O library ii pipewire-pulse 0.3.65-3 amd64 PipeWire PulseAudio daemon ii xfce4-pulseaudio-plugin:amd640.4.8-1 amd64Xfce4 panel plugin to control pulseaudio # dpkg -l | grep pipewire ii libpipewire-0.3-0:amd64 0.3.65-3amd64libraries for the PipeWire multimedia server ii libpipewire-0.3-common 0.3.65-3all libraries for the PipeWire multimedia server - common files ii libpipewire-0.3-modules:amd640.3.65-3amd64libraries for the PipeWire multimedia server - modules ii pipewire:amd64 0.3.65-3amd64audio and video processing engine multimedia server ii pipewire-alsa:amd64 0.3.65-3amd64PipeWire ALSA plugin ii pipewire-audio 0.3.65-3all recommended set of PipeWire packages for a standard audio desktop use ii pipewire-bin 0.3.65-3amd64PipeWire multimedia server - programs ii pipewire-pulse 0.3.65-3amd64PipeWire PulseAudio daemon -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipewire depends on: ii adduser 3.137 ii init-system-helpers 1.65.2 ii libpipewire-0.3-modules 0.3.65-3 ii pipewire-bin 0.3.65-3 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#1030778: firmware-nonfree: source package has disappeared from testing and unstable archives
Source: firmware-nonfree
Version: 20210315-3
Severity: important
Tags: ftbfs
On the tracker page for the "firmware-nonfree" source package, we read that
the testing and unstable versions should be 20221214-5 and 20230117-2,
respectively:
https://tracker.debian.org/pkg/firmware-nonfree
https://tracker.debian.org/news/141/firmware-nonfree-20221214-5-migrated-
to-testing/
https://tracker.debian.org/news/1415807/accepted-firmware-
nonfree-20230117-1-source-into-unstable/
https://tracker.debian.org/news/1417869/accepted-firmware-
nonfree-20230117-2-source-into-unstable/
The stable package page is here:
https://packages.debian.org/source/bullseye/firmware-nonfree
However, the testing and unstable packages are said not to exist:
https://packages.debian.org/source/bookworm/firmware-nonfree
("Error: Package not available in this suite.")
https://packages.debian.org/source/sid/firmware-nonfree
("Error: Package not available in this suite.")
Binary packages have similarly disappeared from the archive:
# apt-show-versions -a firmware-linux-nonfree
firmware-linux-nonfree:all 20221214-3 install ok installed
firmware-linux-nonfree:all 20210315-3 stable deb.debian.org
No stable-updates version
No testing version
No unstable version
No experimental version
firmware-linux-nonfree:all 20221214-3 newer than version in archive
Surely this is a problem?
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#994741: inkscape: Inkscape v1.1 is not being built for amd64 and other architectures
Package: inkscape Version: 1.1-1 Severity: important Inkscape v1.1 is not being successfully built for amd64. It is, however, being built for i386, ia64, ppc64, and sparc64, so it's hard to see why amd64, surely by far the most common, and most tested, architecture, would be omitted. There seem to be some other architectures missing as well. https://packages.debian.org/experimental/inkscape The build logs suggest some kind of misconfiguration of the build environment: Start 303: render_text-gzipped-svg-glyph 303/303 Test #303: render_text-gzipped-svg-glyph ...***Failed0.26 sec Unable to init server: Could not connect: Connection refused Failed to get connection ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_call: assertion 'DBUS_IS_G_PROXY (proxy)' failed ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_connection_register_g_object: assertion 'connection != NULL' failed end_font_face_cb: font face rule limited support. font-family : 'GeomTest'; src : url(fonts/GeomTest-gzipped-SVG-glyphs.otf) end_font_face_cb: Added font: /<>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG- glyphs.otf Background RRGGBBAA: ff00 Area 0:0:110:40 exported to 110 x 40 pixels (96 dpi) Pixbuf::create_from_file: Unrecognized image file format () Pixbuf::create_from_file: Unrecognized image file format () Pixbuf::create_from_file: Unrecognized image file format () 1589 text-gzipped-svg-glyph FAILED text-gzipped-svg-glyph-large SKIPPED 99% tests passed, 1 tests failed out of 303 https://buildd.debian.org/status/fetch.php?pkg=inkscape&arch=amd64&ver=1.1-1&stamp=1629559190&raw=0 https://buildd.debian.org/status/fetch.php?pkg=inkscape&arch=amd64&ver=1.1-1&stamp=1623167725&raw=0 Why should there be a "connection refused" on amd64, when there was not on several other architectures? In any case, this does not appear to be a problem with the compiler or linker, but some kind of build system failure, unrelated to Inkscape itself. Can this not be investigated, and fixed? Inkscape v1.1 was released four months ago, and Inkscape v1.0.2 is extremely buggy, so it would be good if this problem could be fixed soon, or there could be some investigation of the reason why this particular regression test would fail on amd64, but succeed on other architectures, both 32- and 64-bit. This seems to be a problem with the build environment, and it is probably breaking other packages as well. Please look into it as soon as possible.
Bug#978049: vulkan-tools: Vulkan not usable by default on AMD hardware
Package: vulkan-tools Version: 1.2.154.0+dfsg1-1 Severity: important # vulkaninfo ERROR at /build/vulkan-tools-tihVv9/vulkan- tools-1.2.154.0+dfsg1/vulkaninfo/vulkaninfo.h:248:vkEnumerateInstanceExtensionProperties failed with ERROR_INITIALIZATION_FAILED a google search finds this page -- https://bbs.archlinux.org/viewtopic.php?id=254015 -- which suggests that the root problem is that the wrong kernel module is getting loaded. and so it turns out to be: # lspci -k ... 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] Subsystem: Hightech Information System Ltd. Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] Kernel driver in use: radeon Kernel modules: radeon, amdgpu it doesn't seem reasonable that end users should have to figure this out, and edit the mkinitramfs config files, or whatever, to get this to work. can't it be arranged that the amdgpu kernel module is preferred over the radeon kernel module, whenever AMD GCN video hardware is detected? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vulkan-tools depends on: ii libc6 2.31-5 ii libgcc-s1 10.2.1-1 ii libstdc++6 10.2.1-1 ii libvulkan1 1.2.154.1-1 ii libwayland-client0 1.18.0-2~exp1.1 ii libx11-62:1.6.12-1 ii libxcb1 1.14-2 vulkan-tools recommends no packages. vulkan-tools suggests no packages. -- no debconf information
Bug#973976: libb2-1: please package BLAKE3 library
Package: libb2-1 Version: 0.98.1-1.1 Severity: wishlist Please consider packaging the new BLAKE3 hash library, either as part of the libb2-1 package, or separately. https://www.blake2.net/ https://github.com/BLAKE3-team/BLAKE3 description: We present BLAKE3, an evolution of the BLAKE2 cryptographic hash that is both faster and also more consistently fast across different platforms and input sizes. BLAKE3 supports an unbounded degree of parallelism, using a tree structure that scales up to any number of SIMD lanes and CPU cores. On Intel Cascade Lake-SP, peak single-threaded throughput is 4x that of BLAKE2b, 8x that of SHA-512, and 12x that of SHA-256, and it can scale further using multiple threads. BLAKE3 is also efficient on smaller architectures: throughput on a 32-bit ARM1176 core is 1.3x that of SHA-256 and 3x that of BLAKE2b and SHA-512. Unlike BLAKE2 and SHA-2, with different variants better suited for different platforms, BLAKE3 is a single algorithm with no variants. It provides a simplified API supporting all the use cases of BLAKE2, including keying and extendable output. The tree structure also supports new use cases, such as verified streaming and incremental updates. https://raw.githubusercontent.com/BLAKE3-team/BLAKE3-specs/master/blake3.pdf Thank you. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libb2-1 depends on: ii libc6 2.31-4 ii libgomp1 10.2.0-16 libb2-1 recommends no packages. libb2-1 suggests no packages. -- no debconf information
Bug#971925: cpio: manual page does not document "--list" option
Package: cpio Version: 2.13+dfsg-4 Severity: normal Tags: upstream "cpio --help" provides the following information: Main operation mode: -i, --extract Extract files from an archive (run in copy-in mode) -o, --create Create the archive (run in copy-out mode) -p, --pass-through Run in copy-pass mode -t, --list Print a table of contents of the input however, "man cpio" does not describe the "--list" option, and the "-t" equivalent is only implicitly mentioned: The operation mode is requested by one of the following options: -o, --create Copy-out. Read a list of file names from the standard input and create on the standard output (unless overridden by the --file option) an archive containing these files. -i, --extract Copy-in. Read the archive from standard input (or from the file supplied with the --file option) and extract files from it, or (if the -t option is given) list its contents to the standard output. If one or more patterns are supplied, read or list only files matching these patterns. The -t option alone implies -i. -p, --pass-through Pass-through. Read a list of file names from the standard input and copy them to the specified directory. the only mention of the "--list" option is in the SYNOPSIS section of the manual page, but it is not explained, or specified as the equivalent of "-t". the manual page should be rewritten to match the description given by "cpio --help", which makes clear that "-t" / "--list" is one of the main operating modes of the cpio command, and not some kind of minor variation of the "--extract" mode. related bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558149 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=72 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cpio depends on: ii libc6 2.31-3 cpio recommends no packages. Versions of packages cpio suggests: pn libarchive1 -- no debconf information
Bug#958487: inkscape: Inkscape v1.0 requires libcairo v1.17
Package: inkscape Version: 0.92.5-1 Severity: normal One of the new features in Inkscape v1.0 is the ability to export PNG images with 16-bit colour depth: https://wiki.inkscape.org/wiki/index.php?title=Release_notes/1.0#Export_PNG_images However, this depends on the corresponding feature in the Cairo graphics library, which only became available in version 1.17.2, released over a year ago: https://cairographics.org/news/cairo-1.17.2/ But this version is not yet available in the Debian archive, even in experimental: # apt-show-versions -a libcairo2 libcairo2:amd64 1.16.0-4 install ok installed libcairo2:amd64 1.16.0-4 stable ftp.us.debian.org No stable-updates version libcairo2:amd64 1.16.0-4 testing ftp.us.debian.org libcairo2:amd64 1.16.0-4 unstable ftp.us.debian.org No experimental version libcairo2:amd64/testing 1.16.0-4 uptodate Cairo v1.17.2 in turn depends on libpixman v0.36, which is available in the Debian archive. However, it is also over a year out-of-date; the current version is v0.40: https://www.cairographics.org/releases/ Please upgrade the Debian version of libcairo, and possibly also libpixman, to the current release, so that the new 16-bit colour depth functionality in Inkscape can be supported. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libatkmm-1.6-1v5 2.28.0-2 ii libc62.30-4 ii libcairo21.16.0-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-1 ii libdbus-glib-1-2 0.110-5 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgc1c2 1:7.6.4-0.4 ii libgcc-s110-20200411-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libglib2.0-0 2.64.1-1 ii libglibmm-2.4-1v52.64.2-1 ii libgomp1 10-20200411-1 ii libgsl23 2.5+dfsg-6+b1 ii libgtk2.0-0 2.24.32-4 ii libgtkmm-2.4-1v5 1:2.24.5-4 ii libgtkspell0 2.0.16-1.3 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-4+b1 ii libmagick++-6.q16-8 8:6.9.10.23+dfsg-2.1+b2 ii libpango-1.0-0 1.44.7-3 ii libpangocairo-1.0-0 1.44.7-3 ii libpangoft2-1.0-01.44.7-3 ii libpangomm-1.4-1v5 2.42.1-1 ii libpng16-16 1.6.37-2 ii libpoppler-glib8 0.71.0-6 ii libpoppler82 0.71.0-6 ii libpopt0 1.16-14 ii libpotrace0 1.16-2 ii librevenge-0.0-0 0.0.4-6+b1 ii libsigc++-2.0-0v52.10.2-1 ii libstdc++6 10-20200411-1 ii libvisio-0.1-1 0.1.7-1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.6.9-2 ii libxml2 2.9.10+dfsg-4 ii libxslt1.1 1.1.34-4 ii python2 2.7.17-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: ii aspell 0.60.8-1 ii fig2dev 1:3.2.7b-3 ii imagemagick 8:6.9.10.23+dfsg-2.1+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1 ii libwmf-bin 0.2.8.4-17 ii python-lxml 4.5.0-1+b1 ii python-numpy 1:1.16.5-5 ii python-scour 0.37-2 Versions of packages inkscape suggests: ii dia 0.97.3+git20160930-9 pn inkscape-tutorials pn libsvg-perl pn libxml-xql-perl ii pstoedit 3.75-1 pn python-uniconvertor ii ruby 1:2.7+1
Bug#933773: mdadm: manual page incorrectly documents --size option
Package: mdadm Version: 4.1-2 Severity: normal Tags: upstream The mdadm(8) manual page describes the "--size" option as follows: Amount (in Kilobytes) of space to use from each drive in RAID levels 1/4/5/6. This must be a multiple of the chunk size, and must leave about 128Kb of space at the end of the drive for the RAID superblock. If this is not specified (as it normally is not) the smallest drive (or partition) sets the size, though if there is a variance among the drives of greater than 1%, a warning is issued. However, leaving the size unspecified does not actually work: # mdadm --grow /dev/md/boot1 --size mdadm: option '--size' requires an argument Usage: mdadm --help for help Fortunately, "mdadm --grow --help" explains why: --size=-z : Change the active size of devices in an array. : This is useful if all devices have been replaced : with larger devices. Value is in Kilobytes, or : the special word 'max' meaning 'as large as possible'. And specifying the size as "max" actually does what is expected: # mdadm --grow /dev/md/boot1 --size=max mdadm: component size of /dev/md/boot1 has been set to 393152K The manual page needs to be updated to reflect the actual usage of the "--size" option. Although the "max" keyword is mentioned in a subsequent paragraph, the description of the option is unclear and misleading. -- Package-specific info: WARNING: the following output was not generated by the root user. If you can, please replace the following up until "-- System Information:" with the output of /usr/share/bug/mdadm/script 3>&1 run as root. Thanks! --- mdadm.conf CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST MAILADDR root ARRAY /dev/md/boot1 metadata=1.2 UUID=ba76a595:e40a1f39:c877443a:2f7b1374 name=sixtie:boot1 ARRAY /dev/md/data1 metadata=1.2 UUID=65aa7e93:5b4d84c9:b5ef738d:b9d2d8a0 name=sixtie:data1 ARRAY /dev/md/0 metadata=1.2 UUID=a4386ed0:4f2c478f:c3f1bb2b:d9b66f14 name=sixtie:0 ARRAY /dev/md/1 metadata=1.2 UUID=41d502d3:d79096dd:77f88c8d:9e4cb843 name=sixtie:1 --- /etc/default/mdadm AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=false --- /proc/mdstat: Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] md126 : active raid10 sda6[0] sdb6[1] sdc6[2] 403041792 blocks super 1.2 512K chunks 3 far-copies [3/3] [UUU] bitmap: 1/4 pages [4KB], 65536KB chunk md127 : active raid1 sda2[0] sdb2[1] sdc2[2] 393152 blocks super 1.2 [3/3] [UUU] bitmap: 0/1 pages [0KB], 65536KB chunk unused devices: --- /proc/partitions: major minor #blocks name 8 16 976762584 sdb 8 17 3072 sdb1 8 18 393216 sdb2 8 21 131072 sdb5 8 22 403173376 sdb6 8 23 16777216 sdb7 8 24 16777216 sdb8 8 25 16777216 sdb9 8 26 522728448 sdb10 80 976762584 sda 81 3072 sda1 82 393216 sda2 85 131072 sda5 86 403173376 sda6 87 16777216 sda7 88 16777216 sda8 89 16777216 sda9 8 10 522728448 sda10 8 32 976762584 sdc 8 33 3072 sdc1 8 34 393216 sdc2 8 37 131072 sdc5 8 38 403173376 sdc6 8 39 16777216 sdc7 8 40 16777216 sdc8 8 41 16777216 sdc9 8 42 522728448 sdc10 8 48 2930266584 sdd 8 49 3072 sdd1 8 50 262144 sdd2 8 51 268435456 sdd3 8 52 2661564416 sdd4 9 127 393152 md127 9 126 403041792 md126 25302097152 dm-0 2531 16777216 dm-1 2532 25165824 dm-2 2534 489168896 dm-4 2533 16777216 dm-3 2535 33554432 dm-5 2536 67108864 dm-6 2537 134217728 dm-7 2538 100663296 dm-8 2539 2625634304 dm-9 253 10 201326592 dm-10 253 11 486539264 dm-11 253 12 503316480 dm-12 253 13 16777216 dm-13 --- LVM physical volumes: LVM does not seem to be used. --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=8107992k,nr_inodes=2026998,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1634116k,mode=755) /dev/mapper/system130907-root on / type ext4 (rw,relatime,errors=remount-ro,stripe=384) /dev/mapper/system130907-usr on /usr type ext4 (rw,relatime,stripe=384) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime
Bug#932620: libcrypto++-dev: cannot link dynamic library
Package: libcrypto++-dev Version: 5.6.4-8 Severity: important For some reason, linking to the crypto++ dynamic library fails. Note that these are linker errors; the compiler has no problem. What is wrong with this? Is some other option necessary? If so, it should go in a README file. $ g++ -I/usr/include/cryptopp -o fingerprint fingerprint.cc -lcryptopp /usr/bin/ld: /tmp/ccphZUrI.o: in function `main': fingerprint.cc:(.text+0x6e2): undefined reference to `CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o: in function `CryptoPP::BLAKE2b::BLAKE2b(bool, unsigned int)': fingerprint.cc:(.text._ZN8CryptoPP7BLAKE2bC2Ebj[_ZN8CryptoPP7BLAKE2bC5Ebj]+0x25): undefined reference to `CryptoPP::BLAKE2_Base::BLAKE2_Base(bool, unsigned int)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x88): undefined reference to `CryptoPP::BLAKE2_Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xa8): undefined reference to `CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xb0): undefined reference to `CryptoPP::BLAKE2_Base::Restart()' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xb8): undefined reference to `CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xf0): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x108): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Restart()' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x148): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x88): undefined reference to `CryptoPP::BLAKE2_Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xa8): undefined reference to `CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xb0): undefined reference to `CryptoPP::BLAKE2_Base::Restart()' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xb8): undefined reference to `CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xf0): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x108): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Restart()' /usr/bin/ld: /tmp/ccphZUrI.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x148): undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)' collect2: error: ld returned 1 exit status -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcrypto++-dev depends on: ii libcrypto++6 5.6.4-8 libcrypto++-dev recommends no packages. libcrypto++-dev suggests no packages. -- no debconf information
Bug#922396: webext-noscript: version out of date -- does not work with current Firefox
Package: webext-noscript Version: 10.1.9.6-2 Severity: important The latest version of NoScript in the Debian archive is v10.1.9.6, whereas the current released version is v10.2.1 . https://noscript.net/changelog The Debian version appears not to work with Firefox v65.0.1, which has just entered the "unstable" archive. Please upgrade the Debian NoScript package to the current version, so that it is compatible with the Debian Firefox package. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled webext-noscript depends on no packages. Versions of packages webext-noscript recommends: ii firefox 65.0.1-1 webext-noscript suggests no packages. -- no debconf information
Bug#903552: apt: complains about "unsandboxed download" and undocumented config parameter "pkgAcquire::Run"
Package: apt Version: 1.6.2 Severity: important # apt-get source inkscape Reading package lists... Done Selected version '0.92.3-2' (testing) for inkscape NOTICE: 'inkscape' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/multimedia-team/inkscape.git Please use: git clone https://salsa.debian.org/multimedia-team/inkscape.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 31.6 MB of source archives. Get:1 http://ftp.us.debian.org/debian testing/main inkscape 0.92.3-2 (dsc) [2891 B] Get:2 http://ftp.us.debian.org/debian testing/main inkscape 0.92.3-2 (tar) [31.6 MB] Get:3 http://ftp.us.debian.org/debian testing/main inkscape 0.92.3-2 (asc) [181 B] Get:4 http://ftp.us.debian.org/debian testing/main inkscape 0.92.3-2 (diff) [28.2 kB] Fetched 31.6 MB in 46s (687 kB/s) dpkg-source: info: extracting inkscape in inkscape-0.92.3 dpkg-source: info: unpacking inkscape_0.92.3.orig.tar.bz2 dpkg-source: info: unpacking inkscape_0.92.3-2.debian.tar.xz dpkg-source: info: applying 0001-Drop_PS_and_PDF_support_in_MimeType.patch dpkg-source: info: applying 0002-typos-libcroco.patch dpkg-source: info: applying upstream/trunk/15400.patch W: Download is performed unsandboxed as root as file 'inkscape_0.92.3-2.dsc' couldn't be accessed by user '_apt'. \ - pkgAcquire::Run (13: Permission denied) # grep apt /etc/passwd _apt:x:126:65534::/nonexistent:/bin/false Note that the supposed config parameter "pkgAcquire::Run" is unknown to the apt(8), apt-get(8), and apt.conf(5) manual pages, as well as the file "/usr/share/doc/apt/examples/configure-index.gz", which is supposed to be "an index of all APT configuration directives". see also here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864179 https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/1522675 https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1543280 http://forums.debian.net/viewtopic.php?f=17&t=133676&start=15 https://askubuntu.com/questions/908800/what-does-this-synaptic-error-message- mean https://forums.linuxmint.com/viewtopic.php?t=242358 http://www.google.com/search?q=Download+is+performed+unsandboxed+as+root+as+file+couldn%27t+be+accessed+by+user+_apt+pkgAcquire%3A%3ARun -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.16\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^postgresql-"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-modules"; APT::VersionedKernelPackages:: "linux-modules-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages::
Bug#902593: reportbug: should "Recommend:" package gir1.2-vte-2.91
Package: reportbug Version: 7.1.10 Severity: normal Currently, reportbug "Suggests:" package "gir1.2-vte-2.91". If this package is not installed, as would be the default for "Suggests:", running reportbug produces the surprising dialog box attached here as an image, requesting installation of that package, on pain of "Falling back to text interface." This is rather unreasonable behaviour. It's probably not appropriate to make that package a dependency, but it should at least be a "Recommends:", so that a default installation avoids this obstacle. Perhaps the intention was to avoid pulling in graphical dependencies on text-only systems, which makes sense. A possible solution would be to create a "reportbug-gtk" package, which included all the graphical code and dependencies, leaving the text-mode version in the original "reportbug" package. Many other text/graphical packages have adopted this split-package solution. -- Package-specific info: ** Environment settings: INTERFACE="gtk2" ** /home/ian/.reportbugrc: reportbug_version "6.6.6" mode standard ui gtk2 realname "Ian Bruce" email "ian_br...@mail.ru" no-cc header "X-Debbugs-CC: ian_br...@mail.ru" smtphost reportbug.debian.org -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt1.6.2 ii python33.6.5-3 ii python3-reportbug 7.1.10 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: ii claws-mail 3.16.0-2 pn debconf-utils ii debsums2.2.2 pn dlocate ii emacs25-bin-common 25.2+1-6+b2 ii exim4 4.91-5 ii exim4-daemon-light [mail-transport-agent] 4.91-5 ii file 1:5.33-3 ii gir1.2-gtk-3.0 3.22.29-3 ii gir1.2-vte-2.910.52.0-1 ii gnupg 2.2.8-3 ii python3-gi 3.28.2-1 ii python3-gi-cairo 3.28.2-1 pn python3-gtkspellcheck pn python3-urwid ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.6.2 ii file 1:5.33-3 ii python33.6.5-3 ii python3-apt1.6.1 ii python3-debian 0.1.32 ii python3-debianbts 2.7.2 ii python3-requests 2.18.4-2 python3-reportbug suggests no packages. -- no debconf information
Bug#890724: gcc-7: redundant base packages
Package: gcc-7 Version: 7.3.0-3 Severity: normal The files in these packages seem to be essentially duplicates of each other. Is this really necessary? # deborphan gcc-6-base gcc-7-base gcc-8-base gcc-6-base libgcj17 gcj-6-jre-headless gcj-6-jre-lib libgcj17-awt gcj-6-jre gcc-7-base libasan4 libgfortran4 gcc-7 g++-7 libcilkrts5 libubsan0 libgcc-7-dev cpp-7 libstdc++-7-dev libobjc-7-dev gcc-8-base libquadmath0 libgomp1 libatomic1 libcc1-0 libobjc4 libtsan0 liblsan0 libmpx2 libstdc++6 lib32stdc++6 libitm1 libgcc1 lib32gcc1 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-7 depends on: ii binutils 2.30-4 ii cpp-7 7.3.0-3 ii gcc-7-base7.3.0-3 ii libc6 2.26-4 ii libcc1-0 8-20180207-2 ii libgcc-7-dev 7.3.0-3 ii libgcc1 1:8-20180207-2 ii libgmp10 2:6.1.2+dfsg-2 ii libisl15 0.18-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.0-7 ii libstdc++68-20180207-2 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.26-4 Versions of packages gcc-7 suggests: ii gcc-7-doc 7.2.0-1 pn gcc-7-locales pn gcc-7-multilib pn libasan4-dbg pn libatomic1-dbg pn libcilkrts5-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information
Bug#885446: systemd: user processes remain after logout
Package: systemd Version: 236-1 Severity: important Is there any legitimate reason why after logging out of an XFCE session, all these desktop processes should remain alive? # ps axfu | grep ^ian ian 1687 0.0 0.0 80544 8384 ?Ss 19:35 0:00 /lib/systemd/systemd --user ian 1688 0.0 0.0 198308 3328 ?S19:35 0:00 \_ (sd-pam) ian 1712 0.0 0.0 49884 4628 ?Ss 19:35 0:00 \_ /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ian 1761 0.0 0.0 287908 6696 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfsd ian 1781 0.0 0.0 348884 8172 ?Ssl 19:35 0:00 \_ /usr/lib/at-spi2-core/at-spi-bus-launcher ian 1786 0.0 0.0 49392 3612 ?S19:35 0:00 | \_ /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 ian 1796 0.0 0.0 58948 5136 ?S19:35 0:00 \_ /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd ian 1803 0.0 0.0 94464 2928 ?SLs 19:35 0:00 \_ /usr/bin/gpg-agent --supervised ian 1866 0.0 0.0 362732 12304 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfs-udisks2-volume-monitor ian 1870 0.0 0.0 286540 6172 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfs-gphoto2-volume-monitor ian 1874 0.0 0.0 377216 7432 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfs-afc-volume-monitor ian 1879 0.0 0.0 272236 5252 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfs-goa-volume-monitor ian 1883 0.0 0.0 274168 5560 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfs-mtp-volume-monitor ian 1903 0.0 0.0 364068 6684 ?Sl 19:35 0:00 \_ /usr/lib/gvfs/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0 ian 1908 0.0 0.0 187628 5084 ?Sl 19:35 0:00 \_ /usr/lib/dconf/dconf-service ian 1925 0.0 0.0 198308 4380 ?Ssl 19:35 0:00 \_ /usr/lib/gvfs/gvfsd-metadata ian 2029 0.0 0.0 76028 5580 ?S19:35 0:00 \_ /usr/lib/x86_64-linux-gnu/gconf/gconfd-2 ian 1753 0.2 0.0 357636 7136 ?Ssl 19:35 0:01 /usr/bin/ibus-daemon --daemonize --xim ian 1773 0.0 0.0 276644 8308 ?Sl 19:35 0:00 \_ /usr/lib/ibus/ibus-dconf ian 1806 0.0 0.0 200916 5752 ?Sl 19:35 0:00 \_ /usr/lib/ibus/ibus-engine-simple ian 2051 0.0 0.0 303972 10976 ?Sl 19:35 0:00 \_ /usr/lib/ibus-mozc/ibus-engine-mozc --ibus ian 2055 0.0 0.1 95956 29312 ?SLl 19:35 0:00 \_ /usr/lib/mozc/mozc_server ian 1917 0.0 0.2 254324 33804 ?Sl 19:35 0:00 /usr/bin/python3 /usr/share/system-config-printer/applet.py It may be a related issue that also after logging out, a tmpfs remains mounted at /run/user/. -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.116 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.1-4 ii libaudit1 1:2.8.2-1 ii libblkid1 2.30.2-0.1 ii libc6 2.25-5 ii libcap2 1:2.25-1.2 ii libcryptsetup4 2:1.7.5-1 ii libgcrypt20 1.8.1-4 ii libgpg-error0 1.27-5 ii libidn111.33-2.1 ii libip4tc0 1.6.1-2+b1 ii libkmod224-1 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.3 ii libmount1 2.30.2-0.1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.7-2 ii libsystemd0 236-1 ii mount 2.30.2-0.1 ii procps 2:3.3.12-3 ii util-linux 2.30.2-0.1 Versions of packages systemd recommends: ii dbus1.12.2-1 ii libpam-systemd 236-1 Versions of packages systemd suggests: ii policykit-10.105-18 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 236-1 -- no debconf information
Bug#884092: freecad: bad dependency
Package: freecad Version: 0.16.6712+dfsg1-1+b2 Severity: normal Why does freecad have dependencies for both "python2.7" and "python:any"? They can't both be correct. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages freecad depends on: ii libboost-atomic1.62.0 1.62.0+dfsg-4+b2 ii libboost-chrono1.62.0 1.62.0+dfsg-4+b2 ii libboost-date-time1.62.01.62.0+dfsg-4+b2 ii libboost-filesystem1.62.0 1.62.0+dfsg-4+b2 ii libboost-program-options1.62.0 1.62.0+dfsg-4+b2 ii libboost-python1.62.0 1.62.0+dfsg-4+b2 ii libboost-regex1.62.01.62.0+dfsg-4+b2 ii libboost-signals1.62.0 1.62.0+dfsg-4+b2 ii libboost-system1.62.0 1.62.0+dfsg-4+b2 ii libboost-thread1.62.0 1.62.0+dfsg-4+b2 ii libc6 2.25-3 ii libcoin80v5 3.1.4~abc9f50+dfsg1-2 ii libfreeimage3 3.17.0+ds1-5+b2 ii libfreetype62.8.1-0.1 ii libgcc1 1:7.2.0-17 ii libgl1 1.0.0-1 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii liboce-foundation11 0.18.2-2 ii liboce-modeling11 0.18.2-2 ii liboce-ocaf-lite11 0.18.2-2 ii liboce-ocaf11 0.18.2-2 ii liboce-visualization11 0.18.2-2 ii libpyside1.21.2.2+source1-2 ii libpython2.72.7.14-2 ii libqt4-network 4:4.8.7+dfsg-11 ii libqt4-opengl 4:4.8.7+dfsg-11 ii libqt4-svg 4:4.8.7+dfsg-11 ii libqt4-xml 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libshiboken1.2v51.2.2-5+b1 ii libsoqt4-20 1.6.0~e8310f-3 ii libspnav0 0.2.3-1 ii libstdc++6 7.2.0-17 ii libx11-62:1.6.4-3 ii libxerces-c3.2 3.2.0+debian-2 ii libxext62:1.3.3-1+b2 ii libzipios++0v5 0.1.5.9+cvs.2007.04.28-10 ii pyside-tools0.2.15-1+b1 ii python 2.7.14-1 ii python-collada 0.4-2 ii python-matplotlib 2.0.0+dfsg1-2+b1 ii python-pivy 0.5.0~v609hg-3.1 ii python-ply 3.9-1 ii python-pyside 1.2.2+source1-2 ii python2.7 2.7.14-2 ii zlib1g 1:1.2.8.dfsg-5 freecad recommends no packages. Versions of packages freecad suggests: pn graphviz pn povray -- no debconf information
Bug#884091: gimp: bad dependency
Package: gimp Version: 2.8.20-1 Severity: normal Why does gimp have dependencies for both "python2.7" and "python:any"? They can't both be correct. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.8.20-1 ii libaa1 1.4p5-44+b1 ii libatk1.0-0 2.26.0-2 ii libbabl-0.1-00.1.34-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.25-3 ii libcairo21.15.8-2 ii libdbus-1-3 1.12.2-1 ii libdbus-glib-1-2 0.108-3 ii libexif120.6.21-4 ii libexpat12.2.3-2 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-0.1 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libgegl-0.3-00.3.20-3 ii libgimp2.0 2.8.20-1 ii libglib2.0-0 2.54.1-1 ii libgs9 9.22~dfsg-1 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 232-1 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjson-glib-1.0-0 1.4.2-2 ii liblcms2-2 2.8-4 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.40.12-1 ii libpangocairo-1.0-0 1.40.12-1 ii libpangoft2-1.0-01.40.12-1 ii libpng16-16 1.6.34-1 ii libpoppler-glib8 0.61.1-2 ii librsvg2-2 2.40.18-2 ii libsm6 2:1.2.2-1+b3 ii libtiff5 4.0.8-6 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.4-3 ii libxcursor1 1:1.1.14-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii python 2.7.14-1 ii python-gtk2 2.24.0-5.1+b1 ii python2.72.7.14-2 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-1 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help ii gvfs-backends 1.34.1-1+b1 ii libasound21.1.3-5 -- no debconf information
Bug#883917: im-config: doesn't offer UIM as an option
Package: im-config Version: 0.32-1 Severity: important Tags: l10n im-config doesn't offer UIM as an option, even when it is installed. $ dpkg -l | grep uim ii libuim-custom2:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - uim-custom API library ii libuim-scm0:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - uim-scm API library ii libuim8:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - uim library ii uim1:1.8.6+gh20161003.0.d amd64 Universal Input Method - main binary package ii uim-data 1:1.8.6+gh20161003.0.d allUniversal Input Method - data files ii uim-fep1:1.8.6+gh20161003.0.d amd64 Universal Input Method - front end processor ii uim-gtk2.0 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - GTK+2.x front end ii uim-gtk2.0-immodule:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - GTK+2.x IM-module ii uim-gtk3 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - GTK+3.x front end ii uim-gtk3-immodule:amd641:1.8.6+gh20161003.0.d amd64 Universal Input Method - GTK+3.x IM module ii uim-mozc:amd64 2.20.2673.102+dfsg-2 amd64 Mozc engine for uim - Client of the Mozc input method ii uim-plugins:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - plugin files ii uim-qt51:1.8.6+gh20161003.0.d amd64 Universal Input Method - Qt 5.x front end ii uim-qt5-immodule:amd64 1:1.8.6+gh20161003.0.d amd64 Universal Input Method - Qt 5.x IM module ii uim-xim1:1.8.6+gh20161003.0.d amd64 Universal Input Method - XIM compatibility interface See attached image for options offered by im-config with these packages installed. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages im-config depends on: ii gettext-base 0.19.8.1-4 Versions of packages im-config recommends: ii whiptail0.52.20-1+b1 ii x11-common 1:7.7+19 ii zenity 3.26.0-1 im-config suggests no packages. -- Configuration Files: /etc/X11/xinit/xinputrc changed [not included] -- no debconf information
Bug#883766: apt-show-versions: does not work for uninstalled packages
Package: apt-show-versions Version: 0.22.7 Severity: important When querying uninstalled packages, "apt-show-versions" fails with the error message "Use of uninitialized value $arch": # apt-show-versions -a linux-image-4.14.0-1-amd64 linux-image-4.13.0-1-amd64 linux-image-4.13.0-1-amd64:amd64 4.13.13-1 install ok installed No stable version No stable-updates version linux-image-4.13.0-1-amd64:amd64 4.13.13-1 testing ftp.us.debian.org linux-image-4.13.0-1-amd64:amd64 4.13.13-1 unstable ftp.us.debian.org No experimental version linux-image-4.13.0-1-amd64:amd64/testing 4.13.13-1 uptodate Use of uninitialized value $arch in concatenation (.) or string at /usr/bin/apt-show-versions line 370. Use of uninitialized value $arch in hash element at /usr/bin/apt-show-versions line 373. Use of uninitialized value $arch in hash element at /usr/bin/apt-show-versions line 385. No stable version No stable-updates version No testing version No unstable version No experimental version linux-image-4.14.0-1-amd64: not installed (This output would be easier to read if the program would insert a blank line between the sections for different packages.) However, if you restrict the query to a single package, it miraculously starts working: # apt-show-versions -a linux-image-4.14.0-1-amd64 No stable version No stable-updates version No testing version linux-image-4.14.0-1-amd64:amd64 4.14.2-1 unstable ftp.us.debian.org No experimental version linux-image-4.14.0-1-amd64:amd64 not installed This bug has persisted for a long time, although various other bug reports regarding it have previously been opened, and then closed, for some reason. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715314 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725107 "apt-show-versions" still doesn't know its own version number: # apt-show-versions -V Apt-Show-Versions v.0.22.6 (c) Christoph Martin # dpkg -s apt-show-versions | grep Version Version: 0.22.7 You would think that kind of thing could be automated, somehow. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-show-versions depends on: ii apt 1.6~alpha5 ii libapt-pkg-perl 0.1.33 ii libperl5.26 [libstorable-perl] 5.26.1-3 ii perl5.26.1-3 apt-show-versions recommends no packages. apt-show-versions suggests no packages. -- no debconf information
Bug#881904: xul-ext-useragentswitcher: does not work with modern versions of Firefox
Package: xul-ext-useragentswitcher Version: 0.7.3-3 Severity: grave Justification: renders package unusable This Firefox addon has not been updated in six years, and does not work with any version of Firefox available in the current release, even those prior to v57. This package is therefore useless, in its current form. Please replace it with one of the following: https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-revived/ https://addons.mozilla.org/en-US/firefox/addon/custom-user-agent-revived/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-useragentswitcher depends on: ii firefox 57.0-1 xul-ext-useragentswitcher recommends no packages. xul-ext-useragentswitcher suggests no packages. -- no debconf information
Bug#881812: xul-ext-treestyletab: two months out-of-date
Package: xul-ext-treestyletab Version: 0.19.2017061601-1 Followup-For: Bug #881812 Please upgrade this package to the current version, which is required in order to support Firefox v57, as recently uploaded to Unstable. https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/versions/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-treestyletab depends on: ii firefox 57.0-1 xul-ext-treestyletab recommends no packages. xul-ext-treestyletab suggests no packages. -- no debconf information
Bug#875575: vlc: incorrect changelog
Package: src:vlc Version: 2.2.6-6 Severity: normal The Debian changelog entry for vlc/2.2.6-6 says "Update to ffmpeg 2.8.13." However, ffmpeg is currently at version 3.3.3, so this seems inherently implausible. At the very least, further explanation is required. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlc depends on: ii vlc-bin 2.2.6-6 ii vlc-l10n 2.2.6-6 ii vlc-plugin-base 2.2.6-6 ii vlc-plugin-qt2.2.6-6 ii vlc-plugin-video-output 2.2.6-6 Versions of packages vlc recommends: pn vlc-plugin-notify pn vlc-plugin-samba ii vlc-plugin-skins2 2.2.6-6 ii vlc-plugin-video-splitter 2.2.6-6 ii vlc-plugin-visualization 2.2.6-6 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.24-17 ii libvlc5 2.2.6-6 Versions of packages libvlc5 depends on: ii libc62.24-17 ii libvlccore8 2.2.6-6 Versions of packages libvlc5 recommends: ii libvlc-bin 2.2.6-6 Versions of packages libvlccore8 depends on: ii libc62.24-17 ii libdbus-1-3 1.11.16+really1.10.22-1 ii libidn11 1.33-1 Versions of packages libvlccore8 recommends: ii libproxy-tools 0.4.14-3 Versions of packages vlc-bin depends on: ii libc6 2.24-17 ii libvlc-bin 2.2.6-6 ii libvlc5 2.2.6-6 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-19 ii libasound2 1.1.3-5 ii libass91:0.13.7-2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavc1394-0 0.5.4-4+b1 ii libbasicusageenvironment1 2017.07.18-1 ii libbluray2 1:1.0.1.deb1-2 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-17 ii libcairo2 1.14.10-1 ii libcddb2 1.3.2-5 ii libcdio13 0.83-4.3+b1 ii libchromaprint11.4.2-1 ii libcrystalhd3 1:0.0~git20110715.fdd2f19-12 ii libdbus-1-31.11.16+really1.10.22-1 ii libdc1394-22 2.2.5-1 ii libdca00.0.5-10 ii libdvbpsi101.3.1-2 ii libdvdnav4 5.0.3-3 ii libdvdread45.0.3-2 ii libebml4v5 1.3.5-2 ii libfaad2 2.8.1-2 ii libflac8 1.3.2-1 ii libfontconfig1 2.12.3-0.2 ii libfreetype6 2.8-0.2 ii libfribidi00.19.7-1+b1 ii libgcc11:7.2.0-4 ii libgcrypt201.7.9-1 ii libglib2.0-0 2.53.6-1 ii libgme00.6.1-1 ii libgnutls303.5.15-2 ii libgpg-error0 1.27-3 ii libgroupsock8 2017.07.18-1 ii libgsm11.0.13-4+b2 ii libjpeg62-turbo1:1.5.2-2 ii libkate1 0.4.1-7+b1 ii liblirc-client00.10.0-2 ii liblivemedia58 2017.07.18-1 ii liblua5.2-05.2.4-1.1+b2 ii liblzma5 5.2.2-1.3 ii libmad00.15.1b-8+b2 ii libmatroska6v5 1.4.7-2 ii libmp3lame03.99.5+repack1-9+b2 ii libmpcdec6 2:0.1~r495-1+b1 ii libmpeg2-4 0.5.1-8 ii libmtp91.1.13-1 ii libncursesw5 6.0+20170902-1 ii libogg01.3.2-1+b1 ii libopenmpt-modplug10.2.8760~beta27-1 ii libopus0 1.2~alpha2-1 ii libpng16-161.6.32-1 ii libpulse0 10.0-2 ii libraw1394-11 2.1.2-1+b1 ii libresid-builder0c2a 2.1.1-15 ii librsvg2-2 2.40.18-1 ii librtmp1 2.4+20151223.gitfa8646d.1-1+b1 ii libsamplerate0 0.1.9-1 ii libsdl-image1.21.2.12-6 ii libsdl1.2debian1.2.15+dfsg2-0.1 ii libshine3 3.1.1-1 ii libshout3 2.4.1-1 ii libsidplay22.1.1-15 ii libsnappy1v5 1.1.6-4 ii libsndio6.11.1.0-3 ii libspeex1 1.2~rc1.2-1+b2 ii libspeexdsp1 1.2~rc1.2-1+b2 ii libssh-gcrypt-40.7.5-1 ii libssh2-1 1.8.0-1 ii libstdc++6 7.2.0-4 ii libtag1v5 1.11.1+dfsg.1-0.1 ii libtheora0 1.1.1+dfsg.1-14+b1 ii libtinfo5 6.0+20170902-1 ii libtwolame00.3.13-3 ii libudev1 234-3 ii libupnp6 1:1.6.22-1 i
Bug#870250: syslinux: duplicate MBR files in Syslinux
Package: syslinux Version: 3:6.03+dfsg-14.1 Severity: normal Syslinux Master Boot Record files have been duplicated across three packages: $ dpkg -L syslinux-common | grep mbr /usr/lib/syslinux/mbr /usr/lib/syslinux/mbr/altmbr.bin /usr/lib/syslinux/mbr/gptmbr.bin /usr/lib/syslinux/mbr/mbr.bin $ dpkg -L syslinux | grep mbr /usr/lib/SYSLINUX/altmbr.bin /usr/lib/SYSLINUX/gptmbr.bin /usr/lib/SYSLINUX/mbr.bin $ dpkg -L extlinux | grep mbr /usr/lib/EXTLINUX/altmbr.bin /usr/lib/EXTLINUX/gptmbr.bin /usr/lib/EXTLINUX/mbr.bin $ ls -l /usr/lib/syslinux/mbr/* /usr/lib/SYSLINUX/* /usr/lib/EXTLINUX/* -rw-r--r-- 1 root root 439 Jan 28 2017 /usr/lib/EXTLINUX/altmbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/EXTLINUX/gptmbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/EXTLINUX/mbr.bin -rw-r--r-- 1 root root 439 Jan 28 2017 /usr/lib/SYSLINUX/altmbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/SYSLINUX/gptmbr.bin -rw-r--r-- 1 root root 439 Jan 28 2017 /usr/lib/syslinux/mbr/altmbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/SYSLINUX/mbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/syslinux/mbr/gptmbr.bin -rw-r--r-- 1 root root 440 Jan 28 2017 /usr/lib/syslinux/mbr/mbr.bin $ md5sum /usr/lib/syslinux/mbr/* /usr/lib/SYSLINUX/* /usr/lib/EXTLINUX/* | sort 0897ba470594ea2ea0c3dbbe4afcfbf3 /usr/lib/EXTLINUX/gptmbr.bin 0897ba470594ea2ea0c3dbbe4afcfbf3 /usr/lib/SYSLINUX/gptmbr.bin 0897ba470594ea2ea0c3dbbe4afcfbf3 /usr/lib/syslinux/mbr/gptmbr.bin 114a332543d206a1884a7da2dedebb02 /usr/lib/EXTLINUX/altmbr.bin 114a332543d206a1884a7da2dedebb02 /usr/lib/SYSLINUX/altmbr.bin 114a332543d206a1884a7da2dedebb02 /usr/lib/syslinux/mbr/altmbr.bin 8cb37afc263a219ebb7586f9c495114e /usr/lib/EXTLINUX/mbr.bin 8cb37afc263a219ebb7586f9c495114e /usr/lib/SYSLINUX/mbr.bin 8cb37afc263a219ebb7586f9c495114e /usr/lib/syslinux/mbr/mbr.bin Obviously, the amount of storage wasted by this duplication is trivial, but to have three files with the same name, in different packages, is quite confusing, until one realizes that they are duplicates. Presumably, Debian has a policy against duplicating files, for this exact reason. A better solution would be for the syslinux and extlinux packages to "Depend" on syslinux-common, rather than just "Recommend"ing it, and to split out the documentation into a new syslinux-doc package, and the EFI32 and EFI64 files into the existing syslinux-efi package. Note that bug #819973 is related to this report. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages syslinux depends on: ii libc6 2.24-12 ii mtools 4.0.18-2+b1 Versions of packages syslinux recommends: ii syslinux-common 3:6.03+dfsg-14.1 Versions of packages syslinux suggests: ii dosfstools 4.1-1 -- no debconf information
Bug#866064: xul-ext-treestyletab: version is out-of-date
Package: xul-ext-treestyletab Version: 0.18.2016111701-1 Severity: normal This package is now seven months, and two versions, out-of-date. Please upgrade to the current version. https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/versions/ -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-treestyletab depends on: ii firefox 54.0-1 xul-ext-treestyletab recommends no packages. xul-ext-treestyletab suggests no packages. -- no debconf information
Bug#857718: blender: enable GPU rendering with openCL
Package: blender
Version: 2.78.a+dfsg0-4
Severity: important
As many people are aware, GPU rendering in Blender with Mesa/openCL is
currently broken. HOWEVER, it appears that all the outstanding problems
are now fixable, if the appropriate patches and updates are applied to
the relevant Debian packages. Therefore, this bug report does not
describe a problem with Blender itself, but what changes must be made
elsewhere to get GPU rendering working.
This is what currently happens when GPU rendering is attempted:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848258
https://developer.blender.org/T50522
There are three separate problems visible here; I have filed a Debian
bug report, with solution, for each of them:
*** implicit declaration of function {lgamma,native_tan} is invalid in C99 ***
This results from using an insufficiently up-to-date version of libclc.
see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857710
*** invalid argument type 'X *' to unary expression ***
This results from a known bug in LLVM; a patch is available upstream.
see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857623
*** unsupported call to function get_local_size ***
This results from a known bug in libclc-amdgcn; a patch is available
upstream. see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857591
All three of these problems are fixable NOW. Once having done that, it
might happen that other problems would become evident, but then they
could be worked on, too. Or it might happen that GPU rendering would
finally just start working.
Can these updates be applied to the Debian archive, in the near future?
-- Ian Bruce
Bug#857710: libclc-dev: some math functions missing; please upgrade to newer version
Package: libclc-dev
Version: 0.2.0+git20160907-3
Severity: important
3D rendering with Blender is one of the most important potential uses
for openCL, among programs in the Debian archive. Currently this is not
working; see here, for example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848258
Among other problems (which are also being worked on), these compiler
warnings are visible:
implicit declaration of function 'lgamma' is invalid in C99
implicit declaration of function 'native_tan' is invalid in C99
If other errors had not terminated compilation, these warnings would
have eventually turned into linker errors. These functions have only
recently been implemented in libclc, and the version in Debian "testing"
is not recent enough to include them:
$ cd /usr/include/clc/
$
$ find . -type f -exec grep lgamma {} \; -print
$
$ find . -type f -exec grep native_tan {} \; -print
$
These are the relevant development commits:
http://llvm.org/viewvc/llvm-project?view=revision&revision=281565
http://llvm.org/viewvc/llvm-project?view=revision&revision=295920
equivalently:
https://github.com/llvm-mirror/libclc/commit/07fa4ae82da5fa75af174f30c498ff160bbf8644
https://github.com/llvm-mirror/libclc/commit/a2593ed8adbf7386f88dfc828cfc32f788ec3983
It appears that the version of libclc in Debian "experimental" includes
lgamma(), but not native_tan(), which only became available a few weeks
ago:
https://packages.debian.org/experimental/all/libclc-dev/filelist
Please upgrade the libclc package in the main Debian archive to a newer
version, which includes both of the above development commits, so that
GPU rendering with openCL will start working.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
Bug#857623: mesa-opencl-icd: openCL is broken in LLVM < v5
Package: mesa-opencl-icd
Version: 13.0.5-1
Severity: important
Tags: upstream patch
LLVM versions before v5 contain a known language bug, involving the use
of pointers as boolean values, which makes them essentially unusable for
openCL:
https://bugs.llvm.org/show_bug.cgi?id=30217
https://reviews.llvm.org/D29038
https://reviews.llvm.org/rL294313
For an example of the problems this causes, see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848258
https://developer.blender.org/T50522
a trivial test case illustrating the bug:
$ cat ptr-expr2.c
int ptr_expr(int *p)
{
if (!p)
return(0);
else
return(1);
}
$ clang-3.9 -x cl -emit-llvm -S ptr-expr2.c
ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression
if (!p)
^~
1 error generated.
$ clang-4.0 -x cl -emit-llvm -S ptr-expr2.c
ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression
if (!p)
^~
1 error generated.
$ clang-5.0 -x cl -emit-llvm -S ptr-expr2.c
$ # compilation succeeds
possible solutions:
- make openCL require LLVM-v5
- backport the bugfix from LLVM-v5 to earlier versions;
it is apparently a single line change (see LLVM link above)
Until one or other of these solutions is applied, openCL in Mesa is
effectively unusable.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mesa-opencl-icd depends on:
ii libc62.24-9
ii libclc-amdgcn0.2.0+git20160907-3
ii libclc-r600 0.2.0+git20160907-3
ii libdrm-amdgpu1 2.4.74-1
ii libdrm-nouveau2 2.4.74-1
ii libdrm-radeon1 2.4.74-1
ii libdrm2 2.4.74-1
ii libelf1 0.168-0.2
ii libexpat12.2.0-2
ii libgcc1 1:6.3.0-6
ii libgcrypt20 1.7.6-1
ii libllvm3.9 1:3.9.1-4
ii libsensors4 1:3.4.0-3+b1
ii libstdc++6 6.3.0-6
ii ocl-icd-libopencl1 [libopencl1] 2.2.11-1
mesa-opencl-icd recommends no packages.
mesa-opencl-icd suggests no packages.
Versions of packages xserver-xorg depends on:
ii x11-xkb-utils 7.7+3+b1
ii xkb-data 2.19-1
ii xserver-xorg-core 2:1.19.2-1
ii xserver-xorg-input-evdev [xorg-driver-input] 1:2.10.5-1
ii xserver-xorg-video-radeon [xorg-driver-video] 1:7.8.0-1+b1
Versions of packages xserver-xorg recommends:
ii libgl1-mesa-dri 13.0.5-1
Versions of packages xserver-xorg-core depends on:
ii keyboard-configuration1.160
ii libaudit1 1:2.6.7-1
ii libbsd0 0.8.3-1
ii libc6 2.24-9
ii libdbus-1-3 1.10.16-1
ii libdrm2 2.4.74-1
ii libegl1-mesa 13.0.5-1
ii libepoxy0 1.3.1-2
ii libgbm1 13.0.5-1
ii libgcrypt20 1.7.6-1
ii libgl1-mesa-glx [libgl1] 13.0.5-1
ii libpciaccess0 0.13.4-1
ii libpixman-1-0 0.34.0-1
ii libselinux1 2.6-3
ii libsystemd0 232-19
ii libudev1 232-19
ii libxau6 1:1.0.8-1
ii libxdmcp6 1:1.1.2-3
ii libxfont2 1:2.0.1-3
ii libxshmfence1 1.2-1
ii udev 232-19
ii xserver-common2:1.19.2-1
Versions of packages xserver-xorg-core recommends:
ii libgl1-mesa-dri 13.0.5-1
ii libpam-systemd 232-19
Versions of packages xserver-xorg-core suggests:
ii xfonts-100dpi1:1.0.4+nmu1
ii xfonts-75dpi 1:1.0.4+nmu1
ii xfonts-scalable 1:1.0.3-1.1
-- no debconf information
Bug#857591: libclc-amdgcn: apply upstream Mesa patch
Package: libclc-amdgcn Version: 0.2.0+git20160907-3 Severity: important Tags: upstream patch Running the "clinfo" utility (with AMD GPU), from the package of the same name, produces the following openCL compile error: unsupported call to function get_local_size This is a known problem, and is being widely complained of, as it makes openCL unusable on AMD GPUs: http://www.google.com/search?q=%22unsupported+call+to+function+get_local_size%22 Fortunately, a patch is now available from Mesa upstream: https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24 However, it is suggested that "distros will probably have to apply that patch individually": https://bugs.freedesktop.org/attachment.cgi?id=130136 Please do so; until this is done, libclc-amdgcn is effectively unusable. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libclc-amdgcn depends on: ii libclang-common-3.9-dev 1:3.9.1-4 ii libclc-dev 0.2.0+git20160907-3 libclc-amdgcn recommends no packages. libclc-amdgcn suggests no packages. -- no debconf information
Bug#857394: libgegl-dev: contains duplicate copy of openCL library files
Package: libgegl-dev
Version: 0.3.8-3+b1
Severity: normal
As far as I understand, Debian packages aren't supposed to contain
duplicate copies of libraries which have been packaged independently
(isn't that a Policy violation?), but that appears to be the case here:
$ dpkg -L opencl-c-headers | grep include/CL | sort
/usr/include/CL
/usr/include/CL/cl_d3d10.h
/usr/include/CL/cl_d3d11.h
/usr/include/CL/cl_dx9_media_sharing.h
/usr/include/CL/cl_egl.h
/usr/include/CL/cl_ext.h
/usr/include/CL/cl_gl_ext.h
/usr/include/CL/cl_gl.h
/usr/include/CL/cl.h
/usr/include/CL/cl_platform.h
/usr/include/CL/opencl.h
$ dpkg -L libgegl-dev | grep include/gegl-0.3/opencl | sort
/usr/include/gegl-0.3/opencl
/usr/include/gegl-0.3/opencl/cl_d3d10.h
/usr/include/gegl-0.3/opencl/cl_ext.h
/usr/include/gegl-0.3/opencl/cl_gl_ext.h
/usr/include/gegl-0.3/opencl/cl_gl.h
/usr/include/gegl-0.3/opencl/cl.h
/usr/include/gegl-0.3/opencl/cl_platform.h
/usr/include/gegl-0.3/opencl/gegl-cl-color.h
/usr/include/gegl-0.3/opencl/gegl-cl.h
/usr/include/gegl-0.3/opencl/gegl-cl-init.h
/usr/include/gegl-0.3/opencl/gegl-cl-random.h
/usr/include/gegl-0.3/opencl/gegl-cl-types.h
/usr/include/gegl-0.3/opencl/opencl.h
The included version of openCL seems to be many years out of date:
$ diff -u /usr/include/{gegl-0.3/opencl,CL}/opencl.h
--- /usr/include/gegl-0.3/opencl/opencl.h 2016-06-26 05:02:45.0
-0700
+++ /usr/include/CL/opencl.h2016-06-14 08:44:21.0 -0700
@@ -1,5 +1,5 @@
/***
- * Copyright (c) 2008-2010 The Khronos Group Inc.
+ * Copyright (c) 2008-2015 The Khronos Group Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and/or associated documentation files (the
It appears that there may also be another independent library, under the
/usr/include/gegl-0.3/npd/ directory.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libgegl-dev depends on:
ii libbabl-dev 0.1.18-1
ii libgegl-0.3-0 0.3.8-3+b1
ii libglib2.0-dev2.50.3-1
ii libjson-glib-dev 1.2.2-1+b1
libgegl-dev recommends no packages.
libgegl-dev suggests no packages.
-- no debconf information
Bug#857117: qpdfview: recommends qpdfview-translations with non-existent version 0.4.14-1+b1
Package: qpdfview Version: 0.4.14-1+b1 Severity: normal Tags: l10n qpdfview-translations seems to consist entirely of internationalization text files, so consequently there is no "+b1" version; however, that is what qpdfview v0.4.14-1+b1 recommends, potentially resulting in non-installation or auto-removal of the internationalization package. This should be corrected to the non-"b1" version. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qpdfview depends on: ii hicolor-icon-theme0.15-1 ii libc6 2.24-9 ii libcups2 2.2.1-8 ii libgcc1 1:6.3.0-6 ii libgl1-mesa-glx [libgl1] 13.0.5-1 ii libpoppler-qt5-1 0.48.0-2 ii libqt5concurrent5 5.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5sql55.7.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii libqt5svg55.7.1~20161021-2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-6 ii zlib1g1:1.2.8.dfsg-5 Versions of packages qpdfview recommends: ii qpdfview-djvu-plugin 0.4.14-1+b1 ii qpdfview-ps-plugin 0.4.14-1+b1 ii qpdfview-translations 0.4.14-1 qpdfview suggests no packages. -- no debconf information
Bug#855871: mdadm: maximum of 27 block devices for RAID assembly
Package: mdadm
Version: 3.4-4
Severity: important
mdadm seems to have a limit of 27 block devices for a RAID array.
Is this limit documented anywhere?
Is it configurable?
I tried the solution suggested here, but it didn't help:
http://dev.bizo.com/2012/07/mdadm-device-or-resource-busy.html
# truncate -s 64M fs.{00..31}
#
# ls
fs.00 fs.03 fs.06 fs.09 fs.12 fs.15 fs.18 fs.21 fs.24 fs.27 fs.30
fs.01 fs.04 fs.07 fs.10 fs.13 fs.16 fs.19 fs.22 fs.25 fs.28 fs.31
fs.02 fs.05 fs.08 fs.11 fs.14 fs.17 fs.20 fs.23 fs.26 fs.29
#
# for x in fs.* ; do losetup --show -f $x ; done
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7
/dev/loop8
/dev/loop9
/dev/loop10
/dev/loop11
/dev/loop12
/dev/loop13
/dev/loop14
/dev/loop15
/dev/loop16
/dev/loop17
/dev/loop18
/dev/loop19
/dev/loop20
/dev/loop21
/dev/loop22
/dev/loop23
/dev/loop24
/dev/loop25
/dev/loop26
/dev/loop27
/dev/loop28
/dev/loop29
/dev/loop30
/dev/loop31
#
# # *** RAID FAILURE *** :
#
# mdadm --build /dev/md/md-test --level=linear --raid-devices=28
/dev/loop{0..27}
mdadm: ADD_NEW_DISK failed for /dev/loop27: Device or resource busy
#
# # *** RAID SUCCESS *** :
#
# mdadm --build /dev/md/md-test --level=linear --raid-devices=27
/dev/loop{0..26}
mdadm: array /dev/md/md-test built and started.
#
# mdadm --detail /dev/md/md-test
/dev/md/md-test:
Version :
Creation Time : Wed Feb 22 07:48:57 2017
Raid Level : linear
Array Size : 1769472 (1728.00 MiB 1811.94 MB)
Raid Devices : 27
Total Devices : 27
State : clean
Active Devices : 27
Working Devices : 27
Failed Devices : 0
Spare Devices : 0
Rounding : 64K
Number Major Minor RaidDevice State
0 700 active sync /dev/loop0
1 711 active sync /dev/loop1
2 722 active sync /dev/loop2
3 733 active sync /dev/loop3
4 744 active sync /dev/loop4
5 755 active sync /dev/loop5
6 766 active sync /dev/loop6
7 777 active sync /dev/loop7
8 788 active sync /dev/loop8
9 799 active sync /dev/loop9
10 7 10 10 active sync /dev/loop10
11 7 11 11 active sync /dev/loop11
12 7 12 12 active sync /dev/loop12
13 7 13 13 active sync /dev/loop13
14 7 14 14 active sync /dev/loop14
15 7 15 15 active sync /dev/loop15
16 7 16 16 active sync /dev/loop16
17 7 17 17 active sync /dev/loop17
18 7 18 18 active sync /dev/loop18
19 7 19 19 active sync /dev/loop19
20 7 20 20 active sync /dev/loop20
21 7 21 21 active sync /dev/loop21
22 7 22 22 active sync /dev/loop22
23 7 23 23 active sync /dev/loop23
24 7 24 24 active sync /dev/loop24
25 7 25 25 active sync /dev/loop25
26 7 26 26 active sync /dev/loop26
#
# mdadm --stop /dev/md/md-test
mdadm: stopped /dev/md/md-test
#
# losetup -d /dev/loop{0..31}
#
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mdadm depends on:
ii debconf [debconf-2.0] 1.5.60
ii libc6 2.24-9
ii lsb-base 9.20161125
ii udev 232-15
Versions of packages mdadm recommends:
ii exim4-daemon-light [mail-transport-agent] 4.88-5
ii kmod 23-2
mdadm suggests no packages.
Bug#827104: Recommends: obsolete package xfce4-volumed
Package: xfce4-settings Version: 4.12.0-2 Severity: normal xfce4-volumed doesn't seem to exist in Xfce 4.12, but the xfce4-settings package still recommends it. This is especially bad, because xfce4-volumed then pulls in the entire gstreamer0.10 set of packages, which are otherwise totally unnecessary and obsolete. Please remove this false dependency. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-settings depends on: ii libc62.22-11 ii libcairo21.14.6-1+b1 ii libdbus-1-3 1.10.8-1 ii libdbus-glib-1-2 0.106-1 ii libexo-1-0 0.10.7-1 ii libfontconfig1 2.11.0-6.4 ii libgarcon-1-00.4.0-2 ii libgarcon-common 0.4.0-2 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.1-1 ii libgtk2.0-0 2.24.30-2 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libupower-glib3 0.99.4-2 ii libx11-6 2:1.6.3-1 ii libxcursor1 1:1.1.14-1+b1 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util74.12.1-2 ii libxfconf-0-24.12.0-2+b1 ii libxi6 2:1.7.6-1 ii libxklavier165.2.1-1 ii libxrandr2 2:1.5.0-1 ii xfconf 4.12.0-2+b1 Versions of packages xfce4-settings recommends: ii x11-utils 7.7+3 pn xfce4-volumed xfce4-settings suggests no packages. -- no debconf information
Bug#827029: udisks2: machine-readable output for "udisksctl loop-setup" and "udisksctl mount"
Package: udisks2 Version: 2.1.7-2 Severity: normal Tags: upstream Contrary to traditional expectations for UNIX command-line utilities (but reminiscent of dumbed-down software systems such as MS-Windows), /usr/bin/udisksctl produces non-informational output, which tells a human user nothing they didn't already know, but makes it difficult to use the results in a script. $ udisksctl loop-setup --file ./linuxmint-17.3-xfce-64bit.iso Mapped file ./linuxmint-17.3-xfce-64bit.iso as /dev/loop0. $ udisksctl mount --block-device /dev/loop0p1 Mounted /dev/loop0p1 at /media/ian/Linux Mint 17.3 Xfce 64-bit. These are not error messages; they are the normal output resulting from successful command execution. Presumably, the output format strings are, respectively: "Mapped file %s as %s." and "Mounted %s at %s." In each case, the first "%s" is simply the command-line argument, and the rest of the text is literal-string boilerplate, so both are completely non-informative. The only useful output is the second "%s", which is the actual result of the command. This should be output by itself, followed only by a newline, so that it can be read and used by a script: LOOP_DEVICE=$(udisksctl loop-setup --file $LOOP_FILE) # --> "/dev/loop0" MOUNT_POINT=$(udisksctl mount --block-device $FILE_SYSTEM) # --> "/media/ian/Linux Mint 17.3 Xfce 64-bit" As it is, in order for these commands to be used in a script, the output must be parsed by regular-expression pattern-matching, or something like that, which is an unnecessary nuisance, and will break as soon as the format string is changed, for any reason. (see below) Please fix this. Let me point out that the output of this program is apparently so unimportant that it hasn't even been internationalized: $ env | grep -e LANG -e LC LC_MESSAGES=fr_CA.utf8 LANG=fr_CA.utf8 LANGUAGE= $ $ pwdd bash: pwdd : commande introuvable $ $ ls foobar ls: impossible d'accéder à 'foobar': Aucun fichier ou dossier de ce type $ $ udisksctl loop-setup --file ./linuxmint-17.3-xfce-64bit.iso Mapped file ./linuxmint-17.3-xfce-64bit.iso as /dev/loop0. $ $ udisksctl mount --block-device /dev/loop0p1 Mounted /dev/loop0p1 at /media/ian/Linux Mint 17.3 Xfce 64-bit. $ If this text isn't necessary for non-English speakers, then it clearly isn't necessary for English speakers, either. PLEASE REMOVE IT. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages udisks2 depends on: ii dbus 1.10.8-1 ii libacl12.2.52-3 ii libatasmart4 0.19-4 ii libc6 2.22-11 ii libglib2.0-0 2.48.1-1 ii libgudev-1.0-0 230-3 ii libpam-systemd 230-2 ii libpolkit-agent-1-00.105-15 ii libpolkit-gobject-1-0 0.105-15 ii libsystemd0230-2 ii libudisks2-0 2.1.7-2 ii parted 3.2-15 ii udev 230-2 Versions of packages udisks2 recommends: ii dosfstools 4.0-2 ii eject2.1.5+deb1+cvs20081104-13.1 ii gdisk1.0.1-1 ii ntfs-3g 1:2016.2.22AR.1-3 ii policykit-1 0.105-15 Versions of packages udisks2 suggests: pn btrfs-tools ii cryptsetup-bin 2:1.7.0-2 pn exfat-utils ii mdadm 3.4-1 pn reiserfsprogs pn xfsprogs -- no debconf information
Bug#812466: gnuplot5 depends on gnuplot4
Package: gnuplot5 Version: 5.0.2+dfsg1-2 Severity: normal # dpkg -l | grep gnuplot ii gnuplot-tex 4.6.6-3 all Command-line driven interactive plotting program. Tex-files ii gnuplot5 5.0.2+dfsg1-2 all Command-line driven interactive plotting program, version 5 ii gnuplot5-data5.0.2+dfsg1-2 all Command-line driven interactive plotting program. Data-files ii gnuplot5-doc 5.0.2+dfsg1-2 all Command-line driven interactive plotting program. Doc-package ii gnuplot5-x11 5.0.2+dfsg1-2 amd64 Command-line driven interactive plotting program. X-package # # apt-get remove gnuplot-tex Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnuplot5-data : Depends: gnuplot-tex but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. # # apt-show-versions -a gnuplot-tex gnuplot-tex:all 4.6.6-3 install ok installed gnuplot-tex:all 4.6.6-2 stable ftp.us.debian.org No stable-updates version gnuplot-tex:all 4.6.6-3 testing ftp.us.debian.org gnuplot-tex:all 4.6.6-3 unstable ftp.us.debian.org gnuplot-tex:all/testing 4.6.6-3 uptodate # -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnuplot5 depends on: ii gnuplot5-x11 [gnuplot5-nox] 5.0.2+dfsg1-2 gnuplot5 recommends no packages. Versions of packages gnuplot5 suggests: ii gnuplot5-doc 5.0.2+dfsg1-2 -- no debconf information
Bug#806533: systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot)
Package: systemd-sysv Version: 228-2 Severity: important This option seems to have recently disappeared; see here, for example: http://linuxcommand.org/man_pages/shutdown8.html It seems to be related to systemd; perhaps it's supposed to be an "improvement". http://forums.fedoraforum.org/showthread.php?t=268935 There are a wide variety of situations in which you might want to force filesystem checks on reboot, which is why this option existed in the first place. There is no valid reason for removing it -- it's OPTIONAL. Can we please have it back? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-sysv depends on: ii systemd 228-2 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information
Bug#780754: ruby-rmagick: README.html is defective
Package: ruby-rmagick Version: 2.13.2-4+b1 Severity: normal There's clearly something wrong with the README.html documentation file for this package. See attached screenshot. -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ruby-rmagick depends on: ii libc6 2.19-15 ii libgmp10 2:6.0.0+dfsg-6 ii libmagickcore-6.q16-2 8:6.8.9.9-5 ii libruby2.1 2.1.5-1 ii ruby 1:2.1.5 ruby-rmagick recommends no packages. ruby-rmagick suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#493366: info2www: not just a typo, but incorrect information
Package: info2www Version: 1.2.2.9-24 Followup-For: Bug #493366 The previously mentioned misspelling of "/vaw/www/" still persists, but the advice given in README.Debian is incorrect in another regard as well. The current default configuration for the Debian apache2 package specifies /var/www/html as the DocumentRoot, so even without the misspelling, the instructions on enabling info2www will fail. Currently, the correct command would be: ln -s /var/lib/info2www /var/www/html/ As mentioned above, the trailing slash specified in the README is unnecessary for the first argument. However, it is just as well to include one for the second argument. If that directory does not exist, this will force an error. Without the trailing slash, if that directory did not exist, a symlink named "html" would be silently created, which is certainly not a satisfactory outcome. -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages info2www depends on: ii apache2 [httpd-cgi] 2.4.10-9 ii perl 5.20.2-2 info2www recommends no packages. info2www suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779544: phppgadmin: apache config needs "mod_dir" enabled
Package: phppgadmin Version: 5.1-1.1 Severity: critical Justification: breaks unrelated software Installing phppgadmin breaks the Apache webserver: # /etc/init.d/apache2 start [] Starting apache2 (via systemctl): apache2.serviceJob for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details. failed! # # systemctl -l status apache2.service + apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2) Active: failed (Result: exit-code) since Sun 2015-03-01 20:15:35 PST; 13s ago Process: 15301 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS) Process: 15591 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE) Mar 01 20:15:35 quadlie apache2[15591]: Starting web server: apache2 failed! Mar 01 20:15:35 quadlie apache2[15591]: The apache2 configtest failed. ... (warning). Mar 01 20:15:35 quadlie apache2[15591]: Output of config test was: Mar 01 20:15:35 quadlie apache2[15591]: AH00526: Syntax error on line 5 of /etc/apache2/conf-enabled/phppgadmin.conf: Mar 01 20:15:35 quadlie apache2[15591]: Invalid command 'DirectoryIndex', perhaps misspelled or defined by a module not included in the server configuration Mar 01 20:15:35 quadlie apache2[15591]: Action 'configtest' failed. Mar 01 20:15:35 quadlie apache2[15591]: The Apache error log may have more information. Mar 01 20:15:35 quadlie systemd[1]: apache2.service: control process exited, code=exited status=1 Mar 01 20:15:35 quadlie systemd[1]: Failed to start LSB: Apache2 web server. Mar 01 20:15:35 quadlie systemd[1]: Unit apache2.service entered failed state. It appears that "mod_dir" needs to be enabled: http://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryindex You could do this manually, but shouldn't it happen automatically? -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages phppgadmin depends on: ii libapache2-mod-php5 5.6.5+dfsg-2 ii libjs-jquery 1.7.2+dfsg-3 ii php5-pgsql 5.6.5+dfsg-2 Versions of packages phppgadmin recommends: ii apache2 [httpd] 2.4.10-9 ii postgresql-doc 9.4+165 Versions of packages phppgadmin suggests: ii postgresql 9.4+165 pn slony1-bin -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768787: xfce4-screenshooter: documentation in wrong directory
Package: xfce4-screenshooter Version: 1.8.1-5 Severity: normal Tags: l10n The xfce4-screenshooter package contains some files under the /usr/share/xfce4/doc/ast/ directory. (Asturian translation?) This is surely the wrong place. All the other translations are under /usr/share/doc/xfce4-screenshooter/html/ . There is no reason why this language, for this package, should be a special case; it should be moved. -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4-screenshooter depends on: ii libc6 2.19-12 ii libcairo2 1.14.0-2.1 ii libexo-1-0 0.10.2-4 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.0-2 ii libgtk2.0-0 2.24.25-1 ii libsoup2.4-12.44.2-1 ii libx11-62:1.6.2-3 ii libxext62:1.3.1-2+deb7u1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfixes3 1:5.0-4+deb7u1 Versions of packages xfce4-screenshooter recommends: ii libatk1.0-0 2.14.0-1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libice6 2:1.0.8-2 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-01.36.8-2 ii libsm6 2:1.2.1-2 ii xfce4-panel 4.10.1-1 xfce4-screenshooter suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748840: emscripten: change dependency to llvm-3.3 OR llvm-3.4
Package: emscripten Severity: normal Package emscripten depends on "clang-3.2 | clang-3.3 | clang-3.4" and "llvm (>= 1:3.3)". But the latest version of package llvm in the archive IS 3.3 . This means that if you already have clang-3.4/llvm-3.4 installed, installing emscripten will require installing clang-3.3/llvm-3.3 as well, apparently needlessly. The llvm dependency should therefore be changed to "llvm-3.3 | llvm-3.4". Consider whether clang-3.5/llvm-3.5 would also be acceptable. -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735918: bfgminer version is out of date
Package: bfgminer Version: 3.8.1-1 Severity: normal As of January 15, 2014, BFGMiner v3.10.0 is available. http://bfgminer.org/ https://bitcointalk.org/?topic=168174.msg4532634#msg4532634 The version in Debian unstable is 3.9.0 . Please upgrade when convenient. -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bfgminer depends on: ii libblkmaker-0.1-0 0.3.2-1 ii libc6 2.17-97 ii libcurl3-gnutls7.26.0-1+wheezy3 ii libevent-2.0-5 2.0.19-stable-3 ii libjansson42.5-2 ii libmicrohttpd100.9.33-1 ii libncurses55.9-10 ii libsensors41:3.3.2-2 ii libtinfo5 5.9-10 ii libudev1 204-6 ii libusb-1.0-0 2:1.0.11-1 Versions of packages bfgminer recommends: ii amd-opencl-icd [opencl-icd] 1:13.12-3 pn ocl-icd-libopencl1 bfgminer suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704198: syslinux doesn't rewrite backup boot sector
Package: syslinux Version: 3:4.05+dfsg-6+deb7u2 Severity: normal Tags: upstream After installing Syslinux on a USB flashdrive: syslinux -d /boot/syslinux/ -i /dev/sde1 as described here: http://www.syslinux.org/wiki/index.php/SYSLINUX#Linux -- I found that "dosfsck", from the dosfstools package, isn't happy about it: # dosfsck /dev/sde1 dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN There are differences between boot sector and its backup. Differences: (offset:original/backup) ... This doesn't seem to prevent booting from the partition, but such errors are disconcerting, and presumably the backup is there for a reason. There is some discussion of the technical issues involved here: http://en.wikipedia.org/wiki/File_Allocation_Table#Technical_design For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup (logical sector 0 only) for the bootstrap loader, Microsoft's boot sector code has grown to spawn over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. -- but the basic problem seems clear enough. If Syslinux writes its bootloader code into the VFAT boot sector, shouldn't it write a duplicate copy into the backup area? I have attached a copy of the first 32 (512-byte) sectors of the flashdrive partition in question, in case anybody wants to investigate this problem in detail, although it shouldn't be difficult to replicate. -- Ian Bruce -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages syslinux depends on: ii libc62.13-38 ii libuuid1 2.20.1-5.3 ii syslinux-common 3:4.05+dfsg-6+deb7u2 Versions of packages syslinux recommends: ii mtools 4.0.17-1 Versions of packages syslinux suggests: ii dosfstools 3.0.13-1 ii os-prober 1.42 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691690: texlive-extra-utils: missing dependencies
Package: texlive-extra-utils Version: 2012.20120611-2 Severity: normal /usr/bin/pdfjam reports the following errors: pdfjam ERROR: can't find pdflatex! pdfjam ERROR: LaTeX package pdfpages.sty is not installed It turns out that the required files are /usr/bin/pdflatex , and /usr/share/texlive/texmf-dist/tex/latex/pdfpages/pdfpages.sty , from the packages texlive-latex-base , and texlive-latex-recommended , respectively. Shouldn't these packages be listed as dependencies of texlive-extra-utils ? ## List of ls-R files -rw-r--r-- 1 root root 1285 Oct 28 10:44 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jun 17 18:25 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Oct 3 05:12 /usr/share/texlive/texmf/ls-R -> /var/lib/texmf/ls-R-TEXLIVEMAIN lrwxrwxrwx 1 root root 31 Oct 3 05:12 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 05:12 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 05:12 /usr/share/texlive/texmf/ls-R -> /var/lib/texmf/ls-R-TEXLIVEMAIN ## Config files -rw-r--r-- 1 root root 475 Oct 28 10:22 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 3806 Oct 28 10:44 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 Oct 3 05:12 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3245 Oct 28 10:44 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jun 17 18:25 mktex.cnf -rw-r--r-- 1 root root 475 Oct 28 10:22 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages texlive-extra-utils depends on: ii dpkg 1.16.8 ii install-info 4.13a.dfsg.1-6 ii python2.7.3~rc2-1 ii tex-common3.13 ii texlive-base 2012.20120611-5 ii texlive-binaries 2012.20120628-3 ii texlive-common2012.20120611-5 Versions of packages texlive-extra-utils recommends: ii ghostscript 9.05~dfsg-6.1 ii ruby 4.9 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-3 Versions of packages texlive-extra-utils suggests: pn chktex pn dvidvi pn dvipng pn fragmaster pn lacheck pn latexdiff pn latexmk pn purifyeps pn xindy Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.36.1 ii dpkg 1.16.8 ii ucf3.0025+nmu1 Versions of packages tex-common suggests: ii debhelper 9.20120909 Versions of packages texlive-extra-utils is related to: ii tex-common3.13 ii texlive-binaries 2012.20120628-3 -- debconf information: tex-common/check_texmf_wrong: tex-common/check_texmf_missing: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687710: archivemount: cannot read ISO-9660 archives
Package: archivemount Version: 0.6.1-2+b1 Severity: normal Tags: upstream Basic read operations seem to fail on loop mounts of ISO-9660 images: $ ls -l ubuntu/xubuntu-12.04-desktop-i386.iso -rw-r--r-- 1 ian ian 713338880 Apr 23 14:34 ubuntu/xubuntu-12.04-desktop-i386.iso $ $ archivemount ubuntu/xubuntu-12.04-desktop-i386.iso ./mnt $ $ df ./mnt Filesystem 1K-blocks Used Available Use% Mounted on archivemount 1048576000 0 1048576000 0% /home/ian/linux/mnt $ $ ls -l ./mnt/casper/ total 0 -r--r--r-- 1 root root 36824 Apr 23 06:28 filesystem.manifest -r--r--r-- 1 root root 1249 Apr 23 06:28 filesystem.manifest-remove -r--r--r-- 1 root root11 Apr 23 06:28 filesystem.size -r--r--r-- 1 root root 683204608 Apr 23 06:28 filesystem.squashfs -r--r--r-- 1 root root 15536358 Apr 23 06:28 initrd.lz -r--r--r-- 1 root root 4864480 Apr 23 06:28 vmlinuz $ $ cp ./mnt/casper/initrd.lz . cp: reading `./mnt/casper/initrd.lz': Operation not permitted cp: failed to extend `./initrd.lz': Operation not permitted $ $ ls -l ./initrd.lz -r--r--r-- 1 ian ian 2162688 Sep 15 03:57 ./initrd.lz $ $ rm ./initrd.lz rm: remove write-protected regular file `./initrd.lz'? y $ $ cat ./mnt/casper/initrd.lz >./initrd.lz cat: ./mnt/casper/initrd.lz: Operation not permitted $ $ ls -l ./initrd.lz -rw-r--r-- 1 ian ian 4915200 Sep 15 04:07 ./initrd.lz $ $ rm ./initrd.lz $ $ dd if=./mnt/casper/initrd.lz of=./initrd.lz dd: reading `./mnt/casper/initrd.lz': Operation not permitted 8160+0 records in 8160+0 records out 4177920 bytes (4.2 MB) copied, 0.240161 s, 17.4 MB/s $ $ ls -l ./initrd.lz -rw-r--r-- 1 ian ian 4177920 Sep 15 04:08 ./initrd.lz $ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages archivemount depends on: ii fuse 2.9.0-2 ii libarchive12 3.0.4-2 ii libc6 2.13-35 ii libfuse2 2.9.0-2 archivemount recommends no packages. archivemount suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687009: archivemount: package description contains unicode quote characters
Package: archivemount Version: 0.6.1-2+b1 Severity: minor Tags: l10n Surely package descriptions should be 8-bit only, especially for something as trivial as quotation marks? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages archivemount depends on: ii fuse 2.9.0-2 ii libarchive12 3.0.4-2 ii libc6 2.13-35 ii libfuse2 2.9.0-2 archivemount recommends no packages. archivemount suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684866: coreutils: 64-bit arithmetic overflow in expr(1)
Package: coreutils
Version: 8.13-3.2
Severity: normal
quote from expr(1) info file:
When built with support for the GNU MP library, `expr' uses
arbitrary-precision arithmetic; otherwise, it uses native arithmetic
types and may fail due to arithmetic overflow.
This appears to actually happen:
$ expr 100 \* 100 \* 100
100
$
$ expr 100 \* 100 \* 100 \* 5
500
$
$ expr 100 \* 100 \* 100 \* 9
900
$
$ expr 100 \* 100 \* 100 \* 10
expr: *: Numerical result out of range
Note that 10^19 is close to 2^64 :
$ bc <<< '10^19 ; 2^64'
1000
18446744073709551616
Any shell in current use offers basic arithmetic facilities; surely the
only remaining potential benefit of "expr" is extended-range arithmetic.
Why then is it not compiled to do that?
Alternatively, it appears that gcc supports native 128-bit integers, at
least on some targets, including AMD64. Perhaps use could be made of
that feature.
http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
See here for a related bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608832
Package libgmp10, the above mentioned "GNU MP library", has an
Installed-Size of 492 (kilobytes?).
Package bc, an arbitrary-precision calculator, which appears to be
statically linked against its own MP arithmetic library, has an
Installed-Size of 260.
Surely coreutils can be dynamically linked against some stripped-down
library which will solve this problem? It doesn't seem like implementing
variable precision arithmetic ("+", "-", "*", "/", "%") and relational
("==", "!=", "<", "<=", ">", ">=") operators should take more than a few
tens of kilobytes, maximum.
The version of "expr" in the busybox package suffers from the same
problem. Should a separate bug be filed for that?
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages coreutils depends on:
ii dpkg 1.16.4.3
ii install-info 4.13a.dfsg.1-6
ii libacl1 2.2.51-8
ii libattr1 1:2.4.46-8
ii libc6 2.13-33
ii libselinux1 2.0.96-1
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684227: reportbug: --source command-line option does not work
Package: reportbug Version: 6.4.2 Severity: normal The reportbug manual page documents this option: --src, --source Specify to report the bug against the source package, and not the binary package (default behaviour). This does not work: $ reportbug --source debian-installer No package specified or we were unable to find it in the apt cache; stopping. What does appear to work is this: reportbug src: However, this possibility is not mentioned in the manual page. The actual behaviour of the program and its documentation ought to be brought into agreement with each other, one way or another. -- Package-specific info: ** Environment settings: INTERFACE="text" ** /home/ian/.reportbugrc: reportbug_version "6.4" mode standard ui text realname "Ian Bruce" email "ian_br...@fastmail.net" -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 0.9.7.2 ii python2.7.3~rc2-1 ii python-reportbug 6.4.2 reportbug recommends no packages. Versions of packages reportbug suggests: ii claws-mail 3.8.1-1 pn debconf-utils ii debsums2.0.51 pn dlocate pn emacs22-bin-common | emacs23-bin-common ii exim4 4.80-4 ii exim4-daemon-light [mail-transport-agent] 4.80-4 ii file 5.11-2 ii gnupg 1.4.12-4+b1 ii python-gtk22.24.0-3 ii python-gtkspell2.25.3-11 pn python-urwid ii python-vte 1:0.28.2-4 ii xdg-utils 1.1.0~rc1+git20111210-6 Versions of packages python-reportbug depends on: ii apt 0.9.7.2 ii python2.7.3~rc2-1 ii python-debian 0.1.21 ii python-debianbts 1.11 ii python-support1.0.14 python-reportbug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684224: ghex: indicate insert/overstrike mode
Package: ghex Version: 3.4.1-1 Severity: normal Tags: upstream Apparently ghex can be switched between insert and overstrike edit modes either by the key or by an option in the [Edit] menu. However, there is no visible indication in the main window which of these modes is active, which can cause mistakes. Most other programs indicate this with a change in the cursor, or in some other more explicit way. Suggestion: move the "Insert Mode" checkbox from the [Edit] menu to the main window, beside the already-existing "Show little endian decoding" and "Show unsigned and float as hexadecimal" checkboxes. Failing that, at least change the cursor shape. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ghex depends on: ii dconf-gsettings-backend [gsettings-backend] 0.10.0-3 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.12.2-1 ii libcairo21.12.2-1 ii libgail-3-0 3.4.2-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgtk-3-0 3.4.2-1 ii libgtkhex-3-03.4.1-1 ii libpango1.0-01.30.0-1 ghex recommends no packages. ghex suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684128: src:debian-installer: allow use of binary units in disk partitioner
Package: src:debian-installer
Severity: important
Tags: d-i
The version 6.0 installer invites users to specify the sizes of disk
partitions and volumes in units of "K", "M", "G", and "T". Only later do
they find out that what is meant by this is the politically-correct
decimal units 10^3, 10^6, 10^9, and 10^12, rather than the conventional
binary units of 2^10, 2^20, 2^30, and 2^40. One is only likely to
discover this when the installation is complete, and if that is not what
was wanted, it is then too late to do anything about it other than wipe
the disk and start all over again.
This is not a trivial problem. It is quite reasonable, for example, to
want to be able to say "this system has eight gigabytes of main memory"
and "this system has eight gigabytes of swap space", and have those two
values mean the same thing. The difference between a binary and decimal
"gigabyte" is over seven percent, not insignificant when allocating
filesystem storage.
Currently the only solution is to know in advance (probably by learning
the hard way) that decimal units are being used, and if binary units are
wanted, to write them out in full: 1024, 1048576, 1073741824, etc. This
is clearly not adequate.
Possible solutions:
1 - AT AN ABSOLUTE MINIMUM: at the point where the use of metric
suffixes is suggested, explain that these really are decimal, so that
people who want the binary values know that they need to write them out,
as above.
2 - Give the suffixes the same binary values that many people would
expect them to have, and explain this. There is no need to support the
hard disk manufacturers' deceptive marketing strategy. Flash drives are
not specified with decimal units. (Are they?)
3 - Let the user choose at the beginning of partitioning whether these
units will have binary or decimal meanings, both for specifying new
partitions and volumes, and reporting those that are already present, as
well as the sizes of physical media.
4 - The disk partitioner is presumably based on GNU parted, which allows
either binary ("KiB", "MiB", "GiB", "TiB") or decimal ("KB", "MB", "GB",
"TB") units to be used. Explain to the user that they may specify any of
these units, and pass them through to parted.
5 - Solution (4) leaves open the question of what units will be used to
report volume/partition/disk status. Parted provides the "unit" command
for this purpose, as well as that of solution (3). Perhaps this should
be made available as a menu option, or in some other way.
6 - Alternatively, if the size of some disk volume is an exact multiple
of 2^{10,20,30,40}, report it using the appropriate binary unit,
otherwise with a decimal unit.
http://www.gnu.org/software/parted/manual/html_node/unit.html
Hopefully something can be done about this problem before the next major
release.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679386: lightdm: Language selection is ignored in session, $LANG is system default
Package: lightdm Version: 1.2.2-3 Followup-For: Bug #679386 I confirm this bug report in every detail; what the submitter describes happens exactly the same for me. It used to work, prior to the recent package upgrade. I'm using the XFCE-4 desktop environment; I don't know if that matters. The ~/.dmrc file is written according to the language selected at login, but the environment variables are not set: $ cat ~/.dmrc [Desktop] Session=xfce Language=ja_JP.utf8 $ $ $ locale LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm depends on: ii adduser3.112+nmu2 ii consolekit 0.4.5-1 ii dbus 1.6.0-1 ii debconf [debconf-2.0] 1.5.36.1 ii libc6 2.13-33 ii libglib2.0-0 2.32.3-1 ii libpam0g 1.1.1-6.1+squeeze1 ii libxcb11.8.1-1 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter1.1.6-2 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+1 Versions of packages lightdm suggests: ii accountsservice 0.6.21-6 -- Configuration Files: /etc/lightdm/lightdm.conf changed: [LightDM] [SeatDefaults] xserver-allow-tcp=true greeter-session=lightdm-greeter greeter-hide-users=true session-wrapper=/etc/X11/Xsession [XDMCPServer] [VNCServer] -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675016: ifupdown: don't use PPP updetach option by default
Package: ifupdown Version: 0.7~rc3 Severity: critical Justification: breaks the whole system I have specified this bug as "critical/breaks the whole system", because its effect is that if an external PPP link does not come up for some reason, the system boot fails. It actually gets wedged so hard that you cannot even boot into recovery mode to fix it; the problem can only be resolved with a rescue disk. This is completely unacceptable. According to the ifupdown package changelog, as of version 0.7~alpha4, "ifup -a" will use the "updetach" option for PPP interfaces. This may be an attempt to address the problem described in #127786, #287173, and #347594, wherein it is implied that other boot scripts which depend on the PPP link should be able to rely on it being up by the time they are run. This fails for two reasons. First, the termination of "pppd updetach" does not by any means guarantee that the PPP link is up, only that the attempt was made. It might have timed out and then failed, so other boot processes must be prepared to deal with that contingency anyway. Second, PPP links can go up and down depending on conditions on external WAN links and telephone lines, which are not in any way controllable by the local system or its human administrators. For maximum resiliency, it therefore makes sense to specify the PPP options "persist maxfail 0" in /etc/network/interfaces, so that if the link does not come up on boot, or goes down later, the PPP daemon will keep retrying indefinitely until it does come up. Unfortunately, the combination of these options, a broken WAN link, and the "updetach" option now baked into the ifup binary result in an unbootable system, which cannot even be gotten into recovery mode. This is unacceptable. It is quite inappropriate for "updetach" to be hard-wired into a binary executable, where it can only be removed with a hex editor. However, the patch for #196877, where this change is made, provides another solution to the network dependency problem: "Allow passing PPP options" (presumably in /etc/network/interfaces). If anybody wishes to have the "updetach" behavior, let them specify it there, without forcing it on other installations where it is quite possibly fatal. Suggestion for further work on network dependencies at boot: perhaps this is better handled in a general way for any type of network interface, through hotplug or udev, or something like that? What happens if /etc/network/interfaces specifies "auto eth0/iface eth0 inet dhcp", and the DHCP server is not responding for some reason? Does this also result in a boot failure? Is this not exactly analogous to the PPP situation described above? There seems to be some discussion of these issues in #245642. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ifupdown depends on: ii dpkg 1.16.3 ii initscripts 2.88dsf-22.1 ii iproute 20120105-1 ii libc62.13-32 ii lsb-base 3.2-28 ifupdown recommends no packages. Versions of packages ifupdown suggests: pn isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5 pn net-tools 1.60-23 pn ppp2.4.5-5.1 pn rdnssd -- no debconf information -- debsums errors found: debsums: changed file /sbin/ifdown (from ifupdown package) debsums: changed file /sbin/ifquery (from ifupdown package) debsums: changed file /sbin/ifup (from ifupdown package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660163: libpodofo0.9.0: PoDoFo version is almost one year out of date
Package: libpodofo0.9.0 Version: 0.9.0-1.1 Severity: normal The latest PoDoFo version in Debian is 0.9.0 . Version 0.9.1 was released on April 26th, 2011, close to one year ago. Please upgrade to the current version. http://podofo.sourceforge.net/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpodofo0.9.0 depends on: ii libc6 2.13-26 ii libfontconfig1 2.8.0-3 ii libfreetype62.4.8-1 ii libgcc1 1:4.6.2-12 ii libjpeg88d-1 ii libstdc++6 4.6.2-12 ii libtiff43.9.5-2 ii zlib1g 1:1.2.3.4.dfsg-3 libpodofo0.9.0 recommends no packages. libpodofo0.9.0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627875: libjson-spirit-dev: missing dependency on libboost-dev
Package: libjson-spirit-dev Version: 4.03-2 Severity: important compilation error: $ g++ -c file.cpp In file included from /usr/include/json_spirit.h:13:0, /usr/include/json_spirit_value.h:19:29: fatal error: boost/config.hpp: No such file or directory compilation terminated. The file "/usr/include/boost/config.hpp" is found in package libboost1.42-dev or libboost1.46-dev . libboost-dev depends on one or other of these, so making libjson-spirit-dev depend on it will fix the problem. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement
Package: libwebkit-1.0-2 Version: 1.2.0-1 Severity: important Webkit seems to make a DNS query for every mouse movement event that it receives from the browser window. (This happens with both Epiphany and Midori, so I assume that the problem is in Webkit.) This is easy to reproduce; run the following command (as root): tcpdump -n -i eth0 port 53 (use appropriate network interface for remote DNS server) Then load any random website (say, www.debian.org) into a browser window, and simply move the mouse pointer around in that window, without clicking on anything. This will generate a continuous stream of hundreds of DNS queries, of the following form: 21:54:13.616734 IP client.address.net.55545 > dns.server.net.53: 47984+ A? . (17) 21:54:13.616870 IP client.address.net.55545 > dns.server.net.53: 21375+ ? . (17) 21:54:13.637479 IP dns.server.net.53 > client.address.net.55545: 47984 0/1/0 (92) 21:54:13.638427 IP dns.server.net.53 > client.address.net.55545: 21375 0/1/0 (92) 21:54:13.657687 IP client.address.net.40289 > dns.server.net.53: 53754+ A? . (17) 21:54:13.657824 IP client.address.net.40289 > dns.server.net.53: 43656+ ? . (17) 21:54:13.678386 IP dns.server.net.53 > client.address.net.40289: 53754 0/1/0 (92) 21:54:13.678841 IP dns.server.net.53 > client.address.net.40289: 43656 0/1/0 (92) 21:54:13.688747 IP client.address.net.34724 > dns.server.net.53: 52909+ A? . (17) 21:54:13.688878 IP client.address.net.34724 > dns.server.net.53: 19941+ ? . (17) 21:54:13.709435 IP dns.server.net.53 > client.address.net.34724: 52909 0/1/0 (92) 21:54:13.710367 IP dns.server.net.53 > client.address.net.34724: 19941 0/1/0 (92) (IP addresses replaced with appropriate hostnames) Presumably, even with a local DNS server, tracing calls to the DNS resolver library would show the same phenomenon. I have to say that I find this behaviour appalling. It seems to be a security issue all by itself, and is probably a symptom of even bigger problems. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libwebkit-1.0-2 depends on: ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libenchant1c2a 1.4.2-3.3a wrapper library for various spel ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgail18 2.20.0-2 GNOME Accessibility Implementation ii libgcc1 1:4.4.2-9GCC support library ii libglib2.0-02.24.0-1 The GLib library of C routines ii libgstreamer-plugins-base0. 0.10.28-1GStreamer libraries from the "base ii libgstreamer0.10-0 0.10.28-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.20.0-2 The GTK+ graphical user interface ii libicu424.2.1-3 International Components for Unico ii libjpeg62 6b-15The Independent JPEG Group's JPEG ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio ii libpng12-0 1.2.43-1 PNG library - runtime ii libsoup2.4-12.30.0-1 an HTTP library implementation in ii libsqlite3-03.6.23.1-1 SQLite 3 shared library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libwebkit-1.0-common1.2.0-1 Web content engine library for Gtk ii libxml2 2.7.7.dfsg-1 GNOME XML library ii libxslt1.1 1.1.26-2 XSLT processing library - runtime ii libxt6 1:1.0.7-1X11 toolkit intrinsics library libwebkit-1.0-2 recommends no packages. libwebkit-1.0-2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#577629: galeon: "Detach Tab" causes segmentation fault
Package: galeon Version: 2.0.7-2.1 Severity: important This problem is easily reproducible: Open at least two tabs in a Galeon window; these can be blank. Select the "Detach Tab" item in the "Tabs" menu. Immediate segmentation fault, with the following error messages: ** (galeon:2219): WARNING **: Spinner rest icon not found ** (galeon:2219): WARNING **: Spinner rest icon not found (galeon:2219): GLib-GObject-WARNING **: invalid (NULL) pointer instance (galeon:2219): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (galeon:2219): GLib-GObject-WARNING **: invalid (NULL) pointer instance (galeon:2219): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** (galeon:2219): CRITICAL **: sync_tab_security: assertion `GALEON_IS_EMBED (embed)' failed Segmentation fault -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages galeon depends on: ii galeon-common 2.0.7-2.1data for the galeon web browser ii gconf2 2.28.0-1 GNOME configuration database syste 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-6 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9GCC support library 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.24.0-1 The GLib library of C routines ii libgnome-desktop-2-11 2.28.2-1 Utility library for loading .deskt ii libgnome2-0 2.28.0-1 The GNOME library - runtime files ii libgnomeui-02.24.2-1 The GNOME libraries (User Interfac ii libgnomevfs2-0 1:2.24.2-2 GNOME Virtual File System (runtime ii libgtk2.0-0 2.20.0-2 The GTK+ graphical user interface ii libnspr4-0d 4.8.4-1 NetScape Portable Runtime Library ii liborbit2 1:2.14.17-2 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.26.2-2 Layout and rendering of internatio ii libpopt01.15-1 lib for parsing cmdline parameters ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libx11-62:1.3.3-2X11 client-side library ii libxml2 2.7.7.dfsg-1 GNOME XML library ii procps 1:3.2.8-8/proc file system utilities ii xulrunner-1.9.1 1.9.1.9-3XUL + XPCOM application runner Versions of packages galeon recommends: ii gnome-control-center 1:2.28.1-2 utilities to configure the GNOME d ii gnome-icon-theme 2.28.0-1GNOME Desktop icon theme ii iso-codes3.8-1 ISO language, territory, currency, ii rarian-compat [scrollkee 0.8.1-4 Documentation meta-data library (c ii scrollkeeper 0.8.1-4 Transitional package for scrollkee ii yelp 2.28.0+webkit-2 Help browser for GNOME Versions of packages galeon suggests: pn mozplugger (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545274: dpkg-dev: dpkg-source cannot verify GPG signatures
Package: dpkg-dev Version: 1.15.3.1 Severity: important $ dscverify psutils_1.17-27.dsc psutils_1.17-27.dsc: Good signature found validating psutils_1.17.orig.tar.gz validating psutils_1.17-27.diff.gz All files validated successfully. $ $ dpkg-source --require-valid-signature -x psutils_1.17-27.dsc gpgv: keyblock resource `/home/ian/.gnupg/trustedkeys.gpg': general error gpgv: Signature made Wed 19 Aug 2009 04:21:54 PM PDT using DSA key ID D688E0A7 gpgv: Can't check signature: public key not found dpkg-source: error: failed to verify signature on ./psutils_1.17-27.dsc $ -- System Information: Debian Release: 5.0.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii binutils 2.19.51.20090723-1 The GNU assembler, linker and bina ii bzip2 1.0.5-3high-quality block-sorting file co ii dpkg 1.15.3.1 Debian package management system ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii lzma 4.43-14Compression method of 7z format in ii make 3.81-6 An utility for Directing compilati ii patch 2.5.9-5Apply a diff file to an original ii perl [perl5] 5.10.0-25 Larry Wall's Practical Extraction ii perl-modules 5.10.0-25 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii gcc [c-compiler] 4:4.3.3-9 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.4-1The GNU C compiler ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep ii gpgv 1.4.9-4GNU privacy guard - signature veri Versions of packages dpkg-dev suggests: ii debian-keyring [debian-mainta 2009.08.27 GnuPG (and obsolete PGP) keys of D -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531677: iptables: minor errors in man page
Package: iptables Version: 1.4.3.2-2 Severity: normal Tags: patch The attached patch corrects some minor errors in the iptables(8) man page, related to port ranges in the "tcp" module. --- /usr/share/man/man8/iptables.orig.8 2009-04-19 12:25:09.0 -0700 +++ /usr/share/man/man8/iptables.8 2009-06-03 01:30:03.0 -0700 @@ -1187,23 +1187,23 @@ .SS tcp These extensions can be used if `\-\-protocol tcp' is specified. It provides the following options: .TP [\fB!\fP] \fB\-\-source\-port\fP,\fB\-\-sport\fP \fIport\fP[\fB:\fP\fIport\fP] Source port or port range specification. This can either be a service name or a port number. An inclusive range can also be specified, -using the format \fIport\fP\fB:\fP\fIport\fP. +using the format \fIfirst\fP\fB:\fP\fIlast\fP. If the first port is omitted, "0" is assumed; if the last is omitted, "65535" is assumed. -If the second port is greater than the first they will be swapped. +If the first port is greater than the last they will be swapped. The flag \fB\-\-sport\fP is a convenient alias for this option. .TP -[\fB!\fP] \fB\-\-destination\-port\fP,\fB\-\-dport\fP \fIport\fP[\fB,\fP\fIport\fP] +[\fB!\fP] \fB\-\-destination\-port\fP,\fB\-\-dport\fP \fIport\fP[\fB:\fP\fIport\fP] Destination port or port range specification. The flag \fB\-\-dport\fP is a convenient alias for this option. .TP [\fB!\fP] \fB\-\-tcp\-flags\fP \fImask\fP \fIcomp\fP Match when the TCP flags are as specified. The first argument \fImask\fP is the flags which we should examine, written as a comma-separated list, and -- System Information: Debian Release: 5.0.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages iptables depends on: ii libc6 2.9-12 GNU C Library: Shared libraries iptables recommends no packages. iptables suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531052: claws-mail: Message-ID header does not conform to RFC-2822
Package: claws-mail Version: 3.7.1-2 Severity: important Claws-Mail generates Message-ID headers of the form ; for example, <20090529055315.7f6ad...@foobar> . This does not conform to RFC-2822, which requires that the string after the "@" character be a fully-qualified domain name, in order to make the Message-ID globally unique. Some mailing list software will refuse to process messages because of this problem. A better choice would be for the Message-ID to be of the form , where "use...@fqdn" is the sender's email address; for example, <20090309043710.b6bc3b96.ian_br...@fastmail.net> . This is what Sylpheed already does. Please import the relevant code section from Sylpheed, and also send this patch upstream. Thanks. -- System Information: Debian Release: 5.0.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages claws-mail depends on: ii libc62.9-12 GNU C Library: Shared libraries ii libcairo21.8.6-2+b1 The Cairo 2D vector graphics libra ii libcompfaceg11:1.5.2-4 Compress/decompress images for mai ii libdbus-glib-1-2 0.80-4 simple interprocess messaging syst ii libenchant1c2a 1.4.2-3.3 a wrapper library for various spel ii libetpan13 0.57-2 mail handling library ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime libr ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libgnutls26 2.6.4-2 the GNU TLS library - runtime libr ii libgtk2.0-0 2.16.1-2The GTK+ graphical user interface ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libldap-2.4-22.4.11-1OpenLDAP libraries ii libpango1.0-01.24.0-3+b1 Layout and rendering of internatio ii libpisock9 0.12.3-11 library for communicating with a P ii libsm6 2:1.1.0-2 X11 Session Management library Versions of packages claws-mail recommends: ii aspell-en [aspell-dictionary] 6.0-0-5.1 English dictionary for GNU Aspell ii claws-mail-i18n 3.7.1-2Locale data for Claws Mail (i18n s ii xfonts-100dpi 1:1.0.0-4 100 dpi fonts for X ii xfonts-75dpi 1:1.0.0-4 75 dpi fonts for X Versions of packages claws-mail suggests: pn claws-mail-doc (no description available) pn claws-mail-tools (no description available) ii galeon [www-browser] 2.0.7-1GNOME web browser for advanced use ii gedit 2.26.1-1 official text editor of the GNOME ii w3m [www-browser] 0.5.2-2+b1 WWW browsable pager with excellent ii xemacs21-nomule [www-browser] 21.4.22-1 highly customizable text editor -- -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497037: flightgear: unclear where to put airport data files
Package: flightgear Version: 1.0.0-3+b1 Severity: normal The file "/usr/share/doc/flightgear/README.Debian" says: Additional scenery is available at http://www.flightgear.org/. They should be unpacked into /usr/share/games/FlightGear/Scenery. This works fine for the regular scenery files. However, the FTP servers offer a directory called "AirportsOverlay/", which seems to contain additional airport data; as is, there seems to be a hole in the scenery around the airports, except for the runways. It appears that this directory, and the data files therein, are nowhere mentioned in either the Debian package documentation, or that on the project website. Could the README file above be updated, to explain where the airport files should be unpacked, or how they should be made available to the program? I am aware of the file "/usr/share/games/FlightGear/Docs/README.scenery", from the "fgfs-base" package. Experimentation with the "FG_SCENERY" environment variable does not seem to solve the problem. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.26-1-amd64 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages flightgear depends on: ii fgfs-base 1.0.0-2 Flight Gear Flight Simulator -- ba ii freeglut3 2.4.0-6.1 OpenGL Utility Toolkit ii libalut0 1.1.0-2 OpenAL Utility Toolkit ii libc6 2.7-13GNU C Library: Shared libraries ii libgcc11:4.3.1-2 GCC support library ii libgl1-mesa-glx [libgl 7.0.3-5 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.0.3-5 The OpenGL utility library (GLU) ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libopenal1 1:1.4.272-1 Software implementation of the Ope ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxmu61:1.0.2-2 X11 miscellaneous utility library ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii plib1.8.4c21.8.4-10 Portability Libraries: Run-time pa ii simgear1.0.0 1.0.0-4+b1Simulator Construction Gear -- sha ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime flightgear recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496616: libglib1.2ldbl: should "Provides:" libglib1.2
Package: libglib1.2ldbl Version: 1.2.10-19 Severity: important Package libglib1.2ldbl contains these headers: Replaces: libglib1.2 Conflicts: libglib1.2 Shouldn't it then also contain a "Provides: libglib1.2" header? It can't really replace it otherwise. For example, xmms is currently uninstallable. It depends on both libglib1.2 and libgtk1.2 . libgtk1.2 depends on libglib1.2ldbl , but this prevents libglib1.2 from being installed. Is "Replaces:" supposed to be equivalent to "Provides:"? It isn't working that way on this system (AMD64). dpkg : v1.14.20 apt : v0.7.14+b1 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.26-1-amd64 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages libglib1.2ldbl depends on: ii libc6 2.7-13 GNU C Library: Shared libraries libglib1.2ldbl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496283: nvidia-kernel-2.6.26-1-amd64: contains an invalid "Provides:" header
Package: nvidia-kernel-2.6.26-1-amd64 Version: 173.14.09+2 Severity: important This package contains the header "Provides: nvidia-kernel-100.11.14". Shouldn't that match the version number, which is "173.14.09"? The effect of the mismatch is that the corresponding nvidia-glx package is currently uninstallable, because of an unsatisfied dependency. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.26-1-amd64 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495049: grub-pc: does not boot because module "normal" is not loaded
Package: grub-pc
Version: 1.96+20080724-7
Severity: critical
Justification: breaks the whole system
I installed grub because lilo wouldn't boot any more.
My root fs is on lvm; I don't know if this is related.
After running "grub-install" and rebooting, grub drops into the
"grub rescue>" prompt. The "pc", "lvm", and "ext2" modules are loaded,
"ls" finds the root volume, and the variable "root" is set
appropriately.
Investigation shows that if the following commands are issued:
insmod normal
normal
-- then the boot menu specified by "grub.cfg" appears, and the system
boots properly. It turns out that the file "core.img" does not contain
the string "normal".
It seems like this problem should be easy to fix.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/volume11-root / ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/mapper/volume11-root /dev/.static/dev ext3
ro,errors=remount-ro,data=ordered 0 0
/dev/mapper/volume11-home /home ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-usr /usr ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-var /var ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-work /work ext3 rw,errors=continue,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/sda
(volume11-root) /dev/mapper/volume11-root
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
insmod lvm
set root=(volume11-usr)
search --fs-uuid --set b2a61cc9-be9a-43a2-9ca6-900dc4e01ea1
if font /share/grub/ascii.pff ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
terminal gfxterm
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
insmod lvm
set root=(volume11-root)
search --fs-uuid --set cbcda803-4997-4932-bd61-f8bd0a168859
menuentry "Debian GNU/Linux, linux 2.6.26-1-amd64" {
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.26-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.26-1-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.26-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.25-2-amd64" {
linux /boot/vmlinuz-2.6.25-2-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.25-2-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.25-2-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.25-2-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.25-2-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.18-6-amd64" {
linux /boot/vmlinuz-2.6.18-6-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.18-6-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.18-6-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.18-6-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.18-6-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: lenny/sid
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-1-amd64
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages grub-pc depends on:
ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy
ii grub-common 1.96+20080724-7 GRand Unified Bootloader, version
ii libc62.7-13 GNU C Library: Shared libraries
ii liblzo2-22.03-1 data compression library
ii libncurses5 5.6+20080713-1 shared libraries for terminal hand
grub-pc recommends no packages.
-- debconf information:
grub-pc/linux_cmdline: fillme
grub-pc/chainload_from_menu.lst: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419539: options error in Apache config file
Package: apache2.2-common Version: 2.2.3-4 The file "/etc/apache2/sites-available/default" contains this item (in the section): Options ExecCGI -MultiViews +SymLinksIfOwnerMatch This is explicitly disallowed by the Apache documentation. >From <http://httpd.apache.org/docs/2.2/mod/core.html#options> : Normally, if multiple Options could apply to a directory, then the most specific one is used and others are ignored; the options are not merged. However if *all* the options on the Options directive are preceded by a + or - symbol, the options are merged. Prefixing a "+" to the "ExecCGI" option would resolve the issue. This bug is a reversion. I reported it previously (bug #345922), and it was supposed to have been fixed. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372280: [Pkg-shadow-devel] Bug#372280: adduser fails: "configuration error - unknown item"
On Mon, 12 Jun 2006 11:41:00 +0200 Christian Perrier <[EMAIL PROTECTED]> wrote: > > As for fixing the deprecated options, they're included in the version > > of login from the current stable archive. If the already existing > > version dependency in newer versions of passwd were updated to reflect > > this, the whole problem would just go away. > > Hmmm, I'm not sure it would as /etc/login.defs is a configuration > file. Actually, that file will be replaced silently is it has never > been changed by the local adminso the problem will disappear. But, > if the file has been changed, it will never be replaced and then > updating it is left to the local admin. > > So, part from the warning message wording change, I'm not sure we can > do much more. The file will only get replaced when the login package is upgraded. Updating the version dependency in passwd will ensure that this happens. Even if the administrator has edited the file, apt-get will give them the option of replacing it, as well as the option of reviewing the differences between the current and new versions. As things are now, unless you already know where these deprecated parameters are coming from, there is no indication of what the cause of the problem is. Changing the version dependency in passwd will automatically make administrators aware of the issue, after which fixing the problem is trivial. Then you won't need to have any more discussions with people to explain what the source of the problem is. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372280: [Pkg-shadow-devel] Bug#372280: adduser fails: "configuration error - unknown item"
On Fri, 9 Jun 2006 22:30:48 +0200 Christian Perrier <[EMAIL PROTECTED]> wrote: > And each time such "bug" has been reported to login/passwd, it has > been immediately closed as "feature not bug". > > This message is a warning about deprecated options in /etc/login.defs > and is perfectly intended. > > So, actually, users should do what's adviced: warn the system > administrator so that s/he fixes the deprecacted options in login.defs That would be a lot easier if the error message actually referenced /etc/login.defs . As it is now, there is absolutely no indication of where these parameters may be found, so if you don't already know, you're out of luck. As for fixing the deprecated options, they're included in the version of login from the current stable archive. If the already existing version dependency in newer versions of passwd were updated to reflect this, the whole problem would just go away. -- Ian Bruce --- Begin Message --- On Fri, 9 Jun 2006 10:57:57 +0100 Stephen Gran <[EMAIL PROTECTED]> wrote: > This one time, at band camp, Ian Bruce said: > > "adduser" produces a lot of error messages about unrecognized > > parameters, which may or may not be harmless. This may indicate a > > conflict with some version of another package, but it's not clear to me > > which one. > > You have these directives set in /etc/login.defs. My understanding is > that they have been deprecated for some time, but now they create a > warning message. This is not a bug in adduser (in fact, I'm not sure > it's a bug at all - programs do change the acceptable options in their > conf files over time, and it's not a good idea to automatedly overwrite > an edited config file on upgrade). > > Others, I leave it to you whether or not you want to reassign this to > login (the package responsible for login.defs) or just close it. I can > see arguments both ways. The version of "login" on this system is 1:4.0.3-31sarge5 (current "stable" archive). I have not edited /etc/login.defs since installing the operating system. I suggest that a conflict, or an updated version dependency, be put in the "passwd" package to prevent this problem, since it's apparently the one that no longer recognizes these parameters. It's pretty alarming if you don't know what the cause of it is; it barfs up these errors every time "apt-get" tries to create a system userid. It might also be a good idea to change the error message to refer to the login.defs file which is causing the problem; if this had been the case, I could have figured it out for myself. The program /usr/sbin/useradd contains the following string (as do several others from this package): "configuration error - unknown item '%s' (notify administrator)" How about changing that to: "configuration error - unknown item '%s' in file '%s' (notify administrator)" -- Ian Bruce --- End Message ---
Bug#372280: adduser fails: "configuration error - unknown item"
On Fri, 9 Jun 2006 10:57:57 +0100 Stephen Gran <[EMAIL PROTECTED]> wrote: > This one time, at band camp, Ian Bruce said: > > "adduser" produces a lot of error messages about unrecognized > > parameters, which may or may not be harmless. This may indicate a > > conflict with some version of another package, but it's not clear to me > > which one. > > You have these directives set in /etc/login.defs. My understanding is > that they have been deprecated for some time, but now they create a > warning message. This is not a bug in adduser (in fact, I'm not sure > it's a bug at all - programs do change the acceptable options in their > conf files over time, and it's not a good idea to automatedly overwrite > an edited config file on upgrade). > > Others, I leave it to you whether or not you want to reassign this to > login (the package responsible for login.defs) or just close it. I can > see arguments both ways. The version of "login" on this system is 1:4.0.3-31sarge5 (current "stable" archive). I have not edited /etc/login.defs since installing the operating system. I suggest that a conflict, or an updated version dependency, be put in the "passwd" package to prevent this problem, since it's apparently the one that no longer recognizes these parameters. It's pretty alarming if you don't know what the cause of it is; it barfs up these errors every time "apt-get" tries to create a system userid. It might also be a good idea to change the error message to refer to the login.defs file which is causing the problem; if this had been the case, I could have figured it out for myself. The program /usr/sbin/useradd contains the following string (as do several others from this package): "configuration error - unknown item '%s' (notify administrator)" How about changing that to: "configuration error - unknown item '%s' in file '%s' (notify administrator)" -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372280: adduser fails: "configuration error - unknown item"
Package: adduser Version: 3.87 "adduser" produces a lot of error messages about unrecognized parameters, which may or may not be harmless. This may indicate a conflict with some version of another package, but it's not clear to me which one. related packages: passwd : v1:4.0.15-10 debconf : v1.5.1 The first example below shows "adduser" being invoked directly from the command line. The other two examples show the same problem occurring when "apt-get" tries to create system userids while installing other packages. -- Ian Bruce --- # adduser gdubya Adding user `gdubya'... Adding new group `gdubya' (1002). configuration error - unknown item 'FAIL_DELAY' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'NOLOGIN_STR' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MAX_LEN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'CLOSE_SESSIONS' (notify administrator) Adding new user `gdubya' (1002) with group `gdubya'. configuration error - unknown item 'FAIL_DELAY' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'NOLOGIN_STR' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MAX_LEN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'CLOSE_SESSIONS' (notify administrator) --- Setting up nfs-common (1.0.7-17) ... Installing new version of config file /etc/init.d/nfs-common ... Installing new version of config file /etc/default/nfs-common ... Adding system user `statd'... Adding new user `statd' (110) with group `nogroup'. configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'NOLOGIN_STR' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MAX_LEN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'CLOSE_SESSIONS' (notify administrator) --- Setting up gdm (2.14.5-1) ... Adding group `gdm' (107)... configuration error - unknown item 'FAIL_DELAY' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'NOLOGIN_STR' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MAX_LEN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'CLOSE_SESSIONS' (notify administrator) Done. adduser: Warning: The home dir you specified already exists. Adding system user `gdm' with uid 104... Adding new user `gdm' (104) with group `gdm'. configuration error - unknown item 'FAIL_DELAY' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'NOLOGIN_STR' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MAX_LEN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'CLOSE_SESSIONS' (notify administrator) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368845: ISA ethernet device is renumbered on every reboot
On Thu, 25 May 2006 21:57:23 +0200 [EMAIL PROTECTED] (Marco d'Itri) wrote: > Please send me a copy of your /sys/class/net/eth0/ directory (first > make a copy using cp -a and then use tar + gz.) See attachment. Because of the device renumbering, it's actually the /sys/class/net/eth2/ directory; the eth0/ directory doesn't exist. > Does the /sys/class/net/eth0/device/driver/ symlink exist? Probably > not. No. The device/ subdirectory doesn't even exist. > If so, this can be fixed by adding this line to the top of > persistent-net-generator.rules: > > DRIVER!="?*", GOTO="persistent_net_generator_end" That seems to fix the problem. With this change, the /etc/udev/rules.d/z25_persistent-net.rules file is not recreated, and the network interface comes up as eth0 on every reboot. There's still no eth0/device/ subdirectory, however. -- Ian Bruce sys-class-net-eth2.tgz Description: GNU Unix tar archive
Bug#368845: ISA ethernet device is renumbered on every reboot
Package: udev
Version: 0.091-2
I have a Pentium I system with a fresh installation of Debian/stable. I
upgraded it to run a v2.6 kernel ( linux-image-2.6.15-1-486 ), which
pulled in udev as a dependency. Subsequently, I discovered that the
network interface had stopped working.
Investigation shows that the cause of the network malfunction is that
the ethernet device number is incremented on every reboot, and
consequently, the "/etc/network/interfaces" file, which is configured
for "eth0", cannot find it. This seems to be related to the fact that
the file "/etc/udev/rules.d/z25_persistent-net.rules" gets a new entry
added on every reboot:
# UNKNOWN device (/class/net/eth0)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:20:35:XX:YY:ZZ", NAME="eth0"
# UNKNOWN device (/class/net/eth0)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:20:35:XX:YY:ZZ", NAME="eth1"
# UNKNOWN device (/class/net/eth0)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:20:35:XX:YY:ZZ", NAME="eth2"
This went up to "eth7" at one point. If I delete this file and reboot,
then everything works fine: the network interface comes up as "eth0",
and the network init scripts configure it properly. But on the next
boot, it comes up as "eth1", and everything breaks. Subsequent reboots
produce "eth2", "eth3", and so on.
I understand that the intention of this mechanism is to produce
persistent device names for the same physical device, while other
hardware is being added or removed. But in this case, it is producing
exactly the opposite result: the device name changes with every boot,
while the hardware configuration remains the same.
The network configuration of this system is as simple as it could
possibly be: there is one ISA ethernet card, the driver for which is
loaded by the "etc/modules" file. It seems like the default udev
configuration ought to be able to handle this situation without manual
intervention. Whether this problem also affects PCI ethernet cards, I do
not know. It doesn't seem to be an issue with the kernel driver; if I
manually "ifconfig" the device, it starts working immediately.
-- Ian Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364760: can't export server root filesystem
On Sat, 13 May 2006 02:42:37 +0200 "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > On Sat, May 06, 2006 at 02:01:56AM +0200, Steinar H. Gunderson wrote: > > I'm unable to reproduce this; I can export and mount the root file > > system like any other file system, both read-only and read-write. > > What architecture are you on? Have you tried a newer kernel than > > 2.4.27 (ie. something from the 2.6 series)? > > Anything on this? It's not reproducible here, so I'll need more > information from you if I am to help solve the bug. Sorry. I've been trying to figure out what kernel package I'm supposed to use to run Linux v2.6 on a Pentium I, which is what the NFS server in question is. Do you have any idea about that? I should mention that the NFS client was running Linux v2.6, although I don't see why that should matter; presumably the NFS wire protocol is still the same. I have some recollection about seeing it mentioned in the documentation somewhere that exporting root filesystems might be a problem, because of something about the device ID. I can't find that now; I suspect it was in an earlier version of the NFS packages. As soon as I manage to get Linux v2.6 running on the server, I'll try all four permutations of 2.4/2.6 on the client and server and see what happens. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365134: confirmation of severe xdm bug
I'd like to confirm the seriousness of this bug. I have a pre-Xorg X-server, but I thought I would try upgrading xdm to see if that would fix some minor problems associated with "/etc/init.d/xdm restart". Instead, it broke the X-server completely. The original submitter is correct that xdm looks for some executables in the wrong places: # strings /usr/bin/xdm | grep usr /usr/bin/xrdb /usr/bin/xterm -ls /usr/bin/xterm /usr/lib/X11/xdm/chooser :0 local /usr/bin/X :0 /bin:/usr/bin:/usr/bin:/usr/ucb /etc:/bin:/usr/bin:/usr/bin:/usr/ucb /usr/lib/X11/xdm/libXdmGreet.so The file /etc/X11/xdm/Xservers has the same wrong location for the X-server binary. I was able to fix this with a few symlinks, but if I hadn't seen his report of what the problem was, I wouldn't have had a clue. # ls -l /usr/bin/X /usr/bin/xrdb lrwxrwxrwx 1 root root 5 2006-04-28 14:48 /usr/bin/X -> X11/X lrwxrwxrwx 1 root root 8 2006-04-28 14:48 /usr/bin/xrdb -> X11/xrdb In order to fix this reliably, why not give the PATH variable a reasonable value, and then let execlp() find the actual location of the executables? Either that, or have the xdm package create these same symlinks. As the original report says, it is also necessary to change the references in /etc/init.d/xdm and /etc/X11/default-display-manager from "/usr/bin/X11/xdm" to "/usr/bin/xdm". It's hard to see how this problem arose, because these files all come from the same package; there's no question of a version conflict. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364760: can't export server root filesystem
Package: nfs-kernel-server
Version: 1:1.0.7-9
I find that it's impossible to successfully export a root filesystem
which is locally mounted from a hard disk. All other exports involving
the same client/server pair work fine; it only fails when the client
attempts to NFS mount the server's root filesystem.
server filesystem (from /bin/mount):
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
server /etc/exports entry:
/ 192.168.0.0/16(sync)
No error message appears in the logs when the server starts, but
attempting to NFS mount the server root produces a "Permission denied"
error on the client, and the following entry in the server logs:
Apr 25 06:30:21 server mountd[17596]: authenticated mount request from
client:988 for / (/)
Apr 25 06:30:21 server mountd[17596]: getfh failed: Operation not permitted
Conversely, when the root filesystem is not even exported, the same
mount attempt produces this log entry:
Apr 25 06:31:04 server mountd[17596]: refused mount request from client for /
(/): no export entry
And this is a successful mount of a non-root filesystem:
Apr 25 06:47:06 server mountd[17596]: authenticated mount request from
client:993 for /home (/home)
related packages:
nfs-common : 1:1.0.7-9
libnfsidmap1 : version 0.13-1
libc6 : version 2.3.6-7
mount : 2.12r-8
kernel-image-2.4.27-2-386 : version 2.4.27-11
Various configuration examples suggest that it ought to be possible to
export a block-device root filesystem just like any other, but currently
this seems not to work. Perhaps the documentation could explain what
needs to be done to make this possible ("fsid=xxx"?), or if it is in
fact not possible for some reason, make this clear.
-- Ian Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343182: lilypond-data installation/removal is broken
Package: lilypond-data Bug #: 343182 I don't understand why this bug was closed. The explanation given makes no sense. Both installation and removal of this package require the file "/usr/bin/kpsewhich", which seems to come from either package "tetex-bin" or package "libkpathsea-perl". So either one of these packages needs to be listed as a Pre-Depends, or this command needs to be taken out of the installation/removal scripts. See also bug #325907, which reports the same problem, and points out that it constitutes a Debian Policy violation. Again, this bug has not been resolved, and should not have been closed. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345922: options error in Apache config file
Package: apache2-common Version: 2.0.55-3 The file "/etc/apache2/sites-available/default" contains this item (in the "/usr/lib/cgi-bin" section): Options ExecCGI -MultiViews +SymLinksIfOwnerMatch This is explicitly disallowed by the Apache documentation. >From "http://httpd.apache.org/docs/2.0/mod/core.html#options"; : Warning Mixing Options with a + or - with those without is not valid syntax, and is likely to cause unexpected results. This entry does indeed result in various problems, but you will not discover that it is the cause of those problems without carefully reading the documentation. It needs to be fixed. Prefixing a "+" to the "ExecCGI" option would resolve the issue. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308136: pppd segfaults if "call" option is used more than once
It seems that the underlying problem here is that pppd (Debian version
2.4.3-20050321+2) will segfault if you try to use the "call" option more
than once. It has nothing specifically to do with nested use of this
option. This is a new bug; previous versions did not have this problem.
I use pppd like this:
/usr/sbin/pppd call netctrl call myaccount
The file /etc/ppp/peers/netctrl contains:
noauth
defaultroute
/dev/ttyS2
115200
linkname inet
idle 1200
The file /etc/ppp/peers/myaccount contains:
user joe
password abcxyz
The purpose of this is to separate the hardware configuration from the
dialup account information. I also use a standard /etc/ppp/options file
and a "connect" script, but these don't appear to be relevant to the
matter at hand. This all worked fine until I upgraded to the current ppp
version. Now this command segfaults immediately:
/usr/sbin/pppd call netctrl call myaccount dryrun
However, when I concatenate the two config files together, so as to use
a single "call" option, everything works fine; the command prints all
the options and exits normally:
/usr/sbin/pppd call test dryrun
It does not appear that any /var/run/ppp* files are created in either
case; the segfault happens even when these are removed beforehand.
GDB backtrace:
$ gdb /usr/sbin/pppd core
GNU gdb 6.3-debian
...
(gdb) bt
#0 0x08074fd2 in tdb_store ()
#1 0x08051b80 in unlock_db ()
#2 0x08061a11 in int_option ()
#3 0x08060b3b in options_from_list ()
#4 0x080601ef in parse_args ()
#5 0x0804ee59 in main ()
(gdb)
-- which looks pretty much the same as what some other people reported
previously.
To summarize, this bug is simple to reproduce; just use the "call"
option twice. It does not depend on the specific contents of the options
files, or using "call" in nested files. A comparison of the relevant
code section with the previous version should find it; it's probably
something trivial, like some variable not being properly reinitialized
the second time it's used. Using "call" more than once always used to
work, and it seems like a reasonable thing to want to do. It might be
worth investigating the "file" option to see if it now exhibits the same
problem.
A related issue: I'd like to suggest that the secret "password" option
be documented in the manual page. I only found it when I was digging
through the source code trying to figure out how to implement such a
feature; it turned out that somebody already had. When I asked the
upstream maintainers why it wasn't documented, they said that this was
because using it on the command line would be a security hole, as the
authentication password would be exposed by "ps". The simple solution to
that problem is to disallow it on the command line, and only accept it
through the "call" and "file" options. This is the reason why I was
using a "call" option to pass the dialup account information to pppd.
Anyway, for PPP clients, it's a lot more convenient just to use the
"user" and "password" options than messing around with the
{pap,chap}-secrets files. Since the "password" option is already
implemented, it ought to be documented along with the rest of the pppd
options.
-- Ian Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300870: install report: Debian-Installer fails on old IBM PC
On Tue, 29 Mar 2005 14:15:19 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Friday 25 March 2005 15:02, Ian Bruce wrote: > > On Thu, 24 Mar 2005 20:38:28 -0500 > > > > Joey Hess <[EMAIL PROTECTED]> wrote: > > > The installer tries to load all modules in the same order that > > > Debian will load them on boot, to avoid this kind of > > > inconsistency. All I can think of is that there must be some > > > difference between the modules that are loaded or the order they > > > are loaded. This should be reflected in the kernel messages. > > I have compared the load order by the installer and the order in the > loadmodules file. The order seems almost _reversed_, not the same at > all. The third and sixth columns are cross-references to the other. It turns out that in the mkinitrd script there is a function called "print_ide_modules()" which is responsible for most of the contents of this "loadmodules" file. It doesn't appear to do any kind of hardware detection. It just runs "find" on the /lib/modules//kernel/drivers/ide/pci directory, the output of which depends only on the order that the files in that directory were originally copied into it. Notice that both of the lists you quoted are (mostly) alphabetically ordered, the first in reverse. This is undoubtedly a result of modules being copied into various directories in that order; "for x in *" would do it. The implication is that neither the installer nor mkinitrd is particularly concerned about the order in which IDE modules are loaded. > In this case the problem could well be the reversed load order of the > piix and generic modules. I tried hacking the mkinitrd script to reverse the relative order of these two modules, and I also tried eliminating all the other IDE modules except those. Neither change fixed the problem. modprobe -k vesafb > /dev/null 2>&1 modprobe -k fbcon 2> /dev/null modprobe -k unix 2> /dev/null modprobe -k piix > /dev/null 2>&1 modprobe -k generic > /dev/null 2>&1 modprobe -k ide-detect modprobe -k ide-disk The installation floppies still have no difficulty at all with this hardware. What file on them controls module loading? Perhaps some module parameters are required? I could change mkinitrd to produce exactly the same module load order as during installation, but it's not clear to me that this will work either. Any suggestions? > > There is one other oddity I noticed, which may or may not be > > related. When I retry the installation (as I have many times), at > > the "Partition disks" stage (where I choose "manual"), the existing > > ext3 partition on hda is never recognized, although the existing > > swap partition on hdc is. I don't understand why that would happen. > > What do you mean by "recognized"? The screen you get after choosing > "manual partitioning" should look something like [1] (only probably in > English, not in Dutch ;-). > > [1] http://home.tiscali.nl/isildur/d-i/nl/partman.html#09.03 I mean it sees the drive, but not the partition table, on hda, although it does see the partition table on hdc. It looks something like this: IDE1 master (hda) 540MB IDE2 master (hdc)85MB #1 primary 85MB swap I'll make one of those screenshots, if you'll tell me how. The partition table on hda is quite definitely there; GRUB finds it with no problem. It seems to me that this must be related to the reboot failure, somehow. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300870: install report: Debian-Installer fails on old IBM PC
On Thu, 24 Mar 2005 20:38:28 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > The installer tries to load all modules in the same order that Debian > will load them on boot, to avoid this kind of inconsistency. All I can > think of is that there must be some difference between the modules > that are loaded or the order they are loaded. This should be reflected > in the kernel messages. > > So if you can get us a copy of /var/log/debian-installer/syslog, that > will provide the first set of kernel messages, from the installation. > Then if you can copy down as much as possible of the messages when the > installed system fails to boot, I'll bet comparing these two will shed > some useful light on the problem. Thanks for your reply. Fortunately, I saw it just before I was about to try the RC3 install floppies, which would have overwritten this file. Can you tell me why the files in this directory: http://ftp.debian.org/debian/dists/testing/main/installer-i386/rc3/images/floppy/ have a timestamp of March 5th? This is much earlier than the pre-RC3 daily-build images I was using; is that intentional? A gzip'ed copy of /var/log/debian-installer/syslog is attached. Also attached is /var/log/debian-installer/messages , which seemed like it might be relevant. As for the module loading order for the failed reboot, see the "loadmodules" file extracted from the initrd image in my previous message. There is one other oddity I noticed, which may or may not be related. When I retry the installation (as I have many times), at the "Partition disks" stage (where I choose "manual"), the existing ext3 partition on hda is never recognized, although the existing swap partition on hdc is. I don't understand why that would happen. Let me know if there is other information that would be useful in solving this problem. -- Ian Bruce syslog.gz Description: Binary data messages.gz Description: Binary data
Bug#300870: install report: Debian-Installer fails on old IBM PC
Package: installation-reports Of course, I do realize that this isn't exactly current hardware, but I don't see why it shouldn't work anyway. Debian-installer-version: boot floppy daily build of March 18th, from http://people.debian.org/~joeyh/d-i/images/daily/floppy/ Method: boot from floppy, install packages from network Machine: IBM Personal Computer 750 (PCI/ISA, not MicroChannel) chipset: INTEL PCIset SB82437JX + SB82371FB Processor: Pentium-1 133MHz Memory: 48MB Root Device: Quantum 540MB IDE hard disk Partition table: Disk /dev/hda: 541 MB, 541384704 bytes 255 heads, 63 sectors/track, 65 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 65 522081 83 Linux note: swap space is on separate drive, on secondary IDE bus PCI devices: :00:00.0 Host bridge: Intel Corp. 82437FX [Triton FX] (rev 01) :00:01.0 ISA bridge: Intel Corp. 82371FB PIIX ISA [Triton I] (rev 02) :00:01.1 IDE interface: Intel Corp. 82371FB PIIX IDE [Triton I] (rev 02) :00:06.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] :00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 53) Problems: reboot from hard disk fails The installation was carried out with the current daily-build floppy disks (boot, root, drivers), with everything else obtained through the network. Everything proceeds smoothly until the reboot from hard disk. GRUB loads the kernel and initrd image, apparently successfully. The kernel runs through the bootup sequence without issue until it tries to "Partition check" the hard drive. After making some comment about using the PIIX module, and correctly recognizing the Quantum hard drive, it then fails with a bunch of DMA timeout errors. Since neither the install floppies, nor GRUB, nor "tomsrtbt" have any problem at all with this hardware, I infer that it's a software problem. Probably something about the right module not being loaded, or loaded in the wrong order, or a conflict with another module. The installer chose the "kernel-image-2.4.27-2-586tsc_2.4.27-8_i386.deb" kernel package; I also tried the "kernel-image-2.4.27-2-386_2.4.27-8_i386.deb" kernel package, but the result was the same. Attached are the files "/linuxrc.conf", "/script", and "/loadmodules" extracted from the initrd image "/boot/initrd.img-2.4.27-2-586tsc" found on the hard disk after the failed reboot. The initrd package is "initrd-tools_0.1.77_all.deb". Any suggestions? -- Ian Bruce DELAY=0 BUSYBOX= FSTYPES=ext3 IDE_CORE=ide-core VERSION=0.1.77 ROOT=/dev/hda1 unload_unused_ide 'yes' pdc202xx_new adma100 aec62xx alim15x3 amd74xx atiixp cmd640 cmd64x cs5530 cy82c693 generic hpt34x hpt366 ns87415 opti621 pdc202xx_old piix rz1000 sc1200 serverworks siimage sis5513 slc90e66 triflex trm290 via82cxxx modprobe -k vesafb > /dev/null 2>&1 modprobe -k fbcon 2> /dev/null modprobe -k unix 2> /dev/null modprobe -k pdc202xx_new > /dev/null 2>&1 modprobe -k adma100 > /dev/null 2>&1 modprobe -k aec62xx > /dev/null 2>&1 modprobe -k alim15x3 > /dev/null 2>&1 modprobe -k amd74xx > /dev/null 2>&1 modprobe -k atiixp > /dev/null 2>&1 modprobe -k cmd640 > /dev/null 2>&1 modprobe -k cmd64x > /dev/null 2>&1 modprobe -k cs5530 > /dev/null 2>&1 modprobe -k cy82c693 > /dev/null 2>&1 modprobe -k generic > /dev/null 2>&1 modprobe -k hpt34x > /dev/null 2>&1 modprobe -k hpt366 > /dev/null 2>&1 modprobe -k ns87415 > /dev/null 2>&1 modprobe -k opti621 > /dev/null 2>&1 modprobe -k pdc202xx_old > /dev/null 2>&1 modprobe -k piix > /dev/null 2>&1 modprobe -k rz1000 > /dev/null 2>&1 modprobe -k sc1200 > /dev/null 2>&1 modprobe -k serverworks > /dev/null 2>&1 modprobe -k siimage > /dev/null 2>&1 modprobe -k sis5513 > /dev/null 2>&1 modprobe -k slc90e66 > /dev/null 2>&1 modprobe -k triflex > /dev/null 2>&1 modprobe -k trm290 > /dev/null 2>&1 modprobe -k via82cxxx > /dev/null 2>&1 modprobe -k ide-detect modprobe -k ide-disk
Bug#294807: sylpheed v1.0.1-1 doesn't support GnuPG
Package: sylpheed Version: 1.0.1-1 The sylpheed v1.0.1-1 package appears to have been compiled without support for GnuPG. Sylpheed version 1.0.1 requires GPGME v1.0 rather than v0.3 , as previous versions did. If this omission is intentional, it should be noted as such in the README or Changelog files. Another problem is that the installation scripts apparently do not run "update-menus", so that sylpheed disappears from application menus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
